Résumé

  • Le RFC 2079 a défini l’attribut sensible à la casse et multivalué labeledURI, ainsi qu’une classe auxiliaire permettant de l’ajouter à un objet X.500 ou LDAP existant.
  • Un espace non encodé séparait l’URI d’un libellé facultatif. Plusieurs valeurs pouvaient viser des ressources distinctes ou plusieurs emplacements de la même ressource, sans indicateur permettant de trancher.
  • Une URI enregistrée ne prouvait ni disponibilité, ni fraîcheur, ni autorité, ni équivalence. Le libellé n’était pas du HTML fiable : le texte mettait expressément en garde contre son insertion aveugle.

En 1997, l’idée d’ajouter une adresse web à un annuaire n’était déjà plus neuve. Plusieurs groupes le faisaient dans LDAP et X.500. Le travail utile du RFC 2079 consistait à leur donner une définition commune, afin qu’un client reconnaisse la même forme chez plusieurs producteurs.

Une valeur commençait par une URI — alors une URL conforme au RFC 1738 — et pouvait se poursuivre par des espaces puis un libellé destiné au lecteur. Une URL ne contenant pas d’espace littéral, la première séparation non encodée indiquait précisément où commençait le texte humain. Le problème du découpage était résolu.

Le pluriel conservait une ambiguïté légitime

Le RFC précisait que plusieurs valeurs représenteraient généralement différentes ressources liées à l’objet, mais pourraient aussi être plusieurs lieux de la même ressource. Une page personnelle et une photographie ne sont pas un site principal et son miroir. Pourtant l’attribut ne portait aucun rôle explicite comme portrait, archive, copie, source canonique ou secours.

Le libellé pouvait suggérer le type ou la taille d’un contenu, mais aucune grammaire ne lui était imposée. « Site officiel » demeurait une affirmation humaine. L’annuaire pouvait attester que la chaîne avait été enregistrée sous un attribut connu ; il ne pouvait pas attester que la cible reconnaissait cette relation ou que deux adresses étaient interchangeables.

Le RFC 3986 a ensuite décrit plusieurs niveaux de comparaison des URI. Deux chaînes strictement identiques peuvent être considérées comme équivalentes ; deux chaînes différentes peuvent néanmoins mener à la même ressource après normalisation propre à leur syntaxe ou à leur protocole. Conserver exactement les caractères est donc une preuve d’écriture, pas une théorie complète de l’identité.

Ajouter une classe n’ajoutait pas une autorité

La classe auxiliaire labeledURIObject pouvait être ajoutée à un objet existant et autorisait labeledURI sans exiger d’autre valeur. D’autres classes pouvaient également adopter directement l’attribut. Cette souplesse élargissait les endroits où le pointeur pouvait apparaître.

Le RFC 2798 l’a rendu facultatif dans inetOrgPerson et a donné l’exemple d’une page personnelle. Le RFC 3383 a conservé les noms et identifiants dans le tableau LDAP. Ces étapes prouvent réutilisation et repérage de la définition, non validation des cibles ni généralisation des usages.

Le RFC 3296 a repris la même forme pour les références subordonnées LDAP, avec une sémantique plus étroite. Son attribut ref n’utilisait pas le libellé, l’enlevait lors de la construction d’un renvoi et recommandait au serveur détenteur de ne pas valider l’intégrité référentielle. Il fallait donc un autre document pour transformer une forme générale en action protocolaire précise.

Le texte amical changeait de nature à l’affichage

Le libellé était conçu pour les humains. Le RFC 2079 déconseillait les caractères non ASCII, que les clients de l’époque pouvaient traiter différemment, et distinguait les conventions X.500 des échappements HTML. Sa mise en garde la plus nette concernait l’affichage : copier directement le libellé dans une page HTML pouvait laisser des balises tromper le lecteur.

Le passage du stockage au rendu est donc une frontière d’exécution. Le client doit échapper le texte, montrer la destination et décider si le lien devient cliquable. Puis la cible ajoute ses propres inconnues : redirection, changement de propriétaire, contenu nouveau, hôte expiré ou comportement spécifique au protocole.

Une enquête solide sépare l’entrée, la valeur, le découpage URI/libellé, la multiplicité, la relation revendiquée, l’auteur de cette revendication, la récupération de la cible, son origine, son actualité et son affichage. Aucune de ces étapes ne peut être remplacée par la précédente.

Un seul attribut n’unifiait pas les significations

Une version antérieure avait créé labeledURL. Le RFC 2079 l’a rendu obsolète : le groupe préférait un attribut URI à deux attributs concurrents. L’ancienne définition restait documentée pour faciliter la transition des clients.

Réduire le vocabulaire commun simplifiait l’échange. Cela ne supprimait pas les anciennes valeurs, ne prouvait pas leur migration et n’ajoutait pas de rôles aux relations. Le mot URI, plus large, ne rendait pas non plus tous les protocoles équivalents.

La leçon historique est précise : normaliser l’attache d’un pointeur permet aux systèmes de l’échanger. Cela ne normalise ni la raison du lien, ni son état présent, ni la confiance que mérite le texte placé à côté.

Sources