Groupe de travail Réseau	G. Camarillo, Ericsson
Request for Comments : 5368	A. Niemi, Nokia
Catégorie : Sur la voie de la normalisation	H. Khartabil, Ericsson Australia
	M. Isomaki, Nokia
	M. Garcia-Martin, Ericsson
Traduction Claude Brière de L'Isle	octobre 2008

Référence à des ressources multiples dans le protocole d'initialisation de session (SIP)

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet sur la voie de la 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.

Résumé
Le présent document définit des extensions à la méthode SIP REFER afin qu’elle puisse être utilisée pour se référer à plusieurs ressources dans une seule demande. Ces extensions incluent l’utilisation de pointeurs sur des listes d’identifiants de ressource universels (URI, Uniform Resource Identifier) dans le champ d’en-tête Refer-To et dans l’étiquette d’option "multiple-refer" SIP.
Table des matières
1. Introduction	1
2. Terminologie	2
3. Vue d’ensemble du fonctionnement	2
4. Étiquette d’option SIP multiple-refer	2
5. Suppression de l’abonnement implicite de REFER	3
6. Format de URI-List	3
7. Comportement des producteurs de REFER SIP	4
8. Comportement des receveurs de REFER	4
9. Exemple	5
10. Considérations sur la sécurité	6
11. Considérations relatives à l’IANA	6
12. Références	7
12.1 Références normatives	7
12.2 Références pour information	7
Adresse des auteurs	7
Déclaration complète de droits de reproduction	8

 	1.	Introduction

La [RFC3261] (SIP) est étendue par la [RFC3515] avec une méthode REFER qui permet à un agent d'utilisateur (UA) de demander à un second UA d’envoyer une demande SIP à un tiers. Par exemple, si Alice est dans un appel avec Bob, et décide que Bob a besoin de parler à Carol, Alice peut donner pour instruction à son UA SIP d’envoyer une demande REFER à l’UA de Bob pour lui fournir les informations de contact SIP de Carol En supposant que Bob a donné sa permission, l’UA de Bob va tenter d’appeler Carol en utilisant ce contact. C'est-à-dire, il va envoyer une demande INVITE à ce contact.

Un certain nombre d’applications ont besoin de demander à ce second UA d’initier les transactions vers un ensemble de destinations. Par exemple, le modérateur d’une conférence peut vouloir que le serveur de conférence envoie des demandes BYE à un groupe de participants. Dans un autre exemple, le même modérateur peut vouloir que le serveur de conférence envoie un INVITE à un ensemble de nouveaux participants.

On définit une extension à la méthode REFER afin que les demandes REFER puissent être utilisées pour se référer à d’autres agents d’utilisateur (comme des serveurs de conférence) à plusieurs destinations. De plus, ce mécanisme utilise la  suppression de l’abonnement implicite à la méthode REFER spécifiée dans la [RFC4488].

 	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] et indiquent les niveaux d’exigence pour les mises en œuvre conformes.

Le présent document réutilise les termes suivants définis dans la [RFC3261] :
o	UA (User Agent) agent d’utilisateur
o	UAC (User Agent Client) client d’agent d’utilisateur
o	UAS (User Agent Server) serveur d’agent d’utilisateur

Le présent document définit les nouveaux termes suivants :

Producteur de REFER :  agent d'utilisateur qui produit une demande REFER.

Receveur du REFER : entité qui reçoit une demande REFER et transmet une demande SIP à un certain nombre de REFER cibles. Le receveur du REFER est normalement une entité du réseau, comme un serveur de liste d’URI, qui agit comme UAS pour les demandes REFER et comme UAC pour les autres demandes SIP.

REFER cible : UA du receveur final prévu d’une demande SIP générée par le receveur du REFER.

 	3.	Vue d’ensemble du fonctionnement

Le présent document décrit une application de services de liste d'URI [RFC5363] qui permet à un service de liste d'URI de recevoir une demande REFER SIP contenant une liste de cibles. Le service de liste d'URI invoque la méthode SIP demandée à chacune des cibles contenues dans la liste. Ce type de service de liste d'URI est appelé un receveur du REFER dans tout ce document.

