IETF Logo Mail Archive

Re: [Webtransport] Confirming Consensus on WebTransport protocols

Lucas Pardue <lucaspardue.24.7@gmail.com> Wed, 13 January 2021 16:45 UTC

Return-Path: <lucaspardue.24.7@gmail.com>
X-Original-To: webtransport@ietfa.amsl.com
Delivered-To: webtransport@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEFE53A11BE for <webtransport@ietfa.amsl.com>; Wed, 13 Jan 2021 08:45:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Level:
X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drMaVpdVhhKr for <webtransport@ietfa.amsl.com>; Wed, 13 Jan 2021 08:45:03 -0800 (PST)
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B68933A11BC for <webtransport@ietf.org>; Wed, 13 Jan 2021 08:45:02 -0800 (PST)
Received: by mail-ed1-x532.google.com with SMTP id g1so1994749edu.4 for <webtransport@ietf.org>; Wed, 13 Jan 2021 08:45:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GILOD9yNAZYu2/y28sC5cCfkFzpm03oEN0cxx2CrSfs=; b=pqe8CU3RZUFvRcQnbbTdCKNg/FtGFI1VR2vkjxY0jbIMVoewP13ttNPMzAAjYE35b6 AdxlyBrB322JsZviMhNi6rcaKbl9c5lx6cLjzYpbLqxNpX4tqmzqZsS96nkHNIoAzkIm OIGRodpH9OAdU9JNTL5N7iBKOP4oQPwpx/NYQ4cfpBFME3qIXn/OCMVLzqYAnUmEfsuk KXKuhHl+AqJtirtY9MMo5hMscbvvobI6JhD0qZUPxIa4eIIMorPMj20zPWtZiQOtTH1y dzSxq8EJXcGWPh5B53LqtIBfluFr7SHGbkh2ecn7RY6LaNJQq5BjtmYeJvlqtxezT9Qw PuHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GILOD9yNAZYu2/y28sC5cCfkFzpm03oEN0cxx2CrSfs=; b=nQPyIQlZuJ6K3ddgfOiExedpWw9JWdHRdyaULDkZaQO8vl1FBIO5xlZWbBhtBgaI1g rhhNqhYfPiQR4P8VkB/22EAsEVoaL9r+/eoNw0i0+XCktBBkPcIrqvSESeQGDB01hwOC pagFpZC7F10m9RZ2TAylwHI0gsFWR0V0elK4ZP0eZ2QZ6Mn62U5GmtbC81oVAdwAz/8m sePo6B7/Fa6WCHlyzuyPPMK2k8Fb2aTaSBMwpw5tiGg1sS31wUp1SYhSN5A4MOJQ4Wd0 1SnLZxsc6ybMt4EOPU8AJm2ixTd80ohyDk40jMUEveZVAgaV1PcjWEOrQo+x3/zApM5l bsgQ==
X-Gm-Message-State: AOAM531wSNohWpBb/77xRDXK9MzqcTFqpIEBu4aNErj8CI5DnhVe/P1e BZNPpQAhU2qQt7IiRiMDnp9kjyLFSirilAchseRpfyQy+Dk=
X-Google-Smtp-Source: ABdhPJxQpcZAjgEnn4JSGpeXo9GPoE4XVVsehmwHAGa+7UrYJMdi1ycN71EWM8j0heKtWH18ojIJY/+CVGkbIFjhPXk=
X-Received: by 2002:a05:6402:c4:: with SMTP id i4mr2466516edu.152.1610556301213; Wed, 13 Jan 2021 08:45:01 -0800 (PST)
MIME-Version: 1.0
References: <CAPDSy+5R=v2GjyJU1o=+Ai0X0iOqJSX787GfLBSUkd9odR++Rw@mail.gmail.com> <1003bdcf-dc36-47ce-a4f5-dcfd9b2146b8@www.fastmail.com> <CAKcm_gO6VCip7bkrJMjDn4D5sjPMQMRhW2BnV5z6RK+MiUfMkg@mail.gmail.com>
In-Reply-To: <CAKcm_gO6VCip7bkrJMjDn4D5sjPMQMRhW2BnV5z6RK+MiUfMkg@mail.gmail.com>
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Wed, 13 Jan 2021 16:44:49 +0000
Message-ID: <CALGR9obUHRn9Y-eXZjnUMQU22ZnLcw0RLs7FhrrrZOd9OM63yA@mail.gmail.com>
To: Ian Swett <ianswett=40google.com@dmarc.ietf.org>
Cc: Martin Thomson <mt@lowentropy.net>, WebTransport <webtransport@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003984d405b8cadc27"
Archived-At: <https://mailarchive.ietf.org/arch/msg/webtransport/sLpcMae3TcnTLUWSASusg5Ucu6Y>
Subject: Re: [Webtransport] Confirming Consensus on WebTransport protocols
X-BeenThere: webtransport@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <webtransport.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/webtransport>, <mailto:webtransport-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/webtransport/>
List-Post: <mailto:webtransport@ietf.org>
List-Help: <mailto:webtransport-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/webtransport>, <mailto:webtransport-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Jan 2021 16:45:06 -0000

Hi Ian,

On Wed, Jan 13, 2021 at 3:46 PM Ian Swett <ianswett=
40google.com@dmarc.ietf.org> wrote:

>
>
> On Tue, Jan 12, 2021 at 7:02 PM Martin Thomson <mt@lowentropy.net> wrote:
>
>> On Wed, Jan 13, 2021, at 04:25, David Schinazi wrote:
>> > The consensus was option 1A.
>>
>> Great!
>>
>> > The consensus was option 2A.
>>
>> I can live with that.  Can I request a brief summary of the reasons?
>>
>
> I asked a question like this during the interim, and I think it'd be worth
> clearly documenting the reasons, as I think it'd clarify our direction a
> bit.  The one that I clearly recall is that we'd have to re-invent many of
> the features that HTTP/3 provides, but I'm not clear why that's the case.
>

I made a comment along those lines. It was mainly motivated by Victor's PR
"Refactor client indication into a full header exchange" see
https://github.com/vasilvv/webtransport/pull/18. AFAICT this is merged into
the editors copy of draft-vvv-webtransport-quic but there is no published
I-D with this change in. Victor please correct me if I'm wrong.

Not that I'm not questioning whether the motivation behind needing more
flexibility of the client indication. But it highlights that we'll discover
more things that are needed or nice to have and require additions. My
concern is that inventing something that is similar to HTTP headers but not
actually HTTP is duplication and brings risks that we need to mirror the
engineering and design effort that has already gone into HTTP. As an
implementer, it seems better to reuse HTTP semantics (i.e code I have
already, or libraries) than to invent another HTTP-alike.

Cheers,

Lucas

v2.23.0 | Report a Bug | By Email