Groupe de travail Réseau	E. Burger
Request for Comments : 5438	H. Khartabil, Ericsson Australia
Catégorie : Sur la voie de la normalisation	février 2009
Traduction Claude Brière de L'Isle	

Notification de disposition de message instantané (IMDN)

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.

Notice de droits de reproduction
Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document.

Résumé
La messagerie instantanée (IM, Instant Messaging) se réfère au transfert en temps réel de messages entre usagers. Le présent document fournit un mécanisme pour que les points d'extrémité puissent demander des notifications de disposition de message instantané (IMDN, Instant Message Disposition Notification) incluant les notifications de livraison, de traitement, et d'affichage, pour les messages instantanés en mode page.

Le format de données commun de présence et de messagerie instantanée (CPIM, Common Presence et Instant Messaging) spécifié dans la RFC 3862 est étendu par de nouveaux champs d'en-tête qui permettent aux points d'extrémité de demander des IMDN. Un nouveau format de message est aussi défini pour porter les IMDN.

Le présent document décrit aussi comment les entités SIP se comportent en utilisant cette extension.
Table des matières
1. Introduction	2
2. Conventions	2
3. Terminologie	2
4. Vue d'ensemble	3
5. Types de disposition	4
5.1 Livraison	4
5.2 Traitement	4
5.3 Affichage	4
6. Nouveaux champs d'en-tête CPIM	4
6.1 Espace de noms de champ d'en-tête CPIM	5
6.2 Disposition-Notification	5
6.3 Message-ID	5
6.5 IMDN-Record-Route	5
6.6 IMDN-Route	6
7. Comportement des points d'extrémité	6
7.1 Envoyeur d'IM	6
7.2 Receveur d'IM	7
8. Comportement d'intermédiaire	9
8.1 Construction des notifications de traitement	10
8.2 Construction des notifications de livraison	10
8.3 Agrégation des IMDN	11
9. Identification des messages	12
10. Syntaxe formelle des champs d'en-tête	12
11. Format d'IMDN	13
11.1 Structure d'une charge utile IMDN codée en XML	13
12. Transport des messages avec SIP	17
12.1 Comportement de point d'extrémité	17
12.2 Comportement d'intermédiaire	18
13. Transport des messages avec MSRP	19
14. Considérations sur la sécurité	19
14.1 Falsification	20
14.2 Confidentialité	21
14.3 IMDN comme service de livraison certifiée	21
15. Considérations relatives à l’IANA	21
15.1 Type MIME message/imdn+xml	21
15.2 Enregistrement XML	22
15.3 Enregistrement d'URN pour les paramètres d'en-tête IMDN	22
15.4 Notification Content-Disposition: 	22
16. Remerciements	22
17. Références	23
17.1 Références normatives	23
17.2 Références pour information	23
Adresse des auteurs	24

 	1.	Introduction

Dans de nombreux systèmes d'échange de messages d'utilisateur à utilisateur, les envoyeurs de messages souhaitent souvent savoir si le receveur humain a réellement reçu un message ou si le message a été affiché.

La messagerie électronique [RFC5321] offre une solution à ce besoin avec les notifications de disposition de message [RFC3798]. Après que le receveur a vu le message, son agent d'utilisateur de messagerie génère une notification de disposition de message (MDN, Message Disposition Notification). La MDN est un message qui suit le format prescrit par la [RFC3798]. Le format fixé assure qu'un automate peut traiter le message.

Le format commun de présence et de message instantané (CPIM, Common Presence and Instant Messaging) Message/CPIM [RFC3862], est un format de message utilisé pour générer des messages instantanés. Le protocole d'initialisation de session (SIP, Session Initiation Protocol) [RFC3261] peut porter des messages instantanés générés en utilisant message/CPIM dans les demandes SIP MESSAGE [RFC3428].

Le présent document étend le format de message Message/CPIM à peu près de la même façon que les notifications de disposition de message étendent la messagerie électronique. Cette extension permet aux envoyeurs de message instantané de demander, créer, et envoyer des notifications de disposition de message instantané (IMDN, Instant Message Disposition Notification). Ce mécanisme fonctionne pour le message instantané en mode page aussi bien que pour le mode session. Le présent document discute seulement le mode page. Le mode session fera l'objet d'un futur travail de standardisation.

La présente spécification définit trois catégories de types de disposition : "delivery" (livraison), "processing" (traitement), et "display" (affichage). Des types de disposition spécifiques fournissent des informations plus détaillées. Par exemple, la catégorie "delivery" inclut "delivered" (livré) pour indiquer la réussite de la livraison et "failed" (échec) pour indiquer l'échec de la livraison.

 	2.	Conventions

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

Le présent document se réfère de façon générique à l'envoyeur d'un message au masculin (il/lui/son) et au receveur du message au féminin (elle/sa). Cette convention est purement arbitraire et ne fait aucune hypothèse sur le genre de l'envoyeur ou receveur du message.

 	3.	Terminologie

IM (Instant Message) : message instantané généré en utilisant le format de message/CPIM.

IMDN (Instant Message Disposition Notification) : notification de disposition de message instantané généré en utilisant le format de message/CPIM qui porte un document XML IMDN.

Message : IM ou IMDN généré en utilisant le format message/CPIM.

Envoyeur IM : point d'extrémité (agent d'utilisateur) qui génère et envoie un IM. Aussi, le point d'extrémité demande des IMDN pour un IM. Assez souvent, l'envoyeur IM est le receveur IMDN. Cependant, ce n'est pas toujours le cas, car l'IMDN utilise l'en-tête From dans le message CPIM. Cette valeur est souvent l'adresse d’enregistrement (AOR, Address of Record) de l'envoyeur d'IM. Cette adresse peut en fait se résoudre en différents agents d'utilisateur.

Receveur d'IM : point d'extrémité (agent d'utilisateur) qui reçoit des IM. Le receveur d'IM, en tant que nœud qui va probablement restituer l'IM à l'utilisateur, génère et envoie les IMDN de livraison des IM, si c'est demandé par l'envoyeur d'IM et permis par le receveur d'IM.

Point d'extrémité : envoyeur d'IM ou receveur d'IM.

Intermédiaire : entité dans le réseau, le plus souvent un serveur d'application (y compris des serveurs de liste d'URI et de mémorisation-transmission) qui transmettent un IM à sa destination finale. Les intermédiaires peuvent aussi générer et envoyer le traitement des IMDN aux IM, si c'est demandé par l'envoyeur d'IM et permis par la politique.

Passerelle : intermédiaire qui traduit entre différents systèmes d'IM qui utilisent des protocoles différents.

Charge utile IMDN : document XML qui porte les informations de notification de disposition. Dans la présente spécification, c'est le type MIME "message/imdn+xml".

Type de disposition : la présente spécification définit trois catégories de types de disposition : "livraison", "traitement", et "affichage".

Message de protocole de transport : message SIP ou d'autre protocole qui contient un IM ou une IMDN.

 	4.	Vue d'ensemble

Le diagramme ci-dessous montre le flux de base du protocole. Un envoyeur d'IM crée un IM, ajoute des informations de demande d'IMDN que l'envoyeur d'IM est intéressé à recevoir, et envoie ensuite l'IM. À un certain moment, le receveur d'IM ou un intermédiaire détermine que l'utilisateur ou l'application a reçu, n'a pas reçu, affiché, ou autrement disposé de l'IM. Le mécanisme par lequel un receveur d'IM détermine que son utilisateur a lu un IM sort du domaine d'application de ce document. À ce point, le receveur d'IM ou l'intermédiaire génère automatiquement un message de notification à l'envoyeur d'IM. Ce message de notification est la notification de disposition de message instantané (IMDN, Instant Message Disposition Notification).

      +--------------+                        +--------------+
      | Envoyeur IM  |                        | Receveur IM  |
      |Receveur IMDN |                        | Envoyeur IMDN|
      +--------------+                        +--------------+
              |                                       |
              |         1. IM demandant IMDN          |
              |-------------------------------------->|
              |                                       |
              |         2. IMDN (disposition)         |
              |<--------------------------------------|
              |                                       |
              |                                       |

Flux de messages IMDN de base

Noter que le receveur d'une IMDN, peut dans certaines instances, ne pas être l'envoyeur d'IM.  Ceci est particulièrement vrai pour les IM en mode page où l'adresse d'enregistrement (AOR, Address of Record ) de l'envoyeur IM, qui est présente dans l'IM, se résout en une localisation ou agent d'utilisateur différent de celui d'où l'IM est originaire. Cela pourrait arriver, par exemple, si la résolution de l'AOR résulte en un fourchement de la demande en plusieurs agents d'utilisateur. Pour simplifier, le reste de ce document suppose que l'envoyeur d'IM et le receveur d'IMDN sont le même et donc se réfère aux deux comme envoyeur d'IM.

 	5.	Types de disposition

Il y a trois grandes catégories d'états de disposition, la livraison, le traitement, et l'affichage.

 	5.1	Livraison
Le type de notification livraison indique si l'IM a ou non été livrée au receveur d'IM. Le type de notification livraison peut avoir les états suivants :

o	"delivered" (livré) pour indiquer la réussite de la livraison.

o	"failed" (échec) pour indiquer l'échec de livraison.

o	"forbidden" (interdit) pour indiquer le refus de l'envoyeur d'IM de recevoir la IMDN demandée. Le receveur d'IM peut envoyer l'état "forbidden", mais généralement c'est un intermédiaire qui envoie le message, si on le configure à le faire. Par exemple, il est possible à l'administrateur d'interdire les IMDN.

o	"error" pour indiquer une erreur de détermination du sort d'un IM.

 	5.2	Traitement
