Andy, My responses are included below, prefixed with "JG-".
-- 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/21/26, 4:40 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. On 8/21/26 10:18 AM, Gould, James wrote: > > 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. Isn't this non-overlapping superseders in Section 5.4.3.1? JG-No, the successor "redacted2" extension does not "replicate all the functionality of the predecessor" of the predecessor "redacted" extension. > 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. Isn't this section 5.4.4? JG-No, since the extension identifier is being changed from "redacted" to "redacted2", the successor extension is considered a superseder and therefore one of the two strategies defined for superseders needs to be followed. Neither strategy (non-overlapping superseders in section 5.4.3.1 nor the overlapping superseders in section 5.4.3.2) apply to what I described. The strategy of defining a superseder extension that stands alone from the predecessor and leverages an extension like the versioning extension to support the transition needs to be formally defined as a valid strategy, which is what I'm referring to as the ""Standalone Superseders with Versioning" strategy. -andy _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
