Minutes IETF117: regext
minutes-117-regext-00

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