3. Modifiche ai campi di intestazione del messaggio
Per consentire caratteri Unicode non ASCII nei valori dei campi, la definizione di intestazione in [RFC5322] viene estesa per supportare il nuovo formato. Le sezioni seguenti specificano le modifiche necessarie all'ABNF del RFC 5322.
Le regole sintattiche non menzionate di seguito restano definite come in [RFC5322].
Si noti che questo protocollo non modifica le regole del RFC 5322 per la definizione dei nomi dei campi di intestazione. I corpi dei campi di intestazione possono contenere caratteri Unicode, ma i nomi dei campi di intestazione stessi devono essere composti esclusivamente da caratteri ASCII.
Si noti inoltre che i messaggi in questo formato richiedono l'uso dell'estensione SMTPUTF8 [RFC6531] per essere trasferiti tramite SMTP.
3.1. Sintassi e normalizzazione UTF-8
I caratteri UTF-8 possono essere definiti in termini di ottetti utilizzando la seguente ABNF [RFC5234], tratta da [RFC3629]:
UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4
UTF8-2 = <Defined in Section 4 of RFC3629>
UTF8-3 = <Defined in Section 4 of RFC3629>
UTF8-4 = <Defined in Section 4 of RFC3629>
Vedere [RFC5198] per una discussione sulla normalizzazione Unicode; dovrebbe (SHOULD) essere utilizzata la forma di normalizzazione NFC [UNF]. In realtà, se si intende fare correttamente internazionalizzazione, uno degli obiettivi più spesso citati è consentire alle persone di scrivere correttamente il proprio nome. Poiché molte parti locali delle caselle di posta riflettono nomi personali, tale principio si applica anche alle caselle di posta. La forma di normalizzazione NFKC [UNF] non dovrebbe (SHOULD NOT) essere utilizzata, poiché può perdere informazioni necessarie per scrivere correttamente alcuni nomi in alcune circostanze inusuali.
3.2. Estensioni sintattiche al RFC 5322
Le regole seguenti estendono la sintassi ABNF definita in [RFC5322] e [RFC5234] al fine di consentire contenuto UTF-8.
VCHAR =/ UTF8-non-ascii
ctext =/ UTF8-non-ascii
atext =/ UTF8-non-ascii
qtext =/ UTF8-non-ascii
text =/ UTF8-non-ascii
; note that this upgrades the body to UTF-8
dtext =/ UTF8-non-ascii
Le modifiche precedenti significano che i seguenti costrutti ora consentono UTF-8:
-
Testo non strutturato (unstructured text), utilizzato in campi di intestazione quali "Subject:" o "Content-description:".
-
Qualsiasi costrutto che utilizzi atomi, inclusi ma non limitati alle parti locali degli indirizzi e dei Message-ID. Ciò include gli indirizzi nelle clausole "for" dei campi di intestazione "Received:".
-
Stringhe tra virgolette (quoted strings).
-
Domini (domains).
Si noti che i nomi dei campi di intestazione non sono in questo elenco; questi sono ancora limitati all'ASCII.
3.3. Uso di UTF-8 a 8 bit nei Message-ID
Gli implementatori di algoritmi di generazione dei Message-ID possono (MAY) preferire limitare il proprio output all'ASCII, poiché ciò presenta alcuni vantaggi, ad esempio quando si costruiscono i campi di intestazione "In-reply-to:" e "References:" nei thread delle liste di distribuzione in cui alcuni mittenti usano indirizzi internazionalizzati e altri no.
3.4. Effetti sui limiti di lunghezza delle righe
La sezione 2.1.1 di [RFC5322] limita le righe a 998 caratteri e raccomanda che le righe siano limitate a soli 78 caratteri. Questa specifica porta il primo limite a 998 ottetti. (Si noti che, in ASCII, ottetti e caratteri sono di fatto la stessa cosa, ma ciò non vale in UTF-8.) Il limite di 78 caratteri resta definito in termini di caratteri, non di ottetti, poiché è inteso a risolvere problemi di larghezza di visualizzazione, non di lunghezza delle righe.
3.5. Modifiche alle restrizioni di codifica dei tipi di messaggio MIME
Questa specifica aggiorna la sezione 6.4 di [RFC2045]. [RFC2045] vieta di applicare un content-transfer-encoding a qualsiasi sottotipo di "message/". Questa specifica allenta tale regola -- consente ai tipi MIME di nuova definizione di permettere il content-transfer-encoding, e consente il content-transfer-encoding per message/global (vedere la sezione 3.7).
Contesto: normalmente il trasferimento di message/global avviene su canali 8-bit-clean e le parti del corpo hanno codifiche "identity", cioè non è necessaria alcuna decodifica.
Tuttavia, nel caso in cui un messaggio contenente un message/global venga declassato da 8 bit a 7 bit come descritto in [RFC6152], potrebbe essere necessario applicare una codifica al messaggio. Se il messaggio viaggia più volte tra un ambiente a 7 bit e un ambiente che implementa queste estensioni, possono verificarsi più livelli di codifica. Si prevede che ciò si osservi raramente nella pratica, e si ritiene che la potenziale complessità di altri modi di affrontare il problema sia maggiore della complessità di consentire codifiche annidate ove necessario.
3.6. Uso delle parole codificate MIME
La funzionalità delle parole codificate MIME [RFC2047] fornisce la capacità di inserire testo non ASCII, ma solo in un sottoinsieme delle posizioni consentite da questa estensione. Inoltre, le parole codificate sono sostanzialmente più complesse, poiché consentono l'uso di set di caratteri arbitrari. Di conseguenza, le parole codificate non dovrebbero (SHOULD NOT) essere utilizzate quando si generano campi di intestazione per messaggi che impiegano questa estensione. Gli agenti possono (MAY), quando incorporano materiale da un altro messaggio, convertire l'uso delle parole codificate nell'uso diretto di UTF-8.
Si noti che occorre prestare attenzione durante la decodifica delle parole codificate, poiché i risultati ottenuti dopo aver sostituito una parola codificata con il suo equivalente decodificato in UTF-8 possono essere sintatticamente non validi. I processori che scelgono di decodificare le parole codificate non devono (MUST NOT) generare campi sintatticamente non validi.
3.7. Il tipo di media message/global
I messaggi internazionalizzati in questo formato devono (MUST) essere trasmessi solo come autorizzato da [RFC6531] o all'interno di un ambiente non SMTP che supporti questi messaggi. Un messaggio è un "messaggio message/global" se:
-
contiene valori di intestazione UTF-8 a 8 bit come specificato in questo documento, oppure
-
contiene valori UTF-8 a 8 bit nei campi di intestazione delle parti del corpo.
Il contenuto di una parte message/global è per il resto identico a quello di una parte message/rfc822.
Se un oggetto di questo tipo viene inviato a un sistema solo a 7 bit, deve (MUST) essergli applicato un content-transfer-encoding appropriato. (Si noti che un sistema conforme a MIME che non riconosce message/global dovrebbe trattarlo come "application/octet-stream", come descritto nella sezione 5.2.4 di [RFC2046].)
La registrazione è la seguente:
Type name: message
Subtype name: global
Required parameters: none
Optional parameters: none
Encoding considerations: Qualsiasi content-transfer-encoding è consentito. I content-transfer-encoding a 8 bit o binari sono raccomandati ove consentito.
Security considerations: Vedere la sezione 4.
Interoperability considerations: Questo tipo di media fornisce funzionalità simili al tipo di contenuto message/rfc822 per i messaggi di posta elettronica con intestazioni internazionalizzate. Quando vi è la necessità di incorporare o restituire tale contenuto in un altro messaggio, in genere esiste la possibilità di utilizzare questo tipo di media e lasciare il contenuto invariato, oppure di convertire il contenuto in message/rfc822. Ciascuna di queste scelte interopererà con la base installata, ma con proprietà diverse. I sistemi che non conoscono le intestazioni internazionalizzate tratteranno tipicamente una parte message/global come un allegato sconosciuto, mentre comprenderanno la struttura di un message/rfc822. Tuttavia, i sistemi che comprendono message/global forniranno funzionalità superiori al risultato di una conversione in message/rfc822. La scelta più interoperabile dipende dal software installato.
Published specification: RFC 6532
Applications that use this media type: Server SMTP e client di posta elettronica che supportano la generazione o l'analisi di multipart/report. Client di posta elettronica che inoltrano come allegati messaggi con intestazioni internazionalizzate.
Additional information:
Magic number(s): none
File extension(s): Si suggerisce l'estensione ".u8msg".
Macintosh file type code(s): Si suggerisce un uniform type identifier (UTI) "public.utf8-email-message". Esso è conforme a "public.message" e "public.composite-content", ma non necessariamente a "public.utf8-plain-text".
Person & email address to contact for further information: Vedere la sezione degli indirizzi degli autori di questo documento.
Intended usage: COMMON
Restrictions on usage: Questo è un tipo di media strutturato che incorpora altri tipi di media MIME. Dovrebbe (SHOULD) essere utilizzato un content-transfer-encoding a 8 bit o binario, a meno che questo tipo di media non venga inviato su un trasporto solo a 7 bit.
Author: Vedere la sezione degli indirizzi degli autori di questo documento.
Change controller: IETF Standards Process