HTTPbis Working Group                                          M. Bishop
Internet-Draft                                                 Microsoft
Expires: November 23, 2014                                  May 22, 2014


                       Extension Frames in HTTP/2
                 draft-bishop-http2-extension-frames-01

Abstract

   This document describes a proposed modification to the HTTP/2
   specification to better support the creation of extensions without
   the need to version the core protocol or invoke additional protocol
   identifiers.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on November 23, 2014.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.





Bishop                  Expires November 23, 2014               [Page 1]


Internet-Draft                 Extensions                       May 2014


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Conventions and Terminology . . . . . . . . . . . . . . .   3
   2.  Problems an extension model must solve  . . . . . . . . . . .   3
   3.  Extension Functionality . . . . . . . . . . . . . . . . . . .   4
     3.1.  Extension Identification and Negotiation  . . . . . . . .   4
     3.2.  Extension Negotiation . . . . . . . . . . . . . . . . . .   5
     3.3.  New Frames and Modifications  . . . . . . . . . . . . . .   5
     3.4.  Settings  . . . . . . . . . . . . . . . . . . . . . . . .   8
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
   Appendix A.  Example Extensions . . . . . . . . . . . . . . . . .  11
     A.1.  Blocked Flow-Control Announcement Extension . . . . . . .  11
     A.2.  Alternate-Service Announcement  . . . . . . . . . . . . .  12
     A.3.  Compressed Data Frames  . . . . . . . . . . . . . . . . .  14
   Appendix B.  Acknowledgements . . . . . . . . . . . . . . . . . .  18

1.  Introduction

   HTTP/2 previously offered an inconsistent story about the use of
   extensions.  Following a discussion of the previous version of this
   draft, the working group reached consensus to prohibit all
   extensibility, declaring that any new functionality would constitute
   the creation of a new protocol with a new ALPN identifier.  This was
   driven in large part by a desire not to delay the specification while
   an extension model was finalized and implemented.

   In the wake of this decision, a number of new frames and subfeatures
   have been proposed (BLOCKED (Appendix A.1), ALTSVC (Appendix A.2),
   compression of DATA frames (Appendix A.3)), delaying the
   specification and introducing a dependency on a draft
   [I-D.ietf-httpbis-alt-svc] which is not as close to ready for last
   call as the core HTTP/2 specification.  Others, such as DRAINING,
   have been suggested on the mailing list though not introduced to the
   specification.  Many of these features are optional either to use or
   to process, limiting their broad applicability.

   In the words of Antoine de Saint-Exupery, "Perfection is achieved,
   not when there is nothing more to add, but when there is nothing left
   to take away."  Many of these frames represent concerns which, while
   worth addressing, are not fundamental to the goals of HTTP/2.  The
   HTTP/2 specification should be the minimal set of features which
   enables two peers to communicate efficiently and achieve the goals
   laid out in the working group charter.

   This working group is empowered by its charter to work on additional
   extensions to HTTP provided that "[t]he Working Group Chairs ...



Bishop                  Expires November 23, 2014               [Page 2]


Internet-Draft                 Extensions                       May 2014


   believe that it will not interfere with the work described above
   [definition of HTTP/2]."  The working group is explicitly prohibited
   from defining HTTP/2 extensions until the HTTP/2 work is complete.

   This draft contends that some or all of these late-breaking features
   could be easily recast as extensions, simplifying and unblocking the
   core specification.  Existing implementations of these features would
   test the extensibility model in the process of interoperating with
   others who have chosen not to implement them, permitting us to
   finalize HTTP/2 and turn our attention to the set of extensions the
   working group has already reached consensus should be explored.

1.1.  Conventions and Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   All numeric values are in network byte order.  Values are unsigned
   unless otherwise indicated.  Literal values are provided in decimal
   or hexadecimal as appropriate.  Hexadecimal literals are prefixed
   with "0x" to distinguish them from decimal literals.

