[atlarge-discuss] Support des noms de domaine multinationaux

["J-F C. (Jefsey) Morfin" <jefsey@club-internet.fr>]

Comme vous le savez l'IETF est en train de finaliser une position sur les
noms de domaines multinationaux. Ceci est fait par le groupe de travail
WG-IDN
http://ietf.org/html.charters/idn-charter.html.

Le scope de ce groupe de travail inclut la mission de documenter l'impact
des propositions (pluriel) sur les développeurs d'applications et les
utilisateurs et administrateurs du DNS. Il précise aussi qu'il ne doit en
rien affecter les opérations du DNS.

J'ai tenté de participer à ce groupe de travail, non en tant que
proposant, mais en tant que témoin des développeurs d'application et des
utilisateurs et administrateurs du DNS. Ceci correspond dont à la fois à
mes intérêts @large  (je suis chargé du WG-NetSys dans la structure
@large - et france@large) et aux préoccupations que je partage avec les
autres fondateurs de l'initiative européenne d'Eurolinc pour le
multiliguisme et les langues Européennes sur l'Internet.

D'une façon plus générale ce document correspond pour les utilisateurs au
passage, irreversible une fois officiellement engagé dans la pratique, de
l'Internet américain à l'internet multinational. C'est donc la maturité
culturelle, lingusitique, quotidienne du support de la société de
l'information. Ce peut être une réussite de développement durable, ou un
Babel à la puissance "n". 

Nous sommes tous concernés. La différence tient a peu de choses
auxquelles nous pouvons contribuer. L'orientation Babel est l'orientation
actuelle, mais la prise de conscience est tout à fait possible.

Je documente en annexe (en HTML pour plus de lisibilité) :

A.

      

les problèmes que
j'ai rencontrés
B.

      

la bonne solution
partielle proposée par le WG-IDN
C.

      

l'attitude générale
du WG face aux propositions
D.

      

ma conclusion de
cette participation
E.

      

la proposition d'une
contribution sérieuse concertée

Je vous remercie de vos commentaires et de votre participation éventuelle
qui pourrait s'organiser via une mailing liste.
jfc

ANNEXE

A.      J'ai rencontré sept problèmes principaux :

1.

      

l'idée que ce
qui est International est "tout le possible" et non
l"'universellement commun" : non pas chaque langue se
retrouvant sous un jeu de caractères réduit commun, mais l'obligation de
tous les mots mélangés de toutes les langues.

2.

      

un consensus mou
(que je partage totalement) sur l'idée que la solution utilisée par le
DNS sera utilisée progressivement partout où une base de données "à
la DNS" (indexation multilingue) sera utilisée (donc un processus
fondamental au multilinguisme) mais aucune relation approfondie avec des
groupes de travail externes sur le sujet.

3.

      

une absence
d'analyse de la nature du nom de domaine pourtant devenue inévitable et
pratiquement imposée par l'énoncé du charter. Une analyse qui est
d'ailleurs comprise par cetains membres, mais dont l'impact serait sans
doute trop important.

4.

      

l'introduction d'une
seconde hiérarchie (DNs actuels et iDNs) dans le plan de nommage. Etant
hors de la hierachie du DNS elle conduit à un amoncellement de conflits
possibles . 

5.

      

une absence de mise
en situation opérationnelle : support des registres, mises à jour
d'Unicode, évolution possibles du DNS, brèches ouvertes à de nombreuses
dérives. Le modèle est bon le premier jour, pour le monde entier et pour
l'éternité si personne ne succombe à ses nombreuses tentations. Ensuite
... on verra.

6.

      

une rédaction
difficile à suivre du document global due au souci de surajouter des
"simplifications"  

7.

      

une mission
d'investigation (reporter sur l'impact sur les opérations) que la
procédure IETF ne sait pas gérer, et qui réclame donc de la part des
concernés (nous : les développeurs, utilisateurs, registres de tous
niveaux) de rentrer dans le processus IETF, sinon le WG ne pourra pas
remplir pleinement son rôle, et l'IETF sa réflexion, et nous ne pourrons
qu'en souffrir.

B.      Donne solution partielle prose par le WG-IDN

J'ai aussi rencontré une solution technique simple qui permet de
faire correspondre à pratiquement tout script Unicode un label lisible
par le DNS grâce à une préparation du script Unicode (comme par exemple
tout  mettre en minuscules) et un transcodage donnant deux ascii
pour un unicode.

C.      Attitude du WG-IDN

