Re: New Version Notification for draft-ietf-httpbis-priority-00.txt

Lucas Pardue <> Thu, 05 March 2020 20:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E96183A0ADF for <>; Thu, 5 Mar 2020 12:08:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.75
X-Spam-Status: No, score=-2.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KFb0Nb94aOJD for <>; Thu, 5 Mar 2020 12:08:20 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 83B0D3A0ADE for <>; Thu, 5 Mar 2020 12:08:20 -0800 (PST)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1j9wkN-0001Ir-AL for; Thu, 05 Mar 2020 20:05:31 +0000
Resent-Date: Thu, 05 Mar 2020 20:05:31 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1j9wkH-0001I4-SF for; Thu, 05 Mar 2020 20:05:25 +0000
Received: from ([2a00:1450:4864:20::332]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1j9wkG-0004l9-7q for; Thu, 05 Mar 2020 20:05:25 +0000
Received: by with SMTP id i14so222675wmb.1 for <>; Thu, 05 Mar 2020 12:05:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WsLVrwwMcZkicuzq18XfujWVlOHNo+HeLWGWYaZCB3E=; b=LYbNwNZivrAT2bWSbZ4nV/DcurTefR1qirFk2ps39MExvd8nzGv91s2mdQC9XDw6Wl vrI7Od+K++xvpKf9UfBUuFR7dfd8jx3bQBIQnJfsQ+x4mACZA71HpYMJIziFzirttqK1 CzObIY0ZAcsl5dP2pNjaAkCSlQcjedGPzC/ISD1xJ0CiraxvRqXOR59EdxhqZGIqGYnh D+N/0RdfAlahEsSl1eEdhA/OOM/491uza5L+DD3QB2V89zsQW204GCThLG0oPbvtqP7z u+JaSnPNwD3eavsZCbub8hkenZ4sq9NwyjurIzqdDxr16JiaSXm3fC0e5LyQh7eahw+o I0QQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WsLVrwwMcZkicuzq18XfujWVlOHNo+HeLWGWYaZCB3E=; b=ceoYgCV72NVvoIpFdLN5nlN3b0mvbM4ByuBQdXLXgwTeCYpu5CJJ8Zc1k9VcWf6S1a DZ5lK8OZxSmMxAUYdP1hDwb0vP7zRnuOvojyFEp5N9phoE6Gf1Z6PeGQ9ar0QmwEPbA4 Otw9pCuC9USMhtUvbvAO5BxAHIfrUv65HQUM1gTorQmxKS81POh1Zc3YNpYZ7pvK+ak5 0oSWGWBPg6gSZhab7blp7e9+KUf26OuARAbMQJ4cWq2pYsdx8PJpPZ9zWvc1hlI1axHq Gbu2U3hGwdXnJvv2K53Ch4rslncI69Cg81oVBCx2qDAkXY8FlPuaoQXIpjLPgsmCaBlE vcpw==
X-Gm-Message-State: ANhLgQ1TS4JRU69Y1cjbWR4ZiyD/QH6vYaoDY9pDrcduuumJr07oQnCq Etl9XVq64+AlDwhUgVMGIWLR4osxaRxLCzAbGdg=
X-Google-Smtp-Source: ADFU+vugmBSoo1WJRXhRpMXt6jwPpyYDSy+VfQ/5lK7HScaSrfGt5werbklMjdZZn+ssQWwjip++cOC8mOjzynT14SI=
X-Received: by 2002:a1c:9c87:: with SMTP id f129mr507734wme.26.1583438712424; Thu, 05 Mar 2020 12:05:12 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Lucas Pardue <>
Date: Thu, 05 Mar 2020 20:05:01 +0000
Message-ID: <>
To: Ian Swett <>
Cc: HTTP Working Group <>, QUIC WG <>
Content-Type: multipart/alternative; boundary="000000000000fa4e3a05a0210d58"
Received-SPF: pass client-ip=2a00:1450:4864:20::332;;
X-W3C-Hub-Spam-Status: No, score=-3.8
X-W3C-Scan-Sig: 1j9wkG-0004l9-7q e58b52fed941bb04a7ea00d7c2c6559e
Subject: Re: New Version Notification for draft-ietf-httpbis-priority-00.txt
Archived-At: <>
X-Mailing-List: <> archive/latest/37410
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Thu, Mar 5, 2020 at 7:51 PM Ian Swett <> wrote:

> The draft is written with that in mind, but there's no requirement in
> design or the draft that an implementation can only use the header for
> initial prioritization.  Chrome uses the frame for initial priority and
> updates and it seems to work fine.  Obviously only the frame can be used
> for reprioritization.  I expect Google HTTP/3 servers will end up
> supporting both.
> But I think the draft should be updated to describe the frame as HBH and
> able to be used for either initial or priority updates.
> In practice, due to reordering, implementations need to handle receiving
> the frame prior to the request anyway.
> I hope that clarifies my thinking, Ian

Based on your implementation experience, would you be happy with the frame
being restricted to only being sent on the control stream? Or do you see
some need for allowing that frame on the request stream (noting that doing
so adds challenges to making it work with HTTP/2)?