draft-ietf-lemonade-search-within-03.txt   draft-ietf-lemonade-search-within-04.txt 
Lemonade S. Maes Lemonade E. Burger, Ed.
Internet-Draft R. Cromwell Internet-Draft BEA Systems, Inc.
Intended status: Standards Track Oracle Corporation Intended status: Standards Track R. Cromwell
Expires: August 27, 2007 S. Maes
Oracle Corporation
February 23, 2007
WITHIN Search extension to the IMAP Protocol WITHIN Search extension to the IMAP Protocol
draft-ietf-lemonade-search-within-03 draft-ietf-lemonade-search-within-04
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 32 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 December 3, 2006. This Internet-Draft will expire on August 27, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2006). 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 SINCE in that the client specifies an interval, rather differs from BEFORE and SINCE in that the client specifies an
than a date. We expect WITHIN to be most useful for persistent interval, rather than a date. We expect WITHIN to be most useful for
searches from mobile devices. persistent searches from mobile devices.
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].
skipping to change at page 5, line 11 skipping to change at page 5, line 11
interval. The server calculates the time of interest by subtracting interval. The server calculates the time of interest by subtracting
the time interval presented by the client, and either returning the time interval presented by the client, and either returning
messages older or younger than the resultant time and date. messages older or younger than the resultant time and date.
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 of the OLDER and YOUNGER search keys, the server calculates For both the OLDER and YOUNGER search keys, the server calculates a
a date and time by subtracting the interval on the current date and target date and time by subtracting the interval from the current
time of the server. Servers MUST maintain at least a precision of an date and time of the server. The server then compares the target
hour in this calculation. time with the INTERNALDATE of the message, as specified in IMAP [2].
For OLDER, messages match if the INTERNALDATE is less recent than, or
equal to, the target time. For YOUNGER, messages match if the
INTERNALDATE is more recent than, or equal to, the target time.
The interval specification is in seconds. The server honors the In some cases, the server may be unable, or unwilling, to use a
interval request if it has the precision to do so. If the server precision of a single second. This is expected to be the case
does not have the precision to honor the interval request, the server particularly for dynamically updated searches. In these cases,
MUST select the closest precision possible. For example, if the servers are permitted to reduce the precision used for date
client requests messages that are younger than 4020 (67 minutes), but calulcations and comparisons, but SHOULD ensure that a precision of
the server only performs searches with hourly accuracy (as mandated no less than an hour (3600 seconds) is used. This might mean re-
above), the server performs the search as if the client requested a running the search criteria only every hour for a dynamic search, for
60-minute interval. example. Clients MUST be aware that search results, whether viewed
directly or through some other mechanism, MAY not be accurate as a
result.
The server then compares the resultant date and time against the For example, if the client requests messages that are younger than
INTERNALDATE of the message set in question, as specified in IMAP 4020 (67 minutes), but the server only performs searches with hourly
[2]). For OLDER, messages match if the date and time is less recent accuracy (as mandated above), the server performs the search as if
then the INTERNALDATE. For YOUNGER, messages match if the date and the client requested a 60-minute interval. Note the choice of
time is more recent then the INTERNALDATE. If the date and time rounding up or down is at the discretion of the server. However,
matches the INTERNALDATE precisely, both OLDER and YOUNGER will match rounding down to zero is NOT RECOMMENDED, as this may result in
the message. searches for messages YOUNGER than a value being rounded to YOUNGER
0, which will always fail.
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
skipping to change at page 9, line 5 skipping to change at page 9, line 5
Search for all unseen messages within the past 3 days (72 hours) Search for all unseen messages within the past 3 days (72 hours)
according to the server's current time. 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. Normative References 6. IANA Considerations
None.
7. 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 Appendix A. 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 Alexey Melnikov, Arnt We also want to give a special thanks to Arnt Gilbrandsen, Alexey
Gilbrandsen, Zoltan Ordogh, and Dave Cridland for their review and Melnikov, Ken Murchison, Zoltan Ordogh, and most especially Dave
suggestions, as well as thanks to Eric Burger for reformatting and Cridland for their review and suggestions.
editing the document to meet IETF publication standards.
Authors' Addresses Authors' Addresses
Stephane H. Maes Eric W. Burger (editor)
Oracle Corporation BEA Systems, Inc.
500 Oracle Parkway, M/S 4op634
Redwood Shores, CA 94065
USA USA
Email: stephane.maes@oracle.com Phone:
Fax:
Email: eric.burger@bea.com
URI:
Ray Cromwell Ray Cromwell
Oracle Corporation Oracle Corporation
500 Oracle Parkway 500 Oracle Parkway
Redwood Shores, CA 94065 Redwood Shores, CA 94065
USA USA
Email: ray.cromwell@oracle.com 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 (2006). 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
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 14 change blocks. 
39 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/