[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 rfc5465                               
Network Working Group                                        Curtis King
Internet-Draft                                           Alexey Melnikov
Intended Status: Proposed Standard                            Isode Ltd.
                                                        Arnt Gulbrandsen
                                                  Oryx Mail Systems GmbH
                                                       February 25, 2008


                       The IMAP NOTIFY Extension
                 draft-ietf-lemonade-imap-notify-04.txt


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 expires in July 2008.


Copyright Notice

   Copyright (C) The IETF Trust (2008).


Abstract

   This document defines an IMAP extension which allows a client to
   request specific kinds of unsolicited notifications for specified
   mailboxes, such as messages being added to or deleted from mailboxes.




King, et al.               Expires August 2008                  [Page 1]


Internet-draft                                             February 2008


   [[Add Updates: RFC-CONTEXT to the headers]]


1.  Conventions Used in This Document

   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].

   Formal syntax is defined by [RFC5234] as extended by [RFC3501] and
   [RFC4466].

   The acronym MSN stands for Message Sequence Numbers (see Section
   2.3.1.2 of [RFC3501]).

   Example lines prefaced by "C:" are sent by the client and ones
   prefaced by "S:" by the server. "[...]" means elision.


2.  Overview and rationale

   The IDLE command (defined in [RFC2177]) provides a way for the client
   to go into a mode where the IMAP server pushes notifications about
   IMAP mailstore events for the selected mailbox.  However, the IDLE
   extension doesn't restrict or control which server events can be
   sent, or what information the server sends in response to each event.
   Also, IDLE only applies to the selected mailbox, thus requiring an
   additional TCP connection per mailbox.

   This document defines an IMAP extension that allows clients to
   express their preferences about unsolicited events generated by the
   server.  The extension allows clients to only receive events they are
   interested in, while servers know that they don't need to go into
   effort of generating certain types of untagged responses.

   Without the NOTIFY command defined in this document, and IMAP server
   will only send information about mailstore changes to the client in
   the following cases:
     -  as the result of a client command (e.g. FETCH responses to
        a FETCH or STORE command),
     -  unsolicited responses sent just before the end of a command
        (e.g. EXISTS or EXPUNGE) as the result of changes in other
        sessions, and
     -  during an IDLE command.

   The NOTIFY command extends what information may be returned in those
   last two cases, and also permits and requires the server to send
   information about updates between command.  The NOTIFY command also



King, et al.               Expires August 2008                  [Page 2]


Internet-draft                                             February 2008


   allows for the client to extend what information is sent unsolicited
   about the selected mailbox, and to request some update information to
   be sent regarding other mailboxes.

   For the new messages delivered to or appended to the selected
   mailbox, the NOTIFY command can be used to request that a set of
   attributes be sent to the client in an unsolicited FETCH response.
   This allows a client to be passive recipient of events and new mail,
   and be able to maintain full synchronisation without having to issue
   any subsequent commands except to modify the state of the mailbox on
   the server.

   Some mobile clients, however, may want mail "pushed" only for mail
   that matches a SEARCH pattern.  To meet that need [CONTEXT] is
   augmented by this document to extend the UPDATE return option to
   specify a list of fetch-atts to be returned when a new message is
   delivered or appended in another session.

   [[Should the following be a normative subsection?]]  IMAP servers
   which support this extension advertise the X-DRAFT-W04-NOTIFY
   extension.

   A server implementing this extension is not required to implement
   LIST-EXTENDED [LISTEXT], even though a NOTIFY compliant server must
   be able to return extended LIST responses defined in [LISTEXT].

   [[RFC-Editor: Please delete the following before publication:
   Comments regarding this draft may be sent either to the
   lemonade@ietf.org mailing list or to the authors.]]



3.  The NOTIFY Command

    Arguments: "SET"
               optional STATUS indicator
               Mailboxes to be watched
               Events about which to notify the client

    Or
    Arguments: "NONE"

    Responses: Possibly untagged STATUS responses (for SET)

    Result: OK - The server will notify the client as requested.
            NO - Unsupported notify event, NOTIFY too complex or
               expensive, etc.
           BAD - Command unknown, invalid, unsupported or unknown



