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

Paquetage d’événements Ajouts en cours 
du 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 le paquetage d’événements Ajouts en cours de SIP. Ce paquetage d’événements est utilisé par les relais SIP pour informer les agents d’utilisateur de l’état relatif au consentement des entrées à ajouter à une liste de ressources.
Table des matières
1. Introduction	1
2. Terminologie	2
3. Vue d’ensemble du fonctionnement	2
4. Définition du schéma XML	2
5. Définition du paquetage d’événements Ajouts en cours	3
5.1 Nom du paquetage d’événements	3
6. Notifications Partielles	5
6.1 Génération des notifications partielles	5
6.2 Traitement des notifications partielles	5
6.3 Schéma XML pour notifications partielles	6
6.4 Exemples	7
7. Considérations relatives à l’IANA	7
7.1 SIP Event Package Registration	7
7.2 URN Sub-Namespace Registration: consent-status	7
7.3 XML Schema Registration: consent-status	8
7.4 XML Schema Registration: resource-lists	8
7.5 MIME Type Registration: application/resource-lists-diff+xml	8
8. Considérations sur la sécurité	9
9. Remerciements	9
10. Références normatives	9
Adresse de l’auteur	10
Déclaration complète de droits de reproduction	10

 	1.	Introduction

Le cadre pour les communications fondées sur le consentement dans SIP [RFC5360] identifie le besoin pour les utilisateurs qui manipulent la logique de traduction à un relais (par exemple, en ajoutant un nouveau receveur) d’être informés de l’état relatif au consentement des receveurs d’une certaine traduction. C'est-à-dire, que l’utilisateur qui manipule la logique de traduction a besoin de savoir quels receveurs ont donné au relais la permission de leur envoyer des demandes SIP.

Le présent document définit un paquetage d'événements SIP par lequel les agents d'utilisateur peuvent s’abonner à l’état relatif au consentement des ressources qui sont ajoutées à une liste de ressources que définit une traduction.

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