Le type de notification "traitement" indique qu'un intermédiaire a traité un IM. Le type de notification "traitement" peut avoir les états suivants :

o	"processed" (traité) pour indiquer que l'intermédiaire a effectué sa tâche sur l'IM. C'est un état général de l'IM.

o	"stored" (mémorisé) pour indiquer que l'intermédiaire a mémorisé l'IM pour livraison ultérieure.

o	"forbidden" (interdit) pour indiquer le refus par l'envoyeur d'IM de recevoir la IMDN demandée. L'état "forbidden" est envoyé par un intermédiaire qui est configuré à le faire. Par exemple, l'administrateur a interdit les IMDN.

o	"error" pour indiquer une erreur de détermination du sort d'un IM.

 	5.3	Affichage
Le type de notification "affichage" indique si le receveur d'IM a ou non rendu l'IM à l'utilisateur. Le type de notification d'affichage peut avoir les états suivants :
o	"displayed" pour indiquer que l'IM a été rendu à l'utilisateur.
o	"forbidden" pour indiquer le refus par le receveur d'IM, que l'envoyeur d'IM reçoive la IMDN demandée.
o	"error" pour indiquer une erreur de détermination du sort d'un IM.

En plus de texte, certains IM peuvent contenir de l'audio, de la vidéo, et des images fixes. Donc, l'état "affiché" inclut le début du rendu du fichier audio ou vidéo à l'utilisateur.

Comme il n'y a pas d'accusé de réception positif de la part de l'utilisateur, on ne peut pas déterminer si l'utilisateur a bien lu l'IM. Donc, on ne peut pas utiliser le protocole décrit ici comme un service pour prouver que quelqu'un a réellement lu l'IM.

 	6.	Nouveaux champs d'en-tête CPIM

La présente spécification étend le format de données CPIM spécifié dans la [RFC3862]. Un nouvel espace de noms est créé ainsi qu'un certain nombre de nouveaux champs d'en-tête CPIM.

 	6.1	Espace de noms de champ d'en-tête CPIM
Conformément à CPIM [RFC3862], la présente spécification définit un nouvel espace de noms pour les champs d'en-tête d'extension à CPIM  définis dans les paragraphes qui suivent. L'espace de noms est : urn:ietf:params:imdn

Conformément aux exigences de CPIM [RFC3862], les nouveaux champs d'en-tête définis dans les paragraphes qui suivent sont précédés, dans les messages CPIM, d'un préfixe alloué à l'URN dans le champ d'en-tête NS  du message CPIM. Le reste de la présente spécification suppose toujours un champ d'en-tête NS comme celui-ci :

NS : imdn <urn:ietf:params:imdn>.

Bien sûr, les clients sont libres d'utiliser tout préfixe tandis que les serveurs et intermédiaires doivent accepter toute spécification de préfixe d'espace de noms légal.

 	6.2	Disposition-Notification
L'envoyeur d'IM DOIT inclure le champ d'en-tête Disposition-Notification pour indiquer le désir de recevoir des IMDN de la part du receveur d'IM pour cet IM spécifique. La Section 10 définit sa syntaxe.

 	6.3	Message-ID
L'envoyeur d'IM DOIT inclure le champ d'en-tête Message-ID dans l'IM pour lequel il souhaite recevoir une IMDN. Le Message-ID contient un identifiant de message unique au monde que l'envoyeur IM peut utiliser pour corréler les IMDN reçues. Parce que le Message-ID est utilisé par l'envoyeur pour corréler les IMDN avec leurs IM respectifs, le Message-ID DOIT être choisi de telle façon que :

o	Il y ait des chances minimales que deux Message-ID coïncident accidentellement durant la période de temps pendant laquelle une IMDN pourrait être reçue.

o	Il soit prohibitif pour un attaquant qui a vu un ou plusieurs Message-ID valides de générer des identifiants de message valides supplémentaires.

La première exigence est une exigence de correction pour s'assurer d'une correspondance correcte par l'envoyeur. La seconde exigence empêche des attaquants hors chemin de falsifier des IMDN. Afin de satisfaire ces deux exigences, il est RECOMMANDÉ que les identifiants de message soient générés en utilisant un générateur de nombres pseudo aléatoires cryptographiquement sûrs, et contienne au moins 64 bits d'aléa, réduisant donc les chances de réussite d'une attaque au hasard à n/2^64, où n est le nombre de messages valides en cours.

Quand l'envoyeur d'IM reçoit une IMDN, il peut comparer sa valeur à celle de l'élément <message-id> présent dans la charge utile de la IMDN. Les IMDN portent aussi ce champ d'en-tête. Noter que comme la IMDN est elle-même un IM, le Message-ID de la IMDN va être différent du Message-ID de l'IM original. La Section 10 définit sa syntaxe.

 	6.4	Original-To
Un intermédiaire PEUT insérer un champ d'en-tête Original-To dans l'IM. La valeur du champ Original-To DOIT être l'adresse du receveur d'IM. Le receveur d'IM utilise cet en-tête pour indiquer l'adresse originale de l'IM dans les IMDN. Le receveur d'IM fait cela en remplissant l'élément <original-receveur-uri> dans la IMDN. L'intermédiaire DOIT insérer cet en-tête si il change la valeur du champ d'en-tête CPIM To. Le champ d'en-tête NE DOIT PAS apparaître plus d'une fois dans un IM. L'intermédiaire NE DOIT PAS changer cette valeur de champ d'en-tête si il est déjà présent. La Section 10 définit sa syntaxe.

 	6.5	IMDN-Record-Route
Un intermédiaire PEUT insérer un champ d'en-tête IMDN-Record-Route dans l'IM. Cela permet à l'intermédiaire de recevoir et traiter la IMDN sur son chemin de retour à l'envoyeur d'IM. La valeur du champ d'en-tête IMDN-Record-Route DOIT être l'adresse de l'intermédiaire. Plusieurs champs d'en-tête IMDN-Record-Route peuvent apparaître dans un IM. La Section 10 définit sa syntaxe.

 	6.6	IMDN-Route
Le champ d'en-tête IMDN-Route fournit des informations d'acheminement en incluant une ou plusieurs adresses auxquelles acheminer la IMDN. Un intermédiaire qui a besoin que l'IMDN repasse à travers le même intermédiaire DOIT ajouter l'en-tête IMDN-Record-Route. Quand le receveur d'IM crée la IMDN correspondante, le receveur d'IM copie les en-têtes IMDN-Record-Route dans les champs d'en-tête IMDN-Route correspondants. La Section 10 définit sa syntaxe.

 	7.	Comportement des points d'extrémité
 	7.1	Envoyeur IM
 	7.1.1	Construction des messages instantanés
Un IM est construit en utilisant le format de message CPIM défini dans la [RFC3862].

 	7.1.1.1	Ajout d'un champ d'en-tête Message-ID
Si l'envoyeur d'IM demande la réception d'IMDN, il DOIT inclure un champ d'en-tête Message-ID. Ce champ d'en-tête permet à l'envoyeur d'IM de confronter toutes les IMDN à leurs IM correspondants. Voir au paragraphe 6.3 les exigences d'unicité de l'identifiant de message.

 	7.1.1.2	Ajout d'un champ d'en-tête DateTime
Certains appareils ne sont pas capables de conserver l'état sur de longues périodes. Par exemple, les appareils mobiles peuvent avoir des limites de mémoire ou de batterie. De telles limites signifient que ces appareils peuvent n'être pas capables, ou de ne pas pouvoir choisir de conserver les messages envoyés pour les besoins de corrélation des IMDN avec les IM envoyés. Pour utiliser la IMDN dans ce cas, on ajoute un horodatage à l'IM pour indiquer quand l'utilisateur a envoyé le message. La IMDN retourne cet horodatage pour permettre à l'utilisateur de corréler l'IM avec la IMDN au niveau humain. On utilise le champ d'en-tête DateTime CPIM à cette fin. Donc, si l'envoyeur IM voudrait une IMDN, l'envoyeur d'IM DOIT inclure le champ d'en-tête DateTime CPIM.

 	7.1.1.3	Ajout d'un champ d'en-tête Disposition-Notification
Le champ Disposition-Notification porte le type de notification de disposition demandé par l'envoyeur d'IM. Il y a trois types de notification de disposition : livraison, traitement, et affichage. La notification de livraison est subdivisée en les notifications d'échec et de succès de livraison. Un envoyeur d'IM demande une notification d'échec de livraison en incluant un champ d'en-tête Disposition-Notification avec la valeur "negative-delivery". De même, une notification de succès est demandée en incluant un champ d'en-tête Disposition-Notification de valeur "positive-delivery". L'envoyeur d'IM peut demander les deux types de notifications de livraison pour le même IM.

L'envoyeur d'IM peut demander une notification de traitement en incluant un champ d'en-tête Disposition-Notification de valeur "processing".

L'envoyeur d'IM peut aussi demander une notification d'affichage. L'envoyeur d'IM DOIT inclure un champ d'en-tête Disposition-Notification avec la valeur "display" pour demander une IMDN d'affichage.

L'absence de ce champ d'en-tête ou la présence du champ d'en-tête avec une valeur vide indique que l'envoyeur d'IM ne demande aucune IMDN. Les valeurs de champ d'en-tête Disposition-Notification sont séparées par des virgules. L'envoyeur d'IM PEUT demander plus d'un type de IMDN pour un seul IM.

De futures extensions pourront définir d'autres notifications de disposition non définies dans le présent document.

