Document: draft-melnikov-imap-search-res-00.txt A. Melnikov Intended category: Standard Track Isode Ltd. Expires: April 2005 October 2004 IMAP extension for referencing the last SEARCH result Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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. A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested, and should be sent to the IMAPEXT Mailing list . Distribution of this draft is unlimited. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract Many IMAP clients use the result of a SEARCH command as the input to perform another operation, for example fetching the found messages, deleting them or copying them to another mailbox. This can be achieved using standard IMAP operations described in RFC Melnikov Expires: April 2005 [Page 1] INTERNET DRAFT Last SEARCH result reference October 2004 2501, however this would be suboptimal: the server will send the list of found messages to the client, after that the client will have to parse the list, reformat it and send it back to the server. The client can't pipeline the SEARCH command with the subsequent command. This document proposes an IMAP extension that allows a client to tell a server to use the result of the latest SEARCH (or UID SEARCH) command as an input to any subsequent command. 1. Conventions Used in this Document In examples, "C:" indicates lines sent by a client that is connected to a server. "S:" indicates lines sent by the server to the client. The keywords "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document when typed in uppercase are to be interpreted as defined in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS]. <> 2. New sequence element for referencing the result of the last SEARCH command. The SEARCH result reference extension described in this document is present in any IMAP4 implementation which returns "X-DRAFT- I00-SEARCHRES" as one of the supported capabilities in the CAPABILITY command response. <>. The SEARCH result reference extension REQUIREs that a compliant server remembers the result of the latest SEARCH (also UID SEARCH, SORT, UID SORT) command and stores it in an internal variable that we will reference as the "search result variable". The client can use the "<<" marker in message (or UID) sequence in order to indicate that the server should substitute it with the list of messages from the search result variable. This way the client can use the result of the latest SEARCH command as a parameter to another command. <> Upon successful completion of SELECT or EXAMINE command, the current search result variable is reset to the empty sequence. <> A successful SEARCH command sets the value of the search result variable to the list of messages found in the SEARCH command. For example, if no messages were found, the search result variable will contain the empty list. A failed SEARCH command (any SEARCH command that caused the server to return BAD or NO tagged response) doesn't change the search result variable. When a message listed in the search result variable is EXPUNGEd, it is automatically removed from the list. (Implementation note: if the server stores the list as a list of message numbers, it MUST automatically adjust them when sending any untagged EXPUNGE response) If the server decides to send a new UIDVALIDITY value while mailbox is opened, this causes resetting the search variable to the empty list. <> When the mailbox is closed (explicitly or implicitly) the server MUST forget the value of the search result variable. <> <> 2.1. Examples 1) The following example demonstrates how the client can use the result of a SEARCH command to FETCH headers of interesting messages: Example: C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith" S: * SEARCH 2 84 882 S: A282 OK SEARCH completed C: A283 FETCH << (UID INTERNALDATE FLAGS RFC822.HEADER) S: * 2 FETCH (UID 14 ... S: * 84 FETCH (UID 100 ... S: * 882 FETCH (UID 1115 ... S: A283 OK completed The client can also pipeline the two commands: Melnikov Expires: April 2005 [Page 3] INTERNET DRAFT Last SEARCH result reference October 2004 Example: C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith" C: A283 FETCH << (UID INTERNALDATE FLAGS RFC822.HEADER) S: * SEARCH 2 84 882 S: A282 OK SEARCH completed S: * 2 FETCH (UID 14 ... S: * 84 FETCH (UID 100 ... S: * 882 FETCH (UID 1115 ... S: A283 OK completed 2) The following example demonstrates that the result of one SEARCH command can be used to subset the result of another SEARCH command: Example: C: A300 SEARCH SINCE 1-Jan-2004 NOT FROM "Smith" S: * SEARCH 3 16 18 21 501 502 503 504 508 611 S: A300 OK SEARCH completed C: A301 UID SEARCH UID << SMALLER 4096 S: * SEARCH 17 900 901 S: A301 OK completed 3) The following example demonstrates that a failed SEARCH doesn't invalidate the search result variable. It also shows that the "<<" marker can be combined with other message numbers: Example: C: B282 SEARCH SINCE 1-Feb-1994 NOT FROM "Smith" S: * SEARCH 2 84 882 1102 2056 S: B282 OK SEARCH completed C: B283 SEARCH CHARSET KOI8-R 1,<<,3000-3021 TEXT {4} C: XXXX S: B283 NO [BADCHARSET UTF-8] KOI8-R is not supported C: B284 SEARCH CHARSET UTF-8 1,<<,3000-3021 TEXT {8} C: YYYYYYYY S: * SEARCH 882 1102 3003 3005 3006 S: B284 OK completed Note: Since this document is restricted to 7-bit ASCII text, it is not possible to show actual KOI8-R or UTF-8 data. The "XXXX" and ""YYYYYYYY" are placeholders for what would be 4 and 8 octets of 8-bit data in an actual transaction. 3. Formal Syntax The following syntax specification uses the Augmented Backus- Naur Form (ABNF) notation as specified in [ABNF]. Non-terminals referenced but not defined below are as defined by [IMAP4]. Melnikov Expires: April 2005 [Page 4] INTERNET DRAFT Last SEARCH result reference October 2004 Except as noted otherwise, all alphabetic characters are case- insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion. seq-range =/ seq-last-command ; Extend seq-range to allow for "result of the ; last command" indicator. seq-last-command= "<<" 4. Security Considerations <<>> It is believed that this extension doesn't raise any additional security concerns not already discussed in [IMAP4]. 5. Acknowledgments The author would like to thank Mark Crispin for reminding that this document has to be written. 6. Normative references [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [ABNF] Crocker, D., and Overell, P. "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 3501, University of Washington, March 2003. <> <> 7. Author's Addresses Alexey Melnikov Isode Ltd. 5 Castle Business Village, 36 Station Road, Hampton, Middlesex, Melnikov Expires: April 2005 [Page 5] INTERNET DRAFT Last SEARCH result reference October 2004 TW12 2BX, United Kingdom Email: Alexey.Melnikov@isode.com 8. Full Copyright Statement Copyright (C) The Internet Society (2004). 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 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. 9. 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. Melnikov Expires: April 2005 [Page 6]