Original text:
as a connection error of type PROTOCOL_ERROR. Until the client receives the SETTINGS frame from the server, the <del> client SHOULD send both the priority signal defined in the HTTP/2 priority scheme and also that of this prioritization scheme.  When the client receives the first SETTINGS frame that contains the </del>  SETTINGS_DEPRECATE_HTTP2_PRIORITIES parameter with value of 1, it SHOULD stop sending the HTTP/2 priority signals.  If the value was 0 or if the settings parameter was absent, it SHOULD stop sending

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:
as a connection error of type PROTOCOL_ERROR. Until the client receives the SETTINGS frame from the server, the  <ins> client SHOULD send the signals of the HTTP/2 priority scheme (see motivation) and the signals of this prioritization scheme (see header-field and h2-update-frame).  When the client receives the first SETTINGS frame that contains the </ins> SETTINGS_DEPRECATE_HTTP2_PRIORITIES parameter with value of 1, it SHOULD stop sending the HTTP/2 priority signals.  If the value was 0 or if the settings parameter was absent, it SHOULD stop sending