From: Gould, James <[email protected]> Sent: Tuesday, May 24, 2022 4:37 PM To: [email protected]; [email protected] Cc: Hollenbeck, Scott <[email protected]>; [email protected] Subject: Re: Re: [regext] Extension Prefixes, JSON Values, and URI Path Segments
Approach A – “tight coupling” and Approach B “lack of tight coupling “ treats the RDAP Conformance value not as hint to the specifications used in the construction of the response, as defined in section 4.1 of RFC 9083, but instead as defining the prefix value of the extension elements (URI path segments, JSON response members, and objectClassName values). My read of the RDAP Conformance is that version is material and there doesn’t need to be any direct link between the literal values in the RDAP Conformance with the prefixes used for the extension elements. If the versioning of the RDAP Conformance needed to cascade down to the extension elements, why didn’t the base RDAP RFCs cascade the version “rdap_level_0” down to all the base RFC elements? What would happen if a new version of RDAP was created, with the RDAP Conformance value of “rdap_level_1”, should all of the RFC elements embed the version “_1” version as well, as in “domain_1”, “domains_1”? I believe the answer is “no”. The example provided for the fictional registry of the Moon is “lunarNIC_level_0” and not simply the prefix “lunarNIC”. We already have examples of pure RDAP Conformance literals that don’t relate to extension element prefixes with the RDAP profile identifiers, which certainly have value to the client. [SAH] The authors of 9083 believe that the “lunarNIC_level_0” example is an error. It should be “lunarNIC” so that the IANA-registered value, the rdapConformance value, and the prefix used in examples is consistent. We’re currently looking at everything that needs to be documented as errata; this will be one of the items. My recommendation is to separate the RDAP Conformance values from the registration of the prefixes used for the extension elements, which can be registered separately for uniqueness. We get full version signaling in the RDAP Conformance member and we get full support for a mix of extension elements that are registered for uniqueness. I don’t see a compliance issue with the language in the RDAP RFCs with Approach C taken in draft-ietf-regext-rdap-redacted and I don’t see any technical issues that will impact the client by having a versioned RDAP Conformance registration (“redacted_level_0_3” with a future value of “redacted_level_1”) and a registration of the “redacted” member that is used in the JSON response. Does anyone see any explicit compliance issues or technical issues with this? [SAH] See above. Scott
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