La réponse sympathique de membres du WG à mes interventions (ou à ma
perturbation ; car parfois très maladroites :  c'est la première
fois que je participe à l'IETF) est assez claire :

1.

      

à ma proposition de
mettre en bon ordre : j'étais le seul à me plaindre car ils sont ... les
rédacteurs. Le souci de répondre est évident mais mon intervention est
tardive, mon analyse plus globale et ils ne voient pas bien pourquoi
changer ce qu'ils comprennent et ont donc tendance à rajouter des détails
que de synthétiser. Cela est normal.

2.

      

le manque de
l'analyse globale qu'aurait entraînée une mise à plat avec les
développeurs et les utilisateurs ne conduit pas à la différentiation
entre l'aspect software (nom de domaine pointeur vers une adresse IP) et
l'aspect brainware (nom de domaine mnémonique pour l'utilisateur). Ceci
rend difficile une bonne compréhension de la différence entre la version
ascii (pointeur software) et Unicode (mnémonique brainware) des scripts.
En particulier quelle est la référence légale, bien plus de gens et de
processus allant voir et utiliser la version ascii. Les implications
légales et opérationnelles sont pourtant fondamentales.

3.

      

j'ai tenté de
documenter la position d'un développer, d'un utilisateur et d'un
administrateur DNS par mon expérience et mes applications personnelles
(cf. le scope). Manifestement la réponse est : "hors sujet pour la
procédure IETF mais cela montre que tu es dans le coup, fais un draft
pour la conclusion technique".

D.      Ma conclusion est que :

-       

le
transcodage proposé est la solution qui devrait être adoptée.
Convenablement encapsulée dans l'Internet elle ne devrait d'ailleurs pas
porter à conséquence : c'est une simple conversion qui devrait pouvoir
être changée de façon transparente.

-       

le
reste est à revoir en bon français/anglais dans le respect du DNS et de
son utilisation réelle. Pour cela une aide concertée est à apporter à
l'IETF.

L'alternative est le cauchemar. Dès que l'ensemble des noms de domaine et
labels ne seront pas saisis manuellement par le Registra d'un TLD, rien
ne permettra d'être sur qu'un nom de domaine va résoudre de la façon dont
on croit qu'il est écrit, rien ne permettra de s'assurer qu'un nom de
domaine sera lisible aux utilisateurs, rien ne permettra d'empêcher que
les noms de domaine n'aient (sous la responsabilité légale du name
Manager) un double sens lié à leur double script parallèle (Unicode et
ASCII), rien n'empêchera que puissent être créés facilement autant
d'espaces de nommage différents où des entrées inventives auront pour
certains des sens contrevenant aux droits IP ou à la loi.

E.      Apporter une contribution concertée et utile

Je pense qu'une proposition "utilisateur" est assez simple
si l'on reprend le problème à la base, c'est à dire sans tenir compte des
intérêts de Verisign, de iDNs et des autres vendeurs initiaux. Donc en
raisonnant simplement au support du multilinguisme par le DNS et les
applications liées (mail, etc.). Puis, une fois cette solution dégagée
(elle devrait utiliser les outils validés par le WG), de la valider en
voyant comment elle peut aussi supporter les noms de domaines déjà
vendus, éviter les problèmes qu'ils ont rencontrés et permettre une
évolution de tous les éléments concernés (Unicode, DNS, applications,
plug-ins etc.).

Ayant déjà présenté la solution que j'endends utiliser pour mes moteurs
de recherche qui croisent les besoins DNS et les besoins annuaire (Whois,
LDAP, bases de données) et voyant que son support par l'AFNIC, .eu etc.
ne demanderait pas plus d'une journée de travail et de test, je pense que
l'on peut facilement mettre au point une réponse initiale.

Ensuite des considérations plus avancées seront nécessaires, mais elles
correspondent à une évaluation opérationnelle/marketing plus poussée
(questionnaire utilisateurs envisagé lors de la rencontre avec l'AFNIC).
Ceci se traduirait en terme IETF par ;

1.      rencontre de débroussaillage du sujet - 1 heure ou deux

2.      présentation de ma solution comme point de départ et lancement de sa critique point par point

3.      sa critique par mail

(une répétition éventuelle du cycle une ou deux fois, avec plus de
gens)

4.      une petite journée de rédaction (anglais)

5.      une critique par mail

6.      revue par des externes

7.      envoi ou abandon

Le processus de standardisation étant engagé et l'IETF étant soumis
à des pressions commerciales et politiques souvent internes, ce travail -
si certains voulaient s'y enager - doit se faire ou au moins s'annoncer
trés rapidement. 


---------------------------------------------------------------------
To unsubscribe, e-mail: atlarge-discuss-unsubscribe@lists.fitug.de
For additional commands, e-mail: atlarge-discuss-help@lists.fitug.de