Thanks
Roger
------------------------------------------------------------------------
*From:* regext <[email protected]> on behalf of Rick Wilhelm
<[email protected]>
*Sent:* Friday, June 24, 2022 11:37 AM
*To:* Gould, James <[email protected]>;
[email protected] <[email protected]>;
[email protected]
<[email protected]>; [email protected]
<[email protected]>
*Subject:* Re: [regext] OK, What Next? (was RDAP Extensions Approach
Analysis v2)
Caution: This email is from an external sender. Please do not click
links or open attachments unless you recognize the sender and know the
content is safe. Forward suspicious emails to isitbad@.
I have been watching this discussion with great interest. Thanks to
Jim Gould for the below. As it’s been a week and no one has commented
on this summary, I will assume that prior participants view the below
as largely reasonable.
In considering the below, I’ll offer the observations related to two
key use-cases related to implementers.
Use-case: Determine the version from the conformance identifier:
Approach A: The version information is in the prefix, probably at the
end and without a defined separator (in all examples I’ve seen). The
most logical place for the version is at the END of the prefix and
therefore, the version is placed in the middle of the conformance
identifier. While a reader can detect the version by looking closely,
this seems like a big disadvantage for an implementer seeking to parse
the conformance identifier. I would have a hard time writing that
code. Others might be better programmers.
Approach B/C: Version information at the end; using the underbar.
Seems easy to parse via code. Super-easy to read.
Implementers need to be able to determine the version quickly and
reliably in code. For this, either Approach B or Approach C is the
better fit. Approach A works for human readers, but not for code.
Use-case: Interacting with IANA Registry as an extension implementer:
Approach A: Create a new registry entry when creating a new extension
or when the version changes. Registry entry integrates version.
Benefit: IANA registry has full record of all versions. Drawback:
Seems hard to express version compatibility.
Approach B: Create a new registry entry when creating a new
extension, but NO interaction required when creating a version.
Approach C: Create a new registry entry when creating a new
extension. Create a new versioned extension identifier when creating
a new version of an existing extension. Registry entry decoupled
from versioning. Benefit: IANA registry has full record of all versions.
In my experience, IANA registries are typically managed to avoid
namespace collision. They do not typically have an explicit mechanism
for versioning. For example:
https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fprotocol-numbers%2Fprotocol-numbers.xhtml&data=05%7C01%7Crcarney%40godaddy.com%7Cf7f575f03b434a22320808da55ffe472%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637916855724654440%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=uTXePdmzasi%2FJAXvf7Aq%2FdCB1PWG3WxHXOYEEVZtVwQ%3D&reserved=0>
https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml#dns-sec-alg-numbers-1
<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fdns-sec-alg-numbers%2Fdns-sec-alg-numbers.xhtml%23dns-sec-alg-numbers-1&data=05%7C01%7Crcarney%40godaddy.com%7Cf7f575f03b434a22320808da55ffe472%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637916855724654440%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=8LrZ1Kc5a9NmxjyZ717bGehtFLMSKPSwgd4CtE8gcMs%3D&reserved=0>
https://www.iana.org/assignments/epp-extensions/epp-extensions.xhtml#epp-extensions-1
<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fepp-extensions%2Fepp-extensions.xhtml%23epp-extensions-1&data=05%7C01%7Crcarney%40godaddy.com%7Cf7f575f03b434a22320808da55ffe472%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637916855724654440%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=WUaiml%2FzBK2yXYiOPwiUnLNoeDXBxyOLWjNTQ7D3hNY%3D&reserved=0>
If client-side implementers used the IANA RDAP Extensions registry for
discovery, then it might make sense to have some versioning
mechanism. However, unlike the various RDAP Bootstrap registries, I
do not believe that the IANA RDAP Extensions registry is used for
discovery.
This would tilt the decision in favor of B because it results in a
simpler RDAP Extensions registry.
I wonder if, over the long term, Approach A might discourage protocol
evolution because the version information is embedded.
Regardless, when looking at the combination of these use-cases, I
think that Approach B is the better fit overall: simple to parse and
a simpler RDAP Extensions registry.
Happy to hear other points of view to move the discussion forward and
get us toward closure.
I think that whatever we do, it is going to require some clean-up.
But I would offer that the situation is never going to get any
easier. From an implementation standpoint, RDAP is still in the early
stages. Let’s make the investment now.
Thanks
Rick
*From: *regext <[email protected]> on behalf of Gould, James
<[email protected]>
*Date: *Friday, June 17, 2022 at 9:02 AM
*To: *[email protected] <[email protected]>,
[email protected]
<[email protected]>, [email protected]
<[email protected]>
*Subject: *[EXTERNAL] Re: [regext] OK, What Next? (was RDAP Extensions
Approach Analysis v2)
*CAUTION: This email came from outside your organization. Don’t trust
emails, links, or attachments from senders that seem suspicious or you
are not expecting.*
------------------------------------------------------------------------
I agree with Mario that we need to first consider the approaches
presented (approach A, B, and C) prior to determining what changes
need to be made to the existing RFCs. I believe that the use of the
"lunarNIC_level_0" identifier is appropriate for the RDAP Conformance
value in RFC 9083 to signal support for the specification.
The gap that exists in the RFCs is how to support versioning of the
RDAP extensions. The RDAP conformance identifiers can support
versioning, with "rdap_level_0" providing the base identifier for RDAP
itself. There is nothing that explicitly ties the prefix
registrations with the RDAP conformance identifier registrations,
where the prefixes define new path segment and response elements, and
the RDAP conformation identifier signals the support for a
specification. I believe the RDAP Conformance identifiers should
include the versioning, like the namespace URI in XML, and the
prefixes should not include versioning, like the namespace prefix in
XML. If we consider the versioning of RDAP extensions, I include an
example of each approach in the drafts below:
1. Approach A -
https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-openid-15
<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2FgmaECADgR1HNQmZfGNRzE%3Fdomain%3Ddatatracker.ietf.org&data=05%7C01%7Crcarney%40godaddy.com%7Cf7f575f03b434a22320808da55ffe472%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637916855724654440%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=kIE%2BMq1B4GKgfwhtC%2FuL1YRPIFgDO9p1ixB6gAwSkCM%3D&reserved=0>
1. Registration of versioned extension prefix “roidc1”, that is
used for the RDAP conformance and used as an RDAP prefix, as
in “roidc1_session”, “roidc1_deviceInfo”,
“roidc1_openidcConfiguration”.
2. If the version changes, all the extension elements (RDAP
conformance and the RDAP prefixes elements will change), and
there is no formal format for the version number.
2. Approach B -
https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-redacted-04#section-6
<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2F5HCkCBBjV6f7GZDi6yN-J%3Fdomain%3Ddatatracker.ietf.org&data=05%7C01%7Crcarney%40godaddy.com%7Cf7f575f03b434a22320808da55ffe472%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637916855724654440%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=EUdsVt9sDEtIPYhKr5Y8fgIx6Wz%2BaXBI1FxDqylsMzc%3D&reserved=0>
1. Registration of the extension prefix “redacted”, which is used
for the new response member and used as the prefix used in the
versioned RDAP conformance value “redacted_level_0.2”. Note,
the use of “.” does not match RFC 7480, so the versioned RDAP
Conformance value should have been “redacted_level_0_2”.
2. The version of the RDAP Conformance is defined in the
associated specification, but it will use the unique prefix
registered in the RDAP Extension Registry.
3. This provides the linkage similar to Approach A, but doesn’t
cascade versioning into the prefix and the extension elements.
3. Approach C -
https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-redacted-07
<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2FG7WTCDklX8F596oHAnunI%3Fdomain%3Ddatatracker.ietf.org&data=05%7C01%7Crcarney%40godaddy.com%7Cf7f575f03b434a22320808da55ffe472%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637916855724654440%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=b0xHcQiQziEKP2DtATVpWxVowVw7ht7DERaarDrZlfk%3D&reserved=0>
1. Registration of the extension prefix “redacted” and the
versioned extension identifier “redacted_level_0_3”, where
there can be more than one extension prefix “redacted”,
“redacting”, “redaction” registered along with the versioned
extension identifier “redacted_level_0_3”. The RDAP
conformance identifier is used for signaling only and the
registered prefixes ensure uniqueness with other RDAP extensions.
I’m starting to think that Approach B may satisfy both requirements of
those advocating for Approach A and those advocating for Approach C,
where there is a linkage between the RDAP conformation value and the
RDAP prefixed in Approach A, and there is versioning support that is
isolated to the RDAP conformance in Approach C. The RFCs mix of the
term prefix and identifier would need to be clarified and how
versioning is handled needs to be defined.
--
JG
James Gould
Fellow Engineer
[email protected]
<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com <http://verisigninc.com/
<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2F5kk9CERmYxi37AlSP2r_h%3Fdomain%3Dverisigninc.com%2F&data=05%7C01%7Crcarney%40godaddy.com%7Cf7f575f03b434a22320808da55ffe472%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637916855724654440%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=8m6cngcRSoZ1nHbM9X9gjCMZ3BszpSHJ5%2BTfCO4%2FnJE%3D&reserved=0>>
On 6/16/22, 10:08 AM, "regext on behalf of Mario Loffredo"
<[email protected] on behalf of [email protected]> wrote:
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 Scott,
Il 16/06/2022 15:30, Hollenbeck, Scott ha scritto:
>> -----Original Message-----
>> From: regext <[email protected]> On Behalf Of Mario Loffredo
>> Sent: Thursday, June 16, 2022 2:57 AM
>> To: [email protected]
>> 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
> [email protected]
>
https://secure-web.cisco.com/1Kzc-Qe6UgjV-R9D2TuSkCiAafVeiC69srrhOy-YfkUT4wEoM6P4tZxle5nMP2p-grJmL0sN3MargRWKU2K-ElZjgbuj8xU0cvmNj4uqkkc-SjTa-BGR0IOlyGCdhl8Rj9Qc4NbyS0UjRXvGNXAdDDEQCMhMe8cYtnDL9tvmCrGYtXWO7-oBuJQybPtdjJkCPzkggPpEpCWOmAnGfc1Uufdspuxdz1Xt0F6s6QQBVHkVvoZ9TnNImAB3s5ENwyL9_/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2FIqfWCG6o18i17yBfknsBU%3Fdomain%3Dsecure-web.cisco.com&data=05%7C01%7Crcarney%40godaddy.com%7Cf7f575f03b434a22320808da55ffe472%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637916855724654440%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=KmvSoXaCm6kQ0B9%2F5hZBiINnzfvRaeUKlOa0rKEYkEI%3D&reserved=0>
--
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://secure-web.cisco.com/14ojfrPjCC0uZKbflsEuxNfFgHKsAz5anzd-kaxzeNZsRbCoDuDjpzlEzWIzaM5MM8XZjqFJHKfGDDPcnA6dr_GgY2-CXYGZieUsDALj1M9E2Fmebwzya7Wp3wKKqZ0rg6uy10EnPPBNDdD83p4kCSKx4Cll-08iXc0jKVi-322wXWyKG1ITCW0m1sdJEkipnozrferGaRL91A5v6j0PkC4lg_f2Dh9-sN84qFT8BhMJeNh1aHQvYc0Sp-Lh9J7D3/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo
<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2FDqKiCJ6r4QiqJ4BtOAOnl%3Fdomain%3Dsecure-web.cisco.com&data=05%7C01%7Crcarney%40godaddy.com%7Cf7f575f03b434a22320808da55ffe472%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637916855724654440%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=hRnJH5UIGfPnAXbIXGJwdgThplTJnFmvyNpEJzgHu9E%3D&reserved=0>
_______________________________________________
regext mailing list
[email protected]
https://secure-web.cisco.com/1Kzc-Qe6UgjV-R9D2TuSkCiAafVeiC69srrhOy-YfkUT4wEoM6P4tZxle5nMP2p-grJmL0sN3MargRWKU2K-ElZjgbuj8xU0cvmNj4uqkkc-SjTa-BGR0IOlyGCdhl8Rj9Qc4NbyS0UjRXvGNXAdDDEQCMhMe8cYtnDL9tvmCrGYtXWO7-oBuJQybPtdjJkCPzkggPpEpCWOmAnGfc1Uufdspuxdz1Xt0F6s6QQBVHkVvoZ9TnNImAB3s5ENwyL9_/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2FIqfWCG6o18i17yBfknsBU%3Fdomain%3Dsecure-web.cisco.com&data=05%7C01%7Crcarney%40godaddy.com%7Cf7f575f03b434a22320808da55ffe472%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637916855724654440%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=KmvSoXaCm6kQ0B9%2F5hZBiINnzfvRaeUKlOa0rKEYkEI%3D&reserved=0>
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
