3. Definizione del problema

Internationalizing Domain Names in Applications (IDNA) [RFC5890] consente i nomi di dominio internazionalizzati, ma la diffusione non ha ancora raggiunto la maggior parte degli utenti. Una delle ragioni è che non disponiamo ancora di schemi di denominazione completamente internazionalizzati. I nomi di dominio sono solo uno dei vari nomi e identificatori che è necessario internazionalizzare. In molti contesti, finché non sarà internazionalizzata una quota maggiore di tali identificatori, i nomi di dominio internazionalizzati da soli hanno scarso valore.

Gli indirizzi email sono esempi lampanti del perché non sia sufficiente internazionalizzare soltanto il nome di dominio. Come la maggior parte degli osservatori ha imparato dall'esperienza, gli utenti preferiscono decisamente indirizzi email che assomigliano a nomi o iniziali rispetto a quelli che contengono stringhe di lettere o numeri apparentemente prive di significato. A meno che l'intero indirizzo email possa utilizzare caratteri e formati familiari, gli utenti percepiranno l'email come culturalmente poco amichevole. Se i nomi e le iniziali usati negli indirizzi email possono essere espressi nelle lingue native e nei sistemi di scrittura degli utenti, Internet sarà percepito come più naturale, specialmente da coloro la cui lingua nativa non è scritta in un sottoinsieme di un alfabeto di derivazione latina.

L'internazionalizzazione degli indirizzi email non è soltanto una questione di modificare la busta SMTP; o di modificare i campi di intestazione "From:", "To:" e "Cc:"; o di consentire ai Mail User Agent (MUA) aggiornati di decodificare una codifica speciale e rispondere visualizzando caratteri locali. Per essere percepiti come utilizzabili, gli indirizzi MUST essere internazionalizzati e gestiti in modo coerente in tutti i contesti in cui compaiono. Questo requisito ha implicazioni di vasta portata: raccolte di patch e soluzioni alternative non sono adeguate. Anche se lo fossero, un approccio basato su soluzioni alternative potrebbe dar luogo a una varietà di implementazioni con insiemi diversi di patch e soluzioni applicate, con conseguente confusione degli utenti su ciò che è effettivamente utilizzabile e supportato. Dobbiamo invece costruire un ambiente email completamente internazionalizzato, concentrandoci sul consentire una comunicazione efficiente tra coloro che condividono una lingua e un sistema di scrittura. Ciò implica, a sua volta, modifiche all'ambiente delle intestazioni di posta per consentire a quei campi di intestazione che sono opportunamente internazionalizzati di utilizzare l'intera gamma di caratteri Unicode, un'estensione SMTP per consentire l'indirizzamento UTF-8 [RFC3629] [RFC5198] e la consegna di quei campi di intestazione estesi, il supporto per l'internazionalizzazione delle notifiche di consegna e di servizio [RFC3461] [RFC3464] e (infine) un requisito di supporto per l'estensione SMTP 8BITMIME [RFC6152], affinché tutto ciò possa essere trasportato attraverso il sistema di posta senza dover superare la limitazione per cui i campi di intestazione non dispongono di content-transfer-encoding.