idnits 2.17.1 draft-ietf-morg-list-specialuse-06.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 (December 15, 2010) is 4879 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: June 18, 2011 Google 6 December 15, 2010 8 IMAP LIST extension for special-use mailboxes 9 draft-ietf-morg-list-specialuse-06 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 optional mailbox attributes that a server may include in IMAP LIST 19 command responses to identify special-use mailboxes to the client, 20 easing configuration. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on June 18, 2011. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Conventions used in this document . . . . . . . . . . . . . 3 59 2. New mailbox attributes identifying special-use mailboxes . . 3 61 3. Extension to IMAP CREATE command to set special-use 62 attributes . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 4. IMAP METADATA entry for special-use attributes . . . . . . . 6 66 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 5.1. Example of an IMAP LIST command . . . . . . . . . . . . . . 7 68 5.2. Example of an extended IMAP LIST command . . . . . . . . . . 7 69 5.3. Example of an IMAP CREATE command . . . . . . . . . . . . . 8 70 5.4. Example of using IMAP METADATA to manipulate special-use 71 attributes . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 9 75 7. Security Considerations . . . . . . . . . . . . . . . . . . 10 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 10 78 8.1. Registration of USEATTR IMAP response code . . . . . . . . . 11 79 8.2. Registration of CREATE-SPECIAL-USE IMAP capability . . . . . 11 80 8.3. Registration of SPECIAL-USE IMAP capability . . . . . . . . 11 81 8.4. Registration of SPECIAL-USE selection option . . . . . . . . 11 82 8.5. Registration of SPECIAL-USE return option . . . . . . . . . 11 83 8.6. Registration of SPECIAL-USE metadata . . . . . . . . . . . . 12 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 9.1. Normative References . . . . . . . . . . . . . . . . . . . . 12 87 9.2. Informative References . . . . . . . . . . . . . . . . . . . 13 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13 91 1. Introduction 93 Some IMAP message stores include special-use mailboxes, such as those 94 used to hold draft messages or sent messages. Many mail clients 95 allow users to specify where draft or sent messages should be put, 96 but configuring them requires that the user know which mailboxes the 97 server has set aside for these purposes. This extension adds new 98 optional mailbox attributes that a server may include in IMAP LIST 99 command responses to identify special-use mailboxes to the client, 100 easing configuration. 102 In addition, this extension adds an optional parameter on the IMAP 103 CREATE command, allowing a client to assign a special use to a 104 mailbox when it is created. Servers may choose to support this part 105 of the extension, but are not required to. 107 1.1. Conventions used in this document 109 In examples, "C:" indicates lines sent by a client that is connected 110 to a server. "S:" indicates lines sent by the server to the client. 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [RFC2119]. 116 2. New mailbox attributes identifying special-use mailboxes 118 An IMAP server that supports this extension MAY include any or all of 119 the following attributes in responses to the non-extended IMAP LIST 120 command. The new attributes are included along with existing 121 attributes, such as "\Marked" and "\Noselect". A given mailbox may 122 have none, one, or more than one of these attributes. In some cases, 123 a special use is advice to a client about what to put in that 124 mailbox. In other cases, it's advice to a client about what to 125 expect to find there. There is no capability string related to the 126 support of special-use attributes on the non-extended LIST command. 128 For the extended list command [RFC5258], this extension adds a new 129 capability string, a new selection option, and a new return option, 130 all called "SPECIAL-USE". Supporting implementations MUST include 131 the "SPECIAL-USE" capability string in response to an IMAP CAPABILITY 132 command. If the client specifies the "SPECIAL-USE" selection option, 133 the LIST command MUST return only those mailboxes that have a 134 special-use attribute set. If the client specifies the "SPECIAL-USE" 135 return option, the LIST command MUST return the new special-use 136 attributes on those mailboxes that have them set. The "SPECIAL-USE" 137 return option is implied by the "SPECIAL-USE" selection option. The 138 extended LIST command MAY return SPECIAL-USE attributes even if the 139 client does not specify the return option. 141 The new attributes defined here are as follows: 143 \Drafts 144 This mailbox is used to hold draft messages -- typically, 145 messages that are being composed but have not yet been sent. In 146 some server implementations, this might be a virtual mailbox, 147 containing messages from other mailboxes that are marked with 148 the "\Draft" message flag. Alternatively, this might just be 149 advice that a client put drafts here. 151 \Flagged 152 This mailbox presents all messages marked in some way as 153 "important". When this special use is supported, it is likely 154 to represent a virtual mailbox collecting messages (from other 155 mailboxes) that are marked with the "\Flagged" message flag. 157 \Junk 158 This mailbox is where messages deemed to be junk mail are held. 159 Some server implementations might put messages here 160 automatically. Alternatively, this might just be advice to a 161 client-side spam filter. 163 \Sent 164 This mailbox is used to hold copies of messages that have been 165 sent. Some server implementations might put messages here 166 automatically. Alternatively, this might just be advice that a 167 client save sent messages here. 169 \Trash 170 This mailbox is used to hold messages that have been deleted, or 171 marked for deletion. In some server implementations, this might 172 be a virtual mailbox, containing messages from other mailboxes 173 that are marked with the "\Deleted" message flag. 174 Alternatively, this might just be advice that a client that 175 chooses not to use the IMAP "\Deleted" model should use this as 176 its trash location. In server implementations that strictly 177 expect the IMAP "\Deleted" model, this special use is likely not 178 to be supported. 180 \All 181 This mailbox presents all messages in the user's message store. 182 Implementations MAY omit some messages, such as, perhaps, those 183 in \Trash and \Junk. When this special use is supported, it is 184 almost certain to represent a virtual mailbox. 186 \Archive 187 This mailbox is used to archive messages. The meaning of an 188 "archival" mailbox is server-dependent; typically, it will be 189 used to get messages out of the inbox, or otherwise keep them 190 out of the user's way, while still making them accessible. 192 All of the above attributes are OPTIONAL, and any given server or 193 message store may support any combination of the attributes, or none 194 at all. In most cases there will likely be at most one mailbox with 195 a given attribute for a given user, but in some server or message 196 store implementations it might be possible for multiple mailboxes to 197 have the same special-use attribute. 199 Special-use attributes are likely to be user-specific. User Adam 200 might share his \Sent mailbox with user Barb, but that mailbox is 201 unlikely to also serve as Barb's \Sent mailbox. It's certainly 202 possible for Adam and Barb to each set the \Sent use on the same 203 mailbox, but that would be done by specific action (see the sections 204 below). 206 3. Extension to IMAP CREATE command to set special-use attributes 208 As an OPTIONAL feature, a server MAY allow clients to designate a 209 mailbox, at creation, as having one or more special uses. This 210 extension defines the "USE" parameter to the IMAP CREATE command for 211 that purpose (using the syntax defined in RFC 4466 section 2.2 212 [RFC4466]). The new OPTIONAL "USE" parameter is followed by a 213 parenthesized list of zero or more special-use attributes, as defined 214 above. 216 In some server implementations, some special uses may imply automatic 217 action by the server. For example, creation of a "\Junk" mailbox 218 might cause the server to start placing messages that have been 219 evaluated as spam into the mailbox. 221 In some server implementations, some special uses may result in a 222 mailbox with unusual characteristics or side effects. For example, 223 creation of an "\All" mailbox might cause the server to create a 224 virtual mailbox, rather than a standard one, and that mailbox might 225 behave in unexpected ways (COPY into it might fail, for example). 227 Servers MAY allow the creation of a special-use mailbox even if one 228 so designated already exists, having the effect of moving the special 229 use from the old mailbox to the new one. Alternatively, servers MAY 230 refuse the creation, considering the designation to be a conflict. 232 If the server can not create a mailbox with the designated special 233 use defined, for whatever reason, it MUST NOT create the mailbox, and 234 MUST respond to the CREATE command with a tagged NO response. If the 235 reason for the failure is related to the special-use attribute (the 236 specified special use is not supported or cannot be assigned to the 237 specified mailbox), the server SHOULD include the new "USEATTR" 238 response code in the tagged response (see Section 5.3 for an 239 example). 241 An IMAP server that supports this OPTIONAL feature will advertise the 242 CREATE-SPECIAL-USE capability string. Clients MUST NOT use the "USE" 243 parameter unless the server advertises the capability. Note that 244 this capability string is different from the SPECIAL-USE string 245 defined above, and a server that supports both functions MUST 246 advertise both capability strings. 248 4. IMAP METADATA entry for special-use attributes 250 If a server supports this extension and the METADATA extension 251 [RFC5464], it SHOULD tie the special-use attributes for a mailbox to 252 its metadata entry "/shared/specialuse". The value of /shared/ 253 specialuse is either NIL (if there are no special-use attributes for 254 that mailbox) or a space-separated list of special-use attributes, 255 presented the same way they would be presented in the LIST command 256 response. 258 Such a server MAY allow the setting of special-use attributes through 259 the METADATA mechanisms, thereby allowing clients to change the 260 special uses of existing mailboxes. These changes might have side 261 effects, as the server automatically adjusts the special uses 262 accordingly, just as it might do with CREATE USE, above. See 263 Section 5.4 for an example. 265 A server that supports this MUST check the validity of changes to the 266 special-use attributes that are done through the metadata in the same 267 way that it checks validity for the CREATE command and for any 268 internal mechanisms for setting special uses on mailboxes. It MUST 269 NOT just blindly accept setting of these metadata by clients, which 270 might result in the setting of special uses that the implementation 271 does not support, multiple mailboxes with the same special use, or 272 other situations that the implementation considers invalid. 274 5. Examples 275 5.1. Example of an IMAP LIST command 277 This example shows an IMAP LIST response from a server that supports 278 this extension. Note that not all of the attributes are used. This 279 server also supports the Child Mailbox extension [RFC3348]. 281 C: t1 LIST "" "%" 282 S: * LIST (\Marked \HasNoChildren) "/" Inbox 283 S: * LIST (\HasNoChildren) "/" ToDo 284 S: * LIST (\HasChildren) "/" Projects 285 S: * LIST (\Sent \HasNoChildren) "/" SentMail 286 S: * LIST (\Marked \Drafts \HasNoChildren) "/" MyDrafts 287 S: * LIST (\Trash \HasNoChildren) "/" Trash 288 S: t1 OK done 290 5.2. Example of an extended IMAP LIST command 292 This example shows an IMAP LIST response from a server that supports 293 this extension. The client uses the extended IMAP LIST command. 295 C: t1 CAPABILITY 296 S: * CAPABILITY IMAP4rev1 SPECIAL-USE 297 S: t1 OK done 299 C: t2 LIST "" "%" RETURN (SPECIAL-USE) 300 S: * LIST (\Marked) "/" Inbox 301 S: * LIST () "/" ToDo 302 S: * LIST () "/" Projects 303 S: * LIST (\Sent) "/" SentMail 304 S: * LIST (\Marked \Drafts) "/" MyDrafts 305 S: * LIST (\Trash) "/" Trash 306 S: t2 OK done 308 Here, the client also includes the "SPECIAL-USE" selection option for 309 the same list. The "SPECIAL-USE" return option could also have been 310 specified, but it is unnecessary, as it is implied by the selection 311 option. Note that in this case, mailboxes that do not have a 312 special-use attribute are not listed. Also note that we've used the 313 wildcard "*", rather than "%", to make sure we see all special-use 314 mailboxes, even ones that might not be at the namespace's root. 316 C: t3 LIST (SPECIAL-USE) "" "*" 317 S: * LIST (\Sent) "/" SentMail 318 S: * LIST (\Marked \Drafts) "/" MyDrafts 319 S: * LIST (\Trash) "/" Trash 320 S: t3 OK done 322 5.3. Example of an IMAP CREATE command 324 This example shows an IMAP CREATE command that might be used to 325 create a mailbox designated to hold draft and sent messages. It also 326 attempts to create a mailbox that will contain all the user's 327 messages, but the server does not support that special use for this 328 user's message store. 330 C: t1 CAPABILITY 331 S: * CAPABILITY IMAP4rev1 CREATE-SPECIAL-USE 332 S: t1 OK done 334 C: t2 CREATE MySpecial (USE (\Drafts \Sent)) 335 S: t2 OK MySpecial created 337 C: t3 CREATE Everything (USE (\All)) 338 S: t3 NO [USEATTR] \All not supported 340 5.4. Example of using IMAP METADATA to manipulate special-use 341 attributes 343 This example shows how IMAP METADATA can be used to manipulate 344 special-use attributes, if the operation is supported on the server. 346 ==> Starting point: 347 C: t1 LIST "" "%" RETURN (SPECIAL-USE) 348 S: * LIST (\Sent) "/" SentMail 349 S: * LIST (\Drafts) "/" MyDrafts 350 S: * LIST () "/" SavedDrafts 351 S: * LIST (\Trash) "/" Trash 352 S: t1 OK done 354 ==> Demonstrate the connection: 355 C: t2 GETMETADATA "MyDrafts" /shared/specialuse 356 S: * METADATA "MyDrafts" (/shared/specialuse "\Drafts") 357 S: t2 OK done 359 ==> Set new use for SavedDrafts; MyDrafts changes automatically: 360 C: t3 SETMETADATA "SavedDrafts" (/shared/specialuse "\Drafts") 361 S: * METADATA "MyDrafts" (/shared/specialuse NIL) 362 S: t3 OK SETMETADATA complete 364 ==> Remove special use for SentMail: 365 C: t4 SETMETADATA "SentMail" (/shared/specialuse NIL) 366 S: t4 OK SETMETADATA complete 368 ==> Check the results: 369 C: t5 LIST "" "%" RETURN (SPECIAL-USE) 370 S: * LIST () "/" SentMail 371 S: * LIST () "/" MyDrafts 372 S: * LIST (\Drafts) "/" SavedDrafts 373 S: * LIST (\Trash) "/" Trash 374 S: t5 OK done 376 6. Formal Syntax 378 The following syntax specification uses the augmented Backus-Naur 379 Form (BNF) as described in [RFC5234]. 381 create-param =/ "USE" SP "(" [use-attr *(SP use-attr)] ")" 382 ; Extends "create-param" from RFC 4466 [RFC4466] 384 mbx-list-oflag =/ use-attr 385 ; Extends "mbx-list-oflag" from IMAP base [RFC3501] 387 list-select-independent-opt =/ "SPECIAL-USE" 388 ; Extends "list-select-independent-opt" from 389 ; LIST-extended [RFC5258] 391 return-option =/ "SPECIAL-USE" 392 ; Extends "return-option" from 393 ; LIST-extended [RFC5258] 395 resp-text-code =/ "USEATTR" 396 ; Extends "resp-text-code" from 397 ; IMAP [RFC3501] 399 use-attr = "\All" / "\Archive" / "\Drafts" / "\Flagged" / 400 "\Junk" / "\Sent" / "\Trash" / use-attr-ext 402 use-attr-ext = "\" atom 403 ; Reserved for future extensions. Clients 404 ; MUST ignore list attributes they do not understand 405 ; Server implementations MUST NOT generate 406 ; extension attributes except as defined by 407 ; future standards-track revisions of or 408 ; extensions to this specification. 410 7. Security Considerations 412 LIST response: There are no security issues with conveying special- 413 use information to a client. 415 CREATE command "USE" parameter and metadata extension: In some server 416 implementations, some special uses may imply automatic action by the 417 server. For example, creation of a "\Junk" mailbox might cause the 418 server to start placing messages that have been evaluated as spam 419 into the mailbox. Implementors SHOULD consider the consequences of 420 allowing a user (or client program) to designate the target of such 421 automatic action. 423 Example: If a user is allowed to give the "\Junk" attribute to a 424 shared mailbox, legitimate mail that's misclassified as junk (false 425 positives) will be put into that shared mailbox, exposing the user's 426 private mail to others. The server might warn a user of that 427 possibility, or might refuse to allow the specification to be made on 428 a shared mailbox. (Note that this problem exists independent of this 429 specification, if the server allows a user to share a mailbox that's 430 already in use for such a function.) 432 8. IANA Considerations 433 8.1. Registration of USEATTR IMAP response code 435 This document defines a new IMAP response code. IANA is asked to add 436 "USEATTR" to the IMAP Response Codes registry. 438 8.2. Registration of CREATE-SPECIAL-USE IMAP capability 440 This document defines a new IMAP capability. IANA is asked to add 441 "CREATE-SPECIAL-USE" to the IMAP 4 Capabilities registry. 443 8.3. Registration of SPECIAL-USE IMAP capability 445 This document defines a new IMAP capability. IANA is asked to add 446 "SPECIAL-USE" to the IMAP 4 Capabilities registry. 448 8.4. Registration of SPECIAL-USE selection option 450 This document defines a new IMAP4 List Extended selection option. 451 IANA is asked to add "SPECIAL-USE" to the IMAP4 List Extended 452 registry, as follows: 454 To: iana@iana.org 455 Subject: Registration of LIST-EXTENDED selection option SPECIAL-USE 456 LIST-EXTENDED option name: SPECIAL-USE 457 LIST-EXTENDED option type: SELECTION 458 Implied return option(s): SPECIAL-USE 459 LIST-EXTENDED option description: Limit the list to special-use 460 mailboxes only 461 Published specification: [[this RFC]] 462 Security considerations: none 463 Intended usage: COMMON 464 Person and email address to contact for further information: Authors' 465 Addresses at the end of [[this RFC]] 466 Owner/Change controller: iesg@ietf.org 468 8.5. Registration of SPECIAL-USE return option 470 This document defines a new IMAP4 List Extended return option. IANA 471 is asked to add "SPECIAL-USE" to the IMAP4 List Extended registry, as 472 follows: 474 To: iana@iana.org 475 Subject: Registration of LIST-EXTENDED return option SPECIAL-USE 476 LIST-EXTENDED option name: SPECIAL-USE 477 LIST-EXTENDED option type: RETURN 478 LIST-EXTENDED option description: Request special-use mailbox 479 information 480 Published specification: [[this RFC]] 481 Security considerations: none 482 Intended usage: COMMON 483 Person and email address to contact for further information: Authors' 484 Addresses at the end of [[this RFC]] 485 Owner/Change controller: iesg@ietf.org 487 8.6. Registration of SPECIAL-USE metadata 489 This document defines a new IMAP METADATA entry. IANA is asked to 490 add the following to the IMAP METADATA Mailbox Entry registry: 492 To: iana@iana.org 493 Subject: IMAP METADATA Entry Registration 494 Type: Mailbox 495 Name: /shared/specialuse 496 Description: Defines any special-use features of a mailbox. See the 497 reference specification for details of its use. 498 Content-type: text/plain; charset=us-ascii 499 RFC Number: [[this RFC]] 500 Contact: MORG mailing list mailto:morg@ietf.org 502 9. References 504 9.1. Normative References 506 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 507 Requirement Levels", BCP 14, RFC 2119, March 1997. 509 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 510 4rev1", RFC 3501, March 2003. 512 [RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 513 ABNF", RFC 4466, April 2006. 515 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 516 Specifications: ABNF", STD 68, RFC 5234, January 2008. 518 [RFC5258] Leiba, B. and A. Melnikov, "Internet Message Access 519 Protocol version 4 - LIST Command Extensions", RFC 5258, 520 June 2008. 522 [RFC5464] Daboo, C., "The IMAP METADATA Extension", RFC 5464, 523 February 2009. 525 9.2. Informative References 527 [RFC3348] Gahrns, M. and R. Cheng, "The Internet Message Action 528 Protocol (IMAP4) Child Mailbox Extension", RFC 3348, 529 July 2002. 531 Authors' Addresses 533 Barry Leiba 534 Huawei Technologies 536 Phone: +1 646 827 0648 537 Email: barryleiba@computer.org 538 URI: http://internetmessagingtechnology.org/ 540 Jamie Nicolson 541 Google 543 Email: nicolson@google.com