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