Groupe de travail Réseau	O. Levin, Microsoft Corporation	
Request for Comments : 4508	A. Johnston, Avaya	
Catégorie : Sur la voie de la normalisation	mai 2006	
Traduction Claude Brière de L'Isle		

Transport des étiquettes de caractéristique avec la méthode REFER du protocole d'initialisation de session (SIP)

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é
L'extension à SIP "Préférences de l'appelant" définie dans la RFC 3840 fournit un mécanisme qui permet à une demande SIP de porter des informations relatives aux capacités et préférences du générateur pour traiter cette demande. La méthode SIP REFER définie dans la RFC 3515 fournit un mécanisme qui permet à une partie d'induire une autre à initier une demande SIP. Le présent document étend la méthode REFER pour utiliser le mécanisme de la RFC 3840. Faisant ainsi, le générateur d'un REFER peut informer le receveur des caractéristiques de la cible que la demande induite est supposée atteindre.
Table des matières
1. Introduction	1
2. Terminologie	2
3. Définitions	2
4. Exemples	2
4.1 Usage de l'étiquette de caractéristiques isfocus	2
4.2 Usage des étiquettes de caractéristiques de voix et de vidéo	2
4.3 Exemple avec paramètres d'URI et plusieurs étiquettes de caractéristiques	2
5. Considérations sur la sécurité	3
6. Remerciements	3
7. Références normatives	3
Adresse des auteurs	3
Déclaration complète de droits de reproduction	4

 	1.	Introduction

Le présent document étend la méthode SIP [RFC3261] REFER définie dans la [RFC3515] pour être utilisée avec les paramètres de caractéristiques définis dans la [RFC3840].

Les étiquettes de caractéristiques sont utilisées par un agent d'utilisateur (UA) pour porter à un autre UA des informations sur ses capacités et caractéristiques. Ces informations peuvent être partagées par un UA en utilisant un certain nombre de mécanismes, incluant des demandes et réponses REGISTER et des réponses OPTIONS. Ces informations peuvent aussi être partagées dans le contexte d'un dialogue en incluant un URI de cible distante (URI de contact).

Les informations d'étiquette de caractéristiques peuvent être très utiles à un autre UA. Elles sont particulièrement utiles avant l'établissement d'une session. Par exemple, si un UA connaît (par exemple par une interrogation OPTIONS) que l'UA distant prend en charge à la fois la vidéo et l'audio, l'UA appelant peut faire un appel offrant la vidéo dans le SDP. Un autre exemple serait quand un UA sait qu'un UA distant agit comme point de concentration et d'hébergement d'une conférence. Dans ce cas, l'UA peut d'abord s'abonner à l'URI de conférence et découvrir les détails de la conférence avant d'envoyer un INVITE pour s'y joindre.

Cette extension à la méthode REFER fournit un mécanisme par lequel le producteur de REFER peut fournir ces informations utiles sur les capacités et les fonctionnalités de la cible du REFER au receveur du REFER en incluant les étiquettes de caractéristiques dans le champ d'en-tête dans une demande REFER.

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

Pour simplifier la discussions de la méthode REFER et ses extensions, trois nouveaux termes sont utilisés dans ce document :
o	roducteur de REFER : l'UA qui produit la demande REFER
o	receveur de REFER : l'UA qui reçoit la demande de REFER
o	cible de REFER : l'UA désigné dans l'URI Refer-To

 	3.	Définitions

Le BNF de Refer-To d'après la RFC 3515 :

Refer-To = ("Refer-To" / "r") HCOLON ( name-addr / addr-spec ) *(SEMI generic-param)

est étendu en :

Refer-To = ("Refer-To" / "r") HCOLON ( name-addr / addr-spec ) *(SEMI refer-param)
refer-param = generic-param / feature-param

où feature-param est défini à la Section 9 de la [RFC3840].

