Scott, My comments are embedded below with a “JG – “ prefix.
-- JG [cid:[email protected]] 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/> From: "Hollenbeck, Scott" <[email protected]> Date: Wednesday, May 25, 2022 at 9:10 AM To: James Gould <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Cc: "[email protected]" <[email protected]> Subject: RE: [regext] Extension Prefixes, JSON Values, and URI Path Segments 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. JG – The question is associated with the purpose of the RDAP Conformance. If the intent of the RDAP Conformance is to signal the set of prefixes used in the response in place of the list of extension literals, then the base RFCs should have followed the intent. There is no existing language in the RFCs that requires consistency between the entries in the RDAP Conformance and the prefixes used by the extension. 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. JG – If the RDAP profile doesn’t register extension elements, do the RDAP Profile literals belong in the RDAP Extension Registry? I believe the RDAP Profile literals has value to the client and therefore should be in the RDAP Extension Registry and represented as an entry in the RDAP Conformance, but that would violate the intent of the RDAP Conformance values as prefixes and not versioned literals. 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. JG - Injecting versioning into the extension elements adds brittleness when backward compatible version changes are made. Including the versioning in the RDAP Conformance provides the signaling, and the registered prefixes ensures uniqueness. Artificially linking the two adds brittleness with no perceived value. draft-ietf-regext-rdap-openid would be cleaner by registering “roidc_level_0” for the RDAP Conformance value and a single prefix “roidc” value used for the set of extension elements (“roidc_id”, “roidc_session”, “roidc_iss”, “roidc_session”, “roidc_openidcConfiguration”). The individual extension elements could be registered as well but based on the number and use of something generic like “id”, it may be best to group them using a single prefix. 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 [cid:[email protected]] 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/> 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
