Groupe de travail Réseau	R. Gellens, QUALCOMM Inc.
Request for Comments : 5423	C. Newman, Sun Microsystems
Catégorie : Sur la voie de la normalisation	mars 2009
Traduction Claude Brière de L'Isle	

Événements de mémorisation de message Internet

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.

Le présent document peut contenir des matériaux provenant de documents de l’IETF ou de contributions à l’IETF publiées ou rendues disponibles au public avant le 10 novembre 2008. La ou les personnes qui ont le contrôle des droits de reproduction sur tout ou partie de ces matériaux peuvent n’avoir pas accordé à l’IETF Trust le droit de permettre des modifications de ces matériaux en dehors du processus de normalisation de l’IETF. Sans l’obtention d’une licence adéquate de la part de la ou des personnes qui ont le contrôle des droits de reproduction de ces matériaux, le présent document ne peut pas être modifié en dehors du processus de normalisation de l’IETF, et des travaux dérivés ne peuvent pas être créés en dehors du processus de normalisation de l’IETF, excepté pour le formater en vue de sa publication comme RFC ou pour le traduire dans une autre langue que l’anglais.

Résumé
Une des caractéristiques manquantes des normes existantes de la messagerie Internet est une facilité de notification d'événements de serveur à serveur et de serveur à client relative aux événements de mémorisation de message. Alors que la portée de la messagerie Internet s'étend pour prendre en charge plus de supports divers (comme la messagerie vocale) et d'appareils (comme des téléphones cellulaires) et pour fournir de riches interactions avec d'autres services (comme des portails de la Toile et des systèmes de conformité légale) le besoin s'accroît d'un système de notification interopérable. Le présent document tente d'énumérer les types d'événements qui intéressent les vrais consommateurs d'un tel système.

Le présent document décrit les événements et paramètres d'événements utilisés dans plusieurs cas, incluant des notifications aux systèmes administratifs et aux utilisateurs finaux. Il n'est pas destiné à remplacer une facilité d'accès au message comme IMAP.
Table des matières
1. Introduction	2
1.1 Conventions utilisées dans le document	2
2. Terminologie	2
3. Modèle d'événement	3
4. Types d'événements	3
4.1 Ajout et suppression de message	3
4.2 Fanions de message	4
4.3 Comptabilité d'accès	4
4.4 Gestion de boîte aus lettres	5
5. Paramètres d'événement	5
6. Considérations relatives à l’IANA	7
7. Considérations sur la sécurité	7
8. Remerciements	7
9. Références	8
9.1 Références normatives	8
9.2 Références pour information	8
Appendice A. Futures extensions	8
Adresse des auteurs	9

 	1.	Introduction

Une mémorisation de messages est utilisée pour organiser les messages Internet [RFC5322] dans une ou plusieurs boîtes aux lettres (éventuellement hiérarchiques) les annoter de diverses façons, et donner accès à ces messages et métadonnées associées. Trois différents protocoles fondés sur des normes sont largement déployés pour donner accès à distance au magasin de messages. Le protocole Post Office (POP, Post Office Protocol) [RFC1939] fournit un accès simple de téléchargement et suppression à un seul dépôt de messages (qui est un sous ensemble de la fonction normalement associée à un magasin de messages). Le protocole d'accès au message Internet (IMAP, Internet Message Access Protocol) [RFC3501] fournit un modèle extensible riche en caractéristiques pour l'accès en ligne, hors ligne, et hors connexion à une mémorisation de messages avec des contraintes minimales sur toute interface d'utilisateur associée de "gros client". Finalement, les applications d'accès à la messagerie construites sur le protocole de transfert hypertexte (HTTP, Hypertext Transfer Protocol) [RFC2616] qui fonctionnent dans les navigateurs de la Toile normalisés fournissent un troisième mécanisme d'accès fondé sur les normes pour l'accès seulement en ligne.

