Résumé

  • RFC 3966 comparait les URI tel au-delà de leur texte brut : casse, séparateurs visuels et ordre reçu des paramètres pouvaient différer, tandis que forme locale ou globale, contexte et noms de paramètres restaient déterminants.
  • L’égalité décrivait une ressource numérotée. Elle ne certifiait ni personne, ni appareil physique, ni attribution actuelle, ni route, ni consentement, ni résultat de communication.

Un numéro imprimé peut changer d’allure sans changer de fonction. On le groupe, on l’entoure de parenthèses, on ajoute des tirets. Pour un lecteur, la continuité est évidente ; pour un registre qui compare des octets, elle ne l’est pas. Publié en décembre 2004, RFC 3966 a donné au schéma tel une relation de comparaison propre.

Le texte parlait d’une ressource identifiée par un numéro de téléphone. Il ne décrivait pas les gestes nécessaires pour l’atteindre depuis un terminal particulier et ne désignait pas un appareil physique unique. La composition d’un préfixe de sortie, le choix du mode de signalisation ou l’envoi de chiffres après connexion relevaient d’un plan d’appel local.

La réécriture de RFC 2806 rendait cette frontière plus nette. RFC 3966 supprimait du schéma les sélections de transporteur, pauses, chaînes postérieures à la connexion et formes fax ou modem. RFC 3601 conserve l’histoire voisine des chaînes qui commandent des actions. Ici, le sujet est un identifiant et son égalité.

Comparer exigeait d’oublier avec précision

Deux URI globaux, ou deux URI locaux, pouvaient être équivalents sans être identiques caractère par caractère. Les séparateurs , ., ( et ) disparaissaient lors de la comparaison des chiffres. La casse n’avait pas d’effet. Les paramètres étaient rapprochés par leur nom, quel que soit leur ordre d’arrivée.

Mais un URI global et un URI local n’étaient pas égaux selon l’algorithme, même si un opérateur savait les faire aboutir au même endroit. Un paramètre présent d’un seul côté rendait les deux URI différents. Pour un numéro local, phone-context faisait partie de l’identifiant. L’extension et les paramètres obligatoires comptaient également.

La normalisation devait donc retirer le décor sans retirer le mandat. Une comparaison brute créait des doublons artificiels ; une comparaison qui effaçait tout créait des fusions fausses.

La grammaire imposait aussi un ordre canonique d’écriture : isub ou ext, puis phone-context, puis les autres paramètres dans l’ordre lexical. Ce choix facilitait les comparaisons de caractères dans les systèmes voisins. Pourtant, la règle sémantique continuait de comparer par nom, indépendamment de l’ordre reçu. Sérialiser proprement et décider l’égalité n’étaient pas la même opération.

RFC 3986 a ensuite consolidé le cadre générique des URI. RFC 3261 intégrait la syntaxe téléphonique dans SIP et montrait pourquoi certains environnements sensibles au texte exigeaient une forme stable. Une implémentation responsable garde donc les octets d’origine, la structure analysée et la forme canonique, avec la trace de chaque transformation.

Le contexte bornait un nom local, pas un itinéraire

La forme globale était recommandée, mais certains numéros privés, d’urgence ou de service ne s’y prêtaient pas. Un numéro local devait porter phone-context, soit sous forme de domaine contrôlé, soit sous forme de premiers chiffres d’un numéro global valide.

Le couple contexte-numéro devait être unique à l’échelle mondiale. Toutefois, le contexte n’était pas un préfixe à coller devant le numéro. Le code 911 dans le contexte +1 ne devenait pas +1-911. Un domaine de contexte n’avait même pas besoin de résoudre vers une machine ; il devait être sous le contrôle administratif du gestionnaire de cet espace local.

Deux URI locaux peuvent donc être égaux sans que le contexte fournisse une route DNS, une passerelle ou une attribution encore valide. RFC 3966 rappelait aussi qu’un numéro global pouvait être périmé ou impossible à joindre depuis un endroit donné.

Pour identifier, un destinataire pouvait traiter le contexte comme une partie opaque du nom. Pour appeler, il devait le comprendre et être capable d’agir dans cet environnement. Une même donnée alimentait deux décisions dont les exigences de preuve différaient.

Même ensemble de paramètres, capacité encore inconnue

ext identifiait un poste derrière un PBX non ISDN ; isub portait une sous-adresse ISDN. Ils étaient mutuellement exclusifs. RFC 4715 a précisé plus tard l’encodage des sous-adresses. RFC 4694, RFC 4759 et RFC 4904 ont ajouté les histoires de portabilité, d’interrogation ENUM et de groupes de trunks.

Les futurs paramètres obligatoires devaient commencer par m-. Un logiciel qui ne comprenait pas un tel paramètre ne devait pas utiliser l’URI. Les paramètres facultatifs pouvaient être ignorés. Ainsi, deux URI pouvaient partager exactement le même paramètre obligatoire inconnu et rester inutilisables pour ce récepteur. L’égalité ne créait pas la capacité.

RFC 5341 a ensuite organisé l’enregistrement des paramètres, et le registre IANA tel URI Parameters tient le vocabulaire coordonné. Une inscription permet de trouver la spécification ; elle n’atteste ni la fraîcheur d’une valeur, ni la prise en charge d’un équipement, ni l’autorité de l’émetteur.

Une ressource n’était pas une personne

Le même URI pouvait être traduit en plusieurs autres URI pendant l’établissement. La signalisation pouvait négocier la voix, les données ou le fax. Un point de terminaison pouvait avoir plusieurs identifiants, et un numéro ne choisissait pas nécessairement un seul combiné ou un seul humain.

RFC 6116 a plus tard décrit la résolution ENUM d’un numéro E.164 vers des services et URI. Cette résolution a sa propre provenance et son propre instant. Elle ne transforme pas rétroactivement l’égalité RFC 3966 en preuve sur celui qui répondra.

La sécurité fournissait une dernière limite. Un client Web ne devait pas lancer automatiquement un appel à partir d’un lien tel sans consentement explicite. L’appel pouvait coûter, occuper la ligne ou dévoiler le numéro appelant. Le texte visible d’un lien pouvait même afficher une autre cible. Deux cibles égales ne prouvaient donc ni honnêteté de l’affichage ni autorisation humaine.

La notice RFC Editor, la recherche d’errata et la fiche Datatracker établissent le statut documentaire et les corrections signalées. Elles ne mesurent aucune adoption ni aucun résultat d’appel.

Le journal d’audit doit conserver le texte d’origine, la forme locale ou globale, les chiffres avant et après retrait des séparateurs, la casse, l’ensemble et l’ordre reçu des paramètres, la sérialisation canonique, le type de contexte, ext ou isub, la reconnaissance des paramètres obligatoires, la version du parseur et le résultat de comparaison. Attribution, plan d’appel, cible de signalisation, route, consentement, réponse et service viennent ensuite, chacun avec son reçu.

RFC 3966 a appris aux systèmes à dire « même ressource » sans exiger « mêmes caractères ». Sa discipline durable consiste à ne pas étendre ce « même » au monde que l’algorithme n’a jamais observé.

Sources