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
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
