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]
