[regext] Re: Comments Regarding draft-ietf-regext-rdap-extensions-04

["Andrew Newton (andy)" <[e-mail]>]

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