RE: For review: editorial updates pull request

Mike Bishop <> Mon, 29 April 2013 22:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0660C21F9B6F for <>; Mon, 29 Apr 2013 15:17:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.466
X-Spam-Status: No, score=-7.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tF1xAtRr-2g0 for <>; Mon, 29 Apr 2013 15:17:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DBE1B21F9ACB for <>; Mon, 29 Apr 2013 15:17:35 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UWwNS-0005yV-1E for; Mon, 29 Apr 2013 22:16:54 +0000
Resent-Date: Mon, 29 Apr 2013 22:16:54 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UWwNH-0005va-LU for; Mon, 29 Apr 2013 22:16:43 +0000
Received: from ([] by with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from <>) id 1UWwNE-0007Jf-Qt for; Mon, 29 Apr 2013 22:16:41 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.675.0; Mon, 29 Apr 2013 22:16:07 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Mon, 29 Apr 2013 22:16:07 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.2.318.3; Mon, 29 Apr 2013 22:14:58 +0000
Received: from ( by ( with Microsoft SMTP Server id; Mon, 29 Apr 2013 22:13:57 +0000
Received: from mail217-co1 (localhost []) by (Postfix) with ESMTP id D5FFA1E0118 for <>; Mon, 29 Apr 2013 22:13:57 +0000 (UTC)
X-Forefront-Antispam-Report-Untrusted: CIP:; KIP:(null); UIP:(null); (null);; R:internal; EFV:INT
X-SpamScore: 2
X-BigFish: PS2(zz9371Ic89bh542Ic857hzz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz17326ah18c673h8275bh8275dhz31h2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1bceh1d07h1d0ch1d2eh17ej9a9j1155h)
Received-SPF: softfail (mail217-co1: transitioning domain of does not designate as permitted sender) client-ip=;; ; ;
X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2PR03MB025;; LANG:en;
Received: from mail217-co1 (localhost.localdomain []) by mail217-co1 (MessageSwitch) id 1367273635118561_23313; Mon, 29 Apr 2013 22:13:55 +0000 (UTC)
Received: from (unknown []) by (Postfix) with ESMTP id 14C279C004E; Mon, 29 Apr 2013 22:13:55 +0000 (UTC)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 29 Apr 2013 22:13:55 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 29 Apr 2013 22:13:54 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.670.13; Mon, 29 Apr 2013 22:13:51 +0000
Received: from ([]) by ([]) with mapi id 15.00.0670.000; Mon, 29 Apr 2013 22:13:51 +0000
From: Mike Bishop <>
To: James M Snell <>, "" <>
Thread-Topic: For review: editorial updates pull request
Thread-Index: AQHOQtmQ8ZqrzYPMKkWslmuvrRE6yZjtjBQA
Date: Mon, 29 Apr 2013 22:13:50 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: [2001:4898:98:200b:d09a:f937:4580:57f3]
Content-Type: multipart/alternative; boundary="_000_7c2d96dc20424ef6b7bcb8085a7530b3BY2PR03MB025namprd03pro_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(13464002)(377454001)(76482001)(74316001)(79102001)(74662001)(74366001)(74706001)(80022001)(47446002)(16236675002)(74502001)(56816002)(47976001)(15202345002)(54356001)(65816001)(31966008)(50986001)(46102001)(71186001)(51856001)(54316002)(56776001)(63696002)(47736001)(20776003)(81342001)(69226001)(4396001)(49866001)(81542001)(16676001)(564824004)(59766001)(77982001)(512874001)(53806001)(44976003)(6806003)(33646001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB014;; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en;
X-Forefront-PRVS: 0831C25939
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=0.7
X-W3C-Scan-Sig: 1UWwNE-0007Jf-Qt 185414fc67f82640ffecfa39950fcc3f
Subject: RE: For review: editorial updates pull request
Archived-At: <>
X-Mailing-List: <> archive/latest/17690
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

I'm not sure all of this is editorial.  I'd prefer to have mailing list discussion of at least this one:

The state of promised streams is bound to the state of the original associated stream on which the PUSH_PROMISE frame were sent. If the originating stream changes to half or fully closed, all associated promised streams close as well.  More specifically, if the sender of the PUSH_PROMISE half-closes the original stream, the sender will no longer be permitted to send frames for any associated promised streams. Accordingly, the FINAL flag SHOULD NOT be set on a PUSH_PROMISE frame, as doing so would make it impossible for the sender to use the promised stream.

This prevents the client from considering the original request complete, and we’re requiring the server to maintain more state about the request that it’s finished answering, but it can’t half-close yet because it has other related streams that aren’t done yet.  That also means that a server might not explicitly half-close any pushed stream, and just let that be implied by the closing of the parent stream.  That feels unnecessarily round-about.

It looks like you’re pulling from 4.3.2, which says:

To cancel all server push streams related to a request, the client may issue a stream error (Section 3.5.2<>) of type CANCEL on the associated-stream-id. By cancelling that stream, the server MUST immediately stop sending frames for any streams with in-association-to for the original stream.

I think you’re trying to address the inconsistency that a particular error on the associated (original) stream flows to the pushed streams, and I agree with correcting that.  You’re addressing it by saying that any closure flows to pushed streams, and I hesitate on that.  I’d rather resolve it by saying that once a PUSH_PROMISE has been sent, the stream is allocated and has an independent lifecycle; if the client wants to reset that stream, the client should reset that stream.  If the client wants to reset many streams at once, the client should send stream errors for each stream it wants to reset.

-----Original Message-----
From: James M Snell []
Sent: Friday, April 26, 2013 4:52 PM
Subject: For review: editorial updates pull request

Another, fairly significant pull request with some suggested spec edits. Please review carefully, these are a bit more extensive than what I submitted yesterday...

- James