Re: PRIORITY flag on HEADERS Frame?

I don't think we should take this change. We've deferred other
nice-to-haves on the basis of where we are in the pipeline and that should
be what happens here too. There is no particular reason to think that this
will be the last one and should be treated specially.

breaking changes reduce the value of the wg last call review that has
already happened and weaken the value of the interop testing that has been
completed when considering IESG last call. Discipline is the better route
here.

-P


On Mon, Dec 1, 2014 at 9:20 PM, Mark Nottingham <mnot@mnot.net> wrote:

> Jeff,
>
> This seems like an optimisation -- everyone (including you) were willing
> to have the flag there beforehand.
>
> It doesn't cause any security or interop problems, so I'm inclined to hold
> this change to the same bar as similar ones brought up recently -- it needs
> pretty much universal acclaim to get through.
>
> Who supports this change, and is anyone against it?
>
> Regards,
>
>
> > On 2 Dec 2014, at 11:28 am, Jeff Pinner <jpinner@twitter.com> wrote:
> >
> > With the change from -15 to -16 to allow PRIORITY frames to be sent at
> > any time, why is the PRIORITY flag retained on the HEADERS frame?
> >
> > Was this an oversight or intentional?
> >
> > IIRC we added the flag there because of the race condition where you
> > couldn't send priority information for a stream that wasn't yet open
> > and need a HEADERS frame to open the stream.
> >
> > Now that you can send the PRIORITY frame before the HEADERS that opens
> > the stream there is no need to append the priority information and the
> > parsing of the HEADERS frame can be simplified.
> >
> > - Jeff
> >
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>
>