draft-ietf-lemonade-imap-notify-06.txt   draft-ietf-lemonade-imap-notify-07.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.
June 21, 2008 August 18, 2008
The IMAP NOTIFY Extension The IMAP NOTIFY Extension
draft-ietf-lemonade-imap-notify-06.txt draft-ietf-lemonade-imap-notify-07.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 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-
Draft Shadow Directories can be accessed at Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft expires in September 2008. This Internet-Draft expires in February 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
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.
[[Add Updates: RFC-CONTEXT to the headers]] [[Add Updates: RFC-CONTEXT to the headers]]
Internet-draft August 2008
Table of Contents
1. Conventions Used in This Document . . . . . . . . . . . . . . 3
2. Overview and rationale . . . . . . . . . . . . . . . . . . . . 3
3. The NOTIFY extension . . . . . . . . . . . . . . . . . . . . . 4
3.1. The NOTIFY Command . . . . . . . . . . . . . . . . . . . . 4
4. Interaction with the IDLE Command . . . . . . . . . . . . . . 8
5. Event Types . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. FlagChange and AnnotationChange . . . . . . . . . . . . . . 9
5.2. MessageNew . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3. MessageExpunge . . . . . . . . . . . . . . . . . . . . . . 11
5.4. MailboxName . . . . . . . . . . . . . . . . . . . . . . . . 11
5.5. SubscriptionChange . . . . . . . . . . . . . . . . . . . . 12
5.6. MailboxMetadataChange . . . . . . . . . . . . . . . . . . . 12
5.7. ServerMetadataChange . . . . . . . . . . . . . . . . . . . 13
5.8. Notification Overflow . . . . . . . . . . . . . . . . . . . 13
5.9. ACL Changes . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Mailbox Specification . . . . . . . . . . . . . . . . . . . . 14
6.1. Mailbox specifiers affecting the currently selected mailbox 14
6.2. Personal . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.3. Inboxes . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.4. Subscribed . . . . . . . . . . . . . . . . . . . . . . . . 15
6.5. Subtree . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.6. Mailboxes . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Extension to SEARCH and SORT commands . . . . . . . . . . . . 16
8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 16
9. Security considerations . . . . . . . . . . . . . . . . . . . 19
10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 19
10.1. Initial LIST-EXTENDED extended data item registrations . 19
11. Acknowedgements . . . . . . . . . . . . . . . . . . . . . . . 20
12. Normative References . . . . . . . . . . . . . . . . . . . . . 20
13. Informative References . . . . . . . . . . . . . . . . . . . . 21
14. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 23
Internet-draft August 2008
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 [RFC5234] as extended by [RFC3501] and Formal syntax is defined by [RFC5234] as extended by [RFC3501] and
[RFC4466]. [RFC4466].
The acronym MSN stands for Message Sequence Numbers (see Section The acronym MSN stands for Message Sequence Numbers (see Section
2.3.1.2 of [RFC3501]). 2.3.1.2 of [RFC3501]).
Example lines prefaced by "C:" are sent by the client and ones Example lines prefaced by "C:" are sent by the client and ones
prefaced by "S:" by the server. "[...]" means elision. prefaced by "S:" by the server. "[...]" means elision.
2. Overview and rationale 2. Overview and rationale
The IDLE command (defined in [RFC2177]) provides a way for the The IDLE command (defined in [RFC2177]) provides a way for the
client to go into a mode where the IMAP server pushes notifications client to go into a mode where the IMAP server pushes
about IMAP mailstore events for the selected mailbox. However, the notifications about IMAP mailstore events for the selected
IDLE extension doesn't restrict or control which server events can mailbox. However, the IDLE extension doesn't restrict or
be sent, or what information the server sends in response to each control which server events can be sent, or what information
event. Also, IDLE only applies to the selected mailbox, thus the server sends in response to each event.
requiring an additional TCP connection per mailbox. 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 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
server. The extension allows clients to only receive events they the server. The extension allows clients to only receive events
are interested in, while servers know that they don't need to go they are interested in, while servers know that they don't need
into effort of generating certain types of untagged responses. to go into effort of generating certain types of untagged responses.
Without the NOTIFY command defined in this document, an IMAP server Without the NOTIFY command defined in this document, an IMAP server
will only send information about mailstore changes to the client in will only send information about mailstore changes to the client in
the following cases: the following cases:
- as the result of a client command (e.g. FETCH responses to - as the result of a client command (e.g. FETCH responses to
a FETCH or STORE command), a FETCH or STORE command),
- unsolicited responses sent just before the end of a command - unsolicited responses sent just before the end of a command
(e.g. EXISTS or EXPUNGE) as the result of changes in other (e.g. EXISTS or EXPUNGE) as the result of changes in other
sessions, and sessions, and
- during an IDLE command. - during an IDLE command.
The NOTIFY command extends what information may be returned in those The NOTIFY command extends what information may be returned in those
last two cases, and also permits and requires the server to send last two cases, and also permits and requires the server to send
information about updates between command. The NOTIFY command also information about updates between command. The NOTIFY command also
allows for the client to extend what information is sent unsolicited allows for the client to extend what information is sent unsolicited
about the selected mailbox, and to request some update information about the selected mailbox, and to request some update information
Internet-draft August 2008
to be sent regarding other mailboxes. to be sent regarding other mailboxes.
For the new messages delivered to or appended to the selected For the new messages delivered to or appended to the selected
mailbox, the NOTIFY command can be used to request that a set of mailbox, the NOTIFY command can be used to request that a set of
attributes be sent to the client in an unsolicited FETCH response. attributes be sent to the client in an unsolicited FETCH response.
This allows a client to be passive recipient of events and new mail, This allows a client to be passive recipient of events and new mail,
and be able to maintain full synchronisation without having to issue and be able to maintain full synchronisation without having to issue
any subsequent commands except to modify the state of the mailbox on any subsequent commands except to modify the state of the mailbox on
the server. the server.
skipping to change at page 3, line 38 skipping to change at page 4, line 37
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-
W06-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].
<<Should QRESYNC be a required dependency for this 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"
Responses: Possibly untagged STATUS responses (for SET) Responses: Possibly untagged STATUS responses (for SET)
Result: OK - The server will notify the client as requested. Result: OK - The server will notify the client as requested.
Internet-draft August 2008
NO - Unsupported notify event, NOTIFY too complex or NO - Unsupported notify event, NOTIFY too complex or
expensive, etc. 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 two forms. NOTIFY NONE set of events. The NOTIFY command has two forms. 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
skipping to change at page 5, line 10 skipping to change at page 6, line 4
The client can also request notifications on other mailboxes by name The client can also request notifications on other mailboxes by name
or by a limited mailbox pattern match. Message related or by a limited mailbox pattern match. Message related
notifications returned for the currently selected mailbox will be notifications returned for the currently selected mailbox will be
those specified by the SELECTED/SELECTED-DELAYED mailbox specifier, those specified by the SELECTED/SELECTED-DELAYED mailbox specifier,
even if the selected mailbox also appears by name (or matches a even if the selected mailbox also appears by name (or matches a
pattern) in the command. Non message related notifications are pattern) in the command. Non message related notifications are
controlled by mailbox specifiers other than SELECTED/SELECTED- controlled by mailbox specifiers other than SELECTED/SELECTED-
DELAYED. DELAYED.
If the NOTIFY command enables MessageNew, MessageExpunge, If the NOTIFY command enables MessageNew, MessageExpunge,
Internet-draft August 2008
AnnotationChange or FlagChange notification for a mailbox other than AnnotationChange or FlagChange notification for a mailbox other than
the currently selected mailbox, and the client has specified the the currently selected mailbox, and the client has specified the
STATUS indicator parameter, then the server MUST send a STATUS STATUS indicator parameter, then the server MUST send a STATUS
response for that mailbox before NOTIFY's tagged OK. If MessageNew response for that mailbox before NOTIFY's tagged OK. If MessageNew
is enabled, the STATUS response MUST contain MESSAGES, UIDNEXT and is enabled, the STATUS response MUST contain MESSAGES, UIDNEXT and
UIDVALIDITY. If MessageExpunge is enabled, the STATUS response MUST UIDVALIDITY. If MessageExpunge is enabled, the STATUS response MUST
contain MESSAGES. If either AnnotationChange or FlagChange are contain MESSAGES. If either AnnotationChange or FlagChange are
included and the server also supports CONDSTORE [RFC4551] and/or included and the server also supports CONDSTORE [RFC4551] and/or
QRESYNC [QRESYNC] extension, the STATUS response MUST contain QRESYNC [QRESYNC] extension, the STATUS response MUST contain
UIDVALIDITY and HIGHESTMODSEQ. Absence of the STATUS indicator UIDVALIDITY and HIGHESTMODSEQ. Absence of the STATUS indicator
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
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 may reduce client's battery life. Also this wastes
each mailbox specified, the server verifies that the client has both server and network resources. For each mailbox
access using the following test: 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 - 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
information to clients which don't have rights to know it. information to clients which don't have rights to know it.
skipping to change at page 6, line 9 skipping to change at page 7, line 4
The server SHOULD return the tagged OK response if the client has The server SHOULD return the tagged OK response if the client has
access to at least one of the mailboxes specified in the current access to at least one of the mailboxes specified in the current
list of interesting events. The server MAY return the tagged NO list of interesting events. The server MAY return the tagged NO
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
Internet-draft August 2008
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 If the client requests information for events of an unsupported
type, the server MUST refuse the command with a tagged NO response type, the server MUST refuse the command with a tagged NO response
(not a BAD). This response SHOULD contain the BADEVENT response (not a BAD). This response SHOULD contain the BADEVENT response
code, which MUST list names of all events supported by the server. code, which MUST list names of all events supported by the server.
Here's an example: Here's an example:
skipping to change at page 7, line 9 skipping to change at page 8, line 4
necessary STATUS information for all mailboxes below necessary STATUS information for all mailboxes below
the Lists mailbox and because "notify set status" would the Lists mailbox and because "notify set status" would
cause STATUS responses for *all* mailboxes specified in cause STATUS responses for *all* mailboxes specified in
the NOTIFY command, including the ones for which the the NOTIFY command, including the ones for which the
client already knows STATUS information, the client client already knows STATUS information, the client
issues explicit STATUS request for the mailbox to be issues explicit STATUS request for the mailbox to be
added to the watch list, followed by the NOTIFY SET added to the watch list, followed by the NOTIFY SET
without the STATUS parameter.) without the STATUS parameter.)
C: d STATUS misc (UIDVALIDITY UIDNEXT MESSAGES) C: d STATUS misc (UIDVALIDITY UIDNEXT MESSAGES)
S: * STATUS misc (UIDVALIDITY 1 UIDNEXT 999) S: * STATUS misc (UIDVALIDITY 1 UIDNEXT 999)
Internet-draft August 2008
S: d STATUS completed S: d STATUS completed
C: e notify set (selected MessageNew (uid C: e notify set (selected MessageNew (uid
body.peek[header.fields (from to subject)]) MessageExpunge) body.peek[header.fields (from to subject)]) MessageExpunge)
(subtree Lists MessageNew) (mailboxes misc MessageNew) (subtree Lists MessageNew) (mailboxes misc MessageNew)
S: e OK done S: e OK done
4. Interaction with the IDLE Command 4. Interaction with the IDLE Command
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
skipping to change at page 8, line 10 skipping to change at page 9, line 4
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 and/or AnnotationChange event is specified, MessageNew If FlagChange and/or AnnotationChange event is specified, MessageNew
and MessageExpunge MUST also be specified by the client. Otherwise and MessageExpunge MUST also be specified by the client. Otherwise
the server MUST respond 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
Internet-draft August 2008
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.
The client can instruct the server not to send an event by omitting 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, the necessary event from the list of events specified in NOTIFY SET,
by using NONE event specifier in the NOTIFY SET or by using NOTIFY by using NONE event specifier in the NOTIFY SET or by using NOTIFY
NONE. In particular NOTIFY SET ... NONE can be used as a snapshot NONE. In particular NOTIFY SET ... NONE can be used as a snapshot
facility by clients. facility by clients.
5.1. FlagChange and AnnotationChange 5.1. FlagChange and AnnotationChange
skipping to change at page 8, line 35 skipping to change at page 9, line 32
...] 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 server responds If the change happens in another mailbox, then the server responds
with a STATUS response. The exact content of the STATUS response with a STATUS response. The exact content of the STATUS response
depends on various factors. If CONDSTORE [RFC4551] and/or QRESYNC depends on various factors. If CONDSTORE [RFC4551] and/or QRESYNC
[QRESYNC] is being used, then the server sends a STATUS response [QRESYNC] is enabled by the client, then the server sends a STATUS
that includes at least HIGHESTMODSEQ and UIDVALIDITY status data response that includes at least HIGHESTMODSEQ and UIDVALIDITY status
items. If the number of messages with \Seen flag changes, the data items. If the number of messages with the \Seen flag changes,
server MAY also include the UNSEEN data item in the STATUS response. the server MAY also include the UNSEEN data item in the STATUS
If CONDSTORE/QRESYNC is not used and the server choses not to response. If CONDSTORE/QRESYNC is not enabled by the client and the
include the UNSEEN, the server does not notify the client. <<Open server choses not to include the UNSEEN, the server does not notify
Issue: should there be a way to require the server to return the client. When this event is requested the server MUST notify the
UNSEEN?>> When this event is requested the server MUST notify the
client about mailbox UIDVALIDITY changes. This is done by sending a client about mailbox UIDVALIDITY changes. This is done by sending a
STATUS response that includes UIDVALIDITY. 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 mailbox, with CONDSTORE in use:
S: * STATUS Lists/Lemonade (HIGHESTMODSEQ 65666665 UIDVALIDITY S: * STATUS Lists/Lemonade (HIGHESTMODSEQ 65666665 UIDVALIDITY
101) 101)
5.2. MessageNew 5.2. MessageNew
Internet-draft August 2008
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
connection, for instance as the result of an APPEND or COPY command connection, for instance as the result of an APPEND or COPY command
to the selected mailbox performed by the client itself. The server to the selected mailbox performed by the client itself. The server
MAY also send a RECENT response, if the server marks the message as MAY also send a RECENT response, if the server marks the message as
skipping to change at page 9, line 45 skipping to change at page 10, line 42
an unsolicited STATUS (UIDNEXT MESSAGES) response for the relevant an unsolicited STATUS (UIDNEXT MESSAGES) response for the relevant
mailbox. If the CONDSTORE extension [RFC4551] and/or the QRESYNC mailbox. If the CONDSTORE extension [RFC4551] and/or the QRESYNC
extension [QRESYNC] is enabled, the HIGHESTMODSEQ status data item extension [QRESYNC] is enabled, the HIGHESTMODSEQ status data item
MUST be included in the STATUS 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 with
number of messages can increase at any time, and therefore the the SELECTED mailbox specifier, the number of messages can increase
client cannot refer to a specific message using the MSN/UID '*'. at any time, and therefore the 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 mailbox, without CONDSTORE enabled: And in another mailbox, without CONDSTORE enabled:
S: * STATUS Lists/Lemonade (UIDNEXT 10002 MESSAGES 503) S: * STATUS Lists/Lemonade (UIDNEXT 10002 MESSAGES 503)
Internet-draft August 2008
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 the QRESYNC [QRESYNC] extension is enabled, the relevant mailbox. If the QRESYNC [QRESYNC] extension is enabled, the
HIGHESTMODSEQ data item MUST be included in the STATUS response as HIGHESTMODSEQ data item MUST be included in the STATUS response as
well. well.
Note that if a client requests MessageExpunge, the meaning of a MSN Note that if a client requests MessageExpunge with the SELECTED
can change at any time, so the client cannot use MSNs in commands mailbox specifier, the meaning of a MSN can change at any time, so
anymore. For example, such a client cannot use FETCH, but it has to the client cannot use MSNs in commands anymore. For example, such a
use UID FETCH. The meaning of '*' can also change when messages are client cannot use FETCH, but it has to use UID FETCH. The meaning of
added or expunged. A client wishing to keep using MSNs MUST NOT '*' can also change when messages are added or expunged. A client
request the MessageExpunge event. wishing to keep using MSNs can either use the SELECTED-DELAYED
mailbox specifier, or can avoid using the MessageExpunge event
entirely.
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 mailbox, when QRESYNC is not enabled: 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 direct parent (whether it is an
affected. existing mailbox or not) 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
response for each affected mailbox name. If, after the event, the response for each affected mailbox name. If, after the event, the
mailbox name does not refer to a mailbox accessible to the client, mailbox name does not refer to a mailbox accessible to the client,
Internet-draft August 2008
the \Nonexistent flag MUST be included. the \Nonexistent flag MUST be included.
For each LISTable mailbox renamed, the server sends an extended LIST For each LISTable mailbox renamed, the server sends an extended LIST
response [LISTEXT] for the new mailbox name, containing the OLDNAME response [LISTEXT] for the new mailbox name, containing the OLDNAME
extended data item with the old mailbox name. When a mailbox is extended data item with the old mailbox name. When a mailbox is
renamed, its children are renamed too. No additional MailboxName renamed, its children are renamed too. No additional MailboxName
events are sent for children in this case. When INBOX is renamed, a 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 new INBOX is assumed to be created. No MailboxName event is sent
sent for INBOX in this case. 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]). The server SHOULD also include
\HasChildren/\HasNoChildren attributes [LISTEXT] as appropriate.
Example of a newly created mailbox (or granting of the 'l' right on Example of a newly created mailbox (or granting of the 'l' right on
the mailbox): the mailbox):
S: * LIST () "/" "NewMailbox" S: * LIST () "/" "NewMailbox"
And a deleted mailbox (or revocation of the 'l' right on the And a deleted mailbox (or revocation of the 'l' right on the
mailbox): mailbox):
S: * LIST (\NonExistent) "." "INBOX.DeletedMailbox" S: * LIST (\NonExistent) "." "INBOX.DeletedMailbox"
Example of a renamed mailbox: Example of a renamed mailbox:
S: * LIST () "/" "NewMailbox" ("OLDNAME" ("OldMailbox")) S: * LIST () "/" "NewMailbox" ("OLDNAME" ("OldMailbox"))
5.5. 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. Note that in the LIST response, all mailbox
attributes MUST be accurately computed (this differs from the
behavior of the LSUB command).
Example: Example:
S: * LIST (\Subscribed) "/" "SubscribedMailbox" S: * LIST (\Subscribed) "/" "SubscribedMailbox"
5.6. MailboxMetadataChange 5.6. MailboxMetadataChange
Support for this event type is OPTIONAL, unless the METADATA Support for this event type is OPTIONAL, unless the METADATA
extension [METADATA] is also supported by the server, in which case extension [METADATA] is also supported by the server, in which case
support for this event type is REQUIRED. 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
Internet-draft August 2008
4.4.2 of [METADATA]). If possible, only the changed metadata SHOULD 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 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. metadata item, it MAY include all metadata items set on the mailbox.
Example: Example:
S: * METADATA "INBOX" /public/comment S: * METADATA "INBOX" /public/comment
5.7. ServerMetadataChange 5.7. ServerMetadataChange
Support for this event type is OPTIONAL, unless the METADATA or the Support for this event type is OPTIONAL, unless the METADATA or the
METADATA-SERVER extension [METADATA] is also supported by the METADATA-SERVER extension [METADATA] is also supported by the
server, in which case support for this event type is REQUIRED. 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.4.2 of [METADATA]). Only the names of changed metadata entries 4.4.2 of [METADATA]). Only the names of changed metadata entries
skipping to change at page 12, line 44 skipping to change at page 14, line 5
mailboxes monitoried at a later time. If this happens, the server mailboxes monitoried at a later time. If this happens, the server
MUST stop monitoring these mailboxes. If access is later granted, MUST stop monitoring these mailboxes. If access is later granted,
the server MUST restart event monitoring. the server MUST restart event monitoring.
The server SHOULD return the LIST response with the \NoAccess name The server SHOULD return the LIST response with the \NoAccess name
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.
Internet-draft August 2008
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' and 'SELECTED-DELAYED' (section 6.1) match the Only 'SELECTED' and 'SELECTED-DELAYED' (section 6.1) match the
currently selected mailbox. All other mailbox specifications affect currently selected mailbox. All other mailbox specifications affect
other (non-selected) mailboxes. other (non-selected) mailboxes.
Note that multiple <event-group>s can apply to the same mailbox. Note that multiple <event-group>s can apply to the same mailbox.
skipping to change at page 13, line 47 skipping to change at page 15, line 5
Both refer to the mailbox selected using either SELECT or EXAMINE 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 (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 not in the selected state, such mailbox specifiers don't refer to
any mailbox. any mailbox.
The mailbox specifiers only apply to <message-event>s. It is an The mailbox specifiers only apply to <message-event>s. It is an
error to specify other types of events with either the SELECTED or error to specify other types of events with either the SELECTED or
the SELECTED-DELAYED selector. the SELECTED-DELAYED selector.
Internet-draft August 2008
6.1.1. Selected 6.1.1. Selected
The SELECTED mailbox specifier requires the server to send immediate The SELECTED mailbox specifier requires the server to send immediate
notifications for the currently selected mailbox about all specified notifications for the currently selected mailbox about all specified
<message-event>s. <message-event>s.
6.1.2 Selected-delayed 6.1.2 Selected-delayed
The SELECTED-DELAYED mailbox specifier requires the server to delay The SELECTED-DELAYED mailbox specifier requires the server to delay
MessageExpunge event until the client issues a command that allows MessageExpunge event until the client issues a command that allows
returning information about expunged messages (see Section 7.4.1 of returning information about expunged messages (see Section 7.4.1 of
[RFC3501] for more details), for example till a NOOP or an IDLE [RFC3501] for more details), for example till a NOOP or an IDLE
skipping to change at page 14, line 21 skipping to change at page 15, line 26
MessageExpunge event until the client issues a command that allows MessageExpunge event until the client issues a command that allows
returning information about expunged messages (see Section 7.4.1 of returning information about expunged messages (see Section 7.4.1 of
[RFC3501] for more details), for example till a NOOP or an IDLE [RFC3501] for more details), for example till a NOOP or an IDLE
command. When SELECTED-DELAYED is specified the server MAY also command. When SELECTED-DELAYED is specified the server MAY also
delay returning other <message-event>s until the client issues a delay returning other <message-event>s until the client issues a
command specified above, or it MAY return them immediately. 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), as defined in [NAMESPACE].
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
[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".
skipping to change at page 14, line 45 skipping to change at page 16, line 5
If the subscription list changes, the server MUST reevaluate the If the subscription list changes, the server MUST reevaluate the
list. list.
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.
Internet-draft August 2008
6.6 Mailboxes 6.6 Mailboxes
Mailboxes is followed by a mailbox name or a 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. Extension to SEARCH and SORT commands 7. Extension to SEARCH and SORT commands
If the server that support the NOTIFY extension also supports If the server that support the NOTIFY extension also supports
CONTEXT=SEARCH and/or CONTEXT=SORT as defined in [CONTEXT], the CONTEXT=SEARCH and/or CONTEXT=SORT as defined in [CONTEXT], the
UPDATE return option is extended so that a client can request that UPDATE return option is extended so that a client can request that
skipping to change at page 15, line 19 skipping to change at page 16, line 24
7. Extension to SEARCH and SORT commands 7. Extension to SEARCH and SORT commands
If the server that support the NOTIFY extension also supports If the server that support the NOTIFY extension also supports
CONTEXT=SEARCH and/or CONTEXT=SORT as defined in [CONTEXT], the CONTEXT=SEARCH and/or CONTEXT=SORT as defined in [CONTEXT], the
UPDATE return option is extended so that a client can request that UPDATE return option is extended so that a client can request that
FETCH attributes be returned when a new message is added to the FETCH attributes be returned when a new message is added to the
context result set. context result set.
For example: For example:
C: a00 SEARCH RETURN (COUNT UPDATE (UID BODY[HEADER.FIELDS (TO C: a00 SEARCH RETURN (COUNT UPDATE (UID BODY[HEADER.FIELDS (TO
FROM FROM SUBJECT)])) FROM "boss"
SUBJECT)])) FROM "boss" S: * ESEARCH (TAG "a00") (COUNT S: * ESEARCH (TAG "a00") (COUNT 17)
17) S: a00 OK [...a new message is delivered...] S: * EXISTS S: a00 OK
93 S: * 93 FETCH (UID 127001 BODY[HEADER.FIELDS (FROM TO [...a new message is delivered...]
SUBJECT)] {76} S: Subject: Re: good morning S: From: S: * EXISTS 93
myboss@example.org S: To: bob@example.org S: S: ) S: * S: * 93 FETCH (UID 127001 BODY[HEADER.FIELDS (FROM TO
ESEARCH (TAG "a00") ADDTO (0 93) 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 Note that the EXISTS response MUST precede any FETCH responses, and
together they MUST precede the ESEARCH response. together they MUST precede the ESEARCH response.
No untagged FETCH response SHOULD be returned if a message becomes a No untagged FETCH response SHOULD be returned if a message becomes a
member of UPDATE SEARCH due to flag or annotation changes. member of UPDATE SEARCH due to flag or annotation changes.
8. Formal Syntax 8. 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 [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].
Internet-draft August 2008
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. For example accept these strings in a case-insensitive fashion. For example
<filter-mailboxes-selected> non-terminal value "SELECTED" must be <filter-mailboxes-selected> non-terminal value "SELECTED" must be
treated in the same way as "Selected" or "selected". treated in the same way as "Selected" or "selected".
capability =/ "X-DRAFT-W06-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]]
skipping to change at page 16, line 30 skipping to change at page 17, line 41
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 ")"
;; Only <message-event>s are allowed in <events>
;; when <filter-mailboxes-selected> is used.
filter-mailboxes = filter-mailboxes-selected / filter-mailboxes = filter-mailboxes-selected /
filter-mailboxes-other filter-mailboxes-other
filter-mailboxes-other = "inboxes" / "personal" / "subscribed" / 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" filter-mailboxes-selected = "selected" / "selected-delayed"
;; Apply to the currently selected mailbox only. ;; Apply to the currently selected mailbox only.
;; Only one of them can be specified in a NOTIFY ;; Only one of them can be specified in a NOTIFY
;; command. ;; command.
Internet-draft August 2008
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-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"
/ "AnnotationChange" SP message-match-criteria / "AnnotationChange"
;; "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
skipping to change at page 17, line 45 skipping to change at page 19, line 4
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" /
Internet-draft August 2008
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"
skipping to change at page 18, line 39 skipping to change at page 19, line 49
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.
10. IANA considerations 10. 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.
10.1. Initial LIST-EXTENDED extended data item registrations 10.1. Initial LIST-EXTENDED extended data item registrations
It is requested that the following entry be added to the LIST- It is requested that the following entry be added to the IMAP4 List
EXTENDED extended data item registry [LISTEXT]: Extended registry [LISTEXT]:
Internet-draft August 2008
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.
skipping to change at page 19, line 43 skipping to change at page 21, line 5
[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
4rev1", RFC 3501, University of Washington, June 2003. 4rev1", RFC 3501, University of Washington, June 2003.
Internet-draft August 2008
[RFC5234] Crocker, Overell, "Augmented BNF for Syntax [RFC5234] Crocker, Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 5234, Brandenburg Specifications: ABNF", RFC 5234, Brandenburg
Internetworking, THUS plc, January 2008. Internetworking, THUS plc, January 2008.
[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.
skipping to change at page 20, line 20 skipping to change at page 21, line 29
4551, Isode Ltd., June 2006. 4551, Isode Ltd., June 2006.
[QRESYNC] Melnikov, A., Cridland, D. and C. Wilson, "IMAP4 [QRESYNC] Melnikov, A., Cridland, D. and C. Wilson, "IMAP4
Extensions for Quick Mailbox Resynchronization", RFC Extensions for Quick Mailbox Resynchronization", RFC
5162, March 2008. 5162, March 2008.
[LISTEXT] Leiba, Melnikov, "IMAP4 List Command Extensions", RFC [LISTEXT] Leiba, Melnikov, "IMAP4 List Command Extensions", RFC
5258, June 2008. 5258, June 2008.
[METADATA] Daboo, "IMAP METADATA Extension", draft-daboo-imap- [METADATA] Daboo, "IMAP METADATA Extension", draft-daboo-imap-
annotatemore-13 (work in progress), Apple Computer, Inc., annotatemore-14 (work in progress), Apple Computer, Inc.,
April 2008. July 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-06.txt (work in
progress), January 2008. progress), July 2008.
[CONTEXT] Cridland, D. and C. King, "Contexts for IMAP4", work in [CONTEXT] Cridland, D. and C. King, "Contexts for IMAP4", RFC 5267,
progress, draft-cridland-imap-context-05.txt, April 2008. July 2008.
[NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342,
May 1998.
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.
[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.
Internet-draft August 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
UK UK
Email: Curtis.King@isode.com Email: Curtis.King@isode.com
skipping to change at page 22, line 5 skipping to change at page 23, 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 August 2008
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
documents can be found in BCP 78 and BCP 79. documents can be found in BCP 78 and BCP 79.
 End of changes. 47 change blocks. 
64 lines changed or deleted 171 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/