Journal Nommer les choses par leur contenu, une norme

25
22
avr.
2013

Il y a des tas de sortes d'identificateurs pour désigner les trucs (les choses, les objets, les ressources) qu'on récupère sur le réseau. Une technique amusante est que l'identificateur dépende du contenu de l'objet, ce qui permet de vérifier qu'on a récupéré le bon objet, quelle qu'était la source. C'est le cas des magnets de BitTorrent, par exemple :

http://fr.wikipedia.org/wiki/Magnet_(standard)

Freenet avait déjà montré la voie il y a bien longtemps, avec ses CHK (Content Hash Key).

Voici une nouvelle déclinaison du concept, cette fois sous forme d'une norme, le RFC 6920, qui standardise les NI (Named Information) :

http://www.bortzmeyer.org/6920.html

  • # NIH

    Posté par (page perso) . Évalué à 10.

    Merci pour cette article de vulgarisation qui me permet de tirer quelques conclusions que j'espère pas trop hâtives. Là, ma première question c'est : que résoud le RFC 6920 que ne résoud pas le lien magnet ? Je vais essayer de voir ce qui différencie les deux, parce que pour moi les liens magnets répondent déjà à pas mal de choses.

    Le cahier des charges est plutôt simple :

    • identifier un contenu uniquement par un identifiant
    • indiquer une source possible ou le contenu est disponible

    Des deux côtés, le contenu est identifié via une somme de contrôle. Celle-ci est plus ou moins sujette à collisions, mais sa nature (MD5, SHA1, …) est toujours spécifiée. Chacune des solutions est également capable de répondre au deuxième point, via le paramètre as ou le paramètre xs pour le lien magnet, et via l'_autorité_ pour ni.

    La première différence apparait ici : les liens magnet autorisent plusieurs sources acceptables alors que ni n'en autorise qu'une seule. Naïvement, on pourrait se demander quel est l'intérêt de ne proposer qu'une seule source puisque cette source est facultative et interchangeable ? C'est peut-être pour garder la hiérarchie connue d'une URI classique, qui n'autorise qu'une seule source, mais du coup ça fait perdre en possibilités.

    Le deuxième point faible que je vois dans ni est que l'URL alternative est quasi imposée : c'est forcément du HTTP(S), c'est forcément dans la hiérarchie .well_known/ni/sha256/<blabla>. Je ne vois pas de problème particulier avec le deuxième point, mais par contre pour le premier, on peut se demander : pourquoi HTTP seulement ? Note que rien n'empêche un client de tester autre chose (disons FTP) mais rien ne permet de dire qu'il trouvera quelque chose (à moins d'attendre que le RFC en parle et commence à mettre du SHOULD). À l'inverse, avec un lien magnet, le protocole alternatif est précisé.

    Le seul vrai avantage que je trouve à ni est nih: une réflexion sur comment communiquer un hash via un moyen qui peut couper les mots ou être facilement dégradé. Ça donne des trucs presque lisibles.

    Au final, j'ai l'impression qu'on se retrouve avec la même situation qu'IRC et XMPP : on a d'un côté un protocole bidouillé au fil des âges, sans vrai documentation (il y a bien des RFC pour IRC, mais il semblerait que chacun fasse plus ou moins ce qu'il veut dans son coin…), mais utilisé par plusieurs milliers de personnes, qui fait ce qu'on lui demande et même plus, et de l'autre côté un protocole très bien documenté, qui est le fruit de nombreuses discussions, et qui du coup peut être un guide pour le développeur perdu, mais qui a du mal à prendre parce qu'il ne se démarque pas suffisamment de ce qui existe déjà (en dehors de Google et Jabber.org, quel grand nom utilise une version ouverte de XMPP ?). Les liens magnets sont déjà utilisés par des millions de personnes, est-ce que le changement vers ni a du sens ?

  • # URN ?

    Posté par (page perso) . Évalué à 3.

    À ce que je vois, il s'agit d'URI de type URL. Est-ce vraiment pertinent ? Tout comme les schémas news, mid et magnet, cela me semble un mésusage des URL pour ce qui devrait être des URN…

    • [^] # Re: URN ?

      Posté par (page perso) . Évalué à 3.

      Non, les URI "ni" ne sont pas forcément des URL. Ils peuvent l'être (si on met l'autorité) mais ce n'est pas obligatoire.

      Et le but est justement de faire mieux que les URN. Ceux-ci ne sont pas « actionnables », on ne peut pas s'en servir pour récupérer une ressource. C'est bien pour cela que les URN ont eu peu de succès en pratique. (Avant les "ni", il y avait eu une proposition de faire la même chose avec des URN, draft-thiemann-hash-urn, mais elle n'avait pas abouti.)

  • # Sacré Graal

    Posté par (page perso) . Évalué à 5.

    Heureusement qu'il y a des RFC comme celle-ci et les chevaliers qui disent ni !

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.