Questions about stream state transitions

Shigeki Ohtsu <ohtsu@iij.ad.jp> Wed, 17 July 2013 12:41 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 97A3B21F9F50 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 17 Jul 2013 05:41:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 e2wWGUU0k18B for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 17 Jul 2013 05:41:08 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id B428821F9EF5 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 17 Jul 2013 05:41:08 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UzR20-0006QX-Py for ietf-http-wg-dist@listhub.w3.org; Wed, 17 Jul 2013 12:40:32 +0000
Resent-Date: Wed, 17 Jul 2013 12:40:32 +0000
Resent-Message-Id: <E1UzR20-0006QX-Py@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <ohtsu@iij.ad.jp>) id 1UzR1k-0006PQ-A3 for ietf-http-wg@listhub.w3.org; Wed, 17 Jul 2013 12:40:16 +0000
Received: from mo00.iij.ad.jp ([202.232.30.145] helo=omgo.iij.ad.jp) by lisa.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <ohtsu@iij.ad.jp>) id 1UzR1e-0001am-OL for ietf-http-wg@w3.org; Wed, 17 Jul 2013 12:40:16 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iij.ad.jp; h=Message-ID: Date:From:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; i= ohtsu@iij.ad.jp; s=omgo1; t=1374064786; x=1375274386; bh=2rFn/7DXOny8yMH7H86nxUVa PYwj9VyzoV016eaxZfg=; b=unCcxGCCqRvPgomnZujuwt/tpjOXCHUFgH7TiymR4jMFmA9GBwT0Mq Md/ZxunNSMKq1hLfte/KIKOv7m/maHrvNJtnPT/RV2PmPQvm80o+oc+dAhmJNcdCZuu/6ZW894OaS WAiQtj0eKi3nwD+fzQFaCgaMxzKnNpZ9MYIHsYco=;
Received: by omgo.iij.ad.jp (mo00) id r6HCdkF0002173; Wed, 17 Jul 2013 21:39:46 +0900
Message-ID: <51E6908F.2010602@iij.ad.jp>
Date: Wed, 17 Jul 2013 21:39:43 +0900
From: Shigeki Ohtsu <ohtsu@iij.ad.jp>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=202.232.30.145; envelope-from=ohtsu@iij.ad.jp; helo=omgo.iij.ad.jp
X-W3C-Hub-Spam-Status: No, score=-3.7
X-W3C-Hub-Spam-Report: AWL=-3.252, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.394, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UzR1e-0001am-OL 7069447a40c2948c83d6da6df70ae567
X-Original-To: ietf-http-wg@w3.org
Subject: Questions about stream state transitions
Archived-At: <http://www.w3.org/mid/51E6908F.2010602@iij.ad.jp>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18823
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>

Hi,

The stream state is newly introduced in the draft-04. For my understandings,
I've just wrote a table diagram for the stream states transition to cover
 all scenarios in the case of sending and receiving frames.

The table is listed in

http://html5.ohtsu.org/HTTP2_Stream_State.pdf

In writing this, I have the folowing five questions which are painted gray in
the table field.

(1) Receiving RST_STREAM in "idle"
Is it a stream error with PROTOCOL_ERROR or falled into "closed" state?

(2) Receivng PRIRORITY and WINDOW_UPDATE in "half closed(local)"
They are not necessary. So is it to be an error or ignored?

(3) Sending PRIORITY in "half closed(remote)"
No description about this case is in the draft. Is it prohibited?

(4) Receiving RST_STREAM in "closed"
The draft says that " An endpoint that sends a RST_STREAM frame MUST ignore
frames that it receives on closed streams after it has sent a RST_STREAM frame."

Is this ignored always in the closed state or only in the case
after RST_STREAM sent?

(5) Receiving PUSH_PROMISE in "closed"
The draft says that 'An endpoint might receive a PUSH_PROMISE frame after
it sends RST_STREAM. PUSH_PROMISE causes a stream to become "reserved".'

The same question above.
Is PUSH_PROMISE always leads the associted stream to be reserved(remote)
in the closed state? Or is it limited in the case after RST_STREAM was sent?


If any missings or mistakes are found in the table, I'm very glad to have feedbacks.

Regards,