L'IETF a annoncé le 24 avril 2017 la
dissolution du groupe de travail DBOUND. Je n'écrirai donc pas
d'article sur les RFC de ce groupe, il n'y
en a eu aucun. Pourquoi cet échec ?
D'abord, voyons quel était le problème que voulait résoudre ce
groupe. DBOUND signifie Domain Boundaries et
il s'agissait en gros d'indiquer publiquement quelles étaient les
frontières organisationnelles dans les noms de domaine. Minute, vont se dire
certains lecteurs, c'est facile ! Dans
www.foobar.example, la frontière est
forcément entre foobar et le truc appelé à
tort « extension »
.example ? Mais c'est complètement faux, les
coupures (passage d'une organisation à une autre) peuvent être à
plein d'endroits différents et rien dans le nom de domaine ne
l'indique. (Cf. mon article sur « La terminologie des parties d'un nom
de domaine ».)
Et, au passage, pourquoi est-ce que c'est important de savoir
que signal.eu.org et
eahm.eu.org ne dépendent
pas de la même organisation ? Parce que
plusieurs services en dépendent. (Une liste partielle de raisons
figure dans mon article « Trouver le domaine
responsable ».) Par exemple, on pourrait vouloir, dans la
barre d'adresses du navigateur Web, colorier
différemment le domaine enregistré le plus haut dans l'arbre, pour
éviter certains trucs utilisés par le hameçonnage.
Aujourd'hui, comme il y a un vrai besoin, la plupart des
utilisateurs se servent de la « Public Suffix List » de
Mozilla. Cela marche « suffisamment » mais
son principal inconvénient est qu'elle n'est pas administrée par les
gérants de noms de domaine, et qu'elle n'est donc jamais à
jour.
C'est là dessus que devait travailler le groupe
DBOUND. Il devait « développer une solution unique pour
déterminer les frontières organisationnelles ». Le travail a
commencé sur une liste de diffusion en
janvier
2014, et le groupe lui-même a été créé en avril
2015. Plusieurs documents ont
été proposés mais aucun n'a réuni même un début de
commencement de consensus. (Même pas le document de description du
problème, draft-sullivan-dbound-problem-statement.)
Suivant un principe général de l'IETF, qu'un groupe de travail
est fait pour travailler et qu'il ne faut pas maintenir en vie
artificiellement des groupes qui ne produiront manifestement rien
d'utile, le groupe a donc été dissous.
Pourquoi cet échec ? Il n'y a sans doute pas une raison
unique. Parmi les explications :
Le problème est bien plus compliqué qu'il n'en a l'air
(comme beaucoup de problèmes qu'on aborde avec des yakafokon),
par exemple parce qu'il n'est pas évident qu'il faille les mêmes
frontières pour toutes les applications,Il y a un désaccord de fond entre ceux qui disent que
l'indication des frontières doit être faite par le domaine
parent (au-dessus de la frontière), car c'est lui qui fixe les
règles d'enregistrement, et ceux qui disent qu'elle
doit être faite par le domaine fils (car c'est lui qui sait son
propre statut),Et, tout simplement, intérêt insuffisant pour un problème
dont la partie la plus urgente (les
cookies) est déjà
partiellement résolu. L'IETF étant une organisation de
volontaires, s'il n'y a pas de volontaire, rien ne se passe.