Subject: [Masque] Dropping HTTP/1.x requirement for CONNECT-UDP

From: David Schinazi <[email-masked]>
Date: Thu, 18 Mar 2021 15:12:36 -0700

Hi MASQUE enthusiasts,

The CONNECT-UDP draft currently states "The CONNECT-UDP method is defined
for all versions of HTTP." While supporting HTTP/3 is our top priority, and
supporting HTTP/2 is necessary because of networks that block UDP, I'm not
sure supporting versions of HTTP before 2 is useful. Additionally, it
constrains our design space as HTTP/1.1 does not have the HTTP framing
layer that HTTP/2 and HTTP/3 have. I would like to drop support for
HTTP/1.1, 1.0 and 0.9.

Does anyone object to dropping the requirement to support versions of HTTP
before 2?

Thanks,
David

---

From: Alex Chernyakhovsky <[email-masked]>
Date: Mon, 22 Mar 2021 18:21:24 -0400

I think this makes a lot of sense. As it stands today, anyone wishing to
add UDP support would have to make changes to their client/server anyway --
I feel like the complexity we'd take on by continuing to support HTTP/1.1
and older isn't beneficial since we wouldn't be able to interoperate with
existing implementations with the new features. Requiring HTTP/2 or newer
lets us rely on a lot of nice things that have been added (like
multiplexing) and not have to re-invent them in HTTP/1.1 just for UDP.

Sincerely,
-Alex

On Thu, Mar 18, 2021 at 6:12 PM David Schinazi <[email-masked]>
wrote:

> --
> Masque mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/masque
>

---

From: Tommy Pauly <[email-masked]>
Date: Mon, 22 Mar 2021 15:39:26 -0700

While I understand the desire for this, I’m concerned about making a method that only works with some versions.

From https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#methods <https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#methods> :

HTTP defines a number of generic extension points that can be used to introduce capabilities to the protocol without introducing a new version, including methods, status codes, field names, and further extensibility points within defined fields, such as authentication schemes and cache-directives (see Cache-Control extensions in Section 5.2.3 of [Caching]). Because the semantics of HTTP are not versioned, these extension points are persistent; the version of the protocol in use does not affect their semantics.

Version-independent extensions are discouraged from depending on or interacting with the specific version of the protocol in use. When this is unavoidable, careful consideration needs to be given to how the extension can interoperate across versions.

I’d like to hear the opinions of Mark and Roy on this.

Tommy

> On Mar 22, 2021, at 3:21 PM, Alex Chernyakhovsky <achernya=[email-masked]> wrote:
> 
> I think this makes a lot of sense. As it stands today, anyone wishing to add UDP support would have to make changes to their client/server anyway -- I feel like the complexity we'd take on by continuing to support HTTP/1.1 and older isn't beneficial since we wouldn't be able to interoperate with existing implementations with the new features. Requiring HTTP/2 or newer lets us rely on a lot of nice things that have been added (like multiplexing) and not have to re-invent them in HTTP/1.1 just for UDP.
> 
> Sincerely,
> -Alex
> 
> On Thu, Mar 18, 2021 at 6:12 PM David Schinazi <[email-masked] <mailto:[email-masked]>> wrote:
> Hi MASQUE enthusiasts,
> 
> The CONNECT-UDP draft currently states "The CONNECT-UDP method is defined for all versions of HTTP." While supporting HTTP/3 is our top priority, and supporting HTTP/2 is necessary because of networks that block UDP, I'm not sure supporting versions of HTTP before 2 is useful. Additionally, it constrains our design space as HTTP/1.1 does not have the HTTP framing layer that HTTP/2 and HTTP/3 have. I would like to drop support for HTTP/1.1, 1.0 and 0.9.
> 
> Does anyone object to dropping the requirement to support versions of HTTP before 2?
> 
> Thanks,
> David
> -- 
> Masque mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/masque <https://www.ietf.org/mailman/listinfo/masque>
> -- 
> Masque mailing list
> [email-masked]

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 23 Mar 2021 13:53:44 +1100

