- From: Yoav Nir <ynir@checkpoint.com>
- Date: Wed, 8 May 2013 19:33:11 +0000
- To: "<willchan@google.com>" <willchan@google.com>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
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:33:43 UTC