Création de TLD en unicode par l'ICANN

[Jean-Marc Desperrier]

L'ICANN a décidé le mois dernier de créer les premiers domaine de
premier niveau (TLD) en unicode. Il devient du coup possible de créer
des noms de domaine entièrement en caractères chinois.

Ce sont les domaines :
- 中国 et 中國 attribués à la chine (CNNIC)
- 香港 pour Hong-Kong
- 台灣 et 台湾 pour Taiwan

Le texte de la résolution de l'ICANN:
http://www.icann.org/en/minutes/resolutions-25jun10-en.htm#2

Curieusement le Japon n'a pas demandé le sien, et il reste à voir si
d'autres alphabets que les kanji chinois seront concernés dans le futur.

L'annonce s'est un peu perdue dans les communiqués focalisés plutôt sur
la création simultanément du domaine xxx.

[Xavier Roche]

Post by Jean-Marc Desperrier
- 中国 et 中國 attribués à la chine (CNNIC)

Pour précision, concrètement, cela reviens à ajouter un ".xn--fiqs8s" ou
un ".xn--fiqz9s" (etc.). Il n'y a aucune modification nécessaire côté
infrastructure (c'était l'idée de IDN au passage: permettre la gestion
Unicode au niveau le plus haut, càd affichage et en entrée) ; et
notamment les URL resteront sous la forme .xn--*.

[Julien ÉLIE]

Bonjour Jean-Marc,

L'ICANN a décidé le mois dernier de créer les premiers domaine de premier niveau
(TLD) en unicode. Il devient du coup possible de créer des noms de domaine
entièrement en caractères chinois.
- 中国 et 中國 attribués à la chine (CNNIC)
- 香港 pour Hong-Kong
- 台灣 et 台湾 pour Taiwan

Merci pour l'info !
J'avais aussi noté il y a quelques jours ce billet de Stéphane :

http://www.bortzmeyer.org/domaines-synchrones.html

au sujet d'une synchronisation DNS entre .台灣 et .台湾 par exemple.

[JV Gruat]

[suivi fscc]

Post by Jean-Marc Desperrier
L'ICANN a décidé le mois dernier de créer les premiers domaine de
premier niveau (TLD) en unicode. Il devient du coup possible de créer
des noms de domaine entièrement en caractères chinois.
- 中国 et 中國 attribués à la chine (CNNIC)
- 香港 pour Hong-Kong
- 台灣 et 台湾 pour Taiwan
http://www.icann.org/en/minutes/resolutions-25jun10-en.htm#2
Curieusement le Japon n'a pas demandé le sien, et il reste à voir si
d'autres alphabets que les kanji chinois seront concernés dans le futur.
L'annonce s'est un peu perdue dans les communiqués focalisés plutôt sur
la création simultanément du domaine xxx.

Merci pour l'information !
C'est effectivement fascinant de taper dans la barre de recherche
中央电视台.中国 - zhōng yāng diàn shì tái.zhōng guó - et de se retrouver
sur le site de la télévision chinoise ... à l'adresse
http://www.cntv.cn/ , ceci dit.
Entre-temps, on voit fugacement apparaître le décodage de l'adresse en
caractères, trop vite cependant pour pouvoir la déchiffrer. Quelqu'un
sait-il comment un nom de domaine en .中国 est transformé en .xn-fiqs8S?
Sinon, m'appelant par décision professorale 圭亚 en chinois, j'ai
vérifié: 圭亚.中国 est disponible, et je pourrais l'acquérir pour un peu
moins de 50 dollars l'année - mais, outre le prix, je me demande un peu
comment le faire héberger ... Y a-t-il un décodage officiel qui serait
reconnu par un hébergeur français ?

[JV Gruat]

[Retour sur fcnu]

http://punycoder.com/

Merci infiniment - je suis allé voir sur p.o.h.support si l'hébergement
de xn--jlqv2s.xn--fiqs8s serait envisageable.

