Groupe de travail Réseau	M. Garcia-Martin, Ericsson
Request for Comments : 5365	G. Camarillo, Ericsson
Catégorie : Sur la voie de la normalisation	
Traduction Claude Brière de L'Isle	octobre 2008

Demandes MESSAGE à destinataires 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 spécifie un mécanisme qui permet à un client d’agent d’utilisateur (UAC, User Agent Client) SIP d’envoyer une demande SIP MESSAGE à un ensemble de destinations, en utilisant un service SIP URI-list (liste d’identifiants de ressources universels). L’UAC envoie une demande SIP MESSAGE qui inclut la charge utile avec la liste d’URI au service de MESSAGE URI-list, qui envoie une demande MESSAGE incluant la charge utile à chacun des URI inclus dans la liste.
Table des matières
1. Introduction	1
2. Terminologie	2
3. Vue d’ensemble	3
4. Document URI-List	3
5. Option-Tag	3
6. Procédures chez le client d’agent d’utilisateur	4
7. Procédures du service MESSAGE URI-List	4
7.1 Détermination du receveur prévu	5
7.2 Création d’une demande MESSAGE sortante	5
7.3 Corps composants dans la demande MESSAGE sortante	6
8. Procédures chez l’UAS	6
9. Exemples	7
10. Considérations sur la sécurité	9
11. Considérations relatives à l’IANA	9
12. Remerciements	9
13. Références	9
13.1 Références normatives	9
13.2 Références pour information	10
Adresse des auteurs	10
Déclaration complète de droits de reproduction	11

 	1.	Introduction

La [RFC3261] (SIP) est étendue par la [RFC3428] pour porter des messages instantanés dans les demandes MESSAGE. La messagerie fondée sur SIP, décrite dans la [RFC3428], ne fournit pas de mécanisme pour envoyer la même demande à plusieurs receveurs ou de répondre à tous les receveurs d’une demande MESSAGE SIP. Le présent mémoire traite de ces fonctions.

Une première exigence peut être exprimée par :

REQ-1 : Il doit être possible à un utilisateur d’envoyer une demande de message instantané à un groupe ad hoc, où les identités des receveurs sont portées dans le message lui-même.

Une possibilité de satisfaire cette exigence est d’établir une session de messages instantanés avec un serveur de conférence de messagerie instantanée, et d’échanger les messages, par exemple, en utilisant le protocole de relais de session de message (MSRP, Message Session Relay Protocol) [RFC4975]. Bien que cette option semble être raisonnable dans de nombreux cas, dans d’autres situations l’utilisateur envoyeur veut juste envoyer un petit message instantané en mode radiomessagerie à un groupe hoc sans se charger d’établir une session. Le présent document se concentre sur l’envoi d’un message instantané en mode radiomessagerie à un certain nombre de receveurs prévus.

Pour satisfaire l’exigence avec un message instantané en mode radiomessagerie, on permet que les demandes MESSAGE SIP portent des corps de liste de receveurs, c'est-à-dire, des listes d’URI dans des parties de corps dont la disposition de contenu [RFC2183] est "recipient-list", comme spécifié dans la [RFC5363]. Un service de liste d'URI SIP MESSAGE, qui est un service d’application spécialisé, reçoit la demande et envoie une demande MESSAGE incluant la charge utile reçue à chaque URI de la liste. Chacune de ces demandes MESSAGE contient une copie du corps inclus dans la demande MESSAGE originale.

Une seconde exigence vise la fonction "Reply-To-All" (répondre à tous)  :

