idnits 2.17.1 draft-ietf-lemonade-reconnect-client-01.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 341. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 352. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 359. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 365. ** 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 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 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 2006) is 6522 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: 'TRANS-CAPA' is mentioned on line 117, but not defined == Missing Reference: 'UIDVALIDITY 3857529045' is mentioned on line 171, but not defined == Missing Reference: 'UIDNEXT 550' is mentioned on line 172, but not defined == Missing Reference: 'HIGHESTMODSEQ 20060128194045007' is mentioned on line 173, but not defined == Missing Reference: 'UNSEEN 12' is mentioned on line 174, but not defined == Missing Reference: 'UIDVALIDITY 67890007' is mentioned on line 208, but not defined == Missing Reference: 'UIDNEXT 567' is mentioned on line 210, but not defined == Missing Reference: 'HIGHESTMODSEQ 20060115205545359' is mentioned on line 212, but not defined == Missing Reference: 'UNSEEN 7' is mentioned on line 214, 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'EXPUNGED' ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) Summary: 6 errors (**), 0 flaws (~~), 10 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Melnikov 3 Internet-Draft Isode Ltd 4 Intended status: Standards Track D. Cridland 5 Expires: December 3, 2006 Inventure Systems Ltd 6 C. Wilson 7 Nokia 8 June 2006 10 IMAP4 Extensions for Quick Mailbox Resynchronization 11 draft-ietf-lemonade-reconnect-client-01.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on December 3, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 This document defines an IMAP4 extension, which gives an IMAP client 45 the ability to quickly resynchronize any previously opened mailbox as 46 part of the SELECT command, without the need for server-side state or 47 additional client round-trips. 49 Changes since draft-ietf-lemonade-reconnect-client-01.txt 51 o If client's UIDVALIDITY doesn't match server's, the server will 52 not return any flags anymore. 54 o Clarified that SELECT (QRESYNC) is a CONDSTORE-enabling command. 56 o Other minor editorial changes and fixes. 58 Changes since draft-ietf-lemonade-reconnect-client-00.txt 60 o Changed server behavior when the specified UIDVALIDITY doesn't 61 match the current. This allows the client to chose how to proceed 62 after that. 64 o Other minor editorial changes and fixes. 66 Table of Contents 68 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 69 2. Introduction and Overview . . . . . . . . . . . . . . . . . . 4 70 3. Quick resynchronization extension . . . . . . . . . . . . . . 5 71 3.1. QRESYNC parameter to SELECT/EXAMINE . . . . . . . . . . . 5 72 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 7 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 75 7. Normative References . . . . . . . . . . . . . . . . . . . . . 8 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 77 Intellectual Property and Copyright Statements . . . . . . . . . . 10 79 1. Requirements notation 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in [RFC2119]. 85 In examples, "C:" and "S:" indicate lines sent by the client and 86 server respectively. If a single "C:" or "S:" label applies to 87 multiple lines, then the line breaks between those lines are for 88 editorial clarity only and are not part of the actual protocol 89 exchange. 91 2. Introduction and Overview 93 IMAP [CONDSTORE] extension provides a way to quickly resynchronize 94 changes to IMAP flags since a known moment. This can be done using 95 FETCH modifier once a mailbox is opened. 97 The [EXPUNGED] IMAP extension allows to quickly discover expunged 98 messages. 100 The IMAP extension described in this document combines functionality 101 provided by both [CONDSTORE] and [EXPUNGED] extensions, while 102 reducing one more round-trip. 104 In particular this extension can be useful for mobile clients that 105 can experience frequent disconnects caused by environmental factors 106 (battery life, signal strength, etc.). Such clients would need a way 107 to quickly reconnect to the IMAP server, without forcing the user to 108 experience long delay and pay big bills for the amount of traffic 109 generated by resynchronization. 111 By extending the SELECT command to perform the additional 112 resynchronization, this also allows clients to reduce concurrent 113 connections to the IMAP server held purely for the sake of avoiding 114 the resynchronization. 116 [[anchor3: Note to RFC editor: This document is compliant with 117 "transitional IMAP capabilities" document [TRANS-CAPA]. Please 118 change the capability name below to "QRESYNC"]] 120 The quick resync IMAP extension is present if an IMAP4 server returns 121 "X-DRAFT-W01-QRESYNC" as one of the supported capabilities to the 122 CAPABILITY command. Note, that this extension REQUIREs support for 123 the [CONDSTORE] and the [EXPUNGED] IMAP extensions, so they MUST be 124 announced in the CAPABILITY response as well. 126 3. Quick resynchronization extension 128 3.1. QRESYNC parameter to SELECT/EXAMINE 130 The Quick Resynchronization parameter to SELECT/EXAMINE commands has 131 three arguments: 133 o the last known UIDVALIDITY, 135 o the last known modification sequence 137 o and the optional list of known UIDs. 139 The parameter acts as a CONDSTORE enabling command, as defined in 140 [CONDSTORE]. In other words, the use of the QRESYNC parameter 141 implies the CONDSTORE parameter. Also, the QRESYNC parameter implies 142 the EXPUNGED parameter, as defined in [EXPUNGED]. 144 Before opening the specified mailbox the server verifies all 145 arguments for syntactic validity. If any parameter is not 146 syntactically valid, the server return the tagged BAD response, and 147 the mailbox remains unselected. Once the check is done the server 148 opens the mailbox as if no SELECT/EXAMINE parameters are specified 149 (this is subject to processing of other parameters as defined in 150 other extensions). In particular this means that server MUST send 151 all untagged responses as specified in Section 6.3.1/6.3.2 of 152 [RFC3501]. 154 After that the server checks the UIDVALIDITY value provided by the 155 client. If the provided UIDVALIDITY doesn't match the UIDVALIDITY 156 for the mailbox being opened, then the server MUST ignore the 157 remaining parameters and behave as if no dynamic message data 158 changed. The client can discover this situation by comparing the 159 UIDVALIDITY value returned by the server. This behaviour allows the 160 client not to synchronize the mailbox or decide on the best 161 synchronization strategy. 163 Example: Attempting to resynchronize INBOX, but the provided 164 UIDVALIDITY parameter doesn't match the current UIDVALIDITY 165 value. 167 C: A02 SELECT INBOX (QRESYNC (67890007 20050715194045000 168 41,43:211,214:541)) 169 S: * 464 EXISTS 170 S: * 3 RECENT 171 S: * OK [UIDVALIDITY 3857529045] UIDVALIDITY 172 S: * OK [UIDNEXT 550] Predicted next UID 173 S: * OK [HIGHESTMODSEQ 20060128194045007] 174 S: * OK [UNSEEN 12] Message 12 is first unseen 175 S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) 176 S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft 177 \Deleted \Seen \*)] Permanent flags 178 S: A02 OK [READ-WRITE] Sorry, UIDVALIDITY mismatch 180 Modification Sequence and UID Parameters: 182 If the provided UIDVALIDITY matches that of the selected mailbox, the 183 server then checks the last known modification sequence. 184 The server sends the client any pending flag changes (using FETCH 185 responses that MUST contain UIDs) and expunges that have occurred in 186 this mailbox since the provided modification sequence. 188 If the list of known UIDs was also provided, the server should only 189 report flag changes and expunges for the provided messages. If the 190 client doesn't provide the list of UIDs, the server acts as if the 191 client has specified "1:*". 193 Thus, the client client can process just these pending events and 194 need not perform a full resynchronization. The result of this step 195 is semantically equivalent to the client issuing: 196 tag1 UID FETCH "known-uids" (FLAGS) (CHANGEDSINCE 197 "mod-sequence-value" REPORTEXPUNGES) 199 Example: 201 C: A02 SELECT INBOX (QRESYNC (67890007 202 20060115194045000 41,43:211,214:541)) 204 S: * 314 EXISTS 206 S: 15 RECENT 208 S: * OK [UIDVALIDITY 67890007] UIDVALIDITY 210 S: * OK [UIDNEXT 567] Predicted next UID 212 S: * OK [HIGHESTMODSEQ 20060115205545359] 214 S: * OK [UNSEEN 7] There are some unseen messages in the mailbox 216 S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) 218 S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft 219 \Deleted \Seen \*)] Permanent flags 221 S: * 49 FETCH (UID 117 FLAGS (\Seen \Answered)) 223 S: * 50 FETCH (UID 119 FLAGS (\Draft $MDNSent)) 225 S: ... 227 S: * 100 FETCH (UID 541 FLAGS (\Seen $Forwarded)) 229 S: * EXPUNGED 41,43:116,118,120:211,214:540 231 S: A02 OK [READ-WRITE] mailbox selected 233 4. Formal Syntax 235 The following syntax specification uses the Augmented Backus-Naur 236 Form (ABNF) notation as specified in [ABNF]. 238 Non-terminals referenced but not defined below are as defined by 239 [RFC3501], [CONDSTORE], [EXPUNGED] or [IMAPABNF]. 241 Except as noted otherwise, all alphabetic characters are case- 242 insensitive. The use of upper or lower case characters to define 243 token strings is for editorial clarity only. Implementations MUST 244 accept these strings in a case-insensitive fashion. 246 select-param = "QRESYNC" SP "(" uidvalidity SP 247 mod-sequence-value [SP known-uids] ")" 248 ;; conforms to the generic select-param 249 ;; syntax defined in [IMAPABNF] 251 uidvalidity = nz-number 253 known-uids = sequence-set 254 ;; sequence of UIDs, "*" is not allowed 256 5. Security Considerations 258 Security considerations relevant to [CONDSTORE] and [EXPUNGED] are 259 relevant to this extension. 261 This document doesn't raise any new security concerns not already 262 raised by [CONDSTORE]. 264 6. IANA Considerations 266 IMAP4 capabilities are registered by publishing a standards track or 267 IESG approved experimental RFC. The registry is currently located 268 at: 270 http://www.iana.org/assignments/imap4-capabilities 272 This document defines the X-DRAFT-W01-QRESYNC [[anchor9: The final 273 capability name will be chosen during AUTH48]] IMAP capability. IANA 274 is requested to add this capability to the registry. 276 7. Normative References 278 [ABNF] Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for 279 Syntax Specifications: ABNF", RFC 4234, October 2005. 281 [CONDSTORE] 282 Melnikov, A. and S. Hole, "IMAP Extension for Conditional 283 STORE Operation or Quick Flag Changes Resynchronization", 284 RFC 4551, June 2006. 286 [EXPUNGED] 287 Melnikov, A., "IMAP4 extension for reporting expunged 288 messages", June 2006. 290 [IMAPABNF] 291 Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 292 ABNF", RFC 4466, April 2006. 294 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 295 Requirement Levels", BCP 14, RFC 2119, March 1997. 297 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 298 4rev1", RFC 3501, March 2003. 300 Authors' Addresses 302 Alexey Melnikov 303 Isode Ltd 304 5 Castle Business Village 305 36 Station Road 306 Hampton, Middlesex TW12 2BX 307 UK 309 Email: Alexey.Melnikov@isode.com 311 Dave Cridland 312 Inventure Systems Ltd 313 21, Heol Bronwydd 314 Caerfyrddin, Cymru SA31 2AJ 315 GB 317 Email: dave.cridland@invsys.co.uk 319 Corby Wilson 320 Nokia 321 5 Wayside Rd. 322 Burlington, MA 01803 323 USA 325 Email: corby@computer.org 327 Full Copyright Statement 329 Copyright (C) The Internet Society (2006). 331 This document is subject to the rights, licenses and restrictions 332 contained in BCP 78, and except as set forth therein, the authors 333 retain all their rights. 335 This document and the information contained herein are provided on an 336 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 337 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 338 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 339 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 340 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 341 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 343 Intellectual Property 345 The IETF takes no position regarding the validity or scope of any 346 Intellectual Property Rights or other rights that might be claimed to 347 pertain to the implementation or use of the technology described in 348 this document or the extent to which any license under such rights 349 might or might not be available; nor does it represent that it has 350 made any independent effort to identify any such rights. Information 351 on the procedures with respect to rights in RFC documents can be 352 found in BCP 78 and BCP 79. 354 Copies of IPR disclosures made to the IETF Secretariat and any 355 assurances of licenses to be made available, or the result of an 356 attempt made to obtain a general license or permission for the use of 357 such proprietary rights by implementers or users of this 358 specification can be obtained from the IETF on-line IPR repository at 359 http://www.ietf.org/ipr. 361 The IETF invites any interested party to bring to its attention any 362 copyrights, patents or patent applications, or other proprietary 363 rights that may cover technology that may be required to implement 364 this standard. Please address the information to the IETF at 365 ietf-ipr@ietf.org. 367 Acknowledgment 369 Funding for the RFC Editor function is provided by the IETF 370 Administrative Support Activity (IASA).