idnits 2.17.1 draft-kinnear-httpbis-http2-transport-00.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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 10, 2018) is 2053 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) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Kinnear 3 Internet-Draft T. Pauly 4 Intended status: Standards Track Apple Inc. 5 Expires: March 14, 2019 September 10, 2018 7 Using HTTP/2 as a Transport for Arbitrary Bytestreams 8 draft-kinnear-httpbis-http2-transport-00 10 Abstract 12 HTTP/2 provides multiplexing of HTTP requests over a single 13 underlying transport connection. HTTP/2 Transport defines a 14 transport abstraction provided by HTTP/2 framing that is separate 15 from HTTP semantics. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on March 14, 2019. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 2 53 2. The STREAM HTTP/2 Frame . . . . . . . . . . . . . . . . . . . 2 54 2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.2. Advertising Support for STREAM Frames . . . . . . . . . . 4 56 2.3. Processing STREAM Frames . . . . . . . . . . . . . . . . 4 57 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 59 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 60 6. Normative References . . . . . . . . . . . . . . . . . . . . 5 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 63 1. Introduction 65 HTTP/2 [RFC7540] provides a framing layer that describes the exchange 66 of HTTP messages following HTTP semantics. This framing layer 67 provides multiplexing of multiple streams on a single underlying 68 transport connection, flow control, stream dependencies and 69 priorities, and exchange of configuration information between 70 endpoints. HTTP/2 also defines the mapping of HTTP semantics onto 71 that framing layer. 73 This document defines the use of the HTTP/2 framing layer as a 74 transport for arbitrary byte streams without the use of HTTP 75 semantics. 77 1.1. Notational Conventions 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 81 "OPTIONAL" in this document are to be interpreted as described in BCP 82 14 [RFC2119] [RFC8174] when, and only when, they appear in all 83 capitals, as shown here. 85 2. The STREAM HTTP/2 Frame 87 This document defines a new HTTP/2 frame type called STREAM, that 88 allows endpoints to open HTTP/2 streams without header values. 89 Either endpoint can send this frame to open a stream. STREAM frames 90 are treated in all ways as HEADERS frames, including in the stream 91 state machine, but are not required to contain any header values. 93 2.1. Syntax 95 The STREAM frame type is 0xd (decimal 13) and contains similar fields 96 to that of the HEADERS frame. 98 A STREAM frame is shown below. 100 0 1 2 3 101 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 102 +---------------+ 103 |Pad Length? (8)| 104 +-+-------------+-----------------------------------------------+ 105 |E| Stream Dependency? (31) | 106 +-+-------------+-----------------------------------------------+ 107 | Weight? (8) | 108 +-+-------------+-----------------------------------------------+ 109 | Padding (*) ... 110 +---------------------------------------------------------------+ 112 Figure 1: STREAM Frame Format 114 The STREAM frame contains the following fields: 116 Pad Length: An 8-bit field containing the length of the frame 117 padding in units of octets. This field is only present if the 118 PADDED flag is set. 120 E: A single-bit flag indicating that the stream dependency is 121 exclusive (see Section 5.3 of [RFC7540]). This field is only 122 present if the PRIORITY flag is set. 124 Stream Dependency: A 31-bit stream identifier for the stream that 125 this stream depends on (see Section 5.3 of [RFC7540]). This field 126 is only present if the PRIORITY flag is set. 128 Weight: An unsigned 8-bit integer representing a priority weight for 129 the stream (see Section 5.3 of [RFC7540]). Add one to the value 130 to obtain a weight between 1 and 256. This field is only present 131 if the PRIORITY flag is set. 133 Padding: Padding octets. 135 The STREAM frame defines the following flags: 137 PADDED (0x8): When set, bit 3 indicates that the Pad Length field 138 and any padding that it describes are present. 140 PRIORITY (0x20): When set, bit 5 indicates that the Exclusive Flag 141 (E), Stream Dependency, and Weight fields are present; see 142 Section 5.3 of [RFC7540]. 144 STREAM frames MUST be associated with a stream. If a STREAM frame is 145 received whose stream identifier field is 0x0, the recipient MUST 146 respond with a connection error of type PROTOCOL_ERROR. 148 The STREAM frame can include padding. Padding fields and flags are 149 identical to those defined for DATA frames. 151 Prioritization information in a STREAM frame is logically equivalent 152 to a separate PRIORITY frame, but inclusion in a STREAM frame avoids 153 the potential for churn in stream prioritization when new streams are 154 created. Prioritization fields in STREAM frames subsequent to the 155 first on a stream reprioritize the stream (Section 5.3.3 of 156 [RFC7540]). 158 2.2. Advertising Support for STREAM Frames 160 As defined in [RFC7540], both endpoints can send 161 SETTINGS_MAX_CONCURRENT_STREAMS in SETTINGS frames to indicate the 162 number of streams that the sender permits the receiver to create. 163 This limit applies to streams created via the STREAM frame as well as 164 streams created via HEADERS frames. 166 2.3. Processing STREAM Frames 168 The STREAM frame is a non-critical extension to HTTP/2. Endpoints 169 that do not support this frame can safely ignore it upon receipt. 171 When received by a client that implements support, the STREAM frame 172 behaves in the same manner as a HEADERS frame, but does not carry any 173 header blocks. This changes the connection state in the same manner 174 as a HEADERS frame, described in Section 4.3 of [RFC7540]. 176 STREAM frames can be sent on a stream in the "idle", "reserved 177 (local)", "open", or "half-closed (remote)" state. STREAM frames can 178 be sent by either endpoint on a connection. 180 Streams created via a STREAM frame are multiplexed in the same manner 181 on the underlying transport connection as streams created via a 182 HEADERS frame. Flow control also applies to these streams in the 183 same way. Flow control, stream dependencies, and priorities continue 184 to apply to streams as defined by [RFC7540]. 186 Anywhere an endpoint would be permitted to send a HEADERS frame by 187 [RFC7540], it is likewise permitted to send a STREAM frame. 189 A stream is closed via a RST_STREAM frame or by setting the 190 END_STREAM flag on a DATA frame. 192 3. IANA Considerations 194 This specification adds an entry to the "HTTP/2 Frame Type" registry. 196 o Frame Type: STREAM 198 o Code: 0xd 200 o Specification: [[RFC Editor: Please fill in this value with the 201 RFC number for this document.]] 203 4. Security Considerations 205 5. Acknowledgments 207 Thanks to Anthony Chivetta, Joshua Otto, and Valentin Pistol for 208 their contributions in the design and prototyping of this work. 210 6. Normative References 212 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 213 Requirement Levels", BCP 14, RFC 2119, 214 DOI 10.17487/RFC2119, March 1997, 215 . 217 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 218 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 219 DOI 10.17487/RFC7540, May 2015, 220 . 222 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 223 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 224 May 2017, . 226 Authors' Addresses 228 Eric Kinnear 229 Apple Inc. 230 One Apple Park Way 231 Cupertino, California 95014 232 United States of America 234 Email: ekinnear@apple.com 235 Tommy Pauly 236 Apple Inc. 237 One Apple Park Way 238 Cupertino, California 95014 239 United States of America 241 Email: tpauly@apple.com