Re: New Version Notification for draft-kazuho-httpbis-priority-00.txt

> On Jul 12, 2019, at 7:01 AM, Kazuho Oku <kazuhooku@gmail.com> wrote:
> 
> Hello all,
> 
> Thank you very much for all the discussion here and elsewhere.
> 
> Based on the feedback, Robin, Lucas and I have expanded the number of urgency levels from 3 to 8, including a "background" level. From what we have heard, this would be sufficient; 5 levels is what some browsers use now (and we now provide 5 + background to them).
> 
> I hope that this gives them enough space to start with (we can subdivide existing levels later), at the same time associating enough meanings to each of the urgency levels so that the servers can tweak the prioritization scheme.
> 
> We can't submit -01 now, but the up-to-date draft can be found at:
> 
>     https://kazuho.github.io/draft-kazuho-httpbis-priority/draft-kazuho-httpbis-priority.html <https://kazuho.github.io/draft-kazuho-httpbis-priority/draft-kazuho-httpbis-priority.html>
> 
> The repository and the issue list can be tracked from https://github.com/kazuho/draft-kazuho-httpbis-priority/ <https://github.com/kazuho/draft-kazuho-httpbis-priority/>.
> 
> Please let us know what you think. Thank you in advance.  

Hi Kazuho,

This is starting to sound a lot like Waka's request priority (hi, lo, HiLo) and request context
[slide 9 of http://tools.ietf.org/agenda/83/slides/slides-83-httpbis-5.pdf <http://tools.ietf.org/agenda/83/slides/slides-83-httpbis-5.pdf> ]. I agree that defining
this as an e2e header field is a good way forward. HiLo is progressive with high priority for the
first block and then regular priority for the rest.

Note that there are other (security and privacy) reasons for explicitly communicating the context
of a request, since it can be used to detect some forms of fraud, phish, or transclusion.
However, that would need to be in a non-script-settable field.

We should also consider non-browsing priorities, such as indicating intentionally long-lived
responses that might have a low priority but do require some form of unbuffered regularity
(e.g., pongs). I don't think progressive is an independent parameter unless we intend
to communicate some sort of block size; otherwise, it is just saying that HoL blocking
isn't desired, which is not necessary to communicate beyond not setting "background".

In general, I like the approach, but I think the structured header syntax is the wrong choice.
Why send 26 bytes to communicate one (or maybe two) bytes of information?

....Roy