draft-ietf-imapext-condstore-05.txt   draft-ietf-imapext-condstore-06.txt 
Internet Draft: IMAP Extension for Conditional STORE A. Melnikov Internet Draft: IMAP Extension for Conditional STORE A. Melnikov
Document: draft-ietf-imapext-condstore-05.txt Isode Ltd. Document: draft-ietf-imapext-condstore-06.txt Isode Ltd.
Expires: May 2004 S. Hole Expires: April 2006 S. Hole
ACI WorldWide/MessagingDirect ACI WorldWide/MessagingDirect
November 2003 October 2005
IMAP Extension for Conditional STORE operation IMAP Extension for Conditional STORE operation
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, each author represents that any
all provisions of Section 10 of RFC2026. Internet-Drafts are applicable patent or other IPR claims of which he or she is aware
working documents of the Internet Engineering Task Force (IETF), its have been or will be disclosed, and any of which he or she becomes
areas, and its working groups. Note that other groups may also aware will be disclosed, in accordance with Section 6 of BCP 79.
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are working documents of the Internet Engineering
months and may be updated, replaced, or obsoleted by other documents Task Force (IETF), its areas, and its working groups. Note that
at any time. It is inappropriate to use Internet-Drafts as other groups may also distribute working documents as Internet-
reference material or to cite them other than as "work in progress." Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at 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
Draft Shadow Directories can be accessed at
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society 2001-2003. All Rights Reserved. Copyright (C) The Internet Society (2005).
Please see the Full Copyright section near the end of this document
for more information.
Abstract Abstract
Often, multiple IMAP (RFC 3501) clients need to coordinate changes to Often, multiple IMAP (RFC 3501) clients need to coordinate changes to
a common IMAP mailbox. Examples include different clients working on behalf a common IMAP mailbox. Examples include different clients working on behalf
of the same user, and multiple users accessing shared mailboxes. These clients of the same user, and multiple users accessing shared mailboxes. These clients
need a mechanism to synchronize state changes for messages within the need a mechanism to synchronize state changes for messages within the
mailbox. They must be able to guarantee that only one client can change mailbox. They must be able to guarantee that only one client can change
message state (e.g., message flags or annotations) at any time. An message state (e.g., message flags) at any time. An
example of such an application is use of an IMAP mailbox as a message example of such an application is use of an IMAP mailbox as a message
queue with multiple dequeueing clients. queue with multiple dequeueing clients.
The Conditional Store facility provides a protected update mechanism for The Conditional Store facility provides a protected update mechanism for
message state information that can detect and resolve conflicts between message state information that can detect and resolve conflicts between
multiple writing mail clients. multiple writing mail clients.
This document defines an extension to IMAP (RFC 3501). This document defines an extension to IMAP (RFC 3501).
Table of Contents Table of Contents
skipping to change at line 91 skipping to change at line 93
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 RFC 2119 [KEYWORDS]. document are to be interpreted as described in RFC 2119 [KEYWORDS].
In examples, lines beginning with "S:" are sent by the IMAP server, and In examples, lines beginning with "S:" are sent by the IMAP server, and
lines beginning with "C:" are sent by the client. Line breaks may appear lines beginning with "C:" are sent by the client. Line breaks may appear
in example commands solely for editorial clarity; when present in in example commands solely for editorial clarity; when present in
the actual message they are represented by "CRLF". the actual message they are represented by "CRLF".
Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4]. Formal syntax is defined using ABNF [ABNF].
The term "metadata" or "metadata item" is used throughout this document. The term "metadata" or "metadata item" is used throughout this document.
It refers to any system or user defined keyword or an annotation It refers to any system or user defined keyword. Future documents
[ANNOTATE]. may extend "metadata" to include other dynamic message data.
Some IMAP mailboxes are private, accessible only to the owning user. Some IMAP mailboxes are private, accessible only to the owning user.
Other mailboxes are not, either because the owner has set an ACL Other mailboxes are not, either because the owner has set an ACL
[ACL] which permits access by other users, or because it is a [ACL] which permits access by other users, or because it is a
shared mailbox. Let's call a metadata item "shared" for the mailbox shared mailbox. Let's call a metadata item "shared" for the mailbox
if any changes to the metadata items are persistent and visible to all if any changes to the metadata items are persistent and visible to all
other users accessing the mailbox. Otherwise the metadata item is called other users accessing the mailbox. Otherwise the metadata item is called
"private". Note, that private metadata items are still visible to all "private". Note, that private metadata items are still visible to all
sessions accessing the mailbox as the same user. Also note, that different sessions accessing the mailbox as the same user. Also note, that different
mailboxes may have different metadata items as shared. mailboxes may have different metadata items as shared.
skipping to change at line 132 skipping to change at line 134
will get a different mod-sequence value. Also, for any two successful will get a different mod-sequence value. Also, for any two successful
STORE operations performed in the same session on the same mailbox, STORE operations performed in the same session on the same mailbox,
the mod-sequence of the second completed operation MUST be greater than the mod-sequence of the second completed operation MUST be greater than
the mod-sequence of the first completed. Note that the latter rule disallows the mod-sequence of the first completed. Note that the latter rule disallows
the use of the system clock as a mod-sequence, because if system time changes the use of the system clock as a mod-sequence, because if system time changes
(e.g., a NTP [NTP] client adjusting the time), the next generated value might (e.g., a NTP [NTP] client adjusting the time), the next generated value might
be less than the previous one. be less than the previous one.
Mod-sequences allow a client that supports the CONDSTORE extension to Mod-sequences allow a client that supports the CONDSTORE extension to
determine if a message metadata has changed since some known determine if a message metadata has changed since some known
moment. Whenever the state of a flag changes (i.e., the flag is added and moment. Whenever the state of a flag changes (i.e., the flag is added where
before it wasn't set, or the flag is removed and before it was set) the previously it wasn't set, or the flag is removed and before it was set) the
value of the modification sequence for the message MUST be updated. value of the modification sequence for the message MUST be updated.
Adding the flag when it is already present or removing when it is not Adding the flag when it is already present or removing when it is not
present SHOULD NOT change the mod-sequence. present SHOULD NOT change the mod-sequence.
When a message is appended to a mailbox (via the IMAP APPEND command, When a message is appended to a mailbox (via the IMAP APPEND command,
COPY to the mailbox or using an external mechanism) the server COPY to the mailbox or using an external mechanism) the server
generates a new modification sequence that is higher than the highest generates a new modification sequence that is higher than the highest
modification sequence of all messages in the mailbox and assigns it to modification sequence of all messages in the mailbox and assigns it to
the appended message. the appended message.
When an annotation [ANNOTATE] is added, modified or removed the corresponding
message mod-sequence MUST be updated.
The server MAY store separate (per message) modification sequence values for The server MAY store separate (per message) modification sequence values for
different metadata items. If the server does so, per message mod-sequence is different metadata items. If the server does so, per message mod-sequence is
the highest mod-sequence of all metadata items for the specified message. the highest mod-sequence of all metadata items for the specified message.
The server that supports this extension is not required to be able to store The server that supports this extension is not required to be able to store
mod-sequences for every available mailbox. Section 3.1.2 describes how mod-sequences for every available mailbox. Section 3.1.2 describes how
the server may act if a particular mailbox doesn't support the persistent the server may act if a particular mailbox doesn't support the persistent
storage of mod-sequences. storage of mod-sequences.
This extension makes the following changes to the IMAP4 protocol: This extension makes the following changes to the IMAP4 protocol:
skipping to change at line 181 skipping to change at line 180
f) extends the syntax of untagged SEARCH responses to include mod-sequence f) extends the syntax of untagged SEARCH responses to include mod-sequence
g) adds new OK untagged responses for the SELECT and EXAMINE commands g) adds new OK untagged responses for the SELECT and EXAMINE commands
h) defines an additional parameter to SELECT/EXAMINE commands h) defines an additional parameter to SELECT/EXAMINE commands
i) adds the HIGHESTMODSEQ status data item to the STATUS command i) adds the HIGHESTMODSEQ status data item to the STATUS command
A client supporting CONDSTORE extension indicates its willingness to receive A client supporting CONDSTORE extension indicates its willingness to receive
mod-sequence updates in all untagged FETCH responses by issuing a SELECT or mod-sequence updates in all untagged FETCH responses by issuing a SELECT or
EXAMINE command with the CONDSTORE parameter, or a FETCH, SEARCH, or SORT EXAMINE command with the CONDSTORE parameter, or STATUS (HIGHESTMODSEQ) command,
or a FETCH, SEARCH, or SORT
(if it also supports SORT=MODSEQ extension, see below) command that includes (if it also supports SORT=MODSEQ extension, see below) command that includes
the MODSEQ message data item, a FETCH command with the CHANGEDSINCE modifier, the MODSEQ message data item, a FETCH command with the CHANGEDSINCE modifier,
or a STORE command with the UNCHANGEDSINCE modifier. or a STORE command with the UNCHANGEDSINCE modifier.
The server will include mod-sequence data in all FETCH responses, whether they The server MUST include mod-sequence data in all subsequent untagged FETCH
responses, whether they
were caused by a regular STORE, STORE with UNCHANGEDSINCE modifier, or an external were caused by a regular STORE, STORE with UNCHANGEDSINCE modifier, or an external
agent, until the connection is closed. agent, until the connection is closed.
This document uses the term "CONSTORE-aware client" to refer to a client This document uses the term "CONSTORE-aware client" to refer to a client
that announces its willingness to receive mod-sequence updates as described that announces its willingness to receive mod-sequence updates as described
above. The term "CONDSTORE enabling command" will refer any of the commands above. The term "CONDSTORE enabling command" will refer any of the commands
listed above. A first CONDSTORE enabling command executed in the session listed above. A first CONDSTORE enabling command executed in the session
MUST cause the server to return HIGHESTMODSEQ (section 3.1.1) unless the MUST cause the server to return HIGHESTMODSEQ (section 3.1.1) unless the
server has sent NOMODSEQ (section 3.1.2) response code when the currently server has sent NOMODSEQ (section 3.1.2) response code when the currently
selected mailbox was selected. selected mailbox was selected.
skipping to change at line 216 skipping to change at line 217
b) adds a new MODSEQ sort criterion (see sections 3.4 and 3.5) b) adds a new MODSEQ sort criterion (see sections 3.4 and 3.5)
The rest of this document describes the protocol changes more rigorously. The rest of this document describes the protocol changes more rigorously.
3. IMAP Protocol Changes 3. IMAP Protocol Changes
3.1. New OK untagged responses for SELECT and EXAMINE 3.1. New OK untagged responses for SELECT and EXAMINE
This document adds two new response codes HIGHESTMODSEQ and NOMODSEQ. This document adds two new response codes HIGHESTMODSEQ and NOMODSEQ.
One of those response codes MUST be returned in the OK untagged One of those response codes MUST be returned in the OK untagged
response for a successful SELECT and EXAMINE commands. response for a successful SELECT/EXAMINE command.
When opening a mailbox the server must check if the mailbox supports When opening a mailbox the server must check if the mailbox supports
the persistent storage of mod-sequences. If the mailbox supports the persistent storage of mod-sequences. If the mailbox supports
the persistent storage of mod-sequences and mailbox open operation succeeds, the persistent storage of mod-sequences and mailbox open operation succeeds,
the server MUST send the OK untagged response including HIGHESTMODSEQ the server MUST send the OK untagged response including HIGHESTMODSEQ
response code. If the persistent storage for the mailbox is not supported, response code. If the persistent storage for the mailbox is not supported,
the server MUST send the OK untagged response including NOMODSEQ response the server MUST send the OK untagged response including NOMODSEQ response
code instead. code instead.
3.1.1. HIGHESTMODSEQ response code 3.1.1. HIGHESTMODSEQ response code
skipping to change at line 242 skipping to change at line 243
every successful SELECT or EXAMINE command: every successful SELECT or EXAMINE command:
OK [HIGHESTMODSEQ <mod-sequence-value>] OK [HIGHESTMODSEQ <mod-sequence-value>]
Where <mod-sequence-value> is the highest mod-sequence value of all Where <mod-sequence-value> is the highest mod-sequence value of all
messages in the mailbox. When the server changes UIDVALIDITY for a messages in the mailbox. When the server changes UIDVALIDITY for a
mailbox, it doesn't have to keep the same HIGHESTMODSEQ for the mailbox, it doesn't have to keep the same HIGHESTMODSEQ for the
mailbox. mailbox.
A disconnected client can use the value of HIGHESTMODSEQ to check if A disconnected client can use the value of HIGHESTMODSEQ to check if
it has to refetch flags and/or annotations from the server. If the it has to refetch metadata from the server. If the
UIDVALIDITY value has changed for the selected mailbox, the client UIDVALIDITY value has changed for the selected mailbox, the client
MUST delete the cached value of HIGHESTMODSEQ. If UIDVALIDITY for MUST delete the cached value of HIGHESTMODSEQ. If UIDVALIDITY for
the mailbox is the same and if the HIGHESTMODSEQ value stored in the mailbox is the same and if the HIGHESTMODSEQ value stored in
the client's cache is less than the value returned by the server, the client's cache is less than the value returned by the server,
then some metadata items on the server have changed since the last then some metadata items on the server have changed since the last
synchronization, and the client needs to update its cache. The client synchronization, and the client needs to update its cache. The client
MAY use SEARCH MODSEQ as described in section 3.4 to find out exactly MAY use SEARCH MODSEQ as described in section 3.4 to find out exactly
which metadata items have changed. Alternatively the client MAY issue which metadata items have changed. Alternatively the client MAY issue
FETCH with CHANGEDSINCE modifier (section 3.3.1) in order to fetch data FETCH with CHANGEDSINCE modifier (section 3.3.1) in order to fetch data
for all messages that have metadata items changed since some known for all messages that have metadata items changed since some known
skipping to change at line 307 skipping to change at line 308
commands (see section 6.4.6 of [IMAP4]) to include an optional STORE commands (see section 6.4.6 of [IMAP4]) to include an optional STORE
modifier. The document defines the following modifier: modifier. The document defines the following modifier:
UNCHANGEDSINCE <mod-sequence> UNCHANGEDSINCE <mod-sequence>
For each message specified in the message set the server performs For each message specified in the message set the server performs
the following. If the mod-sequence of any metadata item of the the following. If the mod-sequence of any metadata item of the
message is equal or less than the specified UNCHANGEDSINCE value, message is equal or less than the specified UNCHANGEDSINCE value,
then the requested operation (as described by the then the requested operation (as described by the
message data item) is performed. If the operation is successful message data item) is performed. If the operation is successful
the server MUST update the mod-sequence attribute of the message. the server MUST update the mod-sequence attribute of the message.
An untagged FETCH response MUST be sent (even if the .SILENT suffix An untagged FETCH response MUST be sent, even if the .SILENT suffix
is specified or ANNOTATION message data item is used; the latter is specified and the response MUST include the MODSEQ message data
changes the behavior described in Section 9.4 of [ANNOTATE])
and the response MUST include the MODSEQ message data
item. This is required to update the client's cache with the correct item. This is required to update the client's cache with the correct
mod-sequence values. See section 3.3.2 for more details. mod-sequence values. See section 3.3.2 for more details.
However, if the mod-sequence of any metadata item of the However, if the mod-sequence of any metadata item of the
message is greater than the specified UNCHANGEDSINCE value, than message is greater than the specified UNCHANGEDSINCE value, than
the requested operation MUST NOT be performed. In this case, the requested operation MUST NOT be performed. In this case,
the mod-sequence attribute of the message is not updated, and the the mod-sequence attribute of the message is not updated, and the
message number (or unique identifier in the case of the UID STORE message number (or unique identifier in the case of the UID STORE
command) is added to the list of messages that failed the UNCHANGESINCE test. command) is added to the list of messages that failed the UNCHANGESINCE test.
skipping to change at line 335 skipping to change at line 334
response code includes the message set (for STORE) or set of UIDs response code includes the message set (for STORE) or set of UIDs
(for UID STORE) of all messages that failed the UNCHANGESINCE test. (for UID STORE) of all messages that failed the UNCHANGESINCE test.
Example : Example :
All messages pass the UNCHANGESINCE test. All messages pass the UNCHANGESINCE test.
C: a103 UID STORE 6,4,8 (UNCHANGEDSINCE 200012121230045) C: a103 UID STORE 6,4,8 (UNCHANGEDSINCE 200012121230045)
+FLAGS.SILENT (\Deleted) +FLAGS.SILENT (\Deleted)
S: * 1 FETCH (UID 4 MODSEQ (200012121231000)) S: * 1 FETCH (UID 4 MODSEQ (200012121231000))
S: * 2 FETCH (UID 6 MODSEQ (200012101230852)) S: * 2 FETCH (UID 6 MODSEQ (200012121230852))
S: * 4 FETCH (UID 8 MODSEQ (200012121130956)) S: * 4 FETCH (UID 8 MODSEQ (200012121130956))
S: a103 OK Conditional Store completed S: a103 OK Conditional Store completed
Example: Example:
C: a104 STORE * (UNCHANGEDSINCE 200012121230045) +FLAGS.SILENT C: a104 STORE * (UNCHANGEDSINCE 200012121230045) +FLAGS.SILENT
(\Deleted $Processed) (\Deleted $Processed)
S: * 50 FETCH (MODSEQ (200012111230047)) S: * 50 FETCH (MODSEQ (200012111230047))
S: a104 OK Store (conditional) completed S: a104 OK Store (conditional) completed
Example: Example:
C: c101 STORE 1 (UNCHANGEDSINCE 200012121230045) ANNOTATION C: c101 STORE 1 (UNCHANGEDSINCE 200012121230045) -FLAGS.SILENT
("/message/comment" ("value.priv" "My new comment")) (\Deleted)
S: * OK [HIGHESTMODSEQ 200012111230047] S: * OK [HIGHESTMODSEQ 200012111230047]
S: * 50 FETCH (MODSEQ (200012111230048)) S: * 50 FETCH (MODSEQ (200012111230048))
S: c101 OK Store (conditional) completed S: c101 OK Store (conditional) completed
HIGHESTMODSEQ response code was sent by the server HIGHESTMODSEQ response code was sent by the server
presumably because this was the first CONDSTORE enabling presumably because this was the first CONDSTORE enabling
command. command.
Example: Example:
skipping to change at line 561 skipping to change at line 560
include the mod-sequence value whenever it decides to send the include the mod-sequence value whenever it decides to send the
unsolicited FETCH response to all CONDSTORE-aware clients that have opened unsolicited FETCH response to all CONDSTORE-aware clients that have opened
the mailbox containing the message. the mailbox containing the message.
3.3 FETCH and UID FETCH Commands 3.3 FETCH and UID FETCH Commands
3.3.1 FETCH modifiers 3.3.1 FETCH modifiers
Arguments: sequence set Arguments: sequence set
message data item names or macro message data item names or macro
OPTIONAL fetch modifiers
Responses: untagged responses: FETCH Responses: untagged responses: FETCH
Result: OK - fetch completed Result: OK - fetch completed
NO - fetch error: can't fetch that data NO - fetch error: can't fetch that data
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
This document extends the syntax of the FETCH and UID FETCH This document extends the syntax of the FETCH and UID FETCH
commands (see section 6.4.5 of [IMAP4]) to include an optional FETCH commands (see section 6.4.5 of [IMAP4]) to include an optional FETCH
modifier. The document defines the following modifier: modifier. The document defines the following modifier:
skipping to change at line 717 skipping to change at line 717
item) and <entry-type-req> (type of metadata item) before item) and <entry-type-req> (type of metadata item) before
<mod-sequence-valzer>. <entry-type-req> can be one of "shared", <mod-sequence-valzer>. <entry-type-req> can be one of "shared",
"priv" (private) or "all". The latter means that the server should use "priv" (private) or "all". The latter means that the server should use
the biggest value among "priv" and "shared" mod-sequences for the the biggest value among "priv" and "shared" mod-sequences for the
metadata item. If the server doesn't store internally separate metadata item. If the server doesn't store internally separate
mod-sequences for different metadata items, it MUST ignore mod-sequences for different metadata items, it MUST ignore
<entry-name> and <entry-type-req>. Otherwise the server should <entry-name> and <entry-type-req>. Otherwise the server should
use them to narrow down the search. use them to narrow down the search.
For a flag <flagname> the corresponding <entry-name> has a form For a flag <flagname> the corresponding <entry-name> has a form
"/flags/<flagname>" as defined in [ANNOTATE]. Note, that "/flags/<flagname>" as defined in [IMAPABNF]. Note, that
the leading "\" character that denotes a system flag has to be the leading "\" character that denotes a system flag has to be
escaped as per Section 4.3 of [IMAP4], as the <entry-name> uses escaped as per Section 4.3 of [IMAP4], as the <entry-name> uses
syntax for quoted strings. syntax for quoted strings.
If client specifies a MODSEQ criterion in a SEARCH command and If client specifies a MODSEQ criterion in a SEARCH command and
the server returns a non-empty SEARCH result, the server MUST also the server returns a non-empty SEARCH result, the server MUST also
append (to the end of the untagged SEARCH response) the highest append (to the end of the untagged SEARCH response) the highest
mod-sequence for all messages being returned. See also section 3.6. mod-sequence for all messages being returned. See also section 3.6.
Example: Example:
C: a SEARCH MODSEQ "/flags/\\draft" all 20010320162338 C: a SEARCH MODSEQ "/flags/\\draft" all 20010320162338
ANNOTATION "/comment" "value" "IMAP4"
S: * SEARCH 2 5 6 7 11 12 18 19 20 23 (MODSEQ 20010917162500) S: * SEARCH 2 5 6 7 11 12 18 19 20 23 (MODSEQ 20010917162500)
S: a OK Search complete S: a OK Search complete
In the above example, the message numbers of any messages In the above example, the message numbers of any messages
containing the string "IMAP4" in the "value" attribute of the containing the string "IMAP4" in the "value" attribute of the
"/comment" entry and having a mod-sequence equal to or "/comment" entry and having a mod-sequence equal to or
greater than 20010320162338 for the "\Draft" flag are returned in greater than 20010320162338 for the "\Draft" flag are returned in
the search results. the search results.
Example: Example:
skipping to change at line 758 skipping to change at line 757
SORT=MODSEQ extension that allows for sorting on per-message SORT=MODSEQ extension that allows for sorting on per-message
mod-sequence. SORT=MODSEQ extension adds MODSEQ sort criterion mod-sequence. SORT=MODSEQ extension adds MODSEQ sort criterion
that allows to sort the matching messages based on their mod-sequence. that allows to sort the matching messages based on their mod-sequence.
If client specifies a MODSEQ search (as per section 3.4) or sort If client specifies a MODSEQ search (as per section 3.4) or sort
criterion in the SORT command and the server returns a non-empty criterion in the SORT command and the server returns a non-empty
SORT result, the server MUST also append (to the end of the untagged SORT result, the server MUST also append (to the end of the untagged
SORT response) the highest mod-sequence for all messages being returned. SORT response) the highest mod-sequence for all messages being returned.
See also section 3.6. See also section 3.6.
Example (MODSEQ search criterion): Example (MODSEQ sort criterion):
C: A282 SORT (SUBJECT MODSEQ) UTF-8 SINCE 1-Feb-2001 C: A282 SORT (SUBJECT MODSEQ) UTF-8 SINCE 1-Feb-2001
S: * SORT 2 81 83 84 82 882 (MODSEQ 117) S: * SORT 2 81 83 84 82 882 (MODSEQ 117)
S: A282 OK SORT completed S: A282 OK SORT completed
Example (MODSEQ sort criterion): Example (MODSEQ search criterion):
C: A283 SORT (SUBJECT REVERSE DATE) UTF-8 MODSEQ 21 C: A283 SORT (SUBJECT REVERSE DATE) UTF-8 MODSEQ 21
S: * SORT 6 3 4 5 2 (MODSEQ 125) S: * SORT 6 3 4 5 2 (MODSEQ 125)
S: A283 OK SORT completed S: A283 OK SORT completed
Example (MODSEQ search criterion and MODSEQ SORT criterion, Example (MODSEQ search criterion and MODSEQ SORT criterion,
but no messages matching the search criteria): but no messages matching the search criteria):
C: A284 SORT (MODSEQ) KOI8-R OR NOT MODSEQ 20010320162338 C: A284 SORT (MODSEQ) KOI8-R OR NOT MODSEQ 20010320162338
SUBJECT "Privet" SUBJECT "Privet"
S: * SORT S: * SORT
S: A284 OK Sort complete, nothing found S: A284 OK Sort complete, nothing found
3.6. Modified SEARCH and SORT untagged responses 3.6. Modified SEARCH and SORT untagged responses
Data: zero or more numbers Data: zero or more numbers
mod-sequence value (omitted if no match) mod-sequence value (omitted if no match)
This document extends syntax of the untagged SEARCH and SORT responses This document extends syntax of the untagged SEARCH and SORT responses
to include mod-sequence for all messages being returned. to include the highest mod-sequence for all messages being returned.
If a client specifies a MODSEQ criterion in a SEARCH (or UID SEARCH) If a client specifies a MODSEQ criterion in a SEARCH (or UID SEARCH)
command and the server returns a non-empty SEARCH result, the server command and the server returns a non-empty SEARCH result, the server
MUST also append (to the end of the untagged SEARCH response) the MUST also append (to the end of the untagged SEARCH response) the
highest mod-sequence for all messages being returned. See section highest mod-sequence for all messages being returned. See section
3.4 for examples. 3.4 for examples.
If client specifies a MODSEQ search or sort criterion in a SORT If client specifies a MODSEQ search or sort criterion in a SORT
(or UID SORT) command and the server returns a non-empty SORT result, (or UID SORT) command and the server returns a non-empty SORT result,
the server MUST also append (to the end of the untagged SORT response) the server MUST also append (to the end of the untagged SORT response)
skipping to change at line 838 skipping to change at line 837
S: * OK [UIDVALIDITY 3857529045] UIDs valid S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * OK [UIDNEXT 4392] Predicted next UID S: * OK [UIDNEXT 4392] Predicted next UID
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
S: * OK [HIGHESTMODSEQ 20010715194045007] S: * OK [HIGHESTMODSEQ 20010715194045007]
S: A142 OK [READ-WRITE] SELECT completed, CONDSTORE is now enabled S: A142 OK [READ-WRITE] SELECT completed, CONDSTORE is now enabled
4. Formal Syntax 4. 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 [ABNF]. Form (ABNF) [ABNF] notation. Elements not defined here can be found in
the formal syntax of the ABNF [ABNF], IMAP [IMAP4], and IMAP ABNF extensions
Non-terminals referenced but not defined below are as defined by [IMAPABNF] specifications.
[IMAP4] or [ANNOTATE].
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 token insensitive. The use of upper or lower case characters to define token
strings is for editorial clarity only. Implementations MUST accept strings is for editorial clarity only. Implementations MUST accept
these strings in a case-insensitive fashion. these strings in a case-insensitive fashion.
capability =/ "CONDSTORE" / "SORT=MODSEQ" capability =/ "CONDSTORE" / "SORT=MODSEQ"
status = "STATUS" SP mailbox SP status-att =/ "HIGHESTMODSEQ"
"(" status-att-req *(SP status-att-req) ")" ;; extends non-terminal defined in RFC 3501.
;; redefine STATUS command syntax defined in [IMAP4]
status-att-req = status-att / "HIGHESTMODSEQ"
status-rsp-info = status-att SP number /
"HIGHESTMODSEQ" SP mod-sequence-value
store = "STORE" SP sequence-set store-modifiers SP store-att-flags
store-modifiers = [ SP "(" store-modifier *(SP store-modifier) ")" ] status-att-val =/ "HIGHESTMODSEQ" SP mod-sequence-value
store-modifier = "UNCHANGEDSINCE" SP mod-sequence-valzer store-modifier =/ "UNCHANGEDSINCE" SP mod-sequence-valzer
;; Only a single "UNCHANGEDSINCE" may be specified ;; Only a single "UNCHANGEDSINCE" may be specified
;; in a STORE operation ;; in a STORE operation
fetch = "FETCH" SP sequence-set SP ("ALL" / "FULL" / fetch-modifier =/ chgsince-fetch-mod
"FAST" / fetch-att / ;; conforms to the generic "fetch-modifier" syntax
"(" fetch-att *(SP fetch-att) ")") [SP fetch-modifiers] ;; defined in [IMAPABNF].
;; modifies the original IMAP4 fetch command to
;; accept optional modifiers
fetch-modifiers = "(" fetch-modifier *(SP fetch-modifier) ")"
fetch-modifier = fetch-modifier-name / fetch-modifier-name SP astring /
fetch-modifier-name SP "(" fetch-modif-params ")"
;; modifiers to FETCH may contain a modifier name
;; followed by zero or more atoms or strings - multiple
;; items are always parenthesised, nesting is allowed
fetch-modif-params = astring *(SP astring) /
"(" fetch-modif-params *(SP fetch-modif-params) ")"
fetch-modifier-name = atom
chgsince-fetch-mod = "CHANGEDSINCE" SP mod-sequence-value chgsince-fetch-mod = "CHANGEDSINCE" SP mod-sequence-value
;; CHANGEDSINCE FETCH modifier conforms to ;; CHANGEDSINCE FETCH modifier conforms to
;; the fetch-modifier syntax ;; the fetch-modifier syntax
fetch-att =/ fetch-mod-sequence fetch-att =/ fetch-mod-sequence
;; modifies original IMAP4 fetch-att ;; modifies original IMAP4 fetch-att
fetch-mod-sequence = "MODSEQ" fetch-mod-sequence = "MODSEQ"
fetch-mod-resp = "MODSEQ" SP "(" permsg-modsequence ")" fetch-mod-resp = "MODSEQ" SP "(" permsg-modsequence ")"
msg-att-dynamic =/ fetch-mod-resp
search-key =/ search-modsequence search-key =/ search-modsequence
;; modifies original IMAP4 search-key ;; modifies original IMAP4 search-key
;; ;;
;; This change applies to all command referencing this ;; This change applies to all command referencing this
;; non-terminal, in particular SEARCH and SORT. ;; non-terminal, in particular SEARCH and SORT.
search-modsequence = "MODSEQ" [search-modseq-ext] SP mod-sequence-valzer search-modsequence = "MODSEQ" [search-modseq-ext] SP mod-sequence-valzer
search-modseq-ext = SP entry-name SP entry-type-req search-modseq-ext = SP entry-name SP entry-type-req
resp-text-code =/ "HIGHESTMODSEQ" SP mod-sequence-value / resp-text-code =/ "HIGHESTMODSEQ" SP mod-sequence-value /
"NOMODSEQ" / "NOMODSEQ" /
"MODIFIED" SP set "MODIFIED" SP set
entry-name = entry-flag-name / entry-annotate-name entry-name = entry-flag-name
;; The server MUST understand entry-flag-name.
;; If the server also supports [ANNOTATE], it MUST
;; also support entry-annotate-name.
entry-flag-name = DQUOTE "/flags/" attr-flag DQUOTE entry-flag-name = DQUOTE "/flags/" attr-flag DQUOTE
;; each system or user defined flag <flag> ;; each system or user defined flag <flag>
;; is mapped to "/flags/<flag>". ;; is mapped to "/flags/<flag>".
;; ;;
;; <entry-flag-name> follows the escape rules used ;; <entry-flag-name> follows the escape rules used
;; by "quoted" string as described in Section ;; by "quoted" string as described in Section
;; 4.3 of [IMAP4], e.g. for the flag \Seen ;; 4.3 of [IMAP4], e.g. for the flag \Seen
;; the corresponding <entry-name> is ;; the corresponding <entry-name> is
;; "/flags/\\seen", and for the flag ;; "/flags/\\seen", and for the flag
;; $MDNSent, the corresponding <entry-name> ;; $MDNSent, the corresponding <entry-name>
;; is "/flags/$mdnsent". ;; is "/flags/$mdnsent".
entry-annotate-name = entry
;; <entry> is defined in [ANNOTATE]
entry-type-resp = "priv" / "shared" entry-type-resp = "priv" / "shared"
;; metadata item type ;; metadata item type
entry-type-req = entry-type-resp / "all" entry-type-req = entry-type-resp / "all"
;; perform SEARCH operation on private ;; perform SEARCH operation on private
;; metadata item, shared metadata item or both ;; metadata item, shared metadata item or both
permsg-modsequence = mod-sequence-value permsg-modsequence = mod-sequence-value
;; per message mod-sequence ;; per message mod-sequence
skipping to change at line 955 skipping to change at line 926
mod-sequence-valzer = "0" / mod-sequence-value mod-sequence-valzer = "0" / mod-sequence-value
search-sort-mod-seq = "(" "MODSEQ" SP mod-sequence-value ")" search-sort-mod-seq = "(" "MODSEQ" SP mod-sequence-value ")"
sort-key =/ "MODSEQ" sort-key =/ "MODSEQ"
condstore-param = "CONDSTORE" condstore-param = "CONDSTORE"
;; defines the select parameter used with ;; defines the select parameter used with
;; CONDSTORE extension ;; CONDSTORE extension
mailbox-data =/ "STATUS" SP mailbox SP "(" <<This will have to be updated if IMAPABNF is updated to always have
[status-rsp-info *(SP status-rsp-info)] ")" / a parameter.>>
"SEARCH" [1*(SP nz-number) SP search-sort-mod-seq] /
mailbox-data =/ "SEARCH" [1*(SP nz-number) SP search-sort-mod-seq] /
"SORT" [1*(SP nz-number) SP search-sort-mod-seq] "SORT" [1*(SP nz-number) SP search-sort-mod-seq]
<<How does this interact with ESEARCH?>>
attr-flag = "\\Answered" / "\\Flagged" / "\\Deleted" / attr-flag = "\\Answered" / "\\Flagged" / "\\Deleted" /
"\\Seen" / "\\Draft" / attr-flag-keyword / "\\Seen" / "\\Draft" / attr-flag-keyword /
attr-flag-extension attr-flag-extension
;; Does not include "\\Recent" ;; Does not include "\\Recent"
attr-flag-extension = "\\" atom attr-flag-extension = "\\" atom
;; Future expansion. Client implementations ;; Future expansion. Client implementations
;; MUST accept flag-extension flags. Server ;; MUST accept flag-extension flags. Server
;; implementations MUST NOT generate ;; implementations MUST NOT generate
;; flag-extension flags except as defined by ;; flag-extension flags except as defined by
skipping to change at line 1037 skipping to change at line 1011
operation even more important. operation even more important.
7. References 7. References
7.1. Normative References 7.1. Normative References
[KEYWORDS] Bradner, "Key words for use in RFCs to Indicate [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, Harvard University, March 1997. Requirement Levels", RFC 2119, Harvard University, March 1997.
[ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd, ABNF", RFC 4234, October 2005.
November 1997.
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 3501, University of Washington, March 2003. 4rev1", RFC 3501, University of Washington, March 2003.
[ANNOTATE] Gellens, R., Daboo, C., "IMAP ANNOTATE Extension",
work in progress.
<http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-xx.txt>
[SORT] Crispin, M., Murchison, K., "Internet Message Access Protocol -- [SORT] Crispin, M., Murchison, K., "Internet Message Access Protocol --
SORT AND THREAD EXTENSIONS", work in progress. SORT AND THREAD EXTENSIONS", work in progress.
<http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-xx.txt> <http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-xx.txt>
[IMAPABNF] Melnikov, A., "Collected extensions to IMAP4 ABNF",
work in progress.
<http://www.ietf.org/internet-drafts/draft-melnikov-imap-ext-abnf-xx.txt>
7.2. Informative References 7.2. Informative References
[ACAP] Newman, Myers, "ACAP -- Application Configuration Access [ACAP] Newman, Myers, "ACAP -- Application Configuration Access
Protocol", RFC 2244, Innosoft, Netscape, November 1997. Protocol", RFC 2244, Innosoft, Netscape, November 1997.
<ftp://ftp.isi.edu/in-notes/rfc2244.txt> <ftp://ftp.isi.edu/in-notes/rfc2244.txt>
[ACL] Myers, "IMAP4 ACL extension", RFC 2086, Carnegie Mellon, [ACL] Myers, "IMAP4 ACL extension", RFC 2086, Carnegie Mellon,
January 1997. January 1997.
<ftp://ftp.isi.edu/in-notes/rfc2086.txt> <ftp://ftp.isi.edu/in-notes/rfc2086.txt>
skipping to change at line 1086 skipping to change at line 1059
This document defines the CONDSTORE and SORT=MODSEQ IMAP capabilities. This document defines the CONDSTORE and SORT=MODSEQ IMAP capabilities.
IANA should add them to the registry accordingly. IANA should add them to the registry accordingly.
9. Acknowledgments 9. Acknowledgments
Some text was borrowed from "IMAP ANNOTATE Extension" by Randall Gellens Some text was borrowed from "IMAP ANNOTATE Extension" by Randall Gellens
and Cyrus Daboo, and "ACAP -- Application Configuration Access Protocol" and Cyrus Daboo, and "ACAP -- Application Configuration Access Protocol"
by Chris Newman and John Myers. by Chris Newman and John Myers.
Many thanks to Randall Gellens for his comments on how CONDSTORE should Many thanks to Randall Gellens for his thorough review of the document.
interact with ANNOTATE extension and for thorough review of the document.
The authors also acknowledge the feedback provided by Cyrus Daboo, Larry The authors also acknowledge the feedback provided by Cyrus Daboo, Larry
Greenfield, Chris Newman, Harrie Hazewinkel, Arnt Gulbrandsen, Timo Greenfield, Chris Newman, Harrie Hazewinkel, Arnt Gulbrandsen, Timo
Sirainen, Mark Crispin and Ned Freed. Sirainen, Mark Crispin, Ned Freed, Ken Murchison and Dave Cridland.
10. Author's Addresses 10. Author's Addresses
Alexey Melnikov Alexey Melnikov
mailto: Alexey.Melnikov@isode.com mailto: Alexey.Melnikov@isode.com
Isode Limited Isode Limited
5 Castle Business Village, 36 Station Road, 5 Castle Business Village, 36 Station Road,
Hampton, Middlesex, TW12 2BX, United Kingdom Hampton, Middlesex, TW12 2BX, United Kingdom
Steve Hole Steve Hole
mailto: Steve.Hole@messagingdirect.com mailto: Steve.Hole@messagingdirect.com
ACI WorldWide/MessagingDirect ACI WorldWide/MessagingDirect
#900, 10117 Jasper Avenue, #900, 10117 Jasper Avenue,
Edmonton, Alberta, T5J 1W8, CANADA Edmonton, Alberta, T5J 1W8, CANADA
11. Intellectual Property Rights 11. 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 or other rights that might be claimed to pertain Intellectual Property Rights or other rights that might be claimed to
to the implementation or use of the technology described in this pertain to the implementation or use of the technology described in
document or the extent to which any license under such rights might or this document or the extent to which any license under such rights
might not be available; neither does it represent that it has made any might or might not be available; nor does it represent that it has
effort to identify any such rights. Information on the IETF's made any independent effort to identify any such rights. Information
procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such proprietary assurances of licenses to be made available, or the result of an
rights by implementors or users of this specification can be obtained attempt made to obtain a general license or permission for the use of
from the IETF Secretariat. such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at
Director. ietf-ipr@ietf.org.
12. Full Copyright Statement The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
Copyright (C) The Internet Society 2001-2003. All Rights Reserved. Disclaimer of Validity
This document and translations of it may be copied and furnished to This document and the information contained herein are provided on an
others, and derivative works that comment on or otherwise explain it "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
or assist in its implementation may be prepared, copied, published OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
and distributed, in whole or in part, without restriction of any ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
kind, provided that the above copyright notice and this paragraph INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
are included on all such copies and derivative works. However, this INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
document itself may not be modified in any way, such as by removing WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Copyright Statement
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an Copyright (C) The Internet Society (2005). This document is subject
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING to the rights, licenses and restrictions contained in BCP 78, and
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING except as set forth therein, the authors retain all their rights.
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
Appendix A. Open Issues and Change History Appendix A. Change History
Note that this appendix will be removed before publication. Note that this appendix will be removed before publication.
0.1. Change History 0.1. Change History
Changes from draft-ietf-imapext-condstore-05
1. Reworded not to have a normative reference to ANNOTATE.
2. Updated ABNF to reference IMAP ABNF.
3. Clarified that STATUS (HIGHESTMODSEQ) also enables
CONDSTORE notifications.
4. Fixed few typos in examples or example titles.
5. Updated boilerplate, references.
Changes from draft-ietf-imapext-condstore-04 Changes from draft-ietf-imapext-condstore-04
1. Fixed typo in an example, added more examples. 1. Fixed typo in an example, added more examples.
2. Clarified client behavior regarding retrying the request 2. Clarified client behavior regarding retrying the request
when the server returns MODIFIED (IESG comment) when the server returns MODIFIED (IESG comment)
3. Added new section describing how a CONDSTORE server implementation 3. Added new section describing how a CONDSTORE server implementation
should avoid sending MODIFIED when the client has requested should avoid sending MODIFIED when the client has requested
a conditional store on a flag A and a flag B was modified a conditional store on a flag A and a flag B was modified
by another client. (IESG comment) by another client. (IESG comment)
Changes from draft-ietf-imapext-condstore-03 Changes from draft-ietf-imapext-condstore-03
 End of changes. 50 change blocks. 
137 lines changed or deleted 112 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/