2.  Problems an extension model must solve

   Possible extensions vary along a number of pivots.  Any extension
   model must define how extensions will work along each pivot, which
   may include disallowing certain combinations.  Possible variants of
   extensions include:

   o  Changes session state, or strictly informative

   o  Flow-controlled third-party data or freely-sent control data

   o  Hop-by-hop or end-to-end

   There is no way to know whether the peer supports a given extension
   before sending extension-specific information.  This can be simply
   addressed by saying that implementations MUST ignore frame types and
   settings values they don't understand.  However, this model only
   works for strictly informative frames and/or settings.  An extension
   model must define a way to determine whether a peer supports a given
   extension, if non-informative extensions are supported.

   Another concern is that with only 256 frame types, the frame type
   space may be exhausted if many extensions are defined.  Different
   extensions could collide with each other in the choice of frame type
   identifiers, since the space is limited.  RFC 6709 [RFC6709]



Bishop                  Expires November 23, 2014               [Page 3]


Internet-Draft                 Extensions                       May 2014


   discusses in detail the trade-offs that must be considered by any
   protocol's extension model.  One key risk is that a difficult
   registration process will encourage the use of unregistered
   extensions, which leads to collisions, but a small space requires
   rigorous control over the identifier space.

   Another risk that arises when extension is overly constrained is the
   emergence of protocol variations.  RFC 6709 [RFC6709] has this to
   say: "Protocol variations -- specifications that look very similar to
   the original but don't interoperate with each other or with the
   original -- are even more harmful to interoperability than
   extensions."  Where no extensions are possible, implementers who wish
   to extend HTTP/2 will quickly move to define a new protocol which
   looks remarkably similar to HTTP/2, but is not interoperable.

   Future protocols using the HTTP/2 framing layer will face exactly the
   same problem as extension authors, since they share a frame type and
   setting value space with any extensions.  Thus, a new frame
   introduced with, for example, HTTP/3 must avoid collision with any
   HTTP/2 extensions and must deal with space exhaustion.  Any means of
   resolving such adoption after the fact complicates forward-porting of
   existing extensions.

   This document proposes an alternative method of supporting extension
   frames and settings, with the following goals:

   o  Reduce the probability of collision among extensions and between
      extensions and future versions of HTTP

   o  Enable peers to quickly discover support for a particular
      extension on the far side

   o  Enable extension implementers to interoperate with minimal
      procedural overhead

3.  Extension Functionality

3.1.  Extension Identification and Negotiation

   An extension to HTTP/2 is identified by an Extension ID.  An
   Extension ID is a 32-bit identifier registered with IANA.  Extension
   identifiers above 0xFFFF0000 are reserved for experimental use, as
   described below (Section 3.1.1).








Bishop                  Expires November 23, 2014               [Page 4]


Internet-Draft                 Extensions                       May 2014


3.1.1.  Experimental Extensions

   The designer of an extension MAY self-allocate an extension ID in the
   experimental range defined above without interaction with IANA.  Such
   an extension MUST use only frame numbers and setting IDs from the
   experimental range.  These extensions MUST NOT be generally deployed
   until a non-experimental extension ID has been allocated.

   As a further guard against accidental collisions, an experimental
   extension SHOULD define a random 32-bit number, and include this
   number as the first four bytes of each frame used by the extension.
   Received frames which do not include this identifier MUST be treated
   as an unrecognized frame type.

3.2.  Extension Negotiation

   An implementation which supports extensions SHOULD send an EXTENSIONS
   (Section 3.3.2) frame immediately following its SETTINGS frame at
   connection establishment, listing all extensions that it wishes to
   use during the lifetime of the connection.  After receiving a
   corresponding EXTENSIONS frame, any extensions which were present in
   both frames are considered to be in effect for the lifetime of the
   connection.  The EXTENSIONS frame may be sent only once per
   connection.

   An empty EXTENSIONS frame declares that the sender does not wish to
   employ any hop-by-hop extensions beyond the negotiated protocol.

   Extension-defined hop-by-hop frames and settings which modify stream
   or session state (including flow control) MUST NOT be sent until the
   EXTENSIONS frame has been received from the remote endpoint declaring
   support for the associated extension ID.  Extension-defined frames
   and settings which are strictly informative MAY be sent between
   sending the EXTENSIONS frame and before receiving the peer's
   EXTENSIONS frame.  Implementations SHOULD NOT send informative frames
   or settings from any extension after receiving an EXTENSIONS frame
   which does not list support for that extension, since the receiver
   likely will not understand the extra information.

