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

Extension au format de langage de balisage extensible (XML) pour représenter les attributs de contrôle de copie dans les listes de ressources

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é
Dans certains types de communications multimédia, une demande du protocole d’initialisation de session (SIP, Session Initiation Protocol) est distribuée à un groupe d’agents d’utilisateurs (UA, User Agent) de SIP. L’envoyeur envoie une seule demande SIP à un serveur qui va ensuite distribuer la demande au groupe. Cette demande SIP contient une liste d’identifiants de ressource universels (URI, Uniform Resource Identifier) qui identifient les receveurs de la demande SIP. Cette liste d’URI est exprimée comme un document XML de liste de ressources. La présente spécification définit une extension XML au format de liste de ressources XML qui permet à l’envoyeur de la demande de qualifier un receveur avec un niveau de contrôle de copie similaire au niveau de contrôle de copie des systèmes de messagerie existants.
Table des matières
1. Introduction	1
2. Terminologie	2
3. Vue d’ensemble du fonctionnement	2
4. Extension au format de données de liste de ressources	4
5. Schéma XML	5
6. Exemples	6
7. Portage des listes d’URI dans SIP	6
8. Considérations sur la sécurité	7
9. Considérations relatives à l’IANA	8
9.1 Enregistrement du type de disposition	8
9.2 Enregistrement de l’espace de noms XML	8
9.3 Enregistrement du schéma XML	8
10. Remerciements	9
11. Références	9
11.1 Références normatives	9
11.2 Références pour information	9
Adresse des auteurs	10
Déclaration complète de droits de reproduction	10
 	1.	Introduction

La [RFC5363] décrit un cadre générique pour porter des listes d’identifiants de ressource universels (URI, Uniform Resource Identifier) dans les messages SIP [RFC3261]. Précisément, le document donne un cadre commun pour des mises en œuvre spécifiques de services de liste d'URI, comme des conférences initiées avec des demandes INVITE [RFC5366] ou des demandes MESSAGE multi receveurs [RFC5365].

La présence d’une demande SIP qui contient une collection de ressources est commune à tous les services de liste d'URI, normalement exprimée comme une liste de ressources XML [RFC4826]. Les demandes SIP qui portent des listes de ressources peuvent apparaître dans des demandes reçues par le serveur de liste d'URI, indiquant la liste des receveurs prévus, ou dans chacune des demandes que le serveur de liste d'URI envoie aux receveurs, indiquant la liste de receveurs de la même demande SIP.

Bien que la liste de ressources XML [RFC4826] fournisse un mécanisme puissant pour décrire une liste de ressources, il est besoin d’un attribut de contrôle de copie pour déterminer si une ressource reçoit une demande SIP comme receveur principal, une copie identique, ou une copie aveugle. C’est similaire aux systèmes de messagerie courants, où l'envoyeur peut catégoriser chaque receveur comme receveur "to", "cc" (copie carbone) ou "bcc" (blind carbon copy, copie identique aveugle).

Le présent document traite ce problème en fournissant une extension à la liste de ressources XML [RFC4826] qui permet à l'envoyeur de fournir un attribut de contrôle de copie qui étiquette chaque receveur comme receveur "to", "cc", ou "bcc". Cet attribut indique si le receveur reçoit un copie principale de la demande SIP, une copie identique, ou une copie aveugle.  De plus, on donne à l'envoyeur la capacité d’indiquer dans la liste d'URI que une ou plusieurs ressources devraient être anonymisées, afin que certains URI de receveurs ne soient pas divulgués aux autres receveurs. Ces URI sont remplacés par des URI anonymes.

Le reste du document est organisé comme suit : la Section 2 introduit la terminologie utilisée tout au long de la présente spécification. La Section 3 donne une vue d’ensemble du fonctionnement. La Section 4 définit formellement une extension aux listes d'URI. La définition du schéma XML est fournie dans la Section 5. La Section 6 montre des exemples des listes d'URI avec les extensions définies dans ce document. La Section 7 discute les implications du transport des listes d'URI dans les messages SIP.

 	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.

