Résumé

  • RFC 1485 répondait à une question précise : comment faire voyager dans un message ou sur papier un Distinguished Name X.500 déjà connu, sans perdre sa structure ASN.1.
  • Une chaîne conforme déterminait un DN lors de l’analyse, mais un même DN pouvait connaître plusieurs rendus valides selon le séparateur, la disposition, le descripteur de type ou l’échappement. L’absence d’ambiguïté n’était pas la canonicité.
  • Le résultat de l’analyse demeurait en amont de l’annuaire et de la décision : existence de l’entrée, fraîcheur, égalité, authentification, autorisation et effet exigeaient d’autres reçus.

Le nom qui changeait de forme en changeant de support

Sur une fiche imprimée, un long nom d’annuaire pouvait se répartir sur plusieurs lignes. Dans un courrier électronique, il pouvait tenir sur une seule ligne. Le premier émetteur séparait les parties par des points-virgules ; le second préférait des virgules. Le lecteur voyait deux objets graphiques, alors qu’un analyseur pouvait y retrouver la même suite de Relative Distinguished Names.

C’est à cette traversée que RFC 1485, publié en juillet 1993, consacrait son effort. Dans X.500, le DN servait de clé structurée à une entrée et sa représentation protocolaire relevait d’ASN.1. Or une carte de visite ou un message humain ne transportait pas naturellement cet objet. Il fallait une notation lisible, mais assez générale pour ne pas abandonner les cas difficiles.

La question venait après celle de la recherche. RFC 1484 partait d’un nom convivial supposé et laissait l’annuaire proposer des DN. RFC 1485 partait d’un DN acquis et cherchait à le sérialiser. Confondre les deux reviendrait à prendre une requête approximative pour une clé, ou une clé imprimée pour le résultat d’une consultation.

Une grammaire discrète sous la page

Chaque assertion associait un type d’attribut à une valeur au moyen du signe =. Les RDN étaient présentés dans un ordre commode pour l’utilisateur, du plus spécifique vers les contextes plus larges. Une virgule ou un point-virgule séparait les étapes du nom. Le signe + avait une autre fonction : il réunissait plusieurs assertions dans un seul RDN multivalué.

La différence est structurelle. Remplacer un + par une virgule ne modifie pas seulement la mise en page ; cela transforme une étape de nommage composée en deux étapes successives. Omettre le type d’attribut n’était pas non plus une variante du DN selon RFC 1485, même si la grammaire avait été pensée avec les usages plus souples des noms conviviaux.

La notation conservait ainsi quatre renseignements : le type, la valeur, le regroupement des assertions et l’ordre des RDN. L’analyseur n’avait pas à deviner la hiérarchie d’après la police ou l’alignement. Ce résultat, modeste en apparence, permettait de sortir le nom du protocole d’annuaire sans le réduire à une légende visuelle.

La beauté pour l’ordinaire, l’échappatoire pour le réel

Les valeurs ordinaires devaient rester intuitives. Mais une valeur pouvait contenir une virgule, un guillemet, des espaces aux extrémités ou plusieurs espaces consécutifs. Guillemets et échappements protégeaient alors les données contre leur interprétation comme ponctuation de grammaire.

Une difficulté plus profonde apparaissait lorsqu’un logiciel ne connaissait pas le mot court désignant un type d’attribut. Le type pouvait être écrit par son OID numérique en notation pointée. Et lorsqu’aucune forme d’affichage satisfaisante n’existait pour la valeur, RFC 1485 autorisait une représentation hexadécimale de son encodage BER.

Le texte qualifiait ce dernier résultat de laid et le réservait surtout aux cas pathologiques. Pourtant, c’était la clause la plus ambitieuse. Une notation limitée aux attributs déjà familiers aurait été élégante et fragile. L’OID et l’hexadécimal permettaient de préserver une information future, privée ou inconnue sans prétendre que le destinataire en comprenait déjà le sens.

La généralité venait donc d’un aveu : l’interface ne saurait pas toujours présenter joliment tout ce que le modèle savait transporter.

Une seule destination d’analyse, plusieurs chemins textuels

Dire qu’une chaîne est analysable sans ambiguïté décrit son arrivée. Cela n’impose pas une origine unique. Les virgules, points-virgules et dispositions différentes offraient déjà plusieurs surfaces au même objet. Selon les registres connus, un type pouvait apparaître comme descripteur ou comme OID. Les règles d’échappement et d’encodage ajoutaient encore des choix de sérialisation.

