Groupe de travail Réseau	A. Gulbrandsen, Oryx Mail Systems GmbH
Request for Comments : 5465	C. King, Isode Ltd.
RFC mise à jour : 5267	A. Melnikov, Isode Ltd.
Catégorie : Sur la voie de la normalisation	février 2009
Traduction Claude Brière de L'Isle

Extension IMAP NOTIFY

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éfinit une extension IMAP qui permet à un client de demander des sortes spécifiques de notifications non sollicitées pour des boîtes aux lettres spécifiées, comme des messages ajoutés ou supprimés de telles boîtes aux lettres.
Table des matières
1. Vue d'ensemble et raisons	2
2. Conventions utilisées dans le document	2
3. Extension NOTIFY	2
3.1 Commande NOTIFY	2
4. Interaction avec la commande IDLE	4
5. Types d'événements	5
5.1 FlagChange et AnnotationChange	5
5.2 MessageNew	6
5.3 MessageExpunge	6
5.4 MailboxName	7
5.6 MailboxMetadataChange	7
5.7 ServerMetadataChange	8
5.8 Débordement de notifications	8
5.9 Changements de liste de contrôle d'accès	8
6. Spécification de boîte aux lettres	8
6.1 Spécificateurs de boîte aux lettres qui affectent la boîte aux lettres choisie	9
6.2 Personal	9
6.3 Inboxes	9
6.4 Subscribed	9
6.5 Subtree	9
6.6 Mailboxes	9
7. Extension aux commandes SEARCH et SORT	9
8. Syntaxe formelle	10
9. Considérations sur la sécurité	11
10. Considérations relatives à l’IANA	12
10.1 Enregistrements initiaux d'élément de données étendus LIST-EXTENDED	12
11. Remerciements	12
12. Références normatives	12
13. Références pour information	13
Adresse des auteurs	13

 	1.	Vue d'ensemble et raisons

La commande IDLE (définie dans la [RFC2177]) donne un moyen pour que le client passe dans un mode où le serveur IMAP pousse ses notifications sur les événements de stockage de messagerie IMAP pour la boîte aux lettres choisie. Cependant, l'extension IDLE ne restreint pas ou ne contrôle pas quels événements de serveur peuvent être envoyés, ou quelles informations le serveur envoie en réponse à chaque événement. Aussi, IDLE s'applique seulement à la boîte aux lettres choisie, exigeant donc une connexion TCP supplémentaire par boîte aux lettres.

Le présent document définit une extension IMAP qui permet aux clients d'exprimer leurs préférences sur des événements  non sollicités générés par le serveur. L'extension permet aux clients de seulement recevoir les événements qui les intéressent, tandis que les serveurs savent qu'il n'ont pas besoin de faire l'effort de générer certains types de réponses non étiquetées.

Sans la commande NOTIFY définie dans le présent document, un serveur IMAP va seulement envoyer des informations sur les changements de la mémorisation de messagerie au client dans les cas suivants :
-	par suite d'une commande du client (par exemple, des réponses FETCH à une commande FETCH ou STORE),
-	comme des réponses non sollicitées envoyées juste avant la fin d'une commande (par exemple, EXISTS ou EXPUNGE) par suite de changements dans d'autres sessions, et
-	durant une commande IDLE.

La commande NOTIFY étend les informations qui peuvent être retournées dans ces deux derniers cas, et aussi permet et exige du serveur qu'il envoie des informations sur les mises à jour entre les commandes. La commande NOTIFY permet aussi au client d'étendre quelles informations sont envoyées non sollicitées sur la boîte aux lettres choisie et de demander l'envoi de mises à jour d'informations concernant d'autres boîtes aux lettres.

L'interaction entre les commandes IDLE et NOTIFY est décrite à la Section 4.

Pour les nouveaux messages livrés ou ajoutés à la boîte aux lettres choisie, la commande NOTIFY peut être utilisée pour demander qu'un ensemble d'attributs soient envoyés au client dans une réponse FETCH non sollicitée. Cela permet au client d'être un receveur passif des événements et nouveaux messages et d'être capable de maintenir une pleine synchronisation sans avoir à produire de nouvelles commandes sauf pour modifier l'état de la boîte aux lettres sur le serveur.

Certains clients mobiles, peuvent cependant vouloir des messages "poussés" seulement pour ceux qui correspondent à un schéma SEARCH. Pour satisfaire ce besoin, la [RFC5267] est augmentée par le présent document pour étendre l'option de retour UPDATE en spécifiant une liste de "fetch-atts" à retourner quand un nouveau message est livré ou ajouté dans une autre session.

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

L'acronyme MSN (Message Sequence Number) signifie numéro de séquence de message (voir le paragraphe 2.3.1.2 de la [RFC3501]).

Les lignes d'exemple qui commencent par "C :" sont envoyées par le client et celles par "S :", par le serveur. "[...]" signifie une élision.

 	3.	Extension NOTIFY

Les serveurs IMAP qui prennent en charge la présente extension annoncent la capacité NOTIFY. Cette extension ajoute la commande NOTIFY comme défini au paragraphe 5.1.

Un serveur qui met en œuvre cette extension n'est pas obligé de mettre en œuvre LIST-EXTENDED [RFC5258], même si un serveur conforme à NOTIFY doit être capable de retourner des réponses LIST étendues, définies dans la [RFC5258].

 	3.1	Commande NOTIFY
Arguments : "SET"
                     Indicateur STATUS facultatif
                     Boîtes aux lettres à observer
                     Événements à notifier au client

Ou
Arguments : "NONE"

Réponses : réponses STATUS éventuellement non étiquetées (pour SET)

