Subject: [Webtransport] Confirming consensus of building WebTransport over HTTP semantics

From: David Schinazi <[email-masked]>
Date: Tue, 3 Aug 2021 16:00:09 -0700

Hi WebTransport enthusiasts,

As you may recall, we established consensus a couple months ago [1] that
the WEBTRANS WG would build a version of WebTransport that runs over HTTP.
We also reached consensus that this would use HTTP/2, though we hadn't
discussed how exactly to accomplish that.

On the list and in our meeting at IETF 111 last week, we discussed options
for this:
A) modifying HTTP/2, in other words integrating WebTransport deep into
HTTP/2
B) building over HTTP/2, in other words using HTTP/2 without changing it
C) building over HTTP semantics, in other words using HTTP without changing
it (this would work over HTTP/2 but also HTTP/1.1, potentially with
version-specific optimizations)

Last week we reached agreement in the room [2] on option (C). The chairs
would like to confirm this consensus on the list, so we are starting a two
week consensus call. Please state your opinions (even if they agree with
the sense of the room) in reply to this email. This call will last until
2021-08-17 23:59 UTC.

Thanks,
David

[1]
https://mailarchive.ietf.org/arch/msg/webtransport/OUPOUY1knWCAWeEebtij5SorRQk/
[2] https://datatracker.ietf.org/meeting/111/materials/minutes-111-webtrans

---

From: Ian Swett <[email-masked]>
Date: Tue, 3 Aug 2021 19:15:54 -0400

I strongly agree with the room's consensus on option C.

On Tue, Aug 3, 2021 at 7:00 PM David Schinazi <[email-masked]>
wrote:

> C) building over HTTP semantics, in other words using HTTP without
> changing it (this would work over HTTP/2 but also HTTP/1.1, potentially
> with version-specific optimizations)
>
> [2]
> https://datatracker.ietf.org/meeting/111/materials/minutes-111-webtrans
> --
> Webtransport mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webtransport
>

---

From: Alan Frindell <[email-masked]>
Date: Tue, 3 Aug 2021 23:29:22 +0000

I agree with the consensus for C

From: Webtransport <[email-masked]> on behalf of Ian Swett <ianswett=[email-masked]>
Date: Tuesday, August 3, 2021 at 4:16 PM
To: David Schinazi <[email-masked]>
Cc: WebTransport <[email-masked]>
Subject: Re: [Webtransport] Confirming consensus of building WebTransport over HTTP semantics

On Tue, Aug 3, 2021 at 7:00 PM David Schinazi <[email-masked]<mailto:[email-masked]>> wrote:
Hi WebTransport enthusiasts,

As you may recall, we established consensus a couple months ago [1] that the WEBTRANS WG would build a version of WebTransport that runs over HTTP. We also reached consensus that this would use HTTP/2, though we hadn't discussed how exactly to accomplish that.

On the list and in our meeting at IETF 111 last week, we discussed options for this:
A) modifying HTTP/2, in other words integrating WebTransport deep into HTTP/2
B) building over HTTP/2, in other words using HTTP/2 without changing it
C) building over HTTP semantics, in other words using HTTP without changing it (this would work over HTTP/2 but also HTTP/1.1, potentially with version-specific optimizations)

Last week we reached agreement in the room [2] on option (C). The chairs would like to confirm this consensus on the list, so we are starting a two week consensus call. Please state your opinions (even if they agree with the sense of the room) in reply to this email. This call will last until 2021-08-17 23:59 UTC.

Thanks,
David

[1] https://mailarchive.ietf.org/arch/msg/webtransport/OUPOUY1knWCAWeEebtij5SorRQk/<https://mailarchive.ietf.org/arch/msg/webtransport/OUPOUY1knWCAWeEebtij5SorRQk/>
[2] https://datatracker.ietf.org/meeting/111/materials/minutes-111-webtrans<https://datatracker.ietf.org/meeting/111/materials/minutes-111-webtrans>
--
Webtransport mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/webtransport<https://www.ietf.org/mailman/listinfo/webtransport>

