imapext-2007
diff docs/rfc/rfc4551.txt @ 0:ada5e610ab86
imap-2007e
| author | yuuji@gentei.org |
|---|---|
| date | Mon, 14 Sep 2009 15:17:45 +0900 |
| parents | |
| children |
line diff
1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000 1.2 +++ b/docs/rfc/rfc4551.txt Mon Sep 14 15:17:45 2009 +0900 1.3 @@ -0,0 +1,1403 @@ 1.4 + 1.5 + 1.6 + 1.7 + 1.8 + 1.9 + 1.10 +Network Working Group A. Melnikov 1.11 +Request for Comments: 4551 Isode Ltd. 1.12 +Updates: 3501 S. Hole 1.13 +Category: Standards Track ACI WorldWide/MessagingDirect 1.14 + June 2006 1.15 + 1.16 + 1.17 + IMAP Extension for Conditional STORE Operation 1.18 + or Quick Flag Changes Resynchronization 1.19 + 1.20 +Status of This Memo 1.21 + 1.22 + This document specifies an Internet standards track protocol for the 1.23 + Internet community, and requests discussion and suggestions for 1.24 + improvements. Please refer to the current edition of the "Internet 1.25 + Official Protocol Standards" (STD 1) for the standardization state 1.26 + and status of this protocol. Distribution of this memo is unlimited. 1.27 + 1.28 +Copyright Notice 1.29 + 1.30 + Copyright (C) The Internet Society (2006). 1.31 + 1.32 +Abstract 1.33 + 1.34 + Often, multiple IMAP (RFC 3501) clients need to coordinate changes to 1.35 + a common IMAP mailbox. Examples include different clients working on 1.36 + behalf of the same user, and multiple users accessing shared 1.37 + mailboxes. These clients need a mechanism to synchronize state 1.38 + changes for messages within the mailbox. They must be able to 1.39 + guarantee that only one client can change message state (e.g., 1.40 + message flags) at any time. An example of such an application is use 1.41 + of an IMAP mailbox as a message queue with multiple dequeueing 1.42 + clients. 1.43 + 1.44 + The Conditional Store facility provides a protected update mechanism 1.45 + for message state information that can detect and resolve conflicts 1.46 + between multiple writing mail clients. 1.47 + 1.48 + The Conditional Store facility also allows a client to quickly 1.49 + resynchronize mailbox flag changes. 1.50 + 1.51 + This document defines an extension to IMAP (RFC 3501). 1.52 + 1.53 + 1.54 + 1.55 + 1.56 + 1.57 + 1.58 + 1.59 + 1.60 + 1.61 +Melnikov & Hole Standards Track [Page 1] 1.62 + 1.63 +RFC 4551 IMAP Extension for Conditional STORE June 2006 1.64 + 1.65 + 1.66 +Table of Contents 1.67 + 1.68 + 1. Introduction and Overview ................................. 3 1.69 + 2. Conventions Used in This Document ......................... 5 1.70 + 3. IMAP Protocol Changes ..................................... 6 1.71 + 3.1. New OK untagged responses for SELECT and EXAMINE ......... 6 1.72 + 3.1.1. HIGHESTMODSEQ response code ............................ 6 1.73 + 3.1.2. NOMODSEQ response code ................................. 7 1.74 + 3.2. STORE and UID STORE Commands ............................. 7 1.75 + 3.3 FETCH and UID FETCH Commands ..............................13 1.76 + 3.3.1. CHANGEDSINCE FETCH modifier ............................13 1.77 + 3.3.2. MODSEQ message data item in FETCH Command ..............14 1.78 + 3.4. MODSEQ search criterion in SEARCH ........................16 1.79 + 3.5. Modified SEARCH untagged response ........................17 1.80 + 3.6. HIGHESTMODSEQ status data items ..........................17 1.81 + 3.7. CONDSTORE parameter to SELECT and EXAMINE ................18 1.82 + 3.8. Additional quality of implementation issues ..............18 1.83 + 4. Formal Syntax .............................................19 1.84 + 5. Server implementation considerations ......................21 1.85 + 6. Security Considerations ...................................22 1.86 + 7. IANA Considerations .......................................22 1.87 + 8. References ................................................23 1.88 + 8.1. Normative References .....................................23 1.89 + 8.2. Informative References ...................................23 1.90 + 9. Acknowledgements ..........................................23 1.91 + 1.92 + 1.93 + 1.94 + 1.95 + 1.96 + 1.97 + 1.98 + 1.99 + 1.100 + 1.101 + 1.102 + 1.103 + 1.104 + 1.105 + 1.106 + 1.107 + 1.108 + 1.109 + 1.110 + 1.111 + 1.112 + 1.113 + 1.114 + 1.115 + 1.116 + 1.117 +Melnikov & Hole Standards Track [Page 2] 1.118 + 1.119 +RFC 4551 IMAP Extension for Conditional STORE June 2006 1.120 + 1.121 + 1.122 +1. Introduction and Overview 1.123 + 1.124 + The Conditional STORE extension is present in any IMAP4 1.125 + implementation that returns "CONDSTORE" as one of the supported 1.126 + capabilities in the CAPABILITY command response. 1.127 + 1.128 + An IMAP server that supports this extension MUST associate a positive 1.129 + unsigned 64-bit value called a modification sequence (mod-sequence) 1.130 + with every IMAP message. This is an opaque value updated by the 1.131 + server whenever a metadata item is modified. The server MUST 1.132 + guarantee that each STORE command performed on the same mailbox 1.133 + (including simultaneous stores to different metadata items from 1.134 + different connections) will get a different mod-sequence value. 1.135 + Also, for any two successful STORE operations performed in the same 1.136 + session on the same mailbox, the mod-sequence of the second completed 1.137 + operation MUST be greater than the mod-sequence of the first 1.138 + completed. Note that the latter rule disallows the use of the system 1.139 + clock as a mod-sequence, because if system time changes (e.g., an NTP 1.140 + [NTP] client adjusting the time), the next generated value might be 1.141 + less than the previous one. 1.142 + 1.143 + Mod-sequences allow a client that supports the CONDSTORE extension to 1.144 + determine if a message metadata has changed since some known moment. 1.145 + Whenever the state of a flag changes (i.e., the flag is added where 1.146 + previously it wasn't set, or the flag is removed and before it was 1.147 + set) the value of the modification sequence for the message MUST be 1.148 + updated. Adding the flag when it is already present or removing when 1.149 + it is not present SHOULD NOT change the mod-sequence. 1.150 + 1.151 + When a message is appended to a mailbox (via the IMAP APPEND command, 1.152 + COPY to the mailbox, or using an external mechanism) the server 1.153 + generates a new modification sequence that is higher than the highest 1.154 + modification sequence of all messages in the mailbox and assigns it 1.155 + to the appended message. 1.156 + 1.157 + The server MAY store separate (per-message) modification sequence 1.158 + values for different metadata items. If the server does so, per- 1.159 + message mod-sequence is the highest mod-sequence of all metadata 1.160 + items for the specified message. 1.161 + 1.162 + The server that supports this extension is not required to be able to 1.163 + store mod-sequences for every available mailbox. Section 3.1.2 1.164 + describes how the server may act if a particular mailbox doesn't 1.165 + support the persistent storage of mod-sequences. 1.166 + 1.167 + 1.168 + 1.169 + 1.170 + 1.171 + 1.172 + 1.173 +Melnikov & Hole Standards Track [Page 3] 1.174 + 1.175 +RFC 4551 IMAP Extension for Conditional STORE June 2006 1.176 + 1.177 + 1.178 + This extension makes the following changes to the IMAP4 protocol: 1.179 + 1.180 + a) adds UNCHANGEDSINCE STORE modifier. 1.181 + 1.182 + b) adds the MODIFIED response code which should be used with an OK 1.183 + response to the STORE command. (It can also be used in a NO 1.184 + response.) 1.185 + 1.186 + c) adds a new MODSEQ message data item for use with the FETCH 1.187 + command. 1.188 + 1.189 + d) adds CHANGEDSINCE FETCH modifier. 1.190 + 1.191 + e) adds a new MODSEQ search criterion. 1.192 + 1.193 + f) extends the syntax of untagged SEARCH responses to include 1.194 + mod-sequence. 1.195 + 1.196 + g) adds new OK untagged responses for the SELECT and EXAMINE 1.197 + commands. 1.198 + 1.199 + h) defines an additional parameter to SELECT/EXAMINE commands. 1.200 + 1.201 + i) adds the HIGHESTMODSEQ status data item to the STATUS command. 1.202 + 1.203 + A client supporting CONDSTORE extension indicates its willingness to 1.204 + receive mod-sequence updates in all untagged FETCH responses by 1.205 + issuing: 1.206 + 1.207 + - a SELECT or EXAMINE command with the CONDSTORE parameter, 1.208 + - a STATUS (HIGHESTMODSEQ) command, 1.209 + - a FETCH or SEARCH command that includes the MODSEQ message data 1.210 + item, 1.211 + - a FETCH command with the CHANGEDSINCE modifier, or 1.212 + - a STORE command with the UNCHANGEDSINCE modifier. 1.213 + 1.214 + The server MUST include mod-sequence data in all subsequent untagged 1.215 + FETCH responses (until the connection is closed), whether they were 1.216 + caused by a regular STORE, a STORE with UNCHANGEDSINCE modifier, or 1.217 + an external agent. 1.218 + 1.219 + This document uses the term "CONDSTORE-aware client" to refer to a 1.220 + client that announces its willingness to receive mod-sequence updates 1.221 + as described above. The term "CONDSTORE enabling command" will refer 1.222 + any of the commands listed above. A future extension to this 1.223 + document may extend the list of CONDSTORE enabling commands. A first 1.224 + CONDSTORE enabling command executed in the session MUST cause the 1.225 + 1.226 + 1.227 + 1.228 + 1.229 +Melnikov & Hole Standards Track [Page 4] 1.230 + 1.231 +RFC 4551 IMAP Extension for Conditional STORE June 2006 1.232 + 1.233 + 1.234 + server to return HIGHESTMODSEQ (Section 3.1.1) unless the server has 1.235 + sent NOMODSEQ (Section 3.1.2) response code when the currently 1.236 + selected mailbox was selected. 1.237 + 1.238 + The rest of this document describes the protocol changes more 1.239 + rigorously. 1.240 + 1.241 +2. Conventions Used in This Document 1.242 + 1.243 + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 1.244 + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 1.245 + document are to be interpreted as described in RFC 2119 [KEYWORDS]. 1.246 + 1.247 + In examples, lines beginning with "S:" are sent by the IMAP server, 1.248 + and lines beginning with "C:" are sent by the client. Line breaks 1.249 + may appear in example commands solely for editorial clarity; when 1.250 + present in the actual message, they are represented by "CRLF". 1.251 + 1.252 + Formal syntax is defined using ABNF [ABNF]. 1.253 + 1.254 + The term "metadata" or "metadata item" is used throughout this 1.255 + document. It refers to any system or user-defined keyword. Future 1.256 + documents may extend "metadata" to include other dynamic message 1.257 + data. 1.258 + 1.259 + Some IMAP mailboxes are private, accessible only to the owning user. 1.260 + Other mailboxes are not, either because the owner has set an Access 1.261 + Control List [ACL] that permits access by other users, or because it 1.262 + is a shared mailbox. Let's call a metadata item "shared" for the 1.263 + mailbox if any changes to the metadata items are persistent and 1.264 + visible to all other users accessing the mailbox. Otherwise, the 1.265 + metadata item is called "private". Note that private metadata items 1.266 + are still visible to all sessions accessing the mailbox as the same 1.267 + user. Also note that different mailboxes may have different metadata 1.268 + items as shared. 1.269 + 1.270 + See Section 1 for the definition of a "CONDSTORE-aware client" and a 1.271 + "CONDSTORE enabling command". 1.272 + 1.273 + 1.274 + 1.275 + 1.276 + 1.277 + 1.278 + 1.279 + 1.280 + 1.281 + 1.282 + 1.283 + 1.284 + 1.285 +Melnikov & Hole Standards Track [Page 5] 1.286 + 1.287 +RFC 4551 IMAP Extension for Conditional STORE June 2006 1.288 + 1.289 + 1.290 +3. IMAP Protocol Changes 1.291 + 1.292 +3.1. New OK Untagged Responses for SELECT and EXAMINE 1.293 + 1.294 + This document adds two new response codes, HIGHESTMODSEQ and 1.295 + NOMODSEQ. One of those response codes MUST be returned in the OK 1.296 + untagged response for a successful SELECT/EXAMINE command. 1.297 + 1.298 + When opening a mailbox, the server must check if the mailbox supports 1.299 + the persistent storage of mod-sequences. If the mailbox supports the 1.300 + persistent storage of mod-sequences and the mailbox open operation 1.301 + succeeds, the server MUST send the OK untagged response including 1.302 + HIGHESTMODSEQ response code. If the persistent storage for the 1.303 + mailbox is not supported, the server MUST send the OK untagged 1.304 + response including NOMODSEQ response code instead. 1.305 + 1.306 +3.1.1. HIGHESTMODSEQ Response Code 1.307 + 1.308 + This document adds a new response code that is returned in the OK 1.309 + untagged response for the SELECT and EXAMINE commands. A server 1.310 + supporting the persistent storage of mod-sequences for the mailbox 1.311 + MUST send the OK untagged response including HIGHESTMODSEQ response 1.312 + code with every successful SELECT or EXAMINE command: 1.313 + 1.314 + OK [HIGHESTMODSEQ <mod-sequence-value>] 1.315 + 1.316 + where <mod-sequence-value> is the highest mod-sequence value of 1.317 + all messages in the mailbox. When the server changes UIDVALIDITY 1.318 + for a mailbox, it doesn't have to keep the same HIGHESTMODSEQ for 1.319 + the mailbox. 1.320 + 1.321 + A disconnected client can use the value of HIGHESTMODSEQ to check if 1.322 + it has to refetch metadata from the server. If the UIDVALIDITY value 1.323 + has changed for the selected mailbox, the client MUST delete the 1.324 + cached value of HIGHESTMODSEQ. If UIDVALIDITY for the mailbox is the 1.325 + same, and if the HIGHESTMODSEQ value stored in the client's cache is 1.326 + less than the value returned by the server, then some metadata items 1.327 + on the server have changed since the last synchronization, and the 1.328 + client needs to update its cache. The client MAY use SEARCH MODSEQ 1.329 + (Section 3.4) to find out exactly which metadata items have changed. 1.330 + Alternatively, the client MAY issue FETCH with the CHANGEDSINCE 1.331 + modifier (Section 3.3.1) in order to fetch data for all messages that 1.332 + have metadata items changed since some known modification sequence. 1.333 + 1.334 + Example 1: 1.335 + 1.336 + C: A142 SELECT INBOX 1.337 + S: * 172 EXISTS 1.338 + 1.339 + 1.340 + 1.341 +Melnikov & Hole Standards Track [Page 6] 1.342 + 1.343 +RFC 4551 IMAP Extension for Conditional STORE June 2006 1.344 + 1.345 + 1.346 + S: * 1 RECENT 1.347 + S: * OK [UNSEEN 12] Message 12 is first unseen 1.348 + S: * OK [UIDVALIDITY 3857529045] UIDs valid 1.349 + S: * OK [UIDNEXT 4392] Predicted next UID 1.350 + S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 1.351 + S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited 1.352 + S: * OK [HIGHESTMODSEQ 715194045007] 1.353 + S: A142 OK [READ-WRITE] SELECT completed 1.354 + 1.355 +3.1.2. NOMODSEQ Response Code 1.356 + 1.357 + A server that doesn't support the persistent storage of mod-sequences 1.358 + for the mailbox MUST send the OK untagged response including NOMODSEQ 1.359 + response code with every successful SELECT or EXAMINE command. A 1.360 + server that returned NOMODSEQ response code for a mailbox, which 1.361 + subsequently receives one of the following commands while the mailbox 1.362 + is selected: 1.363 + 1.364 + - a FETCH command with the CHANGEDSINCE modifier, 1.365 + - a FETCH or SEARCH command that includes the MODSEQ message data 1.366 + item, or 1.367 + - a STORE command with the UNCHANGEDSINCE modifier 1.368 + 1.369 + MUST reject any such command with the tagged BAD response. 1.370 + 1.371 + Example 2: 1.372 + 1.373 + C: A142 SELECT INBOX 1.374 + S: * 172 EXISTS 1.375 + S: * 1 RECENT 1.376 + S: * OK [UNSEEN 12] Message 12 is first unseen 1.377 + S: * OK [UIDVALIDITY 3857529045] UIDs valid 1.378 + S: * OK [UIDNEXT 4392] Predicted next UID 1.379 + S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 1.380 + S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited 1.381 + S: * OK [NOMODSEQ] Sorry, this mailbox format doesn't support 1.382 + modsequences 1.383 + S: A142 OK [READ-WRITE] SELECT completed 1.384 + 1.385 +3.2. STORE and UID STORE Commands 1.386 + 1.387 + This document defines the following STORE modifier (see Section 2.5 1.388 + of [IMAPABNF]): 1.389 + 1.390 + UNCHANGEDSINCE <mod-sequence> 1.391 + 1.392 + For each message specified in the message set, the server performs 1.393 + the following. If the mod-sequence of any metadata item of the 1.394 + 1.395 + 1.396 + 1.397 +Melnikov & Hole Standards Track [Page 7] 1.398 + 1.399 +RFC 4551 IMAP Extension for Conditional STORE June 2006 1.400 + 1.401 + 1.402 + message is equal or less than the specified UNCHANGEDSINCE value, 1.403 + then the requested operation (as described by the message data 1.404 + item) is performed. If the operation is successful, the server 1.405 + MUST update the mod-sequence attribute of the message. An 1.406 + untagged FETCH response MUST be sent, even if the .SILENT suffix 1.407 + is specified, and the response MUST include the MODSEQ message 1.408 + data item. This is required to update the client's cache with the 1.409 + correct mod-sequence values. See Section 3.3.2 for more details. 1.410 + 1.411 + However, if the mod-sequence of any metadata item of the message 1.412 + is greater than the specified UNCHANGEDSINCE value, then the 1.413 + requested operation MUST NOT be performed. In this case, the 1.414 + mod-sequence attribute of the message is not updated, and the 1.415 + message number (or unique identifier in the case of the UID STORE 1.416 + command) is added to the list of messages that failed the 1.417 + UNCHANGESINCE test. 1.418 + 1.419 + When the server finished performing the operation on all the 1.420 + messages in the message set, it checks for a non-empty list of 1.421 + messages that failed the UNCHANGESINCE test. If this list is 1.422 + non-empty, the server MUST return in the tagged response a 1.423 + MODIFIED response code. The MODIFIED response code includes the 1.424 + message set (for STORE) or set of UIDs (for UID STORE) of all 1.425 + messages that failed the UNCHANGESINCE test. 1.426 + 1.427 + Example 3: 1.428 + 1.429 + All messages pass the UNCHANGESINCE test. 1.430 + 1.431 + C: a103 UID STORE 6,4,8 (UNCHANGEDSINCE 12121230045) 1.432 + +FLAGS.SILENT (\Deleted) 1.433 + S: * 1 FETCH (UID 4 MODSEQ (12121231000)) 1.434 + S: * 2 FETCH (UID 6 MODSEQ (12121230852)) 1.435 + S: * 4 FETCH (UID 8 MODSEQ (12121130956)) 1.436 + S: a103 OK Conditional Store completed 1.437 + 1.438 + Example 4: 1.439 + 1.440 + C: a104 STORE * (UNCHANGEDSINCE 12121230045) +FLAGS.SILENT 1.441 + (\Deleted $Processed) 1.442 + S: * 50 FETCH (MODSEQ (12111230047)) 1.443 + S: a104 OK Store (conditional) completed 1.444 + 1.445 + Example 5: 1.446 + 1.447 + C: c101 STORE 1 (UNCHANGEDSINCE 12121230045) -FLAGS.SILENT 1.448 + (\Deleted) 1.449 + S: * OK [HIGHESTMODSEQ 12111230047] 1.450 + 1.451 + 1.452 + 1.453 +Melnikov & Hole Standards Track [Page 8] 1.454 + 1.455 +RFC 4551 IMAP Extension for Conditional STORE June 2006 1.456 + 1.457 + 1.458 + S: * 50 FETCH (MODSEQ (12111230048)) 1.459 + S: c101 OK Store (conditional) completed 1.460 + 1.461 + HIGHESTMODSEQ response code was sent by the server presumably 1.462 + because this was the first CONDSTORE enabling command. 1.463 + 1.464 + Example 6: 1.465 + 1.466 + In spite of the failure of the conditional STORE operation for 1.467 + message 7, the server continues to process the conditional STORE 1.468 + in order to find all messages that fail the test. 1.469 + 1.470 + C: d105 STORE 7,5,9 (UNCHANGEDSINCE 320162338) 1.471 + +FLAGS.SILENT (\Deleted) 1.472 + S: * 5 FETCH (MODSEQ (320162350)) 1.473 + S: d105 OK [MODIFIED 7,9] Conditional STORE failed 1.474 + 1.475 + Example 7: 1.476 + 1.477 + Same as above, but the server follows the SHOULD recommendation in 1.478 + Section 6.4.6 of [IMAP4]. 1.479 + 1.480 + C: d105 STORE 7,5,9 (UNCHANGEDSINCE 320162338) 1.481 + +FLAGS.SILENT (\Deleted) 1.482 + S: * 7 FETCH (MODSEQ (320162342) FLAGS (\Seen \Deleted)) 1.483 + S: * 5 FETCH (MODSEQ (320162350)) 1.484 + S: * 9 FETCH (MODSEQ (320162349) FLAGS (\Answered)) 1.485 + S: d105 OK [MODIFIED 7,9] Conditional STORE failed 1.486 + 1.487 + Use of UNCHANGEDSINCE with a modification sequence of 0 always 1.488 + fails if the metadata item exists. A system flag MUST always be 1.489 + considered existent, whether it was set or not. 1.490 + 1.491 + Example 8: 1.492 + 1.493 + C: a102 STORE 12 (UNCHANGEDSINCE 0) 1.494 + +FLAGS.SILENT ($MDNSent) 1.495 + S: a102 OK [MODIFIED 12] Conditional STORE failed 1.496 + 1.497 + The client has tested the presence of the $MDNSent user-defined 1.498 + keyword. 1.499 + 1.500 + Note: A client trying to make an atomic change to the state of a 1.501 + particular metadata item (or a set of metadata items) should be 1.502 + prepared to deal with the case when the server returns the MODIFIED 1.503 + response code if the state of the metadata item being watched hasn't 1.504 + changed (but the state of some other metadata item has). This is 1.505 + necessary, because some servers don't store separate mod-sequences 1.506 + 1.507 + 1.508 + 1.509 +Melnikov & Hole Standards Track [Page 9] 1.510 + 1.511 +RFC 4551 IMAP Extension for Conditional STORE June 2006 1.512 + 1.513 + 1.514 + for different metadata items. However, a server implementation 1.515 + SHOULD avoid generating spurious MODIFIED responses for +FLAGS/-FLAGS 1.516 + STORE operations, even when the server stores a single mod-sequence 1.517 + per message. Section 5 describes how this can be achieved. 1.518 + 1.519 + Unless the server has included an unsolicited FETCH to update 1.520 + client's knowledge about messages that have failed the UNCHANGEDSINCE 1.521 + test, upon receipt of the MODIFIED response code, the client SHOULD 1.522 + try to figure out if the required metadata items have indeed changed 1.523 + by issuing FETCH or NOOP command. It is RECOMMENDED that the server 1.524 + avoids the need for the client to do that by sending an unsolicited 1.525 + FETCH response (Examples 9 and 10). 1.526 + 1.527 + If the required metadata items haven't changed, the client SHOULD 1.528 + retry the command with the new mod-sequence. The client SHOULD allow 1.529 + for a configurable but reasonable number of retries (at least 2). 1.530 + 1.531 + Example 9: 1.532 + 1.533 + In the example below, the server returns the MODIFIED response 1.534 + code without sending information describing why the STORE 1.535 + UNCHANGEDSINCE operation has failed. 1.536 + 1.537 + C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000) 1.538 + +FLAGS.SILENT ($Processed) 1.539 + S: * 100 FETCH (MODSEQ (303181230852)) 1.540 + S: * 102 FETCH (MODSEQ (303181230852)) 1.541 + ... 1.542 + S: * 150 FETCH (MODSEQ (303181230852)) 1.543 + S: a106 OK [MODIFIED 101] Conditional STORE failed 1.544 + 1.545 + The flag $Processed was set on the message 101... 1.546 + 1.547 + C: a107 NOOP 1.548 + S: * 101 FETCH (MODSEQ (303011130956) FLAGS ($Processed)) 1.549 + S: a107 OK 1.550 + 1.551 + Or the flag hasn't changed, but another has (note that this server 1.552 + behaviour is discouraged. Server implementers should also see 1.553 + Section 5)... 1.554 + 1.555 + C: b107 NOOP 1.556 + S: * 101 FETCH (MODSEQ (303011130956) FLAGS (\Deleted \Answered)) 1.557 + S: b107 OK 1.558 + 1.559 + ...and the client retries the operation for the message 101 with 1.560 + the updated UNCHANGEDSINCE value 1.561 + 1.562 + 1.563 + 1.564 + 1.565 +Melnikov & Hole Standards Track [Page 10] 1.566 + 1.567 +RFC 4551 IMAP Extension for Conditional STORE June 2006 1.568 + 1.569 + 1.570 + C: b108 STORE 101 (UNCHANGEDSINCE 303011130956) 1.571 + +FLAGS.SILENT ($Processed) 1.572 + S: * 101 FETCH (MODSEQ (303181230852)) 1.573 + S: b108 OK Conditional Store completed 1.574 + 1.575 + Example 10: 1.576 + 1.577 + Same as above, but the server avoids the need for the client to 1.578 + poll for changes. 1.579 + 1.580 + The flag $Processed was set on the message 101 by another 1.581 + client... 1.582 + 1.583 + C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000) 1.584 + +FLAGS.SILENT ($Processed) 1.585 + S: * 100 FETCH (MODSEQ (303181230852)) 1.586 + S: * 101 FETCH (MODSEQ (303011130956) FLAGS ($Processed)) 1.587 + S: * 102 FETCH (MODSEQ (303181230852)) 1.588 + ... 1.589 + S: * 150 FETCH (MODSEQ (303181230852)) 1.590 + S: a106 OK [MODIFIED 101] Conditional STORE failed 1.591 + 1.592 + Or the flag hasn't changed, but another has (note that this server 1.593 + behaviour is discouraged. Server implementers should also see 1.594 + Section 5)... 1.595 + 1.596 + C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000) 1.597 + +FLAGS.SILENT ($Processed) 1.598 + S: * 100 FETCH (MODSEQ (303181230852)) 1.599 + S: * 101 FETCH (MODSEQ (303011130956) FLAGS (\Deleted \Answered)) 1.600 + S: * 102 FETCH (MODSEQ (303181230852)) 1.601 + ... 1.602 + S: * 150 FETCH (MODSEQ (303181230852)) 1.603 + S: a106 OK [MODIFIED 101] Conditional STORE failed 1.604 + 1.605 + ...and the client retries the operation for the message 101 with 1.606 + the updated UNCHANGEDSINCE value 1.607 + 1.608 + C: b108 STORE 101 (UNCHANGEDSINCE 303011130956) 1.609 + +FLAGS.SILENT ($Processed) 1.610 + S: * 101 FETCH (MODSEQ (303181230852)) 1.611 + S: b108 OK Conditional Store completed 1.612 + 1.613 + Or the flag hasn't changed, but another has (nice server 1.614 + behaviour. Server implementers should also see Section 5)... 1.615 + 1.616 + C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000) 1.617 + +FLAGS.SILENT ($Processed) 1.618 + 1.619 + 1.620 + 1.621 +Melnikov & Hole Standards Track [Page 11] 1.622 + 1.623 +RFC 4551 IMAP Extension for Conditional STORE June 2006 1.624 + 1.625 + 1.626 + S: * 100 FETCH (MODSEQ (303181230852)) 1.627 + S: * 101 FETCH (MODSEQ (303011130956) FLAGS ($Processed \Deleted 1.628 + \Answered)) 1.629 + S: * 102 FETCH (MODSEQ (303181230852)) 1.630 + ... 1.631 + S: * 150 FETCH (MODSEQ (303181230852)) 1.632 + S: a106 OK Conditional STORE completed 1.633 + 1.634 + Example 11: 1.635 + 1.636 + The following example is based on the example from the Section 1.637 + 4.2.3 of [RFC-2180] and demonstrates that the MODIFIED response 1.638 + code may be also returned in the tagged NO response. 1.639 + 1.640 + Client tries to conditionally STORE flags on a mixture of expunged 1.641 + and non-expunged messages; one message fails the UNCHANGEDSINCE 1.642 + test. 1.643 + 1.644 + C: B001 STORE 1:7 (UNCHANGEDSINCE 320172338) +FLAGS (\SEEN) 1.645 + S: * 1 FETCH (MODSEQ (320172342) FLAGS (\SEEN)) 1.646 + S: * 3 FETCH (MODSEQ (320172342) FLAGS (\SEEN)) 1.647 + S: B001 NO [MODIFIED 2] Some of the messages no longer exist. 1.648 + 1.649 + C: B002 NOOP 1.650 + S: * 4 EXPUNGE 1.651 + S: * 4 EXPUNGE 1.652 + S: * 4 EXPUNGE 1.653 + S: * 4 EXPUNGE 1.654 + S: * 2 FETCH (MODSEQ (320172340) FLAGS (\Deleted \Answered)) 1.655 + S: B002 OK NOOP Completed. 1.656 + 1.657 + By receiving FETCH responses for messages 1 and 3, and EXPUNGE 1.658 + responses that indicate that messages 4 through 7 have been 1.659 + expunged, the client retries the operation only for the message 2. 1.660 + The updated UNCHANGEDSINCE value is used. 1.661 + 1.662 + C: b003 STORE 2 (UNCHANGEDSINCE 320172340) +FLAGS (\Seen) 1.663 + S: * 2 FETCH (MODSEQ (320180050)) 1.664 + S: b003 OK Conditional Store completed 1.665 + 1.666 + Note: If a message is specified multiple times in the message set, 1.667 + and the server doesn't internally eliminate duplicates from the 1.668 + message set, it MUST NOT fail the conditional STORE operation for the 1.669 + second (or subsequent) occurrence of the message if the operation 1.670 + completed successfully for the first occurrence. For example, if the 1.671 + client specifies: 1.672 + 1.673 + 1.674 + 1.675 + 1.676 + 1.677 +Melnikov & Hole Standards Track [Page 12] 1.678 + 1.679 +RFC 4551 IMAP Extension for Conditional STORE June 2006 1.680 + 1.681 + 1.682 + e105 STORE 7,3:9 (UNCHANGEDSINCE 12121230045) 1.683 + +FLAGS.SILENT (\Deleted) 1.684 + 1.685 + the server must not fail the operation for message 7 as part of 1.686 + processing "3:9" if it succeeded when message 7 was processed the 1.687 + first time. 1.688 + 1.689 + Once the client specified the UNCHANGEDSINCE modifier in a STORE 1.690 + command, the server MUST include the MODSEQ fetch response data items 1.691 + in all subsequent unsolicited FETCH responses. 1.692 + 1.693 + This document also changes the behaviour of the server when it has 1.694 + performed a STORE or UID STORE command and the UNCHANGEDSINCE 1.695 + modifier is not specified. If the operation is successful for a 1.696 + message, the server MUST update the mod-sequence attribute of the 1.697 + message. The server is REQUIRED to include the mod-sequence value 1.698 + whenever it decides to send the unsolicited FETCH response to all 1.699 + CONDSTORE-aware clients that have opened the mailbox containing the 1.700 + message. 1.701 + 1.702 + Server implementers should also see Section 3.8 for additional 1.703 + quality of implementation issues related to the STORE command. 1.704 + 1.705 +3.3. FETCH and UID FETCH Commands 1.706 + 1.707 +3.3.1. CHANGEDSINCE FETCH Modifier 1.708 + 1.709 + This document defines the following FETCH modifier (see Section 2.4 1.710 + of [IMAPABNF]): 1.711 + 1.712 + CHANGEDSINCE <mod-sequence> 1.713 + 1.714 + CHANGEDSINCE FETCH modifier allows to create a further subset of 1.715 + the list of messages described by sequence set. The information 1.716 + described by message data items is only returned for messages that 1.717 + have mod-sequence bigger than <mod-sequence>. 1.718 + 1.719 + When CHANGEDSINCE FETCH modifier is specified, it implicitly adds 1.720 + MODSEQ FETCH message data item (Section 3.3.2). 1.721 + 1.722 + Example 12: 1.723 + 1.724 + C: s100 UID FETCH 1:* (FLAGS) (CHANGEDSINCE 12345) 1.725 + S: * 1 FETCH (UID 4 MODSEQ (65402) FLAGS (\Seen)) 1.726 + S: * 2 FETCH (UID 6 MODSEQ (75403) FLAGS (\Deleted)) 1.727 + S: * 4 FETCH (UID 8 MODSEQ (29738) FLAGS ($NoJunk $AutoJunk 1.728 + $MDNSent)) 1.729 + S: s100 OK FETCH completed 1.730 + 1.731 + 1.732 + 1.733 +Melnikov & Hole Standards Track [Page 13] 1.734 + 1.735 +RFC 4551 IMAP Extension for Conditional STORE June 2006 1.736 + 1.737 + 1.738 +3.3.2. MODSEQ Message Data Item in FETCH Command 1.739 + 1.740 + This extension adds a MODSEQ message data item to the FETCH command. 1.741 + The MODSEQ message data item allows clients to retrieve mod-sequence 1.742 + values for a range of messages in the currently selected mailbox. 1.743 + 1.744 + Once the client specified the MODSEQ message data item in a FETCH 1.745 + request, the server MUST include the MODSEQ fetch response data items 1.746 + in all subsequent unsolicited FETCH responses. 1.747 + 1.748 + Syntax: MODSEQ 1.749 + 1.750 + The MODSEQ message data item causes the server to return MODSEQ 1.751 + fetch response data items. 1.752 + 1.753 + Syntax: MODSEQ ( <permsg-modsequence> ) 1.754 + 1.755 + MODSEQ response data items contain per-message mod-sequences. 1.756 + 1.757 + The MODSEQ response data item is returned if the client issued 1.758 + FETCH with MODSEQ message data item. It also allows the server to 1.759 + notify the client about mod-sequence changes caused by conditional 1.760 + STOREs (Section 3.2) and/or changes caused by external sources. 1.761 + 1.762 + Example 13: 1.763 + 1.764 + C: a FETCH 1:3 (MODSEQ) 1.765 + S: * 1 FETCH (MODSEQ (624140003)) 1.766 + S: * 2 FETCH (MODSEQ (624140007)) 1.767 + S: * 3 FETCH (MODSEQ (624140005)) 1.768 + S: a OK Fetch complete 1.769 + 1.770 + In this example, the client requests per-message mod-sequences for 1.771 + a set of messages. 1.772 + 1.773 + When a flag for a message is modified in a different session, the 1.774 + server sends an unsolicited FETCH response containing the mod- 1.775 + sequence for the message. 1.776 + 1.777 + Example 14: 1.778 + 1.779 + (Session 1, authenticated as a user "alex"). The user adds a 1.780 + shared flag \Deleted: 1.781 + 1.782 + C: A142 SELECT INBOX 1.783 + ... 1.784 + S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 1.785 + S: * OK [PERMANENTFLAGS (\Answered \Deleted \Seen \*)] Limited 1.786 + 1.787 + 1.788 + 1.789 +Melnikov & Hole Standards Track [Page 14] 1.790 + 1.791 +RFC 4551 IMAP Extension for Conditional STORE June 2006 1.792 + 1.793 + 1.794 + ... 1.795 + 1.796 + C: A160 STORE 7 +FLAGS.SILENT (\Deleted) 1.797 + S: * 7 FETCH (MODSEQ (2121231000)) 1.798 + S: A160 OK Store completed 1.799 + 1.800 + (Session 2, also authenticated as the user "alex"). Any changes 1.801 + to flags are always reported to all sessions authenticated as the 1.802 + same user as in the session 1. 1.803 + 1.804 + C: C180 NOOP 1.805 + S: * 7 FETCH (FLAGS (\Deleted \Answered) MODSEQ (12121231000)) 1.806 + S: C180 OK Noop completed 1.807 + 1.808 + (Session 3, authenticated as a user "andrew"). As \Deleted is a 1.809 + shared flag, changes in session 1 are also reported in session 3: 1.810 + 1.811 + C: D210 NOOP 1.812 + S: * 7 FETCH (FLAGS (\Deleted \Answered) MODSEQ (12121231000)) 1.813 + S: D210 OK Noop completed 1.814 + 1.815 + The user modifies a private flag \Seen in session 1... 1.816 + 1.817 + C: A240 STORE 7 +FLAGS.SILENT (\Seen) 1.818 + S: * 7 FETCH (MODSEQ (12121231777)) 1.819 + S: A240 OK Store completed 1.820 + 1.821 + ...which is only reported in session 2... 1.822 + 1.823 + C: C270 NOOP 1.824 + S: * 7 FETCH (FLAGS (\Deleted \Answered \Seen) MODSEQ 1.825 + (12121231777)) 1.826 + S: C270 OK Noop completed 1.827 + 1.828 + ...but not in session 3. 1.829 + 1.830 + C: D300 NOOP 1.831 + S: D300 OK Noop completed 1.832 + 1.833 + And finally, the user removes flags \Answered (shared) and \Seen 1.834 + (private) in session 1. 1.835 + 1.836 + C: A330 STORE 7 -FLAGS.SILENT (\Answered \Seen) 1.837 + S: * 7 FETCH (MODSEQ (12121245160)) 1.838 + S: A330 OK Store completed 1.839 + 1.840 + 1.841 + 1.842 + 1.843 + 1.844 + 1.845 +Melnikov & Hole Standards Track [Page 15] 1.846 + 1.847 +RFC 4551 IMAP Extension for Conditional STORE June 2006 1.848 + 1.849 + 1.850 + Both changes are reported in the session 2... 1.851 + 1.852 + C: C360 NOOP 1.853 + S: * 7 FETCH (FLAGS (\Deleted) MODSEQ (12121245160)) 1.854 + S: C360 OK Noop completed 1.855 + 1.856 + ...and only changes to shared flags are reported in session 3. 1.857 + 1.858 + C: D390 NOOP 1.859 + S: * 7 FETCH (FLAGS (\Deleted) MODSEQ (12121245160)) 1.860 + S: D390 OK Noop completed 1.861 + 1.862 + Server implementers should also see Section 3.8 for additional 1.863 + quality of implementation issues related to the FETCH command. 1.864 + 1.865 +3.4. MODSEQ Search Criterion in SEARCH 1.866 + 1.867 + The MODSEQ criterion for the SEARCH command allows a client to search 1.868 + for the metadata items that were modified since a specified moment. 1.869 + 1.870 + Syntax: MODSEQ [<entry-name> <entry-type-req>] <mod-sequence-valzer> 1.871 + 1.872 + Messages that have modification values that are equal to or 1.873 + greater than <mod-sequence-valzer>. This allows a client, for 1.874 + example, to find out which messages contain metadata items that 1.875 + have changed since the last time it updated its disconnected 1.876 + cache. The client may also specify <entry-name> (name of metadata 1.877 + item) and <entry-type-req> (type of metadata item) before 1.878 + <mod-sequence-valzer>. <entry-type-req> can be one of "shared", 1.879 + "priv" (private), or "all". The latter means that the server 1.880 + should use the biggest value among "priv" and "shared" mod- 1.881 + sequences for the metadata item. If the server doesn't store 1.882 + internally separate mod-sequences for different metadata items, it 1.883 + MUST ignore <entry-name> and <entry-type-req>. Otherwise, the 1.884 + server should use them to narrow down the search. 1.885 + 1.886 + For a flag <flagname>, the corresponding <entry-name> has a form 1.887 + "/flags/<flagname>" as defined in [IMAPABNF]. Note that the 1.888 + leading "\" character that denotes a system flag has to be escaped 1.889 + as per Section 4.3 of [IMAP4], as the <entry-name> uses syntax for 1.890 + quoted strings. 1.891 + 1.892 + If client specifies a MODSEQ criterion in a SEARCH command and the 1.893 + server returns a non-empty SEARCH result, the server MUST also append 1.894 + (to the end of the untagged SEARCH response) the highest mod-sequence 1.895 + for all messages being returned. See also Section 3.5. 1.896 + 1.897 + 1.898 + 1.899 + 1.900 + 1.901 +Melnikov & Hole Standards Track [Page 16] 1.902 + 1.903 +RFC 4551 IMAP Extension for Conditional STORE June 2006 1.904 + 1.905 + 1.906 + Example 15: 1.907 + 1.908 + C: a SEARCH MODSEQ "/flags/\\draft" all 620162338 1.909 + S: * SEARCH 2 5 6 7 11 12 18 19 20 23 (MODSEQ 917162500) 1.910 + S: a OK Search complete 1.911 + 1.912 + In the above example, the message numbers of any messages 1.913 + containing the string "IMAP4" in the "value" attribute of the 1.914 + "/comment" entry and having a mod-sequence equal to or greater 1.915 + than 620162338 for the "\Draft" flag are returned in the search 1.916 + results. 1.917 + 1.918 + Example 16: 1.919 + 1.920 + C: t SEARCH OR NOT MODSEQ 720162338 LARGER 50000 1.921 + S: * SEARCH 1.922 + S: t OK Search complete, nothing found 1.923 + 1.924 +3.5. Modified SEARCH Untagged Response 1.925 + 1.926 + Data: zero or more numbers 1.927 + mod-sequence value (omitted if no match) 1.928 + 1.929 + This document extends syntax of the untagged SEARCH response to 1.930 + include the highest mod-sequence for all messages being returned. 1.931 + 1.932 + If a client specifies a MODSEQ criterion in a SEARCH (or UID SEARCH) 1.933 + command and the server returns a non-empty SEARCH result, the server 1.934 + MUST also append (to the end of the untagged SEARCH response) the 1.935 + highest mod-sequence for all messages being returned. See Section 1.936 + 3.4 for examples. 1.937 + 1.938 +3.6. HIGHESTMODSEQ Status Data Items 1.939 + 1.940 + This document defines a new status data item: 1.941 + 1.942 + HIGHESTMODSEQ 1.943 + 1.944 + The highest mod-sequence value of all messages in the mailbox. 1.945 + This is the same value that is returned by the server in the 1.946 + HIGHESTMODSEQ response code in an OK untagged response (see 1.947 + Section 3.1.1). If the server doesn't support the persistent 1.948 + storage of mod-sequences for the mailbox (see Section 3.1.2), the 1.949 + server MUST return 0 as the value of HIGHESTMODSEQ status data 1.950 + item. 1.951 + 1.952 + 1.953 + 1.954 + 1.955 + 1.956 + 1.957 +Melnikov & Hole Standards Track [Page 17] 1.958 + 1.959 +RFC 4551 IMAP Extension for Conditional STORE June 2006 1.960 + 1.961 + 1.962 + Example 17: 1.963 + 1.964 + C: A042 STATUS blurdybloop (UIDNEXT MESSAGES HIGHESTMODSEQ) 1.965 + S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292 1.966 + HIGHESTMODSEQ 7011231777) 1.967 + S: A042 OK STATUS completed 1.968 + 1.969 +3.7. CONDSTORE Parameter to SELECT and EXAMINE 1.970 + 1.971 + The CONDSTORE extension defines a single optional select parameter, 1.972 + "CONDSTORE", which tells the server that it MUST include the MODSEQ 1.973 + fetch response data items in all subsequent unsolicited FETCH 1.974 + responses. 1.975 + 1.976 + The CONDSTORE parameter to SELECT/EXAMINE helps avoid a race 1.977 + condition that might arise when one or more metadata items are 1.978 + modified in another session after the server has sent the 1.979 + HIGHESTMODSEQ response code and before the client was able to issue a 1.980 + CONDSTORE enabling command. 1.981 + 1.982 + Example 18: 1.983 + 1.984 + C: A142 SELECT INBOX (CONDSTORE) 1.985 + S: * 172 EXISTS 1.986 + S: * 1 RECENT 1.987 + S: * OK [UNSEEN 12] Message 12 is first unseen 1.988 + S: * OK [UIDVALIDITY 3857529045] UIDs valid 1.989 + S: * OK [UIDNEXT 4392] Predicted next UID 1.990 + S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 1.991 + S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited 1.992 + S: * OK [HIGHESTMODSEQ 715194045007] 1.993 + S: A142 OK [READ-WRITE] SELECT completed, CONDSTORE is now enabled 1.994 + 1.995 +3.8. Additional Quality-of-Implementation Issues 1.996 + 1.997 + Server implementations should follow the following rule, which 1.998 + applies to any successfully completed STORE/UID STORE (with and 1.999 + without UNCHANGEDSINCE modifier), as well as to a FETCH command that 1.1000 + implicitly sets \Seen flag: 1.1001 + 1.1002 + Adding the flag when it is already present or removing when it is 1.1003 + not present SHOULD NOT change the mod-sequence. 1.1004 + 1.1005 + This will prevent spurious client synchronization requests. 1.1006 + 1.1007 + 1.1008 + 1.1009 + 1.1010 + 1.1011 + 1.1012 + 1.1013 +Melnikov & Hole Standards Track [Page 18] 1.1014 + 1.1015 +RFC 4551 IMAP Extension for Conditional STORE June 2006 1.1016 + 1.1017 + 1.1018 + However, note that client implementers MUST NOT rely on this server 1.1019 + behavior. A client can't distinguish between the case when a server 1.1020 + has violated the SHOULD mentioned above, and that when one or more 1.1021 + clients set and unset (or unset and set) the flag in another session. 1.1022 + 1.1023 +4. Formal Syntax 1.1024 + 1.1025 + The following syntax specification uses the Augmented Backus-Naur 1.1026 + Form (ABNF) [ABNF] notation. Elements not defined here can be found 1.1027 + in the formal syntax of the ABNF [ABNF], IMAP [IMAP4], and IMAP ABNF 1.1028 + extensions [IMAPABNF] specifications. 1.1029 + 1.1030 + Except as noted otherwise, all alphabetic characters are case- 1.1031 + insensitive. The use of upper- or lowercase characters to define 1.1032 + token strings is for editorial clarity only. Implementations MUST 1.1033 + accept these strings in a case-insensitive fashion. 1.1034 + 1.1035 + capability =/ "CONDSTORE" 1.1036 + 1.1037 + status-att =/ "HIGHESTMODSEQ" 1.1038 + ;; extends non-terminal defined in RFC 3501. 1.1039 + 1.1040 + status-att-val =/ "HIGHESTMODSEQ" SP mod-sequence-valzer 1.1041 + ;; extends non-terminal defined in [IMAPABNF]. 1.1042 + ;; Value 0 denotes that the mailbox doesn't 1.1043 + ;; support persistent mod-sequences 1.1044 + ;; as described in Section 3.1.2 1.1045 + 1.1046 + store-modifier =/ "UNCHANGEDSINCE" SP mod-sequence-valzer 1.1047 + ;; Only a single "UNCHANGEDSINCE" may be 1.1048 + ;; specified in a STORE operation 1.1049 + 1.1050 + fetch-modifier =/ chgsince-fetch-mod 1.1051 + ;; conforms to the generic "fetch-modifier" 1.1052 + ;; syntax defined in [IMAPABNF]. 1.1053 + 1.1054 + chgsince-fetch-mod = "CHANGEDSINCE" SP mod-sequence-value 1.1055 + ;; CHANGEDSINCE FETCH modifier conforms to 1.1056 + ;; the fetch-modifier syntax 1.1057 + 1.1058 + fetch-att =/ fetch-mod-sequence 1.1059 + ;; modifies original IMAP4 fetch-att 1.1060 + 1.1061 + fetch-mod-sequence = "MODSEQ" 1.1062 + 1.1063 + fetch-mod-resp = "MODSEQ" SP "(" permsg-modsequence ")" 1.1064 + 1.1065 + msg-att-dynamic =/ fetch-mod-resp 1.1066 + 1.1067 + 1.1068 + 1.1069 +Melnikov & Hole Standards Track [Page 19] 1.1070 + 1.1071 +RFC 4551 IMAP Extension for Conditional STORE June 2006 1.1072 + 1.1073 + 1.1074 + search-key =/ search-modsequence 1.1075 + ;; modifies original IMAP4 search-key 1.1076 + ;; 1.1077 + ;; This change applies to all commands 1.1078 + ;; referencing this non-terminal, in 1.1079 + ;; particular SEARCH. 1.1080 + 1.1081 + search-modsequence = "MODSEQ" [search-modseq-ext] SP 1.1082 + mod-sequence-valzer 1.1083 + 1.1084 + search-modseq-ext = SP entry-name SP entry-type-req 1.1085 + 1.1086 + resp-text-code =/ "HIGHESTMODSEQ" SP mod-sequence-value / 1.1087 + "NOMODSEQ" / 1.1088 + "MODIFIED" SP set 1.1089 + 1.1090 + entry-name = entry-flag-name 1.1091 + 1.1092 + entry-flag-name = DQUOTE "/flags/" attr-flag DQUOTE 1.1093 + ;; each system or user defined flag <flag> 1.1094 + ;; is mapped to "/flags/<flag>". 1.1095 + ;; 1.1096 + ;; <entry-flag-name> follows the escape rules 1.1097 + ;; used by "quoted" string as described in 1.1098 + ;; Section 4.3 of [IMAP4], e.g., for the flag 1.1099 + ;; \Seen the corresponding <entry-name> is 1.1100 + ;; "/flags/\\seen", and for the flag 1.1101 + ;; $MDNSent, the corresponding <entry-name> 1.1102 + ;; is "/flags/$mdnsent". 1.1103 + 1.1104 + entry-type-resp = "priv" / "shared" 1.1105 + ;; metadata item type 1.1106 + 1.1107 + entry-type-req = entry-type-resp / "all" 1.1108 + ;; perform SEARCH operation on private 1.1109 + ;; metadata item, shared metadata item or both 1.1110 + 1.1111 + permsg-modsequence = mod-sequence-value 1.1112 + ;; per message mod-sequence 1.1113 + 1.1114 + mod-sequence-value = 1*DIGIT 1.1115 + ;; Positive unsigned 64-bit integer 1.1116 + ;; (mod-sequence) 1.1117 + ;; (1 <= n < 18,446,744,073,709,551,615) 1.1118 + 1.1119 + mod-sequence-valzer = "0" / mod-sequence-value 1.1120 + 1.1121 + search-sort-mod-seq = "(" "MODSEQ" SP mod-sequence-value ")" 1.1122 + 1.1123 + 1.1124 + 1.1125 +Melnikov & Hole Standards Track [Page 20] 1.1126 + 1.1127 +RFC 4551 IMAP Extension for Conditional STORE June 2006 1.1128 + 1.1129 + 1.1130 + select-param =/ condstore-param 1.1131 + ;; conforms to the generic "select-param" 1.1132 + ;; non-terminal syntax defined in [IMAPABNF]. 1.1133 + 1.1134 + condstore-param = "CONDSTORE" 1.1135 + 1.1136 + mailbox-data =/ "SEARCH" [1*(SP nz-number) SP 1.1137 + search-sort-mod-seq] 1.1138 + 1.1139 + attr-flag = "\\Answered" / "\\Flagged" / "\\Deleted" / 1.1140 + "\\Seen" / "\\Draft" / attr-flag-keyword / 1.1141 + attr-flag-extension 1.1142 + ;; Does not include "\\Recent" 1.1143 + 1.1144 + attr-flag-extension = "\\" atom 1.1145 + ;; Future expansion. Client implementations 1.1146 + ;; MUST accept flag-extension flags. Server 1.1147 + ;; implementations MUST NOT generate 1.1148 + ;; flag-extension flags except as defined by 1.1149 + ;; future standard or standards-track 1.1150 + ;; revisions of [IMAP4]. 1.1151 + 1.1152 + attr-flag-keyword = atom 1.1153 + 1.1154 +5. Server Implementation Considerations 1.1155 + 1.1156 + This section describes how a server implementation that doesn't store 1.1157 + separate per-metadata mod-sequences for different metadata items can 1.1158 + avoid sending the MODIFIED response to any of the following 1.1159 + conditional STORE operations: 1.1160 + 1.1161 + +FLAGS 1.1162 + -FLAGS 1.1163 + +FLAGS.SILENT 1.1164 + -FLAGS.SILENT 1.1165 + 1.1166 + Note that the optimization described in this section can't be 1.1167 + performed in case of a conditional STORE FLAGS operation. 1.1168 + 1.1169 + Let's use the following example. The client has issued 1.1170 + 1.1171 + C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000) 1.1172 + +FLAGS.SILENT ($Processed) 1.1173 + 1.1174 + When the server receives the command and parses it successfully, it 1.1175 + iterates through the message set and tries to execute the conditional 1.1176 + STORE command for each message. 1.1177 + 1.1178 + 1.1179 + 1.1180 + 1.1181 +Melnikov & Hole Standards Track [Page 21] 1.1182 + 1.1183 +RFC 4551 IMAP Extension for Conditional STORE June 2006 1.1184 + 1.1185 + 1.1186 + Each server internally works as a client, i.e., it has to cache the 1.1187 + current state of all IMAP flags as it is known to the client. In 1.1188 + order to report flag changes to the client, the server compares the 1.1189 + cached values with the values in its database for IMAP flags. 1.1190 + 1.1191 + Imagine that another client has changed the state of a flag \Deleted 1.1192 + on the message 101 and that the change updated the mod-sequence for 1.1193 + the message. The server knows that the mod-sequence for the mailbox 1.1194 + has changed; however, it also knows that: 1.1195 + 1.1196 + a) the client is not interested in \Deleted flag, as it hasn't 1.1197 + included it in +FLAGS.SILENT operation; and 1.1198 + 1.1199 + b) the state of the flag $Processed hasn't changed (the server can 1.1200 + determine this by comparing cached flag state with the state of 1.1201 + the flag in the database). 1.1202 + 1.1203 + Therefore, the server doesn't have to report MODIFIED to the client. 1.1204 + Instead, the server may set $Processed flag, update the mod-sequence 1.1205 + for the message 101 once again and send an untagged FETCH response 1.1206 + with new mod-sequence and flags: 1.1207 + 1.1208 + S: * 101 FETCH (MODSEQ (303011130956) 1.1209 + FLAGS ($Processed \Deleted \Answered)) 1.1210 + 1.1211 + See also Section 3.8 for additional quality-of-implementation issues. 1.1212 + 1.1213 +6. Security Considerations 1.1214 + 1.1215 + It is believed that the Conditional STORE extension doesn't raise any 1.1216 + new security concerns that are not already discussed in [IMAP4]. 1.1217 + However, the availability of this extension may make it possible for 1.1218 + IMAP4 to be used in critical applications it could not be used for 1.1219 + previously, making correct IMAP server implementation and operation 1.1220 + even more important. 1.1221 + 1.1222 +7. IANA Considerations 1.1223 + 1.1224 + IMAP4 capabilities are registered by publishing a standards track or 1.1225 + IESG approved experimental RFC. The registry is currently located 1.1226 + at: 1.1227 + 1.1228 + http://www.iana.org/assignments/imap4-capabilities 1.1229 + 1.1230 + This document defines the CONDSTORE IMAP capability. IANA has added 1.1231 + it to the registry accordingly. 1.1232 + 1.1233 + 1.1234 + 1.1235 + 1.1236 + 1.1237 +Melnikov & Hole Standards Track [Page 22] 1.1238 + 1.1239 +RFC 4551 IMAP Extension for Conditional STORE June 2006 1.1240 + 1.1241 + 1.1242 +8. References 1.1243 + 1.1244 +8.1. Normative References 1.1245 + 1.1246 + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 1.1247 + Requirement Levels", BCP 14, RFC 2119, March 1997. 1.1248 + 1.1249 + [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1.1250 + Specifications: ABNF", RFC 4234, October 2005. 1.1251 + 1.1252 + [IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1.1253 + 4rev1", RFC 3501, March 2003. 1.1254 + 1.1255 + [IMAPABNF] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 1.1256 + ABNF", RFC 4466, April 2006. 1.1257 + 1.1258 +8.2. Informative References 1.1259 + 1.1260 + [ACAP] Newman, C. and J. Myers, "ACAP -- Application 1.1261 + Configuration Access Protocol", RFC 2244, November 1997. 1.1262 + 1.1263 + [ACL] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", 1.1264 + RFC 4314, December 2005. 1.1265 + 1.1266 + [ANN] Daboo, C. and R. Gellens, "IMAP ANNOTATE Extension", Work 1.1267 + in Progress, March 2006. 1.1268 + 1.1269 + [NTP] Mills, D., "Network Time Protocol (Version 3) 1.1270 + Specification, Implementation and Analysis", RFC 1305, 1.1271 + March 1992. 1.1272 + 1.1273 + [RFC-2180] Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC 1.1274 + 2180, July 1997. 1.1275 + 1.1276 +9. Acknowledgements 1.1277 + 1.1278 + Some text was borrowed from "IMAP ANNOTATE Extension" [ANN] by 1.1279 + Randall Gellens and Cyrus Daboo and from "ACAP -- Application 1.1280 + Configuration Access Protocol" [ACAP] by Chris Newman and John Myers. 1.1281 + 1.1282 + Many thanks to Randall Gellens for his thorough review of the 1.1283 + document. 1.1284 + 1.1285 + The authors also acknowledge the feedback provided by Cyrus Daboo, 1.1286 + Larry Greenfield, Chris Newman, Harrie Hazewinkel, Arnt Gulbrandsen, 1.1287 + Timo Sirainen, Mark Crispin, Ned Freed, Ken Murchison, and Dave 1.1288 + Cridland. 1.1289 + 1.1290 + 1.1291 + 1.1292 + 1.1293 +Melnikov & Hole Standards Track [Page 23] 1.1294 + 1.1295 +RFC 4551 IMAP Extension for Conditional STORE June 2006 1.1296 + 1.1297 + 1.1298 +Authors' Addresses 1.1299 + 1.1300 + Alexey Melnikov 1.1301 + Isode Limited 1.1302 + 5 Castle Business Village 1.1303 + 36 Station Road 1.1304 + Hampton, Middlesex 1.1305 + TW12 2BX, 1.1306 + United Kingdom 1.1307 + 1.1308 + EMail: Alexey.Melnikov@isode.com 1.1309 + 1.1310 + 1.1311 + Steve Hole 1.1312 + ACI WorldWide/MessagingDirect 1.1313 + #1807, 10088 102 Ave 1.1314 + Edmonton, AB 1.1315 + T5J 2Z1 1.1316 + Canada 1.1317 + 1.1318 + EMail: Steve.Hole@messagingdirect.com 1.1319 + 1.1320 + 1.1321 + 1.1322 + 1.1323 + 1.1324 + 1.1325 + 1.1326 + 1.1327 + 1.1328 + 1.1329 + 1.1330 + 1.1331 + 1.1332 + 1.1333 + 1.1334 + 1.1335 + 1.1336 + 1.1337 + 1.1338 + 1.1339 + 1.1340 + 1.1341 + 1.1342 + 1.1343 + 1.1344 + 1.1345 + 1.1346 + 1.1347 + 1.1348 + 1.1349 +Melnikov & Hole Standards Track [Page 24] 1.1350 + 1.1351 +RFC 4551 IMAP Extension for Conditional STORE June 2006 1.1352 + 1.1353 + 1.1354 +Full Copyright Statement 1.1355 + 1.1356 + Copyright (C) The Internet Society (2006). 1.1357 + 1.1358 + This document is subject to the rights, licenses and restrictions 1.1359 + contained in BCP 78, and except as set forth therein, the authors 1.1360 + retain all their rights. 1.1361 + 1.1362 + This document and the information contained herein are provided on an 1.1363 + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1.1364 + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1.1365 + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1.1366 + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1.1367 + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1.1368 + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1.1369 + 1.1370 +Intellectual Property 1.1371 + 1.1372 + The IETF takes no position regarding the validity or scope of any 1.1373 + Intellectual Property Rights or other rights that might be claimed to 1.1374 + pertain to the implementation or use of the technology described in 1.1375 + this document or the extent to which any license under such rights 1.1376 + might or might not be available; nor does it represent that it has 1.1377 + made any independent effort to identify any such rights. Information 1.1378 + on the procedures with respect to rights in RFC documents can be 1.1379 + found in BCP 78 and BCP 79. 1.1380 + 1.1381 + Copies of IPR disclosures made to the IETF Secretariat and any 1.1382 + assurances of licenses to be made available, or the result of an 1.1383 + attempt made to obtain a general license or permission for the use of 1.1384 + such proprietary rights by implementers or users of this 1.1385 + specification can be obtained from the IETF on-line IPR repository at 1.1386 + http://www.ietf.org/ipr. 1.1387 + 1.1388 + The IETF invites any interested party to bring to its attention any 1.1389 + copyrights, patents or patent applications, or other proprietary 1.1390 + rights that may cover technology that may be required to implement 1.1391 + this standard. Please address the information to the IETF at 1.1392 + ietf-ipr@ietf.org. 1.1393 + 1.1394 +Acknowledgement 1.1395 + 1.1396 + Funding for the RFC Editor function is provided by the IETF 1.1397 + Administrative Support Activity (IASA). 1.1398 + 1.1399 + 1.1400 + 1.1401 + 1.1402 + 1.1403 + 1.1404 + 1.1405 +Melnikov & Hole Standards Track [Page 25] 1.1406 +