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

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
>
>