Andy, I saw Mario's response to "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.". We never discussed having many versions of an extension with the same extension identifier as not being STD95 compatible; although, we heard STD95 brought up many times in the discussion.
You need to point out the language in STD95 that would make the versioning extension non-compatible (non-compliant) with STD95, since we've been discussing and debating opaque versioning versus other forms of versioning for years. It states in draft-ietf-regext-rdap-extensions "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", which mirrors what was agreed to. The purpose of the versioning extension is to provide explicit versioning outside of the extension identifier, which makes it compliant with STD95. If different versions of an extension required a different extension identifier, then that means all extensions that has used opaque versioning as IETF drafts are not STD95 compatible. I'm not aware of any of the IETF drafts changing the extension identifier per interface change through the draft process. Creating an extension that doesn't change the use of the extension identifier in STD95 and that adds additional versioning information within the bounds of the extension, is fully compliant and compatible with STD95. In the meeting at IETF-126 it was made clear that draft-ietf-regext-rdap-extensions was meant to clarify STD95 with no changes required of the existing extensions. The language in section 5.4.3 needs to provide guidance and not mandates with a static list of unproven strategies. Both strategies refer to "extension author", which means the strategy needs to be used in an extension specification. There are no extension specifications that use either strategy in a successor extension of a predecessor extension. Consider the use case of a bis draft of the redacted extension in RFC 9537 that only wants to remove the use of JSON Path, which we've brought up in the past. In this use case the child members of "prePath", "postPath", "replacementPath", and "pathLang" would be removed. The bis draft could use opaque versioning by bumping the extension identifier from "redacted" to "redacted2". How would the application of the strategies in draft-ietf-regext-rdap-extensions apply to this use case? With the "Standalone Superseders with Versioning" strategy, the bis draft simply removes the needed child members, bumps the extension identifier, and then leverages the versioning extension in the transition from "redacted" to "redacted2" with a transition period. By adding support for extension relationships in the versioning draft, the server can signal support for both redacted extensions (predecessor "redacted" and successor "redacted2") with the relationship, the start, the end of each extension, and which extension is the default. I believe the server will default to over version of the redacted extension, which based on Section 7.2 of draft-ietf-regext-rdap-versioning the server would support "redacted" by default with the option for clients to use "redacted2", then switch the default to "redacted2" with the option for clients to use "redacted", and finally only support "redacted2" at completion of the transition period. Both "redacted" and "redacted2" are standalone specifications with the ability to leverage the versioning extension in support of the transition. 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 8/17/26, 4:09 PM, "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. James, Thanks for this. Your questions have made me think that there is more explanatory text needed. Inline... On 8/14/26 5:10 PM, Gould, James wrote: > JG15-Addressed > > I recommend injecting some of Section 2.3 “Bare Extension Identifiers” into > Section 2.2 and formally defining the ABNF for an RDAP extension identifier, > which revises the “name” ABNF rule defined in Section 6 of [RFC 7480] and > formally defines the RDAP extension (variable / element / parameter) ABNF. A > good name needs to be given to the RDAP extension elements that use the RDAP > extension identifier as a prefix. > > OLD > > For this reason, this document updates the guidance of [RFC7480] regarding > underscore characters: RDAP extensions MUST NOT use an underscore character > in their RDAP extension identifier. Implementers should be aware that many > existing extension identifiers do contain underscore characters. > > NEW > > This document updates the ABNF “name” rule in [RFC7480] to not allow the use > of an underscore character in the RDAP extension identifier. The revised ABNF > [RFC5234] “name” rule is: > > name = ALPHA *( ALPHA / DIGIT ) > > Implementers should be aware that existing extension identifiers do contain > underscore characters. > > JG15-Addressed See Jasdip's message. We appear to have blundered here. > I like scoping the sub-sections of Section 5.4.3 with “replacements”, which > as when the extension identifier changes. We need to ensure that the > strategies are explicitly not considered. Considering that designers and > implementers may take different approaches that listed in the sub-sections, > to clarify this I would add the word “non-exhaustive” to the last sentence. > > OLD > > Strategies for using a replacement in a transition are described below. > > NEW > > The non-exhaustive list of considerations for using a replacement in a > transition are described below: > > JG15-Not addressed, " Strategies for using a replacement in a transition are > described" was replaced with "Known strategies compatible with [RFC7480], > [RFC9082], and [RFC9083] below." It's unclear how these strategies are > "compatible" with STD95. That's a good question. They are compatible because they use the namespacing strategy specified in STD95 to differentiate the meaning of once extension from another. I think we can put some wording in to explain it. Regarding the term "superseder" (which I don't think anybody was particularly happy with), I think it comes from an over reliance on deprecation of the predecessor. As that is not always the intent, perhaps a better term is "supplement" with some text about the caveat on interoperability if the predecessor is deprecated. For example, both RFC 9910 and the NRO profile use this pattern with no intent to deprecate. I think we need to work on the text here. > 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. > > Section 5.4.3.1 “Non-overlapping Replacements” > > This is certainly an option, but I haven’t seen an instance where this has > been implemented in new versions of an RDAP extension. I don’t have an issue > included this consideration if the sub-sections of 5.4.3 are defined as a > non-exhaustive list of considerations. > > JG15-May have been addressed. The non-exhaustive language was not added to > the draft for the list of strategies, but the section does include the term > considerations. I want to confirm that if a strategy is used that does not > include one of these two strategies will be it considered non-compliant, > since I wouldn't recommend using these strategies based on my operational > experience of transitioning between EPP extension versions. It would be non-compliant if it violates the rules of STD95 (see text above). -andy _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
