8. IANA-Erwägungen
8.1. Registrierung von Header-Feldern
HTTP-Header-Felder werden im Register "Message Headers" registriert, das unter http://www.iana.org/assignments/message-headers/ gepflegt wird.
Dieses Dokument definiert die folgenden HTTP-Header-Felder, daher wurde das Register "Permanent Message Header Field Names" entsprechend aktualisiert (siehe [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 |
+-------------------+----------+----------+---------------+
Darüber hinaus wurde der Header-Feldname "Close" als "reserved" registriert, da die Verwendung dieses Namens als HTTP-Header-Feld mit der "close"-Verbindungsoption des Header-Felds Connection (Abschnitt 6.1) in Konflikt geraten könnte.
+-------------------+----------+----------+-------------+
| Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+-------------+
| Close | http | reserved | Section 8.1 |
+-------------------+----------+----------+-------------+
Der Change Controller ist: "IETF ([email protected]) - Internet Engineering Task Force".
8.2. Registrierung von URI-Schemata
IANA pflegt das Register der URI-Schemata [BCP115] unter http://www.iana.org/assignments/uri-schemes/.
Dieses Dokument definiert die folgenden URI-Schemata, daher wurde das Register "Permanent URI Schemes" entsprechend aktualisiert.
+------------+------------------------------------+---------------+
| URI Scheme | Description | Reference |
+------------+------------------------------------+---------------+
| http | Hypertext Transfer Protocol | Section 2.7.1 |
| https | Hypertext Transfer Protocol Secure | Section 2.7.2 |
+------------+------------------------------------+---------------+
8.3. Registrierung von Internet-Medientypen
IANA pflegt das Register der Internet-Medientypen [BCP13] unter http://www.iana.org/assignments/media-types.
Dieses Dokument dient als Spezifikation für die Internet-Medientypen "message/http" und "application/http". Das Folgende wurde bei IANA registriert.
8.3.1. Internet-Medientyp message/http
Der Typ message/http kann verwendet werden, um eine einzelne HTTP-Anfrage- oder -Antwortnachricht einzuschließen, vorausgesetzt, sie befolgt die MIME-Beschränkungen für alle "message"-Typen hinsichtlich Zeilenlänge und Kodierungen.
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-Medientyp application/http
Der Typ application/http kann verwendet werden, um eine Pipeline aus einer oder mehreren HTTP-Anfrage- oder -Antwortnachrichten (nicht gemischt) einzuschließen.
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. Register für Transferkodierungen
Das "HTTP Transfer Coding Registry" definiert den Namensraum für Namen von Transferkodierungen. Es wird unter http://www.iana.org/assignments/http-parameters gepflegt.
8.4.1. Verfahren
Registrierungen MÜSSEN die folgenden Felder enthalten:
-
Name
-
Description
-
Pointer to specification text
Namen von Transferkodierungen dürfen NICHT mit Namen von Inhaltskodierungen überlappen (Abschnitt 3.1.2.1 von [RFC7231]), es sei denn, die Kodierungstransformation ist identisch, wie es bei den in Abschnitt 4.2 definierten Kompressionskodierungen der Fall ist.
Werte, die diesem Namensraum hinzugefügt werden sollen, erfordern IETF Review (siehe Abschnitt 4.1 von [RFC5226]) und MÜSSEN dem in dieser Spezifikation definierten Zweck der Transferkodierung entsprechen.
Die Verwendung von Programmnamen zur Identifizierung von Kodierungsformaten ist nicht wünschenswert und wird für zukünftige Kodierungen nicht empfohlen.
8.4.2. Registrierung
Das "HTTP Transfer Coding Registry" wurde mit den folgenden Registrierungen aktualisiert:
+------------+--------------------------------------+---------------+
| 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. Registrierung von Inhaltskodierungen
IANA pflegt das "HTTP Content Coding Registry" unter http://www.iana.org/assignments/http-parameters.
Das "HTTP Content Coding Registry" wurde mit den folgenden Registrierungen aktualisiert:
+------------+--------------------------------------+---------------+
| 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. Register für Upgrade-Token
Das "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" definiert den Namensraum für protocol-name-Token, die zur Identifizierung von Protokollen im Header-Feld Upgrade verwendet werden. Das Register wird unter http://www.iana.org/assignments/http-upgrade-tokens gepflegt.
8.6.1. Verfahren
Jeder registrierte Protokollname ist mit Kontaktinformationen und einer optionalen Menge von Spezifikationen verbunden, die detailliert beschreiben, wie die Verbindung nach dem Upgrade verarbeitet wird.
Registrierungen erfolgen nach dem Prinzip "First Come First Served" (siehe Abschnitt 4.1 von [RFC5226]) und unterliegen den folgenden Regeln:
-
Ein protocol-name-Token bleibt, einmal registriert, für immer registriert.
-
Die Registrierung MUSS eine verantwortliche Partei für die Registrierung benennen.
-
Die Registrierung MUSS einen Ansprechpartner (point of contact) benennen.
-
Die Registrierung KANN eine Menge von Spezifikationen benennen, die mit diesem Token verbunden sind. Solche Spezifikationen müssen nicht öffentlich verfügbar sein.
-
Die Registrierung SOLLTE zum Zeitpunkt der Registrierung eine Menge erwarteter "protocol-version"-Token benennen, die mit diesem Token verbunden sind.
-
Die verantwortliche Partei KANN die Registrierung jederzeit ändern. IANA wird ein Verzeichnis aller solcher Änderungen führen und sie auf Anfrage verfügbar machen.
-
Die IESG KANN die Verantwortung für ein Protokoll-Token neu zuweisen. Dies wird normalerweise nur dann verwendet, wenn eine verantwortliche Partei nicht kontaktiert werden kann.
Dieses Registrierungsverfahren für HTTP Upgrade Tokens ersetzt das zuvor in Abschnitt 7.2 von [RFC2817] definierte.
8.6.2. Registrierung von Upgrade-Token
Der Eintrag "HTTP" im Upgrade-Token-Register wurde mit der folgenden Registrierung aktualisiert:
+-------+----------------------+----------------------+-------------+
| Value | Description | Expected Version | Reference |
| | | Tokens | |
+-------+----------------------+----------------------+-------------+
| HTTP | Hypertext Transfer | any DIGIT.DIGIT | Section 2.6 |
| | Protocol | (e.g, "2.0") | |
+-------+----------------------+----------------------+-------------+
Die verantwortliche Partei ist: "IETF ([email protected]) - Internet Engineering Task Force".