REQ-2 : Il DOIT être possible au receveur d’un groupe de message instantané d’envoyer un message à tous les autres participants qui ont reçu le même message instantané de groupe (c'est-à-dire, Reply-To-All).

Pour satisfaire cette exigence, on produit un mécanisme par lequel le service de liste d'URI MESSAGE inclut aussi une liste d'URI dans les parties de corps dont la disposition de contenu [RFC2183] est "recipient-list-history", comme spécifié dans la [RFC5364]. Le corps "recipient-list-history" est envoyé avec la charge utile de message instantané dans chacun des messages instantanés envoyés aux receveurs.

Le client d’agent d’utilisateur (UAC, User Agent Client) qui envoie une demande MESSAGE à un service de liste d'URI MESSAGE doit être configuré avec l’URI SIP du service qui fournit cette fonction. La découverte et le provisionnement de cet URI à l’UAC sort du domaine d’application de ce document.

 	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	AOR (Address-of-Record) adresse d’enregistrement
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 :

Service de liste d'URI MESSAGE : service de liste d'URI spécialisé qui reçoit une demande MESSAGE avec une liste d'URI et envoie une demande MESSAGE similaire à chaque URI de la liste. Dans ce contexte, similaire indique que des champs d’en-tête SIP peuvent changer, mais le service de liste d'URI MESSAGE ne va pas changer la charge utile de message instantané. Les services de liste d'URI MESSAGE se comportent effectivement comme des agents d’utilisateur de bout en bout (B2BUA, Back-to-Back-User-Agent) spécialisés. Un serveur qui fournit des services de liste d'URI MESSAGE peut aussi offrir des services de liste d'URI pour d’autres méthodes, bien que cette fonction sorte du domaine d’application de ce document. Dans le présent document, on discute seulement des services de liste d'URI MESSAGE.

Demande MESSAGE entrante : demande MESSAGE SIP qu’un UAC crée et adresse à un service de liste d'URI MESSAGE. À côté de la charge utile régulière de message instantané, une demande MESSAGE entrante contient une liste d'URI.

Demande MESSAGE sortante :  demande MESSAGE SIP qu’un service de liste d'URI MESSAGE crée et adresse à une serveur d’agent d’utilisateur (UAS). Il contient la charge utile régulière de message instantané.

Receveur prévu : receveur final prévu de la demande à générer par le service de liste d'URI MESSAGE.

Reply-To-All : capacité du receveur prévu de recevoir une demande MESSAGE qui inclut la charge utile et la liste des receveurs, et compose et envoie une demande MESSAGE à l'envoyeur et au reste des receveurs. L’entité qui répond peut utiliser un service de liste d'URI MESSAGE si il en est un à sa disposition ou elle peut créer une séquence de demandes MESSAGE régulières d’un seul receveur à chaque AOR SIP.

 	3.	Vue d’ensemble

Un UAC crée une demande MESSAGE qui contient un corps multi-parties incluant une liste des URI (receveurs prévus) et un message instantané. La liste des URI est formatée en accord avec le format de document de liste de ressources spécifié dans la [RFC4826] et étendu avec les attributs définis dans la [RFC5364]. L’UAC envoie cette demande MESSAGE au service de liste d'URI MESSAGE. À réception de cette demande MESSAGE entrante, le service de liste d'URI MESSAGE crée une demande MESSAGE par receveur prévu (mentionnés dans la liste d'URI) et copie la charge utile de message instantané à chacun de ces MESSAGES. Le service de liste d'URI MESSAGE manipule aussi la liste de ressources XML conformément aux procédures indiquées dans la [RFC5364], et attache le résultat à chaque demande MESSAGE, avec la charge utile de message instantané. Ensuite le service de liste d'URI MESSAGE envoie chaque demande MESSAGE créée sortante au receveur concerné.

Le mécanisme de liste d’URI MESSAGE permet à un envoyeur de spécifier plusieurs cibles pour une demande MESSAGE en incluant un document XML de liste de ressources conformément à la [RFC4826] dans le corps de la demande MESSAGE étendue avec les attributs définis dans la [RFC5364]. Cette liste de ressources, dont la disposition de contenu  (Content-Disposition) [RFC2183] est "recipient-list", comme spécifié dans la [RFC5363], inclut les URI des cibles. Chaque URI cible peut aussi être marqué pour indiquer dans quel rôle le service de liste d'URI va placer la cible (par exemple, "to", "cc", ou "bcc") et si l’URI cible est supposé être anonymisé ou non, conformément aux procédures décrites dans la [RFC5364]. Quand le serveur de liste d’URI MESSAGE étend la demande MESSAGE à chaque receveur, il inclut (avec la charge utile de message instantané) une nouvelle liste d'URI (sur la base de celle reçue) dont le Content-Disposition [RFC2183] est "recipient-list-history", comme spécifié dans la [RFC5364]. Cette nouvelle liste d'URI inclut la liste des cibles non anonymes "to" et "cc", ce qui permet aux receveurs d’avoir connaissance des autres receveurs et de leur répondre.

 	4.	Document URI-List

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

Le format par défaut pour les corps "recipient-list" pour les services de liste d'URI MESSAGE est le document de liste de ressources spécifié dans la [RFC4826] étendu avec les attributs de contrôle de copie [RFC5364]. Les UAC et les services de liste d'URI MESSAGE qui traitent les corps "recipient-list" DOIVENT prendre en charge ces deux formats et PEUVENT prendre en charge d’autres 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 le receveur va obtenir la demande MESSAGE. De plus, les URI peuvent être étiquetés avec l’attribut "anonymize" pour empêcher que le serveur de liste d’URI MESSAGE divulgue l’URI de cible dans une liste d'URI.

De plus, la [RFC5364] définit un corps "recipient-list-history" qui contient la liste des receveurs prévus. La format par défaut pour les corps "recipient-list-history" pour les services de liste d'URI MESSAGE est aussi le document de liste de ressources spécifié dans la [RFC4826] étendu avec les attributs de contrôle de copie [RFC5364]. Les services de liste d'URI MESSAGE DOIVENT prendre en charge ces deux formats ; les UAS PEUVENT prendre en charge ces formats. Les serveurs et UAS de liste d’URI MESSAGE PEUVENT prendre en charge d’autres formats.

Le document de liste de ressources spécifié dans la [RFC4826] fournit un certain nombre de caractéristiques qui ne sont pas nécessaires au service de liste d'URI MESSAGE défini dans le présent document. Le service de liste d'URI MESSAGE a besoin de transférer une simple liste plate d’URI entre un UAC et le serveur de liste d’URI MESSAGE et entre le  serveur de liste d’URI MESSAGE et l’UAS. Le service n’a pas besoin de listes hiérarchiques ou de la capacité d’inclure des entrées par référence relative à l’URI racine du protocole d’accès de configuration XML (XCAP) [RFC4825]. Donc, le service de liste d'URI MESSAGE spécifié ici utilise seulement des documents de listes de ressources plates qui ne contiennent pas de références relatives.

 	5.	Étiquette d’option

Le présent document définit l’étiquette d’option "recipient-list-message" (message de liste de receveurs) à utiliser dans les champs d’en-tête SIP Require et Supported.

Cette étiquette d’option est utilisée pour s’assurer qu’un serveur peut traiter le corps "recipient-list" utilisé dans une demande MESSAGE. Elle fournit aussi un mécanisme pour découvrir les capacités du serveur dans les réponses aux demandes OPTIONS.

La Section 6 donne les procédures normatives pour l’utilisation de cette étiquette d’option.

 	6.	Procédures chez le client d’agent d’utilisateur

Un UAC qui veut créer une demande MESSAGE multi receveurs crée une demande MESSAGE qui DOIT être formatée en accord avec la [RFC3428] Section 4. L’UAC remplit l’URI de demande avec l’URI SIP ou SIPS du service de liste d'URI MESSAGE. En plus du corps régulier de message instantané, l’UAC ajoute un corps de liste de receveurs dont le type de disposition de contenu est "recipient-list", spécifié dans la [RFC5363].  Ce corps contient une liste d'URI avec les receveurs du MESSAGE. Les URI de cible dans ce corps PEUVENT aussi être étiquetés avec les attributs "copyControl" et "anonymize" spécifiés dans la [RFC5364]. L’UAC DOIT aussi inclure l’étiquette d’option "recipient-list-message", définie à la Section 5, dans un champ d'en-tête Require.

Les UAC qui génèrent des demandes MESSAGE qui portent des corps "recipient-list", comme décrit aux sections précédentes, DOIVENT inclure cette étiquette d’option dans un champ d'en-tête Require. Les UA qui sont capables de recevoir et traiter les MESSAGE avec un corps de "recipient-list", comme décrit dans les sections précédentes, DEVRAIENT inclure cette étiquette d’option dans un champ d'en-tête Supported quand ils répondent aux demandes OPTIONS.

Les demandes MESSAGE à plusieurs receveurs contiennent un corps multi parties qui contient le corps portant la liste et la charge utile réelle du message instantané. Dans certains cas, la demande MESSAGE peut contenir des corps autres que les corps de texte et de liste (par exemple, quand la demande est protégée avec S/MIME, comme suivant la [RFC3851]).

Normalement, le service de liste d'URI MESSAGE va copier tous les champs d’en-tête significatifs dans la demande MESSAGE sortante. Cependant, il peut y avoir des cas où l’UA SIP veut que le service de liste d'URI MESSAGE ajoute un champ d'en-tête particulier avec une valeur particulière, même si le champ d'en-tête n’était pas présent dans la demande MESSAGE envoyée par l’UAC. Dans ce cas, l’UAC PEUT utiliser le mécanisme "?" décrit au paragraphe 19.1.1 de la [RFC3261] pour coder les informations supplémentaires dans tout URI de la liste. Cependant, l’UAC NE DOIT PAS utiliser le hname spécial "body" (paragraphe 19.1.1 de la [RFC3261]) pour coder un corps, car le corps est présent dans la demande MESSAGE elle-même.

Voici un exemple d’URI qui utilise le mécanisme "?" :

sip:bob@exemple.com?Accept-Contact=*%3bmobility%3d%22mobile%22

Cet URI demande au service de liste d'URI MESSAGE d’ajouter le champ d'en-tête suivant à une demande MESSAGE à envoyer à bob@exemple.com :

Accept-Contact: *;mobility="mobile"

Le format du document de liste de ressources spécifié dans 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 liste d'URI MESSAGE multiples défini dans le présent document. Donc, quand on utilise le document de liste de ressources par défaut, les UA DEVRAIENT utiliser des listes plates (c'est-à-dire, des listes non hiérarchiques) et NE DEVRAIENT PAS utiliser d’éléments <entry-ref>.

 	7.	Procédures du service MESSAGE URI-List

À réception d’une demande MESSAGE contenant une liste d'URI, le service de liste d'URI MESSAGE répond à l’UAC avec une réponse 202 (Accepté).

Noter que le code d’état dans la réponse au MESSAGE ne fournit aucune information sur la réussite ou non de la livraison des MESSAGE générés par le service de liste d'URI aux URI de la liste. C'est-à-dire, une réponse 202 (Accepté) signifie que le service de liste d'URI MESSAGE a reçu le MESSAGE et qu’il va essayer d’envoyer un message similaire aux URI de la liste. Concevoir un mécanisme pour informer un client de l’état de livraison d’un message instantané sort du domaine d’application du présent document.

Comme le service de liste d'URI MESSAGE n’utilise pas de listes hiérarchiques qui incluent des entrées par référence à l’URI racine XCAP, un serveur de liste d'URI MESSAGE 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.

Si une demande MESSAGE contient un URI de demande contenant un URI qui utilise le mécanisme "?" (voir le paragraphe 19.1.1 de la [RFC3261]) et que cet URI contient le hname "body" spécial à inclure dans un corps supplémentaire, le serveur de liste d'URI MESSAGE PEUT éliminer le contenu du paramètre "body".

 	7.1	Détermination du receveur prévu
À réception d’une demande MESSAGE contenant une liste d'URI, un service de liste d'URI MESSAGE détermine la liste des receveurs prévus en inspectant la liste d'URI contenue dans le corps.

Le paragraphe 4.1 de la [RFC5363] discute des cas où des URI dupliqués se trouvent dans une liste d'URI. Afin d’éviter les demandes dupliquées, les services de liste d'URI MESSAGE DOIVENT prendre en compte les mesures spécifiées dans la [RFC5363] pour éviter d’envoyer des demandes dupliquées au même receveur.

 	7.2	Création d’une demande MESSAGE sortante
Comme le service de liste d'URI MESSAGE se comporte comme un UAC pour les demandes MESSAGE sortantes, pour chaque receveur prévu, le service de liste d'URI MESSAGE crée une nouvelle demande MESSAGE en accord avec les procédures décrites à la Section 4 de la [RFC3428]. De plus, le paragraphe 5.3 de la [RFC5363] donne des lignes directrices générales supplémentaires pour créer des demandes sortantes. Le présent document spécifie aussi les procédures suivantes :

o	Un service de liste d'URI MESSAGE DOIT inclure un champ d'en-tête From dont la valeur est la même que celle du champ d'en-tête From inclus dans la demande MESSAGE entrante, sous réserve des exigences de confidentialité (voir les [RFC3323] et [RFC3325]) exprimées dans la demande MESSAGE entrante.
Noter que ceci ne s’applique pas au paramètre "tag".
L’échec à copier le champ d'en-tête From de l'envoyeur résulte en des défaillances inacceptables de la sécurité et de la confidentialité. Noter aussi que cette exigence n’est pas contraire aux exigences que des services supplémentaires fonctionnent sur le même nœud physique. Précisément, un service de confidentialité (voir la [RFC3323]) peut être co-localisé avec le service de liste d'URI MESSAGE, auquel cas, le service de confidentialité a la préséance sur le service de liste d'URI MESSAGE.

o	Un service de liste d'URI MESSAGE DEVRAIT générer une nouvelle valeur de champ d'en-tête To réglé à l’URI du receveur prévu. Conformément aux procédures de la [RFC3261] paragraphe 8.1.1.1, cette valeur est aussi supposée être égale à l’URI de demande de la demande MESSAGE sortante.
Le service de liste d'URI MESSAGE se comporte comme un client d’agent d’utilisateur ; donc, le champ d'en-tête To devrait être rempli avec l’URI du receveur.

o	Un service de liste d'URI MESSAGE DEVRAIT créer une nouvelle valeur de champ d'en-tête Call-ID. Un champ d'en-tête Call-ID pourrait contenir des informations d’adressage que l'envoyeur veut garder confidentielles. Comme il n’est pas nécessaire de garder le même identifiant d’appel sur les deux côtés du service de liste d'URI MESSAGE, et comme le service de liste d'URI MESSAGE se comporte comme un client d’agent d’utilisateur, il est recommandé de créer une nouvelle valeur de champ d'en-tête Call-ID en accord avec les procédures régulières de SIP.

o	Si un champ d'en-tête P-Asserted-Identity était présent dans la demande MESSAGE entrante et si la demande a été reçue d’une source de confiance, comme spécifié dans la [RFC3325], et si le premier bond de la demande MESSAGE sortante est aussi de confiance, un service de liste d'URI MESSAGE DOIT inclure un champ d'en-tête P-Asserted-Identity dans la demande MESSAGE sortante avec la même valeur reçue. Cependant, si le premier bond de la demande MESSAGE sortante n’est pas de confiance et si la demande MESSAGE entrante incluait un champ d'en-tête Privacy avec une valeur différente de "aucune", le service de liste d'URI MESSAGE NE DOIT PAS inclure de champ d'en-tête P-Asserted-Identity dans la demande MESSAGE sortante.

o	Si un service de liste d'URI MESSAGE est capable d’affirmer l’identité d’un utilisateur (par exemple, en utilisant le schéma d’authentification par résumé de HTTP [RFC2617], S/MIME [RFC3851], etc.) et si le service met en œuvre un mécanisme lui permettant de transposer ce schéma d’authentification en un URI SIP ou SIPS de l’utilisateur, et sous réserve des exigences de confidentialité exprimées dans la demande MESSAGE entrante (voir la [RFC3323]) le service de liste d'URI MESSAGE PEUT insérer un en-tête P-Asserted-Identity avec la valeur de l’URI affirmé par l’utilisateur.

o	Si la demande MESSAGE entrante contenait un champ d'en-tête Authorization ou Proxy-Authorization dont le domaine est réglé au domaine du serveur de liste d'URI MESSAGE, alors le service de liste d'URI MESSAGE NE DEVRAIT PAS le copier dans la demande MESSAGE sortante ; autrement (c'est-à-dire, si le champ d'en-tête Authorization ou Proxy-Authorization d’une demande MESSAGE entrante contient un domaine différent) le service de liste d'URI MESSAGE DOIT copier la valeur des champs d'en-tête respectifs de la demande MESSAGE sortante.

o	Un service de liste d'URI MESSAGE DEVRAIT créer un compte séparé pour le champ d'en-tête CSeq [RFC3261] de la demande MESSAGE sortante.

o	Un service de liste d'URI MESSAGE DEVRAIT initialiser la valeur du champ d'en-tête Max-Forward de la demande MESSAGE sortante.

o	Un service de liste d'URI MESSAGE DOIT inclure sa propre valeur dans le champ d'en-tête Via.

 	7.3	Corps composants dans la demande MESSAGE sortante
Quand il crée le corps de chaque demande MESSAGE sortante, le service de liste d'URI MESSAGE conserve les corps pertinents de la demande MESSAGE entrante et les copie dans la demande MESSAGE sortante. Les lignes directrices suivantes constituent des exceptions au traitement général de corps :

o	Une demande MESSAGE reçue à un service de liste d'URI MESSAGE peut contenir un ou plusieurs corps de sécurité (par exemple, S/MIME, [RFC3851]) chiffrés avec la clé publique du service de liste d'URI MESSAGE. Ces corps sont réputés être lus par le service de liste d'URI plutôt que par le receveur de la demande MESSAGE sortante (qui ne va pas être capable de les déchiffrer). Donc, un service de liste d'URI MESSAGE NE DOIT PAS copier de corps de sécurité (comme un corps chiffré S/MIME de la [RFC3851]) adressé au service de liste d'URI MESSAGE à la demande MESSAGE sortante. Cela inclut les corps chiffrés avec la clé publique du service de liste d'URI.

o	La demande MESSAGE entrante contient normalement un corps "recipient-list" ou une référence, comme indiqué dans la [RFC5363] avec la liste réelle des receveurs. Si cette liste d'URI inclut des ressources étiquetées avec l’attribut "copyControl" réglé à une valeur de "to" ou "cc", le service de liste d'URI DEVRAIT inclure une liste d'URI dans chaque demande MESSAGE sortante. Cette liste DEVRAIT être formatée en accord avec le format de document de liste de ressources spécifié dans la [RFC4826] et l’extension "copyControl" spécifiée dans la [RFC5364]. Le service de liste d'URI MESSAGE DOIT suivre les procédures spécifiées dans la [RFC5364] à l’égard du traitement des attributs "anonymize", "count", et "copyControl".

o	Si le service de liste d'URI MESSAGE inclut une liste d'URI dans une demande MESSAGE sortante, il DOIT inclure un champ d'en-tête Content-Disposition conformément à la [RFC2183] avec la valeur réglée à "recipient-list-history" et un paramètre "handling" conformément à la [RFC3204] réglé à "optional".

o	Si un service de liste d'URI MESSAGE inclut une liste d'URI dans une demande MESSAGE sortante, il DEVRAIT utiliser S/MIME [RFC3851] pour chiffrer la liste d'URI avec la clé publique du receveur.

o	Le service de liste d'URI MESSAGE DEVRAIT copier tous les corps de message restants (par exemple, messages text, images, etc.) de la demande MESSAGE entrante à la demande MESSAGE sortante.

o	Si un seul corps est laissé, le service de liste d'URI MESSAGE DOIT supprimer l’enveloppe multipart/mixed de la demande MESSAGE sortante.

Le reste de la demande MESSAGE correspondant à un URI donné dans la liste d'URI DOIT être créé suivant les règles du paragraphe 19.1.5, "Formation des demandes à partir d’un URI", de la [RFC3261]. En particulier, le paragraphe 19.1.5 de la [RFC3261] déclare : "Une mise en œuvre DEVRAIT traiter la présence de tout en-tête ou partie de corps dans l’URI comme le désir de l’inclure dans le message, et choisir d’honorer la demande sur la base du composant".

SIP permet d’ajouter un paramètre "method" à un URI. Donc, il est légitime que l’attribut "uri" de l’élément <entry> dans la liste de ressources XML contienne un paramètre "method". Les services de liste d'URI MESSAGE DOIVENT générer seulement des demandes MESSAGE, sans considération du paramètre "method" que les URI dans la liste indiquent. Effectivement, les services de liste d'URI MESSAGE DOIVENT ignorer le paramètre "method" dans chaque URI présent dans la liste d'URI.

 	8.	Procédures chez l’UAS

Un UAS (dans cette spécification, aussi appelé UAS de receveur prévu) qui reçoit une demande MESSAGE provenant du service de liste d'URI MESSAGE se comporte comme spécifié à la Section 7 de la [RFC3428].

Si l’UAS prend en charge la présente spécification et si la demande MESSAGE contient un corps avec un champ d'en-tête Content-Disposition conformément à la [RFC2183] réglé à "recipient-list-history", alors l’UAS va être capable de déterminer l’adresse d’enregistrement SIP (AOR) des autres receveurs prévus de la demande MESSAGE. Cela permet à l’utilisateur de créer une demande de réponse (par exemple, MESSAGE, INVITE) à l'envoyeur et au reste des receveurs inclus dans la liste d'URI.

 	9.	Exemples

La Figure 1 montre un exemple de l’opération. Un UAC SIP producteur envoie une demande MESSAGE. Le service de liste d'URI MESSAGE répond avec une réponse 202 (Accepté) et envoie une demande MESSAGE à chaque receveur prévu.

   +----------+      +---------+      +--------+ +--------+ +--------+
   | UAC SIP  |      | Service |      |Receveur| |Receveur| |Receveur|
   |producteur|      | URI-list|      | prévu  | | prévu  | | prévu  |
   |          |      | MESSAGE |      |   1    | |   2    | |   n    |
   +----------+      +---------+      +--------+ +--------+ +--------+
       |                  |               |          |          |
       | F1 MESSAGE       |               |          |          |
       | ---------------->|               |          |          |
       | F2 202 Accepté   |               |          |          |
       |<---------------- |  F3 MESSAGE   |          |          |
       |                  | ------------->|          |          |
       |                  |  F4 MESSAGE   |          |          |
       |                  | ------------------------>|          |
       |                  |  F5 MESSAGE   |          |          |
       |                  | ----------------------------------->|
       |                  |  F6 200 OK    |          |          |
       |                  |<------------- |          |          |
       |                  |  F7 200 OK    |          |          |
       |                  |<------------------------ |          |
       |                  |  F8 200 OK    |          |          |
       |                  |<----------------------------------- |
       |                  |               |          |          |
       |                  |               |          |          |

Figure 1 : Exemple de fonctionnement

La demande MESSAGE F1 (montrée à la Figure 2) contient un corps multipart/mixed qui est composé de deux corps : un corps text/plain contenant la charge utile de message instantané et un corps application/resource-lists+xml contenant la liste des receveurs.

   MESSAGE sip:list-service.exemple.com SIP/2.0
   Via: SIP/2.0/TCP uac.exemple.com
       ;branch=z9hG4bKhjhs8ass83
   Max-Forwards: 70
   To: service de liste d'URI MESSAGE <sip:list-service.exemple.com>
   From: Alice <sip:alice@exemple.com>;tag=32331
   Call-ID: d432fa84b4c76e66710
   CSeq: 1 MESSAGE
   Require: recipient-list-message
   Content-Type: multipart/mixed;boundary="boundary1"
   Content-Length: 501

   --boundary1
   Content-Type: text/plain

   Salut le monde  !

   --boundary1
   Content-Type: application/resource-lists+xml
   Content-Disposition: recipient-list

   <?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@exemple.com" cp:copyControl="to" />
       <entry uri="sip:randy@exemple.net" cp:copyControl="to" cp:anonymize="true"/>
       <entry uri="sip:eddy@exemple.com" cp:copyControl="to" cp:anonymize="true"/>
       <entry uri="sip:joe@exemple.org" cp:copyControl="cc" />
       <entry uri="sip:carol@exemple.net" cp:copyControl="cc" cp:anonymize="true"/>
       <entry uri="sip:ted@exemple.net" cp:copyControl="bcc" />
       <entry uri="sip:andy@exemple.com" cp:copyControl="bcc" />
     </list>
   </resource-lists>
   --boundary1--

Figure 2 : Demande MESSAGE reçue au serveur de liste d’URI MESSAGE

Les demandes MESSAGE F3, F4, et F5 sont de nature similaire. Toutes ces demandes MESSAGE contiennent un corps multipart/mixed qui est composé de deux autre corps : un corps text/plain contenant la charge utile de message instantané et un corps application/resource-lists+xml contenant la liste des receveurs. À la différence du corps text/plain, les corps application/resource-lists+xml des demandes MESSAGE F3, F4, et F5 ne sont pas égaux au corps application/resource-lists+xml inclus dans la demande MESSAGE entrante F1. C’est parce que le service de liste d'URI a anonymisé ces URI étiquetés avec l’attribut "anonymize" et a supprimé les URI étiquetés avec un atrribut "bcc" de "copyControl" ; de plus, la disposition de contenu de ces corps est différente. La Figure 3 montre un exemple de la demande MESSAGE F3.

   MESSAGE sip:bill@exemple.com SIP/2.0
   Via: SIP/2.0/TCP list-service.exemple.com
       ;branch=z9hG4bKhjhs8as34sc
   Max-Forwards: 70
   To: <sip:bill@exemple.com>
   From: Alice <sip:alice@exemple.com>;tag=210342
   Call-ID: 39s02sdsl20d9sj2l
   CSeq: 1 MESSAGE
   Content-Type: multipart/mixed;boundary="boundary1"
   Content-Length: 501

   --boundary1
   Content-Type: text/plain

   Salut le monde !

   --boundary1
   Content-Type: application/resource-lists+xml
   Content-Disposition: recipient-list-history; handling=optional

   <?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@exemple.com" cp:copyControl="to" />
       <entry uri="sip:anonymous@anonymous.invalid" cp:copyControl="to" cp:count="2"/>
       <entry uri="sip:joe@exemple.org" cp:copyControl="cc" />
       <entry uri="sip:anonymous@anonymous.invalid" cp:copyControl="cc" cp:count="1"/>
     </list>
   </resource-lists>
   --boundary1--

Figure 3 : Demande MESSAGE envoyée par le serveur de liste d’URI MESSAGE

 	10.	Considérations sur la sécurité

La [RFC5363] discute des questions relatives aux services de liste d'URI SIP. Les mises en œuvre de services de liste d'URI MESSAGE SIP 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.

Si le contenu du message instantané doit rester confidentiel, le client d’agent d’utilisateur DEVRAIT utiliser S/MIME conformément à la [RFC3851] pour empêcher un tiers de voir ces informations. Dans ce cas, le client d’agent d'utilisateur DEVRAIT chiffrer le corps de message instantané avec une clé de chiffrement de contenu. Ensuite, pour chaque receveur de la liste, l’UAC DEVRAIT chiffrer la clé de chiffrement de contenu avec la clé publique du receveur, et l’attacher à la demande MESSAGE.

 	11.	Considérations relatives à l’IANA

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

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

Nom	Description	Référence	
recipient-list-message	Le corps contient une liste d’URI qui indique les receveurs de la demande SIP MESSAGE	[RFC5365]	

Tableau 1 : Enregistrement de l’étiquette d’option "recipient-list-message" dans SIP

 	12.	Remerciements

Duncan Mills a soutenu l’idée d’avoir 1 à n demandes MESSAGE. Ben Campbell, Paul Kyzivat, Cullen Jennings, Jonathan Rosenberg, Dean Willis, et Keith Drage ont fourni des commentaires utiles.

 	13.	Références
 	13.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.)

