Définition de l'en-tête MIME Content-Duration

Statut de ce mémoire

Le présent document spécifie un protocole Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et des suggestions pour son amélioration. Prière de se reporter à l’édition actuelle du STD 1 "Normes des protocoles officiels de l’Internet" pour connaître l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de copyright

Copyright (C) The Internet Society (2004).

Résumé

Le présent document décrit l'en-tête MIME Content-Duration qui est destiné à être utilisé avec tout contenu de support qui varie avec le temps (normalement audio/* ou video/*).

1. Introduction

Le présent document décrit l'en-tête MIME Content-Duration qui est destiné à être utilisé avec tout contenu de support (normalement audio/* ou video/*) qui varie avec le temps. La durée est représentée en secondes sans aucune indication d'unité. Le présent document rend obsolète la RFC 2424.

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

2. Champ d'en-tête Content-Duration

Les contenus de supports qui varient avec le temps, par exemple, un message vocal parlé ou une séquence vidéo, ont une durée inhérente. De nombreux codages audio et vidéo peuvent inclure leur durée comme informations d'en-tête ou peuvent permettre un calcul précis fondé sur la longueur en octet des données. Cependant, il peut être utile de présenter la durée du contenu sous forme d'un en-tête MIME pour permettre une détermination simple sans avoir à traiter le contenu réel.

2.1 Syntaxe

La valeur du champ Content-Duration est un seul nombre qui spécifie la durée du contenu en secondes. Formellement :

durée : = "Content-Duration" ":" 1*10CHIFFRE

Noter qu'en pratique (bien que très improbable dans un support MIME) la limite supérieure de la valeur numérique de la durée est (2^^31 -1) ou 2 147 483 647.

2.2 Sémantique

Ce champ représente la durée du contenu du support associé variant avec le temps. La durée est notée en secondes sans étiquette d'unité. La valeur de temps devrait être exacte, cependant la valeur exacte de la durée ne peut pas être connue sans ouvrir le contenu et l'exécuter. Si une valeur exacte doit être connue, c'est la première méthode qui devrait être utilisée. Ce mécanisme permet simplement de placer une valeur de durée déterminée par l'envoyeur dans l'en-tête pour un accès facile.

Bien qu'il y ait plusieurs façons de présenter cette durée au receveur (par exemple, avec les en-têtes de boîte de réception, lorsque le message audio s'ouvre) l'utilisation réelle de ce champ à réception est une affaire de mise en œuvre locale.

2.3 Exemple

Dans cet exemple la durée du contenu représente 33 secondes :

Content-Duration: 33

3. Utilisation dans VPIM

Le champ d'en-tête Content-Duration pour le sous type audio/32KADPCM est un composant utile de la spécification VPIM [RFC2421]. Tous les messages VPIM DOIVENT contenir ce sous type pour porter le contenu audio d'un message vocal. Il peut être utile dans certaines instances (par exemple, pour voir sur une simple tablette MIME ou non MIME) pour avoir la durée du message vocal disponible sans avoir à ouvrir le contenu audio.

4. Considérations sur la sécurité

Cette définition introduit l'option d'une identification explicite de la durée d'un contenu audio/* ou video/* en dehors des données binaires qui forment le contenu. Dans certains environnements (bien que vraisemblablement pas la majorité) l'identification de la durée réelle dans un champ d'en-tête puisse poser un problème de sécurité et par suite ne devrait pas être notée. La fiabilité de la durée indiquée dans ce champ d'en-tête ne peut pas être totale pour déterminer la taille exacte des données. La longueur exacte des données doit être déterminée par l'examen des données elles-mêmes.

5. Références

5.1. Références normatives

[RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.

[RFC2646] R. Gellens, éd., "Paramètre de format Text/Plain", août 1999. (Obsolète, voir RFC3676) (P.S.)

[RFC3801] G. Vaudreuil, G. Parsons, "Profil vocal pour la messagerie Internet - version 2 (VPIMv2)", juin 2004. (D.S.)

5.2. Références pour information

[RFC2421] G. Vaudreuil, G. Parsons, "Profil vocal pour la messagerie Internet - version 2", septembre 1998. (Obsolète, voir RFC3801) (P.S.)

[RFC2424] G. Vaudreuil, G. Parsons, "Définition de l'en-tête MIME Durée de contenu", septembre 1998. (Obsolète, voir RFC3803) (P.S.)

6. Changements par rapport à la RFC 2424

Seuls des changements rédactionnels et de présentation par rapport à la RFC 2424 ont été apportés à ce document.

7. Adresse des auteurs

8. Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2004).

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations contenues sont fournis sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci-encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Propriété intellectuelle

L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourraient être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP 78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur le répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr .

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf- ipr@ietf.org .

Remerciement

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.