8. IANA Considerations
8.1. Header Field Registration
HTTP header fields are registered within the "Message Headers" registry maintained at http://www.iana.org/assignments/message-headers/.
This document defines the following HTTP header fields, so the "Permanent Message Header Field Names" registry has been updated accordingly (see [BCP90]).
+-------------------+----------+----------+---------------+
| Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+---------------+
| Connection | http | standard | Section 6.1 |
| Content-Length | http | standard | Section 3.3.2 |
| Host | http | standard | Section 5.4 |
| TE | http | standard | Section 4.3 |
| Trailer | http | standard | Section 4.4 |
| Transfer-Encoding | http | standard | Section 3.3.1 |
| Upgrade | http | standard | Section 6.7 |
| Via | http | standard | Section 5.7.1 |
+-------------------+----------+----------+---------------+
Furthermore, the header field-name "Close" has been registered as "reserved", since using that name as an HTTP header field might conflict with the "close" connection option of the Connection header field (Section 6.1).
+-------------------+----------+----------+-------------+
| Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+-------------+
| Close | http | reserved | Section 8.1 |
+-------------------+----------+----------+-------------+
The change controller is: "IETF ([email protected]) - Internet Engineering Task Force".
8.2. URI Scheme Registration
IANA maintains the registry of URI Schemes [BCP115] at http://www.iana.org/assignments/uri-schemes/.
This document defines the following URI schemes, so the "Permanent URI Schemes" registry has been updated accordingly.
+------------+------------------------------------+---------------+
| URI Scheme | Description | Reference |
+------------+------------------------------------+---------------+
| http | Hypertext Transfer Protocol | Section 2.7.1 |
| https | Hypertext Transfer Protocol Secure | Section 2.7.2 |
+------------+------------------------------------+---------------+
8.3. Internet Media Type Registration
IANA maintains the registry of Internet media types [BCP13] at http://www.iana.org/assignments/media-types.
This document serves as the specification for the Internet media types "message/http" and "application/http". The following has been registered with IANA.
8.3.1. Internet Media Type message/http
The message/http type can be used to enclose a single HTTP request or response message, provided that it obeys the MIME restrictions for all "message" types regarding line length and encodings.
Type name: message
Subtype name: http
Required parameters: N/A
Optional parameters: version, msgtype
version: The HTTP-version number of the enclosed message (e.g., "1.1"). If not present, the version can be determined from the first line of the body.
msgtype: The message type -- "request" or "response". If not present, the type can be determined from the first line of the body.
Encoding considerations: only "7bit", "8bit", or "binary" are permitted
Security considerations: see Section 9
Interoperability considerations: N/A
Published specification: This specification (see Section 8.3.1).
Applications that use this media type: N/A
Fragment identifier considerations: N/A
Additional information:
Magic number(s): N/A
Deprecated alias names for this type: N/A
File extension(s): N/A
Macintosh file type code(s): N/A
Person and email address to contact for further information: See Authors' Addresses section.
Intended usage: COMMON
Restrictions on usage: N/A
Author: See Authors' Addresses section.
Change controller: IESG
8.3.2. Internet Media Type application/http
The application/http type can be used to enclose a pipeline of one or more HTTP request or response messages (not intermixed).
Type name: application
Subtype name: http
Required parameters: N/A
Optional parameters: version, msgtype
version: The HTTP-version number of the enclosed messages (e.g., "1.1"). If not present, the version can be determined from the first line of the body.
msgtype: The message type -- "request" or "response". If not present, the type can be determined from the first line of the body.
Encoding considerations: HTTP messages enclosed by this type are in "binary" format; use of an appropriate Content-Transfer-Encoding is required when transmitted via email.
Security considerations: see Section 9
Interoperability considerations: N/A
Published specification: This specification (see Section 8.3.2).
Applications that use this media type: N/A
Fragment identifier considerations: N/A
Additional information:
Deprecated alias names for this type: N/A
Magic number(s): N/A
File extension(s): N/A
Macintosh file type code(s): N/A
Person and email address to contact for further information: See Authors' Addresses section.
Intended usage: COMMON
Restrictions on usage: N/A
Author: See Authors' Addresses section.
Change controller: IESG
8.4. Transfer Coding Registry
The "HTTP Transfer Coding Registry" defines the namespace for transfer coding names. It is maintained at http://www.iana.org/assignments/http-parameters.
8.4.1. Procedure
Registrations MUST include the following fields:
-
Name
-
Description
-
Pointer to specification text
Names of transfer codings MUST NOT overlap with names of content codings (Section 3.1.2.1 of [RFC7231]) unless the encoding transformation is identical, as is the case for the compression codings defined in Section 4.2.
Values to be added to this namespace require IETF Review (see Section 4.1 of [RFC5226]), and MUST conform to the purpose of transfer coding defined in this specification.
Use of program names for the identification of encoding formats is not desirable and is discouraged for future encodings.
8.4.2. Registration
The "HTTP Transfer Coding Registry" has been updated with the registrations below:
+------------+--------------------------------------+---------------+
| Name | Description | Reference |
+------------+--------------------------------------+---------------+
| chunked | Transfer in a series of chunks | Section 4.1 |
| compress | UNIX "compress" data format [Welch] | Section 4.2.1 |
| deflate | "deflate" compressed data | Section 4.2.2 |
| | ([RFC1951]) inside the "zlib" data | |
| | format ([RFC1950]) | |
| gzip | GZIP file format [RFC1952] | Section 4.2.3 |
| x-compress | Deprecated (alias for compress) | Section 4.2.1 |
| x-gzip | Deprecated (alias for gzip) | Section 4.2.3 |
+------------+--------------------------------------+---------------+
8.5. Content Coding Registration
IANA maintains the "HTTP Content Coding Registry" at http://www.iana.org/assignments/http-parameters.
The "HTTP Content Coding Registry" has been updated with the registrations below:
+------------+--------------------------------------+---------------+
| Name | Description | Reference |
+------------+--------------------------------------+---------------+
| compress | UNIX "compress" data format [Welch] | Section 4.2.1 |
| deflate | "deflate" compressed data | Section 4.2.2 |
| | ([RFC1951]) inside the "zlib" data | |
| | format ([RFC1950]) | |
| gzip | GZIP file format [RFC1952] | Section 4.2.3 |
| x-compress | Deprecated (alias for compress) | Section 4.2.1 |
| x-gzip | Deprecated (alias for gzip) | Section 4.2.3 |
+------------+--------------------------------------+---------------+
8.6. Upgrade Token Registry
The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" defines the namespace for protocol-name tokens used to identify protocols in the Upgrade header field. The registry is maintained at http://www.iana.org/assignments/http-upgrade-tokens.
8.6.1. Procedure
Each registered protocol name is associated with contact information and an optional set of specifications that details how the connection will be processed after it has been upgraded.
Registrations happen on a "First Come First Served" basis (see Section 4.1 of [RFC5226]) and are subject to the following rules:
-
A protocol-name token, once registered, stays registered forever.
-
The registration MUST name a responsible party for the registration.
-
The registration MUST name a point of contact.
-
The registration MAY name a set of specifications associated with that token. Such specifications need not be publicly available.
-
The registration SHOULD name a set of expected "protocol-version" tokens associated with that token at the time of registration.
-
The responsible party MAY change the registration at any time. The IANA will keep a record of all such changes, and make them available upon request.
-
The IESG MAY reassign responsibility for a protocol token. This will normally only be used in the case when a responsible party cannot be contacted.
This registration procedure for HTTP Upgrade Tokens replaces that previously defined in Section 7.2 of [RFC2817].
8.6.2. Upgrade Token Registration
The "HTTP" entry in the upgrade token registry has been updated with the registration below:
+-------+----------------------+----------------------+-------------+
| Value | Description | Expected Version | Reference |
| | | Tokens | |
+-------+----------------------+----------------------+-------------+
| HTTP | Hypertext Transfer | any DIGIT.DIGIT | Section 2.6 |
| | Protocol | (e.g, "2.0") | |
+-------+----------------------+----------------------+-------------+
The responsible party is: "IETF ([email protected]) - Internet Engineering Task Force".