8. Considérations IANA
8.1. Enregistrement des champs d'en-tête
Les champs d'en-tête HTTP sont enregistrés dans le registre « Message Headers » maintenu à l'adresse http://www.iana.org/assignments/message-headers/.
Ce document définit les champs d'en-tête HTTP suivants, de sorte que le registre « Permanent Message Header Field Names » a été mis à jour en conséquence (voir [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 |
+-------------------+----------+----------+---------------+
En outre, le field-name « Close » a été enregistré comme « reserved », car l'utilisation de ce nom comme champ d'en-tête HTTP pourrait entrer en conflit avec l'option de connexion « close » du champ d'en-tête Connection (Section 6.1).
+-------------------+----------+----------+-------------+
| Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+-------------+
| Close | http | reserved | Section 8.1 |
+-------------------+----------+----------+-------------+
Le contrôleur de modification est : « IETF ([email protected]) - Internet Engineering Task Force ».
8.2. Enregistrement des schémas d'URI
L'IANA maintient le registre des schémas d'URI [BCP115] à l'adresse http://www.iana.org/assignments/uri-schemes/.
Ce document définit les schémas d'URI suivants, de sorte que le registre « Permanent URI Schemes » a été mis à jour en conséquence.
+------------+------------------------------------+---------------+
| URI Scheme | Description | Reference |
+------------+------------------------------------+---------------+
| http | Hypertext Transfer Protocol | Section 2.7.1 |
| https | Hypertext Transfer Protocol Secure | Section 2.7.2 |
+------------+------------------------------------+---------------+
8.3. Enregistrement des types de médias Internet
L'IANA maintient le registre des types de médias Internet [BCP13] à l'adresse http://www.iana.org/assignments/media-types.
Ce document sert de spécification pour les types de médias Internet « message/http » et « application/http ». Ce qui suit a été enregistré auprès de l'IANA.
8.3.1. Type de média Internet message/http
Le type message/http peut être utilisé pour encapsuler un seul message de requête ou de réponse HTTP, à condition qu'il respecte les restrictions MIME applicables à tous les types « message » en matière de longueur de ligne et d'encodages.
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. Type de média Internet application/http
Le type application/http peut être utilisé pour encapsuler un pipeline d'un ou plusieurs messages de requête ou de réponse HTTP (non entremêlés).
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. Registre des codages de transfert
Le registre « HTTP Transfer Coding Registry » définit l'espace de noms des noms de codage de transfert. Il est maintenu à l'adresse http://www.iana.org/assignments/http-parameters.
8.4.1. Procédure
Les enregistrements MUST inclure les champs suivants :
-
Name
-
Description
-
Pointer to specification text
Les noms des codages de transfert MUST NOT chevaucher les noms des codages de contenu (Section 3.1.2.1 de [RFC7231]), sauf si la transformation d'encodage est identique, comme c'est le cas pour les codages de compression définis à la Section 4.2.
Les valeurs à ajouter à cet espace de noms nécessitent un IETF Review (voir la Section 4.1 de [RFC5226]) et MUST être conformes à l'objet du codage de transfert défini dans cette spécification.
L'utilisation de noms de programmes pour identifier des formats d'encodage n'est pas souhaitable et est déconseillée pour les encodages futurs.
8.4.2. Enregistrement
Le registre « HTTP Transfer Coding Registry » a été mis à jour avec les enregistrements ci-dessous :
+------------+--------------------------------------+---------------+
| 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. Enregistrement des codages de contenu
L'IANA maintient le registre « HTTP Content Coding Registry » à l'adresse http://www.iana.org/assignments/http-parameters.
Le registre « HTTP Content Coding Registry » a été mis à jour avec les enregistrements ci-dessous :
+------------+--------------------------------------+---------------+
| 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. Registre des jetons Upgrade
Le registre « Hypertext Transfer Protocol (HTTP) Upgrade Token Registry » définit l'espace de noms des jetons protocol-name utilisés pour identifier les protocoles dans le champ d'en-tête Upgrade. Le registre est maintenu à l'adresse http://www.iana.org/assignments/http-upgrade-tokens.
8.6.1. Procédure
Chaque nom de protocole enregistré est associé à des informations de contact et à un ensemble facultatif de spécifications détaillant la façon dont la connexion sera traitée après son basculement.
Les enregistrements se font sur la base « First Come First Served » (voir la Section 4.1 de [RFC5226]) et sont soumis aux règles suivantes :
-
Un jeton protocol-name, une fois enregistré, reste enregistré pour toujours.
-
L'enregistrement MUST nommer une partie responsable de l'enregistrement.
-
L'enregistrement MUST nommer un point de contact.
-
L'enregistrement MAY nommer un ensemble de spécifications associées à ce jeton. Ces spécifications n'ont pas besoin d'être accessibles publiquement.
-
L'enregistrement SHOULD nommer un ensemble de jetons « protocol-version » attendus, associés à ce jeton au moment de l'enregistrement.
-
La partie responsable MAY modifier l'enregistrement à tout moment. L'IANA conservera la trace de toutes ces modifications et les mettra à disposition sur demande.
-
L'IESG MAY réattribuer la responsabilité d'un jeton de protocole. Cela ne s'utilise normalement que dans le cas où une partie responsable ne peut pas être contactée.
Cette procédure d'enregistrement des jetons HTTP Upgrade remplace celle précédemment définie à la Section 7.2 de [RFC2817].
8.6.2. Enregistrement des jetons Upgrade
L'entrée « HTTP » du registre des jetons Upgrade a été mise à jour avec l'enregistrement ci-dessous :
+-------+----------------------+----------------------+-------------+
| Value | Description | Expected Version | Reference |
| | | Tokens | |
+-------+----------------------+----------------------+-------------+
| HTTP | Hypertext Transfer | any DIGIT.DIGIT | Section 2.6 |
| | Protocol | (e.g, "2.0") | |
+-------+----------------------+----------------------+-------------+
La partie responsable est : « IETF ([email protected]) - Internet Engineering Task Force ».