Résumé

  • RFC 3939 a créé les en-têtes Caller-ID et Caller-Name afin de conserver dans un message vocal ce que le réseau téléphonique avait présenté à l’appelé.
  • Il n’en faisait pas une identité authentifiée : troncature internationale, poste interne transféré et décodage du nom pouvaient tous produire une information plausible mais fausse ou inutilisable.

Ne pas déguiser le téléphone en adresse électronique

Lorsqu’un appelant laissait un message sans disposer d’une adresse RFC 2822 connue, le système devait tout de même mémoriser ce qu’affichait le téléphone. Les solutions antérieures forçaient le champ From : mettre les chiffres dans le nom, fabriquer une adresse autour du numéro, ou déclarer l’origine inconnue. RFC 3801 prévoyait déjà non-mail-user pour l’auteur d’un message de répondeur auquel on ne pouvait répondre par e-mail.

RFC 3939, publié en décembre 2004, choisit de ne pas confondre les provenances. Caller-ID reçut le numéro fourni par le réseau téléphonique ; Caller-Name, le nom présenté. Le champ de courrier et l’observation téléphonique pouvaient ainsi coexister sans prétendre désigner la même autorité.

Cette modestie est centrale. Un numéro visible n’attestait ni le propriétaire de la ligne, ni la personne qui parlait, ni son droit d’appeler. Le nouveau champ rendait l’information transportable, pas authentique.

Trois sémantiques, dont une absence de sémantique

Le numéro devait contenir uniquement des chiffres. Un poste interne pouvait suffire pour un appel au sein de la même entreprise ; un appel international devait conserver les composantes E.164, dans la limite de quinze chiffres et sans signe +. Un paramètre facultatif NumberingPlan indiquait unknown, local ou e164.

L’absence du paramètre signifiait unknown. local n’avait de sens que dans le domaine du système de messagerie qui avait stocké le message. Ce choix empêchait une inférence commode mais dangereuse : des chiffres propres ne devenaient pas automatiquement un numéro mondial.

Le contraste avec les textes voisins éclaire la frontière. RFC 2806 exigeait un contexte pour un numéro téléphonique local dans une URL, puisque les mêmes chiffres changent de sens selon la zone. RFC 3191 réservait le préfixe + à une adresse GSTN globale conforme à E.164 dans le courrier. RFC 3939, lui, enregistrait la présentation reçue et disait explicitement ne pas définir une adresse téléphonique composable.

Le transfert révélait ce que le domaine cachait

Dans un autocommutateur d’entreprise, quatre chiffres peuvent être parfaitement suffisants. Une fois le message vocal transféré vers l’extérieur, ils ne mènent plus à rien. Ils révèlent pourtant une partie du plan interne. La confidentialité et l’utilité se détériorent donc au même passage de frontière.

Le cas international était plus trompeur. RFC 3939 signalait que certains systèmes réduisaient les numéros à dix chiffres. Son exemple montrait qu’un numéro irlandais privé de ses premiers chiffres pouvait ressembler à un numéro nord-américain. Le rappel n’échouait pas nécessairement : il pouvait réussir auprès de la mauvaise personne. Une validation purement syntaxique aurait accepté l’erreur.

Le nom de l’appelant connaissait une autre forme de perte. Les réseaux téléphoniques pouvaient employer plusieurs jeux de caractères. Le texte retenait ASCII et autorisait l’encodage RFC 2047 pour un nom natif. Un récepteur dépourvu de la même option pouvait afficher un autre nom ; un fournisseur pouvait aussi limiter la présentation à quinze caractères.

Quant aux numéros privés, la règle était de conserver ce que l’appelé aurait vu—par exemple Private Name—et non les détails complets échangés entre opérateurs. Mais le courrier créait une nouvelle durée de vie : le numéro pouvait rester dans les en-têtes et suivre les transferts. L’utilisateur pouvait même ignorer sa présence si le client ne l’affichait pas.

La date n’échappait pas à cette question de provenance. Le système pouvait employer l’heure transmise par le téléphone ou son heure locale dans le champ Date. Sans trace du choix, le même champ ne prouvait pas exactement le même événement.

RFC 3939 n’a donc pas échoué à fabriquer une identité forte ; ce n’était pas sa fonction. Il a offert un contenant précis à une observation fragile et, fait plus rare, a documenté les endroits où sa signification pouvait se défaire.