Il 27/06/2022 20:01, Gould, James ha scritto:
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.
Agreed.
The incipit of section 4.1 of RFC9083 seems too generic to me either.
The data structure named "rdapConformance" is an array of strings,
each providing*a hint* as to the specifications used in the
construction of the response.
It doesn't formally define how rdapConformance tags should be generated
starting from IANA registered values.
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.
Agreed.
Mario
--
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
--
Dr. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
