IETF117 Minutes for REGEXT


This is a copy of the transcript created automatically while the meeting was in session.  It is raw and has not been reviewed.  Note that it has time notations between at regular intervals.  Please see the meeting recording for details.




Okay. I have this at the top of the hour. Am I supposed to say something useful? Like, we should wait our customary one minute for late comers, or maybe we should get started? I think I'm gonna vote for getting started. and moving into the meeting here. We do have quite a full agenda. Well, we do have a little bit of time at the end. But we have a lot of different topics to get through And I suspect at least one potentially newish topic then we'll we'll take up some time. So that'll be fine. So I am Jim Galvin, Antoine Bashore, and is the big head over there on the side on the screen. the coach here. of this working group. I'm gonna kick us here to the first half of the agenda, and then he's gonna pick up and and run through the rest, and welcome to the regex working group. atietf117. moving on, This is the standard note well, and although it's only Tuesday, I'm sure that everyone here has seen this at least 3 or 4 times over the course of your day yesterday. So please do keep in mind that you are participating in a public forum. and know, any contribution that you make here is part of this public forum and part of this process. as well. Please also be respectful and kind and express yourself in a tactful way in these meetings throughout the IT app. But here, in particular, It really is very important. our role is about doing what's best for the Internet, not about taking exception with each other. So thank you for that. Okay. Agenda bashing. Our agenda is reasonably proforma.
00:02:01 - 00:04:02


We we do typically talk about status of some of our documents. Then we move into current work and potential new work And that's basically what's going on here. But here's your opportunity for agenda bashing. anybody want to jump out and make a comment about the 5. large set of topics here. not seeing any hands or jumping at the microphone here. We shall continue on. are actually in the midst of our welcome books. what happened to the slides. They disappeared from my oh, they're still over here, but they're off my laptop. Okay. Well, that's fine. So we'll do the welcoming introductions. I'll just flip the slides this way, my my laptop figures itself out. terms of note scribing, we we will take advantage of the trans script that comes from these meetings. We think that that serves nicely as notes. but we would welcome if anyone wants to please do go into the notes area. and it should be prepopulated with the agenda for the meeting. And if you wanna capture specific action items, and particular notes from any element to the meeting, we'd certainly greatly appreciate that. anyone who wants to jump in there and do that for us. So thank you very much for that. In terms of document management, Antoine and I have been moving forward and doing more Oh, g. Okay. Now the server slides also dropped off that they're coming back Okay. We've been doing better with document management in terms of being able to make sure we have document shepherds. We have one document that we'll get to as we're going along here still does not have a document Shepherd. We'll call that out when we get there. But many thanks to folks who have been jumping in and helping out with that. and, of course, participating in reviewing documents and such Okay.
00:04:02 - 00:06:00


I don't have the slides here, and this little clicker is not where Yeah. Well, Jim, apparently, you have looked out of of the of Miteco. So that's why the slides disappeared. So I will I will do the slides for you. Right? Yeah. Go ahead to the next slide. while I see why my lab top won't be logged in here. Okay. And so next slide, please. We don't have any you know, new documents published this time around, same as last time. I think we have a bunch in the hopper here, so that's moving along quickly. So we do have a couple of documents that have been submitted to the ISG. Let me take the second one first tier The RDAP reverse search capabilities is Last time when we checked the status here, it's still waiting on a revised document from the authors. After AD review, but then it will get sent around for its IETF last call, and the AD will move it forward. So that's just a a minor step here that has to happen. then we have the internationalized email addresses. I did send a summary note last night to the mailing list. describing the status of this document from the point of view of the working group I also know it's no longer in my line of sight here. Marries it actually in the room. I think that, Murray, did you want to make a comment about this document at this point here. from your point of view based on the status, please go ahead. Sure. Thanks, Jim, for the summary. It's helpful to switch back all the context since it's been a while since I think we've seen this. But one thing I wanna focus on about in the summary you included is that the working group has has It feels that the outstanding I'm EA related issues are out of scope for the working group, and I'd like to understand how that's
00:06:00 - 00:08:01


what that justification is. when this comes to the ISG for review, we can't sort of sweep aside these matters that we have ways of dealing with internationalized email addresses that are fairly well established. And my mind, that's like saying, well, we don't have to bother with ipv6. even though, like, dealing with ipv6s will draw lots of resistance. This is the same kind of we don't wanna we don't feel like we need to deal with it. I'd really like to understand why that's true. So if I understand the comment and the question, what we're saying here is chose a particular path in the working group for this document. We only allow carriage of one email address and the issue is that We need to explain why that is the right answer. Right. as opposed to Yeah. We either either we have to explain why that's the right answer. being that as John Clinton, I think, was the primary one, but there were others. Right. -- who were along the way speaking to this issue of always having the option of having an all ask a email address available Right? I remember I specifically remember in in the attending Philadelphia meeting, and Pete Resnick was at the mic saying essentially the kind of thing and offering the same sort of solution. document has been revised. I think I counted 6 or 8 some number of times since then. And the only change I can really see is that EAI has gone and replaced by smtbutf8, the thing we're now talking about has not been addressed at all. there's not even a comment in the document to explain why we think this is out of scope. so and it only gets in the shepherd right up either. So if this gets all the way to the ISG and this remains an open that will be brought up during last call. is virtually certain to get blocked by the ISG. So we either need to explain why this is the right path forward and explain why, you know, we wanna bypass this question or we need to fix it.
00:08:01 - 00:10:03


Right. Okay. Well, that's partly an artifact to the way the squirking group works. I mean, even though the issues we're bringing up, it's such a small working group with a small number of people who speak. you you often get You know, I mean, unless you get a number of members of the working group who wanna move forward with something. You we get consensus by by by silence an awful lot -- Yeah. -- true. that objection. I'm I'm sympathetic. There's other you're not the only working group that has this problem, but that means when if there's a small number of people that represent that actually represent that consensus. And and there's any challenge along the way there has to be enough momentum to overcome that challenge, and I don't think it exists right Okay. We have a couple of people in the queue, so let's turn to that and get many years, so Jim Gould, you're up first. And, Jim, if you're speaking, we're not hearing you. Okay. Andy, you had your hand up too. Why don't we go to Andy here? He's actually in the room. We'll come back to you, Jim. Give you a moment to Good organized. So Jim is the authority authority on this topic. However, I did I did offer some text about the SMTPUTFA8. That's a mouthful. the the EAI stuff. And I don't think I I disagree with the the characterization that we're kinda like saying this is an important There is an issue about how many email addresses you can you can put in that are reasonable in that field. Right? Because that that Those email addresses get used doing domain transfers and things like that. And if there's multiple of them, then you get have this huge with how many Yep.
00:10:03 - 00:12:03


do you send email to and blah blah blah blah blah. There are other I I went through and read John Clensen's comments his last call comments, and there were some security considerations I saw on there. and I believe we added them to this draft. basically saying, to be if you're gonna if you're going to do SMTP TSA, which graph, I believe, allows you to signal for then then there are some precautions you have to take on what you allow in those email address. because those it's the copy and pasting issue that is actually the security problem. So I think it's been addressed. If it hasn't, then then we need to we don't need to do. Yeah. Okay. Jim Cole, do you wanna try again? Can you hear me? Yes. Yes. We can. Go ahead, please. Oh, fantastic. Okay. Thank you. Yeah. To, I guess, address Murray's question associated with I can consensus. We had modified this rep multiple times. based on the feedback. The last issue remaining was his cardinality issue. and I had posted message to the list with the options And we had 11 responses on the list, which I there's gotta be a record projects. honestly. And positive for Carnality of 1. And so that was the the the working group speaking. And so we address all of the feedback that was received from the IETF last call. And I'm not exactly sure what your I guess, supporting of the the cardinality of 1, Alright. position. Thank you. Okay. So I I put myself in the queue, and so now I'll I'll jump in I wanna be careful. I wanna I wanna tease something apart here.
00:12:03 - 00:14:03


