draft-ietf-lemonade-search-within-04.txt   draft-ietf-lemonade-search-within-05.txt 
Lemonade E. Burger, Ed. Lemonade E. Burger, Ed.
Internet-Draft BEA Systems, Inc. Internet-Draft BEA Systems, Inc.
Intended status: Standards Track R. Cromwell Updates: RFC 3501 June 1, 2007
Expires: August 27, 2007 S. Maes (if approved)
Oracle Corporation Intended status: Standards Track
February 23, 2007 Expires: December 3, 2007
WITHIN Search extension to the IMAP Protocol WITHIN Search extension to the IMAP Protocol
draft-ietf-lemonade-search-within-04 draft-ietf-lemonade-search-within-05
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 27, 2007. This Internet-Draft will expire on December 3, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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. We expect WITHIN to be most useful for interval, rather than a date. WITHIN is useful for persistent
persistent searches from mobile devices. searches where either the device does not have the capacity to
perform the search at regular intervals or the network is of limited
bandwidth and thus there is a desire to reduce network traffic from
sending repeated requests and redundant responses.
Conventions Used in this Document 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 [1].
When describing the general syntax, we omit some definitions as RFC When describing the general syntax, we omit some definitions as RFC
3501 [2] defines them. 3501 [2] defines them.
1. Introduction 1. Introduction
This extension exposes two new search keys, OLDER and YOUNGER, each This extension exposes two new search keys, OLDER and YOUNGER, each
of which takes a non-zero integer argument corresponding to a time of which takes a non-zero integer argument corresponding to a time
interval. The server calculates the time of interest by subtracting interval in seconds. The server calculates the time of interest by
the time interval presented by the client, and either returning subtracting the time interval the client presents. The server then
messages older or younger than the resultant time and date. 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 from the current target date and time by subtracting the interval, specified in
date and time of the server. The server then compares the target seconds, from the current date and time of the server. The server
time with the INTERNALDATE of the message, as specified in IMAP [2]. then compares the target time with the INTERNALDATE of the message,
For OLDER, messages match if the INTERNALDATE is less recent than, or as specified in IMAP [2]. For OLDER, messages match if the
equal to, the target time. For YOUNGER, messages match if the INTERNALDATE is less recent than or equal to the target time. For
INTERNALDATE is more recent than, or equal to, the target time. YOUNGER, messages match if the INTERNALDATE is more recent than, or
equal to, the target time.
In some cases, the server may be unable, or unwilling, to use a
precision of a single second. This is expected to be the case
particularly for dynamically updated searches. In these cases,
servers are permitted to reduce the precision used for date
calulcations and comparisons, but SHOULD ensure that a precision of
no less than an hour (3600 seconds) is used. This might mean re-
running the search criteria only every hour for a dynamic search, for
example. Clients MUST be aware that search results, whether viewed
directly or through some other mechanism, MAY not be accurate as a
result.
For example, if the client requests messages that are younger than Both OLDER and YOUNGER searches always result in exact matching, to
4020 (67 minutes), but the server only performs searches with hourly the resolution of a second. However, if one is doing a dynamic
accuracy (as mandated above), the server performs the search as if evaluation, for example, in a context [4], one needs to be aware the
the client requested a 60-minute interval. Note the choice of server might perform the evaluation periodically. Thus, the server
rounding up or down is at the discretion of the server. However, may delay the updates. Clients MUST be aware that dynamic search
rounding down to zero is NOT RECOMMENDED, as this may result in results may not reflect the current state of the mailbox. If the
searches for messages YOUNGER than a value being rounded to YOUNGER client needs a search result that reflects the current state of the
0, which will always fail. mailbox, we RECOMMEND the client issues 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 [1], IMAP [2], and IMAP Extended ABNF [3]
This document extends RFC 3501 [2] with two new search keys: OLDER This document extends RFC 3501 [2] with two new search keys: OLDER
<interval> and YOUNGER <interval>. <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 (72 hours) Search for all unseen messages within the past 3 days, or 259200
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 which
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 [2].
6. IANA Considerations 6. IANA Considerations
None. Per the IMAP RFC [2], registration of a new IMAP capablity in the
IMAP Capability registry requires the publication of a standards
track RFC or an IESG approved experimental RFC. The registry is
currently located at
<http://www.iana.org/assignments/imap4-capabilities>. This standards
track document defines the WITHIN IMAP capability. We request IANA
to add this extension to the IANA IMAP Capability registry.
7. Normative References 7. References
7.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997. Levels", RFC 2119, BCP 14, March 1997.
[2] Crispin, M., "Internet Message Access Protocol - Version 4rev1", [2] Crispin, M., "Internet Message Access Protocol - Version 4rev1",
RFC 3501, March 2003. RFC 3501, March 2003.
[3] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", [3] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF",
RFC 4466, April 2006. RFC 4466, April 2006.
Appendix A. Acknowledgements 7.2. Informative References
[4] Melnikov, D. and C. Daboo, "Contexts for IMAP4",
draft-cridland-imap-context-02 (work in progress), May 2006.
Appendix A. Contributors
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.
From an attribution perspective, they are clearly authors.
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 extensively reviewed and discussed the concepts of LPSEARCH and the
authors of its early introduction in P-IMAP. authors of its early introduction in P-IMAP.
We also want to give a special thanks to Arnt Gilbrandsen, Alexey We also want to give a special thanks to Arnt Gilbrandsen, Ken
Melnikov, Ken Murchison, Zoltan Ordogh, and most especially Dave Murchison, Zoltan Ordogh, and most especially Dave Cridland for their
Cridland for their review and suggestions. review and suggestions. A special thank you goes to Alexey Melnikov
for his choice submission of text.
Authors' Addresses Author's Address
Eric W. Burger (editor) Eric W. Burger (editor)
BEA Systems, Inc. BEA Systems, Inc.
USA USA
Phone: Phone:
Fax: Fax:
Email: eric.burger@bea.com Email: eric.burger@bea.com
URI: URI: http://www.standardstrack.com
Ray Cromwell
Oracle Corporation
500 Oracle Parkway
Redwood Shores, CA 94065
USA
Email: ray.cromwell@oracle.com
Stephane H. Maes
Oracle Corporation
500 Oracle Parkway, M/S 4op634
Redwood Shores, CA 94065
USA
Email: stephane.maes@oracle.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.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
 End of changes. 15 change blocks. 
63 lines changed or deleted 61 lines changed or added

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