idnits 2.17.1 draft-ietf-lemonade-5162bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1066. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1077. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1084. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1090. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC5162, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 19, 2008) is 5669 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'UIDVALIDITY 3857529045' is mentioned on line 888, but not defined == Missing Reference: 'UIDNEXT 550' is mentioned on line 230, but not defined == Missing Reference: 'HIGHESTMODSEQ 90060128194045007' is mentioned on line 231, but not defined == Missing Reference: 'UNSEEN 12' is mentioned on line 887, but not defined == Missing Reference: 'UIDVALIDITY 67890007' is mentioned on line 356, but not defined == Missing Reference: 'UIDNEXT 30013' is mentioned on line 357, but not defined == Missing Reference: 'HIGHESTMODSEQ 90060115205545359' is mentioned on line 358, but not defined == Missing Reference: 'UNSEEN 7' is mentioned on line 360, but not defined == Missing Reference: 'HIGHESTMODSEQ 20010715194045319' is mentioned on line 565, but not defined == Missing Reference: 'UIDNEXT 201' is mentioned on line 889, but not defined == Missing Reference: 'HIGHESTMODSEQ 20010715194045007' is mentioned on line 892, but not defined ** Obsolete normative reference: RFC 4551 (ref. 'CONDSTORE') (Obsoleted by RFC 7162) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) Summary: 3 errors (**), 0 flaws (~~), 12 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Melnikov 3 Internet-Draft D. Cridland 4 Obsoletes: 5162 (if approved) Isode Ltd 5 Intended status: Standards Track C. Wilson 6 Expires: April 22, 2009 Nokia 7 October 19, 2008 9 IMAP4 Extensions for Quick Mailbox Resynchronization 10 draft-ietf-lemonade-5162bis-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 22, 2009. 37 Abstract 39 This document defines an IMAP4 extension, which gives an IMAP client 40 the ability to quickly resynchronize any previously opened mailbox as 41 part of the SELECT command, without the need for server-side state or 42 additional client round-trips. This extension also introduces a new 43 response that allows for a more compact representation of a list of 44 expunged messages (and always includes the Unique Identifiers (UIDs) 45 expunged). 47 Table of Contents 49 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3 50 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 51 3. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 5 52 3.1. QRESYNC Parameter to SELECT/EXAMINE . . . . . . . . . . . 5 53 3.2. VANISHED UID FETCH Modifier . . . . . . . . . . . . . . . 9 54 3.3. EXPUNGE Command . . . . . . . . . . . . . . . . . . . . . 10 55 3.4. CLOSE Command . . . . . . . . . . . . . . . . . . . . . . 11 56 3.5. UID EXPUNGE Command . . . . . . . . . . . . . . . . . . . 12 57 3.6. VANISHED Response . . . . . . . . . . . . . . . . . . . . 13 58 3.7. CLOSED Response Code . . . . . . . . . . . . . . . . . . . 16 59 4. Server Implementation Considerations . . . . . . . . . . . . . 16 60 4.1. Server Implementations That Don't Store Extra State . . . 16 61 4.2. Server Implementations Storing Minimal State . . . . . . . 16 62 4.3. Additional State Required on the Server . . . . . . . . . 17 63 5. Updated Synchronization Sequence . . . . . . . . . . . . . . . 18 64 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 20 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 67 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 69 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 70 10.2. Informative References . . . . . . . . . . . . . . . . . . 23 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 72 Intellectual Property and Copyright Statements . . . . . . . . . . 25 74 1. Introduction and Overview 76 The [CONDSTORE] extension gives a disconnected client the ability to 77 quickly resynchronize IMAP flag changes for previously seen messages. 78 This can be done using the CHANGEDSINCE FETCH modifier once a mailbox 79 is opened. In order for the client to discover which messages have 80 been expunged, the client still has to issue a UID FETCH or a UID 81 SEARCH command. This document defines an extension to [CONDSTORE] 82 that allows a reconnecting client to perform full resynchronization, 83 including discovery of expunged messages, in a single round-trip. 84 This extension also introduces a new response, VANISHED, that allows 85 for a more compact representation of a list of expunged messages. 87 This extension can be useful for mobile clients that can experience 88 frequent disconnects caused by environmental factors (battery life, 89 signal strength, etc.). Such clients need a way to quickly reconnect 90 to the IMAP server, while minimizing delay experienced by the user as 91 well as the amount of traffic (and hence the expense) generated by 92 resynchronization. 94 By extending the SELECT command to perform the additional 95 resynchronization, this also allows clients to reduce concurrent 96 connections to the IMAP server held purely for the sake of avoiding 97 the resynchronization. 99 The quick resync IMAP extension is present if an IMAP4 server returns 100 "QRESYNC" as one of the supported capabilities to the CAPABILITY 101 command. 103 Servers supporting this extension MUST implement and advertise 104 support for the [ENABLE] IMAP extension. Also, the presence of the 105 "QRESYNC" capability implies support for the [CONDSTORE] IMAP 106 extension even if the "CONDSTORE" capability isn't advertised. A 107 server compliant with this specification is REQUIREd to support 108 "ENABLE QRESYNC" and "ENABLE QRESYNC CONDSTORE" (which are "CONDSTORE 109 enabling commands", as defined in [CONDSTORE], and have identical 110 results), but there is no requirement for a compliant server to 111 support "ENABLE CONDSTORE" by itself. The "ENABLE QRESYNC"/"ENABLE 112 QRESYNC CONDSTORE" command also tells the server that it SHOULD start 113 sending VANISHED responses (see Section 3.6) instead of EXPUNGE 114 responses. This change remains in effect until the connection is 115 closed. 117 For compatibility with clients that only support the [CONDSTORE] IMAP 118 extension, servers SHOULD advertise "CONDSTORE" in the CAPABILITY 119 response as well. 121 Once a "CONDSTORE enabling command" is issued by the client, the 122 server MUST automatically include both UID and mod-sequence data in 123 all subsequent untagged FETCH responses (until the connection is 124 closed), whether they were caused by a regular STORE/UID STORE, a 125 STORE/UID STORE with UNCHANGEDSINCE modifier, or an external agent. 126 Note that this rule doesn't affect untagged FETCH responses caused by 127 a FETCH command that doesn't include UID and/or MODSEQ FETCH data 128 item, or UID FETCH without the MODSEQ FETCH data item. 130 A client making use of this extension MUST issue "ENABLE QRESYNC" 131 once it is authenticated. A server MUST respond with a tagged BAD 132 response if the QRESYNC parameter to the SELECT/EXAMINE command or 133 the VANISHED UID FETCH modifier is specified and the client hasn't 134 issued "ENABLE QRESYNC", or the server has not positively responded 135 to that command with the untagged ENABLED response containing 136 QRESYNC, in the current connection. 138 This document puts additional requirements on a server implementing 139 the [CONDSTORE] extension. Each mailbox that supports persistent 140 storage of mod-sequences, i.e., for which the server has sent a 141 HIGHESTMODSEQ untagged OK response code on a successful SELECT/ 142 EXAMINE, MUST increment the per-mailbox mod-sequence when one or more 143 messages are expunged due to EXPUNGE, UID EXPUNGE or CLOSE; the 144 server MUST associate the incremented mod-sequence with the UIDs of 145 the expunged messages. 147 A client that supports CONDSTORE but not this extension might 148 resynchronize a mailbox and discover that its HIGHESTMODSEQ has 149 increased from the value cached by the client. If the increase is 150 only due to messages having been expunged since the client last 151 synchronized, the client is likely to send a FETCH ... CHANGEDSINCE 152 command that returns no data. Thus, a client that supports CONDSTORE 153 but not this extension might incur a penalty of an unneeded round- 154 trip when resynchronizing some mailboxes (those that have had 155 messages expunged but no flag changes since the last 156 synchronization). 158 This extra round-trip is only incurred by clients that support 159 CONDSTORE but not this extension, and only when a mailbox has had 160 messages expunged but no flag changes to non-expunged messages. 161 Since CONDSTORE is a relatively new extension, it is thought likely 162 that clients that support it will also support this extension. 164 2. Requirements Notation 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in [RFC2119]. 170 In examples, "C:" and "S:" indicate lines sent by the client and 171 server respectively. If a single "C:" or "S:" label applies to 172 multiple lines, then the line breaks between those lines are for 173 editorial clarity only and are not part of the actual protocol 174 exchange. The five characters [...] means that something has been 175 elided. 177 Understanding of the IMAP message sequence numbers and UIDs and the 178 EXPUNGE response [RFC3501] is essential when reading this document. 180 3. IMAP Protocol Changes 182 3.1. QRESYNC Parameter to SELECT/EXAMINE 184 The Quick Resynchronization parameter to SELECT/EXAMINE commands has 185 four arguments: 187 o the last known UIDVALIDITY, 189 o the last known modification sequence, 191 o the optional set of known UIDs, and 193 o an optional parenthesized list of known sequence ranges and their 194 corresponding UIDs. 196 A server MUST respond with a tagged BAD response if the Quick 197 Resynchronization parameter to SELECT/EXAMINE command is specified 198 and the client hasn't issued "ENABLE QRESYNC" in the current 199 connection, or the server has not positively responded to that 200 command with the untagged ENABLED response containing QRESYNC. 202 Before opening the specified mailbox, the server verifies all 203 arguments for syntactic validity. If any parameter is not 204 syntactically valid, the server returns the tagged BAD response, and 205 the mailbox remains unselected. Once the check is done, the server 206 opens the mailbox as if no SELECT/EXAMINE parameters are specified 207 (this is subject to processing of other parameters as defined in 208 other extensions). In particular this means that the server MUST 209 send all untagged responses as specified in Sections 6.3.1 and 6.3.2 210 of [RFC3501]. 212 After that, the server checks the UIDVALIDITY value provided by the 213 client. If the provided UIDVALIDITY doesn't match the UIDVALIDITY 214 for the mailbox being opened, then the server MUST ignore the 215 remaining parameters and behave as if no dynamic message data 216 changed. The client can discover this situation by comparing the 217 UIDVALIDITY value returned by the server. This behavior allows the 218 client not to synchronize the mailbox or decide on the best 219 synchronization strategy. 221 Example: Attempting to resynchronize INBOX, but the provided 222 UIDVALIDITY parameter doesn't match the current UIDVALIDITY 223 value. 225 C: A02 SELECT INBOX (QRESYNC (67890007 20050715194045000 226 41,43:211,214:541)) 227 S: * 464 EXISTS 228 S: * 3 RECENT 229 S: * OK [UIDVALIDITY 3857529045] UIDVALIDITY 230 S: * OK [UIDNEXT 550] Predicted next UID 231 S: * OK [HIGHESTMODSEQ 90060128194045007] Highest mailbox 232 mod-sequence 233 S: * OK [UNSEEN 12] Message 12 is first unseen 234 S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) 235 S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft 236 \Deleted \Seen \*)] Permanent flags 237 S: A02 OK [READ-WRITE] Sorry, UIDVALIDITY mismatch 239 Modification Sequence and UID Parameters: 241 A server that doesn't support the persistent storage of mod-sequences 242 for the mailbox MUST send the OK untagged response including the 243 NOMODSEQ response code with every successful SELECT or EXAMINE 244 command, as described in [CONDSTORE]. Such a server doesn't need to 245 remember mod-sequences for expunged messages in the mailbox. It MUST 246 ignore the remaining parameters and behave as if no dynamic message 247 data changed. 249 If the provided UIDVALIDITY matches that of the selected mailbox, the 250 server then checks the last known modification sequence. 251 The server sends the client any pending flag changes (using FETCH 252 responses that MUST contain UIDs) and expunges those that have 253 occurred in this mailbox since the provided modification sequence. 255 If the list of known UIDs was also provided, the server should only 256 report flag changes and expunges for the specified messages. If the 257 client did not provide the list of UIDs, the server acts as if the 258 client has specified "1:", where is the mailbox's 259 UIDNEXT value minus 1. If the mailbox is empty and never had any 260 messages in it, then lack of the list of UIDs is interpreted as an 261 empty set of UIDs. 263 Thus, the client can process just these pending events and need not 264 perform a full resynchronization. Without the message sequence 265 number matching information, the result of this step is semantically 266 equivalent to the client issuing: 267 tag1 UID FETCH "known-uids" (FLAGS) (CHANGEDSINCE 268 "mod-sequence-value" VANISHED) 270 Example: 271 C: A03 SELECT INBOX (QRESYNC (67890007 272 90060115194045000 41,43:211,214:541)) 273 S: * OK [CLOSED] 274 S: * 314 EXISTS 275 S: * 15 RECENT 276 S: * OK [UIDVALIDITY 67890007] UIDVALIDITY 277 S: * OK [UIDNEXT 567] Predicted next UID 278 S: * OK [HIGHESTMODSEQ 90060115205545359] Highest mailbox mod- 279 sequence 280 S: * OK [UNSEEN 7] There are some unseen messages in the mailbox 281 S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) 282 S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft 283 \Deleted \Seen \*)] Permanent flags 284 S: * VANISHED (EARLIER) 41,43:116,118,120:211,214:540 285 S: * 49 FETCH (UID 117 FLAGS (\Seen \Answered) MODSEQ 286 (90060115194045001)) 287 S: * 50 FETCH (UID 119 FLAGS (\Draft $MDNSent) MODSEQ 288 (90060115194045308)) 289 S: ... 290 S: * 100 FETCH (UID 541 FLAGS (\Seen $Forwarded) MODSEQ 291 (90060115194045001)) 292 S: A03 OK [READ-WRITE] mailbox selected 294 Message sequence match data: 296 A client MAY provide a parenthesized list of a message sequence set 297 and the corresponding UID sets. Both MUST be provided in ascending 298 order. The server uses this data to restrict the range for which it 299 provides expunged message information. 301 Conceptually, the client provides a small sample of sequence numbers 302 for which it knows the corresponding UIDs. The server then compares 303 each sequence number and UID pair the client provides with the 304 current state of the mailbox. If a pair matches, then the client 305 knows of any expunges up to, and including, the message, and thus 306 will not include that range in the VANISHED response, even if the 307 "mod-sequence-value" provided by the client is too old for the server 308 to have data of when those messages were expunged. 310 Thus, if the Nth message number in the first set in the list is 4, 311 and the Nth UID in the second set in the list is 8, and the mailbox's 312 fourth message has UID 8, then no UIDs equal to or less than 8 are 313 present in the VANISHED response. If the (N+1)th message number is 314 12, and the (N+1)th UID is 24, and the (N+1)th message in the mailbox 315 has UID 25, then the lowest UID included in the VANISHED response 316 would be 9. 318 In the following two examples, the server is unable to remember 319 expunges at all, and only UIDs with messages divisible by three are 320 present in the mailbox. In the first example, the client does not 321 use the fourth parameter; in the second, it provides it. This 322 example is somewhat extreme, but shows that judicious usage of the 323 sequence match data can save a substantial amount of bandwidth. 325 Example: 326 C: A04 SELECT INBOX (QRESYNC (67890007 327 90060115194045000 1:29997)) 328 S: * 10003 EXISTS 329 S: * 5 RECENT 330 S: * OK [UIDVALIDITY 67890007] UIDVALIDITY 331 S: * OK [UIDNEXT 30013] Predicted next UID 332 S: * OK [HIGHESTMODSEQ 90060115205545359] Highest mailbox mod- 333 sequence 334 S: * OK [UNSEEN 7] There are some unseen messages in the mailbox 335 S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) 336 S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft 337 \Deleted \Seen \*)] Permanent flags 338 S: * VANISHED (EARLIER) 1:2,4:5,7:8,10:11,13:14 [...] 339 29998:29999,30001:30002,30004:30005,30007:30008 340 S: * 9889 FETCH (UID 29667 FLAGS (\Seen \Answered) MODSEQ 341 (90060115194045027)) 342 S: * 9890 FETCH (UID 29670 FLAGS (\Draft $MDNSent) MODSEQ 343 (90060115194045028)) 344 S: ... 345 S: * 9999 FETCH (UID 29997 FLAGS (\Seen $Forwarded) MODSEQ 346 (90060115194045031)) 347 S: A04 OK [READ-WRITE] mailbox selected 349 Example: 350 C: B04 SELECT INBOX (QRESYNC (67890007 351 90060115194045000 1:29997 (5000,7500,9000,9990:9999 15000, 352 22500,27000,29970,29973,29976,29979,29982,29985,29988,29991, 353 29994,29997))) 354 S: * 10003 EXISTS 355 S: * 5 RECENT 356 S: * OK [UIDVALIDITY 67890007] UIDVALIDITY 357 S: * OK [UIDNEXT 30013] Predicted next UID 358 S: * OK [HIGHESTMODSEQ 90060115205545359] Highest mailbox mod- 359 sequence 360 S: * OK [UNSEEN 7] There are some unseen messages in the mailbox 361 S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) 362 S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft 363 \Deleted \Seen \*)] Permanent flags 364 S: * VANISHED (EARLIER) 29998:29999,30001:30002,30004:30005,30007: 365 30008 366 S: * 9889 FETCH (UID 29667 FLAGS (\Seen \Answered) MODSEQ 367 (90060115194045027)) 368 S: * 9890 FETCH (UID 29670 FLAGS (\Draft $MDNSent) MODSEQ 369 (90060115194045028)) 370 S: ... 371 S: * 9999 FETCH (UID 29997 FLAGS (\Seen $Forwarded) MODSEQ 372 (90060115194045031)) 373 S: B04 OK [READ-WRITE] mailbox selected 375 3.2. VANISHED UID FETCH Modifier 377 [IMAPABNF] has extended the syntax of the FETCH and UID FETCH 378 commands to include an optional FETCH modifier. This document 379 defines a new UID FETCH modifier: VANISHED. 381 Note, that the VANISHED UID FETCH modifier is NOT allowed with a 382 FETCH command. The server MUST return a tagged BAD response if this 383 response is specified as a modifier to the FETCH command. 385 A server MUST respond with a tagged BAD response if the VANISHED UID 386 FETCH modifier is specified and the client hasn't issued "ENABLE 387 QRESYNC" in the current connection. 389 The VANISHED UID FETCH modifier MUST only be specified together with 390 the CHANGEDSINCE UID FETCH modifier. 392 The VANISHED UID FETCH modifier instructs the server to report those 393 messages from the UID set parameter that have been expunged and whose 394 associated mod-sequence is larger than the specified mod-sequence. 395 That is, the client requests to be informed of messages from the 396 specified set that were expunged since the specified mod-sequence. 397 Note that the mod-sequence(s) associated with these messages were 398 updated when the messages were expunged (as described above). The 399 expunged messages are reported using the VANISHED response as 400 described in Section 3.6, which MUST contain the EARLIER tag. Any 401 VANISHED (EARLIER) responses MUST be returned before any FETCH 402 responses, as otherwise the client might get confused about how 403 message numbers map to UIDs. 405 Note: A server that receives a mod-sequence smaller than , 406 where is the value of the smallest expunged mod-sequence 407 it remembers minus one, MUST behave as if it was requested to report 408 all expunged messages from the provided UID set parameter. 410 Example 1: Without the VANISHED UID FETCH modifier, a CONDSTORE-aware 411 client [CONDSTORE] needs to issue separate commands to learn of flag 412 changes and expunged messages since the last synchronization: 414 C: s100 UID FETCH 300:500 (FLAGS) (CHANGEDSINCE 12345) 415 S: * 1 FETCH (UID 404 MODSEQ (65402) FLAGS (\Seen)) 416 S: * 2 FETCH (UID 406 MODSEQ (75403) FLAGS (\Deleted)) 417 S: * 4 FETCH (UID 408 MODSEQ (29738) FLAGS ($NoJunk 418 $AutoJunk $MDNSent)) 419 S: s100 OK FETCH completed 420 C: s101 UID SEARCH 300:500 421 S: * SEARCH 404 406 407 408 410 412 422 S: s101 OK search completed 424 Where 300 and 500 are the lowest and highest UIDs from client's 425 cache. The second SEARCH response tells the client that the messages 426 with UIDs 407, 410, and 412 are still present, but their flags 427 haven't changed since the specified modification sequence. 429 Using the VANISHED UID FETCH modifier, it is sufficient to issue only 430 a single command: 432 C: s100 UID FETCH 300:500 (FLAGS) (CHANGEDSINCE 12345 433 VANISHED) 434 S: * VANISHED (EARLIER) 300:310,405,411 435 S: * 1 FETCH (UID 404 MODSEQ (65402) FLAGS (\Seen)) 436 S: * 2 FETCH (UID 406 MODSEQ (75403) FLAGS (\Deleted)) 437 S: * 4 FETCH (UID 408 MODSEQ (29738) FLAGS ($NoJunk 438 $AutoJunk $MDNSent)) 439 S: s100 OK FETCH completed 441 3.3. EXPUNGE Command 443 Arguments: none 445 Responses: untagged responses: EXPUNGE or VANISHED 447 Result: OK - expunge completed 448 NO - expunge failure: can't expunge (e.g., permission denied) 449 BAD - command unknown or arguments invalid 451 This section updates the definition of the EXPUNGE command described 452 in Section 6.4.3 of [RFC3501]. 454 The EXPUNGE command permanently removes all messages that have the 455 \Deleted flag set from the currently selected mailbox. Before 456 returning an OK to the client, those messages that are removed are 457 reported using a VANISHED response or EXPUNGE responses. 459 If the server is capable of storing modification sequences for the 460 selected mailbox, it MUST increment the per-mailbox mod-sequence if 461 at least one message was permanently removed due to the execution of 462 the EXPUNGE command. For each permanently removed message, the 463 server MUST remember the incremented mod-sequence and corresponding 464 UID. If at least one message got expunged, the server MUST send the 465 updated per-mailbox modification sequence using the HIGHESTMODSEQ 466 response code (defined in [CONDSTORE]) in the tagged OK response. 468 Example: C: A202 EXPUNGE 469 S: * 3 EXPUNGE 470 S: * 3 EXPUNGE 471 S: * 5 EXPUNGE 472 S: * 8 EXPUNGE 473 S: A202 OK [HIGHESTMODSEQ 20010715194045319] expunged 475 Note: In this example, messages 3, 4, 7, and 11 had the \Deleted flag 476 set. The first "* 3 EXPUNGE" reports message # 3 as expunged. The 477 second "* 3 EXPUNGE" reports message # 4 as expunged (the message 478 number got decremented due to the previous EXPUNGE response). See 479 the description of the EXPUNGE response in [RFC3501] for further 480 explanation. 482 Note that if the server chooses to always send VANISHED responses 483 instead of EXPUNGE responses, the previous example might look like 484 this: 486 Example: C: B202 EXPUNGE 487 S: * VANISHED 405,407,410,425 488 S: B202 OK [HIGHESTMODSEQ 20010715194045319] expunged 490 Here messages with message numbers 3, 4, 7, and 11 have respective 491 UIDs 405, 407, 410, and 425. 493 3.4. CLOSE Command 495 Arguments: none 497 Responses: no specific responses for this command 498 Result: OK - close completed, now in authenticated state 499 BAD - command unknown or arguments invalid 501 This section updates the definition of the CLOSE command described in 502 Section 6.4.2 of [RFC3501]. 504 The CLOSE command permanently removes all messages that have the 505 \Deleted flag set from the currently selected mailbox, and returns to 506 the authenticated state from the selected state. No untagged EXPUNGE 507 (or VANISHED) responses are sent. 509 If the server is capable of storing modification sequences for the 510 selected mailbox, it MUST increment the per-mailbox mod-sequence if 511 at least one message was permanently removed due to the execution of 512 the CLOSE command. For each permanently removed message, the server 513 MUST remember the incremented mod-sequence and corresponding UID. 514 The server MUST NOT send the updated per-mailbox modification 515 sequence using the HIGHESTMODSEQ response code (defined in 516 [CONDSTORE]) in the tagged OK response, as this might cause loss of 517 synchronization on the client. 519 Example: C: A202 CLOSE 520 S: A202 OK done 522 3.5. UID EXPUNGE Command 524 Arguments: message set 526 Responses: untagged responses: EXPUNGE or VANISHED 528 Result: OK - expunge completed 529 NO - expunge failure: can't expunge (e.g., permission denied) 530 BAD - command unknown or arguments invalid 532 This section updates the definition of the UID EXPUNGE command 533 described in Section 2.1 of [UIDPLUS]. Servers that implement both 534 [UIDPLUS] and QRESYNC extensions must implement UID EXPUNGE as 535 described in this section. 537 The UID EXPUNGE command permanently removes from the currently 538 selected mailbox all messages that both have the \Deleted flag set 539 and have a UID that is included in the specified message set. If a 540 message either does not have the \Deleted flag set or has a UID that 541 is not included in the specified message set, it is not affected. 543 This command is particularly useful for disconnected mode clients. 544 By using UID EXPUNGE instead of EXPUNGE when resynchronizing with the 545 server, the client can avoid inadvertently removing any messages that 546 have been marked as \Deleted by other clients between the time that 547 the client was last connected and the time the client resynchronizes. 549 Before returning an OK to the client, those messages that are removed 550 are reported using a VANISHED response or EXPUNGE responses. 552 If the server is capable of storing modification sequences for the 553 selected mailbox, it MUST increment the per-mailbox mod-sequence if 554 at least one message was permanently removed due to the execution of 555 the UID EXPUNGE command. For each permanently removed message, the 556 server MUST remember the incremented mod-sequence and corresponding 557 UID. If at least one message got expunged, the server MUST send the 558 updated per-mailbox modification sequence using the HIGHESTMODSEQ 559 response code (defined in [CONDSTORE]) in the tagged OK response. 561 Example: C: . UID EXPUNGE 3000:3002 562 S: * 3 EXPUNGE 563 S: * 3 EXPUNGE 564 S: * 3 EXPUNGE 565 S: . OK [HIGHESTMODSEQ 20010715194045319] Ok 567 Note: In this example, at least messages with message numbers 3, 4, 568 and 5 (UIDs 3000 to 3002) had the \Deleted flag set. The first "* 3 569 EXPUNGE" reports message # 3 as expunged. The second "* 3 EXPUNGE" 570 reports message # 4 as expunged (the message number got decremented 571 due to the previous EXPUNGE response). See the description of the 572 EXPUNGE response in [RFC3501] for further explanation. 574 3.6. VANISHED Response 576 Contents: an optional EARLIER tag 578 list of UIDs 580 The VANISHED response reports that the specified UIDs have been 581 permanently removed from the mailbox. This response is similar to 582 the EXPUNGE response [RFC3501]; however, it can return information 583 about multiple messages, and it returns UIDs instead of message 584 numbers. The first benefit saves bandwidth, while the second is more 585 convenient for clients that only use UIDs to access the IMAP server. 587 The VANISHED response has the same restrictions on when it can be 588 sent as does the EXPUNGE response (see below). 590 The VANISHED response has two forms. The first form contains the 591 EARLIER tag, which signifies that the response was caused by a UID 592 FETCH (VANISHED) or a SELECT/EXAMINE (QRESYNC) command. This 593 response is sent if the UID set parameter to the UID FETCH (VANISHED) 594 command includes UIDs of messages that are no longer in the mailbox. 595 When the client sees a VANISHED EARLIER response, it MUST NOT 596 decrement message sequence numbers for each successive message in the 597 mailbox. 599 The second form doesn't contain the EARLIER tag and is described 600 below. Once a client has issued "ENABLE QRESYNC" (and the server has 601 positively responded to that command with the untagged ENABLED 602 response containing QRESYNC), the server SHOULD use the VANISHED 603 response without the EARLIER tag instead of the EXPUNGE response. 604 The server SHOULD continue using VANISHED in lieu of EXPUNGE for the 605 duration of the connection. In particular, this affects the EXPUNGE 606 [RFC3501] and UID EXPUNGE [UIDPLUS] commands, as well as messages 607 expunged in other connections. Such a VANISHED response MUST NOT 608 contain the EARLIER tag. 610 A VANISHED response sent because of an EXPUNGE or UID EXPUNGE command 611 or because messages were expunged in other connections (i.e., the 612 VANISHED response without the EARLIER tag) also decrements the number 613 of messages in the mailbox; it is not necessary for the server to 614 send an EXISTS response with the new value. It also decrements 615 message sequence numbers for each successive message in the mailbox 616 (see the example at the end of this section). Note that a VANISHED 617 response caused by EXPUNGE, UID EXPUNGE, or messages expunged in 618 other connections SHOULD only contain UIDs for messages expunged 619 since the last VANISHED/EXPUNGE response sent for the currently 620 opened mailbox or since the mailbox was opened. That is, servers 621 SHOULD NOT send UIDs for previously expunged messages, unless 622 explicitly requested to do so by the UID FETCH (VANISHED) command. 624 Note that client implementors must take care to properly decrement 625 the number of messages in the mailbox even if a server violates this 626 last SHOULD or repeats the same UID multiple times in the returned 627 UID set. In general, this means that a client using this extension 628 should either avoid using message numbers entirely, or have a 629 complete mapping of UIDs to message sequence numbers for the selected 630 mailbox. 632 Because clients handle the two different forms of the VANISHED 633 response differently, servers MUST NOT report UIDs resulting from a 634 UID FETCH (VANISHED) or a SELECT/EXAMINE (QRESYNC) in the same 635 VANISHED response as UIDs of messages expunged now (i.e., messages 636 expunged in other connections). Instead, the server MUST send 637 separate VANISHED responses: one with the EARLIER tag and one 638 without. 640 A VANISHED response MUST NOT be sent when no command is in progress, 641 nor while responding to a FETCH, STORE, or SEARCH command. This rule 642 is necessary to prevent a loss of synchronization of message sequence 643 numbers between client and server. A command is not "in progress" 644 until the complete command has been received; in particular, a 645 command is not "in progress" during the negotiation of command 646 continuation. 648 Note: UID FETCH, UID STORE, and UID SEARCH are different commands 649 from FETCH, STORE, and SEARCH. A VANISHED response MAY be sent 650 during a UID command. However, the VANISHED response MUST NOT be 651 sent during a UID SEARCH command that contains message numbers in the 652 search criteria. 654 The update from the VANISHED response MUST be recorded by the client. 656 Example: Let's assume that there is the following mapping between 657 message numbers and UIDs in the currently selected mailbox (here "X" 658 marks messages with the \Deleted flag set, and "x" represents UIDs 659 which are not relevant for the example): 661 Message numbers: 1 2 3 4 5 6 7 8 9 10 11 662 UIDs: x 504 505 507 508 x 510 x x x 625 663 \Deleted messages: X X X X 665 In the presence of the extension defined in this document: 667 C: A202 EXPUNGE 668 S: * VANISHED 505,507,510,625 669 S: A202 OK EXPUNGE completed 671 Without the QRESYNC extension, the same example might look like: 673 C: A202 EXPUNGE 674 S: * 3 EXPUNGE 675 S: * 3 EXPUNGE 676 S: * 5 EXPUNGE 677 S: * 8 EXPUNGE 678 S: A202 OK EXPUNGE completed 680 (Continuing previous example) If subsequently messages with UIDs 504 681 and 508 got marked as \Deleted: 683 C: A210 EXPUNGE 684 S: * VANISHED 504,508 685 S: A210 OK EXPUNGE completed 687 i.e., the last VANISHED response only contains UIDs of messages 688 expunged since the previous VANISHED response. 690 3.7. CLOSED Response Code 692 The CLOSED response code has no parameters. A server implementing 693 the extension defined in this document MUST return the CLOSED 694 response code when the currently selected mailbox is closed 695 implicitly using the SELECT/EXAMINE command on another mailbox. The 696 CLOSED response code serves as a boundary between responses for the 697 previously opened mailbox (which was closed) and the newly selected 698 mailbox: all responses before the CLOSED response code relate to the 699 mailbox that was closed, and all subsequent responses relate to the 700 newly opened mailbox. 702 There is no need to return the CLOSED response code on completion of 703 the CLOSE or the UNSELECT [UNSELECT] command (or similar) whose 704 purpose is to close the currently selected mailbox without opening a 705 new one. 707 4. Server Implementation Considerations 709 This section describes a minimalist implementation, a moderate 710 implementation, and an example of a full implementation. 712 4.1. Server Implementations That Don't Store Extra State 714 Strictly speaking, a server implementation that doesn't remember mod- 715 sequences associated with expunged messages can be considered 716 compliant with this specification. Such implementations return all 717 expunged messages specified in the UID set of the UID FETCH 718 (VANISHED) command every time, without paying attention to the 719 specified CHANGEDSINCE mod-sequence. Such implementations are 720 discouraged, as they can end up returning VANISHED responses that are 721 bigger than the result of a UID SEARCH command for the same UID set. 723 Clients that use the message sequence match data can reduce the scope 724 of this VANISHED response substantially in the typical case where 725 expunges have not happened, or happen only toward the end of the 726 mailbox. 728 4.2. Server Implementations Storing Minimal State 730 A server that stores the HIGHESTMODSEQ value at the time of the last 731 EXPUNGE can omit the VANISHED response when a client provides a 732 MODSEQ value that is equal to, or higher than, the current value of 733 this datum, that is, when there have been no EXPUNGEs. 735 A client providing message sequence match data can reduce the scope 736 as above. In the case where there have been no expunges, the server 737 can ignore this data. 739 4.3. Additional State Required on the Server 741 When compared to the [CONDSTORE] extension, this extension requires 742 servers to store additional state associated with expunged messages. 743 Note that implementations are not required to store this state in 744 persistent storage; however, use of persistent storage is advisable. 746 One possible way to correctly implement the extension described in 747 this document is to store a queue of pairs. 748 can be represented as a sequence of 749 pairs. 751 When messages are expunged, one or more entries are added to the 752 queue tail. 754 When the server receives a request to return messages expunged since 755 a given mod-sequence, it will search the queue from the tail (i.e., 756 going from the highest expunged mod-sequence to the lowest) until it 757 sees the first record with a mod-sequence less than or equal to the 758 given mod-sequence or it reaches the head of the queue. 760 Note that indefinitely storing information about expunged messages 761 can cause storage and related problems for an implementation. In the 762 worst case, this could result in almost 64Gb of storage for each IMAP 763 mailbox. For example, consider an implementation that stores triples for each range of messages 765 expunged at the same time. Each triple requires 16 octets: 4 octets 766 for each of the two UIDs, and 8 octets for the mod-sequence. Assume 767 that there is a mailbox containing a single message with a UID of 768 2**32-1 (the maximum possible UID value), where messages had 769 previously existed with UIDs starting at 1, and have been expunged 770 one at a time. For this mailbox alone, storage is required for the 771 triples <1, 1, modseq1>, <2, 2, modseq2>, ..., <2**32-2, 2**32-2, 772 modseq4294967294>. 774 Hence, implementations are encouraged to adopt strategies to protect 775 against such storage problems, such as limiting the size of the queue 776 used to store mod-sequences for expunged messages and "expiring" 777 older records when this limit is reached. When the selected 778 implementation-specific queue limit is reached, the oldest record(s) 779 are deleted from the queue (note that such records are located at the 780 queue head). For all such "expired" records, the server needs to 781 store a single mod-sequence, which is the highest mod-sequence for 782 all "expired" expunged messages. 784 Note that if the client provides the message sequence match data, 785 this can heavily reduce the data cost of sending a complete set of 786 missing UIDs; thus, reducing the problems for clients if a server is 787 unable to persist much of this queue. If the queue contains data 788 back to the requested mod-sequence, this data can be ignored. 790 Also, note that if the UIDVALIDITY of the mailbox changes or if the 791 mailbox is deleted, then any state associated with expunged messages 792 doesn't need to be preserved and SHOULD be deleted. 794 5. Updated Synchronization Sequence 796 This section updates the description of optimized synchronization in 797 Section 6.1 of the [IMAP-DISC]. 799 An advanced disconnected mail client should use the QRESYNC and 800 [CONDSTORE] extensions when they are supported by the server. The 801 client uses the value from the HIGHESTMODSEQ OK response code 802 received on mailbox opening to determine if it needs to 803 resynchronize. Once the synchronization is complete, it MUST cache 804 the received value (unless the mailbox UIDVALIDITY value has changed; 805 see below). The client MUST update its copy of the HIGHESTMODSEQ 806 value whenever the server sends a subsequent HIGHESTMODSEQ OK 807 response code. 809 After completing a full synchronization, the client MUST also take 810 note of any unsolicited MODSEQ FETCH data items received from the 811 server. Whenever the client receives a tagged response to a command, 812 it calculates the highest value among all MODSEQ FETCH data items 813 received since the last tagged response. If this value is bigger 814 than the client's copy of the HIGHESTMODSEQ value, then the client 815 MUST use this value as its new HIGHESTMODSEQ value. 817 Note: It is not safe to update the client's copy of the HIGHESTMODSEQ 818 value with a MODSEQ FETCH data item value as soon as it is received 819 because servers are not required to send MODSEQ FETCH data items in 820 increasing modseqence order. This can lead to the client missing 821 some changes in case of connectivity loss. 823 When opening the mailbox for synchronization, the client uses the 824 QRESYNC parameter to the SELECT/EXAMINE command. The QRESYNC 825 parameter is followed by the UIDVALIDITY and mailbox HIGHESTMODSEQ 826 values, as known to the client. It can be optionally followed by the 827 set of UIDs, for example, if the client is only interested in partial 828 synchronization of the mailbox. The client may also transmit a list 829 containing its knowledge of message numbers. 831 If the SELECT/EXAMINE command is successful, the client compares 832 UIDVALIDITY as described in step d)1) in Section 3 of the 833 [IMAP-DISC]. If the cached UIDVALIDITY value matches the one 834 returned by the server and the server also returns the HIGHESTMODSEQ 835 response code, then the server reports expunged messages and returns 836 flag changes for all messages specified by the client in the UID set 837 parameter (or for all messages in the mailbox, if the client omitted 838 the UID set parameter). At this point, the client is synchronized, 839 except for maybe the new messages. 841 If upon a successful SELECT/EXAMINE (QRESYNC) command the client 842 receives a NOMODSEQ OK untagged response (instead of the 843 HIGHESTMODSEQ response code), it MUST remove the last known 844 HIGHESTMODSEQ value from its cache and follow the more general 845 instructions in Section 3 of the [IMAP-DISC]. 847 At this point, the client is in sync with the server regarding old 848 messages. This client can now fetch information about new messages 849 (if requested by the user). 851 Step d) ("Server-to-client synchronization") in Section 4 of the 852 [IMAP-DISC] in the presence of the QRESYNC & CONDSTORE extensions is 853 amended as follows: 855 d) "Server-to-client synchronization" -- for each mailbox that 856 requires synchronization, do the following: 858 1a) Check the mailbox UIDVALIDITY (see Section 4.1 of the [IMAP-DISC] 859 for more details) after issuing SELECT/EXAMINE (QRESYNC) command. 861 If the UIDVALIDITY value returned by the server differs, the 862 client MUST 864 * empty the local cache of that mailbox; 866 * "forget" the cached HIGHESTMODSEQ value for the mailbox; 868 * remove any pending "actions" which refer to UIDs in that 869 mailbox. Note, this doesn't affect actions performed on 870 client generated fake UIDs (see Section 5 of the 871 [IMAP-DISC]); 873 2) Fetch the current "descriptors"; 875 I) Discover new messages. 877 3) Fetch the bodies of any "interesting" messages that the client 878 doesn't already have. 880 Example: The UIDVALIDITY value is the same, but the HIGHESTMODSEQ 881 value has changed on the server while the client was 882 offline: 884 C: A142 SELECT INBOX (QRESYNC (3857529045 20010715194032001 1:198)) 885 S: * 172 EXISTS 886 S: * 1 RECENT 887 S: * OK [UNSEEN 12] Message 12 is first unseen 888 S: * OK [UIDVALIDITY 3857529045] UIDs valid 889 S: * OK [UIDNEXT 201] Predicted next UID 890 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 891 S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited 892 S: * OK [HIGHESTMODSEQ 20010715194045007] Highest 893 mailbox mod-sequence 894 S: * VANISHED (EARLIER) 1:5,7:8,10:15 895 S: * 2 FETCH (UID 6 MODSEQ (20010715205008000) 896 FLAGS (\Deleted)) 897 S: * 5 FETCH (UID 9 MODSEQ (20010715195517000) 898 FLAGS ($NoJunk $AutoJunk $MDNSent)) 899 ... 900 S: A142 OK [READ-WRITE] SELECT completed 902 6. Formal Syntax 904 The following syntax specification uses the Augmented Backus-Naur 905 Form (ABNF) notation as specified in [ABNF]. 907 Non-terminals referenced but not defined below are as defined by 908 [RFC3501], [CONDSTORE], or [IMAPABNF]. 910 Except as noted otherwise, all alphabetic characters are case- 911 insensitive. The use of upper or lower case characters to define 912 token strings is for editorial clarity only. Implementations MUST 913 accept these strings in a case-insensitive fashion. 915 capability =/ "QRESYNC" 917 select-param = "QRESYNC" SP "(" uidvalidity SP 918 mod-sequence-value [SP known-uids] 919 [SP seq-match-data] ")" 920 ;; conforms to the generic select-param 921 ;; syntax defined in [IMAPABNF] 923 seq-match-data = "(" known-sequence-set SP known-uid-set ")" 925 uidvalidity = nz-number 927 known-uids = sequence-set 928 ;; sequence of UIDs, "*" is not allowed 930 known-sequence-set = sequence-set 931 ;; set of message numbers corresponding to 932 ;; the UIDs in known-uid-set, in ascending order. 933 ;; * is not allowed. 935 known-uid-set = sequence-set 936 ;; set of UIDs corresponding to the messages in 937 ;; known-sequence-set, in ascending order. 938 ;; * is not allowed. 940 message-data =/ expunged-resp 942 expunged-resp = "VANISHED" [SP "(EARLIER)"] SP known-uids 944 rexpunges-fetch-mod = "VANISHED" 945 ;; VANISHED UID FETCH modifier conforms 946 ;; to the fetch-modifier syntax 947 ;; defined in [IMAPABNF]. It is only 948 ;; allowed in the UID FETCH command. 950 resp-text-code =/ "CLOSED" 952 7. Security Considerations 954 As always, it is important to thoroughly test clients and servers 955 implementing this extension, as it changes how the server reports 956 expunged messages to the client. 958 Security considerations relevant to [CONDSTORE] are relevant to this 959 extension. 961 This document doesn't raise any new security concerns not already 962 raised by [CONDSTORE] or [RFC3501]. 964 8. IANA Considerations 966 IMAP4 capabilities are registered by publishing a standards track or 967 IESG approved experimental RFC. The registry is currently located 968 at: 970 http://www.iana.org/assignments/imap4-capabilities 972 This document defines the QRESYNC IMAP capability. IANA has added 973 this capability to the registry. 975 9. Acknowledgments 977 Thanks to Steve Hole, Cyrus Daboo, and Michael Wener for encouraging 978 creation of this document. 980 Valuable comments, both in agreement and in dissent, were received 981 from Timo Sirainen, Michael Wener, Randall Gellens, Arnt Gulbrandsen, 982 Chris Newman, Peter Coates, Mark Crispin, Elwyn Davies, Dan Karp, 983 Eric Rescorla, Mike Zraly and Alfred Hoenes. 985 This document takes substantial text from [RFC3501] by Mark Crispin. 987 10. References 989 10.1. Normative References 991 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 992 Specifications: ABNF", STD 68, RFC 5234, January 2008. 994 [CONDSTORE] 995 Melnikov, A. and S. Hole, "IMAP Extension for Conditional 996 STORE Operation or Quick Flag Changes Resynchronization", 997 RFC 4551, June 2006. 999 [ENABLE] Gulbrandsen, A., Ed. and A. Melnikov, Ed., "The IMAP 1000 ENABLE Extension", RFC 5161, March 2008. 1002 [IMAPABNF] 1003 Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 1004 ABNF", RFC 4466, April 2006. 1006 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1007 Requirement Levels", BCP 14, RFC 2119, March 1997. 1009 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1010 4rev1", RFC 3501, March 2003. 1012 [UIDPLUS] Crispin, M., "Internet Message Access Protocol (IMAP) - 1013 UIDPLUS extension", RFC 4315, December 2005. 1015 10.2. Informative References 1017 [IMAP-DISC] 1018 Melnikov, A., Ed., "Synchronization Operations For 1019 Disconnected Imap4 Clients", RFC 4549, June 2006. 1021 [UNSELECT] 1022 Melnikov, A., "Internet Message Access Protocol (IMAP) 1023 UNSELECT command", RFC 3691, February 2004. 1025 Authors' Addresses 1027 Alexey Melnikov 1028 Isode Ltd 1029 5 Castle Business Village 1030 36 Station Road 1031 Hampton, Middlesex TW12 2BX 1032 UK 1034 Email: Alexey.Melnikov@isode.com 1036 Dave Cridland 1037 Isode Ltd 1038 5 Castle Business Village 1039 36 Station Road 1040 Hampton, Middlesex TW12 2BX 1041 UK 1043 Email: dave.cridland@isode.com 1044 Corby Wilson 1045 Nokia 1046 5 Wayside Rd. 1047 Burlington, MA 01803 1048 USA 1050 Email: corby@computer.org 1052 Full Copyright Statement 1054 Copyright (C) The IETF Trust (2008). 1056 This document is subject to the rights, licenses and restrictions 1057 contained in BCP 78, and except as set forth therein, the authors 1058 retain all their rights. 1060 This document and the information contained herein are provided on an 1061 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1062 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1063 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1064 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1065 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1066 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1068 Intellectual Property 1070 The IETF takes no position regarding the validity or scope of any 1071 Intellectual Property Rights or other rights that might be claimed to 1072 pertain to the implementation or use of the technology described in 1073 this document or the extent to which any license under such rights 1074 might or might not be available; nor does it represent that it has 1075 made any independent effort to identify any such rights. Information 1076 on the procedures with respect to rights in RFC documents can be 1077 found in BCP 78 and BCP 79. 1079 Copies of IPR disclosures made to the IETF Secretariat and any 1080 assurances of licenses to be made available, or the result of an 1081 attempt made to obtain a general license or permission for the use of 1082 such proprietary rights by implementers or users of this 1083 specification can be obtained from the IETF on-line IPR repository at 1084 http://www.ietf.org/ipr. 1086 The IETF invites any interested party to bring to its attention any 1087 copyrights, patents or patent applications, or other proprietary 1088 rights that may cover technology that may be required to implement 1089 this standard. Please address the information to the IETF at 1090 ietf-ipr@ietf.org.