le DNS et la Corse Re: La monnaie de Ti-Connerie (Re: Fu2 avoué est à demi pardonné ( éta it sur fme))
Nicolas Krebs
news:4856a3a4$0$19295$426a...@news.free.fr
> >> PS : csc dans i...@csc.csc, c'est bien pour CorSiCa non ?
> csc est de mémoire un tld envisagé au cas où la Corse deviendrait
> indépendante non ?
Et aussi si elle ne devient pas indépendante. Coïncidence, je consultais
justement hier des documents à ce sujet (impliquant un autre internaute
pénible). Edmond Simeoni ( http://fr.wikipedia.org/wiki/Edmond_Simeoni )
est impliqué.
Alors que .cat ( http://fr.wikipedia.org/wiki/.cat ) utilise le code
ISO 639-2 « cat », « .csc » n'utilise pas le code ISO 639-2 du corse
(cos), et de plus n'est pas listé dans http://en.wikipedia.org/wiki/.bzh .
Antoine Leca
> Christophe Raverdy écrivit dans l'article
> news:4856a3a4$0$19295$426a...@news.free.fr
>
>>>> PS : csc dans i...@csc.csc, c'est bien pour CorSiCa non ?
>
>> csc est de mémoire un tld envisagé au cas où la Corse deviendrait
>> indépendante non ?
>
> Et aussi si elle ne devient pas indépendante.
SURTOUT tant qu'elle ne devient pas indépendante.
Si elle le devenait, a priori l'agence en charge de ISO3166 serait obligée
de trouver un code à deux lettres, et par ricochet l'IANA devrait l'adopter
comme ccTLD.
> Alors que .cat ( http://fr.wikipedia.org/wiki/.cat ) utilise le code
> ISO 639-2 « cat »
Mmmm.
.cat est un gTLD (comme .gov ou .org), sponsorisé par une agence ([ca]
http://www.domini.cat/qui_som.html) qui se réclame des « Pays catalans », où
il est courant d'utiliser CAT comme symbole distinctif.
Le fait que ce soit aussi le code choisi par la Bibliothèque du Congrès pour
le catalan (et donc le code ISO 639-2) n'est donc qu'une coïncidence non
fortuite.
Dans le même genre, les Français sont désignés dans les retransmissions
sportives par le code FRA, qui se trouve être le même que celui adopté
(conjointement) pour la langue française dans ISO 639-2... Mais l'autre n'a
pas entraîné l'un !
> « .csc » n'utilise pas le code ISO 639-2 du corse (cos)
Mais par contre utilise bien le code (non officiel) amplement utilisé sur
les voitures...
Et les Corses ont peut-être plus d'affinités avec un code qu'ils voient tous
les jours, plutôt qu'avec un code inventé à Washington...
Antoine
Nicolas Krebs
[...]
> Et les Corses ont peut-être plus d'affinités avec un code qu'ils voient tous
> les jours, plutôt qu'avec un code inventé à Washington...
Merci pour toutes ces précisions.
C'est surtout pour éviter les collisions de suffixes dnsà trois lettres que
je considère l'ISO 639-2/3.
Le ministère français de l'économie, de l'industrie et de l'emploi organise une
consultation (dont les contributions seront rendus publiques) sur les suffixes
dns français
http://www.minefe.gouv.fr/discours-presse/discours-communiques_finances.php?type=communique&id=1443&rub=1
http://www.telecom.gouv.fr/rubriques-menu/organisation-du-secteur/textes-reglementaires/consultations-appels-candidatures/consultations-ouvertes/modalites-gestion-du-domaine-internet--dot-fr-extensions-outre-mer-1652.html
La section 2.1.3 du questionnaire
http://www.telecom.gouv.fr/fonds_documentaire/consultations/08/questionnairendinternet.pdf
commence par
« Création de nouveaux domaines internet "génériques"
Après la création récente du domaine internet ".cat" destiné à la
communauté linguistique et culturelle catalane, différents projets
proposent la création de domaines internet "génériques", directement liés
à un territoire (ex. ".berlin") ou destinés à une communauté
d'utilisateurs ayant un lien culturel avec un territoire (ex. ".bzh"). »
D'après http://fr.wikipedia.org/wiki/.%D1%80%D1%84 la Russie serait sur le
point de démarrer un nouveau suffixe complémentaire au .ru. Qui connait,
qui peut confirmer ?
Patrick Mevzek
> D'après http://fr.wikipedia.org/wiki/.%D1%80%D1%84 la Russie serait sur le
> point de démarrer un nouveau suffixe complémentaire au .ru. Qui connait,
> qui peut confirmer ?
L'ICANN discute cette semaine même à Paris, en plus de l'ouverture de
nouveaux gTLDs, d'un « Fast Track IDN ccTLDs » c'est à dire les
transcriptions des ccTLDs actuels en IDN en gros, par une processus à part
de la création des nouveaux gTLDs.
Cf http://www.icann.org/topics/idn/
Donc, c'est dans les tuyaux, mais « sur le point de démarrer » ca me
paraît un peu prématuré. Oh bien sûr ils peuvent tout démarrer de leur
côté (il y a une volonté nationale derrière il me semble avoir récemment
lu une interview du président russe qui voulait cela), mais cela
n'arrivera dans le fichier de zone de la racine tout de suite.
Par contre pour les IDNs en général (ccTLDs ou gTLDs), il y a une révision
en cours du protocole sous-jacent (IDNA) et un certain nombre de personnes
préféreraient que le standard soit mis à jour avant de lancer de nouveaux
IDNs.
Cf par exemple
https://par.icann.org/files/paris/BAA-Paris-IDN-final-23jun08.pdf
C'est sûr que si on était passé à de l'unicode pur dès le début, on n'en
serait pas là :-)
--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
Stephane Bortzmeyer
> D'après http://fr.wikipedia.org/wiki/.%D1%80%D1%84 la Russie serait sur le
> point de démarrer un nouveau suffixe complémentaire au .ru. Qui connait,
> qui peut confirmer ?
J'ai modifié cet article, très contestable.
Stephane Bortzmeyer
> Donc, c'est dans les tuyaux, mais « sur le point de démarrer » ca me
> paraît un peu prématuré.
D'autant plus que le texte actuel sur le « Fast Track IDN » mériterait
plutôt d'être appelé « Track un peu moins Slow que l'autre » Et que,
malgré cela, la tonalité générale à la réunion de Paris n'était pas
enthousiaste.
> Par contre pour les IDNs en général (ccTLDs ou gTLDs), il y a une révision
> en cours du protocole sous-jacent (IDNA) et un certain nombre de personnes
> préféreraient que le standard soit mis à jour avant de lancer de nouveaux
> IDNs.
L'ICANN se sert en effet de cette révision en cours comme prétexte pour
retarder encore les IDN.
> C'est sûr que si on était passé à de l'unicode pur dès le début, on n'en
> serait pas là :-)
On aurait eu d'autres problèmes :-)
Nicolas Krebs
Merci.
Le premier lien dans le corps de l'article renvoie à
http://fr.wikipedia.org/wiki/Domaine_national_de_premier_niveau ,
dont la section « Domaines de complaisance »
http://fr.wikipedia.org/w/index.php?title=Domaine_national_de_premier_niveau&oldid=30577793#Domaines_de_complaisance
parle d'utilisation dévoyée de domaine dns de premier niveau,
caractérisation qui peut àmha être appliquée à l'utilisation du suffixe .tf (TAAF)
à laquelle a pensé vous-savez-qui (voir http://actf.fr/ et
http://alfrance.info/index.php?title=Initiative_ACTF ).
Patrick Mevzek
>> Donc, c'est dans les tuyaux, mais « sur le point de démarrer » ca me
>> paraît un peu prématuré.
>
> D'autant plus que le texte actuel sur le « Fast Track IDN » mériterait
> plutôt d'être appelé « Track un peu moins Slow que l'autre » Et que,
> malgré cela, la tonalité générale à la réunion de Paris n'était pas
> enthousiaste.
Le bureau de l'ICANN vient d'adopter la résolution en question cette
après-midi lors de sa réunion publique.
>> Par contre pour les IDNs en général (ccTLDs ou gTLDs), il y a une
>> révision en cours du protocole sous-jacent (IDNA) et un certain nombre
>> de personnes préféreraient que le standard soit mis à jour avant de
>> lancer de nouveaux IDNs.
>
> L'ICANN se sert en effet de cette révision en cours comme prétexte pour
> retarder encore les IDN.
Comme s'ils avaient besoin de prétexte... :-)
Mais, autant pour les gTLDs, ils peuvent se planquer derrière l'argument «
c'est encore les méchants registres qui veulent se faire de l'argent »,
autant pour les « IDNs ccTLD », certains gouvernements poussent, et
l'ICANN n'est pas franchement connue pour ne pas suivre le GAC.
>> C'est sûr que si on était passé à de l'unicode pur dès le début, on
>> n'en serait pas là :-)
>
> On aurait eu d'autres problèmes :-)
Oui, lesquels ?
(à part devoir mettre à jour tous les logiciels bien étendus, comme ca ce
n'est pas rien :-) ?)
Stephane Bortzmeyer
> Le bureau de l'ICANN vient d'adopter la résolution en question cette
> après-midi lors de sa réunion publique.
A adopté une résolution qui dit que les études vont continuer. Chouette.
>>> C'est sûr que si on était passé à de l'unicode pur dès le début, on
>>> n'en serait pas là :-)
>> On aurait eu d'autres problèmes :-)
>
> Oui, lesquels ?
Il y a plusieurs raisons qui font que ce choix n'a pas été fait au début.
- la première ne vient pas du DNS (qui accepte n'importe quel caractère
depuis des siècles, cf. RFC 2181, section 11) mais des applications qui
gèrent des noms de machines et pour lesquelles la règle (RFC 1123
section 2.1) est en effet bien plus restrictive. Changer cette règle
nécessitait en effet de modifier beaucoup de logiciels.
- mais la seconde est plus subtile : le DNS ne permet pas de recherches
floues. Soit le nom correspond parfaitement à un nom dans la base, soit
NXDOMAIN (No Such Domain). Comme c'est un peu dur pour les utilisateurs,
une canonicalisation est prévue, actuellement uniquement l'insensibilité
à la casse. Elle suffit pour ASCII (encore que pas mal de lecteurs de ce
forum semblent avoir du mal à avaler que montjoie-parapente.es et
montjoie.parapente.es soient deux domaines différents). Pour Unicode,
elle ne serait pas suffisante et il faudrait donc, si on déploie un jour
DNSv2 (100 % Unicode), mettre NFC dans tous les serveurs de noms... (NFC
est un des algorithmes standard de canonicalisation d'Unicode.)
Cette seconde raison est la principale. Même si on choisissait une
approche « table rase » et qu'on fasse DNSv2 en partant de zéro, en
ignorant l'existant, il faudrait résoudre ce problème (voir RFC 5198
pour une façon de le traiter, introduction en
http://www.bortzmeyer.org/5198.html ).
Patrick Mevzek
> Pour Unicode,
> elle ne serait pas suffisante et il faudrait donc, si on déploie un jour
> DNSv2 (100 % Unicode), mettre NFC dans tous les serveurs de noms... (NFC
> est un des algorithmes standard de canonicalisation d'Unicode.)
Cette canonicalisation doit bien être quelque part. Ce n'est donc pas un
autre problème, spécifique à une solution 100% Unicode, mais le même
problème qu'avec la solution actuelle.
Entre avoir cette canonicalisation dans tous
les resolvers/bibliothèques/applicatifs (comme cela a été choisi
actuellement, sauf qu'on a pris la simplification Internet=Web et qu'on
s'est occupé uniquement des navigateurs, pour preuve on arrive seulement
maintenant à des débuts de solution pour les IDNs et le mail) ou l'avoir
seulement dans tous les serveurs de noms autoritaires, je préfère
largement la dernière solution.
Stephane Bortzmeyer
> Cette canonicalisation doit bien être quelque part.
Mais en ASCII, elle éait très simple (ajouter 0x20...). Cela ne gênait
donc personne qu'elle soit dans les serveurs de noms.
> ou l'avoir
> seulement dans tous les serveurs de noms autoritaires, je préfère
> largement la dernière solution.
NFC est autrement plus compliqué que tolower(). Il nécessite des tables
(alors que, en ASCII, la capitalisation peut se faire par une simple
addition). Le mettre dans des serveurs faisant autorité qui reçoivent de
1 000 à 10 000 requêtes par seconde peut faire hésiter.
Patrick Mevzek
> > ou l'avoir
>> seulement dans tous les serveurs de noms autoritaires, je préfère
>> largement la dernière solution.
>
> NFC est autrement plus compliqué que tolower(). Il nécessite des tables
> (alors que, en ASCII, la capitalisation peut se faire par une simple
> addition). Le mettre dans des serveurs faisant autorité qui reçoivent de
> 1 000 à 10 000 requêtes par seconde peut faire hésiter.
Rien n'est gratuit, oui, mais comme aujourd'hui, les IDNs n'ont pas été
déployés simultanément dans tous les TLDs. En commencant par les nouvelles
extensions par exemple, ou de petites zones, on aurait eu des chiffres
pour voir dans quelle mesure cela poserait un problème pour les grosses
zones, comme le .COM
Mais s'il y a au moins une chose pour laquelle je fais confiance à
VeriSign, c'est sa capacité technique à faire évoluer son infrastructure
notamment pour gérer le volume. Ils l'ont dit eux-mêmes en parlant des
DDOS qu'ils ne visaient pas juste une surcapacité x2 ou x3 ...
Et j'imagine qu'on pourrait aussi avoir des puces implémentant
matériellement NFC ou une partie, comme cela existe pour SSL ou d'autres
protocoles.
D'autant que, si j'ai bien suivi le groupe de travail de l'IETF à l'époque,
la situation actuelle n'est sensée être qu'une étape vers une solution
définitive.
Nicolas Krebs
news:g36hak$slo$3...@news.le-studio75.com
> Coïncidence, je consultais
> justement hier des documents à ce sujet (impliquant un autre internaute
> pénible).
Avis dudit pénible (qui se targue de défendre la langue française contre
les hordes anglophones ignorantes auprès de la normalisation des noms de
domaine DNS) sur l'accentuation des majuscules :
| "e", "é", "è", "ê", "ë" ont leurs majuscules absentes du clavier AZERTY
| et notées "E"
Arhhh !