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

[Ian Swett <[e-mail]>]

The draft is written with that in mind, but there's no requirement in
design or the draft that an implementation can only use the header for
initial prioritization.  Chrome uses the frame for initial priority and
updates and it seems to work fine.  Obviously only the frame can be used
for reprioritization.  I expect Google HTTP/3 servers will end up
supporting both.

But I think the draft should be updated to describe the frame as HBH and
able to be used for either initial or priority updates.

In practice, due to reordering, implementations need to handle receiving
the frame prior to the request anyway.

I hope that clarifies my thinking, Ian

On Thu, Mar 5, 2020 at 2:43 PM Lucas Pardue <[e-mail]>
wrote:

> Hi Ian,
>
> On Thu, Mar 5, 2020 at 6:17 PM Ian Swett <[e-mail]> wrote:
>
>> Thanks for updating this draft.
>>
>> On the point of headers vs frame, based on my experience leading the
>> design team and the slightly wider scope of use cases that are now on the
>> table, which includes server-side reprioritization, I see the compromise of
>> having both a frame and a header as the only way forward which has the
>> ability to gain consensus.  I also truly believe there are valid use cases
>> for both.
>>
>> I propose we should own that position and seek to describe the properties
>> of each clearly.
>>
>> Thanks, Ian
>>
>
>  Thanks for sharing your current thinking. Clarification question, the
> present design has an symmetrical design that constrains when and where
> where the signal carrier is used: headers are used for initial priority,
> and frames are used for reprioritization. You position supports both
> carriers but does it support this constraint?
>
> I'd also welcome other people's thoughts on this topic.
>
> Lucas
>