My recollection is that this was discussed at length during chartering, and the resolution was that we'd make it version-independent, like other methods. If you want to re-visit that, I think we'd need to ask the whole HTTP WG, not just a couple of people.

Cheers,

> On 23 Mar 2021, at 9:39 am, Tommy Pauly <[email-masked]> wrote:
> 
> From https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#methods :
> 
>> On Thu, Mar 18, 2021 at 6:12 PM David Schinazi <[email-masked]> wrote:
>> Hi MASQUE enthusiasts,
>> 

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

---

From: Tommy Pauly <[email-masked]>
Date: Mon, 22 Mar 2021 19:56:59 -0700

Yes, that’s what I recall as well.

David, can we still go down the path of using frames in HTTP/3 and HTTP/2, while letting CONNECT-UDP have a more degenerate case for HTTP/1.1?

Tommy

> On Mar 22, 2021, at 7:53 PM, Mark Nottingham <[email-masked]> wrote:
>

---

From: David Schinazi <[email-masked]>
Date: Tue, 23 Mar 2021 15:42:17 -0700

Or we could have one document now that describes CONNECT-UDP over h2 and
h3, and a separate document that defines CONNECT-UDP over h1 later?
I'm not saying CONNECT-UDP should never support HTTP/1.1, I'm just saying
that maybe we don't need to design that yet.

Thoughts?
David

On Mon, Mar 22, 2021 at 7:57 PM Tommy Pauly <[email-masked]> wrote:

> David, can we still go down the path of using frames in HTTP/3 and HTTP/2,
> while letting CONNECT-UDP have a more degenerate case for HTTP/1.1?
>
> Tommy
>
> > My recollection is that this was discussed at length during chartering,
> and the resolution was that we'd make it version-independent, like other
> methods. If you want to re-visit that, I think we'd need to ask the whole
> HTTP WG, not just a couple of people.
> >
> > Cheers,
> >
> >
> >> While I understand the desire for this, I’m concerned about making a
> method that only works with some versions.
> >>
> >> From
> https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#methods
> :
> >>
> >> HTTP defines a number of generic extension points that can be used to
> introduce capabilities to the protocol without introducing a new version,
> including methods, status codes, field names, and further extensibility
> points within defined fields, such as authentication schemes and
> cache-directives (see Cache-Control extensions in Section 5.2.3 of
> [Caching]). Because the semantics of HTTP are not versioned, these
> extension points are persistent; the version of the protocol in use does
> not affect their semantics.
> >>
> >> Version-independent extensions are discouraged from depending on or
> interacting with the specific version of the protocol in use. When this is
> unavoidable, careful consideration needs to be given to how the extension
> can interoperate across versions.
> >>
> >>> I think this makes a lot of sense. As it stands today, anyone wishing
> to add UDP support would have to make changes to their client/server anyway
> -- I feel like the complexity we'd take on by continuing to support
> HTTP/1.1 and older isn't beneficial since we wouldn't be able to
> interoperate with existing implementations with the new features. Requiring
> HTTP/2 or newer lets us rely on a lot of nice things that have been added
> (like multiplexing) and not have to re-invent them in HTTP/1.1 just for UDP.
> >>>
> >>> Sincerely,
> >>> -Alex
> >>>
> >>> The CONNECT-UDP draft currently states "The CONNECT-UDP method is
> defined for all versions of HTTP." While supporting HTTP/3 is our top
> priority, and supporting HTTP/2 is necessary because of networks that block
> UDP, I'm not sure supporting versions of HTTP before 2 is useful.
> Additionally, it constrains our design space as HTTP/1.1 does not have the
> HTTP framing layer that HTTP/2 and HTTP/3 have. I would like to drop
> support for HTTP/1.1, 1.0 and 0.9.
> >>>

---

From: Ian Swett <[email-masked]>
Date: Tue, 23 Mar 2021 19:25:08 -0400

