2. Analisi lessicale dei messaggi
2.1. Descrizione generale
Al livello più elementare, un messaggio è una serie di caratteri. Un messaggio conforme a questa specifica è composto da caratteri con valori nell'intervallo da 1 a 127, interpretati come caratteri US-ASCII [ANSI.X3-4.1986]. Per brevità, questo documento talvolta si riferisce a questo intervallo di caratteri semplicemente come "caratteri US-ASCII".
Nota: Questo documento specifica che i messaggi sono composti da caratteri nell'intervallo US-ASCII da 1 a 127. Esistono altri documenti, in particolare la serie di documenti MIME ([RFC2045], [RFC2046], [RFC2047], [RFC2049], [RFC4288], [RFC4289]), che estendono questa specifica per consentire valori al di fuori di tale intervallo. La discussione di tali meccanismi non rientra nell'ambito di questa specifica.
I messaggi sono divisi in righe di caratteri. Una riga è una serie di caratteri delimitata dai due caratteri ritorno carrello (carriage return) e avanzamento di riga (line feed); vale a dire, il carattere di ritorno carrello (CR) (valore ASCII 13) seguito immediatamente dal carattere di avanzamento di riga (LF) (valore ASCII 10). (La coppia ritorno carrello/avanzamento di riga è solitamente scritta in questo documento come "CRLF".) Un messaggio è costituito da campi di intestazione (collettivamente chiamati "sezione di intestazione del messaggio") seguiti, opzionalmente, da un corpo. La sezione di intestazione è una sequenza di righe di caratteri con una sintassi speciale definita in questa specifica. Il corpo è semplicemente una sequenza di caratteri che segue la sezione di intestazione ed è separato da essa da una riga vuota (cioè una riga con nulla che precede il CRLF).
Nota: Il linguaggio comune e le versioni precedenti di questa specifica usano il termine "header" (intestazione) sia per riferirsi all'intera sezione di intestazione sia per riferirsi a un singolo campo di intestazione. Per evitare ambiguità, questo documento non usa i termini "header" o "headers" in modo isolato, ma usa sempre "campo di intestazione" (header field) per riferirsi al singolo campo e "sezione di intestazione" (header section) per riferirsi all'intera raccolta.
2.1.1. Limiti di lunghezza delle righe
Esistono due limiti che questa specifica impone al numero di caratteri in una riga. Ogni riga di caratteri MUST avere non più di 998 caratteri e SHOULD avere non più di 78 caratteri, escluso il CRLF.
Il limite di 998 caratteri è dovuto ai limiti di molte implementazioni che inviano, ricevono o memorizzano messaggi IMF, le quali semplicemente non riescono a gestire più di 998 caratteri su una riga. Le implementazioni riceventi farebbero bene a gestire un numero arbitrariamente grande di caratteri in una riga, per motivi di robustezza. Tuttavia, esistono così tante implementazioni che (in conformità con i requisiti di trasporto di [RFC5321]) non accettano messaggi contenenti più di 1000 caratteri, inclusi CR e LF, per riga, che è importante che le implementazioni non creino tali messaggi.
La raccomandazione più conservativa di 78 caratteri serve a venire incontro alle numerose implementazioni di interfacce utente che visualizzano questi messaggi e che possono troncare, o mandare disastrosamente a capo, la visualizzazione di più di 78 caratteri per riga, nonostante il fatto che tali implementazioni non siano conformi all'intento di questa specifica (e a quello di [RFC5321] se effettivamente causano la perdita di informazioni). Ancora una volta, anche se questo limite è imposto ai messaggi, spetta alle implementazioni che visualizzano i messaggi gestire un numero arbitrariamente grande di caratteri in una riga (certamente almeno fino al limite di 998 caratteri) per motivi di robustezza.
2.2. Campi di intestazione
I campi di intestazione sono righe che iniziano con un nome del campo, seguito da due punti (":"), seguiti da un corpo del campo e terminati da CRLF. Il nome di un campo MUST essere composto da caratteri US-ASCII stampabili (cioè caratteri con valori tra 33 e 126, inclusi), eccetto i due punti. Il corpo di un campo può essere composto da caratteri US-ASCII stampabili nonché dai caratteri spazio (SP, valore ASCII 32) e tabulazione orizzontale (HTAB, valore ASCII 9) (noti insieme come caratteri di spazio bianco, WSP). Il corpo di un campo MUST NOT includere CR e LF, tranne quando utilizzati nel "ripiegamento" (folding) e nella "distensione" (unfolding), come descritto nella sezione 2.2.3. Tutti i corpi dei campi MUST essere conformi alla sintassi descritta nelle sezioni 3 e 4 di questa specifica.
2.2.1. Corpi dei campi di intestazione non strutturati
Alcuni corpi di campo in questa specifica sono definiti semplicemente come "non strutturati" (il che è specificato nella sezione 3.2.5 come qualunque carattere US-ASCII stampabile più i caratteri di spazio bianco) senza ulteriori restrizioni. Questi sono denominati corpi di campo non strutturati. Semanticamente, i corpi di campo non strutturati devono semplicemente essere trattati come una singola riga di caratteri senza ulteriore elaborazione (eccetto il "ripiegamento" e la "distensione" come descritto nella sezione 2.2.3).
2.2.2. Corpi dei campi di intestazione strutturati
Alcuni corpi di campo in questa specifica hanno una sintassi più restrittiva dei corpi di campo non strutturati descritti sopra. Questi sono denominati corpi di campo "strutturati". I corpi di campo strutturati sono sequenze di token lessicali specifici come descritto nelle sezioni 3 e 4 di questa specifica. A molti di questi token è consentito (secondo la loro sintassi) di essere introdotti o terminati da commenti (come descritto nella sezione 3.2.2) nonché dai caratteri di spazio bianco, e tali caratteri di spazio bianco sono soggetti al "ripiegamento" e alla "distensione" come descritto nella sezione 2.2.3. L'analisi semantica dei corpi di campo strutturati è fornita insieme alla loro sintassi.
2.2.3. Campi di intestazione lunghi
Ogni campo di intestazione è logicamente una singola riga di caratteri che comprende il nome del campo, i due punti e il corpo del campo. Per comodità, tuttavia, e per far fronte ai limiti di 998/78 caratteri per riga, la porzione del corpo del campo di un campo di intestazione può essere suddivisa in una rappresentazione su più righe; questa è chiamata "ripiegamento" (folding). La regola generale è che ovunque questa specifica consenta lo spazio bianco di ripiegamento (non semplicemente i caratteri WSP), un CRLF può essere inserito prima di qualunque WSP.
Per esempio, il campo di intestazione:
Subject: This is a test
può essere rappresentato come:
Subject: This is a test
Nota: Sebbene i corpi di campo strutturati siano definiti in modo tale che il ripiegamento possa avvenire tra molti dei token lessicali (e persino all'interno di alcuni dei token lessicali), il ripiegamento SHOULD essere limitato a collocare il CRLF in corrispondenza di interruzioni sintattiche di livello superiore. Per esempio, se un corpo di campo è definito come valori separati da virgole, è raccomandato che il ripiegamento avvenga dopo la virgola che separa gli elementi strutturati, di preferenza rispetto ad altri punti in cui il campo potrebbe essere ripiegato, anche se ciò è consentito altrove.
Il processo di passaggio da questa rappresentazione ripiegata su più righe di un campo di intestazione alla sua rappresentazione su una singola riga è chiamato "distensione" (unfolding). La distensione si ottiene semplicemente rimuovendo qualunque CRLF immediatamente seguito da WSP. Ogni campo di intestazione dovrebbe essere trattato nella sua forma distesa ai fini di ulteriori valutazioni sintattiche e semantiche. Un campo di intestazione disteso non ha restrizioni di lunghezza e pertanto può essere indeterminatamente lungo.
2.3. Corpo
Il corpo di un messaggio è semplicemente righe di caratteri US-ASCII. Le uniche due limitazioni sul corpo sono le seguenti:
o CR e LF MUST comparire solo insieme come CRLF; essi MUST NOT apparire indipendentemente nel corpo. o Le righe di caratteri nel corpo MUST essere limitate a 998 caratteri e SHOULD essere limitate a 78 caratteri, escluso il CRLF.
Nota: Come affermato in precedenza, esistono altri documenti, in particolare i documenti MIME ([RFC2045], [RFC2046], [RFC2049], [RFC4288], [RFC4289]), che estendono (e limitano) questa specifica per consentire diversi tipi di corpi di messaggio. Ancora una volta, questi meccanismi sono al di fuori dell'ambito di questo documento.