Noter que si des paramètres d'URI sont présents, l'URI entier doit être enclos dans "<" et ">". Si les "<" et ">" ne sont pas présents, tous les paramètres après l'URI sont des paramètres d'en-tête, et non des paramètres de l'URI.

 	4.	Exemples
 	4.1	Usage de l'étiquette de caractéristiques isfocus
L'exemple ci-dessous montre comment l'étiquette de caractéristique "isfocus" peut être utilisée par le producteur de REFER pour dire au receveur de REFER que la cible de REFER est un point de concentration de conférence et que, par conséquent, l'envoi d'une INVITE va amener le receveur de REFER dans la conférence :

Refer-To: sip:conf44@exemple.com;isfocus

 	4.2	Usage des étiquettes de caractéristiques de voix et de vidéo
L'exemple ci-dessous montre comment un producteur de REFER peut dire au receveur de REFER que la cible de REFER prend en charge l'audio et la vidéo et, par conséquent, qu'une session de vidéo et d'audio peut être établie par l'envoi d'une INVITE à la cible de REFER  :

Refer-To: "Vidéophone d'Alice" <sip:alice@videophone.exemple.com> ;audio;video

 	4.3	Exemple avec paramètres d'URI et plusieurs étiquettes de caractéristiques
L'exemple ci-dessous montre comment le producteur de REFER peut dire au receveur de REFER que la cible de REFER est un serveur de messagerie vocale. Noter que le paramètre d'URI de transport est enclos dans les "<" et ">" de sorte qu'il n'est pas interprété comme un paramètre d'en-tête.

Refer-To: <sip:alice-vm@exemple.com;transport=tcp> ;actor="msg-taker";automata;audio

 	5.	Considérations sur la sécurité

Les étiquettes de caractéristiques peuvent fournir des informations sensibles sur un utilisateur ou un UA. À ce titre, la RFC  3840 donne un avertissement quant à la fourniture d'informations sensibles à une autre partie. Une fois que ces informations sont données, elles peuvent être utilisées de façon incontrôlée, incluant de les relayer à un tiers comme dans cette spécification.

Un producteur de REFER NE DOIT PAS créer ou deviner des étiquettes de caractéristiques. Une étiquette de caractéristiques incluse dans un REFER DEVRAIT plutôt être découverte par une méthode authentifiée et sécurisée (comme dans une réponse OPTIONS ou d'un URI cible distant dans un dialogue) directement de la cible de REFER.

Il est RECOMMANDÉ que le producteur de REFER inclut dans le champ d'en-tête Refer-To toutes les étiquettes de caractéristiques qui étaient mentionnées dans le plus récent champ d'en-tête Contact de la cible du REFER.

Une étiquette de caractéristiques fournie par un producteur de REFER ne peut pas être authentifiée ni certifiée directement à partir de la demande REFER. À ce titre, le receveur de REFER DOIT traiter les informations comme une indication. Si la logique d'application du receveur de REFER ou l'action de l'utilisateur dépend de la présence de la caractéristique exprimée, l'étiquette de caractéristique peut être vérifiée. Par exemple, afin de le faire, le receveur du REFER peut envoyer directement une interrogation OPTIONS à la cible du REFER sur une connexion sûre (par exemple, mutuellement authentifiée et protégée en intégrité). Cela protège le receveur de REFER contre l'envoi d'étiquettes de caractéristiques incorrectes ou malveillantes.

 	6.	Remerciements

Les auteurs tiennent à remercier Jonathan Rosenberg de ses conseils utiles pour ce travail.

 	7.	Références normatives

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

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

[RFC3515]	R. Sparks, "Méthode Refer du protocole d'initialisation de session (SIP)", avril 2003. (MàJ par RFC8217)

[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

 	Adresse des auteurs

Orit Levin
Microsoft Corporation
One Microsoft Way
Redmond, WA  98052
USA
téléphone : 425-722-2225
mél : oritl@microsoft.com 

Alan Johnston
Avaya
St. Louis, MO 63124
USA
mél : ajohnston@ipstation.com 

 	Déclaration complète de droits de reproduction

Copyright (C) The IETF Trust (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 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.