Because even in my rereading of all this discussion and getting to the end and writing that summary. One thing occurred to me I I think the cardinality issue is in part a red herring The discussion has never been about being able to support multiple email addresses. It should never have been about supporting multiple email addresses. I think that was just an issue that got confused got confusing along the way. It really is about there being one email address that is the contact address and just about having available having the option as a policy matter external to all of this, although is I understood it in rereading John's comments. It's also about from a technical point of view, what we do in the IETF with respect to email, Right? You wanna have the ability to make use of an all as email address. because there are a lot of reasons why in the email experience that's an important element. So there will always be one email address then an alternative that may or may not be present. And whether or not it's present is entirely a policy issue on somebody's part, probably the registry. but whatever whatever I can decides in that respect, So I just wanna I wanted to tease out that comment from you Jim Gould about it's not about cardinality of of 1 versus many. It's just it's always cardinality of 1. It's just about an alternative. to properly support email. think that's what of the flavor of what I remember from Philadelphia, at least. And I don't see that that was addressed in the document. When I looked at the diff between Philadelphia and today, I mean, I agree with Andy that there's been some stuff in security considerations. That general search and replace, I also saw it done, but this one thing seems to be and then in the summary, you, like, you provided,
00:14:03 - 00:16:00


the the disposition of the remaining question was, like, we don't have to deal with that. that's the part I'm questioning. That's I don't think we can go ahead without dealing with that in And if we're gonna say that we have chosen not to deal with it. There has to be a good reason. So Okay. So what I'm hearing and I see Jim Gould's question hand up. I'll give him in in just a moment. So, yeah, what you're asking for is just how it is that we what our what our answer was to this issue that was raised on the list. you consider it a a substantial issue, and whatever we wanna choose is fine. we have to explain that choice in the document. least in the Shepard write up, if not on the document. Yes. Like, because when it gets to the remainder of of who I, like, still have to go through director reviews. We still have to go through full IATF review, and then we have to go through ISG evaluation. And whenever justification exists not taking action on this has to survive all that. And so It's it's it's it serves us well to shore up that argument if that's the argument we wanna or realize that we can't and then deal with it some other way. Some other way. Okay. You actually said something important there that I wanted to call out, which is this explanation could go in the shepherd write up. It doesn't necessarily have to be in the document I I yes. But -- It's true. But if you don't put it in the document, like, director reviewers don't read Shepard write ups. So it may pop up as a result of, like, wait a minute. What's this? So putting it in the document makes it more front and center, but either of those 2 are fine. Okay. Alright. Thank you. Jim Gould. You have your hand up. Yeah. We can go ahead and add that something in the draft itself. And and just to note, There was a version a prior version of the draft that acts had an alternate email address, and that did not work out very well. for the working group. So we attempted that. We moved it back to be a single dominant, and we can go ahead and capture the reason why that is the case. in the draft and the hopefully, the the right up.
00:16:00 - 00:18:00


shopper wrap. Okay. Think we're at a good place, where he's nodding. Let's take a run at Okay. So the action is is just to add some rationale to the document. and we'll we'll figure out how to move that forward and and get that done. Okay. We did take a little longer on that particular item, but I think that was an important conversation. this document has been hanging out for a while. I'm glad we're able to move it forward. k. Next slide, please. Actually, I think I'm back online. Maybe things will work here. Okay. So discussion about documents that are passed working group last call, but not quite moved up yet. We have the open ID document. just waiting for the document shepherd write up. Actually, I think we have a document shepherd write up for that Right? So we just have to review that and move that along. and redacted is also waiting for a document Shepherd write up. I'm I'm sorry. We do have that. do have that too. Okay. Alright. Well, then then it's on your chairs. You have to look at those 2 things and and move them along. So thank you for that. Okay? last little bit here that I'm gonna do. We'll move into quickly looking at existing work here just a quick statement we have 1 new work item, that it's a recently adopted document that is in front of this working group, not much has happened with it. since the last IETF but we did adopt the document from Gavin Brown about being able to adjust the DNS TTLs, the NS record CTLs at the registry. through the registrar kind of an important thing for registrar's registrants to be able to do. part of managing transitions of their DNS and such. So this is just calling out that that's an outstanding work item that hasn't been progressing. But then again, we have a whole bunch of newer work that we've been getting to. A lot has been going on in our DAP other areas here.
00:18:00 - 00:20:02


if I could get these slides to move on here, Well, back over to you, Richard. That sounds fine. typically. I I'm I'm because we decided we could shift about something. The most important thing is need the document shepherd for this document. Right? So if there are any volunteers to be the document shepherd for this document, please let yourself know either the Ultra show on the mailing list. Right. It even says that right in front of me, and I failed to notice that and call it out. But thank you for that. This is the document that needs it. tell, tell, tell, tell, Okay. With that, over to you, Antoine. So I'll take over from here, and let's see what's the first thing on the agenda. It's Tom Harrison. and Tom is remote, I believe. So I will put up his presentation See. I actually don't see Tom in the room. I actually see him you know what? I said, he's remote. So Hello? Oh, I'm sorry. It just came up to the top. I'm looking in alphabetical order, but it goes to the top. Okay. Okay. Okay. Okay. So don't you want to control your slide yourself, though? Yep. Sounds good for So you have control now. Please go ahead. Okay. Thanks. So it's a recap briefly on this document. It defines some new searches for Internet number resources. First part is searching by handle and name for IP ranges. No sense. The second is a set of new link relations and searches for moving up and down the object hierarchy for IP's ASMs and reverse domains.
00:20:02 - 00:22:04


And the third part is extending reverse search so that it can be used for IPs and license, the idea with doing this is that an RII that implements this functionality ends up with an add up service, that's a complete alternative to who is. So that gives the options around things like encouraging transition to add up. as well as, for example, having who is the just a wrapper around a call that's us. So that's what we're doing. There have been a few changes since the last meeting. One of the changes we made between 000001 1 rather was to switch from using the term RIRs to INR registries because there's nothing in the document that's specific to regional registries. It's all just Internet number of resource related content. But we got feedback at the last meeting that the existing documents are in terms of URLs even though they have a similar even though they're similarly situated. So on reviewing that, we switched back to using our hours and just added some text in about it not being IROS specific. We had feedback at the last meeting about because it was only supporting up and down searches if you wanted to get to the top or the bottom over hierarchy, you needed to repeat those searches. until you got there. So short circuiting that by providing top and bottom searches would be useful. So that's been added in. as part of that feedback, it was mentioned that it would be useful to be able to get to the delegation from an IO to a member if you were way down the hierarchy. So to get to support that, we've added in a status query parameter to the searches. because those allegations will have a status of active Whereas delegations from, for example, for example, Diana to a regional tree point. So that's how we're supporting that. And we also to find the search past segments for
00:22:04 - 00:24:01


