Request/response parameter omission asymmetry

[LPardue]

In my mind, the rules for priority header were quite symmetric but I think this highlights an asymmetry between how they are applied across requests and responses. I think we might want to spin that out into a separate issue, WDYT?

Originally posted by @LPardue in https://github.com/kazuho/draft-kazuho-httpbis-priority/pull/30

Expansion of server override behaviour text seemed to highlight something I had not realised. We might want to try and explain this better in the parameter definition area.

[kazuho]

FWIW, current text has the following sentence, but I agree that there is no text that specifies what happens when a parameter is missing.

When used, the parameters found in the response header field overrides those specified by the client.

Let me elaborate why I think the values of the unused parameters should be the ones that were specified by the client.

Consider the case where a server is serving a baseline JPEG (i.e. non-progressive JPEG file). It might want to send progressive=?0, because it thinks that there's no benefit in sending the image in small chunks. This HTTP response can be cached.

Requests that fetch this JPEG image might contain different urgency levels. When it is used as part of a HTML document, it would likely be urgency=non-blocking. But if the user is saving the image to disk as a background operation, it might have urgency=background (assuming that we define "background").

Or else, we might define an extension called "visibility." I'd assume that we'd want the H2/H3 terminator to respect the value of the client, unless the server explicitly specifies a visibility value.

To generalize, it is my view that (if not all, at least some) parameters are orthogonal to each other. A server specifying one parameter does not mean that the server is specifying others. Hence the parameters unspecified by the server should default to the client-provided value.

[LPardue]

Ok so I dread to suggest it but I think what might help is a section on Priority information lifetime. I.e. before a request is generated a resource has default priority. This can be initialised to non-defauls (using an information tuple) and then later updated (but not requiring a tuple, aka piecemeal). Let me sleep on that idea for a bit.

[rmarx]

I agree with Kazuho that the client-provided parameters should be kept if the server overrides just some of them.

I am also in favor of more clarifications in general, so the Priority Information lifetime gets a thumbs-up from me!

[LPardue]

Ok. I'll wait a little and let some of the other discussion items settle down a bit and then make a start on this.

[LPardue]

I think this has been overtaken, in whole or part, by other events. So I'm closing and will reopen if needs be later.