Résultat : OK - le serveur va notifier au client comme demandé.
                NO -  événement NOTIFY non pris en charge, NOTIFY trop complexe ou coûteux, etc.
                BAD - Commande inconnue, invalide, non prise en charge, ou a des arguments inconnus.

La commande NOTIFY informe le serveur que le client écoute tout le temps les notifications d'événement (même quand aucune commande n'est en cours) et demande au serveur de lui notifier l'ensemble d'événements spécifié. La commande NOTIFY a deux formes. NOTIFY NONE spécifie que le client n'est intéressé par aucune sorte d'événement se produisant sur le serveur. NOTIFY SET remplace la liste actuelle des événements intéressants par une nouvelle liste d'événements.

Jusqu'à ce que la commande NOTIFY soit utilisée pour la première fois, le serveur envoie seulement des notifications quand une commande est traitée, et notifie ces événements au client sur la boîte aux lettres choisie (voir les définitions à la Section 5) : MessageNew, MessageExpunge, ou FlagChange. Il ne notifie pas au client des événements sur d'autres boîtes aux lettres.

L'effet d'une commande NOTIFY réussie dure jusqu'à la commande NOTIFY suivante ou jusqu'à la clôture de la connexion IMAP.

Une commande NOTIFY SET réussie DOIT causer le retour immédiat par le serveur de tous les changements accumulés à la boîte aux lettres actuellement choisie (si il en est une) comme des changements de fanions et des messages nouveaux ou supprimés. Donc, une commande NOTIFY SET réussie implique une commande NOOP implicite.

La commande NOTIFY SET peut demander des notifications de changements relatifs à des messages sur la boîte aux lettres choisie, quels qu'ils soient au moment où les notifications de message sont générées. Cela est fait en spécifiant le sélecteur de boîte aux lettres SELECTED ou SELECTED-DELAYED (voir le paragraphe 6.1) dans la commande NOTIFY SET. Si le sélecteur de boîte aux lettres SELECTED/SELECTED-DELAYED n'est pas spécifié dans la commande NOTIFY SET, cela signifie que le client ne veut pas recevoir des <événement-de-message> pour la boîte aux lettres actuellement choisie. C'est la même chose que de spécifier SELECTED NONE.

Le client peut aussi demander des notifications sur une autre boîte aux lettres par une correspondance de nom ou de schéma limité de boîte aux lettres. Les notifications relatives au message retournées pour la boîte aux lettres actuellement choisie vont être celles spécifiées par le spécificateur de boîte aux lettres SELECTED/SELECTED-DELAYED ; même si la boîte aux lettres choisie apparaît aussi par nom (ou correspond à un schéma) dans la commande. Les notifications non relatives au message sont contrôlées par les spécificateurs de boîte aux lettres autres que SELECTED/SELECTED-DELAYED.

Si la commande NOTIFY permet les notifications MessageNew, MessageExpunge, AnnotationChange, ou FlagChange pour une boîte aux lettres autre que celle actuellement choisie, et si le client a spécifié le paramètre d'indicateur STATUS, alors le serveur DOIT envoyer une réponse STATUS pour cette boîte aux lettres avant le OK étiqueté du NOTIFY. Si MessageNew est activé, la réponse STATUS DOIT contenir MESSAGES, UIDNEXT, et UIDVALIDITY. Si MessageExpunge est activé, la réponsee STATUS DOIT contenir MESSAGES. Si AnnotationChange ou FlagChange sont inclus et si le serveur prend aussi en charge les extensions CONDSTORE [RFC4551] et/ou QRESYNC [RFC5162], la réponse STATUS DOIT contenir UIDVALIDITY et HIGHESTMODSEQ. L'absence du paramètre d'indicateur STATUS permet au client d'éviter les réponses STATUS supplémentaires. Cela pourrait être utile si le client a déjà récupéré ces informations avant de produire la commande NOTIFY.

Il est conseillé aux clients de limiter le nombre de boîtes aux lettres utilisées avec NOTIFY. En particulier, si un client demande les événements pour toutes les boîtes aux lettres accessibles, le serveur peut submerger le client avec des mises à jour sur les boîtes aux lettres partagées. Cela peut réduire la durée de vie de la batterie du client. Aussi, cela gaspille les ressources du serveur et du réseau.

Pour chaque boîte aux lettres spécifiée, le serveur vérifie que le client a accès en utilisant l'essai suivant :

-	Si le nom ne se réfère pas à une boîte aux lettres existante, le serveur DOIT l'ignorer.

-	Si le nom se réfère à une boîte aux lettres que le client ne peut pas mettre sur LIST, le serveur DOIT l'ignorer. Pour un serveur qui met en œuvre la [RFC4314], cela signifie que si le client n'a pas le droit "l" (recherche) pour le nom, alors le serveur DOIT ignorer la boîte aux lettres. Ce comportement empêche la divulgation d'informations potentiellement confidentielles à des clients qui n'ont pas les droits pour les connaître.

-	Si le nom se réfère à une boîte aux lettres que le client peut mettre dans LIST (par exemple, il a le droit "l" de la [RFC4314]) mais le client n'a pas un autre droit nécessaire pour traiter le ou les événements spécifiés, alors le serveur DOIT répondre avec une réponse LIST non étiquetée étendue contenant l'attribut de nom \NoAccess.

Le serveur DEVRAIT retourner la réponse OK étiquetée si le client a accès à au moins une des boîtes aux lettres spécifiées dans la liste actuelle des événements intéressants. Le serveur PEUT retourner la réponse NO étiquetée si le client n'a pas accès à une des boîtes aux lettres spécifiées et qu'aucun accès ne peut être accordé à l'avenir (par exemple, le client a spécifié un événement pour "Sous arborescence Bar/Foo", "Bar/Foo" n'existe pas, et LIST retourne \Noinferiors pour le parent "Bar").

