4. Campo di Intestazione MIME-Version (MIME-Version Header Field)
Dalla pubblicazione della RFC 822 nel 1982, c'è stato davvero solo uno standard di formato per i messaggi Internet, e c'è stata poca necessità percepita di dichiarare lo standard di formato in uso. Questo documento è una specifica indipendente che completa la RFC 822. Sebbene le estensioni in questo documento siano state definite in modo compatibile con la RFC 822, ci sono ancora circostanze in cui potrebbe essere desiderabile per un agente di elaborazione della posta sapere se un messaggio è stato composto tenendo presente il nuovo standard.
Pertanto, questo documento definisce un nuovo campo di intestazione, "MIME-Version", che deve essere usato per dichiarare la versione dello standard di formato del corpo del messaggio Internet in uso.
I messaggi composti in conformità con questo documento devono (MUST) includere tale campo di intestazione, con il seguente testo verbatim:
MIME-Version: 1.0
La presenza di questo campo di intestazione è un'asserzione che il messaggio è stato composto in conformità con questo documento.
Poiché è possibile che un futuro documento possa estendere nuovamente lo standard di formato del messaggio, viene fornito un BNF formale per il contenuto del campo MIME-Version:
version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
Pertanto, i futuri specificatori di formato, che potrebbero sostituire o estendere "1.0", sono vincolati a essere due campi interi, separati da un punto. Se viene ricevuto un messaggio con un valore MIME-Version diverso da "1.0", non si può presumere che sia conforme a questo documento.
Si noti che il campo di intestazione MIME-Version è richiesto (required) al livello superiore di un messaggio. Non è richiesto per ogni parte del corpo di un'entità multipart. È richiesto per le intestazioni incorporate di un corpo di tipo "message/rfc822" o "message/partial" se e solo se il messaggio incorporato stesso è dichiarato conforme a MIME.
Non è possibile specificare completamente come un lettore di posta conforme a MIME come definito in questo documento dovrebbe trattare un messaggio che potrebbe arrivare in futuro con un valore di MIME-Version diverso da "1.0".
Vale anche la pena notare che il controllo delle versioni per tipi di media specifici non viene eseguito utilizzando il meccanismo MIME-Version. In particolare, alcuni formati (come application/postscript) hanno convenzioni di numerazione delle versioni che sono interne al formato del media. Dove tali convenzioni esistono, MIME non le sostituisce. Dove non esistono, un tipo di media MIME potrebbe usare un parametro "version" nel campo Content-Type se necessario.
Nota per gli Implementatori (Implementor's Note)
Quando si controllano i valori MIME-Version, tutte le stringhe di commento RFC 822 presenti devono (MUST) essere ignorate. In particolare, i seguenti quattro campi MIME-Version sono equivalenti:
MIME-Version: 1.0
MIME-Version: 1.0 (produced by MetaSend Vx.x)
MIME-Version: (produced by MetaSend Vx.x) 1.0
MIME-Version: 1.(produced by MetaSend Vx.x)0
In assenza di un campo MIME-Version, un agente utente di posta ricevente (che sia conforme ai requisiti MIME o meno) può opzionalmente scegliere di interpretare il corpo del messaggio secondo convenzioni locali. Molte di tali convenzioni sono attualmente in uso e si dovrebbe notare che in pratica i messaggi non-MIME possono contenere praticamente qualsiasi cosa.
È impossibile essere certi che un messaggio di posta non-MIME sia effettivamente testo semplice nel set di caratteri US-ASCII, poiché potrebbe benissimo essere un messaggio che, utilizzando un insieme di convenzioni locali non standard che precedono MIME, include testo in un altro set di caratteri o dati non testuali presentati in un modo che non può essere riconosciuto automaticamente (ad esempio, un file tar UNIX compresso e uuencodato).
Punti Chiave:
- Tutti i messaggi MIME devono (MUST) includere un'intestazione
MIME-Version: 1.0 - Il formato della versione è
maggiore.minore(ad esempio, 1.0) - Richiesto solo al livello superiore del messaggio, non nelle parti del corpo
- I commenti RFC 822 devono essere ignorati
- I messaggi non-MIME possono usare convenzioni locali