11. Problemi aggiuntivi
Questa sezione identifica problemi che non sono coperti, o non sono coperti in modo completo, nell'ambito di questo insieme di specifiche, ma che richiederanno una revisione continua nell'ambito della distribuzione dell'internazionalizzazione degli indirizzi email e delle intestazioni.
11.1. Impatto su URI e IRI
Lo schema mailto: [RFC6068], e la sua trattazione nella specifica dell'Internationalized Resource Identifier (IRI) [RFC3987], potrebbero dover essere modificati quando questo lavoro sarà completato e standardizzato.
11.2. Uso degli indirizzi email come identificatori
Vi sono numerosi contesti nell'uso contemporaneo di Internet in cui gli indirizzi email sono usati come identificatori di individui, anche come identificatori per server Web che supportano alcuni siti di commercio elettronico e in alcuni certificati X.509 [RFC5280]. Questi documenti non affrontano tali usi, ma è ragionevole aspettarsi che si incontreranno alcune difficoltà quando gli indirizzi internazionalizzati saranno usati per la prima volta in quei contesti, molti dei quali non sono nemmeno in grado di gestire l'intera gamma di indirizzi consentiti oggi.
11.3. Encoded word, messaggi firmati e downgrading
Una caratteristica particolare del formato email è la sua persistenza: ci si aspetta che i MUA gestiscano messaggi originariamente inviati decenni fa, e non solo quelli consegnati pochi secondi fa. In quanto tali, i MUA e il software di filtraggio della posta, come quello specificato in Sieve [RFC5228], dovranno continuare ad accettare e decodificare i campi di intestazione che utilizzano il meccanismo delle "encoded word" [RFC2047] per accogliere caratteri non-ASCII in alcuni campi di intestazione. Sebbene siano state definite estensioni sia per POP3 [RFC1939] sia per IMAP [RFC3501] che includono l'aggiornamento automatico dei messaggi che recano informazioni non-ASCII in forma codificata — inclusa la decodifica RFC 2047 — da parte del server POP3 [RFC5721bis-POP3] o IMAP [RFC5738bis-IMAP], vi sono strutture di messaggio e content-type MIME per i quali ciò non può essere fatto o in cui la modifica avrebbe effetti collaterali inaccettabili.
Per esempio, le parti di messaggio firmate crittograficamente, usando ad es. S/MIME [RFC5751] o Pretty Good Privacy (PGP) [RFC3156], non possono essere aggiornate dalla forma RFC 2047 a caratteri UTF-8 normali senza invalidare la firma. Analogamente, le parti di messaggio cifrate possono contenere, una volta decifrate, campi di intestazione che utilizzano la codifica RFC 2047; tali messaggi non possono essere aggiornati "completamente" senza accesso alle chiavi crittografiche.
Problemi simili possono sorgere se i messaggi vengono firmati e poi successivamente sottoposti a downgrading, ad es. come discusso nella Sezione 8.1, e poi si tenta di aggiornarli alla forma originale e di verificare le firme. Persino i cambiamenti molto sottili che possono derivare da algoritmi di downgrading e successivo upgrading possono essere sufficienti a invalidare le firme, se incidono sulle intestazioni delle parti di corpo primarie o MIME. Quando sono presenti firme, il downgrading deve essere eseguito con estrema cura, se non del tutto evitato.
11.4. Altri usi delle parti locali
Le parti locali sono talvolta usate per costruire etichette di dominio, ad es. la parte locale "user" nell'indirizzo [email protected] potrebbe essere convertita nel nome host user.domain.example, con il suo spazio Web su http://user.domain.example e gli indirizzi catch-all [email protected].
Tali schemi sono ovviamente limitati, tra le altre cose, dalle regole SMTP per i nomi di dominio, e non funzioneranno senza ulteriori restrizioni per altre parti locali. Se tali limitazioni siano rilevanti per queste specifiche è una questione aperta. Può trattarsi semplicemente di un altro caso della considerevole flessibilità accordata ai MTA di consegna nel determinare i nomi di casella postale che accetteranno e come essi vengano interpretati.
11.5. Formati di incapsulamento non standard
Alcune applicazioni usano formati simili al formato application/mbox [RFC4155] anziché alla forma message/digest definita nell'RFC 2046, Sezione 5.1.5 [RFC2046], per trasferire più messaggi come unità singole. Nella misura in cui tali applicazioni presumono che tutti i messaggi memorizzati usino il formato message/rfc822 descritto nell'RFC 2046, Sezione 5.2.1 [RFC2046], con intestazioni di messaggio ASCII, esse non sono pronte per le estensioni specificate in questa serie di documenti, e possono essere necessarie misure speciali per rilevarle ed elaborarle correttamente.