Andy, I view updating the base RFCs as being a material change that would trigger the need for signaling for interoperability via use of “rdap_level_1”. If what is defined maintains backward compatibility with what is defined in the base RFCs, then can a case be made for not having to update them? I don’t believe we can have it both ways.
I’m in the middle of re-reviewing draft-ietf-regext-rdap-extensions and a good point is made related to the forms of RDAP extensions supported by the base RFCs, based on section 2.3.2 “Usage of Query Parameters”. RFC 7480 with “used in JSON [RFC7159<https://datatracker.ietf.org/doc/html/rfc7159>] data serialization and URI path segments”, RFC 9082 with “Custom path segments can be created for objects not specified here using the process described in Section 6<https://www.rfc-editor.org/rfc/rfc7480#section-6>of "HTTP Usage in the Registration Data Access Protocol (RDAP)<https://datatracker.ietf.org/doc/html/rfc7480>" [RFC7480<https://datatracker.ietf.org/doc/html/rfc7480>]”, and RFC 9083 with “The full JSON name (the prefix plus the underscore plus the meaningful name) SHOULD adhere to the character and name limitations of the prefix registry described in [RFC7480<https://datatracker.ietf.org/doc/html/rfc7480>]”, but does the lack of definition implicitly prohibit other forms of RDAP extensibility that we know of and that could be defined in the future? Could draft-ietf-regext-rdap-extensions be used to define all forms of RDAP extensibility formally without requiring an update to RFC 9083 and trigger the definition of “rdap_level_1”? I see 5 forms of extensibility that RFC 9083 only references two of the forms: 1. Path Segment * Path segment for defining a new object in the request, which is covered by RFC 7480 and RFC 9082. 2. JSON Names * JSON names for defining new members in the response, which is covered by RFC 7480 and RFC 9083. 3. Query Parameters * Query parameters for defining new request preferences and features, which is NOT covered RFC 7480 and RFC 9082. Many RDAP extensions have leveraged extensibility of query parameters, including RFC 8982, RFC 8977, RFC 9560, draft-ietf-regext-rdap-versioning, 4. HTTP Headers * HTTP headers for defining new request preferences and features, which is NOT covered RFC 7480 and RFC 9082. The draft-ietf-regext-rdap-x-media-type draft leverages extensibility of HTTP headers. 5. “objectClassName” Member Value * Value of the “objectClassName” member for defining a new object in the response, which is NOT covered RFC 7480 and RFC 9083. I haven’t see this form of extensibility in a published extension, but it certainly would be needed if the path segment was extended to support a new object. Are there other forms of RDAP extensibility that should be considered and formally defined? Potentially draft-ietf-regext-rdap-extensions could define a framework for extending the forms of extensions, since it will hard for us to look in the crystal ball to enumerate all possible forms of extensibility now. -- 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: Thursday, October 3, 2024 at 8:19 AM To: "Hollenbeck, Scott" <shollenbeck=40verisign....@dmarc.ietf.org>, "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/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? 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. Section 2.2: The text notes that "RDAP extension identifiers have no explicit structure, and are opaque insofar as no inner-meaning can be "seen" in them". It then goes on to say that "RDAP extensions MUST NOT define an extension identifier that when prepended to an underscore character may collide with an existing extension identifier. For example, if there were a pre-existing identifier of "foo_bar", another extension could not define the identifier "foo"." If the values are opaque and without meaning, why is there a need to prohibit identifiers that reuse some of the same characters found in an existing extension identifier? That's assigning meaning to the identifiers. I'm a little worried that this text would preclude registration of identifiers like "dns_foo" and "dns_bar", even though they clearly don't collide. The need to prohibit registrations that are subsets of existing registrations is to avoid collisions. If "foo_bar" were an existing registration and then "foo" is registered, it might define "foo_bar" as a JSON name thus causing a collision. If there is a flaw in any of the logic in this section, can you please elaborate? Section 6 of RFC 7480 describes the syntax specification for extension identifiers. It notes that they "consist of the alphabetic US-ASCII characters A through Z in both uppercase and lowercase". The last paragraph of Section 2.2 says that "This document updates the formulation in [RFC7480] to explicitly note that extension identifiers are case-sensitive, and extension identifiers MUST NOT be registered where a new identifier is a mixed-case version of an existing identifier". That's not a change to the syntax specification, though. The ABNF isn't changing. It's a suggested clarification of the registration policy, and would be a better fit in Section 6.1 where guidance is given to the reviewers and current text notes that "RDAP clients SHOULD match values in this registry using case-insensitive matching". That is a good point. I think some of this did not get corrected during clean up. I have put this in the issue tracker: https://github.com/anewton1998/draft-regext-rdap-extensions/issues/33<https://secure-web.cisco.com/1SCG0EdHH5vwZzAv3lIqF69h-7AtEQ1nii3jzbyVuxkk7A0KBHDpHBNg67ADpUu7dxEfXJxS6s37mix-bmrzcr0eQZQi8BdhMUn_jmZQ21Zb4_SGpszrsLWYRsiOKIxPJmgZO9UL6RQkkaTQcy4ZjDlUU2crWZuDRwwFCWo3xj8Clq3o_ufWIhjiunlV2MZy7mF8wOJmNna-pkd1MIVBl8DauI392imciU0XoysBEVzE4TrQkCpVieimeOE_iYPJRaF-uVQXi_vsDyc5ZuZC-_5bIfGZpAh5l_OBtpAm67ovXZILgp-qUVYRpkrg-ZnYx/https%3A%2F%2Fgithub.com%2Fanewton1998%2Fdraft-regext-rdap-extensions%2Fissues%2F33> 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? Section 2.3.2: "Therefore, the use of query parameters, whether prefixed with an extension identifier or not, is not supported by [RFC9082] and [RFC7480]". I don't agree with this. Query parameters/strings are a standard feature of URIs, and are incorporated through normative references to RFC 3986. If an extension describes a use case that includes query parameters/strings, that should be sufficient to ensure that they're not unknown, eliminating the concern described in 7480. Since 7480 and 9082 don't explicitly prohibit query parameters in extensions, it's incorrect to say that they're "not supported by [RFC9082] and [RFC7480]". They may be a standard feature of URIs, but to avoid collisions with parameters defined by multiple extensions there needs to be guidance. Otherwise two extensions may define the value "foo". Also, I don't agree that they are automatically incorporated by reference as RFC 7480 does explicitly mention query parameters but not in this manner. That would also bring up questions about how URI fragments are meant to be handled. 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? 2.4.6: "A strict interpretation of this wording where "construction of the response" refers to the JSON structure only would rule out the use of Section 2.1.1 extension identifiers, which are in common use in RDAP.", and "For responses to queries other than "/help", a response MUST include in the "rdapConformance" array only those extension identifiers necessary for a client to deserialize the JSON and understand the semantic meaning of the content within the JSON, and each extension identifier MUST be free from conflict with the other identifiers with respect to their syntax and semantics." I'm a little confused by the text in this section. Is it saying the profile identifiers should be included in the "rdapConformance" array, or not? Profile identifiers do serve a valuable purpose in terms of understanding how the response should be interpreted after it's been deserialized ("understand the semantic meaning of the content within the JSON"), so I *think* this text is saying that they MUST be included. Is that the case? Yup, that's confusing... and also somewhat contradictory. This was an attempt to clarify the list discussion about what it means to return extension identifiers in the rdapConformance array for non /help queries. Obviously this needs clean up. As written, this says that only the extensions used to interpret the JSON are to be in rdapConformance. However, the first sentence notes that marker and profile extensions are in common use today, but those don't meet the definition of extensions used to interpret the JSON. I'd like to know what my co-authors think, but I believe this is overly restrictive as extensions influence more than just the JSON... they also indicate what can be queried and semantics of things like links. 6.1: I like the idea of adding additional expert reviewers. As noted above, I'd like to see text added here to say that reviewers should perform case-insensitive matching as part of a review request to be consistent with Section 6.2. Noted. -andy
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