Pas trouvé trop d'informations cependant sur pourquoi 圭 devient jlmq,
ceci dit. Avez-vous plus de détails sur la construction de l'algorithme?
Pourquoi en fallait-il un autre que celui générant les U+ ou les &# ?

[Xavier Roche]

Post by JV Gruat
Pas trouvé trop d'informations cependant sur pourquoi 圭 devient jlmq,
ceci dit. Avez-vous plus de détails sur la construction de l'algorithme?

C'est dans la RFC 3492 (http://tools.ietf.org/html/rfc3492), mais ça
donne mal à la tête

Post by JV Gruat
Pourquoi en fallait-il un autre que celui générant les U+ ou les &# ?

Il fallait ne rien toucher à l'existant ; c'est à dire au DNS. Et donc
de limiter aux caractères légaux du DNS (lettres, insensible à la casse,
chiffres, tiret, et c'est tout)

[Olivier Miakinen]

Post by Xavier Roche

Post by JV Gruat
Pas trouvé trop d'informations cependant sur pourquoi 圭 devient jlmq,
ceci dit. Avez-vous plus de détails sur la construction de l'algorithme?

C'est dans la RFC 3492 (http://tools.ietf.org/html/rfc3492), mais ça
donne mal à la tête

Oui. Ceux qui ont eu le courage de le lire sauraient-ils me dire s'il y
a possibilité de surencoder de l'Ascii en Punycode ? La seule lecture du
chapitre 8 « Security Considerations » me fait croire que non, mais
j'aurais aimé en être sûr.

Post by Xavier Roche

Post by JV Gruat
Pourquoi en fallait-il un autre que celui générant les U+ ou les &# ?

Il fallait ne rien toucher à l'existant ; c'est à dire au DNS. Et donc
de limiter aux caractères légaux du DNS (lettres, insensible à la casse,
chiffres, tiret, et c'est tout)

Du coup, cela devrait permettre aussi aux hébergeurs de gérer un
domaine tel que xn--jlqv2s.xn--fiqs8s sans se poser trop de questions.
En principe.

[Jean-Marc Desperrier]

Post by Olivier Miakinen
[...]
Oui. Ceux qui ont eu le courage de le lire sauraient-ils me dire s'il y
a possibilité de surencoder de l'Ascii en Punycode ? La seule lecture du
chapitre 8 « Security Considerations » me fait croire que non, mais
j'aurais aimé en être sûr.

Clairement il n'est pas possible d'encoder *légalement* de l'ASCII en
Punycode.
Je pense que ta question est plus précisément s'il existe des valeurs
illégales qui, si elles ne sont pas détectées correctement comme
illégales, peuvent être décodées comme de l'ASCII en leur appliquant les
règles du Punicode.

C'est le cas par exemple en UTF-8 et ça a donné à une époque de gros
problèmes à travers le surencodage de "/" dans les chemins de fichier
(utilisé avec ".../" pour fabriquer un chemin relatif qui sort de
l'emplacement dans l'arborescence à partir duquel il est appliqué sans
que ce soit détecté avant le décodage UTF-8).

Et bien bonne nouvelle, la réponse est non ! Et c'est détaillé ici :
6.2 Decoding procedure

[...] checking whether n is a basic
code point) can be omitted if initial_n exceeds all basic code points
(which is true for Punycode), because n is never less than initial_n.

Les paramètres de Punicode disent que : initial_n = 128 = 0x80
Et on ne peut pas décoder quoi que ce soit correctement sans utiliser la
valeur correcte de initial_n.

Du coup j'ai compris pourquoi c'est aussi compliqué cet encodage :-)

'n' qui représente la valeur de point de code du prochain caractère à
insérer est une valeur monotone croissante qui commence à 0x80 ce qui a
pour conséquence pratique que dans une chaîne Punicode les caractères
encodés sont stockés dans l'ordre de leur point de code, et non pas
celui où ils apparaissent.
Il y a donc deux informations à stocker pour chaque caractère encodé :
le delta (forcément positif) avec le point de code précédent
(éventuellement et assez souvent zéro), et l'index où l'on va l'insérer
dans la chaîne.

