5. Considérations opérationnelles (Operational Considerations)

Les règles suivantes sont énumérées ici pour garantir que toutes les implémentations IMAP4rev2 interopèrent correctement.

5.1 Nommage des boîtes aux lettres (Mailbox Naming)

Dans IMAP4rev2, les noms de boîtes aux lettres sont encodés en Net-Unicode [NET-UNICODE] (cela diffère d'IMAP4rev1). Les implémentations client peuvent (peuvent) tenter de créer des noms de boîtes aux lettres Net-Unicode et doivent (doivent) interpréter tous les noms de boîtes aux lettres 8 bits renvoyés par LIST comme [NET-UNICODE]. Les implémentations serveur doivent (doivent) interdire la création de noms de boîtes aux lettres 8 bits qui ne sont pas conformes à Net-Unicode. Cependant, les serveurs peuvent (peuvent) accepter un nom de boîte aux lettres UTF-8 dénormalisé et le convertir en forme de normalisation Unicode C (NFC) (selon les exigences Net-Unicode) avant la création de la boîte aux lettres. Les serveurs qui choisissent d'accepter de tels noms de boîtes aux lettres UTF-8 dénormalisés doivent (doivent) les accepter dans toutes les commandes IMAP qui ont un paramètre de nom de boîte aux lettres. En particulier, SELECT <name> doit ouvrir la même boîte aux lettres qui a été créée avec succès avec CREATE <name>, même si <name> est un nom de boîte aux lettres UTF-8 dénormalisé.

Le nom de boîte aux lettres insensible à la casse INBOX est un nom spécial réservé pour signifier "la boîte aux lettres principale pour cet utilisateur sur ce serveur". (Notez que ce nom spécial peut ne pas exister sur certains serveurs pour certains utilisateurs, par exemple, si l'utilisateur n'a pas accès à l'espace de noms personnel.) L'interprétation de tous les autres noms dépend de l'implémentation.

En particulier, cette spécification ne prend pas position sur la sensibilité à la casse dans les noms de boîtes aux lettres non-INBOX. Certaines implémentations de serveur sont entièrement sensibles à la casse dans la plage ASCII ; d'autres préservent la casse d'un nom nouvellement créé mais sont par ailleurs insensibles à la casse ; et d'autres encore forcent les noms à une casse particulière. Les implémentations client doivent être capables d'interagir avec n'importe laquelle de celles-ci.

Il existe certaines considérations client lors de la création d'un nouveau nom de boîte aux lettres :

1. Tout caractère qui fait partie des atom-specials (voir "Syntaxe formelle" dans la Section 9) nécessitera que le nom de boîte aux lettres soit représenté comme une chaîne entre guillemets ou un littéral.

2. CTL et autres caractères non graphiques sont difficiles à représenter dans une interface utilisateur et il est préférable de les éviter. Les serveurs peuvent (peuvent) refuser de créer des noms de boîtes aux lettres contenant des caractères CTL Unicode.

3. Bien que les caractères génériques de liste ("%" et "*") soient valides dans un nom de boîte aux lettres, il est difficile d'utiliser de tels noms de boîtes aux lettres avec la commande LIST en raison du conflit avec l'interprétation des caractères génériques.

4. Habituellement, un caractère (déterminé par l'implémentation du serveur) est réservé pour délimiter les niveaux de hiérarchie.

5. Deux caractères, "#" et "&", ont des significations par convention et doivent être évités sauf lorsqu'ils sont utilisés dans cette convention. Voir la Section 5.1.2.1 et l'Annexe A.1, respectivement.

5.1.1 Nommage hiérarchique des boîtes aux lettres (Mailbox Hierarchy Naming)

S'il est souhaité d'exporter des noms de boîtes aux lettres hiérarchiques, les noms de boîtes aux lettres doivent (doivent) être hiérarchiques de gauche à droite, en utilisant un seul caractère ASCII pour séparer les niveaux de hiérarchie. Le même caractère séparateur de hiérarchie est utilisé pour tous les niveaux de hiérarchie dans un seul nom.

5.1.2 Espaces de noms (Namespaces)

Espace de noms personnel (Personal Namespace) : Un espace de noms que le serveur considère comme faisant partie du périmètre personnel de l'utilisateur authentifié sur une connexion particulière. En règle générale, seul l'utilisateur authentifié a accès aux boîtes aux lettres dans son espace de noms personnel. C'est la partie de l'espace de noms qui appartient à l'utilisateur et est allouée aux boîtes aux lettres. Si un INBOX existe pour un utilisateur, il doit (doit) apparaître dans l'espace de noms personnel de l'utilisateur. Dans le cas typique, il ne devrait (devrait) y avoir qu'un seul espace de noms personnel par utilisateur sur un serveur.

Espace de noms des autres utilisateurs (Other Users' Namespace) : Un espace de noms qui se compose de boîtes aux lettres provenant des espaces de noms personnels d'autres utilisateurs. Pour accéder aux boîtes aux lettres dans l'espace de noms des autres utilisateurs, l'utilisateur actuellement authentifié doit (doit) se voir accorder explicitement des droits d'accès. Par exemple, il est courant pour un gestionnaire d'accorder à son personnel de soutien administratif des droits d'accès à sa boîte aux lettres. Dans le cas typique, il ne devrait (devrait) y avoir qu'un seul espace de noms des autres utilisateurs par utilisateur sur un serveur.

Espace de noms partagé (Shared Namespace) : Un espace de noms qui se compose de boîtes aux lettres destinées à être partagées entre les utilisateurs et qui n'existent pas dans l'espace de noms personnel d'un utilisateur.

Les espaces de noms qu'un serveur utilise peuvent (peuvent) différer selon l'utilisateur.

5.1.2.1 Convention de nommage historique de l'espace de noms des boîtes aux lettres (Historic Mailbox Namespace Naming Convention)

Par convention, le premier élément hiérarchique de tout nom de boîte aux lettres commençant par "#" identifie "l'espace de noms" du reste du nom. Cela permet de lever l'ambiguïté entre différents types de magasins de boîtes aux lettres, chacun ayant ses propres espaces de noms.

Par exemple, les implémentations qui offrent l'accès aux groupes de discussion USENET peuvent (peuvent) utiliser l'espace de noms "#news" pour partitionner l'espace de noms des groupes de discussion USENET de celui des autres boîtes aux lettres. Ainsi, le groupe de discussion comp.mail.misc aurait un nom de boîte aux lettres "#news.comp.mail.misc", et le nom "comp.mail.misc" peut faire référence à un objet différent (par exemple, une boîte aux lettres privée d'un utilisateur).

Les espaces de noms qui incluent le caractère "#" ne sont pas compatibles avec les URL IMAP [IMAP-URL] et nécessitent que le caractère "#" soit représenté comme %23 dans les URL. En tant que tel, les implémenteurs de serveur peuvent (peuvent) plutôt envisager d'utiliser des préfixes d'espace de noms qui ne contiennent pas le caractère "#".

5.1.2.2 Modèles d'espace de noms courants (Common Namespace Models)

La version précédente de ce protocole n'a pas défini d'espace de noms de serveur par défaut. Deux modèles d'espace de noms courants ont évolué :

Le modèle "Boîte aux lettres personnelle" (Personal Mailbox), dans lequel l'espace de noms par défaut présenté se compose uniquement des boîtes aux lettres personnelles de l'utilisateur. Pour accéder aux boîtes aux lettres partagées, l'utilisateur doit utiliser un mécanisme d'échappement pour atteindre un autre espace de noms.

Le modèle "Hiérarchie complète" (Complete Hierarchy), dans lequel l'espace de noms par défaut présenté inclut les boîtes aux lettres personnelles de l'utilisateur ainsi que toutes les autres boîtes aux lettres auxquelles il a accès.

5.2 Taille de la boîte aux lettres et mises à jour de l'état des messages (Mailbox Size and Message Status Updates)

À tout moment, un serveur peut envoyer des données que le client n'a pas demandées. Parfois, un tel comportement est requis par cette spécification et/ou des extensions. Par exemple, des agents autres que le serveur peuvent ajouter des messages à la boîte aux lettres (par exemple, livraison de nouveaux messages) ; modifier les drapeaux des messages dans la boîte aux lettres (par exemple, accès simultané à la même boîte aux lettres par plusieurs agents) ; ou même supprimer des messages de la boîte aux lettres. Un serveur doit (doit) envoyer automatiquement des mises à jour de la taille de la boîte aux lettres si un changement de taille de boîte aux lettres est observé pendant le traitement d'une commande. Un serveur devrait (devrait) envoyer automatiquement des mises à jour des drapeaux de message, sans exiger que le client demande explicitement de telles mises à jour.

Des règles spéciales existent pour la notification du serveur à un client concernant la suppression de messages afin d'éviter les erreurs de synchronisation ; voir la description de la réponse EXPUNGE (Section 7.5.1) pour plus de détails. En particulier, il n'est PAS permis d'envoyer une réponse EXISTS qui réduirait le nombre de messages dans la boîte aux lettres ; seule la réponse EXPUNGE peut le faire.

Indépendamment des décisions d'implémentation qu'un client prend pour mémoriser les données du serveur, une implémentation client doit (doit) mémoriser les mises à jour de la taille de la boîte aux lettres. Elle ne doit pas (ne doit pas) supposer que toute commande après la sélection initiale de la boîte aux lettres renverra la taille de la boîte aux lettres.

5.3 Réponse lorsqu'aucune commande n'est en cours (Response When No Command in Progress)

Les implémentations de serveur sont autorisées à envoyer une réponse non étiquetée (sauf pour EXPUNGE) alors qu'aucune commande n'est en cours. Les implémentations de serveur qui envoient de telles réponses doivent (doivent) traiter les considérations de contrôle de flux. Plus précisément, elles doivent (doivent) soit (1) vérifier que la taille des données n'excède pas la taille de fenêtre disponible du transport sous-jacent, soit (2) utiliser des écritures non bloquantes.

5.4 Minuteur de déconnexion automatique (Autologout Timer)

Si un serveur a un minuteur de déconnexion automatique d'inactivité qui s'applique aux sessions après l'authentification, la durée de ce minuteur doit (doit) être d'au moins 30 minutes. La réception de toute commande du client pendant cet intervalle réinitialise le minuteur de déconnexion automatique.

Notez que cette spécification n'a aucune restriction sur un minuteur de déconnexion automatique utilisé avant l'authentification réussie du client. En particulier, les serveurs sont autorisés à utiliser un minuteur pré-authentification raccourci pour se protéger des attaques par déni de service.

5.5 Commandes multiples en cours (Pipeline de commandes) (Multiple Commands in Progress / Command Pipelining)

Le client peut (peut) envoyer une autre commande sans attendre la réponse de résultat d'achèvement d'une commande, sous réserve des règles d'ambiguïté (voir ci-dessous) et des contraintes de contrôle de flux sur le flux de données sous-jacent. De même, un serveur peut (peut) commencer à traiter une autre commande avant de traiter la commande actuelle jusqu'à son achèvement, sous réserve des règles d'ambiguïté. Cependant, toutes les réponses de demande de continuation de commande et les continuations de commande doivent (doivent) être négociées avant qu'une commande ultérieure ne soit initiée.

L'exception est si une ambiguïté résulterait en raison d'une commande qui affecterait les résultats d'autres commandes. Si le serveur détecte une ambiguïté possible, il doit (doit) exécuter les commandes jusqu'à leur achèvement dans l'ordre donné par le client.

L'exemple le plus évident d'ambiguïté est lorsqu'une commande affecterait les résultats d'une autre commande. Un exemple est un FETCH qui provoquerait la définition de drapeaux \Seen et une commande SEARCH UNSEEN.

Une ambiguïté non évidente se produit avec les commandes qui permettent une réponse EXPUNGE non étiquetée (commandes autres que FETCH, STORE et SEARCH), car une réponse EXPUNGE non étiquetée peut invalider les numéros de séquence dans une commande ultérieure. Ce n'est pas un problème pour les commandes FETCH, STORE ou SEARCH car les serveurs sont interdits d'envoyer des réponses EXPUNGE alors que l'une de ces commandes est en cours. Par conséquent, si le client envoie une commande autre que FETCH, STORE ou SEARCH, il doit (doit) attendre la réponse de résultat d'achèvement avant d'envoyer une commande avec des numéros de séquence de message.

Note : Les réponses EXPUNGE sont autorisées pendant que UID FETCH, UID STORE et UID SEARCH sont en cours. Si le client envoie une commande UID, il doit (doit) attendre une réponse de résultat d'achèvement avant d'envoyer une commande qui utilise des numéros de séquence de message (cela peut inclure UID SEARCH). Tous les numéros de séquence de message dans un argument de UID SEARCH sont associés aux messages avant l'effet de toute réponse EXPUNGE non étiquetée renvoyée par le UID SEARCH.

Par exemple, les séquences de commandes suivantes sans attente sont invalides :

---