Andy,
I believe we first need to define changes in RDAP are material and may trigger
a change to the Extension Identifier or bumping the point versioning value.
Some options to consider below:
1. Is adding any new query features (e.g., path segment, query parameter, media
type parameter) material?
2. Is removing query features (e.g., path segment, query parameter, media type
parameter) material?
3. Is renaming query features (e.g., path segment, query parameter, media type
parameter), which equates to a remove and an add material?
4. Is adding any new JSON members material?
5. Is removing any JSON members material?
6. Is renaming JSON members material?
We have historically kept the Extension Identifier ("exampleExt0" or
"exampleExt1") static through the draft development process, independent of the
interface changes. The only RDAP extensions that registered new Extension
Identifiers has been the Profile Extension Identifiers
(icann_rdap_response_profile_0 and icann_rdap_technical_implementation_guide_0
to icann_rdap_response_profile_1 and
icann_rdap_technical_implementation_guide_1, respectively).
For Opaque Versioning, I believe any interface changes (#1 through #6 above),
independent of whether they are considered breaking or not, should result in a
change in the Extension Identifier. I don't believe breaking is the catalyst
for the change to the Extension Identifier. The Profile Extension Identifier
change was done without considering whether the profile is breaking or not, but
simply to signal a change in policy. With Opaque Versioning, there is no
change in the Extension Identifier through the development process unless we
want to start doing that for interface changes (e.g., ("exampleExt0",
"exampleExt1", " exampleExtN") independent of registration in the RDAP
Extension Registry.
For Point Versioning, all interface changes (#1 through #6 above), represents
an interface change and a change to the Extension Version Identifier
("exampleExt-0.1", "exampleExt-0.2" to "exampleExt-1.0" after WGLC, and then
for the bis draft "exampleExt-1.1", "example-1.2", example-2.0 after WGLC),
which doesn't impact the Extension Identifier ("exampleExt"). With Point
Versioning, the Extension Identifier doesn't need to change, since it reflects
the extension namespace and the Extension Versioning Identifier provides the
versioning information. If draft-ietf-regext-rdap-extensions forces a change
to the Extension Identifier based on registration in the RDAP Extension
Registry, then the scheme would need to change to ("exampleExt1-0.1",
"exampleExt1-0.2" to "exampleExt1-1.0" after WGLC), and then for the bis draft
("exampleExt2-1.1", "example2-1.2", example2-2.0 after WGLC), which duplicates
the versioning information. We could look to update
draft-ietf-regext-rdap-versioning in defining the Extension Identifier
relationships, if such as scheme was necessary. Whether or not we change the
Extension Identifier, the Extension Version Identifier can capture the
interface changes using a predefined versioning scheme.
We really don't know what would break a client, where should they expect all
the data members to be present, will they expect all the query features to
work? A change in the Extension Identifier does not provide clarity to the
interface through the development and publishing of the final RDAP extension as
an RFC.
Thanks,
--
JG
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/>
On 6/9/26, 11:48 AM, "Andy Newton" <[email protected] <mailto:[email protected]>> 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.
Maybe you could but some query/response examples in your draft of how a client
is suppose to handle backwards incompatibility.... both for a client that
supports this versioning extension and one that does not. That would probably
help demystify this for those of us in disagreement.
-andy, no hats
On 09-06-2026 10:07 AM, Gould, James wrote:
> Andy,
>
> It's not a requirement for the client to use the /help to get additional
> versioning data, but a feature that a client can opt to use. The extension
> identifier is not a good versioning signal and leveraging the extensibility
> of RDAP to provide that versioning information is an option and not a mandate
> for interoperability. We could add additional opaque versioning information
> to the /help, such as opaque version relationships, to further help with
> those extensions that choose to use opaque versioning instead of point
> versioning. Do you see a benefit in working on this? This meta-data is not
> required but helpful to client implementations and for troubleshooting.
>
> Thanks,
>
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
