Résumé

  • RFC 3383 n’a pas soumis toutes les extensions LDAP à une approbation uniforme : Standards Action, examen d’expert, Specification Required, premier arrivé, expérimentation et usage privé correspondaient à des risques différents.
  • L’inscription d’un identifiant attestait une coordination, non une implémentation ou une sécurité. Sa valeur venait de la spécification, du responsable et du chemin de modification rendus publics.

Deux équipes peuvent ajouter une fonction à LDAP et choisir le même nombre pour deux résultats incompatibles. Les octets restent valides ; la signification se divise. Un décodeur n’échoue pas nécessairement. Il peut faire pire : accepter la valeur et lui attribuer le sens de sa propre implémentation.

Publié en septembre 2002 comme BCP 64, RFC 3383 organisait ce problème. LDAP permettait déjà de créer des opérations, d’étendre des opérations existantes et d’enrichir le schéma. L’extensibilité technique avait donc besoin d’une infrastructure de noms qui évite que plusieurs inventions occupent silencieusement la même place.

Le document n’a pas construit une file unique. Les types de messages, les mécanismes découvrables, les codes de résultat, les méthodes d’authentification, les descripteurs d’OID et les options d’AttributeDescription n’avaient ni la même rareté ni le même effet sur l’interopérabilité. Il leur a attribué des politiques distinctes.

Pour un élément développé par l’IETF, une spécification pouvait recevoir un OID sous l’arc Internet Directory Numbers après Expert Review avec Specification Required. IANA attribuait un seul arc à la spécification ; celle-ci pouvait ensuite créer ses sous-OID sans demander une nouvelle coordination pour chaque feuille. L’autorité centrale protégeait la branche, tandis que le texte normatif organisait son espace local.

Les autres concepteurs pouvaient employer tout OID correctement délégué, y compris sous un Private Enterprise Number. Pour les travaux encore instables, le RFC recommandait les OID expérimentaux. Les premiers essais évitaient ainsi de se fixer prématurément sur l’identifiant de la publication finale. Un OID expérimental ne devait pas rester dans une spécification publiée.

Les mécanismes que Root DSE permettait de découvrir formaient un autre cas. Les OID de contrôles et d’extensions publiquement décrits pouvaient être enregistrés selon First Come First Served avec Specification Required. Un mécanisme du Standards Track devait, lui, passer par Standards Action. Une description accessible suffisait parfois à éviter une collision ; modifier l’espace des standards exigeait davantage.

Ces mots ne sont pas des niveaux d’une même certification. Premier arrivé ne signifie ni sûr ni recommandé. Specification Required ne transforme pas un texte en standard IETF. Standards Action ne prouve aucune présence dans un logiciel. Chaque règle indique seulement ce qui doit exister avant qu’une valeur entre dans un espace partagé particulier.

Les descripteurs rendaient les OID numériques plus lisibles. Ils étaient insensibles à la casse et plusieurs noms pouvaient désigner le même OID. Un nom terminé par un trait d’union pouvait réserver une famille entière. Le préfixe x- désignait l’usage privé, impossible à enregistrer ; e- signalait l’expérimentation et utilisait le premier arrivé ; les autres noms demandaient un examen d’expert.

Les options d’AttributeDescription reprenaient une séparation comparable. Leur longueur recommandée et leurs politiques différaient légèrement, mais les chemins privé et expérimental demeuraient visibles dans le nom. Le préfixe déclarait la portée de la coordination. Il n’accordait pas une unicité mondiale à une valeur privée.

Les plages numériques des resultCode rendaient la gradation explicite. De 0 à 1023, une nouvelle valeur nécessitait Standards Action. De 1024 à 4095, Expert Review avec Specification Required. De 4096 à 16383, First Come First Served accompagné d’un mot-clé e-. À partir de 16384, ainsi que pour les mots-clés x-, l’espace était privé et non enregistrable.

