Groupe de travail Réseau	P. Saint-André, Cisco
Request for Comments : 5437	A. Melnikov, Isode Limited
Catégorie : Sur la voie de la normalisation	janvier 2009
	Traduction Claude Brière de L'Isle

Mécanisme de notification Sieve : protocole extensible de messagerie et de présence (XMPP)

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é
Le présent document décrit un profil d'extension Sieve pour les notifications, pour permettre que les notifications soient envoyées sur le protocole extensible de messagerie et de présence (XMPP, Extensible Messaging et Presence Protocol), aussi appelé "Jabber".
Table des matières
1. Introduction	1
1.1 Vue d'ensemble	1
1.2 Terminologie	2
2. Définition	2
2.1 Paramètre Notify "method"	2
2.2 Essai notify_method_capability	2
2.3 Étiquette Notify ":from"	2
2.4 Étiquette Notify ":importance"	2
2.5 Étiquette Notify ":message"	2
2.6 Étiquette Notify ":options"	2
2.7 Syntaxe de XMPP 	3
3. Exemples	3
3.1 Action de base	3
3.2 Action avec "body"	4
3.3 Action avec "body", ":importance", ":message", et "subject"	4
3.4 Action avec ":from", ":message", ":importance", "body", et "subject"	5
4. Exigences de conformité	6
5. Considérations d'internationalisation	6
6. Considérations sur la sécurité	7
7. Considérations relatives à l’IANA	7
8. Références	7
8.1 Références normatives	7
8.2 Références pour information	8
Adresse des auteurs	9

 	1.	Introduction
 	1.1	Vue d'ensemble
L'extension de la [RFC5435] au langage de filtrage de messagerie [RFC5228] est un cadre pour la fourniture de notifications en employant des URI pour spécifier le mécanisme de notification. Le présent document définit comment les URI xmpp (voir la [RFC5122]) sont utilisés pour générer des notifications via le protocole extensible de messagerie et de présence (XMPP, Extensible Messaging et Presence Protocol) [RFC3920], qui est largement mis en œuvre dans les technologies de messagerie instantanée Jabber.

 	1.2	Terminologie
Le présent document hérite de la terminologie des [RFC5435], [RFC5228], et [RFC3920]. En particulier, les termes "paramètre" et "étiquette" sont utilisés comme décrit dans la [RFC5435] pour se référer aux aspects de scripts Sieve, et le terme de "clé" est utilisé comme décrit dans la [RFC5122] pour se référer aux aspects d'un URI XMPP.

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

 	2.	Définition
 	2.1	Paramètre Notify "method"
Le paramètre "method" DOIT être un URI conforme au schéma d'URI xmpp (comme spécifié dans la [RFC5122]) et qui identifie un compte XMPP associé à la boîte aux lettres entrante de messagerie électronique. L'URI PEUT inclure l'identifiant de ressource d'une adresse WMPP et/ou la portion de composant d'interrogation d'un URI WMPP, mais NE DEVRAIT PAS inclure un composant d'autorité ou un composant d'identifiant de fragment. L'application traitante DOIT extraire une adresse WMPP de l'URI en accord avec les règles de traitement spécifiées dans la [RFC5122]. L'adresse WMPP résultante DOIT être encapsulée dans la syntaxe WMPP comme la valeur de l'attribut XMPP "to".

 	2.2	Essai notify_method_capability
En réponse à un essai notify_method_capability pour la capacité de notification "online", une mise en œuvre DEVRAIT retourner une valeur de "oui" si elle a connaissance d'une session de présence active (voir la [RFC3921]) pour l'URI de notification XMPP spécifié ; autrement, elle DEVRAIT retourner une valeur de "peut-être" (car les systèmes XMPP normaux peuvent ne pas permettre qu'un moteur Sieve obtienne la connaissance de la présence d'entités XMPP).

 	2.3	Étiquette Notify ":from"
Si elle est incluse, l'étiquette ":from" DOIT être une adresse électronique qui se conforme à la règle "Mailbox" définie dans la [RFC5321]. La valeur de l'étiquette ":from" PEUT être incluse dans les données en caractères XML lisibles par l'homme de la notification XMPP ; autrement ou en plus, elle PEUT être transformée en une syntaxe WMPP formelle, et dans ce cas DOIT être encapsulée comme valeur d'un en-tête XMPP d'en-têtes de strophes et métadonnées Internet (SHIM, Stanza Headers et Internet Metadata) [SHIM] appelé "Resent-From".

 	2.4	Étiquette Notify ":importance"
