Mon blog

Ce RFC, et les deux suivants, 3651 et 3652, décrivent le protocole Handle, qui est à la base du système DOI (Digital Object Identifier), système qui bénéficie d'un marketing très actif. Le 3650 donne une vision générale de Handle, le 3651 décrit le nommage et le 3652 le protocole concret.

Il existe de nombreux systèmes pour désigner un objet sur Internet. Le DNS (RFC 1034 et RFC 1035) est le plus connu, les URL du Web (Uniform Resource Locators, RFC 1738), qui s'appuient sur le DNS, sont les plus visibles dans le monde réel, mais il y a aussi LDAP (Lightweight Directory Access Protocol, RFC 3377) et bien d'autres.

Handle fait partie de ces mécanismes de désignation. Il concurrence le DNS par certains aspects et les URL par d'autres. La motivation principale pour remplacer les URL est leur manque de permanence (un URL change trop facilement et il est trop concret, trop lié à une localisation) et la motivation principale pour remplacer le DNS semble être le désir d'inventer un nouveau protocole, qui n'aurait pas à supporter l'héritage, notamment administratif (le système de l'IANA et des registres actuels) du DNS.

Handle se passe donc du DNS. Les identifiants Handle ressemblent à doi:10.1340/309registries ou à hdl:cnri.dlib/december95. Ils sont résolus par une infrastucture technique qui est distincte, avec ses propres serveurs. Le logiciel client doit connaitre ce protocole Handle (il existe un plugin pour MS Internet Explorer, par exemple).

L'enthousiasme de ses promoteurs leur fait parfois frôler les bornes. Contrairement à ce qu'ils laissent entendre, le DNS peut faire tout ce que fait Handle, à condition d'utiliser tout le DNS, par exemple les enregistrements SRV (RFC 2782).

Une autre alternative à Handle pourrait être un des membres de la grande famille des URI (Uniform Resource Identifiers, RFC 3305) comme les URN (Uniform Resource Names, voir le RFC 8254 pour un exemple : ISBN:0-395-36341-1).

C'est en raison de l'existence d'autres systèmes, moins "séparatistes", que l'IESG a ajouté une note d'avertissement au RFC 3650, indiquant que l'IETF n'approuvait pas vraiment ce protocole.

Un RFC très attendu que ce 3912. Non pas par ce qu'il apporte une révolution technologique mais parce qu'il est le premier à réussir à remplacer le très vieux RFC 954, qui spécifiait le protocole whois.

Le RFC 954, qui décrit le désormais célèbre protocole whois, souffrait de nombreux défauts. Celui que résout le RFC 3912 était le mélange, dans le même texte, de la description technique d'un protocole et de la politique d'utilisation. Le RFC 954, méprisant toute considération de vie privée, rendait obligatoire le fait d'avoir un serveur whois et de publier au monde entier les noms et adresses des titulaires de noms de domaine.

Tout le monde était d'accord pour trouver ce mélange des genres intolérable mais il a fallu du temps, l'obstination de Leslie Daigle (et son poste à l'IAB) pour publier le nouveau RFC.

Le RFC 3912 ne garde donc que la description technique du protocole et supprime toute référence politique. Il est donc reconnu officiellement par l'IETF qu'un registre est libre de définir sa politique de protection des données personnelles. Espérons que cela fera taire les éradicateurs de rfc-ignorant.org qui mettaient en liste noire tous les TLD sans serveur whois !

Le protocole whois est trivial: le client se connecte sur le port 43 du serveur, envoie une ligne qui contient la question (par exemple bortzmeyer.org) et reçoit la réponse sous forme de texte (dont la syntaxe n'est pas spécifiée).

Une mise en œuvre presque complète (n'y manque que la sélection du nom du serveur) en Go prend soixante lignes.

Whois souffre de nombreuses limites. Parmi celles-ci, l'absence d'un standard pour le format de sortie. L'étude faite dans le RFC 7485 montre la variété des serveurs whois, à la fois de format et de modèle de données.

De nombreuses tentatives ont été faites pour remplacer l'antédiluvien protocole whois, la plus récente étant RDAP. Aucune n'a encore réussi, le vieux dinosaure reste indécrochable.

Le RFC 3865, "A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension", vient de sortir.

Il est écrit par un praticien expérimenté de l'Internet, Carl Malamud, l'auteur du "Internet Travelogue", qui a toujours été très proche des questions sociales et politiques. Il était co-auteur de la proposition de reprise de ".org" par une organisation sans but lucratif (le registre a finalement été donné à l'ISOC).

Ce RFC transpose dans le domaine du courrier électronique le principe des affichettes "Pas de pub" que l'on trouve dans de nombreux pays. Un serveur de courrier peut désormais indiqué, via le protocole SMTP, qu'il ne veut pas de spam.

Evidemment, les spammeurs ne respecteront pas ce message. Mais, s'appuyant sur une importante jurisprudence que décrit le RFC, Malamud estime probablement que cet avertissement clair et analysable automatiquement par le logiciel d'émission permettra de prouver clairement que le spammeur ne tenait pas compte des désiderata du destinataire, et ne pouvait donc pas invoquer la liberté d'expression (puisqu'on est toujours libre de ne pas écouter).

C'est donc une mesurette technique, bien plus modérée que les redoutables filtres bayésiens ou que les brutales listes noires, mais qui a pour but de déblayer le terrain juridique pour une éventuelle offensive devant les tribunaux.