wdiff rfc5465.original rfc5465.txt

Network Working Group Alexey Melnikov
Internet-Draft Isode Ltd.
Intended Status: Proposed Standard Arnt A. Gulbrandsen
Request for Comments: 5465 Oryx Mail Systems GmbH
Curtis
Updates: 5267 C. King
Category: Standards Track A. Melnikov
Isode Ltd.
August 18, 2008
February 2009

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

Status of this 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

This document specifies an Internet standards track protocol for the
Internet Engineering
Task Force (IETF), its areas, community, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid requests discussion and suggestions for a maximum
improvements. Please refer to the current edition of six
months the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and may be updated, replaced, or obsoleted by other documents
at any time. It status of this protocol. Distribution of this memo is inappropriate to use Internet-Drafts unlimited.

Copyright (c) 2009 IETF Trust and the persons identified as
reference material or the
document authors. All rights reserved.

This document is subject to cite them other than as "work BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (http://trustee.ietf.org/
license-info) in progress."

The list effect on the date of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. The list publication of Internet-
Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft expires in February 2009. this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.

Abstract

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

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

Internet-draft August 2008

Table of Contents

1. Overview and Rationale ..........................................3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
2. Overview and rationale . . . . . . . . . . . . . . . . . . . . 3 ...............................4
3. The NOTIFY extension . . . . . . . . . . . . . . . . . . . . . 4 Extension ............................................4
3.1. The NOTIFY Command . . . . . . . . . . . . . . . . . . . . 4 .........................................4
4. Interaction with the IDLE Command . . . . . . . . . . . . . . 8 ...............................8
5. Event Types . . . . . . . . . . . . . . . . . . . . . . . . . 8 .....................................................8
5.1. FlagChange and AnnotationChange . . . . . . . . . . . . . . 9 ............................9
5.2. MessageNew . . . . . . . . . . . . . . . . . . . . . . . . 9 .................................................9
5.3. MessageExpunge . . . . . . . . . . . . . . . . . . . . . . 11 ............................................10
5.4. MailboxName . . . . . . . . . . . . . . . . . . . . . . . . 11 ...............................................11
5.5. SubscriptionChange . . . . . . . . . . . . . . . . . . . . 12 ........................................12
5.6. MailboxMetadataChange . . . . . . . . . . . . . . . . . . . 12 .....................................12
5.7. ServerMetadataChange . . . . . . . . . . . . . . . . . . . 13 ......................................13
5.8. Notification Overflow . . . . . . . . . . . . . . . . . . . 13 .....................................13
5.9. ACL (Access Control List) Changes . . . . . . . . . . . . . . . . . . . . . . . . 13 .........................13
6. Mailbox Specification . . . . . . . . . . . . . . . . . . . . 14 ..........................................14
6.1. Mailbox specifiers affecting Specifiers Affecting the currently selected mailbox 14 Currently
Selected Mailbox ..........................................14
6.2. Personal . . . . . . . . . . . . . . . . . . . . . . . . . 15 ..................................................15
6.3. Inboxes . . . . . . . . . . . . . . . . . . . . . . . . . . 15 ...................................................15
6.4. Subscribed . . . . . . . . . . . . . . . . . . . . . . . . 15 ................................................15
6.5. Subtree . . . . . . . . . . . . . . . . . . . . . . . . . . 15 ...................................................15
6.6. Mailboxes . . . . . . . . . . . . . . . . . . . . . . . . . 16 .................................................16
7. Extension to SEARCH and SORT commands . . . . . . . . . . . . 16 Commands ..........................16
8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 16 ..................................................16
9. Security considerations . . . . . . . . . . . . . . . . . . . 19 Considerations ........................................19
10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 19 Considerations ...........................................19
10.1. Initial LIST-EXTENDED extended data item registrations . 19 Extended Data Item Registrations ...19
11. Acknowedgements . . . . . . . . . . . . . . . . . . . . . . . 20 Acknowledgements ..............................................20
12. Normative References . . . . . . . . . . . . . . . . . . . . . 20 ..........................................20
13. Informative References . . . . . . . . . . . . . . . . . . . . 21
14. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 23

