draft-ietf-httpbis-priority-07.txt   draft-ietf-httpbis-priority-08.txt 
HTTP K. Oku HTTP K. Oku
Internet-Draft Fastly Internet-Draft Fastly
Intended status: Standards Track L. Pardue Intended status: Standards Track L. Pardue
Expires: 28 April 2022 Cloudflare Expires: 12 May 2022 Cloudflare
25 October 2021 8 November 2021
Extensible Prioritization Scheme for HTTP Extensible Prioritization Scheme for HTTP
draft-ietf-httpbis-priority-07 draft-ietf-httpbis-priority-08
Abstract Abstract
This document describes a scheme that allows an HTTP client to This document describes a scheme that allows an HTTP client to
communicate its preferences for how the upstream server prioritizes communicate its preferences for how the upstream server prioritizes
responses to its requests, and also allows a server to hint to a responses to its requests, and also allows a server to hint to a
downstream intermediary how its responses should be prioritized when downstream intermediary how its responses should be prioritized when
they are forwarded. This document defines the Priority header field they are forwarded. This document defines the Priority header field
for communicating the initial priority in an HTTP version-independent for communicating the initial priority in an HTTP version-independent
manner, as well as HTTP/2 and HTTP/3 frames for reprioritizing manner, as well as HTTP/2 and HTTP/3 frames for reprioritizing
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 28 April 2022. This Internet-Draft will expire on 12 May 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 34 skipping to change at page 2, line 34
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4
2. Motivation for Replacing RFC 7540 Priorities . . . . . . . . 5 2. Motivation for Replacing RFC 7540 Priorities . . . . . . . . 5
2.1. Disabling RFC 7540 Priorities . . . . . . . . . . . . . . 6 2.1. Disabling RFC 7540 Priorities . . . . . . . . . . . . . . 6
2.1.1. Advice when Using Extensible Priorities as the 2.1.1. Advice when Using Extensible Priorities as the
Alternative . . . . . . . . . . . . . . . . . . . . . 7 Alternative . . . . . . . . . . . . . . . . . . . . . 7
3. Applicability of the Extensible Priority Scheme . . . . . . . 7 3. Applicability of the Extensible Priority Scheme . . . . . . . 8
4. Priority Parameters . . . . . . . . . . . . . . . . . . . . . 8 4. Priority Parameters . . . . . . . . . . . . . . . . . . . . . 8
4.1. Urgency . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Urgency . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Incremental . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Incremental . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Defining New Parameters . . . . . . . . . . . . . . . . . 10 4.3. Defining New Parameters . . . . . . . . . . . . . . . . . 10
4.3.1. Registration . . . . . . . . . . . . . . . . . . . . 10 4.3.1. Registration . . . . . . . . . . . . . . . . . . . . 11
5. The Priority HTTP Header Field . . . . . . . . . . . . . . . 11 5. The Priority HTTP Header Field . . . . . . . . . . . . . . . 12
6. Reprioritization . . . . . . . . . . . . . . . . . . . . . . 12 6. Reprioritization . . . . . . . . . . . . . . . . . . . . . . 12
7. The PRIORITY_UPDATE Frame . . . . . . . . . . . . . . . . . . 12 7. The PRIORITY_UPDATE Frame . . . . . . . . . . . . . . . . . . 12
7.1. HTTP/2 PRIORITY_UPDATE Frame . . . . . . . . . . . . . . 13 7.1. HTTP/2 PRIORITY_UPDATE Frame . . . . . . . . . . . . . . 13
7.2. HTTP/3 PRIORITY_UPDATE Frame . . . . . . . . . . . . . . 14 7.2. HTTP/3 PRIORITY_UPDATE Frame . . . . . . . . . . . . . . 15
8. Merging Client- and Server-Driven Parameters . . . . . . . . 15 8. Merging Client- and Server-Driven Parameters . . . . . . . . 16
9. Client Scheduling . . . . . . . . . . . . . . . . . . . . . . 16 9. Client Scheduling . . . . . . . . . . . . . . . . . . . . . . 17
10. Server Scheduling . . . . . . . . . . . . . . . . . . . . . . 17 10. Server Scheduling . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Intermediaries with Multiple Backend Connections . . . . 18 10.1. Intermediaries with Multiple Backend Connections . . . . 19
11. Scheduling and the CONNECT Method . . . . . . . . . . . . . . 19 11. Scheduling and the CONNECT Method . . . . . . . . . . . . . . 19
12. Retransmission Scheduling . . . . . . . . . . . . . . . . . . 19 12. Retransmission Scheduling . . . . . . . . . . . . . . . . . . 20
13. Fairness . . . . . . . . . . . . . . . . . . . . . . . . . . 20 13. Fairness . . . . . . . . . . . . . . . . . . . . . . . . . . 20
13.1. Coalescing Intermediaries . . . . . . . . . . . . . . . 20 13.1. Coalescing Intermediaries . . . . . . . . . . . . . . . 20
13.2. HTTP/1.x Back Ends . . . . . . . . . . . . . . . . . . . 21 13.2. HTTP/1.x Back Ends . . . . . . . . . . . . . . . . . . . 21
13.3. Intentional Introduction of Unfairness . . . . . . . . . 21 13.3. Intentional Introduction of Unfairness . . . . . . . . . 21
14. Why use an End-to-End Header Field? . . . . . . . . . . . . . 21 14. Why use an End-to-End Header Field? . . . . . . . . . . . . . 22
15. Security Considerations . . . . . . . . . . . . . . . . . . . 22 15. Security Considerations . . . . . . . . . . . . . . . . . . . 22
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
17.1. Normative References . . . . . . . . . . . . . . . . . . 23 17.1. Normative References . . . . . . . . . . . . . . . . . . 24
17.2. Informative References . . . . . . . . . . . . . . . . . 24 17.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 25 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 25
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 25 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 26
B.1. Since draft-ietf-httpbis-priority-06 . . . . . . . . . . 25 B.1. Since draft-ietf-httpbis-priority-06 . . . . . . . . . . 26
B.2. Since draft-ietf-httpbis-priority-05 . . . . . . . . . . 26 B.2. Since draft-ietf-httpbis-priority-06 . . . . . . . . . . 26
B.3. Since draft-ietf-httpbis-priority-04 . . . . . . . . . . 26 B.3. Since draft-ietf-httpbis-priority-05 . . . . . . . . . . 26
B.4. Since draft-ietf-httpbis-priority-03 . . . . . . . . . . 26 B.4. Since draft-ietf-httpbis-priority-04 . . . . . . . . . . 26
B.5. Since draft-ietf-httpbis-priority-02 . . . . . . . . . . 26 B.5. Since draft-ietf-httpbis-priority-03 . . . . . . . . . . 27
B.6. Since draft-ietf-httpbis-priority-01 . . . . . . . . . . 26 B.6. Since draft-ietf-httpbis-priority-02 . . . . . . . . . . 27
B.7. Since draft-ietf-httpbis-priority-00 . . . . . . . . . . 27 B.7. Since draft-ietf-httpbis-priority-01 . . . . . . . . . . 27
B.8. Since draft-kazuho-httpbis-priority-04 . . . . . . . . . 27 B.8. Since draft-ietf-httpbis-priority-00 . . . . . . . . . . 27
B.9. Since draft-kazuho-httpbis-priority-03 . . . . . . . . . 27 B.9. Since draft-kazuho-httpbis-priority-04 . . . . . . . . . 27
B.10. Since draft-kazuho-httpbis-priority-02 . . . . . . . . . 27 B.10. Since draft-kazuho-httpbis-priority-03 . . . . . . . . . 28
B.11. Since draft-kazuho-httpbis-priority-01 . . . . . . . . . 27 B.11. Since draft-kazuho-httpbis-priority-02 . . . . . . . . . 28
B.12. Since draft-kazuho-httpbis-priority-00 . . . . . . . . . 28 B.12. Since draft-kazuho-httpbis-priority-01 . . . . . . . . . 28
B.13. Since draft-kazuho-httpbis-priority-00 . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
It is common for representations of an HTTP [HTTP] resource to have It is common for representations of an HTTP [HTTP] resource to have
relationships to one or more other resources. Clients will often relationships to one or more other resources. Clients will often
discover these relationships while processing a retrieved discover these relationships while processing a retrieved
representation, which may lead to further retrieval requests. representation, which may lead to further retrieval requests.
Meanwhile, the nature of the relationship determines whether the Meanwhile, the nature of the relationship determines whether the
client is blocked from continuing to process locally available client is blocked from continuing to process locally available
skipping to change at page 7, line 6 skipping to change at page 7, line 6
least equivalent performance characteristics compared to the more least equivalent performance characteristics compared to the more
complex RFC 7540 setups seen in practice, at least for the web use complex RFC 7540 setups seen in practice, at least for the web use
case. case.
2.1. Disabling RFC 7540 Priorities 2.1. Disabling RFC 7540 Priorities
The problems and insights set out above provided the motivation for The problems and insights set out above provided the motivation for
deprecating RFC 7540 stream priority (see Section 5.3 of [RFC7540]). deprecating RFC 7540 stream priority (see Section 5.3 of [RFC7540]).
The SETTINGS_NO_RFC7540_PRIORITIES HTTP/2 setting is defined by this The SETTINGS_NO_RFC7540_PRIORITIES HTTP/2 setting is defined by this
document in order to allow endpoints to explicitly opt out of using document in order to allow endpoints to omit or ignore HTTP/2
HTTP/2 priority signals (see Section 5.3.2 of [HTTP2]). Endpoints priority signals (see Section 5.3.2 of [HTTP2]), as described below.
are encouraged to use alternative priority signals (for example,
Section 5 or Section 7.1) but there is no requirement to use a
specific signal type.
The value of SETTINGS_NO_RFC7540_PRIORITIES MUST be 0 or 1. Any The value of SETTINGS_NO_RFC7540_PRIORITIES MUST be 0 or 1. Any
value other than 0 or 1 MUST be treated as a connection error (see value other than 0 or 1 MUST be treated as a connection error (see
Section 5.4.1 of [HTTP2]) of type PROTOCOL_ERROR. The initial value Section 5.4.1 of [HTTP2]) of type PROTOCOL_ERROR. The initial value
is 0. is 0.
Endpoints MUST send this SETTINGS parameter as part of the first If endpoints use SETTINGS_NO_RFC7540_PRIORITIES they MUST send it in
SETTINGS frame. A sender MUST NOT change the the first SETTINGS frame. Senders MUST NOT change the
SETTINGS_NO_RFC7540_PRIORITIES parameter value after the first SETTINGS_NO_RFC7540_PRIORITIES value after the first SETTINGS frame.
SETTINGS frame. Detection of a change by a receiver MUST be treated Receivers that detect a change MAY treat it as a connection error of
as a connection error of type PROTOCOL_ERROR. type PROTOCOL_ERROR.
The SETTINGS frame precedes any HTTP/2 priority signal sent from a Clients can send SETTINGS_NO_RFC7540_PRIORITIES with a value of 1 to
client, so a server can determine if it needs to allocate any indicate that they are not using HTTP/2 priority signals. The
resource to signal handling before they arrive. A server that SETTINGS frame precedes any HTTP/2 priority signal sent from clients,
receives SETTINGS_NO_RFC7540_PRIORITIES with value of 1 MUST ignore so servers can determine whether they need to allocate any resources
HTTP/2 priority signals. to signal handling before signals arrive. A server that receives
SETTINGS_NO_RFC7540_PRIORITIES with a value of 1 MUST ignore HTTP/2
priority signals.
Servers can send SETTINGS_NO_RFC7540_PRIORITIES with a value of 1 to
indicate that they will ignore HTTP/2 priority signals sent by
clients.
Endpoints that send SETTINGS_NO_RFC7540_PRIORITIES are encouraged to
use alternative priority signals (for example, Section 5 or
Section 7.1) but there is no requirement to use a specific signal
type.
2.1.1. Advice when Using Extensible Priorities as the Alternative 2.1.1. Advice when Using Extensible Priorities as the Alternative
Until the client receives the SETTINGS frame from the server, the Until the client receives the SETTINGS frame from the server, the
client SHOULD send both the HTTP/2 priority signals and the signals client SHOULD send both the HTTP/2 priority signals and the signals
of this prioritization scheme (see Section 5 and Section 7.1). When of this prioritization scheme (see Section 5 and Section 7.1). When
the client receives the first SETTINGS frame that contains the the client receives the first SETTINGS frame that contains the
SETTINGS_NO_RFC7540_PRIORITIES parameter with value of 1, it SHOULD SETTINGS_NO_RFC7540_PRIORITIES parameter with value of 1, it SHOULD
stop sending the HTTP/2 priority signals. If the value was 0 or if stop sending the HTTP/2 priority signals. If the value was 0 or if
the settings parameter was absent, it SHOULD stop sending the settings parameter was absent, it SHOULD stop sending
skipping to change at page 8, line 15 skipping to change at page 8, line 25
4. Priority Parameters 4. Priority Parameters
The priority information is a sequence of key-value pairs, providing The priority information is a sequence of key-value pairs, providing
room for future extensions. Each key-value pair represents a room for future extensions. Each key-value pair represents a
priority parameter. priority parameter.
The Priority HTTP header field (Section 5) is an end-to-end way to The Priority HTTP header field (Section 5) is an end-to-end way to
transmit this set of parameters when a request or a response is transmit this set of parameters when a request or a response is
issued. In order to reprioritize a request, HTTP-version-specific issued. In order to reprioritize a request, HTTP-version-specific
PRIORITY_UPDATE frames (Section 7.1 and Section 7.2) are used by PRIORITY_UPDATE frames (Section 7.1 and Section 7.2) are used by
clients to transmit the same information on a single hop. If clients to transmit the same information on a single hop.
intermediaries want to specify prioritization on a multiplexed HTTP
connection, they SHOULD use a PRIORITY_UPDATE frame and SHOULD NOT
change the Priority header field.
In both cases, the set of priority parameters is encoded as a Intermediaries can consume and produce priority signals in a
Structured Fields Dictionary (see Section 3.2 of PRIORITY_UPDATE frame or Priority header field. Sending a
[STRUCTURED-FIELDS]). PRIORITY_UPDATE frame preserves the signal from the client, but
provides a signal that overrides for the next hop; see Section 14.
Replacing or adding a Priority header field overrides any signal from
a client and can affect prioritization for all subsequent recipients.
For both the Priority header field and the PRIORITY_UPDATE frame, the
set of priority parameters is encoded as a Structured Fields
Dictionary (see Section 3.2 of [STRUCTURED-FIELDS]).
This document defines the urgency(u) and incremental(i) parameters. This document defines the urgency(u) and incremental(i) parameters.
When receiving an HTTP request that does not carry these priority When receiving an HTTP request that does not carry these priority
parameters, a server SHOULD act as if their default values were parameters, a server SHOULD act as if their default values were
specified. Note that handling of omitted parameters is different specified. Note that handling of omitted parameters is different
when processing an HTTP response; see Section 8. when processing an HTTP response; see Section 8.
Receivers parse the Dictionary as defined in Section 4.2 of Receivers parse the Dictionary as defined in Section 4.2 of
[STRUCTURED-FIELDS]. Where the Dictionary is successfully parsed, [STRUCTURED-FIELDS]. Where the Dictionary is successfully parsed,
this document places the additional requirement that unknown priority this document places the additional requirement that unknown priority
skipping to change at page 12, line 36 skipping to change at page 13, line 14
PRIORITY_UPDATE frames are sent by clients on the control stream, PRIORITY_UPDATE frames are sent by clients on the control stream,
allowing them to be sent independent from the stream that carries the allowing them to be sent independent from the stream that carries the
response. This means they can be used to reprioritize a response or response. This means they can be used to reprioritize a response or
a push stream; or signal the initial priority of a response instead a push stream; or signal the initial priority of a response instead
of the Priority header field. of the Priority header field.
A PRIORITY_UPDATE frame communicates a complete set of all parameters A PRIORITY_UPDATE frame communicates a complete set of all parameters
in the Priority Field Value field. Omitting a parameter is a signal in the Priority Field Value field. Omitting a parameter is a signal
to use the parameter's default value. Failure to parse the Priority to use the parameter's default value. Failure to parse the Priority
Field Value MUST be treated as a connection error. In HTTP/2 the Field Value MAY be treated as a connection error. In HTTP/2 the
error is of type PROTOCOL_ERROR; in HTTP/3 the error is of type error is of type PROTOCOL_ERROR; in HTTP/3 the error is of type
H3_FRAME_ERROR. H3_GENERAL_PROTOCOL_ERROR.
A client MAY send a PRIORITY_UPDATE frame before the stream that it A client MAY send a PRIORITY_UPDATE frame before the stream that it
references is open (except for HTTP/2 push streams; see Section 7.1). references is open (except for HTTP/2 push streams; see Section 7.1).
Furthermore, HTTP/3 offers no guaranteed ordering across streams, Furthermore, HTTP/3 offers no guaranteed ordering across streams,
which could cause the frame to be received earlier than intended. which could cause the frame to be received earlier than intended.
Either case leads to a race condition where a server receives a Either case leads to a race condition where a server receives a
PRIORITY_UPDATE frame that references a request stream that is yet to PRIORITY_UPDATE frame that references a request stream that is yet to
be opened. To solve this condition, for the purposes of scheduling, be opened. To solve this condition, for the purposes of scheduling,
the most recently received PRIORITY_UPDATE frame can be considered as the most recently received PRIORITY_UPDATE frame can be considered as
the most up-to-date information that overrides any other signal. the most up-to-date information that overrides any other signal.
skipping to change at page 25, line 45 skipping to change at page 26, line 22
Alan Frindell, Andrew Galloni, Craig Taylor, Ian Swett, Kazuho Oku, Alan Frindell, Andrew Galloni, Craig Taylor, Ian Swett, Kazuho Oku,
Lucas Pardue, Matthew Cox, Mike Bishop, Roberto Peon, Robin Marx, Roy Lucas Pardue, Matthew Cox, Mike Bishop, Roberto Peon, Robin Marx, Roy
Fielding. Fielding.
Yang Chi contributed the section on retransmission scheduling. Yang Chi contributed the section on retransmission scheduling.
Appendix B. Change Log Appendix B. Change Log
B.1. Since draft-ietf-httpbis-priority-06 B.1. Since draft-ietf-httpbis-priority-06
* Relax requirements of receiving SETTINGS_NO_RFC7540_PRIORITIES
that changes value (#1714, #1725)
* Clarify how intermediaries might use frames vs. headers (#1715,
#1735)
* Relax requirement when receiving a PRIORITY_UPDATE with an invalid
structured field value (#1741, #1756)
B.2. Since draft-ietf-httpbis-priority-06
* Focus on editorial changes * Focus on editorial changes
* Clarify rules about Sf-Dictionary handling in headers * Clarify rules about Sf-Dictionary handling in headers
* Split policy for parameter IANA registry into two sections based * Split policy for parameter IANA registry into two sections based
on key length on key length
B.2. Since draft-ietf-httpbis-priority-05 B.3. Since draft-ietf-httpbis-priority-05
* Renamed SETTINGS_DEPRECATE_RFC7540_PRIORITIES to * Renamed SETTINGS_DEPRECATE_RFC7540_PRIORITIES to
SETTINGS_NO_RFC7540_PRIORITIES SETTINGS_NO_RFC7540_PRIORITIES
* Clarify that senders of the HTTP/2 setting can use any alternative * Clarify that senders of the HTTP/2 setting can use any alternative
(#1679, #1705) (#1679, #1705)
B.3. Since draft-ietf-httpbis-priority-04 B.4. Since draft-ietf-httpbis-priority-04
* Renamed SETTINGS_DEPRECATE_HTTP2_PRIORITIES to * Renamed SETTINGS_DEPRECATE_HTTP2_PRIORITIES to
SETTINGS_DEPRECATE_RFC7540_PRIORITIES (#1601) SETTINGS_DEPRECATE_RFC7540_PRIORITIES (#1601)
* Reoriented text towards RFC7540bis (#1561, #1601) * Reoriented text towards RFC7540bis (#1561, #1601)
* Clarify intermediary behavior (#1562) * Clarify intermediary behavior (#1562)
B.4. Since draft-ietf-httpbis-priority-03 B.5. Since draft-ietf-httpbis-priority-03
* Add statement about what this scheme applies to. Clarify * Add statement about what this scheme applies to. Clarify
extensions can use it but must define how themselves (#1550, extensions can use it but must define how themselves (#1550,
#1559) #1559)
* Describe scheduling considerations for the CONNECT method (#1495, * Describe scheduling considerations for the CONNECT method (#1495,
#1544) #1544)
* Describe scheduling considerations for retransmitted data (#1429, * Describe scheduling considerations for retransmitted data (#1429,
#1504) #1504)
* Suggest intermediaries might avoid strict prioritization (#1562) * Suggest intermediaries might avoid strict prioritization (#1562)
B.5. Since draft-ietf-httpbis-priority-02 B.6. Since draft-ietf-httpbis-priority-02
* Describe considerations for server push prioritization (#1056, * Describe considerations for server push prioritization (#1056,
#1345) #1345)
* Define HTTP/2 PRIORITY_UPDATE ID limits in HTTP/2 terms (#1261, * Define HTTP/2 PRIORITY_UPDATE ID limits in HTTP/2 terms (#1261,
#1344) #1344)
* Add a Parameters registry (#1371) * Add a Parameters registry (#1371)
B.6. Since draft-ietf-httpbis-priority-01 B.7. Since draft-ietf-httpbis-priority-01
* PRIORITY_UPDATE frame changes (#1096, #1079, #1167, #1262, #1267, * PRIORITY_UPDATE frame changes (#1096, #1079, #1167, #1262, #1267,
#1271) #1271)
* Add section to describe server scheduling considerations (#1215, * Add section to describe server scheduling considerations (#1215,
#1232, #1266) #1232, #1266)
* Remove specific instructions related to intermediary fairness * Remove specific instructions related to intermediary fairness
(#1022, #1264) (#1022, #1264)
B.7. Since draft-ietf-httpbis-priority-00 B.8. Since draft-ietf-httpbis-priority-00
* Move text around (#1217, #1218) * Move text around (#1217, #1218)
* Editorial change to the default urgency. The value is 3, which * Editorial change to the default urgency. The value is 3, which
was always the intent of previous changes. was always the intent of previous changes.
B.8. Since draft-kazuho-httpbis-priority-04 B.9. Since draft-kazuho-httpbis-priority-04
* Minimize semantics of Urgency levels (#1023, #1026) * Minimize semantics of Urgency levels (#1023, #1026)
* Reduce guidance about how intermediary implements merging priority * Reduce guidance about how intermediary implements merging priority
signals (#1026) signals (#1026)
* Remove mention of CDN-Loop (#1062) * Remove mention of CDN-Loop (#1062)
* Editorial changes * Editorial changes
* Make changes due to WG adoption * Make changes due to WG adoption
* Removed outdated Consideration (#118) * Removed outdated Consideration (#118)
B.9. Since draft-kazuho-httpbis-priority-03 B.10. Since draft-kazuho-httpbis-priority-03
* Changed numbering from [-1,6] to [0,7] (#78) * Changed numbering from [-1,6] to [0,7] (#78)
* Replaced priority scheme negotiation with HTTP/2 priority * Replaced priority scheme negotiation with HTTP/2 priority
deprecation (#100) deprecation (#100)
* Shorten parameter names (#108) * Shorten parameter names (#108)
* Expand on considerations (#105, #107, #109, #110, #111, #113) * Expand on considerations (#105, #107, #109, #110, #111, #113)
B.10. Since draft-kazuho-httpbis-priority-02 B.11. Since draft-kazuho-httpbis-priority-02
* Consolidation of the problem statement (#61, #73) * Consolidation of the problem statement (#61, #73)
* Define SETTINGS_PRIORITIES for negotiation (#58, #69) * Define SETTINGS_PRIORITIES for negotiation (#58, #69)
* Define PRIORITY_UPDATE frame for HTTP/2 and HTTP/3 (#51) * Define PRIORITY_UPDATE frame for HTTP/2 and HTTP/3 (#51)
* Explain fairness issue and mitigations (#56) * Explain fairness issue and mitigations (#56)
B.11. Since draft-kazuho-httpbis-priority-01 B.12. Since draft-kazuho-httpbis-priority-01
* Explain how reprioritization might be supported. * Explain how reprioritization might be supported.
B.12. Since draft-kazuho-httpbis-priority-00 B.13. Since draft-kazuho-httpbis-priority-00
* Expand urgency levels from 3 to 8. * Expand urgency levels from 3 to 8.
Authors' Addresses Authors' Addresses
Kazuho Oku Kazuho Oku
Fastly Fastly
Email: kazuhooku@gmail.com Email: kazuhooku@gmail.com
Lucas Pardue Lucas Pardue
Cloudflare Cloudflare
Email: lucaspardue.24.7@gmail.com Email: lucaspardue.24.7@gmail.com
 End of changes. 33 change blocks. 
67 lines changed or deleted 89 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/