[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, 

I reply to your feedback embedded below.  Can you provide an option proposal to address the compatibility issue between the drafts?  

-- 

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, 3:03 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 2:43 PM, Gould, James wrote:
> Andy,
> 
> We can talk about whether a breaking change warrants a change in the extension identifier in the rdapConformance member, but there is no issue with conformance with STD 95. 


So you are arguing that the extension identifier in RDAP doesn't mean anything?

JG-No, I'm arguing that the extension identifier in the rdapComformance indicates that the server supports a particular extension, which has meaning to me.  RDAP doesn't include any built-in versioning scheme, which is where the versioning extension comes in.  


> There is language about this in the extensions draft that needs to be further discussed. The Maturity Versioning doesn't require a change to the extension identifier in the rdapConformance since it provides the versioning information in the extension, which is compliant with STD 95. A client that has coded to a particular version of an extension can easily determine whether the server supports it and can request that version via the query parameter or the x-media parameter if the x-media parameter supported the extension version identifier format.


The problem here is that only clients supporting the versioning extension will be compatible with servers supporting the versioning extension. Since the vast majority of clients probably won't do that, any server using the versioning extension will be incompatible with most of the RDAP ecosystem.

JG-A server supporting an RDAP extension that does use Maturity Versioning in the versioning extension should add support for the versioning extension as well.  Clients can then take advantage of the versioning extension to obtain the extension versioning information and request for a specific extension version.  There is a bootstrapping period, but if the client cares about extension versioning it should implement the versioning extension.  


> We first looked at defining breaking changes in the versioning draft with the Semantic Versioning, but it wound up to focus on the major version being associated with stable interface change and the minor version being associated with an unstable interface change.
That's not semantic versioning. I don't know what that is, but in semantic versioning major means breaking changes and minor means backwards compatible.

JG-We changed the name to Maturity Versioning to be clear that it's not semantic versioning based on our meeting at IETF-124.  Do you want us to go back to signaling breaking and non-breaking changes?      

-andy, no hats