IETF Logo Mail Archive

Re: [quicwg/base-drafts] STOP_SENDING on implicitly opened streams is error-prone (#2345)

Benjamin Saunders <notifications@github.com> Sat, 19 January 2019 18:28 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 702BB130E8D for <quic-issues@ietfa.amsl.com>; Sat, 19 Jan 2019 10:28:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.553
X-Spam-Level:
X-Spam-Status: No, score=-12.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NR2IAlilSRNt for <quic-issues@ietfa.amsl.com>; Sat, 19 Jan 2019 10:28:07 -0800 (PST)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9835130E8B for <quic-issues@ietf.org>; Sat, 19 Jan 2019 10:28:07 -0800 (PST)
Date: Sat, 19 Jan 2019 10:28:06 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1547922486; bh=+vQ01y3EzZ8zwMTx6lgvG1nhJAiWJY5CyTKsCY19XiE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=U7m/BSOqJmG+zFS55YXOqPGposYyH1wjVKo88VZsWaQz/RPm09g3Tz20Y3YIw0dJI 5VPYRHyamYSw0g1DpdS3jcnCljEKvRzUtXUyNG33kHR71oGzqUWgAUz8CSe2r6WPcq 6vAelzPGTajYAnER81njMBCGc2yqX2eSnEydjSv4=
From: Benjamin Saunders <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab2c844c5362ff07b0a4e96c30d009f56db589ce3c92cf00000001185b2e3692a169ce17e0387c@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2345/455803860@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2345@github.com>
References: <quicwg/base-drafts/issues/2345@github.com>
Subject: Re: [quicwg/base-drafts] STOP_SENDING on implicitly opened streams is error-prone (#2345)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c436c36a774e_1f763fc4984d45bc5088f3"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: Ralith
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/GE2wjRgylRf8O0ZCWTEbaKt8qSU>
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: Sat, 19 Jan 2019 18:28:09 -0000

Strictly speaking, the old and new text both dictate what conditions an error is generated by the endpoint receiving the frame, in which case it is entirely appropriate to rely on that endpoint's state. The conditions under which it's safe to send are only implied, but I suppose it wouldn't hurt to be explicit.

[§3.2](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.section.3.2) dictates that a receive stream enters the Recv state when a higher-number stream is created. That suggests the following phrasing to me:

> STOP_SENDING MUST only be sent for streams in the Recv or Size Known states. Receiving a STOP_SENDING frame for a stream that is not yet created MUST be treated as a connection error of type STREAM_STATE_ERROR.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2345#issuecomment-455803860

v2.23.0 | Report a Bug | By Email