Si la notification serait d'un coût prohibitif pour le serveur (par exemple, "notifie moi tous les changements de fanion dans toutes les boîtes aux lettres") le serveur PEUT refuser la commande avec une réponse étiquetée NO [NOTIFICATIONOVERFLOW].

Si le client demande des informations pour des événements d'un type non pris en charge, le serveur DOIT refuser la commande avec une réponse NO étiquetée (pas un BAD). Cette réponse DEVRAIT contenir le code de réponse BADEVENT, qui DOIT faire la liste des noms de tous les événements pris en charge par le serveur.

Voici un exemple :

S : * OK [CAPABILITY IMAP4REV1 NOTIFY]
C : a login bob alice
S : a OK Password matched
C : b notify set status (selected MessageNew (uid body.peek[header.fields (from to subject)]) MessageExpunge) (subtree Lists MessageNew)
S : * STATUS Lists/Lemonade (UIDVALIDITY 4 UIDNEXT 9999 MESSAGES 500)
S : [...]
S : * STATUS Lists/Im2000 (UIDVALIDITY 901 UIDNEXT 1 MESSAGES 0)
S : b OK done
C : c select inbox
S : [...] (les réponses 7-8 usuelles à SELECT)
S : c OK INBOX selected
(Du temps passe. Un nouveau message est livré à la boîte aux lettres Lists/Lemonade.)
S : * STATUS Lists/Lemonade (UIDVALIDITY 4 UIDNEXT 10000 MESSAGES 501)
(Du temps passe. Un nouveau message est livré à inbox.)
S : * 127 FETCH (UID 127001 BODY[HEADER.FIELDS (From To Subject)] {75}
S : Subject: Re: bonjour
S : From: alice@exemple.org
S : To: bob@exemple.org
S :
S : )
(Du temps passe. Le client décide qu'il veut des informations sur une boîte aux lettres supplémentaire. Comme le client connaît déjà les informations de STATUS nécessaires pour toutes les boîtes aux lettres en dessous de la boîte aux lettres Lists, et parce que "notify set status" causerait des réponses STATUS pour *toutes* les boîtes aux lettres spécifiées dans la commande NOTIFY, y compris celles pour lesquelles le client connaît déjà les informations STATUS, le client produit une demande explicite STATUS pour la boîte aux lettres à ajouter à la liste de surveillance, suivie par le NOTIFY SET sans le paramètre STATUS.)
C : d STATUS misc (UIDVALIDITY UIDNEXT MESSAGES)
S : * STATUS misc (UIDVALIDITY 1 UIDNEXT 999)
S : d STATUS completed
C : e notify set (selected MessageNew (uid body.peek[header.fields (from to subject)]) MessageExpunge) (subtree Lists MessageNew) (mailbox misc MessageNew)
S : e OK done

 	4.	Interaction avec la commande IDLE

Si IDLE [RFC2177] (ainsi que la présente extension) est pris en charge, alors pendant le traitement de toute commande IDLE, le serveur DOIT envoyer exactement les mêmes événements que ce que le client a demandé en utilisant la commande NOTIFY.

NOTIFY rend IDLE inutile pour certains clients. Si un client n'utilise pas de MSN et de "*" dans les commandes, il peut demander MessageExpunge et MessageNew pour la boîte aux lettres choisie en utilisant la commande NOTIFY au lieu d'entrer dans le mode IDLE.

Un client qui utilise des MSN et des "*" dans les commandes peut quand même utiliser la commande NOTIFY si il spécifie le spécificateur de boîte aux lettres SELECTED-DELAYED dans la commande NOTIFY.

 	5.	Types d'événements

Seuls certains des événements de la [RFC5423] peuvent être exprimées dans IMAP, et pour certains d'entre eux il y a plusieurs façons possibles d'exprimer l'événement.

Cette section spécifie les événements qu'un serveur IMAP peut notifier à un client IMAP et comment le faire.

Le serveur DEVRAIT omettre de le notifier au client si l'événement est causé par ce client. Par exemple, si le client produit CREATE et a demandé un événement MailboxName qui couvrirait la nouvelle création de boîte aux lettres, le serveur NE DEVRAIT PAS notifier au client le changement de MailboxName.

Tous les types d'événement décrits dans le présent document exigent les droits "l" et "r" (voir la [RFC4314]) sur toutes les boîtes aux lettres observées. Les serveurs qui ne mettent pas en œuvre la [RFC4314] devraient transposer les droits ci-dessus dans leur modèle de contrôle d'accès.

Si les événements FlagChange et/ou AnnotationChange sont spécifiés, MessageNew et MessageExpunge DOIVENT aussi être spécifiés par le client. Autrement, le serveur DOIT répondre avec la réponse BAD étiquetée.

Si un de MessageNew ou MessageExpunge est spécifié, alors les deux événements DOIVENT être spécifiés. Autrement, le serveur DOIT répondre avec la réponse BAD étiquetée.

Le client peut donner pour instruction au serveur de ne pas envoyer un événement en omettant l'événement nécessaire de la liste des événements spécifiés dans NOTIFY SET, en utilisant le spécificateur d'événement NONE dans le NOTIFY SET, ou en utilisant NOTIFY NONE. En particulier, NOTIFY SET ... NONE peut être utilisé comme une facilité instantanée par les clients.

 	5.1	FlagChange et AnnotationChange
Si le changement d'annotation de fanion et/ou message se produit dans la boîte aux lettres choisie, le serveur DOIT le notifier au client en envoyant une réponse FETCH non sollicitée, qui DOIT inclure les éléments de données UID et FLAGS/ANNOTATION FETCH. Il PEUT aussi envoyer de nouvelles réponses FLAGS et/ou OK [PERMANENTFLAGS ...].

Si un contexte de recherche est en cours comme spécifié dans la [RFC5267], un ESEARCH ADDTO ou ESEARCH REMOVEFROM va aussi être généré, si c'est approprié. Dans ce cas, la réponse FETCH DOIT précéder la réponse ESEARCH.

Si le changement se produit dans une autre boîte aux lettres, alors le serveur répond par un STATUS. Le contenu exact de la réponse STATUS dépend de divers facteurs. Si CONDSTORE [RFC4551] et/ou QRESYNC [RFC5162] sont activés par le client, alors le serveur envoie une réponse STATUS qui inclut au moins les éléments de données d'état HIGHESTMODSEQ et UIDVALIDITY. Si le nombre de messages avec le fanion \Seen change, le serveur PEUT aussi inclure l'élément de données UNSEEN dans la réponse STATUS. Si CONDSTORE/QRESYNC n'est pas activé par le client et si le serveur choisit de ne pas inclure l'élément de données UNSEEN, le serveur ne le notifie pas au client. Quand cet événement est demandé, le serveur DOIT notifier au client les changements de UIDVALIDITY de boîte aux lettres. Cela est fait par l'envoi d'une réponse STATUS qui inclut UIDVALIDITY.

FlagChange couvre les événements MessageRead, MessageTrash, FlagsSet, et FlagsClear de la [RFC5423].

Exemple dans la boîte aux lettres choisie :
S : * 99 FETCH (UID 9999 FLAGS ($Junk))

Et dans une autre boîte aux lettres, avec l'utilisation de CONDSTORE :
S : * STATUS Lists/Lemonade (HIGHESTMODSEQ 65666665 UIDVALIDITY 101)

 	5.2	MessageNew
Cela couvre à la fois MessageNew et MessageAppend dans la [RFC5423].

Si le message nouveau/ajouté est dans la boîte aux lettres choisie, le serveur le notifie au client par l'envoi d'une réponse EXISTS non sollicitée, suivie par une réponse FETCH non sollicitée contenant les informations demandées par le client. Une réponse FETCH NE DEVRAIT PAS être générée pour un nouveau message créé par le client sur cette connexion particulière, par exemple, par suite d'une commande APPEND ou COPY à la boîte aux lettres choisie effectuée par le client lui-même. Le serveur PEUT aussi envoyer une réponse RECENT, si le serveur marque le message comme \Recent.

Noter qu'une seule réponse EXISTS peut être retournée pour plusieurs événements MessageAppend/MessageNew.

Si un contexte "search" est utilisé comme spécifié dans la [RFC5267], un ESEARCH ADDTO va aussi être généré, si c'est approprié. Dans ce cas, la réponse EXISTS DOIT précéder la réponse ESEARCH. La commande NOTIFY et les deux commandes SEARCH et SORT (voir la Section 7) peuvent spécifier des attributs à retourner pour les nouveaux messages. Ces attributs DEVRAIENT être combinés dans une seule réponse FETCH. Le serveur DEVRAIT éviter d'envoyer des données dupliquées. La ou les réponses FETCH DOIVENT suivre toute réponse ESEARCH ADDTO.

Si le message nouveau/ajouté est dans une autre boîte aux lettres, le serveur envoie une réponse non sollicitée STATUS (UIDNEXT MESSAGES) pour la boîte aux lettres pertinente. Si l'extension CONDSTORE [RFC4551] et/ou l'extension QRESYNC [RFC5162] est activée, l'élément de données d'état HIGHESTMODSEQ DOIT être inclus dans la réponse STATUS.

Le client NE DEVRAIT PAS utiliser des attributs FETCH qui établissent implicitement le fanion \seen, ou cela présuppose l'existence d'une partie de corps donnée. UID, MODSEQ, FLAGS, ENVELOPE, BODY.PEEK[HEADER.FIELDS... et BODY/BODYSTRUCTURE peuvent être les attributs les plus utiles.

Noter que si un client demande à être notifié des événements MessageNew avec le spécificateur de boîte aux lettres SELECTED, le nombre de messages peut augmenter à tout moment, et donc le client ne peut pas se référer à un message spécifique en utilisant le MSN/UID '*'.

Exemple dans la boîte aux lettres choisie :
S : * 444 EXISTS
S : * 444 FETCH (UID 9999)

Et dans une autre boîte aux lettres, sans que CONDSTORE soit activé :
S : * STATUS Lists/Lemonade (UIDNEXT 10002 MESSAGES 503)

 	5.3	MessageExpunge
Si le ou les messages purgés sont dans la boîte aux lettres choisie, le serveur le notifie au client en utilisant EXPUNGE (ou VANISHED si la [RFC5162] est prise en charge par le serveur et si c'est activé par le client).

Si un contexte "search" est activé, comme spécifié dans la [RFC5267], un ESEARCH REMOVEFROM va aussi être généré, si c'est approprié.

Si le ou les messages purgés sont dans une autre boîte aux lettres, le serveur envoie une réponse non sollicitée STATUS (UIDNEXT MESSAGES) pour la boîte aux lettres pertinente. Si l'extension QRESYNC [RFC5162] est activée, l'élément de données HIGHESTMODSEQ DOIT être aussi inclus dans la réponse STATUS.

Noter que si un client demande MessageExpunge avec le spécificateur de boîte aux lettres SELECTED, la signification d'un MSN peut changer à tout moment, donc le client ne peut plus utiliser des MSN dans les commandes. Par exemple, un tel client ne peut pas utiliser FETCH, mais doit utiliser UID FETCH. La signification de '*' peut aussi changer quand des messages sont ajoutés ou supprimés. Un client qui souhaite continuer d'utiliser des MSN peut soit utiliser le spécificateur de boîte aux lettres SELECTED-DELAYED, soit peut éviter entièrement d'utiliser l'événement MessageExpunge.

La notification MessageExpunge couvre les deux événements MessageExpunge et MessageExpire de la [RFC5423].

Exemple dans la boîte aux lettres choisie, sans QRESYNC :
S : * 444 EXPUNGE

Le même exemple dans la boîte aux lettres choisie, avec QRESYNC :
S : * VANISHED 5444

Et dans une autre boîte aux lettres, quand QRESYNC n'est pas activé :
S : * STATUS misc (UIDNEXT 999 MESSAGES 554)

 	5.4	MailboxName
Ces notifications sont envoyées si un nom de boîte aux lettres affectée a été créé (avec CREATE) supprimé (avec DELETE) ou renommé (avec RENAME). Pour un serveur qui met en œuvre la [RFC4314], accorder ou révoquer le droit "l" à l'utilisateur actuel sur la boîte aux lettres affectée DOIT être considéré comme respectivement une création ou une suppression de boîte aux lettres. Si une boîte aux lettres est créée ou supprimée, la boîte aux lettres elle-même et son parent direct (qu'il soit ou non une boîte aux lettres existante) sont considérés comme étant affectés.

Le serveur notifie au client en envoyant une réponse LIST non sollicitée pour chaque nom de boîte aux lettres affectée. Si, après l'événement, le nom de boîte aux lettres ne se réfère pas à une boîte aux lettres accessible au client, le fanion \Nonexistent DOIT être inclus.

Pour chaque boîte aux lettres LISTable renommée, le serveur envoie une réponse LIST étendue [RFC5258] pour le nouveau nom de boîte aux lettres, contenant l'élément de données étendu OLDNAME avec l'ancien nom de la boîte aux lettres. Quand une boîte aux lettres est renommée, ses enfants sont renommés aussi. Aucun événement MailboxName supplémentaire n'est envoyé pour les enfants dans ce cas. Quand INBOX est renommée, une nouvelle INBOX est supposée être créée. Aucun événement MailboxName n'est envoyé pour INBOX dans ce cas.

Si le serveur s'abonne automatiquement à une boîte aux lettres quand elle est créée ou renommée, alors la réponse LIST non sollicitée pour chaque nom de boîte aux lettres affectée souscrite DOIT inclure l'attribut \Subscribed (voir la [RFC5258]). Le serveur DEVRAIT aussi inclure les attributs \HasChildren ou \HasNoChildren [RFC5258] comme approprié.

Exemple d'une boîte aux lettres nouvellement créée (ou octroi du droit "l" sur la boîte aux lettres) :
S : * LIST () "/" "NewMailbox"

Et d'une boîte aux lettres supprimée (ou d'une révocation du droit "l" sur la boîte aux lettres) :
S : * LIST (\NonExistent) "." "INBOX.DeletedMailbox"

Exemple d'une boîte aux lettres renommée :
S : * LIST () "/" "NewMailbox" ("OLDNAME" ("OldMailbox"))

 	5.5	SubscriptionChange
Le serveur notifie au client en envoyant une réponse LIST non sollicitée pour chaque nom de boîte aux lettres affectée. Si et seulement si l'abonnement à la boîte aux lettres est souscrit après l'événement, l'attribut \Subscribed (voir la [RFC5258]) est inclus. Noter que dans la réponse LIST, tous les attributs de boîte aux lettres DOIVENT être calculés précisément (cela diffère du comportement de la commande LSUB).

Exemple:
S : * LIST (\Subscribed) "/" "SubscribedMailbox"

 	5.6	MailboxMetadataChange
La prise en charge de ce type d'événement est FACULTATIVE sauf si l'extension METADATA [RFC5464] est aussi prise en charge par le serveur, et dans ce cas, la prise en charge de ce type d'événement est EXIGÉE.

Un client qui veut recevoir des réponses METADATA non sollicitées par suite de l'utilisation de l'événement MailboxMetadataChange dans la commande NOTIFY n'a pas besoin de produire ENABLE METADATA.

Le serveur envoie une réponse METADATA non sollicitée (conformément au paragraphe 4.4.2 de la [RFC5464]). Si possible, seules les métadonnées changées DEVRAIENT être incluses, mais si le serveur ne peut pas détecter un changement d'un seul élément de métadonnées, il PEUT inclure tous l'ensemble des éléments de métadonnées sur la boîte aux lettres. Si un élément de métadonnées est supprimé (réglé à NIL) il DOIT toujours être inclus dans la réponse METADATA.

Exemple:
S : * METADATA "INBOX" /shared/comment

 	5.7	ServerMetadataChange
La prise en charge de ce type d'événement est FACULTATIVE sauf si l'extension METADATA ou METADATA-SERVER [RFC5464] est aussi prise en charge par le serveur, et dans ce cas, la prise en charge de ce type d'événement est EXIGÉE.

Un client qui veut recevoir des réponses METADATA non sollicitées par suite de l'utilisation de l'événement ServerMetadataChange dans la commande NOTIFY n'a pas à produire de ENABLE METADATA ou ENABLE METADATA-SERVER.

Le serveur envoie une réponse METADATA non sollicitée (conformément au paragraphe 4.4.2 de la [RFC5464]). Seuls les noms des entrées de métadonnées changées DEVRAIENT être retournés dans de telles réponses METADATA. Si un élément de métadonnées est supprimé (réglé à NIL) il DOIT toujours être inclus dans la réponse METADATA.

Exemple:
S : * METADATA "" /shared/comment

 	5.8	Débordement de notifications
Si le serveur est incapable ou ne veut pas livrer autant de notifications que ce qui lui est demandé, il peut désactiver les notifications pour certains des clients ou tous. Il DOIT le notifier à ces clients en envoyant une réponse non étiquetée "OK [NOTIFICATIONOVERFLOW]" et se comporter comme si une commande NOTIFY NONE avait été reçue.

Exemple:
S: * OK [NOTIFICATIONOVERFLOW] ...Un commentaire peut venir ici...

 	5.9	Changements de liste de contrôle d'accès
Même si NOTIFY réussit, il est encore possible de perdre plus tard l'accès aux boîtes aux lettres surveillées. Si cela arrive, le serveur DOIT arrêter de surveiller ces boîtes aux lettres. Si l'accès est accordé plus tard, le serveur DOIT recommencer la surveillance d'événement.

Le serveur DEVRAIT retourner la réponse LIST avec l'attribut de nom \NoAccess si et quand la boîte aux lettres perd le droit "l". De même, le serveur DEVRAIT retourner la réponse LIST sans attribut de nom \NoAccess si la boîte aux lettres avait été précédemment rapportée commme ayant \NoAccess et que le droit "l" est accordé plus tard.

 	6.	Spécification de boîte aux lettres

Les boîtes aux lettres à surveiller peuvent être spécifiées de plusieurs façons différentes.

Seuls "SELECTED" et "SELECTED-DELAYED" (paragraphe 6.1) correspondent à la boîte aux lettres actuellement choisie. Toutes les autres spécifications de boîte aux lettres affectent d'autres boîtes aux lettres (non choisies).

Noter que plusieurs <groupes d'événements> peuvent s'appliquer à la même boîte aux lettres. L'exemple suivant démontre cela. Dans cet exemple, les événements MessageNew et MessageExpunge sont rapportés pour INBOX, du fait du premier <groupe d'événements>. Un événement SubscriptionChange va aussi être rapporté pour INBOX, du fait du second <groupe d'événements>.

C : a notify set (boîtes aux lettres INBOX (Messagenew messageExpunge)) (personal (SubscriptionChange))

Un client normal qui prend en charge l'extension NOTIFY va demander les événements sur la boîte aux lettres choisie et certaines boîtes aux lettres désignées.

Dans l'exemple suivant, le client demande les événements FlagChange pour toutes les boîtes aux lettres personnelles sauf la boîte aux lettres actuellement choisie. Ceci est différent de l'exemple précédent parce que SELECTED outrepasse toutes les autres définitions d'événement de message pour la boîte aux lettres actuellement choisie (voir le paragraphe 3.1).

C : a notify set (selected (Messagenew (uid flags) messageExpunge)) (personal (MessageNew FlagChange MessageExpunge))

 	6.1	Spécificateurs de boîte aux lettres qui affectent la boîte aux lettres choisie
Un seul des spécificateurs de la boîte aux lettres qui affecte la boîte aux lettres actuellement choisie peut être spécifié dans une commande NOTIFY. Ces deux spécificateurs de boîte aux lettres (SELECTED et SELECTED-DELAYED) sont décrits ci-dessous.

Tous deux se réfèrent à la boîte aux lettres qui a été choisie en utilisant soit SELECT, soit EXAMINE (voir la [RFC3501], paragraphes 6.3.1 et 6.3.2). Quand la connexion IMAP n'est pas dans l'état choisi, ces spécificateurs de boîte aux lettres ne se réfèrent à aucune boîte aux lettres.

Les spécificateurs de boîte aux lettres s'appliquent seulement aux <événements de message>. C'est une erreur de spécifier d'autres types d'événements avec le sélecteur SELECTED ou SELECTED-DELAYED.

 	6.1.1	Selected
Le spécificateur de boîte aux lettres SELECTED exige que le serveur envoie immédiatement les notifications pour la boîte aux lettres actuellement choisie sur tous les <événements de message> spécifiés.

 	6.1.2	Selected-Delayed
Le spécificateur de boîte aux lettres SELECTED-DELAYED exige que le serveur retarde l'événement MessageExpunge jusqu'à ce que le client produise une commande permettant de retourner des informations sur les messages purgés (voir le paragraphe 7.4.1 de la [RFC3501] pour les détails) par exemple, jusqu'à ce qu'une commande NOOP ou IDLE ait été produite. Quand SELECTED-DELAYED est spécifié, le serveur PEUT aussi retarder de retourner d'autres <événements de message> jusqu'à ce que le client produise une des commandes spécifiées ci-dessus, ou il PEUT les retourner immédiatement.

 	6.2	Personal
Personal se réfère à toutes les boîtes aux lettres éligibles dans le ou les espaces de noms personnels de l'utilisateur, comme défini dans la [RFC2342].

 	6.3	Inboxes
Inboxes se réfère à toutes les boîtes aux lettres éligibles dans le ou les espaces de noms personnels de l'utilisateur auxquels des messages peuvent être livrés par un agent de livraison de message (MDA, Message Delivery Agent) (voir la [RFC5598], en particulier le paragraphe 4.3.3).

Si le serveur IMAP ne peut pas calculer facilement cet ensemble, il DOIT traiter "inboxes" comme équivalent à "personal".

 	6.4	Subscribed
Subscribed se réfère à toutes les boîtes aux lettres souscrites par l'utilisateur. Si la liste de souscriptions change, le serveur DOIT réévaluer la liste.

 	6.5	Subtree
Subtree est suivi par un nom de boîte aux lettres ou une liste de noms de boîtes aux lettres. Une sous arborescence se réfère à toutes les boîtes aux lettres éligibles qui sont subordonnées à la boîte aux lettres spécifiée plus la boîte aux lettres spécifiée elle-même.

 	6.6	Mailboxes
Mailboxes est suivi par un nom de boîte aux lettres ou une liste de noms de boîtes aux lettres. Le serveur NE DOIT PAS faire d'expansion de caractère générique. Cela signifie qu'il n'y a pas de traitement particulier pour les caractères génériques de LIST ('*' et '%') si il en est de présent dans les noms de boîte aux lettres.

 	7.	Extension aux commandes SEARCH et SORT

Si le serveur qui prend en charge l'extension NOTIFY prend aussi en charge CONTEXT=SEARCH et/ou CONTEXT=SORT comme défini dans la [RFC5267], l'option de retour UPDATE est étendue afin qu'un client puisse demander que des attributs FETCH soient retournés quand un nouveau message est ajouté à l'ensemble de résultats du contexte.

Par exemple :

C : a00 SEARCH RETURN (COUNT UPDATE (UID BODY[HEADER.FIELDS (TO FROM SUBJECT)])) FROM "boss"
S : * ESEARCH (TAG "a00") (COUNT 17)
S : a00 OK
[...un nouveau message est livré...]
S : * EXISTS 93
S : * 93 FETCH (UID 127001 BODY[HEADER.FIELDS (FROM TO SUBJECT)] {76}
S : Subject: Re: bonjour
S : From: myboss@exemple.org
S : To: bob@exemple.org
S :
S : )
S : * ESEARCH (TAG "a00") ADDTO (0 93)

Noter que la réponse EXISTS DOIT précéder toutes les réponses FETCH, et ensemble, elles DOIVENT précéder la réponse ESEARCH.

Aucune réponse FETCH étiquetée ne DEVRAIT être retournée si un message devient membre de UPDATE SEARCH du fait d'un changement de fanion ou d'annotation.

 	8.	Syntaxe formelle

La spécification de syntaxe suivante utilise la notation de forme Backus-Naur augmenté (ABNF, Augmented Backus-Naur Form) spécifiée dans la [RFC5234]. La [RFC3501] définit les non terminaux "capability", "command-auth", "mailbox", "mailbox-data", "resp-text-code", et "search-key". Le non terminal "modifier-update" est défini dans la [RFC5267]. "mbx-list-oflag" est défini dans la [RFC3501] et mis à jour par la [RFC5258].

Sauf notation contraire, tous les caractères alphabétiques sont insensibles à la casse. L'utilisation de caractères majuscules ou minuscules pour définir des chaînes de jeton est seulement pour faciliter la lecture. Les mises en œuvre DOIVENT accepter ces chaînes de façon insensible à la casse. Par exemple, dans la valeur de non terminal <filter-mailbox-selected> "SELECTED" doit être traitée de la même façon que "Selected" ou "selected".

capability =/ "NOTIFY"

command-auth =/ notify

notify = "NOTIFY" SP (notify-set / notify-none)

notify-set = "SET" [status-indicator] SP event-groups
 ; Remplace les événements de notification enregistrés par la liste d'événements spécifiée

notify-none = "NONE"
 ; Annule tous les événements de notification enregistrés. Le client n'est pas intéressé à recevoir des événements.

status-indicator = SP "STATUS"

one-or-more-mailbox = mailbox / many-mailbox

many-mailbox  = "(" mailbox *(SPmailbox ) ")"

event-groups = event-group *(SP event-group)

event-group = "(" filter-mailbox SP event ")"
 ;; Seuls les <message-event> sont permis dans <event> quand <filter-mailbox-selected> est utilisé.

filter-mailbox = filter-mailbox-selected / filter-mailbox-other

filter-mailbox-other = "inboxes" / "personal" / "subscribed" / ( "subtree" SP one-or-more-mailbox ) / ( "mailbox" SP one-or-more-mailbox )

filter-mailbox-selected = "selected" / "selected-delayed" ;; s'applique seulement à la boîte aux lettres acuellement choisie. Un seul d'entre eux peut être spécifié dans une commande NOTIFY.

events = ( "(" event *(SP event) ")" ) / "NONE"
;; Comme dans [MSGEVENT]. "NONE" signifie que le client ne souhaite pas recevoir d'événements pour la boîtes aux lettres spécifiée.

event = message-event / mailbox-event / user-event / event-ext

message-event = ( "MessageNew" [SP "(" fetch-att *(SP fetch-att) ")" ] ) / "MessageExpunge" / "FlagChange" / "AnnotationChange"
;; "MessageNew" inclut "MessageAppend" provenant de [MSGEVENT]. "FlagChange" est un de "MessageRead", "MessageTrash", "FlagsSet", "FlagsClear" [MSGEVENT]. "MessageExpunge" inclut "MessageExpire" [MSGEVENT]. MessageNew et MessageExpunge DOIVENT toujours être spécifiés ensemble. Si FlagChange est spécifié, alors MessageNew et MessageExpunge DOIVENT être aussi spécifiés. La liste fett-att peut seulement être présente pour le filtre de boîte aux lettres SELECTED/SELECTED-DELAYED (<filter-mailbox>).

mailbox-event = "MailboxName" / "SubscriptionChange" / "MailboxMetadataChange"
; "SubscriptionChange" inclut MailboxSubscribe et MailboxUnSubscribe. "MailboxName" inclut MailboxCreate, ; "MailboxDelete" et "MailboxRename".

user-event = "ServerMetadataChange"

event-ext = atom	;; pour de futures extensions

oldname-extended-item =  "OLDNAME" SP "(" mailbox ")"
;; élément de données étendu (mbox-list-extended-item) retourné dans une réponse LIST quand une boîte aux lettres est renommée. Note 1 : l'étiquette OLDNAME peut être retournée avec ou sans guillemets, comme dans la production mbox-list-extended-item-tag.

resp-text-code=/ "NOTIFICATIONOVERFLOW" / unsupported-events-code

message-évent-name = "MessageNew" / "MessageExpunge" / "FlagChange" / "AnnotationChange"

event-name = message-event-name / mailbox-event / user-event

unsupported-events-code = "BADEVENT" SP "(" event-name *(SP event-name) ")"

modifier-update = "UPDATE" [ "(" fetch-att *(SP fetch-att) ")" ]

mbx-list-oflag =/ "\NoAccess"

 	9.	Considérations sur la sécurité

Il est très facile à un client de se refuser le service en utilisant NOTIFY. Demander tous les événements sur toutes les boîtes aux lettres peut fonctionner sur un petit serveur, mais avec un gros serveur, cela peut submerger la connexion réseau du client ou sa capacité de traitement. Dans le pire des cas, le traitement du serveur pourrait aussi dégrader le service qu'il offre aux autres clients.

Les auteurs de serveur devraient avoir conscience que si un client produit des demandes et n'écoute pas les réponses résultantes, la fenêtre TCP peut facilement se remplir, et un serveur négligent pourrait se bloquer. Ce problème existe aussi  dans IMAP normal ; cependant, cette extension amplifie le problème.

Cette extension rend possible de restituer les messages immédiatement quand ils sont ajoutés à la boîte aux lettres. Cela rend complètement impossible de supprimer les messages sensibles en utilisant des programmes comme imapfilter. Utiliser SIEVE [RFC5228] ou quelque chose de similaire est bien préférable.

 	10.	Considérations relatives à l’IANA

L'IANA a ajouté NOTIFY à la liste des extensions IMAP.

 	10.1	Enregistrements initiaux d'élément de données étendues LIST-EXTENDED
L'entrée suivante a été ajoutée au registre de réponses LIST-EXTENDED [RFC5258] :

Pour : iana@iana.org
Objet : enregistrement de l'élément de données étendu OLDNAME LIST-EXTENDED 
Étiquette d'élément de données étendu LIST-EXTENDED : OLDNAME
Description de l'élément de données étendu LIST-EXTENDED : l'élément de données étendu OLDNAME décrit l'ancien nom de boîte aux lettres pour la boîte aux lettres identifiée par la réponse LIST.
Options de LIST-EXTENDED (et types) qui causent le retour de cet élément de données étendu (si il y en a) : aucune
Spécification publiée : RFC 5465, paragraphe 5.4.
Considérations de sécurité : aucune
Usage prévu : COMMUN
Adresse personnelle et de messagerie à contacter pour plus d'informations : Alexey Melnikov <Alexey.Melnikov@isode.com>
Propriétaire/contrôleur des changements : iesg@ietf.org

 	11.	Remerciements

Les auteurs remercient chaleureusement de leur aide Peter Coates, Dave Cridland, Mark Crispin, Cyrus Daboo, Abhijit Menon-Sen, Timo Sirainen, et Eric Burger. En particulier, Peter Coates a contribué par beaucoup de texte et d'utiles suggestions au présent document.

Divers exemples sont copiés d'autres RFC.

Le présent document s'appuie sur un document publié et deux projets non publiés des mêmes auteurs.

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

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

[RFC2342]	M. Gahrns, C. Newman, "Espace de noms IMAP4", mai 1998. (MàJ par RFC4466) (P.S.)

[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

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

[RFC4466]	A. Melnikov, C. Daboo, "Récapitulation des extensions à l'ABNF pour IMAP4", avril 2006. (P.S.)

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

[RFC5162]	A. Melnikov et autres, "Extensions à IMAP4 pour la resynchronisation rapide de boîte aux lettres", mars 2008. (P.S.; obsolète, voir RFC7162)

[RFC5234]	D. Crocker, P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", janvier 2008. (STD0068)

[RFC5258]	B. Leiba, A. Melnikov, "Protocole d'accès au message Internet, version 4 - extensions de commande LIST", juin 2008. (P.S.)

[RFC5267]	D. Cridland, C. King, "Contextes pour IMAP4", juillet 2008. (MàJ par RFC5465) (P.S.)

[RFC5423]	R. Gellens et C. Newman, "Événements de mémorisation de message Internet", mars 2009. (P. S.

[RFC5464]	C. Daboo, "Extension IMAP METADATA", février 2009. (P.S.)

 	13.	Références pour information

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

[RFC5598]	D. Crocker, "Architecture de la messagerie Internet", juillet 2009. (Information) 

 	Adresse des auteurs

Arnt Gulbrandsen	Curtis King	Alexey Melnikov	
Oryx Mail Systems GmbH	Isode Ltd	Isode Ltd	
Schweppermannstr. 8	5 Castle Business Village	5 Castle Business Village	
D-81671 Muenchen	36 Station Road	36 Station Road	
Germany	Hampton, Middlesex  TW12 2BX	Hampton, Middlesex  TW12 2BX	
mél : arnt@oryx.com	UK	UK	
	mél : Curtis.King@isode.com	mél : Alexey.Melnikov@isode.com