[lemonade] suggested changes to NOTIFY

In Vancouver I said I would write up my proposal for changes to NOTIFY.  I
have marked up the -07 draft with my changes.  Deletions I have marked thus,
and additions thus.  I have not made any efforts to correct section numbers.

Peter

Network Working Group                                        Curtis King

Internet-Draft                                           Alexey Melnikov

Intended Status: Proposed Standard                            Isode Ltd.

                                                        Arnt Gulbrandsen

                                                  Oryx Mail Systems GmbH

                                                            July 9, 2007

                       The IMAP NOTIFY Extension

                  draft-gulbrandsen-imap-notify-07.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 November 2007.

Copyright Notice

    Copyright (C) The IETF Trust (2007).

Abstract

    This document defines an IMAP extension which allows a client to

    request specific kinds of unsolicited notifications, such as

    messages being added to or deleted from mailboxes.

King, et al.              Expires January 2008                FF[Page 1]

Internet-draft                                                 July 2007

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 [RFC4234] as extended by [RFC3501] and

    [RFC4466].

    Example lines prefaced by "C:" are sent by the client and ones

    prefaced by "S:" by the server. "[...]" means elision.

2.  Overview

    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.

    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.

    IMAP servers which support this extension advertise the X-DRAFT-

    I07-NOTIFY extension.

    Comments regarding this draft may be sent either to the

    lemonade@ietf.org mailing list or to the authors.

