IDN in Italia: alcuni commenti

Questo documento vuole esporre i miei commenti personali sulla possibilità di introdurre nomi a dominio internazionalizzati (IDN) immediatamente al di sotto del Country Code Top Level Domain .it. Non ho nessuna pretesa di scrivere qui le Risposte; ho piuttosto cercato di esporre diverse tesi, con quelli che io ho visto come pro e contro, per dare un ausilio a chi dovrà prendere le decisioni. Il testo è di pubblico dominio.

Questa è la seconda versione: le modifiche rispetto alla precedente sono indicate in blu. Ho raccolto spunti da Tullio Andreatta, Marco d'Itri, Giorgio Giunchi, Enzo Viscuso.

1. Premessa: cosa sono gli IDN

I nomi identificativi dei calcolatori in rete sono sempre stati composti con un insieme di caratteri molto ristretto: le lettere (senza distinzione tra maiuscole e minuscole), le cifre e il trattino. Anche se i documenti ufficiali (RFC 1034 e 1035, con i loro aggiornamenti) non ponevano limiti ai caratteri utilizzabili, la pratica ha portato ad avere implementazioni che assumevano implicitamente queste limitazioni.
Lo spostamento verso un mondo più internazionale ha anche portato alla richiesta, soprattutto da parte dei paesi asiatici, di avere i nomi a dominio che potessero rappresentare parole nella propria lingua. Dopo tre anni di discussioni, si sono definiti alcuni nuovi RFC (3454, 3490, 3491, 3492) che danno questa possibilità.

La scelta che è stata fatta, non senza aspre discussioni all'interno del gruppo di lavoro IDN, è stata quella della codifica dei caratteri. I nomi IDN, pertanto, appaiono come delle stringhe di lettere, cifre e trattino, aventi però una sottostringa distintiva (xn--). In questo modo, si è certi che le applicazioni che non conoscono IDN continuano a funzionare, anche se all'utente apparirà un nome illeggibile; si immagina che man mano esse verranno aggiornati.
Dal punto di vista tecnico, si è definito un algoritmo (Nameprep) per decidere quali caratteri Unicode sono accettabili - ad esempio i vari tipi di spazio o di punto sono stati vietati - e quali sono equivalenti - ad esempio, alcune legature con la coppia di caratteri corrispondente. E' stato poi definito un altro algoritmo (Punycode) per convertire da e verso IDN. Tecnicamente non vi sono pertanto problemi.

2. Scelte possibili per gli IDN in Italia

Se vogliamo introdurre anche in Italia i nomi IDN, abbiamo a disposizione una serie di scelte, più o meno pragmatiche, su cui si può discutere.

non fare nulla. Si continua a vietare l'uso di nomi IDN, visto che fortunatamente in Italia non ce n'è una necessità estrema. Almeno nel breve termine è un'opzione accettabile; però credo che nel lungo periodo sia insostenibile, e quindi è meglio cominciare a pensarci su.
liberalizzare tutto. In questa opzione si accettano direttamente tutti i caratteri definiti negli RFC. Anche questa opzione è attraente, perché è semplice da implementare: porta però a una serie di problemi legati ai caratteri che si assomigliano ma sono diversi. Già in Italia sono in pochi a sapere se si scrive "perché" oppure "perchè"; cosa potrebbe accadere con un link a http://www.micrοsoft.it/? (per chi non se ne fosse accorto: la prima "o" è in realtà una omicron greca)
accettare solo alcuni caratteri. Nessuno ci vieta di ridurre il numero di caratteri ammessi, decidendo regole come "ammettiamo solo le lettere accentate", oppure "ammettiamo tutti i caratteri ISO-8859-xx", o ancora "non si possono registrare nomi con alfabeti misti". A me piace questa idea, ma non nascondo che richiede molto lavoro e l'accordo di RA per l'implementazione delle regole. Le classi di caratteri ammissibili sono ovviamente molte: le prime che vengono in mente sono le lettere accentate italiane, oppure le lettere usate negli alfabeti francese e tedesco (non per altro, ma ricordo che sono lingue ufficiali in Val d'Aosta e nella Provincia di Bolzano), o ancora le lettere che si usano nelle lingue ufficiali dell'Unione Europea. Oppure si può pensare a certi simboli come quello dell'euro. L'ultima regola che ho indicato permetterebbe di evitare casi come quello di micrοsoft.it indicato sopra, permettendo però ad esempio παρακαλω.it.
definire equivalenze tra caratteri. Se noi decidiamo che, per quanto riguarda .it, "e","è" ed "é" sono lo stesso simbolo, non possiamo certo avere problemi di nomi che si confondano! Gli RFC non vietano che all'interno di un namespace come nel nostro caso .it si faccia questa operazione. Il problema arriva quando bisogna decidere come effettuare questa equivalenza: vedi la sezione seguente per le possibilità.

3. Equivalenze di caratteri

Abbiamo appena visto come sia possibile definire alcuni caratteri come "equivalenti". Questo impatta ovviamente sulle possibilità di registrazione (vedi sotto): tendenzialmente si può dire che i nomi a dominio contenenti caratteri equivalenti non possono venire registrati, che devono venire registrati a forza dal titolare del nome canonico, o che possono venire registrati da quest'ultimo (il caso "possono venire registrati da chiunque" non si dà, perché allora non avrebbe nemmeno senso creare l'equivalenza!)
Ecco i problemi che sorgono:

