Chaque entité dispose par nature d’un identifiant unique, invariant et non cessible. C’est une clé cryptographique publique.
Cependant cet identifiant ne précise pas la place de l’entité, ou plutôt la place où on peut la joindre.
Les entités, pour pouvoir échanger, doivent avoir une place publique, c’est la localisation.
Cette place est-elle unique d’ailleurs?
En fait non, l’entité peut être présente en de multiples places, soit par le biais de relais, soit parce que la clé privé aura été volé et exploité.
Ce qui différencie fortement l’entité d’une ressource web classique, c’est que l’entité est unique quelque soit sa localisation, et n’existe pas uniquement du fait de l’existence du serveur web qui l’héberge. Cette entité survira à la disparition d’un serveur web, sa résilience est grandement amélioré et ne dépend que faiblement de sont environnement.
(Cette réflexion est mené en préambule de l’expérience 4)
On va ici réduire le problème à des échanges via le protocole http, et donc à des places sur les serveurs web. Ces serveurs ayant un nom de domaine unique (et souvent une adresse IP unique).
Cette localisation impose plusieurs choses :
1/ définition de la localisation
2/ attachement d’une localisation à l’entité
3/ résolution de la localisation
1/ Définition
Se restreignant au web, la localisation est donc une URL de type http ou https (CF Wikipedia – URL [FR] et RFC2616[EN].
Une entité est-elle unique sur une URL donnée? Ne faut-il pas prévoir qu’une URL, et donc souvent un seul serveur, puisse héberger plusieurs entités? Ces multiples entités pouvant n’être que des automates au service d’une seule entité.
1.1/ Champs
Les éléments qui doivent apparaître :
1- l’entité
2- l’objet (source)
Les éléments optionnels :
Рla requ̻te sur un objet ou sur les liens
– l’objet cible
– l’objet méta
Рla p̩riode de temps
Pour rappel, le lien a cette forme : Signature-HashSignataire-TimeStamp-Action-HashSource-HashCible-HashMeta
On retrouve des choses similaires avec ce que l’on veut obtenir : (?)-Entité-PériodeTemps-Requête-Objet-ObjCible-ObjMeta
1.2/ Formes des URL
Il y a de multiples façons d’intégrer des éléments dans une URL. On peut ainsi mettre quelques informations dans le nom de domaine, dans la partie répertoire ou fichier, ou sous forme d’options.
On peut tout mettre en options de l’URL :
http://site.net?entité=0123456789abcdef&objet=a9c66dbee3b73720&req=liens
Cette forme d’URL est assez souple mais pas toujours facile à lire. Mais après tout, ce seront les machines qui la liront. Elle présente néanmoins l’avantage de nommer explicitement les champs ce qui est aussi une perte de place net pour les champs obligatoires qui, eux, peuvent être prépositionnés de façon stricte.
Une autre forme d’URL peut être :
http://site.net/0123456789abcdef/a9c66dbee3b73720/l
Cette forme est plus courte, a des champs prépositionnés dont la signification est implicite, est reste assez lisible avec un peu de pratique. A part le début de l’URL, le nom de domaine et sa forme imposés http://site.net/, pour la suite le séparateur ‘/’ peut être remplacé par un autre séparateur.
Mais comment cela se passe avec les champs optionnels?
De plus, cette forme d’URL nécessite soit une organisation strict est pré-adapté des objets, soit un traitement/traduction au niveau du serveur web.
Une dernière forme permet de placer un champs dans la partie nom de domaine, comme ceci :
http://0123456789abcdef.site.net/a9c66dbee3b73720/l
Cette forme n’est pas plus courte que la précédente, cependant elle nécessite aussi du travail de traitement/traduction sur les URL côté serveur web.
1.3/ Limites
Toutes ces formes sont possibles, tant que l’on respecte les contraintes des URL. Quelles limites avons nous sur les URL http?
La limite de l’espace des caractères utilisables. Nous utilisons les caractères ASCII pour la date, le même mais restreint à l’alphabet pour les actions, et les chiffres en base hexadécimale (0 à 9 et a à f) pour les objets. Rien de tout cela n’est hors de ce que peut accepter une URL.
La limite de taille de l’URL. Cette limite, telle que défini par la RFC2616[EN] est uniquement dépendante du bon vouloir des navigateurs et des serveurs web. Une étude empirique montre que c’est assez disparate (étude de 2006 mais qui semble toujours d’actualité) et qu’il est préférable de ne pas dépasser 2000 caractères pour que tous les navigateurs puissent l’utiliser. Apache, par exemple (le serveur que j’utilise), est volontairement limité à 4000 caractères, ce qui veut dire que l’on ne peut utiliser d’URL de plus grande taille en pratique.
Une empreinte de 512bits (sha512sum par exemple) occupe 128 octets dans sa notation hexadécimale affichée en ASCII.
L’exemple ci-dessous fait 539 caractères et utilise des empreintes de 512bits :
http://neb.nebule.org/1693306c861103bce613b2537a1e6542c1d7cd00152c31feddd9c2853c6cafc868efae4fd20eb22485c63f404af9de11caa9fa8c13c24f8d848fd9279e80c5fc/e1fe8e95010d855c097435e49055198e9ca70ee7dd301dc24533c3705773d354472344b45d5d286d35fd3a26f7c24b8d4c8491f119efaed2648994f41fb3dc06/l/779aca9c758c7d46fb537c013fae9cd1a529af276cf1e121a6870aad9987ad6a70232d92ecc665037fd24208b7b79be5960ad1de326365696665ed8c6f03aacd/078ef386644bf75e8f3c2b3355d9347294344b889b0703da7bc14c02cb20e2d63cdf81158e4b3fd022352505996d90c2087d25241fb01c5dd03cc501a0223b74
Cette exemple montre que, en utilisant sha512, l’URL sera inférieur à 600 caractères.
Donc, au moins dans un premier temps et pour un avenir à moyen terme, c’est utilisable.
1.4/ Variabilité de la forme
La requête sur l’objet ne peut prendre que deux valeurs, L ou O. C’est à dire que l’on demande l’objet (son contenu) ou ses liens. Ce champ est optionnel, son absence signifie que l’on demande l’objet.
Cette forte prédétermination permet une reconnaissance certaine de ce champ, quelque soit sa place dans l’URL.
L’objet cible et l’objet méta sont des empreintes. L’empreinte est représenté par une suite de caractères ASCII limités au nécessaire pour représenter l’hexadécimal, soit 16 caractères possibles.
Sauf quelques très rares cas, ces objets ne sont pas échangeable dans les liens. Cela implique que si l’on demande l’un ou l’autre (avec l’objet source), on aura des réponses qui respectent le type de ce second (voir troisième) objet de l’URL.
Il n’est donc pas besoin de préciser leur qualité, et donc peuvent être interchangeable à condition que l’objet source reste parfaitement identifiable.
Les rares cas d’interversion de ces deux objets peuvent facilement être traités par l’entité qui fait la requête.
De plus, ces deux champs n’ont pas de raison d’être si la requête n’est pas L.
La période de temps est plus problématique. Ce champ n’est pas encore pleinement définit même si il sera restreint à de l’ASCII.
Étant le seul champ aujourd’hui problématique, il peut simplement être positionné à la fin.
De plus, ce champ n’a pas de raison d’être si la requête n’est pas L.
L’entité doit-elle apparaître dans l’URL?
On peut assumer le fait que, dans certains cas, une seule entité est accessible à une adresse donnée. Mais en supprimant l’information de l’entité que l’on vise, cela réduit de fait les échanges à ce que propose directement l’entité attachée à l’URL, et exclue donc la possibilité de récupérer des informations qui ne sont pas liées à cette entité.
Mais si l’entité derrière l’URL est unique, elle héberge des objets qui sont accessibles de façon arborescente. Et si une entité, en tant que relai, héberge une copie d’une autre entité, cette entité hébergée hérite en localisation d’une sous-lien de cette entité relai. Cette entité hébergé peut naturellement ajouter ce sous-lien dans ses localisations, et devient ainsi accessible aussi à cette adresse.
Le champ entité peut donc ne pas être présent dans l’URL, et ne doit pas être interprété comme un champ mais utilisé tel quel.
Comment vont pouvoir se propager des liens sur des objets que l’on héberge mais dont on est pas signataire, des liens que l’on partage « par relation de confiance »? Cet aspect n’est pas encore étudié et sera résolu plus tard.
Il en résulte que la place des champs est fixe et en premières positions pour l’entité et l’objet source, ainsi que en dernière position pour la période de temps éventuelle. Et les autres champs sont placés si besoin entre.
Cependant, dans un premier temps et par simplification, on n’utilisera pas, l’entité, l’objet cible, l’objet méta et la période de temps. Ensuite, on rend obligatoire et non plus optionnel la requête sur l’objet. Cela réduit donc les champs utilisés à l’objet source et la requête sur l’objet.
Cette propriété arborescente, qui n’a pas vocation à être directement propagée, offre une souplesse qui pourra être exploité plus tard. Mais impose une contrainte supplémentaire sur l’URL qui va permettre les échanges. On doit pouvoir distinguer ce qui appartient à l’URL de base, fourni comme localisation d’une entité, et les champs optionnels. Ne pas utiliser ces champs optionnels dans un premier temps simplifie grandement le problème. Ces champs optionnels pourront ensuite être intégrés sous forme d’options de l’URL.
1.5/ Forme
Il faut définir une manière commune de travailler, un protocole.
Dans un premier temps, ce protocole doit être assez stricte dans la définition de la forme des URL utilisées. Il pourra ensuite être assoupli avec les retours d’expériences.
L’URL retenu est de la forme :
http://server.net/Objet/Requête
Avec un traitement de l’URL côté serveur, ou un pré-agencement des fichiers.
Soit, par exemple, le téléchargement d’un objet :
http://neb.starend.org/bed8ee9b19b156d94ca6c5bdc359f6e4/6e0f296c00bfebe8587d14b5eaf67786/o
et le téléchargement des liens de cet objet :
http://neb.starend.org/bed8ee9b19b156d94ca6c5bdc359f6e4/6e0f296c00bfebe8587d14b5eaf67786/l
2/ Attachement
L’entité doit être capable par ses propres moyens de partager sa ou ses localisations. Chaque localisation est un objet contenant une URL, objet lié à l’entité par un objet méta le définissant comme étant une localisation.
L’objet contenant la localisation est donc un objet de type texte contenant uniquement l’URL.
L’objet méta contient uniquement le texte « nebule/entite/localisation« .
3/ Résolution
La dernière étape permet à toute entité de retrouver une autre entité ainsi que ses localisations. C’est classiquement le rôle d’annuaire.
L’annuaire peut être implémenté comme une entité relai qui tient à jour et partage les entités abonnées (objets clé publique) ainsi que les objets de localisations associés.
Pour qu’une résolution marche, il faut disposer au moins d’une localisation valide et accessible.