idnits 2.17.1 draft-crispin-imap-rfc2359bis-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 3667, Section 5.1 on line 332. -- Found old boilerplate from RFC 3978, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 371. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 382. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 389. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 395. ** Found boilerplate matching RFC 3978, Section 5.1 (on line 13), which is fine, but *also* found old RFC 3667, Section 5.1 text on line 332. ** Found boilerplate matching RFC 3979, Section 5, paragraph 1 (on line 382), which is fine, but *also* found old RFC 2026, Section 10.4A text on line 348. ** Found boilerplate matching RFC 3979, Section 5, paragraph 3 (on line 395), which is fine, but *also* found old RFC 2026, Section 10.4B text on line 354. ** 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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 409 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 24 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([IMAP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == In addition to RFC 3979, Section 5, paragraph 1 boilerplate, a section with a similar start was also found: The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. == In addition to RFC 3979, Section 5, paragraph 3 boilerplate, a section with a similar start was also found: The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'UNSEEN 1' is mentioned on line 223, but not defined == Missing Reference: 'UIDVALIDITY 3857529045' is mentioned on line 224, but not defined == Missing Reference: 'UIDNEXT 2' is mentioned on line 225, but not defined == Missing Reference: 'IMAP4' is mentioned on line 244, but not defined == Unused Reference: 'RFC-2822' is defined on line 303, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) -- Obsolete informational reference (is this intentional?): RFC 2359 (Obsoleted by RFC 4315) Summary: 13 errors (**), 0 flaws (~~), 11 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Crispin 2 Obsoletes: 2359 3 Document: internet-drafts/draft-crispin-imap-rfc2359bis-04.txt 5 Internet Message Access Protocol (IMAP) - UIDPLUS extension 7 Status of this Memo 9 By submitting this Internet-Draft, each author represents that 10 any applicable patent or other IPR claims of which he or she is 11 aware have been or will be disclosed, and any of which he or she 12 becomes aware will be disclosed, in accordance with Section 6 of 13 BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 A revised version of this document will be submitted to the RFC 32 editor as an Informational Document for the Internet Community. 34 A revised version of this draft document will be submitted to the RFC 35 editor as a Proposed Standard for the Internet Community. Discussion 36 and suggestions for improvement are requested, and should be sent to 37 imapext@IMC.ORG. This document will expire before 25 November 2005. 38 Distribution of this memo is unlimited. 40 Abstract 42 The UIDPLUS extension of the Internet Message Access Protocol [IMAP] 43 provides a set of features intended to reduce the amount of time and 44 resources used by some client operations. The features in UIDPLUS 45 are primarily intended for disconnected-use clients. 47 Conventions Used in this Document 49 In examples, "C:" and "S:" indicate lines sent by the client and 50 server respectively. 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are 54 to be interpreted as described in [KEYWORDS]. 56 A "UID set" is similar to the [IMAP] sequence set; however, the "*" 57 value for sequence number is not permitted. 59 Introduction and Overview 61 The UIDPLUS extension is present in any IMAP server implementation 62 which returns "UIDPLUS" as one of the supported capabilities to the 63 CAPABILITY command. 65 The UIDPLUS extension defines an additional command. In addition, 66 this document recommends new status response codes in IMAP which 67 SHOULD be returned by all server implementations, regardless of 68 whether or not the UIDPLUS extension is implemented. 70 The added facilities of the features in UIDPLUS are optimizations; 71 clients can provide equivalent functionality, albeit less 72 efficiently, by using facilities in the base protocol. 74 1. Additional Commands 76 The following command definition is an extension to [IMAP] section 77 6.4. 79 1.1 UID EXPUNGE Command 81 Arguments: sequence set 83 Data: untagged responses: EXPUNGE 85 Result: OK - expunge completed 86 NO - expunge failure (e.g., permission denied) 87 BAD - command unknown or arguments invalid 89 The UID EXPUNGE command permanently removes from the currently 90 selected mailbox all messages that both have the \Deleted flag set 91 and have a UID that is included in the specified sequence set. If 92 a message either does not have the \Deleted flag set or has a UID 93 that is not included in the specified sequence set, it is not 94 affected. 96 This command may be used to ensure that a replayed EXPUNGE command 97 does not remove any messages that have been marked as \Deleted 98 between the time that the user requested the expunge operation and 99 the time the server processes the command. 101 If the server does not support the UIDPLUS capability, the client 102 should fall back to using the STORE command to temporarily remove 103 the \Deleted flag from messages it does not want to remove. The 104 client could alternatively fall back to using the EXPUNGE command, 105 risking the unintended removal of some messages. 107 Example: C: A003 UID EXPUNGE 3000:3002 108 S: * 3 EXPUNGE 109 S: * 3 EXPUNGE 110 S: * 3 EXPUNGE 111 S: A003 OK UID EXPUNGE completed 113 2. Additional Response Codes 115 The following response codes are extensions to the response codes 116 defined in [IMAP] section 7.1. With limited exceptions, discussed 117 below, server implementations that advertise the UIDPLUS extension 118 SHOULD return these response codes. 120 In the case of a mailbox which has permissions set so that the client 121 can COPY or APPEND to the mailbox, but not SELECT or EXAMINE it, the 122 server SHOULD NOT send an APPENDUID or COPYUID response code as it 123 would disclose information about the mailbox. 125 In the case of a mailbox that has UIDNOTSTICKY status (as defined 126 below), the server MAY omit the APPENDUID or COPYUID response code as 127 it is not meaningful. 129 If the server does not return the APPENDUID or COPYUID response 130 codes, the client can discover this information by selecting the 131 destination mailbox. The location of messages placed in the 132 destination mailbox by COPY or APPEND can be determined by using 133 FETCH and/or SEARCH commands (e.g. for Message-ID or some unique 134 marker placed in the message in an APPEND). 136 APPENDUID 138 Followed by the UIDVALIDITY of the destination mailbox and the 139 UID assigned to the appended message in the destination mailbox, 140 indicates that the message has been appended to the destination 141 mailbox with that UID. 143 If the server also supports the [MULTIAPPEND] extension, and if 144 multiple messages were appended in the APPEND command, then the 145 second value is a UID set containing the UIDs assigned to 146 the appended messages, in the order they were transmitted in the 147 APPEND command. This UID set may not contain extraneous 148 UIDs or the symbol "*". 150 Note: the UID set form of the APPENDUID response code MUST 151 NOT be used if only a single message was appended. In 152 particular, a server MUST NOT send a range such as 123:123. 153 This is because a client which does not support [MULTIAPPEND] 154 expects only a single UID and not a UID set. 156 UIDs are assigned strictly ascending in the mailbox (refer to 157 [IMAP], section 2.3.1.1) and UID ranges are as in [IMAP]; in 158 particular, note that a range of 12:10 is exactly equivalent to 159 10:12 and refers to the sequence 10,11,12. 161 This response code is returned in a tagged OK response to the 162 APPEND command. 164 COPYUID 166 Followed by the UIDVALIDITY of the destination mailbox, a UID 167 set containing the UIDs of the message(s) in the source mailbox 168 which were copied to the destination mailbox, and a UID set 169 containing the UIDs assigned to the copied message(s) in the 170 destination mailbox, indicates that the message(s) have been 171 copied to the destination mailbox with the stated UID(s). 173 The source UID set is in the order the message(s) were copied; the 174 destination UID set corresponds to the source UID set and is in 175 the same order. Neither of the UID sets may contain extraneous 176 UIDs or the symbol "*". 178 UIDs are assigned strictly ascending in the mailbox (refer to 179 [IMAP], section 2.3.1.1) and UID ranges are as in [IMAP]; in 180 particular, note that a range of 12:10 is exactly equivalent to 181 10:12 and refers to the sequence 10,11,12. 183 This response code is returned in a tagged OK response to the 184 COPY command. 186 UIDNOTSTICKY 188 The selected mailbox is supported by a mail store which does not 189 support persistent UIDs; that is, UIDVALIDITY will be different 190 each time the mailbox is selected. Consequently, APPEND or COPY 191 to this mailbox will not return an APPENDUID or COPYUID response 192 code. 194 This response code is returned in an untagged NO response to the 195 SELECT command. 197 Note: servers SHOULD NOT have any UIDNOTSTICKY mail stores. 198 This facility exists to support legacy mail stores in which 199 it is technically infeasible to support persistant UIDs. 200 This should be avoided when designing new mail stores. 202 Example: C: A003 APPEND saved-messages (\Seen) {297} 203 C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) 204 C: From: Fred Foobar 205 C: Subject: afternoon meeting 206 C: To: mooch@example.com 207 C: Message-Id: 208 C: MIME-Version: 1.0 209 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 210 C: 211 C: Hello Joe, do you think we can meet at 3:30 tomorrow? 212 C: 213 S: A003 OK [APPENDUID 38505 3955] APPEND completed 214 C: A004 COPY 2:4 meeting 215 S: A004 OK [COPYUID 38505 304,319:320 3956:3958] Done 216 C: A005 UID COPY 305:310 meeting 217 S: A005 OK No matching messages, so nothing copied 218 C: A006 COPY 2 funny 219 S: A006 OK Done 220 C: A007 SELECT funny 221 S: * 1 EXISTS 222 S: * 1 RECENT 223 S: * OK [UNSEEN 1] Message 1 is first unseen 224 S: * OK [UIDVALIDITY 3857529045] Validity session-only 225 S: * OK [UIDNEXT 2] Predicted next UID 226 S: * NO [UIDNOTSTICKY] Non-persistent UIDs 227 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 228 S: * OK [PERMANENTFLAGS (\Deleted \Seen)] Limited 229 S: A007 OK [READ-WRITE] SELECT completed 231 In this example, A003 and A004 demonstrate successful appending and 232 copying to a mailbox which returns the UIDs assigned to the messages. 233 A005 is an example in which no messages were copied; this is because 234 in A003 we see that message 2 had UID 304 and message 3 had UID 319; 235 therefore UIDs 305 through 310 do not exist (refer to section 2.3.1.1 236 of [IMAP] for further explanation). A006 is an example of a message 237 being copied that did not return a COPYUID; and as expected A007 238 shows that the mail store containing that mailbox does not support 239 persistent UIDs. 241 5. Formal Syntax 243 Formal syntax is defined using ABNF [ABNF], extending the ABNF rules 244 defined in [IMAP4]. The IMAP4 ABNF should be imported first before 245 attempting to validate these rules. 247 append-uid = uniqueid 249 capability =/ "UIDPLUS" 251 command-select =/ uid-expunge 253 resp-code-apnd = "APPENDUID" SP nz-number SP append-uid 255 resp-code-copy = "COPYUID" SP nz-number SP uid-set SP uid-set 257 resp-text-code =/ resp-code-apnd / resp-code-copy / "UIDNOTSTICKY" 258 ; incorporated before the expansion rule of 259 ; atom [SP 1*] 260 ; which appears in [IMAP] 262 uid-expunge = "UID" SP "EXPUNGE" SP sequence-set 264 uid-set = (uniqueid / uid-range) *("," uid-set) 266 uid-range = (uniqueid ":" uniqueid) 267 ; two uniqueid values and all values 268 ; between these two regards of order. 269 ; Example: 2:4 and 4:2 are equivalent. 271 Servers which support [MULTIAPPEND] will have the following extension 272 to the above rules: 274 append-uid =/ uid-set 275 ; only permitted if client uses [MULTIAPPEND] 276 ; to append multiple messages. 278 Security Considerations 280 The COPYUID and APPENDUID response codes return information about the 281 mailbox. These response codes SHOULD NOT be issused if the client 282 does not have access to SELECT or EXAMINE the mailbox. 284 IANA Considerations 286 This document constitutes registration of the UIDPLUS capability in 287 the imap4-capabilities registry, replacing RFC 2359. 289 Normative References 291 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 292 Specifications: ABNF", RFC 2234, November 1997. 294 [IMAP] Crispin, M., "Internet Message Access Protocol - 295 Version 4rev1", RFC 3501, March 2003. 297 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 298 Requirement Levels", BCP 14, RFC 2119, March 1997. 300 [MULTIAPPEND] Crispin, M., "Internet Message Access Protocol (IMAP) - 301 MULTIAPPEND Extension", RFC 3502, March 2003. 303 [RFC-2822] Resnick, P., "Internet Message Format", RFC 2822, April 304 2001. 306 Informative References 308 [RFC-2359] Myers, J., "IMAP4 UIDPLUS extension", RFC 2359, June 309 1988. 311 Acknowledgements 313 This document obsoletes [RFC-2359]. However, it is based upon that 314 document, and takes substantial text from it. 316 Author's Address 318 Mark R. Crispin 319 Networks and Distributed Computing 320 University of Washington 321 4545 15th Avenue NE 322 Seattle, WA 98105-4527 324 Phone: (206) 543-5762 325 EMail: MRC@CAC.Washington.EDU 327 IPR Disclosure Acknowledgement 329 By submitting this Internet-Draft, I certify that any applicable 330 patent or other IPR claims of which I am aware have been disclosed, 331 and any of which I become aware will be disclosed, in accordance with 332 RFC 3668. 334 Intellectual Property Statement 336 The IETF takes no position regarding the validity or scope of any 337 intellectual property or other rights that might be claimed to 338 pertain to the implementation or use of the technology described in 339 this document or the extent to which any license under such rights 340 might or might not be available; neither does it represent that it 341 has made any effort to identify any such rights. Information on the 342 IETF's procedures with respect to rights in standards-track and 343 standards-related documentation can be found in BCP-11. Copies of 344 claims of rights made available for publication and any assurances of 345 licenses to be made available, or the result of an attempt made to 346 obtain a general license or permission for the use of such 347 proprietary rights by implementors or users of this specification can 348 be obtained from the IETF Secretariat. 350 The IETF invites any interested party to bring to its attention any 351 copyrights, patents or patent applications, or other proprietary 352 rights which may cover technology that may be required to practice 353 this standard. Please address the information to the IETF Executive 354 Director. 356 Full Copyright Statement 358 Copyright (C) The Internet Society (2005). 360 This document is subject to the rights, licenses and restrictions 361 contained in BCP 78, and except as set forth therein, the authors 362 retain all their rights. 364 This document and the information contained herein are provided 365 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 366 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 367 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 368 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 369 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 370 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 371 PARTICULAR PURPOSE. 373 Intellectual Property 375 The IETF takes no position regarding the validity or scope of any 376 Intellectual Property Rights or other rights that might be claimed to 377 pertain to the implementation or use of the technology described in 378 this document or the extent to which any license under such rights 379 might or might not be available; nor does it represent that it has 380 made any independent effort to identify any such rights. Information 381 on the procedures with respect to rights in RFC documents can be 382 found in BCP 78 and BCP 79. 384 Copies of IPR disclosures made to the IETF Secretariat and any 385 assurances of licenses to be made available, or the result of an 386 attempt made to obtain a general license or permission for the use of 387 such proprietary rights by implementers or users of this 388 specification can be obtained from the IETF on-line IPR repository at 389 http://www.ietf.org/ipr. 391 The IETF invites any interested party to bring to its attention any 392 copyrights, patents or patent applications, or other proprietary 393 rights that may cover technology that may be required to implement 394 this standard. Please address the information to the IETF at ietf- 395 ipr@ietf.org. 397 Acknowledgement 399 Funding for the RFC Editor function is currently provided by the 400 Internet Society.