Come fare le equivalenze per gli ideogrammi. Non credo ci siano così tanti esperti da fare una tabella di equivalenza pratica: forse conviene aspettare che qualche altro registro si metta a spiegare lui come fare.
Che equivalenze fare? Anche solo rimanendo sulle lettere latine, pensiamo al carattere "a". Anche rimanendo in ISO-Latin-1, abbiamo "a", "à", "á", "ä", "â", "ã", "å". Devono entrare tutte in una classe? C'è una classe con la sola "a", e una con tutte le altre lettere? Ci si limita a mettere in un'unica classe i due caratteri con l'accento? Ricordatevi che in una parola tipica ci sono molti caratteri con possibili equivalenze, e che il numero di combinazioni cresce a dismisura.

4. Impatti prevedibili con l'introduzione degli IDN

Ho già fatto vedere che le varie scelte hanno un impatto sulle nuove registrazioni. Ma occorre anche tenere a mente i problemi legati all'introduzione dei nuovi nomi, e il loro impatto con quelli già registrati. Di nuovo, ecco le varie scelte che si possono fare.

partire in quarta: tutti i nomi vengono resi immediatamente disponibili. La cosa non mi piace per nulla, perché si rischia un assalto alla diligenza come a fine 1999, ed espone al rischio di ricorsi da parte di chi si trova il nome che a suo tempo avrebbe voluto registrare preso da un accaparratore. Forse le PDR servirebbero, ma il danno di immagine è enorme.
un sunrise period: Si dice che per X giorni a partire dalla data di inizio di accettazione di nomi IDN, solo i titolari di nomi "equivalenti" possono (eviterei di costringerli a farlo, anche se fosse a titolo gratuito!) registrarli. Per definizione non possono esserci due nomi distinti equivalenti a uno IDN (è l'opposto che è vero), quindi non ci sono problemi da quel punto di vista: è anche possibile registrare da subito nomi "nuovi", e insomma questa è la soluzione che preferisco. I problemi che vedo sono la definizione dell'equivalenza, oltre naturalmente alla sua implementazione pratica nella procedura della RA. È evidente che in questo caso occorre avvisare i registratari dei nomi a dominio della possibilità di registrazione delle varianti.

sunrise period con prenotazione: funziona come il precedente, ma con la possibilità di chiedere la registrazione di un nome la cui versione equivalente è già stata registrata da qualcun altro. Se il "prioritario" non è interessato alla registrazione, allora il "prenotato" potrà prenderlo. Il vantaggio di questa soluzione rispetto alla precedente è che il peso delle registrazioni di nomi rimane diluito: prima si salvano tutte e poi si possono lanciare in batch.

assegnazione automatica: sempre con le classi di equivalenza - e i relativi problemi - di cui sopra, si afferma che in assoluto l'unico che possa avere titolo al dominio IDN è chi ha il dominio "equivalente". Mi sembra un inutile blocco di nomi, anche perché in futuro le confusioni tra i nomi a dominio aumenteranno.

blocco automatico: ancora con le classi di equivalenza di cui sopra, se c'è un nome registrato è impossibile registrarne uno "equivalente". La cosa potrebbe andare bene solo nel caso in cui si permetta la sostituzione di un nome a dominio: si rinuncia a universita.it per avere università.it. Mi pare però che il gioco non valga la candela, e allora tanto vale usare l'assegnazione automatica.

Vorrei ancora stressare un punto molto importante: le regole di equivalenza devono essere verificabili automaticamente, sia nel caso del sunrise period che nel blocco di registrazioni. Altrimenti il costo per la RA sarebbe troppo alto. Questo non significa che le regole debbano essere inutilmente generali: ad esempio, si potrebbe dire "se il nome a dominio finisce con una vocale, si ritengono equivalenti le forme con questa vocale accentata". In questo caso, telema.it e telèma.it non sarebbero equivalenti, ma universita.it e università.it sì. Come ho detto all'inizio, questo documento vuole proprio limitarsi a essere un riferimento: non penso che si possa trovare in quattro e quattr'otto la soluzione perfetta.

Questo documento è stato redatto da Maurizio Codogno
Versione 1.00, 24 ottobre 2003