draft-ietf-lemonade-imap-notify-05.txt   draft-ietf-lemonade-imap-notify-06.txt 
Network Working Group Alexey Melnikov Network Working Group Alexey Melnikov
Internet-Draft Isode Ltd. Internet-Draft Isode Ltd.
Intended Status: Proposed Standard Arnt Gulbrandsen Intended Status: Proposed Standard Arnt Gulbrandsen
Oryx Mail Systems GmbH Oryx Mail Systems GmbH
Curtis King Curtis King
Isode Ltd. Isode Ltd.
March 24, 2008 June 21, 2008
The IMAP NOTIFY Extension The IMAP NOTIFY Extension
draft-ietf-lemonade-imap-notify-05.txt draft-ietf-lemonade-imap-notify-06.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 3, line 31 skipping to change at page 3, line 31
specify a list of fetch-atts to be returned when a new message is specify a list of fetch-atts to be returned when a new message is
delivered or appended in another session. delivered or appended in another session.
[[RFC-Editor: Please delete the following before publication: [[RFC-Editor: Please delete the following before publication:
Comments regarding this draft may be sent either to the Comments regarding this draft may be sent either to the
lemonade@ietf.org mailing list or to the authors.]] lemonade@ietf.org mailing list or to the authors.]]
3. The NOTIFY extension 3. The NOTIFY extension
IMAP servers which support this extension advertise the X-DRAFT- IMAP servers which support this extension advertise the X-DRAFT-
W05-NOTIFY capability. This extension adds the NOTIFY command as W06-NOTIFY capability. This extension adds the NOTIFY command as
defined in Section 5.1. defined in Section 5.1.
A server implementing this extension is not required to implement A server implementing this extension is not required to implement
LIST-EXTENDED [LISTEXT], even though a NOTIFY compliant server must LIST-EXTENDED [LISTEXT], even though a NOTIFY compliant server must
be able to return extended LIST responses defined in [LISTEXT]. be able to return extended LIST responses defined in [LISTEXT].
[[RFC-Editor: Should QRESYNC be a required dependency for this <<Should QRESYNC be a required dependency for this extension?>>
extension?]]
3.1. The NOTIFY Command 3.1. The NOTIFY Command
Arguments: "SET" Arguments: "SET"
optional STATUS indicator optional STATUS indicator
Mailboxes to be watched Mailboxes to be watched
Events about which to notify the client Events about which to notify the client
Or Or
Arguments: "NONE" Arguments: "NONE"
skipping to change at page 4, line 38 skipping to change at page 4, line 38
The effect of a successful NOTIFY command lasts until the next The effect of a successful NOTIFY command lasts until the next
NOTIFY command, or until the IMAP connection is closed. NOTIFY command, or until the IMAP connection is closed.
A successful NOTIFY SET command MUST cause the server to immediately A successful NOTIFY SET command MUST cause the server to immediately
return any accumulated changes to the currently selected mailbox (if return any accumulated changes to the currently selected mailbox (if
any), such as flag changes, new or expunged messages. This is any), such as flag changes, new or expunged messages. This is
equivalent to NOOP command being issued by the client just before equivalent to NOOP command being issued by the client just before
the NOTIFY SET command. the NOTIFY SET command.
The NOTIFY SET command can request notifications of changes to the The NOTIFY SET command can request notifications of message related
selected mailbox, whatever it may be at the time the notifications changes to the selected mailbox, whatever it may be at the time the
are being generated. This is done by specifying the SELECTED mailbox message notifications are being generated. This is done by
selector (see Section 6.1) in the NOTIFY SET command. The client specifying either the SELECTED or the SELECTED-DELAYED mailbox
can also request notifications on other mailboxes by name or by a selector (see Section 6.1) in the NOTIFY SET command. If the
limited mailbox pattern match. The notifications returned for the SELECTED/SELECTED-DELAYED mailbox selector is not specified in the
currently selected mailbox will be those specified by the SELECTED NOTIFY SET command, this means that the client doesn't want to
mailbox specifier, even if the selected mailbox also appears by name receive any <message-event>s for the currently selected mailbox.
in the command. 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
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 notifications are
controlled by mailbox specifiers other than SELECTED/SELECTED-
DELAYED.
If the NOTIFY command enables MessageNew, MessageExpunge, If the NOTIFY command enables MessageNew, MessageExpunge,
AnnotationChange or FlagChange notification for a mailbox other than AnnotationChange or FlagChange notification for a mailbox other than
SELECTED, and the client has specified the STATUS indicator the currently selected mailbox, and the client has specified the
parameter, then the server MUST send a STATUS response for that STATUS indicator parameter, then the server MUST send a STATUS
mailbox before NOTIFY's tagged OK. If MessageNew is enabled, the response for that mailbox before NOTIFY's tagged OK. If MessageNew
STATUS response MUST contain MESSAGES, UIDNEXT and UIDVALIDITY. If is enabled, the STATUS response MUST contain MESSAGES, UIDNEXT and
MessageExpunge is enabled, the STATUS response MUST contain UIDVALIDITY. If MessageExpunge is enabled, the STATUS response MUST
MESSAGES. If either AnnotationChange or FlagChange are included and contain MESSAGES. If either AnnotationChange or FlagChange are
the server also supports CONDSTORE [RFC4551] and/or QRESYNC included and the server also supports CONDSTORE [RFC4551] and/or
[QRESYNC] extension, the STATUS response MUST contain UIDVALIDITY QRESYNC [QRESYNC] extension, the STATUS response MUST contain
and HIGHESTMODSEQ. Absence of the STATUS indicator parameter allows UIDVALIDITY and HIGHESTMODSEQ. Absence of the STATUS indicator
the client to avoid the additional STATUS responses. This might be parameter allows the client to avoid the additional STATUS
useful if the client has already retrieved this information before responses. This might be useful if the client has already retrieved
issuing the NOTIFY command. this information before issuing the NOTIFY command.
Clients are advised to limit the number of mailboxes used with Clients are advised to limit the number of mailboxes used with
NOTIFY. Particularly, if a client asks for events for all accessible NOTIFY. Particularly, if a client asks for events for all accessible
mailboxes, the server may swamp the client with updates about shared mailboxes, the server may swamp the client with updates about shared
mailboxes. This wastes both server and network resources. For mailboxes. This wastes both server and network resources. For
each mailbox specified, the server verifies that the client has each mailbox specified, the server verifies that the client has
access using the following test: access using the following test:
- If the name does not refer to an existing mailbox, the server MUST - If the name does not refer to an existing mailbox, the server MUST
ignore it. ignore it.
skipping to change at page 7, line 17 skipping to change at page 7, line 26
If IDLE (as well as this extension) is supported, while processing If IDLE (as well as this extension) is supported, while processing
IDLE the server MUST send the same events as instructed by the IDLE the server MUST send the same events as instructed by the
client using the NOTIFY command. client using the NOTIFY command.
NOTIFY makes IDLE unnecessary for some clients. If a client does not NOTIFY makes IDLE unnecessary for some clients. If a client does not
use MSNs and '*' in commands, it can request MessageExpunge and use MSNs and '*' in commands, it can request MessageExpunge and
MessageNew for the selected mailbox using the NOTIFY command instead MessageNew for the selected mailbox using the NOTIFY command instead
of entering the IDLE mode. 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 5. Event Types
Only some of the events in [MSGEVENT] can be expressed in IMAP, and 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 for some of them there are several possible ways to express the
event. event.
This section specifies the events which an IMAP server can notify an This section specifies the events which an IMAP server can notify an
IMAP client, and how. IMAP client, and how.
The server SHOULD omit notifying the client if the event is caused The server SHOULD omit notifying the client if the event is caused
by this client. For example, if the client issues CREATE and has by this client. For example, if the client issues CREATE and has
requested MailboxName event that would cover the newly created requested MailboxName event that would cover the newly created
mailbox, the server SHOULD NOT notify the client of the MailboxName mailbox, the server SHOULD NOT notify the client of the MailboxName
change. change.
All event types described in this document require the 'l' and 'r' All event types described in this document require the 'l' and 'r'
rights (see [RFC4314]) on all observed mailboxes. Servers that rights (see [RFC4314]) on all observed mailboxes. Servers that
don't implement [RFC4314] should map the above rights to their don't implement [RFC4314] should map the above rights to their
access control model. access control model.
If FlagChange event is specified, MessageNew and MessageExpunge MUST If FlagChange and/or AnnotationChange event is specified, MessageNew
also be specified by the client. Otherwise the server MUST respond and MessageExpunge MUST also be specified by the client. Otherwise
with the tagged BAD response. the server MUST respond with the tagged BAD response.
If one of MessageNew or MessageExpunge is specified, the both events If one of MessageNew or MessageExpunge is specified, the both events
MUST be specified. Otherwise the server MUST respond with the MUST be specified. Otherwise the server MUST respond with the
tagged BAD response. tagged BAD response.
If the client instructs the server not to send MessageNew and The client can instruct the server not to send an event by omitting
MessageExpunge for the selected mailbox, the server MUST still send the necessary event from the list of events specified in NOTIFY SET,
EXISTS and EXPUNGE responses as required by IMAP (see [RFC3501] by using NONE event specifier in the NOTIFY SET or by using NOTIFY
section 7). In other words, MessageExpunge instructs the server to NONE. In particular NOTIFY SET ... NONE can be used as a snapshot
notify the client immediately, and the lack of MessageExpunge facility by clients.
instructs the server to notify the client during execution of the
next command as specified in [RFC3501]. MessageNew is handled
similarly by the server.
5.1. FlagChange and AnnotationChange 5.1. FlagChange and AnnotationChange
If the flag and/or message annotation change happens in the selected If the flag and/or message annotation change happens in the selected
mailbox, the server MUST notify the client by sending an unsolicited mailbox, the server MUST notify the client by sending an unsolicited
FETCH response, which MUST include UID and FLAGS/ANNOTATION FETCH FETCH response, which MUST include UID and FLAGS/ANNOTATION FETCH
data items. It MAY also send new FLAGS and/or OK [PERMANENTFLAGS data items. It MAY also send new FLAGS and/or OK [PERMANENTFLAGS
...] responses. ...] responses.
If a search context is in effect as specified in [CONTEXT], an If a search context is in effect as specified in [CONTEXT], an
ESEARCH ADDTO or ESEARCH REMOVEFROM will also be generated, if ESEARCH ADDTO or ESEARCH REMOVEFROM will also be generated, if
appropriate. In this case, the FETCH response MUST precede the appropriate. In this case, the FETCH response MUST precede the
ESEARCH response. ESEARCH response.
If the change happens in another mailbox, then the response depends If the change happens in another mailbox, then the server responds
on whether CONDSTORE [RFC4551] and/or QRESYNC [QRESYNC] is being with a STATUS response. The exact content of the STATUS response
used. If so, the server sends a STATUS (HIGHESTMODSEQ) response. depends on various factors. If CONDSTORE [RFC4551] and/or QRESYNC
Note that whenever mailbox UIDVALIDITY changes, the server MUST also [QRESYNC] is being used, then the server sends a STATUS response
include UIDVALIDITY in the STATUS response. If the number of that includes at least HIGHESTMODSEQ and UIDVALIDITY status data
messages with \Seen flag changes, the server MAY also include the items. If the number of messages with \Seen flag changes, the
UNSEEN in the STATUS response. If CONDSTORE/QRESYNC is not used and server MAY also include the UNSEEN data item in the STATUS response.
the server choses not to include the UNSEEN, the server does not If CONDSTORE/QRESYNC is not used and the server choses not to
notify the client. [[Open Issue: should there be a way to require include the UNSEEN, the server does not notify the client. <<Open
the server to return UNSEEN?]] Issue: should there be a way to require the server to return
UNSEEN?>> When this event is 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 and FlagChange covers the MessageRead, MessageTrash, FlagsSet and
FlagsClear events in [MSGEVENT]. FlagsClear events in [MSGEVENT].
Example in the selected mailbox: Example in the selected mailbox:
S: * 99 FETCH (UID 9999 FLAGS ($Junk)) S: * 99 FETCH (UID 9999 FLAGS ($Junk))
And in another mailbox, with CONDSTORE in use:
And in another, with CONDSTORE in use: S: * STATUS Lists/Lemonade (HIGHESTMODSEQ 65666665 UIDVALIDITY
S: * STATUS Lists/Lemonade (HIGHESTMODSEQ 65666665) 101)
5.2. MessageNew 5.2. MessageNew
This covers both MessageNew and MessageAppend in [MSGEVENT]. This covers both MessageNew and MessageAppend in [MSGEVENT].
If the new/appended message is in the selected mailbox, the server If the new/appended message is in the selected mailbox, the server
notifies the client by sending an unsolicited EXISTS response, notifies the client by sending an unsolicited EXISTS response,
followed by an unsolicited FETCH response containing the information followed by an unsolicited FETCH response containing the information
requested by the client. A FETCH response SHOULD NOT be generated requested by the client. A FETCH response SHOULD NOT be generated
for a new message created by the client on this particular for a new message created by the client on this particular
skipping to change at page 9, line 23 skipping to change at page 9, line 36
ESEARCH ADDTO will also be generated, if appropriate. In this case, ESEARCH ADDTO will also be generated, if appropriate. In this case,
the EXISTS response MUST precede the ESEARCH response. Both the the EXISTS response MUST precede the ESEARCH response. Both the
NOTIFY command and the SEARCH and SORT commands (see Section 7) can NOTIFY command and the SEARCH and SORT commands (see Section 7) can
specify attributes to be returned for new messages. These specify attributes to be returned for new messages. These
attributes SHOULD be combined into a single FETCH response. The attributes SHOULD be combined into a single FETCH response. The
server SHOULD avoid sending duplicate data. The FETCH response(s) server SHOULD avoid sending duplicate data. The FETCH response(s)
MUST follow any ESEARCH ADDTO responses. MUST follow any ESEARCH ADDTO responses.
If the new/appended message is in another mailbox, the server sends If the new/appended message is in another mailbox, the server sends
an unsolicited STATUS (UIDNEXT MESSAGES) response for the relevant an unsolicited STATUS (UIDNEXT MESSAGES) response for the relevant
mailbox. If CONDSTORE (defined in [RFC4551]) is in use, the mailbox. If the CONDSTORE extension [RFC4551] and/or the QRESYNC
HIGHESTMODSEQ status data item MUST be included in the STATUS extension [QRESYNC] is enabled, the HIGHESTMODSEQ status data item
response. MUST be included in the STATUS response.
The client SHOULD NOT use FETCH attributes that implicitly set the The client SHOULD NOT use FETCH attributes that implicitly set the
\seen flag, or that presuppose the existence of a given bodypart. \seen flag, or that presuppose the existence of a given bodypart.
UID, MODSEQ, FLAGS, ENVELOPE, BODY.PEEK[HEADER.FIELDS... and UID, MODSEQ, FLAGS, ENVELOPE, BODY.PEEK[HEADER.FIELDS... and
BODY/BODYSTRUCTURE may be the most useful attributes. BODY/BODYSTRUCTURE may be the most useful attributes.
Note that if a client asks to be notified of MessageNew events, the Note that if a client asks to be notified of MessageNew events, the
number of messages can increase at any time, and therefore the number of messages can increase at any time, and therefore the
client cannot refer to a specific message using the MSN/UID '*'. client cannot refer to a specific message using the MSN/UID '*'.
Example in the selected mailbox: Example in the selected mailbox:
S: * 444 EXISTS S: * 444 EXISTS
S: * 444 FETCH (UID 9999) S: * 444 FETCH (UID 9999)
And in another, without CONDSTORE: And in another mailbox, without CONDSTORE enabled:
S: * STATUS Lists/Lemonade (UIDNEXT 10002 MESSAGES 503) S: * STATUS Lists/Lemonade (UIDNEXT 10002 MESSAGES 503)
5.3. MessageExpunge 5.3. MessageExpunge
If the expunged message(s) is/are in the selected mailbox, the If the expunged message(s) is/are in the selected mailbox, the
server notifies the client using EXPUNGE (or VANISHED, if [QRESYNC] server notifies the client using EXPUNGE (or VANISHED, if [QRESYNC]
is supported by the server and enabled by the client). is supported by the server and enabled by the client).
If a search context is in effect as specified in [CONTEXT], an If a search context is in effect as specified in [CONTEXT], an
ESEARCH REMOVEFROM will also be generated, if appropriate. ESEARCH REMOVEFROM will also be generated, if appropriate.
If the expunged message(s) is/are in another mailbox, the server If the expunged message(s) is/are in another mailbox, the server
sends an unsolicited STATUS (UIDNEXT MESSAGES) response for the sends an unsolicited STATUS (UIDNEXT MESSAGES) response for the
relevant mailbox. If CONDSTORE is being used, HIGHESTMODSEQ MUST be relevant mailbox. If the QRESYNC [QRESYNC] extension is enabled, the
included in the STATUS response. HIGHESTMODSEQ data item MUST be included in the STATUS response as
well.
Note that if a client requests MessageExpunge, the meaning of a MSN Note that if a client requests MessageExpunge, the meaning of a MSN
can change at any time, so the client cannot use MSNs in commands 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 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 use UID FETCH. The meaning of '*' can also change when messages are
added or expunged. A client wishing to keep using MSNs MUST NOT added or expunged. A client wishing to keep using MSNs MUST NOT
request the MessageExpunge event. request the MessageExpunge event.
The MessageExpunge notification covers both MessageExpunge and The MessageExpunge notification covers both MessageExpunge and
MessageExpire events from [MSGEVENT]. MessageExpire events from [MSGEVENT].
Example in the selected mailbox, without QRESYNC: Example in the selected mailbox, without QRESYNC:
S: * 444 EXPUNGE S: * 444 EXPUNGE
The same example in the selected mailbox, with QRESYNC: The same example in the selected mailbox, with QRESYNC:
S: * VANISHED 5444 S: * VANISHED 5444
And in another: And in another mailbox, when QRESYNC is not enabled:
S: * STATUS misc (UIDNEXT 999 MESSAGES 554) S: * STATUS misc (UIDNEXT 999 MESSAGES 554)
5.4. MailboxName 5.4. MailboxName
These notifications are sent if an affected mailbox name was created These notifications are sent if an affected mailbox name was created
(with CREATE), deleted (with DELETE) or renamed (with RENAME). For (with CREATE), deleted (with DELETE) or renamed (with RENAME). For
a server that implements [RFC4314] granting or revocation of the 'l' a server that implements [RFC4314] granting or revocation of the 'l'
right to the current user on the affected mailbox MUST be considered right to the current user on the affected mailbox MUST be considered
mailbox creation/deletion respectively. If a mailbox is created or mailbox creation/deletion respectively. If a mailbox is created or
deleted, the mailbox itself and its parent are considered to be deleted, the mailbox itself and its parent are considered to be
skipping to change at page 11, line 26 skipping to change at page 11, line 41
The server notifies the client by sending an unsolicited LIST The server notifies the client by sending an unsolicited LIST
responses for each affected mailbox name. If and only if the mailbox responses for each affected mailbox name. If and only if the mailbox
is subscribed after the event, the \Subscribed attribute (see is subscribed after the event, the \Subscribed attribute (see
[LISTEXT]) is included. [LISTEXT]) is included.
Example: Example:
S: * LIST (\Subscribed) "/" "SubscribedMailbox" S: * LIST (\Subscribed) "/" "SubscribedMailbox"
5.6. MailboxMetadataChange 5.6. MailboxMetadataChange
The server sends an unsolicited LIST response including METADATA (as Support for this event type is OPTIONAL, unless the METADATA
per Section 4.3.1 of [METADATA]). If possible, only the changed extension [METADATA] is also supported by the server, in which case
metadata should be included, but if necessary, all metadata must be support for this event type is REQUIRED.
included.
The server sends an unsolicited METADATA response (as per Section
4.4.2 of [METADATA]). 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.
Example: Example:
S: * LIST "/" "INBOX" (METADATA (/comment))
S: * METADATA "INBOX" /public/comment
5.7. ServerMetadataChange 5.7. ServerMetadataChange
Support for this event type is OPTIONAL, unless the METADATA or the
METADATA-SERVER extension [METADATA] is also supported by the
server, in which case support for this event type is REQUIRED.
The server sends an unsolicited METADATA response (as per Section The server sends an unsolicited METADATA response (as per Section
4.5.2 of [METADATA]). Only the names of changed metadata entries 4.4.2 of [METADATA]). Only the names of changed metadata entries
SHOULD be returned in such METADATA responses. SHOULD be returned in such METADATA responses.
Example: Example:
S: * METADATA (/comment) S: * METADATA "" /public/comment
5.8. Notification Overflow 5.8. Notification Overflow
If the server is unable or unwilling to deliver as many If the server is unable or unwilling to deliver as many
notifications as it is being asked to, it may disable notifications notifications as it is being asked to, it may disable notifications
for some or all clients. It MUST notify these clients by sending an for some or all clients. It MUST notify these clients by sending an
untagged "OK [NOTIFICATIONOVERFLOW]" response and behave as if a untagged "OK [NOTIFICATIONOVERFLOW]" response and behave as if a
NOTIFY NONE command had just been received. NOTIFY NONE command had just been received.
Example: Example:
skipping to change at page 12, line 28 skipping to change at page 13, line 6
attribute if and when the mailbox loses the 'l' right. Simalarly, attribute if and when the mailbox loses the 'l' right. Simalarly,
the server SHOULD return the LIST response with no \NoAccess name the server SHOULD return the LIST response with no \NoAccess name
attribute, if the mailbox was previously reported as having attribute, if the mailbox was previously reported as having
\NoAccess, and later on the 'l' right is granted. \NoAccess, and later on the 'l' right is granted.
6. Mailbox Specification 6. Mailbox Specification
Mailboxes to be monitored can be specified in several different Mailboxes to be monitored can be specified in several different
ways. ways.
Only 'selected' (section 6.1) matches the currently selected Only 'SELECTED' and 'SELECTED-DELAYED' (section 6.1) match the
mailbox. All other mailbox specifications affect other (non- currently selected mailbox. All other mailbox specifications affect
selected) mailboxes. other (non-selected) mailboxes.
If for any given event type the client specifies monitoring of the
same mailbox several times (using the same or different mailbox
specifications), the first specification wins.
Note that for different event types different <event-group>s can Note that multiple <event-group>s can apply to the same mailbox.
apply to the same mailbox. The following example demonstrates this. The following example demonstrates this. In this example,
In this example, MessageNew and MessageExpunge events are reported MessageNew and MessageExpunge events are reported for INBOX due to
for INBOX due to the first <event-group>. SubscriptionChange event the first <event-group>. SubscriptionChange event will also be
will also be reported for INBOX due to the second <event-group>. reported for INBOX due to the second <event-group>.
C: a notify set (mailboxes INBOX (Messagenew messageExpunge)) C: a notify set (mailboxes INBOX (Messagenew messageExpunge))
(personal (SubscriptionChange)) (personal (SubscriptionChange))
A typical client that supports the NOTIFY extension would ask for A typical client that supports the NOTIFY extension would ask for
events on the selected mailbox and some named mailboxes. events on the selected mailbox and some named mailboxes.
In this example, the client asks for FlagChange events for all In the next example the client asks for FlagChange events for all
personal mailboxes except the selected mailbox: personal mailboxes except the currently selected mailbox. This is
different from the previous 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) C: a notify set (selected (Messagenew (uid flags)
messageExpunge)) (personal (MessageNew FlagChange messageExpunge)) (personal (MessageNew FlagChange
MessageExpunge)) MessageExpunge))
6.1. Selected 6.1. Mailbox specifiers affecting the currently selected mailbox
Selected refers to the mailbox selected using either SELECT or Only one of the mailbox specifiers affecting the currently selected
EXAMINE (see [RFC3501] section 6.3.1 and 6.3.2). When the IMAP mailbox can be specified in any NOTIFY command. The two such mailbox
connection is not in selected state, selected does not refer to any specifiers (SELECTED and SELECTED-DELAYED) are described below.
mailbox.
Both refer 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 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.
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
The SELECTED-DELAYED mailbox specifier requires the server to delay
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 till a NOOP or an IDLE
command. When SELECTED-DELAYED is specified the server MAY also
delay returning other <message-event>s until the client issues a
command specified above, or it MAY return them immediately.
6.2. Personal 6.2. Personal
Personal refers to all selectable mailboxes in the user's personal Personal refers to all selectable mailboxes in the user's personal
namespace(s). namespace(s).
6.3. Inboxes 6.3. Inboxes
Inboxes refers to all selectable mailboxes in the user's personal Inboxes refers to all selectable mailboxes in the user's personal
namespace(s) to which messages may be delivered by an MDA (see namespace(s) to which messages may be delivered by an MDA (see
skipping to change at page 14, line 45 skipping to change at page 15, line 45
The following syntax specification uses the Augmented Backus-Naur The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) notation as specified in [RFC5234]. [RFC3501] defines Form (ABNF) notation as specified in [RFC5234]. [RFC3501] defines
the non-terminals "capability", "command-auth", "mailbox", "mailbox- the non-terminals "capability", "command-auth", "mailbox", "mailbox-
data", "resp-text-code" and "search-key". The "modifier-update" non- data", "resp-text-code" and "search-key". The "modifier-update" non-
terminal is defined in [CONTEXT]. "mbx-list-oflag" is defined in terminal is defined in [CONTEXT]. "mbx-list-oflag" is defined in
[RFC3501] and updated by [LISTEXT]. [RFC3501] and updated by [LISTEXT].
Except as noted otherwise, all alphabetic characters are case- Except as noted otherwise, all alphabetic characters are case-
insensitive. The use of upper or lower case characters to define insensitive. The use of upper or lower case characters to define
token strings is for editorial clarity only. Implementations MUST token strings is for editorial clarity only. Implementations MUST
accept these strings in a case-insensitive fashion. accept these strings in a case-insensitive fashion. For example
<filter-mailboxes-selected> non-terminal value "SELECTED" must be
treated in the same way as "Selected" or "selected".
capability =/ "X-DRAFT-W05-NOTIFY" capability =/ "X-DRAFT-W06-NOTIFY"
;; [[Note to RFC Editor: change the capability ;; [[Note to RFC Editor: change the capability
;; name before publication]] ;; name before publication]]
command-auth =/ notify command-auth =/ notify
notify = "NOTIFY" SP notify = "NOTIFY" SP
(notify-set / notify-none) (notify-set / notify-none)
notify-set = "SET" [status-indicator] SP event-groups notify-set = "SET" [status-indicator] SP event-groups
; Replace registered notification events ; Replace registered notification events
; with the specified list of events ; with the specified list of events
notify-none = "NONE" notify-none = "NONE"
skipping to change at page 15, line 28 skipping to change at page 16, line 31
status-indicator = SP "STATUS" status-indicator = SP "STATUS"
one-or-more-mailbox = mailbox / many-mailboxes one-or-more-mailbox = mailbox / many-mailboxes
many-mailboxes = "(" mailbox *(SP mailbox) ")" many-mailboxes = "(" mailbox *(SP mailbox) ")"
event-groups = event-group *(SP event-group) event-groups = event-group *(SP event-group)
event-group = "(" filter-mailboxes SP events ")" event-group = "(" filter-mailboxes SP events ")"
filter-mailboxes = "selected" / "inboxes" / "personal" / filter-mailboxes = filter-mailboxes-selected /
"subscribed" / filter-mailboxes-other
filter-mailboxes-other = "inboxes" / "personal" / "subscribed" /
( "subtree" SP one-or-more-mailbox ) / ( "subtree" SP one-or-more-mailbox ) /
( "mailboxes" 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.
events = ( "(" event *(SP event) ")" ) / "NONE" events = ( "(" event *(SP event) ")" ) / "NONE"
;; As in [MSGEVENT]. ;; As in [MSGEVENT].
;; "NONE" means that the client does not wish ;; "NONE" means that the client does not wish
;; to receive any events for the specified ;; to receive any events for the specified
;; mailboxes. ;; mailboxes.
event = message-event event = message-event /
/ mailbox-event / user-event / event-ext mailbox-event / user-event / event-ext
message-match-criteria = "(" search-key ")" message-match-criteria = "(" search-key ")"
message-event = ( "MessageNew" [SP message-event = ( "MessageNew" [SP
"(" fetch-att *(SP fetch-att) ")" ] ) "(" fetch-att *(SP fetch-att) ")" ] )
/ "MessageExpunge" / "MessageExpunge"
/ "FlagChange" SP message-match-criteria / "FlagChange" SP message-match-criteria
/ "AnnotationChange" SP message-match-criteria / "AnnotationChange" SP message-match-criteria
;; "MessageNew" includes "MessageAppend" from ;; "MessageNew" includes "MessageAppend" from
;; [MSGEVENT]. "FlagChange" is any of ;; [MSGEVENT]. "FlagChange" is any of
;; "MessageRead", "MessageTrash", "FlagsSet", ;; "MessageRead", "MessageTrash", "FlagsSet",
;; "FlagsClear" [MSGEVENT]. "MessageExpunge" ;; "FlagsClear" [MSGEVENT]. "MessageExpunge"
;; includes "MessageExpire" [MSGEVENT]. ;; includes "MessageExpire" [MSGEVENT].
;; MessageNew and MessageExpunge MUST always ;; MessageNew and MessageExpunge MUST always
;; be specified together. If FlagChange is ;; be specified together. If FlagChange is
;; specified, then MessageNew and MessageExpunge ;; specified, then MessageNew and MessageExpunge
;; MUST be specified as well. ;; MUST be specified as well.
;; The fett-att list may only be present for the ;; The fett-att list may only be present for the
;; SELECTED mailbox filter (<filter-mailboxes>). ;; SELECTED/SELECTED-DELAYED mailbox filter
;; (<filter-mailboxes>).
mailbox-event = "MailboxName" / mailbox-event = "MailboxName" /
"SubscriptionChange" / "MailboxMetadataChange" "SubscriptionChange" / "MailboxMetadataChange"
; "SubscriptionChange" includes ; "SubscriptionChange" includes
; MailboxSubscribe and MailboxUnSubscribe. ; MailboxSubscribe and MailboxUnSubscribe.
; "MailboxName" includes MailboxCreate, ; "MailboxName" includes MailboxCreate,
; "MailboxDelete" and "MailboxRename". ; "MailboxDelete" and "MailboxRename".
user-event = "ServerMetadataChange" user-event = "ServerMetadataChange"
skipping to change at page 16, line 37 skipping to change at page 17, line 48
;; returned in a LIST response when a mailbox is ;; returned in a LIST response when a mailbox is
;; renamed. ;; renamed.
;; Note 1: the OLDNAME tag can be returned ;; Note 1: the OLDNAME tag can be returned
;; with and without surrounding quotes, as per ;; with and without surrounding quotes, as per
;; mbox-list-extended-item-tag production. ;; mbox-list-extended-item-tag production.
resp-text-code =/ "NOTIFICATIONOVERFLOW" / resp-text-code =/ "NOTIFICATIONOVERFLOW" /
unsupported-events-code unsupported-events-code
message-event-name = "MessageNew" / message-event-name = "MessageNew" /
/ "MessageExpunge" / "FlagChange" / "MessageExpunge" / "FlagChange" /
"AnnotationChange" "AnnotationChange"
event-name = message-event-name / mailbox-event / event-name = message-event-name / mailbox-event /
user-event user-event
unsupported-events-code = "BADEVENT" unsupported-events-code = "BADEVENT"
SP "(" event-name *(SP event-name) ")" SP "(" event-name *(SP event-name) ")"
modifier-update = "UPDATE" modifier-update = "UPDATE"
[ "(" fetch-att *(SP fetch-att) ")" ] [ "(" fetch-att *(SP fetch-att) ")" ]
skipping to change at page 18, line 46 skipping to change at page 20, line 12
[RFC4314] Melnikov, "IMAP4 Access Control List (ACL) Extension", [RFC4314] Melnikov, "IMAP4 Access Control List (ACL) Extension",
RFC 4314, December 2005. RFC 4314, December 2005.
[RFC4466] Melnikov, Daboo, "Collected Extensions to IMAP4 ABNF", [RFC4466] Melnikov, Daboo, "Collected Extensions to IMAP4 ABNF",
RFC 4466, Isode Ltd., April 2006. RFC 4466, Isode Ltd., April 2006.
[RFC4551] Melnikov, Hole, "IMAP Extension for Conditional STORE [RFC4551] Melnikov, Hole, "IMAP Extension for Conditional STORE
Operation or Quick Flag Changes Resynchronization", RFC Operation or Quick Flag Changes Resynchronization", RFC
4551, Isode Ltd., June 2006. 4551, Isode Ltd., June 2006.
[LISTEXT] Leiba, Melnikov, "IMAP4 List Command Extensions", draft- [QRESYNC] Melnikov, A., Cridland, D. and C. Wilson, "IMAP4
ietf-imapext-list-extensions-18 (work in progress), IBM, Extensions for Quick Mailbox Resynchronization", RFC
September 2006. 5162, March 2008.
[LISTEXT] Leiba, Melnikov, "IMAP4 List Command Extensions", RFC
5258, June 2008.
[METADATA] Daboo, "IMAP METADATA Extension", draft-daboo-imap- [METADATA] Daboo, "IMAP METADATA Extension", draft-daboo-imap-
annotatemore-12 (work in progress), Apple Computer, Inc., annotatemore-13 (work in progress), Apple Computer, Inc.,
December 2007. April 2008.
[MSGEVENT] Newman, C. and R. Gellens, "Internet Message Store [MSGEVENT] Newman, C. and R. Gellens, "Internet Message Store
Events", draft-ietf-lemonade-msgevent-05.txt (work in Events", draft-ietf-lemonade-msgevent-05.txt (work in
progress), January 2008. progress), January 2008.
[CONTEXT] Cridland, D. and C. King, "Contexts for IMAP4", work in [CONTEXT] Cridland, D. and C. King, "Contexts for IMAP4", work in
progress, draft-cridland-imap-context-03.txt, Isode, June progress, draft-cridland-imap-context-05.txt, April 2008.
2007.
13. Informative References 13. Informative References
[SIEVE] Guenther, P. and T. Showalter, "Sieve: A Mail Filtering [SIEVE] Guenther, P. and T. Showalter, "Sieve: A Mail Filtering
Language", RFC 5228, January 2008. Language", RFC 5228, January 2008.
[QRESYNC] Melnikov, A., Cridland, D. and C. Wilson, "IMAP4
Extensions for Quick Mailbox Resynchronization", RFC
5162, March 2008.
[EMAIL-ARCH] Crocker, "Internet Mail Architecture", draft-crocker- [EMAIL-ARCH] Crocker, "Internet Mail Architecture", draft-crocker-
email-arch-10 (work in progress), February 2008. email-arch-10 (work in progress), February 2008.
14. Authors' Addresses 14. Authors' Addresses
Curtis King Curtis King
Isode Ltd Isode Ltd
5 Castle Business Village 5 Castle Business Village
36 Station Road 36 Station Road
Hampton, Middlesex TW12 2BX Hampton, Middlesex TW12 2BX
 End of changes. 37 change blocks. 
103 lines changed or deleted 156 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/