Andy, As it relates to the Bare Extension Identifiers in section 2.4.5 of draft-ietf-regext-rdap-extensions. There was much discussion on the mailing list related to what is being called a “bare extension identifier” in RFC 9537, where the extension identifier is functioning as a namespace to address name collision. If there is the use of a single JSON name for the extension (e.g., “redacted” for RFC 9537), the ‘_’ does not add any value. Section 2.4.5 of draft-ietf-regext-rdap-extensions could make that clarification of the non-use of the separator, which is not defined as a MUST in RFC 9083, so technically it does not represent a compliance issue and does not require an update to RFC 9083. Below are examples of bare values defined in existing RDAP extensions:
1. “count”, “sort”, “cursor” query parameters in RFC 8977, but there is no registered extension identifier for these. Should query parameters include the use of an extension identifier prefix to ensure there is no name collision? 2. “redacted” JSON name in RFC 9537 that matches the “redacted” extension identifier. 3. “role”, “handle”, “fn”, “email” query parameters in RFC 9536, but these query parameters are only used with the “reverse_search” path segment, so there is no namespace collision issue. Adding a new request type of an existing object, such as what has been done with “reverse_search” is an interesting form of extension that could be captured explicitly in draft-ietf-regext-rdap-extensions. 4. “fieldSet” query parameter in RFC 8942, but there is no registered extension identifier for it. Same question with the need for an extension identifier prefix for query parameters in #1 above. 5. “versioning” that is used in combination with “versioning_help” (currently “versioning-help”, but it will be updated in -02) in draft-ietf-regext-rdap-versioning. Should the “versioning” member be named something like “versioning_data” to go along with “versioning_help”? 6. “extensions” media type parameter in draft-ietf-regext-rdap-x-media-type. Does draft-ietf-regext-rdap-x-media-type represent another form of RDAP extension with the need for a registered extension identifier for inclusion in the rdapConformance of the help response? Should the extension identifier further be used as a prefix with the media type parameter, similar to other extension values? 7. “jscard” in draft-ietf-regext-rdap-jscontact, which matches the use case of RFC 9537 of having a single JSON name for the extension identifier. Would setting the JSON name to “jscard_data” add value? 8. “ips”, “autnums”, “ipSearchResults”, “autnumSearchResults” in draft-ietf-regext-rdap-rir-search, where “ips” and “autnums” is used in the path segment and “ipSearchResults” and “autnumSearchResults” is used for JSON names. Should the path segments and the JSON names include the use of an ‘_”, where each of these values are registered as seperated extension identifiers. We discussed this in detail on the mailing list and came to consensus to use the “bare extension identifier” values, which makes sense but doesn’t follow the guidance in RFC 9083. In reviewing the bare values above, I don’t believe that there is a compliance issue with RFC 9083, but that draft-ietf-regext-rdap-extensions can provide the clarification. It may be easiest to provid the guidance, where if there is a single extension value (path segment, query parameter, JSON name, HTTP header or HTTP header parameter, JSON member value, etc.) for the extension identifer, the ‘_’ separator is not needed. The guidance in RFC 9083 holds when there is the need for more than one value, so draft-ietf-regext-rdap-versioning can be updated to use the ‘_’ separator for the second possible JSON name value (change “versioning” with “versioning_data”. -- JG [cid87442*image001.png@01D960C5.C631DA40] James Gould Fellow Engineer jgo...@verisign.com<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: "Andrew Newton (andy)" <a...@hxr.us> Date: Monday, October 7, 2024 at 6:40 AM To: "Hollenbeck, Scott" <shollenb...@verisign.com>, "regext@ietf.org" <regext@ietf.org> Subject: [EXTERNAL] [regext] Re: Comments Regarding draft-ietf-regext-rdap-extensions-04 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. On 10/3/24 10:57, Hollenbeck, Scott wrote: On 10/2/24 11:06, Hollenbeck, Scott wrote: I've read draft-ietf-regext-rdap-extensions-04 completely and have several comments to share. An overarching comment is that any update to Standard 95 responses means that the modified responses will not be consistent with "rdap_level_0". A new identifier will be needed. I'd very much prefer to avoid updates to Standard 95 unless there's an absolute necessity to do so. This draft does not change the RDAP data model and all updates are either backwards compatible and/or codify existing practices, many of them made by this working group. As there are no changes to the RDAP data model and this draft is dealing with extensions and not the core of RDAP, can you provide specific examples of these inconsistencies? [SAH] The data model might not be changing, but that’s not the only consideration. Recall this sentence from Section 4.1 of RFC 9083: “The string literal "rdap_level_0" signifies conformance with this specification”. It doesn’t say anything about the data model. I interpret that sentence to mean that if RFC 9083 changes, “rdap_level_0" continues to signify conformance with RFC 9083, NOT with whatever updates it. Also, I'd like to point out that this working group has not updated "rdap_level_0" even when making changes to the core RDAP data model, as the move from PS to IS did in fact change the core RDAP data model but did not change the identifier. With regard to interoperability between a client and a server, what is changing that is incompatible? What core RDAP JSON or query is changing? Can you provide specific examples? This document updates the core RDAP specs for two reasons: 1) they define the rules around extension registrations, many of which this working group has repeatedly broken, and 2) there are areas of those documents concerning extensions that are very ambiguous. But this document changes nothing with regard to current interoperability between a client and server. Also, changing that identifier signals a new version of the protocol, which this is not, and introduces an incompatibility with any current software that relies on it. I don't know the extent of that incompatibility, but I suspect at the very least many conformance tools will break. Section 2.3.1: "This document updates [RFC9082] to allow the usage of extension identifiers as path segments which may have child path segments" What's the rationale for this proposed change? It's not a clarification. It is specifically allowing something that is not specified in RFC 9082, and that some extensions may want to utilize when formulating RESTful URLs. Is there a specific issue with it? [SAH] I’m not a fan of any change to 9082 that allows something that’s described as a prefix to be used as something other than a prefix. It can cause confusion. Looking at the example in the draft, absent the underscore there’s nothing that identifies “foobar” as an extension identifier when used to create a “foobar/fizz” path segment. Is a server supposed to guess that it might match a “foobar_” extension? Explicit pattern matching seems safer to me. The text of the draft says the extension identifier IS the path segment. There is no guessing needed, I am not sure how that is confusing. If you can provide clearer text, that would be welcomed. Also, this is already something this working group has approved of in an extension: https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-rir-search-09#name-path-segments-2<https://secure-web.cisco.com/1H0-rFgvp1EYJOPnchCb2n9JDfjS0hlCHzr0OFlebdWsAkHpqGGkqJJt9cnqzmsH-BiyS8tq5cSSj9qQnAXQ8rc9Tn4LAIhgCeQiOVASOC5oL2G_c3eEdX84-iIgvyH2nlub6N1Hi_Y1pDMLZCgPnmHP4-nMCll38OMPyyC1CjrtAmIB5Gz2dFbc8C_al7yz1lIwjcVtKyh1kOWqSiJZfvjMMWgBEaZ2lGFapt9zxvDwIa6Dh_MpJcjkRoqm4FmWeQywVxGQE0Isgq1F8KKno45KUBw7rwV9XMvKF9mYGBlHaWKEp01jjU40BfIIYh56z/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-regext-rdap-rir-search-09%23name-path-segments-2> 2.4.5: "That is, the extension identifier is used "bare" and not appended with an underscore character and subsequent names" and "Usage of a bare extension identifier contravenes the guidance in [RFC9083]. This document updates [RFC9083] to explicitly allow this pattern." There are extensions that violate 9083, so we should update 9083? It would be far more appropriate to update the extensions that violate 9083.. To be honest, I agree that this should have never happened. But this type of violation has been committed by this working group, RFC 9537 being an example. And while RFC 9537 has many interoperability issues, practically speaking this isn't one of them. In practice, this does not appear to be harmful so it seems impractical to relitigate the issue and to open up all the violating extensions. Do you feel otherwise? [SAH] I’d feel better about fixing the extensions than I do about changing RDAP to legitimize them. Technical errata could be submitted to note the violations, and the errata could be held for document updates. The changes necessary for this cause interoperability problems and would require obsoleting and replacing those RDAP extensions. Is that what you are advocating for? Because that seems terribly disruptive for something that is not a known technical issue. -andy
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