---

From: Adam Rice <[email-masked]>
Date: Wed, 4 Aug 2021 12:50:03 +0900

It is not clear what "building over HTTP semantics" would mean, in
particular in the case of HTTP/1.1 which doesn't support full-duplex
streams.

On Wed, 4 Aug 2021 at 08:29, Alan Frindell <afrind=[email-masked]>
wrote:

> *From: *Webtransport <[email-masked]> on behalf of Ian
> Swett <ianswett=[email-masked]>
> *Date: *Tuesday, August 3, 2021 at 4:16 PM
> *To: *David Schinazi <[email-masked]>
> *Cc: *WebTransport <[email-masked]>
> *Subject: *Re: [Webtransport] Confirming consensus of building
> WebTransport over HTTP semantics
>
>
>

---

From: Victor Vasiliev <[email-masked]>
Date: Tue, 10 Aug 2021 13:57:22 -0400

I agree in general with the consensus for C.

That said, Adam raises a good point: we should understand why/how the
resulting WebTransport over HTTP/1.1 addresses concerns that led to the
creation of WebSocket protocol before.

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 11 Aug 2021 09:04:32 +1000

I don't understand Adam's point.  We're using CONNECT (-ish), which is fully duplex.  thewebsocketprotocol uses Upgrade, which is also fully duplex.

On Wed, Aug 11, 2021, at 03:57, Victor Vasiliev wrote:
> > It is not clear what "building over HTTP semantics" would mean, in particular in the case of HTTP/1.1 which doesn't support full-duplex streams.
> > 
> > On Wed, 4 Aug 2021 at 08:29, Alan Frindell <afrind=[email-masked]> wrote:
> >> I agree with the consensus for C____
> >> __ __
> >> *From: *Webtransport <[email-masked]> on behalf of Ian Swett <ianswett=[email-masked]>
> >> *Subject: *Re: [Webtransport] Confirming consensus of building WebTransport over HTTP semantics____
> >> __ __
> >> I strongly agree with the room's consensus on option C.____
> >> __ __
> >> On Tue, Aug 3, 2021 at 7:00 PM David Schinazi <[email-masked]> wrote:____
> >>> Hi WebTransport enthusiasts,____
> >>> __ __
> >>> As you may recall, we established consensus a couple months ago [1] that the WEBTRANS WG would build a version of WebTransport that runs over HTTP. We also reached consensus that this would use HTTP/2, though we hadn't discussed how exactly to accomplish that.____
> >>> __ __
> >>> On the list and in our meeting at IETF 111 last week, we discussed options for this:____
> >>> A) modifying HTTP/2, in other words integrating WebTransport deep into HTTP/2____
> >>> B) building over HTTP/2, in other words using HTTP/2 without changing it____
> >>> C) building over HTTP semantics, in other words using HTTP without changing it (this would work over HTTP/2 but also HTTP/1.1, potentially with version-specific optimizations)____
> >>> __ __
> >>> Last week we reached agreement in the room [2] on option (C). The chairs would like to confirm this consensus on the list, so we are starting a two week consensus call. Please state your opinions (even if they agree with the sense of the room) in reply to this email. This call will last until 2021-08-17 23:59 UTC.____
> >>> __ __
> >>> Thanks,____
> >>> David____
> >>> __ __
> >>> [1] https://mailarchive.ietf.org/arch/msg/webtransport/OUPOUY1knWCAWeEebtij5SorRQk/____
> >>> [2] https://datatracker.ietf.org/meeting/111/materials/minutes-111-webtrans____
> >>> -- 
> >>> https://www.ietf.org/mailman/listinfo/webtransport____
> >> --

---

From: Victor Vasiliev <[email-masked]>
Date: Wed, 11 Aug 2021 14:55:23 -0400