King, et al.               Expires August 2008                  [Page 3]


Internet-draft                                             February 2008


               arguments.

   The NOTIFY command informs the server that the client listens for
   event notifications all the time (even when no command is in
   progress) and requests the server to notify it about the specified
   set of events. The NOTIFY command has two forms. NOTIFY NONE
   specifies that the client is not interested in any kind of event
   happening on the server. NOTIFY SET replaces the current list of
   interesting events with a new list of events.

   Until the NOTIFY command is used for the first time, the server only
   sends notifications while a command is being processed, and notifies
   the client about these events on the selected mailbox: (see section 5
   for definitions): MessageNew, MessageExpunge, FlagChange. It does not
   notify the client about any events on other mailboxes.

   The effect of a successful NOTIFY command lasts until the next NOTIFY
   command, or until the IMAP connection is closed.

   A successful NOTIFY SET command MUST cause the server to immediately
   return any accumulated changes to the mailbox (if any), such as flag
   changes, new or expunged messages. This is equivalent to NOOP command
   being issued by the client just before the NOTIFY SET command.

   If the NOTIFY command enables MessageNew, MessageExpunge,
   AnnotationChange or FlagChange notification for a mailbox, and the
   client has specified the STATUS indicator parameter, then the server
   MUST send a STATUS response for that mailbox before NOTIFY's tagged
   OK. If MessageNew is enabled, the STATUS response MUST contain
   MESSAGES, UIDNEXT and UIDVALIDITY. If MessageExpunge is enabled, the
   STATUS response MUST contain MESSAGES. If either AnnotationChange or
   FlagChange are included, the STATUS response MUST contain UIDVALIDITY
   and HIGHESTMODSEQ.  Absence of the STATUS indicator parameter allows
   the client to avoid the additional STATUS responses. This might be
   useful if the client has already retrieved this information before
   issuing the NOTIFY command.

   Clients are advised to limit the number of mailboxes used with
   NOTIFY. Particularly, if a client asks for events for all accessible
   mailboxes, the server may swamp the client with updates about shared
   mailboxes. This wastes both server and network resources.        For
   each mailbox specified, the server verifies that the client has
   access using the following test:

   - If the name does not refer to an existing mailbox, the server MUST
     ignore it.

   - If the name refers to a mailbox which the client can't LIST, the



King, et al.               Expires August 2008                  [Page 4]


Internet-draft                                             February 2008


     server MUST ignore it. For a server that implements [RFC4314] this
     means that if the client that doesn't have the 'l' (lookup) right
     for the name, then the server MUST ignore the mailbox. This
     behavior prevents dislosure on potentially confidential information
     to clients which don't have rights to know it.

   - If the name refers to a mailbox which the client can LIST (e.g. it
     has the 'l' right from [RFC4314]), but misses another right
     required for processing of the specified event(s), then the server
     MUST respond with an untagged extended LIST response containing the
     \NoAccess name attribute.  [[Alexey: Note, the newly defined
     \NoAccess doesn't mean that the client doesn't have any rights
     other than 'l'. The \NoAccess is only meaningful in the context of
     the specified NOTIFY command.]]

   The server SHOULD return the tagged OK response if the client has
   access to at least one of the mailboxes specified in the current list
   of interesting events.  The server MAY return the tagged NO response
   if the client has no access to any of the specified mailboxes and no
   access can ever be granted in the future (e.g. the client specified
   an event for 'Subtree Bar/Foo', 'Bar/Foo' doesn't exist and LIST
   returns \Noinferiors for the parent 'Bar').

   If the notification would be prohibitively expensive for the server
   (e.g. "notify me of all flag changes in all mailboxes"), the server
   MAY refuse the command with a tagged NO [NOTIFICATIONOVERFLOW]
   response.

   If the client requests information for events of an unsupported type,
   the server MUST refuse the command with a tagged NO response (not a
   BAD).  This response SHOULD contain the BADEVENT response code, which
   MUST list names of all events supported by the server.

   Here's an example:

        S: * OK [CAPABILITY IMAP4REV1 NOTIFY]
        C: a login bob alice
        S: a OK Password matched
        C: b notify set status (selected MessageNew (uid
           body.peek[header.fields (from to subject)]) MessageExpunge)
           (subtree Lists MessageNew)
        S: * STATUS Lists/Lemonade (UIDVALIDITY 4 UIDNEXT 9999 MESSAGES
           500)
        S: [...]
        S: * STATUS Lists/Im2000 (UIDVALIDITY 901 UIDNEXT 1 MESSAGES 0)
        S: b OK done
        C: c select inbox
        S: [...] (the usual 7-8 responses to SELECT)



