[IANA #801638] Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard

(BEGIN IANA LAST CALL COMMENTS)

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-httpbis-http2-16.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA understands that, upon approval of this document, there are eight actions which must be completed.

IANA has questions about some of the requested actions that require Expert Review 
according to the relevant defining RFCs.

First, in the Application-Layer Protocol Negotiation (ALPN) Protocol IDs subregistry of the Transport Layer Security (TLS) Extensions registry located at:

http://www.iana.org/assignments/tls-extensiontype-values/

two new protocol IDs will be registered as follows:

Protocol: HTTP/2 over TLS
Identification Sequence: 0x68 0x32 ("h2")
Reference: [ RFC-to-be ]

Protocol: HTTP/2 over TCP
Identification Sequence: 0x68 0x32 0x63 ("h2c")
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review (see RFC 5226) registry, we will initiate the required Expert Review via a separate request.  Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, a new entry is created in the IANA matrix located at:

https://www.iana.org/protocols

called "Hypertext Transfer Protocol (HTTP) 2 Parameters"  

Third, in the new IANA Matrix registry created in action two above, a new registry will be created called the HTTP/2 Frame Type registry. Maintainence of the registry for values 0x00 and 0xef is done via IETF Review or IESG Approval as defined by RFC 5226. Values between 0xf0 and 0xff are reserved for experimental use.

There are initial values in this new registry as follows:

+---------------+------+----------------+
| Frame Type    | Code | Reference      |
+---------------+------+----------------+
| DATA          | 0x0  | [ RFC-to-be ]  |
| HEADERS       | 0x1  | [ RFC-to-be ]  |
| PRIORITY      | 0x2  | [ RFC-to-be ]  |
| RST_STREAM    | 0x3  | [ RFC-to-be ]  |
| SETTINGS      | 0x4  | [ RFC-to-be ]  |
| PUSH_PROMISE  | 0x5  | [ RFC-to-be ]  |
| PING          | 0x6  | [ RFC-to-be ]  |
| GOAWAY        | 0x7  | [ RFC-to-be ]  |
| WINDOW_UPDATE | 0x8  | [ RFC-to-be ]  |
| CONTINUATION  | 0x9  | [ RFC-to-be ]  |
+---------------+------+----------------+

Fourth, also in the new IANA Matrix registry created in action two above, a new registry will be created called the HTTP/2 Settings Registry. Maintenance of the registry for values 0x0000 to 0xefff is done through Expert Review as defined in RFC 5226. Values between 0xf000 and 0xffff are reserved for experimental use.

There are initial registrations in the new registry as follows:

+------------------------+------+---------------+---------------+
| Name                   | Code | Initial Value | Reference     |
+------------------------+------+---------------+---------------+
| HEADER_TABLE_SIZE      | 0x1  | 4096          | [ RFC-to-be ] |
| ENABLE_PUSH            | 0x2  | 1             | [ RFC-to-be ] |
| MAX_CONCURRENT_STREAMS | 0x3  | (infinite)    | [ RFC-to-be ] |
| INITIAL_WINDOW_SIZE    | 0x4  | 65535         | [ RFC-to-be ] |
| MAX_FRAME_SIZE         | 0x5  | 16384         | [ RFC-to-be ] |
| MAX_HEADER_LIST_SIZE   | 0x6  | (infinite)    | [ RFC-to-be ] |
+------------------------+------+---------------+---------------+

Fifth, also in the new IANA Matrix registry created in action two above, a new registry will be created called the HTTP/2 Error Code registry. Maintenance of the registry is done through Expert Review as defined in RFC 5226.

There are initial registrations in the new registry as follows:

+---------------------+------+----------------------+---------------+
| Name                | Code | Description          | Reference     |
+---------------------+------+----------------------+---------------+
| NO_ERROR            | 0x0  | Graceful shutdown    | [ RFC-to-be ] |
| PROTOCOL_ERROR      | 0x1  | Protocol error       | [ RFC-to-be ] |
|                     |      | detected             |               |
| INTERNAL_ERROR      | 0x2  | Implementation fault | [ RFC-to-be ] |
| FLOW_CONTROL_ERROR  | 0x3  | Flow control limits  | [ RFC-to-be ] |
|                     |      | exceeded             |               |
| SETTINGS_TIMEOUT    | 0x4  | Settings not         | [ RFC-to-be ] |
|                     |      | acknowledged         |               |
| STREAM_CLOSED       | 0x5  | Frame received for   | [ RFC-to-be ] |
|                     |      | closed stream        |               |
| FRAME_SIZE_ERROR    | 0x6  | Frame size incorrect | [ RFC-to-be ] |
| REFUSED_STREAM      | 0x7  | Stream not processed | [ RFC-to-be ] |
| CANCEL              | 0x8  | Stream cancelled     | [ RFC-to-be ] |
| COMPRESSION_ERROR   | 0x9  | Compression state    | [ RFC-to-be ] |
|                     |      | not updated          |               |
| CONNECT_ERROR       | 0xa  | TCP connection error | [ RFC-to-be ] |
|                     |      | for CONNECT method   |               |
| ENHANCE_YOUR_CALM   | 0xb  | Processing capacity  | [ RFC-to-be ] |
|                     |      | exceeded             |               |
| INADEQUATE_SECURITY | 0xc  | Negotiated TLS       | [ RFC-to-be ] |
|                     |      | parameters not       |               |
|                     |      | acceptable           |               |
| HTTP_1_1_REQUIRED   | 0xd  | Use HTTP/1.1 for the | [ RFC-to-be ] |
|                     |      | request              |               |
+---------------------+------+----------------------+---------------+

Sixth, in the Permanent Message Header Field Registry of the Message Headers registry located at:

http://www.iana.org/assignments/message-headers/

a new header field will be registered as follows: 

Header Field Name: HTTP2-Settings
Template: 
Protocol: http
Status: Standard
Reference: [ RFC-to-be ]

This registry is maintained via Expert Review and Expert review will need to be completed for this registration before your document can be approved for publication as an RFC.

Seventh, in the Hypertext Transfer Protocol (HTTP) Method Registry located at:

http://www.iana.org/assignments/http-methods/

a new method will be registered as follows:

Method Name: PRI
Safe: No
Idempotent: No
Reference: [ RFC-to-be ]

Question: just to double check if the new requested method "PRI" is an abbreviation.
It appears that RFC7231 does not require a full name.


Eighth, in the Hypertext Transfer Protocol (HTTP) Status Code Registry located at:

http://www.iana.org/assignments/http-status-codes/

a new status code will be registered as follows:

Value: 421
Description: Misdirected Request
Reference: [ RFC-to-be ]

IANA understands that these eight actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.  

Please note that IANA cannot reserve specific values. However, early allocation is available for some types of registrations. For more information, please see RFC 7120. 

Thanks,

Pearl Liang
ICANN

(END IANA LAST CALL COMMENTS)


On Wed Dec 31 15:31:14 2014, iesg-secretary@ietf.org wrote:
> 
> The IESG has received a request from the Hypertext Transfer Protocol WG
> (httpbis) to consider the following document:
> - 'Hypertext Transfer Protocol version 2'
>   <draft-ietf-httpbis-http2-16.txt> as Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@ietf.org mailing lists by 2015-01-14. Exceptionally, comments may be
> sent to iesg@ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>    This specification describes an optimized expression of the semantics
>    of the Hypertext Transfer Protocol (HTTP).  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 messages on the same connection.  It also introduces
>    unsolicited push of representations from servers to clients.
> 
>    This specification is an alternative to, but does not obsolete, the
>    HTTP/1.1 message syntax.  HTTP's existing semantics remain unchanged.
> 
> 
> 
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-httpbis-http2/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-httpbis-http2/ballot/
> 
> 
> The following IPR Declarations may be related to this I-D:
> 
>    http://datatracker.ietf.org/ipr/1737/
>    http://datatracker.ietf.org/ipr/2122/
>    http://datatracker.ietf.org/ipr/1692/
>    http://datatracker.ietf.org/ipr/2506/
> 
> 
>

Received on Wednesday, 14 January 2015 08:09:55 UTC