- From: Brad Lassey <lassey@google.com>
- Date: Thu, 25 Jul 2019 16:06:38 -0400
- To: Lucas Pardue <lucaspardue.24.7@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CALjsk176o8B4rfhZxYgGorerV5BnQV4LWnFYCatCehy+xh9C7g@mail.gmail.com>
On Thu, Jul 25, 2019 at 3:35 PM Lucas Pardue <lucaspardue.24.7@gmail.com> wrote: > Hey Dmitri, > > > On Thu, Jul 25, 2019 at 8:21 PM Dmitri Tikhonov < > dtikhonov@litespeedtech.com> wrote: > >> From the draft: >> >> " 3. The SETTINGS_ENABLE_HTTP2_PRIORITIES SETTINGS Parameter >> " >> " This document adds a new SETTINGS parameter to those defined by >> " [RFC7540], Section 6.5.2. >> " >> " The new parameter name is SETTINGS_ENABLE_HTTP2_PRIORITIES. >> >> Including "HTTP2" in the name is superfluous: Since this is an >> HTTP/2 setting, it deals with HTTP/2 priorities. >> > > I agree with your observation > > >> Or was "HTTP2" added to the name to differentiate it from possible >> future priority mechanisms? In that case, I suggest s/HTTP2/RFC7540/ >> > I think this is true, where HTTP2 here refers to RFC7540 (and the priority scheme defined there) and it would be possible for two peers to negotiate a different priority scheme via and extension to use for the session. > > My observation is that WG is using a range of terms to refer to > > * HTTP/2's tree-based priority model > * signalled using HTTP/2 frames > * HTTP/3's HTTP/2-inspired-tree-based priority model > * signalled using HTTP/3 frames > > Refining these terms would help in generak IMO, and would probably get > reflected back into the name of this setting. > > Lucas >
Received on Thursday, 25 July 2019 20:21:08 UTC