284 lines
8.7 KiB
Plaintext
284 lines
8.7 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
Network Working Group E. Burger, Ed.
|
||
Request for Comments: 5032 BEA Systems, Inc.
|
||
Updates: 3501 September 2007
|
||
Category: Standards Track
|
||
|
||
|
||
WITHIN Search Extension to the IMAP Protocol
|
||
|
||
Status of This Memo
|
||
|
||
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
|
||
|
||
This document describes the WITHIN extension to IMAP SEARCH. IMAP
|
||
SEARCH returns messages whose internal date is within or outside a
|
||
specified interval. The mechanism described here, OLDER and YOUNGER,
|
||
differs from BEFORE and SINCE in that the client specifies an
|
||
interval, rather than a date. WITHIN is useful for persistent
|
||
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.
|
||
|
||
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
|
||
server, respectively.
|
||
|
||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||
document are to be interpreted as described in RFC 2119 [RFC2119].
|
||
|
||
|
||
|
||
|
||
|
||
Burger Standards Track [Page 1]
|
||
|
||
RFC 5032 Search Within September 2007
|
||
|
||
|
||
When describing the general syntax, we omit some definitions, as RFC
|
||
3501 [RFC3501] defines them.
|
||
|
||
2. Protocol Operation
|
||
|
||
An IMAP4 server that supports the capability described here MUST
|
||
return "WITHIN" as one of the server supported capabilities in the
|
||
CAPABILITY command.
|
||
|
||
For both the OLDER and YOUNGER search keys, the server calculates a
|
||
target date and time by subtracting the interval, specified in
|
||
seconds, from the current date and time of the server. The server
|
||
then compares the target time with the INTERNALDATE of the message,
|
||
as specified in IMAP [RFC3501]. 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.
|
||
|
||
Both OLDER and YOUNGER searches always result in exact matching, to
|
||
the resolution of a second. However, if one is doing a dynamic
|
||
evaluation, for example, in a context [CONTEXT], one needs to be
|
||
aware that the server might perform the evaluation periodically.
|
||
Thus, the server may delay the updates. Clients MUST be aware that
|
||
dynamic search results may not reflect the current state of the
|
||
mailbox. If the client needs a search result that reflects the
|
||
current state of the mailbox, we RECOMMEND that the client issue a
|
||
new search.
|
||
|
||
3. Formal Syntax
|
||
|
||
The following syntax specification uses the Augmented Backus-Naur
|
||
Form (ABNF) notation. Elements not defined here can be found in the
|
||
formal syntax of ABNF [RFC4234] and IMAP [RFC3501].
|
||
|
||
This document extends RFC 3501 [RFC3501] with two new search keys:
|
||
OLDER <interval> and YOUNGER <interval>.
|
||
|
||
search-key =/ ( "OLDER" / "YOUNGER" ) SP nz-number
|
||
; search-key defined in RFC 3501
|
||
|
||
4. Example
|
||
|
||
C: a1 SEARCH UNSEEN YOUNGER 259200
|
||
S: a1 * SEARCH 4 8 15 16 23 42
|
||
|
||
Search for all unseen messages within the past 3 days, or 259200
|
||
seconds, according to the server's current time.
|
||
|
||
|
||
|
||
|
||
Burger Standards Track [Page 2]
|
||
|
||
RFC 5032 Search Within September 2007
|
||
|
||
|
||
5. Security Considerations
|
||
|
||
The WITHIN extension does not raise any security considerations that
|
||
are not present in the base protocol. Considerations are the same as
|
||
for IMAP [RFC3501].
|
||
|
||
6. IANA Considerations
|
||
|
||
Per the IMAP RFC [RFC3501], registration of a new IMAP capability 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. IANA
|
||
has added this extension to the IANA IMAP Capability registry.
|
||
|
||
7. References
|
||
|
||
7.1. Normative References
|
||
|
||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||
Requirement Levels", RFC 2119, BCP 14, March 1997.
|
||
|
||
[RFC3501] Crispin, M., "Internet Message Access Protocol - Version
|
||
4rev1", RFC 3501, March 2003.
|
||
|
||
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
|
||
Specifications: ABNF", RFC 4234, October 2005.
|
||
|
||
7.2. Informative References
|
||
|
||
[CONTEXT] Melnikov, D. and C. King, "Contexts for IMAP4", Work
|
||
in Progress, May 2006.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Burger Standards Track [Page 3]
|
||
|
||
RFC 5032 Search Within September 2007
|
||
|
||
|
||
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 versions 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
|
||
who have extensively reviewed and discussed the concepts of LPSEARCH.
|
||
They also thank the authors of its early introduction in P-IMAP.
|
||
|
||
We also want to give a special thanks to Arnt Gilbrandsen, Ken
|
||
Murchison, Zoltan Ordogh, and most especially Dave Cridland for their
|
||
review and suggestions. A special thank you goes to Alexey Melnikov
|
||
for his choice submission of text.
|
||
|
||
Author's Address
|
||
|
||
Eric W. Burger (editor)
|
||
BEA Systems, Inc.
|
||
USA
|
||
|
||
EMail: eric.burger@bea.com
|
||
URI: http://www.standardstrack.com
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Burger Standards Track [Page 4]
|
||
|
||
RFC 5032 Search Within September 2007
|
||
|
||
|
||
Full Copyright Statement
|
||
|
||
Copyright (C) The IETF Trust (2007).
|
||
|
||
This document is subject to the rights, licenses and restrictions
|
||
contained in BCP 78, and except as set forth therein, the authors
|
||
retain all their rights.
|
||
|
||
This document and the information contained herein are provided on an
|
||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
|
||
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
|
||
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
|
||
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||
|
||
Intellectual Property
|
||
|
||
The IETF takes no position regarding the validity or scope of any
|
||
Intellectual Property Rights or other rights that might be claimed to
|
||
pertain to the implementation or use of the technology described in
|
||
this document or the extent to which any license under such rights
|
||
might or might not be available; nor does it represent that it has
|
||
made any independent effort to identify any such rights. Information
|
||
on the procedures with respect to rights in RFC documents can be
|
||
found in BCP 78 and BCP 79.
|
||
|
||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||
assurances of licenses to be made available, or the result of an
|
||
attempt made to obtain a general license or permission for the use of
|
||
such proprietary rights by implementers or users of this
|
||
specification can be obtained from the IETF on-line IPR repository at
|
||
http://www.ietf.org/ipr.
|
||
|
||
The IETF invites any interested party to bring to its attention any
|
||
copyrights, patents or patent applications, or other proprietary
|
||
rights that may cover technology that may be required to implement
|
||
this standard. Please address the information to the IETF at
|
||
ietf-ipr@ietf.org.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Burger Standards Track [Page 5]
|
||
|