each of the each of the link relations. So rather than just having the doc be in terms of link relations that you follow to find objects. So everything intern is in terms of some object you've achieved. the search path support arbitrary searches. So more similar to how things work and who is at the moment. And a mono up upside is the document is no longer marked as updating those earlier, RFROCs, We've done that because we wanted to avoid the prefix and the URLs. But the advice at the last meeting was that that wasn't the way to deal with that. So We've just taken that out. We haven't put anything in printing print anything into handle that. Yeah. So we still need to look at that. There are a couple of questions that came up after making the implementation changes. The first one is that the bottom of search includes the argument object if nothing more specific covers it. for example, if you have a slash 24 a slash 25 under it. and you retrieve the you follow the bottom link. for the for the 24, you'll get back to 25 plus the 24. The audio is that the response will completely cover the argument, you'll get kind of the terminal point for for each part for each part of the argument. this is arguably a little bit unintuitive. So it would be good if people could if if anybody had feedback on that, that would be good to have. The other question is whether the links and objects should be mandatory if the relevant objects are present. And that if if we make it mandatory, then that means that the absence of the links can be used to infer the absence of the object So rather than having to Follow a bunch of links to get back empty results, results the client would save some time in that respect. So feedback on that would be useful.
00:24:01 - 00:26:02


As far as next steps go, we are still pending input from the subregional through, so we're following that up. The document in the transition from being just about link relations to including search pods as well. there are still some parts of the document that that are really written in terms of link relations. So we need to go through that and make sure all of that those parts are fixed up. And the last thing is that the again, something that just came during implementation. it'd be useful to clarify that the status parameter applies to all objects in the results that the idea there is that if somebody somebody might think that if you put example, status equals active, can and into a a a then it will stop and it reaches an object that doesn't have status equals active. just clarifying that it's the full It's a full object set, so it can actually sort of skip holes in in the hierarchy would be useful to make it clear how it works. And that's all. Thank you. Thank you Are there any questions for them So, James, go ahead. Hi, Tom. Thanks for publishing this draft. I did post a message to the list. I did a quick review. I didn't do it as deep as I will do in the future. But the main question I had was around the the lack of the prefix on the past segments. And whether or not you'd consider all of our options I put 2 in there, maybe others for example, one of them would be to to find 2 different identifiers, one for the IPs, and the other one for the ATNMs,
00:26:02 - 00:28:03


so that you would be able to use them as is. in the the past segment instead of having to use a prefix. It's like a Planningri, are underbar, But anyways, I just wanted to to ask that, you've thought about other options. Yeah. No. Thanks for that. I I did see that now this morning. but on the skin to But, yeah, for for sure, we're definitely open to other options there. And I think the idea of having yeah. At least in principle, I think the idea of having the 2 extra identifiers just to get just to get just to avoid the the prefix problem, I think that sounds fun. but I I haven't haven't thought of any other ideas, but, yeah, we'll look at that and send up as the list Thanks. Thanks. Okay. And then I put myself in the queue, Tom, if you could since I was responsible for asking for the top bottom searches. Still getting back can go back to that slide So, yeah, the the one in the next one next one. So it a good idea? bottoms yours include the the argument of you. So if I understand you correctly, you know, if if I query specifically for English, 20, let's say. And there are 2 slash 20 ones below when I do a bottom search, I would expect to be returned to 2 slash 20 ones. Right? That's right. Yep. Yep. So why wouldn't that be good idea. because it doesn't include the argument that they're doing. No. That that part. if in the case where In the case where the argument is completely covered by more specific objects. So 21's under a 20. there's there's no problem because
00:28:03 - 00:30:00


because you don't get back the argument object. But if you had, for example, a single 21 under it, and you do the search for the 20. then it then it's about whether do you want to get back just that 21, or do you want to get back the 21 and the 20 completely cover the argument. I think you would want to get both back in that case. Yes. Because I'm I'm I'm expecting, you know, to to research or to query a specific particular IP address in that range. Right? And from my query, you don't know the bottom half of the or the the second half that I'm after. Yeah. Yeah. Yeah. So yeah. So so, basically, that that's what I would expect Right? If I if I query a slash 20 and there's only one point slash 21 below it, then I will expect to get both back. If there are 2 slash 20 ones under it, I would expect to get that 2 sets 21s. Okay. That's good. Thanks. Okay. Thank you. Then just deep. Go ahead. I just deep saying, Erin, So I think And that's alright, Antoine, what you're saying. But just want to clarify, The bottom essentially talking about subnets. Right? slash 21s, So if the intent was just to get the subnet layer then And if you ask for, let's say, slash 20, and there's only one slash 21, returning a slash 20, could it be confusing? So so the semantics of bottom is something. I think the they need to be clarified, I guess, in that sense. Yeah.
00:30:00 - 00:32:00


Well, I I I clarified the use cases on the list. Right? most of the time when you when you were looking for a particular p address. You want to get know, the real end user of the address space And most of the time, that's, you know, in the bottom of the hierarchy. That's what you get back by default when you do who is query as well. my my concern was more with the top query because the top query usually represents the allocation So when you are in search of, you know, who is actually controlling this address space, the would expect top query to give me much of the LAR that's responsible for the allocation. in terms of, you know, when you want to know where RPKI ROAS are maintained and stuff like that. So those were basically my use cases. I understood that in the higher you know, when you look up One IP address, you go to the bottom anyway. Right? And if you but if you are looking for a particular prefice, And you do a bottom query then you are notified that, hey. the particular prefix you're looking at is actually not the user of this address space because there are still two objects below So I think that's cool, Antoine. I just wanted to clarify that. But looks like, as a use case you mentioned, you're alright with what Thomas. So so Thank you. Okay. Thank you. So if there are no more questions for Tom. Then thank you, Tom. Thanks. Thanks. and get the discussion going on the list. I'll take you out of the judge's date, and
00:32:00 - 00:34:01


Let's go to the next presentation on the agenda which is let's see. Yeah. Now we will If I go back to the slayers, chairs, slides, You make this complicated, Jim. So we were here. moving on to no. We were actually here. Yes. Next in on the agenda. It's a discussion on contacts, and we actually have two presentations on this. One is Mario about Jeff's contact. And after that, there will be Andrew on the simple context I want to ask everybody to have the discussion after the press the two presentations so that we can actually have a have a proper discussion here So we'll Start with Mario. I'll put up your slides, Mario. these ones can you share this the can you scroll these slides for me, please? Okay. Yeah. I could put you in control, but I can also scroll to try for you. That's fine. This presentation is about the objections to just contact that have been raised on the main list and also in forums other than ITS. My consideration and to show that these objects objections are at least in my opinion, biased Next slide, please. As far as I understood the main objection, to just contact it is too complex for RADA it is easy to get wrong it it should use the ready raise instead of objects or maps it shouldn't use a batch object to handle localization.
00:34:01 - 00:36:02


Next slide, please. By design, Just contact master represent the same information as GICad. Alright. Now to my knowledge, are the implementers have complained more about the JK cards crutch are rather than the DG card content. Therefore, if ad hoc implemented haven't been concerned about those JEC card elements that are inapplicable, you know, that. But I wonder why they can be concerned about their guest contact counterparts. In addition, in this case, unlike Jacob, there are other prep implementers would supporting ingest ingest contact implementation by 2 documents. But I do believe that the most important thing to auto align is that since the JS contact is a multipurpose representation for contacts. add up implementers who do a great the libraries develop it outside the ad hoc equities them. Next slide, please. Next, please. Yes. This objection looks very back back to me. And those inconsistent with the previous objection. Indeed, If we agree, they just contact is ugly structured, and controlled That's a model. then we should also agree that the more structure and control the data model is the less ambiguous is and the more it's difficult to get wrong. I can surely say that based on my experience with just constitutes you can't you can't build the wrong objects through a library, fully supporting just content implementation and validation. Next slide, please. With regard to the discussion about if it's better to use MET,
00:36:02 - 00:38:03