King, et al.               Expires August 2008                  [Page 5]


Internet-draft                                             February 2008


        S: c OK INBOX selected
               (Time passes. A new message is delivered to mailbox
                Lists/Lemonade.)
        S: * STATUS Lists/Lemonade (UIDVALIDITY 4 UIDNEXT 10000 MESSAGES
           501)
               (Time passes. A new message is delivered to inbox.)
        S: * 127 FETCH (UID 127001 BODY[HEADER.FIELDS (From To Subject)]
           {75}
        S: Subject: Re: good morning
        S: From: alice@example.org
        S: To: bob@example.org
        S:
        S: )
               (Time passes. The client decides it wants to know about
                one more mailbox.)
        C: d notify set status (selected MessageNew (uid
           body.peek[header.fields (from to subject)]) MessageExpunge)
           (subtree Lists MessageNew) (mailboxes misc MessageNew)
        S: * STATUS misc (UIDVALIDITY 1 UIDNEXT 999)
               (This command enables notification on one mailbox and
                otherwise changes nothing, so one STATUS response is
                sent.[[AM: This is no longer correct.]])
        S: d OK done


4.  Interaction with the IDLE Command

   If IDLE (as well as this extension) is supported, while processing
   IDLE the server MUST send the same events as instructed by the client
   using the NOTIFY command.

   NOTIFY makes IDLE unnecessary for some clients. If a client does not
   use MSNs and '*' in commands, it can request MessageExpunge and
   MessageNew for the selected mailbox using the NOTIFY command instead
   of entering IDLE mode.


5.  Event Types

   Only some of the events in [MSGEVENT] can be expressed in IMAP, and
   for some of them there are several possible ways to express the
   event.

   This section specifies the events which an IMAP server can notify an
   IMAP client, and how.

   The server SHOULD omit notifying the client if the event is caused by
   this client. For example, if the client issues CREATE and has



King, et al.               Expires August 2008                  [Page 6]


Internet-draft                                             February 2008


   requested MailboxName event that would cover the newly created
   mailbox, the server SHOULD NOT notify the client of the MailboxName
   change.

   All event types described in this document require the 'l' and 'r'
   rights (see [RFC4314]) on all observed mailboxes.  Servers that don't
   implement [RFC4314] should map the above rights to their access
   control model.

   Note that MessageNew and MessageExpunge must be specified together.
   It is not possible to specify one, but not the other.

   If the client instructs the server not to send MessageNew and
   MessageExpunge for the selected mailbox, the server MUST still send
   EXISTS and EXPUNGE responses as required by IMAP (see [RFC3501]
   section 7). In other words, MessageExpunge instructs the server to
   notify the client immediately, and the lack of MessageExpunge
   instructs the server to notify the client during execution of the
   next command as specified in [RFC3501].  MessageNew is handled
   similarly by the server.