3.  Rationale and Principals of Operation

    Without the Notify command, and IMAP server will only send information

    About changes of state to the client in one of three places:

    -  as the result of a client command (eg *FETCH responses to a FETCH

       or STORE command),

    -  unsolicited responses sent just before the end of a command (eg 

       * EXISTS or * EXPUNGED responses return just before a TAGGED

       response as the result of changes outside the current context, 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 

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

    yhis draft 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 context.

3.  The NOTIFY Command

    Arguments: "ADD" or "SET"

               Mailboxes to be watched

               Events about which to notify the client

    Or

    Arguments: "NONE"

    Responses: Possibly untagged STATUS responses (for ADD/SET)

    Result: OK The server will notify the client as requested.

            NO NOTIFY too complex or expensive, lack of permissions.

           BAD Command unknown, invalid, unsupported or unknown

               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 for the selected mailbox or for specific mailboxes.

    The NOTIFY command has 3 forms. The NOTIFY NONE specifies that the

    client is not interested in any kind of event happening on the

    server. The NOTIFY ADD prepends one or more events to the list of

    events which are interesting to the client. The NOTIFY SET replaces

    the current list of interesting events with a new list of events.

    (Note that NOTIFY SET <events> is effectively the same as NOTIFY

    NONE followed by NOTIFY ADD <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 and (if

    [ANNOTATE] is being used) AnnotationChange. It does not notify the

    client about any events on other mailboxes.

    The effect of NOTIFY lasts until the next NOTIFY command, or until

    the IMAP connection is closed.

    The NOTIFY command can request notifications of changes to the 

    selected mailbox whatever it may be at the time the notifications are

    being generated, specified by the SELECTED mailbox selector in the

    NOTIFY COMMAND.  It can also request notifications on other mailboxes

    by name or by a limited pattern match.  The notifications returned for

    the currently selected mailbox will be those specified by the SELECTED

    mailbox specifier, even if the selected mailbox also appears by name in

    the command.

    The information returned for message level changes to the SELECTED

    mailbox will be in the form of untagged FETCH, EXISTS, RECENT, EXPUNGE

    or VANISHED responses.  The information returned for message level

    changes to other mailboxes will be in the form a untagged STATUS 

    responses.

    If the NOTIFY command enables MessageNew, MessageExpunge,

    AnnotationChange or FlagChange notification for a mailbox other than 

    SELECTED, 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.

    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 resources and network traffic,

    and the client may have to pay for every byte.

    For each mailbox specified, the server verifies that the client has

    access using the following test:

    - If the name does not refer to a mailbox, the server MUST ignore

      it.

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

      server MUST ignore it. For a server that implements [RFC4314] this

      means that the client that doesn't have the 'l' (lookup) right for

King, et al.              Expires January 2008                FF[Page 3]

Internet-draft                                                 July 2007

      the name, it MUST ignore it.

    - If the name refers to a mailbox for which the client has 'l', but

      misses another required right, the server MUST respond with a

      tagged NO.  [[Alexey: I still think that ignoring such mailboxes

      would be better from security standpoint.]]

    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

    (e.g. QuotaExceed and the server does not advertise the QUOTA

    extension defined in [RFC2087]), the server MUST refuse the command

    with a tagged BAD response.

    Here's an example:

         S: * OK [CAPABILITY IMAP4REV1 NOTIFY]

         C: a login bob alice

         S: a OK Password matched

         C: b notify set (selected MessageNew (uid

            body.peek[header.fields (from to subject)]) (all)

            MessageExpunge) (subtree Lists MessageNew (uid) (all))

         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)

         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 add (mailboxes misc MessageNew (uid) (all))

King, et al.              Expires January 2008                FF[Page 4]

Internet-draft                                                 July 2007

         S: * STATUS misc (UIDVALIDITY 1 UIDNEXT 999)

                (This command enables notification on one mailbox and

                 otherwise changes nothing, so one STATUS response is

                 sent.)

         S: d OK done

4.  Interaction with the IDLE Command

    If IDLE (as well as this extension) is supported, the server should

    send MessageExpunge while processing IDLE, and otherwise send the

    same events as the client instructed using NOTIFY.

    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 NOTIFY 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 of 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

    requested MailboxCreate event that would cover the newly created

    mailbox, the server SHOULD NOT notify the client of the

    MailboxCreate change.

    All event types require the 'l' and 'r' rights (see [RFC4314]) on

    all observed mailboxes. AdminMailbox and the quota-related event

    types additionally require the 'a' right.  Servers that don't

    implement [RFC4314] should map the above rights to their access

    control model.

    If the client instructs the server to not send MessageNew or

    MessageExpunge for the SELECTED mailbox, the server MUST send EXISTS

    and EXPUNGE responses as required by IMAP (see RFC3501 section 7).

    In other words, MessageNew instructs the server to notify the client

    immediately, and the lack of MessageNew instructs the server to

    notify the client during execution of the next command.

    MessageExpunge is similar.

King, et al.              Expires January 2008                FF[Page 5]

Internet-draft                                                 July 2007

5.1. FlagChange and AnnotationChange

    If the flag/annotation change happens in the SELECTED mailbox, the

    server notifies 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.

    In this case, the FETCH response will 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 not, 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

    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 will not be generated for 

    a new message created in this context, for instance as the result of 

    an APPEND or COPY command to the selected mailbox. 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 will precede the ESEARCH response.  Both the NOTIFY command and

    the SEARCH and SORT commands can specify attributes to be returned for

    new messages.  These attributes MAY be combined into a single FETCH

    response.  The server SHOULD avoid sending duplicate data.  The FETCH

    response(s) SHOULD 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

King, et al.              Expires January 2008                FF[Page 6]

Internet-draft                                                 July 2007

    \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. Whatever FETCH

    attributes are specified, the server SHOULD NOT set the \seen flag.

    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 '*'.

    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 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 an MSN

    can change at any time, so the client cannot use MSNs in commands

    any more. For example, such a client cannot use FETCH (it must only

    use UID FETCH). The meaning of '*' can also change when messages are

    added or expunged.

    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. QuotaExceed, QuotaWithin and QuotaChange

    [[Alexey: I liked the following version more: If the client has

    permission to perform GETQUOTA (defined in [RFC2087]), the server

King, et al.              Expires January 2008                FF[Page 7]

Internet-draft                                                 July 2007

    sends an unsolicited QUOTA response containing the new quotas.  ]]

    The server sends an unsolicited QUOTA response containing the new

    quotas. The server also sends an unsolicited QUOTAROOT response, so

    that the client can correlate the affected mailbox to the quota

    root.

    These notifications are sent if the client has requested

    notifications for at least one affected mailbox.

    Example:

        S: * QUOTAROOT INBOX ""

        S: * QUOTA "" (STORAGE 10 512)

    In this example the quota root named "" (see [RFC2087] for the

    definition of quota root) governs the mailbox INBOX.  Note that the

    server may return the QUOTAROOT and the QUOTA response in any order.

5.5. MailboxCreate and MailboxDelete

    The server notifies the client by sending an unsolicited LIST

    responses for each affected mailbox name. If the mailbox name does

    not refer to a mailbox after the event, the \Nonexistent flag MUST

    be included.

    These notifications are sent if the client has requested

    notifications for at least one affected mailbox. In the case of

    MailboxCreate, the mailbox itself and its parent are considered to

    be affected. In the case of MailboxDelete, all deleted mailboxes and

    their parent(s) are considered to be affected.

    Example of a newly created mailbox:

        S: * LIST () "/" "NewMailbox"

    And a deleted mailbox:

        S: * LIST (\NoSelect) "/" "INBOX.DeletedMailbox"

5.6. MailboxRename

    For each selectable 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

    MailboxRename events are sent for children in this case.  When INBOX

    is renamed, a new INBOX is assumed to be created.  No MailboxCreate

    event must be sent for INBOX in this case.

    Example:

King, et al.              Expires January 2008                FF[Page 8]

Internet-draft                                                 July 2007

        S: * LIST () "/" "NewMailbox" ("OLDNAME" ("OldMailbox"))

5.7. 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.8. MailboxMetadataChange

    The server sends an unsolicited LIST response including METADATA. If

    possible, only the changed metadata should be included, but if

    necessary, all metadata must be included.

    Example:

        S: * LIST "/" "INBOX" (METADATA (/comment (value.priv "My

           comment")))

5.9. AdminMailbox

    If the user has the right to perform GETACL (see [RFC4314]) after

    the event, the server notifies the client by sending an unsolicited

    ACL response with the mailbox' new rights.

    If the user loses the right to perform GETACL as a result of this

    event, the server MAY also send the ACL response.

    In all other cases, the server does not notify the client.

    Example:

        S: * ACL INBOX Fred rwipslxcetda David lrswideta

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

King, et al.              Expires January 2008                FF[Page 9]

Internet-draft                                                 July 2007

    Example:

        S: * OK [NOTIFICATIONOVERFLOW] CPU overloaded, sorry

5.11. ACL Changes

    Even if NOTIFY succeeds, it is still possible to lose 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.

    [[Open issue: This similar with the GETACL treatment in 5.9, which

    noone has complained about, but is it optimal?]]

6.  Mailbox Specification.

    Mailboxes to be monitored can be specified in several different

    ways.

    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 (uid flags) 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

    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

King, et al.              Expires January 2008               FF[Page 10]

Internet-draft                                                 July 2007

    [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 list MUST be reevaluated.

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.

    [[Open Issue: Making this "all selectable mailboxes" makes it easy

    to implement this well. The pattern can be evaluated at NOTIFY time

    and notification information affixed to the mailboxes in RAM. Fine.

    But what about "notify me if any mailboxes are created whose name

    contains the letters xxx"? Not useful IMO...? (writes arnt)]]

6.6 Mailboxes

    Mailboxes is followed by a mailbox name or list of mailbox names.

    Note that the LIST wildcard characters ('*' and '%') are not treated

    specially in mailbox names.

8.  Search and Sort commands

    If the server supports CONTEXT=SEARCH or CONTEXT=SORT as defined in

    [CONTEXT], the UPDATE return option is extended to a client can 

    request that FETCH attributes be returned when a new message is added

    to a result set.

    For example:

    C: a00 SEARCH RETURN (COUNT UPDATE (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 SHOULD follow the ESEARCH response

7.  Formal Syntax

    The following syntax specification uses the Augmented Backus-Naur

    Form (ABNF) notation as specified in [RFC4234]. [RFC3501] defines

    the non-terminals "capability", "command-auth", "mailbox", "mailbox-

    data", "resp-text-code" and "search-key".

    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-I07-NOTIFY"

                        ;; [[Note to RFC Editor: change the capability

King, et al.              Expires January 2008               FF[Page 11]

Internet-draft                                                 July 2007

                        ;; name before publication]]

        command-auth    =/ notify

        notify          = "NOTIFY" SP

                        (notify-add / notify-set / notify-none)

        notify-add      = "ADD" SP event-groups

                        ; Add (prepend) registered notification

                        ; events to the list of notification

                        ; events. Newer events override older

                        ; events.

                        [[Alexey: what about "most specific" event

                        overriding a pattern?]]

        notify-set      = "SET" SP event-groups

                        ; Replace registered notification events

                        ; with the specified list of events

        notify-none     = "NONE"

                        ; Cancel all registered notification

                        ; events. The client is not interested

                        ; in receiving any events.

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

King, et al.              Expires January 2008               FF[Page 12]

Internet-draft                                                 July 2007

        message-event   = ( "MessageNew" [ SP

                            "(" fetch-att *(SP fetch-att) ")"

                          SP message-match-criteria ] )

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

                        ;; the fett-att list may only be present for the

                        ;; SELECTED mailbox filter

        mailbox-event   = "MailboxCreate" / "MailboxDelete" /

                        "MailboxRename" /

                        "SubscriptionChange" / "MailboxMetadataChange"

                        / "QuotaChange" / "AdminMailbox"

                        ; "SubscriptionChange" includes

                        ; MailboxSubscribe and MailboxUnSubscribe

        user-event      = "QuotaExceed" / "QuotaWithin"

        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"

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

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

King, et al.              Expires January 2008               FF[Page 13]

Internet-draft                                                 July 2007

    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.

9.  IANA considerations

    The IANA is requested to add NOTIFY to the list of IMAP extensions,

    http://www.iana.org/assignments/imap4-capabilities.

    9.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.6.

    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

10. Acknowedgements

    The authors gratefully acknowledge the help of Peter Coates, Dave

    Cridland, Mark Crispin, Cyrus Daboo and Abhijit Menon-Sen. Various

    example lines are copied from other RFCs.

    This document builds on one published and two unpublished drafts by

    the same authors.

King, et al.              Expires January 2008               FF[Page 14]

Internet-draft                                                 July 2007

11. Normative References

    [RFC2087]  Myers, "IMAP4 QUOTA extension", RFC 2087, January 1997.

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

    [RFC4234]  Crocker, Overell, "Augmented BNF for Syntax

               Specifications: ABNF", RFC 4234, Brandenburg

               Internetworking, Demon Internet Ltd, October 2005.

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

    [ANNOTATE] Gellens, Daboo, "IMAP ANNOTATE Extension", draft-ietf-

               imapext-annotate-16 (work in progress).

    [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-11 (work in progress), Apple Computer, Inc.,

               February 2007.

    [MSGEVENT] Newman, "Internet Message Store Events", draft-ietf-

               lemonade-msgevent-03.txt (work in progress), Sun, July

               2007.

12. Informative References

    [SIEVE]    Showalter, "Sieve: A Mail Filtering Language", RFC 3028,

               Mirapoint Inc, January 2001.

King, et al.              Expires January 2008               FF[Page 15]

Internet-draft                                                 July 2007

    [QRESYNC]  Melnikov, Cridland, Wilson, "IMAP4 Extensions for Quick

               Mailbox Resynchronization", draft-ietf-lemonade-

               reconnect-client-05.txt (work in progress), February

               2007.

    [EMAIL-ARCH] Crocker, "Internet Mail Architecture", draft-crocker-

               email-arch-09 (work in progress), March 2007.

13. 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 January 2008               FF[Page 16]

Internet-draft                                                 July 2007

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 (2007).  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 January 2008               FF[Page 17]