instead of raise, I think that it should be sufficient to remind that the authors and collects that have been working on just contact for for years to make it ambiguous and ambiguous flexible, expensive, m a Bully that valley Dataable. And at the same time, fully compatible compatible with with Jake Gicotte. Anyway, just to explain the urgency to use maps, we have used the convention that largely known by implementers. I mean, we have used maps for an order in collections and the rates for collection where order may be 4 In addition, when map keys are known in advance, like, in the document about using guest guest contact in add up. getting a map entry is easier than looping on an array and deserializing a map into an object could be straightforward. The system map is basically an object including members of the same type. Next slide, please. The last objection is about as contact and those localizations. I mean, through Petcha object. I would like to act like that a batch object allows to localize both simple and complex values. you have the same process to get the localization of values that raise objects including the card itself and the extensions, and separate the core information provided in the default language from its localization. Definitely, think that the focus should be on if this method is more efficient in terms of extensibility and flex and flexibility replicating the language information whenever it's needed. Next slide, please. My conclusion that being a format fully compact compatible with Jacob. The amount of information contact. Get represent
00:38:03 - 00:40:00


surely far outweighs the needs of other but I consider it as a benefit, not a drawback. The pool that to take out this context by this structure control that say, it's unclear to me how it can be easy to get it wrong. this contest structure has been tuned over time to achieve clearness flexibility and extensibility. Given that the discussion about using arrays instead of maps look looks very simplistic to me. Finally, pitch object is a flexible, extensible, and and definitely to to handle any localization And any alternative solution should be just as efficient. Next slide, please. and that's it. So thank you, Mario. and then we immediately move to the next presentation which is sort of like the other side of the discussion that took place on the mailing list that is simple contact. So that's Andy. So, Andy, go ahead. Alright. Are you clicking for me? Or Yes. I can do that. Okay. Thanks. So the this whole thought about simple contact started when I started writing an RDEB client And I noticed that looking at several RDAP servers, j card is not implemented correctly on all loud servers. There it's not like it's a There are a lot of very simple mistakes you can make the j card that make it very hard to parse. on a client, if you're writing client software, j card is kind of a bear.
00:40:00 - 00:42:00


So my whole thought process here was started off with I wanna write a some software that can do JCAR, but has an internal internal data model. that's compatible with JSContact. And that caused me to to take a very close look at JS contact. And so doing I did not I do not believe JS contact is right for RDEB. I think it is complex too complex for what we need. and suffers from many of the same problems that j JCAR does. just in different ways. Alright. So next slide, please. So The original reason we have Jay Card to begin with is when the Weir's working group was working on our app. the first two or three drafts of RDEB did not have JCAR. That actually had its own internal contact model, and the people working on Jay Card at the time came to us and say, hey. You know, the i and the idea if we eat our own dog food, so you should do be using j card. So we switched to using JCAR. That's how we ended up with that. But the problem is, again, that it's it's easy to easy to get wrong It's a JSON that looks like nothing else in our app. And so you both client client client implementers and certain implementers have a hard time with And as I said, you know, after looking at JS Contact, it suffers from some of some of the same problems. just in different ways. And some of those ways are and where you could get away with using arrays that they have these complex complex map structures, and patch objects are just it it's not a very good solution for saving about a 100 bytes of information. So It's a very complex solution for doing that. Alright. So next slide. other thing is is when you take a step back, jcardandvcardandjscontact Those are you know, they're meant for being virtual business cards. And virtual business cards are are a great thing for putting into
00:42:00 - 00:44:00


into, you know, your virtual Rolodex or your contact or whatnot, but that's not registration data. There there is overlap between registration data and a business card. but that they're not the same thing. When you go to get a domain name or an IP address, you don't give them at least I've never seen it. tell them what your organizational title is. You know what I'm saying? I'm the software by president of operations and I please get this domain name or this IP address? So that kind of information is is superfluous to our app. Both b j card and JS contact have things like you know, birthdays and wedding anniversaries and thing all sorts of things, are not registration data. So when you get when it gets down to it, This is not appropriate for RDEB. and to to insist that a client implement or has to implement all these things that don't have any any relevance to the problem they're working on, It's just a little more than than we need. So the other thing is So if you take a tour around, like, looking for different libraries, You know, we were sold Jay Card being that, hey. There's gonna be all these third party libraries for Jay Card and whatnot. that's absolutely not true. I can only find 2. So dealing with J Card, if you're a client implemented, is very difficult. You basically have to go implement it yourself I don't know of any software third party software like Outlook or anything that ingests it. If Outlook does, I couldn't figure out how to do And so there's no indication to us that JS contact's going to be any different. Different. V card, on the other hand, is the is the kind of dominant virtual business card format So if anything we wanna be supporting vcard, if that is the goal, So, Next step. Next slide. Sorry. next step. Next step. Next step. Next step. So anyway, so I I think one of the things that kind of We we we kinda get wrapped around the axle on is you know, how do we put enough information into our contact model? I know that we've covered all our bases
00:44:00 - 00:46:03


without without going too far. So that's on this kind of like the enticing the the appeal of of the of the other work of JSContact and J Card and whatnot is like, well, it covers all the bases. supposedly. but we actually have enough deployment experience now with our app. and and who is that we actually know with fairly high confidence, what the data elements are that we need And so there's there's a, you know, a couple of RFCs or a profile that ICANN has. It's a profile that the NRO has. So we have a pretty good idea of what data we do need in our app. and and I'm gonna steal a comment from Jazdeep, using thoughtful reduction we can we can actually take what we need and model that. And then we've reduced the the burdens on the on both the the server and the client couple manners. Next slide, please. So here's the here's the top level objects that simple contact supports. There's not a whole there's not a whole lot less than 10. And so the by doing this, we actually cut down on a lot of the information that someone would have to go implement a lot of the things they would have to do. So next slide, Oh, it's in front of me. The other thing when we create our own contact model, there are some things that there's some some works with both JS contact and JCAR that we get out of. So there's a requirement in j card that the FN at mute has to always be populated, but then actually goes against a lot of server policy. The same is true for the UIB in JS contact, you know, we've had these long discussions on the mailing list about these things. But if we use our own contact model, we don't have to worry about finding workarounds for these things. thing we put into the draft is a mechanism for being able to signal for the client Hey. I don't need Jay Card anymore because I understand whatever contact model you have. And so that would in in a lot of cases, it doesn't really matter because it's just extra data.
00:46:03 - 00:48:03


for for when you're doing searches, that can actually be quite a lot of a lot of information. Additionally, because we can target our use case, the simple contact actually specifically addresses the int and low information in our our differences in EPP. Either JS contact or Jay Card even address that. and then we're reusing the the art apps laying attribute for internationalization. Next slide. So here's the feedback we've gotten so far. So When I first introduced this idea, a lot of people were, you know, supportive of it. I do wanna give a hat tip to Gavin Brown for pointing out that we did discuss this in 2019. I or 2018, I'd completely forgotten about it. But for whatever reason, this was always associated specifically with EPP, and that was probably not the I don't think that was ever the intent. So EPPs part of what guides us, but it's not the whole thing. So is not an EPP data model. strictly, we put in a thing in the draft about structured names Tom and I kind of don't think they're really necessary. they don't exist in the who is the the the who is inventory that the the guys from CN during the work the weird working group There is one instance of that. and I guess we could ask the server operator who does that. One instance that we know of whether they actually need it or not So so Marty also pointed out that There are things like birthdays and national IDs, such as social security numbers, which should be in there. And I I I don't know of any RDEB servers that actually serve this information I'm not sure we should put it in. It's kind of a working group decision, I guess. But that would be highly contentious, then we would have to have some pretty good privacy considerations around
00:48:03 - 00:50:05


