draft-ietf-lemonade-vfolder-00.txt   draft-ietf-lemonade-vfolder-01.txt 
<VFOLDER> February 2006 <VFOLDER> May 2006
Lemonade Lemonade
Internet Draft: VFOLDER S. H. Maes Internet Draft: VFOLDER S. H. Maes
Document: draft-ietf-lemonade-vfolder-00 R. Cromwell Document: draft-ietf-lemonade-vfolder-01 R. Cromwell
A. Srivastava A. Srivastava
A. Gulbrandsen
Eds. Eds.
Expires: August 2006 Febuary 2006 Expires: November 2006 May 2006
Persistent Virtual Folder extension to the IMAP Protocol Persistent Virtual Folder extension to the IMAP Protocol
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at page 1, line 37 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice This Internet-Draft will expire on November 30, 2006.
Copyright (C) The Internet Society (2006).
Abstract Abstract
Persistent Extensions to the IMAP Protocol (LPSEARCH) defines Persistent Extensions to the IMAP Protocol (LPSEARCH) defines
extension parameters to the [RFC3501] CREATE command to allow virtual extension parameters to the [RFC3501] CREATE command to allow virtual
mailboxes to be created which are views of other mailboxes narrowed mailboxes to be created which are views of other mailboxes narrowed
by search criteria. by search criteria.
Conventions used in this document Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and In examples, "C:" and "S:" indicate lines sent by the client and
server respectively. server respectively.
<VFOLDER> February 2006 <VFOLDER> May 2006
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
An implementation is not compliant if it fails to satisfy one or more 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 of the MUST or REQUIRED level requirements for the protocol(s) it
implements. An implementation that satisfies all the MUST or REQUIRED implements. An implementation that satisfies all the MUST or REQUIRED
level and all the SHOULD level requirements for a protocol is said to level and all the SHOULD level requirements for a protocol is said to
be "unconditionally compliant" to that protocol; one that satisfies be "unconditionally compliant" to that protocol; one that satisfies
all the MUST level requirements but not all the SHOULD level all the MUST level requirements but not all the SHOULD level
requirements is said to be "conditionally compliant." When requirements is said to be "conditionally compliant." When
describing the general syntax, some definitions are omitted as they describing the general syntax, some definitions are omitted as they
are defined in [RFC3501]. are defined in [RFC3501].
Table of Contents Table of Contents
Status of this Memo...............................................1 Status of this Memo...............................................1
Copyright Notice..................................................1
Abstract..........................................................1 Abstract..........................................................1
Conventions used in this document.................................1 Conventions used in this document.................................1
Table of Contents.................................................2 Table of Contents.................................................2
1. Introduction................................................2 1. Introduction................................................2
2. LVFOLDER Capability.........................................3 2. VFOLDER semantics...........................................3
3. CREATE Command Extension....................................3 3. VFOLDER Capability..........................................4
4. Response Codes..............................................4 4. CREATE Command Extension....................................4
5. Response Codes..............................................4
A.1. BADBACKING................................................4 A.1. BADBACKING................................................4
A.2. BADSEARCH.................................................4 A.2. BADSEARCH.................................................5
5. Formal Syntax...............................................4 6. Formal Syntax...............................................5
7. Message and Mailbox changes.................................5 7. Examples....................................................5
Security Considerations...........................................6 8. Message and Mailbox changes.................................6
IANA Considerations...............................................6 9. List Extension..............................................7
References........................................................6 10. ACL.........................................................7
Normative Appendices...........................................7 A. Avoiding Duplicates (Informative)...........................8
A. SEARCH extensions...........................................7 Security Considerations...........................................8
B. Dealing with mutable message state..........................7 Normative References..............................................8
Future Work.......................................................7 Future Work.......................................................9
Version History...................................................8 Version History...................................................9
Acknowledgments...................................................8 Acknowledgments..................................................10
Authors Addresses.................................................8 Authors Addresses................................................10
Intellectual Property Statement...................................9 Intellectual Property Statement..................................11
Disclaimer of Validity............................................9 Disclaimer of Validity...........................................11
Copyright Statement...............................................9 Copyright Statement..............................................11
1. Introduction 1. Introduction
<VFOLDER> February 2006 <VFOLDER> May 2006
The LVFOLDER extension is present in any IMAP4 implementation which The VFOLDER extension is present in any IMAP4 implementation which
returns “LVFOLDER” as one of the supported capabilities in the returns "VFOLDER" as one of the supported capabilities in the
CAPABILITY command. CAPABILITY command.
A virtual folder is an IMAP4 folder with attached search criteria. A virtual folder (vfolder) is an IMAP4 folder with attached search
The search criteria specify the backing mailbox, as well as a subset criteria. A new CREATE parameter allows clients to specify a backing
IMAP SEARCH grammar which may be applied to the immutable properties mailbox and search criteria, such that messages in the backing
of messages in the backing mailbox. Once created, all operations mailbox which satisfy the search criteria are shown in the vfolder.
applied to the virtual mailbox, such as APPEND and STORE, are Once created, operations applied to the virtual mailbox, such as
actually applied to the backing mailbox. For all intents and APPEND and STORE, may be applied to the backing mailbox. For all
purposes, the virtual folder looks and behaves like a real IMAP4 intents and purposes, the virtual folder looks and behaves like a
folder. real IMAP4 folder, except that it does not contain any messages
itself.
Any changes made to the underlying folder must pass the search The intent of this extension is to provide efficient access to
criteria for the virtual folder before being visible. UIDs are potentially large or high velocity mailboxes, for all clients,
preserved, and as well as the UIDVALIDITY value. In general, most particularly resource restricted mobile clients.
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 VFOLDER also defines two new response codes and if [LISTEXT] is
messages in the sequence, and the ordering of UIDs, MUST be supported, it defines 1 new selection option and 1 new return option.
preserved.
From the client’s perspective, whether or not a mailbox is a vfolder 2. VFOLDER semantics
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 When a change is made to the backing mailbox, such as the deposit of
flags and non-immutable messages annotations. a new message, or the mutation of a dynamic message attribute, the
change must pass the search criteria of the virtual folder before
being visible in it.
2. LVFOLDER Capability Changes made to dynamic attributes of messages in a vfolder are
propagated to the backing mailbox (e.g. STORE) APPEND/COPY to a
vfolder SHOULD be supported as well, but may not on some
implementations.
A server which supports LVFOLDER returns “LVFOLDER” as one of the From the client's perspective, a vfolder should appear to function as
responses of the CAPABILITY command. LPSEARCH adheres to a regular mailbox. This includes the ability for a new virtual folder
[CREATEPARAM] and [ABNFEXTEND] syntax so a server MAY also wish to to be created by using another virtual folder as a backing mailbox.
report additional capabilities for extended CREATE.
3. CREATE Command Extension A VFOLDER search MUST NOT reference session dependent keys such as
MSN sequence sets, NEW, OLD, and RECENT. A VFOLDER implementation MAY
permit search on dynamic message attributes (e.g. flags) but clients
should not assume support without checking for BADSEARCH response
codes.
If a server does support search on dynamic attributes, the
possibility arises that a message may be included in a vfolder,
excluded, and then included again. When this happens, the server MUST
generate a new UID each time, and this implies that the order of
messages in a vfolder need not match the underlying order of the
<VFOLDER> May 2006
backing mailbox. VFOLDER aware clients may wish to try and detect
this case and prevent duplicate downloads.
The VFOLDER extension makes a message appear in multiple
"mailboxes" at a time; one actual mailbox and zero or more views.
Messages can also disappear and reappear in views. This complicates
the semantics of the \Recent pseudoflag considerably. To simplify
implementation, the server MAY omit computing any \Recent pseudoflag
for view mailboxes. In that case, a message is only \Recent when
viewed in the underlying mailbox. If it does compute \Recent, it
should present the view exactly as an ordinary mailbox.
3. VFOLDER Capability
A server which supports LVFOLDER returns "VFOLDER" as one of the
responses of the CAPABILITY command. VFOLDER adheres to [CREATEPARAM]
and [ABNFEXTEND] syntax so a server MAY also wish to report
additional capabilities for extended CREATE.
4. CREATE Command Extension
Arguments: mailbox name Arguments: mailbox name
Optional “LPSEARCH” backing mailbox name & Optional "VFOLDER" backing mailbox name &
search criteria search criteria
<VFOLDER> February 2006
Responses: optional NO responses BADSEARCH,BADBACKING Responses: optional NO responses BADSEARCH,BADBACKING
Result: OK created lpsearch completed Result: OK created lpsearch completed
NO cant create mailbox with that name NO can't create mailbox with that name
BAD command unknown or arguments invalid BAD command unknown or arguments invalid
All of the semantics of CREATE as defined in 6.3.3 of [RFC3501] must All of the semantics of CREATE as defined in 6.3.3 of [RFC3501]
hold. Additionally, if the backing mailbox name doesn’t exist, the must hold. Additionally, if the backing mailbox name doesn't exist,
creation MUST fail with a NO result and BADBACKING response code. If the creation MUST fail with a NO result and BADBACKING response code.
the search criteria are invalid because the search would violate some
of the required properties (immutable message properties only), If the search criteria are invalid because the search references
search keys which cannot be used (e.g. session dependent keys like
NEW, OLD, RECENT) or because the server deems a persistent search on
those keys too expensive or not implemented (e.g. mailbox flags),
BADSEARCH must be reported with a NO response, or if the SEARCH 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 contains an error in one of its argument values, a NO with a
BADSEARCH response is returned. BADSEARCH response is returned. The response SHOULD provide enough
explanation to allow a user to correct the search.
4. Response Codes 5. Response Codes
A.1. A.1.
BADBACKING BADBACKING
The mailbox name used for the backing mailbox doesn’t exist. The mailbox name used for the backing mailbox doesn't exist.
<VFOLDER> May 2006
A.2. A.2.
BADSEARCH BADSEARCH
The search criteria violates the pre-conditions mentioned in The search criteria violates the pre-conditions mentioned in
section 1, or some of the arguments of the search are invalid. section 2, or some of the arguments of the search are invalid.
5. Formal Syntax 6. Formal Syntax
The following syntax specification uses the Augmented Backus-Naur The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) notation. Elements not defined here can be found in Form (ABNF) notation. Elements not defined here can be found in
the formal syntax of the [ABNF], [RFC3501], and [ABNFEXTEND]. the formal syntax of the [ABNF], [RFC3501], and [ABNFEXTEND].
The create ABNF grammar in [RFC3501] is hereby modified to the The create ABNF grammar in [RFC3501] is hereby modified to the
grammar defined in [ABNFEXTEND]. An additional CREATE param grammar defined in [ABNFEXTEND]. An additional CREATE param "VFOLDER"
“LPSEARCH” is introduced whose value is a list containing the backing is introduced whose value is a list containing the backing store
store mailbox and the search parameters. mailbox and the search parameters.
create_param =/ “LVFOLDER” SP “(“ backing-mailbox psearch “)” create_param =/ "VFOLDER" SP "(" backing-mailbox psearch ")"
;; conforms to generic "create-param" syntax as ;; conforms to generic "create-param" syntax as
defined in [ABNFEXTEND] defined in [ABNFEXTEND]
backing-mailbox = mailbox backing-mailbox = mailbox
psearch = search-program psearch = search-program
; defined in [ABNFEXTEND] ; defined in [ABNFEXTEND]
; RECENT, NEW, and OLD should not be used.
6. Examples option-extension =/ "VFOLDER"
; option-extension is in [LISTEXT]
C: a1 CREATE lemonade (LPSEARCH (INBOX HEADER “Sender” “lemonade- vfolder-extended-item = "VFOLDER" SP "(" mailbox SP nstring ")"
bounces”))
<VFOLDER> February 2006
S: a1 OK CREATE LPSEARCH Completed 7. Examples
C: a1 CREATE lemonade (VFOLDER(INBOX HEADER "Sender" "lemonade-
bounces"))
S: a1 OK CREATE VFOLDER Completed
Create a persistent mailbox which shows only messages sent to Create a persistent mailbox which shows only messages sent to
lemonade mailing list. lemonade mailing list.
C: a2 CREATE mobile (LPSEARCH (INBOX FROM “boss@mycompany.com”)) C: a2 CREATE mobile (VFOLDER(INBOX FROM "boss@mycompany.com"))
S: a2 OK CREATE LPSEARCH Completed S: a2 OK CREATE VFOLDER Completed
Create a mailbox to be synchronized (not in scope of this Create a mailbox to be synchronized (not in scope of this
document) with a mobile device. document) with a mobile device.
C: a2 CREATE mobile (LPSEARCH (INBOX FROM “boss@mycompany.com” WITHIN <VFOLDER> May 2006
259200))
C: a2 CREATE mobile (VFOLDER (INBOX FROM "boss@mycompany.com" WITHIN
3))
S: a2 OK CREATE LPSEARCH Completed S: a2 OK CREATE LPSEARCH Completed
Create a mailbox that contains all messages from Create a mailbox that contains all messages from
boss@mycompany.com that were sent within the last 3 days according to boss@mycompany.com that were sent within the last 3 days according to
the timezone of the server, utilizing the [WITHIN] draft extension. the time of the server, utilizing the [WITHIN] draft extension.
C: a3 CREATE foo (LPSEARCH (INBOX FROM “boss@mycompany.com”)) C: a3 CREATE foo (VFOLDER (IMBOX FROM "boss@mycompany.com"))
S: a3 NO [BADBACKING] CREATE failed. IMBOX is not a valid mailbox. S: a3 NO [BADBACKING] CREATE failed. IMBOX is not a valid mailbox.
Attempt to create a mailbox with a non-existence backing mailbox Attempt to create a mailbox with a non-existent backing mailbox
(fail) (fail)
C: a3 CREATE foo (LPSEARCH (INBOX FLAGGED)) C: a3 CREATE foo (VFOLDER (INBOX RECENT))
S: a3 NO [BADSEARCH] CREATE failed. SEARCH refers to mutable S: a3 NO [BADSEARCH] CREATE failed. SEARCH refers to session
properties dependent properties.
Attempt to create a mailbox with a search for flagged messages Attempt to create a mailbox with a search based on session
(fail)_ dependent keys.
7. Message and Mailbox changes C: a3 CREATE foo (VFOLDER (INBOX UNSEEN))
S: a3 NO [BADSEARCH] CREATE failed. SEARCH refers to message flags.
VFOLDER with dynamic attributes not implemented by this server.
When new messages arrive, or messages are expunged, an untagged 8. Message and Mailbox changes
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.
<VFOLDER> February 2006 The DELETE Command (RFC 3501 section 6.3.4) offers a special problem
if a mailbox is deleted while there are vfolders onto that mailbox.
Servers MUST NOT show messages in deleted mailboxes to clients. If a
DELETE command deletes a mailbox, existing vfolders which reference
the mailbox should be deleted and not appear in future LIST commands.
If a client has a vfolder currently SELECTed, the server MUST not
show any messages.
If a backing mailbox is deleted, then all vfolders attached to that The RENAME Command (RFC 3501 section 6.3.5) has a similar problem:
backing mailbox as deleted as well. If a mailbox is renamed, what happens to views onto that mailbox? The
server MAY treat it in the same way as a DELETE command by removing
all vfolders attached to the old mailbox name, OR it MAY track the
new name and modify all dependent vfolders to use the new folder
name.
Changes to UIDVALIDITY, UIDNEXT, and other underlying properties of The APPEND Command (RFC 3501 section 6.3.11) and the COPY Command
the backing mailbox are reflected in all attached vfolders. <VFOLDER> May 2006
Security Considerations (RFC 3501 section 6.4.7) MAY be used to append/copy messages to
vfolder, depending on the implementation. A NO response should be
generated if the server lacks APPEND/COPY support on VFOLDER.
The LVFOLDER extension does not raise any security considerations The LIST Command (RFC 3501 section 6.3.8) MUST tag vfolders with the
which are not present in the base protocol. Considerations are the new \Vfolder mailbox flag. (LIST is also described below.)
same as for IMAP [RFC 3501].
IANA Considerations The EXPUNGE Command (RFC 3501 section 6.4.3) causes the underlying
mailbox to be expunged when a view is expunged. Servers SHOULD
expunge only the messages visible in the view, or MAY expunge the
entire mailbox. The former is more desirable, if possible.
When using the LVFOLDER extension, the names of created mailboxes The IDLE command should treat vfolders the same as any normal
MUST not overlap with existing mailboxes. Therefore the following mailbox. When new messages arrive, or messages are expunged, an
mailbox names are reserved and not suitable as names of mailboxes untagged response MUST be sent to the client just as it would if the
created by VFOLDER: backing mailbox was selected.
- INBOX*
- OUTBOX*
- SENT*
- DELETED*
- DRAFTS*
- CONTACTS*
- CALENDAR*
- TASKS*
Where * denotes are other combination of characters. 9. List Extension
These mailbox names are reserved. If the server also supports [LISTEXT], a client can find existing
vfolders, and can read the search expression for an existing vfolder.
References The selection option vfolder instructs the server to return LIST
responses only for vfolders.
[ABNF] D. Crocker, et al. "Augmented BNF for Syntax Specifications: The return option vfolders instructs the server to include the view's
ABNF”, RFC 2234, November 1997. search and underlying mailbox in a LIST response.
http://www.ietf.org/rfc/rfc2234
[ABNFEXTEND] Melnikov, A., and C. Daboo, "Collected extensions to Some servers MAY elect to hide vfolders by default so that non-
IMAP4 ABNF", work in progress, draft-melnikov-imap-ext-abnf-XX.txt. vfolder aware clients cannot see them. In such cases, if a client
uses the vfolder selection option, the server MUST return responses
with vfolders.
[CREATEPARAM] Melnikov, A., “IMAP CREATE/RENAME parameters”, draft- 10. ACL
melnikov-imap-createparams-01.txt, September 2005.
[WITHIN] Maes, S.H., Cromwell, R., “WITHIN Search extension to the SETACL can be used to set access control lists on vfolders, just like
IMAP Protocol”, draft-ietf-lemonade-search-within-0x.txt, February on mailboxes. The i right (COPY/APPEND) MAY or MAY NOT be granted on
2006 (Work in progress) a view.
<VFOLDER> February 2006
[P-IMAP] Maes, S.H., Lima R., Kuang, C., Cromwell, R., Ha, V. and LISTRIGHTS acts as for mailboxes.
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 MYRIGHTS computes access as for mailboxes. However, it may or may
Version 4 rev1", RFC 3501, March 2003. not consider the underlying mailbox ACL, depending on how a server
http://www.ietf.org/rfc/rfc3501 implements VFOLDER.
Normative Appendices <VFOLDER> May 2006
A. If it considers the underlying mailbox ACL, the ACL on a mailbox
SEARCH extensions controls all access to the messages stored there. From a security
perspective, this may be considered an advantage.
In order to support certain mobile uses cases, the ABNF search-key If it works independently of the underlying mailbox ACL, vfolders can
grammar of [RFC3501] has been extended with a new search key: WITHIN be used to selectively grant access to a few messages in a mailbox.
<interval seconds> This can also be viewed as a security advantage, since it allows
more finegrained access control.
search-key /= “WITHIN” nz-number A. Avoiding Duplicates (Informative)
The key returns messages whose sent date is within the specified With the introduction of VFOLDER, two problems arise. First, a
interval starting from the current date of the server. message may appear in one or more vfolders as well as the backing
mailbox. Clients may wish to prevent the duplicate retrieval of such
messages. Secondly, it is possible for a message to appear,
disappear, and reappear in a VFOLDER, which causes the message to be
assigned a new UID by the server. This may result in unnecessary
duplication of message on a client, may confuse users, and may
interfere with notification mechanisms.
B. Clients wishing to check if a message is a duplicate at this point
Dealing with mutable message state may have to fetch message headers of new message and compare that
against the local client cache of messages. This may require some
reasonable persistence of deleted messages in the cache. See [IMAP-
DISC] section 4.2.2.1 for a discussion of a possible technique.
In order to gain implementation simplicity, vfolder prohibits the Future versions of VFOLDER may introduce a new server supported
usage of mutable message state in search criteria when creating a mechanism for efficiently determining the original mailbox and UID of
folder. It does not however, prevent searching on mutable state a message
elsewhere.
Clients that wish to create virtual folders based on mutable state Security Considerations
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 The VFOLDER extension does not raise any security considerations
which are not present in the base protocol. Considerations are the
same as for IMAP [RFC 3501].
[1] Decide whether virtual mailboxes may have their own annotations Normative References
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.
<VFOLDER> October 2005 [ABNF] D. Crocker, et al. "Augmented BNF for Syntax Specifications:
ABNF", RFC 4234, October 2005.
http://www.ietf.org/rfc/rfc4234
[ABNFEXTEND] Melnikov, A., and C. Daboo, "Collected extensions to
IMAP4 ABNF", work in progress, draft-melnikov-imap-ext-abnf-XX.txt.
<VFOLDER> May 2006
[ACL] Melnikov, A., "IMAP4 Access Control List (ACL)
Extension", RFC 4314, Isode Ltd., December 2005.
[CREATEPARAM] Melnikov, A., "IMAP CREATE/RENAME parameters", draft-
melnikov-imap-createparams-01.txt, September 2005.
[IMAP-DISC] Melnikov, A. " Synchronization operations for
disconnected IMAP4 clients", draft-melnikov-imap-disc-06.txt, October
2004.
[LISTEXT] Leiba, B. and A. Melnikov, "IMAP4 LIST Command
Extensions", work in progress, draft-ietf-imapext-list-
extensions-xx.txt.
[RFC3501] Crispin, M. "IMAP4, Internet Message Access Protocol
Version 4 rev1", RFC 3501, March 2003.
http://www.ietf.org/rfc/rfc3501
[WITHIN] Maes, S.H., Cromwell, R., "WITHIN Search extension to the
IMAP Protocol", draft-maes-lemonade-search-within-02.txt, May 2006
Future Work
[1] Determine what, if any, of VIEW and VFOLDER's former restrictions
on search parameters must be restored.
[2] Better solution for the duplicate download problem
[3] Tighten semantics and defined behavior, promoting some MAY or
SHOULD to MUST.
Version History Version History
Release 00 (was 03 of draft-maes-lemonade-vfolder) Release 04
Separate WITHIN extension to separate draft Overhauled since last IETF Plenary. Merged Arnt Gulbrandsen's VIEW
Additional section on IANA considerations draft with VFOLDER 03 draft. Release 04 represents a superset,
Release 02 of draft-maes-lemonade-vfolder with some of both VFOLDER and VIEW's restrictions removed.
Release 03
Separate SEARCH extension to separate draft
Release 02
Update to address comments from Alexey Melnikov, and a new Update to address comments from Alexey Melnikov, and a new
restricted model using immutable message properties restricted model using immutable message properties
Release 01 of draft-maes-lemonade-vfolder Release 01
<VFOLDER> May 2006
Update to address comments from Alexey Melnikov to follow Update to address comments from Alexey Melnikov to follow
appropriately the generic syntax provided in draft-melnikov-imap-ext- appropriately the generic syntax provided in draft-melnikov-imap-ext-
abnf-05.txt. abnf-05.txt.
Release 00 of draft-maes-lemonade-vfolder Release 00
Initial release Initial release
Acknowledgments Acknowledgments
We want to give a special thanks to A. Melnikov for his review and
suggestions, and to thank Arnt Gulbrandsen for his excellent VIEW
proposal, which has now been merged with VFOLDER.
The authors want to thank all who have contributed key insight and The authors want to thank all who have contributed key insight and
extensively reviewed and discussed the concepts of LPSEARCH and its extensively reviewed and discussed the concepts of LPSEARCH and its
early introduction P-IMAP [P-IMAP]. In particular, this includes the early introduction P-IMAP [P-IMAP]. In particular, this includes the
authors of the P-IMAP draft: Rafiul Ahad – Oracle Corporation, Eugene authors of the P-IMAP draft: Rafiul Ahad – Oracle Corporation, Eugene
Chiu – Oracle Corporation, Ray Cromwell – Oracle Corporation, Jia-der Chiu – Oracle Corporation, Ray Cromwell – Oracle Corporation, Jia-der
Day – Oracle Corporation, Vi Ha – Oracle Corporation, Wook-Hyun Jeong Day – Oracle Corporation, Vi Ha – Oracle Corporation, Wook-Hyun Jeong
– Samsung Electronics Co. LTF, Chang Kuang – Oracle Corporation, – Samsung Electronics Co. LTF, Chang Kuang – Oracle Corporation,
Rodrigo Lima – Oracle Corporation, Stephane H. Maes – Oracle Rodrigo Lima – Oracle Corporation, Stephane H. Maes – Oracle
Corporation, Gustaf Rosell - Sony Ericsson, Jean Sini – Symbol Corporation, Gustaf Rosell - Sony Ericsson, Jean Sini – Symbol
Technologies, Sung-Mu Son – LG Electronics, Fan Xiaohui - CHINA Technologies, Sung-Mu Son – LG Electronics, Fan Xiaohui - CHINA
MOBILE COMMUNICATIONS CORPORATION (CMCC), Zhao Lijun - CHINA MOBILE MOBILE COMMUNICATIONS CORPORATION (CMCC), Zhao Lijun - CHINA MOBILE
COMMUNICATIONS CORPORATION (CMCC). We also want to give a special COMMUNICATIONS CORPORATION (CMCC).
thanks to A. Melnikov for his review and suggestions.
Authors Addresses Authors Addresses
Stephane H. Maes Stephane H. Maes
Oracle Corporation Oracle Corporation
500 Oracle Parkway 500 Oracle Parkway
M/S 4op634 M/S 4op634
Redwood Shores, CA 94065 Redwood Shores, CA 94065
USA USA
Phone: +1-650-607-6296 Phone: +1-650-607-6296
Email: stephane.maes@oracle.com Email: stephane.maes@oracle.com
Ray Cromwell Ray Cromwell
Oracle Corporation Oracle Corporation
500 Oracle Parkway 500 Oracle Parkway
Redwood Shores, CA 94065 Redwood Shores, CA 94065
USA USA
<VFOLDER> October 2005
Arnt Gulbrandsen
Oryx Mail Systems GmbH
Schweppermannstr. 8
D-81671 Muenchen
Germany
<VFOLDER> May 2006
Anil Srivastava Anil Srivastava
Sun Microsystems Sun Microsystems
4150 Network Circle SCA15/201 4150 Network Circle SCA15/201
Santa Clara, CA 94065 Santa Clara, CA 94065
anil.srivastava@sun.com anil.srivastava@sun.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 7878 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an 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 attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
skipping to change at page 10, line 4 skipping to change at page 12, line 4
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgement Acknowledgement
<VFOLDER> October 2005 <VFOLDER> May 2006
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 78 change blocks. 
187 lines changed or deleted 275 lines changed or added

This html diff was produced by rfcdiff 1.31. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/