Bien que des mécanimses simples et/ou ad-hoc pour les notifications aient suffi à un certain degré dans le passé (par exemple, "Notification simple de nouveau message" [RFC4146], "Commande IMAP4 IDLE" [RFC2177]) comme la portée et l'importance des mémorisations de messages s'étend, la demande d'un système de magasins de notifications plus complet augmente. Certaines des forces derrière cette demande incluent :
o	Les appareils mobiles avec une connexité intermittente au réseau qui ont des indicateurs de "nouveau message" ou "compte de messages".
o	Les systèmes unifiés de messagerie qui incluent à la fois l'Internet et la messagerie vocale exigent la prise en charge d'un indicateur de message en attente sur les téléphones.
o	L'interaction avec les systèmes pour la facturation fondée sur l'événement ou le calcul d'utilitaires.
o	La simplification du traitement du passage des événements de mémorisation de message à des systèmes de notification  non Internet.
o	Un système de calendrier peut souhaiter s'abonner aux notifications de MessageNew afin de prendre en charge iMIP [RFC2447].
o	Certaines juridictions ont des lois ou règlements pour la protection de l'information et l'audit qui exigent des protocoles interopérables entre magasins de messages construits par des experts de messagerie et des systèmes d'examen de conformité construits par des experts en conformité.

Les fabricants qui ont déployé des systèmes de notification propriétaires pour leurs mémorisations de messages Internet ont vu une demande significative pour fournir des notifications pour de plus en plus d'événements. Comme première étape vers la construction d'un système de notifications, le présent document tente d'énumérer les principaux événements que demandent les consommateurs réels.

Le présent document inclut les événements qui peuvent être générés par l'utilisation de IMAP4rev1 [RFC3501] et certaines extensions existantes. Lorsque de nouvelles extensions IMAP seront définies, ou que des types ou paramètres supplémentaires d'événements devront être ajoutés, l'ensemble spécifié ici pourra être étendu au moyen d'un registre de l'IANA avec des exigences de mise à jour, comme spécifié à la Section 6.

 	1.1	Conventions utilisées dans le document
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]. Quand ces mots apparaissent en minuscule ou avec une lettre initiale en majuscule, ce ne sont pas des mots clés de la RFC 2119.

 	2.	Terminologie

Les termes suivants sont utilisés dans ce document :

boîte aux lettres : un conteneur pour les messages Internet et/ou les boîtes aux lettres filles. Une boîte aux lettres peut ou non permettre de livrer de nouveaux messages via un agent de livraison de messagerie.

identifiant de boîte aux lettres : un identifiant de boîte aux lettres fournit des informations suffisantes pour identifier une boîte aux lettres spécifique sur une instance de serveur spécifique. Un URL IMAP peut être un identifiant de boîte aux lettres.

protocoles d'accès au message : protocoles qui fournissent aux clients (par exemple, un agent d'utilisateur de messagerie ou un navigateur de la Toile) l'accès à la mémorisation de message, incluant mais sans se limiter à IMAP, POP, et HTTP.

contexte de message : comme défini dans la [RFC3458].

UIDVALIDITY : comme défini dans IMAP4rev1 [RFC3501]. UIDVALIDITY est critique pour le fonctionnement correct d'une antémémoire de client de messagerie. Quand il change, le client DOIT purger son antémémoire. Il est particulièrement important d'inclure UIDVALIDITY avec les notifications d'événements relatives à l'ajout ou suppression de message afin de garder les données de message correctement synchronisées.

 	3.	Modèle d'événement

Les événements qui sont générés par une mémorisation de message dépendent dans une certaine mesure du modèle utilisé pour représenter une mémorisation de message. Le modèle qu'a l'IETF pour une mémorisation de message est implicite d'après IMAP4rev1 et ses extensions, de sorte que ce modèle est supposé par le présent document.

Un événement de mémorisation de message a normalement un nom de boîte aux lettres associé et a généralement un nom d'utilisateur associé (ou une identité d'autorisation si on utilise la terminologie de "Simple authentification et couche de sécurité" (SASL) [RFC4422]). Les événements qui se réfèrent à un message spécifique peuvent utiliser un URI IMAP [RFC5092] pour faire cela. Les événements qui se réfèrent à un ensemble de messages peuvent utiliser un ensemble d'URL IMAP pour la boîte aux lettres plus un identifiant unique (UID, Unique Identifier) IMAP.

