Sorry, but I still don’t see the problem. If the value in the rdapConformance structure tells the client “this is the set of specifications that I conform to”, and the client uses those values to identify and interpret what it sees in a response, I don’t see the need to treat those values as anything more than opaque identifiers. If I’m missing something, please provide some examples to illustrate what works, and what doesn’t.
Scott From: Mario Loffredo <[email protected]> Sent: Wednesday, May 25, 2022 2:22 PM To: Hollenbeck, Scott <[email protected]>; Gould, James <[email protected]>; [email protected] Cc: [email protected] Subject: [EXTERNAL] Re: [regext] Extension Prefixes, JSON Values, and URI Path Segments Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Scott, I'm concerned about injecting the version information into prefixes/identifiers as I see some drawbacks in dealing with non-breaking changes, which hopefully should be the majority and usually don't require to manage a deprecation process. For example, introducing a new property into a response extension would result in returning the same information twice (e.g. the response field "ext1_..." and response field "ext2_..." resulting from adding the new property to "ext1_..") . To ensure interoperability, both the response fields should coexist for a period time so that the RDAP server could manage the sunset and then the deprecation of "ext1_..." as smoothly as possible. Furthermore, according to a largely used best practice in versioning REST APIs, breaking changes should always result in a change to the major version number while non-breaking changes, such as adding new endpoints or new response parameters, do not require a change to the major version number. Unfortunately, injecting the version information into the prefixes/identifiers means that every change would break the RDAP server and would result in a change of the major version number !?!? Really, this doesn't make sense to me. Think the RDAP mechanism to implement and signal extensions should take vantage from an RDAP server being a REST service that returns a JSON (schemeless) content and, as such, it is possible to make many changes without breaking the REST contract with the client and forcing the server to manage a deprecation process even when it is unnecessary. Hope it could be helpful to evaluate the various approaches on the table from a practical perspective. Best, Mario Il 25/05/2022 16:41, Hollenbeck, Scott ha scritto: From: Gould, James <[email protected]><mailto:[email protected]> Sent: Wednesday, May 25, 2022 10:23 AM To: Hollenbeck, Scott <[email protected]><mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> Subject: Re: [regext] Extension Prefixes, JSON Values, and URI Path Segments Scott, My comments are embedded below with a “JG – “ prefix. -- 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://secure-web.cisco.com/1Az2HSHZzGvgHEbROH_s70GCP3M6srHu4FX8TLyhKJ17_Gm-TRcGNUQYsvf0t-i8UHQRK2btIQNCg82vDjo_gUx6uppYT0yEqRdz-ZrqGTnMhmCC1Y-DRMWhPYlUM4M6nrtKG2CPvNfYQffzydyc00qjV2QCnsvRZ7YffQAOcCKd_-P7XZLxy6DLHXFt-pleKpGO_WOZb-z7gWt-DCr4GxLJdCs5xmgB-E1gJj37YzWpFrHeGR3s8D2GrTpgEMD_H/http%3A%2F%2Fverisigninc.com%2F> From: "Hollenbeck, Scott" <[email protected]<mailto:[email protected]>> Date: Wednesday, May 25, 2022 at 9:10 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: [regext] Extension Prefixes, JSON Values, and URI Path Segments From: Gould, James <[email protected]<mailto:[email protected]>> Sent: Wednesday, May 25, 2022 8:49 AM To: Hollenbeck, Scott <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[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. [SAH] “RDAP conformance” is intended to identify the specification(s) associated with elements found an in RDAP response. That’s why the registry of values includes identification of the associated specification. 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. [SAH] Yes, the values should be registered. Including them in the rdapConformance section of an RDAP response describes how that response was formed. There’s value in that even if the response doesn’t contain any 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://secure-web.cisco.com/1RCKIrI_F7eR2CYGPEmtkdJIKaZSD4Cpyx2o6sLHRktKXb_kKx4Hu1eGxxfbzU9PqGNKtmS55BRDNtL3mm5HLkDwg8w7GKI8C8EXwzybNznbU6IIfRm9Kj-SE8tptqLgCaZ8F6sgp12cQwdUTfz2-NSsK0fbfSMNwoG2A-66M5e6VSaJMK2CojsXOgIKRPIYWngV3PXsBdRuPVAUsJAxCALUah5LxiNxHEc0Kc_OQ3n4ei6cWascyLPmVKxgFu_Ps/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7480>]. 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. [SAH] I can only say that I disagree. There’s more value in consistency and simplicity. It makes life *much* easier for a client if the value registered with IANA is the same value that’s used to identify extension elements. If changes are made in the future, you just need to register a new value. 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 [email protected]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://secure-web.cisco.com/1Az2HSHZzGvgHEbROH_s70GCP3M6srHu4FX8TLyhKJ17_Gm-TRcGNUQYsvf0t-i8UHQRK2btIQNCg82vDjo_gUx6uppYT0yEqRdz-ZrqGTnMhmCC1Y-DRMWhPYlUM4M6nrtKG2CPvNfYQffzydyc00qjV2QCnsvRZ7YffQAOcCKd_-P7XZLxy6DLHXFt-pleKpGO_WOZb-z7gWt-DCr4GxLJdCs5xmgB-E1gJj37YzWpFrHeGR3s8D2GrTpgEMD_H/http%3A%2F%2Fverisigninc.com%2F> 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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/regext<https://secure-web.cisco.com/1byPhl1rtImLOuxnRRye2TYPXPXUPWIiWj9Ws4ztRYL1elI-CSsoIL7JsnG1qSMIQ7XP767dLLG7SZYzYPmYQb8bMI3apxxUyb5sfchV_b9RZkFF0d9Ow62-6PL5vbZyZjsRIcN_8GM9veoI-wOxFeGzpZkPQTmayzzFNm6ATpuafGzo74EtMh8o_Wi4lILbgvFKICFSIlxPazKzDBjG5pZZ6w07z_HFdxxZ2X8choTw9g81vfBsVI0ZXnpRju3Ob/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext> -- Dr. Mario Loffredo Technological Unit “Digital Innovation” Institute of Informatics and Telematics (IIT) National Research Council (CNR) via G. Moruzzi 1, I-56124 PISA, Italy Phone: +39.0503153497 Web: http://www.iit.cnr.it/mario.loffredo<http://secure-web.cisco.com/1SLzKuU3jEmu1rAIFnKD256HyjU4Cu4YzZ-ZfRjXTXHaucCPKE7p5YfA6m9Tc4DukKcIGLfYr4yGbqWXJ3_PycSt4s4c1wOPO4CFaRFueTUj5h-PpDo7k3Wcw7_cK7XYyktJJKLuodMQggk0l0wiayDeatSiN_OvbViPaZrz3IElLoSZkHm5PibpwubJa0skxzpu6kBXCFKKFtSW5E23ndISeiXsHsrRsCdBJ2EeYgrLXtr3lSWIK6utL0t9AzUll/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo>
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