3.3.  New Frames and Modifications

3.3.1.  Definition of Frames









Bishop                  Expires November 23, 2014               [Page 5]


Internet-Draft                 Extensions                       May 2014


   To support the notion of end-to-end extension frames, one Reserved
   bit from the Frame Header is given a defined meaning:

       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | R |     Length (14)           |   Type (8)    |   Flags (8)   |
      +-+-+-----------+---------------+-------------------------------+
      |E|                 Stream Identifier (31)                      |
      +-+-------------------------------------------------------------+
      |                   Frame Payload (0...)                      ...
      +---------------------------------------------------------------+

                               Frame Header

   The newly-added "E" field marks whether a frame is intended for end-
   to-end transmission or hop-by-hop transmission.  End-to-end frames
   MUST be relayed by intermediaries, even if the frame type is unknown.
   Such frames do not imply any changes to stream or session state.
   End-to-end frames are always subject to flow control.

   An end-to-end frame on stream zero is meaningless, and MUST be
   discarded upon receipt.

   Of the frames defined in the base HTTP/2 spec, DATA frames MUST set
   the E bit; all other control frames (WINDOW_UPDATE, PUSH_PROMISE,
   HEADERS, etc.)  MUST NOT set the E bit.  Receipt of a base HTTP/2
   frame with the E bit set improperly indicates a fundamental error in
   the remote implementation, and MUST trigger a connection error of
   type PROTOCOL_ERROR.

3.3.2.  EXTENSIONS Frame

   The EXTENSIONS frame (number TBD) carries a list of zero or more
   extensions supported by the sender:


       0                   1                   2                   3
       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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Extension ID (32)                     |
       +---------------------------------------------------------------+
       |                   Extension-specific data (32)                |
       +---------------------------------------------------------------+


                             EXTENSIONS format




Bishop                  Expires November 23, 2014               [Page 6]


Internet-Draft                 Extensions                       May 2014


   For each extension, the sender includes 32 bits of inital state.  The
   semantics of this value are completely defined by the extension.

3.3.3.  EXPANDED Frame

   The EXPANDED frame (number 0xFF) expands the space of frame types by
   supplying additional bits for the frame type:


       0                   1                   2                   3
       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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |0|                    Expanded Frame Type (31)                 |
       +---------------------------------------------------------------+
       |                        Frame Payload (0...)                 ...
       +---------------------------------------------------------------+


                              EXPANDED Format

   In order to mitigate the concern that 256 frame types are too few to
   allow free access to extensions, the EXPANDED frame defines an
   additional 31 bits that can be used for the frame type space.  Frame
   types numbered 256 or greater are encoded within an EXPANDED frame,
   and the Expanded Frame Type field set to the desired frame type value
   minus 256.  This increases the maximum frame type to 0x80000100
   without increasing the frame size for common frame types.

   Implementations which have no knowledge of frame types greater than
   255 MAY ignore any EXPANDED frames upon receipt, though
   intermediaries MUST still relay end-to-end EXPANDED frames.

3.3.4.  Extension-Defined Frames

   An extension MAY define new frame types, which are registered with
   IANA.  Frame types greater than 0x80000000 will not be allocated by
   IANA and are reserved for use by experimental extensions.  Frame
   types less than 256 are reserved for assignment by standards-track
   RFCs.

   As part of the definition of the extension and frame type, the
   extension MUST specify whether the frames it defines modify session
   state in any way, including being flow-controlled.  (Any frame which
   modifies session state MUST NOT be sent prior to receipt of an
   EXTENSIONS frame declaring support for the specified extension.)

   Only frames which do not change stream or session state may be marked
   as end-to-end, since intermediaries which do not understand the frame



Bishop                  Expires November 23, 2014               [Page 7]


Internet-Draft                 Extensions                       May 2014


   type would not be able to track the state changes.  Because end-to-
   end frames have unknown payload and provenance, end-to-end frames are
   always flow-controlled.

   Frames which do not modify stream or session state MAY be sent at any
   time.  However, an implementation SHOULD NOT send hop-by-hop
   extension frames after receiving an EXTENSIONS frame indicating that
   the other party will not understand the frame being sent.

   An extension has complete freedom to define the payload, flags, and
   other semantics of the frames it specifies, including when and on
   what streams the frame may or may not be sent.

