On Tue, Nov 28, 2023 at 5:39 AM Mario Loffredo <mario.loffr...@iit.cnr.it> wrote: > > [ML] Since it talks about "content negotiation", rdap-x regards clients > signaling their preferences about response extensions or, at most, > extensions involving both the response and the request. > > With regard to pure request extensions, clients should signal > preferences by using query parameters prefixed by opaque extension > identifiers as defined in rdap-extensions. > > This in turn implies that, on one hand, rdap-x is strictly bound to > rdap-extensions and, on the other hand, instead of what is stated in > Section 6 of rdap-extensions, even the extensions created by IETF MUST > use the extension identifier as a prefix. > > Do you agree ?
The important part is that extensions have identifiers. The use of the identifiers as prefixes for JSON names or URL paths or query parameters is a separate issue. > [ML] It could be an issue if we decide to start using content > negotiation. The media type has not influenced the RDAP response so far. With all due respect, that is incorrect. Current RDAP does do content negotiation. Section 4.2 of RFC 7480 says the accept header can have either application/rdap+json, application/json, or both and the content-type header must have application/rdap+json. -andy _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
