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

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

Scott,

That's a possibility; although on the EPP side we limited bumping the URI to XML schema changes, since nit updates are not relevant to the interface.  The other issue is that all the elements of the extension need to be revised (e.g., draft_<unique name>_<draft number>_<member1..N>) for every draft version.  I may be willing to drop my objection with having to change all the elements to get past this multi-year debate.  This would be another form of versioning in draft-ietf-regext-rdap-versioning, since it's really not Opaque Versioning by embedding a versioning scheme directly into the Extension Identifier.  The advantage of your proposal is that there is a direct mapping of the I-D version to the extension version, which we don't have with the EPP convention.  

I would like to consolidate our versioning discussion to a single draft and work towards solutions as opposed to rehashing the opaque versioning versus semantic / maturity / point versioning debate.  Merge draft-ietf-regext-rdap-x-media-type into draft-ietf-regext-rdap-versioning and take some of the agreeable concepts from the sub-sections of draft-ietf-regext-rdap-extensions section 5.4 into draft-ietf-regext-rdap-versioning.  We have competing, conflicting, and incompatible concepts spread through the three drafts of draft-ietf-regext-rdap-x-media-type, draft-ietf-regext-rdap-versioning, and draft-ietf-regext-rdap-extensions that need to be consolidated so we can start working towards solutions.  

Thanks,

-- 

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 6/10/26, 9:51 AM, "Scott Hollenbeck" <sah=[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. 


The longer this discussion goes on, the more I become convinced that there's a simple concept here that's being complicated for reasons that I still don't understand. To whit:


Both EPP and RDAP extensions use identifiers that are ultimately associated with a specific specification document. IETF documents can be either Internet-Drafts or RFCs, and both types of documents have unique identifiers. Drafts are identified by a string and a number, e.g., draft-ietf-foo-00. When the draft changes, the number changes. RFCs are identified by a number. If the RFC changes, a new number is assigned. It's that simple.


This is why I don't understand how extension identifiers for EPP and RDAP can't follow a similar, simple convention. We could agree that, for example, a draft RDAP extension should be identified by a string of the form "draft_<unique name>_<draft number>. Using the sample example from above for an initial version, draft_foo_0. Every time the draft/specification changes, the identifier is incremented just as the draft number is incremented. Draft implementation can happen, and servers can announce support for specified draft versions using these unique identifiers. Clients can choose the draft versions they wish to implement using the same identifiers. There's no need to worry about breaking changes because every version of a specification is associated with a unique identifier. Clients and servers use those identifiers when sending and receiving information, and mismatches in implementation are ignored or flagged appropriately. When a draft becomes an RFC, a final identifier (foo_0) is defined by removing "draft" and resetting the version number.


We need to get past this. Keep it simple, people.


Scott