A tiny nit: the ClientHello is not subject to MAX_STREAM_DATA. #803
Conversation
draft-ietf-quic-transport.md
Outdated
| limits established by MAX_DATA. Data on stream 0 other than the | ||
| TLS ClientHello is still subject to stream-level data limits and | ||
| MAX_STREAM_DATA. The TLS ClientHello is exempt from flow control because it needs | ||
| to be sent in one piece regardless of the server's flow control |
There was a problem hiding this comment.
I don't understand this phrase: "it needs to be sent in one piece". Do you mean that it needs to fit within a single packet (because we do require that, in Section 7.2.) If so, can you use the same language as in 7.2 (" initial cryptographic handshake message MUST be sent in a single packet")?
draft-ietf-quic-transport.md
Outdated
| MAX_STREAM_DATA. The TLS ClientHello is exempt from flow control because it needs | ||
| to be sent in one piece regardless of the server's flow control | ||
| state. This rule applies even for 0-RTT handshakes where the | ||
| remembered value of MAX_STREAM_DATA would not permit sending |
There was a problem hiding this comment.
nit: "would not permit" --> "does not permit"
There was a problem hiding this comment.
I made the change, but I actually think this is wrong because this is a counterfactual. I.e., it wouldn't permit it if taken literally, but we do not.
There was a problem hiding this comment.
Ah, right, good point. Your wording seems better, so go with it.
draft-ietf-quic-transport.md
Outdated
| is within the data limits set by its peer. The cryptographic | ||
| handshake stream, Stream 0, is exempt from the connection-level data | ||
| limits established by MAX_DATA. Data on stream 0 other than the | ||
| TLS ClientHello is still subject to stream-level data limits and |
There was a problem hiding this comment.
editorial nit: Can you say "initial cryptographic message from the client" instead of TLS ClientHello, for consistency (here and below)?
No description provided.