Groupe de travail Réseau	S. Casner, Packet Design	
Request for Comments : 4855	février 2007	
RFC rendue obsolète  : 3555		
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle	

Enregistrement de type de support des formats de charge utile RTP

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Protocoles officiels de l’Internet" (STD 1) pour voir 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 (2006).

Résumé
Le présent document spécifie la procédure pour enregistrer les formats de charge utile RTP comme audio, vidéo, ou autres noms de sous type de support. Ceci est utile dans une description de format fondée sur le texte ou dans un protocole de contrôle pour identifier le type d'une transmission RTP.
Table des matières
1. Introduction	1
1.1 Terminologie	1
2. Procédure pour enregistrer les types MIME pour les types de charge utile RTP	1
2.1 Exemple d'enregistrement de type de support	2
2.2. Restrictions au partage d'un nom de sous type	3
3. Transposition en paramètres SDP	3
4. Changements par rapport à la RFC 3555	4
5. Considérations sur la sécurité	4
6.  Considérations relatives à l'IANA	6
7. Références	6
7.1 Références normatives	6
7.2 Références pour information	6
Adresse de l'auteur	6
Déclaration complète de droits de reproduction	6

 	1.	Introduction

La [RFC4288] définit la spécification de type de support et les procédures d'enregistrement qui utilisent l'Autorité d'allocation des numéros de l'Internet (IANA) comme registraire central. Ce document couvre les exigences générales indépendamment des environnements d'application et modes de transport particuliers. Le présent document définit les exigences spécifiques pour l'enregistrement des types de supports à utiliser avec le protocole de transport en temps réel (RTP, Real-time Transport Protocol), [RFC3550], pour identifier les formats de charge utile RTP.

 	1.1	Terminologie
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] et indiquent les niveaux d’exigence pour les mises en œuvre conformes à la présente spécification.

 	2.	Procédure pour enregistrer les types MIME pour les types de charge utile RTP

L'enregistrement d'un type de charge utile RTP comme type de support suit les mêmes procédures que décrit dans la [RFC4288] et utilise le gabarit d'enregistrement montré à la Section 10 de cette RFC. Des informations supplémentaires sont exigées de ce gabarit pour spécifier dans les paragraphes qui suivent comment un format de charge utile particulier est transporté sur RTP:

Paramètres exigés  : si le format de charge utile n'a pas un débit fixe d'horloge d'horodatage RTP, alors un paramètre "rate" est nécessaire pour spécifier le débit d'horloge de l'horodatage RTP. Un format de charge utile particulier peut avoir des paramètres supplémentaires exigés.

Paramètres facultatifs  : La plupart des formats de charge utile audio peuvent avoir un paramètre "channels" facultatif pour spécifier le nombre de canaux audio inclus dans la transmission. L'ordre de canal par défaut est spécifié dans la [RFC3551]. Tout format de charge utile, mais particulièrement les formats audio, peut aussi inclure des paramètres facultatifs "ptime", pour spécifier la durée recommandée en millisecondes représentée par le support dans un paquet, et/ou "maxptime" pour spécifier la quantité maximum de support qui peut être encapsulée dans chaque paquet, exprimée comme un temps en millisecondes. Les paramètres "ptime" et "maxptime" sont définis dans le protocole de description de session (SDP) [RFC4566]. Un format particulier de charge utile peut avoir des paramètres facultatifs supplémentaires. Comme le permet le paragraphe 4.3 de la [RFC4288], de nouveaux paramètres PEUVENT être ajoutés aux types de supports RTP qui ont été définis précédemment, mais les nouveaux paramètres NE DOIVENT PAS changer des fonctionnalités existantes et il DOIT être possible aux mises en œuvre existantes d'ignorer les paramètres supplémentaires sans gêner le fonctionnement.

Considérations de codage  : la plupart des formats de charge utile RTP incluent des données binaires ou tramées comme décrit au paragraphe 4.8 de la [RFC4288]. Les considérations de codage appropriées DOIVENT être notées.

