- From: Willy Tarreau <w@1wt.eu>
- Date: Thu, 1 Aug 2019 06:48:20 +0200
- To: Lucas Pardue <lucaspardue.24.7@gmail.com>
- Cc: Kari Hurtta <hurtta-ietf@elmme-mailer.org>, HTTP Working Group <ietf-http-wg@w3.org>, Brad Lassey <lassey@chromium.org>
On Thu, Aug 01, 2019 at 06:41:08AM +0200, Willy Tarreau wrote: > On Wed, Jul 31, 2019 at 08:14:24PM +0100, Lucas Pardue wrote: > > > If initial value for SETTINGS_ENABLE_HTTP2_PRIORITIES is really 1, > > > then peer may assume that other ends supports HTTP/2 priorities > > > until SETTINGS_ENABLE_HTTP2_PRIORITIES is seen. > > > > > > So there is inconsistence between chapters. > > > > > > / Kari Hurtta > > > > > > > Agreed. We should tighten this up for something that is practically > > deployable and meets the needs of implementers. Ideally we can take > > feedback so far and iterate through the design team process. > > I think the confusing part comes from the ENABLE word in the setting > name. We could proceed differently by exchanging a supported model > for priorities : SETTINGS_HTTP2_PRIORITY_MODEL > It could then take the following values : > > 0 (default) : as specified in RFC7540 > 1 : priorities not sent and silently ignored > 2 and above : to be documented in future specifications > > This way it seems more natural to consider that unless advertised, we > stay on RFC7540 and nothing changes. I've just seen the other proposal for SETTINGS_PRIORITY_SCHEME (which sounds better) and which seems fairly similar, I'm fine with this as well of course. Willy
Received on Thursday, 1 August 2019 04:48:47 UTC