L'étiquette ":importance" n'a pas de signification particulière pour ce mécanisme de notification, et la présente spécification ne met pas de restriction à son utilisation. La valeur de l'étiquette ":importance" PEUT être transformée en syntaxe WMPP (en plus ou à la place d'inclure un texte approprié dans les données de caractère XML dans l'élément XMPP <body/>) ; si il en est ainsi, elle DEVRAIT être encapsulée comme la valeur d'un en-tête XMPP SHIM [SHIM] appelé "Urgency", où le caractère XML de l'en-tête est "high" si la valeur de l'étiquette ":importance" est "1", "medium" si la valeur de l'étiquette ":importance" est "2", et "low" si la valeur de l'étiquette ":importance" est "3".

 	2.5	Étiquette Notify ":message"
Si l'étiquette ":message" est incluse, cette chaîne DOIT être transformée en les données de caractère XML d'un élément XMPP <body/> (où la chaîne est générée conformément aux lignes directrices spécifiées au paragraphe 3.6 de la [RFC5435]).

 	2.6	Étiquette Notify ":options"
L'étiquette ":options" n'a pas de signification particulière pour ce mécanisme de notification. Tout traitement ce cette étiquette est de la responsabilité d'une mise en œuvre.

 	2.7	Syntaxe de XMPP
Le mécanisme xmpp résulte en l'envoi d'un message XMPP pour notifier à un receveur un message électronique. La syntaxe WMPP générale est la suivante :

o	La notification DOIT être une strophe XMPP <message/>.

o	La valeur de l'attribut XMPP "from" DEVRAIT être l'adresse WMPP du service de notification associé au moteur Sieve ou à l'adresse WMPP de l'entité à notifier. La valeur de l'attribut XMPP "from" NE DOIT PAS être générée à partir de l'étiquette Sieve ":from".

o	La valeur de l'attribut XMPP "to" DOIT être l'adresse WMPP spécifiée dans l'URI WMPP contenu dans le paramètre "method" notify.

o	La valeur de l'attribut XMPP "type" DOIT être "headline" ou "normal".

o	La strophe XMPP <message/> DOIT inclure un élément fils <body/>. Si l'étiquette ":message" est incluse dans le script Sieve, cette chaîne DOIT être utilisée comme données de caractère XML de l'élément <body/>. Sinon et si l'URI WMPP contenu dans le paramètre "method" notify spécifiait une clé "body" dans le composant d'interrogation, cette valeur DEVRAIT être utilisée. Autrement, les données de caractère XML DEVRAIENT être un texte configurable qui indique que le message est une notification Sieve.

o	La strophe XMPP <message/> PEUT inclure un élément fils  <subject/>. Si l'URI WMPP contenu dans le paramètre notify "method" spécifiait une clé "subject" dans le composant d'interrogation, cette valeur DEVRAIT être utilisée comme données de caractère XML de l'élément <subject/>. Autrement, les données de caractère XML DEVRAIENT être un texte configurable qui indique que le message est une notification Sieve.

o	La strophe XMPP <message/> DEVRAIT inclure un URI, pour que le receveur l'utilise comme indication pour localiser le message, encapsulé dans les données de caractère XML d'un élément fils <url/> d'un élément <x/> qualifié par l'espace de noms "jabber:x:oob", comme spécifié dans [OOB]. Si il est inclus, l'URI DEVRAIT être an URL du protocole d'accès au message Internet [RFC3501] qui spécifie la localisation du message, comme défini dans la [RFC5092], mais PEUT être un autre type d'URI qui peut spécifier ou donner une indication sur la localisation d'un message, comme un URI pour une ressource HTTP [RFC2616] ou une boîte aux lettres du protocole Post Office version 3 (POP3) [RFC2384] à laquelle on peut accéder au message. Il n'est pas supposé qu'un agent d'utilisateur XMPP doive traiter directement un tel URI, mais plutôt qu'il devra invoquer une application d'aide appropriée pour traiter l'URI.

