Accept-Query scope

[mnot]

Right now, the spec says:

The "Accept-Query" response header field MAY be used by a server to directly signal support for the QUERY method while identifying the specific query format media type(s) that may be used.

The use of 'server' here implies that if a client gets a response from e.g., https://example.com/foo that contains Accept-Query, that client can infer that all other resources on the server support the listed media type(s).

That seems like it's overstating things; other resources on the server might accept other formats, or not accept QUERY at all (indeed, most may not). Given how disruptive such a change would be (e.g., to caching), it seems like a more cautious approach is warranted.

So, I suggest specifying 'resource', not 'server', and explaining the implications in some more detail.

I'm aware that Accept-Patch and Accept-Post both say 'server', but I think that's more from a history of imprecision. Also, neither of those can be read to imply that the specified method is preferred in place of another (especially one as widely used as GET).

[mnot]

(I wonder if it would be good to raise technical errata on accept-patch and accept-post about this)

[reschke]

(I wonder if it would be good to raise technical errata on accept-patch and accept-post about this)

Accept-Patch: yes.

Accept-Post: IANA points to https://www.w3.org/TR/ldp/ which mentions the expired ID https://datatracker.ietf.org/doc/draft-wilde-accept-post/ - maybe this should be resurrected. As POST is defined in the core specs, this could go there in a future revision, too (maybe open a reminder ticket over there?)