Until HTTP offers chunk-extensions again, I don’t see how it can be otherwise?
-=R
From: QUIC <quic-bounces@ietf.org> on behalf of Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Thursday, March 5, 2020 at 12:24 PM
To: Ian Swett <ianswett@google.com>
Cc: QUIC WG <quic@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: New Version Notification for draft-ietf-httpbis-priority-00.txt
Hi Ian,
On Thu, Mar 5, 2020 at 6:17 PM Ian Swett <ianswett@google.com<mailto:ianswett@google.com>> wrote:
Thanks for updating this draft.
On the point of headers vs frame, based on my experience leading the design team and the slightly wider scope of use cases that are now on the table, which includes server-side reprioritization, I see the compromise of having both a frame and a header as the only way forward which has the ability to gain consensus. I also truly believe there are valid use cases for both.
I propose we should own that position and seek to describe the properties of each clearly.
Thanks, Ian
Thanks for sharing your current thinking. Clarification question, the present design has an symmetrical design that constrains when and where where the signal carrier is used: headers are used for initial priority, and frames are used for reprioritization. You position supports both carriers but does it support this constraint?
I'd also welcome other people's thoughts on this topic.
Lucas