Groupe de travail Réseau	G. Camarillo, Ericsson
Request for Comments : 5367	A.B. Roach, Tekelec
RFC mise à jour  : 3265	O. Levin, Microsoft Corporation
Catégorie : Sur la voie de la normalisation	
Traduction Claude Brière de L'Isle	octobre 2008

Abonnements aux listes de ressources contenues dans les demandes 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 spécifie un moyen de créer un abonnement à une liste de ressources dans SIP. C’est réalisé en incluant la liste des ressources dans le corps d’une demande SUBSCRIBE. Au lieu qu’un abonné envoie une demande SUBSCRIBE pour chaque ressource individuelle, l’abonné définit une liste de ressources, s’y abonne, et obtient des notifications des changements d’état des ressources en utilisant un seul dialogue SUBSCRIBE.
Table des matières
1. Introduction	1
2. Terminologie	1
3. Procédures du client d’agent d’utilisateur	2
3.1 Traitement de la réponse	2
3.2 Demandes SUBSCRIBE suivantes	2
4. Format du document URI-List	2
5. Comportement du serveur de liste de ressources	3
5.1 Demandes SUBSCRIBE suivantes	3
6. Fourniture d’un URI pour manipuler une liste de ressources	3
7. Exemple	3
8. Considérations sur la sécurité	4
9. Considérations relatives à l’IANA	4
9.1 Valeur du paramètre "Purpose" de List-Management 	4
9.2 Étiquette d’option recipient-list-subscribe	4
10. Remerciements	5
11. Références normatives	5
Adresse des auteurs	5
Déclaration complète de droits de reproduction	5

 	1.	Introduction

La [RFC4662] spécifie comment établir des abonnements à une liste homogène de ressources dans SIP (spécifié dans la [RFC3261]) et définit les procédures pour obtenir des notifications sur les changements de l’état des ressources associées. La création de liste sort du domaine d’application de  la [RFC4662].

Le présent document spécifie un moyen de créer une liste avec un ensemble de ressources et de s’y abonner en utilisant une seule demande SIP. Ceci est réalisé en incluant la liste de ressources (comme définie dans la [RFC5363]) dans le corps d’une demande SUBSCRIBE.

 	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.	Procédures du client d’agent d’utilisateur

Un client d’agent d’utilisateur (UAC, User Agent Client) qui veut créer une liste de ressources et s’y abonne en utilisant le mécanisme décrit dans ce document construit une demande SUBSCRIBE avec au moins un corps, dont la disposition est du type "recipient-list" (liste de receveurs) comme défini dans la [RFC5363], qui contient la liste d'URI. De plus, l’UAC DOIT inclure l’étiquette d’option "recipient-list-subscribe" (abonnement à la liste de receveurs) (qui est enregistrée par l’IANA à la Section 9) dans un champ d'en-tête Require. L’UAC DOIT construire le reste de la demande SUBSCRIBE en suivant les règles de la [RFC3265].

L’UAC DOIT prendre en charge le format "rlmi+xml" défini dans la [RFC4662] et le signaler en incluant "rlmi+xml" dans l’en-tête Accept. L’UAC PEUT prendre en charge des formats supplémentaires et les inclure dans le champ d'en-tête Accept de la demande SUBSCRIBE.

 	3.1	Traitement de la réponse
Le code d’état dans la réponse à la demande SUBSCRIBE ne fournit aucune information sur si le serveur de liste de ressources a ou non été capable de réussir à s’abonner aux URI dans la liste d'URI. L’UAC obtient cette information dans les notifications envoyées par le serveur.

 	3.2	Demandes SUBSCRIBE suivantes
Les paragraphes précédents ont spécifié comment inclure une liste d'URI dans une demande SUBSCRIBE initiale à un serveur de liste de ressources afin de s’abonner à) l’état d’un ensemble de ressources. Une fois que l'abonnement a été créé et qu’un dialogue entre l’UAC et le serveur de liste de ressources a été établi, l’UAC peut envoyer des demandes SUBSCRIBE suivantes pour, par exemple, étendre la durée de l'abonnement.

À ce point, il n’y a pas de signification associée aux corps de liste de ressource dans les demandes SUBSCRIBE suivantes (bien que de futures extensions puissent en définir une). Donc, les UAC NE DEVRAIENT PAS inclure des corps de liste de ressources dans les demandes SUBSCRIBE suivantes à un serveur de liste de ressources.

