Re: Proposed text for erratum on PRIORITY in RFC 7540

Scott Mitchell <> Fri, 20 January 2017 17:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CAF29129476 for <>; Fri, 20 Jan 2017 09:18:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.699
X-Spam-Status: No, score=-9.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id p7bemgAK_IWZ for <>; Fri, 20 Jan 2017 09:18:52 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5B6A5129452 for <>; Fri, 20 Jan 2017 09:18:52 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1cUcnZ-0005O6-7b for; Fri, 20 Jan 2017 17:16:25 +0000
Resent-Date: Fri, 20 Jan 2017 17:16:25 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1cUcnV-0005NG-Cq for; Fri, 20 Jan 2017 17:16:21 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <>) id 1cUcnP-0005aX-4N for; Fri, 20 Jan 2017 17:16:16 +0000
Received: by with SMTP id n124so61981789lfd.2 for <>; Fri, 20 Jan 2017 09:15:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RAFth9BR6mKPDuDnILG6HcroWQ2oR23ijgZ9yXAiSXg=; b=Ej7aeSPhjzRbEmv+cs9OfH6EKGlyArQeTILOaV0sAVJ5r+rCOadUL+68wBtZQQsAya uZgYaxcla7lSLHINWETHsP+RsqSMMWbktAbEyzOEJMCBWm7Rn7UA4Ipr85k0DHE06Isf qvwsEHV2+4mkXlYknn3y7YFTsW+BUCa4tMiMoFEIfga+xTGedjI0GGa1dqhTN/FrqPnL d5xdu0c0wy316kxDYl2TN47ifgAy9eI+z65XVGnRK6rGaNGafsdkLdCDzj1ZCxeZdwue 2KwhZuiVjMdE8KzQ/a1n6+oiiNEBWdVBW2J7pEChVBC7o5QvOGEAdCoCQBz5jiP+Xbgp jWiw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RAFth9BR6mKPDuDnILG6HcroWQ2oR23ijgZ9yXAiSXg=; b=IWKUAsLss1eao9BBPhY4O+6/HsX2JpuXhtVXjdIRzCksSAA62xYXB9Yoh+B3lQrVRc 9kE6u1Ih2n4hWyvb4YecplPvo+vK2FZLp7RvejCjqiOq6DfEkFD1/3AhR637TWIla2G8 eQRWKVoBYzuRKt60mAXcETZkkugkRP+fGNDDu2ongRXid5dzpZ4iZI/xM45bR75o7Tkq 0ACUfT7eCpryEEvVUPew5WViNXiemv7g3d5pBEtkPVDSVINTCgv9Lhke2ux9nPbkCQeb 0hJHxZWeF1s4s/7lRgc0h9ICpch5DCvRmbwX01kLmyzvlYkAFB9kwgAuNXzEASEGeA1P HT8g==
X-Gm-Message-State: AIkVDXKvl0bw8BBBRWeXOGerocpZ2Fx8XuH5Il0PNuCfYC+JBecw2DPAGbM7qN/ygMZJ2wgN7Y2e/bPgkuDMnw==
X-Received: by with SMTP id q17mr4625847lfg.178.1484932548127; Fri, 20 Jan 2017 09:15:48 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 20 Jan 2017 09:15:47 -0800 (PST)
In-Reply-To: <>
References: <>
From: Scott Mitchell <>
Date: Fri, 20 Jan 2017 09:15:47 -0800
Message-ID: <>
To: Martin Thomson <>
Cc: HTTP Working Group <>
Content-Type: multipart/alternative; boundary="94eb2c06391a0bf3c2054689cd30"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-2.5
X-W3C-Scan-Sig: 1cUcnP-0005aX-4N ebf467d11cf7945b6e31e811b1db62ca
Subject: Re: Proposed text for erratum on PRIORITY in RFC 7540
Archived-At: <>
X-Mailing-List: <> archive/latest/33347
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Thu, Jan 19, 2017 at 7:59 PM, Martin Thomson <>

> I figure that I might try to nut this out here before opening an
> erratum.  It's not clear from the thread that we all understand this.
> I think that suggesting two additions is the right thing here.  It's
> an erratum, so we don't have to do a proper edit, we can leave that
> for some future revision of the spec to get precisely right.
> In Section 5.3 (Stream Priority) a new paragraph:
> > The information that an endpoint maintains for stream priority is
> separate from other state. Importantly, this includes stream states
> (Section 5.1).  A stream in any state can have its priority changed with a
> PRIORITY frame. The state of a stream is not changed as a result of
> changing its priority.  The number of streams for which state is remembered
> is at the discretion of an endpoint, see Section 5.3.4 for details.
> In Section 6.4 (PRIORITY) a new sentence at the end of the first paragraph:
Section 6.3? Section 6.4 is RST_STREAM right?

> > Sending or receiving a PRIORITY frame does not affect the state of the
> identified stream (Section 5.1), only its priority is altered.
The bit I think needs clarification is that a PRIORITY frame doesn't impact
state of ANY stream (if this is the intention of the RFC). The ambiguity
comes from the language "first use of a new stream identifier" in section
5.1.1 (see below). Is it possible to directly resolve this issue?  Updating
other sections is great, but this creates an implicit dependency between
different sections which leaves room for error.
> The first use of a new stream identifier implicitly closes all streams in
the "idle" state that might have been initiated by that peer with a
lower-valued stream identifier.

> I think that we only really need one piece of clarification (the
> second would be enough), but it doesn't hurt to make it clear in both
> places that one might go to learn this.