On 10/3/24 08:26, Gould, James wrote:
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.
See my note to Scott, but these are all backwards-compatible changes. If
there are any incompatibilities, specific examples would be helpful.
Also note that changing "rdap_level_0" to "rdap_level_1" introduces its
own compatibility issue. 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 broken but have caused no harm, 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.
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
1. Path segment for defining a new object in the request, which
is covered by RFC 7480 and RFC 9082.
2. JSON Names
1. JSON names for defining new members in the response, which is
covered by RFC 7480 and RFC 9083.
3. Query Parameters
1. 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
1. 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
1. 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.
That's a very good list. Maybe our summary section of the draft should
do something similar.
I do not understand your suggestion but that maybe lack of imagination
on my part. Doesn't such a framework exist in the form of the REGEXT
working group?
-andy
_______________________________________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org