IMO it makes sense to align the h1 and h2 designs, since they're both
fallbacks we'd rather not use.  If h1+h2 lands after h3 in a different doc,
I don't see a problem with that, but I'm also fine with them being in a
single document.

In a surprising number of cases where h3 is blocked, h2 is blocked as
well(ie: Corp MITMs) and users will end up on h1.  Additionally, h1 is
still widely used behind load balancers/proxies.  As such, by the time this
becomes RFC, I wouldn't be surprised if there's more usage of it over h1
than h2.

I don't think the CONNECT-UDP design for h2 and h3 needs to share framing,
given h3 has datagrams and doesn't need frames transmitted on streams to
transmit UDP?

On Tue, Mar 23, 2021 at 6:42 PM David Schinazi <[email-masked]>
wrote:

>> David, can we still go down the path of using frames in HTTP/3 and
>> HTTP/2, while letting CONNECT-UDP have a more degenerate case for HTTP/1.1?
>>
>> Tommy
>>

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 24 Mar 2021 10:34:48 +1100

On Wed, Mar 24, 2021, at 10:25, Ian Swett wrote:
> fallbacks we'd rather not use.  

I believe that it should be possible to construct a unified design that works for all three versions.  That would be ideal from my perspective.

It means doing as I suggested at the last meeting and constraining HTTP/2 and HTTP/1.1 to using a single, ordered byte stream for everything it does (streams, datagrams, control messaging).  But I think that could be relatively easy to specify, necessary for other reasons, and simpler overall than what has been proposed thus far.

It might not be as good, but I think that we're all in agreement regarding the desirability of versions of this that aren't built on top of QUIC, so that seems like a tolerable trade-off to me.

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 24 Mar 2021 00:14:03 +0000

My preference would be towards a design that can operate over versions 1.x,
2 and 3 in order to avoid the opportunity cost tied to picking only a
subset. I do acknowledge this comes with challenges, at this time they do
not seem unsurmountable.

To echo some of the points made by Ian and Martin, the opportunity cost
from omitting HTTP/1.1 comes from friction to deploy, met by infrastructure
that does not support HTTP/2 or HTTP/3 end to end. For an infrastructure
that is composed of a chain of services (client-facing edge -> internal
service -> internal service -> target-facing edge), the actionable
requirements for something like CONNECT-UDP are often only needed at the
edges. For example, a server that validates CONNECT-UDP is permitted for
the authority or path, then delegates the target-connection logic to some
other thing up the chain. Supporting transformations between HTTP versions
can help avoid needing that entire chain to talk HTTP/2+. Defining a
standard transformation avoids the need to define proprietary means for
carrying the same information. As an example of what I mean, Cloudflare
relied on such a transformation strategy to help deploy gRPC [1] support.
The gRPC client spoke HTTP/2, the gRPC server spoke HTTP/2. But several
components in between them spoke gRPC-Web over HTTP/1.1.

Cheers
Lucas

[1] https://blog.cloudflare.com/road-to-grpc/

---

From: Alex Chernyakhovsky <[email-masked]>
Date: Tue, 23 Mar 2021 21:10:26 -0400

I don't think aligning h1 and h2 makes sense. h2 is closer to h3 than it is
to h1.

Sincerely,
-Alex

On Tue, Mar 23, 2021 at 7:25 PM Ian Swett <[email-masked]> wrote:

>>> > My recollection is that this was discussed at length during
>>> chartering, and the resolution was that we'd make it version-independent,
>>> like other methods. If you want to re-visit that, I think we'd need to ask
>>> the whole HTTP WG, not just a couple of people.
>>> >
>>> > Cheers,
>>> >
>>> >
>>> >>> I think this makes a lot of sense. As it stands today, anyone
>>> wishing to add UDP support would have to make changes to their
>>> client/server anyway -- I feel like the complexity we'd take on by
>>> continuing to support HTTP/1.1 and older isn't beneficial since we wouldn't
>>> be able to interoperate with existing implementations with the new
>>> features. Requiring HTTP/2 or newer lets us rely on a lot of nice things
>>> that have been added (like multiplexing) and not have to re-invent them in
>>> HTTP/1.1 just for UDP.
>>> >>>
>>> >>> Sincerely,
>>> >>> -Alex
>>> >>>

