Return-Path: 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 2D43212004C for ; Wed, 19 Jun 2019 09:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.009 X-Spam-Level: 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: 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 xqT0ty2_Ulxt for ; Wed, 19 Jun 2019 09:29:34 -0700 (PDT) Received: from out-20.smtp.github.com (out-20.smtp.github.com [192.30.252.203]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A34101201ED for ; Wed, 19 Jun 2019 09:29:33 -0700 (PDT) Date: Wed, 19 Jun 2019 09:29:32 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1560961772; bh=B+W4vKU5FpIbU64x+gHVd9dVhA8otQVSG5UmPefU8NE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=f1pLBW2RTw0Y36xX7ebk8jyahsanp2abgdiv6ZKLOySUGSbqzXDJzsDsZnd0L5unz GN6pnkmyj0WGywhqtkZ3/6BIssewxLf7g8tN0bHDkFAkqAeUF+sWxP4aklDPeDTdHl Zs/SQFJSqrsegEy06xesTmN3LPWUlchRTtpenNcw= From: Mike Bishop Reply-To: quicwg/base-drafts To: quicwg/base-drafts Cc: Subscribed Message-ID: In-Reply-To: References: Subject: Re: [quicwg/base-drafts] Editorial suggestions on the Streams section (#2730) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_5d0a62ec83fda_540a3fdc320cd96c364626"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: MikeBishop X-GitHub-Recipient: quic-issues X-GitHub-Reason: subscribed X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: quic-issues@ietf.org Archived-At: X-BeenThere: quic-issues@ietf.org 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 16:29:36 -0000 ----==_mimepart_5d0a62ec83fda_540a3fdc320cd96c364626 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit MikeBishop commented on this pull request. > @@ -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 Structure? Sequence of octets? Or drop it entirely and define a packet as a header, payload, and authentication tag in that order. > @@ -335,8 +337,9 @@ the flow control limits set by its peer. Flow control is described in detail in Stream multiplexing can have a significant effect on application performance if resources allocated to streams are correctly prioritized. -QUIC does not provide frames for exchanging prioritization information. Instead -it relies on receiving priority information from the application that uses QUIC. +QUIC does not provide a mechanism for exchanging prioritization information. +Instead it relies on receiving priority information from the application that ```suggestion Instead, it relies on receiving priority information from the application that ``` > @@ -335,8 +337,9 @@ the flow control limits set by its peer. Flow control is described in detail in Stream multiplexing can have a significant effect on application performance if resources allocated to streams are correctly prioritized. -QUIC does not provide frames for exchanging prioritization information. Instead -it relies on receiving priority information from the application that uses QUIC. +QUIC does not provide a mechanism for exchanging prioritization information. +Instead it relies on receiving priority information from the application that +uses QUIC. implementation-specific, with the hyphen > @@ -543,9 +546,9 @@ 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". After all data has been +received, Any STREAM or STREAM_DATA_BLOCKED frames it receives for the stream ```suggestion received, any STREAM or STREAM_DATA_BLOCKED frames for the stream ``` -- 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/pull/2730#pullrequestreview-251820000 ----==_mimepart_5d0a62ec83fda_540a3fdc320cd96c364626 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

@MikeBishop commented on this pull request.

=0D =0D
=0D =0D

In draft-ietf-quic-transport.md:

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

Structure? Sequence of octets? Or drop it entirely and define a pack= et as a header, payload, and authentication tag in that order.

=0D =0D
=0D =0D

In draft-ietf-quic-transport.md:

=0D 
> @@ -335,8 +337,9 @@ the flow control limit=
s set by its peer.  Flow control is described in detail in=0D
 Stream multiplexing can have a significant effect on application perform=
ance if=0D
 resources allocated to streams are correctly prioritized.=0D
 =0D
-QUIC does not provide frames for exchanging prioritization information. =
 Instead=0D
-it relies on receiving priority information from the application that us=
es QUIC.=0D
+QUIC does not provide a mechanism for exchanging prioritization informat=
ion.=0D
+Instead it relies on receiving priority information from the application=
 that=0D
=0D =E2=AC=87=EF=B8=8F Suggested change=0D 
-Instead it relies on receiving priority infor=
mation from the application that=0D
+Instead, it relies on receiving priority information from the applicatio=
n that=0D
=0D =0D =0D
=0D =0D

In draft-ietf-quic-transport.md:

=0D 
> @@ -335,8 +337,9 @@ the flow control limit=
s set by its peer.  Flow control is described in detail in=0D
 Stream multiplexing can have a significant effect on application perform=
ance if=0D
 resources allocated to streams are correctly prioritized.=0D
 =0D
-QUIC does not provide frames for exchanging prioritization information. =
 Instead=0D
-it relies on receiving priority information from the application that us=
es QUIC.=0D
+QUIC does not provide a mechanism for exchanging prioritization informat=
ion.=0D
+Instead it relies on receiving priority information from the application=
 that=0D
+uses QUIC.=0D
=0D

implementation-specific, with the hyphen

=0D =0D
=0D =0D

In draft-ietf-quic-transport.md:

=0D 
> @@ -543,9 +546,9 @@ MAX_STREAM_DATA frames=
, it only receives any retransmissions of stream data.=0D
 =0D
 Once all data for the stream has been received, the receiving part enter=
s the=0D
 "Data Recvd" state.  This might happen as a result of receivin=
g the same STREAM=0D
-frame that causes the transition to "Size Known".  In this sta=
te, the endpoint=0D
-has all stream data.  Any STREAM or STREAM_DATA_BLOCKED frames it receiv=
es for=0D
-the stream can be discarded.=0D
+frame that causes the transition to "Size Known".  After all d=
ata has been=0D
+received, Any STREAM or STREAM_DATA_BLOCKED frames it receives for the s=
tream=0D
=0D =E2=AC=87=EF=B8=8F Suggested change=0D 
-received, Any STREAM or STREAM_DATA_BLOCKED f=
rames it receives for the stream=0D
+received, any STREAM or STREAM_DATA_BLOCKED frames for the stream=0D
=0D =0D =0D

&m= dash;
You are receiving this because you are subscribed to this thre= ad.
Reply to this email directly, view it on GitHub, or mute the th= read.3D""=

=0D = ----==_mimepart_5d0a62ec83fda_540a3fdc320cd96c364626--