[quicwg/base-drafts] Different meanings of "message" are mixed up in transport draft (#3724)

[Baptiste Jonglez <[e-mail]>]

I reviewed `draft-ietf-quic-transport-27`, and it is not always clear what a "message" is supposed to mean. It needs clarification in the text to disambiguate between different meanings, and could also benefit from definitions.

Here is a review of the different meanings of "message" I found in the draft:

- **TLS message** (referred to as **cryptographic message** or **cryptographic handshake message**)
- **ICMP message**
- **application message**, which seems to refer to messages sent by applications with their own internal framing (not visible to QUIC, since each stream provides a simple bytestream with no framing)
- **QUIC "message"**, which seems to roughly mean "any QUIC control frame" but this is not defined. In any case, there is no "QUIC message" as such in the base protocol.

The first three meanings are understandable, but the last one should be clarified or removed altogether. Additionally, any usage of "message" not clearly falling into one of these four categories should be clarified.

Here is a breakdown of usages that need clarification:

- [2.] _An alternative view of QUIC unidirectional streams is a **"message"** abstraction of practically unlimited length._
-> this is not exactly the same as an application message. That being said, the quotes make it clear that it is used in an approximate sense.

- [5.1.1.] _Each Connection ID has an associated sequence number to assist in deduplicating **messages**_
-> this seems to refer to `NEW_CONNECTION_ID` and `RETIRE_CONNECTION_ID` frames specifically

- [5.3.] _0-RTT allows **application messages** to be sent by a client before receiving any **messages** from the server_
-> the second occurrence is unclear: does it refer to application messages sent by the server application? Or does it also include TLS messages or other "QUIC messages"?

- [10.3.] _The application protocol exchanges whatever **messages** that are needed to cause both endpoints to agree to close the connection_
-> this is quite clear from the context, but it would be more consistent to use "application messages"

- [14.1.] _An endpoint SHOULD use Datagram Packetization Layer PMTU Discovery (...) to determine whether the path to a destination will support a desired **message** size without fragmentation_
-> this should probably be replaced with "QUIC maximum packet size" as defined just above in the text.

- [21.7.] _QUIC and TLS both contain **messages** that have legitimate uses in some contexts, but that can be abused (..)_
-> this section contains several other occurrences of "message". This is well-defined for TLS, but there is no such thing as a "QUIC message" currently.

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