Thank you Pawel for clearly stating your position. Please confirm, are you physically present? I currently understand that you’re not, so we may have to setup something ad hoc to include your participation.
Thanks, Jim On 14 Jul 2026, at 11:55, Pawel Kowalik wrote: > Hi Chairs, > > I would also prefer to participate in the discussion. 2-4pm on Monday would > be possible. > > I have a clear view aligned with WG position from several meetings ago to > close draft-ietf-regext-rdap-extensions first. > This draft shall give a clear guidance, how extensions shall be written and > what are the expectation of clients and servers with STD95-based RDAP > deployment - without any extensions. > > This includes a clear guidance as under what conditions the extension > identified MAY remain the same if an extension specification is being > updated, and what conditions determine that the identifier MUST change. > > The pivotal question remains, what the conditions are. > > A part of the question is when to consider a specification update as not back > compatible. I think here we have a good understanding, drafted in > draft-ietf-regext-rdap-extensions, what kind of changes we consider breaking > and which back compatible for clients operating pure STD95 protocol without > extensions. > > As to when the identifier MUST change, there seem to be 3 options on the > table, each with different degree of rigidity: > 1) extension identifier MUST update on every specification change - IMHO too > restrictive, not really aligned with REST API approaches, burden for both > clients and servers in migration paths. Also not in line with spirit of > rfc9083 2.1. > 2) extension identifier MUST update only on not back compatible specification > change - less restrictive but coarse-grained. Not allowing space of other > mechanisms of signalling changes. Easy to implement for the client though. > 3) extension identifier MUST update only on not back compatible specification > change, unless extension offers own signalling of compatibility within its > own extension identifier namespace. draft-ietf-regext-rdap-versioning MAY be > a solution of choice for all such extensions to set upon in a standardised > way. It shall remain open that there might be other methods. > > The called out "solution, offered by Pawel" was in fact the approach 2, > however I see the arguments about too coarse-grained versioning consequences > of it, therefore I can also agree to go with 3. > > The choices imho shall be taken regardless of existence or compatibility of > further drafts in the discussion, as draft-ietf-regext-rdap-extensions shall > lay down higher level principles that the other drafts in question shall not > gate. > > That being said I think we shall finalise draft-ietf-regext-rdap-extensions > with full focus not waiting for any of the drafts down the stream. Also limit > the influence of those drafts specific solutions in the discussion to > absolute minimum. > > To the other questions: > > - draft-ietf-regext-rdap-versioning and draft-ietf-regext-rdap-x-media-type > have both mechanisms for signalling of requested representation (content > negotiation). I still hold to my opinion that: > a) 2 ways of signalling in "versioning" draft are not necessary and that we > shall have only one way described in one draft. "media type" draft is my > clear preference as using standard http content negotiation. > b) "media type" shall foresee not only requesting extensions by a list of > ext. identifiers, but also their versions in opaque way - so that > "versioning" draft can fill in on one side, but other versioning mechanisms > can use same way. This is only useful if we go for option 2 or 3 from above. > More utility with 3. > > Kind Regards, > Pawel > > On 14.07.26 14:43, Andy Newton wrote: >> Hi Chairs, >> >> Regarding the question of what is needed: >> >> We need to go back to the agreement [1] made in a meeting at the Montreal >> IETF between the authors of these documents and interested parties. At that >> meeting, everyone agreed to a simple solution, offered by Pawel, that is >> compatible with how RDAP is deployed today. >> >> The crux of the current disagreement is compatibility with RDAP as it is >> deployed today. While the versioning draft has been a moving target -- now >> on its third redesign -- each iteration has NOT been compatible with >> currently deployed RDAP. >> >> Regarding logistics: >> >> I am available during those times though would prefer an evening meeting >> because IETF sessions do get moved around. Also, Pawel has been very >> involved in these discussions and played the part of mediator. It would be >> unfortunate if he could not be on equal footing in these discussions. Absent >> an immediate need to meet a deadline, I think a fast-follow, virtual interim >> meeting would serve us well. >> >> -andy, no hats >> >> [1] https://mailarchive.ietf.org/arch/msg/regext/sN-ar484f9n5YgXkTauq7CE6xMk/ >> >> On 7/13/26 11:43 AM, James Galvin wrote: >>> To the principals listed below, please confirm if you wish to be present >>> for the discussion the Chairs are trying to organize. >>> >>> To everyone in the working group, the question the Chairs need to answer >>> is, “What is needed to move these documents forward?” It may help to think >>> of this as a pre-working-group-last-call question. >>> >>> For anyone who has a question, concern, or a position regarding these >>> documents, please do send a note to the list with your statement. >>> >>> One email message per person, please. Do not respond to each other. >>> >>> The Chairs will review all messages and frame the discussion to be had and >>> propose either a consensus or a specific question for consideration after >>> the IETF. Again, the goal is to finalize these documents so we can quickly >>> move forward a number of other documents that are dependent on them. >>> >>> >>> LOGISTICALLY, it seems that Wednesday morning is not going to work for our >>> ad hoc meeting. Best bets are currently Monday Session III (2-4pm >>> timeslot) or in the evening on Monday or Tuesday. It would be helpful if >>> the principals would indicate their availability in those times. >>> >>> >>> Thanks to all. See you next week in person. >>> >>> Jorge, Antoin, Jim >>> >>> >>> On 10 Jul 2026, at 18:06, James Galvin wrote: >>> >>>> The Chairs have received requests both on list and privately to please >>>> help facilitate finding a consensus as to how to proceed with these three >>>> documents. >>>> >>>> https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-extensions/ >>>> https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-x-media-type/ >>>> https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-versioning/ >>>> >>>> It does seem that there is an impasse, which is unfortunate. However, The >>>> Chairs remain ever hopeful that we will find a path forward. >>>> >>>> What we propose is to get the principals together while we are all present >>>> in Vienna. The Chairs will prepare an agenda and review concerns and >>>> preferences among the principals. The objective is for the Chairs to be >>>> able to identify the rough consensus, if not full consensus, in the room. >>>> >>>> The Chairs will provide a summary of the discussion to the list and assert >>>> the identified consensus for review by the working group. we will be >>>> looking for objections from other working group members and, of course, >>>> ask that if you object you provide a technical explanation with new >>>> information to support it. >>>> >>>> The goal is to finalize these documents, or to indicate explicit next >>>> steps to be completed that will finalize these documents. They have been >>>> on our milestone list for years and worse they are about two years overdue. >>>> >>>> The only meeting slot that we have available to do this is Wednesday >>>> morning, 22 July, in the first time slot of the day 9am-11am local time. >>>> Our AD has offered the IESG meeting room for this discussion and it is >>>> currently reserved for us. Sorry folks, there is no remote participation >>>> available but we believe this will be okay as we will be reporting to the >>>> working group for the final decision. >>>> >>>> Although anyone is welcome to join, the principals the Chairs would like >>>> to be present for this discussion are as follows. >>>> >>>> Jim Gould >>>> Tom Harrison >>>> Paweł Kowalik >>>> Mario Loffredo >>>> Andy Newton >>>> Jasdip Singh >>>> >>>> We should appreciate if those on that list would indicate if they are >>>> available for this discussion. As long as we have a quorum, as determined >>>> at the discretion of the Chairs and the AD, we will have the discussion >>>> and report to the mailing list. >>>> >>>> If for some reason this meeting cannot happen, then the Chairs will >>>> organize an interim meeting in the weeks following the IETF. Of course, >>>> we’d prefer not to do this so please do try to accommodate this meeting in >>>> your busy schedules. >>>> >>>> Thanks to all! >>>> >>>> Jorge, Antoin, and Jim >>> _______________________________________________ >>> regext mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >> _______________________________________________ >> regext mailing list -- [email protected] >> To unsubscribe send an email to [email protected] > _______________________________________________ > regext mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
