Résumé

  • RFC 3968 a réparé l’absence laissée par RFC 3261 en créant un registre IANA des paramètres de champs d’en-tête SIP et de leurs valeurs.
  • La ligne enregistrée établissait un nom dans un champ et renvoyait aux RFC qui lui donnaient sens ; elle ne prouvait ni implantation, ni compréhension par un terminal, ni résultat sécurisé.

Imaginez une fiche cartonnée dans un grand catalogue. Elle porte quatre indications : le champ d’en-tête, le nom du paramètre, la présence éventuelle d’une liste fermée de valeurs et les documents qui définissent le tout. Cette fiche permet de retrouver l’autorité et d’éviter qu’un autre auteur réemploie le même nom au même endroit. Elle ne contient pourtant pas le code d’un téléphone, la politique d’un proxy ou la trace d’une transaction.

C’est la bonne échelle pour lire RFC 3968. En décembre 2004, le texte partait d’une lacune précise. RFC 3261 permettait de créer de nouveaux paramètres et de nouvelles valeurs, mais n’avait pas prévu leur registre IANA. Deux extensions indépendantes pouvaient donc choisir le même mot pour des fonctions différentes. RFC 3968 a créé le point de coordination manquant.

Pour obtenir une entrée, il fallait une RFC expliquant complètement syntaxe, usage prévu et sémantique. L’intention annoncée était double : faciliter l’interopérabilité entre implémentations indépendantes et prévenir les collisions accidentelles. La publication donnait à chaque mot une origine vérifiable. Elle ne forçait aucun logiciel à le connaître.

La fiche était indexée par le champ

Le registre n’imposait pas une unicité universelle des chaînes. Un même nom pouvait figurer dans plusieurs champs d’en-tête. En revanche, deux paramètres du même champ devaient porter des noms différents. Le contexte faisait donc partie de l’identité.

Conserver seulement le mot q, tag ou algorithm dans un journal revient à arracher l’étiquette de son tiroir. La recherche peut retrouver une chaîne exacte tout en attribuant la mauvaise signification. Une preuve exploitable garde le couple champ-paramètre, les références et la date d’observation.

Une fois inscrits, paramètres et valeurs devenaient des mots réservés. Leur emploi devait rester conforme à la RFC citée, et une définition locale ne pouvait entrer en conflit avec eux. Les noms non enregistrés n’étaient toutefois pas interdits. Le document signalait leur risque : un futur texte pouvait attribuer publiquement le même nom à une autre fonction.

Un réseau fermé pouvait donc faire fonctionner son paramètre privé aujourd’hui. Cette réussite attestait un accord local, non un droit durable sur le nom. À l’inverse, une inscription publique établissait le droit documentaire sans attester que des terminaux anciens avaient reçu la mise à jour.

Les références portaient le sens

La colonne Predefined Values demandait une lecture attentive. Quand elle indiquait Yes, le registre ne déroulait pas nécessairement toutes les valeurs permises. RFC 3968 choisissait l’enregistrement par référence : la RFC initiale et les RFC ultérieures ajoutant des valeurs constituaient ensemble la source. Les ajouts apparaissaient entre doubles crochets.

La fiche était donc un index, pas un parseur complet. Copier le tableau sans ses liens supprimait la chaîne de provenance. Une copie ancienne pouvait ignorer une valeur ajoutée plus tard tout en ayant l’air officielle. L’implémenteur devait ouvrir chaque référence et y lire grammaire, intention, sémantique et considérations de sécurité.

La politique était IETF Consensus selon RFC 2434, avec publication d’une RFC sans obligation qu’elle appartienne à la voie des normes. Le cadre plus récent de RFC 8126 décrit l’enregistrement comme l’association d’une valeur à un usage dans un espace de noms. Cette définition borne bien l’autorité : le registre attribue ; il n’exécute pas.

Un registre n’était pas un dialogue de capacités

SIP disposait déjà de mécanismes transactionnels. RFC 3261 employait Supported, Require, Proxy-Require, Unsupported et la réponse 420 pour annoncer, exiger ou refuser certaines extensions. Ces champs étaient produits par des participants à une transaction donnée. Ils apportaient un autre type de preuve.

L’existence d’une entrée IANA ne provoquait aucune de ces réponses. Elle ne disait pas que le terminal avait compilé la fonction, accepté sa politique ou terminé l’appel. Même une annonce de prise en charge restait distincte de l’action : reconnaître une extension n’oblige pas à accepter son emploi dans toutes les circonstances.

RFC 3261 demandait par ailleurs d’ignorer un champ inconnu et de continuer, lorsqu’il n’était pas indispensable au traitement. Le passage réussi d’un message devenait donc ambigu. Il pouvait signifier compréhension ou simple tolérance. Pour savoir ce qui s’est produit, il fallait observer le traitement, pas seulement l’arrivée du paquet.

Les préfixes n’ont pas retenu le déploiement

RFC 3427 avait voulu encadrer les extensions SIP parce qu’elles pouvaient augmenter fortement la complexité ou détériorer la sécurité. Son mécanisme de champs P- cherchait à signaler un usage préliminaire, privé ou propriétaire et à le limiter.

Le nom n’a pas tenu la frontière. RFC 5727 a constaté que certains champs P- s’étaient répandus hors de leur environnement prévu et qu’une base installée rendait leur renommage invraisemblable. Il a abandonné ce processus spécial, tout en maintenant RFC 3968 comme référence pour les paramètres SIP.

RFC 6648 a tiré une règle générale de cette expérience : la présence ou l’absence d’un préfixe comme X- ne permet de conclure ni au statut normatif ni à la sécurité. Une propriété de gouvernance doit rester dans les métadonnées et les documents, pas être devinée à partir de l’orthographe.

Le tableau initial illustrait déjà la diversité cachée derrière une forme uniforme. RFC 3310 apportait des éléments d’authentification Digest, RFC 3265 des événements, RFC 3455 des champs de réseau privé et RFC 3329 la négociation d’accords de sécurité. Le catalogue rapprochait les entrées ; il n’unifiait ni leur mécanisme ni leur risque.

Le registre IANA des paramètres SIP est aujourd’hui une collection vivante de sous-registres. La fiche RFC Editor, les errata et le Datatracker IETF établissent la trajectoire documentaire. Aucun ne mesure la part des terminaux compatibles ou les résultats de sécurité.

L’héritage de RFC 3968 tient à cette séparation. Le catalogue rendait le nom attribuable ; la RFC en fixait le sens ; l’implémentation et la transaction devaient encore produire leurs propres preuves.

Sources