o	La strophe XMPP <message/> PEUT inclure un en-tête XMPP SHIM [SHIM] "Resent-From". Si le script Sieve incluait une étiquette ":from", la valeur "Resent-From" DOIT être la valeur de l'étiquette ":from" ; autrement, la valeur "Resent-From" DEVRAIT être l'adresse de receveur d'enveloppe du message original qui a déclenché la notification.

 	3.	Exemples

Dans les exemples, suivants l'envoyeur du message a une adresse de <mailto:juliet@exemple.org>, l'entité à notifier a une adresse de messagerie de <mailto:romeo@exemple.com> et une adresse WMPP de romeo@im.exemple.com (résultant en un URI WMPP de <xmpp:romeo@im.exemple.com>) et le service de notification associé au moteur Sieve a une adresse WMPP de notify.exemple.com.

Note : dans les exemples suivants, des sauts à la ligne sont inclus dans des URI XMPP pour les seuls besoins de lisibilité.

 	3.1	Action de base
Voici une action notify Sieve de base avec une seule méthode. Les données de caractère XML des éléments XMPP <body/> et <subject/> sont donc générés par le moteur Sieve sur la base de la configuration. De plus, le moteur Sieve inclut un URI pointant sur le message.

Action de base (syntaxe Sieve)

notify "xmpp:romeo@im.exemple.com"

La strophe XMPP <message/> résultant pourrait être comme suit :

Action de base (syntaxe WMPP)

<message from='notify.exemple.com'
         to='romeo@im.exemple.com'
         type='headline'
         xml:lang='fr'>
  <subject>SIEVE</subject>
  <body>&lt;juliet@exemple.com&gt; Tu as un message.</body>
  <x xmlns='jabber:x:oob'>
    <url>
      imap://romeo@exemple.com/INBOX;UIDVALIDITY=385759043/;UID=18
    </url>
  </x>
</message>

 	3.2	Action avec "body"
L'action suivante contient une clé "body" dans le composant d'interrogation de l'URI WMPP mais pas d'étiquette ":message" dans le script Sieve. Par suite, les données de caractère XML de l'élément XMPP <body/> dans la notification XMPP sont prises de l'URI WMPP. De plus, le moteur Sieve inclut un URI pointant sur le message.

Action avec "body" (syntaxe Sieve)

     notify "xmpp:romeo@im.exemple.com?message
              ;body=Comment%20vas%20tu%3F"

La strophe résultant de <message/> XMPP pourrait être comme suit.

Action avec "body" (syntaxe WMPP)

     <message from='notify.exemple.com'
              to='romeo@im.exemple.com'
              type='headline'
              xml:lang='fr'>
       <subject>SIEVE</subject>
       <body>Comment vas tu ?</body>
       <x xmlns='jabber:x:oob'>
         <url>
           imap://romeo@exemple.com/INBOX;UIDVALIDITY=385759044/;UID=19
         </url>
       </x>
     </message>

 	3.3	Action avec "body", ":importance", ":message", et "subject"
L'action suivante spécifie une étiquette ":importance" et une étiquette":message" dans le script Sieve, ainsi qu'une clé "body" et une clé "subject" dans le composant d'interrogation de l'URI WMPP. Par suite, l'étiquette ":message" provenant du script Sieve outrepasse la clé "body" provenant de l'URI WMPP quand on génère les données de caractère XML de l'élément <body/> XMPP. De plus, le moteur Sieve inclut un URI pointant sur le message.

Action avec "body", ":importance", ":message", et "subject" (syntaxe Sieve)

     notify :importance "1"
            :message "Contacte Juliette immédiatement !"
            "xmpp:romeo@im.exemple.com?message
              ;body=You%27re%20in%20trouble
              ;subject=ALERT%21"

La strophe XMPP <message/> résultante pourrait être comme suit.

Action avec "body", ":importance", ":message", et "subject" (syntaxe WMPP)

     <message from='notify.exemple.com'
              to='romeo@im.exemple.com'
              type='headline'
              xml:lang='fr'>
       <subject>ALERTE!</subject>
       <body>Contacte Juliette immédiatement !</body>
       <headers xmlns='http://jabber.org/protocol/shim'>
         <header name='Urgency'>high</header>
       </headers>
       <x xmlns='jabber:x:oob'>
         <url>
           imap://romeo@exemple.com/INBOX;UIDVALIDITY=385759045/;UID=20
         </url>
       </x>
     </message>

 	3.4	Action avec ":from", ":message", ":importance", "body", et "subject"
