> -----Original Message-----
> From: Gould, James <[email protected]>
> Sent: Monday, July 18, 2022 2:11 PM
> To: Hollenbeck, Scott <[email protected]>; [email protected];
> [email protected]
> Cc: [email protected]
> Subject: [EXTERNAL] Re: RE: RE: RE: Re: [regext] OK, What Next? (was RDAP
> Extensions Approach Analysis v2)
[SAH] [snip]
> JG - I'm going to go back to Approach B, where there is a unique common
> prefix registered ("e.g., "foo") used by all extension elements and the
> extension's RDAP conformance values ("foo_level_0" or even pointed
> versions "foo_level_0_1"). You get the extension signaling and content
> consistency and the versioning is isolated to the RDAP conformance. What is
> the issue with this approach?
[SAH] All I'm going to say (again) is that ANY approach that doesn't register
an identifier with IANA and then use that same identifier as the value
returned in the rdapConformance data structure and as the prefix for extension
elements is inconsistent with the original intent of RFC 9083. Which gets us
back to what *I* think we need to do:
1. Address the issue in 9083 by making the technical erratum correction I just
repeated above, and then
2. Decide if some sort of version negotiation is a needed feature, and if it
is, how to do it within the constraints of Standard 95.
Note (again) that we cannot use the errata process to make fundamental changes
to 9083:
https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/
Scott
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
