Résumé

  • RFC 3969 réservait tout nom de paramètre d’URI dans SIP et SIPS afin d’empêcher qu’une même graphie acquière deux sens incompatibles; seule la RFC de définition disait où le paramètre s’appliquait.
  • Le texte annonçait « Specification Required » tout en exigeant une RFC de la voie des normes. RFC 5727 a ensuite qualifié ce décalage de contradiction et confirmé la règle voulue : Standards Action.

Une case occupée deux fois paraît d’abord signaler deux fonctions. RFC 3969 organisait exactement l’inverse : une seule identité documentaire occupait les espaces SIP et SIPS pour interdire deux fonctions homonymes. Le paramètre pouvait néanmoins être inapplicable à l’un des schémas. L’inscription empêchait la réutilisation; elle n’activait rien.

Ce choix répondait à une lacune de RFC 3261. Le protocole autorisait de nouveaux paramètres et de nouvelles valeurs dans les URI SIP et SIPS, mais aucun registre IANA ne coordonnait leurs noms. Deux concepteurs indépendants pouvaient donc choisir le même mot pour des comportements différents, puis produire des messages parfaitement lisibles et sémantiquement contradictoires.

RFC 3969, publiée en décembre 2004 comme BCP 99, installa le point d’autorité manquant. Sa première table comptait comp, lr, maddr, method, transport, ttl et user. comp renvoyait à RFC 3486; les autres entrées initiales à RFC 3261. Chaque ligne indiquait aussi si les valeurs étaient prédéfinies.

Réserver deux emplacements pour préserver un sens

Le document explique son arbitrage sans détour. Un nom est enregistré pour SIP comme pour SIPS afin d’éviter qu’il désigne une chose dans l’un et une autre dans l’autre. La portée d’emploi reste dans les spécifications citées. Ainsi, la paire de réservations prouve qu’un mot est indisponible pour une seconde attribution. Elle ne prouve pas que les deux schémas acceptent le mécanisme.

Cette distinction compte pour l’analyse d’incident. Un export qui conserve seulement le nom et deux coches de registre transforme une décision de gouvernance en prétendue matrice de capacités. Il faut garder le schéma observé, la date, toutes les références et la version du logiciel. RFC 5630 a ensuite précisé le maniement de SIPS; RFC 3263 traite la localisation des serveurs et le transport. Ces obligations opérationnelles ne tiennent pas dans une réservation de nom.

Le registre qualifiait noms et valeurs enregistrés de mots réservés. Une implémentation locale pouvait employer un nom non enregistré, mais sans garantie contre une attribution future. Il n’existait pas d’arbre d’extensions fournisseurs. RFC 3427 avait souligné que les extensions SIP pouvaient accroître fortement la complexité ou nuire à la sécurité; la voie publique passait donc par une RFC détaillant syntaxe, usage, sémantique et sécurité.

Pour une entrée à valeurs prédéfinies, la table servait d’index. Elle renvoyait aux textes au lieu de reproduire toutes les valeurs. Le registre vivant des paramètres SIP de l’IANA cite aujourd’hui RFC 3261 et RFC 7118 pour transport. Une copie ancienne du tableau peut être exacte historiquement et incomplète pour un parseur actuel.

La règle d’admission a dû être corrigée

Une seconde frontière traverse le document lui-même. Selon le vocabulaire de RFC 2434, la section 4.2 déclarait la politique « Specification Required ». La phrase suivante exigeait pourtant une RFC de la voie des normes. Ces deux filtres n’accordent pas la même autorité ni le même parcours de révision.

RFC 5727 a conservé la trace de l’erreur au lieu de la faire disparaître. Sa section 7.1 affirme que la contradiction venait d’une mauvaise compréhension des catégories et que l’intention était Standards Action. La page IANA actuelle affiche cette politique. RFC 8126, successeur du cadre de politique, aide à lire ces étiquettes comme des règles de décision, non comme des ornements éditoriaux.

L’état courant ne remplace donc pas l’historique. La notice RFC Editor, la recherche d’errata et le Datatracker de l’IETF répondent à des questions différentes : statut, corrections signalées et trajectoire documentaire. RFC 3986 fournit le cadre général des URI; RFC 6648 rappelle plus tard qu’une graphie ou un préfixe ne suffit pas à déduire le statut normatif.

Pour lire un paramètre observé, il faut partir du schéma et du nom exacts, dater la ligne IANA, ouvrir chaque référence, vérifier l’applicabilité et les considérations de sécurité, puis chercher les preuves propres à l’implémentation et à la transaction. Une session réussie ne démontre pas que le paramètre l’a causée; une réservation publique ne démontre pas qu’un terminal le comprend.

RFC 3969 avait donc payé un petit coût de registre pour éviter une dette de sens. Deux emplacements réservés maintenaient une seule définition possible. La prudence consiste à préserver cette unité sans inventer une symétrie de comportement.

Sources