Subject: [quicwg/base-drafts] Make initial_max_stream_id_* optional and default to zero (#971)

From: Martin Thomson <[email-masked]>
Date: Wed, 29 Nov 2017 21:14:40 +0000 (UTC)

Out of discussion in #958, this allows an endpoint to omit initial_max_stream_id_x for the type of streams that it doesn't want or expect to receive.

Adds a warning about silly values for 0-RTT.

Closes #970.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/971

-- Commit Summary --

  * Make initial_max_stream_id_* optional and default to zero

-- File Changes --

    M draft-ietf-quic-transport.md (42)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/971.patch
https://github.com/quicwg/base-drafts/pull/971.diff

-- 
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/971

---

From: Martin Thomson <[email-masked]>
Date: Wed, 29 Nov 2017 21:14:50 +0000 (UTC)

@martinthomson pushed 1 commit.

654f8e5  Warn against silly values for 0-RTT

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/971/files/0276c89e5f4f9d7cae4e59d46e49559cdd9847a3..654f8e542a61b367c205f02de0e21c73d822bc2f

---

From: janaiyengar <[email-masked]>
Date: Wed, 29 Nov 2017 16:24:13 -0800

janaiyengar commented on this pull request.

A few nits, but looks good otherwise.

> @@ -1151,6 +1140,27 @@ stateless_reset_token (0x0006):
 : The Stateless Reset Token is used in verifying a stateless reset, see
   {{stateless-reset}}.  This parameter is a sequence of 16 octets.
 
+A client MUST NOT include a stateless reset token.  A server MUST treat receipt
+of a stateless_reset_token transport parameter as a connection error of type
+TRANSPORT_PARAMETER_ERROR.
+
+An endpoint MAY use the following transport parameters:
+
+initial_max_stream_id_bidi (0x0002):
+
+: The initial maximum stream ID parameter contains the initial maximum stream
+  number the peer may initiate for bidirectional streams, encoded as an unsigned
+  32-bit integer.  This value MUST be a valid bidirectional stream ID for a
+  peer-initiated stream (that is, the two least significant bits are set to 0 by
+  a server and to 1 by a client).  If an invalid value is provided, the
+  recipient MUST generate a connection error of type TRANSPORT_PARAMETER_ERROR.
+  This is equivalent to sending a MAX_STREAM_ID ({{frame-max-stream-id}})

nit: "This" is ambiguous. I would say "This parameter"

> +of a stateless_reset_token transport parameter as a connection error of type
+TRANSPORT_PARAMETER_ERROR.
+
+An endpoint MAY use the following transport parameters:
+
+initial_max_stream_id_bidi (0x0002):
+
+: The initial maximum stream ID parameter contains the initial maximum stream
+  number the peer may initiate for bidirectional streams, encoded as an unsigned
+  32-bit integer.  This value MUST be a valid bidirectional stream ID for a
+  peer-initiated stream (that is, the two least significant bits are set to 0 by
+  a server and to 1 by a client).  If an invalid value is provided, the
+  recipient MUST generate a connection error of type TRANSPORT_PARAMETER_ERROR.
+  This is equivalent to sending a MAX_STREAM_ID ({{frame-max-stream-id}})
+  immediately after completing the handshake.  The maximum stream ID is set to 0
+  if this parameter is absent, preventing the creation of new unidirectional

"new bidirectional streams", not "unidirectional"

> +
+An endpoint MAY use the following transport parameters:
+
+initial_max_stream_id_bidi (0x0002):
+
+: The initial maximum stream ID parameter contains the initial maximum stream
+  number the peer may initiate for bidirectional streams, encoded as an unsigned
+  32-bit integer.  This value MUST be a valid bidirectional stream ID for a
+  peer-initiated stream (that is, the two least significant bits are set to 0 by
+  a server and to 1 by a client).  If an invalid value is provided, the
+  recipient MUST generate a connection error of type TRANSPORT_PARAMETER_ERROR.
+  This is equivalent to sending a MAX_STREAM_ID ({{frame-max-stream-id}})
+  immediately after completing the handshake.  The maximum stream ID is set to 0
+  if this parameter is absent, preventing the creation of new unidirectional
+  streams until a MAX_STREAM_ID frame is sent.  Note that a default value of 0
+  does not prevent the the cryptographic handshake stream (that is, stream 0) to

typo: "the the"

> @@ -1160,13 +1170,9 @@ initial_max_stream_id_uni (0x0008):
   and to 3 by a client).  If an invalid value is provided, the recipient MUST
   generate a connection error of type TRANSPORT_PARAMETER_ERROR.  This is
   equivalent to sending a MAX_STREAM_ID ({{frame-max-stream-id}}) immediately
