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.
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.
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".
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.
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]".
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..
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?
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.
_______________________________________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org