3.3.4.1.  Handling by Intermediaries

   Intermediaries MUST forward all end-to-end frames regardless of
   whether they recognize the frame type.  Endpoints (user agents and
   origin servers) MUST discard any frame types which they do not
   recognize.  Such frames are, by definition, informational and can be
   safely ignored without affecting the shared state with the sender.

   All hop-by-hop extension-defined frames MUST be dropped by
   intermediaries which do not support the extension.  However, each
   extension SHOULD specify how an intermediary translates the frames
   defined by the extension toward other peers which might or might not
   support the same extension.  When an intermediary advertises support
   for an extension, it MUST abide by the extension-defined intermediary
   behavior.

   An intermediary which advertises support for an extension is
   explicitly not guaranteeing that all peers to which it will relay
   information support the same extensions.  Extension definitions
   SHOULD define how intermediaries translate in the following
   situations:

      Relaying to HTTP/1.1 connection

      Relaying to HTTP/2 connection without extension support

      Relaying to HTTP/2 connection with extension support

3.4.  Settings









Bishop                  Expires November 23, 2014               [Page 8]


Internet-Draft                 Extensions                       May 2014


   This draft restores the definition of a setting value as follows:


       0                   1                   2                   3
       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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Identifier (32)                        |
       +---------------------------------------------------------------+
       |                           Value (32)                          |
       +---------------------------------------------------------------+


                       Modified Setting Value Format

   Extensions may define settings whose identifiers are registered with
   IANA.  The semantics of any such setting value are defined strictly
   by the extension.  Implementations MUST ignore unknown settings and
   MUST NOT emit settings defined by an extension which has not been
   announced in an EXTENSIONS (Section 3.3.2) frame.

4.  IANA Considerations

   This draft proposes the restoration to the HTTP/2 spec of IANA
   registries for the following, pre-populated with the values defined
   in the HTTP/2 specification:

   o  Frame types, with values less than 256 restricted to standards-
      track RFCs and values greater than 0x80000000 reserved for private
      experimental use

   o  Setting identifiers, with values greater than 0xFFFF0000 reserved
      for private experimental use

   o  Error codes

   And additionally, the creation of a registry for Extension IDs, with
   values above 0xFFFF0000 reserved for private experimental use.

   Given the expanded space, these registries should be allocated on a
   first-come-first-served [RFC5226] basis except as described above,
   though a publicly-available specification for each extension is
   strongly recommended.

5.  References







Bishop                  Expires November 23, 2014               [Page 9]


Internet-Draft                 Extensions                       May 2014


   [I-D.ietf-httpbis-alt-svc]
              Nottingham, M., McManus, P., and J. Reschke, "HTTP
              Alternative Services", draft-ietf-httpbis-alt-svc-01 (work
              in progress), April 2014.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC6709]  Carpenter, B., Aboba, B., and S. Cheshire, "Design
              Considerations for Protocol Extensions", RFC 6709,
              September 2012.




































Bishop                  Expires November 23, 2014              [Page 10]


Internet-Draft                 Extensions                       May 2014


Appendix A.  Example Extensions

   This section describes how certain extensions might leverage the
   above model.  Because a number of recent additions to the HTTP/2
   specifications are excellent candidates for extension definition,
   they are used as examples here.

A.1.  Blocked Flow-Control Announcement Extension

A.1.1.  EXTENSIONS Payload

   Support for the Blocked Flow Control Announcement Extension is
   indicated by including extension ID 0xB39D237F in an EXTENSIONS
   frame.  The initial data in the EXTENSIONS frame MUST be zero when
   sent and MUST be ignored on receipt.

A.1.2.  BLOCKED Frame

   The BLOCKED frame defines no flags and contains no interpretable
   payload.  Because the frame is experimental, each BLOCKED frame MUST
   contain the static payload 0xABED6142 for disambiguation.  A receiver
   MUST treat the receipt of a BLOCKED frame with any other payload as
   an unknown frame type and ignore it.