Internet-draft August 2008 ........................................21

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] Overview and
[RFC4466]. Rationale

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 IDLE command (defined in [RFC2177]) provides a way for the client
to go into a mode where the IMAP server pushes it 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 that
they are interested in, while servers know that they don't need to go into
to the effort of generating certain types of untagged responses.

Without the NOTIFY command defined in this document, an 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. (e.g., FETCH responses to a
FETCH or STORE command),
- as unsolicited responses sent just before the end of a command
(e.g.
(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. commands. The NOTIFY command also
allows for the client to extend what information is sent unsolicited
about the selected mailbox, mailbox and to request some update information

Internet-draft August 2008 to
be sent regarding other mailboxes.

The interaction between IDLE and NOTIFY commands is described in
Section 4.

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 a passive recipient of events and new mail, mail
and to 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] need, [RFC5267] 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.

[[RFC-Editor: Please delete the following before publication:
Comments regarding

2. Conventions Used in This Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this draft may
document are to be interpreted as described in [RFC2119].

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

Example lines prefaced by "C:" are sent either to by the
lemonade@ietf.org mailing list or to client and ones
prefaced by "S:", by the authors.]] server. "[...]" means elision.

3. The NOTIFY extension Extension

IMAP servers which that support this extension advertise the X-DRAFT-
W06-NOTIFY NOTIFY
capability. This extension adds the NOTIFY command as defined in
Section 5.1.

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

3.1. The NOTIFY Command

Arguments: "SET"
optional
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.

Internet-draft August 2008
NO - Unsupported notify NOTIFY event, NOTIFY too complex or
expensive, etc.
BAD - Command unknown, invalid, unsupported unsupported, or has
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)
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: mailbox (see section Section 5
for definitions): MessageNew, MessageExpunge, or 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,
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 currently selected mailbox (if
any), such as flag changes, changes and new or expunged messages. This is
equivalent to NOOP command being issued by the client just before
the Thus, a
successful NOTIFY SET command implies an implicit NOOP command.

The NOTIFY SET command can request notifications of message related message-related
changes to the selected mailbox, whatever it that may be at the time the
message notifications are being generated. This is done by
specifying either the SELECTED or the SELECTED-DELAYED mailbox
selector (see Section 6.1) in the NOTIFY SET command. If the
SELECTED/SELECTED-DELAYED mailbox selector is not specified in the
NOTIFY SET command, this means that the client doesn't want to
receive any <message-event>s for the currently selected mailbox.
This is the same as specifying SELECTED NONE.

The client can also request notifications on other mailboxes by name
or by a limited mailbox pattern match. Message related Message-related notifications
returned for the currently selected mailbox will be those specified
by the SELECTED/SELECTED-DELAYED mailbox specifier, even if the
selected mailbox also appears by name (or matches a pattern) in the
command. Non message related Non-message-related notifications are controlled by mailbox
specifiers other than SELECTED/SELECTED-
DELAYED. SELECTED/SELECTED-DELAYED.

If the NOTIFY command enables MessageNew, MessageExpunge,

Internet-draft August 2008

