Re: [regext] OK, What Next? (was RDAP Extensions Approach Analysis v2)

["Hollenbeck, Scott" <[e-mail]>]

> -----Original Message-----
> From: Gould, James <jgould=[e-mail]>
> Sent: Monday, June 27, 2022 12:37 PM
> To: Hollenbeck, Scott <[e-mail]>; [e-mail];
> [e-mail]
> Subject: [EXTERNAL] Re: RE: [regext] OK, What Next? (was RDAP Extensions
> Approach Analysis v2)
>
> 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.
>
> Scott,
>
> The question is how we handle versioning, which is an aspect not covered in
> the existing RFCs.  The only version reference is in the RDAP Conformance
> definition in section 4.1 of RFC 9083 with "rdap_level_0" and
> "lunarNIC_level_0".  If the use of "lunarNIC_level_0" was a mistake, then
> versioning is completely absent for extensions.  A client can easily do a
> regular expression match with the RDAP conformance values since the
> prefixes should be unique.  The reference to "The extension identifier is
> used as a prefix in JSON names and as a prefix of path segments in RDAP
> URLs" in RFC 7480 simply defines the primary key in the RDAP Extensions
> Registry and doesn't imply anything about the RDAP Conformance value in
> RFC 9083.

[SAH] Sorry, but "doesn't imply anything about the RDAP Conformance value in 
RFC 9083" is just not true. 7480 describes that prefix as being registered 
with IANA and being used to prefix extension elements. 9083 says "When custom 
JSON values are inserted into responses, conformance to those custom 
specifications MUST be indicated by including a unique string literal value 
registered in the IANA RDAP Extensions registry specified in [RFC7480]". 
That's clear linkage.

I've said earlier that the errata change to 9083 could be from "lunarNIC" to 
"lunarNIC_level_0" to make the examples consistent. That change would also 
demonstrate that version information can be included in registered prefixes.

Scott