メインコンテンツまでスキップ

8. IANA に関する考慮事項

8.1. ヘッダーフィールドの登録​

HTTP ヘッダーフィールドは、http://www.iana.org/assignments/message-headers/ で維持されている "Message Headers" レジストリに登録されています。

本文書は以下の HTTP ヘッダーフィールドを定義しているため、"Permanent Message Header Field Names" レジストリはそれに応じて更新されました ([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 |
+-------------------+----------+----------+---------------+

さらに、ヘッダーフィールド名 "Close" は "reserved" として登録されました。その名前を HTTP ヘッダーフィールドとして使用すると、Connection ヘッダーフィールドの "close" 接続オプション (セクション 6.1) と競合する可能性があるためです。

+-------------------+----------+----------+-------------+
| Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+-------------+
| Close | http | reserved | Section 8.1 |
+-------------------+----------+----------+-------------+

変更管理者は: "IETF ([email protected]) - Internet Engineering Task Force" です。

8.2. URI スキームの登録​

IANA は、http://www.iana.org/assignments/uri-schemes/ で URI スキームのレジストリ [BCP115] を維持しています。

本文書は以下の URI スキームを定義しているため、"Permanent URI Schemes" レジストリはそれに応じて更新されました。

+------------+------------------------------------+---------------+
| URI Scheme | Description | Reference |
+------------+------------------------------------+---------------+
| http | Hypertext Transfer Protocol | Section 2.7.1 |
| https | Hypertext Transfer Protocol Secure | Section 2.7.2 |
+------------+------------------------------------+---------------+

8.3. インターネットメディアタイプの登録​

IANA は、http://www.iana.org/assignments/media-types でインターネットメディアタイプのレジストリ [BCP13] を維持しています。

本文書は、インターネットメディアタイプ "message/http" および "application/http" の仕様として機能します。以下が IANA に登録されました。

8.3.1. インターネットメディアタイプ message/http​

message/http タイプは、すべての "message" タイプに関する MIME の行長とエンコーディングに関する制限に従うことを条件として、単一の HTTP リクエストまたはレスポンスメッセージを内包するために使用できます。

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. インターネットメディアタイプ application/http​

application/http タイプは、1 つ以上の HTTP リクエストまたはレスポンスメッセージ (混在しない) のパイプラインを内包するために使用できます。

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. 転送コーディングレジストリ​

"HTTP Transfer Coding Registry" は、転送コーディング名の名前空間を定義します。それは http://www.iana.org/assignments/http-parameters で維持されています。

8.4.1. 手順​

登録は以下のフィールドを含まなければなりません (MUST):

  • Name

  • Description

  • Pointer to specification text

転送コーディングの名前は、エンコーディング変換が同一である場合 (セクション 4.2 で定義される圧縮コーディングの場合のように) を除き、コンテンツコーディングの名前と重複してはなりません (MUST NOT) ([RFC7231] のセクション 3.1.2.1)。

この名前空間に追加される値は、IETF Review を必要とし ([RFC5226] のセクション 4.1 を参照してください)、本仕様で定義された転送コーディングの目的に適合しなければなりません (MUST)。

エンコーディング形式の識別にプログラム名を使用することは望ましくなく、将来のエンコーディングに対しては推奨されません。

8.4.2. 登録​

"HTTP Transfer Coding Registry" は、以下の登録で更新されました:

+------------+--------------------------------------+---------------+
| 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. コンテンツコーディングの登録​

IANA は、http://www.iana.org/assignments/http-parameters で "HTTP Content Coding Registry" を維持しています。

"HTTP Content Coding Registry" は、以下の登録で更新されました:

+------------+--------------------------------------+---------------+
| 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 トークンレジストリ​

"Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" は、Upgrade ヘッダーフィールドでプロトコルを識別するために使用される protocol-name トークンの名前空間を定義します。レジストリは http://www.iana.org/assignments/http-upgrade-tokens で維持されています。

8.6.1. 手順​

登録された各プロトコル名は、連絡先情報と、接続がアップグレードされた後にどのように処理されるかを詳述する任意の仕様群に関連付けられます。

登録は "First Come First Served" ベースで行われ ([RFC5226] のセクション 4.1 を参照してください)、以下の規則に従います:

  1. protocol-name トークンは、一度登録されると、永久に登録されたままです。

  2. 登録は、その登録の責任者を指名しなければなりません (MUST)。

  3. 登録は、連絡窓口を指名しなければなりません (MUST)。

  4. 登録は、そのトークンに関連付けられた仕様群を指名してもかまいません (MAY)。そのような仕様は公開されている必要はありません。

  5. 登録は、登録時にそのトークンに関連付けられた、期待される "protocol-version" トークンの集合を指名すべきです (SHOULD)。

  6. 責任者は、いつでも登録を変更してもかまいません (MAY)。IANA はそのようなすべての変更の記録を保持し、要求に応じてそれらを利用可能にします。

  7. IESG は、プロトコルトークンの責任を再割り当てしてもかまいません (MAY)。これは通常、責任者に連絡できない場合にのみ使用されます。

この HTTP Upgrade Token の登録手順は、以前に [RFC2817] のセクション 7.2 で定義されたものを置き換えます。

8.6.2. Upgrade トークンの登録​

アップグレードトークンレジストリの "HTTP" エントリは、以下の登録で更新されました:

+-------+----------------------+----------------------+-------------+
| Value | Description | Expected Version | Reference |
| | | Tokens | |
+-------+----------------------+----------------------+-------------+
| HTTP | Hypertext Transfer | any DIGIT.DIGIT | Section 2.6 |
| | Protocol | (e.g, "2.0") | |
+-------+----------------------+----------------------+-------------+

責任者は: "IETF ([email protected]) - Internet Engineering Task Force" です。