Spécification publiée : une description du codage du support et une spécification du format de charge utile doivent être fournis, généralement par référence à une RFC de spécification de format de charge utile RTP. Cette RFC peut être séparée, ou l'enregistrement de type de support peut être incorporé dans la RFC de spécification du format de charge utile. La spécification de format de charge utile DOIT inclure le débit d'horloge de l'horodatage RTP (ou plusieurs débits pour les codages audio avec plusieurs taux d'échantillonnage).
Une référence à une description plus détaillée du format de compression des données devrait être fournie, si disponible.

Restrictions sur l'usage : le fait que le type de support soit défini pour le transfert via RTP DOIT être noté, en particulier, si le transfert dépend du tramage RTP et donc le type de support est seulement défini pour un transfert via RTP.

Selon que le type a été ou non déjà enregistré pour le transfert avec un protocole non RTP (par exemple, messagerie MIME ou http) plusieurs cas différents peuvent se présenter :

a) Pas encore enregistré comme type MIME
Un nouvel enregistrement devrait être construit en utilisant le gabarit d'enregistrement de type de support. L'enregistrement peut spécifier un transfert via d'autres moyens en plus de RTP si c'est faisable et désiré. Les considérations de codage appropriées doivent être spécifiées, et les restrictions sur l'usage doivent spécifier si le type est seulement défini pour le transfert via RTP ou aussi via d'autres modes. Des paramètres facultatifs peuvent être définis comme nécessaire, et il doit être clairement déclaré à quels modes de transfert s'appliquent les paramètres.

b) Le type MIME existe pour un protocole non RTP
Les restrictions sur l'usage du type existant devraient être changées, si elles existent, ou ajoutées sinon, pour indiquer que le type peut aussi être transféré via RTP. Des paramètres spécifiques de RTP peuvent être ajoutés, et il doit être clairement déclaré qu'ils sont seulement à utiliser quand le type de support est transmis via le transport RTP.

c) Mise à jour d'un type de support existant pour RTP à utiliser pour un protocole non RTP
Les restrictions sur l'usage du type existant devraient être changées pour indiquer que le type peut aussi être transféré via un protocole non RTP (par exemple, SMTP, HTTP). Des paramètres non spécifiques de RTP peuvent être ajoutés, et il doit être clairement déclaré qu'ils ne sont à utiliser que quand le type de support est transmis via un transport non RTP.

 	2.1	Exemple d'enregistrement de type de support
L'exemple d'enregistrement suivant d'un faux type de support audio/exemple montre le texte exigé. Les références à la RFC  nnnn seraient remplacées par les références de la RFC qui contient la spécification de format de charge utile et l'enregistrement du type de support.

Nom de type : audio
Nom de sous type : exemple
Paramètres exigés :
rate : débit d’horloge de l'horodatage RTP, qui est égal au taux d'échantillonnage. Le débit normal est 8000 ; d'autres débits peuvent être spécifiés.
Paramètres facultatifs :
channels : nombre de canaux audio entrelacés, soit 1 pour mono ou 2 pour stéréo, et 1 par défaut si il est omis. L'entrelacement a lieu trame par trame, avec le canal de gauche suivi par le canal de droite.
ptime : longueur recommandée en millisecondes représentée par le support dans un paquet (voir la RFC 4566).
maxptime : quantité maximum du support qui peut être encapsulée dans chaque paquet, exprimé comme un temps en millisecondes (voir la RFC 4566).
Considérations de codage : ce type de supports est fait de trames de données binaires (voir le paragraphe 4.8 de la RFC  4288).
Considérations de sécurité : voir la Section n de la RFC nnnn
Considérations d'interopérabilité : certains receveurs peuvent n'être capables de recevoir qu'un seul canal audio.
Spécification publiée : RFC nnnn
Applications qui utilisent ce type de support : flux audio et vidéo directs et outils de conférences.
Informations supplémentaires : aucune
Personne et adresse de messagerie à contacter pour plus d'informations : Fred Audio <fred@exemple.com>
Utilisation prévue : COMMUN
Restrictions sur l'usage : ce type de support dépend du tramage RTP, et n'est donc défini que pour un transfert via RTP (RFC 3550). Le transfert au sein d'autres protocoles de tramage n'est pas défini pour l'instant.
Auteur  : Fred Audio
Contrôleur des changements : groupe de travail IETF Audio/Video sur délégation de l'IESG.

 	2.2.	Restrictions au partage d'un nom de sous type