L’histoire ultérieure a rendu cette limite explicite. RFC 1779 a remplacé RFC 1485. RFC 2253 a défini une représentation LDAPv3 en UTF-8, puis RFC 4514 lui a succédé. RFC 4514 ne définit pas une chaîne canonique pour un DN : des algorithmes de conversion différents sont admissibles si leur résultat demeure analysable. Pour décider de l’égalité, il renvoie à distinguishedNameMatch, pas à l’identité brute des caractères.

Ce n’est pas attribuer rétrospectivement la formulation de RFC 4514 à RFC 1485. C’est préciser la portée de la promesse ancienne. Une chaîne pouvait conduire sans hésitation à une structure, tandis que cette structure pouvait se laisser imprimer de plusieurs façons.

Ce que l’œil, l’octet et l’annuaire attestent chacun

Une capture d’écran atteste des glyphes. Une archive de courrier peut conserver des octets et un jeu de caractères. Un analyseur produit des types, des valeurs et des RDN ordonnés. Le moteur d’annuaire compare ensuite ces valeurs selon le schéma. Aucun de ces témoins ne remplace automatiquement le suivant.

RFC 4512 situe les noms, les schémas et les règles de correspondance dans le modèle d’information LDAP. RFC 4517 décrit des syntaxes et règles de comparaison. RFC 4518 montre pourquoi les chaînes internationalisées demandent une préparation propre — mappage, normalisation, caractères interdits et règles bidirectionnelles ne se déduisent pas d’une ressemblance visuelle.

Deux textes différents peuvent donc représenter des DN égaux ; deux textes apparemment identiques peuvent cacher des points de code, des octets ou des regroupements différents. Dédupliquer des comptes par comparaison de chaînes, ou « nettoyer » un ancien DN en supprimant ses espaces sans connaître le schéma, déplace une décision sémantique dans une opération typographique.

Le seuil de l’annuaire restait à franchir

RFC 1309 exposait l’architecture distribuée de X.500 : DUA, DSA, contextes de nommage, chaînage, renvois et répliques. RFC 1485 ne garantissait aucun de ces comportements. Une fois analysé, le DN pouvait servir à une opération d’annuaire ; il n’en constituait pas la réponse.

La réussite syntaxique ne prouvait donc pas qu’une entrée existait encore, qu’une réplique était à jour, que tous les attributs étaient visibles ou que l’objet réel correspondait toujours aux données. Même une entrée trouvée ne faisait pas du DN une authentification. Un fournisseur d’identité devait encore établir le contrôle d’un compte ; une application devait autoriser l’action ; une institution devait répondre du rôle ou du statut extérieur.

La section de RFC 1485 consacrée à la sécurité indiquait que ces questions n’étaient pas abordées. Il serait abusif de faire porter à la notation une confidentialité, une intégrité ou une résistance à l’usurpation qu’elle ne spécifiait pas.

Une norme historique laisse des objets vivants

La notice du RFC Editor classe aujourd’hui RFC 1485 comme Historic. RFC 3494 participe au passage de LDAPv2 au statut historique. Les successeurs ont affiné l’UTF-8, les échappements, les descripteurs et surtout la séparation entre représentation et égalité.

Ce statut raconte une filiation normative, non la disparition instantanée des artefacts. Des chaînes anciennes peuvent demeurer dans des journaux, des configurations, des certificats, des sauvegardes ou des courriers. Leur migration dépend des parseurs, registres et schémas effectivement utilisés. « Obsolète » ne signifie ni inutile à son époque, ni uniformément absent du logiciel encore exécuté.

Garder un reçu à chaque frontière

Les textes de Heng Lu sur la primauté du code en fonctionnement, la décision future localisée et les couches de réalité éclairent ce partage. La spécification commune fixait une grammaire minimale. Le sérialiseur décidait localement de la présentation. Le parseur attestait la structure récupérée. L’annuaire détenait son état. Les systèmes d’identité et les applications prenaient leurs décisions ultérieures.

Une preuve sérieuse conserve donc le DN structuré d’origine lorsqu’il existe, les octets transportés, le traitement du jeu de caractères, les versions du sérialiseur et du parseur, le registre de descripteurs, la structure obtenue, le schéma, la règle d’égalité, l’instantané d’annuaire, l’authentification, l’autorisation et l’effet final.

RFC 1485 n’avait pas besoin d’être plus vaste pour être décisif. Il rendait une structure portable à travers le texte. Sa leçon est de ne jamais laisser cette portabilité se faire passer pour la réalité située au-delà du texte.

Sources