idnits 2.17.1 draft-ietf-lemonade-reconnect-client-04.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 1085. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1096. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1103. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1109. 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 : ---------------------------------------------------------------------------- No issues found here. 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 (April 26, 2007) is 6207 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 906, but not defined == Missing Reference: 'UIDNEXT 550' is mentioned on line 244, but not defined == Missing Reference: 'HIGHESTMODSEQ 90060128194045007' is mentioned on line 245, but not defined == Missing Reference: 'UNSEEN 12' is mentioned on line 905, but not defined == Missing Reference: 'UIDVALIDITY 67890007' is mentioned on line 393, but not defined == Missing Reference: 'UIDNEXT 567' is mentioned on line 295, but not defined == Missing Reference: 'HIGHESTMODSEQ 90060115205545359' is mentioned on line 397, but not defined == Missing Reference: 'UNSEEN 7' is mentioned on line 399, but not defined == Missing Reference: 'UIDNEXT 30013' is mentioned on line 395, but not defined == Missing Reference: 'HIGHESTMODSEQ 20010715194045319' is mentioned on line 612, but not defined == Missing Reference: 'UIDNEXT 201' is mentioned on line 907, but not defined == Missing Reference: 'HIGHESTMODSEQ 20010715194045007' is mentioned on line 910, but not defined ** Obsolete normative reference: RFC 4234 (ref. 'ABNF') (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 4551 (ref. 'CONDSTORE') (Obsoleted by RFC 7162) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) Summary: 4 errors (**), 0 flaws (~~), 13 warnings (==), 7 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 Intended status: Standards Track Isode Ltd 5 Expires: October 28, 2007 C. Wilson 6 Nokia 7 April 26, 2007 9 IMAP4 Extensions for Quick Mailbox Resynchronization 10 draft-ietf-lemonade-reconnect-client-04.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 October 28, 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document defines an IMAP4 extension, which gives an IMAP client 44 the ability to quickly resynchronize any previously opened mailbox as 45 part of the SELECT command, without the need for server-side state or 46 additional client round-trips. This extension also introduces a new 47 response that allows for a more compact representation for a list of 48 expunged messages. 50 Changes since draft-ietf-lemonade-reconnect-client-03.txt 52 o Fixed several typos reported by Randy Gellens. 54 o Fixed a couple of errors in examples and text reported by Dan 55 Karp. 57 Changes since draft-ietf-lemonade-reconnect-client-02.txt 59 o Fixed description of the synchronization sequence to properly 60 describe how HIGHESTMODSEQ is used. 62 o Fixed a couple of errors in ABNF. 64 Changes since draft-ietf-lemonade-reconnect-client-01.txt 66 o Folded the EXPUNGED extension 67 (draft-melnikov-imap-expunged-02.txt) into this document. Updated 68 mailbox synchronization instructions. 70 o Added UID sequence number matching. 72 o Clarified how NOMODSEQ response affects this extension. 74 o Other minor editorial changes and fixes. 76 Changes since draft-ietf-lemonade-reconnect-client-00.txt 78 o Changed server behavior when the specified UIDVALIDITY doesn't 79 match the current. This allows the client to chose how to proceed 80 after that. 82 o If client's UIDVALIDITY doesn't match server's, the server will 83 not return any flags anymore. 85 o Clarified that SELECT (QRESYNC) is a CONDSTORE-enabling command. 87 o Other minor editorial changes and fixes. 89 Table of Contents 91 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 92 2. Introduction and Overview . . . . . . . . . . . . . . . . . . 4 93 3. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 5 94 3.1. QRESYNC parameter to SELECT/EXAMINE . . . . . . . . . . . 5 95 3.2. VANISHED UID FETCH modifier . . . . . . . . . . . . . . . 10 96 3.3. EXPUNGE Command . . . . . . . . . . . . . . . . . . . . . 11 97 3.4. CLOSE Command . . . . . . . . . . . . . . . . . . . . . . 12 98 3.5. UID EXPUNGE Command . . . . . . . . . . . . . . . . . . . 13 99 3.6. VANISHED Response . . . . . . . . . . . . . . . . . . . . 14 100 4. Server implementation considerations . . . . . . . . . . . . . 17 101 4.1. Server implementations that don't store extra state . . . 17 102 4.2. Server implementations storing minimal state . . . . . . . 17 103 4.3. Additional state required on the server . . . . . . . . . 17 104 5. Updated synchronization sequence . . . . . . . . . . . . . . . 19 105 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 21 106 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 107 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 108 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 109 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 110 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 111 10.2. Informative References . . . . . . . . . . . . . . . . . . 24 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 113 Intellectual Property and Copyright Statements . . . . . . . . . . 25 115 1. Requirements notation 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 In examples, "C:" and "S:" indicate lines sent by the client and 122 server respectively. If a single "C:" or "S:" label applies to 123 multiple lines, then the line breaks between those lines are for 124 editorial clarity only and are not part of the actual protocol 125 exchange. 127 Understanding of the IMAP message sequence numbers and UIDs and the 128 EXPUNGE response [RFC3501] is essential when reading this document. 130 [[anchor2: Editorial comments and questions are marked like this.]] 132 2. Introduction and Overview 134 The [CONDSTORE] extension gives a disconnected client ability to 135 quickly resynchronize IMAP flag changes for previously seen messages. 136 This can be done using the CHANGEDSINCE FETCH modifier once a mailbox 137 is opened. In order for the client to discover which messages have 138 been expunged, the client still has to issue a UID FETCH or a UID 139 SEARCH command. This document defines an extension to [CONDSTORE] 140 that allows a reconnecting client to perform full resynchronization, 141 including discovery of expunged messages, in a single round-trip. 142 This extension also introduces a new response VANISHED that allows 143 for a more compact representation for a list of expunged messages. 145 This extension can be useful for mobile clients that can experience 146 frequent disconnects caused by environmental factors (battery life, 147 signal strength, etc.). Such clients need a way to quickly reconnect 148 to the IMAP server, without forcing the user to experience long delay 149 and pay big bills for the amount of traffic generated by 150 resynchronization. 152 By extending the SELECT command to perform the additional 153 resynchronization, this also allows clients to reduce concurrent 154 connections to the IMAP server held purely for the sake of avoiding 155 the resynchronization. 157 [[anchor4: Note to RFC editor: Please change the capability name 158 everywhere to "QRESYNC".]] 160 The quick resync IMAP extension is present if an IMAP4 server returns 161 "X-DRAFT-W02-QRESYNC" as one of the supported capabilities to the 162 CAPABILITY command. Note, that this extension REQUIREs support for 163 the [CONDSTORE] IMAP extension, so it MUST be announced in the 164 CAPABILITY response as well. 166 This document puts additional requirements on a server implementing 167 the [CONDSTORE] extension. Each mailbox that supports persistent 168 storage of mod-sequences, i.e., for which the server has sent a 169 HIGHESTMODSEQ untagged OK response code on a successful SELECT/ 170 EXAMINE, MUST increment the per-mailbox mod-sequence when one or more 171 messages are expunged due to EXPUNGE, UID EXPUNGE or CLOSE; the 172 server MUST associate the incremented mod-sequence with the UIDs of 173 the expunged messages. 175 A client which supports CONDSTORE but not this extension might 176 resynchronize a mailbox and discover that its HIGHESTMODSEQ has 177 increased from the value cached by the client. If the increase is 178 due only to messages having been expunged since the client last 179 synchronized, the client is likely to send a FETCH ... CHANGEDSINCE 180 command that returns no data. Thus, a client which supports 181 CONDSTORE but not this extension might incur a penalty of an unneeded 182 round-trip when resynchronizing some mailboxes (those which have had 183 messages expunged but no flag changes since the last 184 synchronization). 186 This extra round-trip is only incurred by clients that supports 187 CONDSTORE but not this extension, and only when a mailbox has had 188 messages expunged but no flag changes to non-expunged messages. 189 Since CONDSTORE is a relatively new extension, it is thought likely 190 that clients that support it will also support this extension. 192 3. IMAP Protocol Changes 194 3.1. QRESYNC parameter to SELECT/EXAMINE 196 The Quick Resynchronization parameter to SELECT/EXAMINE commands has 197 four arguments: 199 o the last known UIDVALIDITY, 201 o the last known modification sequence 203 o the optional set of known UIDs 205 o an optional parenthesized list of known sequence ranges and their 206 corresponding UIDs. 208 The parameter acts as a CONDSTORE enabling command, as defined in 210 [CONDSTORE]. In other words, the use of the QRESYNC parameter 211 implies the CONDSTORE parameter. The QRESYNC parameter also tells 212 the server that it SHOULD start sending VANISHED responses (see 213 Section 3.6) instead of EXPUNGE responses. This change remains in 214 effect until the connection is closed. 216 Before opening the specified mailbox the server verifies all 217 arguments for syntactic validity. If any parameter is not 218 syntactically valid, the server returns the tagged BAD response, and 219 the mailbox remains unselected. Once the check is done the server 220 opens the mailbox as if no SELECT/EXAMINE parameters are specified 221 (this is subject to processing of other parameters as defined in 222 other extensions). In particular this means that server MUST send 223 all untagged responses as specified in Section 6.3.1/6.3.2 of 224 [RFC3501]. 226 After that the server checks the UIDVALIDITY value provided by the 227 client. If the provided UIDVALIDITY doesn't match the UIDVALIDITY 228 for the mailbox being opened, then the server MUST ignore the 229 remaining parameters and behave as if no dynamic message data 230 changed. The client can discover this situation by comparing the 231 UIDVALIDITY value returned by the server. This behaviour allows the 232 client not to synchronize the mailbox or decide on the best 233 synchronization strategy. 235 Example: Attempting to resynchronize INBOX, but the provided 236 UIDVALIDITY parameter doesn't match the current UIDVALIDITY 237 value. 239 C: A02 SELECT INBOX (QRESYNC (67890007 20050715194045000 240 41,43:211,214:541)) 241 S: * 464 EXISTS 242 S: * 3 RECENT 243 S: * OK [UIDVALIDITY 3857529045] UIDVALIDITY 244 S: * OK [UIDNEXT 550] Predicted next UID 245 S: * OK [HIGHESTMODSEQ 90060128194045007] 246 S: * OK [UNSEEN 12] Message 12 is first unseen 247 S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) 248 S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft 249 \Deleted \Seen \*)] Permanent flags 250 S: A02 OK [READ-WRITE] Sorry, UIDVALIDITY mismatch 252 Modification Sequence and UID Parameters: 254 A server that doesn't support the persistent storage of mod-sequences 255 for the mailbox MUST send the OK untagged response including the 256 NOMODSEQ response code with every successful SELECT or EXAMINE 257 command, as described in [CONDSTORE]. Such server doesn't need to 258 remember mod-sequences for expunged messages in the mailbox. It MUST 259 ignore the remaining parameters and behave as if no dynamic message 260 data changed. 262 However, whether the server returns the HIGHESTMODSEQ or the NOMODSEQ 263 response code, the QRESYNC parameter still enables the use of the 264 VANISHED response in lieu of the EXPUNGE response Section 3.6. 266 If the provided UIDVALIDITY matches that of the selected mailbox, the 267 server then checks the last known modification sequence. 268 The server sends the client any pending flag changes (using FETCH 269 responses that MUST contain UIDs) and expunges that have occurred in 270 this mailbox since the provided modification sequence. 272 If the list of known UIDs was also provided, the server should only 273 report flag changes and expunges for the provided messages. If the 274 client did not provide the list of UIDs, the server acts as if the 275 client has specified "1:*". 277 Thus, the client can process just these pending events and need not 278 perform a full resynchronization. Without the message sequence 279 number matching information, the result of this step is semantically 280 equivalent to the client issuing: 281 tag1 UID FETCH "known-uids" (FLAGS) (CHANGEDSINCE 282 "mod-sequence-value" VANISHED) 284 Example: 286 C: A02 SELECT INBOX (QRESYNC (67890007 287 90060115194045000 41,43:211,214:541)) 289 S: * 314 EXISTS 291 S: * 15 RECENT 293 S: * OK [UIDVALIDITY 67890007] UIDVALIDITY 295 S: * OK [UIDNEXT 567] Predicted next UID 297 S: * OK [HIGHESTMODSEQ 90060115205545359] 299 S: * OK [UNSEEN 7] There are some unseen messages in the mailbox 301 S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) 302 S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft 303 \Deleted \Seen \*)] Permanent flags 305 S: * 49 FETCH (UID 117 FLAGS (\Seen \Answered)) 307 S: * 50 FETCH (UID 119 FLAGS (\Draft $MDNSent)) 309 S: ... 311 S: * 100 FETCH (UID 541 FLAGS (\Seen $Forwarded)) 313 S: * VANISHED 41,43:116,118,120:211,214:540 315 S: A02 OK [READ-WRITE] mailbox selected 317 Message sequence match data: 319 A client MAY provide a parenthesized list of a message sequence set 320 and the corresponding UID sets. Both MUST be provided in ascending 321 order. The server uses this data to restrict the range for which it 322 provides expunged message information. 324 Conceptually, the client provides a small sample of sequence numbers 325 for which it knows the corresponding UIDs. The server then compares 326 each sequence number and UID pair the client provides with the 327 current state of the mailbox. If a pair matches, then the client 328 knows of any expunges up to, and including, the message, and thus 329 will not include that range in the VANISHED response, even if the 330 "mod-sequence-value" provided by the client is too old for the server 331 to have data of when those messages were expunged. 333 Thus if the Nth message number in the first set in the list is 4, and 334 the Nth UID in the second set in the list is 8, and the mailbox's 335 fourth message has UID 8, then no UIDs equal to or less than 8 are 336 present in the VANISHED response. If the (N+1)th message number is 337 12, and the (N+1)th UID is 24, and the (N+1)th message in the mailbox 338 has UID 25, then the lowest UID included in the VANISHED response 339 would be 9. 341 In the following two examples, the server is unable to remember 342 expunges at all, and only UIDs with messages divisible by three are 343 present in the mailbox. In the first example, the client does not 344 use the fourth parameter, in the second, it provides it. This 345 example is somewhat extreme, but shows that judicious usage of the 346 sequence match data can save a substantial amount of bandwidth. 348 Example: 350 C: A02 SELECT INBOX (QRESYNC (67890007 351 90060115194045000 1:29997)) 353 S: * 10003 EXISTS 355 S: * 5 RECENT 357 S: * OK [UIDVALIDITY 67890007] UIDVALIDITY 359 S: * OK [UIDNEXT 30013] Predicted next UID 361 S: * OK [HIGHESTMODSEQ 90060115205545359] 363 S: * OK [UNSEEN 7] There are some unseen messages in the mailbox 365 S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) 367 S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft 368 \Deleted \Seen \*)] Permanent flags 370 S: * 9889 FETCH (UID 29667 FLAGS (\Seen \Answered)) 372 S: * 9890 FETCH (UID 29670 FLAGS (\Draft $MDNSent)) 374 S: ... 376 S: * 9999 FETCH (UID 29997 FLAGS (\Seen $Forwarded)) 378 S: * VANISHED 1:2,4:5,7:8,10:11,13:14 [...] 379 29998:29999,30001:30002,30004:30005,30007:30008 381 S: A02 OK [READ-WRITE] mailbox selected 383 Example: 385 C: A02 SELECT INBOX (QRESYNC (67890007 386 90060115194045000 1:29997 (5000,7500,9000,9990:9999 15000, 387 22500,27000,29970,29973,29976,29979,29982,29985,29988,29991, 388 29994,29997)) 390 S: * 10003 EXISTS 392 S: * 5 RECENT 393 S: * OK [UIDVALIDITY 67890007] UIDVALIDITY 395 S: * OK [UIDNEXT 30013] Predicted next UID 397 S: * OK [HIGHESTMODSEQ 90060115205545359] 399 S: * OK [UNSEEN 7] There are some unseen messages in the mailbox 401 S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) 403 S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft 404 \Deleted \Seen \*)] Permanent flags 406 S: * 9889 FETCH (UID 29667 FLAGS (\Seen \Answered)) 408 S: * 9890 FETCH (UID 29670 FLAGS (\Draft $MDNSent)) 410 S: ... 412 S: * 9999 FETCH (UID 29997 FLAGS (\Seen $Forwarded)) 414 S: * VANISHED 29998:29999,30001:30002,30004:30005,30007:30008 416 S: A02 OK [READ-WRITE] mailbox selected 418 3.2. VANISHED UID FETCH modifier 420 [IMAPABNF] has extended the syntax of the FETCH and UID FETCH 421 commands to include an optional FETCH modifier. This document 422 defines a new UID FETCH modifier: VANISHED. 424 Note, that the VANISHED UID FETCH modifier is NOT allowed with a 425 FETCH command. The server MUST return a tagged BAD response if this 426 response is specified as a modifier to the FETCH command. 428 The VANISHED UID FETCH modifier MUST only be specified together with 429 the CHANGEDSINCE UID FETCH modifier. 431 The VANISHED UID FETCH modifier instructs the server to report those 432 messages from the UID set parameter that have been expunged and whose 433 associated modsequence is larger than the specified modsequence. 434 That is, the client requests to be informed of messages from the 435 specified set that were expunged since the specified modsequence. 436 Note that the modsequence(s) associated with these messages were 437 updated when the messages were expunged (as described above). The 438 expunged messages are reported using the VANISHED response as 439 described in Section 3.6, which MUST contain the TAG correlator. 441 Note: a server that receives a modsequence smaller than any of the 442 expunged modsequence it remembers about MUST behave as if it was 443 requested to report all expunged messages from the provided UID set 444 parameter. 446 The VANISHED UID FETCH modifier also instructs the server to replace 447 all further EXPUNGE responses with VANISHED responses. The server 448 MUST do this until the connection is closed. 450 Example 1: Without the VANISHED UID FETCH modifier a CONDSTORE-aware 451 client [CONDSTORE] needs to issue separate commands to learn of flag 452 changes and expunged messages since the last synchronization: 454 C: s100 UID FETCH 300:500 (FLAGS) (CHANGEDSINCE 12345) 455 S: * 1 FETCH (UID 404 MODSEQ (65402) FLAGS (\Seen)) 456 S: * 2 FETCH (UID 406 MODSEQ (75403) FLAGS (\Deleted)) 457 S: * 4 FETCH (UID 408 MODSEQ (29738) FLAGS ($NoJunk 458 $AutoJunk $MDNSent)) 459 S: s100 OK FETCH completed 460 C: s101 UID SEARCH 300:500 461 S: * SEARCH 404 406 407 408 410 412 462 S: s101 OK search completed 464 Where 300 and 500 are the lowest and highest UIDs from client's 465 cache. The second SEARCH response tells the client that the messages 466 with UIDs 407, 410 and 412 are still present, but their flags haven't 467 changed since the specified modification sequence. 469 Using the VANISHED UID FETCH modifier it is sufficient to issue only 470 a single command: 472 C: s100 UID FETCH 300:500 (FLAGS) (CHANGEDSINCE 12345 473 VANISHED) 474 S: * 1 FETCH (UID 404 MODSEQ (65402) FLAGS (\Seen)) 475 S: * 2 FETCH (UID 406 MODSEQ (75403) FLAGS (\Deleted)) 476 S: * 4 FETCH (UID 408 MODSEQ (29738) FLAGS ($NoJunk 477 $AutoJunk $MDNSent)) 478 S: * VANISHED (TAG "s100") 300:310,405,411 479 S: s100 OK FETCH completed 481 3.3. EXPUNGE Command 483 Arguments: none 485 Responses: untagged responses: EXPUNGE or VANISHED 486 Result: OK - expunge completed 487 NO - expunge failure: can't expunge (e.g., permission 488 denied) 489 BAD - command unknown or arguments invalid 491 This section updates the definition of the EXPUNGE command described 492 in section 6.4.3 of [RFC3501]. 494 The EXPUNGE command permanently removes all messages that have the 495 \Deleted flag set from the currently selected mailbox. Before 496 returning an OK to the client, those messages that are removed are 497 reported using a VANISHED response or EXPUNGE responses. 499 If the server is capable of storing modification sequences for the 500 selected mailbox, it MUST increment the per-mailbox mod-sequence if 501 at least one message was permanently removed due to the execution of 502 the EXPUNGE command. For each permanently removed message the server 503 MUST remember the incremented mod-sequence and corresponding UID. If 504 at least one message got expunged, the server MUST send the updated 505 per-mailbox modification sequence using the HIGHESTMODSEQ response 506 code (defined in [CONDSTORE]) in the tagged OK response. 508 Example: C: A202 EXPUNGE 509 S: * 3 EXPUNGE 510 S: * 3 EXPUNGE 511 S: * 5 EXPUNGE 512 S: * 8 EXPUNGE 513 S: A202 OK [HIGHESTMODSEQ 20010715194045319] expunged 515 Note: In this example, messages 3, 4, 7, and 11 had the \Deleted flag 516 set. See the description of the EXPUNGE response in [RFC3501] for 517 further explanation. 519 Note that once the VANISHED response is enabled on the connection the 520 previous example might look like this: 522 Example: C: B202 EXPUNGE 523 S: * VANISHED 405,407,410,425 524 S: B202 OK [HIGHESTMODSEQ 20010715194045319] expunged 526 Here messages with message numbers 3, 4, 7 and 11 have respective 527 UIDs 405, 407, 410 and 425. 529 3.4. CLOSE Command 530 Arguments: none 532 Responses: no specific responses for this command 534 Result: OK - close completed, now in authenticated state 535 BAD - command unknown or arguments invalid 537 This section updates the definition of the CLOSE command described in 538 section 6.4.2 of [RFC3501]. 540 The CLOSE command permanently removes all messages that have the 541 \Deleted flag set from the currently selected mailbox, and returns to 542 the authenticated state from the selected state. No untagged EXPUNGE 543 (or VANISHED) responses are sent. 545 If the server is capable of storing modification sequences for the 546 selected mailbox, it MUST increment the per-mailbox mod-sequence if 547 at least one message was permanently removed due to the execution of 548 the CLOSE command. For each permanently removed message the server 549 MUST remember the incremented mod-sequence and corresponding UID. If 550 at least one message got expunged, the server MUST send the updated 551 per-mailbox modification sequence using the HIGHESTMODSEQ response 552 code (defined in [CONDSTORE]) in the tagged OK response. 554 Example: C: A202 CLOSE 555 S: A202 OK [HIGHESTMODSEQ 20010715194045319] done 557 3.5. UID EXPUNGE Command 559 Arguments: message set 561 Responses: untagged responses: EXPUNGE or VANISHED 563 Result: OK - expunge completed 564 NO - expunge failure: can't expunge (e.g., permission 565 denied) 566 BAD - command unknown or arguments invalid 568 This section updates the definition of the UID EXPUNGE command 569 described in section 2.1 of [UIDPLUS]. Servers that implement both 570 [UIDPLUS] and X-DRAFT-W02-QRESYNC [[anchor11: change before 571 publication]] extensions must implement UID EXPUNGE as described in 572 this section. 574 The UID EXPUNGE command permanently removes from the currently 575 selected mailbox all messages that both have the \Deleted flag set 576 and have a UID that is included in the specified message set. If a 577 message either does not have the \Deleted flag set or has a UID that 578 is not included in the specified message set, it is not affected. 580 This command is particularly useful for disconnected mode clients. 581 By using UID EXPUNGE instead of EXPUNGE when resynchronizing with the 582 server, the client can avoid inadvertently removing any messages that 583 have been marked as \Deleted by other clients between the time that 584 the client was last connected and the time the client resynchronizes. 586 If the server does not support the UIDPLUS capability, the client 587 SHOULD fall back to using the STORE command to temporarily remove the 588 \Deleted flag from messages it does not want to remove, then issuing 589 the EXPUNGE command. Finally, the client SHOULD use the STORE 590 command to restore the \Deleted flag on the messages in which it was 591 temporarily removed. 593 Alternatively, the client MAY fall back to using just the EXPUNGE 594 command, risking the unintended removal of some messages. 596 Before returning an OK to the client, those messages that are removed 597 are reported using a VANISHED response or EXPUNGE responses. 599 If the server is capable of storing modification sequences for the 600 selected mailbox, it MUST increment the per-mailbox mod-sequence if 601 at least one message was permanently removed due to the execution of 602 the UID EXPUNGE command. For each permanently removed message the 603 server MUST remember the incremented mod-sequence and corresponding 604 UID. If at least one message got expunged, the server MUST send the 605 updated per-mailbox modification sequence using the HIGHESTMODSEQ 606 response code (defined in [CONDSTORE]) in the tagged OK response. 608 Example: C: . UID EXPUNGE 3000:3002 609 S: * 3 EXPUNGE 610 S: * 3 EXPUNGE 611 S: * 3 EXPUNGE 612 S: . OK [HIGHESTMODSEQ 20010715194045319] Ok 614 Note: In this example, at least messages with message numbers 3, 4, 615 and 5 (UIDs 3000 to 3002) had the \Deleted flag set. See the 616 description of the EXPUNGE response in [RFC3501] for further 617 explanation. 619 3.6. VANISHED Response 620 Contents: optional correlators 622 list of UIDs 624 The VANISHED response reports that the specified UIDs have been 625 permanently removed from the mailbox. This response is similar to 626 the EXPUNGE response [RFC3501], however it can return information 627 about multiple messages and it returns UIDs instead of message 628 numbers. The first benefit saves bandwidth, while the second is more 629 convenient for clients which only use UIDs to access the IMAP server. 631 The VANISHED response has the same restrictions on when it can be 632 sent as does the EXPUNGE response (see below). 634 The VANISHED response starts with an optional correlator. If it is 635 present and contains the TAG correlator type, then the response is a 636 result of a UID FETCH (VANISHED) or a SELECT/EXAMINE (QRESYNC) 637 command. Other correlators can be added in the future. 639 The VANISHED response is sent as a result of a UID FETCH (VANISHED) 640 command, if the UID set parameter to the UID FETCH (VANISHED) command 641 includes UIDs of messages that are no longer in the mailbox. Such 642 VANISHED response MUST contain the TAG correlator. 644 Once a client has used "(VANISHED)" with a UID FETCH or "(QRESYNC)" 645 with SELECT/EXAMINE command, the server SHOULD use the VANISHED 646 response instead of the EXPUNGE response. The server SHOULD continue 647 using VANISHED in lieu of EXPUNGE for the duration of the connection. 648 In particular this affects the EXPUNGE [RFC3501] and UID EXPUNGE 649 [UIDPLUS] commands, as well as messages expunged in other 650 connections. Such VANISHED response MUST NOT contain the TAG 651 correlator. 653 A VANISHED response sent because of an EXPUNGE or UID EXPUNGE command 654 or because messages were expunged in other connections also 655 decrements the number of messages in the mailbox; it is not necessary 656 for the server to send an EXISTS and/or RECENT response with the new 657 value. It also decrements message sequence numbers for each 658 successive message in the mailbox (see the example at the end of this 659 section). Note that a VANISHED response caused by EXPUNGE/UID 660 EXPUNGE/messages expunged in other connections SHOULD only contain 661 UIDs for messages expunged since the last VANISHED/EXPUNGE response 662 sent for the currently opened mailbox or since the mailbox was 663 opened. That is, servers SHOULD NOT send UIDs for previously 664 expunged messages, unless explicitly requested to do so by the UID 665 FETCH (VANISHED) command. 667 Note that client implementors must take care to properly decrement 668 the number of messages in the mailbox even if a server violates this 669 last SHOULD or repeats the same UID multiple times in the returned 670 UID set. In general this means that a client using this extension 671 should either avoid using message numbers entirely, or have a 672 complete map of UID-to-message mapping for the selected mailbox. 674 A VANISHED response MUST NOT be sent when no command is in progress, 675 nor while responding to a FETCH, STORE, or SEARCH command. This rule 676 is necessary to prevent a loss of synchronization of message sequence 677 numbers between client and server. A command is not "in progress" 678 until the complete command has been received; in particular, a 679 command is not "in progress" during the negotiation of command 680 continuation. 682 Note: UID FETCH, UID STORE, and UID SEARCH are different commands 683 from FETCH, STORE, and SEARCH. A VANISHED response MAY be sent 684 during a UID command. However, the VANISHED response MUST NOT be 685 sent during a UID SEARCH command that contains message numbers in the 686 search criteria. 688 The update from the VANISHED response MUST be recorded by the client. 690 Example: Let's assume that there is the following mapping between 691 message numbers and UIDs in the currently selected mailbox (here "X" 692 marks messages with the \Deleted flag set, and "x" represents UIDs 693 which are not relevant for the example): 695 Message numbers: 1 2 3 4 5 6 7 8 9 10 11 696 UIDs: x 504 505 507 508 x 510 x x x 625 697 \Deleted messages: X X X X 699 In the presence of the extension defined in this document: 701 C: A202 EXPUNGE 702 S: * VANISHED 505,507,510,625 703 S: A202 OK EXPUNGE completed 705 Without the X-DRAFT-W02-QRESYNC [[anchor12: change before 706 publication]] extension the same example might look like: 708 C: A202 EXPUNGE 709 S: * 3 EXPUNGE 710 S: * 3 EXPUNGE 711 S: * 5 EXPUNGE 712 S: * 8 EXPUNGE 713 S: A202 OK EXPUNGE completed 714 (Continuing previous example) If subsequently messages with UIDs 504 715 and 508 got marked as \Deleted: 717 C: A210 EXPUNGE 718 S: * VANISHED 504,508 719 S: A210 OK EXPUNGE completed 721 I.e., the last VANISHED response only contains UIDs of messages 722 expunged since the previous VANISHED response. 724 4. Server implementation considerations 726 This section describes a minimalist implementation, a moderate 727 implementation, and an example of a full implementation. 729 4.1. Server implementations that don't store extra state 731 Strictly speaking, a server implementation that doesn't remember 732 modsequences associated with expunged messages can be considered 733 compliant with this specification. Such implementations return all 734 expunged messages specified in the UID set of the UID FETCH 735 (VANISHED) command every time, without paying attention to the 736 specified CHANGEDSINCE modsequence. Such implementations are 737 discouraged, as they can end up returning VANISHED responses bigger 738 than the result of a UID SEARCH command for the same UID set. 740 Clients which use the message sequence match data can reduce the 741 scope of this VANISHED response substantially in the typical case 742 where expunges have not happened, or happen only toward the end of 743 the mailbox. 745 4.2. Server implementations storing minimal state 747 A server which stores the HIGHESTMODSEQ value at the time of the last 748 EXPUNGE can omit the VANISHED response when a client provides a 749 MODSEQ value that is equal to, or higher than, the current value of 750 this datum - that is, when there have been no EXPUNGEs 752 A client providing message sequence match data can reduce the scope 753 as above. In the case where there have been no expunges, the server 754 can ignore this data. 756 4.3. Additional state required on the server 758 When compared to the [CONDSTORE] extension, this extension requires 759 servers to store additional state associated with expunged messages. 760 Note that implementations are not required to store this state in 761 persistent storage, however use of persistent storage is advisable. 763 One possible way to correctly implement the extension described in 764 this document is to store a queue of pairs. 765 can be represented as a sequence of 766 pairs. 768 When messages are expunged, one or more entry is added to the queue 769 tail. 771 When the server receives a request to return expunged messages since 772 a given modsequence, it will search the queue from the tail (i.e. 773 going from the highest expunged modsequence to the lowest), until it 774 sees the first record with a modsequence less than or equal to the 775 given modsequence, or it reaches the head of the queue. 777 Note that indefinitely storing information about expunged messages 778 can cause storage and related problems for an implementation. In the 779 worst case, this could result in almost 64Gb of storage for each IMAP 780 mailbox. For example, consider an implementation that stores triples for each range of messages 782 expunged at the same time. Each triple requires 16 octets: 4 octets 783 for each of the two UIDs, and 8 octets for the modsequence. Assume a 784 mailbox containing a single message with a UID of 2**32-1 (the 785 maximum possible UID value), where messages had previously existed 786 with UIDs starting at 1, and have been expunged one at a time. For 787 this mailbox alone, storage is required for the triples <1, 1, 788 modseq1>, <2, 2, modseq2>, ..., <2**32-2, 2**32-2, modseq4294967294>. 790 Hence, implementations are encouraged to adopt strategies to protect 791 against such storage problems, such as limiting the size of the queue 792 used to store modsequences for expunged messages and "expiring" older 793 records when this limit is reached. When the selected 794 implementation-specific queue limit is reached, the oldest record(s) 795 are deleted from the queue (Note that such records are located at the 796 queue head). For all such "expired" records the server needs to 797 store a single modsequence, which is the highest modsequence for all 798 "expired" expunged messages. 800 Note that if the client provides the message sequence match data, 801 this can heavily reduce the data cost of sending a complete set of 802 missing UIDs, thus reducing the problems for clients if a server is 803 unable to persist much of this queue. If the queue contains data 804 back to the requested modsequence, this data can be ignored. 806 Also note that if the UIDVALIDITY of the mailbox changes or if the 807 mailbox is deleted, then any state associated with expunged messages 808 MUST be deleted as well. 810 5. Updated synchronization sequence 812 This section updates the description of optimized synchronization in 813 section 6.1 of the [IMAP-DISC]. 815 An advanced disconnected mail client should use the X-DRAFT-W02- 816 QRESYNC [[anchor18: Fix before publication]] and [CONDSTORE] 817 extensions when they are supported by the server. The client uses 818 the value from the HIGHESTMODSEQ OK response code received on mailbox 819 opening to determine if it needs to resynchronize. Once the 820 synchronization is complete it MUST cache the received value (unless 821 the mailbox UIDVALIDITY value has changed; See below). The client 822 MUST update its copy of the HIGHESTMODSEQ value whenever the server 823 sends a subsequent HIGHESTMODSEQ OK response code. 825 The client MUST also take note of any MODSEQ FETCH data items 826 received from the server. Whenever the client receives a tagged 827 response to a command, it calculates the highest value among all 828 MODSEQ FETCH data items received since the last tagged response. If 829 this value is bigger than the client's copy of the HIGHESTMODSEQ 830 value, then the client MUST use this value as its new HIGHESTMODSEQ 831 value. 833 Note: it is not safe to update the client's copy of the HIGHESTMODSEQ 834 value with a MODSEQ FETCH data item value as soon as it is received, 835 because servers are not required to send MODSEQ FETCH data items in 836 increasing modseqence order. This can lead to the client missing 837 some changes in case of connectivity loss. 839 When opening the mailbox for synchronization the client uses QRESYNC 840 parameter to the SELECT/EXAMINE command. The QRESYNC parameter is 841 followed by the UIDVALIDITY and mailbox HIGHESTMODSEQ values, as 842 known to the client. It can be optionally followed by the set of 843 UIDs, for example if the client is only interested in partial 844 synchronization of the mailbox. The client may also transmit a list 845 containing its knowledge of message numbers. 847 If the SELECT/EXAMINE command is successful, the client compares 848 UIDVALIDITY as described in step d)1) in section 3 of the 849 [IMAP-DISC]. If the cached UIDVALIDITY value matches the one 850 returned by the server and the server also returns the HIGHESTMODSEQ 851 response code, then the server reports expunged messages/returns flag 852 changes for all messages specified by the client in the UID set 853 parameter (or for all messages in the mailbox, if the client omitted 854 the UID set parameter). At this point the client is synchronized, 855 except for maybe the new messages. 857 If upon a successful SELECT/EXAMINE (QRESYNC) command the client 858 receives a NOMODSEQ OK untagged response (instead of the 859 HIGHESTMODSEQ response code), it MUST remove the last known 860 HIGHESTMODSEQ value from its cache and follow the more general 861 instructions in section 3 of the [IMAP-DISC]. 863 At this point the client is in sync with the server regarding old 864 messages. This client can now fetch information about new messages 865 (if requested by the user). 867 Step d) ("Server-to-client synchronization") in section 4 of the 868 [IMAP-DISC] in the presence of the X-DRAFT-W02-QRESYNC & CONDSTORE 869 extensions is amended as follows: 871 d) "Server-to-client synchronization" -- for each mailbox that 872 requires synchronization, do the following: 874 1a) Check the mailbox UIDVALIDITY (see section 4.1 of the 875 [IMAP-DISC] for more details) after issuing SELECT/ 876 EXAMINE (QRESYNC) command. If the UIDVALIDITY value 877 returned by the server differs, the client MUST 879 * empty the local cache of that mailbox; 881 * "forget" the cached HIGHESTMODSEQ value for 882 the mailbox; 884 * remove any pending "actions" which refer to 885 UIDs in that mailbox. Note, this doesn't 886 affect actions performed on client generated 887 fake UIDs (see section 5 of the [IMAP-DISC]); 889 * skip steps 1b and 2-II; 891 2) Fetch the current "descriptors"; 893 I) Discover new messages. 895 3) Fetch the bodies of any "interesting" messages that the 896 client doesn't already have. 898 Example: The UIDVALIDITY value is the same, but the HIGHESTMODSEQ 899 value has changed on the server while the client was 900 offline: 902 C: A142 SELECT INBOX (QRESYNC (3857529045 20010715194032001 1:198)) 903 S: * 172 EXISTS 904 S: * 1 RECENT 905 S: * OK [UNSEEN 12] Message 12 is first unseen 906 S: * OK [UIDVALIDITY 3857529045] UIDs valid 907 S: * OK [UIDNEXT 201] Predicted next UID 908 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 909 S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited 910 S: * OK [HIGHESTMODSEQ 20010715194045007] 911 S: * 2 FETCH (UID 6 MODSEQ (20010715205008000) 912 FLAGS (\Deleted)) 913 S: * 5 FETCH (UID 9 MODSEQ (20010715195517000) 914 FLAGS ($NoJunk $AutoJunk $MDNSent)) 915 ... 916 S: * VANISHED 1:5,7:8,10:15 917 S: A142 OK [READ-WRITE] SELECT completed 919 6. Formal Syntax 921 The following syntax specification uses the Augmented Backus-Naur 922 Form (ABNF) notation as specified in [ABNF]. 924 Non-terminals referenced but not defined below are as defined by 925 [RFC3501], [CONDSTORE] or [IMAPABNF]. 927 Except as noted otherwise, all alphabetic characters are case- 928 insensitive. The use of upper or lower case characters to define 929 token strings is for editorial clarity only. Implementations MUST 930 accept these strings in a case-insensitive fashion. 932 capability =/ "X-DRAFT-W02-QRESYNC" 933 ;; [[Note to RFC Editor: fix before 934 ;; publication]] 936 select-param = "QRESYNC" SP "(" uidvalidity SP 937 mod-sequence-value [SP known-uids] 938 [SP seq-match-data] ")" 939 ;; conforms to the generic select-param 940 ;; syntax defined in [IMAPABNF] 942 seq-match-data = "(" known-sequence-set SP known-uid-set ")" 943 uidvalidity = nz-number 945 known-uids = sequence-set 946 ;; sequence of UIDs, "*" is not allowed 948 known-sequence-set = sequence-set 949 ;; set of message numbers corresponding to 950 ;; the UIDs in known-uid-set, in ascending order. 951 ;; * is not allowed. 953 known-uid-set = sequence-set 954 ;; set of UIDs corresponding to the messages in 955 ;; known-sequence-set, in ascending order. 956 ;; * is not allowed. 958 message-data =/ expunged-resp 960 expunged-resp = "VANISHED" [expunge-correlator] SP known-uids 962 expunge-correlator = SP "(" single-exp-correlator 963 *(SP single-exp-correlator) ")" 964 ;; Unless explicitly specified otherwise, 965 ;; all correlator types must be specified 966 ;; only once. 968 single-exp-correlator = "TAG" SP tag-string 969 ;; Correlator type followed by parameters 971 rexpunges-fetch-mod = "VANISHED" 972 ;; VANISHED UID FETCH modifier conforms 973 ;; to the fetch-modifier syntax 974 ;; defined in [IMAPABNF]. It is only 975 ;; allowed in the UID FETCH command. 977 7. Security Considerations 979 As always, it is important to thoroughly test clients and servers 980 implementing this extension, as it changes how the server reports 981 expunged messages to the client. 983 Security considerations relevant to [CONDSTORE] are relevant to this 984 extension. 986 This document doesn't raise any new security concerns not already 987 raised by [CONDSTORE] or [RFC3501]. 989 8. IANA Considerations 991 IMAP4 capabilities are registered by publishing a standards track or 992 IESG approved experimental RFC. The registry is currently located 993 at: 995 http://www.iana.org/assignments/imap4-capabilities 997 This document defines the X-DRAFT-W02-QRESYNC [[anchor22: The final 998 capability name will be chosen during AUTH48]] IMAP capability. IANA 999 is requested to add this capability to the registry. 1001 9. Acknowledgments 1003 Thanks to Steve Hole, Cyrus Daboo and Michael Wener for encouraging 1004 creation of this document. 1006 Valuable comments, both in agreement and in dissent, were received 1007 from Timo Sirainen, Michael Wener, Randall Gellens, Arnt Gulbrandsen, 1008 Peter Coates, Mark Crispin, Elwyn Davies and Dan Karp. 1010 This document takes substantial text from [RFC3501] by Mark Crispin. 1012 10. References 1014 10.1. Normative References 1016 [ABNF] Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for 1017 Syntax Specifications: ABNF", RFC 4234, October 2005. 1019 [CONDSTORE] 1020 Melnikov, A. and S. Hole, "IMAP Extension for Conditional 1021 STORE Operation or Quick Flag Changes Resynchronization", 1022 RFC 4551, June 2006. 1024 [IMAPABNF] 1025 Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 1026 ABNF", RFC 4466, April 2006. 1028 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1029 Requirement Levels", BCP 14, RFC 2119, March 1997. 1031 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1032 4rev1", RFC 3501, March 2003. 1034 [UIDPLUS] Crispin, M., "Internet Message Access Protocol (IMAP) - 1035 UIDPLUS extension", RFC 4315, December 2005. 1037 10.2. Informative References 1039 [IMAP-DISC] 1040 Melnikov, A., "Synchronization Operations For Disconnected 1041 Imap4 Clients", RFC 4549, June 2006. 1043 Authors' Addresses 1045 Alexey Melnikov 1046 Isode Ltd 1047 5 Castle Business Village 1048 36 Station Road 1049 Hampton, Middlesex TW12 2BX 1050 UK 1052 Email: Alexey.Melnikov@isode.com 1054 Dave Cridland 1055 Isode Ltd 1056 5 Castle Business Village 1057 36 Station Road 1058 Hampton, Middlesex TW12 2BX 1059 UK 1061 Email: dave.cridland@isode.com 1063 Corby Wilson 1064 Nokia 1065 5 Wayside Rd. 1066 Burlington, MA 01803 1067 USA 1069 Email: corby@computer.org 1071 Full Copyright Statement 1073 Copyright (C) The IETF Trust (2007). 1075 This document is subject to the rights, licenses and restrictions 1076 contained in BCP 78, and except as set forth therein, the authors 1077 retain all their rights. 1079 This document and the information contained herein are provided on an 1080 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1081 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1082 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1083 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1084 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1085 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1087 Intellectual Property 1089 The IETF takes no position regarding the validity or scope of any 1090 Intellectual Property Rights or other rights that might be claimed to 1091 pertain to the implementation or use of the technology described in 1092 this document or the extent to which any license under such rights 1093 might or might not be available; nor does it represent that it has 1094 made any independent effort to identify any such rights. Information 1095 on the procedures with respect to rights in RFC documents can be 1096 found in BCP 78 and BCP 79. 1098 Copies of IPR disclosures made to the IETF Secretariat and any 1099 assurances of licenses to be made available, or the result of an 1100 attempt made to obtain a general license or permission for the use of 1101 such proprietary rights by implementers or users of this 1102 specification can be obtained from the IETF on-line IPR repository at 1103 http://www.ietf.org/ipr. 1105 The IETF invites any interested party to bring to its attention any 1106 copyrights, patents or patent applications, or other proprietary 1107 rights that may cover technology that may be required to implement 1108 this standard. Please address the information to the IETF at 1109 ietf-ipr@ietf.org. 1111 Acknowledgment 1113 Funding for the RFC Editor function is provided by the IETF 1114 Administrative Support Activity (IASA).