One document matched: draft-bishop-decomposing-http-00.xml

<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.28 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

<rfc ipr="trust200902" docName="draft-bishop-decomposing-http-00" category="info">

  <front>
    <title abbrev="Decomposing HTTP">Decomposing the Hypertext Transfer Protocol</title>

    <author initials="M." surname="Bishop" fullname="Mike Bishop">
      <organization>Microsoft</organization>
      <address>
        <email>michael.bishop@microsoft.com</email>
      </address>
    </author>

    <date year="2015" month="August" day="21"/>

    <area>Applications</area>
    <workgroup>HTTPBis Working Group</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>The Hypertext Transfer Protocol in its various versions
combines concepts of both an application and transport-layer
protocol. As this group contemplates employing alternate
transport protocols underneath HTTP, this document attempts
to delineate the boundaries between these functions to define
a shared vocabulary in discussing the revision and/or replacement
of one or more of these components.</t>



    </abstract>


  </front>

  <middle>


<section anchor="problems" title="Introduction">

<t>The Hypertext Transfer Protocol defines a very flexible
tool set enabling client applications to make requests
of a server for content or action. This general protocol
was conceived for “the web,” interconnected pages of
Hypertext Markup Language (HTML) and associated resources
used to render the HTML, but has since been used as a
general-purpose application transport. Server APIs are
commonly exposed as REST APIs, accessed over HTTP.</t>

<t>HTTP/1.0 <xref target="RFC1945"/> was a text-based protocol which did not specify
its underlying transport, but describes the mapping this way:</t>

<t><list style='empty'>
  <t>On the Internet, HTTP communication generally takes place over TCP/IP
connections. The default port is TCP 80, but other ports can be
used. This does not preclude HTTP from being implemented on top of
any other protocol on the Internet, or on other networks. HTTP only
presumes a reliable transport; any protocol that provides such
guarantees can be used, and the mapping of the HTTP/1.0 request and
response structures onto the transport data units of the protocol in
question is outside the scope of this specification.</t>
</list></t>

<t>HTTP/1.1 <xref target="RFC7230"/> expands on the TCP binding, introducing connection
management concepts into the HTTP layer.</t>

<t>HTTP/2 <xref target="RFC7540"/> replaced the simple text-based protocol with a binary
framing.  The changes are described in the following way:</t>

<t><list style='empty'>
  <t>HTTP/2 addresses these issues by defining an optimized mapping of
  HTTP’s semantics to an underlying connection.  Specifically, it
  allows interleaving of request and response messages on the same
  connection and uses an efficient coding for HTTP header fields.  It
  also allows prioritization of requests, letting more important
  requests complete more quickly, further improving performance.</t>

  <t>The resulting protocol is more friendly to the network because fewer
  TCP connections can be used in comparison to HTTP/1.x.  This means
  less competition with other flows and longer-lived connections, which
  in turn lead to better utilization of available network capacity.</t>

  <t>Finally, HTTP/2 also enables more efficient processing of messages
  through use of binary message framing.</t>
</list></t>

<t>Conceptually, HTTP/2 achieved the same properties required of a TCP
mapping using wildly different strategies from HTTP/1.1.  HTTP/1.1
achieves properties such as parallelism and out-of-order delivery by
the use of multiple TCP connections.  HTTP/2 implements these services
on top of TCP to enable the use of a single TCP connection.
The working group’s charter to maintain HTTP’s broad applicability
meant that there were few or no changes in how HTTP surfaces to
applications.</t>

<t>Other efforts have mapped HTTP or a subset of it to various
transport protocols besides TCP – HTTP can be implemented
over SCTP <xref target="RFC4960"/> as in <xref target="I-D.natarajan-http-over-sctp"/>,
and useful profiles of HTTP have been mapped to
UDP in various ways (HTTPU and HTTPUM in <xref target="goland-http-udp"/>
and <xref target="UPnP"/>, CoAP <xref target="RFC7252"/>, QUIC <xref target="I-D.tsvwg-quic-protocol"/>).</t>

<t>With the publication of HTTP/2 over TCP, the working group 
is beginning to consider how a mapping to a non-TCP transport would
function.  This document aims to enable this conversation by describing
the services required by the HTTP semantic layer.  A mapping of HTTP
to a transport other than TCP must define how these services are
obtained, either from the new transport or by implementing them at
the application layer.</t>

</section>
<section anchor="the-semantic-layer" title="The Semantic Layer">

