idnits 2.17.1 draft-ietf-morg-list-specialuse-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year -- The document date (June 18, 2010) is 5061 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) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 3348 (Obsoleted by RFC 5258) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Message ORGanization Working Group B. Leiba 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track J. Nicolson 5 Expires: December 20, 2010 Google 6 June 18, 2010 8 IMAP LIST extension for special-use mailboxes 9 draft-ietf-morg-list-specialuse-02 11 Abstract 13 Some IMAP message stores include special-use mailboxes, such as those 14 used to hold draft messages or sent messages. Many mail clients 15 allow users to specify where draft or sent messages should be put, 16 but configuring them requires that the user know which mailboxes the 17 server has set aside for these purposes. This extension adds new 18 mailbox flags that a server MAY include in IMAP LIST command 19 responses to identify special-use mailboxes to the client, easing 20 configuration. 22 Note 24 A revised version of this draft document will be submitted to the RFC 25 editor as a Proposed Standard for the Internet Community. Discussion 26 and suggestions for improvement are requested, and should be sent to 27 morg@ietf.org. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on December 20, 2010. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Conventions used in this document . . . . . . . . . . . . . 3 65 1.2. Change log . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.2.1. Changes from -00 to -01 . . . . . . . . . . . . . . . . . . 3 68 2. New mailbox flags identifying special-use mailboxes . . . . 4 70 3. Extension to IMAP CREATE command to set special-use 71 flags . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 4.1. Example of an IMAP LIST command . . . . . . . . . . . . . . 6 75 4.2. Example of an extended IMAP LIST command . . . . . . . . . 6 76 4.3. Example of an IMAP CREATE command . . . . . . . . . . . . . 6 78 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 7 80 6. Security Considerations . . . . . . . . . . . . . . . . . . 7 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8 83 7.1. Registration of CREATE-SPECIAL-USE IMAP capability . . . . 8 84 7.2. Registration of SPECIAL-USE return option . . . . . . . . . 8 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . 8 87 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 88 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 9 92 1. Introduction 94 Some IMAP message stores include special-use mailboxes, such as those 95 used to hold draft messages or sent messages. Many mail clients 96 allow users to specify where draft or sent messages should be put, 97 but configuring them requires that the user know which mailboxes the 98 server has set aside for these purposes. This extension adds new 99 mailbox flags that a server MAY include in IMAP LIST command 100 responses to identify special-use mailboxes to the client, easing 101 configuration. 103 In addition, this extension adds an OPTIONAL parameter on the IMAP 104 CREATE command, allowing a client to assign a special use to a 105 mailbox when it is created. Servers MAY choose to support this part 106 of the extension, but are not required to. 108 1.1. Conventions used in this document 110 In examples, "C:" indicates lines sent by a client that is connected 111 to a server. "S:" indicates lines sent by the server to the client. 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC 2119 [RFC2119]. 117 1.2. Change log 119 [[RFC EDITOR: Please remove this section and its subsections.]] 121 1.2.1. Changes from -00 to -01 123 Added wording about list-extended; added reference to RFC 5258; 124 added example; added registration of list-extended return option. 126 Changed CREATE syntax to use RFC 4466; added reference to RFC 127 4466; fixed example. 129 Added "\Archive" use flag. 131 Noted that multiple mailboxes might have the same flag in some 132 implementations. 134 Changed some use flag names to be more general: \All (was 135 \AllMail), \Junk (was \Spam), \Flagged (was \Starred). 137 2. New mailbox flags identifying special-use mailboxes 139 An IMAP server that supports this extension MAY include any or all of 140 the following flags in responses to the non-extended IMAP LIST 141 command. The new flags are included along with existing flags, such 142 as "\Marked" and "\Noselect". A given mailbox may have none, one, or 143 more than one of these flags. In some cases, a special use is advice 144 to a client about what to put in that mailbox. In other cases, it's 145 advice to a client about what to expect to find there. 147 For the extended list command [RFC5258], this extension adds a new 148 return option, "SPECIAL-USE". The new special-use flags SHOULD be 149 returned if the client specifies the SPECIAL-USE return option, and 150 MAY be returned even if the client does not specify it. 152 The new flags defined here are as follows: 154 \Drafts 155 This mailbox is used to hold draft messages -- typically, 156 messages that are being composed but have not yet been sent. In 157 some server implementations, this might be a virtual mailbox, 158 containing messages from other mailboxes that are marked with 159 the "\Draft" message flag. Alternatively, this might just be 160 advice that a client put drafts here. 162 \Flagged 163 This mailbox presents all messages marked in some way as 164 "important". When this special use is supported, it is likely 165 to represent a virtual mailbox collecting messages (from other 166 mailboxes) that are marked with the "\Flagged" message flag. 168 \Junk 169 This mailbox is where messages deemed to be junk mail are held. 170 Some server implementations might put messages here 171 automatically. Alternatively, this might just be advice to a 172 client-side spam filter. 174 \Sent 175 This mailbox is used to hold copies of messages that have been 176 sent. Some server implementations might put messages here 177 automatically. Alternatively, this might just be advice that a 178 client save sent messages here. 180 \Trash 181 This mailbox is used to hold messages that have been deleted, or 182 marked for deletion. In some server implementations, this might 183 be a virtual mailbox, containing messages from other mailboxes 184 that are marked with the "\Deleted" message flag. 186 Alternatively, this might just be advice that a client that 187 chooses not to use the IMAP "\Deleted" model should use this as 188 its trash location. In server implementations that strictly 189 expect the IMAP "\Deleted" model, this special use is likely not 190 to be supported. 192 \All 193 This mailbox presents all messages in the user's message store. 194 Implementations MAY omit some messages, such as, perhaps, those 195 in \Trash and \Junk. When this special use is supported, it is 196 almost certain to represent a virtual mailbox. 198 \Archive 199 This mailbox is used to archive messages. The meaning of an 200 "archival" mailbox is server-dependent; typically, it will be 201 used to get messages out of the inbox, or otherwise keep them 202 out of the user's way, while still making them accessible. 204 All of the above flags are OPTIONAL, and any given server or message 205 store may support any combination of the flags, or none at all. In 206 some server or message store implementations it might be possible for 207 multiple mailboxes to have the same special-use flag. There is no 208 capability string associated with this feature. 210 3. Extension to IMAP CREATE command to set special-use flags 212 As an OPTIONAL feature, a server MAY allow clients to designate a 213 mailbox, at creation, as having one or more special uses. This 214 extension defines the "USE" parameter to the IMAP CREATE command for 215 that purpose (using the syntax defined in RFC 4466 section 2.2 216 [RFC4466]). The new OPTIONAL "USE" parameter is followed by a 217 parenthesized list of zero or more special-use flags, as defined 218 above. 220 In some server implementations, some special uses may imply automatic 221 action by the server. For example, creation of a "\Junk" mailbox 222 might cause the server to start placing messages that have been 223 evaluated as spam into the mailbox. 225 In some server implementations, some special uses may result in a 226 mailbox with unusual characteristics or side effects. For example, 227 creation of an "\All" mailbox might cause the server to create a 228 virtual mailbox, rather than a standard one, and that mailbox might 229 behave in unexpected ways (COPY into it might fail, for example). 231 Servers MAY allow the creation of a special-use mailbox even if one 232 so designated already exists, having the effect of moving the special 233 use from the old mailbox to the new one. Alternatively, servers MAY 234 refuse the creation, considering the designation to be a conflict. 236 If the server can not create a mailbox with the designated special 237 use defined, for whatever reason, it MUST NOT create the mailbox, and 238 MUST respond to the CREATE command with a tagged NO response. 240 An IMAP server that supports this OPTIONAL feature will advertise the 241 CREATE-SPECIAL-USE capability string. Clients MUST NOT use the "USE" 242 parameter unless the server advertises the capability. 244 4. Examples 246 4.1. Example of an IMAP LIST command 248 This example shows an IMAP LIST response from a server that supports 249 this extension. Note that not all of the flags are used. This 250 server also supports the Child Mailbox extension [RFC3348]. 252 C: t1 LIST "" "%" 253 S: * LIST (\Marked \HasNoChildren) "/" Inbox 254 S: * LIST (\HasNoChildren) "/" ToDo 255 S: * LIST (\HasChildren) "/" Projects 256 S: * LIST (\Sent \HasNoChildren) "/" SentMail 257 S: * LIST (\Marked \Drafts \HasNoChildren) "/" MyDrafts 258 S: * LIST (\Trash \HasNoChildren) "/" Trash 259 S: t1 OK done 261 4.2. Example of an extended IMAP LIST command 263 This example shows an IMAP LIST response from a server that supports 264 this extension. The client uses the extended IMAP LIST command. 266 C: t1 LIST "" "%" RETURN (SPECAL-USE) 267 S: * LIST (\Marked) "/" Inbox 268 S: * LIST () "/" ToDo 269 S: * LIST () "/" Projects 270 S: * LIST (\Sent) "/" SentMail 271 S: * LIST (\Marked \Drafts) "/" MyDrafts 272 S: * LIST (\Trash) "/" Trash 273 S: t1 OK done 275 4.3. Example of an IMAP CREATE command 277 This example shows an IMAP CREATE command that might be used to 278 create a mailbox designated to hold draft and sent messages. It also 279 attempts to create a mailbox that will contain all the user's 280 messages, but the server does not support that special use for this 281 user's message store. 283 C: t1 CAPABILITY 284 S: * CAPABILITY IMAP4rev1 CREATE-SPECIAL-USE 285 S: t1 OK done 286 C: t2 CREATE MySpecial (USE (\Drafts \Sent)) 287 S: t2 OK MySpecial created 288 C: t3 CREATE Everything (USE (\All)) 289 S: t3 NO \All not supported 291 5. Formal Syntax 293 The following syntax specification uses the augmented Backus-Naur 294 Form (BNF) as described in [RFC5234]. 296 create-param =/ "USE" SP "(" [use-flag *(SP use-flag)] ")" 297 ; Extends "create-param" from RFC 4466 [RFC4466] 299 mbx-list-oflag =/ use-flag 300 ; Extends "mbx-list-oflag" from IMAP base [RFC3501] 302 return-option =/ "SPECIAL-USE" 303 ; Extends "return-option" from 304 ; LIST-extended [RFC5258] 306 use-flag = "\All" / "\Archive" / "\Drafts" / "\Flagged" / 307 "\Junk" / "\Sent" / "\Trash" / use-flag-ext 309 use-flag-ext = "\" atom 310 ; Reserved for future extensions. Clients 311 ; MUST ignore list flags they do not understand 312 ; Server implementations MUST NOT generate 313 ; extension flags except as defined by 314 ; future standards-track revisions of or 315 ; extensions to this specification. 317 6. Security Considerations 319 LIST response: There are no security issues with conveying special- 320 use information to a client. 322 CREATE command "USE" parameter: In some server implementations, some 323 special uses may imply automatic action by the server. For example, 324 creation of a "\Junk" mailbox might cause the server to start placing 325 messages that have been evaluated as spam into the mailbox. Server 326 implementors SHOULD consider the consequences of allowing a user (or 327 client program) to designate the target of such automatic action. 329 7. IANA Considerations 331 7.1. Registration of CREATE-SPECIAL-USE IMAP capability 333 This document defines a new IMAP capability. IANA is asked to add 334 "CREATE-SPECIAL-USE" to the imap4-capabilities registry. 336 7.2. Registration of SPECIAL-USE return option 338 This document defines a new IMAP4 List Extended return option. IANA 339 is asked to add "SPECIAL-USE" to the imap4-list-extended registry, as 340 follows: 342 To: iana@iana.org 343 Subject: Registration of LIST-EXTENDED option SPECIAL-USE 344 LIST-EXTENDED option name: SPECIAL-USE 345 LIST-EXTENDED option type: RETURN 346 LIST-EXTENDED option description: Request special-use mailbox 347 information 348 Published specification: [[this RFC]] 349 Security considerations: none 350 Intended usage: COMMON 351 Person and email address to contact for further information: Authors' 352 Addresses at the end of [[this RFC]] 353 Owner/Change controller: iesg@ietf.org 355 8. References 357 8.1. Normative References 359 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 360 Requirement Levels", RFC 2119, March 1997. 362 [RFC3501] Crispin, M., Ed., "Internet Message Access Protocol", 363 RFC 3501, March 2003. 365 [RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 366 ABNF", RFC 4466, April 2006. 368 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 369 Specifications: ABNF", RFC 5234, January 2008. 371 [RFC5258] Leiba, B. and A. Melnikov, "Internet Message Access 372 Protocol version 4 - LIST Command Extensions", RFC 5258, 373 June 2008. 375 8.2. Informative References 377 [RFC3348] Gahrns, M. and R. Cheng, "The Internet Message Action 378 Protocol (IMAP4) Child Mailbox Extension", RFC 3348, 379 July 2002. 381 Authors' Addresses 383 Barry Leiba 384 Huawei Technologies 386 Phone: +1 646 827 0648 387 Email: barryleiba@computer.org 388 URI: http://internetmessagingtechnology.org/ 390 Jamie Nicolson 391 Google 393 Email: nicolson@google.com