From: Andrew Newton (andy) <a...@hxr.us> Sent: Thursday, October 3, 2024 8:19 AM To: Hollenbeck, Scott <shollenb...@verisign.com>; regext@ietf.org Subject: [EXTERNAL] Re: [regext] 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? [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. 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? [SAH] OK, I get it. This, too sounds like guidance for the expert reviewers and should be noted in Section 6.1 as the case variant situation is currently noted. 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/1xdSdjsyIe1Zcc-v1zFYLX51dBSeAHVYvVICgBNZXNGApKaBi3D0kUwXJsE2hvWoh-jpdi2TK1_Vgc7KbS68fiZYtJ-J5dMCEiciRE24ButL7VdPnVbPAmGBY1N_47IYCR0YxwMDzFRKE9O5k7fEEC9rsKnlBUwtNVZrFau_6WuSPm17_YrUiXNfjFlEy4oq3i2KeQkvRbse1fjqT7W0AhDAqU2lksvIy06hlWhkyddtImlPO37HqOxhvkzsAfLp6N49gOc0SSOQR4TgwdizNDrwBmcM_pwGFY78Ng4i-tKDFWLlW5KlPBOAZNK6TfAv5/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? [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. 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. [SAH] If query parameters are prefixed with an extension identifier, we shouldn’t have different extensions defining colliding values. “ext1_foo” and “ext2_foo” would be distinct. 7480 doesn’t explicitly note that extension identifiers can be used to prefix query parameters, though, so I agree that guidance is needed. 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. 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
