[regext] Re: draft-ietf-regext-rdap-x-media-type and draft-ietf-regext-rdap-versioning Compatibility Topic 1: Query Identifiers

["Gould, James" <[e-mail]>]

Andy,

My feedback is embedded below.  

-- 

JG 



James Gould
Fellow Engineer
[e-mail] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/> 




On 4/14/26, 6:50 PM, "Andy Newton" <[e-mail] <mailto:[e-mail]>> wrote:


Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. 




On 14-04-2026 4:35 PM, Gould, James wrote:
> I don't believe we want to embed all versioning into the extension identifiers, where it is noted early that the extension identifiers don't have a versioning scheme. 


We didn't say "all" versioning, just the major as is done today by many extensions.

JG-We have drafts in flight now leveraging the maturity versioning type, including the versioning draft and draft-ietf-regext-rdap-jscontact (reference needs to be updated from semantic to maturity), draft-loffredo-regext-rdap-verified-contacts reference needs to be updated from semantic to maturity), and draft-ietf-regext-rdap-versioning itself.  The breaking changes happen in the major and the minor version bumps, since they reflect changes to the interface as being either stable (e.g., RFC) or unstable (e.g., draft).  


> This is the reason for the other form of versioning. We have not seen draft extensions changing the extension identifier when there are breaking changes, which would be needed based on your / Pawel's proposal.


To my knowledge, we have only ever seen two update at all -- the gtld profile extensions: icann_rdap_response_profile_0 -> icann_rdap_response_profile_1 and icann_rdap_technical_implementation_guide_0 -> icann_rdap_technical_implementation_guide_1. And there are 12 registrations that put the major number in the identifier.

JG-We have been revising the maturity version number in the versioning draft itself, which are minor bumps since it has not reached RFC.  The version bump does not occur when there is no change to the interface, such as the need to update draft-ietf-regext-rdap-versioning to reference the x-media "exts_lists" parameter instead of the old "extensions" parameter.  


I guess you are talking about Internet Drafts, but I don't think that has ever been a problem. I have implemented at least 6 in both client and server and never had an issue. What issues have you run into during your implementation?

JG-Internet Drafts include breaking interface changes, non-breaking interface changes, and simple non-interface impacting changes.  The same goes for proprietary RDAP extensions that don't go through the IETF.  The client should be aware of the interface supported by the server independent of whether the interface change is breaking or not.  RDAP can provide versioning that works for all forms of extension interface changes.  I can't speak to your implementation experience, but it's important for the authors of the extensions to be capable of making changes with support for isolation through version negotiation.  My first RFC in EPP was the DNSSEC EPP extension in RFC 5910, where we were implementing it during the IETF draft process.  I was under immense pressure to not cause breaking changes, which would not be the case if there was support for isolation via versioning.  The Registry Fee EPP extension brought point versioning to the EPP XML namespaces, which did support the needed level of isolation via versioning.  RDAP can learn from EPP in this case.  


And it seems like you are talking about a mechanism that will only ever be used during spec development, not in actual production. I don't think we should a) hyper focus on spec development to the point of ignoring actual versioning issues, and b) putting things in RDAP that will never be used once an I-D becomes an RFC.

JG-I find the use of opaque versioning to be non-optimal even for RFCs, where there is no formally defined versioning scheme.  Look at the RDAP extension registry, where there are extension identifiers that end with a "0", end with a "1", end with a "_DIGIT", and don't end with anything at all.  Changing of the extension identifier is a breaking change since the extension JSON members need to be changed.  A formal versioning scheme can be used for drafts, as reflected in existing RDAP extension drafts noted above, and can be used in RFCs to maintain the incremental version numbering.  


> I would be fine if the major represented a stable update that would change the extension identifier, and the versioning extension could signal updates to the unstable version. We can include an additional signal with the unstable version associated with a breaking change if needed. If we have the major version reflected in the extension identifier for progression of RFCs and then have draft versions signaled by the versioning extension, that would be a good compromise. I don't foresee RFC updates happening very frequently, but I would recommend that the new RFC should have a new extension identifier whether or not it includes a breaking change. The x-media draft would need to support passing the additional minor versioning information, which would mean support for the extension versioning identifier in option 1.


Now you are repeating your past points, so this thread has reached the end of its usefulness.

JG-I thought I was proposing a compromise position that you don't seem interested in.  My initial message to the mailing list was associated with addressing the compatibility issue between x-media draft and the versioning draft with a set of options for consideration and discussion by the working group.  Do you have any new options or a preference on the options presented to address the incompatibility between the drafts? 


Can the chairs please schedule an interim for this topic?

JG-It would be great if we could focus on the incompatibility issue between the drafts and the options presented.  


-andy, no hats