From: Gould, James <[email protected]> Sent: Wednesday, May 25, 2022 8:49 AM To: Hollenbeck, Scott <[email protected]>; [email protected]; [email protected] Cc: [email protected] Subject: Re: [regext] Extension Prefixes, JSON Values, and URI Path Segments
Scott, If the authors of 9083 feel that “lunarNIC_level_0” should be the prefix value “lunarNIC” instead of a versioned literal, then I’m confused on the true purpose of the RDAP Conformance member. If the RDAP Conformance member is meant to signal the use of a namespace prefix and not a versioned literal, then why didn’t the base RFC RDAP Conformance value (“rdap” instead of “rdap_level_0”) and RFC elements (“rdap_domain” instead of “domain”) follow the same pattern? [SAH] The values described in the RDAP specifications aren’t extensions. As such, the extension mechanisms aren’t applicable. Changing the purpose of the RDAP Conformance values would invalidate the use of the literals registered for the RDAP profile. [SAH] No, it wouldn’t. The RDAP profile doesn’t register extension elements. If there is consensus to define the RDAP Conformance as containing only prefixes to ensure the consistency of values, then the RFC 9083 normative sentence below needs to be revised to change “string literal value” to “prefix”: When custom JSON values are inserted into responses, conformance to those custom specifications MUST be indicated by including a prefix value registered in the IANA RDAP Extensions registry specified in [RFC7480 <https://datatracker.ietf.org/doc/html/rfc7480> ]. I believe it’s best for the RDAP Conformance to reflect a versioned literal at the level of the extension specification to indicate to the client what version of the extension is supported instead of attempting to define the extension namespace prefixes. The RDAP Extension Registry can ensure the uniqueness of the prefixes and contain the list of versioned extension literals. This should be handled by the definition of draft like the RFC 3735 “Guidelines for Extending the Extensible Provisioning Protocol (EPP)” that is focused on all the forms of RDAP extensibility (e.g., object extensibility, request and response attribute extensibility, policy signaling). I don’t believe the base RFCs thought through the extensibility deep enough to tweak via errata. [SAH] The registered prefix/identifier can in fact contain version information. That’s exactly what I’m doing in the federated authentication draft. I agree that this all needs to be clarified. The first step is to document the areas that require clarification as errata. Then we write a draft that addresses the errata. -- JG James Gould Fellow Engineer <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> [email protected] 703-948-3271 12061 Bluemont Way Reston, VA 20190 <http://verisigninc.com/> Verisign.com From: "Hollenbeck, Scott" <[email protected] <mailto:[email protected]> > Date: Wednesday, May 25, 2022 at 8:07 AM To: James Gould <[email protected] <mailto:[email protected]> >, "[email protected] <mailto:[email protected]> " <[email protected] <mailto:[email protected]> >, "[email protected] <mailto:[email protected]> " <[email protected] <mailto:[email protected]> > Cc: "[email protected] <mailto:[email protected]> " <[email protected] <mailto:[email protected]> > Subject: RE: Re: [regext] Extension Prefixes, JSON Values, and URI Path Segments From: Gould, James <[email protected] <mailto:[email protected]> > Sent: Tuesday, May 24, 2022 4:37 PM To: [email protected] <mailto:[email protected]> ; [email protected] <mailto:[email protected]> Cc: Hollenbeck, Scott <[email protected] <mailto:[email protected]> >; [email protected] <mailto:[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