Post by Olivier Miakinen
[...]
Du coup, cela devrait permettre aussi aux hébergeurs de gérer un
domaine tel que xn--jlqv2s.xn--fiqs8s sans se poser trop de questions.
En principe.

Oui ça doit marcher. Il faut cependant noter qu'au niveau des
registry/registrar (évidemment les hébergeurs ne sont pas tenus par
cela), il est interdit d'accepter une chaîne qui correspond à un système
d'écriture pour lequel ils n'ont pas de procédure en place pour éviter
les attaques par homographes et donc eux *doivent* se poser des
questions. En principe ;-)

[JV Gruat]

Post by Jean-Marc Desperrier
Oui ça doit marcher. Il faut cependant noter qu'au niveau des
registry/registrar (évidemment les hébergeurs ne sont pas tenus par
cela), il est interdit d'accepter une chaîne qui correspond à un système
d'écriture pour lequel ils n'ont pas de procédure en place pour éviter
les attaques par homographes et donc eux *doivent* se poser des
questions. En principe ;-)

Effectivement, pour obtenir l'enregistrement de 圭亚。com 〔j'ai renoncé
à 圭亚。中国, les justificatifs à fournir étaient hors de portée〕j'ai
dû recourir aux services de Domaindiscount24, organisme agréé ou
recommandé par -sais pas comment il faut dire - par www.cnnic.cn,
online.net refusant de se propnoncer sur la disponibilité de tels noms
de domaine - en caractère ou en punycode.
A noter par ailleurs que si IE 8 reconnaît http://圭亚。com et s'y
tient, Firefox transforme immédiatement en http://xn--jlqv2s.com/.
Pour l'hébergement, pas de problème par contre avec online, dès lors que
l'on utilise une adresse en xn--
Par contre, il ne semble pas que l'on puisse avoir la même flexibilité
au niveau des dossiers ou des noms de pages - un dossier ./xn--siq2a91a/
n'apparaît pas lorsque l'on tape en adresse http://圭亚。com/为什么/

[Xavier Roche]

Post by JV Gruat
Par contre, il ne semble pas que l'on puisse avoir la même flexibilité
au niveau des dossiers ou des noms de pages - un dossier ./xn--siq2a91a/
n'apparaît pas lorsque l'on tape en adresse http://圭亚。com/为什么/

Punycode n'est utilisable que dans les segments des noms de domaines ;
et encore, des restrictions existent (caractères "non confusables", etc.)

Pour les noms de fichiers, il suffit en règle générale d'utiliser
simplement UTF-8 ; même si aucun encodage n'est standardisé pour l'URL
[de mémoire les caractères non ascii sont même suspects - il faudraity
aller voir la BNF], la présence d'UTF-8 est généralement bien acceptée
(affichage et saisie)

[Jean-Marc Desperrier]

Post by Xavier Roche
Pour les noms de fichiers, il suffit en règle générale d'utiliser
simplement UTF-8 ; même si aucun encodage n'est standardisé pour l'URL
[de mémoire les caractères non ascii sont même suspects - il faudraity
aller voir la BNF], la présence d'UTF-8 est généralement bien acceptée
(affichage et saisie)

Globalement, il est recommandé d'encoder en UTF-8, puis de
pourcent-encoder tous les caractères qui ne sont pas de l'ASCII pur.

http://tools.ietf.org/html/rfc3986
the data should first be encoded as octets according to the UTF-8
character encoding [STD63]; then only those octets that do not
correspond to characters in the unreserved set should be percent-
encoded. For example, the character A would be represented as "A",
the character LATIN CAPITAL LETTER A WITH GRAVE would be represented
as "%C3%80"

Petit à petit, les navigateurs et serveurs web se rattachent à ce
standard pour les URL. La conversion est faite à la volée par rapport à
ce que l'on tape dans la barre d'adresse.