Chaque notification a un type et des paramètres. Le type détermine le type d'événement, tandis que les paramètres fournissent des informations sur le contexte de l'événement qui peuvent être utilisées pour ajuster les préférences d'abonnement ou peuvent simplement fournir des données associées à l'événement. Les noms de types et de paramètres dans ce document sont restreints aux caractères US-ASCII imprimables, afin que ces événements puissent être facilement transposés en un système de notification arbitraire. Cependant, le présent document suppose que des valeurs de paramètre arbitraires (incluant des valeurs grandes et multi lignes) peuvent être codées avec le système de notification. Les systèmes qui ne disposent pas de cette caractéristique pourraient seulement mettre en œuvre un sous ensemble de ces événements.

Le présent document n'indique pas quels paramètres d'événement sont obligatoires ou facultatifs. Cela est fait dans les documents qui spécifient les formats ou liens de message spécifiques d'un système de notification.

Pour des raisons d'adaptabilité, un certain degré de filtrage est nécessaire à la génération d'événement. Au minimum, la capacité d'activer et désactiver des groupes d'événements en relations et de supprimer l'inclusion de grands paramètres (comme messageContent) est nécessaire. Un système de notification sophistiqué de publication/abonnement peut être capable de propager des informations d'abonnement cumulatives à l'éditeur.

Certains de ces événements pourraient être logiquement concentrés en un seul type d'événement avec un paramètre exigé pour distinguer entre les cas (par exemple, QuotaExceed et QuotaWithin). Cependant, tant qu'un modèle d'abonnement d'événement n'est pas formulé, il n'est pas pratique de prendre de telles décisions. On note donc seulement le fait que certains de ces événements peuvent être vus comme un seul type d'événement.

 	4.	Types d'événements

Cette Section discute des différents types d'événements utiles dans un système de notification d'événement de mémorisation de message. L'intention est de documenter les événements suffisants pour couvrir une écrasante majorité de cas d'utilisation connus tout en laissant les types d'événements moins courants pour l'avenir. Cette Section mentionne des paramètres qui sont importants ou spécifiques des événements décrits ici. Les paramètres d'événement qui vont probablement être inclus dans la plupart ou toutes les notifications sont discutés dans la section suivante.

 	4.1	Ajout et suppression de message
Ce paragraphe inclut les événements relatifs à l'ajout et la suppression de message.

MessageAppend : un message a été ajouté ou enchaîné dans une boîte aux lettres par un client d'accès au message. Pour l'essentiel, c'est identique au type d'événement MessageNew sauf que les informations d'enveloppe SMTP ne sont pas incluses comme paramètre, mais comme informations sur quel protocole a déclenché l'événement. Voir l'événement MessageNew pour plus d'informations.

MessageExpire : un ou plusieurs messages ont expiré dans une boîte aux lettres du fait de la politique d'expiration du serveur et ne sont plus accessibles à l'utilisateur final. Le paramètres inclut un identifiant de boîte aux lettres qui DOIT inclure un UIDVALIDITY et un UID établi qui décrivent les messages. Des informations sur quelle politique d'expiration du serveur a été appliquée pourraient être incluses à l'avenir.

MessageExpunge : un ou plusieurs messages ont été purgés d'une boîte aux lettres par un IMAP CLOSE/EXPUNGE, POP3 DELE+QUIT, HTTP, ou action de client équivalente et ne sont plus accessibles à l'utilisateur final. Les paramètres incluent un identifiant de boîte aux lettres qui DOIT inclure UIDVALIDITY, un UID établi, et peut aussi indiquer quel protocole d'accès a déclenché l'événement.

MessageNew : un nouveau message a été reçu dans une boîte aux lettres via un agent de livraison de message. Les paramètres incluent un identifiant de message qui, pour les mémorisations de message accessibles par IMAP, DOIVENT inclure UIDVALIDITY et un UID. Les paramètres peuvent aussi inclure une enveloppe SMTP et d'autres messages arbitraires et métadonnées de boîte aux lettres. Dans certains cas, le nouveau message entier lui-même peut être inclus. L'ensemble de paramètres DEVRAIT être ajustable aux préférences du client, dans des limites établies par la politique du serveur. Une politique intéressante, par exemple, serait d'inclure des messages de taille jusqu'à 2k avec la notification, mais d'inclure une référence URLAUTH [RFC4467] pour les messages plus grands.