La Section 10 décrit la syntaxe formelle pour le champ d'en-tête Disposition-Notification. Voici un exemple de corps CPIM d'un IM où l'envoyeur d'IM demande ds notifications positives et négatives de livraison, mais pas de notification d'affichage ni de notification de traitement :

From: Alice <im:alice@exemple.com>
To: Bob <im:bob@exemple.com>
NS: imdn <urn:ietf:params:imdn>
imdn.Message-ID: 34jk324j
DateTime: 2006-04-04T12:16:49-05:00
imdn.Disposition-Notification: positive-delivery, negative-delivery
Content-type: text/plain
Content-length: 12

Salut tout le monde

 	7.1.2	Confrontation des IM avec les IMDN
Un envoyeur d'IM fait correspondre une IMDN à un IM en confrontant la valeur du champ d'en-tête Message-ID dans l'IM à la valeur de l'élément <message-id> dans le corps de la IMDN. Si l'IM a été livré à plusieurs receveurs, l'envoyeur d'IM utilise l'élément <receveur-uri> et l'élément <original-receveur-uri> dans le corps XML de la IMDN qu'il a reçu pour déterminer si l'IM a été envoyé à plusieurs receveurs et pour identifier le receveur d'IM qui a envoyé la IMDN.

Un envoyeur IM peut déterminer qu'une IMDN est une notification de disposition en notant si le Content-Disposition dans la IMDN est "notification". Cela ne signifie pas que l'envoyeur d'IM DOIT comprendre l'en-tête MIME Content-Disposition dans les messages CPIM.

 	7.1.3	Conservation de l'état
La présente spécification n'exige pas que l'envoyeur d'IM conserve l'état pour un IM envoyé.

Une fois qu'un envoyeur d'IM envoie un IM contenant une demande d'IMDN, il PEUT préserver le contexte d'IM (principalement le Message-ID) d'autres informations identifiables d'utilisateur comme le sujet ou le contenu de l'IM, et la date et l'heure de son envoi. Sans préservation du contexte de l'IM, l'envoyeur d'IM ne sera pas capable de corréler la IMDN avec l'IM envoyé. L'envoyeur d'IM peut trouver impossible de préserver l'état d'IM si il a des ressources limitées ou n'a pas de mémoire non volatile et perd ensuite l'alimentation.

Il y a cependant le concept d'une boîte des "éléments envoyés" dans une application qui mémorise les IM envoyés. Cette boîte des "éléments envoyés" a les informations nécessaires et peut avoir une interface d'utilisateur factice qui indique l'état d'un IM envoyé. Un unique Message-ID pour cela se révèle utile. La durée pendant laquelle les éléments restent dans la boîte des "éléments envoyés" est un choix de l'utilisateur. L'utilisateur est généralement libre de garder ou supprimer les éléments de la boîte des "éléments envoyés" à son choix ou lorsque la mémoire de l'appareil atteint sa capacité.

En clair, si un envoyeur IM perd l'état de ses éléments envoyés (par exemple, l'utilisateur supprime les éléments de la boîte "éléments envoyés") le client peut utiliser une stratégie d'affichage différente en réponse à des IMDB apparemment non sollicitées.

La présente spécification ne rend pas obligatoire qu'un envoyeur IM utilise des temporisateurs d'attente d'une IMDN. Il n'y a pas de limites de temps concernant le moment où les IMDN peuvent être reçues.

Les IMDN peuvent légitimement n'être jamais reçues, de sorte que le temps entre l'envoi d'un IM et la génération et la réception ultime de la IMDN peut simplement être très long. Certains clients peuvent choisir de purger l'état associé à l'IM envoyé. C'est la raison de l'ajout de l'horodatage dans l'IM et de le retourner dans l'IMDN. Cela donne à l'utilisateur une opportunité de se souvenir de quel IM a été envoyé. Par exemple, si la IMDN indique que l'IM que l'utilisateur a envoyé à 14 heures mardi dernier a été livré, l'utilisateur a une chance de se souvenir qu'il a envoyé un IM à 14 heures mardi dernier.

 	7.1.4	Agrégation des IMDN
Un envoyeur IM peut envoyer un IM à plusieurs receveurs dans un message de protocole de transport (normalement en utilisant un serveur de liste d'URI [RFC5365]) et demander des IMDN. Un envoyeur d'IM qui a demandé des IMDN DOIT être prêt à recevoir plusieurs IMDN agrégées ou non agrégées. Voir les détails au paragraphe 8.3.

 	7.2	Receveur d'IM
 	7.2.1	Construction des IMDN
Les receveurs d'IM examinent le contenu du champ d'en-tête Disposition-Notification du message CPIM pour déterminer si le receveur a besoin de générer une IMDN pour cet IM. Les champs d'en-tête Disposition-Notification de messages CPIM peuvent inclure une ou plusieurs valeurs. Les receveurs d'IM peuvent avoir besoin de générer zéro, une, ou plusieurs IMDN pour cet IM, par exemple, une notification de livraison ainsi qu'une notification d'affichage. Dans ce cas, le receveur d'IM DOIT être capable de construire plusieurs IMDN par IM. Un receveur d'IM NE DOIT PAS construire plus d'une IMDN par type de disposition. C'est-à-dire, il ne doit pas générer une notification de livraison indiquant "delivered" suivi par une notification de livraison indiquant "failed" pour le même IM. Si l'envoyeur d'IM a demandé seulement des notifications d'échec et que l'IM a réussi à être livré, aucune IMDN ne va alors être générée. Si le receveur d'IM ne comprend par une valeur du champ d'en-tête Disposition-Notification, le receveur d'IM ignore cette valeur.

Le receveur d'IM NE DOIT PAS générer de notification "processing" (en cours de traitement).

Un champ d'en-tête Disposition-Notification NE DOIT PAS apparaître dans une IMDN car il est interdit de demander une IMDN pour une IMDN. Un envoyeur d'IM DOIT ignorer une demande de notification de livraison dans une IMDN si elle est présente. L'envoyeur d'IM NE DOIT PAS envoyer d'IMDN pour une IMDN.

Une IMDN DOIT contenir un champ d'en-tête Message-ID. Les mêmes règles d'unicité s'appliquent pour le champ d'en-tête Message-ID qui apparaît dans un IM que dans une IMDN. Le champ d'en-tête Message-ID dans la IMDN est différent et sans relation avec celui de l'IM.

Un IM peut contenir un champ d'en-tête IMDN-Record-Route (voir les détails à la Section 8). Si des champs d'en-tête IMDN-Record-Route apparaissent dans l'IM, le receveur d'IM qui construit la IMDN DOIT copier le contenu des champs d'en-tête IMDN-Record-Route dans les champs d'en-tête IMDN-Route dans la IMDN et conserver leur ordre. La IMDN est alors envoyée à l'URI au sommet du champ d'en-tête IMDN-Route. Les champs d'en-tête IMDN-Record-Route n'ont pas de sens dans une IMDN et donc NE DOIVENT PAS être placés dans une IMDN. Les receveurs d'IMDN DOIVENT les ignorer si ils sont présents.

Si il n'y a pas de champ d'en-tête IMDN-Record-Route, le receveur d'IM DOIT envoyer l'IMDN à l'URI dans le champ d'en-tête From.

Comme déclaré dans CPIM [RFC3862], les messages CPIM peuvent devoir prendre en charge des en-têtes MIME autres que Content-type. Les receveurs d'IM DOIVENT insérer un champ d'en-tête Content-Disposition réglé à la valeur "notification". Cela indique à l'envoyeur d'IM que le message est une IMDN à un IM qu'il a envoyé antérieurement.

 	7.2.1.1	Construction des notifications de livraison
Le receveur d'IM construit une notification de livraison d'une façon similaire à celle d'un IM, en utilisant un corps CPIM [RFC3862] qui porte un document XML de notification de disposition formaté en accord avec les règles spécifiées à la Section 11. Le type MIME du document XML de notification de disposition est "message/imdn+xml".

La Section 10 définit le schéma d'une IMDN.

Voici un exemple de corps CPIM d'une IMDN :

From: Bob <im:bob@exemple.com>
To: Alice <im:alice@exemple.com>
NS: imdn <urn:ietf:params:imdn>
imdn.Message-ID: d834jied93rf
Content-type: message/imdn+xml
Content-Disposition: notification
Content-length: ...

<?xml version="1.0" encoding="UTF-8"?>
<imdn xmlns="urn:ietf:params:xml:ns:imdn">
      <message-id>34jk324j</message-id>
      <datetime>2008-04-04T12:16:49-05:00</datetime>
     <receveur-uri>im:bob@exemple.com</receveur-uri>
      <original-receveur-uri>im:bob@exemple.com</original-receveur-uri>
      <delivery-notification>
         <status>
            <delivered/>
         </status>
      </delivery-notification>
    </imdn>

 	7.2.1.2	Construction des notifications d'affichage
Le receveur d'IM construit une notification d'affichage d'une façon similaire à celle de la notification de livraison. Voir les détails au paragraphe 7.2.1.1. La Section 10 définit le schéma pour une IMDN.

Voici un exemple :

From: Bob <im:bob@exemple.com>
To: Alice <im:alice@exemple.com>
NS: imdn <urn:ietf:params:imdn>
imdn.Message-ID: dfjkleriou432333
Content-type: message/imdn+xml
Content-Disposition: notification
Content-length: ...

<?xml version="1.0" encoding="UTF-8"?>
<imdn xmlns="urn:ietf:params:xml:ns:imdn">
      <message-id>34jk324j</message-id>
      <datetime>2008-04-04T12:16:49-05:00</datetime>
     <receveur-uri>im:bob@exemple.com</receveur-uri>
      <original-receveur-uri>im:bob@exemple.com</original-receveur-uri>
      <display-notification>
         <status>
            <affiché/>
         </status>
      </display-notification>
    </imdn>

Il y a des situations où le receveur d'IM ne peut pas déterminer si ou quand l'IM a été affiché. Le receveur d'IM génère dans ce cas une notification d'affichage avec une valeur <status> de "error" pour indiquer une erreur interne du serveur. Noter que le receveur d'IM peut choisir d'ignorer toute demande d'IMDN et de ne pas envoyer d'IMDN. Un receveur d'IM peut ne pas souhaiter laisser savoir à l'envoyeur si un message particulier lui a été affiché ou non. Cela pourrait être un choix de politique programmé par message ou par envoyeur.

 	8.	Comportement d'intermédiaire

Dans ce contexte, les intermédiaires sont des serveurs d'application (incluant des serveurs de liste d'URI et de mémorisation et transmission) et des passerelles. Une passerelle est un serveur qui traduit entre différents systèmes d'IM qui utilisent des protocoles différents.