Le présent document définit une extension à la méthode SIP REFER spécifiée dans la [RFC3515] qui permet à un UAC SIP d’inclure une liste d'URI comme spécifié dans la [RFC4826] de REFER cibles dans une demande REFER et de l’envoyer à un receveur du REFER. Le receveur du REFER crée une nouvelle demande SIP pour chaque entrée de la liste d'URI et l’envoie à chaque receveur du REFER.

La liste d'URI qui contient la liste des cibles est utilisée en conjonction avec la [RFC5364] pour permettre à l'envoyeur d’indiquer le rôle (par exemple, "to", "cc", ou anonyme) dans lequel le REFER cible est impliqué dans la signalisation.

On représente plusieurs cibles d’une demande REFER en utilisant une liste d'URI comme spécifié dans la [RFC4826]. Un producteur de REFER qui veut faire se référer un receveur du REFER à un ensemble de destinations crée une demande REFER SIP. L’en-tête Refer-To contient un pointeur sur une liste d'URI, qui est incluse dans une partie de corps, et une étiquette d’option dans le champ d'en-tête Require : "multiple-refer". Cette étiquette d’option indique l’exigence de prendre en charge la fonction décrite dans la présente spécification.

Quand le receveur du REFER reçoit une telle demande, il crée une nouvelle demande par REFER cible et les envoie, une pour chaque REFER cible.

Le présent document ne fournit aucun mécanisme pour que les producteurs de REFER trouvent des informations sur le résultat d’une demande REFER contenant plusieurs REFER cibles. De plus, il ne prend pas en charge le mécanisme d’abonnement implicite qui fait partie de la méthode SIP REFER. La façon dont les producteurs de REFER sont tenus informés des résultats d’un REFER est spécifique du service. Par exemple, un producteur de REFER qui envoie une demande REFER pour inviter un ensemble de participants à une conférence peut découvrir quels participants ont été bien introduits dans la conférence en s’abonnant au paquetage d'événements d’état de conférence spécifié dans la [RFC4575].

 	4.	Étiquette d’option SIP multiple-refer

On définit une nouvelle étiquette d’option SIP pour les champs d’en-tête Require et Supported  : "multiple-refer".

Un agent d'utilisateur qui inclut l’étiquette d’option "multiple-refer" dans un champ d'en-tête Supported indique sa conformité à la présente spécification.

Un agent d'utilisateur qui génère un REFER avec un pointeur sur une liste d'URI dans son champ d'en-tête Refer-To DOIT inclure l’étiquette d’option "multiple-refer" dans le champ d'en-tête Require du REFER.

 	5.	Suppression de l’abonnement implicite de REFER

Les demandes REFER avec un seul REFER cible établissent implicitement un abonnement à l’événement refer. Le producteur de REFER est informé du résultat de la transaction à l’égard du REFER cible par son abonnement implicite. Comme décrit dans la [RFC3515], les demandes NOTIFY envoyées suite à un abonnement implicite créé par une demande REFER contiennent un corps de type "message/sipfrag" [RFC3420], qui décrit l’état de la transaction initiée par le receveur du REFER.

Dans le cas d’un producteur de REFER qui génère un REFER avec plusieurs REFER cibles, le producteur de REFER est normalement déjà abonné à d’autres paquetages d’événement qui peuvent fournir les informations sur le résultat des transactions sur les REFER cibles. Par exemple, un modérateur qui donne pour instruction à un serveur de conférence d’envoyer une demande BYE à un ensemble de participants est généralement abonné au paquetage d'événements d’état de conférence pour la conférence. Les notifications de ce paquetage d'événements vont tenir le modérateur et le reste des abonnés informés de la liste actuelle des participants à la conférence.

La plupart des applications qui utilisent la technique de REFER multiples décrite dans le présent mémoire n’ont pas besoin de l’abonnement implicite. Par conséquent, un producteur de REFER SIP qui génère une demande REFER avec plusieurs REFER cibles DEVRAIT inclure l’étiquette d’option "norefersub" dans un champ d'en-tête Require et DEVRAIT inclure un champ d'en-tête Refer-Sub réglé à "faux" pour indiquer qu’aucune notification sur les demandes ne devrait être envoyée au producteur de REFER. Le receveur du REFER DEVRAIT respecter la suggestion et aussi inclure un champ d'en-tête Refer-Sub réglé à "faux" dans la réponse 200 (OK). L’étiquette d’option "norefersub" SIP et le champ d'en-tête Refer-Sub sont spécifiés dans la [RFC4488].

