Thank you Mario.
Jim
On 14 Jul 2026, at 6:11, Mario Loffredo wrote:
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]
