idnits 2.17.1 draft-ietf-imapext-condstore-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1060. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1032. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1039. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1045. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1270 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 269 instances of too long lines in the document, the longest one being 18 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2006) is 6646 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'UNSEEN 12' is mentioned on line 760, but not defined == Missing Reference: 'UIDVALIDITY 3857529045' is mentioned on line 761, but not defined == Missing Reference: 'UIDNEXT 4392' is mentioned on line 762, but not defined == Missing Reference: 'HIGHESTMODSEQ 715194045007' is mentioned on line 765, but not defined == Missing Reference: 'HIGHESTMODSEQ 12111230047' is mentioned on line 327, but not defined == Missing Reference: 'MODIFIED 7' is mentioned on line 356, but not defined -- Looks like a reference, but probably isn't: '9' on line 356 == Missing Reference: 'MODIFIED 12' is mentioned on line 366, but not defined == Missing Reference: 'MODIFIED 101' is mentioned on line 454, but not defined == Missing Reference: 'MODIFIED 2' is mentioned on line 488, but not defined == Unused Reference: 'ACAP' is defined on line 970, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4234 (ref. 'ABNF') (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 3501 (ref. 'IMAP4') (Obsoleted by RFC 9051) -- Possible downref: Non-RFC (?) normative reference: ref. 'IMAPABNF' -- Obsolete informational reference (is this intentional?): RFC 1305 (ref. 'NTP') (Obsoleted by RFC 5905) Summary: 7 errors (**), 0 flaws (~~), 13 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft: IMAP Extension for Conditional STORE A. Melnikov 2 Document: draft-ietf-imapext-condstore-09.txt Isode Ltd. 3 Expires: August 2006 S. Hole 4 ACI WorldWide/MessagingDirect 5 February 2006 7 IMAP Extension for Conditional STORE operation 8 or quick flag changes resynchronization 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright Notice 35 Copyright (C) The Internet Society (2006). 37 Abstract 39 Often, multiple IMAP (RFC 3501) clients need to coordinate changes to 40 a common IMAP mailbox. Examples include different clients working on 41 behalf of the same user, and multiple users accessing shared mailboxes. 42 These clients need a mechanism to synchronize state changes for messages 43 within the mailbox. They must be able to guarantee that only one client 44 can change message state (e.g., message flags) at any time. An 45 example of such an application is use of an IMAP mailbox as a message 46 queue with multiple dequeueing clients. 48 The Conditional Store facility provides a protected update mechanism for 49 message state information that can detect and resolve conflicts between 50 multiple writing mail clients. 52 The Conditional Store facility also allows a client to quickly 53 resynchronize mailbox flag changes. 55 This document defines an extension to IMAP (RFC 3501). 57 Table of Contents 59 1 Conventions Used in This Document ......................... X 60 2 Introduction and Overview ................................. X 61 3 IMAP Protocol Changes ..................................... X 62 3.1 New OK untagged responses for SELECT and EXAMINE ......... X 63 3.1.1 HIGHESTMODSEQ response code ............................ X 64 3.1.2 NOMODSEQ response code ................................. X 65 3.2 STORE and UID STORE Commands ............................. X 66 3.3 FETCH and UID FETCH Commands ............................. X 67 3.3.1 CHANGEDSINCE FETCH modifier ............................ X 68 3.3.2 MODSEQ message data item in FETCH Command .............. X 69 3.4 MODSEQ search criterion in SEARCH ........................ X 70 3.5 Modified SEARCH untagged response ........................ X 71 3.6 HIGHESTMODSEQ status data items .......................... X 72 3.7 CONDSTORE parameter to SELECT and EXAMINE ................ X 73 3.8 Additional quality of implementation issues .............. X 74 4 Formal Syntax ............................................. X 75 5 Server implementation considerations ...................... X 76 6 Security Considerations ................................... X 77 7 References ................................................ X 78 7.1 Normative References ..................................... X 79 7.2 Informative References ................................... X 80 8 IANA Considerations ....................................... X 81 9 Acknowledgments ........................................... X 82 10 Author's Addresses ........................................ X 83 11 Intellectual Property Rights .............................. X 84 12 Full Copyright Statement .................................. X 86 1. Conventions Used in This Document 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 92 In examples, lines beginning with "S:" are sent by the IMAP server, and 93 lines beginning with "C:" are sent by the client. Line breaks may appear 94 in example commands solely for editorial clarity; when present in 95 the actual message they are represented by "CRLF". 97 Formal syntax is defined using ABNF [ABNF]. 99 The term "metadata" or "metadata item" is used throughout this document. 100 It refers to any system or user defined keyword. Future documents 101 may extend "metadata" to include other dynamic message data. 103 Some IMAP mailboxes are private, accessible only to the owning user. 104 Other mailboxes are not, either because the owner has set an ACL 105 [ACL] which permits access by other users, or because it is a 106 shared mailbox. Let's call a metadata item "shared" for the mailbox 107 if any changes to the metadata items are persistent and visible to all 108 other users accessing the mailbox. Otherwise the metadata item is called 109 "private". Note, that private metadata items are still visible to all 110 sessions accessing the mailbox as the same user. Also note, that different 111 mailboxes may have different metadata items as shared. 113 See the next section for the definition of a "CONDSTORE-aware client" 114 and a "CONDSTORE enabling command". 116 2. Introduction and Overview 118 The Conditional STORE extension is present in any IMAP4 implementation 119 which returns "CONDSTORE" as one of the supported capabilities in the 120 CAPABILITY command response. 122 An IMAP server that supports this extension MUST associate a positive 123 unsigned 64-bit value called a modification sequence (mod-sequence) 124 with every IMAP message. This is an opaque value updated by 125 the server whenever a metadata item is modified. The server MUST 126 guarantee that each STORE command performed on the same mailbox, including 127 simultaneous stores to different metadata items from different connections, 128 will get a different mod-sequence value. Also, for any two successful 129 STORE operations performed in the same session on the same mailbox, 130 the mod-sequence of the second completed operation MUST be greater than 131 the mod-sequence of the first completed. Note that the latter rule disallows 132 the use of the system clock as a mod-sequence, because if system time changes 133 (e.g., a NTP [NTP] client adjusting the time), the next generated value might 134 be less than the previous one. 136 Mod-sequences allow a client that supports the CONDSTORE extension to 137 determine if a message metadata has changed since some known 138 moment. Whenever the state of a flag changes (i.e., the flag is added where 139 previously it wasn't set, or the flag is removed and before it was set) the 140 value of the modification sequence for the message MUST be updated. 141 Adding the flag when it is already present or removing when it is not 142 present SHOULD NOT change the mod-sequence. 144 When a message is appended to a mailbox (via the IMAP APPEND command, 145 COPY to the mailbox or using an external mechanism) the server 146 generates a new modification sequence that is higher than the highest 147 modification sequence of all messages in the mailbox and assigns it to 148 the appended message. 150 The server MAY store separate (per message) modification sequence values for 151 different metadata items. If the server does so, per message mod-sequence is 152 the highest mod-sequence of all metadata items for the specified message. 154 The server that supports this extension is not required to be able to store 155 mod-sequences for every available mailbox. Section 3.1.2 describes how 156 the server may act if a particular mailbox doesn't support the persistent 157 storage of mod-sequences. 159 This extension makes the following changes to the IMAP4 protocol: 161 a) adds UNCHANGEDSINCE STORE modifier 163 b) adds the MODIFIED response code which should be used with 164 an OK response to the STORE command. (It can also be used 165 in a NO response.) 167 c) adds a new MODSEQ message data item for use with the FETCH command 169 d) adds CHANGEDSINCE FETCH modifier 171 e) adds a new MODSEQ search criterion 173 f) extends the syntax of untagged SEARCH responses to include mod-sequence 175 g) adds new OK untagged responses for the SELECT and EXAMINE commands 177 h) defines an additional parameter to SELECT/EXAMINE commands 179 i) adds the HIGHESTMODSEQ status data item to the STATUS command 181 A client supporting CONDSTORE extension indicates its willingness to receive 182 mod-sequence updates in all untagged FETCH responses by issuing a SELECT or 183 EXAMINE command with the CONDSTORE parameter, or STATUS (HIGHESTMODSEQ) command, 184 or a FETCH, or SEARCH command that includes 185 the MODSEQ message data item, a FETCH command with the CHANGEDSINCE modifier, 186 or a STORE command with the UNCHANGEDSINCE modifier. 187 The server MUST include mod-sequence data in all subsequent untagged FETCH 188 responses, whether they were caused by a regular STORE, STORE with 189 UNCHANGEDSINCE modifier, or an external agent, until the connection is closed. 191 This document uses the term "CONSTORE-aware client" to refer to a client 192 that announces its willingness to receive mod-sequence updates as described 193 above. The term "CONDSTORE enabling command" will refer any of the commands 194 listed above. A future extension to this document may extend the list of 195 CONDSTORE enabling commands. A first CONDSTORE enabling command executed in 196 the session MUST cause the server to return HIGHESTMODSEQ (section 3.1.1) unless 197 the server has sent NOMODSEQ (section 3.1.2) response code when the currently 198 selected mailbox was selected. 200 The rest of this document describes the protocol changes more rigorously. 202 3. IMAP Protocol Changes 204 3.1. New OK untagged responses for SELECT and EXAMINE 206 This document adds two new response codes HIGHESTMODSEQ and NOMODSEQ. 207 One of those response codes MUST be returned in the OK untagged 208 response for a successful SELECT/EXAMINE command. 210 When opening a mailbox the server must check if the mailbox supports 211 the persistent storage of mod-sequences. If the mailbox supports 212 the persistent storage of mod-sequences and mailbox open operation succeeds, 213 the server MUST send the OK untagged response including HIGHESTMODSEQ 214 response code. If the persistent storage for the mailbox is not supported, 215 the server MUST send the OK untagged response including NOMODSEQ response 216 code instead. 218 3.1.1. HIGHESTMODSEQ response code 220 This document adds a new response code that is returned in the OK 221 untagged response for the SELECT and EXAMINE commands. A server 222 supporting the persistent storage of mod-sequences for the mailbox MUST 223 send the OK untagged response including HIGHESTMODSEQ response code with 224 every successful SELECT or EXAMINE command: 226 OK [HIGHESTMODSEQ ] 228 Where is the highest mod-sequence value of all 229 messages in the mailbox. When the server changes UIDVALIDITY for a 230 mailbox, it doesn't have to keep the same HIGHESTMODSEQ for the 231 mailbox. 233 A disconnected client can use the value of HIGHESTMODSEQ to check if 234 it has to refetch metadata from the server. If the 235 UIDVALIDITY value has changed for the selected mailbox, the client 236 MUST delete the cached value of HIGHESTMODSEQ. If UIDVALIDITY for 237 the mailbox is the same and if the HIGHESTMODSEQ value stored in 238 the client's cache is less than the value returned by the server, 239 then some metadata items on the server have changed since the last 240 synchronization, and the client needs to update its cache. The client 241 MAY use SEARCH MODSEQ as described in section 3.4 to find out exactly 242 which metadata items have changed. Alternatively the client MAY issue 243 FETCH with CHANGEDSINCE modifier (section 3.3.1) in order to fetch data 244 for all messages that have metadata items changed since some known 245 modification sequence. 247 Example: C: A142 SELECT INBOX 248 S: * 172 EXISTS 249 S: * 1 RECENT 250 S: * OK [UNSEEN 12] Message 12 is first unseen 251 S: * OK [UIDVALIDITY 3857529045] UIDs valid 252 S: * OK [UIDNEXT 4392] Predicted next UID 253 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 254 S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited 255 S: * OK [HIGHESTMODSEQ 715194045007] 256 S: A142 OK [READ-WRITE] SELECT completed 258 3.1.2. NOMODSEQ response code 260 A server that doesn't support the persistent storage of mod-sequences for 261 the mailbox MUST send the OK untagged response including NOMODSEQ response 262 code with every successful SELECT or EXAMINE command. 264 Example: C: A142 SELECT INBOX 265 S: * 172 EXISTS 266 S: * 1 RECENT 267 S: * OK [UNSEEN 12] Message 12 is first unseen 268 S: * OK [UIDVALIDITY 3857529045] UIDs valid 269 S: * OK [UIDNEXT 4392] Predicted next UID 270 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 271 S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited 272 S: * OK [NOMODSEQ] Sorry, this mailbox format doesn't support modsequences 273 S: A142 OK [READ-WRITE] SELECT completed 275 3.2. STORE and UID STORE Commands 277 This document defines the following STORE modifier (see section 278 2.5 of [IMAPABNF]): 280 UNCHANGEDSINCE 281 For each message specified in the message set the server performs 282 the following. If the mod-sequence of any metadata item of the 283 message is equal or less than the specified UNCHANGEDSINCE value, 284 then the requested operation (as described by the 285 message data item) is performed. If the operation is successful 286 the server MUST update the mod-sequence attribute of the message. 287 An untagged FETCH response MUST be sent, even if the .SILENT suffix 288 is specified and the response MUST include the MODSEQ message data 289 item. This is required to update the client's cache with the correct 290 mod-sequence values. See section 3.3.2 for more details. 292 However, if the mod-sequence of any metadata item of the 293 message is greater than the specified UNCHANGEDSINCE value, than 294 the requested operation MUST NOT be performed. In this case, 295 the mod-sequence attribute of the message is not updated, and the 296 message number (or unique identifier in the case of the UID STORE 297 command) is added to the list of messages that failed the UNCHANGESINCE test. 299 When the server finished performing the operation on all the messages 300 in the message set, it checks for a non-empty list of messages that 301 failed the UNCHANGESINCE test. If this list is non-empty, the server MUST 302 return in the tagged response a MODIFIED response code. The MODIFIED 303 response code includes the message set (for STORE) or set of UIDs 304 (for UID STORE) of all messages that failed the UNCHANGESINCE test. 306 Example : 308 All messages pass the UNCHANGESINCE test. 310 C: a103 UID STORE 6,4,8 (UNCHANGEDSINCE 12121230045) 311 +FLAGS.SILENT (\Deleted) 312 S: * 1 FETCH (UID 4 MODSEQ (12121231000)) 313 S: * 2 FETCH (UID 6 MODSEQ (12121230852)) 314 S: * 4 FETCH (UID 8 MODSEQ (12121130956)) 315 S: a103 OK Conditional Store completed 317 Example: 319 C: a104 STORE * (UNCHANGEDSINCE 12121230045) +FLAGS.SILENT 320 (\Deleted $Processed) 321 S: * 50 FETCH (MODSEQ (12111230047)) 322 S: a104 OK Store (conditional) completed 324 Example: 325 C: c101 STORE 1 (UNCHANGEDSINCE 12121230045) -FLAGS.SILENT 326 (\Deleted) 327 S: * OK [HIGHESTMODSEQ 12111230047] 328 S: * 50 FETCH (MODSEQ (12111230048)) 329 S: c101 OK Store (conditional) completed 331 HIGHESTMODSEQ response code was sent by the server 332 presumably because this was the first CONDSTORE enabling 333 command. 335 Example: 337 In spite of the failure of the conditional STORE operation 338 for message 7, the server continues to process the conditional 339 STORE in order to find all messages which fail the test. 341 C: d105 STORE 7,5,9 (UNCHANGEDSINCE 320162338) 342 +FLAGS.SILENT (\Deleted) 343 S: * 5 FETCH (MODSEQ (320162350)) 344 S: d105 OK [MODIFIED 7,9] Conditional STORE failed 346 Example: 348 Same as above, but the server follows SHOULD recommendation 349 in section 6.4.6 of [IMAP4]. 351 C: d105 STORE 7,5,9 (UNCHANGEDSINCE 320162338) 352 +FLAGS.SILENT (\Deleted) 353 S: * 7 FETCH (MODSEQ (320162342) FLAGS (\Seen \Deleted)) 354 S: * 5 FETCH (MODSEQ (320162350)) 355 S: * 9 FETCH (MODSEQ (320162349) FLAGS (\Answered)) 356 S: d105 OK [MODIFIED 7,9] Conditional STORE failed 358 Use of UNCHANGEDSINCE with a modification sequence of 0 359 always fails if the metadata item exists. A system flag 360 MUST always be considered existent, whether it was set or not. 362 Example: 364 C: a102 STORE 12 (UNCHANGEDSINCE 0) 365 +FLAGS.SILENT ($MDNSent) 366 S: a102 OK [MODIFIED 12] Conditional STORE failed 368 The client has tested the presence of the $MDNSent user defined 369 keyword. 371 Note: A client trying to make an atomic change to the state of a particular 372 metadata item (or a set of metadata items) should be prepared 373 to deal with the case when the server returns MODIFIED response code 374 if the state of the metadata item being watched hasn't changed (but 375 the state of some other metadata item has). This is necessary, because 376 some servers don't store separate mod-sequences for different metadata 377 items. However, a server implementation SHOULD avoid generating 378 spurious MODIFIED responses for +FLAGS/-FLAGS STORE operations, 379 even when the server stores a single mod-sequence per message. Section 380 5 describes how this can be achieved. 382 Unless the server has included an unsolicited FETCH to update client's 383 knowledge about message(s) that has failed UNCHANGEDSINCE test, upon the 384 receipt of MODIFIED response code the client SHOULD try to 385 figure out if the required metadata items have indeed changed by issuing 386 FETCH or NOOP command. It is RECOMMENDED that the server avoids the 387 need for the client to do that by sending an unsolicited FETCH response 388 (see two following examples). 390 If the required metadata items haven't changed the client SHOULD retry 391 the command with the new modsequence. The client SHOULD allow for a 392 configurable but reasonable number of retries (at least 2). 394 Example: 395 In the example below the server returns MODIFIED response code 396 without sending information describing why the STORE UNCHANGEDSINCE 397 operation has failed. 399 C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000) 400 +FLAGS.SILENT ($Processed) 401 S: * 100 FETCH (MODSEQ (303181230852)) 402 S: * 102 FETCH (MODSEQ (303181230852)) 403 ... 404 S: * 150 FETCH (MODSEQ (303181230852)) 405 S: a106 OK [MODIFIED 101] Conditional STORE failed 407 the flag $Processed was set on the message 101 ... 408 C: a107 NOOP 409 S: * 101 FETCH (MODSEQ (303011130956) FLAGS ($Processed)) 410 S: a107 OK 412 Or the flag hasn't changed, but another has (note, that this 413 server behaviour is discouraged. Server implementors should also see 414 section 5) ... 416 C: b107 NOOP 417 S: * 101 FETCH (MODSEQ (303011130956) FLAGS (\Deleted \Answered)) 418 S: b107 OK 420 ... and the client retries the operation for the message 101 421 with the updated UNCHANGEDSINCE value 423 C: b108 STORE 101 (UNCHANGEDSINCE 303011130956) 424 +FLAGS.SILENT ($Processed) 425 S: * 101 FETCH (MODSEQ (303181230852)) 426 S: b108 OK Conditional Store completed 428 Example: 429 Same as above, but the server avoids the need for the client to 430 poll for changes. 432 the flag $Processed was set on the message 101 by another client ... 434 C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000) 435 +FLAGS.SILENT ($Processed) 436 S: * 100 FETCH (MODSEQ (303181230852)) 437 S: * 101 FETCH (MODSEQ (303011130956) FLAGS ($Processed)) 438 S: * 102 FETCH (MODSEQ (303181230852)) 439 ... 440 S: * 150 FETCH (MODSEQ (303181230852)) 441 S: a106 OK [MODIFIED 101] Conditional STORE failed 443 Or the flag hasn't changed, but another has (note, that this 444 server behaviour is discouraged. Server implementors should also see 445 section 5) ... 447 C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000) 448 +FLAGS.SILENT ($Processed) 449 S: * 100 FETCH (MODSEQ (303181230852)) 450 S: * 101 FETCH (MODSEQ (303011130956) FLAGS (\Deleted \Answered)) 451 S: * 102 FETCH (MODSEQ (303181230852)) 452 ... 453 S: * 150 FETCH (MODSEQ (303181230852)) 454 S: a106 OK [MODIFIED 101] Conditional STORE failed 456 ... and the client retries the operation for the message 101 457 with the updated UNCHANGEDSINCE value 459 C: b108 STORE 101 (UNCHANGEDSINCE 303011130956) 460 +FLAGS.SILENT ($Processed) 461 S: * 101 FETCH (MODSEQ (303181230852)) 462 S: b108 OK Conditional Store completed 464 Or the flag hasn't changed, but another has (nice server behaviour. 465 Server implementors should also see section 5) ... 467 C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000) 468 +FLAGS.SILENT ($Processed) 469 S: * 100 FETCH (MODSEQ (303181230852)) 470 S: * 101 FETCH (MODSEQ (303011130956) FLAGS ($Processed \Deleted \Answered)) 471 S: * 102 FETCH (MODSEQ (303181230852)) 472 ... 473 S: * 150 FETCH (MODSEQ (303181230852)) 474 S: a106 OK Conditional STORE completed 476 Example: 478 The following example is based on the example from the section 4.2.3 of 479 [RFC-2180] and demonstrates that the MODIFIED response code may be also 480 returned in the tagged NO response. 482 Client tries to conditionally STORE flags on a mixture of expunged 483 and non-expunged messages, one message fails the UNCHANGEDSINCE test. 485 C: B001 STORE 1:7 (UNCHANGEDSINCE 320172338) +FLAGS (\SEEN) 486 S: * 1 FETCH (MODSEQ (320172342) FLAGS (\SEEN)) 487 S: * 3 FETCH (MODSEQ (320172342) FLAGS (\SEEN)) 488 S: B001 NO [MODIFIED 2] Some of the messages no longer exist. 490 C: B002 NOOP 491 S: * 4 EXPUNGE 492 S: * 4 EXPUNGE 493 S: * 4 EXPUNGE 494 S: * 4 EXPUNGE 495 S: * 2 FETCH (MODSEQ (320172340) FLAGS (\Deleted \Answered)) 496 S: B002 OK NOOP Completed. 498 By receiving FETCH responses for messages 1 and 3, and EXPUNGE 499 responses that indicate that messages 4:7 have been expunged, 500 the client retries the operation only for the message 2. The 501 updated UNCHANGEDSINCE value is used. 503 C: b003 STORE 2 (UNCHANGEDSINCE 320172340) +FLAGS (\Seen) 504 S: * 2 FETCH (MODSEQ (320180050)) 505 S: b003 OK Conditional Store completed 507 Note: If a message is specified multiple times in the message 508 set, and the server doesn't internally eliminate duplicates from 509 the message set, it MUST NOT fail the conditional STORE 510 operation for the second (or subsequent) occurrence of the message 511 if the operation completed successfully for the first occurrence. 512 For example, if the client specifies: 514 e105 STORE 7,3:9 (UNCHANGEDSINCE 12121230045) 515 +FLAGS.SILENT (\Deleted) 517 the server must not fail the operation for message 7 as part of 518 processing "3:9" if it succeeded when message 7 was processed 519 the first time. 521 Once the client specified the UNCHANGEDSINCE modifier in a STORE command, 522 the server MUST include the MODSEQ fetch response data items in all 523 subsequent unsolicited FETCH responses. 525 This document also changes the behaviour of the server when it has performed 526 a STORE or UID STORE command and the UNCHANGEDSINCE modifier is not specified. 527 If the operation is successful for a message, the server MUST update 528 the mod-sequence attribute of the message. The server is REQUIRED to 529 include the mod-sequence value whenever it decides to send the 530 unsolicited FETCH response to all CONDSTORE-aware clients that have opened 531 the mailbox containing the message. 533 Server implementors should also see section 3.8 for additional quality of 534 implementation issues related to the STORE command. 536 3.3. FETCH and UID FETCH Commands 538 3.3.1. CHANGEDSINCE FETCH modifier 540 This document defines the following FETCH modifier (see section 541 2.4 of [IMAPABNF]): 543 CHANGEDSINCE 545 CHANGEDSINCE FETCH modifier allows to further subset the list of 546 messages described by sequence set. The information described by 547 message data items is only returned for messages that have 548 mod-sequence bigger than . 550 When CHANGEDSINCE FETCH modifier is specified, it implicitly adds 551 MODSEQ FETCH message data item (section 3.3.2). 553 Example: 555 C: s100 UID FETCH 1:* (FLAGS) (CHANGEDSINCE 12345) 556 S: * 1 FETCH (UID 4 MODSEQ (65402) FLAGS (\Seen)) 557 S: * 2 FETCH (UID 6 MODSEQ (75403) FLAGS (\Deleted)) 558 S: * 4 FETCH (UID 8 MODSEQ (29738) FLAGS ($NoJunk $AutoJunk $MDNSent)) 559 S: s100 OK FETCH completed 561 3.3.2. MODSEQ message data item in FETCH Command 563 This extension adds a MODSEQ message data item to the FETCH command. 564 The MODSEQ message data item allows clients to retrieve mod-sequence 565 values for a range of messages in the currently selected mailbox. 567 Once the client specified the MODSEQ message data item in a FETCH request, 568 the server MUST include the MODSEQ fetch response data items in all 569 subsequent unsolicited FETCH responses. 571 Syntax: MODSEQ 573 The MODSEQ message data item causes the server to return MODSEQ fetch 574 response data items. 576 Syntax: MODSEQ ( ) 578 MODSEQ response data items contain per-message mod-sequences. 580 The MODSEQ response data item is returned if the client issued FETCH with 581 MODSEQ message data item. It also allows the server to notify the client 582 about mod-sequence changes caused by conditional STOREs (section 3.2) and/or 583 changes caused by external sources. 585 Example: 587 C: a FETCH 1:3 (MODSEQ) 588 S: * 1 FETCH (MODSEQ (624140003)) 589 S: * 2 FETCH (MODSEQ (624140007)) 590 S: * 3 FETCH (MODSEQ (624140005)) 591 S: a OK Fetch complete 593 In this example the client requests per message mod-sequences for a 594 set of messages. 596 When a flag for a message is modified in a different session, the server 597 sends an unsolicited FETCH response containing the mod-sequence for the 598 message. 600 Example: 602 (Session 1, authenticated as a user "alex"). The user adds a shared 603 flag \Deleted: 605 C: A142 SELECT INBOX 606 ... 607 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 608 S: * OK [PERMANENTFLAGS (\Answered \Deleted \Seen \*)] Limited 609 ... 611 C: A160 STORE 7 +FLAGS.SILENT (\Deleted) 612 S: * 7 FETCH (MODSEQ (2121231000)) 613 S: A160 OK Store completed 615 (Session 2, also authenticated as the user "alex"). Any changes to flags 616 are always reported to all sessions authenticated as the same user as in 617 the session 1. 619 C: C180 NOOP 620 S: * 7 FETCH (FLAGS (\Deleted \Answered) MODSEQ (12121231000)) 621 S: C180 OK Noop completed 623 (Session 3, authenticated as a user "andrew"). As \Deleted is a shared 624 flag, changes in the session 1 are also reported in the session 3: 626 C: D210 NOOP 627 S: * 7 FETCH (FLAGS (\Deleted \Answered) MODSEQ (12121231000)) 628 S: D210 OK Noop completed 630 The user modifies a private flag \Seen in the session 1 ... 632 C: A240 STORE 7 +FLAGS.SILENT (\Seen) 633 S: * 7 FETCH (MODSEQ (12121231777)) 634 S: A240 OK Store completed 636 ... which is only reported in the session 2 ... 638 C: C270 NOOP 639 S: * 7 FETCH (FLAGS (\Deleted \Answered \Seen) MODSEQ (12121231777)) 640 S: C270 OK Noop completed 642 ... but not in the session 3. 644 C: D300 NOOP 645 S: D300 OK Noop completed 647 And finally the user removes flags \Answered (shared) and \Seen (private) 648 in the session 1. 650 C: A330 STORE 7 -FLAGS.SILENT (\Answered \Seen) 651 S: * 7 FETCH (MODSEQ (12121245160)) 652 S: A330 OK Store completed 654 Both changes are reported in the session 2 ... 656 C: C360 NOOP 657 S: * 7 FETCH (FLAGS (\Deleted) MODSEQ (12121245160)) 658 S: C360 OK Noop completed 660 ... and only changes to shared flags are reported in session 3. 662 C: D390 NOOP 663 S: * 7 FETCH (FLAGS (\Deleted) MODSEQ (12121245160)) 664 S: D390 OK Noop completed 666 Server implementors should also see section 3.8 for additional quality of 667 implementation issues related to the FETCH command. 669 3.4. MODSEQ search criterion in SEARCH 671 The MODSEQ criterion for the SEARCH command allows a client to search 672 for the metadata items that were modified since a specified moment. 674 Syntax: MODSEQ [ ] 676 Messages that have modification values which are equal to or 677 greater than . This allows a client, 678 for example, to find out which messages contain metadata items 679 that have changed since the last time it updated its disconnected 680 cache. The client may also specify (name of metadata 681 item) and (type of metadata item) before 682 . can be one of "shared", 683 "priv" (private) or "all". The latter means that the server should use 684 the biggest value among "priv" and "shared" mod-sequences for the 685 metadata item. If the server doesn't store internally separate 686 mod-sequences for different metadata items, it MUST ignore 687 and . Otherwise the server should 688 use them to narrow down the search. 690 For a flag the corresponding has a form 691 "/flags/" as defined in [IMAPABNF]. Note, that 692 the leading "\" character that denotes a system flag has to be 693 escaped as per Section 4.3 of [IMAP4], as the uses 694 syntax for quoted strings. 696 If client specifies a MODSEQ criterion in a SEARCH command and 697 the server returns a non-empty SEARCH result, the server MUST also 698 append (to the end of the untagged SEARCH response) the highest 699 mod-sequence for all messages being returned. See also section 3.5. 701 Example: 702 C: a SEARCH MODSEQ "/flags/\\draft" all 620162338 703 S: * SEARCH 2 5 6 7 11 12 18 19 20 23 (MODSEQ 917162500) 704 S: a OK Search complete 706 In the above example, the message numbers of any messages 707 containing the string "IMAP4" in the "value" attribute of the 708 "/comment" entry and having a mod-sequence equal to or 709 greater than 620162338 for the "\Draft" flag are returned in 710 the search results. 712 Example: 713 C: t SEARCH OR NOT MODSEQ 720162338 LARGER 50000 714 S: * SEARCH 715 S: t OK Search complete, nothing found 717 3.5. Modified SEARCH untagged response 719 Data: zero or more numbers 720 mod-sequence value (omitted if no match) 722 This document extends syntax of the untagged SEARCH response 723 to include the highest mod-sequence for all messages being returned. 725 If a client specifies a MODSEQ criterion in a SEARCH (or UID SEARCH) 726 command and the server returns a non-empty SEARCH result, the server 727 MUST also append (to the end of the untagged SEARCH response) the 728 highest mod-sequence for all messages being returned. See section 729 3.4 for examples. 731 3.6. HIGHESTMODSEQ status data items 733 This document defines a new status data item: 735 HIGHESTMODSEQ 736 The highest mod-sequence value all messages 737 in the mailbox. This is the same value that is returned by the server 738 in the HIGHESTMODSEQ response code in OK untagged response 739 (see section 3.1.1). 741 Example: C: A042 STATUS blurdybloop (UIDNEXT MESSAGES HIGHESTMODSEQ) 742 S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292 743 HIGHESTMODSEQ 7011231777) 744 S: A042 OK STATUS completed 746 3.7. CONDSTORE parameter to SELECT and EXAMINE 748 The CONDSTORE extension defines a single optional select parameter 749 "CONDSTORE", which tells the server that it MUST include the MODSEQ 750 fetch response data items in all subsequent unsolicited FETCH responses. 752 The CONDSTORE parameter to SELECT/EXAMINE helps to avoid a race condition 753 that might arise when a metadata item(s) is(are) modified in another session 754 after the server has sent the HIGHESTMODSEQ response code and before the 755 client was able to issue a CONDSTORE enabling command. 757 Example: C: A142 SELECT INBOX (CONDSTORE) 758 S: * 172 EXISTS 759 S: * 1 RECENT 760 S: * OK [UNSEEN 12] Message 12 is first unseen 761 S: * OK [UIDVALIDITY 3857529045] UIDs valid 762 S: * OK [UIDNEXT 4392] Predicted next UID 763 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 764 S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited 765 S: * OK [HIGHESTMODSEQ 715194045007] 766 S: A142 OK [READ-WRITE] SELECT completed, CONDSTORE is now enabled 768 3.8. Additional quality of implementation issues. 770 Server implementations should follow the following rule, which applies 771 to any successfully completed STORE/UID STORE (with and without UNCHANGEDSINCE 772 modifier), as well as FETCH command which implicitly sets \Seen flag: 774 Adding the flag when it is already present or removing when it is not 775 present SHOULD NOT change the mod-sequence. 777 This will prevent spurious client synchronization requests. 779 However note that client implementors MUST NOT rely on this server behaviour. 780 Client can't distinguish between the case when a server has violated the SHOULD 781 mentioned above, or one or more client(s) setting and unsetting (or unsetting and 782 setting) the flag in another session(s). 784 4. Formal Syntax 786 The following syntax specification uses the Augmented Backus-Naur 787 Form (ABNF) [ABNF] notation. Elements not defined here can be found in 788 the formal syntax of the ABNF [ABNF], IMAP [IMAP4], and IMAP ABNF extensions 789 [IMAPABNF] specifications. 791 Except as noted otherwise, all alphabetic characters are case- 792 insensitive. The use of upper or lower case characters to define token 793 strings is for editorial clarity only. Implementations MUST accept 794 these strings in a case-insensitive fashion. 796 capability =/ "CONDSTORE" 798 status-att =/ "HIGHESTMODSEQ" 799 ;; extends non-terminal defined in RFC 3501. 801 status-att-val =/ "HIGHESTMODSEQ" SP mod-sequence-value 802 ;; extends non-terminal defined in [IMAPABNF]. 804 store-modifier =/ "UNCHANGEDSINCE" SP mod-sequence-valzer 805 ;; Only a single "UNCHANGEDSINCE" may be specified 806 ;; in a STORE operation 808 fetch-modifier =/ chgsince-fetch-mod 809 ;; conforms to the generic "fetch-modifier" syntax 810 ;; defined in [IMAPABNF]. 812 chgsince-fetch-mod = "CHANGEDSINCE" SP mod-sequence-value 813 ;; CHANGEDSINCE FETCH modifier conforms to 814 ;; the fetch-modifier syntax 816 fetch-att =/ fetch-mod-sequence 817 ;; modifies original IMAP4 fetch-att 819 fetch-mod-sequence = "MODSEQ" 821 fetch-mod-resp = "MODSEQ" SP "(" permsg-modsequence ")" 823 msg-att-dynamic =/ fetch-mod-resp 825 search-key =/ search-modsequence 826 ;; modifies original IMAP4 search-key 827 ;; 828 ;; This change applies to all command referencing this 829 ;; non-terminal, in particular SEARCH. 831 search-modsequence = "MODSEQ" [search-modseq-ext] SP mod-sequence-valzer 833 search-modseq-ext = SP entry-name SP entry-type-req 835 resp-text-code =/ "HIGHESTMODSEQ" SP mod-sequence-value / 836 "NOMODSEQ" / 837 "MODIFIED" SP set 839 entry-name = entry-flag-name 841 entry-flag-name = DQUOTE "/flags/" attr-flag DQUOTE 842 ;; each system or user defined flag 843 ;; is mapped to "/flags/". 844 ;; 845 ;; follows the escape rules used 846 ;; by "quoted" string as described in Section 847 ;; 4.3 of [IMAP4], e.g. for the flag \Seen 848 ;; the corresponding is 849 ;; "/flags/\\seen", and for the flag 850 ;; $MDNSent, the corresponding 851 ;; is "/flags/$mdnsent". 853 entry-type-resp = "priv" / "shared" 854 ;; metadata item type 856 entry-type-req = entry-type-resp / "all" 857 ;; perform SEARCH operation on private 858 ;; metadata item, shared metadata item or both 860 permsg-modsequence = mod-sequence-value 861 ;; per message mod-sequence 863 mod-sequence-value = 1*DIGIT 864 ;; Positive unsigned 64-bit integer (mod-sequence) 865 ;; (1 <= n < 18,446,744,073,709,551,615) 867 mod-sequence-valzer = "0" / mod-sequence-value 869 search-sort-mod-seq = "(" "MODSEQ" SP mod-sequence-value ")" 871 select-param =/ condstore-param 872 ;; conforms to the generic "select-param" non-terminal 873 ;; syntax defined in [IMAPABNF]. 875 condstore-param = "CONDSTORE" 877 mailbox-data =/ "SEARCH" [1*(SP nz-number) SP search-sort-mod-seq] 879 attr-flag = "\\Answered" / "\\Flagged" / "\\Deleted" / 880 "\\Seen" / "\\Draft" / attr-flag-keyword / 881 attr-flag-extension 882 ;; Does not include "\\Recent" 884 attr-flag-extension = "\\" atom 885 ;; Future expansion. Client implementations 886 ;; MUST accept flag-extension flags. Server 887 ;; implementations MUST NOT generate 888 ;; flag-extension flags except as defined by 889 ;; future standard or standards-track 890 ;; revisions of [IMAP4]. 892 attr-flag-keyword = atom 894 5. Server implementation considerations 896 This section describes how a server implementation that 897 doesn't store separate per-metadata modsequences for different metadata 898 items can avoid sending MODIFIED response to any of the following 899 conditional STORE operations: 900 +FLAGS 901 -FLAGS 902 +FLAGS.SILENT 903 -FLAGS.SILENT 905 Note, that the optimization described in this section can't be performed 906 in case of a conditional STORE FLAGS operation. 908 Let's use the following example. The client has issued 910 C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000) 911 +FLAGS.SILENT ($Processed) 913 When the server receives the command and parses it successfully it 914 iterates through the message set and tries to execute the conditional 915 STORE command for each message. 917 Each server internally works as a client, i.e. it has to cache the 918 current state of all IMAP flags as it is known to the client. 919 In order to report flag changes to the client the server compares the 920 cached values with the values in its database for IMAP flags. 922 Imagine that another client has changed the state of a flag \Deleted on 923 message 101 and the change updated the modsequence for the message. 924 The server knows that the modsequence for the mailbox has changed, however 925 it also knows that 927 a) The client is not interested in \Deleted flag, as it hasn't included 928 it in +FLAGS.SILENT operation. 929 b) The state of the flag $Processed hasn't changed (server can determine 930 this by comparing cached flag state with the state of the flag in the 931 database), 932 so the server doesn't have to report MODIFIED to the client. Instead the 933 server may set $Processed flag, update the modsequence for the message 101 934 once again and send an untagged FETCH response with new modsequence and 935 flags: 937 S: * 101 FETCH (MODSEQ (303011130956) 938 FLAGS ($Processed \Deleted \Answered)) 940 See also section 3.8 for additional quality of implementation issues. 942 6. Security Considerations 944 It is believed that the Conditional STORE extension doesn't raise 945 any new security concerns that are not already discussed in [IMAP4]. 946 However, the availability of this extension may make it possible 947 for IMAP4 to be used in critical applications it could not be used 948 for previously, making correct IMAP server implementation and 949 operation even more important. 951 7. References 953 7.1. Normative References 955 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 956 Requirement Levels", RFC 2119, Harvard University, March 1997. 958 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: 959 ABNF", RFC 4234, October 2005. 961 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 962 4rev1", RFC 3501, University of Washington, March 2003. 964 [IMAPABNF] Melnikov, A., "Collected extensions to IMAP4 ABNF", 965 work in progress. 966 968 7.2. Informative References 970 [ACAP] Newman, Myers, "ACAP -- Application Configuration Access 971 Protocol", RFC 2244, Innosoft, Netscape, November 1997. 972 974 [ACL] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", 975 RFC 4314, December 2005. 976 978 [NTP] Mills, D, "Network Time Protocol (Version 3) Specification, 979 Implementation and Analysis", RFC 1305, March 1992. 980 982 [RFC-2180] Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", 983 RFC 2180, July 1997. 984 986 8. IANA Considerations 988 IMAP4 capabilities are registered by publishing a standards track or 989 IESG approved experimental RFC. The registry is currently located 990 at: 992 http://www.iana.org/assignments/imap4-capabilities 994 This document defines the CONDSTORE IMAP capability. 995 IANA should add them to the registry accordingly. 997 9. Acknowledgments 999 Some text was borrowed from "IMAP ANNOTATE Extension" by Randall Gellens 1000 and Cyrus Daboo, and "ACAP -- Application Configuration Access Protocol" 1001 by Chris Newman and John Myers. 1003 Many thanks to Randall Gellens for his thorough review of the document. 1005 The authors also acknowledge the feedback provided by Cyrus Daboo, Larry 1006 Greenfield, Chris Newman, Harrie Hazewinkel, Arnt Gulbrandsen, Timo 1007 Sirainen, Mark Crispin, Ned Freed, Ken Murchison and Dave Cridland. 1009 10. Author's Addresses 1011 Alexey Melnikov 1012 mailto: Alexey.Melnikov@isode.com 1014 Isode Limited 1015 5 Castle Business Village, 36 Station Road, 1016 Hampton, Middlesex, TW12 2BX, United Kingdom 1018 Steve Hole 1019 mailto: Steve.Hole@messagingdirect.com 1021 ACI WorldWide/MessagingDirect 1023 11. Intellectual Property Statement 1025 The IETF takes no position regarding the validity or scope of any 1026 Intellectual Property Rights or other rights that might be claimed to 1027 pertain to the implementation or use of the technology described in 1028 this document or the extent to which any license under such rights 1029 might or might not be available; nor does it represent that it has 1030 made any independent effort to identify any such rights. Information 1031 on the procedures with respect to rights in RFC documents can be 1032 found in BCP 78 and BCP 79. 1034 Copies of IPR disclosures made to the IETF Secretariat and any 1035 assurances of licenses to be made available, or the result of an 1036 attempt made to obtain a general license or permission for the use of 1037 such proprietary rights by implementers or users of this 1038 specification can be obtained from the IETF on-line IPR repository at 1039 http://www.ietf.org/ipr. 1041 The IETF invites any interested party to bring to its attention any 1042 copyrights, patents or patent applications, or other proprietary 1043 rights that may cover technology that may be required to implement 1044 this standard. Please address the information to the IETF at 1045 ietf-ipr@ietf.org. 1047 The IETF has been notified of intellectual property rights claimed in 1048 regard to some or all of the specification contained in this 1049 document. For more information consult the online list of claimed 1050 rights. 1052 Disclaimer of Validity 1054 This document and the information contained herein are provided on an 1055 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1056 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1057 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1058 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1059 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1060 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1062 Copyright Statement 1064 Copyright (C) The Internet Society (2006). This document is subject 1065 to the rights, licenses and restrictions contained in BCP 78, and 1066 except as set forth therein, the authors retain all their rights. 1068 Acknowledgment 1070 Funding for the RFC Editor function is currently provided by the 1071 Internet Society. 1073 Appendix A. Change History 1075 [[Note to RFC editor: please remove this appendix before publication.]] 1077 0.1. Change History 1079 Changes from draft-ietf-imapext-condstore-08 1080 1. Updated examples not to use time-like modification sequences, 1081 in order not to confuse implementors. (As per comment from 1082 Mark Crispin) 1083 2. Clarified beginning of the second paragraph of section 2, 1084 as per GenArt comment. 1085 3. Updated (informative) reference to ACL RFC. 1086 4. Some other editorial changes to reference [IMAPABNF] content. 1087 5. Repeated and explained the requirement on server implementations 1088 not to bump modification sequence when a flag change operation 1089 results in no flag changes. 1090 6. Explained in Abstract that the CONDSTORE extension can also 1091 be used for quick mailbox resynchronization. 1093 Changes from draft-ietf-imapext-condstore-07 1094 1. Reworded not to have any normative references to SORT. 1095 SORT=MODSEQ has been moved to a separate draft. 1097 Changes from draft-ietf-imapext-condstore-06 1098 1. Minor ABNF update to reference IMAP ABNF properly. 1100 Changes from draft-ietf-imapext-condstore-05 1101 1. Reworded not to have a normative reference to ANNOTATE. 1102 2. Updated ABNF to reference IMAP ABNF. 1103 3. Clarified that STATUS (HIGHESTMODSEQ) also enables 1104 CONDSTORE notifications. 1105 4. Fixed few typos in examples or example titles. 1106 5. Updated boilerplate, references. 1108 Changes from draft-ietf-imapext-condstore-04 1109 1. Fixed typo in an example, added more examples. 1110 2. Clarified client behavior regarding retrying the request 1111 when the server returns MODIFIED (IESG comment) 1112 3. Added new section describing how a CONDSTORE server implementation 1113 should avoid sending MODIFIED when the client has requested 1114 a conditional store on a flag A and a flag B was modified 1115 by another client. (IESG comment) 1117 Changes from draft-ietf-imapext-condstore-03 1118 1. ABNF corrections from Ned Freed. 1119 2. Minor spelling/wording corrections from Ned Freed. 1121 Changes from draft-ietf-imapext-condstore-02 1122 1. Added FETCH modifiers. 1123 2. Added example for using ANNOTATE with UNCHANGEDSINCE STORE 1124 modifier. 1125 3. Added a new requirement to send HIGHESTMODSEQ response code 1126 when implicit enabling is used. 1127 4. Fixed syntax in an example in section 3.2. 1129 Changes from draft-ietf-imapext-condstore-01 1130 1. Fixed missing \\ in one example. 1131 2. Added explanatory comment that search-key modifications apply at 1132 least to SEARCH and SORT command. 1133 3. Don't require from a conditional store operation to be atomic accross 1134 message set, updated text and examples. 1135 4. Added SORT=MODSEQ extension and reworked text in the Introduction section. 1136 5. Added Conditional STORE example based on suggestions from RFC 2180. 1137 6. Removed the paragraph about DOS attack from the Security considerations 1138 section, as it doesn't apply anymore. 1139 7. Updated entry-name ABNF. 1140 8. Added an optional CONDSTORE parameter to SELECT/EXAMINE. 1142 Changes from draft-ietf-imapext-condstore-00 1143 1. Dropped "/message" prefix in entry names as per decision in San Francisco. 1144 2. Fixed ABNF for SEARCH and SORT untagged responses. 1145 3. Changed "private" to "priv" to be consistent with ANNOTATE. 1146 4. MODIFIED response code is now returned in OK response, not NO. 1147 5. Added NOMODSEQ response code. 1149 Changes from draft-melnikov-imap-condstore-09: 1150 1. Some text clarifications based on suggestions by Harrie Hazewinkel 1151 2. Added paragraph about mailbox locking and DOS when conditional STORE 1152 operation is performed on a large mailbox. 1153 3. Fixed syntax of to match the ANNOTATE extension. 1154 4. Added sentence that a system flag MUST always be considered existent, 1155 when UNCHANGEDSINCE 0 is used. Is this a good idea? 1156 5. Clarified client behavior upon receipt of MODIFIED response code. 1157 6. Updated ABNF to clarify where 0 is allowed as mod-sequence and where 1158 it is not. 1159 7. Got rid of MODSEQ response code and return this data in the untagged 1160 SEARCH/SORT responses. 1161 8. Updated RFC number for the IMAP4rev1 document. 1163 Changes from -08 to -09: 1164 1. Added an extended example about reporting regular (non-conditional) flag 1165 changes to other sessions. 1166 2. Simplified FETCH MODSEQ syntax by removing per-metadata requests and 1167 responses. 1169 Changes from -07 to -08: 1170 1. Added note saying the change to UIDVALIDITY also invalidates HIGHESTMODSEQ. 1171 2. Fixed several bugs in ABNF for STATUS and STORE commands. 1173 Changes from -06 to -07: 1174 1. Added clarification that when a server does command reordering, the second 1175 completed operation gets the higher mod sequence. 1176 2. Renamed annotation type specifier "both" to "all" as per suggestion 1177 from Minneapolis meeting. 1178 3. Removed PERFLAGMODSEQ capability, as it doesn't buy anything: a client 1179 has to work with both types of servers (i.e. servers that support per 1180 message per flag modseqs and servers that support only per message 1181 modseqs) anyway. 1182 4. Per flag mod-sequences are optional for a server to return. Updated syntax. 1183 5. Allow MODSEQ response code only as a result of SEARCH/SORT as suggested 1184 by John Myers. MODSEQ response code is not allowed after FETCH or STORE. 1186 Changes from -05 to -06: 1187 1. Replaced "/message/flags/system" with "/message/flags" to 1188 match ANNOTATE draft. 1189 2. Extended FETCH/SEARCH/SORT syntax to allow for specifying 1190 whether an operation should be performed on a shared or a private 1191 annotation (or both). 1192 3. Corrected some examples. 1194 Changes from -04 to -05: 1195 1. Added support for SORT extension. 1196 2. Multiple language/spelling fixes by Randall Gellens. 1198 Changes from -03 to -04: 1199 1. Added text saying that MODSEQ fetch data items cause server 1200 to include MODSEQ data response in all subsuquent unsolicited FETCH 1201 responses. 1202 2. Added "authors address" section. 1204 Changes from -02 to -03: 1205 1. Changed MODTIME untagged response to MODTIME response code. 1206 2. Added MODTIME response code to the tagged OK response for SEARCH. 1207 Updated examples accordingly. 1208 3. Changed rule for sending untagged FETCH response as a result of 1209 STORE when .SILENT prefix is used. If .SILENT prefix is used, 1210 server doesn't have to send untagged FETCH response, because 1211 MODTIME response code already contains modtime. 1212 4. Renamed MODTIME to MODSEQ to make sure there is no confusion 1213 between mod-sequence and ACAP modtime. 1214 5. Minor ABNF changes. 1215 6. Minor language corrections. 1217 Changes from -01 to -02: 1218 1. Added MODTIME data item to STATUS command. 1219 2. Added OK untagged response to SELECT/EXAMINE. 1220 3. Clarified that MODIFIED response code contains list of UIDs for 1221 conditional UID STORE and message set for STORE. 1222 4. Added per-message modtime. 1223 5. Added PERFLAGMODTIME capability. 1224 6. Fixed several bugs in examples. 1225 7. Added more comments to ABNF. 1227 Changes from -00 to -01: 1228 1. Refreshed the list of Open Issues. 1229 2. Changed "attr-name" to "entry-name", because modtime applies to 1230 entry, not attribute. 1231 3. Added MODTIME untagged response. 1232 4. Cleaned up ABNF. 1233 5. Added "Acknowledgments" section. 1234 6. Fixed some spelling mistakes.