L'action suivante spécifie un étiquette ":from", une étiquette ":importance", et une étiquette ":message" dans le script Sieve, ainsi qu'une clé "body" et une clé "subject" dans le composant d'interrogation de l'URI WMPP. Par suite, l'étiquette ":message" provenant du script Sieve outrepasse la clé "body" provenant de l'URI WMPP quand on génère les données de caractère XML de l'élément XMPP <body/>. De plus, le moteur Sieve inclut un URI pointant sur le message, ainsi qu'un en-tête d'en-têtes de strophe et métadonnées Internet (SHIM, Stanza Headers and Internet Metadata) [SHIM] XMPP appelé "Resent-From" (qui encapsule la valeur de l'étiquette ":from").

Action avec ":from", ":importance", ":message", "body", et "subject" (syntaxe Sieve)

     notify :from "romeo.my.romeo@exemple.com"
            :importance "1"
            :message "Contacte Juliette immédiatement !"
            "xmpp:romeo@im.exemple.com?message
              ;body=You%27re%20in%20trouble
              ;subject=ALERT%21"

La strophe XMPP <message/> résultante pourrait être comme suit.

Action avec ":from", ":importance", ":message", "body", et "subject" (syntaxe WMPP)

     <message from='notify.exemple.com'
              to='romeo@im.exemple.com'
              type='headline'
              xml:lang='fr'>
       <subject>ALERTE !</subject>
       <body>Contacte Juliette immédiatement !</body>
       <headers xmlns='http://jabber.org/protocol/shim'>
         <header name='Resent-From'>romeo.my.romeo@exemple.com</header>
         <header name='Urgency'>high</header>
       </headers>
       <x xmlns='jabber:x:oob'>
         <url>
           imap://romeo@exemple.com/INBOX;UIDVALIDITY=385759045/;UID=21
         </url>
       </x>
     </message>

 	4.	Exigences de conformité

Le paragraphe 3.8 de la [RFC5435] spécifie un ensemble d'exigences pour les méthodes de notification Sieve. La conformité du mécanisme de notification xmpp est la suivante :

1.	Une  mise en œuvre de la méthode de notification xmpp NE DEVRAIT PAS modifier le texte final de la notification (par exemple, en limiter la longueur) ; cependant, un déploiement PEUT le faire (par exemple, si des receveurs payent par caractère ou par octet pour les messages XMPP). La modification des caractères eux-mêmes ne devrait pas être nécessaire, car les données de caractère XMPP sont codées dans la [RFC3629].

2.	Une mise en œuvre PEUT ignorer les paramètres spécifiés dans les étiquettes ":from", ":importance", et ":options".

3.	Il n'y a pas de message recommandé par défaut qu'inclut une mise en œuvre si l'étiquette ":message" n'est pas spécifiée.

4.	Une notification envoyée via la méthode de notification xmpp PEUT inclure un horodatage dans le message textuel.

5.	La valeur de l'attribut XMPP "from" DOIT être l'adresse WMPP du service de notification associé au moteur Sieve. La valeur de l'étiquette Sieve ":from" PEUT être transformée en la valeur d'un en-tête SHIM XMPP [SHIM] nommé "Resent-From".

6.	La valeur de l'attribut XMPP "to" DOIT être l'adresse WMPP spécifiée dans l'URI WMPP contenu dans le paramètre "method".

7.	En accord avec la [RFC5122], une mise en œuvre DOIT ignorer toute action ou clé d'URI qu'elle ne comprend pas (c'est-à-dire, l'URI DOIT être traité comme si l'action ou clé n'était pas présente). Il est RECOMMANDÉ de prendre en charge le type d'interrogation XMPP "message" (voir [QUERIES]) et les clé associées "body" et "subject", qui DEVRAIENT être transposées respectivement en les éléments fils XMPP <body/> et <subject/> de la strophe XMPP <message/>. Cependant, si elle est incluse, l'étiquette Sieve notify ":message" DOIT alors être transposée en l'élément XMPP <body/>, outrepassant la clé "body" (si il y en a une) incluse dans l'URI WMPP.

8.	Une mise en œuvre NE DOIT PAS inclure d'autres informations étrangères non spécifiées dans les paramètres de l'action notify.

