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.
* 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.
* 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)
and the definition of the “redacted” member
(https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-redacted#section-4.2)
1. Register a versioned identifier for use as an RDAP conformance value.
* 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 ]
* 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
[cid:[email protected]]
James Gould
Fellow Engineer
[email protected]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com<http://verisigninc.com/>
From: James Gould <[email protected]>
Date: Monday, May 2, 2022 at 9:42 AM
To: "[email protected]"
<[email protected]>, "[email protected]" <[email protected]>
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
[email protected]
<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]>
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"
<[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"."
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
[email protected]
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
[email protected]
https://www.ietf.org/mailman/listinfo/regext