A.1.3.  Use of BLOCKED Frame

   The BLOCKED frame is used to provide feedback about the performance
   of flow control for the purposes of performance tuning and debugging.
   The BLOCKED frame can be sent by a peer when flow controlled data
   cannot be sent due to the connection- or stream-level flow control
   window being zero or less.  This frame MUST NOT be sent if there are
   other reasons preventing data from being sent, such as a lack of
   available data or the underlying transport being blocked.

   The BLOCKED frame MAY be sent on a connection prior to receiving an
   EXTENSIONS frame, but SHOULD NOT be sent after the receipt of an
   EXTENSIONS frame which does not include the BLOCKED extension ID.

   The BLOCKED frame is sent on the stream that is blocked, that is, the
   stream with a non-positive number of bytes available in the flow
   control window.  A BLOCKED frame can be sent on stream 0x0 to
   indicate that connection-level flow control is blocked.

   An endpoint MUST NOT send any subsequent BLOCKED frames until the
   affected flow control window becomes positive.  This means that
   WINDOW_UPDATE frames are received or SETTINGS_INITIAL_WINDOW_SIZE is
   increased before more BLOCKED frames can be sent.




Bishop                  Expires November 23, 2014              [Page 11]


Internet-Draft                 Extensions                       May 2014


A.1.4.  Behavior by Intermediaries

   Because flow-control is hop-by-hop, intermediaries MUST NOT relay a
   BLOCKED frame onto any other connection.  If the intermediary is
   blocked by flow control, they MAY generate BLOCKED frames
   independently on other connections where BLOCKED is supported.

A.2.  Alternate-Service Announcement

A.2.1.  EXTENSIONS Payload

   Support for the Alternate Service Announcement Extension is indicated
   by including extension ID 0x8877B974 in an EXTENSIONS frame.  The
   initial data in the EXTENSIONS frame MUST be zero when sent and MUST
   be ignored on receipt.

A.2.2.  ALTSVC Frame


     0                   1                   2                   3
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Max-Age (32)                         |
    +-------------------------------+---------------+---------------+
    |            Port (16)          | Proto-Len (8) |
    +-------------------------------+---------------+---------------+
    |                        Protocol-ID (*)                        |
    +---------------+-----------------------------------------------+
    | Host-Len (8)  |                   Host (*)                  ...
    +---------------+-----------------------------------------------+
    |                          Origin? (*)                        ...
    +---------------------------------------------------------------+


                           ALTSVC Frame Payload

   The ALTSVC frame contains the following fields:

   Max-Age:  An unsigned, 32-bit integer indicating the freshness
      lifetime of the alternative service association.

   Port:  An unsigned, 16-bit integer indicating the port that the
      alternative service is available upon.

   Proto-Len:  An unsigned, 8-bit integer indicating the length, in
      octets, of the Protocol-ID field.





Bishop                  Expires November 23, 2014              [Page 12]


Internet-Draft                 Extensions                       May 2014


   Protocol-ID:  A sequence of bytes (length determined by "Proto-Len")
      containing the ALPN protocol identifier of the alternative
      service.

   Host-Len:  An unsigned, 8-bit integer indicating the length, in
      octets, of the Host field.

   Host:  A sequence of characters (length determined by "Host-Len")
      containing an ASCII string indicating the host that the
      alternative service is available upon.  An internationalized
      domain name MUST be expressed using A-labels.

   Origin:  An optional sequence of characters (length determined by
      subtracting the length of all preceding fields from the frame
      length) containing the ASCII serialisation of an origin that the
      alternate service is applicable to.

   The ALTSVC frame does not define any flags.