Le même nom de sous type de support NE DOIT PAS être partagé par des méthodes de transfert pour RTP et non RTP (fondées sur le fichier) sauf si le format des données est le même pour les deux méthodes. Le format des données est considéré être le même si le format de fichier est équivalent à une séquence enchaînée de charges utiles provenant de paquets RTP non inclus l'en-tête RTP ou tout en-tête de format de charge utile RTP.

Le format de fichier PEUT inclure un numéro magique ou un autre en-tête au début du fichier qui n'est pas inclus quand les données sont transférées via RTP.

Une seconde exigence pour le partage d'un nom de sous type de support est que les ensembles de paramètres exigés doivent être les mêmes pour les deux méthodes.

Dans les cas où le format des données ou les paramètres exigés ne peuvent pas être les mêmes pour les méthodes de transfert RTP et non RTP, les formats de données DOIVENT être enregistrés comme des types séparés. Il est RECOMMANDÉ que les noms de sous types soient en rapport, comme en utilisant une racine commune plus un suffixe. Dans les cas où un suffixe est appliqué dans le nom de sous type pour la méthode de transfert RTP, le suffixe "+rtp" est suggéré.

 	3.	Transposition en paramètres SDP
La représentation d'un type de support est spécifiée dans la syntaxe du champ d'en-tête Content-Type dans la [RFC2045] comme suit :

type "/" sous type *(";" paramètre)

Des paramètres peuvent être exigés pour un type ou sous type particulier ou ils peuvent être facultatifs. Pour les types de supports qui représentent des formats de charge utile RTP, les paramètres "rate", "channels", "ptime", et "maxptime" ont des définitions générales (voir la Section 2) qui peuvent s'appliquer à travers les types et sous types. Le format pour un paramètre est spécifié dans la RFC 2045 comme 

attribut "=" valeur

où l'attribut est le nom du paramètre et les valeurs permises sont spécifiées pour chaque paramètre. La RFC 2045 spécifie qu'une valeur DOIT être présente et que valeur DOIT être une chaîne entre guillemets si elle contient un des caractères spéciaux mentionnés dans cette RFC.

Les informations portées dans la chaîne de type de support ont une transposition spécifique dans les champs du protocole de description de session (SDP) [RFC2327], qui est couramment utilisé pour décrire les sessions RTP. La transposition est la suivante :

o 	Le type de support (par exemple, audio) va dans la ligne SDP "m=" comme nom de codage.

o 	Le sous type de support (format de charge utile) va dans la ligne SDP "a=rtpmap" comme nom de codage.

o 	Les paramètres généraux (éventuellement facultatifs) "rate" et "channels" vont aussi dans "a=rtpmap" comme, respectivement, débit d'horloge et paramètres de codage.

o 	Les paramètres généraux (et facultatifs) "ptime" et "maxptime" vont, respectivement, dans les attributs SDP "a=ptime" et "a=maxptime".

o 	Tout paramètre spécifique du format de charge utile va dans l'attribut SDP "a=fmtp". L'ensemble de paramètres admis défini par la RFC qui spécifie le format de charge utile NE DOIT PAS être étendu par l'enregistrement de type de support sans une révision correspondante de la spécification du format de charge utile. Le format et la syntaxe de ces paramètres peuvent aussi être définis par la spécification du format de charge utile, mais il est suggéré que les paramètres soient copiés directement de la chaîne de type de support comme une liste séparée par des points virgule de paires "paramètre=valeur". Pour les formats de charge utile qui spécifient une autre syntaxe pour les paramètres fmtp, l'enregistrement de ce format de charge utile comme type de support doit spécifier ce que sont les paramètres dans le format MIME et comment les transposer en l'attribut SDP "a=fmtp". 

Un exemple de transposition est : audio/L16; rate=48000; channels=2; ptime=5; emphasis=50-15

m=audio 49170 RTP/AVP 97
a=rtpmap:97 L16/48000/2
a=fmtp:97 emphasis=50-15
a=ptime:5