9.	En réponse à un essai notify_method_capability pour la capacité de notification "online", une mise en œuvre DEVRAIT retourner une valeur de "oui" si elle a connaissance d'une session de présence active (voir la [RFC3921]) pour l'URI de notification XMPP spécifié, mais seulement si l'entité qui a demandé l'essai est autorisée à connaître la présence de l'entité XMPP associée (par exemple, via un abonnement explicite à présence, comme spécifié dans la [RFC3921]) ; autrement, elle DEVRAIT retourner une valeur de "peut-être" car les systèmes XMPP normaux peuvent ne pas permettre à un moteur Sieve d'obtenir la connaissance de la présence d'entités XMPP).

10.	Une mise en œuvre NE DEVRAIT PAS tenter de réessayer la livraison d'une notification si elle reçoit une erreur XMPP de type "auth" ou "cancel", PEUT tenter de réessayer la livraison si elle reçoit une erreur XMPP de type "wait", et PEUT tenter de réessayer la livraison si elle reçoit une erreur XMPP de "modify", mais seulement si elle fait les modifications appropriées à la notification (voir la [RFC3920]) ; dans tous les cas, le nombre d'essais DEVRAIT être limité à un nombre configurable de pas moins de 3 et pas plus de 10. Une mise en œuvre PEUT réduire les notifications si le nombre de notifications dans la période donnée devient excessif selon la politique de service locale. La suppression des dupliqués (si il en est) est l'affaire de la mise en œuvre et n'est pas spécifiée ici.

 	5.	Considérations d'internationalisation

Bien qu'une adresse WMPP puisse contenir presque tout caractère [UNICODE], la valeur du paramètre "method" DOIT être un identifiant de ressource universel (voir la [RFC3986]) plutôt qu'un identifiant de ressource internationalisé (voir la [RFC3987]). Les règles spécifiées dans la [RFC5122] DOIVENT être suivies lors de la génération des URI XMPP.

En accord avec la Section 13 de la RFC 3920, toutes les données envoyées sur XMPP DOIVENT être codées selon la [RFC3629].

 	6.	Considérations sur la sécurité

Selon les informations incluses, l'envoi d'une notification peut être comparable à la transmission d'un message au receveur de la notification. Il faut faire attention quand on transmet automatiquement un message, de s'assurer que des informations confidentielles ne sont pas envoyées dans un environnement non sûr. En particulier, les mises en œuvre DOIVENT se conformer aux considérations sur la sécurité données dans les [RFC5435], [RFC5228], et [RFC3920].

La [RFC5435] spécifie qu'une méthode de notification DOIT fournir des mécanismes pour éviter des boucles de notifications. Un type de boucle de notification peut être causé par la transmission de message ; cependant, de telles boucles sont empêchées parce que XMPP ne prend pas en charge la transmission de messages provenant d'une adresse WMPP à une autre. Un autre type de boucle de notification peut être causé par des auto-réponses aux messages XMPP reçus par le service de notification XMPP associé au moteur Sieve ; donc, un tel service NE DOIT PAS auto-répondre aux messages XMPP qu'il reçoit.

