Aller au contenu principal

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

  1. Les caractères CTL et autres caractères non graphiques sont difficiles à représenter dans une interface utilisateur et il est préférable de les éviter.

  2. 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 les commandes LIST et LSUB en raison du conflit avec l'interprétation des caractères génériques.

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

  4. Deux caractères, "#" et "&", ont des significations par convention et devraient être évités sauf lorsqu'ils sont utilisés dans cette convention.

5.1.1. Nommage de la hiérarchie 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 (MUST) être hiérarchiques de gauche à droite en utilisant un seul caractère pour séparer les niveaux de hiérarchie. Le même caractère de séparateur de hiérarchie est utilisé pour tous les niveaux de hiérarchie dans un seul nom.

5.1.2. Convention de nommage de l'espace de noms des boîtes aux lettres (Mailbox Namespace Naming Convention)​

Par convention, le premier élément hiérarchique de tout nom de boîte aux lettres qui commence par "#" identifie « l'espace de noms (Namespace) » du reste du nom. Cela permet de lever l'ambiguïté entre différents types de magasins de boîtes aux lettres, chacun ayant son propre espace de noms.

Par exemple, les implémentations qui offrent un accès aux groupes de discussion USENET PEUVENT (MAY) 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).

5.1.3. Convention de nommage international des boîtes aux lettres (Mailbox International Naming Convention)​

Par convention, les noms de boîtes aux lettres internationaux dans IMAP4rev1 sont spécifiés à l'aide d'une version modifiée de l'encodage UTF-7 (Encoding) décrit dans [UTF-7]. L'UTF-7 modifié peut également être utilisable dans les serveurs qui implémentent une version antérieure de ce protocole.

Dans l'UTF-7 modifié, les caractères US-ASCII imprimables, à l'exception de "&", se représentent eux-mêmes ; c'est-à-dire les caractères avec des valeurs d'octet 0x20-0x25 et 0x27-0x7e. Le caractère "&" (0x26) est représenté par la séquence de deux octets "&-".

