draft-ietf-lemonade-imap-notify-01.txt   draft-ietf-lemonade-imap-notify-02.txt 
Network Working Group Curtis King Network Working Group Curtis King
Internet-Draft Alexey Melnikov Internet-Draft Alexey Melnikov
Intended Status: Proposed Standard Isode Ltd. Intended Status: Proposed Standard Isode Ltd.
Arnt Gulbrandsen Arnt Gulbrandsen
Oryx Mail Systems GmbH Oryx Mail Systems GmbH
November 14, 2007 December 25, 2007
The IMAP NOTIFY Extension The IMAP NOTIFY Extension
draft-ietf-lemonade-imap-notify-01.txt draft-ietf-lemonade-imap-notify-02.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 2, line 5 skipping to change at page 2, line 5
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document defines an IMAP extension which allows a client to This document defines an IMAP extension which allows a client to
request specific kinds of unsolicited notifications for specified request specific kinds of unsolicited notifications for specified
mailboxes, such as messages being added to or deleted from mailboxes, such as messages being added to or deleted from
mailboxes. mailboxes.
Internet-draft November 2007 Internet-draft December 2007
1. Conventions Used in This Document 1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Formal syntax is defined by [RFC4234] as extended by [RFC3501] and Formal syntax is defined by [RFC4234] as extended by [RFC3501] and
[RFC4466]. [RFC4466].
skipping to change at page 2, line 41 skipping to change at page 2, line 41
This document defines an IMAP extension that allows clients to This document defines an IMAP extension that allows clients to
express their preferences about unsolicited events generated by the express their preferences about unsolicited events generated by the
server. The extension allows clients to only receive events they server. The extension allows clients to only receive events they
are interested in, while servers know that they don't need to go are interested in, while servers know that they don't need to go
into effort of generating certain types of untagged responses. into effort of generating certain types of untagged responses.
IMAP servers which support this extension advertise the X-DRAFT- IMAP servers which support this extension advertise the X-DRAFT-
W00-NOTIFY extension. W00-NOTIFY extension.
A server implementing this extension is not required to implement
LIST-EXTENDED [LISTEXT], even though a NOTIFY compliant server must
be able to return extended LIST responses defined in [LISTEXT].
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 Command 3. The NOTIFY Command
Arguments: "ADD" or "SET" Arguments: "ADD" or "SET"
optional STATUS indicator optional STATUS indicator
Mailboxes to be watched Mailboxes to be watched
Internet-draft December 2007
Events about which to notify the client Events about which to notify the client
Or Or
Arguments: "NONE" Arguments: "NONE"
Internet-draft November 2007
Responses: Possibly untagged STATUS responses (for ADD/SET) Responses: Possibly untagged STATUS responses (for ADD/SET)
Result: OK - The server will notify the client as requested. Result: OK - The server will notify the client as requested.
NO - NOTIFY too complex or expensive, etc. NO - Unsupported notify event, NOTIFY too complex or
expensive, etc.
BAD - Command unknown, invalid, unsupported or unknown BAD - Command unknown, invalid, unsupported or unknown
arguments. arguments.
The NOTIFY command informs the server that the client listens for The NOTIFY command informs the server that the client listens for
event notifications all the time (even when no command is in event notifications all the time (even when no command is in
progress) and requests the server to notify it about the specified progress) and requests the server to notify it about the specified
set of events. The NOTIFY command has 3 forms. The NOTIFY NONE set of events. The NOTIFY command has 3 forms. The NOTIFY NONE
specifies that the client is not interested in any kind of event specifies that the client is not interested in any kind of event
happening on the server. The NOTIFY ADD prepends one or more events happening on the server. The NOTIFY ADD prepends one or more events
to the list of events which are interesting to the client. The to the list of events which are interesting to the client. The
NOTIFY SET replaces the current list of interesting events with a NOTIFY SET replaces the current list of interesting events with a
new list of events. (Note that NOTIFY SET <events> is effectively new list of events. (Note that NOTIFY SET <events> is effectively
the same as NOTIFY NONE followed by NOTIFY ADD <events>.) the same as NOTIFY NONE followed by NOTIFY ADD <events>.)
Until the NOTIFY command is used for the first time, the server only Until the NOTIFY command is used for the first time, the server only
sends notifications while a command is being processed, and notifies sends notifications while a command is being processed, and notifies
the client about these events on the selected mailbox: (see section the client about these events on the selected mailbox: (see section
5 for definitions): MessageNew, MessageExpunge, FlagChange and (if 5 for definitions): MessageNew, MessageExpunge, FlagChange. It does
[ANNOTATE] is being used) AnnotationChange. It does not notify the not notify the client about any events on other mailboxes.
client about any events on other mailboxes.
The effect of NOTIFY lasts until the next NOTIFY command, or until The effect of a successful NOTIFY command lasts until the next
the IMAP connection is closed. NOTIFY command, or until the IMAP connection is closed.
A successful NOTIFY ADD/SET command MUST cause the server to A successful NOTIFY ADD/SET command MUST cause the server to
immediately return any accumulated changes to the mailbox (if any), immediately return any accumulated changes to the mailbox (if any),
such as flag changes, new or expunged messages. (This is equivalent such as flag changes, new or expunged messages. This is equivalent
to NOOP command being issued by the client just before the NOTIFY to NOOP command being issued by the client just before the NOTIFY
ADD/SET command.) ADD/SET command.
If the NOTIFY command enables MessageNew, MessageExpunge, If the NOTIFY command enables MessageNew, MessageExpunge,
AnnotationChange or FlagChange notification for a mailbox, and the AnnotationChange or FlagChange notification for a mailbox, and the
client has specified the STATUS indicator parameter, then the server client has specified the STATUS indicator parameter, then the server
MUST send a STATUS response for that mailbox before NOTIFY's tagged MUST send a STATUS response for that mailbox before NOTIFY's tagged
OK. If MessageNew is enabled, the STATUS response MUST contain OK. If MessageNew is enabled, the STATUS response MUST contain
MESSAGES, UIDNEXT and UIDVALIDITY. If MessageExpunge is enabled, the MESSAGES, UIDNEXT and UIDVALIDITY. If MessageExpunge is enabled, the
STATUS response MUST contain MESSAGES. If either AnnotationChange or STATUS response MUST contain MESSAGES. If either AnnotationChange or
FlagChange are included, the STATUS response MUST contain FlagChange are included, the STATUS response MUST contain
UIDVALIDITY and HIGHESTMODSEQ. Absence of the STATUS indicator UIDVALIDITY and HIGHESTMODSEQ. Absence of the STATUS indicator
Internet-draft December 2007
parameter allows the client to avoid the additional STATUS parameter allows the client to avoid the additional STATUS
responses. This might be useful if the client has already retrieved responses. This might be useful if the client has already retrieved
this information before 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
Internet-draft November 2007
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 resources and network traffic. mailboxes. This wastes both server and network resources. For
each mailbox specified, the server verifies that the client has
For 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.
- If the name refers to a mailbox which the client can't LIST, the - If the name refers to a mailbox which the client can't LIST, the
server MUST ignore it. For a server that implements [RFC4314] this server MUST ignore it. For a server that implements [RFC4314] this
means that if the client that doesn't have the 'l' (lookup) right means that if the client that doesn't have the 'l' (lookup) right
for the name, then the server MUST ignore the mailbox. This for the name, then the server MUST ignore the mailbox. This
behavior prevents dislosure on potentially confidential behavior prevents dislosure on potentially confidential
skipping to change at page 4, line 46 skipping to change at page 4, line 50
response if the client has no access to any of the specified response if the client has no access to any of the specified
mailboxes and no access can ever be granted in the future (e.g. the mailboxes and no access can ever be granted in the future (e.g. the
client specified an event for 'Subtree Bar/Foo', 'Bar/Foo' doesn't client specified an event for 'Subtree Bar/Foo', 'Bar/Foo' doesn't
exist and LIST returns \Noinferiors for the parent 'Bar'). exist and LIST returns \Noinferiors for the parent 'Bar').
If the notification would be prohibitively expensive for the server If the notification would be prohibitively expensive for the server
(e.g. "notify me of all flag changes in all mailboxes"), the server (e.g. "notify me of all flag changes in all mailboxes"), the server
MAY refuse the command with a tagged NO [NOTIFICATIONOVERFLOW] MAY refuse the command with a tagged NO [NOTIFICATIONOVERFLOW]
response. response.
If the client requests information for events of an unsupported type If the client requests information for events of an unsupported
(e.g. QuotaExceed and the server does not advertise the QUOTA type, the server MUST refuse the command with a tagged NO response
extension defined in [RFC2087]), the server MUST refuse the command (not a BAD). This response SHOULD contain the BADEVENT response
with a tagged BAD response. code, which MUST list names of all events supported by the server.
Internet-draft December 2007
Here's an example: Here's an example:
S: * OK [CAPABILITY IMAP4REV1 NOTIFY] S: * OK [CAPABILITY IMAP4REV1 NOTIFY]
C: a login bob alice C: a login bob alice
Internet-draft November 2007
S: a OK Password matched S: a OK Password matched
C: b notify set status (selected MessageNew (uid C: b notify set status (selected MessageNew (uid
body.peek[header.fields (from to subject)]) (all) body.peek[header.fields (from to subject)]) (all)
MessageExpunge) (subtree Lists MessageNew (uid) (all)) MessageExpunge) (subtree Lists MessageNew (uid) (all))
S: * STATUS Lists/Lemonade (UIDVALIDITY 4 UIDNEXT 9999 MESSAGES S: * STATUS Lists/Lemonade (UIDVALIDITY 4 UIDNEXT 9999 MESSAGES
500) 500)
S: [...] S: [...]
S: * STATUS Lists/Im2000 (UIDVALIDITY 901 UIDNEXT 1 MESSAGES 0) S: * STATUS Lists/Im2000 (UIDVALIDITY 901 UIDNEXT 1 MESSAGES 0)
S: b OK done S: b OK done
C: c select inbox C: c select inbox
skipping to change at page 6, line 5 skipping to change at page 6, line 5
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.
Internet-draft November 2007 Internet-draft December 2007
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 of which an IMAP server can notify This section specifies the events which an IMAP server can notify an
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 MailboxCreate 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 mailbox, the server SHOULD NOT notify the client of the MailboxName
MailboxCreate change. change.
All event types require the 'l' and 'r' rights (see [RFC4314]) on All event types described in this document require the 'l' and 'r'
all observed mailboxes. AdminMailbox and the quota-related event rights (see [RFC4314]) on all observed mailboxes. Servers that
types additionally require the 'a' right. Servers that don't don't implement [RFC4314] should map the above rights to their
implement [RFC4314] should map the above rights to their access access control model.
control model.
If the client instructs the server not to send MessageNew or If the client instructs the server not to send MessageNew or
MessageExpunge for the selected mailbox, the server MUST still send MessageExpunge for the selected mailbox, the server MUST still send
EXISTS and EXPUNGE responses as required by IMAP (see [RFC3501] EXISTS and EXPUNGE responses as required by IMAP (see [RFC3501]
section 7). In other words, MessageExpunge instructs the server to section 7). In other words, MessageExpunge instructs the server to
notify the client immediately, and the lack of MessageExpunge notify the client immediately, and the lack of MessageExpunge
instructs the server to notify the client during execution of the instructs the server to notify the client during execution of the
next command as specified in [RFC3501]. MessageNew is handled next command as specified in [RFC3501]. MessageNew is handled
similarly by the server. similarly by the server.
5.1. FlagChange and AnnotationChange 5.1. FlagChange and AnnotationChange
If the flag/annotation change happens in the selected mailbox, the If the flag/annotation change happens in the selected mailbox, the
server notifies the client by sending an unsolicited FETCH response, server MUST notify the client by sending an unsolicited FETCH
which MUST include UID and FLAGS/ANNOTATION FETCH data items. It MAY response, which MUST include UID and FLAGS/ANNOTATION FETCH data
also send new FLAGS and/or OK [PERMANENTFLAGS ...] responses. items. It MAY also send new FLAGS and/or OK [PERMANENTFLAGS ...]
responses.
If the change happens in another mailbox, then the response depends If the change happens in another mailbox, then the response depends
on whether CONDSTORE [RFC4551] is being used. If so, the server on whether CONDSTORE [RFC4551] is being used. If so, the server
sends a STATUS (HIGHESTMODSEQ) response. (Note that whenever mailbox sends a STATUS (HIGHESTMODSEQ) response. Note that whenever mailbox
UIDVALIDITY changes, the server MUST also include UIDVALIDITY in the UIDVALIDITY changes, the server MUST also include UIDVALIDITY in the
STATUS response.) If not, the server does not notify the client. STATUS response. If CONDSTORE is not used, the server does not
notify the client.
FlagChange covers the MessageRead, MessageTrash, FlagsSet and FlagChange covers the MessageRead, MessageTrash, FlagsSet and
FlagsClear events in [MSGEVENT]. FlagsClear events in [MSGEVENT].
[[Open Issue: Filip Navara requested for STATUS (UNSEEN) to be sent Internet-draft December 2007
Internet-draft November 2007
[[Open Issue: Filip Navara requested for STATUS (UNSEEN) to be sent
for MessageRead. Arnt considers that unsound, since it involves for MessageRead. Arnt considers that unsound, since it involves
processing all messages in a mailbox after an event affecting only processing all messages in a mailbox after an event affecting only
one message, and since it's not reliable anyway.]] one message, and since it's not reliable anyway.]]
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, with CONDSTORE in use: And in another, with CONDSTORE in use:
S: * STATUS Lists/Lemonade (HIGHESTMODSEQ 65666665) S: * STATUS Lists/Lemonade (HIGHESTMODSEQ 65666665)
skipping to change at page 7, line 52 skipping to change at page 8, line 5
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, without CONDSTORE:
S: * STATUS Lists/Lemonade (UIDNEXT 10002 MESSAGES 503) S: * STATUS Lists/Lemonade (UIDNEXT 10002 MESSAGES 503)
5.3. MessageExpunge Internet-draft December 2007
Internet-draft November 2007 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 being used). is being used).
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 CONDSTORE is being used, HIGHESTMODSEQ MUST be
included in the STATUS response. included in the STATUS response.
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 (it must only 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:
S: * STATUS misc (UIDNEXT 999 MESSAGES 554) S: * STATUS misc (UIDNEXT 999 MESSAGES 554)
5.4. QuotaExceed, QuotaWithin and QuotaChange 5.4. MailboxName
[[Alexey: I liked the following version more: If the client has
permission to perform GETQUOTA (defined in [RFC2087]), the server
sends an unsolicited QUOTA response containing the new quotas. ]]
The server sends an unsolicited QUOTA response containing the new
quotas. The server also sends an unsolicited QUOTAROOT response, so
that the client can correlate the affected mailbox to the quota
root.
These notifications are sent if the client has requested
notifications for at least one affected mailbox.
Example:
S: * QUOTAROOT INBOX ""
S: * QUOTA "" (STORAGE 10 512)
In this example the quota root named "" (see [RFC2087] for the
definition of quota root) governs the mailbox INBOX. Note that the
server may return the QUOTAROOT and the QUOTA response in any order.
Internet-draft November 2007
5.5. MailboxCreate and MailboxDelete These notifications are sent if an affected mailbox name was created
(with CREATE), deleted (with DELETE) or renamed (with RENAME). If a
mailbox is created or deleted, the mailbox itself and its parent are
considered to be affected.
The server notifies the client by sending an unsolicited LIST The server notifies the client by sending an unsolicited LIST
responses for each affected mailbox name. If the mailbox name does response for each affected mailbox name. If the mailbox name does
not refer to a mailbox after the event, the \Nonexistent flag MUST not refer to a mailbox after the event, the \Nonexistent flag MUST
be included. be included.
These notifications are sent if the client has requested For each selectable [[Alexey: is "selectable" important?]] mailbox
notifications for at least one affected mailbox. In the case of renamed, the server sends an extended LIST response [LISTEXT] for
MailboxCreate, the mailbox itself and its parent are considered to the new mailbox name, containing the OLDNAME extended data item with
be affected. In the case of MailboxDelete, all deleted mailboxes and the old mailbox name. When a mailbox is renamed, its children are
their parent(s) are considered to be affected. renamed too. No additional MailboxName events are sent for children
in this case. When INBOX is renamed, a new INBOX is assumed to be
created. No MailboxName event must be sent for INBOX in this case.
Internet-draft December 2007
Example of a newly created mailbox: Example of a newly created mailbox:
S: * LIST () "/" "NewMailbox" S: * LIST () "/" "NewMailbox"
And a deleted mailbox: And a deleted mailbox:
S: * LIST (\NonExistent) "/" "INBOX.DeletedMailbox" S: * LIST (\NonExistent) "/" "INBOX.DeletedMailbox"
5.6. MailboxRename Example of a renamed mailbox:
For each selectable mailbox renamed, the server sends an extended
LIST response [LISTEXT] for the new mailbox name, containing the
OLDNAME extended data item with the old mailbox name. When a
mailbox is renamed, its children are renamed too. No additional
MailboxRename events are sent for children in this case. When INBOX
is renamed, a new INBOX is assumed to be created. No MailboxCreate
event must be sent for INBOX in this case.
Example:
S: * LIST () "/" "NewMailbox" ("OLDNAME" ("OldMailbox")) S: * LIST () "/" "NewMailbox" ("OLDNAME" ("OldMailbox"))
5.7. SubscriptionChange 5.5. SubscriptionChange
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.8. MailboxMetadataChange 5.6. MailboxMetadataChange
The server sends an unsolicited LIST response including METADATA. If
Internet-draft November 2007
possible, only the changed metadata should be included, but if The server sends an unsolicited LIST response including METADATA (as
necessary, all metadata must be included. per Section 4.3.1 of [METADATA]). If possible, only the changed
metadata should be included, but if necessary, all metadata must be
included.
Example: Example:
S: * LIST "/" "INBOX" (METADATA (/comment (value.priv "My S: * LIST "/" "INBOX" (METADATA (/comment))
comment")))
5.9. AdminMailbox
If the user has the right to perform GETACL (see [RFC4314]) after
the event, the server notifies the client by sending an unsolicited
ACL response with the mailbox' new rights.
If the user didn't have the right to perform GETACL, but later on
such right was granted, then the server MUST send the ACL response
to notify the client that it has access to the corresponding
mailbox.
If the user loses the right to perform GETACL as a result of an ACL 5.7. ServerMetadataChange
change, the server MUST NOT send the ACL response. Instead it MUST
send an extended LIST response containing the \NonExistent mailbox
attribute.
In all other cases, the server does not notify the client. The server sends an unsolicited METADATA response (as per Section
4.5.2 of [METADATA]). Only the names of changed metadata entries
SHOULD be returned in such METADATA responses.
Example: Example:
S: * ACL INBOX Fred rwipslxcetda David lrswideta S: * METADATA (/comment)
5.10. 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
Internet-draft December 2007
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:
S: * OK [NOTIFICATIONOVERFLOW] ...A comment can go here... S: * OK [NOTIFICATIONOVERFLOW] ...A comment can go here...
5.11. ACL Changes 5.9. ACL Changes
Even if NOTIFY succeeds, it is still possible to lose access to the Even if NOTIFY succeeds, it is still possible to loose access to the
mailboxes monitoried at a later time. If this happens, the server mailboxes monitoried at a later time. If this happens, the server
MUST silently stop monitoring these mailboxes. If access is later MUST silently stop monitoring these mailboxes. If access is later
Internet-draft November 2007
granted, the server MUST restart event monitoring. granted, the server MUST restart event monitoring.
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.
If the client specifies monitoring of the same mailbox several If the client specifies monitoring of the same mailbox several
times, the first specification wins. A common example is asking for times, the first specification wins. A common example is asking 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 MessageExpunge events for all In this example, the client asks for MessageExpunge events for all
personal mailboxes except the selected mailbox: personal mailboxes except the selected mailbox:
skipping to change at page 11, line 38 skipping to change at page 11, line 4
mailbox. mailbox.
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
Internet-draft December 2007
namespace(s) to which messages may be delivered by an MDA (see namespace(s) to which messages may be delivered by an MDA (see
[EMAIL-ARCH], particularly section 4.3.3). [EMAIL-ARCH], particularly section 4.3.3).
If the IMAP server cannot easily compute this set, it MUST treat If the IMAP server cannot easily compute this set, it MUST treat
"inboxes" as equivalent to "personal". "inboxes" as equivalent to "personal".
6.4 Subscribed 6.4 Subscribed
Subscribed refers to all mailboxes subscribed by the user. Subscribed refers to all mailboxes subscribed by the user.
If the subscription list changes, the list MUST be reevaluated. If the subscription list changes, the server MUST reevaluate the
list.
Internet-draft November 2007
6.5 Subtree 6.5 Subtree
Subtree is followed by a mailbox name or list of mailbox names. A Subtree is followed by a mailbox name or list of mailbox names. A
subtree refers to all selectable mailboxes which are subordinate to subtree refers to all selectable mailboxes which are subordinate to
the specified mailbox plus the mailbox itself. the specified mailbox plus the mailbox itself.
[[Open Issue: Making this "all selectable mailboxes" makes it easy [[Open Issue: Making this "all selectable mailboxes" makes it easy
to implement this well. The pattern can be evaluated at NOTIFY time to implement this well. The pattern can be evaluated at NOTIFY time
and notification information affixed to the mailboxes in RAM. Fine. and notification information affixed to the mailboxes in RAM. Fine.
But what about "notify me if any mailboxes are created whose name But what about "notify me if any mailboxes are created whose name
contains the letters xxx"? Not useful IMO...? (writes arnt)]] contains the letters xxx"? Not useful IMO...? (writes arnt)]]
6.6 Mailboxes 6.6 Mailboxes
Mailboxes is followed by a mailbox name or list of mailbox names. Mailboxes is followed by a mailbox name or a list of mailbox names.
The server MUST NOT do wildcard expansion. This means there is no The server MUST NOT do wildcard expansion. This means there is no
special treatment for the LIST wildcard characters ('*' and '%') if special treatment for the LIST wildcard characters ('*' and '%') if
they are present in mailbox names. they are present in mailbox names.
7. Formal Syntax 7. Formal Syntax
The following syntax specification uses the Augmented Backus-Naur The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) notation as specified in [RFC4234]. [RFC3501] defines Form (ABNF) notation as specified in [RFC4234]. [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". data", "resp-text-code" and "search-key".
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.
Internet-draft December 2007
capability =/ "X-DRAFT-W00-NOTIFY" capability =/ "X-DRAFT-W00-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-add / notify-set / notify-none) (notify-add / notify-set / notify-none)
notify-add = "ADD" [status-indicator] SP event-groups notify-add = "ADD" [status-indicator] SP event-groups
; Add (prepend) registered notification ; Add (prepend) registered notification
; events to the list of notification ; events to the list of notification
; events. Newer events override older ; events. Newer events override older
; events. ; events.
[[Alexey: what about "most specific" event [[Alexey: what about "most specific" event
Internet-draft November 2007
overriding a pattern?]] overriding a pattern?]]
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"
; Cancel all registered notification ; Cancel all registered notification
; events. The client is not interested ; events. The client is not interested
; in receiving any events. ; in receiving any events.
skipping to change at page 13, line 40 skipping to change at page 13, line 4
( "subtree" SP one-or-more-mailbox ) / ( "subtree" SP one-or-more-mailbox ) /
( "mailboxes" SP one-or-more-mailbox ) ( "mailboxes" SP one-or-more-mailbox )
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
Internet-draft December 2007
/ 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) ")"
SP message-match-criteria ) SP message-match-criteria )
/ "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].
Internet-draft November 2007 mailbox-event = "MailboxName" /
mailbox-event = "MailboxCreate" / "MailboxDelete" /
"MailboxRename" /
"SubscriptionChange" / "MailboxMetadataChange" "SubscriptionChange" / "MailboxMetadataChange"
/ "QuotaChange" / "AdminMailbox"
; "SubscriptionChange" includes ; "SubscriptionChange" includes
; MailboxSubscribe and MailboxUnSubscribe ; MailboxSubscribe and MailboxUnSubscribe.
; "MailboxName" includes MailboxCreate,
; "MailboxDelete" and "MailboxRename".
user-event = "QuotaExceed" / "QuotaWithin" user-event = "ServerMetadataChange"
event-ext = atom event-ext = atom
;; For future extensions ;; For future extensions
oldname-extended-item = "OLDNAME" SP "(" mailbox ")" oldname-extended-item = "OLDNAME" SP "(" mailbox ")"
;; Extended data item (mbox-list-extended-item) ;; Extended data item (mbox-list-extended-item)
;; 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
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) ")"
Internet-draft December 2007
8. Security considerations 8. Security considerations
It is very easy for a client to deny itself service using NOTIFY: 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, 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 but with a big server can swamp the client's network connection or
processing capability. In the worst case, the server's processing processing capability. In the worst case, the server's processing
could also degrade the service it offers to other clients. could also degrade the service it offers to other clients.
Server authors should be aware that if a client issues requests and Server authors should be aware that if a client issues requests and
skipping to change at page 15, line 5 skipping to change at page 14, line 32
to delete sensitive messages using programs like imapfilter. Using to delete sensitive messages using programs like imapfilter. Using
[SIEVE] or similar is much better. [SIEVE] or similar is much better.
9. IANA considerations 9. IANA considerations
The IANA is requested to add NOTIFY to the list of IMAP extensions, The IANA is requested to add NOTIFY to the list of IMAP extensions,
http://www.iana.org/assignments/imap4-capabilities. http://www.iana.org/assignments/imap4-capabilities.
9.1. Initial LIST-EXTENDED extended data item registrations 9.1. Initial LIST-EXTENDED extended data item registrations
Internet-draft November 2007
It is requested that the following entry be added to the LIST- It is requested that the following entry be added to the LIST-
EXTENDED extended data item registry [LISTEXT]: EXTENDED extended data item registry [LISTEXT]:
To: iana@iana.org Subject: Registration of OLDNAME LIST-EXTENDED To: iana@iana.org Subject: Registration of OLDNAME LIST-EXTENDED
extended data item extended data item
LIST-EXTENDED extended data item tag: OLDNAME LIST-EXTENDED extended data item tag: OLDNAME
LIST-EXTENDED extended data item description: The OLDNAME extended LIST-EXTENDED extended data item description: The OLDNAME extended
data item describes the old mailbox name for the mailbox identified data item describes the old mailbox name for the mailbox identified
by the LIST response. by the LIST response.
Which LIST-EXTENDED option(s) (and their types) causes this extended Which LIST-EXTENDED option(s) (and their types) causes this extended
data item to be returned (if any): none data item to be returned (if any): none
Published specification : RFC XXXX, Section 5.6. Published specification : RFC XXXX, Section 5.4.
Security considerations: none Security considerations: none
Intended usage: COMMON Intended usage: COMMON
Person and email address to contact for further information: Person and email address to contact for further information:
Internet-draft December 2007
Alexey Melnikov <Alexey.Melnikov@isode.com> Alexey Melnikov <Alexey.Melnikov@isode.com>
Owner/Change controller: iesg@ietf.org Owner/Change controller: iesg@ietf.org
10. Acknowedgements 10. Acknowedgements
The authors gratefully acknowledge the help of Peter Coates, Dave The authors gratefully acknowledge the help of Peter Coates, Dave
Cridland, Mark Crispin, Cyrus Daboo and Abhijit Menon-Sen. Various Cridland, Mark Crispin, Cyrus Daboo, Abhijit Menon-Sen and Eric
example lines are copied from other RFCs. Burger. Various example lines are copied from other RFCs.
This document builds on one published and two unpublished drafts by This document builds on one published and two unpublished drafts by
the same authors. the same authors.
11. Normative References 11. Normative References
[RFC2087] Myers, "IMAP4 QUOTA extension", RFC 2087, January 1997.
[RFC2119] Bradner, "Key words for use in RFCs to Indicate [RFC2119] Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, Harvard University, March Requirement Levels", RFC 2119, Harvard University, March
1997. 1997.
[RFC2177] Leiba, "IMAP4 IDLE Command", RFC 2177, IBM, June 1997. [RFC2177] Leiba, "IMAP4 IDLE Command", RFC 2177, IBM, June 1997.
[RFC3501] Crispin, "Internet Message Access Protocol - Version [RFC3501] Crispin, "Internet Message Access Protocol - Version
Internet-draft November 2007
4rev1", RFC 3501, University of Washington, June 2003. 4rev1", RFC 3501, University of Washington, June 2003.
[RFC4234] Crocker, Overell, "Augmented BNF for Syntax [RFC4234] Crocker, Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, Brandenburg Specifications: ABNF", RFC 4234, Brandenburg
Internetworking, Demon Internet Ltd, October 2005. Internetworking, Demon Internet Ltd, October 2005.
[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.
[ANNOTATE] Gellens, Daboo, "IMAP ANNOTATE Extension", draft-ietf- [LISTEXT] Leiba, Melnikov, "IMAP4 List Command Extensions",
imapext-annotate-16 (work in progress). draft-ietf-imapext-list-extensions-18 (work in progress),
IBM, September 2006.
[LISTEXT] Leiba, Melnikov, "IMAP4 List Command Extensions", draft- [METADATA] Daboo, "IMAP METADATA Extension",
ietf-imapext-list-extensions-18 (work in progress), IBM, draft-daboo-imap-annotatemore-12 (work in progress),
September 2006. Apple Computer, Inc., December 2007.
[METADATA] Daboo, "IMAP METADATA Extension", draft-daboo-imap- Internet-draft December 2007
annotatemore-11 (work in progress), Apple Computer, Inc.,
February 2007.
[MSGEVENT] Newman, "Internet Message Store Events", draft-ietf- [MSGEVENT] Newman, "Internet Message Store Events",
lemonade-msgevent-03.txt (work in progress), Sun, July draft-ietf-lemonade-msgevent-03.txt (work in progress),
2007. Sun, July 2007.
12. Informative References 12. Informative References
[SIEVE] Showalter, "Sieve: A Mail Filtering Language", RFC 3028, [SIEVE] Showalter, "Sieve: A Mail Filtering Language", RFC 3028,
Mirapoint Inc, January 2001. Mirapoint Inc, January 2001.
[QRESYNC] Melnikov, Cridland, Wilson, "IMAP4 Extensions for Quick [QRESYNC] Melnikov, Cridland, Wilson, "IMAP4 Extensions for Quick
Mailbox Resynchronization", draft-ietf-lemonade- Mailbox Resynchronization",
reconnect-client-05.txt (work in progress), February draft-ietf-lemonade-reconnect-client-05.txt (work in
2007. progress), February 2007.
[EMAIL-ARCH] Crocker, "Internet Mail Architecture", draft-crocker-
email-arch-09 (work in progress), March 2007.
Internet-draft November 2007 [EMAIL-ARCH] Crocker, "Internet Mail Architecture",
draft-crocker-email-arch-09 (work in progress), March
2007.
13. Authors' Addresses 13. 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
UK UK
skipping to change at page 18, line 5 skipping to change at page 17, line 5
Email: Alexey.Melnikov@isode.com Email: Alexey.Melnikov@isode.com
Arnt Gulbrandsen Arnt Gulbrandsen
Oryx Mail Systems GmbH Oryx Mail Systems GmbH
Schweppermannstr. 8 Schweppermannstr. 8
D-81671 Muenchen D-81671 Muenchen
Germany Germany
Email: arnt@oryx.com Email: arnt@oryx.com
Internet-draft November 2007 Internet-draft December 2007
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights. it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC Information on the procedures with respect to rights in RFC
 End of changes. 70 change blocks. 
166 lines changed or deleted 140 lines changed or added

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