<VFOLDER> February 2006
Lemonade
Internet Draft: VFOLDER S. H. Maes
Document: draft-ietf-lemonade-vfolder-00 R. Cromwell
A. Srivastava
Eds.
Expires: August 2006 Febuary 2006
Persistent Virtual Folder extension 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]
<VFOLDER> February 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. LVFOLDER Capability.........................................3
3. CREATE 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
IANA Considerations...............................................6
References........................................................6
Normative Appendices...........................................7
A. SEARCH extensions...........................................7
B. Dealing with mutable message state..........................7
Future Work.......................................................7
Version History...................................................8
Acknowledgments...................................................8
Authors Addresses.................................................8
Intellectual Property Statement...................................9
Disclaimer of Validity............................................9
Copyright Statement...............................................9
1. Introduction
Maes Expires August 2006 [Page 2]
<VFOLDER> February 2006
The LVFOLDER extension is present in any IMAP4 implementation which
returns LVFOLDER as one of the supported capabilities in the
CAPABILITY command.
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 doesnt 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 clients 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. LVFOLDER Capability
A server which supports LVFOLDER returns LVFOLDER 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 Command Extension
Arguments: mailbox name
Optional LPSEARCH backing mailbox name &
search criteria
Maes Expires August 2006 [Page 3]
<VFOLDER> February 2006
Responses: optional NO responses BADSEARCH,BADBACKING
Result: OK created lpsearch completed
NO cant 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 doesnt 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 doesnt 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 =/ LVFOLDER 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))
Maes Expires August 2006 [Page 4]
<VFOLDER> February 2006
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: 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, utilizing the [WITHIN] draft extension.
C: a3 CREATE foo (LPSEARCH (INBOX 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.
Maes Expires August 2006 [Page 5]
<VFOLDER> February 2006
If a backing mailbox is deleted, then all vfolders attached to that
backing mailbox as deleted as well.
Changes to UIDVALIDITY, UIDNEXT, and other underlying properties of
the backing mailbox are reflected in all attached vfolders.
Security Considerations
The LVFOLDER extension does not raise any security considerations
which are not present in the base protocol. Considerations are the
same as for IMAP [RFC 3501].
IANA Considerations
When using the LVFOLDER extension, the names of created mailboxes
MUST not overlap with existing mailboxes. Therefore the following
mailbox names are reserved and not suitable as names of mailboxes
created by VFOLDER:
- INBOX*
- OUTBOX*
- SENT*
- DELETED*
- DRAFTS*
- CONTACTS*
- CALENDAR*
- TASKS*
Where * denotes are other combination of characters.
These mailbox names are reserved.
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.
[WITHIN] Maes, S.H., Cromwell, R., WITHIN Search extension to the
IMAP Protocol, draft-ietf-lemonade-search-within-0x.txt, February
2006 (Work in progress)
Maes Expires August 2006 [Page 6]
<VFOLDER> February 2006
[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
<interval seconds>
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.
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] Determine whether section 6 conflicts with RFC3501 guarantees or
any IMAP extensions, and if so, how to resolve such conflicts.
Maes Expires August 2006 [Page 7]
<VFOLDER> October 2005
Version History
Release 00 (was 03 of draft-maes-lemonade-vfolder)
Separate WITHIN extension to separate draft
Additional section on IANA considerations
Release 02 of draft-maes-lemonade-vfolder
Update to address comments from Alexey Melnikov, and a new
restricted model using immutable message properties
Release 01 of draft-maes-lemonade-vfolder
Update to address comments from Alexey Melnikov to follow
appropriately the generic syntax provided in draft-melnikov-imap-ext-
abnf-05.txt.
Release 00 of draft-maes-lemonade-vfolder
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
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
Maes Expires April 2006 [Page 8]
<VFOLDER> October 2005
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 7878 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.
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
Maes Expires April 2006 [Page 9]
<VFOLDER> October 2005
Funding for the RFC Editor function is currently provided by the
Internet Society.
Maes Expires April 2006 [Page 10]
