W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2013

Re: http://http2.github.io/http2-spec/#FrameHeader section on Flags being unset

From: 陈智昌 <willchan@google.com>
Date: Wed, 8 May 2013 16:37:44 -0300
Message-ID: <CAA4WUYjyqkhNVdYV1=nSf193E5LJjWqedfZpDcGyPbUxf-MVMw@mail.gmail.com>
To: Yoav Nir <ynir@checkpoint.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
OK, I'm unfamiliar with these editorial tricks since I'm a standards newb
:) This SGTM.

On Wed, May 8, 2013 at 4:33 PM, Yoav Nir <ynir@checkpoint.com> wrote:

> On May 8, 2013, at 9:26 PM, William Chan (陈智昌) <willchan@google.com>
> wrote:
> > """
> > The remaining flags can be assigned semantics specific to the indicated
> frame type. Flags that have no defined semantics for a particular frame
> type MUST be ignored, and MUST be left unset (0) when sending.
> > """
> >
> > Is there a reason that it MUST be left unset? Why not allow
> extensibility like we do for unknown frames? I actually don't think there's
> much value to specifying behavior for unused bits.
> >
> This is a pretty common trick. The flags MUST be sent with value zero, and
> MUST be ignored.
> This allows a future spec to update this document and assign a meaning to
> a set flag. By requiring (in this spec) that the flag be clear, any time
> the flag is set it means that the sender supports the newer spec, because
> an HTTP/2.0 base spec implementation would never set the flag. Similarly,
> "old" implementations ignore the flag.
> If instead, the spec made no requirements about what value is sent, it
> would be valid for an HTTP/2.0 base sender to send this bit as one. In that
> case, no future extensions could ever be made, assigning meaning to this
> flag, because receivers would not be able to tell an HTTP/2.0 base
> implementation that randomly set the bit to one from an implementation of
> the updated spec.
> Yoav
Received on Wednesday, 8 May 2013 19:38:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:11 UTC