Code change:
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?

Related discussion:
text: 1. <del> It is common for an HTTP HTTP resource representation to have </del> <ins> It is common for representations of an HTTP HTTP resource to have </ins> relationships to one or more other resources.  Clients will often discover these relationships while processing a retrieved <del> representation, leading to further retrieval requests.  Meanwhile, the nature of the relationship determines whether the client is blocked from continuing to process locally available resources.  For example, visual rendering of an HTML document could be blocked by the retrieval of a CSS file that the document refers to.  In contrast, inline images do not block rendering and get drawn incrementally as the chunks of the images arrive. To provide meaningful presentation of a document at the earliest </del> <ins> representation, which may lead to further retrieval requests. Meanwhile, the nature of the relationship determines whether the client is blocked from continuing to process locally available resources.  An example of this is visual rendering of an HTML document, which could be blocked by the retrieval of a CSS file that the document refers to.  In contrast, inline images do not block rendering and get drawn incrementally as the chunks of the images arrive. HTTP/2 HTTP2 and HTTP/3 HTTP3 support multiplexing of requests and responses in a single connection.  An important feature of any implementation of a protocol that provides multiplexing is the ability to prioritize the sending of information.  For example, to provide meaningful presentation of an HTML document at the earliest </ins> moment, it is important for an HTTP server to prioritize the HTTP <del> responses, or the chunks of those HTTP responses, that it sends. </del> <ins> responses, or the chunks of those HTTP responses, that it sends to a client. A server that operates in ignorance of how clients issue requests and consume responses can cause suboptimal client application performance.  Priority signals allow clients to communicate their view of request priority.  Servers have their own needs that are independent from client needs, so they often combine priority signals with other available information in order to inform scheduling of response data. </ins> RFC 7540 RFC7540 stream priority allowed a client to send a series of priority signals that communicate to the server a "priority tree";