QuotaExceed : une opération a échoué (normalement MessageNew) parce que la boîte aux lettres de l'utilisateur excédait un des quotas (par exemple, quota de disque, de messages, quota par contexte de message, etc.). Les paramètres DEVRAIENT inclure au moins l'utilisateur pertinent et les quotas et, facultativement, la boîte aux lettres. Les quotas d'usage DEVRAIENT être inclus si possible. Les paramètres nécessaires pour étendre cela pour prendre en charge les quotas par contexte ne sont pas présentement décrits dans ce document mais pourraient être ajoutés à l'avenir.

QuotaWithin : une opération s'est produite (normalement MessageExpunge ou MessageExpire) qui a réduit le quota d'usage de l'utilisateur sous la limite.

QuotaChange : Le quota de l'utilisateur a changé.

 	4.2	Fanions de message
Ce paragraphe inclut les événements relatifs aux changements des fanions de message.

MessageRead : un ou plusieurs messages dans la boîte aux lettres ont été marqués comme lus ou vus par un utilisateur. Noter que POP n'a pas de concept de messages lus ou vus, de sorte que ces événements sont seulement générés par les clients IMAP ou HTTP (ou l'équivalent). Les paramètres incluent un identifiant de boîte aux lettres et un ensemble d'UID de message.

MessageTrash : un ou plusieurs messages ont été marqués pour future suppression par l'utilisateur mais sont encore accessibles par le protocole (le client d'utilisateur peut ou non rendre ces messages accessibles par son interface d'utilisateur). Les paramètres incluent un identifiant de boîte aux lettres et un ensemble d'UID de message.

FlagsSet : un ou plusieurs messages dans la boîte aux lettres avaient un ou plusieurs fanions IMAP ou mots clés établis. Les paramètres incluent une liste de fanions IMAP ou de noms de mots clés qui étaient établis, un identifiant de boîte aux lettres, et l'ensemble des UID des messages affectés. Le flagNames NE DOIT PAS inclure \Recent. Pour la compatibilité avec les clients plus simples, il DEVRAIT être configurable même si l'établissement des fanions \Seen ou \Deleted résulte en cet événement ou en les plus simples événements MessageRead/MessageTrash. Par défaut, les plus simples formes de message DEVRAIENT être utilisées pour MessageRead et MessageTrash.

FlagsClear : un ou plusieurs messages dans la boîte aux lettres avaient un ou plusieurs fanions IMAP ou mots clés à zéro. Les paramètres incluent une liste de fanions IMAP ou noms de mots clés qui étaient à zéro, un identifiant de boîte aux lettres, et l'ensemble des UID des messages affectés. Le paramètre flagNames NE DOIT PAS inclure \Recent.

 	4.3	Comptabilité d'accès
Ce paragraphe fait la liste des événements relatifs à la comptabilité d'accès à la mémorisation de message.

Login : un utilisateur s'est enregistré dans le système via IMAP, HTTP, POP, ou quelque autre mécanisme. Les paramètres incluent le nom de domaine et l'accès utilisé pour accéder au serveur et à l'identité d'autorisation de l'utilisateur. Des paramètres supplémentaires possibles incluent l'adresse IP et l'accès du client, l'identité d'authentification (si elle est différente de l'identité d'autorisation) le nom de service, le mécanisme d'authentification, des informations sur toutes couches de sécurité négociées, un horodatage, et autres informations.

Logout : un utilisateur s'est désenregistré ou à été autrement déconnecté de la mémorisation de message via IMAP, HTTP, POP, ou quelque autre mécanisme. Les paramètres incluent le nom de domaine du serveur et l'identité d'autorisation de l'utilisateur. Des paramètres supplémentaires peuvent inclure toute information provenant de l'événement "Login" ainsi que des informations sur le type de déconnexion (les valeurs suggérées incluent "graceful" (en douceur), "abort" (interruption), "timeout" (fin de temporisation) et erreur de couche de sécurité) la durée de la connexion ou session, et d'autres informations.

 	4.4	Gestion de boîte aus lettres
