Network Working Group A

Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Le présent document définit une commande UNSELECT qui peut être utilisée pour clore la boîte aux lettres en cours d’une session du protocole d’accès au message - version 4 (IMAP4) sans la purger. Certains types de clients IMAP ont besoin de libérer les ressources associées à la boîte aux lettres choisie sans choisir une boîte aux lettres différente. Bien que IMAP4 fournisse cette fonctionnalité (via une commande SELECT avec un nom de boîte aux lettres inexistant ou en resélectionnant la même boîte aux lettres avec une commande EXAMINE) une solution plus nette est souhaitable.

Table des Matières

1. Introduction 1

2. Commande UNSELECT 2

3. Considérations pour la sécurité 2

4. Syntaxe formelle 2

5. Considérations relatives à l’IANA 2

6. Remerciements 2

7. Références 2

8. Adresse de l’auteur 3

9. Déclaration complète de droits de reproduction 3

Certains types de clients IMAP ont besoin de libérer des ressources associées à la boîte aux lettres sélectionnée sans choisir une boîte aux lettres différente. Bien que [IMAP4] fournisse cette fonctionnalité (via une commande SELECT avec un nom de boîte aux lettres inexistant ou en choisissant à nouveau la même boîte aux lettres avec la commande EXAMINE) une solution plus nette est souhaitable.

[IMAP4] définit la commande CLOSE qui clôt la boîte aux lettres sélectionnée tout en supprimant de façon permanente tous les messages avec le fanion \Deleted établi.

Cependant [IMAP4] manque d’une commande qui ferme simplement la boîte aux lettres sans la purger. Le présent document définit la commande UNSELECT pour ce faire.

Un serveur qui prend en charge cette extension indique cela avec un nom de capacité de "UNSELECT".

"C:" et "S:" dans les exemples montrent les lignes envoyées respectivement par le client et le serveur.

Dans le présent document, les mots clés "DOIT", "NE DOIT PAS", "EXIGÉ", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" sont à interpréter comme décrit dans le BCP 14, [RFC2119] et indiquent les niveaux d’exigence pour les mises en œuvre conformes.

BAD – pas de boîte aux lettres sélectionnée, ou argument fourni non permis.

La commande UNSELECT libère les ressources du serveur associées à la boîte aux lettres sélectionnée et fait retourner le serveur à l’état authentifié. Cette commande effectue les mêmes actions que CLOSE, sauf qu’aucun message n’est supprimé de façon permanente de la boîte aux lettre sélectionnée.

On pense que cette extension ne soulève aucun problème de sécurité supplémentaire qui ne soit déjà discuté dans [IMAP4].

La spécification de syntaxe suivante utilise la notation du format Backus-Naur augmenté (ABNF) comme spécifié dans [ABNF]. Les non terminaisons référencées mais non définies ci-dessous sont définies par [IMAP4].

Sauf notation contraire, tous les caractères alphabétiques sont insensibles à la casse. L’utilisation de caractères majuscules ou minuscules pour définir les chaînes de jeton ne sont que pour faciliter la lecture. Une mise en œuvre DOIT accepter ces chaîne de façon insensible à la casse.

Les capacités IMAP4 sont enregistrées par la publication d’une RFC en cours de normalisation ou expérimentale approuvée par l’IESG. Le registre est actuellement situé à :

Le présent document définit la capacité IMAP UNSELECT. L’IANA a ajouté cette capacité au registre.

La commande UNSELECT a à l’origine été mise en œuvre par Tim Showalter dans le serveur Cyrus IMAP.

L’auteur de ce document souhaite aussi remercier Vladimir Butenko et Mark Crispin pour avoir rappelé que UNSELECT devait être documenté. Merci aussi à Simon Josefsson pour avoir souligné qu’il y a de nombreuses façons de mettre en œuvre UNSELECT.

[RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.

[IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 3501, mars 2003.

[ABNF] Crocker, D., éd. et P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, novembre 1997.

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations qui y sont contenues sont fournies sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY, l’IETF TRUST et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourraient être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP 78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr.

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf-ipr@ietf.org.

Le financement de la fonction d'édition des RFC est actuellement assuré par la Internet Society.

Groupe de travail Réseau	A. Melnikov, Isode Ltd.
Request for Comments : 3691	février 2004
Catégorie : En cours de normalisation	Traduction Claude Brière de L’Isle