Hi James,
(Replying to the original mail, but taking into account replies to it
to date as well.)
On Thu, May 05, 2022 at 03:44:01PM +0000, Gould, James wrote:
> 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]
(This text is actually:
When custom JSON values are inserted into responses, conformance
to those custom specifications MUST be indicated by including a
unique string literal value registered in the IANA RDAP Extensions
registry specified in [RFC7480].
But I don't think it makes much difference to your approach.)
> 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.
>
> 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 ]
I think this approach could work in principle, but I don't think it's
in accordance with the current text:
- RFC 7480 has "[t]he extension identifier is used as a prefix in
JSON names and as a prefix of path segments in RDAP URLs", but
under this new approach, that would no longer be the case for
values registered as RDAP conformance values (because they would
not be used as prefixes).
- RFC 9082 has:
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".
But the new extension approach described above would permit a
different model to be used for fields in responses (null suffix),
which is unintuitive/inconsistent. (At least, it would be
surprising if this extra text in 9082 were intended to lead to a
different outcome for path segments when compared with the text in
9083 about fields in responses.)
- More generally, having a single registry for both RDAP conformance
values and field/path prefixes seems like it could be confusing for
users, especially in the absence of clarifying text. (It's true
that there's a mix at the moment, but that appears to be an
oversight, rather than something done intentionally or something
that should be preserved in the future. There are also no existing
instances of an RDAP conformance value and a path prefix being
registered for a single extension.)
I think this topic is sufficiently unclear that a new clarifying
document should be written (and preferably finalised) before any
document progresses that is not in accordance with a 'strict' reading
of the current text. (Such a reading (IMHO) has the RDAP conformance
value as the extension identifier in the IANA registry, with that
identifier used as-is as a prefix for new path segments and fields
defined by the extension.) That new document could e.g. set out the
approach you have described above, though possibly with a separate
registry for path segment and field prefixes to avoid any potential
confusion in that respect, and it could also amend relevant entries in
the existing registry so that they become valid.
-Tom
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
