Network Working Group                                        Curtis King
Internet-Draft                                           Alexey Melnikov
Intended Status: Proposed Standard                            Isode Ltd.
                                                        Arnt Gulbrandsen
                                                  Oryx Mail Systems GmbH
                                                           November 2006


                       The IMAP NOTIFY Extension
                  draft-gulbrandsen-imap-notify-03.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 September 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 September 2007                 [Page 1]

Internet-draft                                                March 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. The five characters [...] means that
    something has been elided.


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.
    Depending on client preference, the extension takes effect either
    during IDLE or always.

    IMAP servers which support this extension advertise the X-DRAFT-
    I03-NOTIFY extension.

    Comments regarding this draft may be sent either to the
    lemonade@ietf.org mailing list or to the authors.


3.  The NOTIFY Command

    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.

    Until the NOTIFY command is used for the first time, the server
    notifies the client about the following events types on the selected
    mailbox (see section 5 for definitions): NewMessage, ExpungeMessage,



King, et al.             Expires September 2007                 [Page 2]

Internet-draft                                                March 2007


    FlagChange and (if [ANNOTATE] is supported and enabled)
    AnnotationChange. It does not notify the client about any events on
    other mailboxes.

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

    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.

    Open issue: At present the client can send a wildcard or a list of
    mailboxes. Should we drop the wildcard? Would that nudge the client
    developers to use short lists by default?

    Open issue: Lingyan Wu suggests that for each mailbox where the
    client requests NewMessage events, the server should send a STATUS
    (UIDNEXT) when the client sends NOTIFY. Arnt's intuition says "That
    is either a good idea or a bad idea, but I don't know which".


4.  The IDLE Command

    If IDLE (as well as this extension) is supported, the IDLE command
    is extended to have the same arguments as NOTIFY, and the server
    sends notifications about the specified events while the client
    remains in idle mode.

    If the client uses IDLE without arguments, the server notifies the
    client about the same events as before IDLE. If the client uses IDLE
    with arguments, the supplied arguments override the previous
    setting, even after the end of IDLE processing.

    Open issue: What's the benefit in extending IDLE this way? If noone
    suggests concrete value, we drop it in the next version of the
    draft.


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.



King, et al.             Expires September 2007                 [Page 3]

Internet-draft                                                March 2007


    The server MAY omit notifying the client if the event is caused by
    this session. For example, if the client issues SETACL and has
    requested AdminMailbox notation, the server MAY NOT notify the
    client of the AdminMailbox change.

    Open issue: Should the two MAYs in the previous paragraph be
    upgraded to SHOULD or MUST?


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.

    If the change happens in another mailbox, then the response depends
    on whether CONDSTORE supported and enabled. If so, the server sends
    a STATUS (HIGHESTMODSEQ) response. If not, the server does not
    notify the client.

    FlagChange covers the ReadMessages, TrashMessages, SetFlags and
    ClearFlags events in [MSGEVENT].


5.2. NewMessage

    This covers both NewMessage and AppendMessage in [MSGEVENT].

    If the new/appended message is in the selected mailbox, the server
    notifies the client by sending an unsolicited FETCH response
    containing the information requested by the client.

    If the new/appended message is in another mailbox, the server sends
    an unsolicited STATUS (EXISTS) response for the relevant mailbox. If
    CONDSTORE (defined in [RFC4551]) is supported and enabled,
    HIGHESTMODSEQ should 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.


5.3. ExpungeMessage

    If the expunged message(s) is/are in the selected mailbox, the
    server notifies the client using EXPUNGE (or EXPUNGED, if [QRESYNC]
    is supported and enabled).




King, et al.             Expires September 2007                 [Page 4]

Internet-draft                                                March 2007


    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 supported and enabled,
    HIGHESTMODSEQ should be included in the STATUS response.


5.4. OverQuota, UnderQuota and QuotaChange

    If the client has permission to perform GETQUOTA, the server sends
    an unsolicited QUOTA response containing the new quotas. If the
    server does not support the QUOTA extension, it MUST ignore request
    for these three events and never send any notifications for them.


5.5. CreateMailbox, DeleteMailbox, RenameMailbox

    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.

    For CreateMailbox and DeleteMailbox, the server usually sends a
    single LIST response. For RenameMailbox, it usually sends two.


5.6. 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 is
    included.


5.7. MailboxMetadataChange

    If METADATA (defined in [METADATA]) is supported and enabled, 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.

    If METADATA is not supported or not enabled, the server does not
    notify the client.

    Open Issue: What does it mean for METADATA to be enabled?







