Groupe de travail Réseau	A. Melnikov, Isode Ltd	
Request for Comments : 4731	D. Cridland, Inventure Systems Ltd	
Catégorie : Sur la voie de la normalisation	novembre 2006	
Traduction Claude Brière de L'Isle		

Extension IMAP4 de commande SEARCH pour contrôler les informations retournées

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet sur la voie de la 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.

Notice de copyright
Copyright (C) The Internet Society (2006). Tous droits réservés.

Résumé
Le présent document étend les commandes IMAP (RFC 3501) SEARCH et UID avec plusieurs options de résultat, qui peuvent contrôler quelle sorte d'information est retournée. Les options de résultat suivantes sont définies : valeur minimale, valeur maximale, tous les messages trouvés, et nombre de messages trouvés.
Table des matières
1. Introduction	1
2. Conventions utilisées dans ce document	1
3. Changements au protocole IMAP	2
3.1 Nouvelles options de résultat de SEARCH SEARCH/UID	2
3.2 Interaction avec l'extension CONDSTORE	3
4. Syntaxe formelle	3
5. Considérations sur la sécurité	4
6. Considérations relatives à l'IANA	4
7. Références normatives	4
8. Remerciements	4
Adresse des auteurs	5
Déclaration complète de droits de reproduction	5

 	1.	Introduction

La [RFC4466] a étendu les commandes SEARCH et UID SEARCH avec des spécificateurs de résultat (aussi appelés des options de résultat) qui peuvent contrôler quelle sorte d'information est retournée.

Un serveur qui annonce la capacité ESEARCH prend en charge les options de résultat suivantes : valeur minimale, valeur maximale, tous les messages trouvés, et nombre de messages trouvés. Ces options de résultat permettent aux clients d'obtenir les résultats de SEARCH sous des formes plus convenables, tout en économisant aussi la bande passante requise pour transporter les résultats, par exemple, en trouvant le premier message non vu ou en retournant le nombre de messages non vus ou supprimés. Aussi, quand une seule option de résultat MIN ou MAX est spécifiée, les serveurs peuvent optimiser l'exécution des SEARCH.

 	2.	Conventions utilisées dans ce document

Dans les exemples, "C:" et "S:" indiquent les lignes envoyées respectivement par le client et le serveur.

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans la [RFC2119] et indiquent les niveaux d’exigence pour les mises en œuvre conformes.

 	3.	Changements au protocole IMAP
 	3.1	Nouvelles options de résultat de SEARCH SEARCH/UID
Les commandes SEARCH SEARCH/UID sont étendues pour permettre les options de résultat suivantes :

MIN : Retourne le plus bas nombre/UID de messages qui satisfait les critères de SEARCH.
Si le résultat de SEARCH ne donne aucune correspondance, le serveur NE DOIT PAS inclure l'option de résultat MIN dans la réponse ESEARCH ; cependant, il DOIT quand même envoyer la réponse ESEARCH.

MAX : Retourne le plus haut numéro/UID de message qui satisfait les critères de SEARCH.
Si la commande SEARCH ne résulte en aucune correspondance, le serveur NE DOIT PAS inclure l'option de résulat MAX dans la réponse ESEARCH ; cependant, il DOIT quand même envoyer la réponse ESEARCH.

ALL : Retourne tous les numéros/UID de message qui satisfont les critères de SEARCH. À la différence du SEARCH régulier (non étendu) les messages sont toujours retournés en utilisant la syntaxe sequence-set. Une représentation de sequence-set peut être plus compacte et peut être utilisée comme elle est dans une commande suivante qui accepte sequence-set. Noter que le client NE DOIT PAS supposer que la liste des messages/UID va être dans un ordre particulier. Si le SEARCH résulte en pas de correspondance, le serveur NE DOIT PAS inclure l'option de résultat ALL dans la réponse ESEARCH ; cependant, il DOIT quand même envoyer la réponse ESEARCH.

COUNT : Retourne les nombre de messages qui satisfont les critères de SEARCH. Cette option de résultat DOIT toujours être incluse dans la réponse ESEARCH.

Si une ou plusieurs options de résultat décrites ci-dessus sont spécifiées, la commande SEARCH étendue DOIT retourner une seule réponse ESEARCH [RFC4466], au lieu de la réponse SEARCH.

