Re: [Webtransport] [Masque] WGLC for draft-ietf-masque-h3-datagram

["Philipp S. Tiesel" <[e-mail]>]

Hi Christopher and Eric,

Technically, the document looks pretty mature. It reflects the way we came here, but after a 6-month masq pause and the resulting distance, it reads a little weird at some places and has a few nits. Here are my comments/nits:

Abstract.

- The abstract very much starts with "QUIC DATAGRAM". I would somewhat have expected something like "This document defines a method to send datagram streams over HTTP. Each datagram stream is associated with a single HTTP request. It is mainly motivated by making the QUIC DATAGRAM extension usable for HTTP speakers in a way backward compatible to HTTP/2 and HTTP/1.1"

Section 1.

- This section also has somewhat of a jump start and should explain a little gentler the relation between HTTP Datagrams and QUIC datagrams.
- The sentence "Additionally, this document defines the Capsule Protocol that can convey datagrams over prior versions of HTTP." seems a little misleading … if I understood capsules right, they are also somewhat targeted as internal reliable datagrams/wire encoding over H/3


Section 2.

- The HTTP/1.1 part would better be a paragraph on its own.
- While the argument "requests are strictly serialized in the connection, therefore demultiplexing is not needed" is technically correct, Section 4. further restricts the use of HTTP/1.1 connections to a single stream of capsules/HTTP datagrams. 
  I would prefer to see this restriction as an argument here. 

Section 4.1.

- "The Capsule Protocol MUST NOT be used with messages […]" would benefit from clarifying that you mean HTTP messages (requests/responses).
- I understand that you want to rule out Content-Length and Transfer-Encoding as it would make implementations much more complex, but it would also allow re-using the HTTP session. Documenting this design choice would be beneficial.
- [out of couriosity] Why do you choose to have a Capsule-Protocol Header instead of specifying "Content-Type: application/http-capsules"?

Section 4.3. 

- Why is the ebnf `Capsule-Protocol = sf-item` instead of `Capsule-Protocol = sf-boolean`?
  Should this allow request/upgrade methods to append a list of additional parameters? 

Section 4.4.

- That section should move one level up to match Section 3
- That section should better be called "HTTP/3 Datagram Format: The DATAGRAM Capsule" to match Section 3

Section 7.4.

- Can you include some clue why you chose the capsule space of 41 * N + 23 for greasing?


AVE!
   Philipp S. Tiesel

--  
Philipp S. Tiesel
https://philipp.tiesel.net/