Groupe de travail Réseau |
O. Levin, Microsoft Corporation |
Request for Comments : 4574 |
G. Camarillo, Ericsson |
Catégorie : Norme |
Traduction Claude Brière de L’Isle |
août 2006 |
septembre 2007 |
Statut de ce mémo
Le présent document spécifie un protocole de normalisation Internet pour la communauté de l'Internet, qui appelle à la discussion et à des suggestions pour son amélioration. Prière de se reporter à l'édition en cours des "Normes de protocole officielles de l'Internet" (STD 1) sur l'état de la normalisation et le statut de ce protocole. La distribution du présent mémo n'est soumise à aucune restriction.
Notice de Copyright
Copyright (C) The Internet Society (2006).
Résumé
Le présent document définit un nouvel attribut de niveau de support du protocole de description de session (SDP, Session Description Protocol) : "label". L’attribut "label" porte un pointeur sur le flux de support dans le contexte d’une application de réseau arbitraire qui utilise SDP. L’envoyeur du document SDP peut attacher l’attribut "label" à un ou des flux de support particuliers. L’application peut alors utiliser le pointeur fourni pour se référer à chaque flux de support particulier dans son contexte.
SDP est utilisé par des applications très diverses distribuées sur le réseau. Ces applications ont affaire à des sessions qui sont décrites par SDP [4] et desservent des utilisateurs ou services dans le contexte d’une seule instance d’application. Ces sortes d’applications ont besoin d’un moyen pour identifier un flux de support particulier) travers les multiples descriptions SDP échangée avec les différents utilisateurs.
Le cadre XCON est un exemple d’architecture de conférence centralisée qui utilise SDP conformément au mécanisme d’offre/réponse défini dans [3] pour établir des flux de support avec chaque autre participant à la conférence. De plus, XCON identifie le besoin d’identification univoque d’un flux de support selon son rôle dans une conférence indépendamment de son type de support, du protocole de transport, et du format du support. Ceci peut être accompli en utilisant un document externe qui pointe sur le flux de support approprié et fournit sur lui des informations (par exemple, le rôle du flux de support dans la conférence). Le paquetage d’événement SIP pour l’état de la conférence [7] définit et utilise un format concret pour de tels documents externes.
La présente spécification définit l’attribut SDP [4] "label" de niveau support, qui procure un pointeur sur un flux de support qui est décrit par une ligne 'm' dans une description de session SDP.
Dans le présent document, les mots clé "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDÉ", "PEUT", et "FACULTATIF" sont à interpréter comme décrit dans le BCP 14 [RFC2119].
Bien que SDP et ses extensions fournissent déjà quelques moyens de se référer à un flux de support, aucun d’eux n’est approprié à une utilisation dans le contexte de documents externes qui pourraient être créés avant la description de session elle-même et doivent être traités par des automates.
L’attribut SDP 'i', défini dans la RFC 2327 [4], peut être utilisé pour étiqueter des flux de support. Néanmoins, les valeurs de l’attribut 'i' sont destinées à l’utilisateur humain et non aux automates.
L’attribut SDP 'mid', défini dans la RFC 3388 [6], peut lui aussi être utilisé pour identifier des flux de support. Néanmoins, la portée de 'mid' est trop limitée pour être utilisée par des applications qui ont affaire à plusieurs sessions SDP. Et cela à cause des valeurs de l’attribut 'mid' qui sont significatives dans le contexte d’une seule session SDP, mais pas dans le contexte d’une application plus grosse (par exemple, une application multiparties).
Une autre façon de se référer à un flux de support est d’utiliser l’ordre de la ligne 'm' dans le document de session SDP (par exemple, le 5 ème flux de support dans la description de session). C’est le mécanisme utilisé dans le modèle offre/réponse [3].
Le problème posé par ce mécanisme est qu’il ne peut être utilisé que pour se référer aux flux de support de descriptions de session qui existent déjà. Il y a des scénarios où un document statique a besoin de se référer, à l’aide d’un pointeur, à un flux de support qui sera négocié au moyen de SDP et n’est pas encore créé. Lorsque le flux de support est finalement créé, l’application besoin d’étiqueter le flux de support de façon que le pointeur dans le document statique pointe sur le flux de support approprié dans la description de session.
La présente spécification définit un nouvel attribut de valeur de niveau support : 'label'. Son format en SDP est décrit par l’ABNF [2] suivant :
label-attribute = "a=label:" pointer
pointer = token
token = 1*(token-char)
applicationtoken-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 / %x41-5A / %x5E-7E
Les éléments token-char et token sont définis dans [4] mais sont inclus ici pour fournir un support à ceux qui mettent en oeuvre cette caractéristique de SDP.
L’attribut 'label' contient un jeton (token) qui est défini par une application et est utilisé dans son contexte. Le nouvel attribut peut être affecté aux lignes 'm' dans les documents SDP multiples ce qui permet à l’application de grouper logiquement les flux de support à travers les sessions SDP lorsque nécessaire.
La présente spécification ne définit pas de moyen pour découvrir si le point d’extrémité homologue comprend ou non l’attribut 'label' parce que les valeurs de 'label' ne sont qu’informatives au niveau du modèle offre/réponse.
Au niveau de l’offre/réponse, cela signifie que le fait qu’une offre ne contienne pas d’attribut label n’implique pas que la réponse ne devrait pas en avoir. Cela signifie aussi que le fait qu’une offre contienne des attributs label n’implique pas que la réponse devrait en avoir aussi.
En plus de la règle de base d’offre/réponse ci-dessus, les applications qui utilisent 'label' comme pointeur sur des flux de support DOIVENT spécifier ses contraintes d’utilisation. Par exemple, de telles applications PEUVENT rendre obligatoire la prise en charge de 'label'. Dans ce cas, l’application définira les moyens de négociation de la prise en charge de l’attribut 'label' au titre de la présente spécification.
Ce qui suit est un exemple de description de session SDP qui utilise l’attribut 'label' :
v=0
o=bob 280744730 28977631 IN IP4 host.example.com
s=
i=A Séminaire sur le protocole de description de session
c=IN IP4 192.0.2.2
t=0 0
m=audio 6886 RTP/AVP 0
a=label:1
m=audio 22334 RTP/AVP 0
a=label:2
Un attaquant peut essayer d’ajouter, modifier, ou retirer des attributs 'label' de la description de session. Il pourrait en résulter un comportement indésirable de l’application. Aussi, il est fortement RECOMMANDÉ que la protection de l’intégrité soit appliquée aux descriptions de session SDP. Pour les descriptions de session portées dans SIP [5], S/MIME est le choix naturel pour fournir une telle protection d’intégrité de bout en bout, comme décrit dans la RFC 3261 [5]. D’autres applications PEUVENT utiliser une forme différente de protection de l’intégrité.
L’IANA a enregistré le nouvel attribut SDP suivant :
Nom du contact : Orit Levin oritl@microsoft.com.
Nom d’attribut : "label".
Type d’attribut : Niveau de support.
Sujet à charset : Non.
Objet de l’attribut : L’attribut 'label' associe un flux de support à une étiquette (label). Cette étiquette permet au flux de support d’être référencé par des documents externes.
Valeurs d’attributs permises : Un jeton.
Robert Sparks, Adam Roach, et Rohan Mahy ont fourni des commentaires utiles sur ce document.
[1] Bradner, S., "Mots clés à utiliser dans les RFC pour indiquer les niveaux d’exigence", BCP 14, RFC 2119, mars 1997.
[2] Crocker, D., éd. et P. Overell, "BNF augmenté pour les spécifications de syntaxe: ABNF", RFC 4234, octobre 2005.
[3] Rosenberg, J. et H. Schulzrinne, "Modèle d’offre/réponse avec le protocole de description de session (SDP)", RFC 3264, juin 2002.
[4] Handley, M., Jacobson, V. et C. Perkins, "SDP : Protocole de description de session", RFC 4566, juillet 2006.
[5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., et E. Schooler, "SIP : Protocole d’initialisation de session", RFC 3261, juin 2002.
[6] Camarillo, G., Eriksson, G., Holler, J., et H. Schulzrinne, "Groupement de lignes de supports dans le protocole de description de session (SDP)", RFC 3388, décembre 2002.
[7] Rosenberg, J., Schulzrinne, H., et O. Levin, "Paquetage d’événement pour l’état de la conférence dans le protocole d’initialisation de session (SIP)", RFC 4575, août 2006.
Adresse des auteurs
Orit Levin |
Gonzalo Camarillo |
Microsoft Corporation |
Ericsson |
One Microsoft Way |
Hirsalantie 11 |
Redmond, WA 98052 |
Jorvas 02420 |
USA |
Finland |
mél : oritl@microsoft.com |
Déclaration de copyright
Copyright (C) The Internet Society (2006).
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 y contenues sont fournies 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 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 la Administrative Support Activity (IASA) de l'IETF.