idnits 2.17.1 draft-bishop-httpbis-decomposing-http-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 14, 2016) is 2957 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-21) exists of draft-ietf-core-block-18 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). 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 Intended status: Informational March 14, 2016 5 Expires: September 15, 2016 7 Decomposing the Hypertext Transfer Protocol 8 draft-bishop-httpbis-decomposing-http-00 10 Abstract 12 The Hypertext Transfer Protocol in its various versions combines 13 concepts of both an application and transport-layer protocol. As 14 this group contemplates employing alternate transport protocols 15 underneath HTTP, this document attempts to delineate the boundaries 16 between these functions to define a shared vocabulary in discussing 17 the revision and/or replacement of one or more of these components. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 15, 2016. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. The Semantic Layer . . . . . . . . . . . . . . . . . . . . . 3 55 3. Transport Services Required . . . . . . . . . . . . . . . . . 4 56 3.1. Reliable delivery . . . . . . . . . . . . . . . . . . . . 5 57 3.2. In-order delivery . . . . . . . . . . . . . . . . . . . . 5 58 3.3. Partial delivery . . . . . . . . . . . . . . . . . . . . 5 59 3.4. Separate request/response, metadata, and payload . . . . 6 60 3.5. Flow control and throttling . . . . . . . . . . . . . . . 6 61 3.6. Other desirable properties . . . . . . . . . . . . . . . 6 62 3.6.1. Parallelism . . . . . . . . . . . . . . . . . . . . . 7 63 3.6.2. Security . . . . . . . . . . . . . . . . . . . . . . 7 64 3.6.3. Efficiency . . . . . . . . . . . . . . . . . . . . . 7 65 4. The Transport Adaptation Layer . . . . . . . . . . . . . . . 8 66 4.1. HTTP/1.x over TCP . . . . . . . . . . . . . . . . . . . . 9 67 4.1.1. Metadata and framing . . . . . . . . . . . . . . . . 9 68 4.1.2. Parallelism and request limiting . . . . . . . . . . 9 69 4.1.3. Security . . . . . . . . . . . . . . . . . . . . . . 10 70 4.1.4. Attempts to improve the TCP mapping . . . . . . . . . 10 71 4.2. HTTP/1.x over SCTP . . . . . . . . . . . . . . . . . . . 10 72 4.3. HTTP/2 over TCP . . . . . . . . . . . . . . . . . . . . . 11 73 4.3.1. Framing and Parallelism . . . . . . . . . . . . . . . 11 74 4.3.2. Congestion and flow control . . . . . . . . . . . . . 12 75 4.3.3. Security . . . . . . . . . . . . . . . . . . . . . . 12 76 4.4. HTTPU(M) and CoAP . . . . . . . . . . . . . . . . . . . . 12 77 4.5. QUIC over UDP, or HTTP/2 over QUIC, or...? . . . . . . . 13 78 5. Moving Forward . . . . . . . . . . . . . . . . . . . . . . . 13 79 6. Informative References . . . . . . . . . . . . . . . . . . . 14 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 82 1. Introduction 84 The Hypertext Transfer Protocol defines a very flexible tool set 85 enabling client applications to make requests of a server for content 86 or action. This general protocol was conceived for "the web," 87 interconnected pages of Hypertext Markup Language (HTML) and 88 associated resources used to render the HTML, but has since been used 89 as a general-purpose application transport. Server APIs are commonly 90 exposed as REST APIs, accessed over HTTP. 92 HTTP/1.0 [RFC1945] was a text-based protocol which did not specify 93 its underlying transport, but describes the mapping this way: 95 On the Internet, HTTP communication generally takes place over 96 TCP/IP connections. The default port is TCP 80, but other ports 97 can be used. This does not preclude HTTP from being implemented 98 on top of any other protocol on the Internet, or on other 99 networks. HTTP only presumes a reliable transport; any protocol 100 that provides such guarantees can be used, and the mapping of the 101 HTTP/1.0 request and response structures onto the transport data 102 units of the protocol in question is outside the scope of this 103 specification. 105 HTTP/1.1 [RFC7230] expands on the TCP binding, introducing connection 106 management concepts into the HTTP layer. 108 HTTP/2 [RFC7540] replaced the simple text-based protocol with a 109 binary framing. Conceptually, HTTP/2 achieved the same properties 110 required of a TCP mapping using wildly different strategies from 111 HTTP/1.1. HTTP/1.1 achieves properties such as parallelism and out- 112 of-order delivery by the use of multiple TCP connections. HTTP/2 113 implements these services on top of TCP to enable the use of a single 114 TCP connection. The working group's charter to maintain HTTP's broad 115 applicability meant that there were few or no changes in how HTTP 116 surfaces to applications. 118 Other efforts have mapped HTTP or a subset of it to various transport 119 protocols besides TCP - HTTP can be implemented over SCTP [RFC4960] 120 as in [I-D.natarajan-http-over-sctp], and useful profiles of HTTP 121 have been mapped to UDP in various ways (HTTPU and HTTPUM in 122 [goland-http-udp] and [UPnP], CoAP [RFC7252], QUIC 123 [I-D.tsvwg-quic-protocol]). 125 With the publication of HTTP/2 over TCP, the working group is 126 beginning to consider how a mapping to a non-TCP transport would 127 function. This document aims to enable this conversation by 128 describing the services required by the HTTP semantic layer. A 129 mapping of HTTP to a transport other than TCP must define how these 130 services are obtained, either from the new transport or by 131 implementing them at the application layer. 133 2. The Semantic Layer 135 At the most fundamental level, the semantic layer of HTTP consists of 136 a client's ability to request some action of a server and be informed 137 of the outcome of that request. HTTP defines a number of possible 138 actions (methods) the client might request of the server, but permits 139 the list of actions to be extended. 141 A client's request consists of a desired action (HTTP method) and a 142 resource on which that action is to be taken (path). The server 143 responds which a status code which informs the client of the result 144 of the request - the outcome of the action or the reason the action 145 was not performed. Actions may or may not be idempotent or safe, and 146 the results may or may not be cached by intermediaries; this is 147 defined as part of the HTTP method. 149 Each message (request or response) has associated metadata, called 150 "headers," which provide additional information about the operation. 151 In a request this might include client identification, credentials 152 authorizing the client to request the action, or preferences about 153 how the client would prefer the server handle the action. In a 154 response, this might include information about the resulting data, 155 modifications to the cacheability of the response, details about how 156 the server performed the action, or details of the reason the server 157 declined to perform the action. 159 The headers are key-value pairs, with rules defining how keys which 160 occur multiple times should be handled. Due to artifacts of existing 161 usage, these rules vary from key to key. For similar legacy reasons, 162 there is no uniform structure of the values across all keys. Keys 163 are case-insensitive ASCII strings, while values are sequences of 164 octets typically interpreted as ASCII. Many headers are defined by 165 the HTTP RFCs, but the space is not constrained and is frequently 166 extended with little or no notice. "Trailing" headers are split, 167 with the key declared in advance, but the value coming only after the 168 body has been transferred. 170 Each message, whether request or response, also has an optional body. 171 The presence and content of the body will vary based on the action 172 requested and the headers provided. 174 3. Transport Services Required 176 The HTTP Semantic Layer depends on the availability of several 177 services from its lower layer: 179 o Reliable delivery 181 o In-order delivery 183 o Partial delivery 185 o Separate request/response, metadata, and payload 187 o Flow control and throttling 189 In this section, each of these properties will be discussed at a high 190 level with a focus on why HTTP requires these properties to be 191 present. The next section (Section 4) will discuss how various HTTP 192 mappings have handled the absence of these required services in 193 different transports. 195 3.1. Reliable delivery 197 HTTP does not provide the concept to higher layers that fragments of 198 data were received while others were not. If a request is sent, it 199 is assumed that either a response will arrive or the transport will 200 report an error. HTTP itself is not concerned with any intermediate 201 states. 203 There are many ways for a transport to provide reliable delivery of 204 messages. This may take the form of loss recovery, where the loss of 205 packets is detected and the corresponding information retransmitted. 206 Alternately, a transport may proactively send extra information so 207 that the data stream is tolerant to some loss - the full message can 208 be reconstructed after receipt of a sufficient fraction of the 209 transmission. 211 It is worth noting that some consumers of HTTP have relaxed 212 requirements in this space - while HTTP itself has no notion of lossy 213 delivery, some mappings do have weakened guarantees and are only 214 appropriate for scenarios where those weakened guarantees are 215 acceptable. 217 3.2. In-order delivery 219 The headers of each message must arrive before any body, since they 220 dictate how the body will be processed. The body is typically 221 exposed as a bytestream which can be read from sequentially, though 222 there are some consumers who are able to use incomplete fragments of 223 certain resource types. 225 Regardless of the ability to surface and use fragmentary pieces of an 226 HTTP message, the HTTP layer requires the transport be able to 227 ultimately provide a correct ordering and full reconstruction of each 228 message. 230 3.3. Partial delivery 232 While only some users of HTTP (client or server) are able to deal 233 with unordered fragments of an HTTP message, it is almost universally 234 necessary to deal with HTTP messages in pieces. There are multiple 235 reasons why that may be necessary: 237 o The message may be too large to maintain in memory at once (the 238 download of a large file) 240 o The beginning of a request may be sufficient to generate a 241 response (error due to lack of authorization) 243 o The message may be constructed incrementally, sending each segment 244 as it becomes available 246 Regardless, HTTP needs the transport to begin sending the message 247 before the end of the message is available. 249 3.4. Separate request/response, metadata, and payload 251 Any protocol defines how the semantics of the protocol are mapped 252 onto the wire in a transport. Most transports are either bytestreams 253 or message-based, meaning that higher-layer concepts must be laid out 254 in a reasonable structure within the stream or message. Each HTTP 255 request or response contains metadata about the message (headers) and 256 an optional body. 258 These are separate constructs in HTTP, and mechanisms to carry them 259 and keep them appropriately associated must be provided. Note that 260 it's not actually expected that any _generic_ transport layer would 261 or should have this property, but is nonetheless involved in 262 transporting HTTP messages. 264 3.5. Flow control and throttling 266 Flow control is a necessary property of any transport. Because no 267 network can handle an uncontrolled burst of data at infinite speeds, 268 the transport must determine an appropriate sustained data rate for 269 the intervening network. Even in the presence of a nearly-infinite 270 network capacity, the remote server will also have limits on its 271 ability to consume data. 273 In order to avoid overwhelming either the network or the server, HTTP 274 requires a mechanism to limit sending data rates as well as to limit 275 the rate of new requests going to a server. Although it is optimal 276 for a server to know about all outstanding client requests (even if 277 it chooses not to work on them immediately), the server may wish to 278 protect itself by limiting the memory commitment to outstanding data 279 or requests. The transport should facilitate such protection on the 280 part of a server (or client, in certain scenarios). 282 3.6. Other desirable properties 284 There are several properties not properly required for the 285 implementation of HTTP, but which users of HTTP have come to assume 286 are present. 288 3.6.1. Parallelism 290 Because a client will often desire a single server to perform 291 multiple actions at once, all HTTP mappings provide the ability to 292 deliver requests in parallel and allow the server to respond to each 293 request as the actions complete. Head-of-line blocking is a 294 particular problem here that transports must attempt to avoid - 295 client requests should ideally reach the server as quickly as 296 possible, allowing the server to choose the correct order in which to 297 handle the requests (with input from the client). Any situation in 298 which a request remains unknown to the server until another request 299 completes is suboptimal. 301 3.6.2. Security 303 Integrity and confidentiality are valuable services for communication 304 over the Internet, and HTTP is no exception. While authentication, 305 message integrity, and secrecy are not inherently _required_ for the 306 implementation of HTTP, they are advantageous properties for any 307 mapping to have, so that each party can be sure that what they 308 received is what the other party sent. 310 Privacy, the control of what data is leaked to the peer and/or third 311 parties, is also a desirable attribute. However, this extends well 312 beyond the scope of any particular mapping and into the use of HTTP. 314 TLS [RFC5246] is commonly used in mappings to provide this service, 315 and itself requires reliable, in-order delivery. When those services 316 are not provided by the underlying transport, the mapping must either 317 provide those services to TLS as well as HTTP (as in QUIC) or a 318 variant of TLS which provides those services for itself must be 319 substituted (DTLS [RFC6347], as used in CoAP). 321 3.6.3. Efficiency 323 While it would be technically possible to define HTTP over a highly 324 inefficient transport or mapping (e.g. format messages in Baudot 325 code, transporting them to the server using avian carriers as in 326 [RFC1149]), there is little reason for applications to use such 327 inefficient mappings when efficient transport mappings exist. 329 Efficiency can be characterized on many levels: 331 o Reducing the number of bytes required to transport a message, 332 either through lower overhead or better compression 334 o Reducing the time from request generation to response receipt 335 o Reducing the amount of computation or memory required to process 336 or route a request 338 o Reducing the power consumption required to generate or process a 339 request 341 4. The Transport Adaptation Layer 343 No present transport over which HTTP has been mapped actually 344 provides all of the services on which the HTTP Semantic Layer 345 depends. In order to compensate for the services not provided by a 346 given underlying transport, each mapping of HTTP onto a new transport 347 must define an intermediate layer implementing the missing services 348 in order to enable the mapping, as well as any additional features 349 the mapping finds to be desirable. 351 In the following table, we can see multiple transports over which 352 HTTP has been deployed and the services which the underlying 353 transports do or do not offer. 355 +-------------------------------+-----+-----+------+------+ 356 | | TCP | UDP | SCTP | QUIC | 357 +-------------------------------+-----+-----+------+------+ 358 | Reliable delivery | X | | X | X | 359 | | | | | | 360 | In-order delivery | X | | X | X | 361 | | | | | | 362 | Partial delivery | X | X | X | X | 363 | | | | | | 364 | Separate metadata and payload | | | | * | 365 | | | | | | 366 | Flow control & throttling | X | X | X | X | 367 +-------------------------------+-----+-----+------+------+ 369 Some mappings contain entirely new protocol machinery constructed 370 specifically to serve as an adaptation layer and carried within the 371 transport (HTTP/2 framing over TCP). Others rely on implementation- 372 level meta-protocol behavior (simultaneous TCP connections handled in 373 parallel) not visible to the transport. Because the existence of 374 these adaptation layers has not been explicitly defined in the past, 375 a clean separation has not always been maintained between the 376 adaptation layer and either the transport or the semantic layer. 378 Some adaptation layers are so complex and fully-featured that the 379 transport layer plus the adaptation layer can be conceptually treated 380 as a new transport. For example, QUIC was originally designed as a 381 transport adaptation layer for HTTP over UDP, but is now being 382 refactored into a general-purpose transport layer for arbitrary 383 protocols. Such a refactoring will require separating the services 384 QUIC provides that are general to all applications from the services 385 which exist purely to enable a mapping of HTTP to QUIC. (In the 386 table above, QUIC is referenced as a generic transport; the HTTP- 387 over-QUIC mapping is discussed below.) 389 4.1. HTTP/1.x over TCP 391 Since HTTP/1.x is defined over TCP, many of the necessary services 392 are provided by the transport, enabling a relatively simple mapping. 393 However, there were a number of conventions introduced to fill lacks 394 in the underlying transport. 396 4.1.1. Metadata and framing 398 HTTP/1.x projects a message as an octet sequence which typically 399 resembles a block of ASCII text. Specific octets are used to delimit 400 the boundaries between message components. Within the portion of the 401 message dedicated to headers, the key-value pairs are expressed as 402 text, with the ':' character and whitespace separating the key from 403 the value. 405 Because this region appears to be text, many text conventions have 406 accidentally crept into HTTP/1.x message parsers and even protocol 407 conventions (line-folding, CRLF differences between operating 408 systems, etc.). This is a source of bugs, such as line-folding 409 characters which appear in header values even after being unframed. 411 4.1.2. Parallelism and request limiting 413 HTTP/1.0 used a very simple multi-request model - each request was 414 made on a separate TCP connection, and all requests were handled 415 independently. This had the drawback that TCP connection setup was 416 required with each request and flow control almost never exited the 417 slow-start phase, limiting performance. 419 To improve this, new headers were introduced to manage connection 420 lifetime (e.g. "Connection: keep-alive"), blurring the distinction 421 between message metadata and connection metadata. These headers were 422 formalized in HTTP/1.1. This improvement means that connections are 423 reused - when the end of a response has been received, a new request 424 can be sent. However, this blurring made it difficult for some 425 implementations to correctly identify the presence and length of 426 bodies, making request-smuggling attacks possible as in 427 [watchfire-request-smuggling]. 429 Throttling of simultaneous requests was fully in the realm of 430 implementations, which constrained themselves to opening only a 431 limited number of connections. HTTP/1.1 originally recommended two, 432 but later implementations increased this to six by default, and more 433 under certain conditions. Because these were fully independent 434 flows, TCP was unable to consider them as a group for purposes of 435 congestion control, leading to suboptimal behavior on the network. 437 Servers which desired additional parallelism could game such 438 implementations by exposing resources under multiple hostnames, 439 causing the client implementations to open six connections _to each 440 hostname_ and gain an arbitrary amount of parallelism, to the 441 detriment of functional congestion control. 443 4.1.3. Security 445 HTTP originally defined no additional integrity or confidentiality 446 mechanisms for the TCP mapping, leaving the integrity and 447 confidentiality levels to those provided by the network transport. 448 These may be minimal (TCP checksums) or rich (IPsec) depending on the 449 network environment. 451 For situations where the network does not provide integrity and 452 confidentiality guarantees sufficient to the content, [RFC2818] 453 defines the use of TLS as an additional component of the adaptation 454 layer in HTTP/1.1. 456 4.1.4. Attempts to improve the TCP mapping 458 Pipelining, also introduced in HTTP/1.1, allowed the client to 459 eliminate the round-trip that was incurred between the end of the 460 server's response to one request and the server's receipt of the 461 client's next request. However, pipelining increases the problem of 462 head-of-line blocking since a request on a different connection might 463 complete sooner. The client's inability to predict the length of 464 requested actions limited the usefulness of pipelining. 466 SMUX [w3c-smux] allowed the use of a single TCP connection to carry 467 multiple channels over which HTTP could be carried. This would 468 permit the server to answer requests in any order. However, this was 469 never broadly deployed. 471 4.2. HTTP/1.x over SCTP 473 Because SCTP permits the use of multiple simultaneous streams over a 474 single connection, HTTP/1.1 could be mapped with relative ease. 475 Instead of using separate TCP connections, SCTP flows could be used 476 to provide a multiplexing layer. Each flow was reused for new 477 requests after the completion of a response, just as HTTP/1.1 used 478 TCP connections. This allowed for better flow control performance, 479 since the transport could consider all flows together. 481 SCTP has seen limited deployment on the Internet, though recent 482 experience has shown SCTP over UDP [RFC6951] to be a more viable 483 combination. 485 4.3. HTTP/2 over TCP 487 HTTP/2, also a TCP mapping, attempted to improve the mapping of HTTP 488 to TCP without introducing changes at the semantic level. 490 HTTP/2 addresses these issues by defining an optimized mapping of 491 HTTP's semantics to an underlying connection. Specifically, it 492 allows interleaving of request and response messages on the same 493 connection and uses an efficient coding for HTTP header fields. 494 It also allows prioritization of requests, letting more important 495 requests complete more quickly, further improving performance. 497 The resulting protocol is more friendly to the network because 498 fewer TCP connections can be used in comparison to HTTP/1.x. This 499 means less competition with other flows and longer-lived 500 connections, which in turn lead to better utilization of available 501 network capacity. 503 Finally, HTTP/2 also enables more efficient processing of messages 504 through use of binary message framing. 506 4.3.1. Framing and Parallelism 508 HTTP/2 introduced a framing layer that incorporated the concept of 509 streams. Because a very large number of idle streams automatically 510 exist at the beginning of each connection, each stream can be used 511 for a single request and response. One stream is dedicated to the 512 transport of control messages, enabling a cleaner separation between 513 metadata about the connection from metadata about the separate 514 messages within the connection. 516 HTTP/2 projects the requested action into the set of headers, then 517 uses separate HEADERS and DATA frames to delimit the boundary between 518 metadata and message body on each stream. These frames are used to 519 provide message-like behaviors and parallelism over a single TCP 520 bytestream. 522 Because the text-based transfer of repetitive headers represented a 523 major inefficiency in HTTP/1.1, HTTP/2 also introduced HPACK 524 [RFC7541], a custom compression scheme which operates on key-value 525 pairs rather than text blocks. HTTP/2 frame types which transport 526 headers always carry HPACK header block fragments rather than an 527 uncompressed key-value dictionary. 529 4.3.2. Congestion and flow control 531 Because HTTP/2's adaptation layer introduces a concurrency construct 532 above the transport, the adaptation layer must also introduce a means 533 of flow control to keep the concurrent transactions from introducing 534 head-of-line blocking above TCP. This led HTTP/2 to create a flow- 535 control scheme within the adaptation layer in addition to TCP's flow 536 control algorithms. 538 In HTTP/1.1, this was not needed - the application simply reads from 539 TCP as space is available, and allow's TCP's own flow control to 540 govern. In HTTP/2, this would cause severe head-of-line blocking due 541 to the increased parallelism, and so the control must be exerted at a 542 higher level. 544 Another drawback to the application-layer multiplexing approach is 545 the fact that TCP's congestion-avoidance mechanisms cannot identify 546 the flows separately, magnifying the impact of packet losses. This 547 manifests both by reducing the congestion window for the entire 548 connection (versus one-sixth of the "connection" in HTTP/1.1) on 549 packet loss, and delayed delivery of packets on unaffected streams 550 due to head-of-line blocking behind lost packets. 552 4.3.3. Security 554 HTTP/2 directly defines how TLS may be used to provide security 555 services as part of its adaptation layer. 557 4.4. HTTPU(M) and CoAP 559 UDP mappings of HTTP must define mechanisms to restore the original 560 order of message fragments. HTTPU(M) and the base form of CoAP both 561 do this by restricting messages to the size of a single datagram, 562 while [I-D.ietf-core-block] extends CoAP to define an in-order 563 delivery mechanism in the adaptation layer. 565 Adaptation layers of HTTP mappings over UDP have also needed to 566 introduce mechanisms for reliable delivery. CoAP dedicates a portion 567 of its message framing to indicating whether a given message requires 568 reliability or not. If reliable delivery is required, the recipient 569 acknowledges receipt and the sender continues to repeat the message 570 until the acknowledgment is received. For non-idempotent requests, 571 this means keeping additional state about which requests have already 572 been processed. 574 Some applications above HTTP are able to provide their own loss- 575 recovery messages, and therefore do not actually require the 576 guarantees that HTTP provides. HTTP over UDP Multicast is targeted 577 at such applications, and therefore does not provide reliable 578 delivery to applications above it. 580 4.5. QUIC over UDP, or HTTP/2 over QUIC, or...? 582 QUIC is an overloaded term. QUIC is a rich HTTP mapping to UDP 583 [I-D.tsvwg-quic-protocol] which implements many TCP- and SCTP-like 584 behaviors in its adaptation layer. It describes itself this way: 586 QUIC (Quick UDP Internet Connection) is a new multiplexed and 587 secure transport atop UDP, designed from the ground up and 588 optimized for HTTP/2 semantics. While built with HTTP/2 as the 589 primary application protocol, QUIC builds on decades of transport 590 and security experience, and implements mechanisms that make it 591 attractive as a modern general-purpose transport. QUIC provides 592 multiplexing and flow control equivalent to HTTP/2, security 593 equivalent to TLS, and connection semantics, reliability, and 594 congestion control equivalent to TCP. 596 Consequently, QUIC is _also_ a "general-purpose transport" over which 597 an HTTP mapping can be defined and implemented. 599 This division makes it unclear which parts belong to the transport 600 versus an HTTP mapping on top of this new transport. For example, 601 [I-D.tsvwg-quic-protocol] does define how to separately transport the 602 headers and body of an HTTP message. However, this capability is 603 likely not relevant in a general-purpose transport and might better 604 be removed from QUIC-the-transport and incorporated into HTTP-over- 605 QUIC. 607 5. Moving Forward 609 The networks over which we run TCP/IP today look nothing like the 610 networks for which TCP/IP was originally designed. It is the clean 611 separation between TCP, IP, and the lower-layer protocols which has 612 enabled the continued usefulness of the higher-layer protocols as the 613 substrate has changed. Likewise, the actions and content carried 614 over HTTP look very different, reflecting well on the abstraction 615 achieved by the HTTP layer. 617 It is the layer between HTTP and the transport where abstraction has 618 not always been successfully achieved. New capabilites in transports 619 have required new expressions at the HTTP layer to take advantage of 620 them, and mappings have defined concepts which are tightly bound to 621 the underlying transport without clearly separating them from the 622 semantics of HTTP. 624 The goal is not merely architectural purity, but modularity. HTTP 625 has enjoyed a long life as a higher-layer protocol and is useful to 626 many varied applications. As transports continue to evolve, we will 627 almost certainly find ourselves in the position of defining a mapping 628 of HTTP onto a new transport once again. With a clear understanding 629 of the HTTP semantic layer and the services it requires, we can 630 better scope the requirements of a new adaptation layer while reusing 631 the components of previous adaptation layers that provide the 632 necessary service well in existing implementations. 634 6. Informative References 636 [goland-http-udp] 637 Goland, Y., "Multicast and Unicast UDP HTTP Messages", 638 November 1999, 639 . 641 [I-D.ietf-core-block] 642 Bormann, C. and Z. Shelby, "Block-wise transfers in CoAP", 643 draft-ietf-core-block-18 (work in progress), September 644 2015. 646 [I-D.natarajan-http-over-sctp] 647 Natarajan, P., Amer, P., Leighton, J., and F. Baker, 648 "Using SCTP as a Transport Layer Protocol for HTTP", 649 draft-natarajan-http-over-sctp-02 (work in progress), July 650 2009. 652 [I-D.tsvwg-quic-protocol] 653 Hamilton, R., Iyengar, J., Swett, I., and A. Wilk, "QUIC: 654 A UDP-Based Secure and Reliable Transport for HTTP/2", 655 draft-tsvwg-quic-protocol-02 (work in progress), January 656 2016. 658 [RFC1149] Waitzman, D., "Standard for the transmission of IP 659 datagrams on avian carriers", RFC 1149, 660 DOI 10.17487/RFC1149, April 1990, 661 . 663 [RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext 664 Transfer Protocol -- HTTP/1.0", RFC 1945, 665 DOI 10.17487/RFC1945, May 1996, 666 . 668 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 669 DOI 10.17487/RFC2818, May 2000, 670 . 672 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 673 RFC 4960, DOI 10.17487/RFC4960, September 2007, 674 . 676 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 677 (TLS) Protocol Version 1.2", RFC 5246, 678 DOI 10.17487/RFC5246, August 2008, 679 . 681 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 682 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 683 January 2012, . 685 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 686 Control Transmission Protocol (SCTP) Packets for End-Host 687 to End-Host Communication", RFC 6951, 688 DOI 10.17487/RFC6951, May 2013, 689 . 691 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 692 Protocol (HTTP/1.1): Message Syntax and Routing", 693 RFC 7230, DOI 10.17487/RFC7230, June 2014, 694 . 696 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 697 Application Protocol (CoAP)", RFC 7252, 698 DOI 10.17487/RFC7252, June 2014, 699 . 701 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 702 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 703 DOI 10.17487/RFC7540, May 2015, 704 . 706 [RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for 707 HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, 708 . 710 [UPnP] "UPnP Device Architecture 2.0", 2015, 711 . 714 [w3c-smux] 715 Nielsen, H., "SMUX Protocol Specification", July 1998, 716 . 718 [watchfire-request-smuggling] 719 Orrin, S., "HTTP Request Smuggling", 2005, 720 . 723 Author's Address 725 Mike Bishop 726 Microsoft 728 Email: michael.bishop@microsoft.com