which kind of goes to the fact that maybe for the other for Jay Card and JS code that we should have some specific guidelines and privacy considerations around those as well. Let me see. I'm trying to go through these without taking up too much time. Marno did point out that we need to be a little more careful with the SMTPUTFA yeah, EAI emails, and I I agree with that. So I I think we need to spend a little more time thinking about that. He also pointed out that the current document, which we kinda put together and paste needs better doc needs better examples. and I agree with that as well. And then one of the interesting comments was Mark Plunchett said that JCARARD is here to stay. that is a very interesting observation in the fact that we currently have J Card It's a mandate from or it's required by the the ICAN GTLD ardAP response. I would say that Jay Card is here for a long time, but I don't think that's always going to be required. So even that that response profile gets updated, every once in a while. So Anyway, that's all I have. Okay. Thank you for that presentation. To put a little bit structure in the discussion that we're going to have, if you have specific questions to one of the presenters, please tell me so I can ask them to give the feedback. If it's a general discussion item for everybody to answer, then please join the queue. to to get answers. Now the first one in the queue that I have is Mark Wonschit. Mark, go ahead. Hello, Martin Blache. our DAP client implementer. And Caitlin in Swift. iOS and Android.
00:50:05 - 00:52:04


Okay. We cannot rewrite the past. I think we would all love G card is ugly to parse but but but we have The cost is already you know, in the past in some ways. Right? and then I'm seeing just so there's those two proposals you know, pros and cons on each and I'm not sure which one would be the best. but we don't want to have. 3 of them. and I'm concerned I'm sorry to Andy, but if GS contact is going, for other protocols you know, for calendar or whatever else. then and then we choose simple contact, then we will have yet another library of of contacts. would great to have only one. and and Andy, you're right that servers are sending shit. But it You know, as an implementer of a client, you know, being used a lot I am actually, you know, looking at all those. And it's been very much, much better, you know, every month. So and and that problem is is going away. So yeah. And, actually, what I'm seeing is more about the other things than the g card does. problem of the of their response from the server. you know you know, So especially now that contact is essentially just everything redacted. k. Thank you. Mark, Next one in the queue. q,
00:52:04 - 00:54:01


Hello. I'm coming to this from the effective of a domain registrar and Yep. I've written the ad apps over that. Generally, I support this. Jay Card and JS contact, I've post post post I've found both of them to be needlessly complicated for what's required for a domain registrar. The the extent of really I need to send back is what someone's email address what what name that they told me they have and what's their postal address. and maybe that telephone number. Like, the the extent of stuff that you can throw into Jay Card is far too much, and it just com makes everything more complicated than it should be. So I I support simple contact, and I think that should be the way moving forward, on a few of the points that have been raised such as structured postal addresses and structured names I don't think they're worthwhile. especially, like, structured names. does I'm sure most of you have seen the infamous blog posts of false hurts programmers believe about names. I just I we should really just have, like, a field for what is your name. because on that's all you need to know. Just like, here's someutf 8 what what should I call you? the same for a postal address because I've read the Universal Postal Union Standard. for which is a UN standard for how a postal address should be encoded. the standard there contains every possible format of a postal address in the world. It's so complicated. It has its own domain specific executable language to generate a postal address. we should not be going we should not try and structure a postal address. We should just have, like, Here are some lines of a postal address. Just put new line characters in. It's fine. You're just going to print this on the front of an envelope to post someone something. It's up to the postal system to deal with get it somewhere. in many countries, the postal addresses
00:54:01 - 00:56:01


not really structured anyway. It's a vague set of instructions for oh, yeah. To that building next to that other building in that town. these and we can trial we want to make the structure and make this lovely format, which can describe everything perfectly. But I think that's unnecessary for what we're trying to achieve, and we should just go for Here's some UTFA that a human will find useful. k. Thank you. 2. Sure. Next, Werner. So Andy wants to respond directly if he can. Oh, sorry. Yeah. Yeah. Sorry about that. The the I totally agree with you structured names. Tom and I went back and forth on this. I wanna point out that Tom pointed me to the discussion in CalEX. There was a working group last call, or maybe it was the IUTF last call. about structured names. one of the reviewers came back and said, this is wrong the way they did it. So I one of my issues with structured names is if we try to do it, we're going to mess up. because, currently, the way easy it is even even the simple contact It's very westernized. And I don't think that works the way we've even done it right now, and I don't think the the way Jay's contact does it, works or and I know JCAR doesn't work with with with non westernized names. So my opinion is that we should Not even not even attempt it. Yeah. I agree with you. Yes. I'll take the risk if arguing in favor of complexity. And your name is? Because -- I've seen send your name for the record. Oh, sorry. My name is Werner style. core association. I've seen simplification come back with the vengeance of complexity so many times. And specifically in the contact clunk context, it has done so
00:56:01 - 00:58:00


to the, you know, point of actually torturing us and specifically, of course, all in all our communities. Now we have simplified things before such as saying that a trend is a contact. just like another contact. It didn't used to be like that. We ended up in that simplification confusing an individual With an organization because in the past, you know, the earlier domain names are mostly organizations. and you have persons attached to that organization. And then something that was just, you know, just a contact. The register's gonna be a contact. We did that 22 years ago, And suddenly, you know, we ending now the situation where we're saying, oh, we're actually not sure if we are referring to a contact that is a person or in their organization. And we came up with this strange solution of saying, if the organization field is set, then actually the registrant is meant to be. the the organization. And also, we've behaved in in all these years as if nothing had been made in terms of progress elsewhere, such as identifying organizations. I mean, just organizations. great progress has been made to identify that we don't even have organization identifiers in our EPP data model, we do have a public ID in RDEB. it is not other than for the Ayanna. used register ID when the when the entities and I under register sure. So we've started we we started using that for some of our cases in our registries, we just put in the in that the company number that that we have in in in some of our registries. But it's not there in the in in the data model. There's no standardization in there. And very often, actually, when you have we just want to say, this is a certain party you know, the party happens to have a certain number
00:58:00 - 01:00:01


details about them that can change, but the essence is who they are, And, say, it would be good to at least have the ability to say, yes. We're talking about that party. If there is some kind of universal identify for companies. It's easy for individuals, lots of work is being done for decentralized identity and so on. And we don't see anything in our data model. So I think be the good idea would be to say take those step back and think more as to how we could solve those problems as well, and then we probably wouldn't be so much concerned about complexity. I mean, we could even have many many formats. Okay. Thank you, Vernon. And for all rest, I've closed the queues. We still we have 5 minutes lifts, next one is Powell. I'm public log clinic. So I would opt for the for the option of this simple contact let's say, not in favor of the complex ones. So Jacob was a bit of difficulty. already in add up model. But my end to just after reading the proposal was a bit vanished because this simple contact proposal is not it's simple. So I would be I think will copy Margaret. We have just one chance to do it right again, And I will be looking a bit forward to alignment with identity walls because especially in Europe with NIS 2 implementation, we have to align with EID key wallets. So there are the data models coming from this direction and I would look for some alignment here. k. Thank you, Pawel. Just did your next Hey, Justeep Singh. Aaron? Sorry. I'm walking with my computer here.
01:00:01 - 01:02:03


