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

I think it would be nice to allow the frame on the request stream, but it's
not a must.  The current design works from my perspective, but it uses a
few more bytes.  If others support allowing it on the request stream, I'd
be supportive, and the additional code is tiny, but I'm not going to fight
for it really strongly and I certainly don't want to delay this effort to
fight for it.

I hope that's slightly clearer.

Thanks, Ian

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

> I agree with the points made but I think my question was unclear of my
> intent. So let me rephrase it as: HTTP/2 allows the PRIORITY frame to be
> sent on a stream at any point. Do we want to allow NU_PRIORITY on request
> streams but constrain the states that it can be sent in?
>
> Given that we're trying to define something that works equivalently across
> HTTP/2 and HTTP/3, my inclination is that restricting NU_PRIORITY to stream
> 0 and the control stream achieves that.
>
>
> On Thu, Mar 5, 2020 at 9:40 PM Ian Swett <ianswett@google.com> wrote:
>
>> Martin's concern is exactly right.
>>
>> On Thu, Mar 5, 2020 at 4:24 PM Martin Thomson <mt@lowentropy.net> wrote:
>>
>>> On Fri, Mar 6, 2020, at 07:43, Roberto Peon wrote:
>>> > Until HTTP offers chunk-extensions again, I don’t see how it can be
>>> otherwise?
>>>
>>> I don't think that's the concern, it's that there is no way for a client
>>> to send an update if the request stream is closed.  At least in QUIC.
>>>
>>>