1. Comment lire ce document
1.1. Organisation de ce document
Ce document est rédigé du point de vue de l’implémenteur d’un client ou d’un serveur IMAP4rev1. Au-delà de la vue d’ensemble du protocole présentée dans la section 2, il n’est pas optimisé pour une personne cherchant à comprendre le fonctionnement du protocole. Le contenu des sections 3 à 5 fournit le contexte général et les définitions dans lesquels IMAP4rev1 fonctionne.
Les sections 6, 7 et 9 décrivent respectivement les commandes IMAP, les réponses et la syntaxe. Leurs relations sont telles qu’il est presque impossible de comprendre chacune séparément. En particulier, ne tentez pas de déduire la syntaxe d’une commande à partir de la seule section des commandes ; consultez plutôt la section de syntaxe formelle.
1.2. Conventions utilisées dans ce document
Les « conventions » sont des principes ou procédures de base. Les conventions du document sont indiquées dans cette section.
Dans les exemples, « C: » et « S: » indiquent respectivement les lignes envoyées par le client et par le serveur.
Les mots clés « MUST », « MUST NOT », « REQUIRED », « SHALL », « SHALL NOT », « SHOULD », « SHOULD NOT », « MAY » et « OPTIONAL » employés dans ce document doivent être interprétés comme décrit dans [KEYWORDS].
Le mot « can » (et non « may ») est utilisé pour désigner une circonstance ou une situation possible, par opposition à une fonction optionnelle du protocole.
Le terme « user » désigne un utilisateur humain, tandis que « client » désigne le logiciel exécuté par l’utilisateur.
Le terme « connection » désigne toute la séquence d’interaction client/serveur, de l’établissement initial de la connexion réseau jusqu’à sa terminaison.
Le terme « session » désigne la séquence d’interaction client/serveur depuis la sélection d’une boîte aux lettres (commande SELECT ou EXAMINE) jusqu’à la fin de cette sélection (SELECT ou EXAMINE d’une autre boîte aux lettres, commande CLOSE ou terminaison de la connexion).
Les caractères sont codés en US-ASCII sur 7 bits, sauf indication contraire. Les autres jeux de caractères sont indiqués au moyen d’un « CHARSET », comme décrit dans [MIME-IMT] et défini dans [CHARSET]. Outre la définition du jeu de caractères, les CHARSET ont d’importantes sémantiques supplémentaires ; consultez ces documents pour davantage de précisions.
IMAP comporte plusieurs conventions de protocole. Elles concernent des aspects de la spécification qui ne font pas strictement partie du protocole IMAP, mais reflètent des pratiques généralement admises. Les implémentations doivent connaître ces conventions et éviter les conflits, qu’elles les implémentent ou non. Par exemple, « & » ne peut pas être utilisé comme délimiteur hiérarchique, car il entre en conflit avec la convention internationale de nommage des boîtes aux lettres ; les autres utilisations de « & » dans les noms de boîtes aux lettres en sont également affectées.
1.3. Notes particulières à l’intention des implémenteurs
Les implémenteurs du protocole IMAP sont vivement encouragés à lire, conjointement avec ce document, le document de recommandations d’implémentation IMAP [IMAP-IMPLEMENTATION], afin de comprendre les subtilités de ce protocole et de concevoir au mieux un produit interopérable.
IMAP4rev1 est conçu pour être compatible vers le haut avec les protocoles [IMAP2] et IMAP2bis, non publié. IMAP4rev1 est largement compatible avec le protocole IMAP4 décrit dans le RFC 1730 ; l’exception concerne certaines fonctions ajoutées dans le RFC 1730 qui se sont révélées problématiques et ont ensuite été supprimées. Au cours de l’évolution d’IMAP4rev1, certains aspects des protocoles antérieurs sont devenus obsolètes. Les commandes, réponses et formats de données obsolètes qu’une implémentation IMAP4rev1 peut rencontrer lorsqu’elle est utilisée avec une implémentation antérieure sont décrits dans [IMAP-OBSOLETE].
D’autres problèmes de compatibilité avec IMAP2bis, la variante la plus courante du protocole antérieur, sont examinés dans [IMAP-COMPAT]. Une discussion complète des problèmes de compatibilité avec les variantes rares (et présumées éteintes) de [IMAP2] figure dans [IMAP-HISTORICAL] ; ce document présente principalement un intérêt historique.
IMAP a été développé à l’origine pour l’ancienne norme [RFC-822] et, par conséquent, plusieurs éléments de récupération IMAP incorporent « RFC822 » dans leur nom. À l’exception de RFC822.SIZE, il existe des remplaçants plus modernes ; par exemple, la version moderne de RFC822.HEADER est BODY.PEEK[HEADER]. Dans tous les cas, « RFC822 » doit être interprété comme une référence à la norme mise à jour [RFC-2822].