Résumé

  • RFC 822, en août 1982, séparait les champs formellement publiés du courrier des champs définis par leurs utilisateurs. Les extensions officielles ne devaient jamais commencer par X-, laissant cette graphie aux usages privés.
  • La séparation a créé des doublons tenaces. RFC 2068, en janvier 1997, demandait à HTTP de traiter x-gzip et x-compress comme les équivalents de gzip et compress. RFC 5064, en décembre 2007, normalisait Archived-At tout en décrivant et enregistrant son ancien nom X-Archived-At.
  • RFC 6648, en juin 2012, a déconseillé le préfixe pour les nouveaux paramètres textuels des protocoles applicatifs. La présence de X- ne devait plus servir de certificat de statut ou de sécurité; des registres accessibles devaient porter cette information.

Le casier réservé aux inventions privées

Un champ de message possède un nom et une valeur. Pour un programme qui reçoit le message, le nom indique quelle règle appliquer à la valeur. Si deux groupes attribuent des sens différents à un même nom, ils préparent un incident d'interopérabilité. Réserver une portion de l'alphabet aux expériences locales semblait donc un arrangement raisonnable : les utilisateurs pourraient inventer sans attendre la publication d'une norme, et les auteurs de normes disposeraient d'un espace intact.

C'est le partage qu'organisait RFC 822, publié en août 1982. Le texte distinguait les extensions susceptibles d'être publiées officiellement des champs définis par les utilisateurs. Il interdisait aux premières de commencer par X-. Les secondes bénéficiaient ainsi d'un ensemble de noms protégés. Une équipe pouvait ajouter une information à ses messages sans solliciter immédiatement l'autorité chargée des noms communs.

Mais le nom d'un champ est aussi un morceau du protocole que le logiciel lit littéralement. Un programme écrit pour X-Exemple ne se met pas à comprendre Exemple le jour où un groupe de travail approuve cette nouvelle graphie. La convention avait inscrit une appréciation sociale, « privé pour l'instant », dans l'identifiant technique. Pour changer l'appréciation, il fallait ensuite changer les programmes et les archives.

Ce coût reste caché tant que l'expérience n'a aucun public. Dès que des expéditeurs envoient le champ et que des lecteurs l'acceptent, le nom acquiert une clientèle. Une version officiellement baptisée peut alors ajouter un second nom sans faire disparaître le premier. Le tiroir expérimental devient une pièce du bâtiment.

En 1997, HTTP règle déjà la facture

RFC 2068, publié en janvier 1997, en donne une preuve sèche. Dans sa description des codages de contenu, le standard demandait, pour rester compatible avec les implémentations antérieures, de considérer x-gzip comme équivalent à gzip, et x-compress à compress. L'auteur du standard ne pouvait pas choisir le nom élégant et effacer l'autre. Les deux graphies étaient déjà des entrées que les applications devaient comprendre.

L'effet est concret. Un expéditeur peut désigner un codage sous l'un des deux noms. Un lecteur qui n'en reconnaît qu'un peut mal traiter la réponse. Un intermédiaire qui archive ou relaie le contenu doit savoir quel codage est annoncé. L'ancien signe d'expérimentation se transforme en règle de compatibilité inscrite dans le standard lui-même.

Le courrier a connu une transition apparentée. RFC 2822, en avril 2001, a remplacé RFC 822 et décrit des champs optionnels sans conserver l'ancienne séparation grammaticale entre extensions officielles et champs d'utilisateurs. La règle de classement pouvait disparaître du texte; les messages déjà écrits et les programmes qui les lisaient conservaient leurs noms.

Puis RFC 5064, en décembre 2007, a normalisé Archived-At, un champ qui donne l'adresse d'une copie archivée du message. Le document devait aussi parler de son précurseur X-Archived-At. Il autorisait la lecture de l'ancien champ, tout en déconseillant de le produire à nouveau. L'enregistrement officiel qualifiait l'ancien nom de périmé. Voilà une opération de promotion inscrite noir sur blanc : le nom propre entre dans la norme, le vieux nom entre dans la liste des choses qu'il faut encore savoir lire.