Les méthodes d’authentification utilisaient les mêmes plages et ajoutaient une classification : COMMON, LIMITED USE ou OBSOLETE. Sans spécification publique, une méthode ne pouvait être COMMON. Une nouvelle inscription ne pouvait pas naître OBSOLETE. Le registre gardait donc aussi une affirmation sur l’usage prévu, sans garantir que cet usage était effectivement répandu.

Les nouveaux types de messages LDAP exigeaient Standards Action. L’existence de messages extensibles réduisait la nécessité de modifier le choix principal du protocole, mais ne la supprimait pas. Toucher à l’enveloppe de base avait un coût de coordination supérieur à celui d’une expérience privée.

RFC 3383 a également fermé une ancienne porte sans effacer son passé. Les Directory Systems Names, liés à une représentation LDAPv2 des distinguished names, n’acceptaient plus de nouveaux enregistrements puisque LDAPv3 employait les descripteurs d’OID. La liste historique devait pourtant rester disponible. Conserver la mémoire ne signifiait pas prolonger l’allocation.

La procédure donnait une réalité aux politiques. Une Standards Action passait par l’IESG. Une demande d’Expert Review utilisait un formulaire complet et restait deux semaines en examen public. Une révision du formulaire relançait la période. Les participants pouvaient objecter ; l’expert approuvait et transmettait ou refusait, et sa décision pouvait être contestée selon la procédure d’appel.

Les demandes First Come First Served allaient directement à IANA. La propriété suivait aussi le chemin d’enregistrement : IESG était considéré comme propriétaire des valeurs Standards Action ; le demandeur contrôlait généralement celles issues d’Expert Review ou du premier arrivé. Ce détail devenait décisif après l’allocation.

Une inscription pouvait être mise à jour sous les mêmes contraintes qu’une nouvelle. Si son propriétaire ne pouvait ou ne voulait pas effectuer une correction nécessaire, IESG pouvait en prendre le contrôle. Lorsqu’un tiers formulait une objection sérieuse et que le propriétaire refusait de modifier l’entrée, un commentaire pouvait être attaché après examen d’expert. Le registre pouvait préserver le désaccord au lieu de prétendre qu’il n’avait jamais existé.

Les modèles de l’annexe montrent le véritable objet de conservation : identifiant, description, spécification, contact, auteur ou responsable des changements, usage et commentaires. Un numéro nu empêche seulement deux allocations régulières d’être identiques. Il ne dit pas ce que signifie la valeur ni qui peut réparer sa définition.

RFC 2434 fournissait le vocabulaire général des politiques d’enregistrement ; RFC 8126 l’a ensuite modernisé. Les pages actuelles des paramètres LDAP d’IANA prouvent la continuité d’un registre public vivant, pas l’immuabilité de chaque champ depuis 2002 ni l’existence d’une implémentation active pour chaque entrée.

RFC 3377 situait ce travail dans la spécification LDAPv3 de l’époque. RFC 2251, RFC 2252 et RFC 2255 fournissaient le contexte du protocole, du schéma et des extensions d’URL ; RFC 4510 a plus tard décrit la spécification révisée. Cette chronologie ne constitue pas un recensement d’adoption.

La décision durable fut d’ajuster la friction au risque. Imposer une norme complète à toute expérimentation aurait découragé l’essai. Distribuer sans documentation tous les identifiants communs aurait reporté le coût sur les futures pannes d’interopérabilité. Les espaces expérimentaux et privés restaient ouverts, mais leurs limites empêchaient de les confondre avec une signification publique coordonnée.

La spécification initiale minimale de Lu Heng éclaire cette architecture : définir partitions, procédures, formulaires, propriétaires et chemins de réparation, sans décider à l’avance de chaque extension future. Sa lecture des couches de réalité sépare allocation, enregistrement, spécification, code, déploiement et résultat. Une ligne IANA est une preuve forte de coordination, pas un certificat des autres couches.

RFC 3383 a ainsi transformé l’extensibilité en responsabilité durable. L’identifiant donnait une place à l’extension. La politique déterminait ce qu’elle devait révéler avant de rejoindre l’espace commun. Le registre permettait encore, des années plus tard, de retrouver son sens, son responsable et la voie de correction.

Sources