Résumé

  • La RFC 3362 a enregistré image/t38 comme descripteur de média SDP ; la définition de l’encodage restait dans la recommandation T.38 de l’UIT-T.
  • Reconnaître cette étiquette ne prouvait ni l’acceptation de l’offre, ni un transport compatible, ni le chiffrement, ni l’arrivée complète des pages.

Dans un tiroir de registre, une chaîne de caractères peut paraître minuscule. Dans un protocole, elle évite pourtant à deux logiciels de donner des noms différents à la même chose. C’était le mérite de image/t38 : offrir un point de rendez-vous entre la télécopie définie par l’UIT-T et les mécanismes de session élaborés à l’IETF.

La RFC 3362, publiée en 2002, n’a pas inventé le flux T.38. Elle renvoie explicitement à la recommandation de l’UIT-T qui décrit le transfert en temps réel entre terminaux ou passerelles de télécopie du groupe 3 sur des réseaux IP. Elle précise que le service peut employer TCP ou UDP selon son environnement. Son apport propre est plus étroit : enregistrer un sous-type de média utilisable dans une description SDP.

Cette architecture partagée compte dans l’histoire de l’Internet. Il n’était pas nécessaire qu’une seule organisation possède le terminal, l’encodage, la signalisation et le registre. Une étiquette stable pouvait relier ces domaines. L’IANA conservait la référence ; les implémentations choisissaient de l’adopter ; les opérateurs restaient responsables du chemin qu’ils faisaient réellement fonctionner.

Le formulaire d’enregistrement était volontairement pauvre. Aucun paramètre obligatoire. Aucun paramètre facultatif. Données binaires. Usage prévu : commun. Cette simplicité empêchait l’étiquette de devenir un profil complet caché. Elle disait de quelle famille de flux il s’agissait, non quelles options précises rendraient deux passerelles compatibles.

La RFC traçait aussi une frontière de contexte. image/t38 devait signaler un flux T.38 dans SDP. L’usage dans le courrier électronique n’était pas prévu. Le texte d’interopérabilité allait plus loin : cet usage n’étant pas défini, rien ne garantissait qu’un objet transporté par courrier fonctionnerait comme un flux T.38. Le mot image ne suffisait pas à transformer une session en pièce jointe.

La sécurité restait elle aussi hors de l’étiquette. La déclaration indiquait que le contenu représentait un train binaire de télécopie susceptible d’être chiffré ou non. La présence du sous-type ne permettait donc de conclure ni à la confidentialité du média, ni à la protection de la signalisation, ni à l’absence d’une conversion en clair dans une passerelle.

SDP n’effaçait pas cette limite. Les RFC 2327, 4566 puis 8866 définissent un format de description de session, sans intégrer elles-mêmes un protocole de transport. Une description peut annoncer un média, une adresse, un port et un format. Elle ne fait pas voyager les paquets.

Il faut ensuite une négociation. La RFC 3264 explique que l’offre présente la vue souhaitée par un participant et que la réponse présente celle de l’autre. La vue complète exige les deux. Une réponse peut refuser un flux en mettant son port à zéro. Une capture où image/t38 apparaît dans l’offre prouve donc une proposition, pas un accord.

Même l’accord ne prouve pas la télécopie. Les deux extrémités doivent partager un comportement T.38 compatible. Le transport choisi doit traverser le réseau. Les délais, pertes et réordonnancements doivent rester tolérables. Les passerelles doivent convertir correctement le rythme du monde des paquets vers celui des terminaux. Une session peut être ouverte alors qu’une page reste tronquée ou illisible.

Il faut donc tenir un registre de preuves, pas seulement un registre de noms. L’entrée IANA prouve que le jeton est enregistré et renvoie à la RFC 3362. Un inventaire logiciel peut prouver sa reconnaissance. L’offre prouve une proposition. La réponse prouve l’acceptation ou le refus. Les traces réseau prouvent le transport observé. Les journaux de passerelle documentent la conversion. Les compteurs et accusés des terminaux documentent les pages.

Ces preuves ne sont pas fongibles. Une entrée durable n’est pas un recensement des déploiements. Une syntaxe comprise n’est pas un média accepté. Une session acceptée n’est pas une page complète. Une page complète n’est pas encore la preuve que son destinataire l’a reçue et utilisée.

L’évolution des règles d’enregistrement confirme cette lecture. La RFC 2048 encadrait la procédure à l’époque. Les RFC 4288 puis 6838 ont révisé le cadre général. Leur but est de rendre les noms examinables, stables et moins ambigus. La procédure améliore la coordination ; elle ne lance aucun logiciel chez un opérateur.

Il en va de même du vocabulaire normatif des RFC 2119 et 8174. Les mots en capitales structurent les obligations d’une spécification. Ils ne constituent pas un rapport d’audit sur une passerelle particulière. Entre « doit » dans le texte et « a fait » dans le réseau, il manque toujours une observation.

L’entrée IANA actuelle conserve utilement image/t38 et sa référence. Cette continuité est un fait de garde documentaire. Elle ne mesure ni le nombre de passerelles actives, ni leur choix entre TCP et UDP, ni leur chiffrement, ni leur taux de pages abouties.

Deux textes de Lu Heng servent ici de grille d’analyse déclarée. « Minimum Initial Specification » invite à limiter la couche commune aux règles nécessaires et vérifiables, puis à laisser l’adoption aux participants qui exécutent le code. La RFC 3362 montre l’utilité d’un raccord minimal. « On Reality Layers » interdit de confondre l’inscription symbolique avec l’état du système. Ici, l’inscription, l’offre, la réponse et la feuille imprimée appartiennent à quatre colonnes différentes.

La modestie de la RFC n’est donc pas une faiblesse. Elle est la raison de sa clarté. image/t38 signifiait : cette description parle d’un flux de télécopie T.38. Pour affirmer « compatible », « accepté », « chiffré » ou « livré », il fallait changer de preuve.

Sources