Un serveur de liste d'URI peut changer l'adresse du receveur d'IM de son adresse propre en l'adresse du receveur final de cet IM pour chaque copie qu'il fait et envoie aux membres de la liste (voir les détails dans la [RFC5365]). Dans ce cas, si l'envoyeur d'IM demande une IMDN, l'intermédiaire DEVRAIT ajouter un champ d'en-tête Original-To à l'IM, le remplissant avec l'adresse qui était dans le champ d'en-tête CPIM To avant le changement. C'est-à-dire, l'intermédiaire remplit le champ d'en-tête Original-To avec l'adresse de l'intermédiaire. Bien sûr, on peut configurer un intermédiaire à se restreindre à réécrire ou remplir le champ Original-To. Un intermédiaire NE DOIT PAS ajouter un champ d'en-tête Original-To si il en existe déjà un. Un intermédiaire PEUT avoir une configuration administrative de ne pas révéler l'URI de demande original, et à ce titre, il NE DOIT PAS ajouter un en-tête Original-To.

Une réponse d'IM pour un IM en mode page n'est en aucune façon liée à l'IM initial et peut finir chez un agent d'utilisateur différent de où l'IM initial a été généré, selon comment l'URI de receveur est résolu. Donc, les réponses d'IM peuvent traverser différents intermédiaires. Une IMDN, par ailleurs, a besoin de traverser les mêmes intermédiaires que l'IM lui-même car ces intermédiaires peuvent être obligés de rapporter des notifications de livraison négatives si l'IM n'a pas réussi à être livré. Certains de ces intermédiaires sont, par exemple, des serveurs de mémorisation et transmission qui peuvent rapporter qu'un IM a été traité et plus tard rapporter que l'IM a échoué à être livré.

Pour les raisons déclarées ci-dessus, un intermédiaire PEUT choisir de rester sur le chemin des IMDN pour un IM spécifique. Il peut le faire en ajoutant un champ d'en-tête CPIM IMDN-Record-Route comme champ d'en-tête IMDN-Record-Route sommital. La valeur de ce champ DOIT être la propre adresse de l'intermédiaire. Un intermédiaire qui ne prend pas en charge cette extension ne va évidemment pas ajouter le champ d'en-tête IMDN-Record-Route. Cela permet aux IMDN de traverser directement du receveur d'IM à l'envoyeur d'IM même si l'IM a traversé un intermédiaire qui ne prend pas en charge cette extension.

Un intermédiaire qui reçoit une IMDN vérifie le champ d'en-tête IMDN-Route sommital. Si ce champ d'en-tête porte l'adresse de l'intermédiaire, l'intermédiaire retire cette valeur et transmet la IMDN à l'adresse indiquée dans le nouveau champ d'en-tête IMDN-Route sommital. Si des champs d'en-tête IMDN-Route supplémentaires sont présents, la IMDN est transmise à l'adresse dans le champ d'en-tête CPIM To.

Un intermédiaire DOIT retirer toutes les information sur les receveurs finaux d'une liste si la liste des membres n'est pas divulguée. L'intermédiaire fait cela en supprimant l'élément <receveur-uri> et/ou l'élément <original-receveur-uri> du corps de la IMDN avant de la transmettre à l'envoyeur d'IM.

 	8.1	Construction des notifications de traitement
Les intermédiaires sont les seules entités qui construisent des notifications de traitement. Ils ne le font que si l'envoyeur d'IM a demandé une notification "processing" en incluant un champ d'en-tête Disposition-Notification de valeur "processing".

L'intermédiaire peut créer et envoyer des notifications "processing" indiquant qu'un IM a été traité ou mémorisé. L'intermédiaire NE DOIT PAS envoyer plus d'une IMDN pour le même type de disposition -- c'est-à-dire, il ne doit pas envoyer une notification "processing" indiquant qu'un IM est en cours de "traitement" suivi par une autre IMDN indiquant que le même IM est "mémorisé".

Un intermédiaire construit une notification "processing" d'une façon similaire à celle dont le receveur d'IM construit une notification de livraison. Voir les détails au paragraphe 7.2.1.1.

Voici un exemple :

Content-type: Message/CPIM
From: Bob <im:bob@exemple.com>
To: Alice <im:alice@exemple.com>
Content-type: message/imdn+xml
Content-Disposition: notification

<?xml version="1.0" encoding="UTF-8"?>
<imdn xmlns="urn:ietf:params:xml:ns:imdn">
      <message-id>34jk324j</message-id>
      <datetime>2008-04-04T12:16:49-05:00</datetime>
     <receveur-uri>im:bob@exemple.com</receveur-uri>
      <original-receveur-uri>im:bob@exemple.com</original-receveur-uri>
      <processing-notification>
         <status>
            <processed/>
         </status>
      </processing-notification>
    </imdn>

Il y a des situations où l'intermédiaire ne peut pas connaître le sort d'un IM. Dans ce cas l'intermédiaire génère une notification de traitement de valeur <status> de "error" pour l'indiquer.

 	8.2	Construction des notifications de livraison
Les intermédiaires PEUVENT construire des notifications de livraison négatives. Il ne le font que si l'envoyeur d'IM a demandé une notification "negative-delivery" en incluant un champ d'en-tête Disposition-Notification de valeur "negative-delivery" ET qu'une erreur a été retournée pour cet IM.

L'intermédiaire peut créer et envoyer des notifications "negative-delivery" indiquant qu'un IM a échoué à être livré. L'intermédiaire NE DOIT PAS envoyer plus d'une IMDN pour le même type de disposition -- c'est-à-dire, il ne doit pas envoyer une notification "failed" indiquant qu'un IM a échoué suivie par une autre IMDN indiquant qu'une IMDN est "forbidden".

Un intermédiaire construit une notification "negative-delivery" un peu comme le receveur d'IM. Voir les détails au paragraphe 7.2.1.1.

 	8.3	Agrégation des IMDN
Comme on l'a décrit précédemment, les serveurs de liste d'URI sont des intermédiaires.

Un serveur de liste d'URI peut choisir (en utilisant la politique locale) d'agréger les IMDN ou il peut à la place envoyer des IMDN individuelles. Quand un serveur de liste d'URI reçoit un IM et décide d'agréger les IMDN, il peut attendre pendant un durée configurable ou jusqu'à ce que tous les receveurs aient envoyé la IMDN, selon ce qui arrive en premier, avant d'envoyer une IMDN agrégée. Noter que certaines IMDN, par exemple les notifications "affiché", peuvent ne jamais venir à cause des réglages chez l'utilisateur. Combien de temps attendre avant d'envoyer une IMDN agrégée et avant qu'un serveur de liste d'URI supprime l'état pour cet IM est une question pour l'administrateur de la configuration et de la mise en œuvre.

Un serveur de liste d'URI PEUT choisir d'envoyer plusieurs IMDN agrégées. Un temporisateur peut être démarré, et quand il arrive à expiration, le serveur de liste d'URI peut agréger toutes les IMDN qu'il a eues jusqu'à présent pour cet IM, envoyer l'IMDN agrégée, et relancer le temporisateur pour le prochain lot. Ceci est nécessaire pour les scénarios où l'envoyeur d'IM a demandé plus d'une IMDN pour un IM spécifique -- par exemple, des notifications de livraison ainsi que des notifications d'affichage -- ou quand le serveur de liste d'URI est à court de ressources et choisit de prioriser la transmission des IM plutôt que des IMDN.

Un second temporisateur peut être en cours, et quand il arrive à expiration, l'état de l'IM est supprimé. Dans ce cas, le serveur de liste d'URI consomme toutes lesIMDN qui pourraient arriver après ce moment.

On notera que les références aux temporisateurs dans les paragraphes précédents ne sont pas normatives et ne sont présentes que pour aider à décrire une façon de mettre en œuvre l'agrégation.

Un serveur de liste d'URI PEUT agréger des IMDN dans le cas où les informations de liste de membres ne sont pas divulguées. Il peut y avoir des scénarios où le serveur de liste d'URI commence par envoyer des IMDN agrégées et passe à des individuelles ou vice-versa. Un temporisateur qui expire souvent peut en fait avoir cet effet.

La IMDN agrégée est construite en utilisant le type MIME multipart/mixed et en incluant comme charges utiles individuelles toutes les IMDN qui ont été reçues comme message/imdn+xml.

Voici un exemple d'IMDN agrégées .

From: Bob <im:bob@exemple.com>
To: Alice <im:alice@exemple.com>
NS: imdn <urn:ietf:params:imdn>
imdn.Message-ID: d834jied93rf
Content-type: multipart/mixed; boundary="imdn-boundary"
Content-Disposition: notification
Content-length: ...

