Protocole d’accès aux messages Internet (IMAP) - Extension MULTIAPPEND

Statut du présent mémoire

Le présent document spécifie un protocole de normalisation Internet pour la communauté Internet, et appelle à discussion et suggestions en vue de son amélioration. Prière de se rapporter à l’édition en cours des "Internet Official Protocol Standards" (normes officielles du protocole Internet) (STD 1) pour connaître l’état de la normalisation et le statut du présent protocole. La distribution du présent mémo n’est pas soumise à restrictions.

Déclaration de copyright

Copyright (C) The Internet Society (2003). Tous droits réservés

Résumé

Le présent document décrit l’extension multiappending au protocole d’accès aux messages Internet (IMAP, Internet Message Access Protocol) (RFC 3501). Cette extension apporte des améliorations de performances substantielles aux clients IMAP qui téléchargent plusieurs messages à la fois vers une boîte aux lettre sur le serveur.

Un serveur qui prend en charge cette extension l’indique avec un nom de capacité de "MULTIAPPEND".

Terminologie

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "PEUT", et "FACULTATIF" dans le présent document sont à interpréter comme décrit dans [KEYWORDS].

Introduction

L’extension MULTIAPPEND permet le téléchargement de plusieurs messages avec une seule commande. Lorsque utilisée en conjonction avec l’extension [LITERAL+], le téléchargement tout entier est accompli par un seul aller-retour de commande/réponse.

Une opération MULTIAPPEND APPEND est atomique; soit tous les messages sont bien ajoutés, soit aucun message n’est ajouté.

Dans la spécification IMAP de base, chaque message doit être ajouté avec une commande distincte, et il n’y a pas de mécanisme pour "désajouter" les messages si une erreur survient pendant l’ajout. Aussi, certaines mémorisations de messagerie peuvent exiger une opération coûteuse de "ouverture/verrouillage + sync/déverrouillage/fermeture" au titre de l’ajout : cela peut être assez coûteux si cela doit être fait message par message.

Si le serveur accepte à la fois LITERAL+ et l’intubage mais pas MULTIAPPEND, il est possible d’obtenir certains des avantages de performances de MULTIAPPEND en faisant un ajout "par lot" en intubage. Cependant, cela ne fonctionnera pas aussi bien que MULTIAPPEND pour les raisons suivantes :

1) Des commandes APPEND multiples, même au titre d’un lot intubé, sont non atomiques par définition. Il n’y a aucun moyen de faire revenir la boîte aux lettres à l’état antérieur à l’ajout du lot en cas d’erreur.

2) Il peut n’être pas possible au serveur de grouper les opérations APPEND intubées de façon à éviter la surcharge de "ouverture/verrouillage + sync/déverrouillage/fermeture" décrite ci-dessus. Dans tous les cas, un tel groupage prendrait du temps et serait donc potentiellement non fiable. En particulier, avec les fichiers de boîte aux lettres UNIX traditionnels, on suppose qu’un verrouillage ne tient que pour une seule opération atomique, et de nombreuses applications n’aiment pas qu’un verrouillage dure plus de 5 minutes.

3) Si une erreur survient, selon la nature de l’erreur, il est possible que des messages supplémentaires soient ajoutés après l’erreur. Par exemple, l’usager veut ajouter cinq messages, mais une erreur de quota de disque survient avec le troisième message à cause de sa taille. Cependant, les quatrième et cinquième messages ont déjà été envoyés dans le tube, de sorte que la boîte aux lettres termine avec le premier, second, quatrième et cinquième messages du lot ajoutés.

6.3.11 Commande APPEND

Arguments : nom de boîte aux lettres

un ou plusieurs messages à charger, spécifiés comme :

liste entre parenthèses avec le fanion FACULTATIF

chaîne date/heure FACULTATIVE

texte du message

Données : pas de réponses spécifiques pour cette commande

Résultat : OK – ajout terminé

NO – erreur d’ajout : pas possible de faire un ajout à cette boîte aux lettres, erreur dans les fanions ou dans date/heure ou dans le texte du message, ajout annulé

BAD – commande inconnue ou arguments invalides

La commande APPEND ajoute les arguments textuels comme nouveaux messages à la fin de la boîte aux lettres de destination spécifiée. Cet argument DEVRAIT être dans le format d’un message de la [RFC-2822]. Les caractères de 8 bits sont permis dans le message. Une mise en œuvre de serveur qui n’est pas capable de préserver correctement les données à 8 bits DOIT être capable de convertir de façon réversible les données APPEND à 8 bits en 7 bits en utilisant un codage de transfert de contenu [MIME-IMB].

Note : Il PEUT y avoir des exceptions, par exemple, les projets de message, dans lesquels les lignes d’en-tête exigées par la [RFC-2822] sont omises dans l’argument à APPEND du texte du message. Les pleines implications de cette façon de faire DOIVENT être comprises et soigneusement appréciées.

Si une liste entre parenthèses de fanions est spécifiée, les fanions DEVRAIENT être établis dans le message résultant ; autrement, la liste de fanions dans le message résultant est établie vide par défaut.

Si une date-heure est spécifiee, la date interne DEVRAIT être établie dans le message résultant ; autrement, la date interne du message résultant est établie par défaut à la date et heure courantes.

Un argument littéral de message de longueur zéro est une erreur, et DOIT retourner un NO. Cela peut être utilisé pour annuler l’ajout.

Si l’ajout est un échec pour une raison quelconque (y compris son annulation), la boîte aux lettres DOIT être restaurée à son état antérieur à la tentative de APPEND ; aucun ajout partiel n’est permis. Le serveur PEUT retourner une erreur avant de traiter tous les arguments de message.