Noter qu’une différence entre une demande SUBSCRIBE initiale et les suivantes est que alors que la demande initiale est envoyée à l"URI public de la liste de ressources, les suivantes sont envoyées à l’URI fourni par le serveur quand le dialogue est établi. Donc, du point de vue de l’UAC, la ressource identifiée par l’URI précédent prend en charge les corps de liste de receveurs, tandis que la ressource identifiée par le dernier ne les prend pas en charge.

 	4.	Format du document URI-List

La [RFC5363] exige que chaque spécification de service de liste d'URI, comme le service d'abonnement défini ici, spécifie le format par défaut pour les corps de liste de receveur utilisés dans le service particulier.

Le format par défaut pour les corps de liste de receveur pour le service d'abonnement défini dans le présent document est le format de liste de ressource défini dans la [RFC4826]. Les agents d’utilisateur (UA, User Agent) qui génèrent des corps de liste de receveurs DOIVENT prendre en charge ce format et PEUVENT prendre en charge d’autres formats. Les serveurs de liste de ressources capables de traiter les corps de liste de receveurs DOIVENT prendre en charge ce format et PEUVENT prendre en charge d’autres formats.

Le document de liste de ressources du protocole d’accès à la configuration de langage de balisage extensible (XML, Extensible Markup Language) (XCAP, XML Configuration Access Protocol) donne des caractéristiques, comme les listes hiérarchiques et la capacité d’inclure des entrées par référence relative à l’URI racine XCAP, qui ne sont pas nécessaires dans le service d'abonnement défini ici, qui a seulement besoin de transférer une liste simple d’URI entre un UA et le serveur de liste de ressources. Donc, quand ils utilisent le document de liste de ressources par défaut, les UA DEVRAIENT utiliser des listes simples (c'est-à-dire, pas des listes hiérarchiques) et NE DEVRAIENT PAS utiliser d’éléments <entry-ref>. Un serveur de liste de ressources qui reçoit une liste d'URI avec plus d’informations que ce qui vient d’être décrit PEUT éliminer toutes les informations supplémentaires.

La Figure 1 montre un exemple d’une liste simple 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:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <list>
    <entry uri="sip:bill@example.com" />
    <entry uri="sip:joe@example.org" />
    <entry uri="sip:ted@example.net" />
  </list>
</resource-lists>

Figure 1 : Liste d’URI

 	5.	Comportement du serveur de liste de ressources

Les serveurs de liste de ressources qui sont capables de recevoir et traiter les demandes SUBSCRIBE avec un corps de liste de receveur DEVRAIENT inclure une étiquette d’option "recipient-list-subscribe" dans un champ d'en-tête Supported quand ils répondent aux demandes OPTIONS.

À réception d’une demande SUBSCRIBE avec une liste d'URI, un serveur de liste de ressources qui choisit d’accepter le format "rlmi+xml" DOIT se conformer à la [RFC4662] pour la création de l'abonnement et rapporter les changements des ressources dans le dialogue créé.

 	5.1	Demandes SUBSCRIBE suivantes
À ce point, il n’y a pas de signification associée aux corps de liste de ressources dans les demandes SUBSCRIBE suivantes (bien que de futures extensions puissent en définir une). Donc, un serveur de liste de ressources qui reçoit une demande SUBSCRIBE suivante avec un corps de liste de ressource, la rejette avec une réponse 415 (Type de support non pris en charge) conformément aux procédures SIP standard.

 	6.	Fourniture d’un URI pour manipuler une liste de ressources

Un UAC peut manipuler une liste de ressources chez un serveur de liste de ressources. Le serveur de liste de ressources PEUT fournir un URI pour manipuler la liste de ressources associée à un abonnement en utilisant le champ d'en-tête Call-Info dans la demande NOTIFY qui établit l'abonnement. Le paramètre "purpose" du champ d'en-tête Call-Info DOIT avoir une valeur de "list-management" (gestion de liste), qui est enregistrée par l’IANA à la Section 9. Voici un exemple de ce champ d'en-tête  :

Call-Info: <http://xcap.example.com/your-list.xml>
           ;purpose=list-management

La durée de vie d’une liste de ressource à manipuler par l’URI fourni par le serveur est liée à la durée de vie de l'abonnement. C'est-à-dire, la liste de ressources DEVRAIT être détruite quand l'abonnement expire ou est autrement terminé.