--imdn-boundary
Content-type: message/imdn+xml

<?xml version="1.0" encoding="UTF-8"?>
<imdn xmlns="urn:ietf:params:xml:ns:imdn">
      <message-id>34jk324j</message-id>
      <datetime>2008-04-04T12:16:49-05:00</datetime>
     <receveur-uri>im:bob@exemple.com</receveur-uri>
      <original-receveur-uri>im:bob@exemple.com</original-receveur-uri>
      <delivery-notification>
         <status>
            <delivered/>
         </status>
      </delivery-notification>
    </imdn>

--imdn-boundary
Content-type: message/imdn+xml

<?xml version="1.0" encoding="UTF-8"?>
<imdn xmlns="urn:ietf:params:xml:ns:imdn">
      <message-id>34jk324j</message-id>
      <datetime>2008-04-04T12:16:49-05:00</datetime>
     <receveur-uri>im:bob@exemple.com</receveur-uri>
      <original-receveur-uri>im:bob@exemple.com</original-receveur-uri>
      <display-notification>
         <status>
            <displayed/>
         </status>
      </display-notification>
    </imdn>

--imdn-boundary

 	9.	Identification des messages

Les messages sont normalement portés dans un protocole de transport comme SIP [RFC3261]. Si la charge utile portée par le protocole de transport ne contient aucune partie de type Message/CPIM, alors le message est un IM. Si la charge utile contient des parties de type Message/CPIM, et si aucune de ces parties ne contient une charge utile qui est de type "message/imdn+xml", le message est un IM. Il n'est pas valide de tenter de porter à la fois un IM et une IMDN dans une charge utile multipart dans un seul message de protocole de transport.

Un message est identifié comme une notification de livraison en examinant son contenu. Le message est une notification de livraison si le champ d'en-tête Content-type présent a une valeur de "message/imdn+xml", si le champ d'en-tête Content-Disposition a une valeur de "notification", et si l'élément <delivery-notification> apparaît dans ce corps XML.

Un message est identifié comme une notification de traitement ou notification d'affichage d'une façon similaire à celle d'une notification de livraison. La différence est que, pour une notification de traitement, l'élément <processing-notification> apparaît dans le corps XML. Pour une notification d'affichage, l'élément <display-notification> apparaît dans le corps XML.

 	10.	Syntaxe formelle des champs d'en-tête

La spécification de syntaxe suivante utilise la syntaxe de champ d'en-tête de message décrite à la Section 3 de la [RFC3862].

La syntaxe de champ d'en-tête est décrite sans qualification d'espace de noms. Suivant les règles de la [RFC3862], les noms de champ d'en-tête et le reste du texte sont sensibles à la casse et DOIVENT être utilisés comme donnés, en utilisant exactement les lettres indiquées en majuscules et minuscules.

Disposition-Notification = "Disposition-Notification" ": " [(notify-req *(COMMA notify-req))]

notify-req = ("negative-delivery" / "positive-delivery" / "processing" / "display" / Token) *(SEMI disp-notify-params)

disp-notify-params = Ext-param

Message-ID = "Message-ID" ": " Token

Original-To = "Original-To" ": " [ Formal-name ] "<" URI ">"

IMDN-Record-Route = "IMDN-Record-Route" ": " [ Formal-name ] "<" URI ">"

IMDN-Route = "IMDN-Route" ": " [ Formal-name ] "<" URI ">"

SEMI =  *SP ";" *SP	; point-virgule

COMMA =  *SP "," *SP	; virgule

 	11.	Format d'IMDN
 	11.1	Structure d'une charge utile IMDN codée en XML
Une charge utile d'IMDN est un document XML [XML] qui DOIT être bien formé et DOIT être valide selon les schémas, y compris les schémas d'extension, disponibles au valideur et applicables au document XML. La charge utile IMDN DOIT être fondée sur XML 1.0 et DOIT être codée en utilisant UTF-8.

Le schéma permet des éléments d'extension qualifiés dans plusieurs positions autres que l'espace de noms "urn:ietf:params:xml:ns:imdn". Pour conserver la compatibilité future (c'est-à-dire, que des documents d'instance plus récents puissent être utilisés par les consommateurs existants) les nouvelles spécifications NE DOIVENT PAS étendre le contenu permis de la présente spécification. La rétro compatibilité (c'est-à-dire, les documents d'instances existantes peuvent aussi être utilisés par de nouveaux consommateurs mis à jour) PEUT échouer si il y a des conflits avec les noms qualifiés existants d'éléments d'extension et d'éventuelles futures spécifications. L'IETF PEUT spécifier de nouveaux éléments d'extension dans le "sous espace de noms" de "urn:ietf:params:xml:ns:" pour ce type de message/imdn+xml MIME.

Des futures spécifications pourront ajouter de nouvelles définitions d'élément avec le schéma combine="interleave". Quand plusieurs éléments de ce nouveau type sont alors permis, la nouvelle définition DOIT contenir la règle de cardinalité <zeroOrMore> (zéro, un ou plusieurs). Si la nouvelle spécification permet seulement un nouvel élément, la règle de cardinalité <optional> DOIT être utilisée. Ces exigences de cardinalité maintiennent la rétro compatibilité des documents d'instance existants avec des consommateurs plus récents. Aussi, la nouvelle spécification DOIT alors redéfinir l'extension "anyIMDN" ou que l'extension individuelle pointe sur cette référence, afin que les nouvelles définitions d'élément ne correspondent pas à celle redéfinie et des schémas de caractères génériques plus limités.

L'identifiant d'espace de noms pour les éléments définis dans la présente spécification est un URN [RFC2141], utilisant l'identifiant d'espace de noms "ietf" défini par la [RFC2648] et étendu par la [RFC3688]. Cet URN est : urn:ietf:params:xml:ns:imdn.

Cette déclaration d'espace de noms indique l'espace de noms sur lequel la IMDN se fonde.

L'élément racine est <imdn>. L'élément <imdn> a les sous éléments, <message-id>, <datetime>, <receveur-uri>, <original-receveur-uri>, <subject>, et un de <delivery-notification>, <processing-notification>, ou <display-notification>. Un <status> apparaît aussi comme sous élément de <delivery-notification>, <processing-notification>, et <display-notification>. Les éléments sont décrits en détail dans les paragraphes suivants.

<imdn> pourrait être étendu à l'avenir pour inclure de nouveaux types de notification de disposition ou d'autres éléments, comme décrit au paragraphe 11.1.9.

 	11.1.1	Élément <message-id>
L'élément <message-id> est obligatoire en accord avec le schéma XML et porte l'identifiant de message qui apparaissait dans le champ d'en-tête Message-ID de l'IM.

 	11.1.2	Élément <datetime>
L'élément <datetime> est obligatoire et porte la date et l'heure à laquelle l'IM a été envoyé (pas la IMDN). Cette information est obtenue du champ d'en-tête DateTime de l'IM.

 	11.1.3	Élément <receveur-uri>
L'élément <receveur-uri> est facultatif et porte l'URI du receveur final. Cette information est obtenue du champ d'en-tête CPIM To de l'IM.

 	11.1.4	Élément <original-receveur-uri>
L'élément <original-receveur-uri> est facultatif et porte l'URI du receveur original. Il DOIT être présent si l'IM portait le champ d'en-tête Original-To. Cette information est obtenue du champ d'en-tête Original-To de l'IM.

 	11.1.5	Élément <subject>
L'élément <subject> est facultatif. Si il est présent, il DOIT porter les attributs de texte et langage qui étaient dans le champ d'en-tête Subject, si il y en a un. Cela permet une corrélation au niveau humain entre un IM et une IMDN. Si il y a plus d'un champ d'en-tête Subject dans un IM, il va suffire d'en choisir un à placer dans l'élément <subject> de la charge utile de l'IMDN. L'envoyeur doit alors comparer les champs d'en-tête Subject jusqu'à trouver une correspondance ou qu'il soit déterminé qu'il n'y a pas de correspondance.

 	11.1.6	Éléments <delivery-notification>, <processing-notification>, et <display-notification>
L'apparition d'un des éléments <delivery-notification>, <processing-notification>, et <display-notification> est obligatoire et porte le type de disposition que l'envoyeur d'IM a demandé et qui est rapporté. Il porte le sous élément <status>.

 	11.1.7	Élément <status>
L'élément <status> est obligatoire et porte le résultat de la demande de disposition. Pour le type de notification <delivery-notification>, il peut porter un des sous éléments <delivered>, <failed>, <forbidden>, ou <error>. Pour le type de notification <display-notification>, il peut porter un des sous éléments <displayed>, <forbidden>, ou <error>. Pour le type de notification <processing-notification>, il peut porter un des sous éléments <processed>, <stored>, <forbidden>, ou <error>. <forbidden> signifie que la disposition a été refusée. <error> signifie une erreur interne du serveur. L'élément <status> peut aussi être étendu pour porter toutes autres extensions d'état.

 	11.1.8	Type MIME pour charge utile IMDN
Le type MIME pour la charge utile d'IMDN est "message/imdn+xml". La IMDN DOIT identifier la charge utile comme type MIME "message/imdn+xml" dans le champ d'en-tête Content-type.

 	11.1.9	Schéma RelaxNG
