[regext] Re: draft-ietf-regext-rdap-x-media-type-02 Feedback (on rdap-x media type)

[[e-mail]]

Hi,

A sub-thread just on this one aspect of media type to be used in rdap-x, 
or generally content negotiation.

On 12.11.24 21:46, Andrew Newton (andy) wrote:
> responding to both Mario and JGould in line...
>
> On Mon, Nov 4, 2024 at 5:50 AM Mario Loffredo
> <mario.loffredo=[e-mail]> wrote:
>
>>
>>
>> Section 3 "Using The RDAP-X Media Type"
>>
>> My initial thought upon re-review of this section was to reuse the existing "application/rdap+json" media type by adding the optional parameter "extensions", or better "rdapx" to the media type registration, but then I got to Appendix B.1 that makes a good point with the language in RFC 6838.  I really don't want to include RDAP-X in the content-type header of the response, since it duplicates the rdapConformance member, and requires updating RFC 7480 with no real positive value.  Updating RFC 7480 may also trigger the need to bump rdap_level_0 to rdap_level_1, which is certainly not desired.  We should re-evaluate the language of RFC 6838 in its application to an RDAP extension.  How about adding support for RDAP-X in the accept header of the request and to have the response content-type header remain using the existing media type of "application/rdap+json"?  This would meet the need of the client providing the RDAP extension hints without the negative side effects of updating RFC 7480 and bumping rdap_level_0 to rdap_level_1.
>>
> This is an interesting idea and I think it simplifies things. Thanks.

I would very much support extending application/rdap+json with an 
additional optional parameter of requested extensions instead of adding 
application/rdap-x at all. A new artificial media type seems to be a 
tempting approach to maintain back compatibility, but maybe it is not 
needed at all?

There was an argument, that it would likely break the servers if 
unexpected parameters appear. I decided to check in reality how big the 
problem would be.

With help of small script [1] I queried all RDAP servers listed in IANA 
bootstrap list to get some stats how they behave with different Accept 
header.

The results [2] show, that 99.65% of the servers would deliver the same 
answer for 'application/rdap+json;extensions="rdap_level_0 rdapx foo"' 
as they do for 'application/rdap+json'.

What with the remaining 0.35%? It seems they are so wrongly implemented, 
that they would also break if an additional media type rdap-x appears in 
the request. 99.47% works with rdap-x as a second media type and 99.29% 
if you change order and put rdap-x first.

My conclusion is, that rdap-x will break a marginal portion of wrongly 
written servers, no matter if we keep same media type or define a new one.

Defining a new media type would mean, that application/rdap-x+jsonwould 
remain with us forever, as it will never replace application/rdap+json, 
but will become eventually a common practice to support. Extending of 
application/rdap+json seems to me less of pollution to the protocol on 
the long run.

>>
>> Appendix B.1 "Not Reusing the Existing Media Type"
>>
>> This section helped me out since my thought was to reuse the existing "application/rdap+json" media type instead of defining the new RDAP-X media type.  The language in RFC 6838 is clear and adding the capability of providing hints of the RDAP extensions is new functionality, but I really don't see that it's adding new functionality for the media type itself. We could define the existing "application/rdap+json" media type optional parameters as a form of extension in the extensions draft, where it will become an extension point without adding new functionality specific to the media type itself.  The response is still RDAP using JSON independent of the mix of extensions that are used.  If use of an optional media type parameter of the existing "application/rdap+json" media type cannot be done, can RDAP-X be used in the accept header and not returned in the content-type header to get the value of RDAP-X without the negative side effect of updating RFC 7480 and bumping rdap_level_0 to rdap_level_1?
>>
>> [ML] Think it's worth investigating if this soultion could be feasible.
>>
> I think so. We'll look into it. See above.

Also supportive of this one. Just extend the media type registration 
that parameters are to be expected provided by extensions (with usual 
prefix logic of RDAP etc.). New parameters will be then added in 
extensions themselves and update media type registration with detailed 
parameters.

The registration tells there are no *required* parameters to the media 
type, which remains true so in my opinion neither update to rfc7483 or 
rfc7480 would be required nor would we need to bump to rdap_level_1.


[1] https://github.com/pawel-kow/RDAP-tests/

[2] 
https://github.com/pawel-kow/RDAP-tests/blob/main/rdap_help_responses_20241114_IANA_bootstrap_list.md

https://github.com/pawel-kow/RDAP-tests/blob/main/rdap_help_responses_20241114_IANA_bootstrap_list.csv

Kind Regards,

Pawel