Hi Scott,
Il 16/06/2022 15:30, Hollenbeck, Scott ha scritto:
-----Original Message-----
From: regext <regext-boun...@ietf.org> On Behalf Of Mario Loffredo
Sent: Thursday, June 16, 2022 2:57 AM
To: regext@ietf.org
Subject: [EXTERNAL] 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.
Hi folks,
I invite you to consider that, currently, rdap-reverse-search and,
potentially,
three other RDAP-related docs are blocked waiting for the end of this
discussion.
[SAH] There's no reason for the documents to be blocked if you adopt the
practice described in 9083. Look at Section 2.1 (Naming):
"Servers that insert such unspecified members into JSON responses SHOULD have
member names prefixed with a short identifier followed by an underscore
followed by a meaningful name"
We need an identifier for "unspecified members" (extension elements) that's to
be used as a prefix. Further:
"If The Registry of the Moon desires to express information not found in this
specification, it might select "lunarNIC" as its identifying prefix and
insert, as an example, the member named "lunarNIC_beforeOneSmallStep" to
signify registrations occurring before the first moon landing and the member
named "lunarNIC_harshMistressNotes" that contains other descriptive text."
This example shows the identifying prefix being used in two examples. This
begs the question: "What is registered with IANA and returned in the
rdapConformance data structure?". Section 4.1 (RDAP Conformance) has the
answer:
"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].
For example, if the fictional Registry of the Moon wants to signify that their
JSON responses are conformant with their registered extensions, the string
used might be "lunarNIC_level_0"."
This unambiguously tells us that the value registered with IANA is included in
the rdapConformance data structure. If you consider the text from Section 2.1,
the only thing that make sense is if these identifiers are one and the same.
That's why I'm saying that the example in 4.1 is incorrect and needs to be
fixed. It should be "lunarNIC" to be consistent with Section 2.1 such that the
identifier used with "unspecified members" is the same identifier that's
returned in the rdapConformance data structure and the same identifier that's
registered with IANA.
In addition, it seems to me more logical, first, to decide how RDAP
exentions
must be treated and, then, correct RFC 9083 to make it consistent with what
decided.
[SAH] 9083 already describes how extensions must be treated. If there's
anything unclear about that description, that lack of clarity should be
addressed first. If the WG wants to *change* that description, that's a
different discussion.
[ML] Whatever will be the approach (A,B, or C) we'll agree on, RFC 9083
needs to be updated.
But depending on the approach agreed, the corrections needed will be
different and they wiil involve either the definitions or the examples
or both.
Likewise, the elected approach could imply possible changes to the
existing documents.
Best,
Mario
Scott
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
--
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
