Code change:
responses that uses absolute values. parameters defines priority parameters, which are a standardized and extensible format of priority information. header-field defines the Priority HTTP header <del> field that can be used by both client and server to exchange parameters in order to specify the precedence of HTTP responses in a protocol-version-independent and end-to-end manner.  h2-update-frame and h3-update-frame define version-specific frames that carry parameters for reprioritization.  This prioritization scheme and its signals can act as a substitute for RFC 7540 stream priority. </del> <ins> field, a protocol-version-independent and end-to-end priority signal. Clients can use this header to signal priority to servers in order to specify the precedence of HTTP responses.  Similarly, servers behind an intermediary can use it to signal priority to the intermediary. h2-update-frame and h3-update-frame define version-specific frames that carry parameters, which clients can use for reprioritization. Header field and frame priority signals are input to a server's response prioritization process.  They are only a suggestion and do not guarantee any particular processing or transmission order for one response relative to any other response. server-scheduling and retransmission-scheduling provide consideration and guidance about how servers might act upon signals. The prioritization scheme and priority signals defined herein can act as a substitute for RFC 7540 stream priority. </ins> 1.1.

Related discussion:
text: and This is an editorial set of changes to the intro text. The first paragraph in the "motivation for replacement" section is actually broadly applicable motivation for any priority scheme. So we can move that up and highlight that H2 and H3 are multiplexed protocols that have the need of something. This helps us to clarify that mention of HTML document loading is only an example. We also give greater exposition about the actors involved in signalling, highlighting early that servers treat signals as a suggestion and they might follow some of the guidance provided later in the document.
To avoid bitrot, I'm merging.
The introductory material tries to be general, but routinely fails to be, falling back on talking about rendering web pages. If this is the best example, it could be more direct about that. Or, if this is general, it could try to be more careful about limiting its use of "document" and so forth to examples. For example, this lacks sufficient context: And this launches into talking about HTML without saying HTML:
good catch. I do think this is the best example and therefore will take your first suggestion. I'll follow up with a PR.
I have an unpushed branch for this that conflicts with other things, but I believe solves the matter.
says in part: In the first sentence, the endpoint is the one that is applying priority based on signals (or lack thereof) from its peer. In the second, the endpoint is the one providing signals when the peer is the one that acts upon it. This is confusing.
I see what you mean but I don't have a quick fix to hand. Would "one side operates in ignorance of the needs of the other" work?
Possibly. In the first you might say a sender might operate in ignorance of the needs of a receiver; the second might then say that a receive can communicate its view of priority to inform sender behaviour. Not that prioritization is exclusively about prioritization of sending, of course.
the terms in the second sentence were written intentionally fuzzy to accommodate intermediaries in the general statement. IIRC Robin elsewhere suggested just saying client and server but that risks over simplifying or misleading.
I think it might be a good idea to using terms "sender", "receiver", as suggested by NAME
To me, that risks conflating signal sender vs data sender. Someone want to propose a PR?