Équipe d'ingénierie de l'Internet (IETF)	J. Rosenberg, Skype	
Request for Comments: 5688	janvier 2010	
Catégorie : Sur la voie de la normalisation		
ISSN: 2070-1721	Traduction Claude Brière de L'Isle	

Étiquette de caractérisation du support de protocole d'initialisation de session (SIP) pour les sous-types d'application MIME

Résumé
La spécification des préférences de l'appelant pour le protocole d'initialisation de session (SIP, Session Initiation Protocol) permet à un appelant d'exprimer ses préférences pour que l'appel soit acheminé à un agent d'utilisateur (UA, User Agent) avec des capacités particulières. De même, une spécification existe pour permettre à un UA d'indiquer ses capacités dans un enregistrement. Parmi ces capacités est le type de flux de supports que l'agent prend en charge, décrit comme un type MIME de niveau supérieur. Le type MIME "application" est utilisé pour décrire une large gamme de types de flux, et il donne une granularité insuffisante pour une capacité. La présente spécification permet à un UA d'indiquer quels sous types d'application l'agent prend en charge.

Statut de ce mémoire
Ceci est un document de l’Internet sur la voie de la normalisation.

Le présent document a été produit par l’équipe d’ingénierie de l’Internet (IETF). Il représente le consensus de la communauté de l’IETF. Il a subi une révision publique et sa publication a été approuvée par le groupe de pilotage de l’ingénierie de l’Internet (IESG). Tous les documents approuvés par l’IESG ne sont pas candidats à devenir une norme de l’Internet ; voir la Section 2 de la RFC5741.

Les informations sur le statut actuel du présent document, tout errata, et comment fournir des réactions sur lui peuvent être obtenues à http://www.rfc-editor.org/info/rfc5688 

Notice de droits de reproduction
Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document. Les composants de code extraits du présent document doivent inclure le texte de licence simplifié de BSD comme décrit au paragraphe 4.e des dispositions légales du Trust et sont fournis sans garantie comme décrit dans la licence de BSD simplifiée.

Le présent document peut contenir des matériaux provenant de documents de l’IETF ou de contributions à l’IETF publiées ou rendues disponibles au public avant le 10 novembre 2008. La ou les personnes qui ont le contrôle des droits de reproduction sur tout ou partie de ces matériaux peuvent n’avoir pas accordé à l’IETF Trust le droit de permettre des modifications de ces matériaux en dehors du processus de normalisation de l’IETF. Sans l’obtention d’une licence adéquate de la part de la ou des personnes qui ont le contrôle des droits de reproduction de ces matériaux, le présent document ne peut pas être modifié en dehors du processus de normalisation de l’IETF, et des travaux dérivés ne peuvent pas être créés en dehors du processus de normalisation de l’IETF, excepté pour le formater en vue de sa publication comme RFC ou pour le traduire dans une autre langue que l’anglais.
Table des matières
1. Introduction	2
2. Terminologie	2
3. Étiquette de caractéristique de support sip.app-subtype	2
4. Exemple	3
5. Considérations sur la sécurité	3
6. Considérations relatives à l'IANA	4
7. Références	4
7.1 Références normatives	4
7.2 Références pour information	5
Adresse de l'auteur	5

 	1.	Introduction

La spécification des préférences de l'appelant [RFC3841] pour le protocole d'initialisation de session (SIP, Session Initiation Protocol) [RFC3261] permet à un utilisateur d'exprimer ses préférences pour l'acheminement des demandes SIP. Ces préférences sont exprimées comme un ensemble de capacités désirées et des caractéristiques de l'agent receveur. Quand un agent d'utilisateur s'enregistre sur le réseau SIP, il inclut, au titre de son enregistrement, ses propres capacités et caractéristiques [RFC3840]. Ces capacités sont mémorisées au titre de l'enregistrement, et rendues ensuite disponibles au mandataire dans le réseau. Quand une demande arrive au mandataire avec les préférences de l'appelant, les préférences dans la demande sont comparées aux caractéristiques et capacités prises en charge mémorisées dans les enregistrements, et le résultat est utilisé pour choisir les agents d'utilisateur cibles pour la demande.

La RFC 3840 utilise des étiquettes de caractéristiques de support [RFC2506]. Chaque étiquette a un nom et un type. Les étiquettes définies dans la RFC 3840 décrivent certaines des caractéristiques de base des agents d'utilisateur, incluant si ils sont ou non des automates (étiquette sip.automata) leur classe (étiquette sip.class) si ils prennent en charge le support dans une ou les deux directions (étiquette sip.duplex) et si ils sont un point de conférence (sip.isfocus). Ces étiquettes incluent aussi les capacités SIP, y compris les schémas pris en charge par l'agent (sip.schemes) les méthodes (sip.methods) et les paquetages d'événements (sip.events) [RFC3265].

