<VFOLDER> October 2005 Lemonade Internet Draft: VFOLDER S. H. Maes Document: draft-maes-lemonade-vfolder-00 R. Cromwell A. Srivastava Eds. Expires: April 2006 October 2005 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. Abstract Persistent Extensions to the IMAP Protocol (LPSEARCH) defines an extension 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. 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]. Maes [Page 1]
<VFOLDER> October 2005 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 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.................................................3 4.1. BADBACKING................................................3 4.2. BADSEARCH.................................................4 5. Formal Syntax..................................................4 6. Message changes................................................4 Security Considerations...........................................5 References........................................................5 Future Work.......................................................5 Version History...................................................5 Acknowledgments...................................................5 Authors Addresses.................................................6 Intellectual Property Statement...................................6 Full Copyright Statement..........................................7 1. Introduction The LPSEARCH extension is present in any IMAP4 implementation which returns ôLPSEARCHö as one of the supported capabilities in the CAPABILITY command. A virtual folder is an IMAP4 folder with an attached search criteria. 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 Maes Expires û April 2006 [Page 2]
<VFOLDER> October 2005 preserved, and it has its own 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. Most importantly, order should be preserved. If message X occurs before message Y in the backing folder, the same property must hold in the virtual folder. Message sequence numbers will be different, but the order of the messages in the sequence, and the ordering of UIDs, MUST be preserved. This has the implication that future IMAP extensions which might alter the order of search results may not be used with LPSEARCH. From the clientÆs perspective, whether or not a mailbox is persistent is not visible, and for all intents and purposes, it appears as any other mailbox name. This includes the ability for a new virtual mailbox to be created by using another virtual mailbox as a backing mailbox. 2. LPSEARCH Capability A server which supports LPSEARCH returns ôLPSEARCHö as one of the responses of the CAPABILITY command. 3. CREATE and LPSEARCH Command Extension Arguments: mailbox name Optional ôLPSEARCHö backing mailbox name Optional search criteria Responses: optional NO responses BADSEARCH,BADBACKING Result: OK created lpsearch completed NO canÆt create mailbox with that name 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 (message ordering), 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 4.1. BADBACKING The mailbox name used for the backing mailbox doesnÆt exist. Maes Expires û April 2006 [Page 3]
<VFOLDER> October 2005 4.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] and [RFC3501]. The create ABNF grammar in [RFC3501] is hereby modified to: create = ôCREATEö SP mailbox [ôLPSEARCHö backing-mailbox psearch] backing-mailbox = mailbox psearch = [SP "CHARSET" SP astring] 1*(SP search-key) ; CHARSET argument to MUST be registered with IANA 6. Examples C: a1 CREATE lemonade LPSEARCH INBOX HEADER ôSenderö ôlemonade- bouncesö S: a1 OK CREATE LPSEARCH Completed 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: a3 CREATE foo LPSEARCH IMBOX FROM ôboss@mycompany.comö S: a3 NO [BADBACKING] CREATE failed. IMBOX is not a valid mailbox. <<EditorÆs note: extend the example with a mopre complicate search criteria as messages from boss@mycompany.com and arrived in the last 5 days. >> IMAP SORT can be be applied to a virtual folder created using XPSEARCH exactly the same way it applies to a real folder. 6. Message changes Maes Expires û April 2006 [Page 4]
<VFOLDER> October 2005 When messages in the underlying mailbox change, such as new messages arrive, or messages are expunged and in general in all cases where the underlying message state changes, an untagged response MUST be sent to the client. 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 [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 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. Version History 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 Maes Expires û April 2006 [Page 5]
<VFOLDER> October 2005 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 COMMUNICATIONS CORPORATION (CMCC). 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 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to Maes Expires û April 2006 [Page 6]
<VFOLDER> October 2005 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 Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights, which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Full Copyright Statement Copyright (C) The Internet Society (2005). 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. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Maes Expires û April 2006 [Page 7]