<?xml version="1.0" encoding="UTF-8"?>
<grammaire
       xmlns="http://relaxng.org/ns/structure/1.0"
       xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
       datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"
       ns="urn:ietf:params:xml:ns:imdn">

         <start>
             <element name="imdn">
                 <element name="message-id">
                     <data type="token"/>
                 </element>
                 <element name="datetime">
                     <data type="string"/>
                 </element>
                 <optional>
                     <element name="receveur-uri">
                         <data type="anyURI"/>
                     </element>
                     <element name="original-receveur-uri">
                         <data type="anyURI"/>
                     </element>
                     <optional>
                         <element name="subject">
                             <data type="string"/>
                         </element>
                     </optional>
                 </optional>
                 <choice>
                     <ref name="deliveryNotification"/>
                     <ref name="displayNotification"/>
                     <ref name="processingNotification"/>
                     <empty/>
                 </choice>
                 <ref name="imdnExtension"/>
             </element>
         </start>
         <define name="deliveryNotification">
             <element name="delivery-notification">
                 <element name="status">
                     <choice>
                         <element name="delivered">
                             <empty/>
                         </element>
                         <element name="failed">
                             <empty/>
                         </element>
                         <ref name="commonDispositionStatus"></ref>
                     </choice>
                     <ref name="deliveryExtension"/>
                   </element>
              </element>
         </define>

         <define name="displayNotification">
             <element name="display-notification">
                 <element name="status">
                     <choice>
                         <element name="affiché">
                             <empty/>
                         </element>
                         <ref name="commonDispositionStatus"></ref>
                     </choice>
                     <ref name="displayExtension"/>
                 </element>
             </element>
         </define>

         <define name="processingNotification">
             <element name="processing-notification">
                 <element name="status">
                     <choice>
                         <element name="processed">
                             <empty/>
                         </element>
                         <element name="stored">
                             <empty/>
                         </element>
                         <ref name="commonDispositionStatus"></ref>
                     </choice>
                     <ref name="processingExtension"/>
                  </element>
             </element>

         </define>

         <define name="commonDispositionStatus">
             <choice>
                 <element name="forbidden">
                     <empty/>
                 </element>
                 <element name="error">
                     <empty/>
                 </element>
             </choice>
         </define>

<!-- L'extension <imdn> pointe sur les schémas d'extension pour ajouter de nouvelles définitions avec le schéma combine="interleave". Les schémas d'extension devraient ajouter les cardinalités appropriées. Par exemple, la cardinalité <zeroOrMore> devrait être utilisée si l'extension est pour permettre plusieurs éléments, et la cardinalité <optional> devrait être utilisée si l'extension est pour permettre un seul élément. -->

         <define name="imdnExtension">
             <zeroOrMore>
                 <ref name="anyIMDN"/>
             </zeroOrMore>
         </define>

<!--Point d'extension <status> de delivery-notification -->
         <define name="deliveryExtension">
             <zeroOrMore>
                 <ref name="anyIMDN"/>
             </zeroOrMore>
         </define>

<!-- Point d'extension <status> de display-notification -->
         <define name="displayExtension">
             <zeroOrMore>
                 <ref name="anyIMDN"/>
             </zeroOrMore>
         </define>

<!--Point d'extension <status> de processing-notification -->
         <define name="processingExtension">
             <zeroOrMore>
                 <ref name="anyIMDN"/>
             </zeroOrMore>
         </define>

<!-- Définition de caractère générique pour des éléments complexes (de type mixte) non qualifiés ou qualifiés dans l'espace de noms imdn. Les schémas d'extension DOIVENT redéfinir cela ou les définitions individuelles précédentes qui utilisent cette définition. En d'autres termes, le schéma d'extension DOIT réduire le contenu admis afin de maintenir des schémas déterministes et non ambigus avec le schéma d'entrelacement. -->
         <define name="anyIMDN">
             <element>
                 <anyName>
                     <except>
                         <nsName ns="urn:ietf:params:xml:ns:imdn"/>
                         <nsName ns=""/>
                     </except>
                 </anyName>
                 <ref name="anyExtension"/>
             </element>
         </define>

<!-- Le reste de la définition de caractère générique "anyIMDN" -->
         <define name="anyExtension">
             <zeroOrMore>
                <choice>
                    <attribute>
                       <anyName/>
                    </attribute>
                    <ref name="any"/>
                </choice>
             </zeroOrMore>
         </define>

<!-- Type de caractère générique pour éléments complexes (de type mixte) sans aucun espace de noms ou restrictions de contenu -->
         <define name="any">
             <element>
                 <anyName/>
                 <zeroOrMore>
                    <choice>
                       <attribute>
                          <anyName/>
                       </attribute>
                       <text/>
                       <ref name="any"/>
                    </choice>
                 </zeroOrMore>
             </element>
         </define>

</grammaire>

 	12.	Transport des messages avec SIP
 	12.1	Comportement de point d'extrémité
 	12.1.1	Envoi des demandes
L'envoyeur d'IM construit une demande SIP MESSAGE en utilisant la [RFC3428]. Le champ d'en-tête Content-type indique le type MIME de la charge utile de la demande. Quand on utilise cette extension, le champ d'en-tête Content-type DOIT être du type MIME "message/cpim" [RFC3862] pour les IM et les IMDN. L'envoyeur d'IM construit la charge utile conformément à la Section 7.

L'envoyeur d'IM construit une demande SIP MESSAGE pour plusieurs receveurs d'une manière a similaire à celle d'une demande SIP MESSAGE à un seul receveur. La [RFC5365] "Demandes MESSAGE à plusieurs receveurs dans SIP" décrit les différences.

Les envoyeurs d'IM peuvent rester anonymes. Par exemple, l'envoyeur peut régler le champ d'en-tête SIP From du message SIP à un URI anonyme. Comme il n'y a pas d'adresse de retour, les envoyeurs d'IM anonymes NE DEVRAIENT PAS demander des notifications de disposition. Un receveur d'IM PEUT ignorer une telle demande si l'envoyeur d'IM est anonyme.

 	12.1.2	Envoi des réponses
Un point d'extrémité qui reçoit une demande SIP MESSAGE construit une réponse SIP conformément à la [RFC3428]. Bien sûr, un point d'extrémité va envoyer une réponse SIP à la demande MESSAGE sans considération du type de message (IM ou IMDN) qu'il a reçu ou du type de disposition qui lui a été demandé.

 	12.1.3	Réception de demandes
 	12.1.3.1	Message instantané
Une demande SIP MESSAGE est identifiée comme un IM en examinant son contenu conformément à la Section 9.

Si un receveur d'IM a reçu une demande SIP MESSAGE qui est un IM demandant une notification de livraison positive, et si ce receveur d'IM a construit et envoyé une réponse SIP de classe 2xx, il PEUT générer une notification de livraison positive après s'être assuré que l'IM a bien été livré à l'utilisateur ou l'application. Une passerelle, par exemple, peut générer une réponse 2xx avant que le receveur final ait reçu l'IM. Le receveur d'IM construit une notification de livraison positive conformément au paragraphe 7.2.1.1. Le receveur d'IM place le message comme charge utile d'une demande SIP MESSAGE.

Si un receveur d'IM a reçu une demande SIP MESSAGE qui est un IM demandant une livraison négative, et si ce receveur d'IM a construit et envoyé une réponse de classe 2xx, il DEVRAIT générer une notification de livraison négative si il a appris que le receveur ou application final n'a pas reçu l'IM (une passerelle, par exemple, peut générer une réponse 2xx avant d'avoir une réponse d'erreur de l'aval ou avant qu'un temporisateur interne arrive à expiration pour une réponse). La notification de livraison négative est construite conformément au paragraphe 7.2.1.1. Le message est alors placé comme charge utile dans une demande SIP MESSAGE.

Si un receveur d'IM a reçu une demande SIP MESSAGE qui est un IM demandant une notification de livraison négative, et si le receveur d'IM a construit et envoyé une réponse finale non 2xx, il NE DOIT PAS générer une notification de livraison négative.

Si un receveur d'IM a reçu une demande SIP MESSAGE qui est un IM demandant une notification d'affichage, et si ce receveur d'IM a construit et envoyé une réponse SIP de classe 2xx, il PEUT générer une notification d'affichage après s'être assuré que l'IM a bien été présenté à l'utilisateur ou application. Il sort du domaine d'application du présent document de discuter comment peut être faite la détermination de si l'IM a été lu. Noter que la décision d'envoyer ou non une notification d'affichage peut être laissée à l'utilisateur. Une application peut permettre à un utilisateur de configurer ce choix. Le receveur d'IM construit la notification d'affichage conformément au paragraphe 7.2.1.2. Le receveur d'IM place le message comme charge utile dans une demande SIP MESSAGE.

Pour les IMDN, le receveur d'IM remplit l'URI de demande SIP et le champ d'en-tête SIP To en utilisant l'adresse qui apparaissait dans le champ d'en-tête SIP From dans l'IM.

 	12.1.3.2	Notification de livraison
Une demande SIP MESSAGE est identifiée comme notification de livraison en examinant son contenu conformément à la Section 9.

 	12.1.3.3	Notification d'affichage
Une demande SIP MESSAGE est identifiée comme notification d'affichage en examinant son contenu conformément à la Section 9.

 	12.2	Comportement d'intermédiaire
Dans ce contexte, les intermédiaires incluent des serveurs d'application (incluant des serveurs de liste d'URI et de mémorisation et transmission) et des passerelles. Les mandataires SIP NE DOIVENT PAS générer des IMDN mais DOIVENT les transmettre comme toutes les autres demandes SIP.

Les intermédiaires transmettent une demande SIP MESSAGE à plusieurs receveurs conformément à la [RFC5365].

