Hi,
below is a summary of my position on what is needed to move them foward:
*1)* rdap-versioning should include a "Transition Considerations"
section (we are already working on it) specifying that, rather than
moving directly from a previous version of an extension to a new,
incompatible version, a server should perform the transition in two phases:
- Transition to an intermediate version. The server first deploys an
intermediate version of the extension that includes both the features of
the deprecated version and those of the target version. This version
allows existing clients to continue using the deprecated protocol
elements, while allowing upgraded clients to adopt the new ones.
- Transition to the target version. After an appropriate deprecation
period, the server deploys the target version, which removes the
deprecated protocol elements and retains only the features defined by
the new version.
This corresponds to the implementation of the "Expand and Contract"
pattern for managing REST APIs and is essentially the same approach
described in rdap-extensions, but, rather than always affecting the
entire extension, it would limit the scope of an incompatible change to
only the affected functionality whenever possible. It wouldn't mean
requiring the use of the versioning extension, but rather using it to
handle incompatible changes as if they were additive changes. Note that
the versioning extension is already mentioned in rdap-extensions as a
possible way for extension providers to signal and handle compatible
changes.
*2) *rdap-extensions should be made more flexible. I believe extension
providers should be free to decide the scope of an incompatible change.
It can range from a single element to the entire extension; requiring
the extension identifier to be changed for every incompatible change
seems rigid, impractical and inconsistent with REST API management best
practices. Personally, I think changing the extension identifier can be
useful when the namespace needs to be changed, or when the scope of the
change is comparable to the entire extension, or, in any case, when
extension providers deem it appropriate to do so. I would also remove
Section 5.4.3.2 of rdap-extensions. Using overlapping extensions to
narrow the scope of changes seems like a potentially confusing solution,
as the functionality that logically belongs to one extension is split
across multiple, potentially unrelated, extensions that evolve
independently, as noted in the last sentence of that section.
*3)* rdap-x-media-type should allow the exts_list parameter to include
extension version identifiers, i.e., generically, extension identifiers
that include version information. Servers could use client preferences
for both extensions and extension versions to more precisely tune the
time when old versions are no longer supported. Therefore, the
versioning parameter defined in rdap-versioning could be removed. I
believe rdap-x-media-type should also be updated to return an error when
a client requests an extension or a version of an extension that is no
longer supported. I don't think a server would be considered incapable
of understanding RDAP if it returned HTTP status codes 406 or 410 along
with an RDAP error message specifying that a version is unsupported. On
the contrary, a client is more likely to interpret a response that
doesn't include the requested extension as a server error.
Best,
Mario
Il 13/07/2026 17:43, James Galvin ha scritto:
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 [email protected]
--
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
Address: Via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
