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

[ HTTP and WebTransport lists to BCC to avoid further cross-posting ]

Hi Philipp,

Thanks for your review.

Regarding your editorial comments, the editors will work to improve the
document editorially, Mark's PR is a great starting point for this work:
https://github.com/ietf-wg-masque/draft-ietf-masque-h3-datagram/pull/152/files

Other responses inline.

David

On Wed, Mar 23, 2022 at 11:15 AM Philipp S. Tiesel <philipp@tiesel.net>
wrote:

> 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"?
>

The Capsule Protocol is designed to be used by new HTTP Upgrade Tokens.
Those are used by the Upgrade mechanism in HTTP/1.x and by Extended CONNECT
in HTTP/2+3. In both of these, there is no concept of "HTTP Content"
because the stream (or connection in HTTP/1.x) is replaced with a new
protocol that isn't HTTP. We prohibit those headers because they don't
make any sense here.

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?
>

Thanks for filing an issue, let's discuss there:
https://github.com/ietf-wg-masque/draft-ietf-masque-h3-datagram/issues/153

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?
>

We're following what RFC 9000 did here. We picked some random numbers using:
https://xkcd.com/221/

AVE!
>    Philipp S. Tiesel
>
> --
> Philipp S. Tiesel
> https://philipp.tiesel.net/
>
> --
> Masque mailing list
> Masque@ietf.org
> https://www.ietf.org/mailman/listinfo/masque
>