draft-ietf-lemonade-search-within-05.txt   rfc5032.txt 
Lemonade E. Burger, Ed. Network Working Group E. Burger, Ed.
Internet-Draft BEA Systems, Inc. Request for Comments: 5032 BEA Systems, Inc.
Updates: RFC 3501 June 1, 2007 Updates: 3501 September 2007
(if approved) Category: Standards Track
Intended status: Standards Track
Expires: December 3, 2007
WITHIN Search extension to the IMAP Protocol
draft-ietf-lemonade-search-within-05
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 3, 2007. WITHIN Search Extension to the IMAP Protocol
Copyright Notice Status of This Memo
Copyright (C) The IETF Trust (2007). This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract Abstract
This document describes the WITHIN extension to IMAP SEARCH. IMAP This document describes the WITHIN extension to IMAP SEARCH. IMAP
SEARCH returns messages whose internal date is within or outside a SEARCH returns messages whose internal date is within or outside a
specified interval. The mechanism described here, OLDER and YOUNGER, specified interval. The mechanism described here, OLDER and YOUNGER,
differs from BEFORE and SINCE in that the client specifies an differs from BEFORE and SINCE in that the client specifies an
interval, rather than a date. WITHIN is useful for persistent interval, rather than a date. WITHIN is useful for persistent
searches where either the device does not have the capacity to searches where either the device does not have the capacity to
perform the search at regular intervals or the network is of limited perform the search at regular intervals or the network is of limited
bandwidth and thus there is a desire to reduce network traffic from bandwidth and thus there is a desire to reduce network traffic from
sending repeated requests and redundant responses. sending repeated requests and redundant responses.
Conventions Used in this Document 1. Introduction
This extension exposes two new search keys, OLDER and YOUNGER, each
of which takes a non-zero integer argument corresponding to a time
interval in seconds. The server calculates the time of interest by
subtracting the time interval the client presents from the current
date and time of the server. The server then either returns messages
older or younger than the resultant time and date, depending on the
search key used.
1.1. Conventions Used in This Document
In examples, "C:" and "S:" indicate lines sent by the client and In examples, "C:" and "S:" indicate lines sent by the client and
server respectively. server, respectively.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [RFC2119].
When describing the general syntax, we omit some definitions as RFC
3501 [2] defines them.
1. Introduction
This extension exposes two new search keys, OLDER and YOUNGER, each When describing the general syntax, we omit some definitions, as RFC
of which takes a non-zero integer argument corresponding to a time 3501 [RFC3501] defines them.
interval in seconds. The server calculates the time of interest by
subtracting the time interval the client presents. The server then
either returnings messages older or younger than the resultant time
and date, depending on the search key used.
2. Protocol Operation 2. Protocol Operation
An IMAP4 server that supports the capability described here MUST An IMAP4 server that supports the capability described here MUST
return "WITHIN" as one of the server supported capabilities in the return "WITHIN" as one of the server supported capabilities in the
CAPABILITY command. CAPABILITY command.
For both the OLDER and YOUNGER search keys, the server calculates a For both the OLDER and YOUNGER search keys, the server calculates a
target date and time by subtracting the interval, specified in target date and time by subtracting the interval, specified in
seconds, from the current date and time of the server. The server seconds, from the current date and time of the server. The server
then compares the target time with the INTERNALDATE of the message, then compares the target time with the INTERNALDATE of the message,
as specified in IMAP [2]. For OLDER, messages match if the as specified in IMAP [RFC3501]. For OLDER, messages match if the
INTERNALDATE is less recent than or equal to the target time. For INTERNALDATE is less recent than or equal to the target time. For
YOUNGER, messages match if the INTERNALDATE is more recent than, or YOUNGER, messages match if the INTERNALDATE is more recent than or
equal to, the target time. equal to the target time.
Both OLDER and YOUNGER searches always result in exact matching, to Both OLDER and YOUNGER searches always result in exact matching, to
the resolution of a second. However, if one is doing a dynamic the resolution of a second. However, if one is doing a dynamic
evaluation, for example, in a context [4], one needs to be aware the evaluation, for example, in a context [CONTEXT], one needs to be
server might perform the evaluation periodically. Thus, the server aware that the server might perform the evaluation periodically.
may delay the updates. Clients MUST be aware that dynamic search Thus, the server may delay the updates. Clients MUST be aware that
results may not reflect the current state of the mailbox. If the dynamic search results may not reflect the current state of the
client needs a search result that reflects the current state of the mailbox. If the client needs a search result that reflects the
mailbox, we RECOMMEND the client issues a new search. current state of the mailbox, we RECOMMEND that the client issue a
new search.
3. Formal Syntax 3. Formal Syntax
The following syntax specification uses the Augmented Backus-Naur The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) notation. Elements not defined here can be found in the Form (ABNF) notation. Elements not defined here can be found in the
formal syntax of ABNF [1], IMAP [2], and IMAP Extended ABNF [3] formal syntax of ABNF [RFC4234] and IMAP [RFC3501].
This document extends RFC 3501 [RFC3501] with two new search keys:
OLDER <interval> and YOUNGER <interval>.
This document extends RFC 3501 [2] with two new search keys: OLDER
<interval> and YOUNGER <interval>.
search-key =/ ( "OLDER" / "YOUNGER" ) SP nz-number search-key =/ ( "OLDER" / "YOUNGER" ) SP nz-number
; search-key defined in RFC 3501 ; search-key defined in RFC 3501
4. Example 4. Example
C: a1 SEARCH UNSEEN YOUNGER 259200 C: a1 SEARCH UNSEEN YOUNGER 259200
S: a1 * SEARCH 4 8 15 16 23 42 S: a1 * SEARCH 4 8 15 16 23 42
Search for all unseen messages within the past 3 days, or 259200 Search for all unseen messages within the past 3 days, or 259200
seconds, according to the server's current time. seconds, according to the server's current time.
5. Security Considerations 5. Security Considerations
The WITHIN extension does not raise any security considerations which The WITHIN extension does not raise any security considerations that
are not present in the base protocol. Considerations are the same as are not present in the base protocol. Considerations are the same as
for IMAP [2]. for IMAP [RFC3501].
6. IANA Considerations 6. IANA Considerations
Per the IMAP RFC [2], registration of a new IMAP capablity in the Per the IMAP RFC [RFC3501], registration of a new IMAP capability in
IMAP Capability registry requires the publication of a standards the IMAP Capability registry requires the publication of a standards-
track RFC or an IESG approved experimental RFC. The registry is track RFC or an IESG approved experimental RFC. The registry is
currently located at currently located at
<http://www.iana.org/assignments/imap4-capabilities>. This standards <http://www.iana.org/assignments/imap4-capabilities>. This
track document defines the WITHIN IMAP capability. We request IANA standards-track document defines the WITHIN IMAP capability. IANA
to add this extension to the IANA IMAP Capability registry. has added this extension to the IANA IMAP Capability registry.
7. References 7. References
7.1. Normative References 7.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Levels", RFC 2119, BCP 14, March 1997. Requirement Levels", RFC 2119, BCP 14, March 1997.
[2] Crispin, M., "Internet Message Access Protocol - Version 4rev1", [RFC3501] Crispin, M., "Internet Message Access Protocol - Version
RFC 3501, March 2003. 4rev1", RFC 3501, March 2003.
[3] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
RFC 4466, April 2006. Specifications: ABNF", RFC 4234, October 2005.
7.2. Informative References 7.2. Informative References
[4] Melnikov, D. and C. Daboo, "Contexts for IMAP4", [CONTEXT] Melnikov, D. and C. King, "Contexts for IMAP4", Work
draft-cridland-imap-context-02 (work in progress), May 2006. in Progress, May 2006.
Appendix A. Contributors Appendix A. Contributors
Stephane Maes and Ray Cromwell wrote the original version of this Stephane Maes and Ray Cromwell wrote the original version of this
document as part of P-IMAP as well as the first drafts for the IETF. document as part of P-IMAP, as well as the first versions for the
From an attribution perspective, they are clearly authors. IETF. From an attribution perspective, they are clearly authors.
Appendix B. Acknowledgements Appendix B. Acknowledgements
The authors want to thank all who have contributed key insight and The authors want to thank all who have contributed key insight and
extensively reviewed and discussed the concepts of LPSEARCH and the who have extensively reviewed and discussed the concepts of LPSEARCH.
authors of its early introduction in P-IMAP. They also thank the authors of its early introduction in P-IMAP.
We also want to give a special thanks to Arnt Gilbrandsen, Ken We also want to give a special thanks to Arnt Gilbrandsen, Ken
Murchison, Zoltan Ordogh, and most especially Dave Cridland for their Murchison, Zoltan Ordogh, and most especially Dave Cridland for their
review and suggestions. A special thank you goes to Alexey Melnikov review and suggestions. A special thank you goes to Alexey Melnikov
for his choice submission of text. for his choice submission of text.
Author's Address Author's Address
Eric W. Burger (editor) Eric W. Burger (editor)
BEA Systems, Inc. BEA Systems, Inc.
USA USA
Phone: EMail: eric.burger@bea.com
Fax:
Email: eric.burger@bea.com
URI: http://www.standardstrack.com URI: http://www.standardstrack.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
skipping to change at page 5, line 44 skipping to change at line 195
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 26 change blocks. 
83 lines changed or deleted 61 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/