King, et al.             Expires September 2007                 [Page 5]

Internet-draft                                                March 2007


5.8. AdminMailbox

    If the user has the right to perform GETACL 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.


6.  Interaction with the ID Extension

    The ID extension defined by [RFC2971] defines a way for the client
    and server to identify themselves. This is meant to be for debugging
    and statistics purposes. The client can send any number of
    field/value pairs describing itself, and the server responds
    similarly.

    The ID field "instance" is hereby defined as a string containing at
    least 64 bits of entropy, which is specific to the client instance.
    If both client and server support ID, and the client opens two or
    more connections to the server and wants notifications on both, then
    it SHOULD send an ID command with a specified instance value.

    If the server supports both ID and NOTIFY, it MUST assume that all
    IMAP connections sharing instance and authentication-id represent
    the same client. If the server would notify a client of an event via
    two or more connections, it SHOULD notify the client via only one.

    In the case of NewMessage it is best to send the notification on a
    connection where the relevant mailbox is selected, if possible.


7.  Formal Syntax

    The following syntax specification uses the Augmented Backus-Naur
    Form (ABNF) notation as specified in RFC 4234. RFC 3501 defines the
    non-terminals "capability", "command-auth" and "search-key".
    [RFC2177] defines the non-terminal "idle". [LISTEXT] defines the
    non-terminal "mbox-or-pat".

    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.




King, et al.             Expires September 2007                 [Page 6]

Internet-draft                                                March 2007


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

        command-auth    =/ notify

        notify          = "NOTIFY" SP event-groups

        idle            =/ "IDLE" SP "(FILTER" event-groups ")" CRLF
                        "DONE"
                        ;; Only if IDLE is also advertised

        event-groups    = "(" 1*event-group ")"

        event-group     = filter-mailboxes SP events

        filter-mailboxes =  mbox-or-pat

        events          = "(" event *(SP event) ")" / "*"
                        ;; "*" is used to denote all events.

        event           = message-event SP "(" search-key ")"
                        / mailbox-event / user-event / event-ext
                        ;; As in draft-ietf-lemonade-msgevent-XX.txt

        message-event   = ( "NewMessage" SP
                            "(" fetch-att *(SP fetch-att) ")" )
                        / "ExpungeMessage" / "OverQuota" / "UnderQuota"
                        / "FlagChange" / "AnnotationChange"
                        ;; "NewMessage" includes "AppendMessage".
                        ;; "FlagChange" is any of "ReadMessages",
                        ;; "TrashMessages", "SetFlags", "ClearFlags".

        mailbox-event   = "CreateMailbox" / "DeleteMailbox" /
                        "RenameMailbox" /
                        "SubscriptionChange" / "MailboxMetadataChange"
                        / "QuotaChange" / "AdminMailbox"
                        ;; Should "{Create/Delete/Rename}Mailbox" be
                        ;; replaced with a single event?
                        ;; Is "AdminMailbox" (ACL change) needed?
                        ;; Add "LocationChange" - e.g. mailbox
                        ;; migration between servers?

        user-event      = "OverQuota" / "UnderQuota"

        event-ext       = atom
                        ;; For future extensions




King, et al.             Expires September 2007                 [Page 7]

Internet-draft                                                March 2007


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.

    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.


10. Acknowedgements

    The authors gratefully acknowledge the help of Dave Cridland, Mark
    Crispin, Cyrus Daboo and Abhijit Menon-Sen.

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


11. Normative References

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

    [RFC2971]  Showalter, "IMAP4 ID extension", RFC 2971, Mirapoint,
               October 2000.

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




King, et al.             Expires September 2007                 [Page 8]

Internet-draft                                                March 2007


    [RFC4234]  Crocker, Overell, "Augmented BNF for Syntax
               Specifications: ABNF", RFC 4234, Brandenburg
               Internetworking, Demon Internet Ltd, October 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-00.txt (work in progress), Sun, June
               2006.


12. Informative References

    [SIEVE]    Showalter, "Sieve: A Mail Filtering Language", RFC 3028,
               Mirapoint Inc, January 2001.

    [QRESYNC]  Melnikov, Cridland, Wilson, "IMAP4 Extensions for Quick
               Mailbox Resynchronization", draft-ietf-lemonade-
               reconnect-client-02.txt (work in progress), February
               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



King, et al.             Expires September 2007                 [Page 9]

Internet-draft                                                March 2007


    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


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



King, et al.             Expires September 2007                [Page 10]

Internet-draft                                                March 2007


    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 September 2007                [Page 11]