<t>At the most fundamental level, the semantic layer of HTTP consists
of a client’s ability to request some action of a server and be informed
of the outcome of that action.  HTTP defines a number of possible
actions (methods) the client might request of the server, but permits the
list of actions to be extended.</t>

<t>A client’s request consists of a desired action (HTTP method) and a
resource on which that action is to be taken (path).  The server 
responds which a status code which informs the client of the result
of the request – the outcome of the action or the reason the action
was not performed.  Actions may or may not be idempotent or safe, and
the results may or may not be cached by intermediaries; this is
defined as part of the HTTP method.</t>

<t>Each message (request or response) has associated metadata, called
“headers,” which provide additional information about the operation.
In a request this might include client identification, credentials
authorizing the client to request the action, or preferences about
how the client would prefer the server handle the action.  In a
response, this might include information about the resulting data,
modifications to the cacheability of the response,
details about how the server performed the action, or details of
the reason the server declined to perform the action.</t>

<t>The headers are structured key-value pairs, with rules defining how
keys which occur multiple times should be handled.  Due to artifacts
of existing usage, these rules vary from key to key.  For similar
legacy reasons, there is no uniform structure of the values across
all keys.  Keys are case-insensitive ASCII strings, while values
are sequences of octets typically interpreted as ASCII.  Many headers
are defined by the HTTP RFCs, but the space is not constrained and
is frequently extended with little or no notice.</t>

<t>Each message, whether request or response, also has an optional body.  The
presence and content of the body will vary based on the action requested.</t>

</section>
<section anchor="transport" title="Transport Services Required">

<t>The HTTP Semantic Layer depends on the availability
of the following services:</t>

<t><list style="symbols">
  <t>Separate metadata and payload</t>
  <t>Parallelism</t>
  <t>Partial delivery</t>
  <t>Flow control and throttling</t>
  <t>Reliable delivery</t>
  <t>In-order delivery</t>
  <t>Security</t>
</list></t>

<t>No transport over which HTTP can be mapped actually provides
all of the services on which the HTTP Semantic Layer depends.
In the following table, we can see multiple transports
over which HTTP has been deployed and the services they do
or do not offer.</t>

<texttable>
      <ttcol align='left'> </ttcol>
      <ttcol align='center'>TCP</ttcol>
      <ttcol align='center'>UDP</ttcol>
      <ttcol align='center'>SCTP</ttcol>
      <ttcol align='center'>QUIC</ttcol>
      <c>Metadata</c>
      <c> </c>
      <c> </c>
      <c> </c>
      <c> </c>
      <c>Parallelism</c>
      <c> </c>
      <c> </c>
      <c>X</c>
      <c>X</c>
      <c>Partial delivery</c>
      <c>X</c>
      <c>X</c>
      <c>X</c>
      <c>X</c>
      <c>Flow Control</c>
      <c>X</c>
      <c>X</c>
      <c>X</c>
      <c>X</c>
      <c>Reliable</c>
      <c>X</c>
      <c> </c>
      <c>X</c>
      <c>X</c>
      <c>In-order</c>
      <c>X</c>
      <c> </c>
      <c>X</c>
      <c>X</c>
      <c>Secure</c>
      <c> </c>
      <c> </c>
      <c> </c>
      <c>X</c>
</texttable>

<t>Based on an initial review of this table, it would seem that
UDP is the least-appropriate substrate for an HTTP mapping.
However, what ultimately matters is the combined capability
of the transport and the application-defined adaptation layer.</t>

</section>
<section anchor="transport-adaptation" title="The Transport Adaptation Layer">

<t>In order to compensate for the services not provided by a given
underlying transport, each mapping of HTTP onto a new transport
must define an intermediate layer implementing the missing
services in order to enable the mapping.</t>

<t>Some of these have been wholesale imports of other protocols
which exist to provide such an adaptation layer (TLS <xref target="RFC5246"/>) while
others have been entirely new protocol machinery constructed
specifically to serve as an adaptation layer (HTTP/2 framing).
Still others take the form of implementation-level meta-protocol
behavior (simultaneous connections handled in parallel).
Because the existence of this adaptation layer has not been
explicitly defined in the past, a clean separation
has not always been maintained between the adaptation layer
and either the transport or the semantic layer.</t>

