> 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. I also support excluding the version information from the paths and field names as a mandatory requirement. If an extension provides successive version which would break the REST API contract it can always choose to include the version number to make a field distinct from the previous number (so as an MAY, not MUST). Kind Regards, Pawel On Tue, 10 May 2022 at 10:05, Mario Loffredo <mario.loffr...@iit.cnr.it> wrote: > 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" <jgo...@verisign.com> <jgo...@verisign.com> > *Date: *Friday, May 6, 2022 at 9:25 AM > *To: *Jasdip Singh <jasd...@arin.net> <jasd...@arin.net>, > "regext@ietf.org" <regext@ietf.org> <regext@ietf.org> <regext@ietf.org> > *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 > jgo...@verisign.com > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com <http://verisigninc.com/> > > > > *From: *regext <regext-boun...@ietf.org> <regext-boun...@ietf.org> on > behalf of Jasdip Singh <jasd...@arin.net> <jasd...@arin.net> > *Date: *Thursday, May 5, 2022 at 6:45 PM > *To: *"regext@ietf.org" <regext@ietf.org> <regext@ietf.org> > <regext@ietf.org> > *Subject: *[EXTERNAL] Re: [regext] Extension Prefixes, JSON Values, and > URI Path Segments > > > > Hello James, > > > > Please find my comments below. > > > > Thanks, > > Jasdip > > > > *From: *"Gould, James" <jgo...@verisign.com> <jgo...@verisign.com> > *Date: *Thursday, May 5, 2022 at 2:46 PM > *To: *Jasdip Singh <jasd...@arin.net> <jasd...@arin.net>, > "regext@ietf.org" <regext@ietf.org> <regext@ietf.org> <regext@ietf.org> > *Subject: *Re: Re: [regext] Extension Prefixes, JSON Values, and URI Path > Segments > > > > > > *From: *regext <regext-boun...@ietf.org> <regext-boun...@ietf.org> on > behalf of Jasdip Singh <jasd...@arin.net> <jasd...@arin.net> > *Date: *Thursday, May 5, 2022 at 1:53 PM > *To: *"regext@ietf.org" <regext@ietf.org> <regext@ietf.org> > <regext@ietf.org> > *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 <regext-boun...@ietf.org> <regext-boun...@ietf.org> on > behalf of "Gould, James" <jgould=40verisign....@dmarc.ietf.org> > <jgould=40verisign....@dmarc.ietf.org> > *Date: *Thursday, May 5, 2022 at 11:44 AM > *To: *"shollenbeck=40verisign....@dmarc.ietf.org" > <shollenbeck=40verisign....@dmarc.ietf.org> > <shollenbeck=40verisign....@dmarc.ietf.org> > <shollenbeck=40verisign....@dmarc.ietf.org>, "regext@ietf.org" > <regext@ietf.org> <regext@ietf.org> <regext@ietf.org> > *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 > jgo...@verisign.com > > 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 <jgo...@verisign.com> <jgo...@verisign.com> > *Date: *Monday, May 2, 2022 at 9:42 AM > *To: *"shollenbeck=40verisign....@dmarc.ietf.org" > <shollenbeck=40verisign....@dmarc.ietf.org> > <shollenbeck=40verisign....@dmarc.ietf.org> > <shollenbeck=40verisign....@dmarc.ietf.org>, "regext@ietf.org" > <regext@ietf.org> <regext@ietf.org> <regext@ietf.org> > *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 > > jgo...@verisign.com > <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/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/> <http://verisigninc.com/> > > > > On 4/28/22, 10:27 AM, "regext on behalf of Hollenbeck, Scott" > <regext-boun...@ietf.org > on behalf of shollenbeck=40verisign....@dmarc.ietf.org> > <regext-bounces@ietf.orgonbehalfofshollenbeck=40verisign....@dmarc.ietf.org> > 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 > > regext@ietf.org > > > 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 listregext@ietf.orghttps://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 >
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
