Re: Design: Ignored Unknown Frame Types and Intermediaries

James M Snell <> Mon, 13 May 2013 21:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4B00121F9467 for <>; Mon, 13 May 2013 14:55:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.379
X-Spam-Status: No, score=-9.379 tagged_above=-999 required=5 tests=[AWL=1.220, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GOJwB8WNK1kB for <>; Mon, 13 May 2013 14:55:26 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B256C21F9401 for <>; Mon, 13 May 2013 14:55:26 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1Uc0i1-00018h-DV for; Mon, 13 May 2013 21:55:05 +0000
Resent-Date: Mon, 13 May 2013 21:55:05 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1Uc0hp-0007xl-1K for; Mon, 13 May 2013 21:54:53 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1Uc0ho-0002Z3-Df for; Mon, 13 May 2013 21:54:53 +0000
Received: by with SMTP id h1so8061248oag.39 for <>; Mon, 13 May 2013 14:54:26 -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=2KGTRcXKVFWVP3yIMgpQqjIaftPzIYSZZAFxk/SUkjY=; b=WDk7iZnO31C+9Ne9777PBMDxZZBs7TRPFmTKuF0uqAP5hs0gUEQhMopLij7HBj1/if hT6kOKn2l+qNekbgxB7jGvXlwXGnmL+3WjtzFaVounHmAUb3OBEW5Y2YxEfxk+D4dPiH 9oKedo9PVYLcn5CrsqmaEi91hoQ+8FwyikE8BtTq2gSjbLsCKjpEDhjgIRZxqdNBjTu8 FWbmMrNptU97t2gAd0bax1netkGjIJdm1U9vN9te/Qa2j41rEJW0gvm3WpzRWPuhOk6Z fNb0z9Ehb/8Gjs6ygNDOUNXPFXuKLs3mKn0uMN2sahA7t45mp/Wi4vfJCDir68mZdg4I 4Yqg==
X-Received: by with SMTP id rr2mr14321713oeb.35.1368482066498; Mon, 13 May 2013 14:54:26 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 13 May 2013 14:54:06 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
From: James M Snell <>
Date: Mon, 13 May 2013 14:54:06 -0700
Message-ID: <>
To: Martin Thomson <>
Cc: Roberto Peon <>, Yoav Nir <>, "" <>
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.693, 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: 1Uc0ho-0002Z3-Df be2555b905dafc309bd2f9d01aede788
Subject: Re: Design: Ignored Unknown Frame Types and Intermediaries
Archived-At: <>
X-Mailing-List: <> archive/latest/17979
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Mon, May 13, 2013 at 2:13 PM, Martin Thomson
<> wrote:
> On 13 May 2013 11:37, Roberto Peon <> wrote:
>> James:
>> Can you construct a case where, if you follow the rule spelled out in my
>> earlier email, you fail to achieve interop (because I can't)?
> It's trivially possible to construct a scenario where this happens,
> but only if you don't write down a "MUST ignore" rule.  Once the rule
> is in place, then you are constraining future extensibility.  A "MUST
> ignore" rule is the easiest rule to get right, but there are other
> models you can use.
>> The rule is, essentially:
>> If a party to the communication ignores (or removes) something it don't
>> understand, that must not screw up the session.
> The ignore/remove distinction is very important.  You can't
> selectively remove; it's all or nothing.  Either remove everything you
> don't know about or leave it all in.
> This consideration, along with James' hop-by-hop question does suggest
> a relatively simple way out:
> All unsupported/unknown frames that have a non-zero stream identifier
> MUST be ignored.  If a stream is forwarded by an intermediary, all
> unsupported/unknown frames MUST either be forwarded or removed; an
> intermediary MUST NOT selectively forward unsupported frame types.
> Unsupported/unknown frames with a zero stream identifier MUST be
> ignored and MUST NOT be forwarded.

I would go one step further and say that if an intermediary does not
wish to forward an unknown frame, it MUST NOT forward ANY additional
frames and ought to respond with an RST_STREAM. Removing only some
frames from the stream could cause significant data corruption or data
loss, especially if you don't know why those frames are there.

>> That implies that, when you add anything that must be interpreted, it then
>> must be declared in the version string (i.e. new version) and thus agreed
>> upon by both parties up front, and if you don't negotiate that other
>> version, you don't get to add frames whose removal would screw up the
>> session.
> Yeah, we addressed that early on.  If you want to guarantee that the
> other guy is going to support something, either work out how to agree
> in-session (with those ignored frames) or negotiate a new protocol.

Agreeing without prior coordination (must ignore or reject the stream)
is, in my opinion, the best approach for long term evolution and
growth. The "come up with a new version string" reminds me far too
much of things like XML namespaces. It's one of those things that
sounds like it ought to work in theory but when it gets down to real
world implementation, it ends up being a bigger mess than anticipated.

- James