Re: Design Issue: Must Ignore Rule for Unknown Frame Types

James M Snell <> Thu, 25 April 2013 23:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 820F721F972B for <>; Thu, 25 Apr 2013 16:21:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.166
X-Spam-Status: No, score=-10.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NcgMZeSVkADd for <>; Thu, 25 Apr 2013 16:21:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3AE7421F972C for <>; Thu, 25 Apr 2013 16:21:53 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UVVTy-0000l5-JJ for; Thu, 25 Apr 2013 23:21:42 +0000
Resent-Date: Thu, 25 Apr 2013 23:21:42 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UVVTu-0000kL-39 for; Thu, 25 Apr 2013 23:21:38 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1UVVTt-0006tW-Ar for; Thu, 25 Apr 2013 23:21:38 +0000
Received: by with SMTP id 16so2979752obc.23 for <>; Thu, 25 Apr 2013 16:21:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=PQ1mMYmcES7nqViS95NBJDZemFFs8ODgRJ4e+wqrrSM=; b=w5RiKuz784Kj7nYT/xLn8oRBtFybGXWD3yQ1c7lE+50/khphbU81XwWxAG8eNIvuud M5VpACrFBuYevgC+6vhp9m4J94i2eirgC5fbxpdZkiF3q/3ndgQPgp+9A8lHIEAh1Wxd D6ZTM9gBzLhEGlzZYY57FlIGfQpkIwOKpnfFudhwRKp57uBTR1QYS02rH5vXiPOYSDtW 5SkSfP6vAkabfij1W9DD+1BV4c5y8+UdgUikRlBSU3/wzt2f42739L+0oZX2kNexvtxQ TER6HKQYRg2BOVebrZ0FUBeGtkeuKNEhZD/vR04AZ2BZnYzg5+boRXeZkngIlK3bVRYr 0Epw==
X-Received: by with SMTP id nx6mr2272708obc.77.1366932071279; Thu, 25 Apr 2013 16:21:11 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 25 Apr 2013 16:20:51 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: James M Snell <>
Date: Thu, 25 Apr 2013 16:20:51 -0700
Message-ID: <>
To: Martin Thomson <>
Cc: "" <>
Content-Type: text/plain; charset=UTF-8
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: AWL=-1.728, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1UVVTt-0006tW-Ar 45d6f6fe14b6a926efd9c168c0667f6f
Subject: Re: Design Issue: Must Ignore Rule for Unknown Frame Types
Archived-At: <>
X-Mailing-List: <> archive/latest/17583
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Ok, then if we go with MUST Ignore, we need to be explicit about
requiring that unknown frame types cannot modify session / connection
state. The most significant effect of this is that new frame types
must not contain compressed header blocks that utilize the same shared
compression state as known frames. That does not rule out the use of
header compression in those frames, it just dictates that the state
management for those occur at a higher level in the stack.

On Thu, Apr 25, 2013 at 4:14 PM, Martin Thomson
<> wrote:
> If "MUST ignore", then it follows that "cannot modify session/connection state".
> I prefer "MUST ignore" because it allows for new frame types within a
> standardized negotiated protocol without fatal errors.  If you want to
> have new frame types modify session state, then you can negotiate a
> new protocol (HTTP/2.infinity)".
> BTW, that's a standard response we came up with informally at the
> Tokyo interim.  If someone wants to break the protocol, they are free
> to break their own because negotiating new protocols is going to be
> easy ... we hope.
> On 25 April 2013 15:58, James M Snell <> wrote:
>> In the current draft (-02) we say, "Implementations MUST ignore
>> unsupported and unrecognized frame types." but we give no guidance
>> that I can find about handling unknown frames that potentially modify
>> session state. For example, suppose some extension comes up with a new
>> frame type that includes a compressed header block. The receiving
>> endpoint will have no way of interpreting the content, but if it
>> ignores the frame entirely, it's stored session state can unknowingly
>> fall out of sync with the sender.
>> Recommendation: rather than a "MUST IGNORE" rule here, unknown and
>> unrecognized frame types ought to be a Session Error because the
>> receiver cannot determine whether and how those frames may have
>> changed the session state on the sending side. It would not be safe
>> for the receiver to continue attempting to communicate with the sender
>> on that session.
>> This obviously has an impact on the extensibility of the framing
>> layer. In short, a sender would not be able to use a new frame type
>> unless it knows the receiver can interpret it. The only solution for
>> that would be to have some kind of negotiation occur where the sender
>> effectively ask the recipient if particular extensions are supported
>> (as part of the session header perhaps?)