A.2.3.  Use of ALTSVC Frame

   The ALTSVC frame (type=0xA) advertises the availability of an
   alternative service to the client.  It can be sent at any time for an
   existing client-initiated stream or stream 0, and is intended to
   allow servers to load balance or otherwise segment traffic; see
   [I-D.ietf-httpbis-alt-svc] for details.

   An ALTSVC frame on a client-initiated stream indicates that the
   conveyed alternative service is associated with the origin of that
   stream.

   An ALTSVC frame on stream 0 indicates that the conveyed alternative
   service is associated with the origin contained in the Origin field
   of the frame.  An association with an origin that the client does not
   consider authoritative for the current connection MUST be ignored.

   The ALTSVC frame is intended for receipt by clients; a server that
   receives an ALTSVC frame MAY treat it as a connection error of type
   PROTOCOL_ERROR.

   A server MAY send an ALTSVC frame before receiving an EXTENSIONS
   frame listing support for the Alternate-Service Availability
   Announcement extension, but SHOULD NOT send an ALTSVC frame after
   receiving an EXTENSIONS frame which does not declare support.







Bishop                  Expires November 23, 2014              [Page 13]


Internet-Draft                 Extensions                       May 2014


A.2.4.  Behavior by Intermediaries

   The ALTSVC frame is processed hop-by-hop.  An intermediary MUST NOT
   forward ALTSVC frames, though it can use the information contained in
   ALTSVC frames in forming new ALTSVC frames to send to its own
   clients.

A.3.  Compressed Data Frames

   The COMPRESSED_DATA frame (type=TBD) permits a frame-by-frame choice
   of transfer encoding, permitting connections to employ compression
   where appropriate while still enabling the separation of different
   data into different contexts as appropriate.

A.3.1.  EXTENSIONS Payload

   Support for the Compressed Data Extension is indicated by the
   following in an EXTENSIONS frame:


   0                   1                   2                   3
   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Extension ID (32)                       |
   +---------------+-----------------------------------------------+
   |  Contexts (8) |             Supported algorithms (24)         |
   +---------------+-----------------------------------------------+


                       Compressed Data in EXTENSIONS

   The EXTENSIONS entry contains the following fields:

   Extension ID:  The extension ID for the Compressed Data Extension is
      0x53F9F537.

   Contexts  An eight-bit count of the number of separate compression
      contexts the sender is willing to maintain.  This SHOULD be
      greater than zero.

   Supported algorithms  A bitmap of compression algorithms supported by
      the sender:

      0x001:  Compress  The "compress" coding is an adaptive Lempel-Ziv-
         Welch (LZW) coding that is commonly produced by the UNIX file
         compression program "compress".





Bishop                  Expires November 23, 2014              [Page 14]


Internet-Draft                 Extensions                       May 2014


      0x002:  Deflate  The "deflate" coding is a "zlib" data format
         [RFC1950] containing a "deflate" compressed data stream
         [RFC1951] that uses a combination of the Lempel-Ziv (LZ77)
         compression algorithm and Huffman coding.

      0x003:  GZip  The "gzip" coding is an LZ77 coding with a 32 bit
         CRC that is commonly produced by the gzip file compression
         program [RFC1952].

      Other bits:  Reserved for future updates; MUST be zero when sent
         and ignored upon receipt

      Setting the corresponding bit indicates that the sender supports
      creating a compression context for the corresponding algorithm.

A.3.2.  COMPRESSED_DATA Frame

   The COMPRESSED_DATA frame defines the following flags:

   END_STREAM (0x1):  Bit 1 being set indicates that this frame is the
      last that the endpoint will send for the identified stream.
      Setting this flag causes the stream to enter one of the "half
      closed" states or the "closed" state.

   END_SEGMENT (0x2):  Bit 2 being set indicates that this frame is the
      last for the current segment.  Intermediaries MUST NOT coalesce
      frames across a segment boundary and MUST preserve segment
      boundaries when forwarding frames.

   PAD_LOW (0x8):  Bit 4 being set indicates that the Pad Low field is
      present.

   PAD_HIGH (0x10):  Bit 5 being set indicates that the Pad High field
      is present.  This bit MUST NOT be set unless the PAD_LOW flag is
      also set.  Endpoints that receive a frame with PAD_HIGH set and
      PAD_LOW cleared MUST treat this as a connection error of type
      PROTOCOL_ERROR.

   Init_Context (0x20):  Indicates the presence of the Algorithm and
      Initialization fields in the COMPRESSED_DATA frame.  MUST be set
      on the first frame to reference a context which has not previously
      been used, or which has been cleared.  If set on any other frame,
      the previous value of the context MUST be discarded before further
      processing.

   Clear_Context (0x40):  Indicates that this is the last frame which
      will use the current context state, and that the context MUST be
      discarded after interpretation of the current frame.