<t>Some adaptation layers are so complex and fully-featured that
the transport layer plus the adaptation layer can be conceptually
treated as a new transport.  For example, QUIC was originally
designed as a transport adaptation layer for HTTP over UDP,
but is now being refactored into a general-purpose transport
layer for multiple protocols.  Such a refactoring will require
separating the services QUIC provides that are general to all
applications from the services which exist purely to enable a
mapping of HTTP to QUIC.</t>

<section anchor="security" title="Security">

<t>Integrity and confidentiality are valuable services for
communication over the Internet, and HTTP is no exception.
HTTP originally defined no additional integrity or
confidentiality mechanisms for the TCP mapping, leaving
the integrity and confidentiality levels to those provided
by the network transport.  These may be minimal (TCP
checksums) or rich (IPsec) depending on the network
environment.</t>

<t>For situations where the network does not provide integrity
and confidentiality guarantees sufficient to the content,
<xref target="RFC2818"/> defines the use of TLS as an additional
component of the adaptation layer in HTTP/1.1.  HTTP/2
directly defines how TLS may be used to provide these
services as part of its adaptation layer.</t>

<t>TLS itself requires reliable, in-order delivery.  When
those services are provided by the adaptation layer itself
rather than the underlying transport, the adaptation layer
must either provide those services to TLS as well as HTTP
(as in QUIC) or a variant of TLS which does not require
those services must be substituted (DTLS <xref target="RFC6347"/>,
as used in CoAP).</t>

</section>
<section anchor="message-framing-and-request-metadata" title="Message Framing and Request Metadata">

<t>Any protocol defines how the semantics of the protocol are
mapped onto the wire in a transport.  Most transports are
either bytestreams or message-based, meaning that higher-layer
concepts must be laid out in a reasonable structure within the
stream or message.  Each HTTP request and response contains
metadata about the message (headers) and an optional body.</t>

<section anchor="http1x-and-text-based-headers" title="HTTP/1.x and Text-Based Headers">

<t>HTTP/1.x projects a message as an octet sequence which typically
resembles a block of ASCII text.  Specific octets are used to
delimit the boundaries between message components.  Within
the portion of the message dedicated to headers, the key-value pairs
are expressed as text, with the ‘:’ character and whitespace
separating the key from the value.</t>

<t>Because this region appears to be text, many text conventions have
accidentally crept into HTTP/1.x message parsers and even protocol
conventions (line-folding, CRLF differences between operating systems,
etc.).  This is a source of bugs, such as line-folding characters which
appear in an HTTP/2 message despite HTTP/2 not using a text-based
header framing.</t>

</section>
<section anchor="http2-and-hpack" title="HTTP/2 and HPACK">

<t>HTTP/2 projects the requested action into the set of headers,
then uses separate HEADERS and DATA frames to delimit the boundary
between metadata and message body.  These frames are used to provide
message-like behaviors and parallelism over a single TCP bytestream.</t>

<t>Because the text-based transfer of repetitive headers represented
a major inefficiency in HTTP/1.1, HTTP/2 also introduced HPACK
<xref target="RFC7541"/>, a custom compression scheme which operates on key-value
pairs rather than text blocks.  HTTP/2 frame types which transport
headers always carry HPACK header block fragments rather than an
uncompressed key-value dictionary.</t>

</section>
</section>
<section anchor="parallelism-and-throttling" title="Parallelism and Throttling">

<t>Because a client will often need each server to perform multiple
actions at once, HTTP requires the ability to deliver requests
in parallel and allow the server to respond to each request
as the actions complete.  In order to avoid overwhelming
either the transport or the server, HTTP also requires a
mechanism to limit the number of simultaneous requests
a client may have outstanding.</t>

<section anchor="http1x-and-multiple-connections" title="HTTP/1.x and Multiple Connections">

<t>HTTP/1.0 used a very simple multi-request model – each request
was made on a separate TCP connection, and all requests were
handled independently.  This had the drawback that TCP connection
setup was required with each request and flow control almost
never exited the slow-start phase, limiting performance.</t>

<t>To improve this, new headers were introduced to manage connection
lifetime (e.g. “Connection: keep-alive”), blurring the distinction
between message metadata and connection metadata.  These headers
were formalized in HTTP/1.1.  This improvement means that connections
are reused – when the end of a response
has been received, a new request can be sent.</t>

