Groupe de travail Réseau |
E. Burger, éditeur |
Request for Comments : 5032 |
BEA Systems, Inc. |
RFC mise à jour : 3501 |
septembre 2007 |
Catégorie : En cours de normalisation |
Traduction Claude Brière de L’Isle |
Statut du présent mémoire
Le présent document spécifie un protocole de normalisation Internet pour la communauté Internet, et appelle à discussions 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 soumise à aucune restriction.
Résumé
Le présent document décrit l’extension WITHIN à IMAP SEARCH. IMAP SEARCH retourne des messages dont la date interne est au sein ou en dehors d’un intervalle spécifié. Le mécanisme décrit ici , OLDER et YOUNGER, diffère de BEFORE et SINCE en ce que le client spécifie un intervalle, plutôt qu’une date. WITHIN est utile pour les recherches persistantes où soit l’appareil n’a pas la capacité d’effectuer la recherche à des intervalles réguliers, soit le réseau a une bande passante limitée et donc il y a un désir de réduire le trafic d’envoi de demandes répétées et de réponses redondantes sur le réseau.
Cette extension expose deux nouvelles clés de recherche, OLDER (plus ancien) et YOUNGER (plus récent), dont chacune prend un argument d’entier non nul correspondant à un intervalle de temps en secondes. Le serveur calcule le temps d’intérêt en soustrayant l’intervalle de temps présenté par le client de la date et l’heure actuelles au serveur. Le serveur retourne alors les messages older (plus ancien) ou younger (plus récent) que la date et l’heure résultantes, selon la clé de recherche utilisée.
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", "RECOMMANDÉ", "PEUT", et "FACULTATIF" dans ce document sont à interpréter comme décrit dans la [RFC2119].
Lors de la description de la syntaxe générale, certaines définitions sont omises, car elles figurent dans la [RFC3501].
Un serveur IMAP4 qui prend en charge la capacité décrite ici DOIT retourner "WITHIN" comme une des capacités prises en charge par le serveur dans la commande CAPABILITY.
Pour les deux clés de recherche OLDER et YOUNGER, le serveur calcule une date et heure cible en soustrayant l’intervalle, spécifié en secondes, de la date et heure actuelle du serveur. Le serveur compare alors l’heure cible à la INTERNALDATE du message, comme spécifié dans IMAP [RFC3501]. Pour OLDER, les messages correspondent si la INTERNALDATE est moins récente que l’heure cible ou égale à elle. Pour YOUNGER, les messages correspondent si la INTERNALDATE est plus récente que l’heure cible ou égale à elle.
Les recherches OLDER et YOUNGER résultent toujours toutes deux en une correspondance exacte, à la résolution d’une seconde. Cependant, si on fait une évaluation dynamique, par exemple, dans un contexte [CONTEXT], il faut savoir que le serveur peut effectuer périodiquement l’évaluation. Et donc, le serveur peut différer les mises à jour. Les clients DOIVENT savoir que des résultats de recherche dynamique peuvent ne pas refléter l’état actuel de la boîte aux lettres. Si le client a besoin d’un résultat de recherche qui reflète l’état actuel de la boîte aux lettres, il est RECOMMANDÉ que le client produise une nouvelle recherche.
La spécification de syntaxe suivante utilise la notation de la forme Backus-Naur augmentée (ABNF, Augmented Backus-Naur Form). Les éléments non définis ici pourront être trouvés dans la syntaxe formelle de l’ABNF [RFC4234] et dans IMAP [RFC3501].
Le présent document étend la [RFC3501] avec deux nouvelles clés de recherche : OLDER <interval> et YOUNGER <interval>.
search-key =/ ( "OLDER" / "YOUNGER" ) SP nz-number ; search-key est défini dans la RFC 3501
C : a1 SEARCH UNSEEN YOUNGER 259200
S : a1 * SEARCH 4 8 15 16 23 42
Chercher tous les messages non lus dans les trois derniers jours, ou 259 200 secondes, selon l’heure actuelle du serveur.
L’extension WITHIN ne soulève aucune considérations pour la sécurité qui ne soit déjà présente dans le protocole de base. Les considérations sont les mêmes que pour IMAP [RFC3501].
Selon la RFC IMAP [RFC3501], les enregistrements de nouvelles capacités IMAP dans le registre des capacités IMAP exigent la publication d’une RFC en cours de normalisation ou d’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 en cours de normalisation définit la capacité IMAP WITHIN. L’IANA a ajouté cette extension au registre des capacités IMAP de l’IANA.
[RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d’exigence", RFC 2119, BCP 14, mars 1997.
[RFC3501] M. Crispin, "Protocole d’accès aux messages Internet - Version 4rev1", RFC 3501, mars 2003.
[RFC4234] D. Crocker, éd. et P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", RFC 4234, octobre 2005.
[CONTEXT] D. Melnikov et C. King, "Contextes for IMAP4", Travail en cours, mai 2006.
Stephane Maes et Ray Cromwell ont écrit la version originale du présent document au titre de P-IMAP, ainsi que les premières versions pour l’IETF. De ce point de vue, ils sont évidement les auteurs.
L’éditeur tient à remercier tous ceux qui ont contribué aux appports clés et qui ont largement révisé et discuté les concepts de LPSEARCH. Il faut aussi remercier les auteurs de son introduction précoce dans P-IMAP.
Des remerciements particuliers pour Arnt Gilbrandsen, Ken Murchison, Zoltan Ordogh, et tout spécialement pour Dave Cridland pour leur relecture et leurs suggestions. Un grand merci à Alexey Melnikov pour ses remarquables propositions de texte.
Adresse de l’auteur
Eric W. Burger (editor)
BEA Systems, Inc.
USA
mél : eric.burger@bea.com
URI : http://www.standardstrack.com
Déclaration complète de copyright
Copyright (C) The IETF Trust (2007).
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 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.