Re: [quicwg/base-drafts] Remove PRIORITY (#2924)

[Robin Marx <[e-mail]>]

> This seems a little controversial. Patrick expressed a desire to limit the number of potential schemes. One of the source of the failings in h2 was the way that it enabled proliferation of schemes. 

I understand the argument, but I don't see how we could move prioritization to an extension (and mainly: allow more than one extension) and not add some kind of negotiation/setting to specify what is supported/will be used. I am a big proponent of adding this in if we decide not to fix priorities in H3 core **properly** (which is very much looking like it will be the case). Even if the SETTING ends up being moot down the line (e.g., all browsers decided to just support 1 approach), it will still be very useful for testing various extension proposals in the mean time (see it as a prioritization ALPN). I am interested in working on the design of such a setting. 

> Given the time pressure that you mention, I would be strongly inclined to support a very basic scheme.

This seems to be the most sensible way forward at this point. I would suggest to use the scheme proposed by Kazuho and Lucas (https://tools.ietf.org/html/draft-kazuho-httpbis-priority-01). It uses 8 different semantic prioritization levels ("urgency") and a progressive/non-progressive indicator. It could be seen as a simple variation on both Patrick Meenan's proposal and the original SPDY approach, while still allowing enough flexibility to represent some of the more subtle peculiarities of resource loading semantics. As I feel the best way to "finally fix" priorities down the line is to add a lot more semantic information with each request (see https://github.com/kazuho/draft-kazuho-httpbis-priority/issues/28), I feel this simpler approach is a good foundation for that, that will also make "upgrading" easier down the line.

Concretely, I would suggest **adding the 8 urgencies and progressive boolean to the core H3 draft** (making a note that it's not perfect, but not awful either, and that they remain "hints") and to use (an) H3 frame(s) to transport them. Kazuho's and Lucas' proposal of using an HTTP-header to transmit the same information, can be done as an extension (hopefully to be implemented by most of us as well, especially the browsers). Patrick Meenan's setup can also be an extension, which people can use for experimentation. The "final fix" (whatever it may be) can start as a relatively simple extension, can be implemented by a subset of stacks to get some experience, and then grow organically. 






-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2924#issuecomment-514978982