Ce paragraphe fait la liste des événements relatifs à la gestion des boîtes aux lettres.

MailboxCreate : une boîte aux lettres a été créée, ou un contrôle d'accès a changé sur une boîte aux lettres existante de sorte qu'elle est maintenant accessible à l'utilisateur. Si la création de boîte aux lettres a causé la création de novelles boîtes aux lettres plus haut dans la hiérarchie, des événements MailboxCreate séparés ne sont pas générés, car leur création est implicite. Les paramètres incluent l'identifiant de la boîte aux lettres créée, son UIDVALIDITY pour les magasins de message accessibles par IMAP, et peuvent aussi indiquer quel protocole d'accès a déclenché l'événement. Les informations d'accès et de permissions (comme des réglages de liste de contrôle d'accès (ACL, Access Control List) [RFC4314]) exigent un format normalisé pour être inclus, et sont donc laissés pour une future extension.

MailboxDelete : une boîte aux lettres a été supprimée, ou un contrôle d'accès a changé sur une boîte aux lettres existante de sorte qu'elle n'est plus accessible à l'utilisateur. Noter que si la boîte aux lettres a des boîtes aux lettres filles, seule la boîte aux lettres spécifiée a été supprimée, pas les filles. La boîte aux lettres devient \NOSELECT, et la hiérarchie reste inchangée, conformément à la description de la commande DELETE dans IMAP4rev1 [RFC3501]. Les paramètres incluent l'identifiant de la boîte aux lettres supprimée et peuvent aussi indiquer quel protocole d'accès a déclenché l'événement.

MailboxRename : une boîte aux lettres a été renommée. Noter que, selon la description de la commande RENAME dans IMAP4rev1 [RFC3501], une sémantique particulière concernant la hiérarchie de boîtes aux lettres s'applique quand INBOX est renommé (les boîtes aux lettres filles sont généralement incluses dans le changement de dénomination, mais sont exclues quand INBOX est renommée). Quand une boîte aux lettres autre que INBOX est renommée et que par suite ses boîtes aux lettres filles sont aussi renommées, des événements MailboxRename séparés ne sont pas générés pour les boîtes aux lettres filles, car leur changement de dénomination est implicite. Si le changement de nom a causé la création de nouvelles boîtes aux lettres plus haut dans la hiérarchie, des événements MailboxCreate séparés ne sont pas générés pour elles, car leur création est implicite. Quand INBOX est renommée, une nouvelle INBOX est créée. Un événement MailboxCreate n'est pas généré pour la nouvelle INBOX, car il est implicite. Les paramètres incluent le vieil identifiant de boîte aux lettres, le nouvel identifiant de boîte aux lettres, et peuvent aussi indiquer quel protocole d'accès a déclenché l'événement.

MailboxSubscribe : une boîte aux lettres a été ajoutée à la liste d'abonnements mémorisée par le serveur, comme celle gérée par les commandes IMAP SUBSCRIBE et UNSUBSCRIBE. Les paramètres incluent l'utilisateur dont la liste d'abonnements a été affectée, l'identifiant de la boîte aux lettres, et peut aussi indiquer quel protocole d'accès a déclenché l'événement.

MailboxUnSubscribe : une boîte aux lettres a été supprimée de la liste d'abonnements. Les paramètres incluent l'utilisateur dont la liste d'abonnements a été affectée, l'identifiant de boîte aux lettres, et peuvent aussi indiquer quel protocole d'accès a déclenché l'événement.

 	5.	Paramètres d'événement

Cette section fait la liste des paramètres inclus avec ces événements.

admin : inclus avec tous les événements générés par les protocoles d'accès aux messages. C'est l'identité d'authentification associée à cet événement, distincte de l'identité d'autorisation (voir "utilisateur"). Ce n'est pas inclus quand c'est la même que la valeur du paramètre "user".

bodyStructure : peut être inclus avec MessageAppend et MessageNew. C'est la BODYSTRUCTURE IMAP du message.

clientIP : inclus avec tous les événements générés par les protocoles d'accès aux messages. C'est l'adresse IPv4 ou IPv6 du client d'accès à la mémorisation de message qui a effectué l'action déclenchant la notification.

