Subject: WGLC for draft-ietf-masque-h3-datagram

From: Christopher Wood <[email-masked]>
Date: Mon, 21 Mar 2022 10:38:19 -0700

(Cross-posting to MASQUE, HTTPBIS, and WebTransport)

This email initiates the WGLC for draft-ietf-masque-h3-datagram, located here:

   https://datatracker.ietf.org/doc/draft-ietf-masque-h3-datagram/
   
Please review the document and send any comments to the MASQUE mailing list. HTTPBIS and WebTransport are cc'd given the overlap in technology.

This call will conclude on April 8.

Best,
Chris and Eric

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 23 Mar 2022 12:49:22 +1100

Hi Chris et al,

I've had a read-through of the document, thanks.

The first thing that I noticed is that the specification is very obviously written from the perspective of someone who's very deep into the details of HTTP/3 and QUIC, and is either confusing or silent about how this relates to HTTP as a protocol overall. If this is going to be a new, version-independent feature of HTTP, I think we should specify it as one in the first instance -- especially given how poorly past attempts have failed when they weren't well-integrated (e.g., push).

So, I think it needs a non-trivial rewrite that shouldn't affect implementations, but unfortunately will affect the editors. I'm willing to work on a PR if that'd be helpful -- but it may take a bit of time to get right. Would that work for you/them?

Once that happens, I think it'll be easier to evaluate the technical content. If I understand it correctly, I have no problem with the on-the-wire details, although the capsule protocol feels like premature abstraction at this point. Could someone speak to the thinking behind it?

Cheers,

> On 22 Mar 2022, at 4:38 am, Christopher Wood <[email-masked]> wrote:
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 23 Mar 2022 15:22:02 +1100

OK, I've done a rough run at a PR; see:
  https://github.com/ietf-wg-masque/draft-ietf-masque-h3-datagram/pull/152

The HTML is waiting on someone to press the button on the Action, so I've attached my locally generated copy.

Personally, I think this is a significant improvement, and I don't believe I've changed anything normative.* While I'd be happy to see it merged (perhaps after some more work), I'd be equally pleased if it were cherry-picked from.

Even if nothing from it is incorporated, the exercise has helped me understand the document better, and I've got a few issues/questions as a result. The previous e-mail asked for feedback on-list; is that still preferred?

Cheers,

* If folks do find normative differences, I'd be interested to hear about it; it might indicate misunderstanding on my part, or lack of clarity in the source document. Either way, it'd be good to clear up.

> On 23 Mar 2022, at 12:49 pm, Mark Nottingham <[email-masked]> wrote:
> 
> Hi Chris et al,
> 
> Masque mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/masque

---

From: David Schinazi <[email-masked]>
Date: Wed, 23 Mar 2022 10:41:53 +0100

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

Hi Mark,

Thank you for reviewing the document, and for spending the time to write
this PR. The editors really appreciate it. You're absolutely right that the
draft was written focusing on HTTP/3 -- that's because we initially started
with only supporting HTTP/3 a few years back, but now that we're defining
something more generic over HTTP, I agree that some editorial changes are
needed. Having looked at your PR, I think it definitely helps -- Lucas and
I will sit down and review it together in detail, I suspect we'll end up
cherry-picking most of it into the document.

To respond to your question about the history of the Capsule Protocol,
there was interest from the MASQUE WG to create this generic messaging
system beyond only sending datagrams over h2 and h1. In particular,
CONNECT-IP relies on it to exchange IP configuration, and WebTransport
relies on it to exchange session close messages.

Since the MASQUE WG has been using GitHub, could we ask you to send your
issues/questions there please?
https://github.com/ietf-wg-masque/draft-ietf-masque-h3-datagram/issues
We're also happy to take feedback on the list but GitHub is preferred.

Thanks!
David

On Wed, Mar 23, 2022 at 5:22 AM Mark Nottingham <[email-masked]> wrote:

> Personally, I think this is a significant improvement, and I don't believe
> I've changed anything normative.* While I'd be happy to see it merged
> (perhaps after some more work), I'd be equally pleased if it were
> cherry-picked from.
>
> Even if nothing from it is incorporated, the exercise has helped me
> understand the document better, and I've got a few issues/questions as a
> result. The previous e-mail asked for feedback on-list; is that still
> preferred?
>
> Cheers,
>
>
> * If folks do find normative differences, I'd be interested to hear about
> it; it might indicate misunderstanding on my part, or lack of clarity in
> the source document. Either way, it'd be good to clear up.
>
>
>
>
> > The first thing that I noticed is that the specification is very
> obviously written from the perspective of someone who's very deep into the
> details of HTTP/3 and QUIC, and is either confusing or silent about how
> this relates to HTTP as a protocol overall. If this is going to be a new,
> version-independent feature of HTTP, I think we should specify it as one in
> the first instance -- especially given how poorly past attempts have failed
> when they weren't well-integrated (e.g., push).
> >
> > So, I think it needs a non-trivial rewrite that shouldn't affect
> implementations, but unfortunately will affect the editors. I'm willing to
> work on a PR if that'd be helpful -- but it may take a bit of time to get
> right. Would that work for you/them?
> >
> > Once that happens, I think it'll be easier to evaluate the technical
> content. If I understand it correctly, I have no problem with the
> on-the-wire details, although the capsule protocol feels like premature
> abstraction at this point. Could someone speak to the thinking behind it?
> >
> > Cheers,
> >
> >
> >> Please review the document and send any comments to the MASQUE mailing
> list. HTTPBIS and WebTransport are cc'd given the overlap in technology.
> >>

---

From: David Schinazi <[email-masked]>
Date: Wed, 23 Mar 2022 11:36:13 +0100

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 <[email-masked]>
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
> [email-masked]

---

From: David Schinazi <[email-masked]>
Date: Mon, 28 Mar 2022 16:29:34 -0400

[ HTTP and WebTransport lists to BCC, please reply on MASQUE list or in
GitHub ]

Hi everyone, the editors worked with Mark and Phillipp to write a fairly
large editorial PR.
While this PR didn't change anything normative, we really believe it
significantly improves
readability of the document, especially for folks coming in with more HTTP
than QUIC
experience. For folks coming to this WGLC now, please do check out the
latest version of the draft:
https://www.ietf.org/archive/id/draft-ietf-masque-h3-datagram-08.html
or ideally we recommend reviewing the editor's copy:
https://ietf-wg-masque.github.io/draft-ietf-masque-h3-datagram/draft-ietf-masque-h3-datagram.html

Thanks!
David

On Wed, Mar 23, 2022 at 5:41 AM David Schinazi <[email-masked]>
wrote:

>> Personally, I think this is a significant improvement, and I don't
>> believe I've changed anything normative.* While I'd be happy to see it
>> merged (perhaps after some more work), I'd be equally pleased if it were
>> cherry-picked from.
>>