AnnotationChange
AnnotationChange, or FlagChange notification notifications for a mailbox other
than the currently selected 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 UIDNEXT, and
UIDVALIDITY. If MessageExpunge is enabled, the STATUS response MUST
contain MESSAGES. If either AnnotationChange or FlagChange are
included and the server also supports the CONDSTORE [RFC4551] and/or
QRESYNC [QRESYNC] extension, [RFC5162] extensions, 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 may reduce the client's battery life. Also Also, 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 that the client can't LIST, the
server MUST ignore it. For a server that implements [RFC4314] [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 disclosure of potentially confidential
information to clients which who don't have rights to know it.

- If the name refers to a mailbox which that the client can LIST (e.g. (e.g., it
has the 'l' right from [RFC4314]), but the client doesn't have
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.

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. (e.g., the client specified
an event for 'Subtree Bar/Foo', 'Bar/Foo' doesn't
exist exist, and LIST
returns \Noinferiors for the parent 'Bar').

If the notification would be prohibitively expensive for the server
(e.g.
(e.g., "notify me of all flag changes in all mailboxes"), the server

Internet-draft August 2008
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)
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. As the client already knows necessary
STATUS information for all mailboxes below the Lists mailbox
mailbox, and because "notify set status" would cause
STATUS responses for *all* mailboxes specified in the
NOTIFY command, including the ones for which the client
already knows STATUS information, the client issues an
explicit STATUS request for the mailbox to be added to
the watch list, followed by the NOTIFY SET without the
STATUS parameter.)
C: d STATUS misc (UIDVALIDITY UIDNEXT MESSAGES)
S: * STATUS misc (UIDVALIDITY 1 UIDNEXT 999)

Internet-draft August 2008
S: d STATUS completed
C: e notify set (selected MessageNew (uid
body.peek[header.fields (from to subject)]) MessageExpunge)
(subtree Lists MessageNew) (mailboxes misc MessageNew)
S: e OK done

4. Interaction with the IDLE Command

If IDLE [RFC2177] (as well as this extension) is supported, then
while processing any IDLE command, the server MUST send exactly 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 by using the NOTIFY command
instead of entering the IDLE mode.

A client that uses MSNs and '*' in commands can still use the NOTIFY
command if it specifies the SELECTED-DELAYED mailbox specifier in the
NOTIFY command.

5. Event Types

Only some of the events in [MSGEVENT] [RFC5423] 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 a 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 access-
control model.

If the FlagChange and/or AnnotationChange event is events are specified,
MessageNew and MessageExpunge MUST also be specified by the client. Otherwise
Otherwise, the server MUST respond with the tagged BAD response.

If one of MessageNew or MessageExpunge is specified, the then both events

Internet-draft August 2008
MUST be specified. Otherwise Otherwise, the server MUST respond with the
tagged BAD response.

The client can instruct the server not to send an event by omitting
the necessary event from the list of events specified in NOTIFY SET,
by using the NONE event specifier in the NOTIFY SET SET, or by using
NOTIFY NONE. In particular particular, NOTIFY SET ... NONE can be used as a
snapshot facility by clients.

5.1. FlagChange and AnnotationChange

If the flag and/or message 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], [RFC5267], an
ESEARCH ADDTO or ESEARCH REMOVEFROM will also be generated, if
appropriate. In this case, the FETCH response MUST precede the
ESEARCH response.

If the change happens in another mailbox, then the server responds
with a STATUS response. The exact content of the STATUS response
depends on various factors. If CONDSTORE [RFC4551] and/or QRESYNC
[QRESYNC] is
[RFC5162] are enabled by the client, then the server sends a STATUS
response that includes at least HIGHESTMODSEQ and UIDVALIDITY status
data items. If the number of messages with the \Seen flag changes,
the server MAY also include the UNSEEN data item in the STATUS
response. If CONDSTORE/QRESYNC is not enabled by the client and the
server choses chooses not to include the UNSEEN, UNSEEN data item, the server does
not notify the client. When this event is requested requested, the server MUST
notify the client about mailbox UIDVALIDITY changes. This is done by
sending a STATUS response that includes UIDVALIDITY.

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

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

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

5.2. MessageNew

Internet-draft August 2008

This covers both MessageNew and MessageAppend in [MSGEVENT]. [RFC5423].

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 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], [RFC5267], 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 the CONDSTORE extension [RFC4551] and/or the QRESYNC
extension [QRESYNC] [RFC5162] is enabled, 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 with
the SELECTED mailbox specifier, 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 mailbox, without CONDSTORE enabled:
S: * STATUS Lists/Lemonade (UIDNEXT 10002 MESSAGES 503)

Internet-draft August 2008

5.3. MessageExpunge

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

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