<t>Throttling of simultaneous requests was fully in the realm of
implementations, which constrained themselves to opening only
a limited number of connections.  HTTP/1.1 originally recommended
two, but later implementations increased this to six by default,
and more under certain conditions.  Because these were fully
independent flows, TCP was unable to consider them as a group for
purposes of congestion control, leading to suboptimal behavior
on the network.</t>

<t>Servers which desired additional parallelism could game such
implementations by exposing resources under multiple hostnames,
causing the client implementations to open six connections
<spanx style="emph">to each hostname</spanx> and gain an arbitrary amount of parallelism,
to the detriment of functional congestion control.</t>

<t>There were further attempts to improve the use of TCP.  Pipelining,
also introduced in HTTP/1.1, allowed the client to eliminate the
round-trip that was incurred between the end of the server’s response
to one request and the server’s receipt of the client’s next request.
However, pipelining increases the problem of head-of-line blocking
since a request on a different connection might complete sooner.  The
client’s inability to predict the length of requested actions
limited the usefulness of pipelining.</t>

<t>SMUX <xref target="w3c-smux"/> allowed the use of a single TCP connection to
carry multiple channels over which HTTP could be carried.
This would permit the server to answer requests in any
order.  However, this was never broadly deployed.</t>

</section>
<section anchor="http11-over-sctp" title="HTTP/1.1 over SCTP">

<t>Because SCTP permits the use of multiple simultaneous streams
over a single connection, HTTP/1.1 could be mapped with relative
ease.  Instead of using separate TCP connections, SCTP flows
could be used to provide a multiplexing layer.  Each flow
was reused for new requests after the completion of a 
response, just as HTTP/1.1 used TCP connections.  This allowed
for better flow control performance, since the transport
could consider all flows together.</t>

<t>SCTP has seen limited deployment on the Internet, though recent
experience has shown SCTP over UDP <xref target="RFC6951"/> to be a more viable
combination.</t>

</section>
<section anchor="http2-framing-layer" title="HTTP/2 Framing Layer">

<t>HTTP/2 introduced a framing layer that incorporated the concept
of streams.  Because a very large number of idle streams
automatically exist at the beginning of each connection,
each stream can be used for a single request and response.
One stream is dedicated to the transport of control messages,
enabling a cleaner separation between metadata about the
connection from metadata about the separate messages within
the connection.</t>

</section>
</section>
<section anchor="congestion-control" title="Congestion control">

<t>The transport is aware of each concurrent request in HTTP/1.1’s
mappings to TCP and SCTP.  In TCP, because there is only one
request at a time, and in SCTP because each request occurs on a
separate flow.  This means that the transport’s own congestion
control services are sufficient, even if sub-optimal in TCP’s case
due to multiple independent connections.</t>

<t>Because HTTP/2’s adaptation layer introduces a concurrency construct
above the transport, the adaptation layer must also introduce
a means of flow control to keep the concurrent transactions
from introducing head-of-line blocking above TCP.</t>

</section>
<section anchor="reliable-delivery" title="Reliable delivery">

<t>There are many ways for a transport to provide reliable
delivery of messages. This may take the form of loss recovery,
where the loss of packets is detected and the corresponding
information retransmitted.  Alternately, a transport may
proactively send extra information so that the data stream
is tolerant to some loss – the full message can be reconstructed
after receipt of a sufficient fraction of the transmission.</t>

<t>Because TCP and SCTP both provide reliable delivery mechanisms,
there was no need to introduce new service in this area for HTTP
mappings.  However, the adaptation layers of HTTP mappings
over UDP have needed to introduce this concept.</t>

<t>CoAP dedicates a portion of its message framing to indicating
whether a given message requires reliability or not.  If
reliable delivery is required, the recipient acknowledges
receipt and the sender continues to repeat the message
until the acknowledgment is received.  For non-idempotent
requests, this means keeping additional state about which
requests have already been processed.</t>

<t>Some applications above HTTP are able to provide their own
loss-recovery messages, and therefore do not actually require
the guarantees that HTTP provides.  HTTP over UDP Multicast
is targeted at such applications, and therefore does not
provide reliable delivery to applications above it.</t>

</section>
<section anchor="in-order-delivery" title="In-order delivery">

<t>The sequence numbers used to detect the partial loss of data
also permit TCP and SCTP to reassemble data in the order it
was originally sent.</t>

<t>HTTP/2 does not actually require a full
ordering, but TCP does not offer a way to relax its ordering
guarantees.  HTTP/2 has two ordering requirements:</t>

<t><list style="symbols">
  <t>All frames on a stream must be delivered to the
