je me suis aperçu que l'on pouvait créer des noms de domaines avec
caractères spéciaux à condition qu'un encodage soit effectué.
ex : café.com = xn--caf-dma.com
Pour les caractères accentués, tout a l'air ok.
Mais pour d'autres caractères...
Je cherche pour le signe plus (+).
Est ce possible ?
ex : canal+.fr = ?
"Adrien G." a écrit dans le message de news: 41ef6035$0$22631$
Salut
je me suis aperçu que l'on pouvait créer des noms de domaines avec caractères spéciaux à condition qu'un encodage soit effectué. ex : café.com = xn--caf-dma.com
Attention, ce n'est tjrs pas normalisé partout et il y'a énormément de choses qui ne fonctionnent pas (a commencer par les plateformes mail)
Encore faut il également que les zones gerent cet encodage .. ce qui n'est pas le cas de .FR me semble-t-il.
"Adrien G." <adrien.pademail@nospam.net> a écrit dans le message de news:
41ef6035$0$22631$636a15ce@news.free.fr...
Salut
je me suis aperçu que l'on pouvait créer des noms de domaines avec
caractères spéciaux à condition qu'un encodage soit effectué.
ex : café.com = xn--caf-dma.com
Attention, ce n'est tjrs pas normalisé partout et il y'a énormément de
choses qui ne fonctionnent pas (a commencer par les plateformes mail)
Encore faut il également que les zones gerent cet encodage .. ce qui n'est
pas le cas de .FR me semble-t-il.
"Adrien G." a écrit dans le message de news: 41ef6035$0$22631$
Salut
je me suis aperçu que l'on pouvait créer des noms de domaines avec caractères spéciaux à condition qu'un encodage soit effectué. ex : café.com = xn--caf-dma.com
Attention, ce n'est tjrs pas normalisé partout et il y'a énormément de choses qui ne fonctionnent pas (a commencer par les plateformes mail)
Encore faut il également que les zones gerent cet encodage .. ce qui n'est pas le cas de .FR me semble-t-il.
r.r.
Adrien G. wrote:
Salut
je me suis aperçu que l'on pouvait créer des noms de domaines avec caractères spéciaux à condition qu'un encodage soit effectué. ex : café.com = xn--caf-dma.com
Pour les caractères accentués, tout a l'air ok. Mais pour d'autres caractères... Je cherche pour le signe plus (+). Est ce possible ? ex : canal+.fr = ?
La spécification pour les noms de domaines est (rfc std13):
<letter> ::= any one of the 52 alphabetic characters A through Z in upper case and a through z in lower case
<digit> ::= any one of the ten digits 0 through 9 ****************************
Bref pas de caractères accentués ni de +.
Adrien G. wrote:
Salut
je me suis aperçu que l'on pouvait créer des noms de domaines avec
caractères spéciaux à condition qu'un encodage soit effectué.
ex : café.com = xn--caf-dma.com
Pour les caractères accentués, tout a l'air ok.
Mais pour d'autres caractères...
Je cherche pour le signe plus (+).
Est ce possible ?
ex : canal+.fr = ?
La spécification pour les noms de domaines est (rfc std13):
je me suis aperçu que l'on pouvait créer des noms de domaines avec caractères spéciaux à condition qu'un encodage soit effectué. ex : café.com = xn--caf-dma.com
Pour les caractères accentués, tout a l'air ok. Mais pour d'autres caractères... Je cherche pour le signe plus (+). Est ce possible ? ex : canal+.fr = ?
La spécification pour les noms de domaines est (rfc std13):
Encore faut il également que les zones gerent cet encodage ..
??
Y'a pas un certain nombres de zones qui interdisent le double tiret dans un nom de domaine ?
Patrick Mevzek
je me suis aperçu que l'on pouvait créer des noms de domaines avec caractères spéciaux à condition qu'un encodage soit effectué. ex : café.com = xn--caf-dma.com
Pour les caractères accentués, tout a l'air ok. Mais pour d'autres caractères... Je cherche pour le signe plus (+). Est ce possible ? ex : canal+.fr = ?
Il y a plusieurs choses.
D'abord un algorithme qui transforme n'importe quelle chaine (tant qu'elle comprend des caractères présents dans Unicode) en chaine ASCII spéciale pour les DNS (ie: le codage a été fait de tel façon qu'on minimise l'explosion en taille, en tenant compte des autres contraintes dans un DNS). C'est ce qui est décrit dans les RFC publiés il y a presque deux ans, qui normalisent enfin la chose, puisqu'il y a eu des tentatives avant (notamment en .COM), qui se sont avérés au final totalement incompatibles avec le résultat normalisé.
La chaine ASCII récupérée donc est utilisée comme nom de domaine avec le préfixe xn-- choisit pour. A noter, que le TLD en lui-même n'est pas soumis à ce genre de chose pour le moment.
Pour que l'ensemble fonctionne, il faut donc que toutes les applications (navigateurs web, logiciels de mail, etc...) soient capables de faire cette traduction, de préférence dans les deux sens. Bon rien de sorcier normalement, c'est normalisé et des bibliothèques existent. Il faut tout de même changer toutes les applications, donc on n'est pas prêt d'en voir le bout. Et ce n'est qu'une étape, puisqu'il reste le TLD à internationaler après... Quand je pense que c'était être plus simple que de mettre à jour les DNS pour supporter Unicode nativement.
Bref. Il y a aussi une deuxième chose: des tables par langue (et par registre). Pourquoi ? Le mécanisme en lui-même permet de tout coder, d'accord. Ce qui permet subitement des choses qui n'étaient pas prévues avant Prenons un registre francophone. Il parait logique d'estimer que cafe et café soit la même chose, parce que si une entité achète l'un et pas l'autre, en termes de droit ca va être le capharnaum le plus total. Donc, ce que recommande le standard c'est que chaque registre qui implémente le mécanisme 1) choisisse quels caractères sont supportés (par exemple .INFO/.ORG commencent avec uniquement les caractères allemands, comme l'umlaut), parmi l'ensemble possible, vu qu'on peut estimer que tout n'a pas de sens et qu'on souhaite limiter les problèmes (en particulier, je doute que le + soit accepté un jour) 2) détermine des classes d'équivalence, qui seraient donc des tables qui diraient que cafe et café c'est la même chose et que quand l'un est déposé, l'autre l'est aussi automatiquement et qu'on ne peut pas le déposer à part. Cela impose donc que l'enregistrement soit fait en précisant la langue, parce que sinon cela n'a évidemment pas de sens.
Ce qui veut dire donc en pratique que, selon le TLD - vous ne pourrez pas utiliser n'importe quel caractère - vous ne pourrez pas réserver n'importe quoi à cause des règles d'équivalence.
D'autre part le codage Unicode -> Punycode (c'est le petit nom du résultat) est fait par le bureau d'enregistrement, pas par le client final. Le Registre qui veut bien faire les choses va normalement faire l'opération inverse et de nouveau l'opération de codage pour vérifier certains détails. Mais après normalement on voit partout (zones, whois, etc...) le domaine codé et plus sous sa forme ``en clair''.
Vous avez une interface de conversion en ligne sur http://www.bluerider.com/idn/index.php par exemple.
Les caractères ASCII sont conservés tels quels (pas de différence Unicode/Punycode), mais uniquement certains (lettres, chiffres, etc...) normalement (mêmes règles que précédemment sur la gestion de l'ASCII dans les DNS) Le + est en dehors des caractères concernés d'ailleurs, donc il n'est pas autorisé du tout normalement. Cf RFC3490 §4.1 notamment.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
je me suis aperçu que l'on pouvait créer des noms de domaines avec
caractères spéciaux à condition qu'un encodage soit effectué. ex :
café.com = xn--caf-dma.com
Pour les caractères accentués, tout a l'air ok. Mais pour d'autres
caractères...
Je cherche pour le signe plus (+).
Est ce possible ?
ex : canal+.fr = ?
Il y a plusieurs choses.
D'abord un algorithme qui transforme n'importe quelle chaine (tant
qu'elle comprend des caractères présents dans Unicode) en chaine ASCII
spéciale pour les DNS (ie: le codage a été fait de tel façon qu'on
minimise l'explosion en taille, en tenant compte des autres contraintes
dans un DNS).
C'est ce qui est décrit dans les RFC publiés il y a presque deux ans, qui
normalisent enfin la chose, puisqu'il y a eu des tentatives avant
(notamment en .COM), qui se sont avérés au final totalement incompatibles
avec le résultat normalisé.
La chaine ASCII récupérée donc est utilisée comme nom de domaine avec le
préfixe xn-- choisit pour. A noter, que le TLD en lui-même n'est pas
soumis à ce genre de chose pour le moment.
Pour que l'ensemble fonctionne, il faut donc que toutes les applications
(navigateurs web, logiciels de mail, etc...) soient capables de faire
cette traduction, de préférence dans les deux sens. Bon rien de sorcier
normalement, c'est normalisé et des bibliothèques existent. Il faut tout
de même changer toutes les applications, donc on n'est pas prêt d'en voir
le bout. Et ce n'est qu'une étape, puisqu'il reste le TLD à
internationaler après...
Quand je pense que c'était être plus simple que de mettre à jour les DNS
pour supporter Unicode nativement.
Bref.
Il y a aussi une deuxième chose: des tables par langue (et par registre).
Pourquoi ?
Le mécanisme en lui-même permet de tout coder, d'accord.
Ce qui permet subitement des choses qui n'étaient pas prévues avant
Prenons un registre francophone. Il parait logique d'estimer que cafe et
café soit la même chose, parce que si une entité achète l'un et pas
l'autre, en termes de droit ca va être le capharnaum le plus total.
Donc, ce que recommande le standard c'est que chaque registre qui
implémente le mécanisme
1) choisisse quels caractères sont supportés (par exemple .INFO/.ORG
commencent avec uniquement les caractères allemands, comme l'umlaut),
parmi l'ensemble possible, vu qu'on peut estimer que tout n'a pas de sens
et qu'on souhaite limiter les problèmes (en particulier, je doute que le
+ soit accepté un jour)
2) détermine des classes d'équivalence, qui seraient donc des tables qui
diraient que cafe et café c'est la même chose et que quand l'un est
déposé, l'autre l'est aussi automatiquement et qu'on ne peut pas le
déposer à part. Cela impose donc que l'enregistrement soit fait en
précisant la langue, parce que sinon cela n'a évidemment pas de sens.
Ce qui veut dire donc en pratique que, selon le TLD
- vous ne pourrez pas utiliser n'importe quel caractère
- vous ne pourrez pas réserver n'importe quoi à cause des règles
d'équivalence.
D'autre part le codage Unicode -> Punycode (c'est le petit nom du
résultat) est fait par le bureau d'enregistrement, pas par le client final.
Le Registre qui veut bien faire les choses va normalement faire
l'opération inverse et de nouveau l'opération de codage pour vérifier
certains détails. Mais après normalement on voit partout (zones, whois,
etc...) le domaine codé et plus sous sa forme ``en clair''.
Vous avez une interface de conversion en ligne sur
http://www.bluerider.com/idn/index.php par exemple.
Les caractères ASCII sont conservés tels quels (pas de différence
Unicode/Punycode), mais uniquement certains (lettres, chiffres, etc...)
normalement (mêmes règles que précédemment sur la gestion de l'ASCII dans
les DNS)
Le + est en dehors des caractères concernés d'ailleurs, donc il n'est pas
autorisé du tout normalement.
Cf RFC3490 §4.1 notamment.
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
je me suis aperçu que l'on pouvait créer des noms de domaines avec caractères spéciaux à condition qu'un encodage soit effectué. ex : café.com = xn--caf-dma.com
Pour les caractères accentués, tout a l'air ok. Mais pour d'autres caractères... Je cherche pour le signe plus (+). Est ce possible ? ex : canal+.fr = ?
Il y a plusieurs choses.
D'abord un algorithme qui transforme n'importe quelle chaine (tant qu'elle comprend des caractères présents dans Unicode) en chaine ASCII spéciale pour les DNS (ie: le codage a été fait de tel façon qu'on minimise l'explosion en taille, en tenant compte des autres contraintes dans un DNS). C'est ce qui est décrit dans les RFC publiés il y a presque deux ans, qui normalisent enfin la chose, puisqu'il y a eu des tentatives avant (notamment en .COM), qui se sont avérés au final totalement incompatibles avec le résultat normalisé.
La chaine ASCII récupérée donc est utilisée comme nom de domaine avec le préfixe xn-- choisit pour. A noter, que le TLD en lui-même n'est pas soumis à ce genre de chose pour le moment.
Pour que l'ensemble fonctionne, il faut donc que toutes les applications (navigateurs web, logiciels de mail, etc...) soient capables de faire cette traduction, de préférence dans les deux sens. Bon rien de sorcier normalement, c'est normalisé et des bibliothèques existent. Il faut tout de même changer toutes les applications, donc on n'est pas prêt d'en voir le bout. Et ce n'est qu'une étape, puisqu'il reste le TLD à internationaler après... Quand je pense que c'était être plus simple que de mettre à jour les DNS pour supporter Unicode nativement.
Bref. Il y a aussi une deuxième chose: des tables par langue (et par registre). Pourquoi ? Le mécanisme en lui-même permet de tout coder, d'accord. Ce qui permet subitement des choses qui n'étaient pas prévues avant Prenons un registre francophone. Il parait logique d'estimer que cafe et café soit la même chose, parce que si une entité achète l'un et pas l'autre, en termes de droit ca va être le capharnaum le plus total. Donc, ce que recommande le standard c'est que chaque registre qui implémente le mécanisme 1) choisisse quels caractères sont supportés (par exemple .INFO/.ORG commencent avec uniquement les caractères allemands, comme l'umlaut), parmi l'ensemble possible, vu qu'on peut estimer que tout n'a pas de sens et qu'on souhaite limiter les problèmes (en particulier, je doute que le + soit accepté un jour) 2) détermine des classes d'équivalence, qui seraient donc des tables qui diraient que cafe et café c'est la même chose et que quand l'un est déposé, l'autre l'est aussi automatiquement et qu'on ne peut pas le déposer à part. Cela impose donc que l'enregistrement soit fait en précisant la langue, parce que sinon cela n'a évidemment pas de sens.
Ce qui veut dire donc en pratique que, selon le TLD - vous ne pourrez pas utiliser n'importe quel caractère - vous ne pourrez pas réserver n'importe quoi à cause des règles d'équivalence.
D'autre part le codage Unicode -> Punycode (c'est le petit nom du résultat) est fait par le bureau d'enregistrement, pas par le client final. Le Registre qui veut bien faire les choses va normalement faire l'opération inverse et de nouveau l'opération de codage pour vérifier certains détails. Mais après normalement on voit partout (zones, whois, etc...) le domaine codé et plus sous sa forme ``en clair''.
Vous avez une interface de conversion en ligne sur http://www.bluerider.com/idn/index.php par exemple.
Les caractères ASCII sont conservés tels quels (pas de différence Unicode/Punycode), mais uniquement certains (lettres, chiffres, etc...) normalement (mêmes règles que précédemment sur la gestion de l'ASCII dans les DNS) Le + est en dehors des caractères concernés d'ailleurs, donc il n'est pas autorisé du tout normalement. Cf RFC3490 §4.1 notamment.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Patrick Mevzek
"Patrick Mevzek" a écrit dans le message de news:
Encore faut il également que les zones gerent cet encodage ..
??
Y'a pas un certain nombres de zones qui interdisent le double tiret dans un nom de domaine ?
Justement pour permettre l'arrivée de l'IDN proprement, il y a quelques années on a commencé à interdire la présence d'un tiret en 3ème et 4ème position car les premières tentatives tournaient déjà autour de XX--qqchose et donc il fallait éviter que quelqu'un puisse déposer un nom de domaine avec des tirets à cet endroit sans faire de l'IDN. Après le débat, c'était quoi mettre en XX. Y a eu notamment ra-- et bq-- pendant très longtemps. L'IETF, après moultes réflexions et processus hautement déterministe :-) a dit que ce serait xn--
D'ailleurs, techniquement on pourrait autoriser maintenant YY-- tant que YY est différent de xn puisque c'est xn qui est normalisé pour l'IDN dans les DNS. M'enfin, par simplicité, mieux vaut interdire tous les -- à cet endroit. Par contre on peut en mettre ailleurs : a--a est tout à fait acceptable normalement.
Je parle des gTLDs (ce qui précède est dans les contrats ICANN), mais ca doit être pareil ailleurs.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
"Patrick Mevzek" <pm-N200501@nospam.dotandco.com> a écrit dans le
message de news:
pan.2005.01.20.14.18.23.475456.8851@nospam.dotandco.com...
Encore faut il également que les zones gerent cet encodage ..
??
Y'a pas un certain nombres de zones qui interdisent le double tiret dans
un nom de domaine ?
Justement pour permettre l'arrivée de l'IDN proprement, il y a quelques
années on a commencé à interdire la présence d'un tiret en 3ème et 4ème
position car les premières tentatives tournaient déjà autour de
XX--qqchose
et donc il fallait éviter que quelqu'un puisse déposer un nom de domaine
avec des tirets à cet endroit sans faire de l'IDN.
Après le débat, c'était quoi mettre en XX.
Y a eu notamment ra-- et bq-- pendant très longtemps.
L'IETF, après moultes réflexions et processus hautement déterministe :-)
a dit que ce serait xn--
D'ailleurs, techniquement on pourrait autoriser maintenant YY-- tant que
YY est différent de xn puisque c'est xn qui est normalisé pour l'IDN dans
les DNS. M'enfin, par simplicité, mieux vaut interdire tous les -- à cet
endroit. Par contre on peut en mettre ailleurs : a--a est tout à fait
acceptable normalement.
Je parle des gTLDs (ce qui précède est dans les contrats ICANN),
mais ca doit être pareil ailleurs.
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Encore faut il également que les zones gerent cet encodage ..
??
Y'a pas un certain nombres de zones qui interdisent le double tiret dans un nom de domaine ?
Justement pour permettre l'arrivée de l'IDN proprement, il y a quelques années on a commencé à interdire la présence d'un tiret en 3ème et 4ème position car les premières tentatives tournaient déjà autour de XX--qqchose et donc il fallait éviter que quelqu'un puisse déposer un nom de domaine avec des tirets à cet endroit sans faire de l'IDN. Après le débat, c'était quoi mettre en XX. Y a eu notamment ra-- et bq-- pendant très longtemps. L'IETF, après moultes réflexions et processus hautement déterministe :-) a dit que ce serait xn--
D'ailleurs, techniquement on pourrait autoriser maintenant YY-- tant que YY est différent de xn puisque c'est xn qui est normalisé pour l'IDN dans les DNS. M'enfin, par simplicité, mieux vaut interdire tous les -- à cet endroit. Par contre on peut en mettre ailleurs : a--a est tout à fait acceptable normalement.
Je parle des gTLDs (ce qui précède est dans les contrats ICANN), mais ca doit être pareil ailleurs.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Ronnie Garcia
je me suis aperçu que l'on pouvait créer des noms de domaines avec caractères spéciaux à condition qu'un encodage soit effectué. ex : café.com = xn--caf-dma.com
Attention, ce n'est tjrs pas normalisé
Si, les RFC ont presque un an maintenant.
Je suis HS, mais depuis quand un RFC est il une norme ?
-- Ronnie Garcia <ronnie at mk2 dot net>
je me suis aperçu que l'on pouvait créer des noms de domaines avec
caractères spéciaux à condition qu'un encodage soit effectué. ex :
café.com = xn--caf-dma.com
Attention, ce n'est tjrs pas normalisé
Si, les RFC ont presque un an maintenant.
Je suis HS, mais depuis quand un RFC est il une norme ?
je me suis aperçu que l'on pouvait créer des noms de domaines avec caractères spéciaux à condition qu'un encodage soit effectué. ex : café.com = xn--caf-dma.com
Attention, ce n'est tjrs pas normalisé
Si, les RFC ont presque un an maintenant.
Je suis HS, mais depuis quand un RFC est il une norme ?
-- Ronnie Garcia <ronnie at mk2 dot net>
Dominique ROUSSEAU
je me suis aperçu que l'on pouvait créer des noms de domaines avec caractères spéciaux à condition qu'un encodage soit effectué. ex : café.com = xn--caf-dma.com
Attention, ce n'est tjrs pas normalisé
Si, les RFC ont presque un an maintenant.
Je suis HS, mais depuis quand un RFC est il une norme ?
C'est certes pas sorti de l'ISO (ou assimilé), mais c'est ce sur quoi les acteurs d'Internet pour faire des trucs qui se causent entre eux, et ça semble fonctionner pas mal, comme système.
Dom
je me suis aperçu que l'on pouvait créer des noms de domaines avec
caractères spéciaux à condition qu'un encodage soit effectué. ex :
café.com = xn--caf-dma.com
Attention, ce n'est tjrs pas normalisé
Si, les RFC ont presque un an maintenant.
Je suis HS, mais depuis quand un RFC est il une norme ?
C'est certes pas sorti de l'ISO (ou assimilé), mais c'est ce sur quoi
les acteurs d'Internet pour faire des trucs qui se causent entre eux, et
ça semble fonctionner pas mal, comme système.
je me suis aperçu que l'on pouvait créer des noms de domaines avec caractères spéciaux à condition qu'un encodage soit effectué. ex : café.com = xn--caf-dma.com
Attention, ce n'est tjrs pas normalisé
Si, les RFC ont presque un an maintenant.
Je suis HS, mais depuis quand un RFC est il une norme ?
C'est certes pas sorti de l'ISO (ou assimilé), mais c'est ce sur quoi les acteurs d'Internet pour faire des trucs qui se causent entre eux, et ça semble fonctionner pas mal, comme système.
Dom
Ronnie Garcia
je me suis aperçu que l'on pouvait créer des noms de domaines avec caractères spéciaux à condition qu'un encodage soit effectué. ex : café.com = xn--caf-dma.com
Attention, ce n'est tjrs pas normalisé
Si, les RFC ont presque un an maintenant.
Je suis HS, mais depuis quand un RFC est il une norme ?
C'est certes pas sorti de l'ISO (ou assimilé), mais c'est ce sur quoi les acteurs d'Internet pour faire des trucs qui se causent entre eux, et ça semble fonctionner pas mal, comme système.
Bien entendu, mais utilisons les bons termes. Ca permet à tout le monde de se comprendre sans quiproquo, comme on en voit deja trop souvent ici.
norme != standard != rfc
-- Ronnie Garcia <ronnie at mk2 dot net>
je me suis aperçu que l'on pouvait créer des noms de domaines avec
caractères spéciaux à condition qu'un encodage soit effectué. ex :
café.com = xn--caf-dma.com
Attention, ce n'est tjrs pas normalisé
Si, les RFC ont presque un an maintenant.
Je suis HS, mais depuis quand un RFC est il une norme ?
C'est certes pas sorti de l'ISO (ou assimilé), mais c'est ce sur quoi
les acteurs d'Internet pour faire des trucs qui se causent entre eux, et
ça semble fonctionner pas mal, comme système.
Bien entendu, mais utilisons les bons termes. Ca permet à tout le monde
de se comprendre sans quiproquo, comme on en voit deja trop souvent ici.
je me suis aperçu que l'on pouvait créer des noms de domaines avec caractères spéciaux à condition qu'un encodage soit effectué. ex : café.com = xn--caf-dma.com
Attention, ce n'est tjrs pas normalisé
Si, les RFC ont presque un an maintenant.
Je suis HS, mais depuis quand un RFC est il une norme ?
C'est certes pas sorti de l'ISO (ou assimilé), mais c'est ce sur quoi les acteurs d'Internet pour faire des trucs qui se causent entre eux, et ça semble fonctionner pas mal, comme système.
Bien entendu, mais utilisons les bons termes. Ca permet à tout le monde de se comprendre sans quiproquo, comme on en voit deja trop souvent ici.
norme != standard != rfc
-- Ronnie Garcia <ronnie at mk2 dot net>
Patrick Mevzek
Bien entendu, mais utilisons les bons termes. Ca permet à tout le monde de se comprendre sans quiproquo,
Je pense que tout le monde avait compris sans quiproquo....
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Bien entendu, mais utilisons les bons termes. Ca permet à tout le monde
de se comprendre sans quiproquo,
Je pense que tout le monde avait compris sans quiproquo....
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Bien entendu, mais utilisons les bons termes. Ca permet à tout le monde de se comprendre sans quiproquo,
Je pense que tout le monde avait compris sans quiproquo....
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Jean-Luc ERNST
Bonjour, si le + n'est pas accepté, le - l'est, il me semble. C'est d'ailleurs un peu curieux... On peut avoir www.c-a-d.com ou www.entre-acte.com mais pas www.un+un.com Correct ? Merci. -- -- Cordialement, Jean-Luc ERNST
"Patrick Mevzek" a écrit dans le message de news:
...snip...
Le + est en dehors des caractères concernés d'ailleurs, donc il n'est pas autorisé du tout normalement. Cf RFC3490 §4.1 notamment.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Bonjour,
si le + n'est pas accepté, le - l'est, il me semble. C'est d'ailleurs un peu
curieux...
On peut avoir www.c-a-d.com ou www.entre-acte.com
mais pas www.un+un.com
Correct ?
Merci.
--
--
Cordialement,
Jean-Luc ERNST
"Patrick Mevzek" <pm-N200501@nospam.dotandco.com> a écrit dans le message de
news: pan.2005.01.20.14.43.31.598544.8851@nospam.dotandco.com...
...snip...
Le + est en dehors des caractères concernés d'ailleurs, donc il n'est pas
autorisé du tout normalement.
Cf RFC3490 §4.1 notamment.
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Bonjour, si le + n'est pas accepté, le - l'est, il me semble. C'est d'ailleurs un peu curieux... On peut avoir www.c-a-d.com ou www.entre-acte.com mais pas www.un+un.com Correct ? Merci. -- -- Cordialement, Jean-Luc ERNST
"Patrick Mevzek" a écrit dans le message de news:
...snip...
Le + est en dehors des caractères concernés d'ailleurs, donc il n'est pas autorisé du tout normalement. Cf RFC3490 §4.1 notamment.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
