Original text:
SETTINGS frame.  Detection of a change by a receiver MUST be treated as a connection error of type PROTOCOL_ERROR.  Until the client receives the SETTINGS frame from the server, the client SHOULD send both the HTTP/2 priority signals and the signals of this prioritization scheme (see header-field and h2-update-frame).

Reviewer comments:
The context here is that the document defines independent elements a) the means to deprecate RFC 7540 stream priority using a setting b) the extensible priorities scheme. This text removes conflating those elements and making it appear that Extensible priorities is mandatory. Where someone chooses to use Extensible priorities (good choice!) there is some specific guidance about how to process settings and inform signal setting.
Above, you indicate any scheme can be used, with this being just one option. This does make guidance about PRIOUPDATE frames/header field more difficult later, so maybe some other textual adjustment is needed earlier: e.g., for the remainder of this text ,we assume the use of the scheme defined in this document as the alternate Or, move the following text from below up and adjust a bit send this scheme's priority signal Originally posted by NAME in URL
The text isn't amazingly clear if endpoints have to use Extensible priority when they explicitly disable H2 priority. I suggest we state they do. If anyone really wants to invent a new scheme, they will need to deal with negotiation.
Yeah I see two somewhat contradicting statements: Endpoints are expected to use an alternative, such as the scheme defined in this specification. Until the client receives the SETTINGS frame from the server, the client SHOULD send both the HTTP/2 priority signals and the signals of this prioritization scheme (see Section 5 and Section 7.1). I would argue that the former is precise, and that the latter is a bit misleading in recommending endpoints send Extensible Priorities rather than any alternative to H2 priorities. The rationale is as follows. In principle, negotiation is a hop-by-hop mechanism and therefore cannot be used for negotiating the use of an end-to-end signal, which includes the header-field variant of Extensible Priorities. To paraphrase, in a world where end-to-end signals are used for prioritization, multiple signals are expected to co-exist. IMO, SETTINGSDEPRECATERFC7540_PRIORITIES is no more than an optimization, that allows clients to conserve bandwidth (by omitting the PRIORITY frames), servers to reduce complexity (by ignoring PRIORITY frames being received). These benefits are stated correctly in the section.
Thanks Kazuho. I tend to agree. The thing I also wanted to avoid is endpoints disabling RFC 7550 stream priority and then not providing any suitable replacement by accident. I think there is agreement that not doing scheduling is pretty bad. But we also highlight that other inputs, beyond this scheme and beyond anything that would be standardised are fine to use too. I'm getting an idea of how we could change the text to address the points made on this issue.
Reading again the current text send this scheme's priority signal. Handling of omitted signals is described in {{parameters}}. This is effectively a differently worded restatement of the guidance for implementers of Extensible Priorities receiving an HTTP request that does not carry these priority parameters, a server SHOULD act as if their default values were specified. That is, imagine both endpoints send SETTINGSDEPRECATERFC7540PRIORITIES and a client wants the default prioritization for a request (u=3,i). It can omit the Priority header field and have some expectation that a server implementing Extensible priorities will interpret that as a signal to apply the default. The simple action here is to make SETTINGSDEPRECATERFC7540PRIORITIES independent from any advice to use a specific alternative.
LGTM. I like how you've split the section.

Revised text:
SETTINGS frame.  Detection of a change by a receiver MUST be treated as a connection error of type PROTOCOL_ERROR. <ins> The SETTINGS frame precedes any HTTP/2 priority signal sent from a client, so a server can determine if it needs to allocate any resource to signal handling before they arrive.  A server that receives SETTINGS_NO_RFC7540_PRIORITIES with value of 1 MUST ignore HTTP/2 priority signals. 2.1.1. </ins> Until the client receives the SETTINGS frame from the server, the client SHOULD send both the HTTP/2 priority signals and the signals of this prioritization scheme (see header-field and h2-update-frame).