Tom,
Thank you for your detailed response to help the discussion move forward. I provide my feedback embedded with a "JG - " prefix. I'm pulling the proposal included in the mailing list message (https://mailarchive.ietf.org/arch/msg/regext/GUNzKuVIFx7FHu3DuhS0Nn_zppk/) into this thread for clarity: The draft draft-ietf-regext-rdap-redacted-05 has been posted that implements the proposal on the list for the RDAP Extension Registry registrations, that includes: 1. Registration of a versioned extension identifier that is used for the “rdapConformance” value, which is “redacted_level_0_3” for draft-ietf-regext-rdap-redacted-05. Once draft-ietf-regext-rdap-redacted passes WGLC, the “rdapConformance” value will be updated to “redacted_level_1”. 2. Registration of any URI path segments, JSON response members, and ‘objectClassName” member value prefix identifiers, which can have a null suffix. For draft-ietf-regext-rdap-redacted-05, the “redacted” prefix identifier is registered for use in the JSON response member. * There is a sub-use case for the JSON response, which is the use of the registered prefix identifier for the value of the “objectClassName” member to support new RDAP objects (e.g., “foo” for Foo object). This proposal fully follows the existing RFC language, does not invalidate any existing registrations, supports the registration of a versioned extension identifier, and the registration of unique extension prefix identifiers for URI path segments, JSON response members, and “objectClassName” member values. Clarification in Section 6 and Section 8.1 in an update to RFC 7480 would be helpful. The editors of draft-ietf-regext-rdap-redacted agree with the implementation of the proposal in draft-ietf-regext-rdap-redacted. Thanks, -- 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 5/19/22, 2:35 AM, "Tom Harrison" <[email protected]> wrote: Hi James, On Wed, May 18, 2022 at 11:59:05AM +0000, Gould, James wrote: > On Wed, May 18, 2022 at 09:12:16AM +1000, Tom Harrison wrote: >> The uniqueness aspect of the registry is fine, as is the 'null suffix' >> part. I'm more concerned with the confusing way in which the various >> documents interact in this respect and the fact that two different >> 'types' of values will be registered (advisedly) from now on. > > I don't believe there will be any confusion since the purpose of the > registry is to ensure the uniqueness of the prefixes and identifiers > used by the RDAP extensions and the purpose of the referenced > specification is to define their usage. Having reviewed the relevant text again, I think I know what happened here (which is relevant to what to do next). RFC 7480 has: For extensibility purposes, this document defines an IANA registry for prefixes used in JSON [RFC7159] data serialization and URI path segments (see Section 8). JG - What's interesting is the first normative sentence of the next paragraph states "Prefixes and identifiers SHOULD only consist of...", where an identifier is not formally defined but there is clearly inclusion of both a prefix and an identifier. We have a mix of prefixes and identifiers that exist in the RDAP Extension Registry (e.g., icann_rdap_response_profile_0 as an identifier, rdap_objectTag as a prefix for an identifier in the rdapConformance, paging that is used as a prefix and as an identifier in the rdapConformance). It's unclear whether the registrations are intended to define a namespace or the values that are needed for uniqueness in the URI path segments and JSON response members. I believe attempting to model a namespace in the RDAP Extension Registry for use across all elements defined in the extension is unneeded for REST, but that we only need to ensure that there is uniqueness across the extensions. There is nothing that restricts an extension for registering more than one entry in the RDAP Extension Registry to ensure uniqueness. I believe a versioned identifier for an extension has value for client signaling in the rdapConformance and to decouple the potential set of unique prefixes used for the URI path segments and JSON response members defined by the extension. Later in that document: The purpose of this registry is to ensure uniqueness of extension identifiers. The extension identifier is used as a prefix in JSON names and as a prefix of path segments in RDAP URLs. JG - Agreed, the uniqueness is the key requirement for the extension registrations. Here is a mix of the term identifier and prefix, which needs clarification. Earlier in RFC 7480 it refers to "Prefixes and identifiers", as opposed to simply one form. I see the need for both an identifier for signaling in the rdapConformance, which includes versioning, along with prefixes that are used path segments and response members. Is should be up to the specification to define the set of suffixes (null and non- null) that are used. Clients will not auto discover the prefixes to based on the value in the rdapConformance to match up the accepted set of path segments and the set of response members included in the response. If that was the intent, there would be a much more formal definition requirement in the protocol to support auto-discovery. The reality is that the RDAP Extension Registry is used to define an identifier for the extension and to support the set of unique URI path segment and response members for an extension. Followed by an example registration: Extension identifier: lunarNic Registry operator: The Registry of the Moon, LLC Published specification: http://www.example/moon_apis/rdap Person & email address to contact for further information: Professor Bernardo de la Paz <[email protected]> Intended usage: COMMON lunarNic is not otherwise mentioned in RFC 7480. But RFC 7483 (not 9083) has: 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]. with an example conformance value of "lunarNic_level_0". It then goes on to give example lunarNic fields like "lunarNic_beforeOneSmallStep". For a user looking at this prior to the publication of RFC 9083, it looks like: - the prefix is what is registered as the extension identifier; - if a conformance value begins with the prefix, then the response is in accordance with the corresponding extension; - such a response may contain new fields that begin with the prefix; and - the relevant server may support additional paths that begin with the prefix, per the extension documentation. JG - What you're defining is equivalent to a namespace, which sounds reasonable but doesn't provide value to clients. Does it really matter to a client that an extension has an extension identifier of "foo" that chooses to define the URI path segment "foo_bar" in the specification and a set of response members of the form "foo_member_1", "foo_member_2", and "foo_member_N" in the specification? I see it being more valuable to have a versioned identifier for the extension, such as "foo_level_0" or "foo_level_1" for use in the rdapConformance, along with a set of unique URI path segments and response member prefixes in the registry (e.g., "bar", "member"). Then there is Patrick Mevzek's thread (beginning at https://secure-web.cisco.com/1DXstdAh89074Kv5J3EftnC8Wv2WoD1tegFJDPigzifn5oDjTg41ccK6zo_WOzHBAlxEd4qcnq8tiv8lPwfKATaS9UBH0kTRZCFDdPGyXiaM3dDKWGOnaabG4M7qwdIoSfQYOiAbyJfaEXiRf_lBsYLGWOFYrTu_uy2Dz8YKSBy0156aLoh3pIW7Qmrwg9ebskzST53qGSHrRs2VxOdeELc_WD8Rv6GLiDRa3uer7MKZd5e_V_G-S_C_EwMzmx9eQ/https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fregext%2Fo0o4gpLNOpt5fficODoJr8LP-qM%2F) from 2019, where his understanding is basically per the above, noting some issues with this: - is the text after the prefix in the conformance value free-form? are there any requirements around that text more generally? - if free-form text is permitted, then an extension identifier like "cidr" means that no other extension beginning with "cidr" can be registered, because a client would not be able to distinguish the conformance values: is that intentional? - why do some extensions embed the version in the extension? after which Scott and Andy note that they expect the conformance values to be exact matches for the extension identifiers, and that the same will be addressed in 7483bis (i.e. 9083). That happens by changing the following text in 7483: 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]. such that it becomes: 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 neither 7480 nor the example lunarNic fields in 7483 are updated to suit, leading to the current situation where it appears (at least on one reading) that the conformance value must be used as the prefix. JG - This normative language allows for the registration of a unique version string literal value that is versioned, such as "foo_level_0" or "foo_level_1" for the Foo Extension. There is no requirement in the RFCs that there must be a single prefix value that is used for the rdapConformance and the URI path segment and response member values. I believe it's best for the rdapConformance to support versioning and to enable the registration of zero or more prefixes that are used for the URI path segments and the RDAP response members. If the change in 9083 is considered to be a mistake, and registering prefixes is considered acceptable, then possibly the simplest option is to: - submit an erratum against 9083; - continue registering extensions, but register only the prefixes; and - write a document clarifying all of this, as well as noting conventions around versioning and so on, to avoid some of the problems Patrick raised around namespacing and similar. This has some added benefits: - only one registry is needed; and - the entries in the existing registry are all fine and do not need to be changed (so long as conformance values are permitted to be exact matches for extension identifiers, which doesn't seem to be problematic). It does mean that a given extension is restricted to a single field/path prefix, but I'm not sure that that's a serious problem, or at least I don't think there are any documents pending that are using multiple prefixes. JG - The proposal that I'm making doesn't require touching any of the existing registry entries, which has a mix of identifiers and prefixes. There is no restriction for a given extension to have a single field/path prefix. The latest version of draft-ietf-regext-rdap-redacted includes two RDAP Extensions Registry registrations, with one for the RDAP Conformation ("redacted_level_0_3"), and one for the JSON response member "redacted". An alternative is to only register the prefix "redacted", which is used both for the RDAP Conformation value defined in the specification "redacted_level_0_3" and the JSON response member "redacted". I see no value with including a suffix such as "_data" to form "redacted_data" for the JSON response member, since the suffix can be null based on the ABNF in the RFC 7480. -Tom
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