Service de liste d'URI : service d’application SIP qui reçoit une demande SIP contenant une liste d'URI et envoie une demande SIP similaire à chaque URI de la liste.

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

Contrôle de copie : attribut alloué par l'envoyeur à un URI dans une liste de ressources XML. Son objet est d’indiquer au receveur si ce qu’il obtient est une copie principale, identique, ou aveugle (bcc) de la demande SIP.

Liste des receveurs ou liste de receveurs de ressources XML : liste de ressources XML contenant la liste des receveurs prévus. L’envoyeur établit cette liste dans la demande SIP qu’il envoie au serveur de liste d'URI.

Liste d’historique des receveurs ou liste de ressources XML d’historique des receveurs : liste de ressources XML contenant la liste visible des receveurs (c'est-à-dire, ceux non anonymes non bcc). Le serveur de liste d'URI crée cette liste, sur la base de la liste des receveurs, et l’inclut dans chacune des demandes SIP qu’il envoie à chaque receveur.

 	3.	Vue d’ensemble du fonctionnement

La Figure 1 décrit une vue générale du fonctionnement d’un serveur de liste d'URI. Un client d’agent d’utilisateur (UAC, User Agent Client) SIP producteur envoie une demande SIP (F1) à un serveur de liste d'URI contenant une liste des receveurs. Le serveur de liste d'URI génère une demande SIP à chaque receveur, conformément à la méthode SIP spécifique. Chacune de ces demandes SIP contient une liste d’historique des receveurs qui indique la liste des receveurs visibles de la demande SIP.

 +----------+        +---------+        +--------+ +--------+ +--------+
 |UAC SIP   |        | Serveur |        |receveur| |receveur| |receveur|
 |producteur|        | de liste|        | prévu  | | prévu  | | prévu  |
 |          |        |  d’URI  |        |   1    | |   2    | |   3    |
 +----------+        +---------+        +--------+ +--------+ +--------+
       |                  |                 |          |          |
       | F1 demande SIP   |                 |          |          |
       |(liste receveurs) |                 |          |          |
       | ---------------->|                 |          |          |
       | F2 réponse 2xx   |                 |          |          |
       |<---------------- | F3 demande SIP  |          |          |
       |                  | (liste hist rcv)|          |          |
       |                  | --------------->|          |          |
       |                  | F4 demande SIP  |          |          |
       |                  | (liste hist rcv)|          |          |
       |                  | -------------------------->|          |
       |                  | F5 demande SIP  |          |          |
       |                  | (liste hist rcv)|          |          |
       |                  | ------------------------------------->|
       |                  |  F6 200 OK      |          |          |
       |                  |<--------------- |          |          |
       |                  |  F7 200 OK      |          |          |
       |                  |<-------------------------- |          |
       |                  |  F8 200 OK      |          |          |
       |                  |<------------------------------------- |
       |                  |                 |          |          |
       |                  |                 |          |          |
       |                  |                 |          |          |

Figure 1 : Exemple de fonctionnement

Le mécanisme de liste d’URI permet à un envoyeur de spécifier plusieurs cibles pour une demande SIP en incluant une liste de ressources XML [RFC4826] de receveurs dans le corps de la demande SIP. Cette liste des receveurs inclut les URI cibles de la demande SIP (les procédures réelles sont spécifiques de la méthode et sortent du domaine d’application du présent document). Chaque URI cible peut aussi être marqué avec un attribut de contrôle de copie pour indiquer le niveau de copie avec lequel le receveur reçoit la demande SIP. Ceci est réalisé par l'envoyeur qui qualifie chaque URI de la liste d'URI avec un attribut "copyControl". Les valeurs disponibles de l’attribut "copyControl" incluent "to", "cc", et "bcc" (analogue à la messagerie). Ceci est discuté plus en détail à la Section 4. Quand le serveur de liste d'URI étend la demande à chaque receveur, le serveur de liste d'URI inclut une liste de ressources XML d’historique des receveurs construite sur la liste des receveurs reçue de l'envoyeur. La liste de ressources XML d’historique des receveurs remplace la liste des receveurs dans les demandes SIP générées par le serveur de liste d'URI pour chaque receveur. Le serveur de liste d'URI copie de la liste des receveurs les cibles qui sont marquées avec le niveau de contrôle de copie "to" et "cc", et les colle dans la liste d’historique des receveurs. Le serveur de liste d'URI exclut explicitement de la liste d’historique des receveurs les URI marqués avec un contrôle de copie de "bcc", bien qu’il soit capable de préserver l’adresse d’un URI étiqueté "bcc" quand il confronte l’URI du receveur de la demande SIP (ceci est décrit à la Section 4). Quand un receveur reçoit la demande SIP contenant la liste de ressources XML d’historique des receveurs, il est capable de déterminer quels autres receveurs visibles vont obtenir une copie de la demande SIP, et si ils sont marqués avec le niveau de contrôle de copie "to" ou "cc". Plus tard, si nécessaire, le receveur peut générer une réponse à ces receveurs visibles.

En plus de l’attribut "copyControl" pour un URI dans une liste de ressources XML, on définit un second attribut booléen appelé "anonymize". L’envoyeur d’une demande SIP peut marquer un URI dans une liste de ressources XML de receveur avec l’attribut "anonymize" pour indiquer au serveur de liste d'URI que l’URI marqué avec cet attribut est à remplacer par un URI anonyme dans la liste de ressources XML d’historique des receveurs. Cela fait connaître aux receveurs d’une demande SIP le nombre de receveurs visibles supplémentaires dont les URI n’ont pas été divulgués.

Il y a des cas où l'envoyeur marque plusieurs URI avec l’attribut "anonymize". Le serveur de liste d'URI peut grouper les URI anonymisés dans un seul URI anonymisé au sein de son niveau de contrôle de copie, et fournir un compte du nombre d’URI anonymisés. Pour la prise en charge de ce scénario, on définit un nouvel attribut "count" d’un URI dans la liste de ressources XML d’historique des receveurs. Il est prévu que l’attribut "count" soit seulement utilisé avec des URI anonymes, bien que syntaxiquement il soit possible d’ajouter un attribut "count" à tout URI dans toute liste de ressources XML.

Initialement, on peut penser que l’attribut "anonymize" fait double emploi avec la valeur "bcc" de l’attribut "copyControl". Cependant, il y a des différences entre eux. Si l'envoyeur qualifie un URI avec un attribut "copyControl" de "bcc" dans la liste de ressources XML de receveurs, le serveur de liste d'URI va normalement supprimer cet URI de la liste de ressources XML d’historique des receveurs (sauf si le serveur de liste d'URI décide de préserver un URI marqué "bcc" quand cet URI est lui-même le receveur de la demande SIP). Les receveurs de la demande SIP ne vont pas remarquer qu’un ou plusieurs URI "bcc" ont aussi reçu la demande. Cependant, si l'envoyeur qualifie un URI avec l’attribut "anonymize" dans la liste de ressources XML des receveurs, le serveur de liste d'URI va remplacer l’URI par un URI anonyme dans la liste d’historique des receveurs. Les receveurs de la demande SIP vont remarquer qu’il y a eu un ou plusieurs receveurs supplémentaires de la même demande, mais leurs URI ne sont pas divulgués.

 	4.	Extension au format de données de liste de ressources

Le présent document définit une extension au format de données de liste de ressources XML [RFC4826] qui permet à l'envoyeur d’indiquer un attribut de contrôle de copie qui qualifie un receveur avec un niveau de contrôle de copie. On définit un nouvel attribut "copyControl" à l’élément <entry> du format de document de liste de ressources [RFC4826]. L’attribut "copyControl" a un sens similaire au type d’adresse de destination dans les systèmes de messagerie. Il peut prendre les valeurs "to", "cc", et "bcc". Une valeur de "to" de l’attribut "copyControl" indique que la ressource est considérée comme un receveur principal de la demande SIP. Une valeur de "cc" indique que la ressource reçoit une copie à l’identique de la demande SIP. Une valeur de "bcc" indique que la ressource reçoit une copie aveugle de la demande SIP (c'est-à-dire, cet URI n’est pas divulgué aux autres receveurs de la demande SIP). La valeur par défaut de "copyControl" est "bcc". C'est-à-dire, l’absence d’un attribut "copyControl" DOIT être traitée comme si le "copyControl" était réglé à "bcc".

Quand ils créent une liste d’historique des receveurs, les serveurs de liste d'URI utilisent les attributs de "copyControl"  "bcc" pour acheminer les demandes SIP. De plus, les serveurs de liste d'URI se comportent de façon similaire à celle des systèmes de messagerie [RFC2822] à l’égard du traitement des URI marqués avec un contrôle de copie de "bcc", parce qu’ils ont deux façons de traiter les URI marqués "bcc". Les serveurs de liste d'URI DOIVENT traiter les URI marqués "bcc" d’une des deux façons suivantes :

o	Les serveurs de liste d'URI DOIVENT supprimer tous les URI marqués avec un contrôle de copie "bcc" dans les listes d’historique des receveurs. Ce mécanisme permet aux serveurs de liste d'URI d’envoyer la même liste d’historique des receveurs à chaque receveur de la demande SIP. Cependant, les receveurs qui sont étiquetés de valeurs "bcc" ne sont pas explicitement informés de cela.

o	Les serveurs de liste d'URI DOIVENT préserver avec un contrôle de copie de "bcc" dans la liste d’historique des receveurs l’URI qui identifie le receveur (si il y en a un) et DOIVENT supprimer les URI restants marqués avec un contrôle de copie de "bcc". Par conséquent, chaque receveur reçoit une liste d’historique des receveurs différente. Cependant, les receveurs qui ont été marqués avec un contrôle de copie de "bcc" en sont explicitement informés.

Les mises en œuvre qui sont capables de recevoir des listes d’historique des receveurs doivent faire attention au contenu de la liste. Si l’URI du receveur n’est pas inclus dans la liste d’historique des receveurs ou si il est inclus mais étiqueté avec un contrôle de copie de "bcc", alors les mises en œuvre DEVRAIENT empêcher l’utilisateur de répondre à tous les receveurs de la demande SIP. Cela permettrait aux receveurs non aveugles de noter l’existence des receveurs aveugles de la demande SIP.

Un nouvel attribut "anonymize" peut être inclus dans un élément <entry> au format de document de liste de ressources [RFC4826]. Si il est réglé à la valeur "vrai", il donne l’indication au serveur de liste d'URI de ne pas divulguer l’URI lui-même dans une liste d'URI envoyée au receveur, mais plutôt d’anonymiser l’URI (c'est-à-dire, de le rendre bogué dans la liste de ressources XML d’historique des receveurs). Les serveurs de liste d'URI peuvent utiliser les URI étiquetés avec l’attribut "anonymize" pour acheminer les demandes SIP, mais DOIVENT les convertir en l’URI SIP "sip:anonymous@anonymous.invalid" dans les listes d’historique des receveurs. La valeur par défaut de l’attribut "anonymize" est "faux".

Il y a des cas où le serveur de liste d'URI rencontre la même entrée d’URI dupliquée dans une liste de ressources, où les entrées d’URI dupliquées sont étiquetées avec les mêmes valeurs ou des valeurs différentes de l’attribut "copyControl". Il n’y a pas d’usages raisonnables qui justifient de dupliquer des URI dans les listes de ressources ; donc, ceci est considéré comme une erreur. Les serveurs de liste d'URI ne devraient pas envoyer de copies dupliquées de la même demande SIP au même receveur prévu. Dans le cas où le serveur de liste d'URI rencontre la même entrée d’URI dupliquée dans une liste de ressources, il devrait envoyer au plus une seule copie de la demande à ce receveur prévu. Pour chaque ensemble d’entrées d’URI dupliquées, le serveur de liste d'URI DOIT choisir la plus forte valeur de préséance de l’attribut "copyControl" pour le même receveur prévu. L’ordre de préséance des valeurs de l’attribut "copyControl" est : "to", "cc", et "bcc". Une fois que le serveur de liste d'URI a choisi une valeur pour l’attribut "copyControl" d’un receveur prévu, le serveur de liste d'URI peut continuer de traiter la demande.

Le traitement des URI étiquetés avec un attribut "copyControl" régle à une valeur "bcc" comme plus forte préséance sur l’attribut "anonymize". Donc, si le "copyControl" d’un URI est réglé à "bcc", le serveur de liste d'URI DOIT supprimer cet URI de la liste d’historique des receveurs, et l’attribut "anonymize" va être ignoré. Donc, l’attribut "anonymize" n’est utile que pour les URI étiquetés avec un "copyControl" de "to" ou "cc".

Un nouvel attribut "count" peut être aussi inclus dans un élément <entry>du format de document de liste de ressources [RFC4826]. Il donne le nombre des URI égaux. Normalement, la liste des receveurs créée par les UAC ne va pas avoir d’entrées d’URI égales (ou dupliquées) donc, elle n’est pas supposée contenir d’URI étiquetés avec des attributs "count". Cependant, des listes d’historique des receveurs peuvent contenir des URI dupliqués anonymisés ; donc, il est supposé que les listes d’historique des receveurs vont contenir des attributs "count". La valeur par défaut de l’attribut "count" est "1".

Les attributs "copyControl", "anonymize", et "count" DEVRAIENT être inclus comme modificateurs de tout élément fils inclus dans l’élément <list> d’une liste de ressources (par exemple, attribut des éléments <entry> ou <external>).

La Section 5 décrit le format des attributs "copyControl", "anonymize" et "count". Les mises en œuvre conformes à la présente spécification DOIVENT prendre en charge ce shéma XML.

Les mises en œuvre qui reçoivent des listes d’historique des receveurs doivent faire attention au contenu de la liste. Si l’URI du receveur n’est pas inclus dans la liste d’historique des receveurs ou si il est inclus mais étiqueté avec un contrôle de copie de "bcc", elles DEVRAIENT alors empêcher l’utilisateur de répondre à tous les receveurs de la demande SIP. Cela permettrait aux receveurs non aveugles de remarquer l’existence des receveurs aveugles dans la demande SIP originale.

 	5.	Schéma XML

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:copycontrol"
    xmlns="urn:ietf:params:xml:ns:copycontrol"
    xmlns:rls="urn:ietf:params:xml:ns:resource-lists"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    elementFormDefault="qualified"
    attributeFormDefault="unqualified">

    <xs:annotation>
      <xs:documentation xml:lang="fr">
         Ajoute les attributs copyControl, anonymize, et count aux URI inclus dans une liste de ressources.
      </xs:documentation>
    </xs:annotation>

    <xs:import namespace="urn:ietf:params:xml:ns:resource-lists"
         schemaLocation="urn:ietf:params:xml:schema:resource-lists"/>

    <xs:attribute name="copyControl">
       <xs:simpleType>
          <xs:restriction base="xs:string">
             <xs:enumeration value="to"/>
             <xs:enumeration value="cc"/>
             <xs:enumeration value="bcc"/>
          </xs:restriction>
       </xs:simpleType>
    </xs:attribute>
   <xs:attribute name="anonymize" type="xs:boolean" default="false"/>
   <xs:attribute name="count" type="xs:nonNegativeInteger" default="1"/>

</xs:schema>

Figure 2 : Schéma XML de l’extension au format de liste de ressources

 	6.	Exemples

Cette section montre deux exemples de listes d'URI qui peuvent être incluses dans des demandes SIP. Le premier exemple de la Figure 3 montre une liste des receveurs que l’UAC envoie au serveur de liste d'URI. Cela correspond à une liste qui va être incluse dans le flux F2 de la Figure 1. La liste des receveurs contient une liste simple en accord avec le format de données de liste de ressource spécifié dans la [RFC4826]. Chaque ressource indique le contrôle de copie d’une ressource avec un attribut "copyControl". Certaines des ressources sont aussi marquées avec l’attribut "anonymize". Cela donne pour indication au service de liste d'URI de ne pas divulguer leurs URI dans une liste d’historique des receveurs. Les deux derniers éléments <entry> sont marqués avec un attribut "copyControl" de "bcc". Cela donne pour indication au serveur de liste d'URI de supprimer ces URI de la liste d’historique des receveurs.

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

Figure 3 : Liste des receveurs envoyée de l’UAC au serveur de liste d'URI

À réception d’une demande SIP contenant la liste des receveurs de la Figure 3, le serveur de liste d'URI crée une demande SIP à chaque URI de la liste des receveurs (donc, dans notre exemple, il crée 7 demandes SIP). Le serveur de liste d'URI traite la liste des receveurs et crée une liste d’historique des receveurs qui est incluse dans chaque demande SIP sortante. Le traitement est le suivant : le serveur de liste d'URI crée une nouvelle liste d’historique des receveurs, sur la base de la liste des receveurs, mais avec des changements. D’abord, il copie tous les URI (éléments <entry>) marqués avec les attributs "copyControl" de "to" ou "cc", qui ne contiennent pas un attribut "anonymize" (ou quand l’attribut "anonymize" est réglé à "false"). Ensuite tous les URI marqués avec un attribut "copyControl" réglé à "to" et l’attribut "anonymize" réglé à "true" sont remplacés par l’URI SIP anonyme "sip:anonymous@anonymous.invalid". Dans cette entrée, le serveur de liste d'URI ajoute aussi la valeur d’origine de l’attribut "copyControl" ("to" dans notre exemple) et il ajoute l’attribut "count" contenant le nombre d’entrées anonymes dans ce groupe ("2" dans notre exemple). Ensuite le serveur de liste d'URI fait la même opération sur les URI étiquetés avec l’attribut "copyControl" réglé à "cc" et l’attribut "anonymize" réglé à "true", ajoutant aussi l’attribut "count" qui contient le nombre d’attributs anonymes dans ce groupe ("1" dans l’exemple). Enfin, le serveur de liste d'URI supprime tous les URI marqués avec l’attribut "copyControl" de "bcc". La liste résultante d’historique des receveurs est montrée à la Figure 4.

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

Figure 4 : Liste d’historique de receveurs envoyée du serveur de liste d'URI à chaque receveur

 	7.	Portage des listes d’URI dans SIP

Un client d’agent d’utilisateur (UAC, User Agent Client) SIP qui compose une demande SIP peut inclure une liste d'URI avec les extensions spécifiées dans le présent document pour indiquer la liste des receveurs prévus. En faisant cela, comme spécifié dans la [RFC5363], l’UAC ajoute un champ d'en-tête Content-Disposition [RFC2183] réglé à la valeur "recipient-list". Normalement les UAC envoient ces corps "'recipient-list' aux services de liste d'URI (cela correspond au flux F1 dans la Figure 1). Un corps dont le type Content-Disposition est "recipient-list" contient une liste d'URI qui inclut les receveurs prévus de la demande SIP, ce qui dans le présent document est appelé une liste des receveurs. L’élément <entry> dans la liste d'URI PEUT aussi inclure des attributs "copyControl" et "anonymize", comme spécifié à la Section 4.

Pour être capable d’informer les receveurs prévus de qui d’autre reçoit une copie de la demande SIP, on définit un nouveau type de disposition de message à inclure dans un champ d'en-tête Content-Disposition [RFC2183] d’une demande SIP. La valeur de ce nouveau type de disposition est "recipient-list-history" et son objet est d’indiquer une liste de receveurs à qui une demande SIP a été envoyée, ce qui est appelé dans le présent document une liste d’historique des receveurs. Un corps dont le type Content-Disposition est "recipient-list-history" contient une liste d'URI avec les receveurs visibles (incluant les anonymisés) de la demande SIP. L’élément <entry> de la liste d'URI PEUT aussi inclure des attributs "copyControl" et "count", comme spécifié à la Section 4.

À l’envoi d’une demande SIP qui contient une liste d’historique des receveurs, si le receveur prévu ne prend pas en charge la présente spécification, la demande SIP ne devrait pas échouer. Afin de s’assurer de la bonne réception des demandes SIP qui incluent des corps "recipient-list-history", les agents d’utilisateur (comme les serveurs de liste d'URI) qui constuisent des demandes SIP avec le champ d'en-tête Content-Disposition réglé à "recipient-list-history" DEVRAIENT ajouter un paramètre "handling" [RFC3204] réglé à "optional". Autrement, la demande SIP pourrait échouer et n’être jamais reçue du receveur prévu.

Bien que "Traitement du corps de message dans le protocole d'intialisation de session (SIP)" [RFC5621] rende obligatoire la prise en charge des corps multi parties, des receveurs traditionnels peuvent ne pas les prendre en charge. Dans ce cas, si la demande envoyée par le relais au receveur a besoin de contenir un autre corps (par exemple, une demande MESSAGE portant un message dans son corps) le relais ne va pas être capable d’utiliser cette extension parce que le receveur ne serait pas capable de traiter un corps multi parties avec le corps original plus le corps "recipient-list-history".

 	8.	Considérations sur la sécurité

La [RFC5363] discute les questions relatives aux services de liste d'URI SIP. Les mises en œuvre de la présente spécification 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 obligatoire des clients.

Les clients d'agent d'utilisateur NE DEVRAIENT PAS traiter des demandes SIP contenant des services de liste d'URI à des parties non authentifiés et non de confiance. C’est pour éviter des attaques par interposition ou d’acquérir les listes d'URI pour effectuer des attaques de pourriels.

Les listes d'URI peuvent contenir des informations confidentielles, comme les URI SIP. Il n‘est donc pas souhaitable que ces listes d'URI soient connues des tiers. Des espions sont capables d’observer les listes d'URI contenues dans les demandes SIP sauf si le message SIP est envoyé sur un canal sécurisé en utilisant un des mécanismes disponibles dans SIP, comme la sécurité de la couche transport (TLS, Transport Layer Security) [RFC4346], ou sauf si le corps de liste d'URI est lui-même chiffré avec, par exemple, S/MIME [RFC3851]. Donc, il est RECOMMANDÉ que le corps de liste d'URI soit chiffré avec S/MIME [RFC3851] ou que la demande SIP soit chiffrée avec TLS [RFC4346] ou tout autre mécanisme de chiffrement convenable.

Noter que cette liste d'URI n’indique pas les participants réels à la session. Elle indique seulement les URI invités et qui pourraient accepter la demande. Elle n’affirme pas que ces parties existent réellement, qu’elles sont joignables à l’URI indiqué, ou qu’elles ont accepté l’invitation. Aucune incidence sur la facturation ne devrait être tirée de ces informations. Elles sont sujettes à l’usurpation en chargeant la liste avec un contenu falsifié.

Les producteurs de demande SIP utilisent l’attribut de contrôle de copie "bcc" décrit à la Section 4 pour faciliter l’envoi des demandes SIP aux receveurs sans révéler les URI d’un ou plusieurs des autres receveurs. Méconnaître le traitement de ce contrôle de copie "bcc" a des implications sur les informations confidentielles qui pourraient être révélées, ce qui pourrait éventuellement conduire à des problèmes de sécurité par la simple connaissance de l’existence d’un URI particulier. Par exemple, si on utilise la première méthode décrite à la Section 4, où les URI étiquetés "bcc" sont supprimés de la liste d’historique des receveurs, les receveurs aveugles n’ont aucune indication explicite qu’il leur a été envoyé une copie aveugle de la demande SIP, excepté que leur URI n’apparaît pas dans la liste d’historique des receveurs. À cause de cela, un des URI aveugles pourrait envoyer une réponse à tous les receveurs montrés et accidentellement révéler que le message est allé au receveur aveugle. Quand la seconde méthode de la Section 4 est utilisée, l’adresse du receveur aveugle apparaît dans la liste d’historique de receveurs d’une copie séparée de la liste. Si l’URI étiqueté "bcc" envoyé contient tous les URI étiquetés "bcc", tous les receveurs "bcc" vont être vus par chaque receveur "bcc". Même si un message séparé est envoyé à chaque receveur "bcc" avec seulement l’URI de l’individu, les mises en œuvre doivent quand même être prudentes en traitant les réponses au message selon la Section 4 afin de ne pas révéler accidentellement le receveur aveugle aux autres receveurs.

 	9.	Considérations relatives à l’IANA

L’IANA a fait des enregistrements conformément aux paragraphes suivants : un nouveau type de disposition, un nouvel espace de noms XML, et un nouveau schéma XML.

 	9.1	Enregistrement du type de disposition
La Section 7 définit une nouvelle valeur "recipient-list-history" du registre des valeurs de disposition de contenu de messagerie. Cette valeur a été enregistrée dans le registre IANA des valeurs de disposition de contenu de messagerie avec les données d’enregistrement suivantes :

Nom	Description	Référence
recipient-list-history	le corps contient une liste des URI qui indiquent les receveurs de la demande	[RFC5364]

Tableau 1 : Enregistrement de la valeur "recipient-list-history" de disposition de contenu de messagerie

 	9.2	Enregistrement de l’espace de noms XML
Ce paragraphe enregistre un nouvel espace de noms XML dans le registre XML de l’IANA, conformément aux lignes directrices de la [RFC3688].

URI : l’URI pour cet espace de noms est urn:ietf:params:xml:ns:copycontrol
Contact d’enregistrement : groupe de travail IETF SIPPING, (sipping@ietf.org),
	Miguel Garcia-Martin (miguel.a.garcia@ericsson.com).

XML :

DÉBUT 
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//FR"
 "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
 <html xmlns="http://www.w3.org/1999/xhtml">
 <head>
  <meta http-equiv="content-type"
    content="text/html;charset=iso-8859-1"/>
    <title>Espace de nom de contrôle de copie</title>
    </head>
    <body>
      <h1>Espace de noms pour l’extension d’attribut de contrôle de copie dans les listes de ressources</h1>
      <h2>urn:ietf:params:xml:ns:copycontrol</h2>
      <p>Voir <a href="http://www.rfc-editor.org/rfc/rfc5364.txt"> RFC5364</a>.</p>
    </body>
    </html>
FIN

 	9.3	Enregistrement du schéma XML
Ce paragraphe enregistre un nouveau schéma XML dans le registre XML de l’IANA selon les procédures de la [RFC3688].

URI : urn:ietf:params:xml:schema:copycontrol
Contact d’enregistrement : groupe de travail IETF SIPPING, (sipping@ietf.org),
	Miguel Garcia-Martin (miguel.a.garcia@ericsson.com).
Le XML pour ce schéma est le contenu de la t of Section 5.

 	10.	Remerciements

Merci à Dean Willis, Jari Urpalainen, Pekka Kuure, Atsushi Sato, Brian Rosen, Mary Barnes, James Polk, Brian E. Carpenter, et Chris Newman de leur relecture de ce document de leurs utiles commentairess.

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

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

[RFC3688]	M. Mealling, "Registre XML de l'IETF", BCP 81, janvier 2004.

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

[RFC4346]	T. Dierks et E. Rescorla, "Protocole de sécurité de la couche Transport (TLS) version 1.1", avril 2006. (Remplace RFC2246 ; Remplacée par RFC5246 ; MàJ par RFC4366, 4680, 4681, 5746, 6176, 7465, 7507, 7919)

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

 	11.2	Références pour information

[RFC2822]	P. Resnick, "Format de message Internet", avril 2001. (Remplace la RFC0822, STD 11, Remplacée par RFC5322)

[RFC5365]	M. Garcia-Martin, G. Camarillo, "Demandes MESSAGE à destinataires multiples dans le protocole d'initialisation de session (SIP)", octobre 2008. (P.S.)

[RFC5366]	G. Camarillo, A. Johnston, "Établissement de conférence en utilisant des listes contenues dans des demandes dans le protocole d'initialisation de session (SIP)", octobre 2008. (P.S.)

[RFC5621]	G. Camarillo, "Traitement du corps de message dans le protocole d'intialisation de session (SIP)", septembre 2009. (MàJ RFC3204, RFC3261, RFC3459) (P. S. ; MàJ par RFC8262))

 	Adresse des auteurs

Gonzalo Camarillo	Miguel A. Garcia-Martin	
Ericsson	Ericsson	
Hirsalantie 11	Via de los Poblados 13	
Jorvas  02420	Madrid  28033	
Finland	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.