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

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 8 May 2013 15:26:47 -0300

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

---

From: Yoav Nir <[email-masked]>
Date: Wed, 8 May 2013 19:33:11 +0000

On May 8, 2013, at 9:26 PM, William Chan (陈智昌) <[email-masked]> 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

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 8 May 2013 16:37:44 -0300

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 <[email-masked]> wrote:

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