Résumé

  • Content-Duration: 33 permettait à un client de courrier d’afficher une durée de 33 secondes annoncée par l’expéditeur, sans ouvrir le média. L’en-tête rendait l’information facile d’accès, mais ne constituait pas une mesure indépendante.
  • La RFC 2424 précisait qu’il faut ouvrir et lire le contenu pour en connaître la durée exacte. L’usage à la réception relève de chaque implémentation ; le champ ne permet pas non plus de déduire la taille exacte des données.

Le message n’avait pas encore été écouté. Pourtant, le nombre était déjà là : Content-Duration: 33. Un client sur petit écran pouvait indiquer la durée apparente d’un extrait vocal avant que l’utilisateur n’ouvre la pièce jointe. Il n’avait pas besoin de décoder le son pour proposer ce repère pratique. L’avantage est réel. La distance entre le nombre de l’en-tête et l’observation du média l’est aussi.

C’est ce problème ramassé qu’a traité la RFC 2424, publiée sur la voie des normes en septembre 1998. Elle définit un champ d’en-tête MIME pour les contenus qui varient dans le temps, généralement audio ou vidéo. La syntaxe est volontairement brève : Content-Duration: suivi d’un à dix chiffres décimaux. La valeur correspond à des secondes, sans indication d’unité. Dans l’exemple de la RFC, 33 signifie 33 secondes.

Pourquoi placer cette information dans un en-tête séparé ? Certains formats inscrivent déjà la durée dans leurs propres métadonnées ; pour d’autres, on peut la calculer à partir du nombre d’octets. Dans les deux cas, il faut examiner le contenu ou comprendre son encodage. L’en-tête MIME propose une voie moins coûteuse : rendre la durée lisible en traitant la structure extérieure du message, sans ouvrir le média. Dans un environnement de messagerie vocale contraint, un bureau MIME très simple — voire un bureau qui ne connaît pas MIME — pouvait ainsi montrer la durée avant de manipuler l’audio.

Cette simplicité rend aussi l’autorité du champ visible. La RFC 2424 parle d’une durée déterminée par l’expéditeur. Elle recommande une valeur exacte, puis précise aussitôt ce qui permettrait de la connaître : ouvrir et lire le contenu. Si l’exactitude est nécessaire, c’est cette seconde méthode qu’il faut employer. Le champ n’est donc pas un service de mesure. C’est une déclaration transmissible, fournie par l’expéditeur pour faciliter l’accès ; la vérification exige toujours d’observer le média.

La norme n’impose pas une interface unique. Elle cite plusieurs endroits où afficher la durée — l’en-tête de la boîte de réception ou la pièce jointe audio ouverte, par exemple — avant de laisser l’usage effectif à l’implémentation locale. Le champ et sa signification sont standardisés ; l’affichage n’est pas obligatoire dans chaque client, et sa présentation n’est pas uniforme. Rien ne prouve non plus qu’un client donné ait correctement décodé le média. Un indice normalisé peut circuler plus largement qu’une décision d’interface, sans uniformiser celle-ci.

Voice Profile for Internet Mail donne au champ un contexte concret. Avec le sous-type audio/32KADPCM, la durée pouvait aider un bureau élémentaire à montrer la longueur d’un message vocal avant l’ouverture de l’audio. Cela ne révèle pas qui a parlé, quand l’enregistrement a été fait, si un utilisateur a ouvert le message ni si quelqu’un l’a écouté jusqu’au bout. Ce sont d’autres faits, qu’il faut transporter ou observer ailleurs, s’ils le sont.

Les documents ultérieurs montrent à la fois une continuité et un élargissement du cadre. La RFC 3803, publiée en 2004 pour remplacer la RFC 2424, précise que les changements sont uniquement éditoriaux et conventionnels. La syntaxe et la distinction entre valeur fournie par l’expéditeur et exactitude établie par la lecture restent intactes. En 2005, la RFC 4021 inscrit Content-Duration dans le registre des champs MIME de la voie des normes, comme durée en secondes du contenu d’une partie du corps. Le registre facilite la recherche du champ ; il ne transforme pas la déclaration en mesure vérifiée.

Un document informatif sur le comportement des clients, la RFC 4024, explicite davantage le problème d’affichage. Le texte se mesure en kilooctets, la voix en secondes et le fax en pages. Le document privilégie Content-Duration pour la partie audio principale d’un message vocal, tout en laissant un client agréger plusieurs parties audio. Dans un message mixte, la « taille » affichée dépend du contenu principal. Il s’agit de recommandations d’interface, pas d’une garantie que la durée a été mesurée ou que l’audio a été lu.

La RFC 2424 remarque également que déplacer une propriété hors du média modifie son exposition. Dans certains environnements, indiquer explicitement une durée dans l’en-tête peut poser un problème de sécurité. Et il ne faut pas se fier au champ pour connaître la taille exacte des données : seul l’examen des données permet de l’établir. Les secondes et les octets répondent à des questions différentes. La durée annoncée par l’expéditeur ne remplace pas le comptage des octets ; inversement, ce comptage ne prouve pas combien de temps un décodeur donné fera jouer l’extrait.

La leçon historique est mesurée, mais durable : une norme peut rendre une déclaration facile à transporter et à présenter sans rendre bon marché la vérification de la propriété décrite. La RFC 2424 nomme les deux versants : une durée fournie par l’expéditeur, facile d’accès, et l’ouverture avec lecture, nécessaire pour connaître l’exactitude. Un client peut montrer la première avant que la seconde n’ait lieu. Ni le champ ni son affichage ne prouvent que la durée correspond à la lecture, que le message est arrivé intact ou que quelqu’un l’a entendu. L’en-tête annonce 33 secondes ; tant que le contenu n’est pas examiné, la preuve s’arrête là.