application in order</t>
  <t>All frames bearing header fragments must be
delivered to HPACK in order</t>
</list></t>

<t>UDP mappings of HTTP must define mechanisms to restore the
original order of message fragments.  HTTPU(M) and the base form
of CoAP both do this by restricting messages to the size of
a single datagram, while <xref target="I-D.ietf-core-block"/> extends CoAP
to define an in-order delivery mechanism in the adaptation layer.</t>

</section>
</section>
<section anchor="moving-forward" title="Moving Forward">

<t>The networks over which we run TCP/IP today look nothing like the
networks for which TCP/IP was originally designed.  It is the
clean separation between TCP, IP, and the lower-layer protocols
which has enabled the continued usefulness of the higher-layer
protocols as the substrate has changed.</t>

<t>The goal is not merely architectural purity, but modularity.
HTTP has enjoyed a long life as a higher-layer protocol and is
useful to many varied applications.  As transports continue to
evolve, we will almost certainly find ourselves in the position
of defining a mapping of HTTP onto a new transport once again.
With a clear understanding of the HTTP semantic layer and the
services it requires, we can better scope the requirements
of a new adaptation layer while reusing the components of
previous adaptation layers that provide the necessary service
well in existing implementations.</t>

</section>


  </middle>

  <back>


    <references title='Informative References'>





<reference  anchor='RFC1945' target='http://www.rfc-editor.org/info/rfc1945'>
<front>
<title>Hypertext Transfer Protocol -- HTTP/1.0</title>
<author initials='T.' surname='Berners-Lee' fullname='T. Berners-Lee'><organization /></author>
<author initials='R.' surname='Fielding' fullname='R. Fielding'><organization /></author>
<author initials='H.' surname='Frystyk' fullname='H. Frystyk'><organization /></author>
<date year='1996' month='May' />
<abstract><t>The Hypertext Transfer Protocol (HTTP) is an application-level protocol with the lightness and speed necessary for distributed, collaborative, hypermedia information systems.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.</t></abstract>
</front>
<seriesInfo name='RFC' value='1945'/>
<seriesInfo name='DOI' value='10.17487/RFC1945'/>
</reference>



<reference  anchor='RFC2818' target='http://www.rfc-editor.org/info/rfc2818'>
<front>
<title>HTTP Over TLS</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<date year='2000' month='May' />
<abstract><t>This memo describes how to use Transport Layer Security (TLS) to secure Hypertext Transfer Protocol (HTTP) connections over the Internet.  This memo provides information for the Internet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='2818'/>
<seriesInfo name='DOI' value='10.17487/RFC2818'/>
</reference>



<reference  anchor='RFC7230' target='http://www.rfc-editor.org/info/rfc7230'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding' role='editor'><organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><organization /></author>
<date year='2014' month='June' />
<abstract><t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems.  This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.</t></abstract>
</front>
<seriesInfo name='RFC' value='7230'/>
<seriesInfo name='DOI' value='10.17487/RFC7230'/>
</reference>



<reference  anchor='RFC7252' target='http://www.rfc-editor.org/info/rfc7252'>
<front>
<title>The Constrained Application Protocol (CoAP)</title>
<author initials='Z.' surname='Shelby' fullname='Z. Shelby'><organization /></author>
<author initials='K.' surname='Hartke' fullname='K. Hartke'><organization /></author>
<author initials='C.' surname='Bormann' fullname='C. Bormann'><organization /></author>
<date year='2014' month='June' />
<abstract><t>The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks.  The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s.  The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.</t><t>CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types.  CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.</t></abstract>
</front>
<seriesInfo name='RFC' value='7252'/>
<seriesInfo name='DOI' value='10.17487/RFC7252'/>
</reference>



<reference  anchor='RFC7540' target='http://www.rfc-editor.org/info/rfc7540'>
<front>
<title>Hypertext Transfer Protocol Version 2 (HTTP/2)</title>
<author initials='M.' surname='Belshe' fullname='M. Belshe'><organization /></author>
<author initials='R.' surname='Peon' fullname='R. Peon'><organization /></author>
<author initials='M.' surname='Thomson' fullname='M. Thomson' role='editor'><organization /></author>
<date year='2015' month='May' />
<abstract><t>This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2).  HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection.  It also introduces unsolicited push of representations from servers to clients.</t><t>This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax.  HTTP's existing semantics remain unchanged.</t></abstract>
</front>
<seriesInfo name='RFC' value='7540'/>
<seriesInfo name='DOI' value='10.17487/RFC7540'/>
</reference>



