IETF Logo Mail Archive

Re: [Webtransport] Confirming Consensus on WebTransport protocols

Ian Swett <ianswett@google.com> Thu, 14 January 2021 15:34 UTC

Return-Path: <ianswett@google.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 A77203A1565 for <webtransport@ietfa.amsl.com>; Thu, 14 Jan 2021 07:34:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.971
X-Spam-Level:
X-Spam-Status: No, score=-17.971 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.373, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 XbHHvpUc8J-k for <webtransport@ietfa.amsl.com>; Thu, 14 Jan 2021 07:34:51 -0800 (PST)
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 4E6D83A155A for <webtransport@ietf.org>; Thu, 14 Jan 2021 07:34:51 -0800 (PST)
Received: by mail-wr1-x42d.google.com with SMTP id t16so6215224wra.3 for <webtransport@ietf.org>; Thu, 14 Jan 2021 07:34:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=58/AvykbqMQE4kiUDdr6FFPsf3W/9lMQI3NxUSuRY90=; b=f5Z1AxLc4n74HEaw9JrKkTd8KUzuapnr7oULpKkJIDik+/iZR4QolD9bstFdQVUfB5 mH/lFXJnufLCclaNgA2CjKmVYn6xGwuzvHektZEJeSz8qMR6zXFRO9xJXUSIIeCwIMJU q3DZELhksitiDqgpe/zVahDbgMy4IJEJhnmlv8NgEzjklx7KC2kXF8bpDBmwk2qjzEl3 /5xkRnUUOP/T9iztqflvMV1eQOYF17lQDwQigiyvXQbLHEkSh3VHoXd4N4U8BT01YWsZ cXJrELMqvtWEIf3dakV4tWmWwVa6JadaLdq3JoScX9wXpjgOabO81z+aOLwlFc4xPlUc kkRw==
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=58/AvykbqMQE4kiUDdr6FFPsf3W/9lMQI3NxUSuRY90=; b=tyucXyYEKU9N2Iv5lcCsUjyDs79spGRO8FblRzRcIIm08t87mcbWDRte5N2k2eQ9q5 z/RFIkRSYiSCtStR2xM9Ubu7iAOPGd8zHWa+kqR3pR6FTzKp9W5NJ8X+F4A7Op3Ck9c2 NoqDd11gE2Qde3rc0MFFhDa23rJDtxLp0lDkgt9tP0zulqd5vJE9vjyoy7kIKaB0PPlN MLPGAzl/i4Kps6O1QX0eHPkxN+XSUN/xZpV2xOOtUWnKQwy5I1dEOiD773qNQq8Cpc8B t/WvrhEECyCkW+uT1Cj6Ut9SmL3RHTNr1PO726jUd4m1pEbzGSgrCxmWEypcFV4PgILm jvpw==
X-Gm-Message-State: AOAM532u4ljvhB61h0e3jX3EeTbZDOE1+DkCV/Gx8GU5B20+jDixD7CX POFTgW7fPUdq7Uw4BNZaZaGq5cYH2Q6IdLmwczPuVw==
X-Google-Smtp-Source: ABdhPJwgwIMmlCywkbE7YlmnzuUelE4extkl57aX+RStrZSR/JE9ruOhvD4ZDkVwByOPmkXq6RR2E/46RKFmUmR214Y=
X-Received: by 2002:adf:f707:: with SMTP id r7mr8802316wrp.113.1610638489607; Thu, 14 Jan 2021 07:34:49 -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> <CALGR9obUHRn9Y-eXZjnUMQU22ZnLcw0RLs7FhrrrZOd9OM63yA@mail.gmail.com>
In-Reply-To: <CALGR9obUHRn9Y-eXZjnUMQU22ZnLcw0RLs7FhrrrZOd9OM63yA@mail.gmail.com>
From: Ian Swett <ianswett@google.com>
Date: Thu, 14 Jan 2021 10:34:37 -0500
Message-ID: <CAKcm_gMaDD7ZGsg5xdaQ01y6DzkWQ+u4k1btFQEL5oLrX7bbxg@mail.gmail.com>
To: Lucas Pardue <lucaspardue.24.7@gmail.com>
Cc: Ian Swett <ianswett=40google.com@dmarc.ietf.org>, WebTransport <webtransport@ietf.org>, Martin Thomson <mt@lowentropy.net>
Content-Type: multipart/alternative; boundary="000000000000094c8405b8ddff22"
Archived-At: <https://mailarchive.ietf.org/arch/msg/webtransport/AEapSOI4JaScCgeZBRFOdbi3Zs8>
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: Thu, 14 Jan 2021 15:34:54 -0000

On Wed, Jan 13, 2021 at 11:45 AM Lucas Pardue <lucaspardue.24.7@gmail.com>
wrote:

> 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.
>

Thanks, I hadn't seen that PR.

After re-reading the editors copy of both documents, I'm much happier with
Http3Transport than I was yesterday, because I had some misunderstandings.
It also makes me very happy we allow Type-Value frames with no length in
HTTP/3.


>
> Cheers,
>
> Lucas
> --
> Webtransport mailing list
> Webtransport@ietf.org
> https://www.ietf.org/mailman/listinfo/webtransport
>

v2.23.0 | Report a Bug | By Email