idnits 2.17.1 draft-ietf-imapext-condstore-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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 1204 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 268 instances of too long lines in the document, the longest one being 18 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (October 2003) is 7497 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 757, but not defined == Missing Reference: 'UIDVALIDITY 3857529045' is mentioned on line 758, but not defined == Missing Reference: 'UIDNEXT 4392' is mentioned on line 759, but not defined == Missing Reference: 'HIGHESTMODSEQ 20010715194045007' is mentioned on line 762, but not defined == Missing Reference: 'HIGHESTMODSEQ 200012111230047' is mentioned on line 346, but not defined == Missing Reference: 'MODIFIED 7' is mentioned on line 375, but not defined -- Looks like a reference, but probably isn't: '9' on line 375 == Missing Reference: 'MODIFIED 12' is mentioned on line 385, but not defined == Missing Reference: 'MODIFIED 101' is mentioned on line 408, but not defined == Missing Reference: 'MODIFIED 2' is mentioned on line 440, but not defined == Unused Reference: 'ACAP' is defined on line 938, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3501 (ref. 'IMAP4') (Obsoleted by RFC 9051) -- Possible downref: Non-RFC (?) normative reference: ref. 'ANNOTATE' -- Possible downref: Non-RFC (?) normative reference: ref. 'SORT' -- Obsolete informational reference (is this intentional?): RFC 2086 (ref. 'ACL') (Obsoleted by RFC 4314) -- Obsolete informational reference (is this intentional?): RFC 1305 (ref. 'NTP') (Obsoleted by RFC 5905) Summary: 6 errors (**), 0 flaws (~~), 12 warnings (==), 8 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-04.txt Isode Ltd. 3 Expires: April 2004 S. Hole 4 ACI WorldWide/MessagingDirect 5 October 2003 7 IMAP Extension for Conditional STORE operation 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet-Drafts are 13 working documents of the Internet Engineering Task Force (IETF), its 14 areas, and its working groups. Note that other groups may also 15 distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other documents 19 at any time. It is inappropriate to use Internet-Drafts as 20 reference material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- 24 Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 Copyright Notice 29 Copyright (C) The Internet Society 2001-2003. All Rights Reserved. 31 Please see the Full Copyright section near the end of this document 32 for more information. 34 Abstract 36 Often, multiple IMAP clients need to coordinate changes to a common 37 IMAP mailbox. Examples include different clients for the same user, 38 and multiple users accessing shared mailboxes. These clients 39 need a mechanism to synchronize state changes for messages within the 40 mailbox. They must be able to guarantee that only one client can change 41 message state (e.g., message flags or annotations) at any time. An 42 example of such an application is use of an IMAP mailbox as a message 43 queue with multiple dequeueing clients. 45 The Conditional Store facility provides a protected update mechanism for 46 message state information that can detect and resolve conflicts between 47 multiple writing mail clients. 49 Table of Contents 51 1 Conventions Used in This Document ......................... X 52 2 Introduction and Overview ................................. X 53 3 IMAP Protocol Changes ..................................... X 54 3.1 New OK untagged responses for SELECT and EXAMINE ......... X 55 3.1.1 HIGHESTMODSEQ response code ............................ X 56 3.1.2 NOMODSEQ response code ................................. X 57 3.2 STORE and UID STORE Commands ............................. X 58 3.3 FETCH and UID FETCH Commands ............................. X 59 3.3.1 FETCH modifiers ........................................ X 60 3.3.2 MODSEQ message data item in FETCH Command .............. X 61 3.4 MODSEQ search criterion in SEARCH ........................ X 62 3.5 MODSEQ Sort Criterion .................................... X 63 3.6 Modified SEARCH and SORT untagged responses .............. X 64 3.7 HIGHESTMODSEQ status data items .......................... X 65 3.8 CONDSTORE parameter to SELECT and EXAMINE ................ X 66 4 Formal Syntax ............................................. X 67 5 Security Considerations ................................... X 68 6 References ................................................ X 69 6.1 Normative References ..................................... X 70 6.2 Informative References ................................... X 71 7 IANA Considerations ....................................... X 72 8 Acknowledgments ........................................... X 73 9 Author's Addresses ........................................ X 74 10 Intellectual Property Rights .............................. X 75 11 Full Copyright Statement .................................. X 77 1. Conventions Used in This Document 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 83 In examples, lines beginning with "S:" are sent by the IMAP server, and 84 lines beginning with "C:" are sent by the client. Line breaks may appear 85 in example commands solely for editorial clarity; when present in 86 the actual message they are represented by "CRLF". 88 Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4]. 90 The term "metadata" or "metadata item" is used throughout this document. 91 It refers to any system or user defined keyword or an annotation 92 [ANNOTATE]. 94 Some IMAP mailboxes are private, accessible only to the owning user. 95 Other mailboxes are not, either because the owner has set an ACL 96 [ACL] which permits access by other users, or because it is a 97 shared mailbox. Let's call a metadata item "shared" for the mailbox 98 if any changes to the metadata items are persistent and visible to all 99 other users accessing the mailbox. Otherwise the metadata item is called 100 "private". Note, that private metadata items are still visible to all 101 sessions accessing the mailbox as the same user. Also note, that different 102 mailboxes may have different metadata items as shared. 104 See the next section for the definition of a "CONDSTORE-aware client" 105 and a "CONDSTORE enabling command". 107 2. Introduction and Overview 109 The Conditional STORE extension is present in any IMAP4 implementation 110 which returns "CONDSTORE" as one of the supported capabilities in the 111 CAPABILITY command response. 113 Every IMAP message has an associated positive unsigned 64-bit value called a 114 modification sequence (mod-sequence). This is an opaque value updated by 115 the server whenever a metadata item is modified. The value is intended to 116 be used only for comparisons within a server. However, the server MUST 117 guarantee that each STORE command performed on the same mailbox, including 118 simultaneous stores to different metadata items from different connections, 119 will get a different mod-sequence value. Also, for any two successful 120 STORE operations performed in the same session on the same mailbox, 121 the mod-sequence of the second completed operation MUST be greater than 122 the mod-sequence of the first completed. Note that the latter rule disallows 123 the use of the system clock as a mod-sequence, because if system time changes 124 (e.g., a NTP [NTP] client adjusting the time), the next generated value might 125 be less than the previous one. 127 Mod-sequences allow a client that supports the CONDSTORE extension to 128 determine if a message metadata has changed since some known 129 moment. Whenever the state of a flag changes (i.e., the flag is added and 130 before it wasn't set, or the flag is removed and before it was set) the 131 value of the modification sequence for the message MUST be updated. 132 Adding the flag when it is already present or removing when it is not 133 present SHOULD NOT change the mod-sequence. 135 When a message is appended to a mailbox (via the IMAP APPEND command, 136 COPY to the mailbox or using an external mechanism) the server 137 generates a new modification sequence that is higher than the highest 138 modification sequence of all messages in the mailbox and assigns it to 139 the appended message. 141 When an annotation [ANNOTATE] is added, modified or removed the corresponding 142 message mod-sequence MUST be updated. 144 The server MAY store separate (per message) modification sequence values for 145 different metadata items. If the server does so, per message mod-sequence is 146 the highest mod-sequence of all metadata items for the specified message. 148 The server that supports this extension is not required to be able to store 149 mod-sequences for every available mailbox. Section 3.1.2 describes how 150 the server may act if a particular mailbox doesn't support the persistent 151 storage of mod-sequences. 153 This extension makes the following changes to the IMAP4 protocol: 155 a) extends the syntax of the STORE command to allow STORE 156 modifiers 158 b) adds the MODIFIED response code which should be used with 159 an OK response to the STORE command 161 c) adds a new MODSEQ message data item for use with the FETCH command 163 d) extends the syntax of the FETCH command to allow FETCH 164 modifiers 166 e) adds a new MODSEQ search criterion 168 f) extends the syntax of untagged SEARCH responses to include mod-sequence 170 g) adds new OK untagged responses for the SELECT and EXAMINE commands 172 h) defines an additional parameter to SELECT/EXAMINE commands 174 i) adds the HIGHESTMODSEQ status data item to the STATUS command 176 A client supporting CONDSTORE extension indicates its willingness to receive 177 mod-sequence updates in all untagged FETCH responses by issuing a SELECT or 178 EXAMINE command with the CONDSTORE parameter, or a FETCH, SEARCH, or SORT 179 (if it also supports SORT=MODSEQ extension, see below) command that includes 180 the MODSEQ message data item, a FETCH command with the CHANGEDSINCE modifier, 181 or a STORE command with the UNCHANGEDSINCE modifier. 182 The server will include mod-sequence data in all FETCH responses, whether they 183 were caused by a regular STORE, STORE with UNCHANGEDSINCE modifier, or an external 184 agent, until the connection is closed. 186 This document uses the term "CONSTORE-aware client" to refer to a client 187 that announces its willingness to receive mod-sequence updates as described 188 above. The term "CONDSTORE enabling command" will refer any of the commands 189 listed above. A first CONDSTORE enabling command executed in the session 190 MUST cause the server to return HIGHESTMODSEQ (section 3.1.1) unless the 191 server has sent NOMODSEQ (section 3.1.2) response code when the currently 192 selected mailbox was selected. 194 This document also defines a new SORT extension with a capability name 195 "SORT=MODSEQ". This extension is upwards compatible with the SORT extension 196 defined in [SORT]. Server implementations that support both the CONDSTORE and 197 SORT extensions SHOULD also support the SORT=MODSEQ extension. The 198 SORT=MODSEQ extension makes the following additions to the SORT extension: 200 a) extends syntax of untagged SORT responses to include mod-sequence 201 (see section 3.6) 203 b) adds a new MODSEQ sort criterion (see sections 3.4 and 3.5) 205 The rest of this document describes the protocol changes more rigorously. 207 3. IMAP Protocol Changes 209 3.1. New OK untagged responses for SELECT and EXAMINE 211 This document adds two new response codes HIGHESTMODSEQ and NOMODSEQ. 212 One of those response codes MUST be returned in the OK untagged 213 response for a successful SELECT and EXAMINE commands. 215 When opening a mailbox the server must check if the mailbox supports 216 the persistent storage of mod-sequences. If the mailbox supports 217 the persistent storage of mod-sequences and mailbox open operation succeeds, 218 the server MUST send the OK untagged response including HIGHESTMODSEQ 219 response code. If the persistent storage for the mailbox is not supported, 220 the server MUST send the OK untagged response including NOMODSEQ response 221 code instead. 223 3.1.1. HIGHESTMODSEQ response code 225 This document adds a new response code that is returned in the OK 226 untagged response for the SELECT and EXAMINE commands. A server 227 supporting the persistent storage of mod-sequences for the mailbox MUST 228 send the OK untagged response including HIGHESTMODSEQ response code with 229 every successful SELECT or EXAMINE command: 231 OK [HIGHESTMODSEQ ] 233 Where is the highest mod-sequence value of all 234 messages in the mailbox. When the server changes UIDVALIDITY for a 235 mailbox, it doesn't have to keep the same HIGHESTMODSEQ for the 236 mailbox. 238 A disconnected client can use the value of HIGHESTMODSEQ to check if 239 it has to refetch flags and/or annotations from the server. If the 240 UIDVALIDITY value has changed for the selected mailbox, the client 241 MUST delete the cached value of HIGHESTMODSEQ. If UIDVALIDITY for 242 the mailbox is the same and if the HIGHESTMODSEQ value stored in 243 the client's cache is less than the value returned by the server, 244 then some metadata items on the server have changed since the last 245 synchronization, and the client needs to update its cache. The client 246 MAY use SEARCH MODSEQ as described in section 3.4 to find out exactly 247 which metadata items have changed. Alternatively the client MAY issue 248 FETCH with CHANGEDSINCE modifier (section 3.3.1) in order to fetch data 249 for all messages that have metadata items changed since some known 250 modification sequence. 252 Example: C: A142 SELECT INBOX 253 S: * 172 EXISTS 254 S: * 1 RECENT 255 S: * OK [UNSEEN 12] Message 12 is first unseen 256 S: * OK [UIDVALIDITY 3857529045] UIDs valid 257 S: * OK [UIDNEXT 4392] Predicted next UID 258 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 259 S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited 260 S: * OK [HIGHESTMODSEQ 20010715194045007] 261 S: A142 OK [READ-WRITE] SELECT completed 263 3.1.2 NOMODSEQ response code 265 A server that doesn't support the persistent storage of mod-sequences for 266 the mailbox MUST send the OK untagged response including NOMODSEQ response 267 code with every successful SELECT or EXAMINE command. 269 Example: C: A142 SELECT INBOX 270 S: * 172 EXISTS 271 S: * 1 RECENT 272 S: * OK [UNSEEN 12] Message 12 is first unseen 273 S: * OK [UIDVALIDITY 3857529045] UIDs valid 274 S: * OK [UIDNEXT 4392] Predicted next UID 275 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 276 S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited 277 S: * OK [NOMODSEQ] Sorry, this mailbox format doesn't support modsequences 278 S: A142 OK [READ-WRITE] SELECT completed 280 3.2. STORE and UID STORE Commands 282 Arguments: message set 283 OPTIONAL store modifiers 284 message data item name 285 value for message data item 287 Responses: untagged responses: FETCH 289 Result: OK - store completed 290 NO - store error: can't store that data 291 BAD - command unknown or arguments invalid 293 This document extends the syntax of the STORE and UID STORE 294 commands (see section 6.4.6 of [IMAP4]) to include an optional STORE 295 modifier. The document defines the following modifier: 297 UNCHANGEDSINCE 298 For each message specified in the message set the server performs 299 the following. If the mod-sequence of any metadata item of the 300 message is equal or less than the specified UNCHANGEDSINCE value, 301 then the requested operation (as described by the 302 message data item) is performed. If the operation is successful 303 the server MUST update the mod-sequence attribute of the message. 304 An untagged FETCH response MUST be sent (even if the .SILENT suffix 305 is specified or ANNOTATION message data item is used; the latter 306 changes the behavior described in Section 9.4 of [ANNOTATE]) 307 and the response MUST include the MODSEQ message data 308 item. This is required to update the client's cache with the correct 309 mod-sequence values. See section 3.3.2 for more details. 311 However, if the mod-sequence of any metadata item of the 312 message is greater than the specified UNCHANGEDSINCE value, than 313 the requested operation MUST NOT be performed. In this case, 314 the mod-sequence attribute of the message is not updated, and the 315 message number (or unique identifier in the case of the UID STORE 316 command) is added to the list of messages that failed the UNCHANGESINCE test. 318 When the server finished performing the operation on all the messages 319 in the message set, it checks for a non-empty list of messages that 320 failed the UNCHANGESINCE test. If this list is non-empty, the server MUST 321 return in the tagged response a MODIFIED response code. The MODIFIED 322 response code includes the message set (for STORE) or set of UIDs 323 (for UID STORE) of all messages that failed the UNCHANGESINCE test. 325 Example : 327 All messages pass the UNCHANGESINCE test. 329 C: a103 UID STORE 6,4,8 (UNCHANGEDSINCE 200012121230045) 330 +FLAGS.SILENT (\Deleted) 331 S: * 1 FETCH (UID 4 MODSEQ (200012121231000)) 332 S: * 2 FETCH (UID 6 MODSEQ (200012101230852)) 333 S: * 4 FETCH (UID 8 MODSEQ (200012121130956)) 334 S: a103 OK Conditional Store completed 336 Example: 338 C: a104 STORE * (UNCHANGEDSINCE 200012121230045) +FLAGS.SILENT 339 (\Deleted $Processed) 340 S: * 50 FETCH (MODSEQ (200012111230047)) 341 S: a104 OK Store (conditional) completed 343 Example: 344 C: c101 STORE 1 (UNCHANGEDSINCE 200012121230045) ANNOTATION 345 ("/message/comment" ("value.priv" "My new comment")) 346 S: * OK [HIGHESTMODSEQ 200012111230047] 347 S: * 50 FETCH (MODSEQ (200012111230048)) 348 S: c101 OK Store (conditional) completed 350 HIGHESTMODSEQ response code was sent by the server 351 presumably because this was the first CONDSTORE enabling 352 command. 354 Example: 356 In spite of the failure of the conditional STORE operation 357 for message 7, the server continues to process the conditional 358 STORE in order to find all messages which fail the test. 360 C: a105 STORE 7,5,9 (UNCHANGEDSINCE 20000320162338) 361 +FLAGS.SILENT (\Deleted) 362 S: * 5 FETCH (MODSEQ (20000320162350)) 363 S: a105 OK [MODIFIED 7,9] Conditional STORE failed 365 Example: 367 Same as above, but the server follows SHOULD recommendation 368 in section 6.4.6 of [IMAP4]. 370 C: a105 STORE 7,5,9 (UNCHANGEDSINCE 20000320162338) 371 +FLAGS.SILENT (\Deleted) 372 S: * 7 FETCH (MODSEQ (20000320162342) FLAGS (\Seen \Deleted)) 373 S: * 5 FETCH (MODSEQ (20000320162350)) 374 S: * 9 FETCH (MODSEQ (20000320162349) FLAGS (\Answered)) 375 S: a105 OK [MODIFIED 7,9] Conditional STORE failed 377 Use of UNCHANGEDSINCE with a modification sequence of 0 378 always fails if the metadata item exists. A system flag 379 MUST always be considered existent, whether it was set or not. 381 Example: 383 C: a102 STORE 12 (UNCHANGEDSINCE 0) 384 +FLAGS.SILENT ($MDNSent) 385 S: a102 OK [MODIFIED 12] Conditional STORE failed 387 Note: A client trying to make an atomic change to the state of a particular 388 metadata item (or a set of metadata items) should be prepared 389 to deal with the case when the server returns MODIFIED response code 390 if the state of the metadata item being watched hasn't changed (but 391 the state of some other metadata item has). This is necessary, because 392 some servers don't store separate mod-sequences for different metadata 393 items. However, a server implementation SHOULD avoid generating 394 spurious MODIFIED responses for +FLAGS/-FLAGS STORE operations, 395 even when the server stores a single mod-sequence per message. 397 Upon the receipt of MODIFIED response code the client SHOULD try to 398 figure out if the required metadata items have indeed changed. If they 399 haven't the client SHOULD retry the command. 401 Example: 402 C: a106 STORE 100:150 (UNCHANGEDSINCE 200212030000000) 403 +FLAGS.SILENT ($Processed) 404 S: * 100 FETCH (MODSEQ (200303181230852)) 405 S: * 102 FETCH (MODSEQ (200303181230852)) 406 ... 407 S: * 150 FETCH (MODSEQ (200303181230852)) 408 S: a106 OK [MODIFIED 101] Conditional STORE failed 410 the flag $Processed was set on the message 101 ... 411 C: a107 NOOP 412 S: * 101 FETCH (MODSEQ (200303011130956) FLAGS ($Processed)) 413 S: a107 OK 415 Or the flag hasn't changed ... 416 C: b107 NOOP 417 S: * 101 FETCH (MODSEQ (200303011130956) FLAGS (\Deleted \Answered)) 418 S: b107 OK 420 ... and the client retries the operation for the message 100 421 with the updated UNCHANGEDSINCE value 423 C: b108 STORE 100 (UNCHANGEDSINCE 200303011130956) 424 +FLAGS.SILENT ($Processed) 425 S: * 100 FETCH (MODSEQ (200303181230852)) 426 S: b108 OK Conditional Store completed 428 Example: 430 The following example is based on the example from the section 4.2.3 of 431 [RFC-2180] and demonstrates that the MODIFIED response code may be also 432 returned in the tagged NO response. 434 Client tries to conditionally STORE flags on a mixture of expunged 435 and non-expunged messages, one message fails the UNCHANGEDSINCE test. 437 C: B001 STORE 1:7 (UNCHANGEDSINCE 20000320172338) +FLAGS (\SEEN) 438 S: * 1 FETCH (MODSEQ (20000320172342) FLAGS (\SEEN)) 439 S: * 3 FETCH (MODSEQ (20000320172342) FLAGS (\SEEN)) 440 S: B001 NO [MODIFIED 2] Some of the messages no longer exist. 442 C: B002 NOOP 443 S: * 4 EXPUNGE 444 S: * 4 EXPUNGE 445 S: * 4 EXPUNGE 446 S: * 4 EXPUNGE 447 S: * 2 FETCH (MODSEQ (20000320172340) FLAGS (\Deleted \Answered)) 448 S: B002 OK NOOP Completed. 450 By receiving FETCH responses for messages 1 and 3, and EXPUNGE 451 responses that indicate that messages 4:7 have been expunged, 452 the client retries the operation only for the message 2. The 453 updated UNCHANGEDSINCE value is used. 455 C: b003 STORE 2 (UNCHANGEDSINCE 20000320172340) +FLAGS (\Seen) 456 S: * 2 FETCH (MODSEQ (20000320180050)) 457 S: b003 OK Conditional Store completed 459 Note: If a message is specified multiple times in the message 460 set, and the server doesn't internally eliminate duplicates from 461 the message set, it MUST NOT fail the conditional STORE 462 operation for the second (or subsequent) occurrence of the message 463 if the operation completed successfully for the first occurrence. 464 For example, if the client specifies: 466 a105 STORE 7,3:9 (UNCHANGEDSINCE 200012121230045) 467 +FLAGS.SILENT (\Deleted) 469 the server must not fail the operation for message 7 as part of 470 processing "3:9" if it succeeded when message 7 was processed 471 the first time. 473 Once the client specified the UNCHANGEDSINCE modifier in a STORE command, 474 the server MUST include the MODSEQ fetch response data items in all 475 subsequent unsolicited FETCH responses. 477 This document also changes the behaviour of the server when it has performed 478 a STORE or UID STORE command and the UNCHANGEDSINCE modifier is not specified. 479 If the operation is successful for a message, the server MUST update 480 the mod-sequence attribute of the message. The server is REQUIRED to 481 include the mod-sequence value whenever it decides to send the 482 unsolicited FETCH response to all CONDSTORE-aware clients that have opened 483 the mailbox containing the message. 485 3.3 FETCH and UID FETCH Commands 487 3.3.1 FETCH modifiers 489 Arguments: sequence set 490 message data item names or macro 492 Responses: untagged responses: FETCH 494 Result: OK - fetch completed 495 NO - fetch error: can't fetch that data 496 BAD - command unknown or arguments invalid 498 This document extends the syntax of the FETCH and UID FETCH 499 commands (see section 6.4.5 of [IMAP4]) to include an optional FETCH 500 modifier. The document defines the following modifier: 502 CHANGEDSINCE 504 CHANGEDSINCE FETCH modifier allows to further subset the list of 505 messages described by sequence set. The information described by 506 message data items is only returned for messages that have 507 mod-sequence bigger than . 509 When CHANGEDSINCE FETCH modifier is specified, it implicitly adds 510 MODSEQ FETCH message data item (section 3.3.2). 512 Example: 514 C: s100 UID FETCH 1:* (FLAGS) (CHANGEDSINCE 12345) 515 S: * 1 FETCH (UID 4 MODSEQ (65402) FLAGS (\Seen)) 516 S: * 2 FETCH (UID 6 MODSEQ (75403) FLAGS (\Deleted)) 517 S: * 4 FETCH (UID 8 MODSEQ (29738) FLAGS ($NoJunk $AutoJunk $MDNSent)) 518 S: s100 OK FETCH completed 520 3.3.2 MODSEQ message data item in FETCH Command 522 This extension adds a MODSEQ message data item to the FETCH command. 523 The MODSEQ message data item allows clients to retrieve mod-sequence 524 values for a range of messages in the currently selected mailbox. 526 Once the client specified the MODSEQ message data item in a FETCH request, 527 the server MUST include the MODSEQ fetch response data items in all 528 subsequent unsolicited FETCH responses. 530 Syntax: MODSEQ 532 The MODSEQ message data item causes the server to return MODSEQ fetch 533 response data items. 535 Syntax: MODSEQ ( ) 537 MODSEQ response data items contain per-message mod-sequences. 539 The MODSEQ response data item is returned if the client issued FETCH with 540 MODSEQ message data item. It also allows the server to notify the client 541 about mod-sequence changes caused by conditional STOREs (section 3.2) and/or 542 changes caused by external sources. 544 Example: 546 C: a FETCH 1:3 (MODSEQ) 547 S: * 1 FETCH (MODSEQ (20000624140003)) 548 S: * 2 FETCH (MODSEQ (20000624140007)) 549 S: * 3 FETCH (MODSEQ (20000624140005)) 550 S: a OK Fetch complete 552 In this example the client requests per message mod-sequences for a 553 set of messages. 555 When a flag for a message is modified in a different session, the server 556 sends an unsolicited FETCH response containing the mod-sequence for the 557 message. 559 Example: 561 (Session 1, authenticated as a user "alex"). The user adds a shared 562 flag \Deleted: 564 C: A142 SELECT INBOX 565 ... 566 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 567 S: * OK [PERMANENTFLAGS (\Answered \Deleted \Seen \*)] Limited 568 ... 570 C: A160 STORE 7 +FLAGS.SILENT (\Deleted) 571 S: * 7 FETCH (MODSEQ (200012121231000)) 572 S: A160 OK Store completed 574 (Session 2, also authenticated as the user "alex"). Any changes to flags 575 are always reported to all sessions authenticated as the same user as in 576 the session 1. 578 C: C180 NOOP 579 S: * 7 FETCH (FLAGS (\Deleted \Answered) MODSEQ (200012121231000)) 580 S: C180 OK Noop completed 582 (Session 3, authenticated as a user "andrew"). As \Deleted is a shared 583 flag, changes in the session 1 are also reported in the session 3: 585 C: D210 NOOP 586 S: * 7 FETCH (FLAGS (\Deleted \Answered) MODSEQ (200012121231000)) 587 S: D210 OK Noop completed 589 The user modifies a private flag \Seen in the session 1 ... 591 C: A240 STORE 7 +FLAGS.SILENT (\Seen) 592 S: * 7 FETCH (MODSEQ (200012121231777)) 593 S: A240 OK Store completed 595 ... which is only reported in the session 2 ... 597 C: C270 NOOP 598 S: * 7 FETCH (FLAGS (\Deleted \Answered \Seen) MODSEQ (200012121231777)) 599 S: C270 OK Noop completed 601 ... but not in the session 3. 603 C: D300 NOOP 604 S: D300 OK Noop completed 606 And finally the user removes flags \Answered (shared) and \Seen (private) 607 in the session 1. 609 C: A330 STORE 7 -FLAGS.SILENT (\Answered \Seen) 610 S: * 7 FETCH (MODSEQ (200012121245160)) 611 S: A330 OK Store completed 613 Both changes are reported in the session 2 ... 615 C: C360 NOOP 616 S: * 7 FETCH (FLAGS (\Deleted) MODSEQ (200012121245160)) 617 S: C360 OK Noop completed 619 ... and only changes to shared flags are reported in session 3. 621 C: D390 NOOP 622 S: * 7 FETCH (FLAGS (\Deleted) MODSEQ (200012121245160)) 623 S: D390 OK Noop completed 625 3.4. MODSEQ search criterion in SEARCH 627 The MODSEQ criterion for the SEARCH command allows a client to search 628 for the metadata items that were modified since a specified moment. 630 Syntax: MODSEQ [ ] 632 Messages that have modification values which are equal to or 633 greater than . This allows a client, 634 for example, to find out which messages contain metadata items 635 that have changed since the last time it updated its disconnected 636 cache. The client may also specify (name of metadata 637 item) and (type of metadata item) before 638 . can be one of "shared", 639 "priv" (private) or "all". The latter means that the server should use 640 the biggest value among "priv" and "shared" mod-sequences for the 641 metadata item. If the server doesn't store internally separate 642 mod-sequences for different metadata items, it MUST ignore 643 and . Otherwise the server should 644 use them to narrow down the search. 646 For a flag the corresponding has a form 647 "/flags/" as defined in [ANNOTATE]. Note, that 648 the leading "\" character that denotes a system flag has to be 649 escaped as per Section 4.3 of [IMAP4], as the uses 650 syntax for quoted strings. 652 If client specifies a MODSEQ criterion in a SEARCH command and 653 the server returns a non-empty SEARCH result, the server MUST also 654 append (to the end of the untagged SEARCH response) the highest 655 mod-sequence for all messages being returned. See also section 3.6. 657 Example: 658 C: a SEARCH MODSEQ "/flags/\\draft" all 20010320162338 659 ANNOTATION "/comment" "value" "IMAP4" 660 S: * SEARCH 2 5 6 7 11 12 18 19 20 23 (MODSEQ 20010917162500) 661 S: a OK Search complete 663 In the above example, the message numbers of any messages 664 containing the string "IMAP4" in the "value" attribute of the 665 "/comment" entry and having a mod-sequence equal to or 666 greater than 20010320162338 for the "\Draft" flag are returned in 667 the search results. 669 Example: 670 C: a SEARCH OR NOT MODSEQ 20010320162338 LARGER 50000 671 S: * SEARCH 672 S: a OK Search complete, nothing found 674 3.5. MODSEQ Sort Criterion 676 If a server implementing CONDSTORE also implements the SORT 677 extension as defined by [SORT], it SHOULD implement the 678 SORT=MODSEQ extension that allows for sorting on per-message 679 mod-sequence. SORT=MODSEQ extension adds MODSEQ sort criterion 680 that allows to sort the matching messages based on their mod-sequence. 682 If client specifies a MODSEQ search (as per section 3.4) or sort 683 criterion in the SORT command and the server returns a non-empty 684 SORT result, the server MUST also append (to the end of the untagged 685 SORT response) the highest mod-sequence for all messages being returned. 686 See also section 3.6. 688 Example (MODSEQ search criterion): 690 C: A282 SORT (SUBJECT MODSEQ) UTF-8 SINCE 1-Feb-2001 691 S: * SORT 2 81 83 84 82 882 (MODSEQ 117) 692 S: A282 OK SORT completed 694 Example (MODSEQ sort criterion): 696 C: A283 SORT (SUBJECT REVERSE DATE) UTF-8 MODSEQ 21 697 S: * SORT 6 3 4 5 2 (MODSEQ 125) 698 S: A283 OK SORT completed 700 Example (MODSEQ search criterion and MODSEQ SORT criterion, 701 but no messages matching the search criteria): 703 C: A284 SORT (MODSEQ) KOI8-R OR NOT MODSEQ 20010320162338 704 SUBJECT "Privet" 705 S: * SORT 706 S: A284 OK Sort complete, nothing found 708 3.6. Modified SEARCH and SORT untagged responses 710 Data: zero or more numbers 711 mod-sequence value (omitted if no match) 713 This document extends syntax of the untagged SEARCH and SORT responses 714 to include mod-sequence for all messages being returned. 716 If a client specifies a MODSEQ criterion in a SEARCH (or UID SEARCH) 717 command and the server returns a non-empty SEARCH result, the server 718 MUST also append (to the end of the untagged SEARCH response) the 719 highest mod-sequence for all messages being returned. See section 720 3.4 for examples. 722 If client specifies a MODSEQ search or sort criterion in a SORT 723 (or UID SORT) command and the server returns a non-empty SORT result, 724 the server MUST also append (to the end of the untagged SORT response) 725 the highest mod-sequence for all messages being returned. See section 726 3.5 for examples. 728 3.7. HIGHESTMODSEQ status data items 730 This document defines a new status data item: 732 HIGHESTMODSEQ 733 The highest mod-sequence value all messages 734 in the mailbox. This is the same value that is returned by the server 735 in the HIGHESTMODSEQ response code in OK untagged response 736 (see section 3.1.1). 738 Example: C: A042 STATUS blurdybloop (UIDNEXT MESSAGES HIGHESTMODSEQ) 739 S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292 740 HIGHESTMODSEQ 200201011231777) 741 S: A042 OK STATUS completed 743 3.8. CONDSTORE parameter to SELECT and EXAMINE 745 The CONDSTORE extension defines a single optional select parameter 746 "CONDSTORE", which tells the server that it MUST include the MODSEQ 747 fetch response data items in all subsequent unsolicited FETCH responses. 749 The CONDSTORE parameter to SELECT/EXAMINE helps to avoid a race condition 750 that might arise when a metadata item(s) is(are) modified in another session 751 after the server has sent the HIGHESTMODSEQ response code and before the 752 client was able to issue a CONDSTORE enabling command. 754 Example: C: A142 SELECT INBOX (CONDSTORE) 755 S: * 172 EXISTS 756 S: * 1 RECENT 757 S: * OK [UNSEEN 12] Message 12 is first unseen 758 S: * OK [UIDVALIDITY 3857529045] UIDs valid 759 S: * OK [UIDNEXT 4392] Predicted next UID 760 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 761 S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited 762 S: * OK [HIGHESTMODSEQ 20010715194045007] 763 S: A142 OK [READ-WRITE] SELECT completed, CONDSTORE is now enabled 765 4. Formal Syntax 767 The following syntax specification uses the Augmented Backus-Naur 768 Form (ABNF) notation as specified in [ABNF]. 770 Non-terminals referenced but not defined below are as defined by 771 [IMAP4] or [ANNOTATE]. 773 Except as noted otherwise, all alphabetic characters are case- 774 insensitive. The use of upper or lower case characters to define token 775 strings is for editorial clarity only. Implementations MUST accept 776 these strings in a case-insensitive fashion. 778 capability =/ "CONDSTORE" / "SORT=MODSEQ" 780 status = "STATUS" SP mailbox SP 781 "(" status-att-req *(SP status-att-req) ")" 782 ;; redefine STATUS command syntax defined in [IMAP4] 784 status-att-req = status-att / "HIGHESTMODSEQ" 786 status-rsp-info = status-att SP number / 787 "HIGHESTMODSEQ" SP mod-sequence-value 789 store = "STORE" SP sequence-set store-modifiers SP store-att-flags 791 store-modifiers = [ SP "(" store-modifier *(SP store-modifier) ")" ] 793 store-modifier = "UNCHANGEDSINCE" SP mod-sequence-valzer 794 ;; Only a single "UNCHANGEDSINCE" may be specified 795 ;; in a STORE operation 797 fetch = "FETCH" SP sequence-set SP ("ALL" / "FULL" / 798 "FAST" / fetch-att / 799 "(" fetch-att *(SP fetch-att) ")") [SP fetch-modifiers] 800 ;; modifies the original IMAP4 fetch command to 801 ;; accept optional modifiers 803 fetch-modifiers = "(" fetch-modifier *(SP fetch-modifier) ")" 805 fetch-modifier = fetch-modifier-name / fetch-modifier-name SP astring / 806 fetch-modifier-name SP "(" fetch-modif-params ")" 807 ;; modifiers to FETCH may contain a modifier name 808 ;; followed by zero or more atoms or strings - multiple 809 ;; items are always parenthesised, nesting is allowed 811 fetch-modif-params = astring *(SP astring) / 812 "(" fetch-modif-params *(SP fetch-modif-params) ")" 814 fetch-modifier-name = atom 816 chgsince-fetch-mod = "CHANGEDSINCE" SP mod-sequence-value 817 ;; CHANGEDSINCE FETCH modifier conforms to 818 ;; the fetch-modifier syntax 820 fetch-att =/ fetch-mod-sequence 821 ;; modifies original IMAP4 fetch-att 823 fetch-mod-sequence = "MODSEQ" 825 fetch-mod-resp = "MODSEQ" SP "(" permsg-modsequence ")" 827 search-key =/ search-modsequence 828 ;; modifies original IMAP4 search-key 829 ;; 830 ;; This change applies to all command referencing this 831 ;; non-terminal, in particular SEARCH and SORT. 833 search-modsequence = "MODSEQ" [search-modseq-ext] SP mod-sequence-valzer 835 search-modseq-ext = SP entry-name SP entry-type-req 837 resp-text-code =/ "HIGHESTMODSEQ" SP mod-sequence-value / 838 "NOMODSEQ" / 839 "MODIFIED" SP set 841 entry-name = entry-flag-name / entry-annotate-name 842 ;; The server MUST understand entry-flag-name. 843 ;; If the server also supports [ANNOTATE], it MUST 844 ;; also support entry-annotate-name. 846 entry-flag-name = DQUOTE "/flags/" attr-flag DQUOTE 847 ;; each system or user defined flag 848 ;; is mapped to "/flags/". 849 ;; 850 ;; follows the escape rules used 851 ;; by "quoted" string as described in Section 852 ;; 4.3 of [IMAP4], e.g. for the flag \Seen 853 ;; the corresponding is 854 ;; "/flags/\\seen", and for the flag 855 ;; $MDNSent, the corresponding 856 ;; is "/flags/$mdnsent". 858 entry-annotate-name = entry 859 ;; is defined in [ANNOTATE] 861 entry-type-resp = "priv" / "shared" 862 ;; metadata item type 864 entry-type-req = entry-type-resp / "all" 865 ;; perform SEARCH operation on private 866 ;; metadata item, shared metadata item or both 868 permsg-modsequence = mod-sequence-value 869 ;; per message mod-sequence 871 mod-sequence-value = 1*DIGIT 872 ;; Positive unsigned 64-bit integer (mod-sequence) 873 ;; (1 <= n < 18,446,744,073,709,551,615) 875 mod-sequence-valzer = "0" / mod-sequence-value 877 search-sort-mod-seq = "(" "MODSEQ" SP mod-sequence-value ")" 879 sort-key =/ "MODSEQ" 881 condstore-param = "CONDSTORE" 882 ;; defines the select parameter used with 883 ;; CONDSTORE extension 885 mailbox-data =/ "STATUS" SP mailbox SP "(" 886 [status-rsp-info *(SP status-rsp-info)] ")" / 887 "SEARCH" [1*(SP nz-number) SP search-sort-mod-seq] / 888 "SORT" [1*(SP nz-number) SP search-sort-mod-seq] 890 attr-flag = "\\Answered" / "\\Flagged" / "\\Deleted" / 891 "\\Seen" / "\\Draft" / attr-flag-keyword / 892 attr-flag-extension 893 ;; Does not include "\\Recent" 895 attr-flag-extension = "\\" atom 896 ;; Future expansion. Client implementations 897 ;; MUST accept flag-extension flags. Server 898 ;; implementations MUST NOT generate 899 ;; flag-extension flags except as defined by 900 ;; future standard or standards-track 901 ;; revisions of [IMAP4]. 903 attr-flag-keyword = atom 905 5. Security Considerations 907 It is believed that the Conditional STORE extension doesn't raise 908 any new security concerns that are not already discussed in [IMAP4]. 909 However, the availability of this extension may make it possible 910 for IMAP4 to be used in critical applications it could not be used 911 for previously, making correct IMAP server implementation and 912 operation in even more important. 914 6. References 916 6.1. Normative References 918 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 919 Requirement Levels", RFC 2119, Harvard University, March 1997. 921 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: 922 ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd, 923 November 1997. 925 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 926 4rev1", RFC 3501, University of Washington, March 2003. 928 [ANNOTATE] Gellens, R., Daboo, C., "IMAP ANNOTATE Extension", 929 work in progress. 930 932 [SORT] Crispin, M., Murchison, K., "Internet Message Access Protocol -- 933 SORT AND THREAD EXTENSIONS", work in progress. 934 936 6.2. Informative References 938 [ACAP] Newman, Myers, "ACAP -- Application Configuration Access 939 Protocol", RFC 2244, Innosoft, Netscape, November 1997. 940 942 [ACL] Myers, "IMAP4 ACL extension", RFC 2086, Carnegie Mellon, 943 January 1997. 944 946 [NTP] Mills, D, "Network Time Protocol (Version 3) Specification, 947 Implementation and Analysis", RFC 1305, March 1992. 948 950 [RFC-2180] Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", 951 RFC 2180, July 1997. 952 954 7. IANA Considerations 956 IMAP4 capabilities are registered by publishing a standards track or 957 IESG approved experimental RFC. The registry is currently located 958 at: 960 http://www.iana.org/assignments/imap4-capabilities 962 This document defines the CONDSTORE and SORT=MODSEQ IMAP capabilities. 963 IANA should add them to the registry accordingly. 965 8. Acknowledgments 967 Some text was borrowed from "IMAP ANNOTATE Extension" by Randall Gellens 968 and Cyrus Daboo, and "ACAP -- Application Configuration Access Protocol" 969 by Chris Newman and John Myers. 971 Many thanks to Randall Gellens for his comments on how CONDSTORE should 972 interact with ANNOTATE extension and for thorough review of the document. 974 The authors also acknowledge the feedback provided by Cyrus Daboo, Larry 975 Greenfield, Chris Newman, Harrie Hazewinkel, Arnt Gulbrandsen, Timo 976 Sirainen, Mark Crispin and Ned Freed. 978 9. Author's Addresses 980 Alexey Melnikov 981 mailto: Alexey.Melnikov@isode.com 983 Isode Limited 984 5 Castle Business Village, 36 Station Road, 985 Hampton, Middlesex, TW12 2BX, United Kingdom 987 Steve Hole 988 mailto: Steve.Hole@messagingdirect.com 990 ACI WorldWide/MessagingDirect 991 #900, 10117 Jasper Avenue, 992 Edmonton, Alberta, T5J 1W8, CANADA 994 10. Intellectual Property Rights 996 The IETF takes no position regarding the validity or scope of any 997 intellectual property or other rights that might be claimed to pertain 998 to the implementation or use of the technology described in this 999 document or the extent to which any license under such rights might or 1000 might not be available; neither does it represent that it has made any 1001 effort to identify any such rights. Information on the IETF's 1002 procedures with respect to rights in standards-track and 1003 standards-related documentation can be found in BCP-11. Copies of 1004 claims of rights made available for publication and any assurances of 1005 licenses to be made available, or the result of an attempt made to 1006 obtain a general license or permission for the use of such proprietary 1007 rights by implementors or users of this specification can be obtained 1008 from the IETF Secretariat. 1010 The IETF invites any interested party to bring to its attention any 1011 copyrights, patents or patent applications, or other proprietary 1012 rights which may cover technology that may be required to practice 1013 this standard. Please address the information to the IETF Executive 1014 Director. 1016 11. Full Copyright Statement 1018 Copyright (C) The Internet Society 2001-2003. All Rights Reserved. 1020 This document and translations of it may be copied and furnished to 1021 others, and derivative works that comment on or otherwise explain it 1022 or assist in its implementation may be prepared, copied, published 1023 and distributed, in whole or in part, without restriction of any 1024 kind, provided that the above copyright notice and this paragraph 1025 are included on all such copies and derivative works. However, this 1026 document itself may not be modified in any way, such as by removing 1027 the copyright notice or references to the Internet Society or other 1028 Internet organizations, except as needed for the purpose of 1029 developing Internet standards in which case the procedures for 1030 copyrights defined in the Internet Standards process must be 1031 followed, or as required to translate it into languages other than 1032 English. 1034 The limited permissions granted above are perpetual and will not be 1035 revoked by the Internet Society or its successors or assigns. 1037 This document and the information contained herein is provided on an 1038 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1039 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1040 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1041 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1042 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1044 Acknowledgement 1046 Funding for the RFC Editor function is currently provided by the 1047 Internet Society. 1049 Appendix A. Open Issues and Change History 1051 Note that this appendix will be removed before publication. 1053 0.1. Change History 1055 Changes from draft-ietf-imapext-condstore-03 1056 1. ABNF corrections from Ned Freed. 1057 2. Minor spelling/wording corrections from Ned Freed. 1059 Changes from draft-ietf-imapext-condstore-02 1060 1. Added FETCH modifiers. 1061 2. Added example for using ANNOTATE with UNCHANGEDSINCE STORE 1062 modifier. 1063 3. Added a new requirement to send HIGHESTMODSEQ response code 1064 when implicit enabling is used. 1065 4. Fixed syntax in an example in section 3.2. 1067 Changes from draft-ietf-imapext-condstore-01 1068 1. Fixed missing \\ in one example. 1069 2. Added explanatory comment that search-key modifications apply at 1070 least to SEARCH and SORT command. 1071 3. Don't require from a conditional store operation to be atomic accross 1072 message set, updated text and examples. 1073 4. Added SORT=MODSEQ extension and reworked text in the Introduction section. 1074 5. Added Conditional STORE example based on suggestions from RFC 2180. 1075 6. Removed the paragraph about DOS attack from the Security considerations 1076 section, as it doesn't apply anymore. 1077 7. Updated entry-name ABNF. 1078 8. Added an optional CONDSTORE parameter to SELECT/EXAMINE. 1080 Changes from draft-ietf-imapext-condstore-00 1081 1. Dropped "/message" prefix in entry names as per decision in San Francisco. 1082 2. Fixed ABNF for SEARCH and SORT untagged responses. 1083 3. Changed "private" to "priv" to be consistent with ANNOTATE. 1084 4. MODIFIED response code is now returned in OK response, not NO. 1085 5. Added NOMODSEQ response code. 1087 Changes from draft-melnikov-imap-condstore-09: 1088 1. Some text clarifications based on suggestions by Harrie Hazewinkel 1089 2. Added paragraph about mailbox locking and DOS when conditional STORE 1090 operation is performed on a large mailbox. 1091 3. Fixed syntax of to match the ANNOTATE extension. 1092 4. Added sentence that a system flag MUST always be considered existent, 1093 when UNCHANGEDSINCE 0 is used. Is this a good idea? 1094 5. Clarified client behavior upon receipt of MODIFIED response code. 1095 6. Updated ABNF to clarify where 0 is allowed as mod-sequence and where 1096 it is not. 1097 7. Got rid of MODSEQ response code and return this data in the untagged 1098 SEARCH/SORT responses. 1099 8. Updated RFC number for the IMAP4rev1 document. 1101 Changes from -08 to -09: 1102 1. Added an extended example about reporting regular (non-conditional) flag 1103 changes to other sessions. 1104 2. Simplified FETCH MODSEQ syntax by removing per-metadata requests and 1105 responses. 1107 Changes from -07 to -08: 1108 1. Added note saying the change to UIDVALIDITY also invalidates HIGHESTMODSEQ. 1109 2. Fixed several bugs in ABNF for STATUS and STORE commands. 1111 Changes from -06 to -07: 1112 1. Added clarification that when a server does command reordering, the second 1113 completed operation gets the higher mod sequence. 1114 2. Renamed annotation type specifier "both" to "all" as per suggestion 1115 from Minneapolis meeting. 1116 3. Removed PERFLAGMODSEQ capability, as it doesn't buy anything: a client 1117 has to work with both types of servers (i.e. servers that support per 1118 message per flag modseqs and servers that support only per message 1119 modseqs) anyway. 1120 4. Per flag mod-sequences are optional for a server to return. Updated syntax. 1121 5. Allow MODSEQ response code only as a result of SEARCH/SORT as suggested 1122 by John Myers. MODSEQ response code is not allowed after FETCH or STORE. 1124 Changes from -05 to -06: 1125 1. Replaced "/message/flags/system" with "/message/flags" to 1126 match ANNOTATE draft. 1127 2. Extended FETCH/SEARCH/SORT syntax to allow for specifying 1128 whether an operation should be performed on a shared or a private 1129 annotation (or both). 1130 3. Corrected some examples. 1132 Changes from -04 to -05: 1133 1. Added support for SORT extension. 1134 2. Multiple language/spelling fixes by Randall Gellens. 1136 Changes from -03 to -04: 1137 1. Added text saying that MODSEQ fetch data items cause server 1138 to include MODSEQ data response in all subsuquent unsolicited FETCH 1139 responses. 1140 2. Added "authors address" section. 1142 Changes from -02 to -03: 1143 1. Changed MODTIME untagged response to MODTIME response code. 1144 2. Added MODTIME response code to the tagged OK response for SEARCH. 1145 Updated examples accordingly. 1146 3. Changed rule for sending untagged FETCH response as a result of 1147 STORE when .SILENT prefix is used. If .SILENT prefix is used, 1148 server doesn't have to send untagged FETCH response, because 1149 MODTIME response code already contains modtime. 1150 4. Renamed MODTIME to MODSEQ to make sure there is no confusion 1151 between mod-sequence and ACAP modtime. 1152 5. Minor ABNF changes. 1153 6. Minor language corrections. 1155 Changes from -01 to -02: 1156 1. Added MODTIME data item to STATUS command. 1157 2. Added OK untagged response to SELECT/EXAMINE. 1158 3. Clarified that MODIFIED response code contains list of UIDs for 1159 conditional UID STORE and message set for STORE. 1160 4. Added per-message modtime. 1161 5. Added PERFLAGMODTIME capability. 1162 6. Fixed several bugs in examples. 1163 7. Added more comments to ABNF. 1165 Changes from -00 to -01: 1166 1. Refreshed the list of Open Issues. 1167 2. Changed "attr-name" to "entry-name", because modtime applies to 1168 entry, not attribute. 1169 3. Added MODTIME untagged response. 1170 4. Cleaned up ABNF. 1171 5. Added "Acknowledgments" section. 1172 6. Fixed some spelling mistakes.