Re: [Webtransport] Choosing the Transport, pt. 2

[Luke Curley <[e-mail]>]

Sorry, I was trying to be too terse and should explain.

The QuicTransport indication involves an origin and a path using a custom
encoding. Like Victor mentioned, these are very similar to existing HTTP
headers and could be encoded as such. This would reduce the differences
between QuicTransport and Http3Transport.

Http3Transport establishes the connection with HTTP headers but then
ditches the HTTP semantics. It instead exposes the underlying QUIC
connection and offers the same API as QUIC and QuicTransport.

I was trying to express that QuicTransport and Http3Transport are
converging. You can look at this in one of two ways: Either there's not
enough differences to justify two protocols, or there are so few
differences that they can share everything but the wire protocol.

On Tue, Oct 27, 2020 at 10:40 PM Martin J. Dürst <[e-mail]>
wrote:

> On 28/10/2020 09:34, Luke Curley wrote:
> > Yeah, I definitely agree that there's a grey area between QuicTransport
> and
> > Http3Transport. The QuicTransport indication is similar to HTTP, while
> > HttpTransport behaves like QUIC.
>
> I'm confused by the last sentence. Reformatting it, it reads:
>
> The   QuicTransport indication is similar to HTTP,
> while HttpTransport behaves       like       QUIC.
>
> Is that a typo, or does this crossover naming carry some deep
> philosophical meaning that I didn't get?
>
> Regards,   Martin.
>
> > But I think the decision to implement multiple protocols needs to be more
> > objective. Every WebTransport variant should add functionality or provide
> > backwards compatibility. Otherwise we'll be defining and implementing
> > standards that serve no purpose.
>
>