I'm in a bit of an awkward position. You have a dog food for GS content. I love Mario. And and then we have simple contact. So just to clarify that first. So I think I echo Mark's point and what Pawel said we given the smallness of this group, perhaps, one choice is better than working on 2 things. that's the second point I wanted to make And thirdly, I think I since I've studied GS contact, I think Andy is right in one sense batch object, and ID concepts. I think there are optimizations, which are used as he echoed the that you're saving some bytes. Right? But they look hard to implement if you're not using a library. And I know we have a library visavis, JS contact tools, what Mario gracefully put together. Right? But then you hear languages like Kotlin, Swift, I can keep going with other languages. So that ecosystem takes time to create. whereas the basic simple JSON And I'm not very strong about LA versus objects. Yeah. They are, like, Russian dolls. intertwined at times. But these two concepts are pretty tricky. because they involve Jason Pointer. then the IDs, Meaning, you have dynamic strings as names, So So, yeah, I think that's something we should be mindful of. And finally, I think one point I heard was which is yeah. I let's assume you go with simple contact. Right? just for argument's sake. And extending that thoughtful reduction point what Andy was making, it's about meaningful actions and then thoughtful additions.
01:02:03 - 01:04:01


we and let's we miss something in simple context. Okay? Just for argument's sake, visavis or the regions of the world, we always have the option of extending it on demand. the point I'll make there is that After all, it's also an extension. The whole point of extensions, you can keep evolving it. Yeah. Hopefully not too often. But but it'll be additive rather than subtractive. So, anyway, those those are some of the points. I'm still given my position, I'll I just would like 1. Okay. Thank you, Justin. And the last one in the Or if yeah. Mario, I see you in the queue. will give you an opportunity to speak as one of the presenters after this. At first, let's let's hear it from Jim. Thank you. I'm Calvin for the record and standing in the center of microphones to emphasize that I'm speaking for myself. two things. one 1st. I I'm I'm a very strong opponent of simplicity and and always have been and frankly, I really like the direction that Andy's going in. If anything, I would say, which proposed is still too complicated But, you know, that's that's that's It's all a matter of opinion and judgment. And and in fact, I I like the comment sorry. I don't know you that you were making earlier about you know, I I'm also a strong proponent of internationalization, and I I very much agree, you know, that we are so westernized in what we do. and addresses and names and addresses is one of those things. It's just sort of a little at peace of mind, but I've never really known how to go about fixing all of that. that's just sort of odd. So I I think this is just, you know, good work, and we we should do all of this and we should move in this to and I I like having the option of being able to take advantage of of simple contact or whether Jay Carter or JS contact, whatever it is, which brings me to second point
01:04:01 - 01:06:03


just an observation to be made as someone who participates actively on both the ICANN side and the IETF side of these kinds of things. know, Jay Card, it's we've made that comment a few times here, is kind of here to stay. IETF has its own reasons for you know, making Jay Card be motivated and stick around. but that's also true on the ICANN side. So, you know, the the policies on that side actually do mandate j card. So the reality is if we want something else to come into existence, We have to make that option available. and then is a separate step know, there's a set of people myself included who would have to start motivating that action on the other side see if we can't move to something else. So, you know, we kinda have to decide if we wanna have this option and then make it available. That's the only way to satisfy the problem on the other side. So thanks. Okay. Thank you, Jim. And then, Mario, I can give you 30 seconds of response, and then you have to move on to the the items. And let's let's continue this discussion onto this. Right? Go ahead, Mario. Yeah. I would like to just to outline couple things. I think that what we should think about is First of all, backward compatible compatibility, we Jikad. So Just contact is able to be fully compatible with, again, including any Jacob extension. So And another point is We we I think that we should focus on a model that is extensible and flexible. So we we don't know what will be the the requirements in the future about the the registration on that. So if we may if we if
01:06:03 - 01:08:01


represent the the contact information as limited to the the the the cases that are in in use. today in order to I think that I'm afraid that In in the in the near future, we will be forced to do to update the the the the simple contact that's a model with many extensions. So I think that it's better to think about a representation that is extensible and flexible so that any extension could be represented with legal effort or just, for example, defining new value for kind of the kind values or something like that. So I I think that this is the point. if you want to limited to to limit the the the the contact representation to what is now Obviously, we can use scoped at the board a subset of the information that can be used for for representing the the the current information. So Mario, if if we can interrupt You want different in in the 2 data models based on that information. the difference is in in that jes content is much more flexible and distensible. Mario, I I gave you 2 minutes now, and you were you only have 30 seconds. We have to we have to respect, you know, the other presenters that are still Yeah. Yeah. Yeah. Yeah. I really like this discussion. I think it was very good
01:08:01 - 01:10:01


But I think we should continue with your arguments on the mailing list. There was a very good discussion, and let's continue there. And we are going ahead with the next presentations, And the next thing on the agenda And I have to bring up the slides here again. Dia shares, Jerry, can I interrupt a second? Yeah. Go ahead. Marc Lache, it would be good to have, like, the the tool, the media code tool, poll for, you know, what people think about the different things. while we're here, Okay. That's an interesting suggestion. I'll try and work that with It's the one here in the background as we we move on, we can Okay. So so yeah. So I I'll what he meant is was have a pull right now, right, during the meeting. So Let's do that after the new work presentations. If you have any time, you'll put up a poll so that people can discuss still a little bit and at the at the end of the meeting. So next one up is Bill Carroll, and I see him already available remote. So, Bill, I will put up the slide that I think Scott referred to you. Yeah. Yeah. It's the lead DCP our area. Here we go. we can hear you just fine. So go ahead, Will. Alright. And you can hear me? One thing I forgot to ask, do you want to control the slides? No. There's there's only 4 of them. If you if you wanna just do easier. Okay. Okay. Alright. So my name is Bill Carroll, and I work with Scott Hollandbeck at VeriSign. and I'm gonna briefly introduce this draft, which we wrote that's intended to give best practices around object deletion in EPP. you go to the next line?
01:10:01 - 01:12:00


Okay. So let me give a little history and background if you were at the IETF 115 meeting at the IR TFopen Group. Gautam Akahuate presented a paper called Risky Business. which details a known problem with with a workaround to some EPP recommendations that some registrars had implemented and it was causing thousands of domains to be hijacked. So in response to that, We have prepared this BCP hoping to explain some things about the EPP RFCs, and then offer some best practices and some and removes going forward. So First thing we're in here is that it NRC is 5731, and 5732, which Scott wrote, there are a number of recommendations should and should not language. But there's kind of inadequate explanations and expectations around them. and that's caused some issues when they've been rigidly applied. So in terms of these best practices practices We are limited to what these are best current practices. So they're limited to what's currently available. And then we also hope to give some directions for the next potential practices we'd like to see. you go to the next slide? So let me briefly explain the problem. And if you want more details would recommend seeking out that risky business paper or the presentation and you'll get kind of a fuller example and numbers and so on. So RFC is 5731, 5732, have these focus on very singular discrete steps for deleting objects. And the goals were to avoid breaking resolution to maintain client server, registrar registry, data consistency, and to maintain relational consistency within the server within the registry.
01:12:00 - 01:14:01


