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

Martin Thomson <> Thu, 25 April 2013 23:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B7E2321F9729 for <>; Thu, 25 Apr 2013 16:15:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Tb5yGxH2VDnN for <>; Thu, 25 Apr 2013 16:15:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DBBD821F9726 for <>; Thu, 25 Apr 2013 16:15:16 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UVVNd-0007HU-Hg for; Thu, 25 Apr 2013 23:15:09 +0000
Resent-Date: Thu, 25 Apr 2013 23:15:09 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UVVNY-0006Ff-M3 for; Thu, 25 Apr 2013 23:15:04 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1UVVNX-0008WL-F6 for; Thu, 25 Apr 2013 23:15:04 +0000
Received: by with SMTP id c10so21107wiw.6 for <>; Thu, 25 Apr 2013 16:14:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=STjlJ0GBVR4XUTl9e4zcMAvqTXuWJ5wBRDaYVhQUYzI=; b=mX2+p0MouSwTlrdrKMsk07MuELmNSj9CB1fqb+FAbRKIdihj0rc990eoQw3J9TXMIS VnVTyJ2z2N9SfX8ufAbbKt2IAWpq4TLaqqxybRPiNY4Q69smr2hn8UgLYSebgm5N/MjL U5VD20Q6/l1H7iZp7QDIufGrRKpOq5WuqWmBhq65P7OCBIQ6QwL3mX+ZrpoJyoCEVlsy VQkwQ2HwM9yhsansdTR1qlPgjtL8TD3KU0dOBb/u4D28n2EK4Bz8vMNv96l7T+qC0BYZ 0S3f2xz9Jxa34gJUtjO76tGqigcJKTx6vs0O7/BEsCNEfIJgIhsjlgpwJaEaMHIZ+khh ZTnw==
MIME-Version: 1.0
X-Received: by with SMTP id ed9mr535017wib.32.1366931677338; Thu, 25 Apr 2013 16:14:37 -0700 (PDT)
Received: by with HTTP; Thu, 25 Apr 2013 16:14:37 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Thu, 25 Apr 2013 16:14:37 -0700
Message-ID: <>
From: Martin Thomson <>
To: James M Snell <>
Cc: "" <>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.696, 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: 1UVVNX-0008WL-F6 fb84c655b8839f360cead9d16484d958
Subject: Re: Design Issue: Must Ignore Rule for Unknown Frame Types
Archived-At: <>
X-Mailing-List: <> archive/latest/17581
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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