1. Introduzione (Introduction)

Dalla sua pubblicazione nel 1982, la RFC 822 ha definito il formato standard dei messaggi di posta testuali su Internet. Il suo successo è stato tale che il formato RFC 822 è stato adottato, interamente o parzialmente, ben oltre i confini di Internet e del trasporto SMTP Internet definito dalla RFC 821. Man mano che questo formato è stato ampiamente adottato, una serie di limitazioni si sono dimostrate sempre più restrittive per la comunità degli utenti.

La RFC 822 era destinata a specificare un formato per i messaggi di testo. Come tale, i messaggi non testuali, come i messaggi multimediali che potrebbero includere audio o immagini, semplicemente non vengono menzionati. Anche nel caso del testo, tuttavia, la RFC 822 è inadeguata per le esigenze degli utenti di posta le cui lingue richiedono l'uso di set di caratteri più ricchi dell'US-ASCII. Poiché la RFC 822 non specifica meccanismi per la posta contenente audio, video, testo in lingua asiatica o persino testo nella maggior parte delle lingue europee, sono necessarie specifiche aggiuntive.

Una delle limitazioni notevoli del sistema di posta di base RFC 821/822 è che limitano il contenuto dei messaggi di posta elettronica a righe relativamente brevi (ad es., 1000 caratteri o meno [RFC-821]) di US-ASCII a 7 bit. Questo costringe gli utenti a convertire qualsiasi dato non testuale che desiderano inviare in byte a sette bit rappresentabili come caratteri US-ASCII stampabili prima di invocare un UA di posta locale (User Agent, un programma con cui gli utenti umani inviano e ricevono posta). Esempi di tali codifiche attualmente utilizzate in Internet includono esadecimale puro, uuencode, lo schema base 64 3-in-4 specificato nella RFC 1421, l'Andrew Toolkit Representation [ATK] e molti altri.

Le limitazioni del formato di posta RFC 822 diventano ancora più evidenti quando vengono progettati gateway per consentire lo scambio di messaggi di posta tra host RFC 822 e host X.400. X.400 [X400] specifica meccanismi per l'inclusione di materiale non testuale all'interno dei messaggi di posta elettronica. Gli standard attuali per mappare i messaggi X.400 ai messaggi RFC 822 specificano che il materiale non testuale X.400 deve (must) essere convertito (non codificato) in formato IA5Text, o essere scartato, notificando all'utente RFC 822 che lo scarto è avvenuto. Questo è chiaramente indesiderabile, poiché le informazioni che un utente potrebbe voler ricevere vengono perse. Anche se un agente utente potrebbe non avere la capacità di elaborare il materiale non testuale, l'utente potrebbe avere un meccanismo esterno all'UA che può estrarre informazioni utili dal materiale. Inoltre, non tiene conto del fatto che il messaggio possa eventualmente essere reindirizzato in un sistema di gestione dei messaggi X.400 (cioè, il messaggio X.400 viene « tunnelizzato » attraverso la posta Internet), dove le informazioni non testuali diventerebbero sicuramente utili di nuovo.

Questo documento descrive diversi meccanismi che si combinano per risolvere la maggior parte di questi problemi senza introdurre gravi incompatibilità con il mondo esistente della posta RFC 822. In particolare, descrive:

Un campo di intestazione MIME-Version, che utilizza un numero di versione per dichiarare che un messaggio è conforme a MIME e consente agli agenti di elaborazione della posta di distinguere tra tali messaggi e quelli generati da software più vecchio o non conforme, che si presume manchi di tale campo.
Un campo di intestazione Content-Type, generalizzato dalla RFC 1049, che può essere utilizzato per specificare il tipo di media e il sottotipo di dati nel corpo di un messaggio e per specificare completamente la rappresentazione nativa (forma canonica) di tali dati.
Un campo di intestazione Content-Transfer-Encoding, che può essere utilizzato per specificare sia la trasformazione di codifica che è stata applicata al corpo sia il dominio del risultato. Le trasformazioni di codifica diverse dalla trasformazione di identità vengono solitamente applicate ai dati per consentire loro di passare attraverso meccanismi di trasporto della posta che potrebbero avere limitazioni di dati o set di caratteri.
Due campi di intestazione aggiuntivi, Content-ID e Content-Description, che possono essere utilizzati per descrivere ulteriormente i dati in un corpo.

Tutti i campi di intestazione definiti in questo documento sono soggetti alle regole sintattiche generali per i campi di intestazione specificate nella RFC 822. In particolare, tutti questi campi di intestazione tranne Content-Disposition possono includere commenti RFC 822, che non hanno contenuto semantico e dovrebbero (should) essere ignorati durante l'elaborazione MIME.

Infine, per specificare e promuovere l'interoperabilità, la RFC 2049 fornisce una dichiarazione di applicabilità di base per un sottoinsieme dei meccanismi di cui sopra che definisce un livello « conforme » minimo per il documento corrente.

NOTA STORICA: Alcuni dei meccanismi descritti in questo insieme di documenti possono sembrare piuttosto strani o persino barocchi alla prima lettura. È importante notare che la compatibilità con gli standard esistenti E la robustezza attraverso la pratica esistente erano due delle priorità più alte del gruppo di lavoro che ha sviluppato questo insieme di documenti. In particolare, la compatibilità è sempre stata preferita all'eleganza.

Si prega di fare riferimento all'edizione corrente degli « Internet Official Protocol Standards » per lo stato di standardizzazione e lo status di questo protocollo. La RFC 822 e lo STD 3, la RFC 1123 forniscono anche un importante background per MIME poiché nessuna implementazione MIME conforme può violarli. Inoltre, diversi altri documenti RFC informativi sono anche preziosi per gli implementatori MIME, in particolare la RFC 1344, la RFC 1345 e la RFC 1524.

Terminologia:

User Agent (UA) (Agente Utente): Un programma con cui gli utenti umani inviano e ricevono posta
MIME: Multipurpose Internet Mail Extensions (Estensioni di Posta Internet Multiuso)
forma canonica: La rappresentazione nativa dei dati
tipo di media: Il tipo generale di dati
sottotipo: Un formato specifico all'interno di un tipo di media
trasformazione di codifica: Una conversione applicata ai dati per la trasmissione

Concetti Chiave:

Limitazioni della RFC 822: Supporta solo testo US-ASCII a 7 bit
Obiettivi MIME: Supportare multimedia, più set di caratteri, contenuto non testuale
Compatibilità prima: Il design MIME mantiene la compatibilità all'indietro con la RFC 822