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

I think only sending it on the control stream is fine, as you can bundle a
STREAM frame from the control frame with that of the request stream into a
single datagram.  I don't think I'd object to sending it on the request
stream, but the only clear benefit is saving a few bytes.

And of course, Chrome may change to use the header for the initial priority
at some point after evaluation, but for now this approach is a bit simpler.

On Thu, Mar 5, 2020 at 3:05 PM Lucas Pardue <lucaspardue.24.7@gmail.com>
wrote:

>
>
> On Thu, Mar 5, 2020 at 7:51 PM Ian Swett <ianswett@google.com> wrote:
>
>> 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
>>
>
> Based on your implementation experience, would you be happy with the frame
> being restricted to only being sent on the control stream? Or do you see
> some need for allowing that frame on the request stream (noting that doing
> so adds challenges to making it work with HTTP/2)?
>
>
>