If the expunged message(s) is/are message or messages are in another mailbox, the
server sends an unsolicited STATUS (UIDNEXT MESSAGES) response for
the relevant mailbox. If the QRESYNC [QRESYNC] [RFC5162] extension is enabled,
the HIGHESTMODSEQ data item MUST be included in the STATUS response
as well.

Note that if a client requests MessageExpunge with the SELECTED
mailbox specifier, the meaning of a an 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 can either use the SELECTED-DELAYED
mailbox specifier, specifier or can avoid using the MessageExpunge event
entirely.

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

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 mailbox, when QRESYNC is not enabled:
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) DELETE), or renamed (with RENAME). For
a server that implements [RFC4314] [RFC4314], granting or revocation of the 'l'
right to the current user on the affected mailbox MUST be considered
mailbox creation/deletion creation or deletion, respectively. If a mailbox is created
or deleted, the mailbox itself and its direct parent (whether it is
an existing mailbox or not) are considered to be affected.

The server notifies the client by sending an unsolicited LIST
response for each affected mailbox name. If, after the event, the
mailbox name does not refer to a mailbox accessible to the client,

Internet-draft August 2008
the \Nonexistent flag MUST be included.

For each LISTable mailbox renamed, the server sends an extended LIST
response [LISTEXT] [RFC5258] 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 is sent for
INBOX in this case.

If the server automatically subscribes a mailbox when it is created
or renamed, then the unsolicited LIST response for each affected
subscribed mailbox name MUST include the \Subscribed attribute (see
[LISTEXT]).
[RFC5258]). The server SHOULD also include
\HasChildren/\HasNoChildren \HasChildren or
\HasNoChildren attributes [LISTEXT] [RFC5258] as appropriate.

Example of a newly created mailbox (or granting of the 'l' right on
the mailbox):
S: * LIST () "/" "NewMailbox"

And a deleted mailbox (or revocation of the 'l' right on the
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
response for each affected mailbox name. If and only if the mailbox
is subscribed after the event, the \Subscribed attribute (see
[LISTEXT])
[RFC5258]) is included. Note that in the LIST response, all mailbox
attributes MUST be accurately computed (this differs from the
behavior of the LSUB command).

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

5.6. MailboxMetadataChange

Support for this event type is OPTIONAL, OPTIONAL unless the METADATA extension [METADATA]
[RFC5464] is also supported by the server, in which case support for
this event type is REQUIRED.

The server sends an

A client willing to receive unsolicited METADATA response responses as a
result of using the MailboxMetadataChange event in the NOTIFY command
doesn't have to issue ENABLE METADATA.

The server sends an unsolicited METADATA response (as per Section

Internet-draft August 2008
4.4.2 of [METADATA]). [RFC5464]). If possible, only the changed metadata SHOULD
be included, but if the server can't detect a change to a single
metadata item, it MAY include all metadata items set on the mailbox.
If a metadata item is deleted (set to NIL), it MUST always be
included in the METADATA response.

Example:
S: * METADATA "INBOX" /public/comment /shared/comment

5.7. ServerMetadataChange

Support for this event type is OPTIONAL, OPTIONAL unless the METADATA or the
METADATA-SERVER extension [METADATA] [RFC5464] is also supported by the server,
in which case support for this event type is REQUIRED.

A client willing to receive unsolicited METADATA responses as a
result of using the ServerMetadataChange event in the NOTIFY command
doesn't have to issue ENABLE METADATA or ENABLE METADATA-SERVER.

The server sends an unsolicited METADATA response (as per Section
4.4.2 of [METADATA]). [RFC5464]). Only the names of changed metadata entries
SHOULD be returned in such METADATA responses. If a metadata item is
deleted (set to NIL), it MUST always be included in the METADATA
response.

Example:
S: * METADATA "" /public/comment /shared/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 (Access Control List) Changes

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

The server SHOULD return the LIST response with the \NoAccess name
attribute if and when the mailbox loses the 'l' right. Simalarly, Similarly,
the server SHOULD return the LIST response with no \NoAccess name
attribute,
attribute if the mailbox was previously reported as having
\NoAccess, \NoAccess
and later on the 'l' right is later granted.

