Original text:
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>  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>  Many HTTP/2 server implementations do not include support for the priority scheme.  Some instead favor custom server-driven schemes

Reviewer comments:
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. However, that's going to be a bit complicated, because SETTINGS is a frame that is sent by the two endpoints before receiving one from the peer. Therefore, the minimal mechanism would be something like each endpoint sending a list of schemes that it supports, and then both endpoint choose a scheme from a intersection of the two lists using a predefined logic (e.g., client's list of schemes are ordered by its preference, and the most preferred one also supported by the server will be selected). But before designing a negotiation scheme, I think it's worth asking one question: do we want a negotiation scheme for HTTP/3? If the answer is no, I'm not sure if we need something more than a deprecation scheme for HTTP/2, when what we are trying to do is a back port from HTTP/3. Even with HTTP/2, there's isn't a necessity to negotiate the prioritization scheme. IIRC, the two reasons we introduced the deprecation flag (which IMO is an optimization) are: to reduce the burden of setting up the h2 prioritization tree on the server-side to conserve bandwidth All that said, I think my argument is that having deprecation flag is a good way to punt to the future the cost of designing a solution that we might not need. Because the deprecation flag makes h2 and h3 on par. If we find that we need to replace the new prioritization scheme in the future, then we could introduce a negotiation scheme that works for both H2 and H3. Note also that the new prioritization scheme is extensible.
Not needing to fully specify how they're selected right now is certainly a valid point. But the only difference between a deprecation flag and an indication of support is the orientation of the default value. In HTTP/2, the orientation is that the peer might support that feature, but many don't. So there's value in being explicit both directions; the honest choice for default is "don't know." Indicating support for each scheme gives us more leeway in the future, and we can recommend that implementations which don't support the old scheme explicitly disavow it.
Regarding default, I tend to believe that it should be "supportsh2priorities," because clients should continue sending h2 priorities to h2 servers that do not implement the new extension. That leaves us to the discussion of orientation. I do not have a strong opinion, though IIRC, some argued that they prefer default value being 0 rather than 1. That's how we ended up with a "deprecate" flag than "preferred" flag.
I agree with all of Kazuho's points. We explored something different in the past (e.g. URL) but ended up with what we have today, and I don't think there has been significant new information that would change my opinion.
NAME PTAL at this PR that addresses your comment about describing the signals URL
That looks good, but I wonder if 2.1 should explicitly reference that for the definition of h2 priority signals.

Revised text:
suboptimal, particularly if one endpoint operates in ignorance of the needs of its peer.  <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.  <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