PK> I didn't say draft-ietf-regext-rdap-versioning is not compliant with STD 95 as such. I only say that draft-ietf-regext-rdap-versioning shall not cross boundaries of what STD 95 tells. At the point where this draft is suggesting breaking change in the extension without corresponding update to the extension identifier, then the line would be crossed.
What line are your referring to in STD 95? I don’t see any reference to breaking changes in STD 95 and draft-ietf-regext-rdap-extensions states the following, as it relates to the extension identifier: Section 2.1: “The main purpose of the extension identifier is to act as a namespace, preventing collisions between elements from different extensions.” Section 5.4: “As stated in Section 2.1<https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-extensions#purpose>, RDAP extension identifiers and RDAP conformance strings are opaque, and they possess no explicit version despite the fact that some extension identifiers include trailing numbers.” I don’t believe the version signaling should only be related to breaking changes, since the version defines the interface (query and response) of the extension. A client should not be required to hunt and peck to determine whether a server supports a specific interface of an extension that doesn’t happen to have a breaking change. I don’t have an issue with the RDAP extensions using Opaque Version to only signal breaking changes, but I do have an issue requiring RDAP extensions using the Point Versioning to be required to change the extension identifier for a breaking change when the dependent versioning extension provides versioning of all interface changes. The versioning extension supports both Opaque Versioning and Point Versioning, along with extensibility of future versioning types. If someone feels that Embedded Versioning is a better form of versioning, then it can be formally defined in a specification, where new RDAP extensions using the new versioning type can include a normative reference to it for onboarding, just like what will be done for the Point Versioning type. Each versioning type will be registered in the RDAP JSON Values Registry with the “versioning” type for traceability. This way we have backward compatibility and provide for extensibility of versioning based on operational experience. There is no intention to require any existing RDAP extensions to have to be modified because of the versioning extension, but we have the intention of providing an option for new RDAP extensions to be capable of signaling all interface changes and to provide the option for clients to choose which interface they want to use. This can be used with the deployment of proprietary RDAP extensions, IETF draft RDAP extensions, and IETF RFC RDAP extensions for interoperability either by manual means (e.g., many execute the /help of a target server) or by automated means (e.g., scheduled or executing /help of a target server when the client notices an versioning issue). Thanks, -- JG [cid87442*[email protected]] James Gould Fellow Engineer [email protected]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: Pawel Kowalik <[email protected]> Date: Friday, June 19, 2026 at 2:33 PM To: James Gould <[email protected]>, "[email protected]" <[email protected]> Subject: [EXTERNAL] Re: [regext] Re: Extension Versioning Location Information and What Changes the Version Options Hi Jim, On 19.06.26 17:44, Gould, James wrote: Pawel, Thank you for your preferences and reasoning. Can others of the working group weigh in on the options? I don’t remember you raising an RFC 9083 compliance issue with the extension approach proposed by draft-ietf-regext-rdap-versioning, which is an optional extension and any RDAP extension supporting point versioning in draft-ietf-regext-rdap-versioning will include a normative reference to it. Can you please clarify what language in RFC 9083 represents a compliance issue for draft-ietf-regext-rdap-versioning? PK> I didn't say draft-ietf-regext-rdap-versioning is not compliant with STD 95 as such. I only say that draft-ietf-regext-rdap-versioning shall not cross boundaries of what STD 95 tells. At the point where this draft is suggesting breaking change in the extension without corresponding update to the extension identifier, then the line would be crossed. As the matter of fact however, once this draft evolved to Point Versioning there is a clear indication in 4.2 that back compatibility is not of a concern of this versioning model. In this case I don't even see any conflict or contradiction with draft-ietf-regext-rdap-extensions. On the flip side the utility of this method to signal anything about compatibility vanished. We did agree at IETF 121 that the extensions draft shall go through first, but that was before the extensions draft expanded the Extension Versioning section to include concrete proposals that is in scope for draft-ietf-regext-rdap-versioning. The extensions draft was meant to clarify the confusion in the base RFCs, which Section 5.4 without the sub-sections does. This really becomes a scoping question for the working group, where draft-ietf-regext-rdap-versioning existed first (draft-gould-regext-rdap-versioning-00 published in November 2022) to add the missing functionality for RDAP versioning, and then followed draft-ietf-regext-rdap-extensions (draft-newton-regext-rdap-extensions-00 published in June 2023), and draft-ietf-regext-rdap-x-media-type (draft-newton-regext-rdap-x-media-type-00 published May 2023). All three drafts were adopted by the working group in February 2024 with agreement to support them (Mario Loffredo is the document shepherd of draft-ietf-regext-rdap-x-media-type and Jasdip Singh is the Document Shepherd of draft-ietf-regext-rdap-versioning). What has progressed since then is the draft-ietf-regext-rdap-versioning adding full support for Opaque Versioning and revising Semantic Versioning to now Point Versioning based on feedback from the working group. There have been issues raised on the mailing list related to incompatibilities between the three drafts that has not been addressed. Below are some messages on the mailing lists for reference: PK> I don't have anything to add on top of what Andy wrote already. Kind Regards, Pawel
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