Une commande UID SEARCH étendue DOIT causer une réponse ESEARCH avec l'indicateur d'UID présent.

Noter que de futures extensions au présent document peuvent permettre aux serveurs de retourner plusieurs réponses ESEARCH pour une seule commande SEARCH étendue. Ces extensions devront décrite comment les résultats de plusieurs réponses ESEARCH vont être amalgamées.
Si la liste des options de résultats est vide, cela demande au serveur de retourner une réponse ESEARCH à la place de la réponse SEARCH. C'est équivalent à "(ALL)".

Exemple :
C : A282 SEARCH RETURN (MIN COUNT) FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith"
S : * ESEARCH (TAG "A282") MIN 2 COUNT 3
S : A282 OK SEARCH terminé

Exemple :
C : A283 SEARCH RETURN () FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith"
S : * ESEARCH (TAG "A283") ALL 2,10:11
S : A283 OK SEARCH terminé

L'exemple suivant montre le premier message non vu, comme retourné dans le code de réponse UNSEEN sur une commande SELECT réussie :

Exemple :
C : A284 SEARCH RETURN (MIN) UNSEEN
S : * ESEARCH (TAG "A284") MIN 4
S : A284 OK SEARCH terminé

L'exemple suivant montre que si l'indicateur UID ESEARCH est présent, toutes les données dans la réponse ESEARCH se réfèrent aux UID ; par exemple, le spécificateur de résultat MIN va être suivi d'un UID.

Exemple :
C : A285 UID SEARCH RETURN (MIN MAX) 1:5000
S : * ESEARCH (TAG "A285") UID MIN 7 MAX 3800
S : A285 OK SEARCH terminé

L'exemple suivant montre le retour du nombre de messages supprimés :

Exemple :
C : A286 SEARCH RETURN (COUNT) DELETED
S : * ESEARCH (TAG "A286") COUNT 15
S : A286 OK SEARCH terminé

 	3.2	Interaction avec l'extension CONDSTORE
Quand le serveur prend en charge les deux extensions ESEARCH et CONDSTORE [RFC4551] , et que le client demande une ou plusieurs options de résultat décrites au paragraphe 3.1 avec le critère de recherche MODSEQ dans la même commande SEARCH/UID SEARCH, le serveur DOIT alors retourner la réponse ESEARCH contenant l'option de résultat MODSEQ (décrite au paragraphe suivant) au lieu de la réponse SEARCH étendue décrite au paragraphe 3.5 de la [RFC4551].

Si la commande SEARCH/UID SEARCH contenait une seule option de résultat MIN ou MAX, l'option de résultat MODSEQ contient la mod-sequence pour le message trouvé. Si la commande SEARCH/UID SEARCH contenait les deux options de résultat MIN et MAX et pas d'option ALL/COUNT, l'option de résultat MODSEQ contient la plus haute mod-sequence pour les deux messages retournés. Autrement, l'option de résultat MODSEQ contient la plus haute mod-sequence pour tous les messages retournés.

L'exemple suivant montre à quoi l'exemple 15 de la [RFC4551] ressemblerait en présence d'une ou plusieurs options de résultat :
Exemple : 
C : a1 SEARCH RETURN (MIN) MODSEQ "/flags/\\draft" all 620162338
S : * ESEARCH (TAG "a1") MIN 2 MODSEQ 917162488
S : a1 OK recherche terminée
C : a2 SEARCH RETURN (MAX) MODSEQ "/flags/\\draft" all 620162338
S : * ESEARCH (TAG "a2") MAX 23 MODSEQ 907162321
S : a2 OK recherche terminée
C : a3 SEARCH RETURN (MIN MAX) MODSEQ "/flags/\\draft" all 620162338
S : * ESEARCH (TAG "a3") MIN 2 MAX 23 MODSEQ 917162488
S : a3 OK recherche terminée
C : a4 SEARCH RETURN (MIN COUNT) MODSEQ "/flags/\\draft" all 620162338
S : * ESEARCH (TAG "a4") MIN 2 COUNT 10 MODSEQ 917162500
S : a4 OK recherche terminée

 	4.	Syntaxe formelle

