Résumé

  • RFC 2352 proposait une adresse composée du nom officiel, de la forme juridique, d’une localité et du pays afin que l’autorité d’immatriculation, plutôt que le registre DNS, tranche le premier droit au nom.
  • Cette preuve restait locale : elle ne démontrait ni une délégation DNS, ni une identité mondiale, ni le contrôle du service, et la note de l’éditeur signalait déjà la contradiction institutionnelle et le coût du changement.

Le conflit que le protocole ne savait pas juger

Le DNS savait comparer des étiquettes et déléguer une branche. Il ne savait pas déterminer lequel de deux commerçants portant le même nom devait recevoir l’étiquette la plus mémorable. À la fin des années 1990, la rareté perçue des noms courts dans les domaines génériques faisait remonter vers les registres une question qui appartenait aussi au droit des sociétés et des marques.

RFC 2240 avait présenté ce conflit comme un défaut de l’espace « plat ». RFC 2352, qui le remplaça en mai 1998, proposa d’ajouter le contexte dans le chemin lui-même. Une société britannique à responsabilité limitée pourrait se trouver sous LTD.UK, une marque française sous TM.FR, une société américaine sous une branche comprenant son État. La formule générale associait un jeton juridique, une ou plusieurs localités et le code ISO du pays.

Le libellé de l’organisation devait provenir de son nom légal complet. Le suffixe juridique disparaissait du libellé parce que la branche supérieure le portait déjà ; les espaces devenaient des traits d’union et la ponctuation pouvait être supprimée ou transformée. L’autorité chargée des sociétés ou des marques établirait le droit de départ, puis le gestionnaire DNS créerait l’entrée.

Le mécanisme avait un mérite : il refusait de demander à un opérateur DNS d’inventer du droit. Il admettait aussi que des organisations légitimes puissent porter les mêmes mots dans des juridictions différentes. Mais il faisait d’une réponse limitée — qui détient ce nom dans ce registre ? — l’entrée d’une promesse beaucoup plus vaste : quel nom Internet le public doit-il retenir ?

L’unicité n’était pas universelle

Le texte affirmait que les litiges ne pourraient pas survenir puisque les noms légaux sont uniques dans leur contexte. Le contexte était précisément la limite de la preuve.

Un registre garantit l’unicité selon sa juridiction, sa catégorie d’entité et sa date. Une marque possède encore d’autres frontières : territoire, classes, titulaire, durée. RFC 2352 ne créait aucun registre mondial. Il composait un chemin à partir de décisions prises par plusieurs institutions, selon des règles différentes.

La normalisation ajoutait sa propre perte d’information. Transformer espaces et ponctuation en traits d’union permet de fabriquer une étiquette. Cela ne garantit pas que deux graphies juridiques distinctes restent distinctes, ni que le public reconnaisse l’entreprise. Pour auditer la relation, il faut conserver le dossier légal, la règle de transformation, la décision du registre DNS et l’état de la zone.

Le mot « autorité » change également de sens. Dans RFC 1034, un serveur est autoritaire parce qu’il détient l’information complète d’une zone. Cette qualité technique ne lui confère aucune compétence sur l’existence d’une société, la priorité d’une marque ou la légitimité d’un service. Une réponse DNS prouve moins encore : elle livre des enregistrements pour un nom exact ; elle ne certifie ni le propriétaire réel, ni la sécurité, ni le résultat atteint par l’utilisateur.

L’objection fut publiée avec la proposition

RFC 2352 était une soumission indépendante de catégorie Informational, pas une norme Internet. L’éditeur lui ajouta une note d’une franchise inhabituelle.

Le schéma paraissait exiger que des entreprises abandonnent des noms génériques connus pour des formes beaucoup plus longues, sans leur offrir d’incitation. Or RFC 920 avait déjà décrit la douleur du renommage : références périmées dans les tables, listes de diffusion, anciens courriers, annuaires imprimés et mémoire humaine. La propreté d’une nouvelle ligne de registre ne répare pas automatiquement tout ce qui dépend de l’ancien nom.

La note soulevait surtout une contradiction. RFC 2352 reconnaissait que l’organisation du domaine national relevait du pays, puis recommandait à ces espaces nationaux une structure fondée sur les formes juridiques et les localités. L’éditeur jugeait donc la mise en œuvre politiquement incertaine.

Deux surfaces de contrôle demeuraient. Le registre légal attestait un nom dans un ordre juridique. La hiérarchie DNS décidait quelles branches existaient et comment elles étaient déléguées. Une convention pouvait relier les deux ; elle ne fusionnait pas leur mandat.

Les réponses ultérieures ont séparé les fonctions

L’ICANN adopta en 1999 l’UDRP. Cette politique demande notamment au plaignant de prouver la similitude avec une marque, l’absence de droit ou d’intérêt légitime du titulaire, puis l’enregistrement et l’usage de mauvaise foi. C’est une procédure de litige intégrée au contrat d’enregistrement. Elle ne transforme pas chaque immatriculation de société en domaine automatique.

La question des écritures non ASCII reçut également une réponse séparée. RFC 2352 constatait que la représentation disponible limitait les noms d’autres langues. RFC 3490 introduisit plus tard une représentation compatible ASCII côté application, sans modifier les serveurs DNS. Il conserva la recherche exacte et laissa hors du protocole de nombreuses équivalences linguistiques, visuelles ou sonores.

La représentation n’a donc pas décidé du droit ; le règlement d’un litige n’a pas redessiné tout le DNS ; la délégation n’a pas créé l’entreprise.

Une proposition non adoptée peut rester instructive

RFC 2352 rend visible un risque durable : l’extension silencieuse d’un registre. Le DNS a besoin d’unicité à l’intérieur de chaque branche, de délégations exactes et d’un service interopérable. Le registre des sociétés a besoin de dossiers opposables dans son ressort. Les marques ont leurs critères. L’identité publique possède une continuité faite de liens, de certificats, de courrier et d’habitudes.

Une architecture devient fragile lorsqu’elle laisse l’une de ces preuves parler pour toutes les autres. La proposition de 1998 cherchait à sortir le droit du guichet DNS. Elle découvrait en même temps qu’inscrire le droit dans le chemin DNS recréait un guichet plus long.

Sources et limites

La proposition et l’avertissement éditorial figurent dans la notice de RFC 2352 et le texte de RFC 2352 ; son prédécesseur est RFC 2240. Les frontières administratives et techniques viennent de RFC 920, RFC 1034, RFC 1035 et RFC 1591. Les mécanismes ultérieurs sont l’UDRP de l’ICANN et RFC 3490. La séparation des plans s’appuie sur les textes de Heng Lu consacrés aux couches de réalité et à la spécification commune minimale avec décision locale. Ces sources ne prouvent ni l’adoption de RFC 2352, ni le titulaire actuel d’un exemple, ni un droit juridique contemporain.