Pawel, Thank you in performing the test, which had very interesting results. I agree that adding the parameter to the existing “application/rdap+json” media type registration is the best option, since x-media with the “extensions” (or “rdapx” to match the extension identifier) parameter is not adding new functionality to the media type itself. The response is still RDAP using JSON. The existing “rdap+json” registration is missing the “Optional parameters” field that is defined in the template of Section 5.6 of RFC 6838, so this can be corrected at the same time. The specific language in Section 4.3 of RFC 6838 is:
New parameters SHOULD NOT be defined as a way to introduce new functionality in types registered in the standards tree, although new parameters MAY be added to convey additional information that does not otherwise change existing functionality. I believe the key word here is “new functionality in types”, where an argument can be made that the addition of a new media type parameter, such as “extensions” / “rdapx”, is not changing the functionality of the media type itself. It’s not like we’re defining an extension of JSON or changing how the RDAP is represented on the wire. A hint of what to include doesn’t get to the level of a new functionality to the media type. If we do need to register a new media type, then we either need to include “application/rdap-x+json” in the “accept” header and include “application/rdap+json” in the “content-type” response header, or use “application/rdap-x+json” in both the “accept” and “content-type” headers and go down the path of updating rfc7480 and bumping “rdap_level_0” to “rdap_level_1”. -- JG [cid87442*image001.png@01D960C5.C631DA40] James Gould Fellow Engineer jgo...@verisign.com<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: "kowa...@denic.de" <kowa...@denic.de> Date: Thursday, November 14, 2024 at 6:59 AM To: "Andrew Newton (andy)" <a...@hxr.us>, Mario Loffredo <mario.loffredo=40iit.cnr...@dmarc.ietf.org>, James Gould <jgo...@verisign.com> Cc: "regext@ietf.org" <regext@ietf.org> Subject: [EXTERNAL] Re: [regext] Re: draft-ietf-regext-rdap-x-media-type-02 Feedback (on rdap-x media type) 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=40iit.cnr...@dmarc.ietf.org><mailto:mario.loffredo=40iit.cnr...@dmarc.ietf.org> 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+json would 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/<https://secure-web.cisco.com/1ZV4CLyqfu4OETIDapJVChjr_9vmwyZZd097PFh0ml0YPQOveb8UBv_OVL57310s1C_CW85CGoJRAgBC7V7thuJE-E9POY47O0phZ7w1-diSM9rKvheOBKSUmLrUC0Ey9ZEDJ8y5i_n6LzO61VwLTZhUB9bnfDTqrBQedyfSE5td0WMVpIGNuNkLLe1DtSvC7KwXdjbh-x9dJS21OLFF2DF3CGHojKhc25Ib6toC5xVLC2-HgmGrUmpl04R5wWhf7omStt33KujkThhjpSq5VhoMg7CpC8kceaHDlAMbgKIY/https%3A%2F%2Fgithub.com%2Fpawel-kow%2FRDAP-tests%2F> [2] https://github.com/pawel-kow/RDAP-tests/blob/main/rdap_help_responses_20241114_IANA_bootstrap_list.md<https://secure-web.cisco.com/1t3-KfK5rFOy9MkpJLSsBCx0YtEctHBl3shHT4nBV7Oq7sqEfdvO_X-w4w-8tWZ94d5KcvuRaR79_MSWktSiO50zNt6ijtMbG4ho84IQqNGaHUt_lc0834Xq-IrPkkPLhtmV6gd0U9SdxbTbog990T3vdj_07GecVVdK44TUsIEswkMXAduSiCSM8JhwKbMTiTuwxq-o1rw4O8cjCIx3EjmfTkqOiF63vV7hoed6smJMPaXxOn-vB3GRSrghxeEhbFq7VJN4bAu0OasHyOFxGnHyCDpsYtEoCGsTd-I_h2Tk/https%3A%2F%2Fgithub.com%2Fpawel-kow%2FRDAP-tests%2Fblob%2Fmain%2Frdap_help_responses_20241114_IANA_bootstrap_list.md> https://github.com/pawel-kow/RDAP-tests/blob/main/rdap_help_responses_20241114_IANA_bootstrap_list.csv<https://secure-web.cisco.com/12hqrcNEtTr9NikSC_HHasuCnWl_IW6BmeuTKFnFk8Q-ANPHm2yetd3SJCptvPXG_PkzuTld-TdetT-YeFbR01ZCPNeD9V49H93qy76HTlTDVHAGUEFeZJfsR_6dfuHE11cpfSwWbcWX3oKoY7M0X-LhUhLDTT6VeR1keuv4OEmWBpvaAl_kPT0YvetemzDWtbNwgs0u6cMboAJYt8zpL3XRLyKAK3VzPIZi5oPI35hkLqFStEWFBds3MQE5AalxpUMDW1JQ10DH9M-2U1f6yZYYxbz--crtmNb-pBn7vFkU/https%3A%2F%2Fgithub.com%2Fpawel-kow%2FRDAP-tests%2Fblob%2Fmain%2Frdap_help_responses_20241114_IANA_bootstrap_list.csv> Kind Regards, Pawel
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