---

From: Ian Swett <[email-masked]>
Date: Tue, 23 Mar 2021 21:21:52 -0400

I agree in some ways Alex, but unfortunately I do think we need all 3 in
practice.  Additionally, for the purposes of CONNECT-UDP, both H1 and H2
are head of line blocking.

Given that, the options seem to be:
1) Define a thing we want and one fallback
2) Define a thing we want and two fallbacks

But possibly there's a large efficiency advantage to H2 framing vs framing
within H1 that I'm not considering?

On Tue, Mar 23, 2021 at 9:10 PM Alex Chernyakhovsky <[email-masked]>
wrote:

> I don't think aligning h1 and h2 makes sense. h2 is closer to h3 than it
> is to h1.
>
> Sincerely,
> -Alex
>
>> I don't think the CONNECT-UDP design for h2 and h3 needs to share
>> framing, given h3 has datagrams and doesn't need frames transmitted on
>> streams to transmit UDP?
>>
>>> I'm not saying CONNECT-UDP should never support HTTP/1.1, I'm just
>>> saying that maybe we don't need to design that yet.
>>>
>>> Thoughts?
>>> David
>>>
>>>> >> HTTP defines a number of generic extension points that can be used
>>>> to introduce capabilities to the protocol without introducing a new
>>>> version, including methods, status codes, field names, and further
>>>> extensibility points within defined fields, such as authentication schemes
>>>> and cache-directives (see Cache-Control extensions in Section 5.2.3 of

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 25 Mar 2021 13:41:21 +0000

I agree. I thought that the mapping is actually relatively straight forward though. With H2 you can have one CONNECT per stream (and no datagram support). For H1 you can only have one CONNECT per connection and you would open multiple TCP/HTTP connections for each forwarding request separately.

From: Masque <[email-masked]> on behalf of Alex Chernyakhovsky <achernya=[email-masked]>
Date: Wednesday, 24. March 2021 at 02:11
To: Ian Swett <[email-masked]>
Cc: David Schinazi <[email-masked]>, Mark Nottingham <[email-masked]>, Roy Fielding <[email-masked]>, Tommy Pauly <[email-masked]>, MASQUE <[email-masked]>
Subject: Re: [Masque] Dropping HTTP/1.x requirement for CONNECT-UDP

I don't think aligning h1 and h2 makes sense. h2 is closer to h3 than it is to h1.

Sincerely,
-Alex

On Tue, Mar 23, 2021 at 7:25 PM Ian Swett <[email-masked]<mailto:[email-masked]>> wrote:
IMO it makes sense to align the h1 and h2 designs, since they're both fallbacks we'd rather not use.  If h1+h2 lands after h3 in a different doc, I don't see a problem with that, but I'm also fine with them being in a single document.

In a surprising number of cases where h3 is blocked, h2 is blocked as well(ie: Corp MITMs) and users will end up on h1.  Additionally, h1 is still widely used behind load balancers/proxies.  As such, by the time this becomes RFC, I wouldn't be surprised if there's more usage of it over h1 than h2.

I don't think the CONNECT-UDP design for h2 and h3 needs to share framing, given h3 has datagrams and doesn't need frames transmitted on streams to transmit UDP?

On Tue, Mar 23, 2021 at 6:42 PM David Schinazi <[email-masked]<mailto:[email-masked]>> wrote:
Or we could have one document now that describes CONNECT-UDP over h2 and h3, and a separate document that defines CONNECT-UDP over h1 later?
I'm not saying CONNECT-UDP should never support HTTP/1.1, I'm just saying that maybe we don't need to design that yet.

Thoughts?
David

On Mon, Mar 22, 2021 at 7:57 PM Tommy Pauly <[email-masked]<mailto:[email-masked]>> wrote:
Yes, that’s what I recall as well.

Tommy

> On Mar 22, 2021, at 7:53 PM, Mark Nottingham <[email-masked]<mailto:[email-masked]>> wrote:
>
>> On 23 Mar 2021, at 9:39 am, Tommy Pauly <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> From https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#methods<https://protect2.fireeye.com/v1/url?k=57aa9374-0831aa71-57aad3ef-86d2114eab2f-8a67a28437e1dc6d&q=1&e=cd2d81ff-d165-41ed-836c-128d76921781&u=https%3A%2F%2Fhttpwg.org%2Fhttp-core%2Fdraft-ietf-httpbis-semantics-latest.html%23methods> :
>>
>>> On Mar 22, 2021, at 3:21 PM, Alex Chernyakhovsky <achernya=[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>> On Thu, Mar 18, 2021 at 6:12 PM David Schinazi <[email-masked]<mailto:[email-masked]>> wrote:
>>> Hi MASQUE enthusiasts,
>>>
>>> [email-masked]<mailto:[email-masked]>
>>> [email-masked]<mailto:[email-masked]>
> Mark Nottingham   https://www.mnot.net/<https://protect2.fireeye.com/v1/url?k=0c525adb-53c963de-0c521a40-86d2114eab2f-69a3e42f0cf4ffba&q=1&e=cd2d81ff-d165-41ed-836c-128d76921781&u=https%3A%2F%2Fwww.mnot.net%2F>
>
> --
> Masque mailing list
> [email-masked]<mailto:[email-masked]>
--
Masque mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/masque

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 25 Mar 2021 09:05:43 -0500

I'm actually following up on something Ian said earlier ...

On Thu, Mar 25, 2021 at 8:42 AM Mirja Kuehlewind <mirja.kuehlewind=
[email-masked]> wrote:

> I agree. I thought that the mapping is actually relatively straight
> forward though. With H2 you can have one CONNECT per stream (and no
> datagram support). For H1 you can only have one CONNECT per connection and
> you would open multiple TCP/HTTP connections for each forwarding request
> separately.
>
>
>
>
>
>
>
> *From: *Masque <[email-masked]> on behalf of Alex Chernyakhovsky
> <achernya=[email-masked]>
> *Date: *Wednesday, 24. March 2021 at 02:11
> *To: *Ian Swett <[email-masked]>
> *Cc: *David Schinazi <[email-masked]>, Mark Nottingham <
> [email-masked]>, Roy Fielding <[email-masked]>, Tommy Pauly <
> [email-masked]>, MASQUE <[email-masked]>
> *Subject: *Re: [Masque] Dropping HTTP/1.x requirement for CONNECT-UDP
>
>
>
> I know there's a conceptual reason for having mappings for h3, h2, and h1,
but if Ian's experience here is typical, how bad would it be if the
recommendation was to fall back from h3 to h1?

If h2 doesn't work on a path now, do we want to encourage those operators
to allow h2 and continue to block h3, rather than encouraging people to
allow h3?

Best,

Spencer

> <https://protect2.fireeye.com/v1/url?k=57aa9374-0831aa71-57aad3ef-86d2114eab2f-8a67a28437e1dc6d&q=1&e=cd2d81ff-d165-41ed-836c-128d76921781&u=https%3A%2F%2Fhttpwg.org%2Fhttp-core%2Fdraft-ietf-httpbis-semantics-latest.html%23methods>
> :
> >>
> <https://protect2.fireeye.com/v1/url?k=0c525adb-53c963de-0c521a40-86d2114eab2f-69a3e42f0cf4ffba&q=1&e=cd2d81ff-d165-41ed-836c-128d76921781&u=https%3A%2F%2Fwww.mnot.net%2F>
> >
> > --
> > Masque mailing list
> > [email-masked]

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 25 Mar 2021 08:19:58 -0700

> On Mar 25, 2021, at 7:05 AM, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> On Thu, Mar 25, 2021 at 8:42 AM Mirja Kuehlewind <mirja.kuehlewind=[email-masked] <mailto:[email-masked]>> wrote:
> From: Masque <[email-masked] <mailto:[email-masked]>> on behalf of Alex Chernyakhovsky <achernya=[email-masked] <mailto:[email-masked]>>
> To: Ian Swett <[email-masked] <mailto:[email-masked]>>
> Cc: David Schinazi <[email-masked] <mailto:[email-masked]>>, Mark Nottingham <[email-masked] <mailto:[email-masked]>>, Roy Fielding <[email-masked] <mailto:[email-masked]>>, Tommy Pauly <[email-masked] <mailto:[email-masked]>>, MASQUE <[email-masked] <mailto:[email-masked]>>
> On Tue, Mar 23, 2021 at 7:25 PM Ian Swett <[email-masked] <mailto:[email-masked]>> wrote:
> 
> I know there's a conceptual reason for having mappings for h3, h2, and h1, but if Ian's experience here is typical, how bad would it be if the recommendation was to fall back from h3 to h1? 
> 
> If h2 doesn't work on a path now, do we want to encourage those operators to allow h2 and continue to block h3, rather than encouraging people to allow h3?

The specifics of how a given implementation falls back for a particular scenario are, I think, a bit out of scope. I think we need to be able to use H3, H2, or H1, overall.

While there may be scenarios that are doing man-in-the-middle attacks/techniques that force things back to H1, there are also cases where a client would disallow any such man-in-the-middle attack and would prefer to fail hard. So, I have scenarios were I would accept falling back to H2, but would not accept falling back to H1.

Tommy

> On Tue, Mar 23, 2021 at 6:42 PM David Schinazi <[email-masked] <mailto:[email-masked]>> wrote:
> 
> On Mon, Mar 22, 2021 at 7:57 PM Tommy Pauly <[email-masked] <mailto:[email-masked]>> wrote:
> 
> > On Mar 22, 2021, at 7:53 PM, Mark Nottingham <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> >> On 23 Mar 2021, at 9:39 am, Tommy Pauly <[email-masked] <mailto:[email-masked]>> wrote:
> >> 
> >> From https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#methods <https://protect2.fireeye.com/v1/url?k=57aa9374-0831aa71-57aad3ef-86d2114eab2f-8a67a28437e1dc6d&q=1&e=cd2d81ff-d165-41ed-836c-128d76921781&u=https%3A%2F%2Fhttpwg.org%2Fhttp-core%2Fdraft-ietf-httpbis-semantics-latest.html%23methods> :
> >> 
> >>> On Mar 22, 2021, at 3:21 PM, Alex Chernyakhovsky <achernya=[email-masked] <mailto:[email-masked]>> wrote:
> >>> 
> > Mark Nottingham   https://www.mnot.net/ <https://protect2.fireeye.com/v1/url?k=0c525adb-53c963de-0c521a40-86d2114eab2f-69a3e42f0cf4ffba&q=1&e=cd2d81ff-d165-41ed-836c-128d76921781&u=https%3A%2F%2Fwww.mnot.net%2F>
> > 
> > -- 
> > Masque mailing list
> https://www.ietf.org/mailman/listinfo/masque <https://www.ietf.org/mailman/listinfo/masque>-- 
> Masque mailing list

---

From: Alex Chernyakhovsky <[email-masked]>
Date: Thu, 25 Mar 2021 14:14:36 -0400

Hi Spencer,

Can you please double-check if if all the instances of h1, h2, h3 you wrote
are correct? I'm having trouble parsing your message.

I also want to add that I don't think restricting ourselves to h1 if h3
fails makes much sense. h2 has benefits, and IMO we should use them over h1
if h3 is unavailable.

Sincerely,
-Alex

On Thu, Mar 25, 2021 at 10:06 AM Spencer Dawkins at IETF <
[email-masked]> wrote:

>> *From: *Masque <[email-masked]> on behalf of Alex
>> Chernyakhovsky <achernya=[email-masked]>
>> I know there's a conceptual reason for having mappings for h3, h2, and
> h1, but if Ian's experience here is typical, how bad would it be if the

---

From: Ian Swett <[email-masked]>
Date: Thu, 25 Mar 2021 14:54:58 -0400

I agree that I think we need all 3 versions and didn't intend my message to
indicate that an h2 version shouldn't be created, but rather that I expect
an h1 may be used quite widely.

In terms of MITMs, David Schinazi pointed out that MITMs which block QUIC
may also block CONNECT-UDP, and time will tell on that.

On Thu, Mar 25, 2021 at 2:14 PM Alex Chernyakhovsky <[email-masked]>
wrote:

> Hi Spencer,
>
> Can you please double-check if if all the instances of h1, h2, h3 you
> wrote are correct? I'm having trouble parsing your message.
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 25 Mar 2021 14:56:43 -0500

Dear All,

On Thu, Mar 25, 2021 at 1:55 PM Ian Swett <[email-masked]> wrote:

> I agree that I think we need all 3 versions and didn't intend my message
> to indicate that an h2 version shouldn't be created, but rather that I
> expect an h1 may be used quite widely.
>

Thanks for helping me understand. I was curious because I thought I saw
some people suggesting that it would be helpful to do the h2 and h3
mappings first, and h1 mapping later, and other people saying that h1
mapping mattered a lot.

If we have to do all three, do we need to do all three at the same time?

Best,

Spencer

>>> If h2 doesn't work on a path now, do we want to encourage those
>>> operators to allow h2 and continue to block h3, rather than encouraging
>>> people to allow h3?
>>>
>>> Best,
>>>
>>> Spencer
>>>
>>>>
>>>>
>>>> On Tue, Mar 23, 2021 at 6:42 PM David Schinazi <
>>>> [email-masked]> wrote:
>>>>
>>>> Or we could have one document now that describes CONNECT-UDP over h2
>>>> and h3, and a separate document that defines CONNECT-UDP over h1 later?
>>>>

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 26 Mar 2021 08:08:02 -0700

> On Mar 25, 2021, at 12:56 PM, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Dear All, 
> 
> On Thu, Mar 25, 2021 at 1:55 PM Ian Swett <[email-masked] <mailto:[email-masked]>> wrote:
> I agree that I think we need all 3 versions and didn't intend my message to indicate that an h2 version shouldn't be created, but rather that I expect an h1 may be used quite widely.
> 
> Thanks for helping me understand. I was curious because I thought I saw some people suggesting that it would be helpful to do the h2 and h3 mappings first, and h1 mapping later, and other people saying that h1 mapping mattered a lot. 
> 

That was the original question, but my sense of this thread (which I agree with) is that all versions ought to be specified at the same time. HTTP versions are often used back-to-back as communication traverses intermediaries, and any solution that leaves out some versions, even only temporarily, is not fully-fledged.

Best,
Tommy

> 
> Best,
> 
> Spencer
>  
> In terms of MITMs, David Schinazi pointed out that MITMs which block QUIC may also block CONNECT-UDP, and time will tell on that.
> 
> 
> 
> On Thu, Mar 25, 2021 at 2:14 PM Alex Chernyakhovsky <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Spencer,
> 
> Can you please double-check if if all the instances of h1, h2, h3 you wrote are correct? I'm having trouble parsing your message.
> 
> I also want to add that I don't think restricting ourselves to h1 if h3 fails makes much sense. h2 has benefits, and IMO we should use them over h1 if h3 is unavailable.
> 
> Sincerely,
> -Alex
> 
> 
> On Thu, Mar 25, 2021 at 10:06 AM Spencer Dawkins at IETF <[email-masked] <mailto:[email-masked]>> wrote: