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-

    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 The list of Internet-
    Draft Shadow Directories can be accessed at

    This Internet-Draft will expire in August, 2006.

Copyright Notice

    Copyright (C) The Internet Society (2006).


    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

    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

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.


    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

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

    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.


    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

         C: a VIEW CREATE INBOX "IMAP-announcements" HEADER "Sender"
            "<>" 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

         C: b VIEW CREATE "/archive/support" "/customers/example" OR OR
            FROM ">" TO ">" CC ">"
         S: b OK Created view /customers/example

    This example shows an unextended LIST and two extended LIST

         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-
  >\" 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

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

        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


    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.


    (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

    [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-

Author's Address

    Arnt Gulbrandsen
    Oryx Mail Systems GmbH
    Schweppermannstr. 8
    D-81671 Muenchen

    Fax: +49 89 4502 9758

Gulbrandsen                 Expires July 2006                   [Page 7]

Internet-draft                                             February 2006


    Abhijit Menon-Sen
    Oryx Mail Systems GmbH
    Schweppermannstr. 8
    D-81671 Muenchen


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

    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

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

    This document and the information contained herein are provided


    Funding for the RFC Editor function is currently provided by the
    Internet Society.

Gulbrandsen                 Expires July 2006                   [Page 9]