So they state that a domain object should not be deleted if subordinate host objects are associated with it. And you can see in my example here, delete me dot example has host object nsonedot deletemead dot example. doesn't really matter for this purpose, whether it's a a narrow or wide glue. So it doesn't matter if fleetme dot examples using it or not. But now has this associated host object, which needs to be deleted first or perhaps in the same transaction or something like that. But the problem is if it there's a second rule here that says recommendation, I should say. A hostname object should not be deleted if the host object is associated with any other object. And in this case, dependent dot example is also associated with nsone.delayedmeat.example. So now we can't delete delete me that example. dotdeletting, and that's 1.deletting, for example. And dependent dot example depends on that, so we can't delete that. Okay. Now if they have the same answering registrar. then that registrar could dissociate dependent dot example from NSOne, and and everything would be fine. But if they have different sponsoring registrars, that option is not available. Alright. so we come to that 3rd point. What we see instead as we rename that host object to often an external sacrificial name server, And that maintains the consistency among within the registry, now we can delete delete me dot example. because it doesn't have any associated subordinate host objects. The problem is Now a dependent thought example is dependent on something new, And that that's unexpected strong. They're not informed of the change. and and and If that new domain is taken over by someone else, it it offers an option for the main hijacking. And that that has occurred in
01:14:01 - 01:16:00


1000 of cases. Alright. So Here to the next slide. So we wanted to talk about what we think are the best practices. around this. The first were 4 practices to avoid. And the first three are must nots. We think these are are are bad. The fourth one is a should not because we're kind of open to it, but we need to get more consensus around it. The first is, of course, this renaming hosts to non existent presumed nonexistent external hosts. this is irresponsible because it it creates hijacking opportunities. The second that was suggested actually at that IRTFO meeting is the use of dotalt. And we don't think that that the use of non DNS identifiers the DNS as a a good a good idea. This could cause unpredictable behavior, name collisions. This mixes DNS, namespace, with this non DNS with a non DNS pseudo TLD. So this seems problematic. The third is something we've actually observed in the wild is sometimes these hosts will be pointed to usually, I mean, their their blue records and so on, 2, an existing recursive service. which then offers a DNS service, but it's going to get serve fail or other errors for any requests for those domains. and and Actually, I am a coauthor on a another a draft over in DNS op called negative caching of DNS resolution failures. The reason is there are some recursives that will aggressively re query when they receive, SurVeil, or some other errors. And so in this case, making this change will will create operational problems as you get
01:16:00 - 01:18:05


many, many spurious requests, which these domains can never be resolved. So it it doesn't work really for anyone. That fourth one, which is, again, a a a should not, Because some registrars are doing it now, is the use of a s 112.arpa. and we would really prefer that there be a community well understood rename instead of of using something that's that's a special name for another purpose. And We think this leads to confusion. If If a registrant sees this, it's not clear what happened or what this means, So coming over to the best and better practices, we would like to see registrar's main Cain, a sacrificial name server host, and it needs to respond with non error, non failure, authoritative responses. The draft is open as to what that response might be because we wanna allow for the idea of maybe controlled IP controlled interruption IPs or some other signaling mechanism. But nothing that's gonna be an error or failure because, again, we wanna avoid that aggressive re requiring, The other option that some registries already are implementing is they are allowing deletion. And that is in the RFC, again, those are recommendations. so that's allowed. What we really have a good understanding of is what guard rails there are around that. What are the practices and safeguards around that. Does that mean that the dependent dot example is removed from the zone entirely? Does that mean DS records go away? We don't know. And finally, to what we think would be better practices, We would really like to see a a community sacrificial name server either service or convention, something where, again, registrants and registrars could understand what happened and what the what what this is supposed to be. So that could be a dot something dot sacrificial.
01:18:05 - 01:20:03


sacrificialnameserver.arpaorsome sinkhole service something along those lines. The other option is to move registries towards deletion of the host objects. But in that case, do we in form registrar is the deleting registrar of the details of that and require an explicit delete And if so, then what do we need to share with them? is there a way to inform affected registrars and registrants so that they this has a surprise for them. So that's this is only the first version of this draft. and we are open to any suggestions or practices we've missed. So Any questions or comments? Thanks. to send you bill. We have a few minutes to questions. So can you go ahead? Hi. Your point about a s 112 is interest thing. Just It's just what I thought I've sat down. So this isn't a very well formulated idea, but it might have some possibility of working. So the community slash professional name service why shouldn't that be something that is kind of involved with AS 112 since home.arperisalreadydelegated to a s 112. So we could delegate, invalid.arpertoas112 as well. and then say -- Mhmm. -- points to msonedot invalid.offerorjust can file it to offer or something. and then The problem is solved. I think. Yeah. That that's that's an option. to consider again, I think our focus is on making sure that it's something that can be well understood in the community so that if someone is registrar is able to scan for it, amongst their customers,
01:20:03 - 01:22:04


basically, so that it's it's it's not a surprise and it's not a mystery as to what happened to the name servers for a a domain. Ed, go ahead. Hi, Louis. I can. And I've been out of this for a while, so I'm coming back discussion midstream. One thing I'm looking at this, we know that putting in, like, a dummy value for something is always gonna be treacherous. whatever the dummy value is. We've done that for years of programming. The question I have there, though, is that in the better best practice, we talk about sacrificial names. We can reserve names certain ways. I think there's you wanna have 2 goals here. 1 is a goal that software will not accidentally use that name. You know, you know, they might think that's interpret that's correctly But, also, you wanna have a name that when the operator sees it, eyeballs it, they know what's going on. Right? That's a second that's a different kind of of fall battery up here. And in the second part, having one name may be difficult if it turns out that you have poll names being deleted from different reasons. You don't wanna track back what this one was replacing. So I'll just put it in there. It's it's I can see it's the obvious issues we have to solve for this to work. Good. Thank you so much. It's And thank you, Bill. And just just remark for me. I remember that I have had these discussions about host objects already in 2001. So that's 22 years ago, and, apparently, nobody has solved it yet. I think it's about authority of of records, and it it has a lot to do with with glue and everything. But it it might be good to go back to the discussion in 2001. thank you, Bill. Since we have little time, I locked the queue and We're moving to the next presentation, and I think that is Andrew. So thank you, Will. put up entries.
01:22:04 - 01:24:01


Slide which one do you want to start with, Andrew? I think it's the art of extensions. Right? Sounds good to me. Hello? Alright. So I don't know if some of you remember maybe about a year ago. There were lot of discussions on the mailing list, about how hard up extensions work, and I would say that we had a lot of people talking past each other. So that was kind of the the driving motivator for writing this draft. And next slide, please. So Jessdeep and I and Tom Harrison have gotten together, to try to pull everything together into one place because part of the problem with the RDF extensions is It specified multiple places in the RDF RFCs. and there's no one coherent document that talks about them. that's what we're trying to do here. I will say that this was the original intent was to write just an informational But as we've gotten into this, There are a couple of things that may need fixing in our app. around this. Nothing crucial or nothing that's gonna cause the world to fall apart. but it'd be better to address them sooner or later. So Information was the intent, but this may not be an information when it gets down to it. Next slide, please. Alright. So what we discovered along the way that so, you know, we talk about the we've had these conversations about query parameters forth and extensions. The drafts the actual RFC draft talk about using extension prefix or the extension identifier prefixes in the URLs and URLs. It really talks about using those for paths.
01:24:01 - 01:26:00