Web pages cannot initiate CONNECT requests, though, and WebSockets have
extra security features (SHA-1 handshake confirmation, masking) that
CONNECT currently lacks.

On Tue, Aug 10, 2021 at 7:05 PM Martin Thomson <[email-masked]> wrote:

> I don't understand Adam's point.  We're using CONNECT (-ish), which is
> fully duplex.  thewebsocketprotocol uses Upgrade, which is also fully
> duplex.
>
> > >> *From: *Webtransport <[email-masked]> on behalf of
> Ian Swett <ianswett=[email-masked]>
> WebTransport over HTTP semantics____
> > >> __ __
> > >>> As you may recall, we established consensus a couple months ago [1]
> that the WEBTRANS WG would build a version of WebTransport that runs over
> HTTP. We also reached consensus that this would use HTTP/2, though we
> hadn't discussed how exactly to accomplish that.____
> > >>> __ __
> with version-specific optimizations)____
> > >>> __ __
> > >>> Last week we reached agreement in the room [2] on option (C). The
> chairs would like to confirm this consensus on the list, so we are starting
> a two week consensus call. Please state your opinions (even if they agree
> with the sense of the room) in reply to this email. This call will last
> until 2021-08-17 23:59 UTC.____
> > >>> __ __
> > >>> Thanks,____
> > >>> David____
> > >>> __ __
> > >>> [1]
> https://mailarchive.ietf.org/arch/msg/webtransport/OUPOUY1knWCAWeEebtij5SorRQk/____
> > >>> [2]
> https://datatracker.ietf.org/meeting/111/materials/minutes-111-webtrans____
> > >>> --

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 12 Aug 2021 08:29:52 +1000

> extra security features (SHA-1 handshake confirmation, masking) that 

I don't see how that is relevant.  We are letting web pages make WebTransport sessions, not use CONNECT directly.

(Those WebSocket "features" are not especially useful unless we believe that they are necessary in this context also.  Masking, for instance, might be, though we might get roughly equivalent results if we insist on occasional, random padding.)

---

From: Adam Rice <[email-masked]>
Date: Thu, 12 Aug 2021 08:45:01 +0900

> fully duplex.  thewebsocketprotocol uses Upgrade, which is also fully

Ah, I see. CONNECT is indeed full duplex. However, as Victor pointed out,
determining that all intermediaries can handle it is the tricky part. I
think it would be safer to use the WebSocket protocol as a transport as it
already addresses these problems.

---

From: Eric Kinnear <[email-masked]>
Date: Fri, 13 Aug 2021 13:35:20 -0400

We do have a goal to make WT streams something you can initiate from either endpoint, but I think we’ve always been fine with having the client need to initiate the very first interaction (especially to traverse intermediaries).

So if the client initiates the CONNECT stream and then the framing on that stream is bidirectional, I think you get the same outcome as with the previous design.

Overall, I’d be in support of C.

Thanks,
Eric

