January 2006 Lemonade Internet Draft: VFOLDER S. H. Maes Document: draft-maes-lemonade-vfolder-02 R. Cromwell A. Srivastava Eds. Expires: July 2006 January 2006 Persistent Search Extensions and Virtual Folder to the IMAP Protocol 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. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Persistent Extensions to the IMAP Protocol (LPSEARCH) defines extension parameters to the [RFC3501] CREATE command to allow virtual mailboxes to be created which are views of other mailboxes narrowed by search criteria. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. Maes [Page 1]  January 2006 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 [RFC2119]. An implementation is not compliant if it fails to satisfy one or more of the MUST or REQUIRED level requirements for the protocol(s) it implements. An implementation that satisfies all the MUST or REQUIRED level and all the SHOULD level requirements for a protocol is said to be "unconditionally compliant" to that protocol; one that satisfies all the MUST level requirements but not all the SHOULD level requirements is said to be "conditionally compliant." When describing the general syntax, some definitions are omitted as they are defined in [RFC3501]. Table of Contents Status of this Memo...............................................1 Copyright Notice..................................................1 Abstract..........................................................1 Conventions used in this document.................................1 Table of Contents.................................................2 1. Introduction................................................2 2. LPSEARCH Capability.........................................3 3. CREATE and LPSEARCH Command Extension.......................3 4. Response Codes..............................................4 A.1. BADBACKING................................................4 A.2. BADSEARCH.................................................4 5. Formal Syntax...............................................4 7. Message and Mailbox changes.................................5 Security Considerations...........................................6 References........................................................6 Normative Appendices...........................................6 A. SEARCH extensions...........................................6 B. Dealing with mutable message state..........................7 Future Work.......................................................7 Version History...................................................7 Acknowledgments...................................................7 Authors Addresses.................................................8 Intellectual Property Statement...................................8 Disclaimer of Validity............................................9 Copyright Statement...............................................9 1. Introduction The LPSEARCH extension is present in any IMAP4 implementation which returns “LPSEARCH” as one of the supported capabilities in the CAPABILITY command. Maes Expires – July 2006 [Page 2]  January 2006 A virtual folder is an IMAP4 folder with attached search criteria. The search criteria specify the backing mailbox, as well as a subset IMAP SEARCH grammar which may be applied to the immutable properties of messages in the backing mailbox. Once created, all operations applied to the virtual mailbox, such as APPEND and STORE, are actually applied to the backing mailbox. For all intents and purposes, the virtual folder looks and behaves like a real IMAP4 folder. Any changes made to the underlying folder must pass the search criteria for the virtual folder before being visible. UIDs are preserved, and as well as the UIDVALIDITY value. In general, most mailbox state and metadata present on the backing folder should be identical on the virtual folder, except where it doesn’t make sense. (e.g. EXISTS, RECENT, in general, values which are based on then number of messages which have/do not have a certain property in the mailbox) Message sequence numbers will be different, but the order of the messages in the sequence, and the ordering of UIDs, MUST be preserved. From the client’s perspective, whether or not a mailbox is a vfolder is not visible, and for all intents and purposes, it appears as any other mailbox name. This includes the ability for a new virtual folder to be created by using another virtual folder as a backing mailbox. For the purposes of this draft, ‘immutability’ refers to message flags and non-immutable messages annotations. 2. LPSEARCH Capability A server which supports LPSEARCH returns “LPSEARCH” as one of the responses of the CAPABILITY command. LPSEARCH adheres to [CREATEPARAM] and [ABNFEXTEND] syntax so a server MAY also wish to report additional capabilities for extended CREATE. 3. CREATE and LPSEARCH Command Extension Arguments: mailbox name Optional “LPSEARCH” backing mailbox name & search criteria Responses: optional NO responses BADSEARCH,BADBACKING Result: OK created lpsearch completed NO can’t create mailbox with that name Maes Expires – July 2006 [Page 3]  January 2006 BAD command unknown or arguments invalid All of the semantics of CREATE as defined in 6.3.3 of [RFC3501] must hold. Additionally, if the backing mailbox name doesn’t exist, the creation MUST fail with a NO result and BADBACKING response code. If the search criteria are invalid because the search would violate some of the required properties (immutable message properties only), BADSEARCH must be reported with a NO response, or if the SEARCH contains an error in one of its argument values, a NO with a BADSEARCH response is returned. 4. Response Codes A.1. BADBACKING The mailbox name used for the backing mailbox doesn’t exist. A.2. BADSEARCH The search criteria violates the pre-conditions mentioned in section 1, or some of the arguments of the search are invalid. 5. 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 the [ABNF], [RFC3501], and [ABNFEXTEND]. The create ABNF grammar in [RFC3501] is hereby modified to the grammar defined in [ABNFEXTEND]. An additional CREATE param “LPSEARCH” is introduced whose value is a list containing the backing store mailbox and the search parameters. create_param =/ “LPSEARCH” SP “(“ backing-mailbox psearch “)” ;; conforms to generic "create-param" syntax as defined in [ABNFEXTEND] backing-mailbox = mailbox psearch = search-program ; defined in [ABNFEXTEND] 6. Examples C: a1 CREATE lemonade (LPSEARCH (INBOX HEADER “Sender” “lemonade- bounces”)) S: a1 OK CREATE LPSEARCH Completed Maes Expires – July 2006 [Page 4]  January 2006 Create a persistent mailbox which shows only messages sent to lemonade mailing list. C: a2 CREATE mobile (LPSEARCH (INBOX FROM “boss@mycompany.com”)) S: a2 OK CREATE LPSEARCH Completed Create a mailbox to be synchronized (not in scope of this document) with a mobile device. C: a2 CREATE mobile (LPSEARCH (INBOX FROM “boss@mycompany.com” WITHIN 259200)) S: a2 OK CREATE LPSEARCH Completed Create a mailbox that contains all messages from boss@mycompany.com that were sent within the last 3 days according to the timezone of the server. C: a3 CREATE foo (LPSEARCH (IMBOX FROM “boss@mycompany.com”)) S: a3 NO [BADBACKING] CREATE failed. IMBOX is not a valid mailbox. Attempt to create a mailbox with a non-existence backing mailbox (fail) C: a3 CREATE foo (LPSEARCH (INBOX FLAGGED)) S: a3 NO [BADSEARCH] CREATE failed. SEARCH refers to mutable properties Attempt to create a mailbox with a search for flagged messages (fail)_ 7. Message and Mailbox changes When new messages arrive, or messages are expunged, an untagged response MUST be sent to the client just as it would if the backing mailbox was selected. Modifications to mutable state (flags, annotations) have no affect on the whether or not messages are included virtual folders, nor do they generate events. A client fetching the FLAGS of a message in a virtual folder will however see the latest value of those values in the backing mailbox. If a backing mailbox is deleted, then all vfolders attached to that backing mailbox as deleted as well. Maes Expires – July 2006 [Page 5]  January 2006 Changes to UIDVALIDITY, UIDNEXT, and other underlying properties of the backing mailbox are reflected in all attached vfolders. Security Considerations The LPSEARCH extension does not raise any security considerations which are not present in the base protocol. Considerations are the same as for IMAP [RFC 3501]. References [ABNF] D. Crocker, et al. "Augmented BNF for Syntax Specifications: ABNF”, RFC 2234, November 1997. http://www.ietf.org/rfc/rfc2234 [ABNFEXTEND] Melnikov, A., and C. Daboo, "Collected extensions to IMAP4 ABNF", work in progress, draft-melnikov-imap-ext-abnf-XX.txt. [CREATEPARAM] Melnikov, A., “IMAP CREATE/RENAME parameters”, draft- melnikov-imap-createparams-01.txt, September 2005. [P-IMAP] Maes, S.H., Lima R., Kuang, C., Cromwell, R., Ha, V. and Chiu, E., Day, J., Ahad R., Jeong W-H., Rosell G., Sini, J., Sohn S-M., Xiaohui F. and Lijun Z., "Push Extensions to the IMAP Protocol (P-IMAP)", draft-maes-lemonade-p-imap-xx.txt, (work in progress). [RFC3501] Crispin, M. "IMAP4, Internet Message Access Protocol Version 4 rev1", RFC 3501, March 2003. http://www.ietf.org/rfc/rfc3501 Normative Appendices A. SEARCH extensions In order to support certain mobile uses cases, the ABNF search-key grammar of [RFC3501] has been extended with a new search key: WITHIN search-key /= “WITHIN” nz-number The key returns messages whose sent date is within the specified interval starting from the current date of the server. Maes Expires – July 2006 [Page 6]  January 2006 B. Dealing with mutable message state In order to gain implementation simplicity, vfolder prohibits the usage of mutable message state in search criteria when creating a folder. It does not however, prevent searching on mutable state elsewhere. Clients that wish to create virtual folders based on mutable state such as flags, are urged to create a virtual folder containing the non-mutable search criteria, and then implement the mutable criteria by issuing IMAP SEARCH commands from the client within the virtual folder. Future Work [1] Decide whether virtual mailboxes may have their own annotations and whether messages in a virtual mailbox may have their own annotations, both of which are not reflected in the backing mailbox. View dependent annotations may be useful for multi-device synchronization. [2] Address editor’s notes. [3] Determine whether section 6 conflicts with RFC3501 guarantees or any IMAP extensions, and if so, how to resolve such conflicts. Version History Release 02 Update to address comments from Alexey Melnikov, and a new restricted model using immutable message properties Release 01 Update to address comments from Alexey Melnikov to follow appropriately the generic syntax provided in draft-melnikov-imap-ext- abnf-05.txt. Release 00 Initial release Acknowledgments The authors want to thank all who have contributed key insight and extensively reviewed and discussed the concepts of LPSEARCH and its early introduction P-IMAP [P-IMAP]. In particular, this includes the authors of the P-IMAP draft: Rafiul Ahad – Oracle Corporation, Eugene Chiu – Oracle Corporation, Ray Cromwell – Oracle Corporation, Jia-der Day – Oracle Corporation, Vi Ha – Oracle Corporation, Wook-Hyun Jeong – Samsung Electronics Co. LTF, Chang Kuang – Oracle Corporation, Rodrigo Lima – Oracle Corporation, Stephane H. Maes – Oracle Corporation, Gustaf Rosell - Sony Ericsson, Jean Sini – Symbol Technologies, Sung-Mu Son – LG Electronics, Fan Xiaohui - CHINA MOBILE COMMUNICATIONS CORPORATION (CMCC), Zhao Lijun - CHINA MOBILE Maes Expires – July 2006 [Page 7]  January 2006 COMMUNICATIONS CORPORATION (CMCC). We also want to give a special thanks to A. Melnikov for his review and suggestions. Authors Addresses Stephane H. Maes Oracle Corporation 500 Oracle Parkway M/S 4op634 Redwood Shores, CA 94065 USA Phone: +1-650-607-6296 Email: stephane.maes@oracle.com Ray Cromwell Oracle Corporation 500 Oracle Parkway Redwood Shores, CA 94065 USA Anil Srivastava Sun Microsystems 4150 Network Circle SCA15/201 Santa Clara, CA 94065 anil.srivastava@sun.com Intellectual Property Statement 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 Maes Expires – July 2006 [Page 8]  January 2006 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. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Maes Expires – July 2006 [Page 9]