Re: [quicwg/base-drafts] Clarify zero-length CIDs and active_connection_id_limit TP (#3426)

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.



> @@ -4697,11 +4697,12 @@ active_connection_id_limit (0x000e):
   to store. This value includes the connection ID received during the handshake,
   that received in the preferred_address transport parameter, and those received
   in NEW_CONNECTION_ID frames.
-  Unless a zero-length connection ID is being used, the value of the
-  active_connection_id_limit parameter MUST be no less than 2. If this
-  transport parameter is absent, a default of 2 is assumed.
-  When a zero-length connection ID is being used, the active_connection_id_limit
-  parameter MUST NOT be sent.
+  The value of the active_connection_id_limit parameter MUST be at least 2.
+  If this transport parameter is absent, a default of 2 is assumed.  If an
+  endpoint uses a zero-length connection ID, the active_connection_id_limit
+  value received from its peer is ignored and not used, as
+  NEW_CONNECTION_ID frames cannot be sent by an endpoint that opts for a
+  zero-length connection ID.
 

Well, remembering can't be hard-coded as this is a property of the behaviour of a peer and we don't really allow for implementations to only work if a peer uses zero-length connection IDs.  But the central point remains.

Clients don't really have to remember this transport parameter as much as servers unless they intend to send NEW_CONNECTION_ID during 0-RTT.  But putting that in the spec is perhaps a little detailed - we can rely on no one really knowing if they don't remember it.  Just like clients might choose not to remember the limit on unidirectional streams on the basis that they might assume that servers will always provide the small fixed number needed for HTTP to function.

-- 
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/3426#discussion_r391960617