Internet-draft August 2008

6. Mailbox Specification

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

Only 'SELECTED' and 'SELECTED-DELAYED' (section (Section 6.1) match the
currently selected mailbox. All other mailbox specifications affect
other (non-selected) mailboxes.

Note that multiple <event-group>s can apply to the same mailbox. The
following example demonstrates this. In this example, MessageNew and
MessageExpunge events are reported for INBOX INBOX, due to the first
<event-group>. A SubscriptionChange event will also be reported for INBOX
INBOX, due to the second <event-group>.

C: a notify set (mailboxes INBOX (Messagenew messageExpunge))
(personal (SubscriptionChange))

A typical client that supports the NOTIFY extension would ask for
events on the selected mailbox and some named mailboxes.

In the next example example, the client asks for FlagChange events for all
personal mailboxes except the currently selected mailbox. This is
different from the previous example, example because SELECTED overrides all
other message event definitions for the currently selected mailbox
(see Section 3.1).

C: a notify set (selected (Messagenew (uid flags) messageExpunge))
(personal (MessageNew FlagChange MessageExpunge))

6.1. Mailbox specifiers affecting Specifiers Affecting the currently selected mailbox Currently Selected Mailbox

Only one of the mailbox specifiers affecting the currently selected
mailbox can be specified in any NOTIFY command. The two such mailbox
specifiers (SELECTED and SELECTED-DELAYED) are described below.

Both refer to the mailbox that was selected using either SELECT or
EXAMINE (see [RFC3501] section [RFC3501], Sections 6.3.1 and 6.3.2). When the IMAP
connection is not in the selected state, such mailbox specifiers
don't refer to any mailbox.

The mailbox specifiers only apply to <message-event>s. It is an
error to specify other types of events with either the SELECTED or
the SELECTED-DELAYED selector.

Internet-draft August 2008

6.1.1. Selected

The SELECTED mailbox specifier requires the server to send immediate
notifications for the currently selected mailbox about all specified
<message-event>s.

6.1.2 Selected-delayed

6.1.2. Selected-Delayed

The SELECTED-DELAYED mailbox specifier requires the server to delay a
MessageExpunge event until the client issues a command that allows
returning information about expunged messages (see Section 7.4.1 of
[RFC3501] for more details), for example example, till a NOOP or an IDLE
command.
command has been issued. When SELECTED-DELAYED is specified specified, the
server MAY also delay returning other <message-event>s until the
client issues a
command one of the commands specified above, or it MAY return
them immediately.

6.2. Personal

Personal refers to all selectable mailboxes in the user's personal
namespace(s), as defined in [NAMESPACE]. [RFC2342].

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 a Message Delivery
Agent (MDA) (see [EMAIL-ARCH], particularly section Section 4.3.3).

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

6.4

6.4. Subscribed

Subscribed refers to all mailboxes subscribed to by the user.

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

6.5

6.5. Subtree

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

Internet-draft August 2008

6.6

6.6. Mailboxes

Mailboxes is followed by a mailbox name or a list of mailbox names.
The server MUST NOT do a 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 Commands

If the server that support supports the NOTIFY extension also supports
CONTEXT=SEARCH and/or CONTEXT=SORT as defined in [CONTEXT], [RFC5267], 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
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: * 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: )
S: * ESEARCH (TAG "a00") ADDTO (0 93)

Note that the EXISTS response MUST precede any FETCH responses, and
together they MUST precede 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" "resp-text-code", and "search-key". The "modifier-update" non-
terminal
non-terminal is defined in [CONTEXT]. [RFC5267]. "mbx-list-oflag" is defined in
[RFC3501] and updated by [LISTEXT].

Internet-draft August 2008 [RFC5258].

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. For example example, the
<filter-mailboxes-selected> non-terminal value "SELECTED" must be
treated in the same way as "Selected" or "selected".

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

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