Si un intermédiaire reçoit un IM, il examine son corps. Si le corps est de type "message/cpim", l'intermédiaire cherche alors un champ d'en-tête Disposition-Notification CPIM dans le message. Si le champ d'en-tête Disposition-Notification CPIM a la valeur "positive-delivery" ou "negative-delivery", et, si en traitant l'IM, l'intermédiaire génère une réponse SIP de classe 2xx à la demande MESSAGE, alors l'intermédiaire effectue les actions suivantes.

Si le champ d'en-tête Disposition-Notification contient une valeur de "positive-delivery", l'intermédiaire NE DOIT PAS générer de notification de livraison si il reçoit une réponse SIP de classe 2xx pour l'IM envoyé. Le fait qu'une entité en aval ait reçu une demande MESSAGE ne signifie pas que le message a été relayé à sa destination ultime ou a été livré. Donc, l'intermédiaire ne peut pas dire que la livraison s'est produite juste parce qu'il a reçu une réponse 2xx.

Si le champ d'en-tête Disposition-Notification contient une valeur de "negative-delivery", l'intermédiaire DEVRAIT générer une notification de livraison si il reçoit une réponse finale SIP de classe 4xx, 5xx, ou 6xx pour l'IM envoyé. Si il a reçu une réponse SIP de classe 2xx suivie par une notification de livraison négative, l'intermédiaire transmet cette notification de livraison négative ou l'agrège.

Si le champ d'en-tête Disposition-Notification contient une valeur de "processing", l'intermédiaire PEUT générer une notification de traitement après avoir transmis ou mémorisé l'IM. Le reste des procédures du paragraphe 8.1 s'applique.

La procédure pour générer une telle IMDN est la même que celle d'un receveur d'IM (paragraphe 7.2.1.1).

L'élément <receveur-uri> du corps XML est rempli avec l'URI du receveur d'IM.

Si un intermédiaire reçoit une demande SIP MESSAGE portant une notification de livraison positive ou une notification d'affichage, il la transmet en utilisant les règles de la Section 8.

 	13.	Transport des messages avec MSRP

Le protocole de relais de session de message (MSRP, Message Session Relay Protocol) [RFC4975] fournit déjà un mécanisme incorporé pour fournir des rapports de livraison positive et négative. Ces rapports ne fournissent pas de notifications incorporées d'affichage ou de traitement. Cependant, ces notifications en mode session ne sont pas aussi utiles qu'elles le sont pour le mode page. C'est parce que le cas d'utilisation de base pour MSRP est que l'agent d'utilisateur receveur rend immédiatement des demandes SEND à la suite, fournissant l'expérience de session. Ceci est différent des demandes en mode page où un utilisateur doit activement initier l'affichage du message. C'est-à-dire qu'il doit cliquer sur un bouton, ouvrir un message, et ainsi de suite pour lire le message.

Si de nouvelles exigences apparaissent à l'avenir pour déterminer le besoin de IMDN dans MSRP, des nouvelles spécifications pourront être rédigées.

 	14.	Considérations sur la sécurité

Les IMDN fournissent une vue d'une granularité fine de l'activité du receveur d'IM, et donc méritent une protection particulièrement attentive de la confidentialité afin que seul le receveur prévu de l'IMDN la reçoive. Dans la plupart des cas, le receveur prévu de l'IMDN est l'envoyeur d'IM.

Comme le protocole de transport d'IM porte la IMDN, toutes les considérations sur la sécurité du protocole d'IM sous-jacent s'appliquent aussi à l'IMDN.

Les menaces dans le système d'IMDN, sur et au-delà des menaces inhérentes à l'IM, incluent ce qui suit :

o	Un point d'extrémité malveillant tente d'envoyer des messages à un utilisateur qui ne souhaiterait normalement pas recevoir de messages de ce point d'extrémité, en convainquant le système d'IMDN de "faire rebond" d'une IMDN provenant d'un point d'extrémité innocent à l'utilisateur.

o	Un point d'extrémité malveillant tente d'inonder un envoyeur d'IM avec des IMDN en convainquant un serveur de liste d'URI d'envoyer des IMDN à un envoyeur d'IM innocent.

o	Un intermédiaire ou nœud malveillant tente d'inonder un nœud cible avec des IMDN en insérant l'adresse de la cible dans le champ From ou IMDN-Record-Route.

o	Un nœud malveillant dans le réseau tente de modifier une IMDN provenant d'un receveur d'IM.

o	Un intermédiaire malveillant tente de transmettre une IMDN provenant d'un receveur d'IM à l'envoyeur d'IM, alors que le receveur d'IM ne transmettrait normalement pas d'IMDN à cet envoyeur d'IM si le receveur d'IM savait l'identité de l'envoyeur d'IM.

o	Un point d'extrémité malveillant tente de découvrir l'URI de demande d'un point d'extrémité au delà d'un intermédiaire, alors que le point d'extrémité souhaiterait normalement garder son identité secrète pour le point d'extrémité malveillant.

o	Un nœud malveillant dans le réseau tente d'espionner le trafic d'IMDN pour, par exemple, apprendre l'URI de demande ou des informations sur le schéma de trafic.

o	Un nœud malveillant dans le réseau tente de monter une attaque de déni de service sur un intermédiaire en demandant une grande expansion de liste.

Le protocole ne peut pas protéger contre les attaques qui incluent ce qui suit :

o	Un intermédiaire malveillant révélant directement l'identité d'un point d'extrémité en aval qui souhaiterait normalement que son identité ne soit pas révélée. Garder de telles informations secrètes est un problème de mise en œuvre de l'intermédiaire.

o	Un receveur d'IM malveillant altère l'heure de l'IMDN. Il n'y a pas de mécanisme de protocole pour assurer que le receveur d'IM ne ment pas sur l'heure ou retient délibérément la transmission d'une IMDN pour faire paraître que l'IM affiché à l'utilisateur a été lu plus tard qu'il ne l'a été en réalité.

o	Un attaque de suppression sur une IMDN. C'est un compromis entre confidentialité et sécurité. Les considérations de confidentialité permettent que le receveur d'IM ignore en silence la demande d'IMDN. Tout mécanisme qui indiquerait de façon fiable qu'un nœud malveillant a supprimé l'IMDN d'un receveur d'IM servirait aussi pour détecter qu'un receveur d'IM a choisi de ne pas produire une IMDN.

Pour combattre l'espionnage, la modification, et les attaques par interposition, on exige un certain niveau d'authentification et de protection de l'intégrité. Ceci dit, il y a des circonstances où une forte intégrité serait outrancière. La présomption est que l'envoyeur d'IM a, et attend, le niveau de protection. Les procédures pour la protection de l'intégrité sont les suivantes.

o	Si le receveur d'IM a un certificat, il DOIT signer l'IMDN. Signer l'IMDN fournit la protection de l'intégrité. Bien qu'un intermédiaire puisse remplacer le corps de l'IMDN, l'envoyeur d'IM (le receveur de l'IMDN) peut valider la signature et noter que l'IMDN ne vient pas directement du receveur d'IM. Ce n'est pas un problème si l'envoyeur d'IM fait confiance à l'intermédiaire. De même, une IMDN en réponse à un IM signé sans une signature indique que quelque chose de mauvais s'est produit.

o	Si l'IM est chiffré, le receveur d'IM ou l'intermédiaire DOIT chiffrer le corps d'IMDN, car un attaquant peut tenter de discerner le profil d'activité de l'utilisateur et son identité en lisant les IMDN dans le réseau.

o	Les deux règles ci-dessus sont cumulatives.

Le receveur d'IM ou l'intermédiaire DOIT être capable d'accéder au certificat public de l'envoyeur d'IM afin de vérifier la signature dans l'IM.

Les considérations sur la sécurité de CPIM [RFC3862] s'appliquent ici, car c'est une extension de CPIM. Afin de rendre le mécanisme d'IMDN indépendant du protocole de transport, le groupe de travail a fait le choix de conception de mettre les informations d'acheminement dans la charge utile d'IMDN de couche d'application. Une conséquence de ce choix est que cela élimine la possibilité d'avoir un chiffrement de bout en bout.

Un attaquant peut monter une attaque de déni de service répartie contre un nœud en envoyant des grandes quantités d'IM au nœud avec des demandes d'IMDN. Noter que c'est le même problème que sans IMDN ; l'IMDN augmente simplement de façon linéaire la charge sur le nœud attaqué. On peut atténuer, mais pas éliminer cette menace en faisant que le point d'extrémité ignore immédiatement les demandes qui ne sont pas authentifiées.

Une façon de traiter l'éventualité qu'un nœud malveillant utilise le système d'IMDN pour anonymiser les attaques est d'enregistrer toutes les demandes d'IMDN sur l'agent d'utilisateur du receveur d'IM. Cela permet de tracer les attaques, mais seulement après qu'elles surviennent. Noter que cela fait aussi peser une charge sur l'hôte de l'agent d'utilisateur de receveur d'IM. Des agents d'utilisateur limités peuvent n'être pas capables de conserver beaucoup d'enregistrements.

De même, un attaquant peut monter une attaque de déni de service sur un intermédiaire en demandant à l'intermédiaire de développer une grande liste.

Les considérations de sécurité suivantes s'appliquent quant on utilise des IMDN.

 	14.1	Falsification
Des IM peuvent être falsifiés. Pour protéger contre cela, un IM peut être signé. Un intermédiaire qui reçoit un message signé et a besoin d'en modifier une partie qui est incluse dans la signature (comme d'ajouter un champ d'en-tête Original-To aux champs d'en-tête CPIM) DOIT consommer l'IM et en créer une nouvelle copie que l'intermédiaire signe lui-même.