5.1. FlagChange and AnnotationChange

   If the flag/annotation change happens in the selected mailbox, the
   server MUST notify the client by sending an unsolicited FETCH
   response, which MUST include UID and FLAGS/ANNOTATION FETCH data
   items. It MAY also send new FLAGS and/or OK [PERMANENTFLAGS ...]
   responses.

   If a search context is in effect as specified in [CONTEXT], an
   ESEARCH ADDTO or ESEARCH REMOVEFROM will also be generated, if
   appropriate.  [[Alexey: I don't think this is needed: In this case,
   the FETCH response MUST precede the ESEARCH response.]]

   If the change happens in another mailbox, then the response depends
   on whether CONDSTORE [RFC4551] is being used. If so, the server sends
   a STATUS (HIGHESTMODSEQ) response. Note that whenever mailbox
   UIDVALIDITY changes, the server MUST also include UIDVALIDITY in the
   STATUS response.  If CONDSTORE is not used, the server does not
   notify the client.

   FlagChange covers the MessageRead, MessageTrash, FlagsSet and
   FlagsClear events in [MSGEVENT].

   [[Open Issue: Filip Navara requested for STATUS (UNSEEN) to be sent
   for MessageRead. Arnt considers that unsound, since it involves
   processing all messages in a mailbox after an event affecting only



King, et al.               Expires August 2008                  [Page 7]


Internet-draft                                             February 2008


   one message, and since it's not reliable anyway.]]

   Example in the selected mailbox:
       S: * 99 FETCH (UID 9999 FLAGS ($Junk))

   And in another, with CONDSTORE in use:
       S: * STATUS Lists/Lemonade (HIGHESTMODSEQ 65666665)


5.2. MessageNew

   This covers both MessageNew and MessageAppend in [MSGEVENT].

   If the new/appended message is in the selected mailbox, the server
   notifies the client by sending an unsolicited EXISTS response,
   followed by an unsolicited FETCH response containing the information
   requested by the client. A FETCH response SHOULD NOT be generated for
   a new message created by the client on this particular connection,
   for instance as the result of an APPEND or COPY command to the
   selected mailbox performed by the client itself. The server MAY also
   send a RECENT response, if the server marks the message as \Recent.

   Note that a single EXISTS response can be returned for multiple
   MessageAppend/MessageNew events.

   If a search context is in effect as specified in [CONTEXT], an
   ESEARCH ADDTO will also be generated, if appropriate. In this case,
   the EXISTS response MUST precede the ESEARCH response.  Both the
   NOTIFY command and the SEARCH and SORT commands (see Section 7) can
   specify attributes to be returned for new messages.  These attributes
   SHOULD be combined into a single FETCH response.  The server SHOULD
   avoid sending duplicate data.  The FETCH response(s) MUST follow any
   ESEARCH ADDTO responses.

   If the new/appended message is in another mailbox, the server sends
   an unsolicited STATUS (UIDNEXT MESSAGES) response for the relevant
   mailbox. If CONDSTORE (defined in [RFC4551]) is in use, the
   HIGHESTMODSEQ status data item MUST be included in the STATUS
   response.

   The client SHOULD NOT use FETCH attributes that implicitly set the
   \seen flag, or that presuppose the existence of a given bodypart.
   UID, MODSEQ, FLAGS, ENVELOPE, BODY.PEEK[HEADER.FIELDS... and
   BODY/BODYSTRUCTURE may be the most useful attributes.

   Note that if a client asks to be notified of MessageNew events, the
   number of messages can increase at any time, and therefore the client
   cannot refer to a specific message using the MSN/UID '*'.



King, et al.               Expires August 2008                  [Page 8]


Internet-draft                                             February 2008


   Example in the selected mailbox:
       S: * 444 EXISTS
       S: * 444 FETCH (UID 9999)

   And in another, without CONDSTORE:
       S: * STATUS Lists/Lemonade (UIDNEXT 10002 MESSAGES 503)


5.3. MessageExpunge

   If the expunged message(s) is/are in the selected mailbox, the server
   notifies the client using EXPUNGE (or VANISHED, if [QRESYNC] is being
   used).

   If a search context is in effect as specified in [CONTEXT], an
   ESEARCH REMOVEFROM will also be generated, if appropriate.

   If the expunged message(s) is/are in another mailbox, the server
   sends an unsolicited STATUS (UIDNEXT MESSAGES) response for the
   relevant mailbox. If CONDSTORE is being used, HIGHESTMODSEQ MUST be
   included in the STATUS response.

   Note that if a client requests MessageExpunge, the meaning of a MSN
   can change at any time, so the client cannot use MSNs in commands
   anymore.  For example, such a client cannot use FETCH, but it has to
   use UID FETCH. The meaning of '*' can also change when messages are
   added or expunged. A client wishing to keep using MSNs MUST NOT
   request the MessageExpunge event.

   The MessageExpunge notification covers both MessageExpunge and
   MessageExpire events from [MSGEVENT].

   Example in the selected mailbox, without QRESYNC:
       S: * 444 EXPUNGE
   The same example in the selected mailbox, with QRESYNC:
       S: * VANISHED 5444
   And in another:
       S: * STATUS misc (UIDNEXT 999 MESSAGES 554)


5.4. MailboxName

   These notifications are sent if an affected mailbox name was created
   (with CREATE), deleted (with DELETE) or renamed (with RENAME). If a
   mailbox is created or deleted, the mailbox itself and its parent are
   considered to be affected.

   The server notifies the client by sending an unsolicited LIST



King, et al.               Expires August 2008                  [Page 9]


Internet-draft                                             February 2008


   response for each affected mailbox name. If the mailbox name does not
   refer to a mailbox after the event, the \Nonexistent flag MUST be
   included.

   For each selectable [[Alexey: is "selectable" important?]] mailbox
   renamed, the server sends an extended LIST response [LISTEXT] for the
   new mailbox name, containing the OLDNAME extended data item with the
   old mailbox name.  When a mailbox is renamed, its children are
   renamed too.  No additional MailboxName events are sent for children
   in this case.  When INBOX is renamed, a new INBOX is assumed to be
   created.  No MailboxName event must be sent for INBOX in this case.

   Example of a newly created mailbox:
       S: * LIST () "/" "NewMailbox"

   And a deleted mailbox:
       S: * LIST (\NonExistent) "/" "INBOX.DeletedMailbox"

   Example of a renamed mailbox:
       S: * LIST () "/" "NewMailbox" ("OLDNAME" ("OldMailbox"))


5.5. SubscriptionChange

   The server notifies the client by sending an unsolicited LIST
   responses for each affected mailbox name. If and only if the mailbox
   is subscribed after the event, the \Subscribed attribute (see
   [LISTEXT]) is included.

   Example:
       S: * LIST (\Subscribed) "/" "SubscribedMailbox"


5.6. MailboxMetadataChange

   The server sends an unsolicited LIST response including METADATA (as
   per Section 4.3.1 of [METADATA]). If possible, only the changed
   metadata should be included, but if necessary, all metadata must be
   included.

   Example:
       S: * LIST "/" "INBOX" (METADATA (/comment))


5.7. ServerMetadataChange

   The server sends an unsolicited METADATA response (as per Section
   4.5.2 of [METADATA]). Only the names of changed metadata entries



King, et al.               Expires August 2008                 [Page 10]


Internet-draft                                             February 2008


   SHOULD be returned in such METADATA responses.

   Example:
       S: * METADATA (/comment)



5.8. Notification Overflow

   If the server is unable or unwilling to deliver as many notifications
   as it is being asked to, it may disable notifications for some or all
   clients.  It MUST notify these clients by sending an untagged "OK
   [NOTIFICATIONOVERFLOW]" response and behave as if a NOTIFY NONE
   command had just been received.

   Example:
       S: * OK [NOTIFICATIONOVERFLOW] ...A comment can go here...



5.9. ACL Changes

   Even if NOTIFY succeeds, it is still possible to loose access to the
   mailboxes monitoried at a later time. If this happens, the server
   MUST silently stop monitoring these mailboxes. If access is later
   granted, the server MUST restart event monitoring.


6.  Mailbox Specification

   Mailboxes to be monitored can be specified in several different ways.

   Only 'selected' matches the currently selected mailbox. If the client
   specifies monitoring of the same mailbox several times, the first
   specification wins. A common example is asking for events on the
   selected mailbox and some named mailboxes.

   In this example, the client asks for MessageExpunge events for all
   personal mailboxes except the selected mailbox:
       C: a notify set (selected (MessageNew (uid flags) flagchange))
          (personal (MessageNew FlagChange MessageExpunge))


6.1. Selected

   Selected refers to the mailbox selected using either SELECT or
   EXAMINE (see [RFC3501] section 6.3.1 and 6.3.2). When the IMAP
   connection is not in selected state, selected does not refer to any



King, et al.               Expires August 2008                 [Page 11]


Internet-draft                                             February 2008


   mailbox.


6.2. Personal

   Personal refers to all selectable mailboxes in the user's personal
   namespace(s).


6.3. Inboxes

   Inboxes refers to all selectable mailboxes in the user's personal
   namespace(s) to which messages may be delivered by an MDA (see
   [EMAIL-ARCH], particularly section 4.3.3).

   If the IMAP server cannot easily compute this set, it MUST treat
   "inboxes" as equivalent to "personal".


6.4 Subscribed

   Subscribed refers to all mailboxes subscribed by the user.

   If the subscription list changes, the server MUST reevaluate the
   list.


6.5 Subtree

   Subtree is followed by a mailbox name or list of mailbox names.  A
   subtree refers to all selectable mailboxes which are subordinate to
   the specified mailbox plus the mailbox itself.


6.6 Mailboxes

   Mailboxes is followed by a mailbox name or a list of mailbox names.
   The server MUST NOT do wildcard expansion.  This means there is no
   special treatment for the LIST wildcard characters ('*' and '%') if
   they are present in mailbox names.


7.  Extension to SEARCH and SORT commands

   If the server that support the NOTIFY extension also supports
   CONTEXT=SEARCH and/or CONTEXT=SORT as defined in [CONTEXT], the
   UPDATE return option is extended so that a client can request that
   FETCH attributes be returned when a new message is added to the



King, et al.               Expires August 2008                 [Page 12]


Internet-draft                                             February 2008


   context result set.

   For example:
       C: a00 SEARCH RETURN (COUNT UPDATE (UID BODY[HEADER.FIELDS (TO
          FROM
              SUBJECT)])) FROM "boss" S: * ESEARCH (TAG "a00") (COUNT
          17) S: a00 OK [...a new message is delivered...]  S: * EXISTS
          93 S: * ESEARCH (TAG "a00") ADDTO (0 93) S: * 93 FETCH (UID
          127001 BODY[HEADER.FIELDS (FROM TO SUBJECT)] {76} S: Subject:
          Re: good morning S: From: myboss@example.org S: To:
          bob@example.org S: S: )

   Note that the EXISTS response MUST precede the ESEARCH response, and
   the FETCH response MUST follow the ESEARCH response.

   No untagged FETCH response SHOULD be returned if a message becomes a
   member of UPDATE SEARCH due to flag or annotation changes.


8.  Formal Syntax

   The following syntax specification uses the Augmented Backus-Naur
   Form (ABNF) notation as specified in [RFC5234]. [RFC3501] defines the
   non-terminals "capability", "command-auth", "mailbox", "mailbox-
   data", "resp-text-code" and "search-key". The "modifier-update" non-
   terminal is defined in [CONTEXT].

   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.

       capability      =/ "X-DRAFT-W03-NOTIFY"
                       ;; [[Note to RFC Editor: change the capability
                       ;; name before publication]]

       command-auth    =/ notify

       notify          = "NOTIFY" SP
                       (notify-set / notify-none)

       notify-set      = "SET" [status-indicator] SP event-groups
                       ; Replace registered notification events
                       ; with the specified list of events [[Alexey:
                       what about "most specific" event overriding a
                       pattern?]]

       notify-none     = "NONE"



King, et al.               Expires August 2008                 [Page 13]


Internet-draft                                             February 2008


                       ; Cancel all registered notification
                       ; events. The client is not interested
                       ; in receiving any events.

       status-indicator = SP "STATUS"

       one-or-more-mailbox = mailbox / many-mailboxes

       many-mailboxes = "(" mailbox *(SP mailbox) ")"

       event-groups    = event-group *(SP event-group)

       event-group     = "(" filter-mailboxes SP events ")"

       filter-mailboxes = "selected" / "inboxes" / "personal" /
                       "subscribed" /
                       ( "subtree" SP one-or-more-mailbox ) /
                       ( "mailboxes" SP one-or-more-mailbox )

       events          = ( "(" event *(SP event) ")" ) / "NONE"
                       ;; As in [MSGEVENT].
                       ;; "NONE" means that the client does not wish
                       ;; to receive any events for the specified
                       ;; mailboxes.

       event           = message-event
                       / mailbox-event / user-event / event-ext

       message-match-criteria = "(" search-key ")"

       message-event   = ( "MessageNew" [SP
                           "(" fetch-att *(SP fetch-att) ")" ] )
                       SP "MessageExpunge"
                       / "FlagChange" SP message-match-criteria
                       / "AnnotationChange" SP message-match-criteria
                       ;; "MessageNew" includes "MessageAppend" from
                       ;; [MSGEVENT]. "FlagChange" is any of
                       ;; "MessageRead", "MessageTrash", "FlagsSet",
                       ;; "FlagsClear" [MSGEVENT]. "MessageExpunge"
                       ;; includes "MessageExpire" [MSGEVENT].

       mailbox-event   = "MailboxName" /
                       "SubscriptionChange" / "MailboxMetadataChange"
                       ; "SubscriptionChange" includes
                       ; MailboxSubscribe and MailboxUnSubscribe.
                       ; "MailboxName" includes MailboxCreate,
                       ; "MailboxDelete" and "MailboxRename".




King, et al.               Expires August 2008                 [Page 14]


Internet-draft                                             February 2008


       user-event      = "ServerMetadataChange"

       event-ext       = atom
                       ;; For future extensions

       oldname-extended-item =  "OLDNAME" SP "(" mailbox ")"
                       ;; Extended data item (mbox-list-extended-item)
                       ;; returned in a LIST response when a mailbox is
                       ;; renamed.
                       ;; Note 1: the OLDNAME tag can be returned
                       ;; with and without surrounding quotes, as per
                       ;; mbox-list-extended-item-tag production.

       resp-text-code  =/ "NOTIFICATIONOVERFLOW" /
                       unsupported-events-code

       message-event-name   = "MessageNew" /
                       / "MessageExpunge" / "FlagChange" /
                       "AnnotationChange"

       event-name = message-event-name / mailbox-event /
                       user-event

       unsupported-events-code = "BADEVENT"
                       SP "(" event-name *(SP event-name) ")"

       modifier-update = "UPDATE"
                       [ "(" fetch-att *(SP fetch-att) ")" ]


9.  Security considerations

   It is very easy for a client to deny itself service using NOTIFY:
   Asking for all events on all mailboxes may work on a small server,
   but with a big server can swamp the client's network connection or
   processing capability. In the worst case, the server's processing
   could also degrade the service it offers to other clients.

   Server authors should be aware that if a client issues requests and
   does not listen to the resulting responses, the TCP window can easily
   fill up, and a careless server might block. This problem exists in
   plain IMAP, however this extension magnifies the problem.

   This extensions makes it possible to retrieve messages immediately
   when they are added to the mailbox. This makes it wholly impractical
   to delete sensitive messages using programs like imapfilter. Using
   [SIEVE] or similar is much better.




King, et al.               Expires August 2008                 [Page 15]


Internet-draft                                             February 2008


10.  IANA considerations

   The IANA is requested to add NOTIFY to the list of IMAP extensions,
   http://www.iana.org/assignments/imap4-capabilities.

   10.1.  Initial LIST-EXTENDED extended data item registrations

   It is requested that the following entry be added to the LIST-
   EXTENDED extended data item registry [LISTEXT]:

   To: iana@iana.org Subject: Registration of OLDNAME LIST-EXTENDED
   extended data item

   LIST-EXTENDED extended data item tag: OLDNAME

   LIST-EXTENDED extended data item description: The OLDNAME extended
   data item describes the old mailbox name for the mailbox identified
   by the LIST response.

   Which LIST-EXTENDED option(s) (and their types) causes this extended
   data item to be returned (if any): none

   Published specification : RFC XXXX, Section 5.4.

   Security considerations: none

   Intended usage: COMMON

   Person and email address to contact for further information:
     Alexey Melnikov <Alexey.Melnikov@isode.com>

   Owner/Change controller: iesg@ietf.org


11. Acknowedgements

   The authors gratefully acknowledge the help of Peter Coates, Dave
   Cridland, Mark Crispin, Cyrus Daboo, Abhijit Menon-Sen and Eric
   Burger.  In particular, Peter Coates contributed lots of text and
   useful suggestions to this document.

   Various examples are copied from other RFCs.

   This document builds on one published and two unpublished drafts by
   the same authors.


12. Normative References



King, et al.               Expires August 2008                 [Page 16]


Internet-draft                                             February 2008


   [RFC2119]  Bradner, "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, Harvard University, March
              1997.

   [RFC2177]  Leiba, "IMAP4 IDLE Command", RFC 2177, IBM, June 1997.

   [RFC3501]  Crispin, "Internet Message Access Protocol - Version
              4rev1", RFC 3501, University of Washington, June 2003.

   [RFC5234]  Crocker, Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 5234, Brandenburg
              Internetworking, THUS plc, January 2008.

   [RFC4314]  Melnikov, "IMAP4 Access Control List (ACL) Extension", RFC
              4314, December 2005.

   [RFC4466]  Melnikov, Daboo, "Collected Extensions to IMAP4 ABNF", RFC
              4466, Isode Ltd., April 2006.

   [RFC4551]  Melnikov, Hole, "IMAP Extension for Conditional STORE
              Operation or Quick Flag Changes Resynchronization", RFC
              4551, Isode Ltd., June 2006.

   [LISTEXT]  Leiba, Melnikov, "IMAP4 List Command Extensions", draft-
              ietf-imapext-list-extensions-18 (work in progress), IBM,
              September 2006.

   [METADATA] Daboo, "IMAP METADATA Extension", draft-daboo-imap-
              annotatemore-12 (work in progress), Apple Computer, Inc.,
              December 2007.

   [MSGEVENT] Newman, C. and R. Gellens, "Internet Message Store
              Events", draft-ietf-lemonade-msgevent-05.txt (work in
              progress), Sun, January 2008.

   [CONTEXT] Cridland, D. and C. King, "Contexts for IMAP4", work in
              progress, draft-cridland-imap-context-03.txt, Isode, June
              2007.


13. Informative References

   [SIEVE]   Guenther, P. and T. Showalter, "Sieve: A Mail Filtering
              Language", RFC 5228, January 2008.

   [QRESYNC]  Melnikov, Cridland, Wilson, "IMAP4 Extensions for Quick
              Mailbox Resynchronization", draft-ietf-lemonade-reconnect-
              client-06.txt (work in progress), September 2007.



King, et al.               Expires August 2008                 [Page 17]


Internet-draft                                             February 2008


   [EMAIL-ARCH] Crocker, "Internet Mail Architecture", draft-crocker-
              email-arch-10 (work in progress), February 2008.


14. Authors' Addresses

   Curtis King
   Isode Ltd
   5 Castle Business Village
   36 Station Road
   Hampton, Middlesex  TW12 2BX
   UK

   Email: Curtis.King@isode.com


   Alexey Melnikov
   Isode Ltd
   5 Castle Business Village
   36 Station Road
   Hampton, Middlesex  TW12 2BX
   UK

   Email: Alexey.Melnikov@isode.com


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

   Email: arnt@oryx.com


















King, et al.               Expires August 2008                 [Page 18]


Internet-draft                                             February 2008


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.


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).  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, THE IETF TRUST 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.







King, et al.               Expires August 2008                 [Page 19]