Maurizio Codogno
Telecom Italia Lab
Via Reiss Romoli 274 - 10148 Torino Italy
maurizio.codogno@tilab.com
L'internazionalizzazione del DNS, o iDNS in breve, è un argomento molto sentito negli ultimi anni, da quando cioè l'inglese non è più la lingua dominante nel web. Il gruppo di lavoro idn in IETF si occupa di studiare come si potranno usare caratteri non ASCII nei nomi a dominio nel modo meno doloroso possibile: sono state definite le caratteristiche di tali sistemi, e come i nomi dovrebbero essere preparati: ci sono molte proposte diverse per la codifica dei nomi e per il protocollo da usare a basso livello, oltre a persone che ritengono che l'approccio sia inerentemente sbagliato e a società che stanno già pensando a come fare soldi con brevetti e altro.
Internet è nata come un sistema "all American", e quindi nessuno pensò alla necessità di utilizzare caratteri diversi da quelli standard ASCII (che, per chi non se lo ricordasse, sono rappresentabili con sette bit). Anche il DNS, il sistema che permette di associare un nome comprensibile a un indirizzo IP, è figlio di questa scuola di pensiero: gli RFC che specificano il DNS e lo propongono come successore del sistema piatto basato su un enorme file /etc/hosts sono del 1987, e permettono come caratteri all'interno dei nomi DNS solo gli alfabetici (senza distinzione tra maiuscole e minuscole), i numerici e il trattino: anche se occorre dire che il protocollo a livello di trasporto pacchetti non aveva in realtà nessun problema con il tipo di ottetti che trasferiva.
Man mano che gli anni sono passati, la situazione è molto cambiata: da un lato ci sono sempre più persone che accedono a Internet senza conoscere necessariamente l'inglese, e per cui quindi le stringhe dei nomi a dominio sono incomprensibili esattamente come le quadrotte di numeri degli indirizzi IP; d'altro canto, il giro di affari che sta alla base dei nomi a dominio è così cresciuto che moltissime persone hanno fiutato l'affare nella possibilità di "avere i propri caratteri" nel DNS, e ha spinto per trovare una soluzione interoperabile.
All'interno dell'IETF si è così formato alla fine del 1999 un gruppo di lavoro, idn (l'acronimo sta per "Internationalization of Domain Names" - ma nessun americano pronuncia o scrive mai una parola lunga come quella, e in genere la abbrevia in i18n...) che avrebbe dovuto in tempi brevi definire un protocollo apposito per aggiornare il DNS. Dopo un anno e mezzo siamo ancora qui a parlarne: non è un caso. Cercherò di dare una rapida panoramica di cosa è successo nel gruppo IETF e fuori da esso, senza cercare di tirare fuori chissà quali conclusioni che tanto sarebbero sicuramente errate!
riferimenti:
http://www.i-d-n.net/,
http://www.ietf.org/html.charters/idn-charter.html
Anche se formalmente il gruppo idn non ha ancora pubblicato alcun RFC, bisogna ammettere che c'è almeno un punto su cui c'è stato un consenso abbastanza ampio: quali sono le caratteristiche che dovrebbe avere un sistema di iDNS. Esiste un documento sui requirement, che è nato per mettere nero su bianco che cosa è richiesto a un qualunque sistema voglia essere adottato.
Le caratteristiche richieste sono molte - trenta, per la precisione. Alcune sono semplicemente dei desideri, anche perché non è affatto detto che nel mucchio non ci siano delle incompatibilità; altre sono invece ritenute irrinunciabili. Sono state individuate quattro categorie principali: compatibilità e interoperabilità, che ricorda che iDNS non deve introdurre discrepanze per i nomi DNS attuali, e deve essere studiato in modo tale che se ci sono server non aggiornati, essi diano comunque risultati coerenti; internazionalizzazione, che dice che si vogliono utilizzare dei nomi internazionali, limitando al minimo le restrizioni sui caratteri utilizzabili nei nomi; canonicizzazione, che descrive quali sono i vincoli nel trasformare in una forma univoca i nomi per cui si chiede la risoluzione, ad esempio che il locale non modifichi i risultati; e infine vincoli operazionali, come la richiesta che il traffico non aumenti troppo, e che non si abbiano perdite di sicurezza.
riferimento:
draft-ietf-idn-requirements-07.txt
Nell'approccio portato avanti dal gruppo di lavoro idn, la funzione di preparazione dei nomi ("nameprep") serve per fare in modo che i nomi a dominio internazionalizzati usino caratteri tali da non generare confusione. Notate che questo è assolutamente indipendente da come verrà rappresentato internamente al DNS il nome a dominio richiesto. Per fare un esempio stupido, la Alfa maiuscola greca dà dei problemi perché è indistinguibile da una A maiuscola latina; anche se la codifica interna fosse completamente diversa, chi deve digitare un nome a dominio A-stile.biz non ha nessuna possibilità di capire se deve usare una A o un'Alfa. Il problema che viene risolto da idn è appunto quello di impedire questa confusione, non quello di specificare come dovrà essere codificato ad esempio un ideogramma.
I passi definiti in nameprep sono i seguenti:
La funzione nameprep deve essere eseguita dal client prima di fare la richiesta al DNS: è cioè locale, per semplificare la vita ai server.
riferimento:
draft-ietf-idn-nameprep-03.txt
se fino a questo punto c'è qualche speranza di ottenere un consenso, anche se magari di malavoglia, sui documenti proposti, la cosa si comincia a fare complicata quando si parla della codifica dei nomi a dominio. Come ho detto, un conto è dire che il carattere sigma è accettato all'interno di un nome, un altro è definire come debba venire indicato a basso livello quando si fa la richiesta di un nome. Sono state presentate quasi una ventina di proposte diverse per la fase di codifica: come vedremo in seguito, la ragione di questa proliferazione non è semplicemente dovuto a ragioni tecniche, purtroppo.
La classe più nutrita di questi meccanismi di codifica è quella degli ACE. Questo TLA sta per "ASCII-Compatible Encoding" e parte dal principio che, per evitare per quanto possibile malfunzionamenti di Internet, la cosa più conveniente da fare sia codificare i nomi in modo che gli unici caratteri spediti "sul cavo" siano quelli abituali per il DNS, cioè le lettere minuscole, le cifre e il trattino. In questo modo si costringe naturalmente tutte le routine che trattano con i nomi a dominio a inserire al loro interno la codifica ACE, ma si ha il vantaggio che se qualcosa va male apparirà sì un nome incomprensibile, ma che è comunque perfettamente legale con gli RFC attuali, e quindi non si rischiano danni.
Gli ACE più noti sono probabilmente RACE e LACE: in entrambi c'è lo zampino di Paul Hoffman (Internet Mail Consortium, non certo uno degli ultimi arrivati). La codifica scelta consiste nell'ottimizzare innanzitutto le sequenze di caratteri. Il carattere iniziale degli acronimi sta rispettivamente per "Row" (il byte superiore in Unicode) e "Length" (in questo caso si contano quanti caratteri sono nella stessa riga, e si lascia il numero come indice). Una volta fatta questa codifica, la sequenza di bit ottenuta viene codificata in base 32, vale a dire ogni cinque bit formano un carattere scelto tra a-z2-6. Infine si usa una stringa speciale, come bq-- oppure lq--, per indicare che da quel punto in poi i caratteri sono da considerarsi codificati.
BRACE è abbastanza simile a LACE: viene sempre usata una codifica base32, ma la stringa speciale (-8Q9) viene posta in fondo al nome, e vengono fatti controlli speciali per mantenere per quanto possibile leggibile la parte ASCII. Anche UTF-6 rientra nella grande famiglia delle trasformazioni ASCII: in questo caso però si ha una scrittura in esadecimale modificato in caso di caratteri nella stessa pagina UNICODE. Anche questo algoritmo è stato poi ritirato dall'autore.
DUDE e altDUDE (l'acronimo sta per Differential Unicode Domain Encoding) sono due codifiche per l'appunto differenziali: viene fatto l'XOR tra ogni byte e quello precedente, partendo dal presupposto che in questo modo se si sta all'interno di una famiglia Unicode con "pochi" caratteri (cirillico, greco, ma anche Latin-1 esteso, che in realtà sta in due "righe" consecutive!) ci saranno pochi bit da codificare, e quindi la stringa risultante - che viene comunque codificata Base32 - sarà più corta. Questi algoritmi hanno anche il vantaggio di mantenere le distinzioni maiuscolo-minuscolo, che possono essere interessanti in fase di presentazione all'utente. AltDUDE è poi stato ritirato dall'autore, che ha preferito modificare DUDE seguendo i suggerimenti del gruppo di lavoro.
Queste codifiche sono state fatte tutte o in parte da Adam M. Costello, che probabilmente ha preso gusto alla cosa e ne ha sfornate altre cinque pubbliche - oltre a svariate altre che non considerava sufficientemente intelligenti. Poiché tutta la sua fantasia sta nelle codifiche, non gliene rimaneva poi molta per i nomi: alla fine ha iniziato a chiamare i suoi draft -amc-ace-%, dove % è una lettera dell'alfabeto che corrisponde come posizione ordinale alla codifica da lui proposta: a sarebbe la prima, b la seconda, e così via. È arrivato a w, non so se rendo l'idea!
Naturalmente c'è chi afferma che non vale affatto la pena di fare tutta questa fatica: Dan Bernstein parte ad esempio dal principio "La mia implementazione dei resolver DNS (djbdns) non ha nessun problema se si spediscono caratteri codificati UTF-8, quindi si può tranquillamente lasciare questa codifica". All'obiezione "Ma ad esempio cosa succede con la posta elettronica? Il DNS viene usato anche lì!" la sua risposta è "Il mio server di posta elettronica non ha nessun problema con nomi di dominio codificati UTF-8, quindi si può tranquillamente lasciare questa codifica". Questo modo di vedere le cose può avere una sua logica, tralasciando la ormai pluriennale battaglia di Bernstein contro chi ha scritto BIND e Sendmail, ma sicuramente getta benzina sul fuoco...
TRACE è un sistema che invece predilige una via di mezzo: permettere cioè nomi a 8 bit mantenendo la compatibilità per mezzo di record CNAME. La codifica a 8 bit avviene appunto per mezzo di UTF-8, che si sta ormai affermando come il sistema più apprezzato. Viene poi aggiunto per ogni nome a dominio un CNAME che inizia con un carattere speciale (ASCII 127, trascritto come \127) per indicare che le cifre seguenti sono la rappresentazione utf-8 della stringa.
John Klensin, in un momento di sconforto, ha scritto anch'egli una proposta, DUNCE, che è a suo stesso dire "la più banale possibile". Semplicemente si scrive il nome a dominio indicando i valori esadecimali della rappresentazione Unicode, e si inizia la stringa con bl-- (che sta per "bleech", espressione di disgusto nel dovere fare tutti questo)
Proprio mentre preparavo queste note, è stato inviato un draft da parte dell'ACE Design Team dove Hoffman, il portavoce, ha dato la sua preferenza per DUDE. Esso è stato considerato sufficientemente semplice da implementare, è indipendente dallo script usato, soddisfa i vincoli pratici di lunghezza richiesti (15 caratteri Han-based, e 30 per i linguaggi alfabetici). Che questa raccomandazione sia seguita, e che gli ACE verranno davvero usati, non lo si può sapere.
riferimenti:
draft-ietf-idn-race-03.txt,
draft-ietf-idn-lace-01.txt,
draft-ietf-idn-utf6-00.txt,
draft-ietf-idn-dude-02.txt,
draft-ietf-idn-altdude-00.txt,
draft-ietf-idn-dunce-00.txt,
draft-ietf-idn-brace-00.txt,
draft-ietf-idn-dnsii-trace-00.txt,
RFC 2279 (UTF-8)
Fino ad ora ho parlato di cose relativamente ad alto livello: vediamo se e come invece occorre modificare il protocollo DNS per permettere l'invio di nomi a dominio iDNS. Non sempre queste modifiche sono dipendenti oppure no dalla codifica e dalla preparazione, come vedremo: è importante però essere certi che anche in caso di server non aggiornati, incontrati nel percorso che una richiesta deve fare, non ci siano problemi.
IDNA, proposto da Hoffman insieme a Patrick Fälstrom, è basato molto pesantemente sulle codifiche ACE: nel modello logico, l'applicazione deve presentare il nome con i caratteri internazionali, al limite permettendo solo agli esperti di inserire direttamente il nome codificato. Però l'applicazione traduce immediatamente in un ACE, e da lì in poi non c'è nulla di preoccupante, visto che i server DNS non si accorgono più della differenza.
L'onnipresente Hoffman, insieme a Marc Blanchet che è uno dei co-chair del gruppo idn, ha anche presentato una proposta per utilizzare le funzionalità di Extended DNS per memorizzare i nomi a dominio direttamente in UTF-8. In questo modo, non si hanno problemi con i server che comprendono EDNS, ma naturalmente il problema rimane per i "vecchi server". Gli autori propongono di usare una codifica ACE in parallelo a quella UTF-8, per avere comunque una via di salvezza.
Dan Oscarsson propone un sistema ibrido, UDNS, che utilizza una codifica UTF-8 con una label IANA specifica, oppure un BCE (Backward Compatibility Encoding) che non è altro che un ACE. In questo modo, il server può accorgersi che il cliente non comprende UDNS e inviargli una forma compatibile; se il server invece non comprende UDNS, eventuali dati iDNS devono essere caricati "a mano" nella forma codificata.
Sung Jae Shim propone un sistema di internazionalizzazione "virtuale", VIDN, dove c'è uno strato "di directory" che traduce con un algoritmo tipo soundex i caratteri non ASCII in una forma inglese che sia la più simile possibile come suono all'originale. Tale proposta non ha però avuto un gran seguito, visto che ci sono troppi rischi di confusione.
Un gruppo di autori cinesi ha affrontato il problema da un punto di vista diverso. Come avete notato, tutte le proposte, a partire da nameprep, partono dal presupposto che i nomi iDNS siano scritti in Unicode/ISO10646 (e generalmente codificati in UTF-8, ma questo è un altro punto). Gli autori fanno notare che però in Cina vengono ancora usati molti alfabeti non standard, e quindi occorrerebbe ancora un ulteriore passaggio di traduzione verso Unicode prima di quello verso gli ACE. Sarebbe invece possibile avere un unico strato di normalizzazione, magari utilizzando uno schema tendente alle directory come LDAP o CNRP. L'approccio è denominato UNAME, dove la U sta per "unique". Anche in questo caso i problemi di possibili confusioni tra codifiche diverse non lasciano immaginare una facile accettazione di questo protocollo.
Infine la proposta DNSII rovescia completamente l'approccio e tende a caricare il server con il maggior peso. Come per EDNS, viene usato un flag particolare per indicare che il pacchetto DNS contiene dei caratteri non nel vecchio insieme RFC1035. Vengono poi riservati 12 bit per indicare il tipo di codifica che sarà adottato all'interno, e il nome vero e proprio. Questo dà un'ampia libertà al client, ma costringe il server a un lavoro maggiore perché esso deve decodificare il nome e fare lui la comparazione con le etichette nei suoi file con la zona...
riferimenti:
draft-ietf-idn-idna-01.txt,
draft-ietf-idn-idne-02.txt,
draft-ietf-idn-udns-02.txt,
draft-ietf-idn-vidn-01.txt,
draft-ietf-idn-uname-00.txt,
draft-ietf-cnrp-10.txt,
draft-ietf-idn-dnsii-mdnp-02.txt,
RFC 2671 (EDNS)
Come ho scritto sopra, in realtà non c'è neppure un vero consenso sul fatto che tutto questo lavoro di preparazione sia necessario per l'internazionalizzazione dei nomi a dominio. Ho già accennato alle idee piuttosto tendenti al "Cicero pro domo sua" di Bernstein, che dice che tutto va bene usando semplicemente UTF-8 come codifica per i nomi iDNS. C'è però un approccio molto più generale al problema, portato avanti da John Klensin.
Klensin, un altro dei Grandi Vecchi di IETF, ha portato avanti una disanima complessiva del ruolo che il DNS ha assunto al giorno d'oggi: esso è riuscito a scalare in maniera rimarcabilmente buona rispetto ai requisiti iniziali, ma è chiaro che certe assunzioni che erano state fatte quindici anni fa si sono rivelate completamente sbagliate - nulla di male, visto che nessuno può essere profetico. Tra le cose che vengono gestite male, a parte l'internazionalizzazione, si può notare la mancanza di informazioni sulla localizzazione geografica dei siti; il problema con i virtual host, cioè indirizzi che corrispondono a moltissimi nomi; e naturalmente il problema dei marchi registrati, che in un sistema ormai praticamente piatto non permette di distinguere tra marchi simili o uguali, ma in contesti diversi.
Klensin propone due diverse soluzioni al problema: la prima, più legata alla semplice internazionalizzazione, consiste nel creare una nuova classe all'interno del DNS, superando il monopolio di fatto che adesso è la classe IN. Visto che la classe sarebbe nuova, non ci sarebbero problemi a togliere alcune caratteristiche obsolete, e aggiungere una codifica ad esempio UTF-8 per le etichette dei nomi. È chiaro che gli altri problemi non verrebbero risolti, e che in questo caso non solo i clienti ma anche i server dovrebbero essere aggiornati, ma Klensin afferma che bisogna valutare se la maggior pulizia di questo approccio non possa pesare a favore di esso.
L'altra possibilità indicata da Klensin consiste nel lasciare il DNS così com'è, ma mettere al di sopra di esso due altri livelli "di ricerca" (non vuole usare la parola "directory", perché teme che abbia ormai assunto un significato troppo predefinito). Il primo dovrebbe sfruttare una piccola serie di attributi, come nome, lingua, locazione geografica, topologia di rete - qualunque cosa essa sia! - e categoria industriale. Infine il livello più alto dovrebbe essere più o meno l'equivalente delle pagine gialle e mantenere pertanto una possibilità di ricerca tra i risultati del secondo livello per trovare ll posto cercato. Questo modello è chiaramente ancora più che altro concettuale, e forse si può vedere come un modo di convincere la gente a pensare con maggior cognizione di causa a quello che potrà diventare Internet nei prossimi anni.
riferimenti:
draft-klensin-i18n-newclass-00.txt,
draft-klensin-dns-search-00.txt,
draft-klensin-dns-role-01.txt
Bene, i teorici e i puristi saranno ormai sazi di informazioni. Per le persone che hanno capito che oramai di "puro" su Internet non c'è poi molto, mi affretto ad aggiungere che ci sono forti pressioni da parte di molti attori perché appaia una soluzione nel minor tempo possibile.
Qual è la ragione di tanta fretta? Soldi, naturalmente. Se noi italiani possiamo sopravvivere a scrivere "universita" invece che "università", la cosa non è più così immediata con il greco, il russo, l'arabo... Non parliamo poi delle nazioni che utilizzano ideogrammi, come Giappone, Corea e soprattutto Cina: per loro un nome finalmente comprensibile è un must.
Le mosse che si sono viste in questi mesi, a parte forti lobbying verso l'una o l'altra codifica, partono dalla preregistrazione di nomi a dominio che "casualmente" corrispondono per un certo ACE a parole comuni in certe lingue, ma arrivano addirittura ad avere brevettato il modello logico di codifica ACE per inserire nomi a dominio: la società Walid, Inc. ha per l'appunto fatto la richiesta del brevetto USA n. 6182148
Altri, come Verisign - la società che ha comperato Network Solutions, il registrar di .com, .net e .org, si limitano a annunciare che hanno fatto accordi per la registrazione di nomi a dominio multilingua, senza specificare come viene tecnicamente fatta la cosa: all'interno del gruppo idn il rappresentante Verisign (sì, lo so, non ci sono rappresentanti di aziende in IETF. Lo sappiamo tutti...) fa affermazioni spesso sibilline, e molti sono convinti che essi abbiano la possibilità di prendere la licenza per un qualsivoglia brevetto e sfruttarlo pesantemente e soprattutto prima che altri possano registrare i nomi "più appetibili".
riferimenti:
http://www.delphion.com/details?&pn=US06182148__,
http://www.walid.com,
http://corporate.verisign.com/news/2001/pr_20010529b.html,
Penso che l'unica cosa che sia chiara in tutto questo sfoggio di informazioni è che siamo ancora in alto mare. Non è affatto certo che alla fine l'IETF venga di fatto delegittimato, e uno standard di fatto si imponga a forza di mercato se alcuni dei più importanti attori decidono di scegliere una soluzione, bacata quanto si vuole, ma "quasi buona". Internet è piena di standard "quasi buoni", che sono i più difficili da estirpare proprio perché non sono così tragici da utilizzare, ma semplicemente scoccianti.
Vedremo cosa succederà tra alcuni mesi...
http://beatles.cselt.it/mau/articoli/iDNS.html
15 giugno 2001 - .mau.