- From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
- Date: Thu, 1 Aug 2019 08:09:16 +0300 (EEST)
- To: Willy Tarreau <w@1wt.eu>, HTTP Working Group <ietf-http-wg@w3.org>
- CC: Lucas Pardue <lucaspardue.24.7@gmail.com>, Kari Hurtta <hurtta-ietf@elmme-mailer.org>, HTTP Working Group <ietf-http-wg@w3.org>, Brad Lassey <lassey@chromium.org>
> 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. > > Willy This is almost same than my SETTINGS_PRIORITY_SCHEME suggestion. It have only 1 and 0 flipped. https://lists.w3.org/Archives/Public/ietf-http-wg/2019JulSep/0140.html Then incompatibility with HTTP/3's SETTINGS frame was cited. https://lists.w3.org/Archives/Public/ietf-http-wg/2019JulSep/0141.html / Kari Hurtta
Received on Thursday, 1 August 2019 05:09:50 UTC