From nobody Wed Jan 13 07:29:53 2021 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B723A116A for ; Wed, 13 Jan 2021 07:29:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 JjJmSxmazzrP for ; Wed, 13 Jan 2021 07:29:46 -0800 (PST) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 B01763A114D for ; Wed, 13 Jan 2021 07:29:46 -0800 (PST) Received: by mail-io1-xd33.google.com with SMTP id b19so2374213ioa.9 for ; Wed, 13 Jan 2021 07:29:46 -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=K8bOtCrs8YRmilxp9kWc27QUv674436E+T2QQXMFLzk=; b=dl3GC/XKv6P+edn00Gv6ILf8MYIO51HgVS+xoGHaibjtd5S2u/Fuf+zK16bxFPuXrF QCqyA0t8QhHf88AxUcbNgM32mWYWR8DkAWk+/JpIobg1fsVfp5gqKfUXAxdftW3kdM2N XeDpJ5NECWuDOxaaomPNbKjeVER6gf3Ok1rINdOhRUUoDTGpAaCNGUBDA54WOKJ2zD8r YK+68Q+KP6QPX9NIFVbSujJQ27gFVSNJLuFtu8rRv2ACzFveFr8ESQhulvgwuh32Tt6r kCxLYBjX809MjTzyK88DfRhozUzxJ4Od0Kyzi3kbfWjlV8Z4PQdzNsEsOobko8EDtnLE 7/oQ== 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=K8bOtCrs8YRmilxp9kWc27QUv674436E+T2QQXMFLzk=; b=BOopWbvH26/8eK/Kuk4uThT4X6uQHEfz6aI4narO7Gd/SM7sivq/dccIkHAdsQGr4Y 2OWwRlmiFX+mTSWbCxKIGX7NJTQHOsHztW1TwEad0PLgZahQGD+omrnY/gj9c05hgRop WBqaHoINOObkaTIylIlGhsQ4xBfM5Ll2okMFC5CRzp0K3gFevHh3V7YaJPCsFcESaFPS KWUS1Cj3QqYOY9cfVkjM4kUCjO8U2HHlyqc6SEYFXL5QFEkQ5kOMUa4fTIPqGPPe8vvD tIJDKmnsOGIQ8jAHAuyG0P1Ry5uyVRJZYHTUOgSna2l62GguhuAOb9D35PZSo0D6od9q 2Jtg== X-Gm-Message-State: AOAM530aKc2s0pGl/ZeFTP2jrveWPnahyVzYxeXgk8+pl6t1X7Pf+oHh uUXKIrThaC8o1G6M/AH3YaFPnraz81I9ySCMeq4= X-Google-Smtp-Source: ABdhPJwBIvzHWtoHsyxYJgfa5hKaR4Em6hpiX2fkF3hv0fk4s9TOL9S3BUVnVd9zXiKX/d09qwG87F1yGPgMW600nWk= X-Received: by 2002:a92:da85:: with SMTP id u5mr2810758iln.249.1610551785770; Wed, 13 Jan 2021 07:29:45 -0800 (PST) MIME-Version: 1.0 References: <029bd6e66fb81e2ecf16e35adf30b90c816c9962.camel@ericsson.com> In-Reply-To: <029bd6e66fb81e2ecf16e35adf30b90c816c9962.camel@ericsson.com> From: Martin Duke Date: Wed, 13 Jan 2021 07:29:47 -0800 Message-ID: Subject: Re: HTTP Delays To: Magnus Westerlund Cc: "ted.ietf@gmail.com" , "quic@ietf.org" Content-Type: multipart/alternative; boundary="00000000000015550b05b8c9cfd9" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2021 15:29:51 -0000 --00000000000015550b05b8c9cfd9 Content-Type: text/plain; charset="UTF-8" To summarize, I think there are three options: 1) Don't publish any RFCs until httpbis-semantics and httpbis-cache are in the RFC Ed queue 2) Publish QUIC ASAP without HTTP/3, and suggest that deployed endpoints run QUICv1 with ALPN h3-29/32/34 or whatever 3) Publish QUIC and HTTP/3 ASAP with a downref, allow ALPN h3 to deploy, and hope nothing important changes in the httpbis docs. The second sounds cleanest to me, but I can certainly be persuaded of the others. On Wed, Jan 13, 2021 at 2:41 AM Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi, > > My current judgment is also that this will result in that the HTTP/3 and > QPACK > specs will end up in missref due to these references. I don't think there > is an > good option. The new HTTP specs are substantial rewrites so going back to > RFC > 723x doesn't make sense here, and likely include substantial amount of > work. > > I do think the WG do need to be clear if the message is to stay with the > the > prelimenary versions, if that is h-29 or declare a h-34 based on the > forthcoming > -34 versions and what to do with salts and keys. > > Cheers > > Magnus > > --00000000000015550b05b8c9cfd9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To summarize, I think there are three options:
<= div>1) Don't publish any RFCs until httpbis-semantics and httpbis-cache= are in the RFC Ed queue
2) Publish QUIC ASAP without HTTP/3, and= suggest that deployed endpoints run QUICv1 with ALPN h3-29/32/34 or whatev= er
3) Publish QUIC and HTTP/3 ASAP with a downref, allow ALPN h3 = to deploy, and hope nothing important changes in the httpbis docs.

The second sounds cleanest to me, but I can certainly be p= ersuaded of the others.

On Wed, Jan 13, 2021 at 2:41 AM Magnus Wes= terlund <magnus.wester= lund@ericsson.com> wrote:
Hi,

My current judgment is also that this will result in that the HTTP/3 and QP= ACK
specs will end up in missref due to these references. I don't think the= re is an
good option. The new HTTP specs are substantial rewrites so going back to R= FC
723x doesn't make sense here, and likely include substantial amount of = work.

I do think the WG do need to be clear if the message is to stay with the th= e
prelimenary versions, if that is h-29 or declare a h-34 based on the forthc= oming
-34 versions and what to do with salts and keys.

Cheers

Magnus

--00000000000015550b05b8c9cfd9--