notify-none = "NONE"
; 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 ")"
;; Only <message-event>s are allowed in <events>
;; when <filter-mailboxes-selected> is used.

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

filter-mailboxes-selected = "selected" / "selected-delayed"
;; Apply to the currently selected mailbox only.
;; Only one of them can be specified in a NOTIFY
;; command.

Internet-draft August 2008

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-event = ( "MessageNew" [SP
"(" fetch-att *(SP fetch-att) ")" ] )
/ "MessageExpunge"
/ "FlagChange"
/ "AnnotationChange"
;; "MessageNew" includes "MessageAppend" from
;; [MSGEVENT]. "FlagChange" is any of
;; "MessageRead", "MessageTrash", "FlagsSet",
;; "FlagsClear" [MSGEVENT]. "MessageExpunge"
;; includes "MessageExpire" [MSGEVENT].
;; MessageNew and MessageExpunge MUST always
;; be specified together. If FlagChange is
;; specified, then MessageNew and MessageExpunge
;; MUST be specified as well.
;; The fett-att list may only be present for the
;; SELECTED/SELECTED-DELAYED mailbox filter
;; (<filter-mailboxes>).

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

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 or without surrounding quotes, as per
;; mbox-list-extended-item-tag production.

resp-text-code =/ "NOTIFICATIONOVERFLOW" /

Internet-draft August 2008
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) ")" ]

mbx-list-oflag =/ "\NoAccess"

9. Security considerations Considerations

It is very easy for a client to deny itself service using NOTIFY: NOTIFY.
Asking for all events on all mailboxes may work on a small server,
but with a big server 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 also exists
in plain IMAP, however IMAP; however, this extension magnifies the problem.

This extensions extension 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]
SIEVE [RFC5228] or similar is much better.

10. IANA considerations Considerations

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

10.1. Initial LIST-EXTENDED extended data item registrations

It is requested that the Extended Data Item Registrations

The following entry be has been added to the IMAP4 List
Extended LIST-EXTENDED response
registry [LISTEXT]:

Internet-draft August 2008 [RFC5258]:

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, 5465, 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 Acknowledgments

The authors gratefully acknowledge the help of Peter Coates, Dave
Cridland, Mark Crispin, Cyrus Daboo, Abhijit Menon-Sen, Timo
Sirainen
Sirainen, 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

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

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

[RFC2342] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342,
May 1998.

[RFC3501] Crispin, "Internet Message Access Protocol M., "INTERNET MESSAGE ACCESS PROTOCOL - Version VERSION
4rev1", RFC 3501, University of Washington, June March 2003.

Internet-draft August 2008

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

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

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

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

[QRESYNC]

[RFC5162] Melnikov, A., Cridland, D. D., and C. Wilson, "IMAP4
Extensions for Quick Mailbox Resynchronization", RFC
5162, March 2008.

[LISTEXT]

[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234, January
2008.

[RFC5258] Leiba, B. and A. Melnikov, "IMAP4 List "Internet Message Access
Protocol version 4 - LIST Command Extensions", RFC 5258,
June 2008.

[METADATA] Daboo, "IMAP METADATA Extension", draft-daboo-imap-
annotatemore-14 (work in progress), Apple Computer, Inc.,
July 2008.

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

[CONTEXT]

[RFC5267] Cridland, D. and C. King, "Contexts for IMAP4", RFC
5267, July 2008.

[NAMESPACE] Gahrns, M. and C.

[RFC5423] Newman, "IMAP4 Namespace", C. and R. Gellens, "Internet Message Store
Events", RFC 2342,
May 1998. 5423, Month 2009.

[RFC5464] Daboo, C., "The IMAP METADATA Extension", RFC 5464,
February 2009.

13. Informative References

[SIEVE]

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

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

Internet-draft August 2008

14.

Authors' Addresses

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

EMail: arnt@oryx.com

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

Email:

EMail: Curtis.King@isode.com

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

Email:

EMail: Alexey.Melnikov@isode.com

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

Email: arnt@oryx.com

Internet-draft August 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.