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

["Hollenbeck, Scott" <[e-mail]>]

> -----Original Message-----
> From: Jasdip Singh <[e-mail]>
> Sent: Thursday, April 28, 2022 12:51 PM
> To: Hollenbeck, Scott <[e-mail]>; [e-mail]
> Subject: [EXTERNAL] Re: [regext] Extension Prefixes, JSON Values, and URI
> Path Segments
>
> 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.
>
> Hello Scott,
>
> Please find my comments below.
>
> Thanks,
> Jasdip
>
> P.S. Thanks to Tom for his analysis of all current extensions. :)
>
> On 4/28/22, 10:27 AM, "regext on behalf of Hollenbeck, Scott" <regext-
> [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"."
>
>     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"."
>
>     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.
>
> [JS] Want to test-drive the phrase "new data structures and path segments "
> in the "extensions MUST tag new data structures and path segments with
> the prefix that's registered with IANA" suggestion. :)
>
> A new data structure could be an entirely new object class (e.g. for a 
> session
> in RDAP OpenID), or a change in the member set for an existing object class
> (say, for a domain). Is it correct to assume that for the former, the 
> extension
> prefix would be applied to the overall object name (e.g. "< RDAP OpenID
> extension>_session") in the response whereas for the latter, only the new
> members would be prefixed with the extension identifier (including
> version)?

[SAH] That seems like a reasonable interpretation.

> As for using a new extension in a related new path segment (e.g. for reverse
> search), we seem ok with having path segments like ".../<new
> extension>_0/...", ".../<new extension>_1/...", and so on for each
> subsequent new version of that extension and not concerned about
> inadvertently introducing "brittleness" in URLs for RDAP clients. Right?

[SAH] That "brittleness" is what causes me concern. In theory, it should help 
eliminate surprises. Without these tags, the same path segment might return 
different results depending on whether an extension is supported by a server 
or not.

> Since this subject has engendered discussion/confusion over time, looks like
> a good idea to detail it further in a new doc.

[SAH] That's probably a good idea, Jasdip. Let us know when you have the first 
draft out there... 😊

Scott