Re: [quicwg/base-drafts] Rearrange Packet Types section and references (#2203)

[ianswett <[e-mail]>]

ianswett commented on this pull request.

I believe Token is initial(and Retry) only?

> @@ -2602,15 +2600,21 @@ each packet sent, see {{packet-numbers}} for details.
 
 ## Coalescing Packets {#packet-coalesce}
 
-A sender can coalesce multiple QUIC packets into one UDP datagram.  This can
-reduce the number of UDP datagrams needed to complete the cryptographic
-handshake and starting sending data.  Receivers MUST be able to process
-coalesced packets.
+Packets using the Extended Long Header ({{extended-long-header}}) contain a
+Length field, which determines the end of the packet.  The Length field covers

```suggestion
 Length field, which determines the end of the packet.  The Length includes
```

> @@ -3338,6 +3342,52 @@ then a packet containing a 16-bit value of 0x9b32 will be decoded as 0xa82f9b32.
 Example pseudo-code for packet number decoding can be found in
 {{sample-packet-number-decoding}}.
 
+### Starting Packet Numbers

Agreed, I'd remove this.  In the Packet Number section we say that packet numbers start at 0, but are we intending to require they start at 0, because I can't find any normative language.

>  The following packet types are defined:
 
 | Type | Name                          | Section                     |
 |-----:|:------------------------------|:----------------------------|
 |  0x0 | Initial                       | {{packet-initial}}          |
-|  0x1 | 0-RTT Protected               | {{packet-protected}}        |
+|  0x1 | 0-RTT Protected               | {{packet-0rtt}}             |

```suggestion
|  0x1 | 0-RTT                         | {{packet-0rtt}}             |
```

Everywhere else in the doc, we call them 0-RTT, not 0-RTT Protected, so I'd suggest dropping Protected here.

> +  protected as they are for other packets with the long header, because Retry
+  packets don't contain a protected payload.  These bits instead encode the
+  length of the Original Destination Connection ID field.  The length uses the
+  same encoding as the DCIL and SCIL fields.
+
+Original Destination Connection ID:
+
+: The Original Destination Connection ID contains the value of the Destination
+  Connection ID from the Initial packet that this Retry is in response to. The
+  length of this field is given in ODCIL.
+
+Retry Token:
+
+: An opaque token that the server can use to validate the client's address.
+
+<!-- Break this stuff up a little, maybe into "Sending Retry" and "Processing

+1

> @@ -3674,7 +3707,37 @@ Token Length:
 
 Token:
 
-: The value of the token.
+: The value of the token that was previously provided in a Retry packet or

I thought only Initial packets have Tokens?

> @@ -2602,15 +2600,21 @@ each packet sent, see {{packet-numbers}} for details.
 
 ## Coalescing Packets {#packet-coalesce}
 
-A sender can coalesce multiple QUIC packets into one UDP datagram.  This can
-reduce the number of UDP datagrams needed to complete the cryptographic
-handshake and starting sending data.  Receivers MUST be able to process
-coalesced packets.
+Packets using the Extended Long Header ({{extended-long-header}}) contain a

Above you talk about packet types that use the long header and here you talk about packets with a length, but I don't see anywhere you list out which packet types use the extended long header, and not just the long header.

-- 
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/2203#pullrequestreview-186651662