<reference  anchor='RFC7541' target='http://www.rfc-editor.org/info/rfc7541'>
<front>
<title>HPACK: Header Compression for HTTP/2</title>
<author initials='R.' surname='Peon' fullname='R. Peon'><organization /></author>
<author initials='H.' surname='Ruellan' fullname='H. Ruellan'><organization /></author>
<date year='2015' month='May' />
<abstract><t>This specification defines HPACK, a compression format for efficiently representing HTTP header fields, to be used in HTTP/2.</t></abstract>
</front>
<seriesInfo name='RFC' value='7541'/>
<seriesInfo name='DOI' value='10.17487/RFC7541'/>
</reference>


<reference anchor="goland-http-udp" target="http://tools.ietf.org/html/draft-goland-http-udp-01">
  <front>
    <title>Multicast and Unicast UDP HTTP Messages</title>
    <author fullname="Yaron Y. Goland">
      <organization>Microsoft Corporation</organization>
    </author>
    <date year="1999" month="November" day="09"/>
  </front>
</reference>
<reference anchor="UPnP" target="http://upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v2.0.pdf">
  <front>
    <title>UPnP Device Architecture 2.0</title>
    <author >
      <organization></organization>
    </author>
    <date year="2015"/>
  </front>
</reference>




<reference anchor='I-D.tsvwg-quic-protocol'>
<front>
<title>QUIC: A UDP-Based Secure and Reliable Transport for HTTP/2</title>

<author initials='J' surname='Jana' fullname='Jana'>
    <organization />
</author>

<author initials='I' surname='Swett' fullname='Ian Swett'>
    <organization />
</author>

<date month='July' day='13' year='2015' />

<abstract><t>QUIC (Quick UDP Internet Connection) is a new multiplexed and secure transport atop UDP, designed from the ground up and optimized for HTTP/2 semantics.  While built with HTTP/2 as the primary application protocol, QUIC builds on decades of transport and security experience, and implements mechanisms that make it attractive as a modern general-purpose transport.  QUIC provides multiplexing and flow control equivalent to HTTP/2, security equivalent to TLS, and connection semantics, reliability, and congestion control equivalent to TCP.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-tsvwg-quic-protocol-01' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-tsvwg-quic-protocol-01.txt' />
</reference>



<reference  anchor='RFC6347' target='http://www.rfc-editor.org/info/rfc6347'>
<front>
<title>Datagram Transport Layer Security Version 1.2</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<author initials='N.' surname='Modadugu' fullname='N. Modadugu'><organization /></author>
<date year='2012' month='January' />
<abstract><t>This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol.  The DTLS protocol provides communications privacy for datagram protocols.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.  The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees.  Datagram semantics of the underlying transport are preserved by the DTLS protocol.  This document updates DTLS 1.0 to work with TLS version 1.2.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6347'/>
<seriesInfo name='DOI' value='10.17487/RFC6347'/>
</reference>



<reference anchor='I-D.natarajan-http-over-sctp'>
<front>
<title>Using SCTP as a Transport Layer Protocol for HTTP</title>

<author initials='P' surname='Natarajan' fullname='Preethi Natarajan'>
    <organization />
</author>

<author initials='P' surname='Amer' fullname='Paul Amer'>
    <organization />
</author>

<author initials='J' surname='Leighton' fullname='Jonathan Leighton'>
    <organization />
</author>

<author initials='F' surname='Baker' fullname='Fred Baker'>
    <organization />
</author>

<date month='July' day='9' year='2009' />

<abstract><t>Hyper-Text Transfer Protocol (HTTP) [RFC2616] requires a reliable transport for end-to-end communication.  While historically TCP has been used for this purpose, this document proposes an alternative -- the Stream Control Transmission Protocol (SCTP) [RFC4960].  Similar to TCP, SCTP offers a reliable end-to-end transport connection to applications.  Additionally, SCTP offers innovative services unavailable in TCP.  This draft (i) specifies HTTP over SCTP's multistreaming service, (ii) lists open issues warranting more discussion and/or investigation, and (iii) shares some lessons learned from implementing HTTP over SCTP.  Finally, this document highlights SCTP services that better match HTTP's needs than TCP.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-natarajan-http-over-sctp-02' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-natarajan-http-over-sctp-02.txt' />
</reference>