Les IMDN peuvent être falsifiées aussi facilement que les IM ordinaires. Les points d'extrémité et intermédiaires qui souhaitent faire une utilisation automatique des IMDN devraient prendre des précautions appropriées pour minimiser les dommages potentiels d'attaques de déni de service. Les menaces pour la sécurité relatives à des IMDN falsifiées incluent l'envoi d'IMDN falsifiée quand la disposition indiquée de l'IM ne s'est en fait pas produite. Par exemple, la notification d'affichage pourrait être falsifiée pour indiquer qu'un IM a été affiché au receveur. Des IMDN non sollicitées sont aussi une autre forme de falsification.

 	14.2	Confidentialité
Il peut y avoir des cas où un receveur d'IM ne souhaite pas révéler qu'il a reçu, ou en fait lu, l'IM. Dans cette situation, il est acceptable que le receveur IM ignore en silence les demandes d'IMDN. Il est fortement RECOMMANDÉ que le receveur d'IM obtienne le consentement de l'utilisateur avant d'envoyer une IMDN. Les circonstances où le receveur d'IM ne demande pas le consentement de l'utilisateur incluent des systèmes d'IM qui, pour des raisons réglementaires, sont obligés de produire une IMDN, comme dans le domaine de la santé publique ou de la communauté financière.

Un receveur d'IM peut obtenir un tel consentement par une invite ou une boîte de dialogue IM par IM, globalement par le réglage des préférences de l'utilisateur, ou par un autre mécanisme configurable par l'utilisateur. L'utilisateur pourrait aussi indiquer globalement que les IMDN ne sont jamais à envoyer ou qu'un état d'IMDN de "forbidden" est toujours envoyé en réponse à une demande d'IMDN.

Il y a des situations où un utilisateur envoie un IM et demande des IMDN pour une liste dont les informations de membres ne sont pas divulguées. Dans cette situation, l'utilisateur va apprendre les membres de la liste. Donc, dans ce cas, le serveur de liste d'URI DOIT supprimer toute information sur les membres de la liste. Si le nombre de membres de la liste est aussi non divulgué, le serveur de liste d'URI DOIT seulement livrer une IMDN agrégée. Autrement, le serveur de liste d'URI PEUT rejeter l'IM.

Il est possible qu'un serveur de liste ne comprenne pas la IMDN. Les receveurs d'IM peuvent noter que le champ d'en-tête To est un nom de liste et non le nom du receveur d'IM. Dans ce cas, le receveur d'IM peut prendre les mesures appropriées si il souhaite garder son identité secrète.

Une IMDN non chiffrée pourrait révéler des informations confidentielles sur un IM chiffré. Le même niveau de sécurité appliqué à un IM DOIT être appliqué à ses IMDN. Par exemple, si un IM est signé et chiffré, l'IMDN doit être signée et chiffrée.

 	14.3	IMDN comme service de livraison certifiée
On ne peut pas s'appuyer sur les IMDN pour avoir la garantie qu'un IM a été ou non vu par l'utilisateur. Même si des IMDN ne sont pas activement falsifiées, elles peuvent être perdues dans le transit. De plus, le receveur d'IM peut outrepasser le mécanisme de production d'IMDN par sa politique ou la manipulation de leur serveur d'agent d'utilisateur.

 	15.	Considérations relatives à l’IANA
 	15.1	Type MIME message/imdn+xml
Le présent document enregistre un nouveau type MIME "message/imdn+xml", et enregistre un nouvel espace de noms XML.

La présente spécification suit les lignes directrices de la [RFC3023].

Type de support MIME : message
Nom de sous type MIME : imdn+xml
Paramètres obligatoires : aucun
Paramètres facultatifs : les mêmes que pour le paramètre de jeu de caractères application/xml spécifié dans la [RFC3023].
Considérations de codage : les mêmes que les considérations de codage de application/xml spécifié dans la [RFC3023].
Considérations de sécurité : voir la Section 10 de la [RFC3023] et la Section 14 du présent document.
Considérations d'interopérabilité : aucune
Spécification publiée : RFC 5438
Applications qui utilisent ce type de support : ce type de support est utilisé pour prendre en charge la messagerie instantanée fondée sur CPIM.
Informations supplémentaires : aucune
Numéro magique : aucune
Extension de fichier : .cl ou .xml
Code de type de fichier Macintosh : "TEXT"
Adresse personnelle et de messagerie pour plus d'informations : Hisham Khartabil  (hisham.khartabil@gmail.com)
Usage prévu : COMMUN
Auteur/contrôleur des changements : IETF

 	15.2	Enregistrement XML
Ce paragraphe enregistre un nouvel espace de noms et schéma XML, selon les lignes directrices du registre XML de l'IETF [RFC3688].

URI : urn:ietf:params:xml:ns:imdn
XML : le schéma pour cet espace de noms est au paragraphe 11.1.9 ci-dessus.
Contact d'enregistrement : IETF, groupe de travail SIMPLE, Hisham Khartabil (hisham.khartabil@gmail.com)

 	15.3	Enregistrement d'URN pour les paramètres d'en-tête IMDN
Selon la [RFC3553], prière d'établir le registre suivant. Les nouvelles entrées du registre sont de "Spécification exigée".

Nom du registre : urn:ietf:params:imdn
Spécification : RFC 5438. Des valeurs supplémentaires pourront être définies par une "Action de normalisation" [RFC5226] qui met à jour ou rend obsolète la RFC 5438.
Répertoire : RFC 5438
Valeur d'index : les valeurs subordonnées à urn:ietf:params:imdn exigent la publication d'une RFC. La valeur d'index est le nom de l'en-tête d'IMDN. La valeur d'index doit suivre les règles pour un nom légal d'en-tête d'IMDN. En particulier, le nom d'en-tête d'IMDN, et donc la valeur d'index à enregistrer, doit être une chaîne d'octets prise de l'ensemble restreint de caractères US-ASCII du paragraphe 3.1 de la [RFC3553]. La valeur d'index est sensible à la casse.

Formation d'URN : l'URI pour un en-tête est formé à partir de son nom par :
a) le remplacement de tout caractèrne non URN (comme défini par la [RFC2141]) par la séquence d'échappement correspondante "%hh" (selon la [RFC3986]) et
b) l'ajout devant la chaîne résultante de "urn:ietf:params:imdn:".

Donc, l'URI correspondant à l'en-tête "Disposition-Notification:" d'IMDN de message CPIM serait "urn:ietf:params:imdn:Disposition-Notification".

Valeurs initiales :

Valeur d'index	Référence
Disposition-Notification	RFC5438, paragraphe 6.2
Message-ID	RFC5438, paragraphe 6.3
Original-To	RFC5438, paragraphe 6.4
IMDN-Record-Route	RFC5438, paragraphe 6.5
IMDN-Route	RFC5438, paragraphe 6.6

 	15.4	Notification Content-Disposition: 
Le présent document enregistre un nouveau champ d'en-tête Content-Disposition "disposition-types: notification", qui a été enregistré dans le registre de l' IANA pour les dispositions de contenu de messagerie.

Les descriptions de ces "disposition-types", incluant leur motivation et des exemples, sont données au paragraphe 7.2.1.1 et à la Section 9.

La description courte pour le registre de l'IANA est :
notification : la charge utile du message qui porte cette valeur de champ d'en-tête Content-Disposition est une notification de disposition de messages instantané comme demandé dans le message instantané correspondant.

 	16.	Remerciements

Des remerciements particuliers sont dus à Jari Urpalainen pour sa relecture et ses suggestions sur le schéma RelaxNG.

Les auteurs tiennent aussi à remercier Paul Kyzivat, Ben Campbell, Adam Roach, Gonzalo Camarillo, Frank Ellermann, Sean Olson, Eva Leppanen, Miguel Garcia, Eric McMurry, Jon Peterson, et Robert Sparks de leurs commentaires et leur soutien. De plus, ils tiennent à remercier le réviseur extraordinaire Gen-Art, Spencer Dawkins.

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

[RFC2141]	R. Moats, "Syntaxe des URN", mai 1997. (Obsolète, voir RFC8141)

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

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

[RFC3862]	G. Klyne, D. Atkins, "Format de message commun pour la présence et la messagerie instantanée (CPIM)", août 2004. (P.S.)

[RFC3986]	T. Berners-Lee, R. Fielding et L. Masinter, "Identifiant de ressource uniforme (URI) : Syntaxe générique", STD 66, janvier 2005. (P.S.  ; MàJ par RFC8820)

[XML]	Bray, T., "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C CR CR-xml11-20011006, octobre 2000.

 	17.2	Références pour information

[RFC2648]	R. Moats, "Espace de nom d'URN pour les documents de l'IETF", août 1999. (Information)

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

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

[RFC3553]	M. Mealling et autres, "Sous-espace de noms d'URN de l'IETF pour les paramètres de protocole enregistrés", juin 2003. (BCP0073)

[RFC3798]	T. Hansen et G. Vaudreuil, éd., "Notification de disposition de message", mai 2004. (MàJ par RFC5337, RFC6533) (D.S.; Rendue obsolète par RFC8098)

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

[RFC5226]	T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, mai 2008. (Remplace RFC2434 ; remplacée par RFC8126) 

[RFC5321]	J. Klensin, "Protocole simple de transfert de messagerie (SMTP)", octobre 2008. (Remplace RFC2821) (MàJ RFC1123) (D.S.)

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

 	Adresse des auteurs

Eric Burger	Hisham Khartabil	
New Hampshire	Ericsson Australia	
USA	Melbourne	
Fax :   +1 603 457 5933	Australia	
mél : eburger@standardstrack.com	téléphone : +61 416 108 890	
	mél : hisham.khartabil@gmail.com