Okay, here is the abstract and summary for RFC 9218 based on the provided text.
Abstract:
RFC 9218 introduces an extensible scheme for HTTP clients to signal their preferred priority for receiving responses and for servers to hint priority to downstream intermediaries. It replaces the complex and deprecated RFC 7540 stream priority mechanism. The scheme utilizes a new Priority HTTP header field for conveying initial, end-to-end priority preferences in a version-independent manner, based on parameters like urgency (u) and incremental (i). It also defines new PRIORITY_UPDATE frames for HTTP/2 and HTTP/3, allowing clients to dynamically reprioritize responses on a hop-by-hop basis after requests have been sent. These mechanisms share a common, extensible format using structured key-value pairs, providing guidance for server scheduling while acknowledging that priority signals are suggestions, not mandates.
RFC 9218: Extensible Prioritization Scheme for HTTP
(Section 2) Motivation: The previous HTTP/2 stream priority mechanism (RFC 7540) was complex, suffered from limited adoption and interoperability, was difficult for servers to interpret, lacked server-to-intermediary signalling, and is now deprecated.
(Section 2.1) Disabling Old Priorities: Defines the SETTINGS_NO_RFC7540_PRIORITIES HTTP/2 setting (value 0 or 1) allowing endpoints to signal they will ignore or not send the deprecated RFC 7540 priority signals.
(Section 4) Priority Parameters: Introduces a standardized, extensible key-value format (HTTP Structured Fields Dictionary) for priority information.
(Section 4.1) Urgency (u): An integer from 0 (most urgent) to 7 (least urgent, background tasks), with a default of 3. Indicates the desired precedence of the response.
(Section 4.2) Incremental (i): A boolean (default false). Indicates if the response can be processed incrementally (e.g., displaying parts of an image as they arrive). i=true suggests concurrent delivery might be beneficial; i=false suggests sequential delivery based on request order is better for responses of the same urgency.
(Section 4.3) Extensibility: New parameters can be registered with IANA. Unknown parameters MUST be ignored by implementations.
(Section 7) PRIORITY_UPDATE Frame: Defines new HTTP/2 (type 0x10) and HTTP/3 (type 0xF0700 for requests, 0xF0701 for push) frames.
Used by clients to change the priority of a response after the initial request (reprioritization).
It's a hop-by-hop signal sent on the control stream.
Carries a complete set of priority parameters; omitting a parameter implies its default value.
References the stream ID (HTTP/2, HTTP/3) or push ID (HTTP/3) being reprioritized.
Servers should buffer the latest frame for a stream if it arrives before the stream is opened.
(Section 8) Merging Priorities: Intermediaries can use both client (Priority request header) and server (Priority response header) signals. If a response header omits a parameter, the client's value (or default) is retained; if it includes a parameter (e.g., u), it typically overrides the client's value.
(Section 10) Server Scheduling Guidance: Priority signals are suggestions. Servers combine them with other factors.
Recommended to respect urgency (higher first) and incremental (serve concurrently if i=true, sequentially if i=false for same urgency).
Servers should try to avoid starvation scenarios (e.g., a large non-incremental response blocking later incremental ones).
Intermediaries with multiple backends may need to allocate some bandwidth even to low-priority requests to prevent backend connection stalls.
(Section 12) Retransmission Scheduling: Transport protocols (like QUIC) might use application-provided priorities (from this scheme) when deciding whether to prioritize retransmissions vs. new data, but this is not mandated.
(Section 13) Fairness: Discusses potential unfairness when intermediaries coalesce requests from different clients with different priorities, and suggests mitigations (e.g., server awareness of coalescing, bandwidth distribution). Also notes intentional unfairness can be beneficial (e.g., deprioritizing background transfers).
(Section 14) End-to-End Rationale: The Priority header is end-to-end primarily to allow caching intermediaries to store and utilize the priority information correctly when serving cached responses.