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

[Pawel Kowalik <[e-mail]>]

> 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 <[e-mail]>
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" <[e-mail]> <[e-mail]>
> *Date: *Friday, May 6, 2022 at 9:25 AM
> *To: *Jasdip Singh <[e-mail]> <[e-mail]>,
> "[e-mail]" <[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]
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
>
>
> *From: *regext <[e-mail]> <[e-mail]> on
> behalf of Jasdip Singh <[e-mail]> <[e-mail]>
> *Date: *Thursday, May 5, 2022 at 6:45 PM
> *To: *"[e-mail]" <[e-mail]> <[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]> <[e-mail]>
> *Date: *Thursday, May 5, 2022 at 2:46 PM
> *To: *Jasdip Singh <[e-mail]> <[e-mail]>,
> "[e-mail]" <[e-mail]> <[e-mail]> <[e-mail]>
> *Subject: *Re: Re: [regext] Extension Prefixes, JSON Values, and URI Path
> Segments
>
>
>
>
>
> *From: *regext <[e-mail]> <[e-mail]> on
> behalf of Jasdip Singh <[e-mail]> <[e-mail]>
> *Date: *Thursday, May 5, 2022 at 1:53 PM
> *To: *"[e-mail]" <[e-mail]> <[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]> <[e-mail]> on
> behalf of "Gould, James" <jgould=[e-mail]>
> <jgould=[e-mail]>
> *Date: *Thursday, May 5, 2022 at 11:44 AM
> *To: *"shollenbeck=[e-mail]"
> <shollenbeck=[e-mail]>
> <shollenbeck=[e-mail]>
> <shollenbeck=[e-mail]>, "[e-mail]"
> <[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]
>
> 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]> <[e-mail]>
> *Date: *Monday, May 2, 2022 at 9:42 AM
> *To: *"shollenbeck=[e-mail]"
> <shollenbeck=[e-mail]>
> <shollenbeck=[e-mail]>
> <shollenbeck=[e-mail]>, "[e-mail]"
> <[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]>
> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>
>
>
>
> 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" <[e-mail]
> on behalf of shollenbeck=[e-mail]>
> <[e-mail]=[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 [e-mail]://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
>
> _______________________________________________
> regext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/regext
>