[RFC2617]	J. Franks et autres, "Authentification HTTP : Authentification d'accès de base et par résumé", juin 1999. (DS.)

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

[RFC3323]	J. Peterson, "Mécanisme de confidentialité pour le protocole d'initialisation de session (SIP)", novembre 2002.

[RFC3325]	C. Jennings, J. Peterson et M. Watson, "Extensions privées au protocole d'initialisation de session (SIP) pour l'assertion d'identité au sein de réseaux de confiance", novembre 2002. (Information ; MàJ par RFC8217)

[RFC3428]	B. Campbell et autres, "Extension de messagerie instantanée pour le protocole d'initialisation de session (SIP)", décembre  2002.

[RFC3851]	B. Ramsdell, "Spécification du message d'extensions de messagerie Internet multi-objets/sécurisé (S/MIME) version  3.1", juillet 2004. (Obsolète, voir RFC5751)

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

 	13.2	Références pour information

[RFC4825]	J. Rosenberg, "Protocole d'accès de configuration (XCAP) du langage de balisage extensible (XML)", mai 2007. (P.S.)

[RFC4975]	B. Campbell, R. Mahy, et C. Jennings, "Protocole de relais de session de message (MSRP)", septembre 2007. (P.S ; MàJ par RFC7977, RFC8873) 

 	Adresse des auteurs

Gonzalo Camarillo	Miguel A. Garcia-Martin	
Ericsson	Ericsson	
Hirsalantie 11	Via de los Poblados 13	
Jorvas  02420	Madrid  28033	
Finlande	Espagne	
mél : Gonzalo.Camarillo@ericsson.com	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.