1. Comment lire ce document (How to Read This Document)
1.1 Organisation de ce document (Organization of This Document)
Ce document est rédigé du point de vue de l'implémenteur d'un client ou serveur IMAP4rev2. Au-delà de l'aperçu du protocole de la section 2, il n'est pas optimisé pour quelqu'un essayant de comprendre le fonctionnement du protocole. Le contenu des sections 3, 4 et 5 fournit le contexte général et les définitions avec lesquels IMAP4rev2 fonctionne.
Les sections 6, 7 et 9 décrivent respectivement les commandes (Commands), les réponses (Responses) et la syntaxe (Syntax) IMAP. Les relations entre ces éléments sont telles qu'il est presque impossible de comprendre l'un d'eux séparément. En particulier, ne tentez pas de déduire la syntaxe des commandes uniquement de la section des commandes ; référez-vous plutôt à la « Syntaxe formelle » (Formal Syntax) (section 9).
1.2 Conventions utilisées dans ce document (Conventions Used in This 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 les lignes envoyées respectivement par le client (Client) et le serveur (Server). Notez que chaque ligne inclut le CRLF de terminaison.
Les mots-clés « MUST », « MUST NOT », « REQUIRED », « SHALL », « SHALL NOT », « SHOULD », « SHOULD NOT », « RECOMMENDED », « NOT RECOMMENDED », « MAY » et « OPTIONAL » dans ce document doivent (doit) être interprétés comme décrit dans BCP 14 [RFC2119] [RFC8174] lorsque, et seulement lorsque, ils apparaissent en majuscules, comme indiqué ici.
Correspondance des mots-clés :
- MUST = doit
- MUST NOT = ne doit pas
- REQUIRED = requis
- SHALL = doit
- SHALL NOT = ne doit pas
- SHOULD = devrait
- SHOULD NOT = ne devrait pas
- RECOMMENDED = recommandé
- NOT RECOMMENDED = non recommandé
- MAY = peut
- OPTIONAL = optionnel
Le mot « can » (et non « may ») est utilisé pour désigner une circonstance ou une situation possible, par opposition à une fonctionnalité optionnelle du protocole.
« User » (utilisateur) désigne un utilisateur humain, tandis que « client » désigne le logiciel exécuté par l'utilisateur.
« Connection » (connexion) fait référence à l'ensemble de la séquence d'interaction client/serveur depuis l'établissement initial de la connexion réseau jusqu'à sa terminaison.
« Session » fait référence à la séquence d'interaction client/serveur depuis le moment où une boîte aux lettres est sélectionnée (commande SELECT ou EXAMINE) jusqu'au moment où la sélection se termine (SELECT ou EXAMINE d'une autre boîte aux lettres, commande CLOSE, commande UNSELECT ou terminaison de connexion).
Le terme « Implicit TLS » (TLS implicite) fait référence à la négociation automatique de TLS chaque fois qu'une connexion TCP est établie sur un port TCP particulier utilisé exclusivement par ce serveur pour les connexions TLS. Le terme « Implicit TLS » vise à contraster avec l'utilisation de la commande STARTTLS dans IMAP, utilisée par le client et le serveur pour négocier explicitement TLS sur une connexion TCP en texte clair établie.
Les caractères sont en UTF-8 8 bits (dont l'US-ASCII 7 bits est un sous-ensemble), sauf indication contraire. D'autres jeux de caractères sont indiqués à l'aide d'un « CHARSET », comme décrit dans [MIME-IMT] et défini dans [CHARSET]. Les CHARSET ont une sémantique supplémentaire importante en plus de définir un jeu de caractères ; consultez ces documents pour plus de détails.
Il existe plusieurs conventions de protocole (Protocol Conventions) dans IMAP. Celles-ci se réfèrent à des aspects de la spécification qui ne font pas strictement partie du protocole IMAP mais reflètent une pratique généralement acceptée. Les implémentations doivent (doivent) être conscientes de ces conventions et éviter les conflits, qu'elles implémentent ou non la convention. Par exemple, « & » ne peut pas être utilisé comme délimiteur de hiérarchie (Hierarchy Delimiter) car il entre en conflit avec la convention de dénomination internationale des boîtes aux lettres (Mailbox International Naming Convention), et d'autres utilisations de « & » dans les noms de boîtes aux lettres sont également impactées.
1.3 Notes spéciales pour les implémenteurs (Special Notes to Implementors)
Il est fortement recommandé (recommandé) aux implémenteurs du protocole IMAP de lire le document de recommandations d'implémentation IMAP [IMAP-IMPLEMENTATION] en conjonction avec ce document, pour aider à comprendre les subtilités de ce protocole et comment construire au mieux un produit interopérable.
IMAP4rev2 est conçu pour être compatible vers le haut avec les protocoles IMAP4rev1 [RFC3501], IMAP2 [IMAP2] et IMAP2bis non publié [IMAP2BIS]. IMAP4rev2 est largement compatible avec le protocole IMAP4rev1 décrit dans RFC 3501 et le protocole IMAP4 décrit dans [RFC1730] ; l'exception étant certaines fonctionnalités ajoutées dans [RFC1730] et [RFC3501] qui se sont révélées problématiques et ont ensuite été supprimées ou remplacées par de meilleures alternatives.
D'autres problèmes de compatibilité avec IMAP2bis, la variante la plus courante du protocole antérieur, sont discutés dans [IMAP-COMPAT]. Une discussion complète des problèmes de compatibilité avec les variantes rares de [IMAP2] se trouve dans [IMAP-HISTORICAL] ; ce document est principalement d'intérêt historique.