imapext-2007

annotate docs/rfc/rfc4551.txt @ 0:ada5e610ab86

find changesets by author, revision, files, or words in the commit message
imap-2007e
author yuuji@gentei.org
date Mon, 14 Sep 2009 15:17:45 +0900
parents
children
rev   line source
yuuji@0 1
yuuji@0 2
yuuji@0 3
yuuji@0 4
yuuji@0 5
yuuji@0 6
yuuji@0 7 Network Working Group A. Melnikov
yuuji@0 8 Request for Comments: 4551 Isode Ltd.
yuuji@0 9 Updates: 3501 S. Hole
yuuji@0 10 Category: Standards Track ACI WorldWide/MessagingDirect
yuuji@0 11 June 2006
yuuji@0 12
yuuji@0 13
yuuji@0 14 IMAP Extension for Conditional STORE Operation
yuuji@0 15 or Quick Flag Changes Resynchronization
yuuji@0 16
yuuji@0 17 Status of This Memo
yuuji@0 18
yuuji@0 19 This document specifies an Internet standards track protocol for the
yuuji@0 20 Internet community, and requests discussion and suggestions for
yuuji@0 21 improvements. Please refer to the current edition of the "Internet
yuuji@0 22 Official Protocol Standards" (STD 1) for the standardization state
yuuji@0 23 and status of this protocol. Distribution of this memo is unlimited.
yuuji@0 24
yuuji@0 25 Copyright Notice
yuuji@0 26
yuuji@0 27 Copyright (C) The Internet Society (2006).
yuuji@0 28
yuuji@0 29 Abstract
yuuji@0 30
yuuji@0 31 Often, multiple IMAP (RFC 3501) clients need to coordinate changes to
yuuji@0 32 a common IMAP mailbox. Examples include different clients working on
yuuji@0 33 behalf of the same user, and multiple users accessing shared
yuuji@0 34 mailboxes. These clients need a mechanism to synchronize state
yuuji@0 35 changes for messages within the mailbox. They must be able to
yuuji@0 36 guarantee that only one client can change message state (e.g.,
yuuji@0 37 message flags) at any time. An example of such an application is use
yuuji@0 38 of an IMAP mailbox as a message queue with multiple dequeueing
yuuji@0 39 clients.
yuuji@0 40
yuuji@0 41 The Conditional Store facility provides a protected update mechanism
yuuji@0 42 for message state information that can detect and resolve conflicts
yuuji@0 43 between multiple writing mail clients.
yuuji@0 44
yuuji@0 45 The Conditional Store facility also allows a client to quickly
yuuji@0 46 resynchronize mailbox flag changes.
yuuji@0 47
yuuji@0 48 This document defines an extension to IMAP (RFC 3501).
yuuji@0 49
yuuji@0 50
yuuji@0 51
yuuji@0 52
yuuji@0 53
yuuji@0 54
yuuji@0 55
yuuji@0 56
yuuji@0 57
yuuji@0 58 Melnikov & Hole Standards Track [Page 1]
yuuji@0 59
yuuji@0 60 RFC 4551 IMAP Extension for Conditional STORE June 2006
yuuji@0 61
yuuji@0 62
yuuji@0 63 Table of Contents
yuuji@0 64
yuuji@0 65 1. Introduction and Overview ................................. 3
yuuji@0 66 2. Conventions Used in This Document ......................... 5
yuuji@0 67 3. IMAP Protocol Changes ..................................... 6
yuuji@0 68 3.1. New OK untagged responses for SELECT and EXAMINE ......... 6
yuuji@0 69 3.1.1. HIGHESTMODSEQ response code ............................ 6
yuuji@0 70 3.1.2. NOMODSEQ response code ................................. 7
yuuji@0 71 3.2. STORE and UID STORE Commands ............................. 7
yuuji@0 72 3.3 FETCH and UID FETCH Commands ..............................13
yuuji@0 73 3.3.1. CHANGEDSINCE FETCH modifier ............................13
yuuji@0 74 3.3.2. MODSEQ message data item in FETCH Command ..............14
yuuji@0 75 3.4. MODSEQ search criterion in SEARCH ........................16
yuuji@0 76 3.5. Modified SEARCH untagged response ........................17
yuuji@0 77 3.6. HIGHESTMODSEQ status data items ..........................17
yuuji@0 78 3.7. CONDSTORE parameter to SELECT and EXAMINE ................18
yuuji@0 79 3.8. Additional quality of implementation issues ..............18
yuuji@0 80 4. Formal Syntax .............................................19
yuuji@0 81 5. Server implementation considerations ......................21
yuuji@0 82 6. Security Considerations ...................................22
yuuji@0 83 7. IANA Considerations .......................................22
yuuji@0 84 8. References ................................................23
yuuji@0 85 8.1. Normative References .....................................23
yuuji@0 86 8.2. Informative References ...................................23
yuuji@0 87 9. Acknowledgements ..........................................23
yuuji@0 88
yuuji@0 89
yuuji@0 90
yuuji@0 91
yuuji@0 92
yuuji@0 93
yuuji@0 94
yuuji@0 95
yuuji@0 96
yuuji@0 97
yuuji@0 98
yuuji@0 99
yuuji@0 100
yuuji@0 101
yuuji@0 102
yuuji@0 103
yuuji@0 104
yuuji@0 105
yuuji@0 106
yuuji@0 107
yuuji@0 108
yuuji@0 109
yuuji@0 110
yuuji@0 111
yuuji@0 112
yuuji@0 113
yuuji@0 114 Melnikov & Hole Standards Track [Page 2]
yuuji@0 115
yuuji@0 116 RFC 4551 IMAP Extension for Conditional STORE June 2006
yuuji@0 117
yuuji@0 118
yuuji@0 119 1. Introduction and Overview
yuuji@0 120
yuuji@0 121 The Conditional STORE extension is present in any IMAP4
yuuji@0 122 implementation that returns "CONDSTORE" as one of the supported
yuuji@0 123 capabilities in the CAPABILITY command response.
yuuji@0 124
yuuji@0 125 An IMAP server that supports this extension MUST associate a positive
yuuji@0 126 unsigned 64-bit value called a modification sequence (mod-sequence)
yuuji@0 127 with every IMAP message. This is an opaque value updated by the
yuuji@0 128 server whenever a metadata item is modified. The server MUST
yuuji@0 129 guarantee that each STORE command performed on the same mailbox
yuuji@0 130 (including simultaneous stores to different metadata items from
yuuji@0 131 different connections) will get a different mod-sequence value.
yuuji@0 132 Also, for any two successful STORE operations performed in the same
yuuji@0 133 session on the same mailbox, the mod-sequence of the second completed
yuuji@0 134 operation MUST be greater than the mod-sequence of the first
yuuji@0 135 completed. Note that the latter rule disallows the use of the system
yuuji@0 136 clock as a mod-sequence, because if system time changes (e.g., an NTP
yuuji@0 137 [NTP] client adjusting the time), the next generated value might be
yuuji@0 138 less than the previous one.
yuuji@0 139
yuuji@0 140 Mod-sequences allow a client that supports the CONDSTORE extension to
yuuji@0 141 determine if a message metadata has changed since some known moment.
yuuji@0 142 Whenever the state of a flag changes (i.e., the flag is added where
yuuji@0 143 previously it wasn't set, or the flag is removed and before it was
yuuji@0 144 set) the value of the modification sequence for the message MUST be
yuuji@0 145 updated. Adding the flag when it is already present or removing when
yuuji@0 146 it is not present SHOULD NOT change the mod-sequence.
yuuji@0 147
yuuji@0 148 When a message is appended to a mailbox (via the IMAP APPEND command,
yuuji@0 149 COPY to the mailbox, or using an external mechanism) the server
yuuji@0 150 generates a new modification sequence that is higher than the highest
yuuji@0 151 modification sequence of all messages in the mailbox and assigns it
yuuji@0 152 to the appended message.
yuuji@0 153
yuuji@0 154 The server MAY store separate (per-message) modification sequence
yuuji@0 155 values for different metadata items. If the server does so, per-
yuuji@0 156 message mod-sequence is the highest mod-sequence of all metadata
yuuji@0 157 items for the specified message.
yuuji@0 158
yuuji@0 159 The server that supports this extension is not required to be able to
yuuji@0 160 store mod-sequences for every available mailbox. Section 3.1.2
yuuji@0 161 describes how the server may act if a particular mailbox doesn't
yuuji@0 162 support the persistent storage of mod-sequences.
yuuji@0 163
yuuji@0 164
yuuji@0 165
yuuji@0 166
yuuji@0 167
yuuji@0 168
yuuji@0 169
yuuji@0 170 Melnikov & Hole Standards Track [Page 3]
yuuji@0 171
yuuji@0 172 RFC 4551 IMAP Extension for Conditional STORE June 2006
yuuji@0 173
yuuji@0 174
yuuji@0 175 This extension makes the following changes to the IMAP4 protocol:
yuuji@0 176
yuuji@0 177 a) adds UNCHANGEDSINCE STORE modifier.
yuuji@0 178
yuuji@0 179 b) adds the MODIFIED response code which should be used with an OK
yuuji@0 180 response to the STORE command. (It can also be used in a NO
yuuji@0 181 response.)
yuuji@0 182
yuuji@0 183 c) adds a new MODSEQ message data item for use with the FETCH
yuuji@0 184 command.
yuuji@0 185
yuuji@0 186 d) adds CHANGEDSINCE FETCH modifier.
yuuji@0 187
yuuji@0 188 e) adds a new MODSEQ search criterion.
yuuji@0 189
yuuji@0 190 f) extends the syntax of untagged SEARCH responses to include
yuuji@0 191 mod-sequence.
yuuji@0 192
yuuji@0 193 g) adds new OK untagged responses for the SELECT and EXAMINE
yuuji@0 194 commands.
yuuji@0 195
yuuji@0 196 h) defines an additional parameter to SELECT/EXAMINE commands.
yuuji@0 197
yuuji@0 198 i) adds the HIGHESTMODSEQ status data item to the STATUS command.
yuuji@0 199
yuuji@0 200 A client supporting CONDSTORE extension indicates its willingness to
yuuji@0 201 receive mod-sequence updates in all untagged FETCH responses by
yuuji@0 202 issuing:
yuuji@0 203
yuuji@0 204 - a SELECT or EXAMINE command with the CONDSTORE parameter,
yuuji@0 205 - a STATUS (HIGHESTMODSEQ) command,
yuuji@0 206 - a FETCH or SEARCH command that includes the MODSEQ message data
yuuji@0 207 item,
yuuji@0 208 - a FETCH command with the CHANGEDSINCE modifier, or
yuuji@0 209 - a STORE command with the UNCHANGEDSINCE modifier.
yuuji@0 210
yuuji@0 211 The server MUST include mod-sequence data in all subsequent untagged
yuuji@0 212 FETCH responses (until the connection is closed), whether they were
yuuji@0 213 caused by a regular STORE, a STORE with UNCHANGEDSINCE modifier, or
yuuji@0 214 an external agent.
yuuji@0 215
yuuji@0 216 This document uses the term "CONDSTORE-aware client" to refer to a
yuuji@0 217 client that announces its willingness to receive mod-sequence updates
yuuji@0 218 as described above. The term "CONDSTORE enabling command" will refer
yuuji@0 219 any of the commands listed above. A future extension to this
yuuji@0 220 document may extend the list of CONDSTORE enabling commands. A first
yuuji@0 221 CONDSTORE enabling command executed in the session MUST cause the
yuuji@0 222
yuuji@0 223
yuuji@0 224
yuuji@0 225
yuuji@0 226 Melnikov & Hole Standards Track [Page 4]
yuuji@0 227
yuuji@0 228 RFC 4551 IMAP Extension for Conditional STORE June 2006
yuuji@0 229
yuuji@0 230
yuuji@0 231 server to return HIGHESTMODSEQ (Section 3.1.1) unless the server has
yuuji@0 232 sent NOMODSEQ (Section 3.1.2) response code when the currently
yuuji@0 233 selected mailbox was selected.
yuuji@0 234
yuuji@0 235 The rest of this document describes the protocol changes more
yuuji@0 236 rigorously.
yuuji@0 237
yuuji@0 238 2. Conventions Used in This Document
yuuji@0 239
yuuji@0 240 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
yuuji@0 241 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
yuuji@0 242 document are to be interpreted as described in RFC 2119 [KEYWORDS].
yuuji@0 243
yuuji@0 244 In examples, lines beginning with "S:" are sent by the IMAP server,
yuuji@0 245 and lines beginning with "C:" are sent by the client. Line breaks
yuuji@0 246 may appear in example commands solely for editorial clarity; when
yuuji@0 247 present in the actual message, they are represented by "CRLF".
yuuji@0 248
yuuji@0 249 Formal syntax is defined using ABNF [ABNF].
yuuji@0 250
yuuji@0 251 The term "metadata" or "metadata item" is used throughout this
yuuji@0 252 document. It refers to any system or user-defined keyword. Future
yuuji@0 253 documents may extend "metadata" to include other dynamic message
yuuji@0 254 data.
yuuji@0 255
yuuji@0 256 Some IMAP mailboxes are private, accessible only to the owning user.
yuuji@0 257 Other mailboxes are not, either because the owner has set an Access
yuuji@0 258 Control List [ACL] that permits access by other users, or because it
yuuji@0 259 is a shared mailbox. Let's call a metadata item "shared" for the
yuuji@0 260 mailbox if any changes to the metadata items are persistent and
yuuji@0 261 visible to all other users accessing the mailbox. Otherwise, the
yuuji@0 262 metadata item is called "private". Note that private metadata items
yuuji@0 263 are still visible to all sessions accessing the mailbox as the same
yuuji@0 264 user. Also note that different mailboxes may have different metadata
yuuji@0 265 items as shared.
yuuji@0 266
yuuji@0 267 See Section 1 for the definition of a "CONDSTORE-aware client" and a
yuuji@0 268 "CONDSTORE enabling command".
yuuji@0 269
yuuji@0 270
yuuji@0 271
yuuji@0 272
yuuji@0 273
yuuji@0 274
yuuji@0 275
yuuji@0 276
yuuji@0 277
yuuji@0 278
yuuji@0 279
yuuji@0 280
yuuji@0 281
yuuji@0 282 Melnikov & Hole Standards Track [Page 5]
yuuji@0 283
yuuji@0 284 RFC 4551 IMAP Extension for Conditional STORE June 2006
yuuji@0 285
yuuji@0 286
yuuji@0 287 3. IMAP Protocol Changes
yuuji@0 288
yuuji@0 289 3.1. New OK Untagged Responses for SELECT and EXAMINE
yuuji@0 290
yuuji@0 291 This document adds two new response codes, HIGHESTMODSEQ and
yuuji@0 292 NOMODSEQ. One of those response codes MUST be returned in the OK
yuuji@0 293 untagged response for a successful SELECT/EXAMINE command.
yuuji@0 294
yuuji@0 295 When opening a mailbox, the server must check if the mailbox supports
yuuji@0 296 the persistent storage of mod-sequences. If the mailbox supports the
yuuji@0 297 persistent storage of mod-sequences and the mailbox open operation
yuuji@0 298 succeeds, the server MUST send the OK untagged response including
yuuji@0 299 HIGHESTMODSEQ response code. If the persistent storage for the
yuuji@0 300 mailbox is not supported, the server MUST send the OK untagged
yuuji@0 301 response including NOMODSEQ response code instead.
yuuji@0 302
yuuji@0 303 3.1.1. HIGHESTMODSEQ Response Code
yuuji@0 304
yuuji@0 305 This document adds a new response code that is returned in the OK
yuuji@0 306 untagged response for the SELECT and EXAMINE commands. A server
yuuji@0 307 supporting the persistent storage of mod-sequences for the mailbox
yuuji@0 308 MUST send the OK untagged response including HIGHESTMODSEQ response
yuuji@0 309 code with every successful SELECT or EXAMINE command:
yuuji@0 310
yuuji@0 311 OK [HIGHESTMODSEQ <mod-sequence-value>]
yuuji@0 312
yuuji@0 313 where <mod-sequence-value> is the highest mod-sequence value of
yuuji@0 314 all messages in the mailbox. When the server changes UIDVALIDITY
yuuji@0 315 for a mailbox, it doesn't have to keep the same HIGHESTMODSEQ for
yuuji@0 316 the mailbox.
yuuji@0 317
yuuji@0 318 A disconnected client can use the value of HIGHESTMODSEQ to check if
yuuji@0 319 it has to refetch metadata from the server. If the UIDVALIDITY value
yuuji@0 320 has changed for the selected mailbox, the client MUST delete the
yuuji@0 321 cached value of HIGHESTMODSEQ. If UIDVALIDITY for the mailbox is the
yuuji@0 322 same, and if the HIGHESTMODSEQ value stored in the client's cache is
yuuji@0 323 less than the value returned by the server, then some metadata items
yuuji@0 324 on the server have changed since the last synchronization, and the
yuuji@0 325 client needs to update its cache. The client MAY use SEARCH MODSEQ
yuuji@0 326 (Section 3.4) to find out exactly which metadata items have changed.
yuuji@0 327 Alternatively, the client MAY issue FETCH with the CHANGEDSINCE
yuuji@0 328 modifier (Section 3.3.1) in order to fetch data for all messages that
yuuji@0 329 have metadata items changed since some known modification sequence.
yuuji@0 330
yuuji@0 331 Example 1:
yuuji@0 332
yuuji@0 333 C: A142 SELECT INBOX
yuuji@0 334 S: * 172 EXISTS
yuuji@0 335
yuuji@0 336
yuuji@0 337
yuuji@0 338 Melnikov & Hole Standards Track [Page 6]
yuuji@0 339
yuuji@0 340 RFC 4551 IMAP Extension for Conditional STORE June 2006
yuuji@0 341
yuuji@0 342
yuuji@0 343 S: * 1 RECENT
yuuji@0 344 S: * OK [UNSEEN 12] Message 12 is first unseen
yuuji@0 345 S: * OK [UIDVALIDITY 3857529045] UIDs valid
yuuji@0 346 S: * OK [UIDNEXT 4392] Predicted next UID
yuuji@0 347 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
yuuji@0 348 S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
yuuji@0 349 S: * OK [HIGHESTMODSEQ 715194045007]
yuuji@0 350 S: A142 OK [READ-WRITE] SELECT completed
yuuji@0 351
yuuji@0 352 3.1.2. NOMODSEQ Response Code
yuuji@0 353
yuuji@0 354 A server that doesn't support the persistent storage of mod-sequences
yuuji@0 355 for the mailbox MUST send the OK untagged response including NOMODSEQ
yuuji@0 356 response code with every successful SELECT or EXAMINE command. A
yuuji@0 357 server that returned NOMODSEQ response code for a mailbox, which
yuuji@0 358 subsequently receives one of the following commands while the mailbox
yuuji@0 359 is selected:
yuuji@0 360
yuuji@0 361 - a FETCH command with the CHANGEDSINCE modifier,
yuuji@0 362 - a FETCH or SEARCH command that includes the MODSEQ message data
yuuji@0 363 item, or
yuuji@0 364 - a STORE command with the UNCHANGEDSINCE modifier
yuuji@0 365
yuuji@0 366 MUST reject any such command with the tagged BAD response.
yuuji@0 367
yuuji@0 368 Example 2:
yuuji@0 369
yuuji@0 370 C: A142 SELECT INBOX
yuuji@0 371 S: * 172 EXISTS
yuuji@0 372 S: * 1 RECENT
yuuji@0 373 S: * OK [UNSEEN 12] Message 12 is first unseen
yuuji@0 374 S: * OK [UIDVALIDITY 3857529045] UIDs valid
yuuji@0 375 S: * OK [UIDNEXT 4392] Predicted next UID
yuuji@0 376 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
yuuji@0 377 S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
yuuji@0 378 S: * OK [NOMODSEQ] Sorry, this mailbox format doesn't support
yuuji@0 379 modsequences
yuuji@0 380 S: A142 OK [READ-WRITE] SELECT completed
yuuji@0 381
yuuji@0 382 3.2. STORE and UID STORE Commands
yuuji@0 383
yuuji@0 384 This document defines the following STORE modifier (see Section 2.5
yuuji@0 385 of [IMAPABNF]):
yuuji@0 386
yuuji@0 387 UNCHANGEDSINCE <mod-sequence>
yuuji@0 388
yuuji@0 389 For each message specified in the message set, the server performs
yuuji@0 390 the following. If the mod-sequence of any metadata item of the
yuuji@0 391
yuuji@0 392
yuuji@0 393
yuuji@0 394 Melnikov & Hole Standards Track [Page 7]
yuuji@0 395
yuuji@0 396 RFC 4551 IMAP Extension for Conditional STORE June 2006
yuuji@0 397
yuuji@0 398
yuuji@0 399 message is equal or less than the specified UNCHANGEDSINCE value,
yuuji@0 400 then the requested operation (as described by the message data
yuuji@0 401 item) is performed. If the operation is successful, the server
yuuji@0 402 MUST update the mod-sequence attribute of the message. An
yuuji@0 403 untagged FETCH response MUST be sent, even if the .SILENT suffix
yuuji@0 404 is specified, and the response MUST include the MODSEQ message
yuuji@0 405 data item. This is required to update the client's cache with the
yuuji@0 406 correct mod-sequence values. See Section 3.3.2 for more details.
yuuji@0 407
yuuji@0 408 However, if the mod-sequence of any metadata item of the message
yuuji@0 409 is greater than the specified UNCHANGEDSINCE value, then the
yuuji@0 410 requested operation MUST NOT be performed. In this case, the
yuuji@0 411 mod-sequence attribute of the message is not updated, and the
yuuji@0 412 message number (or unique identifier in the case of the UID STORE
yuuji@0 413 command) is added to the list of messages that failed the
yuuji@0 414 UNCHANGESINCE test.
yuuji@0 415
yuuji@0 416 When the server finished performing the operation on all the
yuuji@0 417 messages in the message set, it checks for a non-empty list of
yuuji@0 418 messages that failed the UNCHANGESINCE test. If this list is
yuuji@0 419 non-empty, the server MUST return in the tagged response a
yuuji@0 420 MODIFIED response code. The MODIFIED response code includes the
yuuji@0 421 message set (for STORE) or set of UIDs (for UID STORE) of all
yuuji@0 422 messages that failed the UNCHANGESINCE test.
yuuji@0 423
yuuji@0 424 Example 3:
yuuji@0 425
yuuji@0 426 All messages pass the UNCHANGESINCE test.
yuuji@0 427
yuuji@0 428 C: a103 UID STORE 6,4,8 (UNCHANGEDSINCE 12121230045)
yuuji@0 429 +FLAGS.SILENT (\Deleted)
yuuji@0 430 S: * 1 FETCH (UID 4 MODSEQ (12121231000))
yuuji@0 431 S: * 2 FETCH (UID 6 MODSEQ (12121230852))
yuuji@0 432 S: * 4 FETCH (UID 8 MODSEQ (12121130956))
yuuji@0 433 S: a103 OK Conditional Store completed
yuuji@0 434
yuuji@0 435 Example 4:
yuuji@0 436
yuuji@0 437 C: a104 STORE * (UNCHANGEDSINCE 12121230045) +FLAGS.SILENT
yuuji@0 438 (\Deleted $Processed)
yuuji@0 439 S: * 50 FETCH (MODSEQ (12111230047))
yuuji@0 440 S: a104 OK Store (conditional) completed
yuuji@0 441
yuuji@0 442 Example 5:
yuuji@0 443
yuuji@0 444 C: c101 STORE 1 (UNCHANGEDSINCE 12121230045) -FLAGS.SILENT
yuuji@0 445 (\Deleted)
yuuji@0 446 S: * OK [HIGHESTMODSEQ 12111230047]
yuuji@0 447
yuuji@0 448
yuuji@0 449
yuuji@0 450 Melnikov & Hole Standards Track [Page 8]
yuuji@0 451
yuuji@0 452 RFC 4551 IMAP Extension for Conditional STORE June 2006
yuuji@0 453
yuuji@0 454
yuuji@0 455 S: * 50 FETCH (MODSEQ (12111230048))
yuuji@0 456 S: c101 OK Store (conditional) completed
yuuji@0 457
yuuji@0 458 HIGHESTMODSEQ response code was sent by the server presumably
yuuji@0 459 because this was the first CONDSTORE enabling command.
yuuji@0 460
yuuji@0 461 Example 6:
yuuji@0 462
yuuji@0 463 In spite of the failure of the conditional STORE operation for
yuuji@0 464 message 7, the server continues to process the conditional STORE
yuuji@0 465 in order to find all messages that fail the test.
yuuji@0 466
yuuji@0 467 C: d105 STORE 7,5,9 (UNCHANGEDSINCE 320162338)
yuuji@0 468 +FLAGS.SILENT (\Deleted)
yuuji@0 469 S: * 5 FETCH (MODSEQ (320162350))
yuuji@0 470 S: d105 OK [MODIFIED 7,9] Conditional STORE failed
yuuji@0 471
yuuji@0 472 Example 7:
yuuji@0 473
yuuji@0 474 Same as above, but the server follows the SHOULD recommendation in
yuuji@0 475 Section 6.4.6 of [IMAP4].
yuuji@0 476
yuuji@0 477 C: d105 STORE 7,5,9 (UNCHANGEDSINCE 320162338)
yuuji@0 478 +FLAGS.SILENT (\Deleted)
yuuji@0 479 S: * 7 FETCH (MODSEQ (320162342) FLAGS (\Seen \Deleted))
yuuji@0 480 S: * 5 FETCH (MODSEQ (320162350))
yuuji@0 481 S: * 9 FETCH (MODSEQ (320162349) FLAGS (\Answered))
yuuji@0 482 S: d105 OK [MODIFIED 7,9] Conditional STORE failed
yuuji@0 483
yuuji@0 484 Use of UNCHANGEDSINCE with a modification sequence of 0 always
yuuji@0 485 fails if the metadata item exists. A system flag MUST always be
yuuji@0 486 considered existent, whether it was set or not.
yuuji@0 487
yuuji@0 488 Example 8:
yuuji@0 489
yuuji@0 490 C: a102 STORE 12 (UNCHANGEDSINCE 0)
yuuji@0 491 +FLAGS.SILENT ($MDNSent)
yuuji@0 492 S: a102 OK [MODIFIED 12] Conditional STORE failed
yuuji@0 493
yuuji@0 494 The client has tested the presence of the $MDNSent user-defined
yuuji@0 495 keyword.
yuuji@0 496
yuuji@0 497 Note: A client trying to make an atomic change to the state of a
yuuji@0 498 particular metadata item (or a set of metadata items) should be
yuuji@0 499 prepared to deal with the case when the server returns the MODIFIED
yuuji@0 500 response code if the state of the metadata item being watched hasn't
yuuji@0 501 changed (but the state of some other metadata item has). This is
yuuji@0 502 necessary, because some servers don't store separate mod-sequences
yuuji@0 503
yuuji@0 504
yuuji@0 505
yuuji@0 506 Melnikov & Hole Standards Track [Page 9]
yuuji@0 507
yuuji@0 508 RFC 4551 IMAP Extension for Conditional STORE June 2006
yuuji@0 509
yuuji@0 510
yuuji@0 511 for different metadata items. However, a server implementation
yuuji@0 512 SHOULD avoid generating spurious MODIFIED responses for +FLAGS/-FLAGS
yuuji@0 513 STORE operations, even when the server stores a single mod-sequence
yuuji@0 514 per message. Section 5 describes how this can be achieved.
yuuji@0 515
yuuji@0 516 Unless the server has included an unsolicited FETCH to update
yuuji@0 517 client's knowledge about messages that have failed the UNCHANGEDSINCE
yuuji@0 518 test, upon receipt of the MODIFIED response code, the client SHOULD
yuuji@0 519 try to figure out if the required metadata items have indeed changed
yuuji@0 520 by issuing FETCH or NOOP command. It is RECOMMENDED that the server
yuuji@0 521 avoids the need for the client to do that by sending an unsolicited
yuuji@0 522 FETCH response (Examples 9 and 10).
yuuji@0 523
yuuji@0 524 If the required metadata items haven't changed, the client SHOULD
yuuji@0 525 retry the command with the new mod-sequence. The client SHOULD allow
yuuji@0 526 for a configurable but reasonable number of retries (at least 2).
yuuji@0 527
yuuji@0 528 Example 9:
yuuji@0 529
yuuji@0 530 In the example below, the server returns the MODIFIED response
yuuji@0 531 code without sending information describing why the STORE
yuuji@0 532 UNCHANGEDSINCE operation has failed.
yuuji@0 533
yuuji@0 534 C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000)
yuuji@0 535 +FLAGS.SILENT ($Processed)
yuuji@0 536 S: * 100 FETCH (MODSEQ (303181230852))
yuuji@0 537 S: * 102 FETCH (MODSEQ (303181230852))
yuuji@0 538 ...
yuuji@0 539 S: * 150 FETCH (MODSEQ (303181230852))
yuuji@0 540 S: a106 OK [MODIFIED 101] Conditional STORE failed
yuuji@0 541
yuuji@0 542 The flag $Processed was set on the message 101...
yuuji@0 543
yuuji@0 544 C: a107 NOOP
yuuji@0 545 S: * 101 FETCH (MODSEQ (303011130956) FLAGS ($Processed))
yuuji@0 546 S: a107 OK
yuuji@0 547
yuuji@0 548 Or the flag hasn't changed, but another has (note that this server
yuuji@0 549 behaviour is discouraged. Server implementers should also see
yuuji@0 550 Section 5)...
yuuji@0 551
yuuji@0 552 C: b107 NOOP
yuuji@0 553 S: * 101 FETCH (MODSEQ (303011130956) FLAGS (\Deleted \Answered))
yuuji@0 554 S: b107 OK
yuuji@0 555
yuuji@0 556 ...and the client retries the operation for the message 101 with
yuuji@0 557 the updated UNCHANGEDSINCE value
yuuji@0 558
yuuji@0 559
yuuji@0 560
yuuji@0 561
yuuji@0 562 Melnikov & Hole Standards Track [Page 10]
yuuji@0 563
yuuji@0 564 RFC 4551 IMAP Extension for Conditional STORE June 2006
yuuji@0 565
yuuji@0 566
yuuji@0 567 C: b108 STORE 101 (UNCHANGEDSINCE 303011130956)
yuuji@0 568 +FLAGS.SILENT ($Processed)
yuuji@0 569 S: * 101 FETCH (MODSEQ (303181230852))
yuuji@0 570 S: b108 OK Conditional Store completed
yuuji@0 571
yuuji@0 572 Example 10:
yuuji@0 573
yuuji@0 574 Same as above, but the server avoids the need for the client to
yuuji@0 575 poll for changes.
yuuji@0 576
yuuji@0 577 The flag $Processed was set on the message 101 by another
yuuji@0 578 client...
yuuji@0 579
yuuji@0 580 C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000)
yuuji@0 581 +FLAGS.SILENT ($Processed)
yuuji@0 582 S: * 100 FETCH (MODSEQ (303181230852))
yuuji@0 583 S: * 101 FETCH (MODSEQ (303011130956) FLAGS ($Processed))
yuuji@0 584 S: * 102 FETCH (MODSEQ (303181230852))
yuuji@0 585 ...
yuuji@0 586 S: * 150 FETCH (MODSEQ (303181230852))
yuuji@0 587 S: a106 OK [MODIFIED 101] Conditional STORE failed
yuuji@0 588
yuuji@0 589 Or the flag hasn't changed, but another has (note that this server
yuuji@0 590 behaviour is discouraged. Server implementers should also see
yuuji@0 591 Section 5)...
yuuji@0 592
yuuji@0 593 C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000)
yuuji@0 594 +FLAGS.SILENT ($Processed)
yuuji@0 595 S: * 100 FETCH (MODSEQ (303181230852))
yuuji@0 596 S: * 101 FETCH (MODSEQ (303011130956) FLAGS (\Deleted \Answered))
yuuji@0 597 S: * 102 FETCH (MODSEQ (303181230852))
yuuji@0 598 ...
yuuji@0 599 S: * 150 FETCH (MODSEQ (303181230852))
yuuji@0 600 S: a106 OK [MODIFIED 101] Conditional STORE failed
yuuji@0 601
yuuji@0 602 ...and the client retries the operation for the message 101 with
yuuji@0 603 the updated UNCHANGEDSINCE value
yuuji@0 604
yuuji@0 605 C: b108 STORE 101 (UNCHANGEDSINCE 303011130956)
yuuji@0 606 +FLAGS.SILENT ($Processed)
yuuji@0 607 S: * 101 FETCH (MODSEQ (303181230852))
yuuji@0 608 S: b108 OK Conditional Store completed
yuuji@0 609
yuuji@0 610 Or the flag hasn't changed, but another has (nice server
yuuji@0 611 behaviour. Server implementers should also see Section 5)...
yuuji@0 612
yuuji@0 613 C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000)
yuuji@0 614 +FLAGS.SILENT ($Processed)
yuuji@0 615
yuuji@0 616
yuuji@0 617
yuuji@0 618 Melnikov & Hole Standards Track [Page 11]
yuuji@0 619
yuuji@0 620 RFC 4551 IMAP Extension for Conditional STORE June 2006
yuuji@0 621
yuuji@0 622
yuuji@0 623 S: * 100 FETCH (MODSEQ (303181230852))
yuuji@0 624 S: * 101 FETCH (MODSEQ (303011130956) FLAGS ($Processed \Deleted
yuuji@0 625 \Answered))
yuuji@0 626 S: * 102 FETCH (MODSEQ (303181230852))
yuuji@0 627 ...
yuuji@0 628 S: * 150 FETCH (MODSEQ (303181230852))
yuuji@0 629 S: a106 OK Conditional STORE completed
yuuji@0 630
yuuji@0 631 Example 11:
yuuji@0 632
yuuji@0 633 The following example is based on the example from the Section
yuuji@0 634 4.2.3 of [RFC-2180] and demonstrates that the MODIFIED response
yuuji@0 635 code may be also returned in the tagged NO response.
yuuji@0 636
yuuji@0 637 Client tries to conditionally STORE flags on a mixture of expunged
yuuji@0 638 and non-expunged messages; one message fails the UNCHANGEDSINCE
yuuji@0 639 test.
yuuji@0 640
yuuji@0 641 C: B001 STORE 1:7 (UNCHANGEDSINCE 320172338) +FLAGS (\SEEN)
yuuji@0 642 S: * 1 FETCH (MODSEQ (320172342) FLAGS (\SEEN))
yuuji@0 643 S: * 3 FETCH (MODSEQ (320172342) FLAGS (\SEEN))
yuuji@0 644 S: B001 NO [MODIFIED 2] Some of the messages no longer exist.
yuuji@0 645
yuuji@0 646 C: B002 NOOP
yuuji@0 647 S: * 4 EXPUNGE
yuuji@0 648 S: * 4 EXPUNGE
yuuji@0 649 S: * 4 EXPUNGE
yuuji@0 650 S: * 4 EXPUNGE
yuuji@0 651 S: * 2 FETCH (MODSEQ (320172340) FLAGS (\Deleted \Answered))
yuuji@0 652 S: B002 OK NOOP Completed.
yuuji@0 653
yuuji@0 654 By receiving FETCH responses for messages 1 and 3, and EXPUNGE
yuuji@0 655 responses that indicate that messages 4 through 7 have been
yuuji@0 656 expunged, the client retries the operation only for the message 2.
yuuji@0 657 The updated UNCHANGEDSINCE value is used.
yuuji@0 658
yuuji@0 659 C: b003 STORE 2 (UNCHANGEDSINCE 320172340) +FLAGS (\Seen)
yuuji@0 660 S: * 2 FETCH (MODSEQ (320180050))
yuuji@0 661 S: b003 OK Conditional Store completed
yuuji@0 662
yuuji@0 663 Note: If a message is specified multiple times in the message set,
yuuji@0 664 and the server doesn't internally eliminate duplicates from the
yuuji@0 665 message set, it MUST NOT fail the conditional STORE operation for the
yuuji@0 666 second (or subsequent) occurrence of the message if the operation
yuuji@0 667 completed successfully for the first occurrence. For example, if the
yuuji@0 668 client specifies:
yuuji@0 669
yuuji@0 670
yuuji@0 671
yuuji@0 672
yuuji@0 673
yuuji@0 674 Melnikov & Hole Standards Track [Page 12]
yuuji@0 675
yuuji@0 676 RFC 4551 IMAP Extension for Conditional STORE June 2006
yuuji@0 677
yuuji@0 678
yuuji@0 679 e105 STORE 7,3:9 (UNCHANGEDSINCE 12121230045)
yuuji@0 680 +FLAGS.SILENT (\Deleted)
yuuji@0 681
yuuji@0 682 the server must not fail the operation for message 7 as part of
yuuji@0 683 processing "3:9" if it succeeded when message 7 was processed the
yuuji@0 684 first time.
yuuji@0 685
yuuji@0 686 Once the client specified the UNCHANGEDSINCE modifier in a STORE
yuuji@0 687 command, the server MUST include the MODSEQ fetch response data items
yuuji@0 688 in all subsequent unsolicited FETCH responses.
yuuji@0 689
yuuji@0 690 This document also changes the behaviour of the server when it has
yuuji@0 691 performed a STORE or UID STORE command and the UNCHANGEDSINCE
yuuji@0 692 modifier is not specified. If the operation is successful for a
yuuji@0 693 message, the server MUST update the mod-sequence attribute of the
yuuji@0 694 message. The server is REQUIRED to include the mod-sequence value
yuuji@0 695 whenever it decides to send the unsolicited FETCH response to all
yuuji@0 696 CONDSTORE-aware clients that have opened the mailbox containing the
yuuji@0 697 message.
yuuji@0 698
yuuji@0 699 Server implementers should also see Section 3.8 for additional
yuuji@0 700 quality of implementation issues related to the STORE command.
yuuji@0 701
yuuji@0 702 3.3. FETCH and UID FETCH Commands
yuuji@0 703
yuuji@0 704 3.3.1. CHANGEDSINCE FETCH Modifier
yuuji@0 705
yuuji@0 706 This document defines the following FETCH modifier (see Section 2.4
yuuji@0 707 of [IMAPABNF]):
yuuji@0 708
yuuji@0 709 CHANGEDSINCE <mod-sequence>
yuuji@0 710
yuuji@0 711 CHANGEDSINCE FETCH modifier allows to create a further subset of
yuuji@0 712 the list of messages described by sequence set. The information
yuuji@0 713 described by message data items is only returned for messages that
yuuji@0 714 have mod-sequence bigger than <mod-sequence>.
yuuji@0 715
yuuji@0 716 When CHANGEDSINCE FETCH modifier is specified, it implicitly adds
yuuji@0 717 MODSEQ FETCH message data item (Section 3.3.2).
yuuji@0 718
yuuji@0 719 Example 12:
yuuji@0 720
yuuji@0 721 C: s100 UID FETCH 1:* (FLAGS) (CHANGEDSINCE 12345)
yuuji@0 722 S: * 1 FETCH (UID 4 MODSEQ (65402) FLAGS (\Seen))
yuuji@0 723 S: * 2 FETCH (UID 6 MODSEQ (75403) FLAGS (\Deleted))
yuuji@0 724 S: * 4 FETCH (UID 8 MODSEQ (29738) FLAGS ($NoJunk $AutoJunk
yuuji@0 725 $MDNSent))
yuuji@0 726 S: s100 OK FETCH completed
yuuji@0 727
yuuji@0 728
yuuji@0 729
yuuji@0 730 Melnikov & Hole Standards Track [Page 13]
yuuji@0 731
yuuji@0 732 RFC 4551 IMAP Extension for Conditional STORE June 2006
yuuji@0 733
yuuji@0 734
yuuji@0 735 3.3.2. MODSEQ Message Data Item in FETCH Command
yuuji@0 736
yuuji@0 737 This extension adds a MODSEQ message data item to the FETCH command.
yuuji@0 738 The MODSEQ message data item allows clients to retrieve mod-sequence
yuuji@0 739 values for a range of messages in the currently selected mailbox.
yuuji@0 740
yuuji@0 741 Once the client specified the MODSEQ message data item in a FETCH
yuuji@0 742 request, the server MUST include the MODSEQ fetch response data items
yuuji@0 743 in all subsequent unsolicited FETCH responses.
yuuji@0 744
yuuji@0 745 Syntax: MODSEQ
yuuji@0 746
yuuji@0 747 The MODSEQ message data item causes the server to return MODSEQ
yuuji@0 748 fetch response data items.
yuuji@0 749
yuuji@0 750 Syntax: MODSEQ ( <permsg-modsequence> )
yuuji@0 751
yuuji@0 752 MODSEQ response data items contain per-message mod-sequences.
yuuji@0 753
yuuji@0 754 The MODSEQ response data item is returned if the client issued
yuuji@0 755 FETCH with MODSEQ message data item. It also allows the server to
yuuji@0 756 notify the client about mod-sequence changes caused by conditional
yuuji@0 757 STOREs (Section 3.2) and/or changes caused by external sources.
yuuji@0 758
yuuji@0 759 Example 13:
yuuji@0 760
yuuji@0 761 C: a FETCH 1:3 (MODSEQ)
yuuji@0 762 S: * 1 FETCH (MODSEQ (624140003))
yuuji@0 763 S: * 2 FETCH (MODSEQ (624140007))
yuuji@0 764 S: * 3 FETCH (MODSEQ (624140005))
yuuji@0 765 S: a OK Fetch complete
yuuji@0 766
yuuji@0 767 In this example, the client requests per-message mod-sequences for
yuuji@0 768 a set of messages.
yuuji@0 769
yuuji@0 770 When a flag for a message is modified in a different session, the
yuuji@0 771 server sends an unsolicited FETCH response containing the mod-
yuuji@0 772 sequence for the message.
yuuji@0 773
yuuji@0 774 Example 14:
yuuji@0 775
yuuji@0 776 (Session 1, authenticated as a user "alex"). The user adds a
yuuji@0 777 shared flag \Deleted:
yuuji@0 778
yuuji@0 779 C: A142 SELECT INBOX
yuuji@0 780 ...
yuuji@0 781 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
yuuji@0 782 S: * OK [PERMANENTFLAGS (\Answered \Deleted \Seen \*)] Limited
yuuji@0 783
yuuji@0 784
yuuji@0 785
yuuji@0 786 Melnikov & Hole Standards Track [Page 14]
yuuji@0 787
yuuji@0 788 RFC 4551 IMAP Extension for Conditional STORE June 2006
yuuji@0 789
yuuji@0 790
yuuji@0 791 ...
yuuji@0 792
yuuji@0 793 C: A160 STORE 7 +FLAGS.SILENT (\Deleted)
yuuji@0 794 S: * 7 FETCH (MODSEQ (2121231000))
yuuji@0 795 S: A160 OK Store completed
yuuji@0 796
yuuji@0 797 (Session 2, also authenticated as the user "alex"). Any changes
yuuji@0 798 to flags are always reported to all sessions authenticated as the
yuuji@0 799 same user as in the session 1.
yuuji@0 800
yuuji@0 801 C: C180 NOOP
yuuji@0 802 S: * 7 FETCH (FLAGS (\Deleted \Answered) MODSEQ (12121231000))
yuuji@0 803 S: C180 OK Noop completed
yuuji@0 804
yuuji@0 805 (Session 3, authenticated as a user "andrew"). As \Deleted is a
yuuji@0 806 shared flag, changes in session 1 are also reported in session 3:
yuuji@0 807
yuuji@0 808 C: D210 NOOP
yuuji@0 809 S: * 7 FETCH (FLAGS (\Deleted \Answered) MODSEQ (12121231000))
yuuji@0 810 S: D210 OK Noop completed
yuuji@0 811
yuuji@0 812 The user modifies a private flag \Seen in session 1...
yuuji@0 813
yuuji@0 814 C: A240 STORE 7 +FLAGS.SILENT (\Seen)
yuuji@0 815 S: * 7 FETCH (MODSEQ (12121231777))
yuuji@0 816 S: A240 OK Store completed
yuuji@0 817
yuuji@0 818 ...which is only reported in session 2...
yuuji@0 819
yuuji@0 820 C: C270 NOOP
yuuji@0 821 S: * 7 FETCH (FLAGS (\Deleted \Answered \Seen) MODSEQ
yuuji@0 822 (12121231777))
yuuji@0 823 S: C270 OK Noop completed
yuuji@0 824
yuuji@0 825 ...but not in session 3.
yuuji@0 826
yuuji@0 827 C: D300 NOOP
yuuji@0 828 S: D300 OK Noop completed
yuuji@0 829
yuuji@0 830 And finally, the user removes flags \Answered (shared) and \Seen
yuuji@0 831 (private) in session 1.
yuuji@0 832
yuuji@0 833 C: A330 STORE 7 -FLAGS.SILENT (\Answered \Seen)
yuuji@0 834 S: * 7 FETCH (MODSEQ (12121245160))
yuuji@0 835 S: A330 OK Store completed
yuuji@0 836
yuuji@0 837
yuuji@0 838
yuuji@0 839
yuuji@0 840
yuuji@0 841
yuuji@0 842 Melnikov & Hole Standards Track [Page 15]
yuuji@0 843
yuuji@0 844 RFC 4551 IMAP Extension for Conditional STORE June 2006
yuuji@0 845
yuuji@0 846
yuuji@0 847 Both changes are reported in the session 2...
yuuji@0 848
yuuji@0 849 C: C360 NOOP
yuuji@0 850 S: * 7 FETCH (FLAGS (\Deleted) MODSEQ (12121245160))
yuuji@0 851 S: C360 OK Noop completed
yuuji@0 852
yuuji@0 853 ...and only changes to shared flags are reported in session 3.
yuuji@0 854
yuuji@0 855 C: D390 NOOP
yuuji@0 856 S: * 7 FETCH (FLAGS (\Deleted) MODSEQ (12121245160))
yuuji@0 857 S: D390 OK Noop completed
yuuji@0 858
yuuji@0 859 Server implementers should also see Section 3.8 for additional
yuuji@0 860 quality of implementation issues related to the FETCH command.
yuuji@0 861
yuuji@0 862 3.4. MODSEQ Search Criterion in SEARCH
yuuji@0 863
yuuji@0 864 The MODSEQ criterion for the SEARCH command allows a client to search
yuuji@0 865 for the metadata items that were modified since a specified moment.
yuuji@0 866
yuuji@0 867 Syntax: MODSEQ [<entry-name> <entry-type-req>] <mod-sequence-valzer>
yuuji@0 868
yuuji@0 869 Messages that have modification values that are equal to or
yuuji@0 870 greater than <mod-sequence-valzer>. This allows a client, for
yuuji@0 871 example, to find out which messages contain metadata items that
yuuji@0 872 have changed since the last time it updated its disconnected
yuuji@0 873 cache. The client may also specify <entry-name> (name of metadata
yuuji@0 874 item) and <entry-type-req> (type of metadata item) before
yuuji@0 875 <mod-sequence-valzer>. <entry-type-req> can be one of "shared",
yuuji@0 876 "priv" (private), or "all". The latter means that the server
yuuji@0 877 should use the biggest value among "priv" and "shared" mod-
yuuji@0 878 sequences for the metadata item. If the server doesn't store
yuuji@0 879 internally separate mod-sequences for different metadata items, it
yuuji@0 880 MUST ignore <entry-name> and <entry-type-req>. Otherwise, the
yuuji@0 881 server should use them to narrow down the search.
yuuji@0 882
yuuji@0 883 For a flag <flagname>, the corresponding <entry-name> has a form
yuuji@0 884 "/flags/<flagname>" as defined in [IMAPABNF]. Note that the
yuuji@0 885 leading "\" character that denotes a system flag has to be escaped
yuuji@0 886 as per Section 4.3 of [IMAP4], as the <entry-name> uses syntax for
yuuji@0 887 quoted strings.
yuuji@0 888
yuuji@0 889 If client specifies a MODSEQ criterion in a SEARCH command and the
yuuji@0 890 server returns a non-empty SEARCH result, the server MUST also append
yuuji@0 891 (to the end of the untagged SEARCH response) the highest mod-sequence
yuuji@0 892 for all messages being returned. See also Section 3.5.
yuuji@0 893
yuuji@0 894
yuuji@0 895
yuuji@0 896
yuuji@0 897
yuuji@0 898 Melnikov & Hole Standards Track [Page 16]
yuuji@0 899
yuuji@0 900 RFC 4551 IMAP Extension for Conditional STORE June 2006
yuuji@0 901
yuuji@0 902
yuuji@0 903 Example 15:
yuuji@0 904
yuuji@0 905 C: a SEARCH MODSEQ "/flags/\\draft" all 620162338
yuuji@0 906 S: * SEARCH 2 5 6 7 11 12 18 19 20 23 (MODSEQ 917162500)
yuuji@0 907 S: a OK Search complete
yuuji@0 908
yuuji@0 909 In the above example, the message numbers of any messages
yuuji@0 910 containing the string "IMAP4" in the "value" attribute of the
yuuji@0 911 "/comment" entry and having a mod-sequence equal to or greater
yuuji@0 912 than 620162338 for the "\Draft" flag are returned in the search
yuuji@0 913 results.
yuuji@0 914
yuuji@0 915 Example 16:
yuuji@0 916
yuuji@0 917 C: t SEARCH OR NOT MODSEQ 720162338 LARGER 50000
yuuji@0 918 S: * SEARCH
yuuji@0 919 S: t OK Search complete, nothing found
yuuji@0 920
yuuji@0 921 3.5. Modified SEARCH Untagged Response
yuuji@0 922
yuuji@0 923 Data: zero or more numbers
yuuji@0 924 mod-sequence value (omitted if no match)
yuuji@0 925
yuuji@0 926 This document extends syntax of the untagged SEARCH response to
yuuji@0 927 include the highest mod-sequence for all messages being returned.
yuuji@0 928
yuuji@0 929 If a client specifies a MODSEQ criterion in a SEARCH (or UID SEARCH)
yuuji@0 930 command and the server returns a non-empty SEARCH result, the server
yuuji@0 931 MUST also append (to the end of the untagged SEARCH response) the
yuuji@0 932 highest mod-sequence for all messages being returned. See Section
yuuji@0 933 3.4 for examples.
yuuji@0 934
yuuji@0 935 3.6. HIGHESTMODSEQ Status Data Items
yuuji@0 936
yuuji@0 937 This document defines a new status data item:
yuuji@0 938
yuuji@0 939 HIGHESTMODSEQ
yuuji@0 940
yuuji@0 941 The highest mod-sequence value of all messages in the mailbox.
yuuji@0 942 This is the same value that is returned by the server in the
yuuji@0 943 HIGHESTMODSEQ response code in an OK untagged response (see
yuuji@0 944 Section 3.1.1). If the server doesn't support the persistent
yuuji@0 945 storage of mod-sequences for the mailbox (see Section 3.1.2), the
yuuji@0 946 server MUST return 0 as the value of HIGHESTMODSEQ status data
yuuji@0 947 item.
yuuji@0 948
yuuji@0 949
yuuji@0 950
yuuji@0 951
yuuji@0 952
yuuji@0 953
yuuji@0 954 Melnikov & Hole Standards Track [Page 17]
yuuji@0 955
yuuji@0 956 RFC 4551 IMAP Extension for Conditional STORE June 2006
yuuji@0 957
yuuji@0 958
yuuji@0 959 Example 17:
yuuji@0 960
yuuji@0 961 C: A042 STATUS blurdybloop (UIDNEXT MESSAGES HIGHESTMODSEQ)
yuuji@0 962 S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292
yuuji@0 963 HIGHESTMODSEQ 7011231777)
yuuji@0 964 S: A042 OK STATUS completed
yuuji@0 965
yuuji@0 966 3.7. CONDSTORE Parameter to SELECT and EXAMINE
yuuji@0 967
yuuji@0 968 The CONDSTORE extension defines a single optional select parameter,
yuuji@0 969 "CONDSTORE", which tells the server that it MUST include the MODSEQ
yuuji@0 970 fetch response data items in all subsequent unsolicited FETCH
yuuji@0 971 responses.
yuuji@0 972
yuuji@0 973 The CONDSTORE parameter to SELECT/EXAMINE helps avoid a race
yuuji@0 974 condition that might arise when one or more metadata items are
yuuji@0 975 modified in another session after the server has sent the
yuuji@0 976 HIGHESTMODSEQ response code and before the client was able to issue a
yuuji@0 977 CONDSTORE enabling command.
yuuji@0 978
yuuji@0 979 Example 18:
yuuji@0 980
yuuji@0 981 C: A142 SELECT INBOX (CONDSTORE)
yuuji@0 982 S: * 172 EXISTS
yuuji@0 983 S: * 1 RECENT
yuuji@0 984 S: * OK [UNSEEN 12] Message 12 is first unseen
yuuji@0 985 S: * OK [UIDVALIDITY 3857529045] UIDs valid
yuuji@0 986 S: * OK [UIDNEXT 4392] Predicted next UID
yuuji@0 987 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
yuuji@0 988 S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
yuuji@0 989 S: * OK [HIGHESTMODSEQ 715194045007]
yuuji@0 990 S: A142 OK [READ-WRITE] SELECT completed, CONDSTORE is now enabled
yuuji@0 991
yuuji@0 992 3.8. Additional Quality-of-Implementation Issues
yuuji@0 993
yuuji@0 994 Server implementations should follow the following rule, which
yuuji@0 995 applies to any successfully completed STORE/UID STORE (with and
yuuji@0 996 without UNCHANGEDSINCE modifier), as well as to a FETCH command that
yuuji@0 997 implicitly sets \Seen flag:
yuuji@0 998
yuuji@0 999 Adding the flag when it is already present or removing when it is
yuuji@0 1000 not present SHOULD NOT change the mod-sequence.
yuuji@0 1001
yuuji@0 1002 This will prevent spurious client synchronization requests.
yuuji@0 1003
yuuji@0 1004
yuuji@0 1005
yuuji@0 1006
yuuji@0 1007
yuuji@0 1008
yuuji@0 1009
yuuji@0 1010 Melnikov & Hole Standards Track [Page 18]
yuuji@0 1011
yuuji@0 1012 RFC 4551 IMAP Extension for Conditional STORE June 2006
yuuji@0 1013
yuuji@0 1014
yuuji@0 1015 However, note that client implementers MUST NOT rely on this server
yuuji@0 1016 behavior. A client can't distinguish between the case when a server
yuuji@0 1017 has violated the SHOULD mentioned above, and that when one or more
yuuji@0 1018 clients set and unset (or unset and set) the flag in another session.
yuuji@0 1019
yuuji@0 1020 4. Formal Syntax
yuuji@0 1021
yuuji@0 1022 The following syntax specification uses the Augmented Backus-Naur
yuuji@0 1023 Form (ABNF) [ABNF] notation. Elements not defined here can be found
yuuji@0 1024 in the formal syntax of the ABNF [ABNF], IMAP [IMAP4], and IMAP ABNF
yuuji@0 1025 extensions [IMAPABNF] specifications.
yuuji@0 1026
yuuji@0 1027 Except as noted otherwise, all alphabetic characters are case-
yuuji@0 1028 insensitive. The use of upper- or lowercase characters to define
yuuji@0 1029 token strings is for editorial clarity only. Implementations MUST
yuuji@0 1030 accept these strings in a case-insensitive fashion.
yuuji@0 1031
yuuji@0 1032 capability =/ "CONDSTORE"
yuuji@0 1033
yuuji@0 1034 status-att =/ "HIGHESTMODSEQ"
yuuji@0 1035 ;; extends non-terminal defined in RFC 3501.
yuuji@0 1036
yuuji@0 1037 status-att-val =/ "HIGHESTMODSEQ" SP mod-sequence-valzer
yuuji@0 1038 ;; extends non-terminal defined in [IMAPABNF].
yuuji@0 1039 ;; Value 0 denotes that the mailbox doesn't
yuuji@0 1040 ;; support persistent mod-sequences
yuuji@0 1041 ;; as described in Section 3.1.2
yuuji@0 1042
yuuji@0 1043 store-modifier =/ "UNCHANGEDSINCE" SP mod-sequence-valzer
yuuji@0 1044 ;; Only a single "UNCHANGEDSINCE" may be
yuuji@0 1045 ;; specified in a STORE operation
yuuji@0 1046
yuuji@0 1047 fetch-modifier =/ chgsince-fetch-mod
yuuji@0 1048 ;; conforms to the generic "fetch-modifier"
yuuji@0 1049 ;; syntax defined in [IMAPABNF].
yuuji@0 1050
yuuji@0 1051 chgsince-fetch-mod = "CHANGEDSINCE" SP mod-sequence-value
yuuji@0 1052 ;; CHANGEDSINCE FETCH modifier conforms to
yuuji@0 1053 ;; the fetch-modifier syntax
yuuji@0 1054
yuuji@0 1055 fetch-att =/ fetch-mod-sequence
yuuji@0 1056 ;; modifies original IMAP4 fetch-att
yuuji@0 1057
yuuji@0 1058 fetch-mod-sequence = "MODSEQ"
yuuji@0 1059
yuuji@0 1060 fetch-mod-resp = "MODSEQ" SP "(" permsg-modsequence ")"
yuuji@0 1061
yuuji@0 1062 msg-att-dynamic =/ fetch-mod-resp
yuuji@0 1063
yuuji@0 1064
yuuji@0 1065
yuuji@0 1066 Melnikov & Hole Standards Track [Page 19]
yuuji@0 1067
yuuji@0 1068 RFC 4551 IMAP Extension for Conditional STORE June 2006
yuuji@0 1069
yuuji@0 1070
yuuji@0 1071 search-key =/ search-modsequence
yuuji@0 1072 ;; modifies original IMAP4 search-key
yuuji@0 1073 ;;
yuuji@0 1074 ;; This change applies to all commands
yuuji@0 1075 ;; referencing this non-terminal, in
yuuji@0 1076 ;; particular SEARCH.
yuuji@0 1077
yuuji@0 1078 search-modsequence = "MODSEQ" [search-modseq-ext] SP
yuuji@0 1079 mod-sequence-valzer
yuuji@0 1080
yuuji@0 1081 search-modseq-ext = SP entry-name SP entry-type-req
yuuji@0 1082
yuuji@0 1083 resp-text-code =/ "HIGHESTMODSEQ" SP mod-sequence-value /
yuuji@0 1084 "NOMODSEQ" /
yuuji@0 1085 "MODIFIED" SP set
yuuji@0 1086
yuuji@0 1087 entry-name = entry-flag-name
yuuji@0 1088
yuuji@0 1089 entry-flag-name = DQUOTE "/flags/" attr-flag DQUOTE
yuuji@0 1090 ;; each system or user defined flag <flag>
yuuji@0 1091 ;; is mapped to "/flags/<flag>".
yuuji@0 1092 ;;
yuuji@0 1093 ;; <entry-flag-name> follows the escape rules
yuuji@0 1094 ;; used by "quoted" string as described in
yuuji@0 1095 ;; Section 4.3 of [IMAP4], e.g., for the flag
yuuji@0 1096 ;; \Seen the corresponding <entry-name> is
yuuji@0 1097 ;; "/flags/\\seen", and for the flag
yuuji@0 1098 ;; $MDNSent, the corresponding <entry-name>
yuuji@0 1099 ;; is "/flags/$mdnsent".
yuuji@0 1100
yuuji@0 1101 entry-type-resp = "priv" / "shared"
yuuji@0 1102 ;; metadata item type
yuuji@0 1103
yuuji@0 1104 entry-type-req = entry-type-resp / "all"
yuuji@0 1105 ;; perform SEARCH operation on private
yuuji@0 1106 ;; metadata item, shared metadata item or both
yuuji@0 1107
yuuji@0 1108 permsg-modsequence = mod-sequence-value
yuuji@0 1109 ;; per message mod-sequence
yuuji@0 1110
yuuji@0 1111 mod-sequence-value = 1*DIGIT
yuuji@0 1112 ;; Positive unsigned 64-bit integer
yuuji@0 1113 ;; (mod-sequence)
yuuji@0 1114 ;; (1 <= n < 18,446,744,073,709,551,615)
yuuji@0 1115
yuuji@0 1116 mod-sequence-valzer = "0" / mod-sequence-value
yuuji@0 1117
yuuji@0 1118 search-sort-mod-seq = "(" "MODSEQ" SP mod-sequence-value ")"
yuuji@0 1119
yuuji@0 1120
yuuji@0 1121
yuuji@0 1122 Melnikov & Hole Standards Track [Page 20]
yuuji@0 1123
yuuji@0 1124 RFC 4551 IMAP Extension for Conditional STORE June 2006
yuuji@0 1125
yuuji@0 1126
yuuji@0 1127 select-param =/ condstore-param
yuuji@0 1128 ;; conforms to the generic "select-param"
yuuji@0 1129 ;; non-terminal syntax defined in [IMAPABNF].
yuuji@0 1130
yuuji@0 1131 condstore-param = "CONDSTORE"
yuuji@0 1132
yuuji@0 1133 mailbox-data =/ "SEARCH" [1*(SP nz-number) SP
yuuji@0 1134 search-sort-mod-seq]
yuuji@0 1135
yuuji@0 1136 attr-flag = "\\Answered" / "\\Flagged" / "\\Deleted" /
yuuji@0 1137 "\\Seen" / "\\Draft" / attr-flag-keyword /
yuuji@0 1138 attr-flag-extension
yuuji@0 1139 ;; Does not include "\\Recent"
yuuji@0 1140
yuuji@0 1141 attr-flag-extension = "\\" atom
yuuji@0 1142 ;; Future expansion. Client implementations
yuuji@0 1143 ;; MUST accept flag-extension flags. Server
yuuji@0 1144 ;; implementations MUST NOT generate
yuuji@0 1145 ;; flag-extension flags except as defined by
yuuji@0 1146 ;; future standard or standards-track
yuuji@0 1147 ;; revisions of [IMAP4].
yuuji@0 1148
yuuji@0 1149 attr-flag-keyword = atom
yuuji@0 1150
yuuji@0 1151 5. Server Implementation Considerations
yuuji@0 1152
yuuji@0 1153 This section describes how a server implementation that doesn't store
yuuji@0 1154 separate per-metadata mod-sequences for different metadata items can
yuuji@0 1155 avoid sending the MODIFIED response to any of the following
yuuji@0 1156 conditional STORE operations:
yuuji@0 1157
yuuji@0 1158 +FLAGS
yuuji@0 1159 -FLAGS
yuuji@0 1160 +FLAGS.SILENT
yuuji@0 1161 -FLAGS.SILENT
yuuji@0 1162
yuuji@0 1163 Note that the optimization described in this section can't be
yuuji@0 1164 performed in case of a conditional STORE FLAGS operation.
yuuji@0 1165
yuuji@0 1166 Let's use the following example. The client has issued
yuuji@0 1167
yuuji@0 1168 C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000)
yuuji@0 1169 +FLAGS.SILENT ($Processed)
yuuji@0 1170
yuuji@0 1171 When the server receives the command and parses it successfully, it
yuuji@0 1172 iterates through the message set and tries to execute the conditional
yuuji@0 1173 STORE command for each message.
yuuji@0 1174
yuuji@0 1175
yuuji@0 1176
yuuji@0 1177
yuuji@0 1178 Melnikov & Hole Standards Track [Page 21]
yuuji@0 1179
yuuji@0 1180 RFC 4551 IMAP Extension for Conditional STORE June 2006
yuuji@0 1181
yuuji@0 1182
yuuji@0 1183 Each server internally works as a client, i.e., it has to cache the
yuuji@0 1184 current state of all IMAP flags as it is known to the client. In
yuuji@0 1185 order to report flag changes to the client, the server compares the
yuuji@0 1186 cached values with the values in its database for IMAP flags.
yuuji@0 1187
yuuji@0 1188 Imagine that another client has changed the state of a flag \Deleted
yuuji@0 1189 on the message 101 and that the change updated the mod-sequence for
yuuji@0 1190 the message. The server knows that the mod-sequence for the mailbox
yuuji@0 1191 has changed; however, it also knows that:
yuuji@0 1192
yuuji@0 1193 a) the client is not interested in \Deleted flag, as it hasn't
yuuji@0 1194 included it in +FLAGS.SILENT operation; and
yuuji@0 1195
yuuji@0 1196 b) the state of the flag $Processed hasn't changed (the server can
yuuji@0 1197 determine this by comparing cached flag state with the state of
yuuji@0 1198 the flag in the database).
yuuji@0 1199
yuuji@0 1200 Therefore, the server doesn't have to report MODIFIED to the client.
yuuji@0 1201 Instead, the server may set $Processed flag, update the mod-sequence
yuuji@0 1202 for the message 101 once again and send an untagged FETCH response
yuuji@0 1203 with new mod-sequence and flags:
yuuji@0 1204
yuuji@0 1205 S: * 101 FETCH (MODSEQ (303011130956)
yuuji@0 1206 FLAGS ($Processed \Deleted \Answered))
yuuji@0 1207
yuuji@0 1208 See also Section 3.8 for additional quality-of-implementation issues.
yuuji@0 1209
yuuji@0 1210 6. Security Considerations
yuuji@0 1211
yuuji@0 1212 It is believed that the Conditional STORE extension doesn't raise any
yuuji@0 1213 new security concerns that are not already discussed in [IMAP4].
yuuji@0 1214 However, the availability of this extension may make it possible for
yuuji@0 1215 IMAP4 to be used in critical applications it could not be used for
yuuji@0 1216 previously, making correct IMAP server implementation and operation
yuuji@0 1217 even more important.
yuuji@0 1218
yuuji@0 1219 7. IANA Considerations
yuuji@0 1220
yuuji@0 1221 IMAP4 capabilities are registered by publishing a standards track or
yuuji@0 1222 IESG approved experimental RFC. The registry is currently located
yuuji@0 1223 at:
yuuji@0 1224
yuuji@0 1225 http://www.iana.org/assignments/imap4-capabilities
yuuji@0 1226
yuuji@0 1227 This document defines the CONDSTORE IMAP capability. IANA has added
yuuji@0 1228 it to the registry accordingly.
yuuji@0 1229
yuuji@0 1230
yuuji@0 1231
yuuji@0 1232
yuuji@0 1233
yuuji@0 1234 Melnikov & Hole Standards Track [Page 22]
yuuji@0 1235
yuuji@0 1236 RFC 4551 IMAP Extension for Conditional STORE June 2006
yuuji@0 1237
yuuji@0 1238
yuuji@0 1239 8. References
yuuji@0 1240
yuuji@0 1241 8.1. Normative References
yuuji@0 1242
yuuji@0 1243 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
yuuji@0 1244 Requirement Levels", BCP 14, RFC 2119, March 1997.
yuuji@0 1245
yuuji@0 1246 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
yuuji@0 1247 Specifications: ABNF", RFC 4234, October 2005.
yuuji@0 1248
yuuji@0 1249 [IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
yuuji@0 1250 4rev1", RFC 3501, March 2003.
yuuji@0 1251
yuuji@0 1252 [IMAPABNF] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4
yuuji@0 1253 ABNF", RFC 4466, April 2006.
yuuji@0 1254
yuuji@0 1255 8.2. Informative References
yuuji@0 1256
yuuji@0 1257 [ACAP] Newman, C. and J. Myers, "ACAP -- Application
yuuji@0 1258 Configuration Access Protocol", RFC 2244, November 1997.
yuuji@0 1259
yuuji@0 1260 [ACL] Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
yuuji@0 1261 RFC 4314, December 2005.
yuuji@0 1262
yuuji@0 1263 [ANN] Daboo, C. and R. Gellens, "IMAP ANNOTATE Extension", Work
yuuji@0 1264 in Progress, March 2006.
yuuji@0 1265
yuuji@0 1266 [NTP] Mills, D., "Network Time Protocol (Version 3)
yuuji@0 1267 Specification, Implementation and Analysis", RFC 1305,
yuuji@0 1268 March 1992.
yuuji@0 1269
yuuji@0 1270 [RFC-2180] Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC
yuuji@0 1271 2180, July 1997.
yuuji@0 1272
yuuji@0 1273 9. Acknowledgements
yuuji@0 1274
yuuji@0 1275 Some text was borrowed from "IMAP ANNOTATE Extension" [ANN] by
yuuji@0 1276 Randall Gellens and Cyrus Daboo and from "ACAP -- Application
yuuji@0 1277 Configuration Access Protocol" [ACAP] by Chris Newman and John Myers.
yuuji@0 1278
yuuji@0 1279 Many thanks to Randall Gellens for his thorough review of the
yuuji@0 1280 document.
yuuji@0 1281
yuuji@0 1282 The authors also acknowledge the feedback provided by Cyrus Daboo,
yuuji@0 1283 Larry Greenfield, Chris Newman, Harrie Hazewinkel, Arnt Gulbrandsen,
yuuji@0 1284 Timo Sirainen, Mark Crispin, Ned Freed, Ken Murchison, and Dave
yuuji@0 1285 Cridland.
yuuji@0 1286
yuuji@0 1287
yuuji@0 1288
yuuji@0 1289
yuuji@0 1290 Melnikov & Hole Standards Track [Page 23]
yuuji@0 1291
yuuji@0 1292 RFC 4551 IMAP Extension for Conditional STORE June 2006
yuuji@0 1293
yuuji@0 1294
yuuji@0 1295 Authors' Addresses
yuuji@0 1296
yuuji@0 1297 Alexey Melnikov
yuuji@0 1298 Isode Limited
yuuji@0 1299 5 Castle Business Village
yuuji@0 1300 36 Station Road
yuuji@0 1301 Hampton, Middlesex
yuuji@0 1302 TW12 2BX,
yuuji@0 1303 United Kingdom
yuuji@0 1304
yuuji@0 1305 EMail: Alexey.Melnikov@isode.com
yuuji@0 1306
yuuji@0 1307
yuuji@0 1308 Steve Hole
yuuji@0 1309 ACI WorldWide/MessagingDirect
yuuji@0 1310 #1807, 10088 102 Ave
yuuji@0 1311 Edmonton, AB
yuuji@0 1312 T5J 2Z1
yuuji@0 1313 Canada
yuuji@0 1314
yuuji@0 1315 EMail: Steve.Hole@messagingdirect.com
yuuji@0 1316
yuuji@0 1317
yuuji@0 1318
yuuji@0 1319
yuuji@0 1320
yuuji@0 1321
yuuji@0 1322
yuuji@0 1323
yuuji@0 1324
yuuji@0 1325
yuuji@0 1326
yuuji@0 1327
yuuji@0 1328
yuuji@0 1329
yuuji@0 1330
yuuji@0 1331
yuuji@0 1332
yuuji@0 1333
yuuji@0 1334
yuuji@0 1335
yuuji@0 1336
yuuji@0 1337
yuuji@0 1338
yuuji@0 1339
yuuji@0 1340
yuuji@0 1341
yuuji@0 1342
yuuji@0 1343
yuuji@0 1344
yuuji@0 1345
yuuji@0 1346 Melnikov & Hole Standards Track [Page 24]
yuuji@0 1347
yuuji@0 1348 RFC 4551 IMAP Extension for Conditional STORE June 2006
yuuji@0 1349
yuuji@0 1350
yuuji@0 1351 Full Copyright Statement
yuuji@0 1352
yuuji@0 1353 Copyright (C) The Internet Society (2006).
yuuji@0 1354
yuuji@0 1355 This document is subject to the rights, licenses and restrictions
yuuji@0 1356 contained in BCP 78, and except as set forth therein, the authors
yuuji@0 1357 retain all their rights.
yuuji@0 1358
yuuji@0 1359 This document and the information contained herein are provided on an
yuuji@0 1360 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
yuuji@0 1361 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
yuuji@0 1362 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
yuuji@0 1363 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
yuuji@0 1364 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
yuuji@0 1365 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
yuuji@0 1366
yuuji@0 1367 Intellectual Property
yuuji@0 1368
yuuji@0 1369 The IETF takes no position regarding the validity or scope of any
yuuji@0 1370 Intellectual Property Rights or other rights that might be claimed to
yuuji@0 1371 pertain to the implementation or use of the technology described in
yuuji@0 1372 this document or the extent to which any license under such rights
yuuji@0 1373 might or might not be available; nor does it represent that it has
yuuji@0 1374 made any independent effort to identify any such rights. Information
yuuji@0 1375 on the procedures with respect to rights in RFC documents can be
yuuji@0 1376 found in BCP 78 and BCP 79.
yuuji@0 1377
yuuji@0 1378 Copies of IPR disclosures made to the IETF Secretariat and any
yuuji@0 1379 assurances of licenses to be made available, or the result of an
yuuji@0 1380 attempt made to obtain a general license or permission for the use of
yuuji@0 1381 such proprietary rights by implementers or users of this
yuuji@0 1382 specification can be obtained from the IETF on-line IPR repository at
yuuji@0 1383 http://www.ietf.org/ipr.
yuuji@0 1384
yuuji@0 1385 The IETF invites any interested party to bring to its attention any
yuuji@0 1386 copyrights, patents or patent applications, or other proprietary
yuuji@0 1387 rights that may cover technology that may be required to implement
yuuji@0 1388 this standard. Please address the information to the IETF at
yuuji@0 1389 ietf-ipr@ietf.org.
yuuji@0 1390
yuuji@0 1391 Acknowledgement
yuuji@0 1392
yuuji@0 1393 Funding for the RFC Editor function is provided by the IETF
yuuji@0 1394 Administrative Support Activity (IASA).
yuuji@0 1395
yuuji@0 1396
yuuji@0 1397
yuuji@0 1398
yuuji@0 1399
yuuji@0 1400
yuuji@0 1401
yuuji@0 1402 Melnikov & Hole Standards Track [Page 25]
yuuji@0 1403

UW-IMAP'd extensions by yuuji