Hi Andy,
Il 17/08/2026 22:09, Andy Newton ha scritto:
The draft should define what makes a strategy compatible with STD95 that we can match
other strategies against. I requested in our mailing list thread to add the strategy
" Standalone Superseders with Versioning", which I'm willing to provide the
content for.
Feel free. Though if the idea is to use the same extension identifier to
reference two different versions of the extension, that's not STD95 compatible,
as has been discussed at length on this list and in the side meeting at 126.
While I don't recall that at the IETF126 side meeting we concluded that
the versioning mechanism described in rdap-versioning is not STD95
compliant, I don't believe this conclusion comes from STD95.
Section 4.1 of RFC 9083 requires a custom specification used in
constructing an RDAP response to be identified in rdapConformance by a
unique string registered in the IANA RDAP Extensions registry. However,
it does not state that every version of the same extension must be
registered under a different extension identifier.
The model in the rdap-versioning draft distinguishes between two levels
of identification. The Extension Identifier, which is registered with
IANA and included in rdapConformance, identifies the extension as a
whole. The Extension Version Identifier identifies a particular version
of that extension and is conveyed through the versioning mechanisms
defined by this draft, including versionng_help and versioning_data.
Consequently, using the same Extension Identifier for multiple versions
is not inherently incompatible with STD 95, provided that those versions
are defined as versions of the same registered extension. The Extension
Identifier still fulfils the RFC 9083 requirement, while the Extension
Version Identifier supplies the additional granularity that STD 95 does
not define.
It would be different if the two versions were registered or defined as
separate RDAP extensions. In that case, representing both with the same
Extension Identifier would indeed be problematic. However, treating
every version as a separate extension is not a requirement imposed by
STD 95.
If it were not clear enough, rdap-versioning could perhaps make this
distinction more explicit, stating that an Extension Identifier
identifies the extension independently of its version and that the
corresponding Extension Version Identifier identifies the particular
version used to construct the response.
Given the above, i recommed to replace the last sentence of Section
5.4.3 of rdap-extensions with the following:
*The strategies described in the following subsections primarily apply
to superseders of opaquely versioned extensions. An extension that
explicitly defines a versioning scheme, such as
[I-D.ietf-regext-rdap-versioning], MAY use the mechanisms defined by
that scheme to support a transition between extension versions. The use
of such a versioning scheme does not preclude the applicability of the
transition strategies described in this section, where appropriate.*
The current text appears to state that only the strategies described in
Sections 5.4.3.1 and 5.4.3.2 are STD95 compliant and that no other
transition strategy provided by a different versioning scheme is allowed.
Such a rewording would be more consistent with the conclusions of the
IETF126 side meeting, which aimed to move both rdap-extensions and
rdap-versioning forward.
Best,
Mario
--
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
Address: Via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
