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

> On Oct 28, 2020, at 2:03 AM, Luke Curley <kixelated@gmail.com> wrote:
> 
> 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.

Just curious: if they share everything but the wire protocol, then are there significant use cases where we’d expect someone to need or only support one wire protocol over another? In other words, if they share everything but a wire protocol, why do we need two wire protocols? 
(There may be completely sensible reasons for this, just thought I’d ask since I thought we’d previously been discussing choosing one or the other as a layering decision, rather than maintaining both.)

Thanks,
Eric

> 
> On Tue, Oct 27, 2020 at 10:40 PM Martin J. Dürst <duerst@it.aoyama.ac.jp <mailto:duerst@it.aoyama.ac.jp>> 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.
> 
> -- 
> Webtransport mailing list
> Webtransport@ietf.org
> https://www.ietf.org/mailman/listinfo/webtransport