La RFC 3840 définit aussi des étiquettes de caractéristiques de support pour les types de flux multimédia. Une étiquette de caractéristique de support est définie pour chaque type de support de niveau supérieur -- sip.audio pour les flux audio, sip.video pour les flux vidéo, et ainsi de suite. Leur principal cas d'utilisation est pour livrer correctement les sessions multimédia à l'agent d'utilisateur qui prend en charge ce type de support. Considérons un appelant sur un visiophone qui veut avoir un appel en vidéo avec un autre utilisateur. Cet utilisateur a deux appareils -- un téléphone mobile qui prend seulement l'audio et un visiophone. On aimerait livrer l'appel en vidéo au visiophone en priorité, et faire seulement "sonner" l'appareil mobile pour un appel seulement audio si l'utilisateur n'est pas présent sur le visiophone.

La RFC 3840 définit des étiquettes de caractéristiques de support pour chaque type de support de niveau supérieur, incluant "application". Ce type de supports couvre une gamme extrêmement large de sous types -- jeux multi joueurs de toutes sortes, tableaux interactifs partagés et partage d'application, et ainsi de suite. Avec l'audio et la vidéo, il y a souvent un codec commun pris en charge par les agents (c'est-à-dire, un sous type commun). Par conséquent, si un appelant veut une session audio, l'acheminement de la demande à tout agent d'utilisateur qui prend en charge l'audio va probablement résulter en des communications réussies. Cependant, avec des flux d'application, acheminer juste une demande à un agent qui prend en charge *des* flux d'application n'est pas très utile ; les flux d'application pour des applications différentes sont très différents. Par conséquent, l'étiquette de caractéristique de support d'application ne fournit pas une granularité suffisante pour les préférences d'appel. Le sous type d'application spécifique doit aussi être indiqué.

Pour remédier à cela, la présente spécification définit une nouvelle étiquette de caractéristique de support qui indique quels sous types d'application sont pris en charge par l'agent pour la livraison des flux. Le nom de cette étiquette de caractéristique de support est "sip.app-subtype".

 	2.	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].

 	3.	Étiquette de caractéristique de support sip.app-subtype

L'étiquette de caractéristique de support "sip.app-subtype" est de type jeton avec une relation d'égalité insensible à la casse. Sa valeur peut être tout sous type enregistré ou privé d'application MIME conforme à la grammaire de nom de sous type définie dans la [RFC4288]. Quand elle est incluse dans le champ d'en-tête Contact d'une demande REGISTER, un agent DEVRAIT inclure tous les sous types d'application qu'il peut prendre en charge comme formats d'écoulement. Un sous type d'application est pris en charge si l'agent d'utilisateur serait capable de traiter une offre [RFC3264] du protocole de description de session (SDP, Session Description Protocol) [RFC4566] qui contient ce sous type comme format dans la ligne m- du SDP.

Quand elle est incluse dans le champ d'en-tête Accept-Contact ou Reject-Contact, elle indique le désir d'un client d'agent d'utilisateur (UAC, User Agent Client) d'être connecté à un serveur d'agent d'utilisateur (UAS, User Agent Server) qui peut, respectivement, prendre en charge ou ne pas prendre en charge l'écoulement en utilisant ce sous type d'application.

Il est important de noter que cette étiquette de caractéristique de support indique seulement les types de supports d'écoulement qu'un agent d'utilisateur est capable de prendre en charge. Elle ne dit rien de la fonctionnalité fournie par l'agent d'utilisateur lui-même ou les types MIME que l'agent peut envoyer ou recevoir dans les messages ou courriels SIP. Par exemple, supposons qu'un agent d'utilisateur SIP soit capable de prendre en charge un jeu d'échecs. La partie est jouée par chaque utilisateur qui envoie un mouvement de pièce comme un objet binaire sur UDP entre une paire d'agents d'utilisateur. Ces objets ont un type MIME de "application/exemple". Quand un UA inclut l'étiquette de caractéristique de support sip.app-subtype dans un champ d'en-tête Contact avec une valeur de "exemple", cela signifie que l'UA peut traiter un INVITE SIP qui contient un SDP avec une ligne de support d'application et le format de "exemple". Cela ne veut pas dire que l'agent d'utilisateur SIP est une application d'échecs, ou que l'agent d'utilisateur peut accepter les demandes SIP qui incluent des corps de type "application/exemple". Pour indiquer qu'un agent d'utilisateur peut accepter des demandes SIP qui incluent des corps de type "application/exemple", l'agent va utiliser l'étiquette de caractéristique de support "type" comme défini dans la [RFC3840].

Une conséquence de cela est que, lorsque de nouveaux formats de type de support d'écoulement sont définis (comme des formats de flux de jeux, des formats de session de tableau interactif, et ainsi de suite) ils DEVRAIENT être définis en utilisant le flux d'application SDP et utiliser un sous type d'application MIME.

 	4.	Exemple

