idnits 2.17.1 draft-melnikov-imap-condstore-09.txt: ** The Abstract section seems to be numbered 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. == 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 802 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 130 instances of too long lines in the document, the longest one being 13 characters in excess of 72. ** There are 3 instances of lines with control characters in the document. 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 (December 2002) is 7775 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 273, but not defined == Missing Reference: 'UIDVALIDITY 3857529045' is mentioned on line 274, but not defined == Missing Reference: 'UIDNEXT 4392' is mentioned on line 275, but not defined == Missing Reference: 'HIGHESTMODSEQ 20010715194045007' is mentioned on line 278, but not defined == Missing Reference: 'IMAP' is mentioned on line 295, but not defined == Missing Reference: 'MODIFIED 7' is mentioned on line 310, but not defined -- Looks like a reference, but probably isn't: '9' on line 310 == Missing Reference: 'MODIFIED 12' is mentioned on line 323, but not defined == Unused Reference: 'ACAP' is defined on line 706, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2060 (ref. 'IMAP4') (Obsoleted by RFC 3501) -- 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: 8 errors (**), 0 flaws (~~), 10 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-melnikov-imap-condstore-09.txt S. Hole 3 Expires: June 2003 ACI WorldWide/MessagingDirect 4 December 2002 6 IMAP Extension for Conditional STORE operation 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. Internet-Drafts are 12 working documents of the Internet Engineering Task Force (IETF), its 13 areas, and its working groups. Note that other groups may also 14 distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other documents 18 at any time. It is inappropriate to use Internet-Drafts as 19 reference material or to cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- 23 Draft Shadow Directories can be accessed at 24 http://www.ietf.org/shadow.html. 26 Copyright Notice 28 Copyright (C) The Internet Society 2001-2002. All Rights Reserved. 30 0.1. Open issues 32 1). Should conditional STORE be atomic accross message set (i.e. either 33 all messages in message set weren't changed since and conditional 34 STORE succeeds or operation fails for all messages)? 35 This can be difficult to implement for some servers. 37 0.2. Change History 39 Changes from -08 to -09: 40 1. Added an extended example about reporting regular (non-conditional) flag 41 changes to other sessions. 42 2. Simplified FETCH MODSEQ syntax by removing per-metadata requests and 43 responses. 45 Changes from -07 to -08: 46 1. Added note saying the change to UIDVALIDITY also invalidates HIGHESTMODSEQ. 47 2. Fixed several bugs in ABNF for STATUS and STORE commands. 49 Changes from -06 to -07: 50 1. Added clarification that when a server does command reordering, the second 51 completed operation gets the higher mod sequence. 52 2. Renamed annotation type specifier "both" to "all" as per suggestion 53 from Minneapolis meeting. 54 3. Removed PERFLAGMODSEQ capability, as it doesn't buy anything: a client 55 has to work with both types of servers (i.e. servers that support per 56 message per flag modseqs and servers that support only per message 57 modseqs) anyway. 58 4. Per flag modsequences are optional for a server to return. Updated syntax. 59 5. Allow MODSEQ response code only as a result of SEARCH/SORT as suggested 60 by John Myers. MODSEQ response code is not allowed after FETCH or STORE. 62 Changes from -05 to -06: 63 1. Replaced "/message/flags/system" with "/message/flags" to 64 match ANNOTATE draft. 65 2. Extended FETCH/SEARCH/SORT syntax to allow for specifying 66 whether an operation should be performed on a shared or a private 67 annotation (or both). 68 3. Corrected some examples. 70 Changes from -04 to -05: 71 1. Added support for SORT extension. 72 2. Multiple language/spelling fixes by Randall Gellens. 74 Changes from -03 to -04: 75 1. Added text saying that MODSEQ fetch data items cause server 76 to include MODSEQ data response in all subsuquent unsolicited FETCH 77 responses. 78 2. Added "authors address" section. 80 Changes from -02 to -03: 81 1. Changed MODTIME untagged response to MODTIME response code. 82 2. Added MODTIME response code to the tagged OK response for SEARCH. 83 Updated examples accordingly. 84 3. Changed rule for sending untagged FETCH response as a result of 85 STORE when .SILENT prefix is used. If .SILENT prefix is used, 86 server doesn't have to send untagged FETCH response, because 87 MODTIME response code already contains modtime. 88 4. Renamed MODTIME to MODSEQ to make sure there is no confusion 89 between mod-sequence and ACAP modtime. 90 5. Minor ABNF changes. 91 6. Minor language corrections. 93 Changes from -01 to -02: 94 1. Added MODTIME data item to STATUS command. 95 2. Added OK untagged response to SELECT/EXAMINE. 96 3. Clarified that MODIFIED response code contains list of UIDs for 97 conditional UID STORE and message set for STORE. 98 4. Added per-message modtime. 99 5. Added PERFLAGMODTIME capability. 100 6. Fixed several bugs in examples. 101 7. Added more comments to ABNF. 103 Changes from -00 to -01: 104 1. Refreshed the list of Open Issues. 105 2. Changed "attr-name" to "entry-name", because modtime applies to 106 entry, not attribute. 107 3. Added MODTIME untagged response. 108 4. Cleaned up ABNF. 109 5. Added "Acknowledgments" section. 110 6. Fixed some spelling mistakes. 112 Table of Contents 114 1 Abstract .................................................. X 115 2 Conventions Used in This Document ......................... X 116 3 Introduction and Overview ................................. X 117 4 IMAP Protocol Changes ..................................... X 118 4.1 New OK untagged responses for SELECT and EXAMINE ......... X 119 4.1.1 HIGHESTMODSEQ response code ............................ X 120 4.2 STORE and UID STORE Commands ............................. X 121 4.3 MODSEQ message data item in FETCH Command ................ X 122 4.4 MODSEQ search criterion in SEARCH ........................ X 123 4.5 MODSEQ Sort Criterion .................................... X 124 4.6 MODSEQ Response code for successful SEARCH and SORT ...... X 125 4.7 HIGHESTMODSEQ status data items .......................... X 126 5 Formal Syntax ............................................. X 127 6 Security Considerations ................................... X 128 7 References ................................................ X 129 7.1 Normative References ..................................... X 130 7.2 Informative References ................................... X 131 8 Acknowledgments ........................................... X 132 9 Author's Addresses ........................................ X 133 10 Full Copyright Statement ................................. X 135 1. Abstract 137 Often, multiple IMAP clients need to coordinate changes to a common 138 IMAP mailbox. Examples include different clients for the same user, 139 and multiple users accessing shared mailboxes. These clients 140 need a mechanism to synchronize state changes for messages within the 141 mailbox. They must be able to guarantee that only one client can change 142 message state (e.g., message flags or annotations) at any time. An 143 example of such an application is use of an IMAP mailbox as a message 144 queue with multiple dequeueing clients. 146 The Conditional Store facility provides a protected update mechanism for 147 message state information that can detect and resolve conflicts between 148 multiple writers. 150 2. Conventions Used in This Document 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 156 In examples, lines beginning with "S:" are sent by the IMAP server, and 157 lines beginning with "C:" are sent by the client. Line breaks may appear 158 in example commands solely for editorial clarity; when present in 159 the actual message they are represented by "CRLF". 161 Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4]. 163 The term "metadata" or "metadata item" is used throughout this document. 164 It refers to any system or user defined keyword or an annotation 165 [ANNOTATE]. 167 Some IMAP mailboxes are private, accessible only to the owning user. 168 Other mailboxes are not, either because the owner has set an ACL 169 [ACL] which permits access by other users, or because it is a 170 shared mailbox. Let's call a metadata item "shared" for the mailbox 171 if any changes to the metadata items are persistent and visible to all 172 other users accessing the mailbox. Otherwise the metadata item is called 173 "private". Note, that private metadata items are still visible to all 174 sessions accessing the mailbox as the same user. Also note, that different 175 mailboxes may have different metadata items as shared. 177 3. Introduction and Overview 179 The Conditional STORE extension is present in any IMAP4 implementation 180 which returns "CONDSTORE" as one of the supported capabilities in the 181 CAPABILITY command response. 183 Every IMAP message has an associated positive unsigned 64-bit value called a 184 modification sequence (mod-sequence). This is an opaque value updated by 185 the server whenever a metadata item is modified. The value is intended to 186 be used only for comparisons within a server. However, the server MUST 187 guarantee that each STORE command performed on the same mailbox, including 188 simultaneous stores to different metadata items from different connections, 189 will get a different mod-sequence value. Also, for any two successfull 190 STORE operations performed in the same session on the same mailbox, 191 the mod-sequence of the second completed operation MUST be greater than 192 the mod-sequence of the first completed. Note that the latter rule disallows 193 the use of the system clock as a mod-sequence, because if system time changes 194 (e.g., a NTP [NTP] client adjusting the time), the next generated value might 195 be less than the previous one. 197 Mod-sequences allow a client that supports the CONDSTORE extension to 198 determine if a message metadata has changed since some known 199 moment. Whenever the state of a flag changes (i.e., the flag is added and 200 before it wasn't set, or the flag is removed and before it was set) the 201 value of the modification sequence for the message MUST be updated. 202 Adding the flag when it is already present or removing when it is not 203 present SHOULD NOT change the mod-sequence. 205 When a message is appended to a mailbox (via the IMAP APPEND command, 206 COPY to the mailbox or using an external mechanism) the server 207 generates a new modification sequence that is higher than the highest 208 modification sequence of all messages in the mailbox and assigns it to 209 the appended message. 211 When an annotation is added, modified or removed the corresponding message 212 mod-sequence MUST be updated. 214 The server MAY store separate (per message) modification sequence values for 215 different metadata items. If the server does so, per message modsequence is 216 the highest modsequence of all metadata items for the specified message. 218 This extension makes the following changes to the IMAP4 protocol: 220 a) extends the syntax of the STORE command to allow STORE 221 modifiers 223 b) adds the MODIFIED response code which should be used with 224 a NO response to the STORE command 226 c) adds a new MODSEQ message data item for use with the FETCH command 228 d) adds a new MODSEQ search criterion 230 e) adds a new MODSEQ response code 232 f) adds a new OK untagged responses for the SELECT and EXAMINE commands 234 g) adds the HIGHESTMODSEQ status data item to the STATUS command 236 h) adds a new MODSEQ sort criterion 238 The rest of this document describes the protocol changes more rigorously. 240 4. IMAP Protocol Changes 242 4.1. New OK untagged responses for SELECT and EXAMINE 244 4.1.1. HIGHESTMODSEQ response code 246 This document adds a new response code that is returned in the OK 247 untagged response for the SELECT and EXAMINE commands. A server 248 supporting the CONDSTORE extension MUST send the OK untagged 249 response including HIGHESTMODSEQ response code with every successful 250 SELECT or EXAMINE command: 252 OK [HIGHESTMODSEQ ] 254 Where is the highest mod-sequence value of all 255 messages in the mailbox. When the server changes UIDVALIDITY for a 256 mailbox, it doesn't have to keep the same HIGHESTMODSEQ for the 257 mailbox. 259 A disconnected client can use the value of HIGHESTMODSEQ to check if 260 it has to refetch flags and/or annotations from the server. If the 261 UIDVALIDITY value has changed for the selected mailbox, the client 262 MUST delete the cached value of HIGHESTMODSEQ. If UIDVALIDITY for 263 the mailbox is the same and if the HIGHESTMODSEQ value stored in 264 the client's cache is less than the value returned by the server, 265 then some metadata items on the server have changed since the last 266 synchronization, and the client needs to update its cache. The client 267 MAY use SEARCH MODSEQ as described in section 4.4 to find out exactly 268 which metadata items have changed. 270 Example: C: A142 SELECT INBOX 271 S: * 172 EXISTS 272 S: * 1 RECENT 273 S: * OK [UNSEEN 12] Message 12 is first unseen 274 S: * OK [UIDVALIDITY 3857529045] UIDs valid 275 S: * OK [UIDNEXT 4392] Predicted next UID 276 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 277 S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited 278 S: * OK [HIGHESTMODSEQ 20010715194045007] 279 S: A142 OK [READ-WRITE] SELECT completed 281 4.2. STORE and UID STORE Commands 283 Arguments: message set 284 OPTIONAL store modifiers 285 message data item name 286 value for message data item 288 Responses: untagged responses: FETCH 290 Result: OK - store completed 291 NO - store error: can't store that data 292 BAD - command unknown or arguments invalid 294 This document extends the syntax of the STORE and UID STORE 295 commands (see section 6.4.6 of [IMAP]) to include an optional STORE 296 modifier. The document defines the following modifier: 298 UNCHANGEDSINCE 299 If the mod-sequence of any metadata item specified in the STORE 300 operation for any message in the message set is greater than the 301 specified unchangedsince value, then the command fails. 302 On failure, a MODIFIED response code is returned which includes 303 the message set (for STORE) or set of UIDs (for UID STORE) 304 of all messages that failed the UNCHANGESINCE test. 306 Example: 308 C: a101 STORE 7,5,9 (UNCHANGEDSINCE 20000320162338) 309 +FLAGS.SILENT (\Deleted) 310 S: a101 NO [MODIFIED 7,9] Conditional STORE failed 312 In spite of the failure of the conditional STORE operation 313 for message 7, the server continues to process the conditional 314 STORE in order to find all messages which fail the test. 316 Use of UNCHANGEDSINCE with a modification sequence of 0 317 always fails if the metadata item exists. 319 Example: 321 C: a102 STORE 12 (UNCHANGEDSINCE 0) 322 +FLAGS.SILENT ($MDNSent) 323 S: a102 NO [MODIFIED 12] Conditional STORE failed 325 If the operation is successful the server MUST update the 326 mod-sequence attribute for every message that was changed. 327 Untagged FETCH responses MUST be sent (even if .SILENT is 328 specified) and each response MUST include MODSEQ message data 329 item if its mod-sequence has changed. This is required to 330 update clients cache with the correct mod-sequence values. 331 See section 4.3 for more details. 333 Example: 335 C: a103 UID STORE 6,4,8 (UNCHANGEDSINCE 200012121230045) 336 +FLAGS.SILENT (\Deleted) 337 S: * 1 FETCH (UID 4 MODSEQ (200012121231000)) 338 S: * 2 FETCH (UID 6 MODSEQ (200012101230852)) 339 S: * 4 FETCH (UID 8 MODSEQ (200012121130956)) 340 S: a103 OK Conditional Store completed 342 Example: 344 C: a104 STORE * (UNCHANGEDSINCE 200012121230045) +FLAGS.SILENT 345 (\Deleted $Processed) 346 S: * 50 FETCH (MODSEQ (200012111230045)) 347 S: a104 OK Store (conditional) completed 349 Note: If a message is specified multiple times in the message 350 set, and the server doesn't internally eliminate duplicates from 351 the message set, it MUST NOT fail the conditional STORE 352 operation for the second (or subsequent) occurrence of the message 353 if the operation completed successfully for the first occurrence. 354 For example, if the client specifies: 356 a100 STORE 7,3:9 (UNCHANGEDSINCE 200012121230045) 357 +FLAGS.SILENT (\Deleted) 359 the server must not fail the operation for message 7 as part of 360 processing "3:9" if it succeeded when message 7 was processed 361 the first time. 363 4.3. MODSEQ message data item in FETCH Command 365 This extension adds a MODSEQ message data item to the FETCH command. 366 The MODSEQ message data item allows clients to retrieve mod-sequence 367 values for a range of messages in the currently selected mailbox. 369 Once the client specified the MODSEQ message data item in a FETCH request, 370 the server MUST include the MODSEQ fetch response data items in all 371 subsequent unsolicited FETCH responses. 373 Syntax: MODSEQ [] 375 The MODSEQ message data item causes the server to return MODSEQ fetch 376 response data items. 378 Syntax: MODSEQ ( ) 380 MODSEQ response data items contain per-message mod-sequences. 382 The MODSEQ response data item is returned if the client issued FETCH with 383 MODSEQ message data item. It also allows the server to notify the client 384 about mod-sequence changes caused by conditional STOREs (section 4.2) and/or 385 changes caused by external sources. 387 Example: 389 C: a FETCH 1:3 (MODSEQ) 390 S: * 1 FETCH (MODSEQ (20000624140003)) 391 S: * 2 FETCH (MODSEQ (20000624140007)) 392 S: * 3 FETCH (MODSEQ (20000624140005)) 393 S: a OK Fetch complete 395 In this example the client requests per message modsequences for a 396 set of messages. 398 When a flag for a message is modified in a different session, the server 399 sends an unsolicited FETCH response containing the modsequence for the 400 message. 402 Example: 404 (Session 1, authenticated as a user "alex"). The user adds a shared 405 flag \Deleted: 407 C: A142 SELECT INBOX 408 ... 409 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 410 S: * OK [PERMANENTFLAGS (\Answered \Deleted \Seen \*)] Limited 411 ... 413 C: A160 STORE 7 +FLAGS.SILENT (\Deleted) 414 S: * 7 FETCH (MODSEQ (200012121231000)) 415 S: A160 OK Store completed 417 (Session 2, also authenticated as the user "alex"). Any changes to flags 418 are always reported to all sessions authenticated as the same user as in 419 the session 1. 421 C: C180 NOOP 422 S: * 7 FETCH (FLAGS (\Deleted \Answered) MODSEQ (200012121231000)) 423 S: C180 OK Noop completed 425 (Session 3, authenticated as a user "andrew"). As \Deleted is a shared 426 flag, changes in the session 1 are also reported in the session 3: 428 C: D210 NOOP 429 S: * 7 FETCH (FLAGS (\Deleted \Answered) MODSEQ (200012121231000)) 430 S: D210 OK Noop completed 432 The user modifies a private flag \Seen in the session 1 ... 434 C: A240 STORE 7 +FLAGS.SILENT (\Seen) 435 S: * 7 FETCH (MODSEQ (200012121231777)) 436 S: A240 OK Store completed 438 ... which is only reported in the session 2 ... 440 C: C270 NOOP 441 S: * 7 FETCH (FLAGS (\Deleted \Answered \Seen) MODSEQ (200012121231777)) 442 S: C270 OK Noop completed 444 ... but not in the session 3. 446 C: D300 NOOP 447 S: D300 OK Noop completed 449 And finally the user removes flags \Answered (shared) and \Seen (private) 450 in the session 1. 452 C: A330 STORE 7 -FLAGS.SILENT (\Answered \Seen) 453 S: * 7 FETCH (MODSEQ (200012121245160)) 454 S: A330 OK Store completed 456 Both changes are reported in the session 2 ... 458 C: C360 NOOP 459 S: * 7 FETCH (FLAGS (\Deleted) MODSEQ (200012121245160)) 460 S: C360 OK Noop completed 462 ... and only changes to shared flags are reported in session 3. 464 C: D390 NOOP 465 S: * 7 FETCH (FLAGS (\Deleted) MODSEQ (200012121245160)) 466 S: D390 OK Noop completed 468 4.4. MODSEQ search criterion in SEARCH 470 The MODSEQ criterion for the SEARCH command allows a client to search 471 for the metadata items that were modified since a specified moment. 473 Syntax: MODSEQ [ ] 475 Messages that have modification values which are equal to or 476 greater than . This allows a client, for example, 477 to find out which messages contain metadata items that have changed 478 since the last time it updated its disconnected cache. 479 The client can also specify and entry type (one of 480 "shared", "private" or "all") before . 481 If the server doesn't store internally separate mod-sequences 482 for different flags and annotations, it MUST ignore 483 and . Otherwise the server should 484 use them to narrow down the search. 486 If client specifies a MODSEQ criterion in a SEARCH command and 487 the server returns a non-empty SEARCH result, the server MUST also 488 return a MODSEQ response code in the tagged OK response. The MODSEQ 489 response code covers all messages returned in the untagged SEARCH results. 490 See also section 4.6. 492 Example: 493 C: a SEARCH MODSEQ "/message/flags/draft" all 20010320162338 494 ANNOTATION "/message/comment" "value" "IMAP4" 495 S: * SEARCH 2 5 6 7 11 12 18 19 20 23 496 S: a OK [MODSEQ 2,5:7,11:12,18:20,23 20010917162500] Search complete 498 In the above example, the message numbers of any messages 499 containing the string "IMAP4" in the "value" attribute of the 500 "/message/comment" entry and having a mod-sequence equal to or 501 greater than 20010320162338 for the "\Draft" flag are returned in 502 the search results. 504 Example: 505 C: a SEARCH OR NOT MODSEQ 20010320162338 LARGER 50000 506 S: * SEARCH 507 S: a OK Search complete, nothing found 509 4.5. MODSEQ Sort Criterion 511 If a server implementing CONDSTORE also implements the SORT 512 extension as defined by [SORT], it MUST also support sorting on 513 per-message mod-sequence. 515 Syntax: MODSEQ 517 If client specifies a MODSEQ search (as per section 4.4) or sort 518 criterion in the SORT command and the server returns a non-empty 519 SORT result, the server MUST also return a MODSEQ response 520 code in the tagged OK response which covers all messages returned 521 in untagged SORT responses. See also section 4.6. 523 Example: 524 C: A282 SORT (SUBJECT MODSEQ) UTF-8 SINCE 1-Feb-2001 525 S: * SORT 2 81 83 84 82 882 526 S: A282 OK [MODSEQ 2,81:84,882 117] SORT completed 528 Example: 529 C: A283 SORT (SUBJECT REVERSE DATE) UTF-8 MODSEQ 21 530 S: * SORT 6 3 4 5 2 531 S: A283 OK [MODSEQ 2:6 125] SORT completed 533 Example: 534 C: A284 SORT (MODSEQ) KOI8-R OR NOT MODSEQ 20010320162338 535 SUBJECT "Privet" 536 S: * SORT 537 S: A284 OK Sort complete, nothing found 539 4.6. MODSEQ Response code for successful SEARCH and SORT 541 Data: message set 542 mod-sequence value 544 The MODSEQ response code is sent in the following two cases: 546 1) If a client specifies a MODSEQ criterion in a SEARCH command 547 and the server returns a non-empty SEARCH result, the server MUST 548 also return a MODSEQ response code in the tagged OK response. 549 The MODSEQ response code MUST be for all messages which were returned 550 in the untagged SEARCH response. 552 The MODSEQ response code contains the message set to which 553 the mod-sequence applies if it is in response to a SEARCH command; 554 or the UID set if it is caused by a UID SEARCH command. 556 2) If client specifies a MODSEQ search or sort criterion in a 557 SORT command and the server returns a non-empty SORT result, 558 the server MUST also return a MODSEQ response code in the tagged 559 OK response for all messages returned in the untagged SORT response. 561 The MODSEQ response code contains the message set to which 562 the mod-sequence applies if it is sent in response to a SORT command, 563 or the UID set if it is caused by UID SORT. 565 4.7. HIGHESTMODSEQ status data items 567 This document defines a new status data item: 569 HIGHESTMODSEQ 570 The highest mod-sequence value all messages 571 in the mailbox. This is the same value that is returned by the server 572 in the HIGHESTMODSEQ response code in OK untagged response 573 (see section 4.1.1). 575 Example: C: A042 STATUS blurdybloop (UIDNEXT MESSAGES HIGHESTMODSEQ) 576 S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292 577 HIGHESTMODSEQ 200201011231777) 578 S: A042 OK STATUS completed 580 5. Formal Syntax 582 The following syntax specification uses the Augmented Backus-Naur 583 Form (ABNF) notation as specified in [ABNF]. 585 Non-terminals referenced but not defined below are as defined by 586 [IMAP4]. 588 Except as noted otherwise, all alphabetic characters are case- 589 insensitive. The use of upper or lower case characters to define token 590 strings is for editorial clarity only. Implementations MUST accept 591 these strings in a case-insensitive fashion. 593 capability =/ "CONDSTORE" 595 status = "STATUS" SP mailbox SP 596 "(" status-att-req *(SP status-att-req) ")" 597 ;; redefine STATUS command syntax defined in [IMAP4] 599 status-att-req = status-att / "HIGHESTMODSEQ" 601 mailbox-data =/ "STATUS" SP mailbox SP "(" 602 [status-rsp-info *(SP status-rsp-info)] ")" 604 status-rsp-info = status-att SP number / 605 "HIGHESTMODSEQ" SP mod-sequence-value 607 store = "STORE" SP set store-modifiers SP store-att-flags 609 store-modifiers = [ SP "(" store-modifier *(SP store-modifier) ")" ] 611 store-modifier = "UNCHANGEDSINCE" SP mod-sequence-value 612 ;; Only single "UNCHANGEDSINCE" may be specified 613 ;; in a STORE operation 615 fetch-att =/ fetch-mod-sequence 616 ;; modifies original IMAP4 fetch-att 618 fetch-mod-sequence = "MODSEQ" 620 fetch-mod-resp = "MODSEQ" SP "(" permsg-modsequence ")" 622 search-key =/ search-modsequence 623 ;; modifies original IMAP4 search-key 625 search-modsequence = "MODSEQ" [search-modseq-ext] SP mod-sequence-value 627 search-modseq-ext = SP entry-name SP entry-type-req 629 resp-text-code =/ "HIGHESTMODSEQ" SP mod-sequence-value / 630 "MODIFIED" SP set / 631 "MODSEQ" SP set SP mod-sequence-value 632 ;; set of message numbers for STORE/FETCH or 633 ;; set of UIDs for UID STORE/UID FECTH 635 entry-name = '"' "/message/flags/" attr-flag '"' 636 ;; each system or user defined flag 637 ;; is mapped to "/message/flags/", 638 ;; where has no leading "\" for system 639 ;; flags and has a leading "-" for all user 640 ;; defined flags. 642 entry-type-resp = "private" | "shared" 643 ;; metadata item type 645 entry-type-req = entry-type-resp | "all" 646 ;; perform SEARCH operation on private 647 ;; metadata item, shared metadata item or both 649 permsg-modsequence = mod-sequence-value 650 ;; per message mod-sequence 652 mod-sequence-value = 1*DIGIT 653 ;; Unsigned 64-bit integer (mod-sequence) 654 ;; (0 <= n < 18,446,744,073,709,551,615) 656 ;;Borrowed from IMAP4rev1 and modified accordingly: 658 attr-flag = "Answered" / "Flagged" / "Deleted" / 659 "Seen" / "Draft" / "-" attr-flag-keyword / 660 attr-flag-extension 661 ;; Does not include "\Recent" 663 attr-flag-extension = atom 664 ;; Future expansion. Client implementations 665 ;; MUST accept flag-extension flags. Server 666 ;; implementations MUST NOT generate 667 ;; flag-extension flags except as defined by 668 ;; future standard or standards-track 669 ;; revisions of this specification. 671 attr-flag-keyword = atom 673 ;;Extension to SORT 675 sort-key =/ "MODSEQ" 677 6. Security Considerations 679 There are no known security issues with this extension, not already 680 found in [IMAP4]. 682 7. References 684 7.1. Normative References 686 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 687 Requirement Levels", RFC 2119, Harvard University, March 1997. 689 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: 690 ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd, 691 November 1997. 693 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 694 4rev1", RFC 2060, University of Washington, December 1996. 696 [ANNOTATE] Gellens, R., Daboo, C., "IMAP ANNOTATE Extension", 697 work in progress. 698 700 [SORT] Crispin, M., "Internet Message Access Protocol -- SORT 701 Extension", work in progress. 702 704 7.2. Informative References 706 [ACAP] Newman, Myers, "ACAP -- Application Configuration Access 707 Protocol", RFC 2244, Innosoft, Netscape, November 1997. 708 710 [ACL] Myers, "IMAP4 ACL extension", RFC 2086, Carnegie Mellon, 711 January 1997. 712 714 [NTP] Mills, D, "Network Time Protocol (Version 3) Specification, 715 Implementation and Analysis", RFC 1305, March 1992. 716 718 8. Acknowledgments 720 Some text was borrowed from "IMAP ANNOTATE Extension" by Randall Gellens 721 and Cyrus Daboo, and "ACAP -- Application Configuration Access Protocol" 722 by Chris Newman and John Myers. 724 Many thanks to Randall Gellens for his comments on how CONDSTORE should 725 interact with ANNOTATE extension and for thorough review of the document. 727 Authors also acknowledge the feedback provided by Cyrus Daboo, Larry 728 Greenfield, Chris Newman and Arnt Gulbrandsen. 730 9. Author's Addresses 732 Alexey Melnikov 733 mailto: Alexey.Melnikov@messagingdirect.com 735 ACI WorldWide/MessagingDirect 736 59 Clarendon Road, Watford, Hertfordshire, 737 WD17 1FQ, United Kingdom 739 Steve Hole 740 mailto: Steve.Hole@messagingdirect.com 742 ACI WorldWide/MessagingDirect 743 #900, 10117 Jasper Avenue, 744 Edmonton, Alberta, T5J 1W8, CANADA 746 10. Full Copyright Statement 748 Copyright (C) The Internet Society 2001-2002. All Rights Reserved. 750 This document and translations of it may be copied and furnished to 751 others, and derivative works that comment on or otherwise explain it 752 or assist in its implementation may be prepared, copied, published 753 and distributed, in whole or in part, without restriction of any 754 kind, provided that the above copyright notice and this paragraph 755 are included on all such copies and derivative works. However, this 756 document itself may not be modified in any way, such as by removing 757 the copyright notice or references to the Internet Society or other 758 Internet organizations, except as needed for the purpose of 759 developing Internet standards in which case the procedures for 760 copyrights defined in the Internet Standards process must be 761 followed, or as required to translate it into languages other than 762 English. 764 The limited permissions granted above are perpetual and will not be 765 revoked by the Internet Society or its successors or assigns. 767 This document and the information contained herein is provided on an 768 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 769 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 770 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 771 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 772 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 774 Acknowledgement 776 Funding for the RFC Editor function is currently provided by the 777 Internet Society.