La spécification de syntaxe suivante utilise la notation de format Backus-Naur augmenté (ABNF) spécifée dans la [RFC4234].

Les non-terminaux référencés mais non définis ci-dessous sont définis par les [RFC3501], [RFC4551], ou [RFC4466].

Sauf notation contraire, tous les caractères alphabétiques sont insensibles à la casse. L'utilisation de caractères majuscules ou minuscules pour définir des chaînes de jetons est seulement pour faciliter la lecture. Les mises en œuvre DOIVENT accepter ces chaînes comme insensibles à la casse.

capability =/ "ESEARCH"

search-return-data = "MIN" SP nz-number / "MAX" SP nz-number / "ALL" SP sequence-set / "COUNT" SP number
;; conforme à la syntaxe générique de search-return-data définie dans la [RFC4466] ;;

search-return-opt  = "MIN" / "MAX" / "ALL" / "COUNT"
;; conforme à la syntaxe générique de search-return-opt définie dans la [RFC4466] ;;

Quand l'extension IMAP CONDSTORE [RFC4551] est aussi prise en charge, l'ABNF est mis à jour comme suit :

search-return-data =/ "MODSEQ" SP mod-sequence-value
;; mod-sequence-value est défini dans la [RFC4551] ;;

 	5.	Considérations sur la sécurité

En général, les commandes IMAP SEARCH/UID SEARCH peuvent être grosses consommatrices de CPU et/ou IO, et sont vues par certains comme un potentiel point d'attaque pour le déni de service, de sorte que certains sites/mises en œuvre les désactivent même entièrement. C'est assez dommage, car la commande SEARCH est un des meilleurs exemples qui démontrent les avantages de IMAP sur POP3.

Les options de retour ALL et COUNT ne changent pas la façon dont SEARCH fonctionne en interne ; elles changent seulement la façon dont les informations sur les messages trouvés sont retournées. Les options de résultat MIN et MAX de SEARCH décrite dans le présent document peuvent alléger la charge sur les serveurs IMAP qui choisissent d'optimiser les recherches contenant seulement une d'entre elles ou les deux.

Il est estimé que cette extension ne soulève aucun problème de sécurité supplémentaire non déjà discuté dans la [RFC3501].

 	6.	Considérations relatives à l'IANA

Les capacités de IMAP4 sont enregistrées par la publication d'une RFC sur la voie de la normalisation ou par une RFC expérimentale approuvée par l'IESG. Le registre est actuellement situé à <http://www.iana.org/assignments/imap4-capabilities >.

Le présent document définit la capacité IMAP ESEARCH, que l'IANA a ajouté au registre.

 	7.	Références normatives

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

[RFC3501]	M. Crispin, "Protocole d'accès au message Internet - version 4rev1", mars 2003. (P.S. ; MàJ par RFC4466, 4469, 4551, 5032, 5182, 7817, 8314, 8437, 8474)

[RFC4234]	D. Crocker et P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", octobre 2005. (Remplace RFC2234, remplacée par RFC5234)

[RFC4466]	A. Melnikov, C. Daboo, "Récapitulation des extensions à l'ABNF pour IMAP4", avril 2006. (P.S.)

[RFC4551]	A. Melnikov, S. Hole, "Extension à IMAP pour l'opération STORE conditionnelle ou la resynchronisation des changements rapides de fanion", juin 2006. (MàJ RFC3501) (P.S.  ; Remplacée par RFC7162)

 	8.	Remerciements

Merci à Michael Wener, Arnt Gulbrandsen, Cyrus Daboo, Mark Crispin, et Pete Maclean de leurs commentaires et corrections.

 	Adresse des auteurs

Alexey Melnikov	Dave A. Cridland	
Isode Limited	Inventure Systems Limited	
5 Castle Business Village	mél : dave.cridland@inventuresystems.co.uk 	
36 Station Road	URL: http://invsys.co.uk/dave/ 	
Hampton, Middlesex, TW12 2BX		
UK		
mél : Alexey.Melnikov@isode.com 		

 	Déclaration complète de droits de reproduction
Copyright (C) The IETF Trust (2006)

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 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, le 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 encloses ne viole 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 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 le 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 la Internet Society.