Re: Priorities I-D for Thursday HTTPbis meeting (Fwd: New Version Notification for draft-kazuho-httpbis-priority-04.txt)

[Stefan Eissing <[e-mail]>]

First of all, thanks for Kazuho and Lucas for putting this together!

I agree with most of what has been already said, especially that it
should be adopted by the WG.

There seems to be consensus that priorities are hints for server and
not laws to obey.

The interleave setting is a new thing (yes, we had weights) and I am 
not sure if it is really something that clients want. I understood 
the mentioned use case, but before implementing this feature, I would 
really like to know more about the effects it has in various scenarios.

Cheers, Stefan

> Am 21.11.2019 um 05:45 schrieb Martin Thomson <[e-mail]>:
> 
> Hi Robin,
> 
> On Thu, Nov 21, 2019, at 10:11, Robin MARX wrote:
>>> I understand that reprioritization was identified as being important 
>> by the design team, but I don't recall seeing ever any evidence to 
>> support that view. Can we split that piece out and maybe pursue it 
>> separately? 
>> 
>> Could you expand on this statement a bit more? 
>> In my view, reprioritization has two sides: reprioritization from the 
>> client after sending an initial priority and server-side 
>> reprioritization, overriding the client's initial priority.
> 
> I refer specifically to the frame.
> 
>> The first side comes into play when doing things like video/media 
>> streaming when switching qualities (see e.g., 
>> https://github.com/kazuho/draft-kazuho-httpbis-priority/issues/92) or 
>> for the "switching tabs" use case that e.g., Ian keeps mentioning.
> 
> These seem fairly obvious, but I realized recently that a lot of our thinking hasn't been grounded in any data.  That is, we're intuiting things about the value of the signal, but we never got firm reasons.
>