Bishop                  Expires November 23, 2014              [Page 15]


Internet-Draft                 Extensions                       May 2014


   The payload is formatted as follows:


     0                   1                   2                   3
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Pad High? (8) |  Pad Low? (8) |  Context (8)  | Algorithm? (8)|
    +---------------+---------------+---------------+---------------+
    |                     Compressed payload (*)                  ...
    +---------------+-----------------------------------------------+
    |                           Padding? (*)                      ...
    +---------------------------------------------------------------+


                              COMPRESSED_DATA

   The fields are:

   Pad High:  An 8-bit field containing an amount of padding in units of
      256 octets.  This field is optional and is only present if the
      PAD_HIGH flag is set.  This field, in combination with Pad Low,
      determines how much padding there is on a frame.

   Pad Low:  An 8-bit field containing an amount of padding in units of
      single octets.  This field is optional and is only present if the
      PAD_LOW flag is set.  This field, in combination with Pad High,
      determines how much padding there is on a frame.

   Context:  An eight-bit value reflecting which of the connection's
      contexts the sender intends to use.  This MUST be less than the
      value the recipient declared in EXTENSIONS.

   Algorithm:  Present only if the Init_Context flag is set.  Declares
      the compression algorithm the sender intends to employ on the new
      context.  Integer taken from the same list employed in the
      EXTENSIONS frame to announce support.

   Compressed payload  The remainder of the payload is the compressed
      content, interpreted using the selected compression context.

   Padding:  Padding octets that contain no application semantic value.
      Padding octets MUST be set to zero when sending and ignored when
      receiving.








Bishop                  Expires November 23, 2014              [Page 16]


Internet-Draft                 Extensions                       May 2014


A.3.3.  Use of COMPRESSED_DATA Frame

   The COMPRESSED_DATA frame may be sent instead of a DATA frame
   provided that both of the following are true:

      The sender is allowed to send a DATA frame at this time on this
      stream

      The recipient has advertised support for the Compressed Data
      Extension

   The sender SHOULD clear contexts, use different contexts, or compress
   selectively to prevent attacker-controlled data from being compressed
   in the same compression context as server-controlled data.

   COMPRESSED_DATA frames are subject to flow control and can only be
   sent when a stream is in the "open" or "half closed (remote)" states.
   The entire frame payload is included in flow control, including Pad
   Low, Pad High, Context, Algorithm, Initialization, and Padding fields
   if present.  If a COMPRESSED_DATA frame is received whose stream is
   not in "open" or "half closed (local)" state, the recipient MUST
   respond with a stream error of type STREAM_CLOSED.  After processing
   flow control, the frame is decompressed and the result processed as
   if a DATA frame with the decompressed payload had just been received.

   If the COMPRESSED_DATA frame had the Clear_Context flag set, the
   sender MUST discard the compression context immediately following
   compression, and the recipient MUST do likewise immediately after
   decompression.

A.3.4.  Behavior by Intermediaries

   COMPRESSED_DATA frames are processed hop-by-hop, though an
   intermediary MAY relay the same compressed content onto another
   connection if an identical compression context is available.

   Intermediaries MAY convert COMPRESSED_DATA frames to use different
   compression schemes on different connections, and MAY convert
   COMPRESSED_DATA frames into DATA frames on connections which do not
   support this extension or which do not support a compression
   algorithm to which the intermediary is willing to convert.

   Intermediaries MUST NOT convert DATA frames into COMPRESSED_DATA
   frames.







Bishop                  Expires November 23, 2014              [Page 17]


Internet-Draft                 Extensions                       May 2014


Appendix B.  Acknowledgements

   This document includes input from Rob Trace, Gabriel Montenegro, and
   James Snell.

   Sample extensions are based largely on the work of Mark Nottingham,
   Roberto Peon, and Matthew Kerwin.

Author's Address

   Mike Bishop
   Microsoft

   EMail: michbish@microsoft.com





































Bishop                  Expires November 23, 2014              [Page 18]