Subject: [quicwg/base-drafts] Is zero a valid stream-ID in Transport Parameters? (#1023)

From: Christian Huitema <[email-masked]>
Date: Mon, 18 Dec 2017 01:01:02 +0000 (UTC)

We found this issue in interop testing. One implementation would send transport parameters with max bidir ID and max unidir ID set to zero. The other implementation applied strictly was is in the spec, and rejected the connection. The spec says:
~~~
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 (Section 8.8) 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) from being used.
~~~
If we interpret this strictly, 0 is illegal -- the way to encode 0 is simply to not provide the parameter. Should 0 actually be accepted?

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

---

From: Nick Banks <[email-masked]>
Date: Mon, 18 Dec 2017 04:34:39 +0000 (UTC)

I'd make the argument that if we support implicitly setting a value of 0, why wouldn't we support explicitly setting it?

-- 
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/1023#issuecomment-352323801

---

From: Christian Huitema <[email-masked]>
Date: Mon, 18 Dec 2017 05:43:36 +0000 (UTC)

@nibanks The counter argument is that it makes every decoder a bit more complex, while the implementations that want to send the value zero can just as well omit the parameter. So basically, who pays the cost?

The other issue is "bit rot". The "liberal in what you accept" argument is nice, but it leads to maintaining warts all over the code to accommodate this or that "almost standard" implementation.

-- 
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/1023#issuecomment-352331500