Re: [regext] Extension Prefixes, JSON Values, and URI Path Segments

[Mario Loffredo <[e-mail]>]

Hi folks,

think we should converge to a widely shared solution as soon as 
possible. There are 4 ongoing drafts about RDAP extensions that are 
obviously involved (and partially blocked).

Anyway, an unambiguous definition of the relationship between the 
extension identifier to be registered by IANA, the names of response 
extensions and URI path segments, and the rdapConformance tags is 
advisable for RDAP implementers.

Personally, I'm not in favor of the exact match between all the 
aforementioned names and in a previous mail I had expressed my opinion 
about excluding the version information from that match.

It seemed to me that such approach could result in better versioning the 
RDAP extensions, especially those ones (hopefully the most) that 
wouldn't break the REST API contract.

Before James's post, I had interpreted that I was the only one 
supporting that approach, hence I had changed both rdap-reverse-search 
and rdap-jscontact.


Best,

Mario


Il 06/05/2022 17:51, Jasdip Singh ha scritto:
>
> Hello James,
>
> Please see my comments, marked [JS2].
>
> Thanks,
>
> Jasdip
>
> *From: *"Gould, James" <[e-mail]>
> *Date: *Friday, May 6, 2022 at 9:25 AM
> *To: *Jasdip Singh <[e-mail]>, "[e-mail]" <[e-mail]>
> *Subject: *Re: Re: [regext] Extension Prefixes, JSON Values, and URI 
> Path Segments
>
> Jasdip,
>
> Thanks, I include my responses embedded below prefixed by “JG2 - “.
>
> -- 
>
> JG
>
>
>
>
> *James Gould
> *Fellow Engineer
> [e-mail] 
> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
> *From: *regext <[e-mail]> on behalf of Jasdip Singh 
> <[e-mail]>
> *Date: *Thursday, May 5, 2022 at 6:45 PM
> *To: *"[e-mail]" <[e-mail]>
> *Subject: *[EXTERNAL] Re: [regext] Extension Prefixes, JSON Values, 
> and URI Path Segments
>
> Hello James,
>
> Please find my comments below.
>
> Thanks,
>
> Jasdip
>
> *From: *"Gould, James" <[e-mail]>
> *Date: *Thursday, May 5, 2022 at 2:46 PM
> *To: *Jasdip Singh <[e-mail]>, "[e-mail]" <[e-mail]>
> *Subject: *Re: Re: [regext] Extension Prefixes, JSON Values, and URI 
> Path Segments
>
> *From: *regext <[e-mail]> on behalf of Jasdip Singh 
> <[e-mail]>
> *Date: *Thursday, May 5, 2022 at 1:53 PM
> *To: *"[e-mail]" <[e-mail]>
> *Subject: *[EXTERNAL] Re: [regext] Extension Prefixes, JSON Values, 
> and URI Path Segments
>
> Hello James, Scott,
>
> Should the rdapConformance string not to be an exact match for the 
> extension identifier registered with IANA? Per Tom’s earlier note [1], 
> that seems to be the case for most, if not all, well-known extensions. 
> If so, then the proposed rdapConformance “redacted_level_1_0” won’t 
> match the proposed to-be-registered extension “redacted”.
>
> JG – Based on my read of the RFC language, I don’t believe the 
> rdapConformance string needs to exactly match the list of URI path 
> segments and JSON members associated with the extension.
>
> [JS] Though this is not explicitly written anywhere in the standard 
> but the “majority” precedence turns out to be an exact match between a 
> registered extension identifier and the related rdapConformance string 
> (per Tom’s earlier note, all in section “-1” there follow this tight 
> coupling whereas those in section “-2” (fred, artRecord, platformNS, 
> and regType for centralnic) don’t. Further, section 8.1. RDAP 
> Extensions Registry in RFC 7480 says: /“The extension identifier is 
> used as a prefix in JSON names and as a prefix of path segments in 
> RDAP URLs.”/ That’s the most definitive guidance I could find. :)
>
> JG2 – I believe this is the deepest the discussion has gotten on the 
> language of the RDAP Extension Registry and how it relates to the 
> values used in the URI path segments, JSON members, and the RDAP 
> Conformance.  There is a mix of usage based on the lack of clarity in 
> the RFCs.  I don’t believe the existing registrations violate the 
> language of the RFCs and the proposal I posted to the list meets the 
> language of the RFCs and doesn’t invalidate the existing 
> registrations.  The lack of clarity may be an opportunity for an 
> update to RFC 7480 for Section 6 “Extensibility” and Section 8.1 “RDAP 
> Extensions Registry”.
>
>   As Tom’s earlier note highlights there is really a mix of prefixes 
> and identifiers currently registered in the RDAP Extension Registry.
>
> [JS] That’s fair but fortunately it seems to me that the ones where 
> the rdapConformance string does not match the extension identifier 
> (section “-2” (fred, artRecord, platformNS, and regType) in Tom’s note 
> are for one only entity (centralnic). The rest (section “-1” in that 
> note) have an exact match between the extension identifier and the 
> rdapConformance string.
>
> JG2 – I believe the best approach to take with this is to ensure that 
> all the existing registrations don’t violate the language of the RFC 
> and to consider what is the best path forward.  I don’t see any 
> violations with the RFCs   Any proposal for moving forward cannot 
> invalidate the existing registrations.  Is there a technical advantage 
> to have a single extension identifier that exactly matches the URI 
> path segments, JSON members, and RDAP Conformance?  I believe the RDAP 
> Conformance provides the signaling with supporting an extension, which 
> is represented by an extension identifier.  The URI path segments, and 
> the JSON members associated with an extension are associated with the 
> registered extension prefixes.  The proposal is for the extension to 
> register a versioned identifier for use in the RDAP Conformance and 
> zero or more prefixes that are used for the URI path segments and JSON 
> members.  For draft-ietf-regext-rdap-redacted, this means two RDAP 
> Extension Registry registrations (“redacted_level_1_0” identifier used 
> in RDAP Conformance and “redacted” to be used for the JSON member).
>
>   Mixing the signaling in the rdapConformance member, which I believe 
> can and should include versioning, with the naming of the URI path 
> segments and JSON members is unnecessary coupling.
>
> [JS] Yah, this I believe is at the heart of our discussion. So far, 
> the “majority” precedence seems to point to tighter coupling between 
> the extension identifier and the rdapConformance string.
>
> JG2 - draft-ietf-regext-rdap-redacted is exposing the issue of the 
> past coupling, where we’re taking a best practice used in the EPP 
> extensions with the use of a pointed identifier.  The pointed version 
> number is applicable for the RDAP Conformance for identity (e.g., 
> “redacted_level_0_2”) but is not useful or needed for the JSON member 
> “redacted”.
>
>   For example, what if there is an extension that contains multiple 
> URI path elements and JSON members.
>
> [JS] Turns out we have an exhibit for this precise use case: 
> https://bitbucket.org/arin-specs/arin-rdap-originas/src/master/arin-rdap-originas.txt 
> <https://secure-web.cisco.com/1Hj540aENSbHyX8Le_IgtTCRWi-6mHtn8E29mqDfuMX1f9EWwcksbghzxvRLcw2IKMh4hhaquRlFe3aEar9VUyiijtz5yzzqHxAhASM92dfGztsSUkBJ0Ehh0ArtRAMo55xggCtFqk8GXk9rTbZ-psckeu0sn8D-Gwpq1STZHfEvFyGV6Fc4Xf6UBNJLqkK6UjGQp0Em2sRfy88vVceek6fZs-CYxtBGYk4B3MNe0vMjPz70PnOmgpMdvvEKsBWbb/https%3A%2F%2Fbitbucket.org%2Farin-specs%2Farin-rdap-originas%2Fsrc%2Fmaster%2Farin-rdap-originas.txt> 
> . “arin_originas0” though only is for one entity’s purposes (ARIN) but 
> seems like a good example to emulate IMO.
>
> JG2 – The use of a versioned prefix identifier certainly works.  I 
> question the value with having the URI path segment of 
> arin_originas0_networksbyorigin and the JSON member 
> “arin_originas0_networkSearchResults” instead of simply 
> “networksbyorigin” and “networkSearchResults”, respectively.  In the 
> world of XML, this feels like we’re merging the namespace URIs with 
> the element names.  It may be more of an attempt to define an XML 
> namespace prefix with the element name, but there is no clear 
> requirement to include a version, which is handled by a namespace URI. 
> There is no clear separation between the namespace prefix and the 
> element name, since both can use underbars.  It’s not well defined in 
> the RFCs, clunky (not a technical term), and inflexible to cover a 
> variety of use cases.  I would much prefer to ensure that the RDAP 
> Conformance represents the versioned identifier and to decouple the 
> registered prefixes for the URI path segments and JSON members.
>
>   We need to ensure that there is signaling of supporting the 
> extension in the rdapConformance member and we need to ensure that 
> there is no conflict with the URI path segments and the JSON members 
> defined in the extension with other extensions.  This can be handled 
> by having registrations for the prefix(es) and for the identifier used 
> in the RDAP conformance .
>
> [JS] Totally agree with avoiding conflicts but AFAIK only extension 
> identifiers are registered with IANA and rdapConformance strings 
> “re-use” that registered string, exactly in case of tight coupling.
>
> JG2 – There is nothing in the RFC’s that require the tight coupling, 
> so we should not include the tight coupling unless there is some 
> technical advantage in doing so.
>
> [JS2] Yah, this is a good way to think through the benefits of tight 
> coupling between a registered extension identifier and the related 
> rdapConformance string.
>
> Section 4.1 RDAP Conformance in RFC 9083 says: “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.” 
> (italics mine)
>
> As we know, the way that happens is that an extension is registered 
> with IANA, backed by a spec to alleviate any ambiguity. The above 
> “specifications” phrase IMO connotes that tight coupling.
>
> So, let’s say an extension evolves sometime in the future ( hasn’t 
> happened yet ;) ). I would wager one would register the next version 
> of that extension, again backed by a new spec (perhaps, the previous 
> spec altered with the changes).
>
> Now, section 8.1. RDAP Extensions Registry in RFC 7480 says: “/The 
> extension identifier is used as a prefix in JSON names and as a prefix 
> of path segments in RDAP URLs./” That points to using the newly 
> versioned extension identifier in the member names and URI paths. The 
> rdapConformance string, matching the new extension identifier, would 
> signal the new spec (provided as part of registering the new version 
> of the extension with IANA), per its definition in section 4.1 RDAP 
> Conformance in RFC 9083.
>
> As to the advantages of having versioned extension identifiers in 
> member names and path segments, I can think of on both server and 
> client sides. For a server, supporting old and new path segments 
> affords a good transition path, providing grace period to clients to 
> switch. As for a client, by calling a versioned path segment, it 
> exactly knows which spec (registered with IANA) it is processing. (We 
> earlier had a discussion on the “brittleness” risk and Mario had 
> shared ways to allay that concern.)
>
> I also want to re-iterate what Tom had said earlier while discussing 
> this vis-à-vis reverse search:
>
> “As well as guaranteeing that different extensions occupy different 
> namespaces, which has other positive effects (e.g. a client seeing an 
> unknown rdapConformance value could extract all fields/paths prefixed 
> with that rdapConformance value from the response, for further review 
> by a user).
>
> ...
>
> (Assuming the lunarNIC text is incorrect, possibly it can be addressed 
> by an erratum, and even if the category 2 extensions can't be changed 
> now, at least the set of extensions in that category doesn't have to 
> expand.)”
>
> Further, shouldn’t the new fields and paths be prefixed with that 
> exact same registered extension identifier? If not, then what happens 
> to the “redacted” member name when the rdapConformance jumps to the 
> next version, say, from redacted_level_1_0 to redacted_level_2_0, with 
> a new child member (beside “name”, “path”, “pathLang”, “method”, and 
> “reason”) ?
>
> JG - The rdapConformance value would reflect “redacted_level_2_0” that 
> would then signal support for the new child member.  The “redacted” 
> member name itself does not need to change since the version change is 
> signaled with the RDAP Conformance value.
>
> Lastly, discounting strict “semantic versioning” and understanding how 
> a minor version might help during the development of an extension, 
> won’t simply registering a new extension with the major version help 
> keep things simple for our purposes? Also, the “_level” sub-string in 
> an extension identifier seems extraneous, no?
>
> JG – Are you proposing the use of the RDAP Conformance value of 
> “redacted_level_1” instead of “redacted_level_1_0”?
>
> [JS] Yah, no minor version in extension identifier and thereby, in 
> rdapConformance string.
>
> JG2 – Yes, I thought about dropping the trailing “_0”, which can be done.
>
>   Yes, I agree that the “_level” substring is somewhat extraneous, but 
> it is consistent with the scheme used for RDAP with “rdap_level_0”.
>
> [JS] True but emulating “rdap_level_0” is somewhat tricky since AFAIK 
> it is not considered an extension, per the IANA RDAP Extensions 
> registry ( 
> https://www.iana.org/assignments/rdap-extensions/rdap-extensions.xhtml 
> <https://secure-web.cisco.com/1Hnx8cWNS-EKfBU5kvD5UhYNw0qk2WZAYt0xGE_mXBPzb0aa8T88p0z7Wh2YO16-LVubR1a1Xjp9uth_tNRpyRpUAf6crsCzpVRoRS8IEoK9W3c_K18Qwic3AYlRtGEJKYu-gdLroJ5ffBStgA42DeWxUok4qPlXm5-0yGP6X6G6UWCtw0QHxd1e9ZMx7l9LFvOsfEIkh_exPWha-Zvncd1dfLpNil-bDNwaXSRX_w-oUuW81dNMbkxgcTh_V5dYS/https%3A%2F%2Fwww.iana.org%2Fassignments%2Frdap-extensions%2Frdap-extensions.xhtml> 
> ).
>
> JG2 – The extension emulating the value used for the RDAP Conformance 
> by the base RFC makes sense to me.  By decoupling the identifier and 
> the prefixes of the extension, the identifier can more easily emulate 
> the identifier used for the base RFC.
>
> Trying to reconcile various inputs thus far. :)
>
> Thanks,
>
> Jasdip
>
> [1] From Tom’s earlier note:
>
> - 1.
>
>     - rdapConformance is an exact match for the extension identifier
>
>     - 1.1
>
>         - New fields are prefixed with the extension identifier
>
>         - New paths are prefixed with the extension identifier
>
>             - arin_originas0
>
>     - 1.2
>
>         - New fields are prefixed with the extension identifier
>
>         - No new paths are defined
>
>             - cidr0
>
>             - paging
>
>             - sorting
>
>             - subsetting
>
>     - 1.3
>
>         - rdapConformance is an exact match for the extension identifier
>
>         - No new fields are defined
>
>         - No new paths are defined
>
>             - icann_rdap_response_profile_0
>
>             - icann_rdap_technical_implementation_guide_0
>
>             - nro_rdap_profile_0
>
>             - nro_rdap_profile_asn_flat_0
>
>             - nro_rdap_profile_asn_hierarchical_0
>
>             - rdap_objectTag
>
>             - redirect_with_content
>
> *From: *regext <[e-mail]> on behalf of "Gould, James" 
> <jgould=[e-mail]>
> *Date: *Thursday, May 5, 2022 at 11:44 AM
> *To: *"shollenbeck=[e-mail]" 
> <shollenbeck=[e-mail]>, "[e-mail]" 
> <[e-mail]>
> *Subject: *Re: [regext] Extension Prefixes, JSON Values, and URI Path 
> Segments
>
> Scott and I discussed this offline, and below is a proposal for the 
> RDAP Extension Registry registrations that meets the language in the 
> RFCs and ensures that there are no conflicts (RFC 7480 “ensure 
> uniqueness of extension identifiers”) with the URI paths or JSON 
> members for new RDAP extensions.
>
> 1.Register any URI path or JSON member prefixes added by the 
> extension.  The value may have a null suffix, so the exact value can 
> be registered.
>
> a.Supporting language in the RFCs
>
> i.RFC 7480
>
> 1.Prefixes and identifiers SHOULD only consist of the alphabetic 
> US-ASCII characters A through Z in both uppercase and lowercase, the 
> numerical digits 0 through 9, and the underscore character, and they 
> SHOULD NOT begin with an underscore character, numerical digit, or the 
> characters “xml”.  The following describes the production of JSON 
> names in ABNF [RFC5234]:
>
> a.name = ALPHA *( ALPHA / DIGIT / “_” )
>
> i.I would more clearly define a custom element (custom URI path or 
> custom JSON member) using the ABNF, which does meet the existing RFC 
> 7480 ABNF:
>
> 1.element = prefix [ suffix ]
>
> 2.prefix = name
>
> 3.suffix = “_” name
>
> ii.RFC 9083
>
> 1.When custom JSON values are inserted into responses, conformance to 
> those custom specifications MUST use a string prefixed with the 
> appropriate identifier from the IANA RDAP Extensions registry 
> specified in [RFC7480]
>
> a.This normative language is contained in the RDAP Conformance section 
> of RFC 9083, but it does cover the JSON members use of the format 
> defined above in RFC7480.
>
> b.Plan for draft-ietf-regext-rdap-redacted
>
> i.Registration of “redacted” 
> (https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-redacted#section-6.1 
> <https://secure-web.cisco.com/1796EpAjawOweT0aWVjTWHSxJCnbUyYlGmlyFkmK3buAQC1FIBNewEjQWgGeyAxzVSH8p7Q_5Dmr75dHsKyfdoAL82rwCsL_9MwJnQAwjNrtQCOoA1JqRzP_KzmgT41ED2AYJ882jppsHHbQntAGIJNIQDO4anVSd0nQIgzvPX686uDh_ty-yEnkbg5W8n2ua5UBF6wglsmmsS-iJHmiIHI2Vgk-2vz5KDbjTLAVBjCSbSlN13bA3RgTE2axe4df1/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-regext-rdap-redacted%23section-6.1>) 
> and the definition of the “redacted” member 
> (https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-redacted#section-4.2 
> <https://secure-web.cisco.com/1iz7wZlK-1QyOwNfVHNW0ittCmdo9GWIFd-Q2pqFf3K2kh7an0wWWPVz-3vr8LI97wirgGHsSvAOPoq6fBvikLu6InzXXCjIG6Nmj_d_dX9-xMcJ8WpKVF1jOgMaTLU8aL1xn7yVCFm3hZKEPKE6gsWehMBye-a7AW_S0LbBtAAqoxln7IkalNDTFrRpa5PYfgnbUOGvFO1TF6RqgeIhkrABzMcMMbgrQUA1V8ImjAfOeBoXxbuPriMtOf_xD_V1m/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-regext-rdap-redacted%23section-4.2>)
>
> 1.Register a versioned identifier for use as an RDAP conformance value.
>
> a.Supporting language in the RFCs
>
> i.RFC 9083
>
> 1.When custom JSON values are inserted into responses, conformance to 
> those custom specifications MUST use a string prefixed with the 
> appropriate identifier from the IANA RDAP Extensions registry 
> specified in [RFC7480]
>
> a.This normative language is contained in the RDAP Conformation 
> section of RFC 9083.  The unique identifier can and should be 
> versioned to support future updates to the extension.  My 
> recommendation is to use a pointed version with the major version set 
> to ‘0’ prior to the draft completing WGLC (e.g., “0_1”, “0_2”, “0_N”). 
>   The RDAP Conformance value specifies the extension and version 
> supported in the response, where the specification defines the 
> prefixes used for the extension URI paths and JSON members, and the 
> prefixes are registered to ensure that there is no conflict with other 
> extensions.  The RDAP Conformance pattern ABNF could be followed:
>
> i.identifier = name “_level_” version
>
> ii.version = DIGIT [ “_” DIGIT ]
>
> b.Plan for draft-ietf-regext-rdap-redacted
>
> i.Registration of “redacted_level_DIGIT_DIGIT”, where the RDAP 
> Conformance value of “redacted_level_0.2” would be changed to 
> “redacted_level_0_2” until it completes WGLC and then would be changed 
> to “redacted_level_1_0”.
>
> -- 
>
> JG
>
>
>
>
> *James Gould
> *Fellow Engineer
> [e-mail] 
> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com 
> <http://secure-web.cisco.com/1h_MeU-fxy9ww_l8QpyWEogFtgpt9pHmJtLD3prIBto2JjdEmAEDhV2TL_M1r3Din4fgET3PRKfP9eJPDwi-TcN491pg3117xwpYoDSWNXe4DKrUjzG6udUzjzGYuv-EtiMnmSWKUV-_ZnOPGV75wPWKTPAxcLpRQANCk9NkthLn2aSZijYXZywHbGVGfg7zHkGHTAFIcN7z6ESQ4ZeypWZOey8SLzuAtg4omZM_tHkv30DIMqiL0vmG8nWYI7B14/http%3A%2F%2Fverisigninc.com%2F>
>
> *From: *James Gould <[e-mail]>
> *Date: *Monday, May 2, 2022 at 9:42 AM
> *To: *"shollenbeck=[e-mail]" 
> <shollenbeck=[e-mail]>, "[e-mail]" 
> <[e-mail]>
> *Subject: *Re: [regext] Extension Prefixes, JSON Values, and URI Path 
> Segments
>
> Scott,
>
> With the potential impacts to draft-ietf-regext-rdap-redacted, I did a 
> review of the referenced RFC language for the Extension Prefixes, JSON 
> Values, and URI Path Segments.  I provide my interpretation embedded 
> below for consideration.  To provide a concrete example of the 
> proposed changes to draft-ietf-regext-rdap-redacted, I list them below:
>
> 1.For the Extension Prefix, I believe that we need to register the 
> “redacted” Extension identifier in the RDAP Extensions Registry 
> instead of the versioned value “redacted_X.X”.
>
> 2.For the RDAP Conformance, as defined in Section 4.1 “RDAP 
> Conformance”, I believe that we can follow the pattern of 
> “rdap_level_0”, but leverage the pointed version number until the 
> draft exits WGLC.
>
> a.Change references of “redacted_0.1” to “redacted_level_0.1”; 
> although I believe we will need to bump it up to “redacted_level_0.2” 
> based on adding the Redaction by Replacement Value Method that will be 
> included in draft-ietf-regext-rdap-redacted-04 .
>
> 3.The “redacted” JSON response member will match the “redacted” 
> extension identifier that will be registered in the RDAP Extensions 
> Registry.
>
> a.The language of RFC 9083 “MUST use a string prefixed with the 
> appropriate identifier from the IANA RDAP Extensions registry 
> specified in [RFC7480].”, I believe the RFC will be met since a 
> registered prefix should be able to be combined with a NULL suffix, 
> meaning the member can match the registered extension identifier. The 
> key is that there are no conflicts with the members returned in the 
> response, which is handled by the registration of the “redacted” 
> extension identifier.
>
> So, the only required changes to draft-ietf-regext-rdap-redacted is 
> the extension identifier registered in the RDAP Extension Registry 
> (“redacted” instead of “redacted_X.X”), and the RDAP Conformance value 
> being changed to “redacted_level_X.X”.  The RDAP response member can 
> remain “redacted”, since it will match the registered extension 
> identifier (e.g., registered prefix with NULL suffix).
>
> -- 
>
> JG
>
> James Gould
>
> Fellow Engineer
>
> [e-mail] 
> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>
>
> 703-948-3271
>
> 12061 Bluemont Way
>
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
> On 4/28/22, 10:27 AM, "regext on behalf of Hollenbeck, Scott" 
> <[e-mail] on behalf of 
> shollenbeck=[e-mail]> wrote:
>
>     Since this topic is coming up in the reverse search discussion, 
> but isn't
>
>     unique to reverse search, I thought it best to start another topic.
>
>     Section 6 of RFC 7480 introduces the concept of "an IANA registry 
> for prefixes
>
>     used in JSON [RFC7159] data serialization and URI path segments 
> (see Section
>
>     8)". "lunarNic" is given as an example in Section 8. I cannot, 
> though, find
>
>     any mention of a MUST when it comes to using these prefixes for data
>
>     structures or URI path segments, though Section 8.1 says this:
>
>     "The extension identifier is used as a prefix in JSON names and as 
> a prefix of
>
>     path segments in RDAP URLs."
>
>     RFC 9083 is more definitive. From Section 4.1:
>
>     "When custom JSON values are inserted into responses, conformance 
> to those
>
>     custom specifications MUST use a string prefixed with the appropriate
>
>     identifier from 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"."
>
> JG – My interpretation is that the registered extension prefixes used 
> in the URI path segments and JSON response members need to be used, 
> but it doesn’t specify the suffix that must be used.  The suffix could 
> be NULL, and therefore the URI path segment and the JSON response 
> members can match the registered extension prefixes.  The reference to 
> “lunarNIC_level_0” looks to be relevant for a rdapConformance value, 
> since the rdapConformance member has the purpose of signaling 
> conformance in the response, and not the names of the RDAP response 
> members themselves.  I believe the goal is to ensure that there is no 
> conflict in URI Path Segments and JSON response members, which is met 
> based on ensuring to use registered extension prefixes, which and I 
> believe most likely will have a null suffix for the path segments and 
> JSON response members.
>
>     Note the use of MUST here. Section 5 of RFC 9082 contains similar 
> text:
>
>     "Custom path segments can be created for objects not specified 
> here using the
>
>     process described in Section 6 of "HTTP Usage in the Registration 
> Data Access
>
>     Protocol (RDAP)" [RFC7480].
>
>     Custom path segments can be created by prefixing the segment with 
> a unique
>
>     identifier followed by an underscore character (0x5F). For 
> example, a custom
>
>     entity path segment could be created by prefixing "entity" with 
> "custom_",
>
>     producing "custom_entity"."
>
> JG – This is not normative and covers a corner case of define a custom 
> object of one that already exists.  Defining a new custom object 
> (e.g., “foo” for the Foo object or “bar” for the Bar object) that 
> doesn’t already exist would not require the use of an underscore 
> character, since there would be no conflict with other path segments.  
> The custom path segment would match the registered RDAP extension 
> identifier.  A custom entity object would not be able to use the path 
> segment “entity”, so instead it differentiates the entity path segment 
> using it’s registered extension identifier prefix.
>
>     After re-reading all of this, my take is that extensions MUST tag 
> new data
>
>     structures and path segments with the prefix that's registered 
> with IANA. That
>
>     means I'm going to have to change the data structures and path 
> segments in
>
>     draft-ietf-regext-rdap-openid (I'm probably going to change the 
> prefixes to
>
>     something shorter to make them a bit less clunky). Other extension
>
>     authors/editors should review their documents and provide their own
>
>     assessments.
>
>     Scott
>
> _______________________________________________
>
>     regext mailing list
>
> [e-mail]
>
> https://secure-web.cisco.com/10mX5xspvc-CplH__kACOPD_MQa73oefUXn9viMqhxjrTvYuTo_t-S7CGnbci1ilq715uayoGpxBTFESCwtUSSzWUMi78Nv4FQfkTsB1MOO6UUM97ePFhV7zZJEmk0lKjItjm799a9SMSdp5Q0Hyfp_sGJDmES9vAI2uRMDbROH-cUeV8EeTbe8nLywXjQOndYdYzCrOCALfOj0sozHZ73hC-GtqysPlWX6PS1P6nVkxuMsRCuAcDcLzDFU0kTTKX/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
>
>
> _______________________________________________
> regext mailing list
> [e-mail]
> 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: [phone]
Web:http://www.iit.cnr.it/mario.loffredo