Tous les autres caractères (valeurs d'octet 0x00-0x1f et 0x7f-0xff) sont représentés en BASE64 modifié, avec une modification supplémentaire de [UTF-7] selon laquelle "," est utilisé au lieu de "/". Le BASE64 modifié NE DOIT PAS (MUST NOT) être utilisé pour représenter tout caractère US-ASCII imprimable qui peut se représenter lui-même.

"&" est utilisé pour passer au BASE64 modifié et "-" pour revenir à US-ASCII. Il n'y a pas de passage implicite de BASE64 à US-ASCII, et les passages nuls ("-&" en BASE64 ; notez que "&-" en US-ASCII signifie "&") ne sont pas autorisés. Cependant, tous les noms commencent en US-ASCII et DOIVENT (MUST) se terminer en US-ASCII ; c'est-à-dire qu'un nom se terminant par un caractère ISO-10646 non-ASCII DOIT (MUST) se terminer par un "-".

Le but de ces modifications est de corriger les problèmes suivants avec UTF-7 :

  1. UTF-7 utilise le caractère "+" pour le passage ; cela entre en conflit avec l'utilisation courante de "+" dans les noms de boîtes aux lettres, en particulier les noms de groupes de discussion USENET.

  2. L'encodage UTF-7 est BASE64 qui utilise le caractère "/" ; cela entre en conflit avec l'utilisation de "/" comme délimiteur de hiérarchie populaire.

  3. UTF-7 interdit l'utilisation non encodée de "" ; cela entre en conflit avec l'utilisation de "" comme délimiteur de hiérarchie populaire.

  4. UTF-7 interdit l'utilisation non encodée de "" ; cela entre en conflit avec l'utilisation de "" dans certains serveurs comme indicateur de répertoire personnel.

  5. UTF-7 permet plusieurs formes alternatives pour représenter la même chaîne ; en particulier, les caractères US-ASCII imprimables peuvent être représentés sous forme encodée.

Bien que l'UTF-7 modifié soit une convention, il établit certaines exigences sur la gestion par le serveur de tout nom de boîte aux lettres avec un caractère "&" intégré. En particulier, les implémentations de serveur DOIVENT (MUST) préserver la forme exacte de la partie BASE64 modifiée d'un nom UTF-7 modifié et traiter ce texte comme sensible à la casse, même si les noms sont autrement insensibles à la casse ou pliés en casse.

Les implémentations de serveur DEVRAIENT (SHOULD) vérifier que tout nom de boîte aux lettres avec un caractère "&" intégré, utilisé comme argument pour CREATE, est : dans la syntaxe UTF-7 modifiée correctement, n'a pas de passages superflus et n'a pas d'encodage en BASE64 modifié de tout caractère US-ASCII imprimable qui peut se représenter lui-même. Cependant, les implémentations de client NE DOIVENT PAS (MUST NOT) dépendre du serveur faisant cela, et NE DEVRAIENT PAS (SHOULD NOT) tenter de créer un nom de boîte aux lettres avec un caractère "&" intégré à moins qu'il ne soit conforme à la syntaxe UTF-7 modifiée.

Les implémentations de serveur qui exportent un magasin de courrier qui ne suit pas la convention UTF-7 modifiée DOIVENT (MUST) convertir en UTF-7 modifié tout nom de boîte aux lettres contenant soit des caractères non-ASCII, soit le caractère "&".

Par exemple, voici un nom de boîte aux lettres qui mélange du texte anglais, chinois et japonais :
~peter/mail/&U,BTFw-/&ZeVnLIqe-

Par exemple, la chaîne "&Jjo!" n'est pas un nom de boîte aux lettres valide car elle ne contient pas de passage vers US-ASCII avant le "!". La forme correcte est "&Jjo-!". La chaîne "&U,BTFw-&ZeVnLIqe-" n'est pas autorisée car elle contient un passage superflu. La forme correcte est "&U,BTF2XlZyyKng-".

5.2. Mises à jour de la taille des boîtes aux lettres et 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 (REQUIRED). Par exemple, des agents autres que le serveur PEUVENT (MAY) 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 (MUST) envoyer automatiquement des mises à jour de taille de 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 (SHOULD) envoyer automatiquement des mises à jour de drapeaux de message, sans exiger que le client demande explicitement de telles mises à jour.

Des règles spéciales existent pour la notification par le serveur à un client de la suppression de messages pour éviter les erreurs de synchronisation ; voir la description de la réponse EXPUNGE pour plus de détails. En particulier, il n'est PAS autorisé 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.

Quelles que soient les décisions d'implémentation qu'un client prend sur la mémorisation des données du serveur, une implémentation de client DOIT (MUST) enregistrer les mises à jour de taille de boîte aux lettres. Elle NE DOIT PAS (MUST NOT) supposer que toute commande après la sélection initiale de 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 (à l'exception d'EXPUNGE) alors qu'aucune commande n'est en cours. Les implémentations de serveur qui envoient de telles réponses DOIVENT (MUST) gérer les considérations de contrôle de flux. Plus précisément, elles DOIVENT (MUST) soit (1) vérifier que la taille des données ne dépasse pas la taille de fenêtre disponible du transport sous-jacent, soit (2) utiliser des écritures non bloquantes.

5.4. Minuterie de déconnexion automatique (Autologout Timer)​

Si un serveur a une minuterie de déconnexion automatique pour inactivité, la durée de cette minuterie DOIT (MUST) être d'au moins 30 minutes. La réception de N'IMPORTE QUELLE commande du client pendant cet intervalle DEVRAIT (SHOULD) suffire à réinitialiser la minuterie de déconnexion automatique.

5.5. Plusieurs commandes en cours (Multiple Commands in Progress)​

Le client PEUT (MAY) envoyer une autre commande sans attendre la réponse de résultat de complétion 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 (MAY) commencer à traiter une autre commande avant de terminer le traitement de la commande en cours, 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 (MUST) être négociées avant que toute commande ultérieure ne soit initiée.

L'exception est si une ambiguïté résulterait d'une commande qui affecterait les résultats d'autres commandes. Les clients NE DOIVENT PAS (MUST NOT) envoyer plusieurs commandes sans attendre si une ambiguïté résulterait. Si le serveur détecte une ambiguïté possible, il DOIT (MUST) 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, par exemple un FETCH des drapeaux d'un message et un STORE des drapeaux de ce même message.

Une ambiguïté non évidente se produit avec les commandes qui autorisent 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 pendant 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 (MUST) attendre la réponse de résultat de complétion avant d'envoyer une commande avec des numéros de séquence de message.

Remarque : UID FETCH, UID STORE et UID SEARCH sont des commandes différentes de FETCH, STORE et SEARCH. Si le client envoie une commande UID, il doit attendre une réponse de résultat de complétion avant d'envoyer une commande avec des numéros de séquence de message.

Dernière mise à jour le