Un cas d'utilisation courant pourrait être qu'un utilisateur crée un script qui permette au moteur Sieve d'agir différemment si l'utilisateur est actuellement disponible pour un type particulier de service (par exemple, l'envoi de notifications à l'adresse WMPP de l'utilisateur si l'utilisateur a une session active à un service XMPP). Si l'utilisateur est actuellement disponible peut être déterminé au moyen d'un essai notify_method_capability pour la capacité de notification "online". Dans XMPP, l'information sur la disponibilité actuelle du réseau est appelée "présence" (voir aussi la [RFC2778]). Comme la [RFC3921] exige qu'un utilisateur approuve un abonnement à présence avant qu'une entité puisse obtenir l'accès aux informations de présence de l'utilisateur, une mise en œuvre limitée mais raisonnablement sûre pourrait être que le moteur Sieve demande un abonnement à la présence de l'utilisateur. L'utilisateur devrait alors approuver cette demande d'abonnement afin que le moteur Sieve puisse agir de façon appropriée selon que l'utilisateur est en ligne ou hors ligne. Cependant, le moteur Sieve NE DOIT PAS utiliser les informations de présence de l'utilisateur quand il traite les scripts au nom du propriétaire d'un script autre que l'utilisateur, sauf si le moteur Sieve a explicitement connaissance (par exemple, via l'intégration avec les règles d'autorisation de présence d'un serveur XMPP) que le propriétaire du script est autorisé à connaître la présence de l'utilisateur. Bien qu'il ne soit pas possible de concevoir une approche plus avancée de la délégation de l'autorisation de présence, une telle approche fera l'objet de futurs travaux de normalisation.

 	7.	Considérations relatives à l’IANA

Le gabarit suivant donne l'enregistrement par l'IANA du mécanisme de notification Sieve spécifié dans ce document :

To : iana@iana.org
Subject : enregistrement d'un nouveau mécanisme de notification Sieve
Nom du mécanisme : xmpp
URI du mécanisme : [RFC5122]
Options spécifiques du mécanisme : aucune
Référence permanente et directement disponible : RFC 5437
Personne et adresse de messagerie à contacter pour plus d'informations : Peter Saint-André <registrar@xmpp.org>

Ces informations ont été ajoutées à la liste des mécanismes de notification Sieve tenue à <http://www.iana.org>.

 	8.	Références
 	8.1	Références normatives

[OOB]	Saint-André, P., "Out of Band Data", XSF XEP 0066, août 2006.

[QUERIES]	Saint-André, P., "URI WMPP Scheme Query Components", XSF XEP 0147, septembre 2006.

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. (MàJ par RFC8174)

[RFC5122]	P. Saint-André, "Identifiants de ressource internationalisés (IRI) et identifiants de ressource uniformes (URI) pour le protocole extensible de messagerie et de présence (XMPP)", février 2008. (Remplace RFC4622) (P.S.)

[RFC5228]	P. Guenther et autres, "Sieve : un langage de filtrage de messagerie électronique", janvier 2008. (P.S. ; Remplace RFC3028, MàJ par RFC5229, 5429 9042)

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

[RFC5435]	A. Melnikov et autres, "Filtrage de messagerie Sieve : extension pour les notifications", janvier 2009. (P.S. ; MàJ par RFC8580)

[SHIM]	Saint-André, P. et J. Hildebrand, "Stanza Headers and Internet Metadata", XSF XEP 0131, juillet 2006.

 	8.2	Références pour information

[RFC2384]	R. Gellens, "Schéma d'URL POP", août 1998. (P.S.)

[RFC2616]	R. Fielding et autres, "Protocole de transfert hypertexte -- HTTP/1.1", juin 1999. (D.S., MàJ par 2817, 6585)

[RFC2778]	M. Day, J. Rosenberg et H. Sugano, "Modèle pour Presence et la messagerie instantanée", février 2000.

[RFC3501]	M. Crispin, "Protocole d'accès au message Internet - version 4rev1", mars 2003. (P.S. ; MàJ par RFC4466, 4469, 4551, 5032, 5182, 7817, 8314, 8437, 8474 ; remplacée par la 9051

[RFC3629]	F. Yergeau, "UTF-8, un format de transformation de la norme ISO 10646", STD 63, novembre 2003, DOI 10.17487/RFC3629.

[RFC3920]	P. Saint-Andre, éd., "Protocole extensible de messagerie et de présence (XMPP) : éléments centraux", octobre 2004. (P.S.) (Remplacée par RFC6120)

[RFC3921]	P. Saint-André, éd., "Protocole extensible de messagerie et de présence (XMPP) : messagerie instantanée et présence", octobre 2004. (P.S.) (Remplacée par RFC6121)

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

[RFC3987]	M. Duerst et M. Suignard, "Identifiant de ressource internationalisé (IRI)", janvier 2005.

[RFC5092]	A. Melnikov et C. Newman, "Schéma d'URL IMAP", novembre 2007. (Remplace RFC2192 ; MàJ RFC4467 ; MàJ par RFC5593) (P.S.)

[UNICODE]	The Unicode Consortium, "The Unicode Standard, Version 3.2.0", 2000.
La norme Unicode, version 3.2.0 est définie par la norme Unicode, version 3.0 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5) telle qu'amendée par la norme Unicode Annexe n° 27 : http://www.unicode.org/reports/tr27/ et Annexe n° 28 : http://www.unicode.org/reports/tr28/ .

 	Adresse des auteurs

Peter Saint-André	Alexey Melnikov	
Cisco	Isode Limited	
mél : psaintan@cisco.com	mél : Alexey.Melnikov@isode.com