Scott,
The "including a unique string literal value registered in the IANA RDAP Extensions registry specified in [RFC7480]" could be the prefix value "lunarNIC", where the “lunarNIC_level_0” value does include the unique string literal value “lunarNIC” registered in the IANA RDAP Extensions registry specified in [RFC7480]. The RFCs refer to identifiers, prefixes, and now unique string literal values. They are very non-specific and open to interpretation. If we were to support Approach B, my recommendation for the errata change to RFC 9083 would be to change section 4.1 to read: … When custom JSON values are inserted into responses, conformance to those custom specifications MUST be indicated by including unique prefix identifiers registered in the IANA RDAP Extensions registry specified in [RFC7480]. The conformance value MUST match or be prefixed with a registered unique prefix identifier. For example, if the fictional Registry of the Moon wants to signify that their JSON responses are conformant with their registered extensions, the conformance value might be "lunarNIC_level_0" that uses the registered “lunarNIC” prefix identifier. … If normative language can’t be used in the errata change, then the second sentence could read “A conformance value matches or is prefixed with a registered unique prefix identifier”. The question is how we address the inclusion of a non-prefix identifier, such as “icann_rdap_response_profile_0” in the RDAP Extensions Registry, which defines policy and not new extension elements. I believe a separate draft will be needed to fully define creating the various forms of RDAP extensions, which includes versioning. -- JG James Gould Fellow Engineer jgo...@verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 6/27/22, 12:54 PM, "Hollenbeck, Scott" <shollenbeck=40verisign....@dmarc.ietf.org> wrote: > -----Original Message----- > From: Gould, James <jgould=40verisign....@dmarc.ietf.org> > Sent: Monday, June 27, 2022 12:37 PM > To: Hollenbeck, Scott <shollenb...@verisign.com>; mario.loffr...@iit.cnr.it; > regext@ietf.org > 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
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