Noter que les noms de format (codage) de charge utile définis dans le profil RTP [RFC3551] sont couramment montrés en majuscules. Les sous types de support sont couramment montrés en minuscules. Ces noms sont insensibles à la casse dans les deux cas. De même, les noms de paramètres sont insensibles à la casse dans les types MIME et dans la transposition par défaut en l'attribut SDP a=fmtp.

 	4.	Changements par rapport à la RFC 3555

Le présent document met à jour la RFC 3555 pour se conformer aux procédures révisées d'enregistrement de type de supports de la [RFC4288]. Alors que la RFC 3555 exigeait que les considérations de codage spécifient le transfert via RTP, c'est maintenant spécifié sous les restrictions à l'usage. Le présent document spécifie aussi les conditions dans lesquelles de nouveaux paramètres facultatifs peuvent être ajoutés à des types de supports RTP précédemment définis, et il ajoute un nouveau paragraphe 2.2 pour préciser les exigences de partage d'un type de supports entre des méthodes de transfert RTP et non RTP.

La RFC 3555 incluait des enregistrements de types de supports pour les formats de charge utile RTP définis dans le profil RTP pour les conférences audio et vidéo, [RFC3551]. Ces enregistrements de types de supports ont été retirés du présent document. Certains d'entre eux ont été rassemblés dans une RFC séparée [RFC4856], laissant de côté ceux qui ont été, ou qui sont destinés à être, enregistrés dans des révisions de leur propre RFC de spécification de format de charge utile.

Philipp Hoschka est le co-auteur de la RFC 3555 ; ses contributions aux fondations du présent document ont été appréciées.

 	5.	Considérations sur la sécurité

La procédure d'enregistrement de type de support spécifiée dans le présent mémoire n'impose par elle-même aucune considérations de sécurité. Les enregistrements qui se conforment à cette procédure n'imposent pas non plus par eux-mêmes de risques pour la sécurité. Cependant, l'utilisation des types de supports enregistrés pourrait très bien faire courir des risques pour la sécurité :

o 	Tout type de support qui contient un "contenu actif" fait courir le risque d'effets collatéraux malveillants sauf si l'exécution de ce contenu est adéquatement contrainte.

o 	Plusieurs codages audio et vidéo sont parfaits pour cacher des données en utilisant la stéganographie.

o 	La spécification RTP [RFC3550] fournit des considérations de sécurité pour le transport de données audio et vidéo sur RTP, incluant l'utilisation du chiffrement quand la confidentialité est exigée.

Donc, chaque enregistrement de type de support doit déclarer toutes les considérations de sécurité qui s'appliquent à l'utilisation de ce type. Le reste de cette Section est copié de la [RFC4288], qui spécifie les procédures d'enregistrement de type de support en général.

Une analyse des questions de sécurité DOIT être effectuée pour tous les types enregistrés dans l'arborescence standard. Une analyse similaire est conseillée, mais non exigée pour les types de supports enregistrés dans les arborescences de fabricant ou personnelle. Cependant, sans considération de la nature de l'analyse de sécurité qui a été ou non faite, toutes les descriptions de questions de sécurité DOIVENT être aussi précises que possible sans considération de l'arborescence d'enregistrement. En particulier, la déclaration qu'il "n'y a pas de problème de sécurité associé à ce type" NE DOIT PAS être confondue avec "les problèmes de sécurité associés à ce type n'ont pas été vérifiés".

Il n'est absolument pas exigé que les types de supports enregistrés dans une des arborescences soient sécurisés ou absolument sans risque. Néanmoins, tous les risques connus pour la sécurité DOIVENT être identifiés dans l'enregistrement d'un type de support, là encore, sans considération de l'arborescence d'enregistrement.

La section des considérations pour la sécurité de tout enregistrement est soumise à une évaluation permanente et à modification, et en particulier PEUT être étendue par l'utilisation des mécanismes de "commentaires sur les types de supports" décrits à la Section 6 de la RFC4288.

Certaines des questions qui devraient être regardées dans une analyse de sécurité d'un type de support sont :

