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

+1 to Victor. The server implementation cost is convincing to me.

On Thu, Oct 29, 2020 at 3:43 AM Eric Kinnear <ekinnear=
40apple.com@dmarc.ietf.org> wrote:

>
>
> 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>
> 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
>
>
> --
> Webtransport mailing list
> Webtransport@ietf.org
> https://www.ietf.org/mailman/listinfo/webtransport
>