draft-ietf-imapext-condstore-00.txt   draft-ietf-imapext-condstore-01.txt 
Internet Draft: IMAP Extension for Conditional STORE A. Melnikov Internet Draft: IMAP Extension for Conditional STORE A. Melnikov
Document: draft-ietf-imapext-condstore-00.txt S. Hole Document: draft-ietf-imapext-condstore-01.txt S. Hole
Expires: September 2003 ACI WorldWide/MessagingDirect Expires: October 2003 ACI WorldWide/MessagingDirect
March 2003 April 2003
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 This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are all provisions of Section 10 of RFC2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
skipping to change at line 43 skipping to change at line 43
all messages in message set weren't changed since and conditional all messages in message set weren't changed since and conditional
STORE succeeds or operation fails for all messages)? STORE succeeds or operation fails for all messages)?
This can be difficult to implement for some servers. This can be difficult to implement for some servers.
Is a server allowed to reply NO to a conditional STORE operation that Is a server allowed to reply NO to a conditional STORE operation that
contains more than one message? Do we need a special response code contains more than one message? Do we need a special response code
for this (probably yes). for this (probably yes).
0.2. Change History 0.2. Change History
Changes from draft-ietf-imapext-condstore-00
1. Dropped "/message" prefix in entry names as per decision in San Francisco.
2. Fixed ABNF for SEARCH and SORT untagged responses.
3. Changed "private" to "priv" to be consistent with ANNOTATE.
4. MODIFIED response code is now returned in OK response, not NO.
5. Added NOMODSEQ response code.
Changes from draft-melnikov-imap-condstore-09: Changes from draft-melnikov-imap-condstore-09:
1. Some text clarifications based on suggestions by Harrie Hazewinkel 1. Some text clarifications based on suggestions by Harrie Hazewinkel
2. Added paragraph about mailbox locking and DOS when conditional STORE 2. Added paragraph about mailbox locking and DOS when conditional STORE
operation is performed on a large mailbox. operation is performed on a large mailbox.
3. Fixed syntax of <entry-name> to match the ANNOTATE extention. 3. Fixed syntax of <entry-name> to match the ANNOTATE extention.
4. Added sentence that a system flag MUST always be considered existent, 4. Added sentence that a system flag MUST always be considered existent,
when UNCHANGEDSINCE 0 is used. Is this a good idea? when UNCHANGEDSINCE 0 is used. Is this a good idea?
5. Clarified client behavior upon receipt of MODIFIED response code. 5. Clarified client behavior upon receipt of MODIFIED response code.
6. Updated ABNF to clarify where 0 is allowed as mod-sequence and where 6. Updated ABNF to clarify where 0 is allowed as mod-sequence and where
it is not. it is not.
skipping to change at line 138 skipping to change at line 145
6. Fixed some spelling mistakes. 6. Fixed some spelling mistakes.
Table of Contents Table of Contents
1 Abstract .................................................. X 1 Abstract .................................................. X
2 Conventions Used in This Document ......................... X 2 Conventions Used in This Document ......................... X
3 Introduction and Overview ................................. X 3 Introduction and Overview ................................. X
4 IMAP Protocol Changes ..................................... X 4 IMAP Protocol Changes ..................................... X
4.1 New OK untagged responses for SELECT and EXAMINE ......... X 4.1 New OK untagged responses for SELECT and EXAMINE ......... X
4.1.1 HIGHESTMODSEQ response code ............................ X 4.1.1 HIGHESTMODSEQ response code ............................ X
4.1.2 NOMODSEQ response code ................................. X
4.2 STORE and UID STORE Commands ............................. X 4.2 STORE and UID STORE Commands ............................. X
4.3 MODSEQ message data item in FETCH Command ................ X 4.3 MODSEQ message data item in FETCH Command ................ X
4.4 MODSEQ search criterion in SEARCH ........................ X 4.4 MODSEQ search criterion in SEARCH ........................ X
4.5 MODSEQ Sort Criterion .................................... X 4.5 MODSEQ Sort Criterion .................................... X
4.6 Modified SEARCH and SORT untagged responses .............. X 4.6 Modified SEARCH and SORT untagged responses .............. X
4.7 HIGHESTMODSEQ status data items .......................... X 4.7 HIGHESTMODSEQ status data items .......................... X
5 Formal Syntax ............................................. X 5 Formal Syntax ............................................. X
6 Security Considerations ................................... X 6 Security Considerations ................................... X
7 References ................................................ X 7 References ................................................ X
7.1 Normative References ..................................... X 7.1 Normative References ..................................... X
skipping to change at line 236 skipping to change at line 244
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 is added, modified or removed the corresponding message When an annotation is added, modified or removed the corresponding message
mod-sequence MUST be updated. 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 extention is not required to be able to store
mod-sequences for every available mailbox. Section 4.1.2 describes how
the server may act if a particular mailbox doesn't support the persistent
storage of mod-sequences.
This extension makes the following changes to the IMAP4 protocol: This extension makes the following changes to the IMAP4 protocol:
a) extends the syntax of the STORE command to allow STORE a) extends the syntax of the STORE command to allow STORE
modifiers modifiers
b) adds the MODIFIED response code which should be used with b) adds the MODIFIED response code which should be used with
a NO response to the STORE command an OK response to the STORE command
c) adds a new MODSEQ message data item for use with the FETCH command c) adds a new MODSEQ message data item for use with the FETCH command
d) adds a new MODSEQ search criterion d) adds a new MODSEQ search criterion
e) extends syntax of untagged SEARCH and SORT responses to include e) extends syntax of untagged SEARCH and SORT responses to include
mod-sequence. mod-sequence.
f) adds a new OK untagged responses for the SELECT and EXAMINE commands f) adds a new OK untagged responses for the SELECT and EXAMINE commands
g) adds the HIGHESTMODSEQ status data item to the STATUS command g) adds the HIGHESTMODSEQ status data item to the STATUS command
h) adds a new MODSEQ sort criterion h) adds a new MODSEQ sort criterion
The rest of this document describes the protocol changes more rigorously. The rest of this document describes the protocol changes more rigorously.
4. IMAP Protocol Changes 4. IMAP Protocol Changes
4.1. New OK untagged responses for SELECT and EXAMINE 4.1. New OK untagged responses for SELECT and EXAMINE
This document adds two new response codes HIGHESTMODSEQ and NOMODSEQ.
One of those response codes MUST be returned in the OK untagged
response for a successful SELECT and EXAMINE commands.
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 and mailbox open operation succeeds,
the server MUST send the OK untagged response including HIGHESTMODSEQ
response code. If the persistent storage for the mailbox is not supported,
the server MUST send the OK untagged response including NOMODSEQ response
code instead.
4.1.1. HIGHESTMODSEQ response code 4.1.1. HIGHESTMODSEQ response code
This document adds a new response code that is returned in the OK This document adds a new response code that is returned in the OK
untagged response for the SELECT and EXAMINE commands. A server untagged response for the SELECT and EXAMINE commands. A server
supporting the CONDSTORE extension MUST send the OK untagged supporting the persistent storage of mod-sequences for the mailbox MUST
response including HIGHESTMODSEQ response code with every successful send the OK untagged response including HIGHESTMODSEQ response code with
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 flags and/or annotations from the server. If the
skipping to change at line 300 skipping to change at line 325
S: * 172 EXISTS S: * 172 EXISTS
S: * 1 RECENT S: * 1 RECENT
S: * OK [UNSEEN 12] Message 12 is first unseen S: * OK [UNSEEN 12] Message 12 is first unseen
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 S: A142 OK [READ-WRITE] SELECT completed
4.1.2 NOMODSEQ response code
A server that doesn't support the persistent storage of mod-sequences for
the mailbox MUST send the OK untagged response including NOMODSEQ response
code with every successful SELECT or EXAMINE command.
Example: C: A142 SELECT INBOX
S: * 172 EXISTS
S: * 1 RECENT
S: * OK [UNSEEN 12] Message 12 is first unseen
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * OK [UIDNEXT 4392] Predicted next UID
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
S: * OK [NOMODSEQ] Sorry, this mailbox format doesn't support modsequences
S: A142 OK [READ-WRITE] SELECT completed
4.2. STORE and UID STORE Commands 4.2. STORE and UID STORE Commands
Arguments: message set Arguments: message set
OPTIONAL store modifiers OPTIONAL store modifiers
message data item name message data item name
value for message data item value for message data item
Responses: untagged responses: FETCH Responses: untagged responses: FETCH
Result: OK - store completed Result: OK - store completed
NO - store error: can't store that data NO - store error: can't store that data
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
This document extends the syntax of the STORE and UID STORE This document extends the syntax of the STORE and UID STORE
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 UNCHANGEDSINCE
If the mod-sequence of any metadata item specified in the STORE If the mod-sequence of any metadata item specified in the STORE
operation for any message in the message set is greater than the operation for any message in the message set is greater than the
specified unchangedsince value, then the command fails. specified unchangedsince value, then the command MUST NOT change
On failure, a MODIFIED response code is returned which includes any flags. Instead, the server replies with the OK tagged response that
includes a MODIFIED response code. The MODIFIED response code includes
the message set (for STORE) or set of UIDs (for UID STORE) the message set (for STORE) or set of UIDs (for UID STORE)
of all messages that failed the UNCHANGESINCE test. of all messages that failed the UNCHANGESINCE test.
Example: Example:
C: a101 STORE 7,5,9 (UNCHANGEDSINCE 20000320162338) C: a101 STORE 7,5,9 (UNCHANGEDSINCE 20000320162338)
+FLAGS.SILENT (\Deleted) +FLAGS.SILENT (\Deleted)
S: a101 NO [MODIFIED 7,9] Conditional STORE failed S: a101 OK [MODIFIED 7,9] Conditional STORE failed
In spite of the failure of the conditional STORE operation In spite of the failure of the conditional STORE operation
for message 7, the server continues to process the conditional for message 7, the server continues to process the conditional
STORE in order to find all messages which fail the test. STORE in order to find all messages which fail the test.
Use of UNCHANGEDSINCE with a modification sequence of 0 Use of UNCHANGEDSINCE with a modification sequence of 0
always fails if the metadata item exists. A system flag always fails if the metadata item exists. A system flag
MUST always be considered existent, whether it was set or not. MUST always be considered existent, whether it was set or not.
Example: Example:
C: a102 STORE 12 (UNCHANGEDSINCE 0) C: a102 STORE 12 (UNCHANGEDSINCE 0)
+FLAGS.SILENT ($MDNSent) +FLAGS.SILENT ($MDNSent)
S: a102 NO [MODIFIED 12] Conditional STORE failed S: a102 OK [MODIFIED 12] Conditional STORE failed
Note: A client trying to atomically change the state of a particular Note: A client trying to atomically change the state of a particular
flag (or a set of flags) should be prepared to deal with the case flag (or a set of flags) should be prepared to deal with the case
when the server returns MODIFIED response code if the state when the server returns MODIFIED response code if the state
of the flag being watched hasn't changed (but the state of some of the flag being watched hasn't changed (but the state of some
other flag has). This is necessary, because some servers don't store other flag has). This is necessary, because some servers don't store
separate mod-sequences for different flags or annotations. However, separate mod-sequences for different flags or annotations. However,
server implementations are discouraged from doing that, as it is server implementations are discouraged from doing that, as it is
possible not to return spurious errors even when storing a single possible not to return spurious errors even when storing a single
mod-sequence per message. mod-sequence per message.
Upon the receipt of MODIFIED response code the client SHOULD try to Upon the receipt of MODIFIED response code the client SHOULD try to
figure out if the required flags have indeed changed. If they haven't figure out if the required flags have indeed changed. If they haven't
the client SHOULD retry the command. the client SHOULD retry the command.
Example: Example:
C: a106 STORE 100:150 (UNCHANGEDSINCE 200212030000000) C: a106 STORE 100:150 (UNCHANGEDSINCE 200212030000000)
+FLAGS.SILENT ($Processed) +FLAGS.SILENT ($Processed)
S: a106 NO [MODIFIED 101] Conditional STORE failed S: a106 OK [MODIFIED 101] Conditional STORE failed
the flag $Processed was set on the message 101 ... the flag $Processed was set on the message 101 ...
C: a107 NOOP C: a107 NOOP
S: * 101 FETCH (MODSEQ (200303011130956) FLAGS ($Processed)) S: * 101 FETCH (MODSEQ (200303011130956) FLAGS ($Processed))
S: a107 OK S: a107 OK
... so the client retries the operation for the rest of the messages ... so the client retries the operation for the rest of the messages
C: a108 STORE 100,102:150 (UNCHANGEDSINCE 200303011130956) C: a108 STORE 100,102:150 (UNCHANGEDSINCE 200303011130956)
+FLAGS.SILENT ($Processed) +FLAGS.SILENT ($Processed)
skipping to change at line 550 skipping to change at line 593
Syntax: MODSEQ [<entry-name> <entry-type-req>] <mod-sequence-valzer> Syntax: MODSEQ [<entry-name> <entry-type-req>] <mod-sequence-valzer>
Messages that have modification values which are equal to or Messages that have modification values which are equal to or
greater than <mod-sequence-valzer>. This allows a client, greater than <mod-sequence-valzer>. This allows a client,
for example, to find out which messages contain metadata items for example, to find out which messages contain metadata items
that have changed since the last time it updated its disconnected that have changed since the last time it updated its disconnected
cache. The client may also specify <entry-name> (name of metadata cache. The client may also specify <entry-name> (name of metadata
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",
"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 "private" and "shared" modseqs 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 flags and annotations, it MUST ignore mod-sequences for different flags and annotations, 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
"/message/flags/<flagname>" as defined in [ANNOTATE]. Note, that "/flags/<flagname>" as defined in [ANNOTATE]. 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
return a MODSEQ response code in the tagged OK response. The MODSEQ return a MODSEQ response code in the tagged OK response. The MODSEQ
response code covers all messages returned in the untagged SEARCH results. response code covers all messages returned in the untagged SEARCH results.
See also section 4.6. See also section 4.6.
Example: Example:
C: a SEARCH MODSEQ "/message/flags/draft" all 20010320162338 C: a SEARCH MODSEQ "/flags/draft" all 20010320162338
ANNOTATION "/message/comment" "value" "IMAP4" 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
"/message/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:
C: a SEARCH OR NOT MODSEQ 20010320162338 LARGER 50000 C: a SEARCH OR NOT MODSEQ 20010320162338 LARGER 50000
S: * SEARCH S: * SEARCH
S: a OK Search complete, nothing found S: a OK Search complete, nothing found
4.5. MODSEQ Sort Criterion 4.5. MODSEQ Sort Criterion
skipping to change at line 670 skipping to change at line 713
these strings in a case-insensitive fashion. these strings in a case-insensitive fashion.
capability =/ "CONDSTORE" capability =/ "CONDSTORE"
status = "STATUS" SP mailbox SP status = "STATUS" SP mailbox SP
"(" status-att-req *(SP status-att-req) ")" "(" status-att-req *(SP status-att-req) ")"
;; redefine STATUS command syntax defined in [IMAP4] ;; redefine STATUS command syntax defined in [IMAP4]
status-att-req = status-att / "HIGHESTMODSEQ" status-att-req = status-att / "HIGHESTMODSEQ"
mailbox-data =/ "STATUS" SP mailbox SP "("
[status-rsp-info *(SP status-rsp-info)] ")"
status-rsp-info = status-att SP number / status-rsp-info = status-att SP number /
"HIGHESTMODSEQ" SP mod-sequence-value "HIGHESTMODSEQ" SP mod-sequence-value
store = "STORE" SP set store-modifiers SP store-att-flags store = "STORE" SP set store-modifiers SP store-att-flags
store-modifiers = [ SP "(" store-modifier *(SP store-modifier) ")" ] store-modifiers = [ SP "(" store-modifier *(SP store-modifier) ")" ]
store-modifier = "UNCHANGEDSINCE" SP mod-sequence-valzer store-modifier = "UNCHANGEDSINCE" SP mod-sequence-valzer
;; Only single "UNCHANGEDSINCE" may be specified ;; Only single "UNCHANGEDSINCE" may be specified
;; in a STORE operation ;; in a STORE operation
skipping to change at line 699 skipping to change at line 739
fetch-mod-resp = "MODSEQ" SP "(" permsg-modsequence ")" fetch-mod-resp = "MODSEQ" SP "(" permsg-modsequence ")"
search-key =/ search-modsequence search-key =/ search-modsequence
;; modifies original IMAP4 search-key ;; modifies original IMAP4 search-key
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" /
"MODIFIED" SP set "MODIFIED" SP set
entry-name = '"' "/message/flags/" attr-flag '"' entry-name = '"' "/flags/" attr-flag '"'
;; each system or user defined flag <flag> ;; each system or user defined flag <flag>
;; is mapped to "/message/flags/<flag>". ;; is mapped to "/flags/<flag>".
;; ;;
;; <entry-name> follows the escape rules used ;; <entry-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
;; "/message/flags/\\seen", and for the flag ;; "/flags/\\seen", and for the flag
;; $MDNSent, the corresponding <entry-name> ;; $MDNSent, the corresponding <entry-name>
;; is "/message/flags/$mdnsent". ;; is "/flags/$mdnsent".
entry-type-resp = "private" | "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
mod-sequence-value = 1*DIGIT mod-sequence-value = 1*DIGIT
skipping to change at line 735 skipping to change at line 776
;; (1 <= n < 18,446,744,073,709,551,615) ;; (1 <= n < 18,446,744,073,709,551,615)
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"
;;Borrowed from IMAP4rev1 and modified accordingly: ;;Borrowed from IMAP4rev1 and modified accordingly:
mailbox-data =/ "SEARCH" [SP nz-number *(SP nz-number) search_sort_mod_seq] / mailbox-data =/ "STATUS" SP mailbox SP "("
"SORT" [SP nz-number *(SP nz-number) search_sort_mod_seq] [status-rsp-info *(SP status-rsp-info)] ")" /
"SEARCH" [1*(SP nz-number) SP search_sort_mod_seq] /
"SORT" [1*(SP nz-number) SP search_sort_mod_seq]
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
skipping to change at line 810 skipping to change at line 853
8. Acknowledgments 8. 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 comments on how CONDSTORE should
interact with ANNOTATE extension and for thorough review of the document. interact with ANNOTATE extension and for thorough review of the document.
Authors also acknowledge the feedback provided by Cyrus Daboo, Larry Authors also acknowledge the feedback provided by Cyrus Daboo, Larry
Greenfield, Chris Newman, Harrie Hazewinkel, Arnt Gulbrandsen and Timo Greenfield, Chris Newman, Harrie Hazewinkel, Arnt Gulbrandsen Timo
Sirainen. Sirainen and Mark Crispin.
9. Author's Addresses 9. Author's Addresses
Alexey Melnikov Alexey Melnikov
mailto: mel@messagingdirect.com mailto: mel@messagingdirect.com
ACI WorldWide/MessagingDirect ACI WorldWide/MessagingDirect
59 Clarendon Road, Watford, Hertfordshire, 59 Clarendon Road, Watford, Hertfordshire,
WD17 1FQ, United Kingdom WD17 1FQ, United Kingdom
 End of changes. 

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