Hi Jasdip and Scott,
Il 01/05/2022 16:11, Hollenbeck, Scott ha scritto:
-----Original Message-----
From: Jasdip Singh <[email protected]>
Sent: Thursday, April 28, 2022 12:51 PM
To: Hollenbeck, Scott <[email protected]>; [email protected]
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-
[email protected] on behalf of [email protected]>
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.
[ML] It all depends on how the transition from
".../<newextension>_0/..." to ".../<newextension>_1/..." is going to be
implemented.
Path versioning in REST API is a common practice.
Servers should signal the sunset and the deprecation of a path version
and its possible replacement with a new one by using links (as described
for example in RFC8594 and RFC8631) in order to make the transition as
smooth as possible and avoid breaking changes.
This is the approach followed by rdap-jscontact doc.
Mario
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
_______________________________________________
regext mailing list
[email protected]
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: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
