Re: For review: editorial updates pull request

James M Snell <jasnell@gmail.com> Tue, 30 April 2013 05:02 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7CD21F9B5E for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 29 Apr 2013 22:02:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.553
X-Spam-Level:
X-Spam-Status: No, score=-10.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ed2bIzxo05Te for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 29 Apr 2013 22:02:42 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3A321F9B56 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 29 Apr 2013 22:02:42 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UX2hR-0007GH-G5 for ietf-http-wg-dist@listhub.w3.org; Tue, 30 Apr 2013 05:01:57 +0000
Resent-Date: Tue, 30 Apr 2013 05:01:57 +0000
Resent-Message-Id: <E1UX2hR-0007GH-G5@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <jasnell@gmail.com>) id 1UX2hH-0007FR-EV for ietf-http-wg@listhub.w3.org; Tue, 30 Apr 2013 05:01:47 +0000
Received: from mail-oa0-f54.google.com ([209.85.219.54]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <jasnell@gmail.com>) id 1UX2hG-0008Oh-JD for ietf-http-wg@w3.org; Tue, 30 Apr 2013 05:01:47 +0000
Received: by mail-oa0-f54.google.com with SMTP id l20so112858oag.27 for <ietf-http-wg@w3.org>; Mon, 29 Apr 2013 22:01:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=wlJ0Sz5C6QvFJza+i7tnAynCOEsKswFaaB98UgBaAC0=; b=EYoMMBaPn9zci33FWU/xtk2XML9oOqidycEBG+b7IlpMYMPjuHslMSZJWNJeh3GYj7 YH5Onz/1i5edNUcfLSEfirs7ikgx8Ui9Zhp/6WUb3WEv5T6Z0FpQicmsbujhoMvPgHfK 5nP8KopAmy/7MgYL/8SHB6VsdbhzpjSq4ufGpCtZUSzB+i+RCgxAd/ANZedyeake6cbE EhrVx7g5q1uiCRCwA/ShFvNaYh52g2iIJj3XsbfzkP0zF7gwQJ5zDLPGspQ2jPbaRH3n ZBGm1bo+kswaWIDrQcvNKXnm+mZuCBsAaLpVlXkn4pUwss+3QNLi7OFnWvO+SDbslMsn s3pA==
X-Received: by 10.182.14.39 with SMTP id m7mr29072590obc.96.1367298080428; Mon, 29 Apr 2013 22:01:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.3.137 with HTTP; Mon, 29 Apr 2013 22:01:00 -0700 (PDT)
In-Reply-To: <7c2d96dc20424ef6b7bcb8085a7530b3@BY2PR03MB025.namprd03.prod.outlook.com>
References: <CABP7RbcLNT5VQiiXNJS3cguxQ6A9xknusOr01Ov4wp+_PG7T6A@mail.gmail.com> <7c2d96dc20424ef6b7bcb8085a7530b3@BY2PR03MB025.namprd03.prod.outlook.com>
From: James M Snell <jasnell@gmail.com>
Date: Mon, 29 Apr 2013 22:01:00 -0700
Message-ID: <CABP7RbefB8+oy4fJwOCX29D1Fw5p19LZYwpEtefw1BSG=D4MKQ@mail.gmail.com>
To: Mike Bishop <Michael.Bishop@microsoft.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=209.85.219.54; envelope-from=jasnell@gmail.com; helo=mail-oa0-f54.google.com
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: AWL=-1.717, 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: lisa.w3.org 1UX2hG-0008Oh-JD 05e0fb4f07a088b10943c7f23ec24c14
X-Original-To: ietf-http-wg@w3.org
Subject: Re: For review: editorial updates pull request
Archived-At: <http://www.w3.org/mid/CABP7RbefB8+oy4fJwOCX29D1Fw5p19LZYwpEtefw1BSG=D4MKQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17712
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Well, it's editorial in the sense that I just rewrote what is already
in the spec. I think that this is still an open technical question tho
that, yes, we need to hammer out.

On Mon, Apr 29, 2013 at 3:13 PM, Mike Bishop
<Michael.Bishop@microsoft.com> wrote:
> 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 [mailto:jasnell@gmail.com]
> Sent: Friday, April 26, 2013 4:52 PM
> To: ietf-http-wg@w3.org
> 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...
>
>
>
> https://github.com/http2/http2-spec/pull/81
>
>
>
> - James
>
>
>
>
>
>