but not the query parameters. So that's probably something we might wanna we might wanna clarify. and that you can probably should be used for the query parameters as well. There's also no guidance on extensions that depend on other extensions. So we probably need to clarify how that would work. One of the things is that and this kinda showed up in the RAR reverse search draft. Right? the IETS because IETF owns the RDEB specification, the IETF actually doesn't have to abide by rule. you need you need to use the extension identifier because the IETF has the ability to coordinate itself. The whole purpose of this extension identifiers was for 3rd parties who come in and add extensions to our app. So we there's Most of the time, I think most of the time we do abide by that in the IETF, but we might wanna clarify whether we should or should not Obviously, because the IETF can change its mind, 10 years down the road, It's not a it's not fixed in stone, but may wanna create some guidance on that. And then one of the other things that kinda showed up was that you can have people registering extension identifiers that are supersets of existing extension identifiers And that would be bad. So we should probably disallow that. Next slide, please. So the other feedback we've gotten on this is needs to be explicit guidance about pre pending the identifiers versus exact match matching extensions, true. we should probably have clearer definitions on what what needs to be documented, and we need to probably be clearer about how we talk about JSON in this draft. and make it
01:26:00 - 01:28:03


if not using the same terminology, try to map back to what the other RDEP RFCs to say. And then Yeah. And then there's some comments about camel casing. So I don't think it was against it, but maybe we need to tighten it up I don't know. Anyway, that's all I have. Welcomeing feedback. So are there any questions from St. Newton on this first presentation. I don't see as I see Dan Kinkley in the queue. Then go ahead. Thanks. Can you hear me? Yep. Great. Thanks. Yeah. Just one question or observation regarding the rules for who has to use the prefixes and who doesn't. I It would be a hard it's a hard sell for me to not eat our own dog food, so to speak. and it seems to me like if we put something in the spec, it and expect people to follow it I would expect that should apply to us. as well. subtleties like that where some some extensions are required to do it while others aren't. To me seems like a source of ambiguity that drives the need for such a draft as this to further explain what our intent is. special cases are generally bad. And if, you know, an extension is an extension is an attention. and thrual surrounding prefixes should be globally applicable if we can help it. at all. So so so Okay. all I wanted to say. Thanks. Alright. Sounds like a reasonable position to me. So Anything else? Alright.
01:28:03 - 01:30:01


If not, then I put up slides for your next presentation. Alright. Alright. So this is a new media type for RDP. Next slide, please. This came about from discussions of both JS contact and the versioning work that James Gould is doing. But and the idea was tried to extract out of there the a a generality of How do you get clients to be able to signal to servers the extensions they support? because that's what the that's what those those are trying to do. this is a generalized mechanism for that. Currently, an adapter is a way for a server to say to a client, here are the extensions I have. that I support, but there's no no way for a client to say that to a server. So that's what this is all about. And some of the current use cases are, like, being able to signal that You don't want JCAR anymore. You want another contact model. So that's kinda one of the the the the the reasons you might wanna do that. also for versioning if you wanted to. Alright. So next slide. So the solution we we came upon was to create a new media type. that. And so this media type would create a what's called a media type parameter It would just be extensions, and it's just a white list separated white space separated there we go. I got it. whitespace separated a list of the extension at the yard app extension identifiers. So that's that's how it would work. We'll just be in in the accept header along with the the current artup, media type. Next slide. Yeah. So the client behavior is is they support this. They send along both the current RDEB media type and the new RDFX media type, and they signal which extensions they support. Next slide.
01:30:01 - 01:32:02


And if the server supports it, What they do is they respond with the artifacts media type in the content type header. Today, what they have to do is they have to respond with the the RDEB media type. So If they respond with the RDFX media type, then it signals to the client they support this as well. Next slide. Alright. So why a new media type. And RFC6838 discourages the practice of a pending media type parameters on existing media types. and it's for good reason because a lot of server software HTTP layer when it's handing things off to the application layer The media type from the accept header is usually just gonna be an opaque string. There's not gonna be any structure around that. So if we try to extend the current media type what would happen is servers that are looking at the looking for the current media type would not get a string match, and they would probably rejected or whatever. So So we we had to go to the new media type. but this is backwards compatible. Next slide, The other thing is in the draft, we actually talk about the justification of why we we went down this route versus using query parameters. And query parameters have a host of problems. There's a the copy and paste issue if you copy your URL which has the query parameter in there that says I support extension x. and you give it to someone who has a client that doesn't support that, but they use it. their client just signaled to the server something that's wrong. So The other thing is is that and this is probably the the biggest issue. the query parameters do not survive or your x. That means it's incompatible with RFC 7480. which talks about handling of query parameters both from the server and the client. And it's more importantly,
01:32:02 - 01:34:04


compatible with current RDF deployment. So there are RADA servers out there which use redirects quite heavily. and this will not query parameters will not work with them. It also when you get down to a kind of an architectural level, removes the content negotiation from the accept header. So where it probably should be. We have some sample code in in the appendix. kinda demonstrates how all this works. the fact that most HTTP libraries You can preserve query parameters, but the default is not to do that. The accept header is the opposite. So most most libraries will preserve what the media types are. Next slide, please. Because there have been a lot of discussions about attention versioning. We actually did some thinking about how we could be compatible with that. And so there's a discussion in the appendix about how this is compatible with any type of extension versioning scheme that would come along. So carefully note that this is graph does not specify any extension versioning. So next slide. Yeah. So the feedback we've gotten so far The there's a use case or kind of a corner case where the the server could respond with extensions they don't support. they shouldn't be doing that, so we should probably put some guidance in there for that. The because you can put weights in the accept header about which which media type you support, we should probably be a little more prescriptive about that. was asked why we didn't go down the route of using a custom HTTP header. the reason we didn't do that is probably because that's very painful. I will note that the w three c attempted what's called the accept profile header a couple years ago in 2019.
01:34:04 - 01:36:02


didn't get very far. I don't think RDP is specifying a new HTTP headers a solution that would would would bear any fruit. So Pavel, I hope I'm saying your name right, did mention that we should consider the use of the options the options method in HTTP or in slash help, I think that's a very good comment So we're gonna look into doing that and maybe creating some sort of marker profile that goes into slash help options, I'm not sure about. I need to look at that. r c 7480 does say RDF only supports get and head methods, but we can still look at that. And then there was some con conversation about this doesn't work with a raw. browser. actually does, but it's not a pretty solution to raw or or just a regular web browser is not a pretty hard app solution to begin And I think that's it. So any other comments? Okay. So we have We we actually have run over time, so I want to ask the question asked to ask the questions short. see. The first one in the queue, Murray, is James Gould. Yeah. So he goes first. And I see that James got offline So Dennis Murray. Two quick things. 1, think it's funny that we've banished x dash, but you're adding dash x. This is a mechanism by which you telling the server I can accept extensions in the answer. Yes. Right? So are you is there gonna be a stipulation that says you always have to give rdapplus JSON plain and then also include this because if you flip that you might create a situation where I can't accept the answer that the server wants to So so this the client always sends both media types. Yeah. Yeah. Alright. And the reason it's ardapdashx, is because when you look at the INA registry, if we because originally it was extensions
01:36:02 - END


dash RDAP or something like that. And, Jesdeep pointed out that this will be up here in the registry, and then our deck will be down here. the rdashdashx is actually so they'll be right next to each other. are in are in are in are in are in are in are in are in are in are in are in are in are in are in are in are in are in are in are in are in are in are in are in are in are in are in are in are in are in are in are in are in are in are in are in are in are in are in are in are in are in are in are in are in are in are in are in are in are in are in Okay. I see that's a James Goops back, James, you have half a minute left for remark a question. team good. We cannot hear you. Okay. So he's gone offline. I think he has audio issues. Since we run out of time, I want to thank everybody. Unfortunately, there's no time left for a pool or any other business, So I hope that we will continue the discussion on the mailing list. It was a very good meeting. Thank you all for for being here. And Yeah. 16 minutes overtime Jim, I'll let you close the meeting. Okay. Yep. We're adjourned. Thanks. Okay. Thank you. Absolutely. them