Noms de domaine linguistiques
Un article de Wiki.
france@large souhaite que l'ICANN perdure dans son rôle stabilisateur de gestionnaire du "legacy américain" (cf. accord de Tunis) et de leader IGF dans la coopération renforcée multipartieprenante avec les homologues régionaux et nationaux qui vont en résulter (nous avons déjà un vote du Parlement européen pour un euro-IGF: l'ICANN y sera-t-elle ? à quel titre ? Idem pour l'IGF-FR ?).
Sommaire |
Préoccupations de l'IETF
Nous sommes actuellement confrontés au souci nouveau de l'IETF de ne pas porter le chapeau de la catastrophe technique de l'IDNA. Vint Cerf a été le premier à poser le problème, sur la liste d'Harald Alvestrand (Google, Membre des Board ICANN et Unicode) pour la révision d'IDNA. Ceci résulte de l'impossibilité actuelle et probablement finale de donner une confiance technique suffisante en IDNA, malgré l'acharnement loyal de Klensin. Ceci résulte en grande partie de la manière dont est utilisé Unicode dans une fonction réversible (codage/décodage) pour lequel ce code n'a pas été prévu. Lors du dernier débat public, la position de Thomas Narten (acceptée par Chris Disspain) refile à l'ICANN l'"implémentation technique" (de quoi peut-il s'agir puisque tout a été fait pour que le DNS ne change pas et que les ccTLD n'aient plus qu'à ne plus traduire les choses en Anglais?) et donc la responsabilité de l'échec.
C'est de bonne guerre, car l'ICANN viole IDNA qui a été développé sous condition qu'il n'y ait pas d'IDNccTLD (demande Verisign/ICANN). Cela leur permet aussi de cacher ce qui y est mal ficelé (détaillé dans la RFC 4690 de l'IAB) et leurs deux erreurs architecturales fondamentales : l'Internet n'a pas de couche présentation OSI et IDNA ne respecte pas le end2end.
Préoccupation Unicode/Google
Harald Alvestrand a aussi un deuxième canard boiteux à faire endosser à l'ICANN: la fameuse et impossible "table" dont Bertrand de la Chapelle leur mit le couteau sous la gorge. Il en a besoin pour que son registre de langues et son "internationalisation" continuent à s'opposer à ISO 3166, maintenant que
- son utilisation de Michael Everson pour en décider (Revue du Registre Linguistique où est documenté la liste "IDN 3166" votée par le Board de l'ICANN à la demande de Paul Twomey à São Paulo) ne tient pas la route,
- la proposition de Debbie Garside de la lui créer à l'ISO a été refusée par le vote du TC46 où son lobbying n'a reçu que son propre soutien (UK) et de l'Irlande (Michael Everson) [et grâce à des délais de vote accordé après la clôture, des USA].
Choix possibles
Le choix de l'ICANN est simple :
- ou la "globalization" d'Unicode = internationalisation du réseau, localisation des terminaux, classement intégré des langues.
- ou le multilinguisme du SMSI = égalité des langues, cultures, et souverainetés, selon ISO 3166.
Importance de ISO 3166
Il convient de se souvenir qu’ISO 3166 :
- est la référence choisie en 1978 pour le réseau international par l'équipe française de Tymnet pionnière du réseau international, passée à Postel en 1984 (RFC 920), confirmée par lui (RFC 1591) en 1994, puis par l'ICANN en 1999 (ICP-1) qui dit en 2001 en retirer sa légitimité (ICP-3). 30 ans, cette année, de stabilité de l'écosystème numérique mondial et la cohérence de tout le système ISO et du modèle OSI pour supporter l'Internet.
- fournit le nom officiel français et anglais des pays, leur code 2 et 3 lettres, 3 chiffres, leur langue(s), leur écriture(s), leur(s) nom(s) romanisé(s) dans ces langues parce que l'ICANN n'a pas demandé plus.
- est - en corrélation avec les positions de l'OMC sur les obstacles techniques au commerce et le besoin d'une position de l'OMPI - le paradigme d'un support technique du multilinguisme qui n'est pas complexe en soi, mais demande une analyse, concertation et un rodage qui relèvent de l'ISO 3166/MA où, pour cette raison, l'ICANN est présente - mais sans demande particulière jusque fin 2007. Cette analyse est aussi supportée par l'effort de standardisation ouverte libre 3166-4 [1] que france@large soutient dans le cadre de l'Intertest [2].
Evolution nécessaire
L'Internet Multilingue passe nécessairement pas une couche présentation virtuelle. C'est à dire de multiples façons indépendantes de faire percevoir l'Internet aux terminaux. John Klensin et l'ICANN avaient envisagé les classes (qui pouvaient rester sous contrôle IETF/ICANN dans une certaine mesure), mais les navigateurs ne les supportent pas. Le "plan (IDN)A" tente de le faire au niveau applicatif.
La coalition dynamique sur les IDN IDNC a suscité la réflexion quant à un "plan (IDN)B" comme alternative technique au "plan (IDN)A". Quoi qu'il en soit, des MLDN stables signifient architecturellement soit un internet pluriel, soit un internet balkanisé.
Dans les deux cas, l'ICANN perd son rôle de monopole de fait actuel. Dans le premier, elle en gagne un autre, peut se privatiser comme le souhaite Paul Twomey, etc. Toutefois, il lui faut avoir des idées nouvelles, "rétrécir au nommage", et se consolider comme un leader affirmé d'une hétérarchie au lieu de se vouloir être le coordinateur contesté d'une unique hiérarchie. Il parait donc urgent pour elle que chacun en prenne conscience, et préserve la stabilité de l'ensemble par la "coopération renforcée" des parties prenantes unanimement votée à Tunis.
Fast Track
Sous la pression l'ICANN s'est engagée elle-même dans l'expérimentation qu'elle demandait à l'IETF en 2001 (Document ICP-1). Nous avons toutefois une approche maladroite du ccNSO qui viole les principes établis par l'ICANN (france@large a participé au projet français communautaire dot-root [3] et de ce fait rencontre des difficultés dont se projet avait été préservé. L'ICANN est de ce fait menacé sous la pression de la vitesse :
- de voir Fast Track très mal perçu par ceux qui ne pourraient y participer.
- d'être obligée d'entériner à l'avenir des choix de Fast Track pris sans l'expérience et l'ouverture nécessaire.
- de s'embarquer dans une stratégie de pression contractuelle sur les ccTLD qui ne peut que pousser à une balkanisation qu'elle cherche précisément à éviter.
ML-DNS
ML-DNS est la proposition simple de rechercher un DNS qui apporte la même qualité de service à toutes les langues que le DNS standard à l'anglais et à l'ascii. Elle est étudiée par le CX ML-DNS