o	Les types de supports complexes peuvent inclure des dispositions qui donnent des directives qui instituent des actions sur les fichiers ou autres ressources d'un receveur. Dans de nombreux cas, des dispositions sont prises pour que le générateur spécifie des actions arbitraires sans restriction qui peuvent avoir des effets dévastateurs. Voir un exemple de telles directives dans l'enregistrement du type de support application/postscript dans la [RFC2046] et de la façon dont il devrait être décrit dans un enregistrement de type de support.
o	Tous les enregistrements DOIVENT déclarer si ils emploient ou non un tel "contenu actif", et si ils le font, ils DOIVENT déclarer quelles mesures sont prises pour protéger les utilisateurs du type de support contre les dommages éventuels.
o	Les types de supports complexes peuvent inclure des dispositions pour donner des directives qui instituent des actions qui, bien que non directement dommageables pour le receveur, peuvent résulter en la divulgation d'informations qui vont faciliter une attaque ultérieure ou violer d'une certaine manière la confidentialité du receveur. Là encore, l'enregistrement du type de support application/postscript illustre comment peuvent être traitées de telles directives.
o	Un type de support qui emploie la compression peut fournir une opportunité d'envoi d'une petite quantité de données qui, lorsque elles sont reçues et évaluées, se développent énormément pour consommer toutes les ressources du receveur. Tous les types de supports DEVRAIENT déclarer si ils emploient ou non la compression, et s'ils l'emploient, ils devraient exposer quelles mesures doivent être prises pour éviter de telles attaques.
o	Un type de support pourrait être ciblé sur des applications qui requièrent une sorte d'assurance de sécurité mais ne fournissent pas elles-mêmes les mécanismes de sécurité nécessaires. Par exemple, un type de support pourrait être défini pour la mémorisation d'informations médicales confidentielles qui à son tour exige un service de confidentialité externe, ou qui serait conçu pour une utilisation exclusive en environnement sécurisé.

 	6.	 Considérations relatives à l'IANA

L'objet du présent document est de spécifier les exigences et procédures d'enregistrement des formats de charge utile dans le registre IANA des types de supports. Aucun enregistrement n'est défini ici.

 	7.	Références
 	7.1	Références normatives

[RFC2045]	N. Freed et N. Borenstein, "Extensions de messagerie Internet multi-objets (MIME) Partie 1 : Format des corps de message Internet", novembre 1996. (D.S., MàJ par 2184, 2231, 5335.)

[RFC2046]	N. Freed et N. Borenstein, "Extensions de messagerie Internet multi-objets (MIME) Partie 2 : Types de support", novembre 1996. (D.S., MàJ par 2646, 3798, 5147, 6657, 8098)

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

[RFC3550]	H. Schulzrinne, S. Casner, R. Frederick et V. Jacobson, "RTP : un protocole de transport pour les applications en temps réel", STD 64, juillet 2003. (MàJ par RFC7164, RFC7160, RFC8083, RFC8108, RFC8860)

[RFC3551]	H. Schulzrinne et S. Casner, "Profil RTP pour conférences audio et vidéo avec contrôle minimal", STD 65, juillet 2003. (MàJ par RFC8860)

[RFC4288]	N. Freed et J. Klensin, "Spécifications du type de support et procédures d'enregistrement", BCP 13, décembre 2005.

[RFC4566]	M. Handley, V. Jacobson et C. Perkins, "SDP : Protocole de description de session", juillet 2006. (P.S.  ; remplacée par RFC8866)

 	7.2	Références pour information

[RFC4856]	S. Casner, "Enregistrement de type de support des formats de charge utile dans le profil RTP pour audio et visio conférences", février 2007. (Remplace RFC3555) (P.S.)

 	Adresse de l'auteur
Stephen L. Casner
Packet Design
3400 Hillview Avenue, Building 3
Palo Alto, CA 94304
USA
téléphone : +1 650 739-1843
mél : casner@acm.org 

 	Déclaration complète de droits de reproduction

Copyright (C) The IETF Trust (2007).

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 encloses ne viole 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 pourrait ê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 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 fourni par l'activité de soutien administatif (IASA) de l'IETF.