Internet DRAFT - draft-gulbrandsen-imap-view
draft-gulbrandsen-imap-view
Network Working Group Arnt Gulbrandsen
Request for Comments: DRAFT Abhijit Menon-Sen
draft-gulbrandsen-imap-view-00.txt Oryx Mail Systems GmbH
February 2006
The IMAP VIEW extension
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.
This Internet-Draft will expire in August, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The VIEW extension allows an [IMAP] client to create and manipulate
mailbox views (persistent searches).
All [IMAP] clients can access a view, as if it were an ordinary
mailbox. Clients which implement the VIEW extension can create
views. Clients which implement both VIEW and [LISTEXT] can find and
modify existing views.
Gulbrandsen Expires July 2006 [Page 1]
Internet-draft February 2006
Conventions Used in This Document
The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD
NOT", and "MAY" in this document are to be interpreted as described
in "Key words for use in RFCs to Indicate Requirement Levels"
[KEYWORDS]. Formal syntax is defined by [ABNF] as modified by
[IMAP].
In the example, "C:" and "S:" indicate lines sent by the client and
server respectively.
Introduction and Overview
An IMAP server that supports this extension announces "VIEW" as one
of its capabilities.
The goal of VIEW is to provide efficient and useful access to large
mailboxes (in particular archives) and require small changes to
clients. The extension should also be practically implementable for
current-day servers (even though it may cost some CPU).
The extension adds one new command (VIEW CREATE) and one new mailbox
flag (\View). It adds no new responses. If a server also supports
the [LISTEXT] extension, VIEW adds one new selection option and one
new return option.
Mailbox Views
A view, as defined by this document, is a mailbox which does not
contain any messages of its own, but instead provides access to a
selected subset of another mailbox's messages.
Only a VIEW-supporting IMAP client can create a view, however any
IMAP client can use the view.
The view specification uses regular IMAP search syntax, except that
session-dependent search keys MUST NOT be used. At the time of
writing, the session-dependent keys are MSN sequence sets, NEW, OLD
and RECENT. (IMAP extensions may add more in the future.)
When a view specification uses dynamic attributes of a message
(primarily flags), a message may be included in a view, later
excluded and later still included again. When this happens, the
server MUST issue a new UID every time. This implies that the order
of messages in a view need not match the order in the underlying
mailbox.
Gulbrandsen Expires July 2006 [Page 2]
Internet-draft February 2006
Views and mailboxes exist in the same name space: creating a view
fails if there already is a mailbox of that name, and creating a
mailbox fails if there already is a view of that name.
Permanent flags are an attribute of the message, not of the mailbox
or session; hence, it does not matter whether the message is
accessed via a mailbox or view. The effect on permanent flags of a
STORE or FETCH command is exactly the same in both cases.
The VIEW 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.
The VIEW CREATE Command
Arguments: Name of underlying mailbox
Name of view to be created
Search expression
Responses: None
Result: OK The server has created the view.
NO The client lacks permission to create the view or
access the mailbox, the view exists, or the mailbox
does not exist.
BAD Command unknown or invalid argument.
The server creates the target view, unless a view or mailbox
already exists with that name, and stores the search expression.
When a client later accesses the view with SELECT or EXAMINE,
the server performs a search on the mailbox and shows the client
only the resulting messages.
The VIEW CREATE command is valid in Authenticated and Selected
states.
Base IMAP Commands
Most commands (SELECT, EXAMINE, SUBSCRIBE, etc) can be used to
select, examine, subscribe, etc. views as well as mailboxes.
Gulbrandsen Expires July 2006 [Page 3]
Internet-draft February 2006
The CREATE Command (RFC 3501 section 6.3.3) fails if a view already
exists with the desired name.
The DELETE Command (RFC 3501 section 6.3.4) offers a special problem
if a mailbox is deleted while there are views onto that mailbox. In
order to simplify implementation, no particular behaviour is
mandated in that case. However, servers MUST NOT show messages in
deleted mailboxes to clients.
The RENAME Command (RFC 3501 section 6.3.5) has a similar problem:
If a mailbox is renamed, what happens to views onto that mailbox?
Again, no particular behaviour is mandated.
The LIST Command (RFC 3501 section 6.3.8) MUST tag views with the
new \View mailbox flag. (LIST is also described below.)
The APPEND Command (RFC 3501 section 6.3.11) and the COPY Command
(RFC 3501 section 6.4.7) cannot be used to append/copy messages to
views.
The EXPUNGE Command (RFC 3501 section 6.4.3) causes the underlying
mailbox to be expunged when a view is expunged. Servers MAY expunge
only the messages visible in the view, or MAY expunge the entire
mailbox. The former is more desirable, if possible.
ACL Commands
SETACL can be used to set access control lists on views, just like
on mailboxes. The i right (COPY/APPEND) cannot be granted on a view.
LISTRIGHTS acts as for mailboxes.
MYRIGHTS computes access as for mailboxes. However, it may or may
not consider the underlying mailbox ACL, depending on how a server
implements VIEW.
If it considers the underlying mailbox ACL, the ACL on a mailbox
controls all access to the messages stored there. From a security
perspective, this may be considered an advantage.
If it works independently of the underlying mailbox ACL, views can
be used to selectively grant access to a few messages in a mailbox.
This can also be viewed as a security advantage, since it allows
more finegrained access control.
Gulbrandsen Expires July 2006 [Page 4]
Internet-draft February 2006
LIST Extensions
If the server also supports [LISTEXT], a client can find existing
views, and can read the search expression for an existing view.
The selection option VIEWS instructs the server to return LIST
responses only for views.
The return option VIEWS instructs the server to include the view's
search and underlying mailbox in a LIST response.
Examples
In examples, some lines have been wrapped for editorial clarity.
This example creates a view onto INBOX that looks at all IETF-
Announce messages that contain either "IMAP" or "SMTP" in the body
text:
C: a VIEW CREATE INBOX "IMAP-announcements" HEADER "Sender"
"<ietf-announce-request@ietf.org>" OR BODY imap BODY smtp
S: a OK Created view user.fred.IMAP-announcements
This example creates a view onto /archive/support that selects all
mail to or from example.com:
C: b VIEW CREATE "/archive/support" "/customers/example" OR OR
FROM "@example.com>" TO "@example.com>" CC "@example.com>"
S: b OK Created view /customers/example
This example shows an unextended LIST and two extended LIST
commands:
C: c LIST "" "%"
S: * LIST (\hasnochildren) "." INBOX
S: * LIST (\hasnochildren \view) "." IMAP-announcements
S: c OK
C: d LIST (views) "" "%"
S: * LIST (\hasnochildren \view) "." IMAP-announcements
C: e LIST (views) "" "%" return (views)
S: * LIST (\hasnochildren \view) "." IMAP-announcements ((view
(INBOX "HEADER \"Sender\" \"<ietf-announce-
request@ietf.org>\" OR BODY imap BODY smtp")))
S: e OK
Note that commands d and e only work if the server supports both
VIEW and [LISTEXT].
Gulbrandsen Expires July 2006 [Page 5]
Internet-draft February 2006
Implementation Notes
In many servers, views can be implemented as a new form of mailbox
format.
Open Issues
The way [LISTEXT] returns the search key is not. How should it be
done? If it's sent as a quoted string, it's hard to express in the
formal grammar. Sending it unquoted, writing the grammar so it fits
both search-leu and the mbox-list-extended-item-data in [LISTEXT]
seems a very tricky proposition.
The return option could do with a bit improvement, all over.
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 [ABNF] (SP, CRLF)
or [IMAP] (all others).
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.
command-auth =/ view
; command-auth is in [IMAP]
option-extension =/ "VIEW"
; option-extension is in [LISTEXT]
view = "VIEW" SP "CREATE" mailbox SP mailbox 1*(SP
search-key)
view-extended-item = "VIEW" SP "(" mailbox SP nstring ")"
; see the open issues section
Security considerations
While views do not need more server capacity than the equivalent
functionality would if the search were implemented on the client or
using SEARCH, the presence of VIEW may tempt users to use larger
mailboxes and search more often on them, which may lead to resource
Gulbrandsen Expires July 2006 [Page 6]
Internet-draft February 2006
problems.
The interaction between VIEW and [ACL] is nontrivial. An ACL change
on a mailbox may either change the ACLs on many views, or it may be
partly ineffective, because some messages are also visible via
views, bypassing the new ACL.
IANA considerations
The IANA is requested to add VIEW to the list of IMAP extensions.
Credits
(Your name here :)
Normative References
[ABNF] Crocker, Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, Internet Mail
Consortium, Demon Internet Ltd, November 1997.
[KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, Harvard University, March
1997.
[IMAP] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 3501, University of Washington, June 2003.
[ACL] Melnikov, A., "IMAP4 Access Control List (ACL)
Extension", RFC 4314, Isode Ltd., December 2005.
[LISTEXT] Leiba, B. and A. Melnikov, "IMAP4 LIST Command
Extensions", work in progress, draft-ietf-imapext-list-
extensions-xx.txt.
Author's Address
Arnt Gulbrandsen
Oryx Mail Systems GmbH
Schweppermannstr. 8
D-81671 Muenchen
Germany
Fax: +49 89 4502 9758
Gulbrandsen Expires July 2006 [Page 7]
Internet-draft February 2006
Email: arnt@oryx.com
Abhijit Menon-Sen
Oryx Mail Systems GmbH
Schweppermannstr. 8
D-81671 Muenchen
Germany
Email: ams@oryx.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
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.
Gulbrandsen Expires July 2006 [Page 8]
Internet-draft February 2006
Full 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.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Gulbrandsen Expires July 2006 [Page 9]