Le paragraphe 7.1 de la [RFC3265] ne mentionne pas le champ d'en-tête Call-Info dans le tableau des champs d’en-tête que peuvent porter les demandes NOTIFY. Le présent document met à jour ce tableau afin que le champ d'en-tête Call-Info puisse facultativement être inclus dans les demandes NOTIFY.

 	7.	Exemple

Voici un exemple d’une demande SUBSCRIBE, qui porte une liste d'URI dans son corps, envoyé par l’UAC à un serveur de liste de ressources.

SUBSCRIBE  sip:rls@example.com SIP/2.0
Via: SIP/2.0/TCP terminal.example.com;branch=z9hG4bKwYb6QREiCL
Max-Forwards: 70
To: RLS <sip:rls@example.com>
From: <sip:adam@example.com>;tag=ie4hbb8t
Call-ID: cdB34qLToC@terminal.example.com
CSeq: 1 SUBSCRIBE
Contact: <sip:terminal.example.com>
Event: presence
Expires: 7200
Require: recipient-list-subscribe
Supported: eventlist
Accept: application/cpim-pidf+xml
Accept: application/rlmi+xml
Accept: multipart/related
Accept: multipart/signed
Accept: multipart/encrypted
Content-Type: application/resource-lists+xml
Content-Disposition: recipient-list
Content-Length: 337

<?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" />
    <entry uri="sip:joe@example.org" />
    <entry uri="sip:ted@example.net" />
  </list>
</resource-lists>

Figure 2 : Demande SUBSCRIBE

 	8.	Considérations sur la sécurité

La section des considérations sur la sécurité de la [RFC4662] discute les questions de sécurité relatives aux serveurs de liste de ressources. Les serveurs de liste de ressources qui acceptent les listes d’URI contenues dans les demandes DOIVENT aussi suivre les lignes directrices sur la sécurité données dans la [RFC4662].

"Cadre et considérations de sécurité pour les services de liste d’URI du protocole d’initialisation de session (SIP)" [RFC5363] discute les questions relatives aux services de liste d'URI SIP. Étant donné qu’un serveur de liste de ressources qui envoie des demandes SUBSCRIBE à un ensemble d’utilisateurs agit comme un service de liste d'URI, les mises en œuvre de serveurs de liste de ressources qui traitent des listes d’URI contenues dans la demande DOIVENT suivre les règles relatives à la sécurité de la [RFC5363]. Ces règles incluent des listes d’inclusion et l’authentification et l’autorisation obligatoires des clients.

 	9.	Considérations relatives à l’IANA

Les paragraphes qui suivent décrivent l’enregistrement par l’IANA de la valeur "list-management" du paramètre "purpose" du champ d'en-tête Call-Info et de l’étiquette d’option SIP "recipient-list-subscribe".

 	9.1	Valeur de List-Management du paramètre "Purpose"
Le présent document définit la valeur "list-management" pour le paramètre "purpose" du champ d'en-tête Call-Info. Une référence à la présente RFC (entre crochets) a été ajoutée à l’entrée existante du paramètre Call-Info "purpose" dans le registre des  paramètres SIP, qui ressemble actuellement à :

Champ d’en-tête	Nom de paramètre	Valeurs pré définies	Référence
Call-Info	purpose	oui	[RFC3261]

 	9.2	Étiquette d’option recipient-list-subscribe
Le présent document définit l’étiquette d’option SIP "recipient-list-subscribe".

La rangée suivante a été ajoutée à la section "Option Tags" du registre des paramètres SIP :

Nom	Description	Référence	
recipient-list-subscribe	Cette étiquette d’option est utilisée pour s’assurer qu’un serveur peut traiter le corps de liste de receveurs utilisé dans une demande SUBSCRIBE 	[RFC5367]	

 	10.	Remerciements

Cullen Jennings et Jonathan Rosenberg ont fourni d’utiles commentaires sur le présent document.

 	11.	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)

[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) 

[RFC4662]	A. B. Roach et autres, "Extension de notification d'événement du protocole d'initialisation de session (SIP) pour les listes de ressources", août 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.)

 	Adresse des auteurs

Gonzalo Camarillo	Orit Levin	Adam Roach	
Ericsson	Microsoft Corporation	Tekelec	
Hirsalantie 11	One Microsoft Way	17210 Campbell Rd Ste 250	
Jorvas  02420	Redmond, WA  98052	Dallas, TX  75252	
Finland	USA	USA	
mél : Gonzalo.Camarillo@ericsson.com	mél : oritl@microsoft.com	mél : Adam.Roach@tekelec.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.