Le bundling est le rassemblement de plusieurs
noms de domaine dans un seul
lot (bundle) qui va être
traité comme un nom unique pour des opérations comme
l'enregistrement du nom ou son transfert à un autre titulaire. Il
est surtout pratiqué par les registres qui ont beaucoup de noms en
écriture chinoise. Ce RFC décrit une extension au
protocole d'avitaillement EPP pour pouvoir traiter ces lots.
Le problème n'existe pas qu'en chinois mais ce sont surtout les
sinophones qui se sont manifestés à ce sujet, en raison de la
possibilité d'écrire le même mot en écriture
traditionnelle ou en écriture
simplifiée (on parle de variantes :
l'ensemble des variantes forme le lot). Pour prendre un exemple
non-chinois, PIR avait décidé qu'un nom dans
.ngo et dans .ong devaient
être dans le même lot. Un registre qui décide que ces deux termes
sont équivalents et doivent être gérés ensemble (par exemple,
appartenir au même titulaire) les regroupent dans un lot
(bundle, ou parfois
package). C'est la politique suggérée dans les
RFC 3743 et RFC 4290, et
le RFC 6927 décrit les pratiques
existantes. Par exemple, certains registres peuvent n'autoriser
qu'une variante par lot, et bloquer les autres (empêcher leur
enregistrement), tandis que d'autres enregistreront tous les noms
ensemble. Sans compter bien sûr les registres qui n'ont pas de
système de lot du tout. Notre nouveau RFC 9095 ne prend pas
position sur ce sujet délicat, il décrit juste un moyen technique de
manipuler ces lots avec EPP (RFC 5731).
Les variantes dans un même lot n'ont pas forcément tout en
commun. Un registre peut par exemple décider que l'enregistrement
des variantes doit être fait par le même titulaire mais qu'un nom du
lot peut ensuite être transféré à un autre titulaire. Notre RFC se
limite au cas strict où les membres du lot ont presque tous leurs
attributs (titulaires, contacts, date d'expiration, peut-être
serveurs de noms et, pourquoi pas, clés DNSSEC) en commun.
La
lecture du RFC nécessite un peu de terminologie spécifique, décrite
dans sa section 2. Par exemple, le RDN (Registered Domain
Name) est celui qui a été demandé par le titulaire lors de
l'enregistrement, et le BDN (Bundled Domain Name)
est un nom qui a été inclus dans le lot, en fonction des règles du
registre. Par exemple, si un registre décidait que tout nom avec des
traits d'union était équivalent au même nom
sans traits d'union, et qu'un titulaire enregistre
tarte-poireaux.example (le RDN), alors
tartepoireaux.example et
tarte-poi-reaux.example seraient des BDN,
membres du même lot que le RDN. Dans le modèle de notre RFC, les
métadonnées comme la date d'expiration ou comme l'état du domaine
sont attachées au RDN, les BDN du lot partageant ces
métadonnées.
Notons aussi que le RFC n'envisage que le cas de lots assez
petits (par exemple le nom en écriture chinoise traditionnelle et
celui en écriture chinoise simplifiée). L'exemple que je donnais
avec le trait d'union ne rentre pas tellement dans le cadre de ce
RFC car le nombre de BDN est alors beaucoup plus élevé et serait
difficile à gérer. (Amusez-vous à calculer combien de variantes de
tartepoireaux.example existeraient si un
décidait que le trait d'union n'est pas significatif.)
Dans l'extension EPP décrite dans ce RFC, le RDN
est représenté (section 5 du RFC) en Unicode
(le « U-label ») ou bien en ASCII (le « A-label »,
la forme « punycodée »). L'élement XML est
b-dn
est un préfixe possible pour l'espace de noms
XML de notre RFC, urn:ietf:params:xml:ns:epp:b-dn). Si le RDN est représenté en ASCII, un attribut XML
uLabel permet d'indiquer la version Unicode du
nom. Cela donnerait, par exemple, xn--fsq270a.example.
Enfin, la section 6 décrit les commandes et réponses EPP pour
notre extension. La commande
Command completed successfully
xn--fsq270a.example
xn--fsqz41a.example
This associated domain name is
a produced name based on bundle name policy.
...
La commande
n'est pas non plus
modifiée mais sa réponse l'est, par l'ajout d'un élément
qui décrit le lot :
Command completed successfully
xn--fsq270a.example
58812678-domain
...
xn--fsq270a.example
xn--fsqz41a.example
Quand on crée un domaine qui fait partie d'un lot, la commande
doit inclure une extension
indiquant que le client EPP connait la gestion de lots, et la
réponse à
lui donnera le
BDN. D'une manière analogue, la commande
détruira tout le lot et
l'indiquera dans la réponse. La commande
fonctionne sur le même
principe : elle modifie le RDN et indique dans sa réponse le BDN
affecté. La syntaxe complète de cette extension EPP figure dans la
section 7 du RFC, sous forme d'un schéma
W3C. Par ailleurs, cette extension est enregistrée dans
le
registre des extensions EPP (celui créé par le RFC 7451).
Un petit mot sur la sécurité, car de nombreux adversaires de
l'internationalisation, notamment anglophones, ont critiqué les
noms de domaine en Unicode, les accusant de
tous les maux : les auteurs du RFC notent que des noms en chinois
sont enregistrés depuis plus de quinze ans, et qu'aucun problème
particulier n'a été signalé.
Questions mises en œuvre de ce RFC, les registres chinois (comme
.cn ou
.tw) suivent les
principes de ce RFC (l'enregistrement d'un lot) depuis
longtemps. CNNIC déploie cette extension
EPP. En dehors de la sinophonie, PIR utilise
les lots pour .ngo et
.ong. Et cette extension EPP est mise en œuvre
dans Net::DRI.
Et, comme souvent, il y a un brevet de
Verisign sur la technique décrite dans ce
RFC. Je ne l'ai pas lu mais il y
a des chances qu'il soit sans mérite, comme beaucoup de brevets
logiciels.
