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? > 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? -andy _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
