- From: Willy Tarreau <w@1wt.eu>
- Date: Thu, 1 Aug 2019 06:41:08 +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 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
Received on Thursday, 1 August 2019 04:41:39 UTC