Tom, Thank you for your thoughts on the proposal. I include my responses embedded below prefixed with "JG - ".
-- JG James Gould Fellow Engineer jgo...@verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 5/17/22, 8:56 AM, "Tom Harrison" <t...@apnic.net> wrote: 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.) JG - Thanks for the correction. Agreed it doesn't make a difference with the proposal. > 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). JG - A registered value is a prefix but with a null suffix. The only formal definition of the name in RFC 7480 is the ABNF name = ALPHA *( ALPHA / DIGIT / "_" ), which does not require the use of the underbar. - 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.) JG - This language from RFC 9082 is not normative and provides an example of defining a custom "entity" path segment, which would conflict with the existing "entity" path segment without the use of the prefix. The registration of the prefix will ensure uniqueness of the use of the prefix across the extensions, where adding a non-null suffix can be used if and when there is a conflict. 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. JG - I agree, it looks like there is the need for a clarifying document to address this. There will be no conflict with other entries in the registry, since a unique versioned identifier is registered for the RDAP conformance, and a unique prefix is registered for use by the path segments and the fields. Use of a null suffix doesn't impact the uniqueness of the registration of the prefixes. The registrations include a reference to the specification that fully defines the use of the registered value. The registry addresses the uniqueness of the identifiers and prefixes, and the specification addresses the usage of the registered identifiers and prefixes with the inclusion of the set of suffix values. -Tom _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
