idnits 2.17.1 draft-bishop-http2-extension-frames-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 22, 2014) is 3598 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC1950' is mentioned on line 608, but not defined == Missing Reference: 'RFC1951' is mentioned on line 609, but not defined == Missing Reference: 'RFC1952' is mentioned on line 614, but not defined == Outdated reference: A later version (-14) exists of draft-ietf-httpbis-alt-svc-01 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Downref: Normative reference to an Informational RFC: RFC 6709 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPbis Working Group M. Bishop 3 Internet-Draft Microsoft 4 Expires: November 23, 2014 May 22, 2014 6 Extension Frames in HTTP/2 7 draft-bishop-http2-extension-frames-01 9 Abstract 11 This document describes a proposed modification to the HTTP/2 12 specification to better support the creation of extensions without 13 the need to version the core protocol or invoke additional protocol 14 identifiers. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on November 23, 2014. 33 Copyright Notice 35 Copyright (c) 2014 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 3 52 2. Problems an extension model must solve . . . . . . . . . . . 3 53 3. Extension Functionality . . . . . . . . . . . . . . . . . . . 4 54 3.1. Extension Identification and Negotiation . . . . . . . . 4 55 3.2. Extension Negotiation . . . . . . . . . . . . . . . . . . 5 56 3.3. New Frames and Modifications . . . . . . . . . . . . . . 5 57 3.4. Settings . . . . . . . . . . . . . . . . . . . . . . . . 8 58 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 59 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 60 Appendix A. Example Extensions . . . . . . . . . . . . . . . . . 11 61 A.1. Blocked Flow-Control Announcement Extension . . . . . . . 11 62 A.2. Alternate-Service Announcement . . . . . . . . . . . . . 12 63 A.3. Compressed Data Frames . . . . . . . . . . . . . . . . . 14 64 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 18 66 1. Introduction 68 HTTP/2 previously offered an inconsistent story about the use of 69 extensions. Following a discussion of the previous version of this 70 draft, the working group reached consensus to prohibit all 71 extensibility, declaring that any new functionality would constitute 72 the creation of a new protocol with a new ALPN identifier. This was 73 driven in large part by a desire not to delay the specification while 74 an extension model was finalized and implemented. 76 In the wake of this decision, a number of new frames and subfeatures 77 have been proposed (BLOCKED (Appendix A.1), ALTSVC (Appendix A.2), 78 compression of DATA frames (Appendix A.3)), delaying the 79 specification and introducing a dependency on a draft 80 [I-D.ietf-httpbis-alt-svc] which is not as close to ready for last 81 call as the core HTTP/2 specification. Others, such as DRAINING, 82 have been suggested on the mailing list though not introduced to the 83 specification. Many of these features are optional either to use or 84 to process, limiting their broad applicability. 86 In the words of Antoine de Saint-Exupery, "Perfection is achieved, 87 not when there is nothing more to add, but when there is nothing left 88 to take away." Many of these frames represent concerns which, while 89 worth addressing, are not fundamental to the goals of HTTP/2. The 90 HTTP/2 specification should be the minimal set of features which 91 enables two peers to communicate efficiently and achieve the goals 92 laid out in the working group charter. 94 This working group is empowered by its charter to work on additional 95 extensions to HTTP provided that "[t]he Working Group Chairs ... 97 believe that it will not interfere with the work described above 98 [definition of HTTP/2]." The working group is explicitly prohibited 99 from defining HTTP/2 extensions until the HTTP/2 work is complete. 101 This draft contends that some or all of these late-breaking features 102 could be easily recast as extensions, simplifying and unblocking the 103 core specification. Existing implementations of these features would 104 test the extensibility model in the process of interoperating with 105 others who have chosen not to implement them, permitting us to 106 finalize HTTP/2 and turn our attention to the set of extensions the 107 working group has already reached consensus should be explored. 109 1.1. Conventions and Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119 [RFC2119]. 115 All numeric values are in network byte order. Values are unsigned 116 unless otherwise indicated. Literal values are provided in decimal 117 or hexadecimal as appropriate. Hexadecimal literals are prefixed 118 with "0x" to distinguish them from decimal literals. 120 2. Problems an extension model must solve 122 Possible extensions vary along a number of pivots. Any extension 123 model must define how extensions will work along each pivot, which 124 may include disallowing certain combinations. Possible variants of 125 extensions include: 127 o Changes session state, or strictly informative 129 o Flow-controlled third-party data or freely-sent control data 131 o Hop-by-hop or end-to-end 133 There is no way to know whether the peer supports a given extension 134 before sending extension-specific information. This can be simply 135 addressed by saying that implementations MUST ignore frame types and 136 settings values they don't understand. However, this model only 137 works for strictly informative frames and/or settings. An extension 138 model must define a way to determine whether a peer supports a given 139 extension, if non-informative extensions are supported. 141 Another concern is that with only 256 frame types, the frame type 142 space may be exhausted if many extensions are defined. Different 143 extensions could collide with each other in the choice of frame type 144 identifiers, since the space is limited. RFC 6709 [RFC6709] 145 discusses in detail the trade-offs that must be considered by any 146 protocol's extension model. One key risk is that a difficult 147 registration process will encourage the use of unregistered 148 extensions, which leads to collisions, but a small space requires 149 rigorous control over the identifier space. 151 Another risk that arises when extension is overly constrained is the 152 emergence of protocol variations. RFC 6709 [RFC6709] has this to 153 say: "Protocol variations -- specifications that look very similar to 154 the original but don't interoperate with each other or with the 155 original -- are even more harmful to interoperability than 156 extensions." Where no extensions are possible, implementers who wish 157 to extend HTTP/2 will quickly move to define a new protocol which 158 looks remarkably similar to HTTP/2, but is not interoperable. 160 Future protocols using the HTTP/2 framing layer will face exactly the 161 same problem as extension authors, since they share a frame type and 162 setting value space with any extensions. Thus, a new frame 163 introduced with, for example, HTTP/3 must avoid collision with any 164 HTTP/2 extensions and must deal with space exhaustion. Any means of 165 resolving such adoption after the fact complicates forward-porting of 166 existing extensions. 168 This document proposes an alternative method of supporting extension 169 frames and settings, with the following goals: 171 o Reduce the probability of collision among extensions and between 172 extensions and future versions of HTTP 174 o Enable peers to quickly discover support for a particular 175 extension on the far side 177 o Enable extension implementers to interoperate with minimal 178 procedural overhead 180 3. Extension Functionality 182 3.1. Extension Identification and Negotiation 184 An extension to HTTP/2 is identified by an Extension ID. An 185 Extension ID is a 32-bit identifier registered with IANA. Extension 186 identifiers above 0xFFFF0000 are reserved for experimental use, as 187 described below (Section 3.1.1). 189 3.1.1. Experimental Extensions 191 The designer of an extension MAY self-allocate an extension ID in the 192 experimental range defined above without interaction with IANA. Such 193 an extension MUST use only frame numbers and setting IDs from the 194 experimental range. These extensions MUST NOT be generally deployed 195 until a non-experimental extension ID has been allocated. 197 As a further guard against accidental collisions, an experimental 198 extension SHOULD define a random 32-bit number, and include this 199 number as the first four bytes of each frame used by the extension. 200 Received frames which do not include this identifier MUST be treated 201 as an unrecognized frame type. 203 3.2. Extension Negotiation 205 An implementation which supports extensions SHOULD send an EXTENSIONS 206 (Section 3.3.2) frame immediately following its SETTINGS frame at 207 connection establishment, listing all extensions that it wishes to 208 use during the lifetime of the connection. After receiving a 209 corresponding EXTENSIONS frame, any extensions which were present in 210 both frames are considered to be in effect for the lifetime of the 211 connection. The EXTENSIONS frame may be sent only once per 212 connection. 214 An empty EXTENSIONS frame declares that the sender does not wish to 215 employ any hop-by-hop extensions beyond the negotiated protocol. 217 Extension-defined hop-by-hop frames and settings which modify stream 218 or session state (including flow control) MUST NOT be sent until the 219 EXTENSIONS frame has been received from the remote endpoint declaring 220 support for the associated extension ID. Extension-defined frames 221 and settings which are strictly informative MAY be sent between 222 sending the EXTENSIONS frame and before receiving the peer's 223 EXTENSIONS frame. Implementations SHOULD NOT send informative frames 224 or settings from any extension after receiving an EXTENSIONS frame 225 which does not list support for that extension, since the receiver 226 likely will not understand the extra information. 228 3.3. New Frames and Modifications 230 3.3.1. Definition of Frames 231 To support the notion of end-to-end extension frames, one Reserved 232 bit from the Frame Header is given a defined meaning: 234 0 1 2 3 235 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | R | Length (14) | Type (8) | Flags (8) | 238 +-+-+-----------+---------------+-------------------------------+ 239 |E| Stream Identifier (31) | 240 +-+-------------------------------------------------------------+ 241 | Frame Payload (0...) ... 242 +---------------------------------------------------------------+ 244 Frame Header 246 The newly-added "E" field marks whether a frame is intended for end- 247 to-end transmission or hop-by-hop transmission. End-to-end frames 248 MUST be relayed by intermediaries, even if the frame type is unknown. 249 Such frames do not imply any changes to stream or session state. 250 End-to-end frames are always subject to flow control. 252 An end-to-end frame on stream zero is meaningless, and MUST be 253 discarded upon receipt. 255 Of the frames defined in the base HTTP/2 spec, DATA frames MUST set 256 the E bit; all other control frames (WINDOW_UPDATE, PUSH_PROMISE, 257 HEADERS, etc.) MUST NOT set the E bit. Receipt of a base HTTP/2 258 frame with the E bit set improperly indicates a fundamental error in 259 the remote implementation, and MUST trigger a connection error of 260 type PROTOCOL_ERROR. 262 3.3.2. EXTENSIONS Frame 264 The EXTENSIONS frame (number TBD) carries a list of zero or more 265 extensions supported by the sender: 267 0 1 2 3 268 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Extension ID (32) | 271 +---------------------------------------------------------------+ 272 | Extension-specific data (32) | 273 +---------------------------------------------------------------+ 275 EXTENSIONS format 277 For each extension, the sender includes 32 bits of inital state. The 278 semantics of this value are completely defined by the extension. 280 3.3.3. EXPANDED Frame 282 The EXPANDED frame (number 0xFF) expands the space of frame types by 283 supplying additional bits for the frame type: 285 0 1 2 3 286 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 |0| Expanded Frame Type (31) | 289 +---------------------------------------------------------------+ 290 | Frame Payload (0...) ... 291 +---------------------------------------------------------------+ 293 EXPANDED Format 295 In order to mitigate the concern that 256 frame types are too few to 296 allow free access to extensions, the EXPANDED frame defines an 297 additional 31 bits that can be used for the frame type space. Frame 298 types numbered 256 or greater are encoded within an EXPANDED frame, 299 and the Expanded Frame Type field set to the desired frame type value 300 minus 256. This increases the maximum frame type to 0x80000100 301 without increasing the frame size for common frame types. 303 Implementations which have no knowledge of frame types greater than 304 255 MAY ignore any EXPANDED frames upon receipt, though 305 intermediaries MUST still relay end-to-end EXPANDED frames. 307 3.3.4. Extension-Defined Frames 309 An extension MAY define new frame types, which are registered with 310 IANA. Frame types greater than 0x80000000 will not be allocated by 311 IANA and are reserved for use by experimental extensions. Frame 312 types less than 256 are reserved for assignment by standards-track 313 RFCs. 315 As part of the definition of the extension and frame type, the 316 extension MUST specify whether the frames it defines modify session 317 state in any way, including being flow-controlled. (Any frame which 318 modifies session state MUST NOT be sent prior to receipt of an 319 EXTENSIONS frame declaring support for the specified extension.) 321 Only frames which do not change stream or session state may be marked 322 as end-to-end, since intermediaries which do not understand the frame 323 type would not be able to track the state changes. Because end-to- 324 end frames have unknown payload and provenance, end-to-end frames are 325 always flow-controlled. 327 Frames which do not modify stream or session state MAY be sent at any 328 time. However, an implementation SHOULD NOT send hop-by-hop 329 extension frames after receiving an EXTENSIONS frame indicating that 330 the other party will not understand the frame being sent. 332 An extension has complete freedom to define the payload, flags, and 333 other semantics of the frames it specifies, including when and on 334 what streams the frame may or may not be sent. 336 3.3.4.1. Handling by Intermediaries 338 Intermediaries MUST forward all end-to-end frames regardless of 339 whether they recognize the frame type. Endpoints (user agents and 340 origin servers) MUST discard any frame types which they do not 341 recognize. Such frames are, by definition, informational and can be 342 safely ignored without affecting the shared state with the sender. 344 All hop-by-hop extension-defined frames MUST be dropped by 345 intermediaries which do not support the extension. However, each 346 extension SHOULD specify how an intermediary translates the frames 347 defined by the extension toward other peers which might or might not 348 support the same extension. When an intermediary advertises support 349 for an extension, it MUST abide by the extension-defined intermediary 350 behavior. 352 An intermediary which advertises support for an extension is 353 explicitly not guaranteeing that all peers to which it will relay 354 information support the same extensions. Extension definitions 355 SHOULD define how intermediaries translate in the following 356 situations: 358 Relaying to HTTP/1.1 connection 360 Relaying to HTTP/2 connection without extension support 362 Relaying to HTTP/2 connection with extension support 364 3.4. Settings 365 This draft restores the definition of a setting value as follows: 367 0 1 2 3 368 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Identifier (32) | 371 +---------------------------------------------------------------+ 372 | Value (32) | 373 +---------------------------------------------------------------+ 375 Modified Setting Value Format 377 Extensions may define settings whose identifiers are registered with 378 IANA. The semantics of any such setting value are defined strictly 379 by the extension. Implementations MUST ignore unknown settings and 380 MUST NOT emit settings defined by an extension which has not been 381 announced in an EXTENSIONS (Section 3.3.2) frame. 383 4. IANA Considerations 385 This draft proposes the restoration to the HTTP/2 spec of IANA 386 registries for the following, pre-populated with the values defined 387 in the HTTP/2 specification: 389 o Frame types, with values less than 256 restricted to standards- 390 track RFCs and values greater than 0x80000000 reserved for private 391 experimental use 393 o Setting identifiers, with values greater than 0xFFFF0000 reserved 394 for private experimental use 396 o Error codes 398 And additionally, the creation of a registry for Extension IDs, with 399 values above 0xFFFF0000 reserved for private experimental use. 401 Given the expanded space, these registries should be allocated on a 402 first-come-first-served [RFC5226] basis except as described above, 403 though a publicly-available specification for each extension is 404 strongly recommended. 406 5. References 408 [I-D.ietf-httpbis-alt-svc] 409 Nottingham, M., McManus, P., and J. Reschke, "HTTP 410 Alternative Services", draft-ietf-httpbis-alt-svc-01 (work 411 in progress), April 2014. 413 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 414 Requirement Levels", BCP 14, RFC 2119, March 1997. 416 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 417 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 418 May 2008. 420 [RFC6709] Carpenter, B., Aboba, B., and S. Cheshire, "Design 421 Considerations for Protocol Extensions", RFC 6709, 422 September 2012. 424 Appendix A. Example Extensions 426 This section describes how certain extensions might leverage the 427 above model. Because a number of recent additions to the HTTP/2 428 specifications are excellent candidates for extension definition, 429 they are used as examples here. 431 A.1. Blocked Flow-Control Announcement Extension 433 A.1.1. EXTENSIONS Payload 435 Support for the Blocked Flow Control Announcement Extension is 436 indicated by including extension ID 0xB39D237F in an EXTENSIONS 437 frame. The initial data in the EXTENSIONS frame MUST be zero when 438 sent and MUST be ignored on receipt. 440 A.1.2. BLOCKED Frame 442 The BLOCKED frame defines no flags and contains no interpretable 443 payload. Because the frame is experimental, each BLOCKED frame MUST 444 contain the static payload 0xABED6142 for disambiguation. A receiver 445 MUST treat the receipt of a BLOCKED frame with any other payload as 446 an unknown frame type and ignore it. 448 A.1.3. Use of BLOCKED Frame 450 The BLOCKED frame is used to provide feedback about the performance 451 of flow control for the purposes of performance tuning and debugging. 452 The BLOCKED frame can be sent by a peer when flow controlled data 453 cannot be sent due to the connection- or stream-level flow control 454 window being zero or less. This frame MUST NOT be sent if there are 455 other reasons preventing data from being sent, such as a lack of 456 available data or the underlying transport being blocked. 458 The BLOCKED frame MAY be sent on a connection prior to receiving an 459 EXTENSIONS frame, but SHOULD NOT be sent after the receipt of an 460 EXTENSIONS frame which does not include the BLOCKED extension ID. 462 The BLOCKED frame is sent on the stream that is blocked, that is, the 463 stream with a non-positive number of bytes available in the flow 464 control window. A BLOCKED frame can be sent on stream 0x0 to 465 indicate that connection-level flow control is blocked. 467 An endpoint MUST NOT send any subsequent BLOCKED frames until the 468 affected flow control window becomes positive. This means that 469 WINDOW_UPDATE frames are received or SETTINGS_INITIAL_WINDOW_SIZE is 470 increased before more BLOCKED frames can be sent. 472 A.1.4. Behavior by Intermediaries 474 Because flow-control is hop-by-hop, intermediaries MUST NOT relay a 475 BLOCKED frame onto any other connection. If the intermediary is 476 blocked by flow control, they MAY generate BLOCKED frames 477 independently on other connections where BLOCKED is supported. 479 A.2. Alternate-Service Announcement 481 A.2.1. EXTENSIONS Payload 483 Support for the Alternate Service Announcement Extension is indicated 484 by including extension ID 0x8877B974 in an EXTENSIONS frame. The 485 initial data in the EXTENSIONS frame MUST be zero when sent and MUST 486 be ignored on receipt. 488 A.2.2. ALTSVC Frame 490 0 1 2 3 491 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Max-Age (32) | 494 +-------------------------------+---------------+---------------+ 495 | Port (16) | Proto-Len (8) | 496 +-------------------------------+---------------+---------------+ 497 | Protocol-ID (*) | 498 +---------------+-----------------------------------------------+ 499 | Host-Len (8) | Host (*) ... 500 +---------------+-----------------------------------------------+ 501 | Origin? (*) ... 502 +---------------------------------------------------------------+ 504 ALTSVC Frame Payload 506 The ALTSVC frame contains the following fields: 508 Max-Age: An unsigned, 32-bit integer indicating the freshness 509 lifetime of the alternative service association. 511 Port: An unsigned, 16-bit integer indicating the port that the 512 alternative service is available upon. 514 Proto-Len: An unsigned, 8-bit integer indicating the length, in 515 octets, of the Protocol-ID field. 517 Protocol-ID: A sequence of bytes (length determined by "Proto-Len") 518 containing the ALPN protocol identifier of the alternative 519 service. 521 Host-Len: An unsigned, 8-bit integer indicating the length, in 522 octets, of the Host field. 524 Host: A sequence of characters (length determined by "Host-Len") 525 containing an ASCII string indicating the host that the 526 alternative service is available upon. An internationalized 527 domain name MUST be expressed using A-labels. 529 Origin: An optional sequence of characters (length determined by 530 subtracting the length of all preceding fields from the frame 531 length) containing the ASCII serialisation of an origin that the 532 alternate service is applicable to. 534 The ALTSVC frame does not define any flags. 536 A.2.3. Use of ALTSVC Frame 538 The ALTSVC frame (type=0xA) advertises the availability of an 539 alternative service to the client. It can be sent at any time for an 540 existing client-initiated stream or stream 0, and is intended to 541 allow servers to load balance or otherwise segment traffic; see 542 [I-D.ietf-httpbis-alt-svc] for details. 544 An ALTSVC frame on a client-initiated stream indicates that the 545 conveyed alternative service is associated with the origin of that 546 stream. 548 An ALTSVC frame on stream 0 indicates that the conveyed alternative 549 service is associated with the origin contained in the Origin field 550 of the frame. An association with an origin that the client does not 551 consider authoritative for the current connection MUST be ignored. 553 The ALTSVC frame is intended for receipt by clients; a server that 554 receives an ALTSVC frame MAY treat it as a connection error of type 555 PROTOCOL_ERROR. 557 A server MAY send an ALTSVC frame before receiving an EXTENSIONS 558 frame listing support for the Alternate-Service Availability 559 Announcement extension, but SHOULD NOT send an ALTSVC frame after 560 receiving an EXTENSIONS frame which does not declare support. 562 A.2.4. Behavior by Intermediaries 564 The ALTSVC frame is processed hop-by-hop. An intermediary MUST NOT 565 forward ALTSVC frames, though it can use the information contained in 566 ALTSVC frames in forming new ALTSVC frames to send to its own 567 clients. 569 A.3. Compressed Data Frames 571 The COMPRESSED_DATA frame (type=TBD) permits a frame-by-frame choice 572 of transfer encoding, permitting connections to employ compression 573 where appropriate while still enabling the separation of different 574 data into different contexts as appropriate. 576 A.3.1. EXTENSIONS Payload 578 Support for the Compressed Data Extension is indicated by the 579 following in an EXTENSIONS frame: 581 0 1 2 3 582 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | Extension ID (32) | 585 +---------------+-----------------------------------------------+ 586 | Contexts (8) | Supported algorithms (24) | 587 +---------------+-----------------------------------------------+ 589 Compressed Data in EXTENSIONS 591 The EXTENSIONS entry contains the following fields: 593 Extension ID: The extension ID for the Compressed Data Extension is 594 0x53F9F537. 596 Contexts An eight-bit count of the number of separate compression 597 contexts the sender is willing to maintain. This SHOULD be 598 greater than zero. 600 Supported algorithms A bitmap of compression algorithms supported by 601 the sender: 603 0x001: Compress The "compress" coding is an adaptive Lempel-Ziv- 604 Welch (LZW) coding that is commonly produced by the UNIX file 605 compression program "compress". 607 0x002: Deflate The "deflate" coding is a "zlib" data format 608 [RFC1950] containing a "deflate" compressed data stream 609 [RFC1951] that uses a combination of the Lempel-Ziv (LZ77) 610 compression algorithm and Huffman coding. 612 0x003: GZip The "gzip" coding is an LZ77 coding with a 32 bit 613 CRC that is commonly produced by the gzip file compression 614 program [RFC1952]. 616 Other bits: Reserved for future updates; MUST be zero when sent 617 and ignored upon receipt 619 Setting the corresponding bit indicates that the sender supports 620 creating a compression context for the corresponding algorithm. 622 A.3.2. COMPRESSED_DATA Frame 624 The COMPRESSED_DATA frame defines the following flags: 626 END_STREAM (0x1): Bit 1 being set indicates that this frame is the 627 last that the endpoint will send for the identified stream. 628 Setting this flag causes the stream to enter one of the "half 629 closed" states or the "closed" state. 631 END_SEGMENT (0x2): Bit 2 being set indicates that this frame is the 632 last for the current segment. Intermediaries MUST NOT coalesce 633 frames across a segment boundary and MUST preserve segment 634 boundaries when forwarding frames. 636 PAD_LOW (0x8): Bit 4 being set indicates that the Pad Low field is 637 present. 639 PAD_HIGH (0x10): Bit 5 being set indicates that the Pad High field 640 is present. This bit MUST NOT be set unless the PAD_LOW flag is 641 also set. Endpoints that receive a frame with PAD_HIGH set and 642 PAD_LOW cleared MUST treat this as a connection error of type 643 PROTOCOL_ERROR. 645 Init_Context (0x20): Indicates the presence of the Algorithm and 646 Initialization fields in the COMPRESSED_DATA frame. MUST be set 647 on the first frame to reference a context which has not previously 648 been used, or which has been cleared. If set on any other frame, 649 the previous value of the context MUST be discarded before further 650 processing. 652 Clear_Context (0x40): Indicates that this is the last frame which 653 will use the current context state, and that the context MUST be 654 discarded after interpretation of the current frame. 656 The payload is formatted as follows: 658 0 1 2 3 659 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | Pad High? (8) | Pad Low? (8) | Context (8) | Algorithm? (8)| 662 +---------------+---------------+---------------+---------------+ 663 | Compressed payload (*) ... 664 +---------------+-----------------------------------------------+ 665 | Padding? (*) ... 666 +---------------------------------------------------------------+ 668 COMPRESSED_DATA 670 The fields are: 672 Pad High: An 8-bit field containing an amount of padding in units of 673 256 octets. This field is optional and is only present if the 674 PAD_HIGH flag is set. This field, in combination with Pad Low, 675 determines how much padding there is on a frame. 677 Pad Low: An 8-bit field containing an amount of padding in units of 678 single octets. This field is optional and is only present if the 679 PAD_LOW flag is set. This field, in combination with Pad High, 680 determines how much padding there is on a frame. 682 Context: An eight-bit value reflecting which of the connection's 683 contexts the sender intends to use. This MUST be less than the 684 value the recipient declared in EXTENSIONS. 686 Algorithm: Present only if the Init_Context flag is set. Declares 687 the compression algorithm the sender intends to employ on the new 688 context. Integer taken from the same list employed in the 689 EXTENSIONS frame to announce support. 691 Compressed payload The remainder of the payload is the compressed 692 content, interpreted using the selected compression context. 694 Padding: Padding octets that contain no application semantic value. 695 Padding octets MUST be set to zero when sending and ignored when 696 receiving. 698 A.3.3. Use of COMPRESSED_DATA Frame 700 The COMPRESSED_DATA frame may be sent instead of a DATA frame 701 provided that both of the following are true: 703 The sender is allowed to send a DATA frame at this time on this 704 stream 706 The recipient has advertised support for the Compressed Data 707 Extension 709 The sender SHOULD clear contexts, use different contexts, or compress 710 selectively to prevent attacker-controlled data from being compressed 711 in the same compression context as server-controlled data. 713 COMPRESSED_DATA frames are subject to flow control and can only be 714 sent when a stream is in the "open" or "half closed (remote)" states. 715 The entire frame payload is included in flow control, including Pad 716 Low, Pad High, Context, Algorithm, Initialization, and Padding fields 717 if present. If a COMPRESSED_DATA frame is received whose stream is 718 not in "open" or "half closed (local)" state, the recipient MUST 719 respond with a stream error of type STREAM_CLOSED. After processing 720 flow control, the frame is decompressed and the result processed as 721 if a DATA frame with the decompressed payload had just been received. 723 If the COMPRESSED_DATA frame had the Clear_Context flag set, the 724 sender MUST discard the compression context immediately following 725 compression, and the recipient MUST do likewise immediately after 726 decompression. 728 A.3.4. Behavior by Intermediaries 730 COMPRESSED_DATA frames are processed hop-by-hop, though an 731 intermediary MAY relay the same compressed content onto another 732 connection if an identical compression context is available. 734 Intermediaries MAY convert COMPRESSED_DATA frames to use different 735 compression schemes on different connections, and MAY convert 736 COMPRESSED_DATA frames into DATA frames on connections which do not 737 support this extension or which do not support a compression 738 algorithm to which the intermediary is willing to convert. 740 Intermediaries MUST NOT convert DATA frames into COMPRESSED_DATA 741 frames. 743 Appendix B. Acknowledgements 745 This document includes input from Rob Trace, Gabriel Montenegro, and 746 James Snell. 748 Sample extensions are based largely on the work of Mark Nottingham, 749 Roberto Peon, and Matthew Kerwin. 751 Author's Address 753 Mike Bishop 754 Microsoft 756 EMail: michbish@microsoft.com