8. Considerazioni IANA
8.1. Registrazione dei campi di intestazione
I campi di intestazione HTTP sono registrati nel registro "Message Headers" mantenuto su http://www.iana.org/assignments/message-headers/.
Questo documento definisce i seguenti campi di intestazione HTTP, quindi il registro "Permanent Message Header Field Names" è stato aggiornato di conseguenza (vedere [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 |
+-------------------+----------+----------+---------------+
Inoltre, il field-name di intestazione "Close" è stato registrato come "reserved", poiché l'uso di quel nome come campo di intestazione HTTP potrebbe entrare in conflitto con l'opzione di connessione "close" del campo di intestazione Connection (Sezione 6.1).
+-------------------+----------+----------+-------------+
| Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+-------------+
| Close | http | reserved | Section 8.1 |
+-------------------+----------+----------+-------------+
Il change controller è: "IETF ([email protected]) - Internet Engineering Task Force".
8.2. Registrazione degli schemi URI
IANA mantiene il registro degli URI Schemes [BCP115] su http://www.iana.org/assignments/uri-schemes/.
Questo documento definisce i seguenti schemi URI, quindi il registro "Permanent URI Schemes" è stato aggiornato di conseguenza.
+------------+------------------------------------+---------------+
| URI Scheme | Description | Reference |
+------------+------------------------------------+---------------+
| http | Hypertext Transfer Protocol | Section 2.7.1 |
| https | Hypertext Transfer Protocol Secure | Section 2.7.2 |
+------------+------------------------------------+---------------+
8.3. Registrazione dei tipi di media Internet
IANA mantiene il registro dei tipi di media Internet [BCP13] su http://www.iana.org/assignments/media-types.
Questo documento funge da specifica per i tipi di media Internet "message/http" e "application/http". Quanto segue è stato registrato presso l'IANA.
8.3.1. Tipo di media Internet message/http
Il tipo message/http può essere usato per racchiudere un singolo messaggio di richiesta o risposta HTTP, purché rispetti le restrizioni MIME per tutti i tipi "message" riguardo alla lunghezza delle righe e alle codifiche.
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. Tipo di media Internet application/http
Il tipo application/http può essere usato per racchiudere una pipeline di uno o più messaggi di richiesta o risposta HTTP (non mescolati tra loro).
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. Registro delle transfer coding
Il registro "HTTP Transfer Coding Registry" definisce lo spazio dei nomi per i nomi delle transfer coding. È mantenuto su http://www.iana.org/assignments/http-parameters.
8.4.1. Procedura
Le registrazioni MUST includere i seguenti campi:
-
Name
-
Description
-
Pointer to specification text
I nomi delle transfer coding MUST NOT sovrapporsi ai nomi delle content coding (Sezione 3.1.2.1 di [RFC7231]), a meno che la trasformazione di codifica non sia identica, come nel caso delle codifiche di compressione definite nella Sezione 4.2.
I valori da aggiungere a questo spazio dei nomi richiedono IETF Review (vedere la Sezione 4.1 di [RFC5226]) e MUST essere conformi allo scopo della transfer coding definito in questa specifica.
L'uso di nomi di programmi per l'identificazione dei formati di codifica non è desiderabile ed è sconsigliato per le codifiche future.
8.4.2. Registrazione
Il registro "HTTP Transfer Coding Registry" è stato aggiornato con le registrazioni riportate di seguito:
+------------+--------------------------------------+---------------+
| 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. Registrazione delle content coding
IANA mantiene il registro "HTTP Content Coding Registry" su http://www.iana.org/assignments/http-parameters.
Il registro "HTTP Content Coding Registry" è stato aggiornato con le registrazioni riportate di seguito:
+------------+--------------------------------------+---------------+
| 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. Registro dei token di upgrade
Il registro "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" definisce lo spazio dei nomi per i token protocol-name usati per identificare i protocolli nel campo di intestazione Upgrade. Il registro è mantenuto su http://www.iana.org/assignments/http-upgrade-tokens.
8.6.1. Procedura
Ogni nome di protocollo registrato è associato a informazioni di contatto e a un insieme opzionale di specifiche che descrive come verrà elaborata la connessione dopo l'aggiornamento.
Le registrazioni avvengono su base "First Come First Served" (vedere la Sezione 4.1 di [RFC5226]) e sono soggette alle seguenti regole:
-
Un token protocol-name, una volta registrato, resta registrato per sempre.
-
La registrazione MUST indicare una parte responsabile della registrazione.
-
La registrazione MUST indicare un punto di contatto.
-
La registrazione MAY indicare un insieme di specifiche associate a quel token. Tali specifiche non devono necessariamente essere disponibili pubblicamente.
-
La registrazione SHOULD indicare un insieme di token "protocol-version" attesi associati a quel token al momento della registrazione.
-
La parte responsabile MAY modificare la registrazione in qualsiasi momento. L'IANA conserverà un registro di tutte queste modifiche e le renderà disponibili su richiesta.
-
L'IESG MAY riassegnare la responsabilità di un token di protocollo. Ciò verrà normalmente usato solo nel caso in cui non sia possibile contattare una parte responsabile.
Questa procedura di registrazione per gli HTTP Upgrade Tokens sostituisce quella definita in precedenza nella Sezione 7.2 di [RFC2817].
8.6.2. Registrazione dei token di upgrade
La voce "HTTP" nel registro dei token di upgrade è stata aggiornata con la registrazione riportata di seguito:
+-------+----------------------+----------------------+-------------+
| Value | Description | Expected Version | Reference |
| | | Tokens | |
+-------+----------------------+----------------------+-------------+
| HTTP | Hypertext Transfer | any DIGIT.DIGIT | Section 2.6 |
| | Protocol | (e.g, "2.0") | |
+-------+----------------------+----------------------+-------------+
La parte responsabile è: "IETF ([email protected]) - Internet Engineering Task Force".