-  after completing the handshake.
-
-A client MUST NOT include a stateless reset token.  A server MUST treat receipt
-of a stateless_reset_token transport parameter as a connection error of type
-TRANSPORT_PARAMETER_ERROR.
-
-An endpoint MAY use the following transport parameters:
+  after completing the handshake.  The maximum stream ID is set to 0 if this

nit: "The maximum unidirectional stream ID"

> +A client MUST NOT include a stateless reset token.  A server MUST treat receipt
+of a stateless_reset_token transport parameter as a connection error of type
+TRANSPORT_PARAMETER_ERROR.
+
+An endpoint MAY use the following transport parameters:
+
+initial_max_stream_id_bidi (0x0002):
+
+: The initial maximum stream ID parameter contains the initial maximum stream
+  number the peer may initiate for bidirectional streams, encoded as an unsigned
+  32-bit integer.  This value MUST be a valid bidirectional stream ID for a
+  peer-initiated stream (that is, the two least significant bits are set to 0 by
+  a server and to 1 by a client).  If an invalid value is provided, the
+  recipient MUST generate a connection error of type TRANSPORT_PARAMETER_ERROR.
+  This is equivalent to sending a MAX_STREAM_ID ({{frame-max-stream-id}})
+  immediately after completing the handshake.  The maximum stream ID is set to 0

nit: "The maximum bidirectional stream ID"

-- 
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/971#pullrequestreview-80043707

---

From: Martin Thomson <[email-masked]>
Date: Thu, 30 Nov 2017 00:29:19 +0000 (UTC)

4dfd06b  Correct far too many nits

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/971/files/654f8e542a61b367c205f02de0e21c73d822bc2f..4dfd06b56e41074bfab53d7dc5ce51fab82b2e30

---

From: Martin Thomson <[email-masked]>
Date: Thu, 30 Nov 2017 00:29:36 +0000 (UTC)

Wow, that was sloppy.  I should not write PRs, even simple ones, when on an IAB call.

-- 
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/971#issuecomment-348042872

---

From: janaiyengar <[email-masked]>
Date: Wed, 29 Nov 2017 16:51:07 -0800

+
+initial_max_stream_id_bidi (0x0002):
+
+: The initial maximum stream ID parameter contains the initial maximum stream
+  number the peer may initiate for bidirectional streams, encoded as an unsigned
+  32-bit integer.  This value MUST be a valid bidirectional stream ID for a
+  peer-initiated stream (that is, the two least significant bits are set to 0 by
+  a server and to 1 by a client).  If an invalid value is provided, the
+  recipient MUST generate a connection error of type TRANSPORT_PARAMETER_ERROR.
+  Setting this parameter is equivalent to sending a MAX_STREAM_ID
+  ({{frame-max-stream-id}}) immediately after completing the handshake.  The
+  maximum bidirectional stream ID is set to 0 if this parameter is absent,
+  preventing the creation of new bidirectional streams until a MAX_STREAM_ID
+  frame is sent.  Note that a default value of 0 does not prevent the
+  cryptographic handshake stream (that is, stream 0) to be used.

This is perhaps a difference in usage, but I would have said "from being used" instead of "to be used".

-- 
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/971#pullrequestreview-80048748

---

From: janaiyengar <[email-masked]>
Date: Thu, 30 Nov 2017 00:51:25 +0000 (UTC)

janaiyengar approved this pull request.

One nit -- take it or leave it -- but LGTM.

-- 
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/971#pullrequestreview-80048794

---

From: Martin Thomson <[email-masked]>
Date: Wed, 29 Nov 2017 17:01:02 -0800

4360951  Grammar booboo

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/971/files/4dfd06b56e41074bfab53d7dc5ce51fab82b2e30..43609515e3c9cd7184d24cc889d68a20d5fc780a

---

From: Martin Thomson <[email-masked]>
Date: Thu, 30 Nov 2017 01:01:17 +0000 (UTC)

Merged #971.

-- 
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/971#event-1364735253