![]() |
Il formato dei messaggi: MIMEDario De JudicibusTesti, immagini e suoni: tutto questo può essere incluso in un messaggio codificato MIME. Ma in che modo avviene, e come fare a orientarsi in mezzo alle centinaia di formati che esistono per ogni tipo di dato?Nel numero scorso abbiamo introdotto MIME illustrando le modalità che gli consentono di superare le limitazioni tipiche dei messaggi basati sullo standard RFC 822. Questo standard, infatti, permette di utilizzare per i messaggi solo lASCII-US a 7 bit. Tale codifica non solo esclude la possibilità di inserire oggetti binari o testi che richiedano alfabeti differenti da quello latino moderno, ma ha problemi a supportare anche semplicemente le vocali accentate o altri simboli utilizzati in molti alfabeti occidentali. Per ovviare a ciò MIME prevede la possibilità di strutturare il contenuto del messaggio in una o più sezioni, ognuna preceduta da una breve intestazione che servirà poi per la decodifica e linterpretazione del contenuto vero e proprio. Ogni sezione può quindi essere ricondotta a una serie di sequenze di caratteri ASCII-US le quali possono a loro volta essere trasmesse via TCP/IP senza violare le regole dellRFC 822. Come abbiamo descritto nella prima parte, MIME prevede cinque nuovi campi per lintestazione del messaggio, che estendono quelli già analizzati quando abbiamo parlato di RFC 822. Di questi solo il primo, e cioè quello relativo alla versione di MIME ( MIME-Version) va obbligatoriamente nellintestazione principale. Esso di fatto segnala che il messaggio è codificato MIME. Gli altri possono far parte sia dellintestazione principale sia di quelle specifiche di ogni sezione. Abbiamo anche aggiunto che il campo Content-Type serve a indicare il tipo di dati contenuti nella sezione, mentre il campo Content-Transfer-Encoding serve a specificare il meccanismo di codifica utilizzato.Gli ultimi due campi Vediamo ora gli ultimi due campi definiti dallo standard MIME base, come avviene la suddivisione in sezioni, e come si specifica il tipo di dati contenuti in ogni sezione. Il quarto campo definito in MIME è Content-ID, e permette di associare a ogni sezione un identificativo. Questo identificativo di sezione, costruito utilizzando le stesse regole usate per lidentificativo dei messaggi, è unico a livello globale. In altre parole, non possono esistere due sezioni in altrettanti differenti messaggi con lo stesso identificativo; ciò permette di poter fare riferimento a una sezione specifica di un determinato messaggio allinterno di un altro messaggio, un documento Html o un articolo di una conferenza elettronica.Il quinto e ultimo campo si chiama Content-Description; permette di associare a ogni sezione una breve descrizione. Il tipo di dato, infatti, spesso non è sufficiente a far capire che cosa in effetti una sezione contiene. Questo campo può, per esempio, servire a riportare il titolo di un brano musicale, lautore di una fotografia, o semplicemente lindicazione di eventuali diritti dautore.Esistono poi altri campi, definiti in vari RFC successivi, che aggiungono ulteriori possibilità allo standard MIME. Tra essi, il campo Content-Disposition viene utilizzato per fornire alcune informazioni per la gestione della sezione da parte dellapplicazione che visualizza la posta elettronica. Così unimmagine può essere visualizzata allinterno del messaggio, cioè in mezzo al testo (inline) oppure essere gestita come un allegato separato (attachment). Nel caso la sezione in questione possa essere salvata separatamente dal resto del messaggio, questo campo prevede anche un parametro che fornisce il nome del file nel quale memorizzare i dati.Facciamo un esempio. Supponiamo di voler allegare a un messaggio un documento Microsoft Word. Lintestazione della sezione relativa somiglierebbe più o meno a questa: Content-Type: application/msword; name="Cappuccetto Rosso.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="C_Rosso.doc" Content-ID: <5.9.23.19971011223409.0072016d@nowhere.it> Content-Description: La favola di Cappuccetto Rosso Ma quali sono i tipi supportati da MIME? Il documento originale prevede un certo numero di tipi e sottotipi, ma lo standard è stato pensato per essere estremamente flessibile; gli autori hanno ipotizzato fin dallinizio una crescita esponenziale di entrambi. È stato così definito un processo di registrazione basato sulla IANA (Internet Assigned Numbers Authority) per gestire le richieste di eventuali nuovi tipi e sottotipi. Fra i tipi base ci sono text, image, audio e video e message. Nel caso un tipo sia più complesso o richieda una gestione particolare, sono stati previsti anche i tipi application e multipart. Qualora poi la coppia tipo/sottotipo non dovesse bastare a capire come gestire i dati, lo standard prevede lutilizzo di uno o più parametri che possono anche essere differenti a seconda della tipologia del contenuto della sezione. Una lista dei principali tipi e delle raccomandazioni relative a come vadano gestite le sezioni è riportata in tabella 1.
Tabella 1 - Tipi e sottotipi standard Il tipo text/plain prevede un parametro che può servire a specificare lo schema di codifica dei caratteri, e precisamente charset. Per esempio Content-type: text/plain; charset=iso-8859-1 Nella tabella 2 abbiamo riportato la lista iniziale prevista dallo standard MIME per gli schemi di codifica dei caratteri. Altri schemi possono essere registrati sempre via IANA.
Tabella 2 - Schemi di codifica dei caratteri standard Il tipo application/octet-type prevede due parametri: type, che serve a fornire una descrizione leggibile del tipo di dati codificati, e padding, che conta quanti zeri sono stati aggiunti alla sequenza di bit per riportare il numero di bit ad un multiplo intero di otto. Per esempio: Content-type: application/octet-type; type="Vector map X3"; padding=6 Per quanto riguarda il tipo application/postscript e in generale per quanto riguarda tutti quei sottotipi di application che rappresentano veri e propri linguaggi di programmazione, è necessario definire tutta una serie di limitazioni e raccomandazioni per evitare che la semplice "lettura" di un messaggio faccia eseguire sulla macchina locale operazioni potenzialmente dannose o comunque non volute. Questo discorso ci porterebbe comunque troppo lontano.Una sezione dentro laltra E veniamo ora ai tipi multiparte, descriviamo cioè come un messaggio MIME può contenere più sezioni contemporaneamente. Una sezione multiparte non è altro che una sezione che contiene altre sezioni. Ogni sottosezione è preceduta da una stringa di caratteri chiamata separatore. Lultima sottosezione viene seguita da una stringa simile chiamata chiusura. Inoltre, ogni sottosezione è formata da unintestazione che però può contenere solo campi di tipo Content-*. Qualunque altro campo tipico dei messaggi RFC822 viene ignorato. In questo modo è possibile collocare allinterno di una sottosezione un messaggio RFC 822 senza il pericolo che lintestazione del messaggio venga a sua volta decodificata. La stringa di separazione è definita per mezzo del parametro boundary, che va definito nel campo Content-type della sezione principale. Una sezione multiparte può a sua volta contenere altre sezioni multiparte. Nel caso tuttavia di sezioni multiparte annidate, ogni sezione dovrà ovviamente avere un separatore differente.Un esempio di sezione multiparte è riportato nella tabella 3.
Tabella 3 - Esempio di sezione multiparte Come si vede, il separatore si ottiene facendo precedere la stringa specificata dal parametro boundary da due trattini o segni meno, mentre la chiusura è formata dalla stessa stringa a cui si aggiungono allinizio e alla fine i due segni meno. Inoltre, mentre ogni singola sottosezione può utilizzare un algoritmo di codifica differente, segnalato dalla presenza del campo Content-Transfer-Encoding, la sezione multiparte stessa accetta solo codifiche del tipo 7 bit, 8 bit e binary, come già accennato lo scorso numero. Infine, la stringa utilizzata per il separatore deve essere formata solamente da caratteri ASCII-US e nel caso contenga anche caratteri non alfanumerici si raccomanda di racchiuderla fra doppie virgolette al momento della definizione, ma non quando è usata come separatore o chiusura. I tipi di sezione multiparte Una sottosezione senza intestazione o della quale non viene comunque fornito il tipo, è di tipo text/plain nel caso di sezione multiparte mista (mixed) e di tipo message/rfc822 nel caso di sezione multiparte di tipo compendio (digest). Esistono, infatti, quattro tipi di sezioni multiparte.Il primo tipo è multipart/mixed, e va utilizzato quando le varie sottosezioni sono indipendenti e vanno assemblate seguendo un ordine ben definito. Il secondo è multipart/alternative. In questo caso tutte le sezioni rappresentano lo stesso oggetto o dato, ma codificato in modo differente. Il lettore del messaggio sceglierà quale dei vari formati andrà visualizzato in funzione delle capacità del sistema su cui viene letto. In genere il livello di dettaglio aumenta mano a mano che ci si sposta in avanti nella sezione multiparte. Per esempio, se la sezione contiene un testo, la prima sezione potrebbe essere in Latin-1, la seconda potrebbe essere in Html, la terza potrebbe contenere lo stesso testo come documento Corel WordPerfect. Se il messaggio è visualizzato su una piattaforma Windows 95 su cui non è stato installato un browser verrà visualizzato solo il testo ISO-8859, se è disponibile, per esempio, Netscape Communicator verrà visualizzata la pagina Html; se, infine, il tipo WPD è regolarmente registrato, verrà caricato il documento WordPerfect. Da notare che benché loggetto sia lo stesso, ogni rappresentazione può contenere un livello di dettaglio differente. Per esempio, la pagina Html può contenere alcune immagini grafiche e una musica di sottofondo, il documento WordPerfect contenere le immagini grafiche e una serie di annotazioni dellautore, mentre il testo semplice non può ovviamente includere alcun tipo di componente multimediale.Il terzo tipo è multipart/digest, e rappresenta un compendio di messaggi RFC 822. In effetti una sottosezione di questo tipo potrebbe anche non essere di tipo message/rfc822, ma la cosa è fortemente sconsigliata. In tal caso è bene utilizzare il tipo misto. Un esempio di compendio è riportato nella tabella 4.
Tabella 4 - Esempio di compendio
Risulta chiaro ora perché qualunque campo che non sia di tipo Content-* non venga interpretato allinterno di una sottosezione. Lultimo tipo è multipart/parallel, in cui le varie sezioni sono da considerarsi parti di un aggregato, e lordine in cui sono riportate non è significativo. Per esempio, un messaggio di questo tipo potrebbe contenere vari oggetti 3D, uno per sezione, da mostrare contemporaneamente in una scena. Da notare che il tipo message/rfc822 non necessariamente deve contenere messaggi conformi allo standard RFC 822. In realtà sezioni di questo tipo possono contenere sia articoli USENET sia generici messaggi codificati MIME. Oltre al sottotipo rfc822, il tipo message prevede anche il sottotipo partial. Questultimo è stato ideato nel caso di messaggi molto lunghi che può essere conveniente, o addirittura necessario, frammentare e spedire in più pezzi. Tuttavia, esiste una forte limitazione: i messaggi devono sempre essere codificati in ASCII-US. Non è infatti permesso codificare in alcun modo le sezioni di tipo message perché le intestazioni del messaggio devono sempre essere leggibili durante il trasporto. Questo vuol dire che una sezione di questo tipo va spedita così comè. Se tale sezione contenesse dati ad 8 bit e passasse attraverso una sottorete in grado di supportare solo dati a 7 bit una parte dellinformazione andrebbe persa, né si potrebbe richiedere al gateway in ingresso di codificare il messaggio base64 o quoted-printable per poi farlo ricostruire da quello in uscita. Tale codifica dovrebbe infatti avvenire per tutto il messaggio, non per i singoli frammenti; è cioè necessario che lintero messaggio venga prima ricostruito e poi convertito. Il problema è che non è detto che tutti i frammenti passino per lo stesso gateway o anche semplicemente attraversino la stessa sottorete. Da qui la suddetta limitazione. Un esempio di message/partial è mostrato nella tabella 5. Come si può vedere, i vari frammenti fanno riferimento allo stesso identificativo di messaggio.
Ogni messaggio parziale è inoltre identificato da un numero che rappresenta la posizione del frammento nel messaggio originale. Il numero totale di frammenti è obbligatorio solo nellultimo parziale, ma lo standard raccomanda di metterlo anche negli altri frammenti. Le regole di ricomposizione del messaggio originale sono un po complesse, e vanno oltre gli scopi di questo articolo. A ogni modo abbiamo riportato in grassetto, a titolo di esempio, le parti che verranno a ricomporre il messaggio originale. Le altre saranno scartate. Un altro importante sottotipo di message è external-body. In questo caso il corpo del messaggio non è incluso nello stesso ma semplicemente referenziato. I parametri del sottotipo servono a segnalare da dove il corpo vero e proprio può essere ottenuto. La tabella 6 ne mostra un esempio.
Tabella 6 - Messaggio con corpo esterno Come si può vedere, il corpo è stato sostituito da uno falso che in genere è ignorato, ma che può contenere informazioni ausiliarie per laccesso ai dati veri e propri. Lidentificativo del messaggio è in questo caso obbligatorio. Fra i parametri di questo sottotipo ci sono access-type ("FTP", "ANON-FTP", "TFTP", "LOCAL-FILE" e "MAIL-SERVER"), che indica il tipo di sorgente dove possono essere reperiti i dati, expiration, una data oltre la quale i dati potrebbero non essere più disponibili, e size, che dà le dimensioni dei dati in ottetti. Questultimo parametro ha lo scopo di fornire unutile indicazione per decidere se vale la pena o meno accedere al corpo del messaggio. Per esempio, se size è 100 MB una persona potrebbe porsi problemi prima di scaricare il messaggio. Per ogni tipo di accesso esistono poi ulteriori parametri che servono a indicare esattamente dove i dati sono stati memorizzati (sito, Url, directory, filename). Per chi ne volesse sapere di più, al momento gli RFC relativi a MIME sono quelli dal 2045 al 2049 inclusi. A ogni modo, la prossima volta che vi arriva un messaggio un po complesso in casella postale, provate a dare unocchiata al testo originale. Può essere unesperienza interessante |