Network Working Group                                           J. Snell
Internet-Draft
Intended status: Informational                         November 11, 2013
Expires: May 15, 2014


               HTTP/2.0 Discussion: Extension Frame Types
                   draft-snell-httpbis-ext-frames-01

Abstract

   This memo describes the structure and use cases for a handful of
   "extension" frames types for HTTP 2.0.  The purpose of this document
   is to add to the overall discussion around the development of HTTP
   2.0 by describing ways in which the framing layer can be leveraged
   and extended.

Status of This Memo

   This Internet-Draft is submitted to IETF 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 May 15, 2014.

Copyright Notice

   Copyright (c) 2013 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.






Snell                     Expires May 15, 2014                  [Page 1]

Internet-Draft     Extension Frame Types for HTTP 2.0      November 2013


Table of Contents

   1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Structured Frame Type Identifier  . . . . . . . . . . . . . .   2
   3.  Update DATA Frame Type Identifier . . . . . . . . . . . . . .   3
   4.  Reserved Private-Use Frame Type Range . . . . . . . . . . . .   3
   5.  New INFO hop-by-hop Frame Type  . . . . . . . . . . . . . . .   3
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
     6.2.  Informational References  . . . . . . . . . . . . . . . .   4
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   4

.  Overview

   HTTP/2.0 frame types are currently identified using an unstructured
   8-bit identifier.  The current draft specification currently defines
   10 standard frame types and establishes an IANA registry to track and
   manage new "extension" frame types.

   This memo proposes a handful of changes to the current specification
   to better support the definition and use of extension frame types.

.  Structured Frame Type Identifier

   First, it is proposed that the frame type identifier be restructured
   such that if the most significant bit is set, the frame type is
   understood to be "end-to-end".

   When an intermediary encounters an unknown or unsupported end-to-end
   frame type, and the stream ID is not zero (0), it MUST either
   terminate the stream with an RST_STREAM or pass the frame through
   untouched and unmodified.  If the stream ID is zero, the intermediary
   SHOULD ignore the frame but MAY choose to signal a connection error.

   Additionally, end-to-end frame types are always subject to HTTP/2.0
   flow control mechanisms.

   If the most significant bit in the frame type identifier is not set,
   the frame type is understood to be "hop-by-hop".

   When an endpoint encounters unknown or unsupported hop-by-hop frame
   types, the frame SHOULD be ignored.  However, endpoints MAY choose to
   signal either a stream or connection error.

   +-------------+-----------------+-----------------+-----------------+
   | Type Range  | Handling        | Handling        | Flow Controlled |
   |             | (Stream = 0)    | (Stream > 0)    |                 |
   +-------------+-----------------+-----------------+-----------------+



Snell                     Expires May 15, 2014                  [Page 2]

Internet-Draft     Extension Frame Types for HTTP 2.0      November 2013


   | 0x00-7F     | SHOULD Ignore   | Stream Error    | No              |
   | 0x80-FF     | SHOULD Ignore   | MUST Forward or | Yes             |
   |             |                 | Error           |                 |
   +-------------+-----------------+-----------------+-----------------+


.  Update DATA Frame Type Identifier

   To reflect the proposed change to the type identifier structure, it
   is further proposed that the type identifier of the existing DATA
   frame be changed to 0x80.

.  Reserved Private-Use Frame Type Range

   The upper range of each frame type segment (0x6B-0x7F and 0xEB-FF)
   would be reserved as "Private Use" and cannot be assigned as part of
   the IANA registry.

.  New INFO hop-by-hop Frame Type

   It is further proposed that a new "INFO" hop-by-hop frame type (0x0B)
   be introduced.  The purpose of the INFO frame is to allow endpoints
   to exchange additional "ok to ignore" "Information Records"
   associated with a connection or stream.

   The INFO frame contains a sub-header with the following format:

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Info Group ID (16)     |       Info Item ID (16)       |
   +---------------------------------------------------------------+
   |                       Info-specific payload                 ...
   +---------------------------------------------------------------+


   Each "Information Record" type is identified by a 16-bit "Group" ID
   followed by a 16-bit "Group Local" ID.  The remaining format of the
   information record depends entirely on the information record type.
   The Group ID 0x0 is reserved for use by Standards Track RFC's.

   INFO frames are always hop-by-hop.  If an endpoint encounters an INFO
   frame that uses an unrecognized information record type identifier,
   the endpoint MUST simply ignore the frame.  Processing of an INFO
   frame MUST never modify the state of the connection or stream.

   INFO frames can be sent on any stream in the "open" or "half-closed
   (remote)" states, or can be sent on stream ID 0 at any time.



Snell                     Expires May 15, 2014                  [Page 3]

Internet-Draft     Extension Frame Types for HTTP 2.0      November 2013


   Note: The INFO frame is modeled after the structure for "Extension
   Frames" proposed by [BishopExtensions].

.  References

6.1.  Normative References

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

6.2.  Informational References

   [BishopExtensions]
              Bishop, M., "Extension Frames in HTTP/2.0", draft-bishop-
              http2-extension-frames-00 (work in progress), November
              2013.

Author's Address

   James M Snell

   Email: jasnell@gmail.com





























Snell                     Expires May 15, 2014                  [Page 4]