---

We need Your Support. Make a Donation now! or

---

Commande IMAP4 IDLE

1.   Résumé

Le protocole d'accès au message Internet (IMAP, Internet Message Access Protocol) [IMAP4] exige d'un client qu'il interroge le serveur pour effectuer des changements à la boîte aux lettres sélectionne (nouveaux messages, suppressions). Il est souvent plus souhaitable que le serveur transmette les mises à jour au client en temps réel. Cela permet à un utilisateur de voir immédiatement les nouveaux messages. Cela aide aussi certaines applications en temps réel fondées sur IMAP, qui auraient autrement besoin de l'interroger extrêmement souvent (comme toutes les quelques secondes). (Quoique la spécification permette bien à un serveur de pousser les réponses EXISTS en asynchrone, un client ne peut compter sur ce comportement et doit faire l'interrogation.)

Le présent document spécifie la syntaxe d'une commande IDLE, qui va permettre à un client de dire au serveur qu'il est prêt à accepter de telles mises à jour en temps réel.

2.   Conventions utilisées dans le document

Dans les exemples, "C:" et "S:" indiquent les lignes envoyées respectivement par le client et le serveur.

Les mots clés "DOIT", "NE DOIT PAS", "DEVRAIT", "NE DEVRAIT PAS" et "PEUT" dans ce document sont à interpréter comme décrit dans la RFC 2060 [IMAP4].

3.   Spécification

Commande IDLE

Arguments : aucun

Réponses :   des données de continuation seront demandées ; le client envoie les données de continuation "DONE" pour terminer la commande

Résultat :      OK - IDLE achevé après que le client a envoyé "DONE"

                       NO – échec : le serveur ne permet pas la commande IDLE pour l'instant

                       BAD – commande inconnue ou arguments invalides

La commande IDLE peut être utilisée avec toute mise en œuvre de serveur IMAP4 qui retourne "IDLE" comme étant une des capacités prises en charge de la commande CAPABILITY. Si le serveur n'annonce pas la capacité IDLE, le client NE DOIT PAS utiliser la commande IDLE et doit interroger (le serveur) pour une mise à jour de la boîte aux lettres. En particulier, le client DOIT continuer d'être capable d'accepter des réponses non étiquetées non sollicitées à TOUTE commande, comme spécifié dans la spécification IMAP de base.

La commande IDLE est envoyée du client au serveur lorsque le client est prêt à accepter des messages de mise à jour de boîte aux lettres non sollicités. Le serveur demande une réponse à la commande IDLE en utilisant la réponse de continuation ("+"). La commande IDLE reste active jusqu'à ce que le client réponde à la continuation, et tant qu'une commande IDLE est active, le serveur est libre d'envoyer à tout moment des messages non étiquetés EXISTS, EXPUNGE, et autres.

La commande IDLE est terminée par la réception d'une continuation "DONE" provenant du client ; une telle réponse satisfait à la demande de continuation du serveur. À ce moment, le serveur PEUT envoyer toutes les réponses non étiquetées restant dans la file d'attente et DOIT alors envoyer immédiatement la réponse étiquetée à la commande IDLE et se préparer à traiter les autres commandes. Comme dans la spécification de base, le traitement de toute nouvelle commande peut causer l'envoi de réponses non étiquetées non sollicitées, sous réserve des limitations d'ambiguïté. Le client NE DOIT PAS envoyer une commande alors que le serveur attend DONE, car le serveur ne sera pas capable de distinguer une commande d'une continuation (de commande).

Le serveur PEUT considérer qu'un client est inactif si il a une commande IDLE en cours, et si un tel serveur a une temporisation d'inactivité, il PEUT déconnecter implicitement le client à la fin de la période de temporisation. À cause de cela, les clients qui utilisent IDLE sont avisés de terminer le IDLE et de le reproduire au moins toutes les 29 minutes pour éviter d'être déconnectés. Cela permet quand même à un client de recevoir des mises à jour immédiates de boîte aux lettres même si il a besoin de faire une interrogation toutes les demi heures.

Exemple :

C: A001 SELECT INBOX

S: * FLAGS (Supprimés Vus)

S: * 3 EXISTS

S: * 0 RECENT

S: * OK [UIDVALIDITY 1]

S: A001 OK SELECT completed

C: A002 IDLE

S: + idling

         ...le temps passe ; de nouveaux messages arrivent...

S: * 4 EXISTS

C: DONE

S: A002 OK IDLE terminated

          ...un autre client supprime maintenant le message 2 ...

C: A003 FETCH 4 ALL

S: * 4 FETCH (...)

S: A003 OK FETCH completed

C: A004 IDLE

S: * 2 EXPUNGE

S: * 3 EXISTS

S: + idling

          ...le temps passe ; un autre client supprime le message 3 ...

S: * 3 EXPUNGE

S: * 2 EXISTS

          ...le temps passe ; un nouveau message arrive...

S: * 3 EXISTS

C: DONE

S: A004 OK IDLE terminated

C: A005 FETCH 3 ALL

S: * 3 FETCH (...)

S: A005 OK FETCH completed

C: A006 IDLE

4.   Syntaxe formelle

La spécification syntaxique suivante utilise la notation de forme Backus-Naur augmentée (BNF) telle que spécifiée dans la [RFC-822] et modifiée par [IMAP4]. Les éléments non terminaux référencés mais non définis ci-dessous sont tels que définis dans [IMAP4].

command_auth   ::= append / create / delete / examine / list / lsub / rename / select / status / subscribe / unsubscribe / idle

   ;; Seulement valide dans les états Authentifié ou Choisi

idle   ::= "IDLE" CRLF "DONE"

5.   Référence

[IMAP4]   M. Crispin, "Protocole d'accès au message Internet - version 4rev1", RFC 2060, décembre 1996. (Obsolète, voirRFC3501)

6.   Considérations pour la sécurité

La présente extension ne pose aucun problème de sécurité connu.

7.   Adresse de l'auteur

Barry Leiba

IBM T.J. Watson Research Center

30 Saw Mill River Road

Hawthorne, NY 10532

USA

mél : leiba@watson.ibm.com