clientPort : inclus avec tous les événements générés par les protocoles d'accès aux messages. C'est le numéro d'accès du client d'accès à la mémorisation de message qui a effectué une action déclenchant la notification (l'accès d'où la connexion s'est produite).

diskQuota : inclus avec les notifications QuotaExceed, QuotaWithin, et QuotaChange relatives au quota de disque d'utilisateur ou de boîte aux lettres. Peut être inclus avec d'autres notifications. C'est la limite du quota de disque en kilo octets (1024 octets).

diskUsed : inclus avec les notifications QuotaExceed et QuotaWithin relatives au quota de disque de l'utilisateur ou boîte aux lettres. Il peut être inclus avec d'autres notifications. C'est l'espace de disque utilisé en kilo octets (1024 octets). Seul l'espace de disque qui compte dans le quota est inclus.

envelope : peut être inclus avec la notification MessageNew. C'est l'enveloppe de transfert de message associée à la livraison finale du message pour la notification MessageNew. Cela inclut le MAIL FROM et la ou les lignes pertinentes RCPT TO utilisées pour la livraison finale avec les délimiteurs CRLF et tous les paramètres ESMTP.

flagNames : inclus avec les événements FlagsSet et FlagsClear. Peut être inclus avec MessageAppend et MessageNew pour indiquer, respectivement, les fanions qui étaient établis initialement par la commande APPEND, ou l'agent de livraison. Une liste (probablement séparée par des espaces) de fanions IMAP ou de noms de mots clés qui étaient établis ou mis à zéro. Les noms de fanion commencent par une barre oblique inverse mais pas les mots clés. Le fanion \Recent est explicitement interdit dans la liste.

mailboxID : inclus dans les événements qui affectent les boîtes aux lettres. C'est un URI qui décrit la boîte aux lettres. Dans le cas de MailboxRename, cela se réfère au nouveau nom.

maxMessages : inclus avec les notifications QuotaExceed et QuotaWithin relatives au quota de compte de messages d'un utilisateur ou d'une boîte aux lettres. Il peut être inclus avec d'autres notifications. C'est la limite du quota sur le nombre de messages dans la boîte aux lettres, pour les événements qui se réfèrent à une boîte aux lettres.

messageContent : peut être inclus avec MessageAppend et MessageNew. C'est le message entier lui-même. Sa suppression fondée sur la taille DEVRAIT être disponible.

messageSize : peut être inclus avec MessageAppend et MessageNew. C'est la taille du message de la RFC 5322 lui-même en octets. Cette valeur correspond à la longueur du littéral IMAP retourné dans la réponse à un IMAP FETCH de BODY[] pour le message référencé.

messages : inclus avec les notifications QuotaExceed et QuotaWithin relatives au quota de compte de messages d'un utilisateur ou d'une boîte aux lettres. Il peut être inclus avec d'autres notifications. C'est le nombre de messages dans la boîte aux lettres. C'est normalement inclus avec des événements d'ajout et suppression de message.

modseq : peut être inclus avec toute notification se référant à un message. C'est l'entier de 64 bits MODSEQ comme défini dans la [RFC4551]. Aucune hypothèse sur MODSEQ ne peut être faite si il est omis.

oldMailboxID : URI décrivant l'ancien nom d'une boîte aux lettres renommée ou déplacée.

pid : peut être inclus avec toute notification. C'est l'identifiant de processus du processus qui a généré la notification.

process : peut être inclus avec toute notification. C'est le nom du processus qui a généré la notification.

serverDomain : inclus dans Login et facultativement dans Logout ou autres événements. C'est le nom de domaine ou l'adresse IP (v4 ou v6) utilisé pour accéder au serveur ou à la boîte aux lettres.

serverPort : inclus dans Login et facultativement dans Logout ou autres événements. C'est le numéro d'accès utilisé pour accéder au serveur. C'est souvent un accès bien connu.

serverFQDN : peut être inclus avec toute notification. C'est le nom de domaine pleinement qualifié du serveur qui a généré l'événement. Noter qu'il peut être différent du nom de serveur utilisé pour accéder à la boîte aux lettres incluse dans l'identifiant de boîte aux lettres.

service : peut être inclus avec toute notification. C'est le nom du service qui a déclenché l'événement. Les valeurs suggérées incluent "imap", "pop", "http", et "admincli" (pour un client administratif).

tags : peut être inclus avec toute notification. C'est une liste d'étiquettes UTF-8 (probablement séparées par des virgules). Une ou plusieurs étiquettes peuvent être établies au moment de la création d'un critère de notification ou d'un abonnement de notification. Les abonnés peuvent utiliser les étiquettes pour un filtrage supplémentaire côté client ou pour un affichage des événements.

timestamp : peut être inclus avec toute notification. C'est l'heure à laquelle se produit l'événement qui a déclenché la notification (le protocole sous-jacent qui porte la notification peut contenir un horodatage de quand la notification a été générée). Cela peut être une heure approximative. Les horodatages sont exprimés en heure locale et contiennent le décalage à l'UTC (cette information est utilisée en plusieurs endroits de la messagerie Internet) et sont normalement dans le format de la [RFC3339].

uidnext : peut être inclus dans toute notification se référant à une boîte aux lettres. C'est l'UID qu'il est projeté d'allouer ensuite dans la boîte aux lettres. C'est normalement inclus avec les événements d'ajout et suppression de message. C'est équivalent à l'élément d'état UIDNEXT dans la commande IMAP STATUS.

uidset : inclus avec MessageExpires, MessageExpunges, MessageRead, MessageTrash, FlagsSet, et FlagsClear. Cela inclut l'ensemble d'UID IMAP référencés.

uri : inclus avec toutes les notifications. C'est une référence au serveur IMAP, à une boîte aux lettres, ou à un message. Normalement c'est un URI IMAP. Cela peut inclure le nom du serveur utilisé pour accéder à la boîte aux lettres/message, le nom de la boîte aux lettres, le UIDVALIDITY de la boîte aux lettres, et l'UID d'un message spécifique.

user : inclus avec tous les événements générés par les protocoles d'accès aux messages. C'est l'identifiant d'autorisation utilisé quand le client se connecte au protocole d'accès qui a déclenché l'événement. Certains protocoles (par exemple, de nombreux mécanismes SASL) distinguent entre identifiant d'autorisation et identifiant d'authentification. Pour les événements associés à une boîte aux lettres, ce peut être différent du propriétaire de la boîte aux lettres spécifié dans l'URL IMAP.

 	6.	Considérations relatives à l’IANA

L'IANA a créé un nouveau registre pour les "événements de mémorisation de message Internet" qui contient deux sous-registres : noms d'événement et paramètres d'événement. Pour les noms d'événement et les paramètres d'événement, les entrées qui ne commencent pas par "vnd." sont ajoutées par l'IETF et sont destinées à une utilisation interopérable. Les entrées qui commencent par "vnd." sont destinées à une utilisation privée par une ou plusieurs parties et sont allouées pour éviter des collisions.

Les valeurs initiales sont contenues dans ce document.

En utilisant la terminologies des considérations relatives à l'IANA [RFC5226], les entrées qui ne commencent pas par "vnd." sont allouées par consensus de l'IETF, tandis que celles qui commencent par "vnd." sont alloués au premier arrivé, premier servi.

 	7.	Considérations sur la sécurité

Les notifications peuvent produire une grande quantité de trafic et exposer des informations sensibles. Quand les mécanismes de notification sont utilisés pour conserver l'état entre différentes entités, la capacité de corrompre ou manipuler les messages de notification pourrait permettre à un attaquant de moduler l'état de ces entités. Par exemple, si un attaquant était capable de modifier les notifications envoyées d'une mémorisation de message à un serveur d'audit, il pourrait modifier les paramètres "user" et "messageContent" dans les notifications de MessageNew pour créer de fausses entrées d'enregistrement d'audit.

Un protocole de transfert compétent pour les notifications DOIT considérer les questions d'authentification, d'autorisation, de confidentialité, et d'intégrité de message, ainsi que de déni de service. Bien que l'IETF ait des outils adéquats et l'expérience pour traiter ces questions pour les mécanismes qui impliquent seulement une connexion TCP, les protocoles de notification ou de publication/abonnement qui sont plus sophistiqués qu'une seule connexion TCP de bout en bout vont devoir porter une attention supplémentaire à ces questions et équilibrer avec soin les exigences pour déployer avec succès un système avec des considérations de sécurité et de confidentialité.

 	8.	Remerciements

Alexey Melnikov, Arnt Gulbrandsen, et Zoltan Ordogh ont relu ce document et proposé des améliorations. Richard Barnes a fait une revue complète durant le dernier appel.

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

[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

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

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

 	9.2	Références pour information

[RFC1939]	J. Myers, M. Rose, "Protocole Post Office - version 3", mai 1996. (MàJ par RFC1957, 2449, 8314) (STD0053)

[RFC2177]	B. Leiba, "Commande IDLE dans IMAP4", juin 1997. (P.S.)

[RFC2447]	F. Dawson, S. Mansour, S. Silverberg, "Protocole d'interopérabilité iCalendar fondé sur le message (iMIP)", novembre  1998. (P.S., Obsolète, voir RFC6047)

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

[RFC3339]	G. Klyne, C. Newman, "La date et l'heure sur l'Internet : horodatages", juillet 2002. (P.S.)

[RFC3458]	E. Burger et autres, "Contexte de message pour la messagerie Internet", janvier 2003. (MàJ par RFC3938) (P.S.)

[RFC4146]	R. Gellens, "Notification simple de nouveau message", août 2005. (Information)

[RFC4314]	A. Melnikov, "Extension IMAP4 de liste de contrôle d'accès (ACL)", décembre 2005. (Remplace RFC2086) (P.S.)

[RFC4422]	A. Melnikov et K. Zeilenga, éd, "Authentification simple et couche de sécurité (SASL)", juin 2006. (P.S.)

[RFC4467]	M. Crispin, "Protocole d'accès au message Internet (IMAP) - Extension URLAUTH", mai 2006. (P.S. ; MàJ par RFC5092)

[RFC4551]	A. Melnikov, S. Hole, "Extension à IMAP pour l'opération STORE conditionnelle ou la resynchronisation des changements rapides de fanion", juin 2006. (P.S.  ; MàJ RFC3501 ; Remplacée par RFC7162)

[RFC5322]	P. Resnick, éd., "Format du message Internet", octobre 2008.(D.S.  ; Remplace RFC2822 ; MàJ RFC4021)

 	Appendice A.	Futures extensions

Le présent document spécifie le cœur des fonctions fondées sur les événements qui sont estimés être bien compris, avoir des cas d'utilisation connus, et sont mis en œuvre par au moins une mémorisation de message Internet déployée dans la réalité. (Quelques événements font exception au dernier essai seulement : FlagsSet, FlagsClear, MailboxCreate, MailboxDelete, MailboxRename, MailboxSubscribe, et MailboxUnSubscribe.)

Certains événements ont été suggérés mais sont remis à de futures extensions parce qu'ils ne satisfont pas ces critères. Ces événements incluent des messages qui ont été déplacés à une mémorisation d'archive et peuvent exiger plus de temps pour y accéder, des quotas par contexte de message, un échec d'authentification, un compte de messagerie d'utilisateur désactivé, des annotations, et un changement d'ACL de boîte aux lettres ou de métadonnées. Les descriptions de plusieurs événements notent des paramètres supplémentaires qui sont probablement des candidats pour une future inclusion. Voir à la Section 6 comment la liste des événements et paramètres peut être étendue.

Afin de restreindre la portée de ce document à quelque chose qui peut être achevé, seuls les événements générés de la mémorisation de message (par un module d'accès au message, un module administratif, ou un agent de livraison de message) sont considérés. Un système de messagerie complet est normalement lié à un système d'identité qui va aussi publier les événements intéressants pour un abonné aux événements de mémorisation de message. Les événements intéressants incluent le compte créé/supprimé/désactivé et le mot de passe changé/expiré.

 	Adresse des auteurs

Randall Gellens	Chris Newman	
QUALCOMM Incorporated	Sun Microsystems	
5775 Morehouse Drive	800 Royal Oaks	
San Diego, CA  92651	Monrovia, CA  91016-6347	
USA	USA	
mél : rg+ietf@qualcomm.com	mél : chris.newman@sun.com