Re: [quicwg/base-drafts] introduce a max_connection_ids transport parameter (#1998)

[Marten Seemann <[e-mail]>]

marten-seemann commented on this pull request.



>  An endpoint SHOULD ensure that its peer has a sufficient number of available and
-unused connection IDs.  While each endpoint independently chooses how many
-connection IDs to issue, endpoints SHOULD provide and maintain at least eight
-connection IDs.  The endpoint SHOULD do this by always supplying a new
-connection ID when a connection ID is retired by its peer or when the endpoint
-receives a packet with a previously unused connection ID.  Endpoints that
+unused connection IDs. Endpoints store received connection IDs for future use.
+An endpoint uses a transport parameter to advertise the maximum number of
+connection IDs it can store for future use. An endpoint MUST NOT provide more
+connection IDs than this limit. An endpoint MUST treat receipt of more than this
+number of connection IDs as an error of type CONNECTION_ID_LIMIT_ERROR. If an

That's the old discussion of error codes vs. error messages, right? Considering the fact that we have separate *_LIMIT_ERRORs for flow control and stream IDs, I thought it would be consistent to have an error code for this as well. I could live with PROTOCOL_VIOLATION as well, if people are unhappy with that.

-- 
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/1998#discussion_r243475748