La [RFC4488] indique qu’une condition pour que le producteur de REFER inclue un en-tête Refer-Sub est que le producteur de REFER soit sûr que la demande REFER ne va pas fourcher.

Au moment de la rédaction du présent mémoire, il n’y a pas d’extension qui permette de rapporter l’état de plusieurs transactions sur l’abonnement implicite associé au dialogue REFER. C'est-à-dire que le motif de ce document est de recommander l’usage de l’étiquette d’option "norefersub". Si à l’avenir une telle extension est définie, les producteurs de REFER qui l’utilisent pourraient s’abstenir d’utiliser l’étiquette d’option "norefersub" et utiliser à la place la nouvelle extension.

 	6.	Format de URI-List

Comme décrit dans la [RFC5363], les spécifications de services de liste d'URI individuels doivent spécifier un format par défaut pour les corps "recipient-list" utilisés dans le service particulier.

Le format par défaut pour les corps "recipient-list" pour les producteurs de REFER et les receveurs de REFER est celui de la [RFC4826] étendu avec la [RFC5364]. Les receveurs de REFER qui traitent les corps de "recipient-list" DOIVENT prendre en charge ces deux formats. Les producteurs de REFER et les receveurs de REFER PEUVENT prendre en charge d’autre formats.

Comme décrit dans la [RFC5364], chaque URI peut être étiqueté avec un attribut "copyControl" réglé à "to", "cc", ou "bcc", pour indiquer le rôle dans lequel la cible va obtenir la demande SIP concernée. Cependant, selon la méthode SIP cible, un attribut "copyControl" manque de sens. Par exemple, alors que un attribut "copyControl" peut être appliqué à des demandes INVITE, il n’a pas de sens avec des demandes de mi-dialogue comme des demandes BYE.

En plus de l’attribut "copyControl", des URI peuvent être étiquetés avec l’attribut "anonymize" (aussi spécifié dans la [RFC5364]) pour empêcher que le receveur du REFER divulgue l’URI cible dans une liste d'URI.

De plus, la [RFC5364] définit un corps "recipient-list-history" qui contient la liste des cibles. Le format par défaut pour les corps "recipient-list-history" pour les services de conférence est aussi celui de la [RFC4826] étendu par la [RFC5364]. Les receveurs de REFER qui prennent en charge la présente spécification DOIVENT prendre en charge ces deux formats ; les REFER cibles PEUVENT prendre en charge ces formats. Les receveurs de REFER et les REFER cibles PEUVENT prendre en charge d’autres formats.

Néanmoins, la [RFC4826] donne des caractéristiques, comme des listes hiérarchiques et la capacité d’inclure des entrées par référence relative à l’URI racine du protocole d’accès à la configuration XML (XCAP) qui ne sont pas nécessaires pour le service de REFER multiples défini dans ce document.

La Figure 1 montre un exemple d’une liste plate qui suit le document de liste de ressources.

<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
           xmlns:cp="urn:ietf:params:xml:ns:copycontrol">

  <list>
    <entry uri="sip:bill@example.com" cp:copyControl="to"  />
    <entry uri="sip:joe@example.org" cp:copyControl="cc" />
    <entry uri="sip:ted@example.net" cp:copyControl="bcc" />
  </list>
</resource-lists>

Figure 1 : Liste d’URI

 	7.	Comportement des producteurs de REFER SIP

Comme indiqué dans les Sections 4 et 5, un producteur de REFER SIP qui crée une demande REFER avec plusieurs REFER cibles inclut des étiquettes d’option "multiple-refer" et "norefersub" dans le champ d'en-tête Require et, si approprié, un champ d'en-tête Refer-Sub réglé à "faux". Le producteur de REFER inclut l’ensemble de REFER cibles dans un corps "recipient-list" dont le type de disposition est "recipient-list", comme défini dans la [RFC5363]. Le corps de URI-list est décrit plus en détails à la Section 6.

