Internet DRAFT - draft-snell-httpbis-ext-frames
draft-snell-httpbis-ext-frames
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
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.
+-------------+-----------------+-----------------+-----------------+
| 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 | |
+-------------+-----------------+-----------------+-----------------+
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.
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].
6. 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]