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.

Table of Contents

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

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

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

6. References

6.1. Normative References

6.2. Informational References

Author's Address