Si la boîte aux lettres de destination n’existe pas, un serveur DOIT retourner une erreur, et NE DOIT PAS créer automatiquement la boîte aux lettres. Sauf s’il est certain que la boîte aux lettres de destination ne peut pas être créée, le serveur DOIT envoyer le code de réponse "[TRYCREATE]" comme préfixe du texte de la réponse NO étiquetée. Cela donne l’indication au client qu’il peut essayer une commande CREATE et réessayer la commande APPEND si le CREATE réussit.

Si la boîte aux lettres est actuellement sélectionnée, les actions normales de nouveau message DEVRAIENT survenir. Précisément, le serveur DEVRAIT notifier le client immédiatement via une réponse EXISTS non marquée. Si le serveur ne le fait pas, le client PEUT produire une commande NOOP (ou à défaut, une commande CHECK) après une ou plusieurs commandes APPEND.

Exemple :

C: A003 APPEND saved-messages (\Seen) {329}
S: + Ready for literal data
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
C: From: Fred Foobar <foobar@Blurdybloop.example.COM>
C: Subject: réunion d’après midi
C: To: mooch@owatagu.example.net
C: Message-Id: <B27397-0100000@Blurdybloop.example.COM>
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: Hello Joe, penses-tu qu’on puisse se réunir à 15:30 demain ?
C: (\Seen) " 7-Feb-1994 22:43:04 -0800" {295}
S: + Ready for literal data
C: Date: Mon, 7 Feb 1994 22:43:04 -0800 (PST)
C: From: Joe Mooch <mooch@OWaTaGu.example.net>
C: Subject: Re: réunion d’après midi
C: To: foobar@blurdybloop.example.com
C: Message-Id: <a0434793874930@OWaTaGu.example.net>
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: 15:30 me convient.
C:
S: A003 OK APPEND completed
C: A004 APPEND bogusname (\Flagged) {1023}
S: A004 NO [TRYCREATE] No such mailbox as bogusname
C: A005 APPEND test (\Flagged) {99}
S: + Ready for literal data
C: Date: Mon, 7 Feb 2000 22:43:04 -0800 (PST)
C: From: Fred Foobar <fred@example.com>
C: Subject: hmm...
C: {35403}
S: A005 NO APPEND failed: Disk quota exceeded

Note : La commande APPEND n’est pas utilisée pour la livraison de message, parce qu’elle ne fournit pas de mécanisme de transfert [SMTP] des informations d’enveloppe.

Modification à la syntaxe formelle du protocole de base IMAP4rev1

La spécification de syntaxe suivante utilise la notation en forme Backus-Naur augmentée (ABNF) comme spécifié dans [ABNF].

append = "APPEND" SP mailbox 1*append-message

append-message = [SP flag-list] [SP date-time] SP literal

Interaction MULTIAPPEND avec l’extension UIDPLUS

Les serveurs qui acceptent à la fois MULTIAPPEND et [UIDPLUS] devront modifier la règle "resp-code-apnd" comme suit :

resp-code-apnd = "APPENDUID" SP nz-number SP set

C’est à dire que le code de réponse APPENDUID retourne autant d’UID qu’il y avait de messages ajoutés dans les divers ajouts. Les UID retournés devraient être dans l’ordre où les articles ont été ajoutés. Le message établi ne doit pas contenir d’UID étrangers ou le symbole "*".

Considérations pour la sécurité

L’extension MULTIAPPEND ne soulève aucun problème de sécurité qui ne soit déjà présent dans le protocole [IMAP] de base, et ces questions sont exposées dans [IMAP]. Néanmoins, il est important de se souvenir que les transactions de protocole IMAP4rev1, y compris las données de messagerie électronique, sont envoyées en clair sur le réseau sauf négociation d’une protection contre l’espionnage, soit par l’utilisation de la protection de confidentialité STARTTLS, négociée dans la commande AUTHENTICATE, soit par l’effet d’un autre mécanisme de protection.

Références normatives

[ABNF] D. Crocker et P. Overell, "BNF augmenté pour les spécifications de syntaxe: ABNF", RFC 2234, novembre 1997.

[IMAP] M. Crispin, "Protocole d’accès aux messages Internet - version 4rev1", RFC 3501, mars 2003.

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

[MIME-IMB] N. Freed et N. Borenstein, "MIME ( extensions multi-usage de messagerie Internet ) Partie une : Format des corps de message Internet", RFC 2045, novembre 1996.

[RFC-2822] P. Resnick, "Format des messages Internet", RFC 2822, avril 2001.

Références informatives

[LITERAL+] J. Myers, "IMAP4 non-synchronizing literals", RFC 2088, janvier 1997.

[UIDPLUS] J. Myers, "Extension UIDPLUS à IMAP4", RFC 2359, juin 1988.

[SMTP] J. Klensin, éditeur, "Protocole simple de transfert de messagerie", RFC 2821, avril 2001.

Adresse de l’auteur

Mark R. Crispin
Networks and Distributed Computing
University of Washington
4545 15th Avenue NE
Seattle, WA 98105-4527
téléphone: (206) 543-5762
mèl : MRC@CAC.Washington.EDU

Déclaration de copyright

Copyright (C) The Internet Society (2006).

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

Le présent document et les informations y 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 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.

Propriété intellectuelle

L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourrait ê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.

Remerciement

Le financement de la fonction d’édition des RFC est actuellement fourni par l’activité de soutien administratif (IASA) de l’IETF.