Résumé

  • RFC 1274, publié en novembre 1991 sur la voie de normalisation de l’IAB, proposait un schema X.500 pour les pilotes COSINE et Internet, indépendant de toute implémentation. Les définitions X.500 de base étaient utiles, mais insuffisantes pour un pilote à grande échelle ; répéter en privé des définitions communes empêchait les systèmes distants d’en connaître la sémantique.
  • La conformité demandait qu’un DSA puisse stocker les valeurs définies et qu’un DUA puisse identifier chaque type. Le rapprochement correct, l’application du schema de classe, l’affichage correct et la compatibilité avec une version antérieure restaient souhaitables, non obligatoires. Les attributs optionnels pouvaient enrichir une classe ; une modification d’attribut obligatoire imposait une nouvelle classe et l’expiration de l’ancienne.

Un vocabulaire commun n’était pas une prise de possession du réel

RFC 1274 laissait délibérément les besoins locaux, rares ou très expérimentaux dans des définitions privées. Le document ne cherchait donc pas à centraliser chaque distinction utile. Il visait les objets et attributs dont plusieurs sites avaient besoin, car des copies privées de la même notion réduisaient la généralité : une machine distante recevait une valeur sans pouvoir déterminer de façon sûre ce que le type privé signifiait.

Le schema partagé répondait à ce problème de langage. Il aidait des systèmes indépendants à employer une définition commune et cherchait à éviter les doublons pour des objets réels essentiellement semblables. Mais un terme commun ne certifie ni la valeur portée par une entrée, ni la personne ou l’institution à laquelle elle se rapporte, ni le droit de l’administrateur à la publier.

Le nom d’attribut rend une assertion lisible dans un cadre. Il ne transforme pas l’assertion en fait vérifié ni en mandat.

Stocker et identifier formaient un plancher, pas une compréhension complète

Pour se dire conforme, un DSA devait pouvoir stocker les valeurs des attributs et classes indiqués ; un DUA devait pouvoir identifier chaque type auprès de l’utilisateur avec une représentation appropriée. Pour les grandes valeurs, la règle était limitée : le DSA ne devait pas nécessairement les stocker ni le DUA les afficher, mais leur présence devait être indiquée.

Ce plancher rend l’échange possible. Il ne dit pas qu’un serveur compare correctement une syntaxe, que le client restitue correctement une valeur, que l’entrée est fraîche ou que la personne décrite l’a autorisée. Une donnée peut être présente dans un annuaire sans que son sens, sa qualité et son lien avec le monde extérieur soient établis.

RFC 1274 évite ainsi une confusion qui accompagne souvent les répertoires : une capacité de stockage est une capacité de représentation, non une preuve de vérité.

Les comportements souhaitables gardaient leur statut propre

Le texte qualifie de souhaitables, sans les rendre obligatoires, quatre capacités : rapprocher correctement toutes les syntaxes définies, appliquer le schema de classe impliqué, afficher correctement les valeurs et conserver la compatibilité avec une version antérieure. Ces réserves ne sont pas des détails d’implémentation. Elles séparent quatre opérations dont la présence d’un type commun ne garantit aucune.

Le rapprochement répond à une question de comparaison. L’application du schema répond à une question de contrainte. L’affichage répond à une question de représentation humaine. La compatibilité répond à une question de continuité entre versions. Une entrée visible peut donc attester qu’un système a rendu une valeur stockée ; elle n’atteste pas, par elle-même, toutes les opérations ni toutes les qualités qui la rendraient fiable hors de ce système.

L’optionnel pouvait enrichir sans réécrire l’appartenance

La règle d’évolution est la partie la plus nette du RFC. Lorsqu’une modification ajoutait seulement des attributs facultatifs, la classe pouvait être enrichie. Les anciennes instances n’avaient pas besoin de produire un nouveau fait pour continuer à appartenir à la même classe.

En revanche, si la modification touchait les types d’attributs obligatoires, RFC 1274 proposait de créer une nouvelle classe et d’expirer l’ancienne. La différence est sémantique : un attribut obligatoire participe à ce qu’il faut être pour entrer dans la classe. Le modifier silencieusement ferait passer le même identifiant pour une promesse différente.

La nouvelle classe conserve une frontière lisible. Elle permet de demander quelle définition s’appliquait à une entrée, au lieu de réécrire le passé avec une condition apparue plus tard.

Le schema réglait le vocabulaire, non l’autorité de l’entrée

Un schema peut donner à des sites indépendants une langue commune. Il ne répond pas à la question de savoir si une valeur est exacte, si elle doit être publiée, si son sujet la reconnaît, si une politique locale la protège, ou si une recherche particulière produit un résultat correct.

Cette modestie est la force historique du texte. Les définitions partagées n’avaient pas à devenir une constitution du monde décrit. Elles pouvaient améliorer la coordination tout en laissant visibles les preuves et autorisations qu’elles ne fournissaient pas.

Sources et limites de preuve

Cet article utilise RFC 1274 — The COSINE and Internet X.500 Schema. Il établit le statut et le contenu du schema de 1991, les règles sur les définitions communes et locales, le plancher de conformité, les capacités souhaitables et l’évolution des classes. Il ne prouve ni service X.500 actif, ni exactitude ou fraîcheur d’une entrée, ni identité, autorisation, confidentialité, comportement d’un DSA/DUA ou résultat de service actuel.