On Mon, Apr 3, 2023 at 3:18 PM Jasdip Singh <[email protected]> wrote: > > Hi. > > > > If the response size increase is not a concern when both jCard and JSContact > objects are returned for some time, it seems Andy’s proposal (option 3) is > the way to go. IMO, it keeps things simple without having to worry about > which query parameter to set on the client side. Additionally, a server could > simply send back a notice as to when jCard would be sunset from its side. As > was mentioned previously, agree that a server couldn’t definitively measure > when the client demand for jCard goes to zero by looking at the proposed > query parameters. Instead, the server would decide unilaterally with > sufficient forewarning to clients.
(replying to Jasdip just because this is a good place to do it)... There is one other issue with the query parameters in that they won't survive redirects. This is the issue with attempting to encode client capabilities into URIs. If we want to encode a client's capabilities (e.g. this client supports JSContact), then that should go into an HTTP header. Now, this is a general RDAP issue and not specific to this draft, but I think this is another reason why the draft should drop the query parameters. -andy ps. Having done a little looking about using HTTP headers for client capabilities, one tried and true method would be to use a media type in the accepts header that supports parameters. Here's an example: https://www.iana.org/assignments/media-types/application/ld+json _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