Le champ d'en-tête Refer-To d’une demande REFER avec plusieurs REFER cibles DOIT contenir un pointeur (c'est-à-dire, un localisateur de ressource universel (URL, Uniform Resource Locator) Content-ID conformément à la [RFC2392]) qui pointe sur la partie de corps qui porte la liste d'URI. Le producteur de REFER NE DEVRAIT PAS inclure d’URI particulier plus d’une fois dans la liste d'URI.

La [RFC4826] donne des caractéristiques, comme des listes hiérarchiques et la capacité d’inclure des entrées par référence relative à l’URI racine XCAP. Cependant, ces caractéristiques ne sont pas nécessaires pour le service de REFER multiples défini dans le présent document. Donc, quand on utilise le document de liste de ressources par défaut, les producteurs de REFER SIP qui génèrent des demandes REFER avec plusieurs REFER cibles DEVRAIENT utiliser des listes plates (c'est-à-dire, pas des listes hiérarchiques) et NE DEVRAIENT PAS utiliser des éléments <entry-ref>.

 	8.	Comportement des receveurs de REFER

Le receveur du REFER suit les règles du paragraphe 2.4.2 de la [RFC3515] pour déterminer le code d’état de la réponse au REFER.

Le receveur du REFER NE DEVRAIT PAS créer un abonnement implicite, et DEVRAIT ajouter un champ d'en-tête Refer-Sub réglé à "faux" dans la réponse 200 OK.

La demande REFER entrante contient normalement un document ou référence URI-list avec la liste réelle des cibles. Si cette liste d'URI inclut des ressources étiquetées avec l’attribut "copyControl" réglé à une valeur de "to" ou "cc", et si la demande est appropriée pour le service, par exemple, elle n’est pas reçue à mi-dialogue, le receveur du REFER DEVRAIT inclure une liste d'URI dans chaque demande sortante. Cette liste DEVRAIT être formatée conformément à la [RFC4826] et la [RFC5364]. Le receveur du REFER DOIT suivre les procédures spécifiées dans la [RFC4826] à l’égard du traitement des attributs "anonymize", "count", et "copyControl".

La Section 4 de la [RFC5363] discute des cas où des URI dupliqués se trouvent dans une liste d'URI. Afin d’éviter des demandes dupliquées, les receveurs de REFER DOIVENT effectuer les actions spécifiées dans la [RFC5363] pour éviter d’envoyer des demandes dupliquées à la même cible.

Si le receveur du REFER inclut une liste d'URI dans une demande sortante, il DOIT inclure un champ d'en-tête Content-Disposition, spécifié dans la [RFC2183], dont la valeur est réglée à "recipient-list-history" et un paramètre "handling", spécifié dans la [RFC3204], réglé à "optional".

Comme le service de REFER multiples n’utilise pas de listes hiérarchiques ni de listes qui incluent des entrées par référence à l’URI racine XCAP, un receveur du REFER qui reçoit une liste d'URI avec plus d’informations que ce qui a été décrit à la Section 6 PEUT éliminer toutes les informations supplémentaires.

Le receveur du REFER suit les règles de la [RFC3515] pour générer les demandes nécessaires vers les REFER cibles, agissant comme si il avait reçu un REFER régulier (pas une liste d'URI) pour chaque URI de la liste d'URI.

 	9.	Exemple

La Figure 2 montre un exemple de flux où un producteur de REFER envoie une demande REFER multiple au concentrateur d’une conférence, qui agit comme receveur du REFER. Le receveur du REFER génère une demande BYE par REFER cible. Les détails de l’utilisation d’une demande REFER pour supprimer des participants d’une conférence sont spécifiés dans la [RFC4579].

   +----------+      +--------+    +--------+  +--------+  +--------+
   |Producteur|      |Receveur|    |Cible 1 |  |Cible 2 |  |Cible 3 |
   |  REFER   |      |  REFER |    | REFER  |  | REFER  |  | REFER  |
   |          |      | concen-|    |        |  |        |  |        |
   |  Carol   |      |trateur |    |  Bill  |  |  Joe   |  |  Ted   |
   +----------+      +--------+    +--------+  +--------+  +--------+
        | 1. REFER         |             |           |           |
        | ---------------->|             |           |           |
        | 2. 202 Accepté   |             |           |           |
        |<---------------- |   3. BYE    |           |           |
        |                  | ----------->|           |           |
        |                  |   4. BYE    |           |           |
        |                  | ----------------------->|           |
        |                  |   5. BYE    |           |           |
        |                  | ----------------------------------->|
        |                  |   6. 200 OK |           |           |
        |                  |<----------- |           |           |
        |                  |   7. 200 OK |           |           |
        |                  |<----------------------- |           |
        |                  |   8. 200 OK |           |           |
        |                  |<----------------------------------- |
        |                  |             |           |           |
        |                  |             |           |           |

Figure 2 : Exemple de flux d’une demande REFER contenant plusieurs REFER cibles

La demande REFER (1) contient un champ d'en-tête Refer-To qui inclut un pointeur sur le corps de message, qui porte une liste avec les URI des REFER cibles. Dans cet exemple, la liste d'URI ne contient pas l’extension d’attribut "copyControl".  Le champ d'en-tête Require de REFER porte les étiquettes d’option "multiple-refer" et "norefersub". L’URI de demande est réglé à l’URI d’agent d’utilisateur mondialement acheminable (GRUU, Globally Routable User Agent) [RFC5627] (comme garantie que la demande REFER ne va pas fourcher).
Le champ d'en-tête Refer-Sub est réglé à "faux" pour demander la suppression de l’abonnement implicite. La Figure 3 montre un exemple de cette demande REFER. Le document de liste de ressources contient la liste des URI de REFER cibles avec la méthode de la demande SIP que le receveur du REFER génère.

REFER sip:conf-123@example.com;gruu;opaque=hha9s8d-999a  SIP/2.0
Via: SIP/2.0/TCP client.chicago.example.com ;branch=z9hG4bKhjhs8ass83
Max-Forwards: 70
To: "Conference 123" <sip:conf-123@example.com>
From: Carol <sip:carol@chicago.example.com>;tag=32331
Call-ID: d432fa84b4c76e66710
CSeq: 2 REFER
Contact: <sip:carol@client.chicago.example.com>
Refer-To: <cid:cn35t8jf02@example.com>
Refer-Sub: false
Require: multiple-refer, norefersub
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Allow-Events: dialog
Accept: application/sdp, message/sipfrag
Content-Type: application/resource-lists+xml
Content-Disposition: recipient-list
Content-Length: 362
Content-ID: <cn35t8jf02@example.com>

<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <list>
    <entry uri="sip:bill@example.com?method=BYE" />
    <entry uri="sip:joe@example.org?method=BYE" />
    <entry uri="sip:ted@example.net?method=BYE" />
  </list>
</resource-lists>

Figure 3 : Demande REFER avec plusieurs REFER cibles

La Figure 4 montre un exemple de la demande BYE (3) que le receveur du REFER envoie au premier REFER cible.

BYE sip:bill@example.com SIP/2.0
Via: SIP/2.0/TCP conference.example.com ;branch=z9hG4bKhjhs8assmm
Max-Forwards: 70
From: "Conference 123" <sip:conf-123@example.com>;tag=88734
To: <sip:bill@example.com>;tag=29872
Call-ID: d432fa84b4c34098s812
CSeq: 34 BYE
Content-Length: 0

Figure 4 : Demande BYE

 	10.	Considérations sur la sécurité

La [RFC5363] discute les questions relatives aux services de liste d'URI SIP. Étant donné qu’un receveur du REFER qui accepte les demandes REFER avec plusieurs REFER cibles agit comme un service de liste d'URI, les mises en œuvre de ce type de serveur DOIVENT suivre les règles relatives à la sécurité de la [RFC5363]. Ces règles incluent des listes d’inclusion et l’authentification et autorisation obligatoires des clients.

De plus, les receveurs de REFER DEVRAIENT seulement accepter des demandes REFER dans le contexte d’une application que le receveur du REFER comprend (par exemple, une application de conférence). Cela implique que les receveurs de REFER NE DOIVENT PAS accepter des demandes REFER pour des méthodes qu’ils ne comprennent pas. L’idée derrière ces deux règles est que les receveurs de REFER ne soient pas utilisés comme des serveurs aveugles dont la seule fonction est ventiler des messages aléatoires qu’ils ne comprenent pas.

 	11.	Considérations relatives à l’IANA

Le présent document définit une nouvelle étiquette d’option SIP : "multiple-refer". Cette étiquette d’option a été enregistrée dans le registre des paramètres SIP.

La rangée suivante a été ajoutée à la section "Étiquettes d’option" du registre des paramètres SIP:

Nom	Description	Référence	
multiple-refer	Cette étiquette d’option indique la prise en charge des demandes REFER qui contiennent un document de liste de ressources décrivant plusieurs REFER cibles.	[RFC5368]	

Tableau 1 : Enregistrement de l’étiquette d’option "multiple-refer" dans SIP

 	12.	Références
 	12.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. (MàJ par RFC8174)

[RFC2183]	R. Troost, S. Dorner, K. Moore, éd., "Communication des informations de présentation dans les messages Internet : le champ d'en-tête Contenu-disposition", août 1997. (MàJ par RFC2184, RFC2231) (P.S.)

[RFC2392]	E. Levinson, "Localisateur de ressource uniforme d'identifiant de contenu et d'identifiant de message", août 1998. (P.S.)

[RFC3204]	E. Zimmerer et autres, "Types de support MIME pour objets ISUP et QSIG", décembre 2001. (MàJ par RFC3459) (P.S.)

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

[RFC3420]	R. Sparks, "message/sipfrag de type de support Internet", novembre 2002.

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

[RFC4488]	O. Levin, "Suppression de l'abonnement implicite de la méthode REFER du protocole d'initialisation de session (SIP)", mai  2006. (P.S.)

[RFC4826]	J. Rosenberg, "Formats du langage de balisage extensible (XML) pour représenter des listes de ressources", mai 2007. (P.S.)

[RFC5363]	G. Camarillo, A.B. Roach, "Cadre et considérations sur la sécurité pour les services URI-List du protocole d'initialisation de session (SIP)", octobre 2008. (P.S.)

[RFC5364]	M. Garcia-Martin, G. Camarillo, "Extension de format du langage de balisage extensible (XML) pour la représentation des attributs de contrôle de copie dans les listes de ressources", octobre 2008. (P.S.)

 	12.2	Références pour information

[RFC4525]	K. Zeilenga, "Extension Modification d'incrément du protocole léger d'accès à un répertoire (LDAP)", juin 2006. (Info.)

[RFC4579]	A. Johnston, O. Levin, "Commande d'appel du protocole d'initialisation de session (SIP) – Conférence pour agents d'utilisateur", août 2006. (BCP0119)

[RFC5627]	J. Rosenberg, "Obtention et utilisation des URI d'agent d'utilisateur mondialement acheminable (GRUU) dans le protocole d'initialisation de session (SIP)", octobre 2009. (P. S.)

 	Adresse des auteurs

Gonzalo Camarillo	Aki Niemi	Markus Isomaki	
Ericsson	Nokia	Nokia	
Hirsalantie 11	P.O. Box 321	P.O. Box 321	
Jorvas  02420	NOKIA GROUP, FIN 00045	NOKIA GROUP, FIN 00045	
Finland	Finland	Finland	
mél : Gonzalo.Camarillo@ericsson.com	mél : Aki.Niemi@nokia.com	mél : markus.isomaki@nokia.com	

Miguel A. Garcia-Martin	Hisham Khartabil	
Ericsson	Ericsson Australia	
Via de los Poblados 13	mél : hisham.khartabil@gmail.com	
Madrid  28033		
Spain		
mél : miguel.a.garcia@ericsson.com		

 	Déclaration complète de droits de reproduction
Copyright (C) The Internet Society (2008)

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, 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, le IETF TRUST 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 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.