[quicwg/base-drafts] Clarify send state behavior for peer-created bidi stream (#2636)

Andy Grover <notifications@github.com> Fri, 19 April 2019 20:14 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id A37671201C3 for <quic-issues@ietfa.amsl.com>; Fri, 19 Apr 2019 13:14:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id J_BUfZsVhxKA for <quic-issues@ietfa.amsl.com>; Fri, 19 Apr 2019 13:14:38 -0700 (PDT)
Received: from out-4.smtp.github.com (out-4.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC59A1200E6 for <quic-issues@ietf.org>; Fri, 19 Apr 2019 13:14:38 -0700 (PDT)
Date: Fri, 19 Apr 2019 13:14:37 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1555704877; bh=o2tsO5dq+eyvrbJbwJ2dg7dinvzes4ZmnLphN+XqFdw=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=W4TYbajB666ufqjDsVSMYAn1cWLycoRtY0vjTnfoBfSrLvuEK+EoY4nIUsx4gJ1H6 NxIRQjbsOfzrIgROB6TSJ3rZ4sTYVbzZ1SpICN4/OiIPy4YFur/7yyUkYzMxuZv5sR G8Tf8XRSKWSJkNfkY0WxR7KHMA12F2FkOT2KqUd8=
From: Andy Grover <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2BXMGFTJHASLE2UDF2Y5PK3EVBNHHBT4QGZ4@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2636@github.com>
Subject: [quicwg/base-drafts] Clarify send state behavior for peer-created bidi stream (#2636)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cba2c2dcaa97_7ba33f9e3facd95c156949"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: agrover
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/lMYtNGzJK6kTiH_QTOGpqNtysz4>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Apr 2019 20:14:41 -0000

>From -transport section 3.1:

> The sending part of a bidirectional stream initiated by a peer (type 0 for a server, type 1 for a client) enters the “Ready” state then immediately transitions to the “Send” state if the receiving part enters the “Recv” state (Section 3.2).

The event causing transition Ready->Send is the host initially having data to send on the stream, which is not the case when the receiving part has just been created in its initial Recv state. I think the send stream should stay in Ready until it does. This also aligns better with similar text in 3.2.

I suggest:

> The sending part of a bidirectional stream initiated by a peer (type 0 for a server, type 1 for a client) starts in the “Ready” state.

p.s. see also #2357, but which is more about being explicit about frames that cause stream creation... rather than this issue, which is about the state the new sending part starts in.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: