query: format for Accept-Query field

[reschke]

1. "#mediatype (for consistency, for example, with PATCH: https://greenbytes.de/tech/webdav/rfc5789.html#accept-patch)
2. Structured Fields, because that's how we define new fields (and one could argue that we shouldn't make up reasons not to use that format)

My proposal is 2).

[Acconut]

I'm also in favor of 2).

[darrelmiller]

I am in favour of 2)

[reschke]

We'll use SF in the next draft, and see whether somebody complains...

[zenomt]

sorry for not chiming in sooner. i'm in favor of (1) #media-range (not #media-type, to allow for wildcarding), both for consistency with Accept, Accept-Patch, and Accept-Post, as well as that if it's a structured field with a list of tokens (as proposed by Martin), then a media type and its parameters is essentially an opaque string, and

application/something; param1="foo"; param2="bar"

would be distinct from

application/something; param2="bar"; param1="foo"

even though they are semantically the same, and still require parsing a media-range out of the SF value.

[reschke]

Good point. @martinthomson - why exactly would you want the parameters be part of the string item? That would make parsing harder than it has to be.

(I assume there was a good reason for your proposal, but which?)

[zenomt]

notwithstanding the issue with parameter order i just mentioned, if this is a structured field, then you need to do the SF parsing to get tokens, and then parse each one as a media-range anyway. so why not just media-ranges without an extra SF wrapper?

[reschke]

One reason we (for some value of "we") prefer SF is that we've been consistently telling others not to define new fields in a non-SF syntax - even for consistency with other existing fields.

[zenomt]

my reading of RFC 9651 suggests that a SF that is a List of Token Items (each of which can be parameterized) is syntactically equivalent (and mostly semantically equivalent) to #media-range (from RFC 9110). that is

Accept-Query: application/something; param1="foo", application/other; profile="bar"; param="baz"

conforms to both #media-range from RFC 9110, and sf-list from RFC 9651 where the sf-items are sf-token parameters.

[martinthomson]

The reason that I suggested parameters as part of the string/token is that I'm not 100% confident that media type parameters fit the SF parameter syntax. If you do the analysis and conclude that it is OK, then that might be OK. Finally, I see q=0.9 being a field value extension, whereas charset="utf8" is a media type extension, so maybe having distinct means of extension makes that separation possible.

[zenomt]

i think there is a complication in the syntax: the SF ABNF only allows parameters to be separated from each other by SP and with no SP before a semicolon, whereas media-range allows OWS (SP and HTAB) to separate parameters and to occur before semicolons too.

[zenomt]

the SF Token Item production is compatible with media-range though. i wouldn't object to the definition of the field being that it encodes a "media range and its parameters" as an sf-list of SF Token Items and their parameters, rather than requiring the field itself to be #media-range. but i do think it's objectionable to have a media-range inside an sf-string, since that still requires separate parsing of each string value as a media-range, and (at the SF layer) destroys the semantic distinction of the parameters.

[reschke]

@martinthomson - we do have that separation for similar fields. OTOH, putting this into a string - essentially a micro syntax - is asking for trouble.

@zenomt - the goal is not to use an existing non-SF parser.

@mnot - I see that "sfbis" discourages using token in new field definions: "Note that Tokens are defined largely for compatibility with the data model of existing HTTP fields and may require additional steps to use in some implementations." - what does this mean (assuming the implementation has a conforming SF parser)? And does it apply here? AFAICT, we explicitly defined tokens so this kind of strings could be used.

[zenomt]

@reschke :

@zenomt - the goal is not to use an existing non-SF parser.

by "[the] production is compatible with media-range though" i only meant that, if limiting oneself to the constraints of SF (no HTABs, no spaces before semicolons), the item and its parameters would look like (and be compatible with) ordinary media ranges, which i think will reduce confusion and cognitive load on people, and will allow the items to be used as-is with existing media type and content negotiation tools, while still being a Structured Field™.