> On Aug 11, 2021, at 7:45 PM, Adam Rice <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Ah, I see. CONNECT is indeed full duplex. However, as Victor pointed out, determining that all intermediaries can handle it is the tricky part. I think it would be safer to use the WebSocket protocol as a transport as it already addresses these problems.
> 
> On Wed, 11 Aug 2021 at 08:05, Martin Thomson <[email-masked] <mailto:[email-masked]>> wrote:
> > On Tue, Aug 3, 2021 at 11:50 PM Adam Rice <[email-masked] <mailto:[email-masked]>> wrote:
> > > On Wed, 4 Aug 2021 at 08:29, Alan Frindell <afrind=[email-masked] <mailto:[email-masked]>> wrote:
> > >> *From: *Webtransport <[email-masked] <mailto:[email-masked]>> on behalf of Ian Swett <ianswett=[email-masked] <mailto:[email-masked]>>
> > >> *To: *David Schinazi <[email-masked] <mailto:[email-masked]>>
> > >> *Cc: *WebTransport <[email-masked] <mailto:[email-masked]>>
> > >> On Tue, Aug 3, 2021 at 7:00 PM David Schinazi <[email-masked] <mailto:[email-masked]>> wrote:____
> > >>> [1] https://mailarchive.ietf.org/arch/msg/webtransport/OUPOUY1knWCAWeEebtij5SorRQk/____ <https://mailarchive.ietf.org/arch/msg/webtransport/OUPOUY1knWCAWeEebtij5SorRQk/____>
> > >>> [2] https://datatracker.ietf.org/meeting/111/materials/minutes-111-webtrans____ <https://datatracker.ietf.org/meeting/111/materials/minutes-111-webtrans____>
> > >>> -- 
> > >>> [email-masked] <mailto:[email-masked]>
> > >>> https://www.ietf.org/mailman/listinfo/webtransport____ <https://www.ietf.org/mailman/listinfo/webtransport____>
> > >> -- 
> > >> [email-masked] <mailto:[email-masked]>
> > >> https://www.ietf.org/mailman/listinfo/webtransport <https://www.ietf.org/mailman/listinfo/webtransport>
> > > -- 
> > > [email-masked] <mailto:[email-masked]>
> > > https://www.ietf.org/mailman/listinfo/webtransport <https://www.ietf.org/mailman/listinfo/webtransport>
> > -- 
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/webtransport <https://www.ietf.org/mailman/listinfo/webtransport>
> > 
> 
> -- 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/webtransport <https://www.ietf.org/mailman/listinfo/webtransport>
> -- 
> [email-masked] <mailto:[email-masked]>

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 16 Aug 2021 10:34:10 +1000

> with version-specific optimizations)

This.  As I precipitated this discussion, I should probably support the resolution :)

---

From: Victor Vasiliev <[email-masked]>
Date: Mon, 16 Aug 2021 22:58:37 -0400

Sure, but we need to make sure we understand if we want those features
too.  For instance, what is the risk of an HTTP/1.1 server mistaking a
WebTransport payload as a pipelined request?

On Wed, Aug 11, 2021 at 6:30 PM Martin Thomson <[email-masked]> wrote:

> I don't see how that is relevant.  We are letting web pages make
> WebTransport sessions, not use CONNECT directly.
>
> (Those WebSocket "features" are not especially useful unless we believe
> that they are necessary in this context also.  Masking, for instance, might
> be, though we might get roughly equivalent results if we insist on
> occasional, random padding.)
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 16 Aug 2021 23:19:56 -0400

I understand the point, or at least I think I do.

WebSocket is not a part of HTTP, it is what you get if you exit HTTP for
lands of your own choosing. I understand why that is useful but please
don't call it 'HTTP' because it really has nothing to do with being a
HyperText Transport Protocol. Its like the fact that the monorail is in the
Magic Kingdom but once you set foot on it, you are off to Epcot or
wherever..

What you have there is a presentation layer that is capable of bypassing
stateful inspection firewalls.

Code reuse is good and all but a heck of a lot of the HTTP/1.0 design was
trying to work around things we discovered about MIME as we were going
along and HTTP/1.1 was trying to patch the thing without breaking it. If
you can find useful ideas in HTTP world, thats good but why chain yourself
to the architectural commitments we were trapped by when Mosaic was growing
by 150% a week and didn't know where we were even going?

For purposes of firewall bypass, I have written a HTTP binding for the
Mesh. At this point it uses only one thing from the HTTP protocol and that
is framing (content length or chunked encoding). That is it. Most of the
binding spec is telling people how to turn off caching which would mess
things up right and proper.

I remember when people got all excited about using XML for data
serialization and turning the Web into an RPC mechanism. That didn't turn
out too good because XML only excised 70% of the lossage from SGML, maybe
less. There is a reason people prefer JSON.

Do what you like but please do not call it HTTP.