Relais : tout serveur SIP, qu’il soit un mandataire, un agent d’utilisateur de bout en bout (B2BUA, Back-to-Back User Agent) ou un mélange des deux, qui reçoit une demande, traduit son URI de demande en un ou plusieurs URI de prochain bond (c'est-à-dire, des URI de receveur) et livre la demande à ces URI.

 	3.	Vue d’ensemble du fonctionnement

Un agent d'utilisateur s’abonne à un relais en utilisant le paquetage d'événements Ajouts en cours. Les demandes NOTIFY au sein de ce paquetage d'événements peuvent porter un document XML dans le format "application/resource-lists+xml" [RFC4826] ou dans le format "application/resource-lists-diff+xml", qui se fonde sur les opérations XML patch [RFC5261].

Un document dans le format "application/resource-lists+xml" fournit à l’agent d'utilisateur la liste complète des ressources ajoutées à une liste de ressources ainsi que l’état relatif au consentement de ces ressources. Un document dans le format "application/resource-lists-diff+xml" donne à l’agent d'utilisateur les changements à la liste de ressources ajoutées telles que rencontrées depuis la dernière notification envoyée à l’agent d'utilisateur.

 	4.	Définition du schéma XML

Cette section définit l’élément <consent-status>, qui fournit des informations relatives au consentement sur une ressource à ajouter à la logique de traduction d’un relais.

Un document d'état du consentement est un document XML qui DOIT être bien formé et DEVRAIT être valide. Les documents d'état du consentement DOIVENT être fondés sur XML 1.0 et DOIVENT être codés en utilisant UTF-8. La présente spécification utilise les espaces de noms XML pour identifier les documents d'état du consentement. L’URI d’espace de noms pour les éléments définis à cette fin est un URN, qui utilise l’identifiant d’espace de noms "ietf". Cet URN est :

urn:ietf:params:xml:ns:consent-status

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:consent-status"
  elementFormDefault="qualified"
  attributeFormDefault="unqualified"
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  xmlns:tns="urn:ietf:params:xml:ns:consent-status">
   <xs:element name="consent-status">
      <xs:simpleType>
        <xs:restriction base="xs:string">
          <xs:enumeration value="pending"/>
          <xs:enumeration value="waiting"/>
          <xs:enumeration value="error"/>
          <xs:enumeration value="denied"/>
          <xs:enumeration value="granted"/>
        </xs:restriction>
      </xs:simpleType>
   </xs:element>
</xs:schema>

L’élément <consent-status> peut prendre une des valeurs suivantes :

En cours : le relais a reçu une demande d'ajout d’une ressource à sa logique de traduction et va demander la permission de le faire.

Attente : le relais a demandé la permission d'ajouter la ressource à sa logique de traduction mais n’a pas encore eu de réponse de la ressource.

Erreur : le relais a demandé la permission d'ajouter la ressource à sa logique de traduction et a reçu une réponse d’erreur (par exemple, une réponse Erreur SIP à la demande MESSAGE envoyée pour demander la permission). C'est-à-dire, le document de permission demandant la permission n’a pas pu être livré à la ressource.

Refusé : la ressource a refusé au relais la permission d'ajouter la ressource à la logique de traduction du relais.

Accordé : la ressource a accordé au relais la permission d'ajouter la ressource à la logique de traduction du relais.

Le paragraphe 5.1.11 contient un exemple de document "application/resource-lists+xml" qui porte les informations d’état relatif au consentement en utilisant des éléments <consent-status>.

 	5.	Définition du paquetage d’événements Ajouts en cours

Cette section donne les détails de la définition d’un paquetage de notification d’événement SIP [RFC3261], comme spécifié par la [RFC3265]. La prise en charge de cette section (c'est-à-dire, la Section 5) est EXICÉE pour les mises en œuvre de la présente spécification. La prise en charge de la notification partielle est facultative, mais si un abonné signale la prise en charge de la notification, la Section 6 DOIT être mise en œuvre.

 	5.1	Nom du paquetage d’événements
Le nom de ce paquetage d'événements est "consent-pending-additions". Ce nom de paquetage est porté dans les en-têtes Event et Allow-Events, comme défini dans la [RFC3265].

 	5.1.1	Paramètres de paquetage d’événements
Ce paquetage ne définit aucun paramètre de paquetage d'événements.

 	5.1.2	Corps SUBSCRIBE
Un SUBSCRIBE pour des événements Ajouts en cours PEUT contenir un corps. Ce corps servirait au filtrage d'abonnement. Les documents de filtre ne sont pas spécifiés dans ce document et, au moment de sa rédaction, il est attendu qu’ils fassent l’objet d’une future activité de normalisation.

Un SUBSCRIBE pour les paquetages d'événements Ajouts en cours PEUT être envoyé sans corps. Cela implique que la politique de filtrage d’une politique de session par défaut a été demandée. La politique par défaut est que les notifications sont générées chaque fois qu’il y a un changement de l’état d’une ressource de la liste.

 	5.1.3	Durée d’abonnement
Le temps d’expiration par défaut d’un abonnement est d’une heure (3600 secondes).

 	5.1.4	Corps NOTIFY
Dans ce paquetage d'événements, le corps des notifications contient un document de liste de ressources. Le présent document décrit les ressources ajoutées comme receveurs à une opération de traduction. Tous les abonnés et notificateurs DOIVENT prendre en charge le format de données "application/resource-lists+xml" [RFC4826] et son extension pour porter les informations d’état relatif au consentement, qui est spécifiée à la Section 4. La demande SUBSCRIBE PEUT contenir un champ d'en-tête Accept. Si un tel champ d'en-tête n’est pas présent, il a une valeur par défaut de "application/resource-lists+xml". Si le champ d'en-tête est présent, il DOIT inclure "application/resource-lists+xml", et PEUT inclure tous autres types capables de représenter un état relatif au consentement.

De plus, tous les abonnés et notificateurs DEVRAIENT prendre en charge le format "application/resource-lists-diff+xml". La Section 6 discute de l’usage des paquetages d'événements Ajouts en cours avec ce format.

 	5.1.5	Traitement des demandes SUBSCRIBE par le notificateur
L’état des ressources à ajouter à la logique de traduction d’un relais peut révéler des informations sensibles. Donc, tous les abonnements DEVRAIENT être authentifiés et ensuite autorisés avant approbation. La politique d’autorisation est à la discrétion de l’administrateur.

 	5.1.6	Génération des demandes NOTIFY par le notificateur
Un notificateur pour les paquetages d'événements Ajouts en cours DEVRAIT inclure l’élément <consent-status>, qui est défini à la Section 4. L’élément <consent-status> DOIT être positionné comme une instance de l’élément <any> au sein de l’élément <entry>.

Les notifications DEVRAIENT être générées pour le paquetage Ajouts en cours chaque fois qu’il y a un changement dans l’état relatif au consentement d’une ressource. Quand une ressource passe à l’état erreur, refusé, ou accordé, et quand une demande NOTIFY est envoyée, la ressource est supprimée des notifications suivantes.

 	5.1.7	Traitement des demandes NOTIFY par l’abonné
Comme déclaré à la Section 3, un document dans le format "application/resource-lists+xml" fournit à l’abonné la liste complète des ressources ajoutées à une liste de ressources avec l’état relatif au consentement de ces ressources. À réception d’une demande NOTIFY avec un tel document, l’abonné DEVRAIT mettre à jour ses informations locales sur les ressources ajoutées à la liste de ressources avec les informations dans le document. Les demandes NOTIFY contiennent l’état complet. L’abonné n’a besoin d’effectuer aucun type d’agrégation d’informations. La Section 6 discute de l’utilisation des paquetages d'événements Ajouts en cours avec notification partielle.

 	5.1.8	Traitement des demandes fourchées
L’état d’une liste de ressources donnée est normalement traité par un serveur et mémorisé dans un répertoire. Donc, il y a généralement un seul endroit où réside l’état de la liste de ressources. Cela implique qu’un abonnement à ces informations est traité directement par un seul élément qui a accès à ce répertoire. Il n’y a donc pas un besoin pressant qu’un abonnement aux informations d’ajouts en cours fourche. Par suite, un abonné NE DOIT PAS créer plusieurs dialogues par suite d’une seule demande d’abonnement. Le traitement requis pour garantir qu’un seul dialogue soit établi est décrit au paragraphe 4.4.9 de la [RFC3265].

 	5.1.9	Taux des notifications
Pour des raisons de contrôle d’encombrement, il est important que le taux de notifications ne devienne pas excessif. Par suite, il est RECOMMANDÉ que le serveur ne génère pas de notifications pour un seul abonné à un taux supérieur à toutes les 5 secondes.

 	5.1.10	Agents d’état
Les agents d’état n’ont pas de rôle dans le traitement de ce paquetage.

 	5.1.11	Exemple
Voici un exemple d’un document "application/resource-lists+xml" qui porte les informations d’état relatif au consentement en utilisant des éléments <consent-status> :

<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
 xmlns:cs="urn:ietf:params:xml:ns:consent-status">
 <list>
  <entry uri="sip:bill@exemple.com">
   <display-name>Bill Doe</display-name>
   <cs:consent-status>pending</cs:consent-status>
  </entry>
 <entry uri="sip:joe@exemple.com">
  <display-name>Joe Smith</display-name>
  <cs:consent-status>pending</cs:consent-status>
  </entry>
  <entry uri="sip:nancy@exemple.com">
   <display-name>Nancy Gross</display-name>
  <cs:consent-status>granted</cs:consent-status>
  </entry>
 </list>
</resource-lists>

 	6.	Notifications Partielles

Les listes de ressources rapportées par ce paquetage d'événements peuvent contenir de nombreuses ressources. Quand le format "application/resource-lists+xml" est utilisé et qu’il y a un changement de l’état relatif au consentement d’une ressource, le serveur génère une notification avec la liste compète. Générer de grandes notifications pour rapporter de petits changements ne satisfait pas aux exigences d’efficacité de certains environnements contraints en bande passante. Le mécanisme de notification partielle spécifié dans cette section est une façon plus efficace de rapporter les changements de l’état des ressources.

Les abonnés signalent la prise en charge de la notification partielle en incluant le format "application/resource-lists-diff+xml" dans le champ d'en-tête Accept des demandes SUBSCRIBE qu’ils génèrent. Si un client qui s’abonne au paquetages d'événements Ajouts en cours génère un champ d'en-tête Accept qui inclut le type MIME "application/resource-lists-diff+xml", le serveur a l’option de retourner les documents dans ce format (au lieu du format "application/resource-lists+xml").

 	6.1	Génération des notifications partielles
Une fois qu’un abonnement est accepté et installé, le serveur DOIT livrer l’état complet dans sa première notification. Pour rapporter l’état complet, le serveur utilise le format normal des listes de ressources. Par conséquent, le serveur DOIT régler le champ d'en-tête Content-Type à la valeur "application/resource-lists+xml".

Afin de livrer une notification partielle, le serveur DOIT régler le champ d'en-tête Content-Type à la valeur "application/resource-lists-diff+xml". Quand le serveur génère une notification partielle, le serveur DEVRAIT seulement inclure les informations qui ont changé depuis la précédente notification. Il appartient à la politique locale du serveur de déterminer ce qui est considéré comme un changement de l’état précédent.

Le serveur DOIT construire la notification partielle selon la logique suivante : toutes les informations qui ont été ajoutées au document sont mentionnées dans des éléments <add>, toutes les informations qui ont été supprimées du document sont mentionnées dans des éléments <remove>, et toutes les informations qui ont changé sont mentionnés dans des éléments <replace>.

Le serveur NE DOIT PAS envoyer une nouvelle demande NOTIFY avec une notification partielle tant qu’il n’a pas reçu une réponse finale de l’abonné à la précédente ou que la précédente demande NOTIFY n’est pas arrivée en fin de temporisation.

Quand le serveur reçoit une demande SUBSCRIBE (rafraîchissement ou terminaison) dans l’abonnement associé, il DEVRAIT envoyer une demande NOTIFY contenant tout le document en utilisant le type de contenu "application/resource-lists+xml".

Si le serveur a utilisé un type de contenu autre que "application/resource-lists+xml" dans les notifications au sein le l’abonnement existant et change pour livrer une notification partielle, le serveur DOIT livrer un état complet en utilisant le type de contenu "application/resource-lists+xml" avant de générer sa première notification partielle.

 	6.2	Traitement des notifications partielles
Quand un abonné reçoit la première notification contenant l’état complet dans un corps MIME "application/resource-lists+xml", l’abonné DOIT mémoriser le document complet reçu comme sa copie locale.

Quand l’abonné reçoit une notification suivante, il DOIT modifier ses informations mémorisées en local selon la logique suivante :

o	Si la notification porte un document "application/resource-lists+xml", l’abonné DOIT remplacer sa copie locale du document par le document reçu dans la notification.

o	Si la notification porte un document "application/resource-lists-diff+xml", l’abonné DOIT appliquer à sa copie locale du document complet les changements indiqués dans le document "application/resource-lists-diff+xml" reçu.

Si un abonné rencontre une erreur de traitement lorsque il traite un document codé "application/resource-lists-diff+xml", il DEVRAIT renouveler son abonnement. Un abonné peut revenir au fonctionnement normal en n’incluant pas le format "application/resource-lists-diff+xml" dans une nouvelle demande SUBSCRIBE.

Si le serveur change le type de contenu utilisé dans les notifications au sein de l’abonnement existant, l’abonné DOIT éliminer toutes les informations reçues précédemment et traiter le nouveau contenu comme spécifié pour ce type de contenu.

 	6.3	Schéma XML pour notifications partielles
Voici le schéma XML pour le format de données "application/resource-lists-diff+xml". Le schéma "urn:ietf:params:xml:schema:xml-patch-ops" est défini dans la [RFC5261].

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

<!-- inclut les définitions de type patch-ops -->
      <xs:include
           schemaLocation="urn:ietf:params:xml:schema:patch-ops"/>

<!-- mises à jour partielles -->
   <xs:element name="resource-lists-diff">
    <xs:sequence minOccurs="0" maxOccurs="unbounded">
     <xs:choice>
      <xs:element name="add">
       <xs:complexType mixed="true">
        <xs:complexContent>
         <xs:extension base="add">
          <xs:anyAttribute processContents="lax"/>
         </xs:extension>
        </xs:complexContent>
       </xs:complexType>
      </xs:element>
      <xs:element name="remove">
       <xs:complexType>
        <xs:complexContent>
         <xs:extension base="remove">
          <xs:anyAttribute processContents="lax"/>
         </xs:extension>
        </xs:complexContent>
       </xs:complexType>
      </xs:element>
      <xs:element name="replace">
       <xs:complexType mixed="true">
        <xs:complexContent>
         <xs:extension base="replace">
          <xs:anyAttribute processContents="lax"/>
         </xs:extension>
        </xs:complexContent>
       </xs:complexType>
      </xs:element>
      <xs:any namespace="##other" processContents="lax"/>
     </xs:choice>
    </xs:sequence>
    <xs:anyAttribute processContents="lax"/>
   </xs:element>
  </xs:schema>

 	6.4	Exemples
Le paragraphe 5.1.11 contient un exemple de document "application/resource-lists+xml", qui porte l’état complet. Ce qui suit est un document de mise à jour partielle "application/resource-lists-diff+xml" :

<?xml version="1.0" encoding="UTF-8"?>
<resource-lists-diff xmlns="urn:ietf:params:xml:ns:resource-lists"
 xmlns:cs="urn:ietf:params:xml:ns:consent-status">

<replace
sel="*/list/entry[@uri='sip:bill@exemple.com']/cs:consent-status/text()"
   >granted</replace>

</resource-lists-diff>

Voici le document "application/resource-lists+xml" résultant après application de la mise à jour partielle :

<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
 xmlns:cs="urn:ietf:params:xml:ns:consent-status">
 <list>
  <entry uri="sip:bill@exemple.com">
   <display-name>Bill Doe</display-name>
   <cs:consent-status>granted</cs:consent-status>
  </entry>
  <entry uri="sip:joe@exemple.com">
   <display-name>Joe Smith</display-name>
   <cs:consent-status>pending</cs:consent-status>
  </entry>
  <entry uri="sip:nancy@exemple.com">
   <display-name>Nancy Gross</display-name>
   <cs:consent-status>granted</cs:consent-status>
  </entry>
 </list>
</resource-lists>

 	7.	Considérations relatives à l’IANA

Cinq points concernant l’IANA sont associés à la présente spécification.

 	7.1	Enregistrement de paquetage d’événement SIP
Cette spécification enregistre un paquetage d'événements SIP conformément aux procédures de la [RFC3265].

Nom de paquetage : consent-pending-additions
Type : paquetage
Contact : Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Spécification publiée : RFC 5362.

 	7.2	Enregistrement du sous espace d’URN : consent-status
Ce paragraphe enregistre un nouvel espace de noms XML conformément aux procédures de la [RFC3688].

URI : urn:ietf:params:xml:ns:consent-status
Contact d’enregistrement : groupe de travail IETF SIPPING, <sipping@ietf.org>,
	Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>

XML :

<?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 noms d’extension Ajouts en cours</title>
</head>
<body>
  <h1>Espace de noms pour l’extension Informations d’état relatif au consentement </h1>
  <h2>urn:ietf:params:xml:ns:consent-status</h2>
  <p>Voir <a href="http://www.rfc-editor.org/rfc/rfc5362.txt">RFC 5362
    </a>.</p>
 </body>
</html>

 	7.3	Enregistrement du schéma XML : consent-status
Ce paragraphe enregistre un schéma XML conformément aux procédures de la [RFC3688].

URI : urn:ietf:params:xml:schema:consent-status
Contact d’enregistrement : groupe de travail IETF SIPPING, <sipping@ietf.org>,
	Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Le XML pour ce schéma se trouve à la Section 4.

 	7.4	Enregistrement du schéma XML : resource-lists
Ce paragraphe enregistre un schéma XML conformément aux procédures de la [RFC3688]. Ce schéma XML est une extension du schéma XML (dont l’identifiant est resource-list) défini dans la [RFC4826]. L’IANA a ajouté une rangée dans le registre des schémas XML avec les valeurs suivantes :

Identifiant : resource-lists-diff
URI : urn:ietf:params:xml:schema:resource-lists-diff
Nom de ficgier : resource-lists-diff
Référence [RFC5362]
Contact d’enregistrement : groupe de travail IETF SIPPING, <sipping@ietf.org>,
	Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Le XML pour ce schéma se trouve au paragraphe 6.3.

 	7.5	Enregistrement de type MIME : application/resource-lists-diff+xml
Ce paragraphe enregistre le type MIME "application/resource-lists-diff+xml".

Nom du type de support MIME :  application
Nom de sous type MIME :  resource-lists-diff+xml
Paramètres obligatoires : aucun
Paramètres facultatifs : le même que le paramètre charset application/xml spécifié dans la [RFC3023].
Considérations de codage : les mêmes que application/xml spécifié dans la [RFC3023].
Considérations sur la sécurité : voir la Section 10 de la [RFC3023] et la Section 7 de la [RFC4826].
Considérations d’interopérabilité :  aucune
Spécification publiée : RFC 5362
Applications qui utilisent ce type de support : le présent type de document a été défini pour prendre en charge la notification partielle dans les abonnements aux listes de ressources.
Information supplémentaires :
Numéro magique : aucun
Extension de fichier : .rld
Code de type de fichier Macintosh :  "TEXT"
Adresse de messagerie pour des informations complémentaires :  Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Usage prévu : COMMUN
Auteur/contrôleur des changements : IETF

 	8.	Considérations sur la sécurité

Le "Cadre pour les communications fondées sur le consentement dans le protocole d’initialisation de session (SIP)" [RFC5360] discute les questions relatives à la sécurité relatives à la présente spécification.

Les abonnements aux paquetages d'événements Ajouts en cours peuvent révéler des informations sensibles. Pour cette raison, il est RECOMMANDÉ que les relais utilisent des moyens forts pour l’authentification et la confidentialité des informations. De plus, des attaquants peuvent tenter de modifier le contenu des notifications envoyées par un relais à ses abonnés. Par conséquent, il est RECOMMANDÉ que les relais utilisent un moyen fort pour la protection de l’intégrité des  informations.

Il est RECOMMANDÉ que les relais authentifient les abonnés en utilisant les mécanismes normaux d’authentification de SIP, tels que le résumé, comme défini dans la [RFC3261].

Le mécanisme utilisé pour porter les informations aux abonnés DEVRAIT assurer l’intégrité et la confidentialité des informations. Pour le faire, un mécanisme de chiffrement SIP de bout en bout, comme S/MIME, décrit dans la [RFC3261], DEVRAIT être utilisé.

Si un moyen fort de sécurité de bout en bout (tel que ci-dessus) n’est pas disponible, il est RECOMMANDÉ que la sécurité bond par bond fondée sur TLS et les URI SIPS, comme décrit dans la [RFC3261], soit utilisée.

 	9.	Remerciements

Jonathan Rosenberg a fourni des idées utiles sur ce document. Ben Campbell et Mary Barnes ont effectué une relecture serrée du document. Jari Urpalainen a aidé à améliorer le mécanisme de notifications partielles.

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

[RFC3023]	M. Murata, S. St.Laurent et D. Kohn, "Types de supports XML", janvier 2001. (Obsolète, voir RFC7303)

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

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

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

[RFC5261]	J. Urpalainen, "Cadre des opérations Patch du langage de balisage extensible (XML) utilisant les sélecteurs de langage de chemin XML (XPath)", septembre 2008. (P.S.)

[RFC5360]	J. Rosenberg et autres, "Cadre des communications fondées sur le consentement dans le protocole d'initialisation de session (SIP)", octobre 2008. (P.S. ; MàJ par RFC8217)

 	Adresse de l’auteur

Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas  02420
Finland
mél : Gonzalo.Camarillo@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.