Les deux exemples ne permettent pas de calculer combien de logiciels ont envoyé chaque variante. Ils montrent des obligations différentes : HTTP traite deux noms précis comme équivalents pour deux codages; le standard du courrier accepte une ancienne entrée mais favorise une nouvelle sortie. Le dénombrement d'un déploiement exigerait des versions de logiciels datées ou des messages conservés. Le travail de compatibilité, lui, est attesté par les textes originaux.

La marque perd son pouvoir de classement

RFC 6648, publié comme bonne pratique actuelle de l'IETF en juin 2012, a tiré la conclusion. Un nom non normalisé finit parfois par circuler bien au-delà du laboratoire. Quand on lui donne un successeur normalisé, les lecteurs anciens ne connaissent que la graphie préfixée, tandis que les nouveaux peuvent n'apprendre que l'autre. Pour éviter la casse, les nouveaux lecteurs gardent souvent l'ancien nom indéfiniment. L'espace que l'on croyait réservé au provisoire fournit alors une norme de fait.

Le texte déconseille X- pour les nouveaux paramètres textuels des protocoles applicatifs. Il ne commande aucune purge des champs existants : leurs responsables décident de leur sort. Il ne proscrit pas l'expérimentation privée et ne réécrit pas automatiquement les règles propres à certains protocoles. Il retire un conseil de dénomination qui faisait payer la promotion par tous les participants.

Il interdit aussi une mauvaise habitude des lecteurs. Un programme ne doit pas déduire le statut officiel d'un champ de la seule présence ou absence de X-. Il ne doit pas non plus tenir un nom sans préfixe pour sûr et un nom préfixé pour dangereux sur cette seule base. Une orthographe n'est ni un certificat de normalisation ni un examen de sécurité.

À la place, RFC 6648 pousse les concepteurs à tenir des registres assez vastes, dotés de procédures simples, éventuellement avec des entrées provisoires et permanentes. Il faut pouvoir enregistrer un nom sans prétendre que ses deux premiers caractères déterminent son rang. Le registre peut publier l'état d'un champ et l'évolution de sa définition sans obliger le réseau entier à apprendre une deuxième identité.

Une dernière difficulté rend le raccourci encore plus risqué. Une version normalisée peut changer de comportement après examen technique ou de sécurité. Dans ce cas, supprimer X- à l'aveugle et traiter les deux formes comme équivalentes peut créer une erreur nouvelle. RFC 2068 fournit une équivalence précise pour x-gzip et gzip; ce n'est pas une règle générale de suppression des préfixes. Chaque migration doit connaître la signification réelle des deux formes.

Une expérience réussie laisse parfois deux noms

En 1982, le tiroir privé donnait une liberté utile. En 2012, l'IETF a reconnu que le succès d'une expérience avait déplacé l'autorité : les logiciels et les archives imposaient leur lecture de l'ancien nom, même après la publication d'un nouveau. Le règlement pouvait nommer et enregistrer; il ne pouvait pas retirer sans frais un identifiant déjà utilisé.

Les exemples officiels donnent la mesure de ce conflit. Le standard HTTP de 1997 conservait deux noms pour un codage. Celui du courrier de 2007 enregistrait l'ancien nom périmé à côté du successeur. Pour mesurer leur diffusion dans une période précise, il faudrait un inventaire daté d'implémentations ou de messages. Pour comprendre pourquoi le préfixe a été abandonné, les textes suffisent : l'étiquette « expérience » avait collé à des objets devenus ordinaires.

RFC 6648 n'a pas vidé l'ancien tiroir. Il a demandé aux prochains auteurs de ne plus en construire un autre. L'état d'un paramètre pouvait vivre dans un registre et changer sans que tous les lecteurs aient à retenir une seconde graphie pour la même tâche.