<reference  anchor='RFC4960' target='http://www.rfc-editor.org/info/rfc4960'>
<front>
<title>Stream Control Transmission Protocol</title>
<author initials='R.' surname='Stewart' fullname='R. Stewart' role='editor'><organization /></author>
<date year='2007' month='September' />
<abstract><t>This document obsoletes RFC 2960 and RFC 3309.  It describes the Stream Control Transmission Protocol (SCTP).  SCTP is designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks, but is capable of broader applications.</t><t>SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP.  It offers the following services to its users:</t><t>--  acknowledged error-free non-duplicated transfer of user data,</t><t>--  data fragmentation to conform to discovered path MTU size,</t><t>--  sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages,</t><t>--  optional bundling of multiple user messages into a single SCTP packet, and</t><t>--  network-level fault tolerance through supporting of multi-homing at either or both ends of an association.</t><t> The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4960'/>
<seriesInfo name='DOI' value='10.17487/RFC4960'/>
</reference>



<reference anchor='I-D.ietf-core-block'>
<front>
<title>Block-wise transfers in CoAP</title>

<author initials='C' surname='Bormann' fullname='Carsten Bormann'>
    <organization />
</author>

<author initials='Z' surname='Shelby' fullname='Zach Shelby'>
    <organization />
</author>

<date month='March' day='9' year='2015' />

<abstract><t>CoAP is a RESTful transfer protocol for constrained nodes and networks.  Basic CoAP messages work well for the small payloads we expect from temperature sensors, light switches, and similar building-automation devices.  Occasionally, however, applications will need to transfer larger payloads -- for instance, for firmware updates.  With HTTP, TCP does the grunt work of slicing large payloads up into multiple packets and ensuring that they all arrive and are handled in the right order.  CoAP is based on datagram transports such as UDP or DTLS, which limits the maximum size of resource representations that can be transferred without too much fragmentation.  Although UDP supports larger payloads through IP fragmentation, it is limited to 64 KiB and, more importantly, doesn't really work well for constrained applications and networks.  Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options, for transferring multiple blocks of information from a resource representation in multiple request-response pairs.  In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers.  In summary, the Block options provide a minimal way to transfer larger representations in a block-wise fashion.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-core-block-17' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-core-block-17.txt' />
</reference>



<reference  anchor='RFC5246' target='http://www.rfc-editor.org/info/rfc5246'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
<author initials='T.' surname='Dierks' fullname='T. Dierks'><organization /></author>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<date year='2008' month='August' />
<abstract><t>This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol.  The TLS protocol provides communications security over the Internet.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5246'/>
<seriesInfo name='DOI' value='10.17487/RFC5246'/>
</reference>


<reference anchor="w3c-smux" target="http://www.w3.org/TR/WD-mux">
  <front>
    <title>SMUX Protocol Specification</title>
    <author fullname="Henrik Frystyk Nielsen">
      <organization>W3C</organization>
    </author>
    <date year="1998" month="July" day="10"/>
  </front>
</reference>




<reference  anchor='RFC6951' target='http://www.rfc-editor.org/info/rfc6951'>
<front>
<title>UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication</title>
<author initials='M.' surname='Tuexen' fullname='M. Tuexen'><organization /></author>
<author initials='R.' surname='Stewart' fullname='R. Stewart'><organization /></author>
<date year='2013' month='May' />
<abstract><t>This document describes a simple method of encapsulating Stream Control Transmission Protocol (SCTP) packets into UDP packets and its limitations.  This allows the usage of SCTP in networks with legacy NATs that do not support SCTP.  It can also be used to implement SCTP on hosts without directly accessing the IP layer, for example, implementing it as part of the application without requiring special privileges.</t><t>Please note that this document only describes the functionality required within an SCTP stack to add on UDP encapsulation, providing only those mechanisms for two end-hosts to communicate with each other over UDP ports.  In particular, it does not provide mechanisms to determine whether UDP encapsulation is being used by the peer, nor the mechanisms for determining which remote UDP port number can be used.  These functions are out of scope for this document.</t><t>This document covers only end-hosts and not tunneling (egress or ingress) endpoints.</t></abstract>
</front>
<seriesInfo name='RFC' value='6951'/>
<seriesInfo name='DOI' value='10.17487/RFC6951'/>
</reference>




    </references>




  </back>
</rfc>