Voici un exemple de fragment de message SIP REGISTER qui indique l'usage de cette étiquette de caractéristique de support. Le REGISTER indique que l'UA peut participer à des sessions de supports d'application utilisant un échange d'objets de type "application/exemple".

REGISTER sip:exemple.com SIP/2.0
To: sip:Y@exemple.com
Contact: <sip:Y1@pc.exemple.com>
 ;methods="INVITE,ACK,OPTIONS,BYE,CANCEL"
 ;uri-user="<Y1>"
 ;uri-domain="exemple.com"
 ;audio
 ;schemes="sip"
 ;mobility="fixed"
 ;class="personal"
 ;+sip.app-subtype="exemple"

Cet enregistrement indique qu'un INVITE de la forme suivante :

INVITE sip:Y@exemple.com SIP/2.0
To: sip:Y@exemple.com
Content-Type: application/sdp
Content-Length: ...

v=0
o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
c=IN IP4 192.0.1.2
t=0 0
m=audio 49170 RTP/AVP 0
m=application 8493 udp exemple

va être accepté par l'UA. Le SDP dans le INVITE indique une session audio et une session application qui fonctionne sur UDP et échange des formats d'objet "application/exemple".

 	5.	Considérations sur la sécurité

Quand elle est présente dans une demande REGISTER, cette étiquette de caractéristique de support donne des informations sur l'ensemble de flux de supports d'application pris en charge. Il est possible que ces informations soient sensibles, fournissant des indications sur les capacités d'un produit. Ces considérations sont déjà discutées dans la RFC 3840, et ces considérations s'appliquent ici aussi. Les applications qui utilisent cette étiquette de caractéristique de support DEVRAIENT fournir un moyen d'assurer son intégrité. De même, l'étiquette de caractéristique de support devrait seulement être estimée valide quand elle vient de l'utilisateur ou agent d'utilisateur décrit par l'étiquette de caractéristique. Par suite, les mécanismes pour convoyer l'étiquette de caractéristique DEVRAIENT fournir un mécanisme pour garantir l'authenticité.

 	6.	Considérations relatives à l'IANA

Cette spécification ajoute une nouvelle étiquette de caractéristique de support à l'arborescence d'enregistrement d'étiquette de caractéristique de support SIP définie dans la [RFC3840].

Nom d'étiquette de caractéristique de support : sip.app-subtype

Identifiant ASN.1 : 1.3.6.1.8.4.24

Résumé des caractéristiques de support indiquées par cette étiquette : cette étiquette de caractéristique indique les sous types d'application MIME pris en charge par l'agent pour les besoins d'écoulement des supports.

Valeurs appropriées à utiliser avec cette étiquette de caractéristique : jeton (relation d'égalité).

L'étiquette de caractéristique est principalement destinée à être utilisée dans les applications, protocoles, services, ou mécanismes de négociation suivants : cette étiquette de caractéristique est des plus utiles dans une application de communication, pour décrire les capacités d'un appareil, comme un téléphone ou une tablette.

Exemples d'utilisation typique : acheminement d'un appel à un téléphone qui peut prendre en charge un jeu à plusieurs joueurs.

Normes ou documents en rapport : RFC 5688

Considérations de sécurité : les considérations de sécurité pour cette étiquette de caractéristique de support sont discutées à la Section 5 de la RFC 5688.

 	7.	Références
 	7.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. DOI 10.17487/RFC2119, (MàJ par RFC8174)

[RFC3264]	J. Rosenberg et H. Schulzrinne, "Modèle d'offre/réponse avec le protocole de description de session (SDP)", juin 2002, DOI 10.17487/RFC3264. (P.S.  ; MàJ par RFC8843, 9143)

[RFC3840]	J. Rosenberg, H. Schulzrinne et P. Kyzivat, "Indication des capacités d'agent d'utilisateur dans le protocole d'initialisation de session (SIP)", août 2004

[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, DOI 10.17487/RFC4566. (P.S.  ; remplacée par RFC8866)

 	7.2	Références pour information

[RFC2506]	K. Holtman, A. Mutz, T. Hardie, "Procédure d'enregistrement d'étiquette de caractéristique de support", mars 1999. (BCP0031)

[RFC3261]	J. Rosenberg et autres, "SIP : Protocole d'initialisation de session", juin 2002, DOI 10.17487/RFC3261. (Mise à jour par 3265, 3853, 4320, 4916, 5393, 6665, 8217, 8760)

[RFC3265]	A.B. Roach, "Notification d'événement spécifique du protocole d'initialisation de session (SIP)", juin 2002. (MàJ par RFC6446) (Remplacée par la RFC6665) 

[RFC3841]	J. Rosenberg, H. Schulzrinne, P. Kyzivat, "Préférences de l'appelant pour le protocole d'initialisation de session (SIP)", août 2004. (P.S.)

 	Adresse de l'auteur

Jonathan Rosenberg
Skype
Monmouth, NJ
USA

mél : jdrosen@jdrosen.net
URI : http://www.jdrosen.net