idnits 2.17.00 (12 Aug 2021) /tmp/idnits19611/draft-ietf-lemonade-reconnect-07.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 976. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 953. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 960. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 966. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([Zoltan]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (June 5, 2006) is 5822 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Zoltan' is mentioned on line 106, but not defined == Missing Reference: 'TRANS-CAPA' is mentioned on line 246, but not defined == Missing Reference: 'UIDVALIDITY 3857529045' is mentioned on line 595, but not defined == Missing Reference: 'UIDNEXT 550' is mentioned on line 596, but not defined == Missing Reference: 'HIGHESTMODSEQ 20060128194045007' is mentioned on line 597, but not defined == Missing Reference: 'UIDVALIDITY 67890007' is mentioned on line 694, but not defined == Missing Reference: 'UIDNEXT 567' is mentioned on line 642, but not defined == Missing Reference: 'HIGHESTMODSEQ 20060115205545359' is mentioned on line 644, but not defined == Missing Reference: 'UIDNEXT 782' is mentioned on line 674, but not defined == Missing Reference: 'HIGHESTMODSEQ 20010715235047007' is mentioned on line 677, but not defined == Missing Reference: 'UIDNEXT 1598' is mentioned on line 695, but not defined == Missing Reference: 'HIGHESTMODSEQ 20010715235047019' is mentioned on line 698, but not defined == Missing Reference: 'UIDVALIDITY 1098183472' is mentioned on line 714, but not defined == Missing Reference: 'UIDNEXT 12' is mentioned on line 715, but not defined == Missing Reference: 'HIGHESTMODSEQ 54' is mentioned on line 716, but not defined == Unused Reference: 'RFC4234' is defined on line 917, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4234 (ref. 'ABNF') (Obsoleted by RFC 5234) -- Possible downref: Non-RFC (?) normative reference: ref. 'CONDSTORE' -- Possible downref: Non-RFC (?) normative reference: ref. 'EXPUNGED' ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) -- Duplicate reference: RFC4234, mentioned in 'RFC4234', was also mentioned in 'ABNF'. ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) Summary: 7 errors (**), 0 flaws (~~), 19 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Melnikov 3 Internet-Draft Isode Ltd 4 Expires: December 7, 2006 C. Wilson 5 Nokia 6 June 5, 2006 8 IMAP4 Extensions for Quick Reconnect 9 draft-ietf-lemonade-reconnect-07.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 7, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document defines a quick reconnect IMAP4 extension, which gives 43 a mobile client the ability to resume a previously abandoned session, 44 without the need to perform a full synchronization sequence. The 45 goal is to minimize the amount of data transfered at login after a 46 dropped connection. 48 Changes since draft-ietf-lemonade-reconnect-06 49 o Multiple spelling and editorial corrections from Arnt, Randy and 50 Dave Cridland. 52 o Renamed FOLDER response to SELECTED and replaced "()" with nothing 53 (i.e. the mailbox name is now optional). 55 o Deleted the requirement to support at least 5 per-user resumable 56 sessions. This is a deployment choice and the client can't rely 57 that there is always a number of sessions available to it. 59 o Define generic syntax for LOGOUT parameters consistent with RFC 60 4466. 62 Changes since draft-ietf-lemonade-reconnect-05 64 o Fixed some formatting issues. 66 o Clarified what state is to be associated with a session. 67 Clarified interaction with IMAP ACL extension. 69 o Clarified that creation of a new session when there is an active 70 one makes the older one inactive. Added DELETEDSID response in 71 order to convey this information. 73 o Clarified that the server can still return NO if per-user limit on 74 number of sessions is reached and all of them are active. 76 o Added paragraph clarifying that any session can only be active on 77 a single TCP connection at a time. 79 o Clarified that if (on session resumption) UIDVALIDITY provided by 80 the client doesn't match the server's value, than the mailbox is 81 selected in the same read-write mode as it was originally 82 selected, but all other state must be forgotten. 84 o Specified that the second (and subsequent) request to create a new 85 session is treated as the first one. (Behavior change from -05) 87 o Added the DELETESID command that allows to terminate a no longer 88 needed resumable session without the need to close the connection. 90 Changes since draft-ietf-lemonade-reconnect-04 92 o Spelling/wording corrections from Zoltan. 94 o Replaced extended Login/Authenticate with a new SID command. This 95 made the document much simpler. 97 o Removed the NOSID untagged response as the SID command can return 98 the tagged NO response. 100 o Made UIDVALIDITY/modification sequence parameters to the SID 101 command required if the SID parameter is also specified. 103 o Made UNSEEN untagged OK response optional. 105 o Specified that LOGOUT (PRESERVE) should be just treated as LOGOUT 106 if there is no active session. [Zoltan] 108 o Specified that the second (and subsequent) request to create a new 109 session is treated as NOOP. 111 o Clarified that when the server reaches the global limit on number 112 of sessions, then it returns NO to the SID command. 114 o Clarified that when the server reaches the per-user limit on 115 number of sessions, then it expires the oldest inactive session 116 belonging to the same user. 118 o Updated examples and ABNF. 120 o Changed section 3 arround to be clearer. 122 o Added new text to security section on New SID flooding. 124 o Completed IANA Considerations section. 126 Changes since draft-ietf-lemonade-reconnect-03 128 o Clarified which response codes/responses are required on 129 successful AUTHENTICATE/LOGIN. 131 o FOLDER untagged response code is not needed if NEWSID parameter 132 was specified. 134 o One of tagged READ-WRITE/READ-ONLY is required if resuming a 135 session in selected state. Updated examples as the result. 137 o Spelling/wording corrections from Eric. 139 Changes since draft-ietf-lemonade-reconnect-02 140 o Removed minimal session expiration timeout. 142 o Moved EXPUNGED response to a separate draft. Updated the document 143 as a result of this change. 145 o Updated references and completed IANA considerations. 147 o Added description of the updated synchronization sequence. 149 Changes since draft-ietf-lemonade-reconnect-01 151 o Added NOSID response. 153 o Added UIDVALIDITY argument to the SID parameter. 155 o Added EXPUNGED response. 157 o Added the following example: an opened mailbox was deleted and 158 another was renamed on top, while the client was offline. 160 o Various editorial changes, mostly rewriting text for clarity. 162 Changes since draft-ietf-lemonade-reconnect-00 164 o Added example protocol traces. 166 o Added interaction with SASL-IR (SASL initial response extension). 168 o SIDs are now server generated. Added NEWSID parameter to LOGIN/ 169 AUTHENTICATE and NEWSID response. 171 o Removed SESSION response. The FOLDER response can now tell if 172 there is a mailbox selected or not. 174 o Added LOGOUT (PRESERVE). 176 Table of Contents 178 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 6 179 2. Introduction and Overview . . . . . . . . . . . . . . . . . . 6 180 2.1. Typical IMAP Session without Reconnect . . . . . . . . . . 7 181 2.2. Reconnect IMAP Session . . . . . . . . . . . . . . . . . . 9 182 3. Session Control . . . . . . . . . . . . . . . . . . . . . . . 10 183 3.1. SID command . . . . . . . . . . . . . . . . . . . . . . . 10 184 3.2. Creating a new session . . . . . . . . . . . . . . . . . . 12 185 3.3. Resuming an existing session . . . . . . . . . . . . . . . 13 186 3.4. DELETESID command . . . . . . . . . . . . . . . . . . . . 17 187 4. PRESERVE parameter to the LOGOUT command . . . . . . . . . . . 18 188 5. New responses . . . . . . . . . . . . . . . . . . . . . . . . 18 189 5.1. SELECTED Response . . . . . . . . . . . . . . . . . . . . 18 190 5.2. NEWSID Response . . . . . . . . . . . . . . . . . . . . . 19 191 5.3. DELETEDSID Response . . . . . . . . . . . . . . . . . . . 19 192 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 19 193 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 194 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 195 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 196 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 197 9.2. Informative References . . . . . . . . . . . . . . . . . . 22 198 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 199 Intellectual Property and Copyright Statements . . . . . . . . . . 24 201 1. Requirements notation 203 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 204 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 205 document are to be interpreted as described in [RFC2119]. 207 In examples, "C:" and "S:" indicate lines sent by the client and 208 server respectively. 210 "Resumable session" (or just "session") refers to the entire sequence 211 of client/server interaction from the initial session creation during 212 SID command (with no parameters) until the session is explicitly 213 terminated (or deleted) upon client request or until the session 214 expires some time after disconnect. A resumable session can be 215 terminated by the [RFC3501] LOGOUT or DELETESID command. Note that a 216 resumable session doesn't terminate when the connection is lost or 217 closed with LOGOUT (PRESERVE) command (see Section 4). Also note 218 that this term has a different meaning from the term "session" used 219 by [RFC3501]. 221 A resumable session is said to be "inactive" if it is not associated 222 with any active TCP connection. 224 The term "event" is as defined in [C2S]. 226 2. Introduction and Overview 228 The IMAP4 protocol does not distinguish between a session that has 229 been disconnected for 15 seconds and one that has been disconnected 230 for 1 week. The assumption is the same: The client and server may be 231 completely out of sync and the client must ensure that it is 232 completely synchronized with the server. 234 In today's mobile environments, accidental disconnects due to 235 environmental factors (battery life, signal strength, etc.) can be 236 quite common. In these situtations, the time between the disconnect 237 and reconnect can be quite short. It is these situations which we 238 are interested in. 240 If the time between connections is sufficiently short, an assumption 241 can be made that the state of the last connection is still valid and 242 that the client can avoid having to query much of the state data at 243 reconnect. 245 [[anchor3: Note to RFC editor: This document is compliant with 246 "transitional IMAP capabilities" document [TRANS-CAPA]. Please 247 change the capability name below to "RECONNECT"]] 248 The quick reconnect IMAP extension is present if an IMAP4 server 249 returns "X-DRAFT-W07-RECONNECT" as one of the supported capabilities 250 to the CAPABILITY command. Note, that this extension REQUIREs 251 support for the [CONDSTORE] and the [EXPUNGED] IMAP extensions, so it 252 MUST be announced in the CAPABILITY response as well. 254 The text below outlines how the quick reconnect extension is to be 255 used. The description assumes that the quick reconnect is mainly 256 used when the client closes the TCP connection (intentionally or 257 accidentally) and tries to reconnect within a preset amount of time. 259 1. The client authenticates and asks the server to create a new 260 session by sending a SID command. The server generates a new 261 Session ID (SID) and returns it to the client. 263 2. The client performs operations as normal, typically selecting a 264 mailbox and accessing messages. 266 3. At some point the client loses connectivity. The server retains 267 all information about the client's session, including information 268 about the currently selected mailbox, for some amount of time. 270 (case a) The client reconnects before the session timeout. 271 It authenticates as the same user as before and specifies the 272 previously used session ID in the SID command. The client and 273 server begin at the same mailbox as before the connection 274 loss. 276 (case b) The client reconnects after the session timeout. 277 It authenticates as the same user and specifies the previously 278 used session ID in the SID command. Since the session has 279 timed out on the server, the server has no record of this 280 session and creates a new session. This behaviour falls back 281 to a normal IMAPv4 login sequence. 283 2.1. Typical IMAP Session without Reconnect 285 A typical IMAP client session looks as follows: (Modified dump from 286 network sniffer) 288 S: * OK [CAPABILITY IMAP4REV1 LOGIN-REFERRALS STARTTLS 289 AUTH=DIGEST-MD5] imap.mail.com IMAP4rev1 2001.315rh at Thu, 290 15 Jul 2004 11:47:49-0400 (EDT) 291 C: 2 AUTHENTICATE DIGEST-MD5 292 S: + cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJPQTZNRzl0 293 RVFHbTJoaCIscW9wPSJhdXRoIixhbGdvcml0aG09bWQ1LXNlc3MsY2hh 294 cnNldD11dGYtOA== 295 C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2 296 QuaW5ub3NvZnQuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLG5jPTAw 297 MDAwMDAxLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9Im 298 ltYXAvZWx3b29kLmlubm9zb2Z0LmNvbSIscmVzcG9uc2U9ZDM4OGRhZDkw 299 ZDRiYmQ3NjBhMTUyMzIxZjIxNDNhZjcscW9wPWF1dGg= 300 S: + cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA== 301 C: 302 S: 2 OK [CAPABILITY IMAP4REV1 NAMESPACE] User chris 303 authenticated 304 C: 3 namespace 305 S: * NAMESPACE (("" "/")("#mhinbox" NIL)("#mh/" "/")) (("~" "/")) 306 (("#shared/" "/")("#ftp/" "/")("#news." ".")("#public/" "/")) 307 S: 3 OK completed 308 C: 4 lsub "" "*" 309 S: 4 OK LSUB completed 310 C: 5 lsub "" "#mhinbox*" 311 S: 5 OK LSUB completed 312 C: 6 lsub "" "#mh/*" 313 S: * NO /home/test8/.mh_profile not found, mh format names disabled 314 S: 6 OK LSUB completed 315 C: 7 lsub "" "~*" 316 S: 7 OK LSUB completed 317 C: 8 lsub "" "#shared/*" 318 S: 8 OK LSUB completed 319 C: 9 lsub "" "#ftp/*" 320 S: 9 OK LSUB completed 321 C: 10 lsub "" "#news.*" 322 S: 10 OK LSUB completed 323 C: 11 lsub "" "#public/*" 324 S: 11 OK LSUB completed 325 C: 12 list "" "INBOX" 326 S: * LIST (\NoInferiors) NIL INBOX 327 S: 12 OK LIST completed 328 C: 15 select "INBOX" 329 S: * 464 EXISTS 330 S: * 3 RECENT 331 S: * OK [UNSEEN 12] Message 12 is first unseen 332 S: * OK [UIDVALIDITY 3857529045] UIDs valid 333 S: * OK [UIDNEXT 550] Predicted next UID 334 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 335 S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited 336 S: 15 OK [READ-WRITE] SELECT completed 337 C: 16 UID fetch 1:500 (FLAGS) 338 S: * 1 FETCH (UID 41 FLAGS (\Seen)) 339 S: * 2 FETCH (UID 43 FLAGS (\Seen \Flagged)) 340 S: ... 341 S: * 464 FETCH (UID 541 FLAGS (Junk)) 342 S: 16 fetch completed 343 C: ... 345 (Note, that the client has recognized the CAPABILITY response code in 346 the initial OK response, it has omitted the CAPABILITY command.) 348 The above dump was generated using Ethereal and it reported that the 349 above process generated just under 20 KB of data. 351 The above protocol sequence simply logged the user into the account, 352 selected the INBOX mailbox and downloaded the updated flags for a 353 subset of messages. 355 2.2. Reconnect IMAP Session 357 Now let's look at the same mailbox, but see how the protocol would 358 react if the client had dropped the connection and was reconnecting 359 within a few minutes. 361 As in the previous section, the client has recognized the CAPABILITY 362 response code in the initial OK response, so it has omitted the 363 CAPABILITY command. 365 S: * OK [CAPABILITY IMAP4REV1 LOGIN-REFERRALS STARTTLS 366 AUTH=DIGEST-MD5] imap.example.com IMAP4rev1 2001.315rh at Thu, 367 15 Jul 2004 11:47:49-0400 (EDT) 368 C: 2 AUTHENTICATE DIGEST-MD5 369 S: + cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJPQTZNRzl0 370 RVFHbTJoaCIscW9wPSJhdXRoIixhbGdvcml0aG09bWQ1LXNlc3MsY2hh 371 cnNldD11dGYtOA== 372 C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2 373 QuaW5ub3NvZnQuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLG5jPTAw 374 MDAwMDAxLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9Im 375 ltYXAvZWx3b29kLmlubm9zb2Z0LmNvbSIscmVzcG9uc2U9ZDM4OGRhZDkw 376 ZDRiYmQ3NjBhMTUyMzIxZjIxNDNhZjcscW9wPWF1dGg= 377 S: + cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA== 378 C: 379 S: 2 OK [CAPABILITY IMAP4REV1 NAMESPACE MAILBOX-REFERRALS 380 CONDSTORE X-DRAFT-I01-EXPUNGED X-DRAFT-W07-RECONNECT] User chris 381 authenticated 382 C: 3 SID P1234567890 56789 20010715194045000 41,43:211,214:541 383 S: * SELECTED INBOX 384 S: * 464 EXISTS 385 S: * 3 RECENT 386 S: * OK [UIDVALIDITY 3857529045] UIDVALIDITY 387 S: * OK [UIDNEXT 550] Predicted next UID 388 S: * OK [HIGHESTMODSEQ 20010715194045007] 389 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 390 S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited 391 S: * 1 FETCH (UID 1 FLAGS (\Seen)) 392 S: * EXPUNGED 205,207,209,215:321 393 S: 3 OK [READ-WRITE] session continued 394 C: ... 396 That's it! And since no new messages arrived, no headers were 397 downloaded. The total byte count is about 500 bytes, significantly 398 less than the amount of data transferred during a normal connect 399 request. 401 3. Session Control 403 3.1. SID command 404 Arguments: optional SID parameter 405 optional mailbox UIDVALIDITY 406 optional last known modification sequence 407 optional list of known UIDs 409 Responses: OPTIONAL untagged responses: NEWSID (REQUIRED if no SID 410 parameter was specified; also required if SID parameter 411 was specified but the given session ID is invalid) 412 OPTIONAL untagged responses: SELECTED (REQUIRED if SID 413 parameter was specified) 414 The following responses are REQUIRED if the client remains 415 in the selected state upon reconnect (See Section 3.3). 416 Untagged responses: FLAGS, EXISTS, RECENT 417 OK untagged responses: PERMANENTFLAGS, UIDNEXT, 418 UIDVALIDITY, HIGHESTMODSEQ 419 OPTIONAL OK untagged responses: UNSEEN 420 OK tagged responses: READ-WRITE or READ-ONLY (as described 421 in section 6.3.1 [RFC3501]) 423 Result: OK - session resumed or created; see Section 3.3 424 NO - session creation failure, e.g. session number limit 425 exceeded 426 BAD - arguments invalid 428 This section defines the new SID command. This command is only 429 available in authenticated and selected IMAP states. 431 If the optional session identifier (SID) parameter is not provided, 432 the server will generate a new session as described in Section 3.2. 434 If the optional SID parameter is defined, the server MUST atempt to 435 locate and resume the session with the given SID as described in 436 Section 3.3. 438 Whether a session was created or resumed, the server is now required 439 to remember the session state associated with the (username, SID) 440 pair. 442 At minimum this state includes: 444 o The currently selected mailbox 446 o If mailbox is selected read-only or read-write 448 o The number of recent messages (RECENT) 450 o Non persistent flags created while mailbox was opened, if the 451 server supports not persistent IMAP flags 453 o Any state associated with the current IMAP connection, but is not 454 the state of the selected mailbox 456 Note that if the server also supports [ACL] extension it can either 457 cache the MYRIGHTS value or can refresh it on reconnect. In the 458 latter case the server SHOULD send the untagged MYRIGHTS response on 459 reconnect. 461 Note that other IMAP extensions can define additional state that has 462 to be preserved. 464 The following state doesn't have to be preserved by the server, 465 because it is either supplied by the client on reconnect, or the 466 server is required to send it to the client on reconnect: 468 o The mailbox UIDVALIDITY value 470 o The mailbox HIGHESTMODSEQ value [CONDSTORE] 472 o The highest message UID used in the mailbox 474 o The total number of messages (EXISTS) 476 An implementation may choose to keep all session state in memory and 477 expire sessions some time after client disconnects due to dropped TCP 478 connection or explicit execution of LOGOUT (PRESERVE) command. Upon 479 session expiration the session ID becomes invalid and its associated 480 state is deleted. While there is no required minimum expiration 481 timeout, server implementations are encouraged to support as long a 482 time as possible, subject to denial-of-service and related concerns. 484 Note that SIDs are chosen by the server and are opaque to the client. 485 The same SID used with two different usernames refers to two 486 different sessions, unless the two usernames refer to the same user 487 account, e.g. one username is an alias for another. 489 3.2. Creating a new session 491 This section describes the server behavior if the client has not 492 specified a session identifier parameter to the SID command. This 493 instructs the server to create a new session regardless if a 494 previous, active resumable session is available. If an active 495 session is already available and a new one can be created, the 496 existing session becomes inactive and can be resumed at a later time. 498 This operation can be performed at any point during the IMAP session. 500 Example: The client issues a SID command without a SID parameter, the 501 server creates a new session and responds with a new NEWSID 502 response: 504 C: A01 SID 505 S: * NEWSID ABC412423rs 506 S: A01 OK session created 508 In order to limit Denial of Service attacks a server implementation 509 SHOULD have a per-user limit on maximum number of resumable sessions. 510 When this limit is reached the server SHOULD expire the oldest 511 inactive (not associated with an active TCP connection) session 512 associated with the same user. If no inactive session associated 513 with the same user is available, the server MUST return the tagged NO 514 response to the SID command. 516 A server implementation might also have a per-server limit on maximum 517 number of resumable sessions. This document doesn't define this 518 limit. If the server has reached the limit, it MUST return the 519 tagged NO response to the SID command. 521 3.3. Resuming an existing session 523 This section describes server behaviour if the client has specified 524 the SID parameter to a SID command. 526 The SID command takes four arguments: the session identifier, the 527 mailbox UIDVALIDITY, the last known modification sequence and the 528 optional list of known UIDs. 530 The server verifies all arguments for syntactic validity. If any 531 parameter is not syntactically valid, the server return the tagged 532 BAD response. 534 After that the server checks the session identifier (SID). If the 535 SID is not recognized (for example, the SID is invalid because it is 536 either not known to the server or has expired), the server creates a 537 new session as described in Section 3.2. 539 If the SID is valid, the server MUST inform the client of the state 540 of the session by sending an untagged SELECTED response. The 541 SELECTED response contains the name of the currently selected mailbox 542 name or nothing if there is no mailbox selected. Note that the 543 mailbox name MUST be reported verbatim as originally specified by the 544 client in SELECT/EXAMINE. I.e. before server applies any mailbox 545 name canonicalization (like converting "Inbox" or "users.andrew" to 546 "INBOX"). If, before the disconnect, the session had a mailbox 547 selected and the mailbox has been deleted since then (or the user no 548 longer has permissions to access it), the server MUST return a 549 special SELECTED untagged response that contains no mailbox name. 550 This tells the client that the session has returned to the 551 unauthenticated state. 553 Note that a session can only be active on a single TCP connection. 554 An attempt to resume an active session on a different TCP connection 555 forces the server to close the session on the other connection and to 556 resume it on the current connection. The other connection is 557 notified about this with the untagged DELETEDSID response (See 558 Section 5.3). 560 If at this point there is no mailbox selected, the remaining 561 arguments MUST be ignored by the server. 563 Example: Resuming an old session. 565 C: A02 SID ABC412423rs 67890007 20050715194045000 566 S: * SELECTED 567 S: ... 568 S: A02 OK session resumed, but no selected mailbox 570 UIDVALIDITY Parameter: 571 Once the session has successfully resumed and there is a mailbox 572 selected, the server checks the UIDVALIDITY value provided by the 573 client. If the provided UIDVALIDITY doesn't match the UIDVALIDITY 574 for the currently selected mailbox, the server MUST send the NEWSID 575 response containing the SID of the resumed session. This is done in 576 order to force the client to perform full resynchronization. In this 577 case the server SHOULD [[anchor7: (MUST? What about non permanent 578 flags?)]] clear all state associated with the mailbox, except for 579 whether the mailbox was selected read-only or read-write and the 580 remaining arguments to the SID command are ignored. After that the 581 server behaves as if SELECT/EXAMINE command for the mailbox was 582 issued (depending on whether the current mailbox was originally 583 selected read-write or read-only), i.e. it returns other untagged 584 responses like EXISTS, UIDVALIDITY untagged OK response, etc. 586 Example: Attempting to resume an old session with an invalid 587 UIDVALIDITY parameter. 589 C: A02 SID ABC412423rs 67890007 20050715194045000 41,43: 590 211,214:541 591 S: * SELECTED INBOX 592 S: * NEWSID ABC412423rs 593 S: * 464 EXISTS 594 S: * 3 RECENT 595 S: * OK [UIDVALIDITY 3857529045] UIDVALIDITY 596 S: * OK [UIDNEXT 550] Predicted next UID 597 S: * OK [HIGHESTMODSEQ 20060128194045007] 598 S: A02 OK [READ-WRITE] resync required 600 Note that even though the UIDVALIDITY is invalid, the mailbox 601 remained selected and the untagged SELECTED response is returned as 602 the result. 604 Modification Sequence and UID Parameters: 606 If the provided UIDVALIDITY matches that of the selected mailbox, the 607 server then checks the last known modification sequence. 608 The server sends the client any pending flag changes (using FETCH 609 responses that MUST contain UIDs) and expunges that have occurred in 610 this mailbox since the provided modification sequence. 612 If the list of known UIDs was also provided, the server should only 613 report flag changes and expunges for the provided messages. If the 614 client doesn't provide the list of UIDs, the server acts as if the 615 client has specified "1:*". Thus, the client client can process just 616 these pending events and need not perform a full resynchronization. 617 The result of this step is semantically equivalent to the client 618 issuing: 619 tag1 UID FETCH "known-uids" (FLAGS) (CHANGEDSINCE 620 "mod-sequence-value" REPORTEXPUNGES) 621 If the server was unable to cache all events since the MODSEQ and 622 hence is unable to send them to the client, the server MUST return 623 the NEWSID response to signal that the client should perform a state- 624 comparison based synchronization. Note, that the NEWSID response MAY 625 contain the same SID as specified in the SID parameter. Section 3.2 626 describes server behavior in this case, i.e. the server behaves as if 627 the session can't be resumed. 629 Example: Resuming an old session in selected state with the INBOX 630 selected. 632 C: A02 SID ABC412423rs 67890007 20060115194045000 41,43:211,214: 633 541) 635 S: * SELECTED INBOX 637 S: * 314 EXISTS 639 S: 15 RECENT 640 S: * OK [UIDVALIDITY 67890007] UIDVALIDITY 642 S: * OK [UIDNEXT 567] Predicted next UID 644 S: * OK [HIGHESTMODSEQ 20060115205545359] 646 S: * 49 FETCH (UID 117 FLAGS (\Seen \Answered)) 648 S: * 50 FETCH (UID 119 FLAGS (\Draft $MDNSent)) 650 S: ... 652 S: * 100 FETCH (UID 541 FLAGS (\Seen $Forwarded)) 654 S: * EXPUNGED 41,43:116,118,120:211,214:540 656 S: A02 OK session resumed 658 If, while the client was offline, the selected mailbox was deleted 659 and another mailbox was renamed to the same name, the server MAY do 660 either: 662 1. return the NEWSID response, as well as the new UIDVALIDITY and 663 all other responses as described in Section 3.1. 665 2. return "SELECTED" response with no mailbox in order to return the 666 client to the authenticated state. 668 Example: Resuming an old session in selected (read-only) state with 669 the INBOX selected. 671 C: A02 SID ABC412423rs 67890007 20010715194045000 41,43:211,214:541 672 S: * SELECTED INBOX 673 S: * OK [UIDVALIDITY 67890007] Current UIDValidity 674 S: * OK [UIDNEXT 782] Next available UID 675 S: * 114 EXISTS 676 S: * 5 RECENT 677 S: * OK [HIGHESTMODSEQ 20010715235047007] S: * FLAGS (\Answered 678 \Flagged \Draft \Deleted \Seen) 679 S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft 680 \Deleted \Seen \*)] Permanent flags 681 S: * 49 FETCH (UID 117 FLAGS (\Seen \Answered)) 682 S: ... 683 S: A02 OK [READ-ONLY] session resumed 685 Example: Resuming an old session in selected state with the INBOX 686 selected, but where the server could not cache all the events since 687 the specified modification sequence. The server sends the NEWSID 688 response, which means that the client should perform full 689 resynchronization. 691 C: A02 SID ABC412423rs 67890007 20010715194045000 41,43:211,214:541 692 S: * NEWSID jwejei9qe3r 693 S: * SELECTED INBOX 694 S: * OK [UIDVALIDITY 67890007] Current UIDValidity 695 S: * OK [UIDNEXT 1598] Next available UID 696 S: * 117 EXISTS 697 S: * 20 RECENT 698 S: * OK [HIGHESTMODSEQ 20010715235047019] S: * FLAGS (\Answered 699 \Flagged \Draft \Deleted \Seen) 700 S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft 701 \Deleted \Seen \*)] Permanent flags 702 S: A02 OK [READ-WRITE] session created 704 Example: Resuming an old session in selected state with the mailbox 705 Drafts selected, but the mailbox was deleted and another one was 706 renamed to become Drafts, while the client was offline. The server 707 chooses to keep the Drafts mailbox open, however it sends the NEWSID 708 response, which means that the client should perform full 709 resynchronization. 711 C: A02 SID Frt-egf-779 6896834 11 20:35 712 S: * NEWSID Frt-egf-779 713 S: * SELECTED Drafts 714 S: * OK [UIDVALIDITY 1098183472] Current UIDValidity 715 S: * OK [UIDNEXT 12] Next available UID 716 S: * OK [HIGHESTMODSEQ 54] S: * 7 EXISTS 717 S: * 0 RECENT 718 S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) 719 S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft 720 \Deleted \Seen \*)] Permanent flags 721 S: A02 OK [READ-WRITE] session created 723 Note that as one of READ-WRITE/READ-ONLY tagged response codes is 724 required when a session is resumed in selected state, the server is 725 unable to send the CAPABILITY response code in the tagged OK 726 response. 728 3.4. DELETESID command 730 Arguments: none 732 Responses: no specific responses for this command 733 Result: OK - session successfully terminated 734 NO - session deletion failure 735 BAD - arguments invalid or no active session 737 The DELETESID command tells the server to terminate the current 738 session. If there is no current session, the server MUST respond 739 with the tagged BAD response. 741 4. PRESERVE parameter to the LOGOUT command 743 [[anchor8: This section clearly assumes voluntarily disconnect]] 745 This section updates the description of the LOGOUT command found in 746 Section 6.1.3 of [RFC3501]. A LOGOUT command with no parameters 747 tells the server to terminate the current session (if any). 749 This document also adds a new parameter "PRESERVE" to the LOGOUT 750 command. This tells the server that it should not terminate the 751 current resumable session. If the client doesn't want to terminate 752 the current session on logout it SHOULD use "LOGOUT (PRESERVE)" 753 instead of just dropping the TCP connection. This helps to avoid 754 unnecessary resource consumption on the server caused by a TCP 755 disconnect. 757 Note that if "LOGOUT (PRESERVE)" is issued when no resumable session 758 was created, the server should treat this as if the LOGOUT command 759 was issued with no parameters. 761 Example: C: A023 LOGOUT (PRESERVE) 763 S: * BYE IMAP4rev1 Server logging out, state preserved 765 S: A023 OK LOGOUT completed 767 (Server and client then close the connection) 769 5. New responses 771 5.1. SELECTED Response 773 Contents: name of the selected mailbox or nothing if there is no 774 selected mailbox 776 The SELECTED response tells the client that a session was 777 successfully resumed and returns the name of the selected mailbox. 778 If the response doesn't contain a mailbox name, this means that there 779 is no mailbox selected. 781 5.2. NEWSID Response 783 Contents: generated session ID 785 The NEWSID response tells the client the unique identifier that can 786 be used to resume the created session. It also tells the client to 787 perform a full state resynchronization. 789 5.3. DELETEDSID Response 791 Contents: session ID 793 The DELETEDSID response tells the client that the current active 794 session is closed because it was resumed (transferred) on another TCP 795 connection. 797 6. Formal Syntax 799 The following syntax specification uses the Augmented Backus-Naur 800 Form (ABNF) notation as specified in [ABNF]. 802 Non-terminals referenced but not defined below are as defined by 803 [RFC3501], [CONDSTORE], [EXPUNGED] or [IMAPABNF]. 805 Except as noted otherwise, all alphabetic characters are case- 806 insensitive. The use of upper or lower case characters to define 807 token strings is for editorial clarity only. Implementations MUST 808 accept these strings in a case-insensitive fashion. 810 sid = "SID" [SP session-id SP uidvalidity SP 811 mod-sequence-value [SP known-uids]] 813 uidvalidity = nz-number 815 known-uids = sequence-set 816 ;; sequence of UIDs, "*" is not allowed 818 deletesid = "DELETESID" 820 uidvalidity = nz-number 822 known-uids = sequence-set 823 ;; sequence of UIDs, "*" is not allowed 825 command-auth =/ sid / deletesid 827 logout = "LOGOUT" [logout-params] 829 logout-params = SP "(" logout-param-data ")" 830 ;; modifies the original IMAP4 LOGOUT 831 ;; command to accept optional parameters 833 logout-param-data= logout-param *(SP logout-param) 835 logout-param = logout-param-name [SP logout-param-value] 836 ;; parameters to LOGOUT may contain one or 837 ;; more atoms atoms and/or strings and/or lists. 839 logout-param-name= tagged-ext-label 841 logout-param-value= tagged-ext-val 842 ;; This non-terminal shows recommended syntax 843 ;; for future extensions. 845 logout-preserve = "PRESERVE" 846 ;; conforms to logout-param syntax 848 mailbox-data =/ selected-resp / newsid-resp / deletedsid-resp 850 selected-resp = "SELECTED" [SP folder] 851 ;; lack of the mailbox parameter denotes 852 ;; that there is no mailbox selected 854 newsid-resp = "NEWSID" SP session-id 856 deletedsid-resp = "DELETEDSID" SP session-id 858 session-id = string ;; a unique session identifier, 859 ;; implementation specific. 861 7. Security Considerations 863 In order to mitigate DoS attacks caused by a client that tries to 864 generate numerous resumable sessions (for example by issuing multiple 865 SID commands with no parameters on the same TCP connection), a server 866 implementation should consider imposing a limit on the maximum number 867 of resumable sessions associated with a particular user and/or coming 868 from a particular IP address/network. Once this limit has been 869 reached, the oldest inactive session must be destroyed and the new 870 one can be created. Inactive sessions SHOULD have an expiration 871 timeout. 873 The Quick Reconnect extension does not make any modifications to the 874 authentication sequence of the current IMAP4 protocol [RFC3501]. 876 8. IANA Considerations 878 IMAP4 capabilities are registered by publishing a standards track or 879 IESG approved experimental RFC. The registry is currently located 880 at: 882 http://www.iana.org/assignments/imap4-capabilities 884 This document defines the X-DRAFT-W07-RECONNECT [[anchor15: Fix 885 capability name upon publication]] IMAP capability. IANA is 886 requested to add this capability to the registry. 888 9. References 890 9.1. Normative References 892 [ABNF] Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for 893 Syntax Specifications: ABNF", RFC 4234, October 2005. 895 [ACL] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", 896 RFC 4314, December 2005. 898 [CONDSTORE] 899 Melnikov, A. and S. Hole, "IMAP Extension for Conditional 900 STORE", November 2003. 902 [EXPUNGED] 903 Melnikov, A., "IMAP4 extension to CONDSTORE for reporting 904 messages expunged since last synchronization", 905 January 2005. 907 [IMAPABNF] 908 Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 909 ABNF", RFC 4466, April 2006. 911 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 912 Requirement Levels", BCP 14, RFC 2119, March 1997. 914 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 915 4rev1", RFC 3501, March 2003. 917 [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 918 Specifications: ABNF", RFC 4234, October 2005. 920 9.2. Informative References 922 [C2S] Maes, S. and C. Wilson, "Lemonade Requirements for Server to 923 Client Notifications", February 2005. 925 Authors' Addresses 927 Alexey Melnikov 928 Isode Ltd 929 5 Castle Business Village 930 36 Station Road 931 Hampton, Middlesex TW12 2BX 932 UK 934 Email: Alexey.Melnikov@isode.com 936 Corby Wilson 937 Nokia 938 5 Wayside Rd. 939 Burlington, MA 01803 940 USA 942 Email: corby@computer.org 944 Intellectual Property Statement 946 The IETF takes no position regarding the validity or scope of any 947 Intellectual Property Rights or other rights that might be claimed to 948 pertain to the implementation or use of the technology described in 949 this document or the extent to which any license under such rights 950 might or might not be available; nor does it represent that it has 951 made any independent effort to identify any such rights. Information 952 on the procedures with respect to rights in RFC documents can be 953 found in BCP 78 and BCP 79. 955 Copies of IPR disclosures made to the IETF Secretariat and any 956 assurances of licenses to be made available, or the result of an 957 attempt made to obtain a general license or permission for the use of 958 such proprietary rights by implementers or users of this 959 specification can be obtained from the IETF on-line IPR repository at 960 http://www.ietf.org/ipr. 962 The IETF invites any interested party to bring to its attention any 963 copyrights, patents or patent applications, or other proprietary 964 rights that may cover technology that may be required to implement 965 this standard. Please address the information to the IETF at 966 ietf-ipr@ietf.org. 968 Disclaimer of Validity 970 This document and the information contained herein are provided on an 971 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 972 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 973 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 974 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 975 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 976 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 978 Copyright Statement 980 Copyright (C) The Internet Society (2006). This document is subject 981 to the rights, licenses and restrictions contained in BCP 78, and 982 except as set forth therein, the authors retain all their rights. 984 Acknowledgment 986 Funding for the RFC Editor function is currently provided by the 987 Internet Society.