Re: [quicwg/base-drafts] Editorial suggestions on the Streams section (#2730)

ianswett <> Wed, 19 June 2019 02:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2977D120183 for <>; Tue, 18 Jun 2019 19:17:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.009
X-Spam-Status: No, score=-8.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id v4u3-B1T-jpn for <>; Tue, 18 Jun 2019 19:17:46 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E4501120089 for <>; Tue, 18 Jun 2019 19:17:45 -0700 (PDT)
Date: Tue, 18 Jun 2019 19:17:44 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1560910664; bh=obYhljwlLa+C+YSkohEETtVGat8BkllJ8qhv5QYBxMw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=yd7PiWUuJZZIcBlcx+lbsXDGy3EXcLvzdQIoFXqazaIRzwxQkwGUWPUW7NvGcf42R 3OjJx1XIBvCswi77FFelhRHcqzFZaj1POeDycGac2BqjibxiqXGyZv0HV/svkTW4HJ iTZ2iEz1h67jskYWYxDFK94iB+vJ7sXXMJHhAoQE=
From: ianswett <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/2730/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Editorial suggestions on the Streams section (#2730)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d099b487cb34_6adc3fe060acd96c8817b"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ianswett
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Jun 2019 02:17:48 -0000

ianswett commented on this pull request.

Thanks Martin, I made some updates based on your suggestions.

> @@ -187,8 +187,9 @@ QUIC:
 QUIC packet:
-: The smallest unit of QUIC that can be encapsulated in a UDP datagram. Multiple
-  QUIC packets can be encapsulated in a single UDP datagram.
+: A complete processable payload with a packet type, encryption level and

Payload was my best suggestion here, so I'm open to others.

> @@ -244,8 +245,9 @@ x (*) ...:
 # Streams {#streams}
 Streams in QUIC provide a lightweight, ordered byte-stream abstraction to an
-application. An alternative view of QUIC streams is as an elastic "message"
+application. Streams can be unidirectional or bidirecational.  An alternative
+view of QUIC unidirectional streams is a "message" abstraction of unlimited

practically unlimited?

> @@ -543,9 +546,8 @@ MAX_STREAM_DATA frames, it only receives any retransmissions of stream data.
 Once all data for the stream has been received, the receiving part enters the
 "Data Recvd" state.  This might happen as a result of receiving the same STREAM
-frame that causes the transition to "Size Known".  In this state, the endpoint
-has all stream data.  Any STREAM or STREAM_DATA_BLOCKED frames it receives for
-the stream can be discarded.
+frame that causes the transition to "Size Known".  Any STREAM or
+STREAM_DATA_BLOCKED frames it receives for the stream can be discarded.

Updated, PTAL

> @@ -734,9 +731,8 @@ used to check for flow control violations. A receiver might use a sum of bytes
 consumed on all streams to determine the maximum data limit to be advertised.
 A receiver can advertise a larger offset by sending MAX_STREAM_DATA or MAX_DATA
-frames at any time during the connection.  A receiver cannot renege on an
-advertisement however.  That is, once a receiver advertises an offset, it MAY
-advertise a smaller offset, but this has no effect.
+frames.  That is, once a receiver advertises an offset, it MAY advertise a


> @@ -746,16 +742,15 @@ A sender MUST ignore any MAX_STREAM_DATA or MAX_DATA frames that do not increase
 flow control limits.
 If a sender runs out of flow control credit, it will be unable to send new data
-and is considered blocked.  A sender SHOULD send STREAM_DATA_BLOCKED or
-DATA_BLOCKED frames to indicate it has data to write but is blocked by flow
+and is considered blocked.  A sender SHOULD send a single STREAM_DATA_BLOCKED or


> @@ -861,13 +855,12 @@ If either is received, the connection MUST be closed immediately with a
 connection error of type STREAM_LIMIT_ERROR (see {{immediate-close}}).
 Endpoints MUST NOT exceed the limit set by their peer.  An endpoint that
-receives a STREAM frame with a stream ID exceeding the limit it has sent MUST
+receives a frame with a stream ID exceeding the limit it has sent MUST

That's true, but I think that's a feature, not a bug.

> @@ -657,11 +659,6 @@ RESET_STREAM frame it sends, but MAY use any application error code.  The
 endpoint that sends a STOP_SENDING frame MAY ignore the error code carried in
 any RESET_STREAM frame it receives.
-If the STOP_SENDING frame is received on a stream that is already in the
-"Data Sent" state, an endpoint that wishes to cease retransmission of
-previously-sent STREAM frames on that stream MUST first send a RESET_STREAM

Upon reading, I thought it was redundant with the surrounding text, but I'll restore it for this PR.

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