Code change:
suboptimal, particularly if one endpoint operates in ignorance of the needs of its peer. <del> HTTP/2 introduced a complex prioritization signaling scheme that used a combination of dependencies and weights, formed into an unbalanced tree.  This scheme has suffered from poor deployment and </del> <ins> HTTP/2 introduced a complex prioritization scheme that uses a combination of stream dependencies and weights to describe an unbalanced tree.  This scheme has suffered from poor deployment and </ins> interoperability. <del> The rich flexibility of client-driven HTTP/2 prioritization tree building is rarely exercised.  Experience has shown that clients tend to choose a single model optimized for a web use case and experiment within the model constraints, or do nothing at all.  Furthermore, many clients build their prioritization tree in a unique way, which makes it difficult for servers to understand their intent and act or intervene accordingly. </del> <ins> Clients build an HTTP/2 prioritization tree through a series of individual stream relationships, which are transferred to the server using HTTP/2 priority signals in either of three forms.  First, a HEADERS frame with the PRIORITY flag set is an explicit signal that includes an Exclusive flag, Stream Dependency field, and Weight field.  Second, a HEADERS frame with no PRIORITY flag is an implicit signal to use the default priority.  Third, the PRIORITY frame, which is always explicit since it always contains an Exclusive flag, Stream Dependency field, and Weight field. The rich flexibility of tree building is rarely exercised. Experience has shown that clients tend to choose a single model optimized for a web use case and experiment within the model constraints, or do nothing at all.  Furthermore, many clients build their prioritization tree in a unique way, which makes it difficult for servers to understand their intent and act or intervene accordingly. </ins> Many HTTP/2 server implementations do not include support for the priority scheme.  Some instead favor custom server-driven schemes

Related discussion:
text: says: 'deprecated' isn't the right word here; perhaps 'disabled by a peer'? Also, here and a few other places refer to 'the HTTP/2 priority signals' without enumerating them. To be precise, that should be done somewhere. I think that means: The PRIORITY flag in HEADERS and its associated Exclusive flag, Stream Dependency field, and Weight field The PRIORITY frame type
How about instead "once a client learns that the server supports this priority scheme, it SHOULD stop sending HTTP/2 priority signals" After all, this spec can only really have something to say about the stuff it defines and the h2 priority stuff. (Plus what Mark says about being very clear about what "HTTP/2 priority signals" means.
NAME I like the suggestion but that does not work as is. The draft defines two separate concepts: an HTTP/2 SETTINGS flag that allows an endpoint to deprecate the use of H2 priorities, and a different prioritization scheme. While the two are expected to be used together on HTTP/2, they aren't required to. defines the SETTINGSDEPRECATEHTTP2PRIORITIES flag as a way to opt out of using the HTTP/2 priority scheme, in favor of using an alternative such as the scheme defined in this specification_. That said, I tend to wonder what NAME and NAME are suggesting is that the current draft is a bit verbose. At the moment, it uses to define what "deprecation" means, then the term to define how the client acts when the peer "deprecates." Hence . I would appreciate your reviews. Makes sense.
That raises a different issue. The setting is phrased in the negative, where it could be positive. That is, I support priority mechanism X. That works equally well and doesn't have issues in the case that we have to design a third scheme.
Yes, I think I would prefer a model of advertising support for (potentially multiple) schemes and then saying that the client SHOULD NOT send more than one scheme on a given connection.
NAME NAME While I do not oppose strongly, I think there are number of things that we have to consider: Technically, we can create a mechanism that allows the two sides of a hop agree on one prioritization scheme.