Re: section on Flags being unset

Yoav Nir <> Wed, 08 May 2013 19:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F232C21F8B45 for <>; Wed, 8 May 2013 12:35:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.413
X-Spam-Status: No, score=-10.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cpREu7yZQ8n2 for <>; Wed, 8 May 2013 12:35:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 447A621F8B2B for <>; Wed, 8 May 2013 12:35:02 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UaA7e-0006VB-Hr for; Wed, 08 May 2013 19:33:54 +0000
Resent-Date: Wed, 08 May 2013 19:33:54 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UaA7T-0006US-PH for; Wed, 08 May 2013 19:33:43 +0000
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UaA7S-0004Zi-Ef for; Wed, 08 May 2013 19:33:43 +0000
Received: from ([]) by (8.13.8/8.13.8) with ESMTP id r48JXDqC021388; Wed, 8 May 2013 22:33:13 +0300
X-CheckPoint: {518AA6DE-5-1B221DC2-1FFFF}
Received: from ([]) by ([]) with mapi id 14.02.0342.003; Wed, 8 May 2013 22:33:13 +0300
From: Yoav Nir <>
To: "<>" <>
CC: HTTP Working Group <>
Thread-Topic: section on Flags being unset
Thread-Index: AQHOTBn8w8XssFbpt0G+vD5f6bmma5j7e0AA
Date: Wed, 8 May 2013 19:33:11 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
x-cpdlp: 11710d152b99c3dde209ca11e7ff2a1253449abd20
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Received-SPF: permerror client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-6.6
X-W3C-Hub-Spam-Report: AWL=-0.274, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.353
X-W3C-Scan-Sig: 1UaA7S-0004Zi-Ef 2a9e101871bef8bbb4442920c9bb44f2
Subject: Re: section on Flags being unset
Archived-At: <>
X-Mailing-List: <> archive/latest/17896
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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