idnits 2.17.1 draft-ietf-morg-list-specialuse-05.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 1, 2010) is 4894 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 4, 2011 Google 6 December 1, 2010 8 IMAP LIST extension for special-use mailboxes 9 draft-ietf-morg-list-specialuse-05 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 attributes 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 June 4, 2011. 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.1. Conventions used in this document . . . . . . . . . . . . . 4 66 2. New mailbox attributes identifying special-use mailboxes . . 4 68 3. Extension to IMAP CREATE command to set special-use 69 attributes . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 4. IMAP METADATA entry for special-use attributes . . . . . . . 7 73 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 5.1. Example of an IMAP LIST command . . . . . . . . . . . . . . 7 75 5.2. Example of an extended IMAP LIST command . . . . . . . . . . 8 76 5.3. Example of an IMAP CREATE command . . . . . . . . . . . . . 8 77 5.4. Example of using IMAP METADATA to manipulate special-use 78 attributes . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 10 82 7. Security Considerations . . . . . . . . . . . . . . . . . . 10 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11 85 8.1. Registration of USEATTR IMAP response code . . . . . . . . . 11 86 8.2. Registration of CREATE-SPECIAL-USE IMAP capability . . . . . 11 87 8.3. Registration of SPECIAL-USE IMAP capability . . . . . . . . 11 88 8.4. Registration of SPECIAL-USE selection option . . . . . . . . 11 89 8.5. Registration of SPECIAL-USE return option . . . . . . . . . 11 90 8.6. Registration of SPECIAL-USE metadata . . . . . . . . . . . . 12 92 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 93 9.1. Normative References . . . . . . . . . . . . . . . . . . . . 12 94 9.2. Informative References . . . . . . . . . . . . . . . . . . . 13 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13 97 1. Introduction 99 Some IMAP message stores include special-use mailboxes, such as those 100 used to hold draft messages or sent messages. Many mail clients 101 allow users to specify where draft or sent messages should be put, 102 but configuring them requires that the user know which mailboxes the 103 server has set aside for these purposes. This extension adds new 104 mailbox attributes that a server MAY include in IMAP LIST command 105 responses to identify special-use mailboxes to the client, easing 106 configuration. 108 In addition, this extension adds an OPTIONAL parameter on the IMAP 109 CREATE command, allowing a client to assign a special use to a 110 mailbox when it is created. Servers MAY choose to support this part 111 of the extension, but are not required to. 113 1.1. Conventions used in this document 115 In examples, "C:" indicates lines sent by a client that is connected 116 to a server. "S:" indicates lines sent by the server to the client. 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in RFC 2119 [RFC2119]. 122 2. New mailbox attributes identifying special-use mailboxes 124 An IMAP server that supports this extension MAY include any or all of 125 the following attributes in responses to the non-extended IMAP LIST 126 command. The new attributes are included along with existing 127 attributes, such as "\Marked" and "\Noselect". A given mailbox may 128 have none, one, or more than one of these attributes. In some cases, 129 a special use is advice to a client about what to put in that 130 mailbox. In other cases, it's advice to a client about what to 131 expect to find there. There is no capability string related to the 132 support of special-use attributes on the non-extended LIST command. 134 For the extended list command [RFC5258], this extension adds a new 135 capability string, a new selection option, and a new return option, 136 all called "SPECIAL-USE". Supporting implementations MUST include 137 the "SPECIAL-USE" capability string in response to an IMAP CAPABILITY 138 command. If the client specifies the "SPECIAL-USE" selection option, 139 the LIST command MUST return only those mailboxes that have a 140 special-use attribute set. If the client specifies the "SPECIAL-USE" 141 return option, the LIST command MUST return the new special-use 142 attributes on those mailboxes that have them set. The "SPECIAL-USE" 143 return option is implied by the "SPECIAL-USE" selection option. The 144 extended LIST command MAY return SPECIAL-USE attributes even if the 145 client does not specify the return option. 147 The new attributes defined here are as follows: 149 \Drafts 150 This mailbox is used to hold draft messages -- typically, 151 messages that are being composed but have not yet been sent. In 152 some server implementations, this might be a virtual mailbox, 153 containing messages from other mailboxes that are marked with 154 the "\Draft" message flag. Alternatively, this might just be 155 advice that a client put drafts here. 157 \Flagged 158 This mailbox presents all messages marked in some way as 159 "important". When this special use is supported, it is likely 160 to represent a virtual mailbox collecting messages (from other 161 mailboxes) that are marked with the "\Flagged" message flag. 163 \Junk 164 This mailbox is where messages deemed to be junk mail are held. 165 Some server implementations might put messages here 166 automatically. Alternatively, this might just be advice to a 167 client-side spam filter. 169 \Sent 170 This mailbox is used to hold copies of messages that have been 171 sent. Some server implementations might put messages here 172 automatically. Alternatively, this might just be advice that a 173 client save sent messages here. 175 \Trash 176 This mailbox is used to hold messages that have been deleted, or 177 marked for deletion. In some server implementations, this might 178 be a virtual mailbox, containing messages from other mailboxes 179 that are marked with the "\Deleted" message flag. 180 Alternatively, this might just be advice that a client that 181 chooses not to use the IMAP "\Deleted" model should use this as 182 its trash location. In server implementations that strictly 183 expect the IMAP "\Deleted" model, this special use is likely not 184 to be supported. 186 \All 187 This mailbox presents all messages in the user's message store. 188 Implementations MAY omit some messages, such as, perhaps, those 189 in \Trash and \Junk. When this special use is supported, it is 190 almost certain to represent a virtual mailbox. 192 \Archive 193 This mailbox is used to archive messages. The meaning of an 194 "archival" mailbox is server-dependent; typically, it will be 195 used to get messages out of the inbox, or otherwise keep them 196 out of the user's way, while still making them accessible. 198 All of the above attributes are OPTIONAL, and any given server or 199 message store may support any combination of the attributes, or none 200 at all. In some server or message store implementations it might be 201 possible for multiple mailboxes to have the same special-use 202 attribute. 204 Special-use attributes are likely to be user-specific. User Adam 205 might share his \Sent mailbox with user Barb, but that mailbox is 206 unlikely to also serve as Barb's \Sent mailbox. It's certainly 207 possible for Adam and Barb to each set the \Sent use on the same 208 mailbox, but that would be done by specific action (see the sections 209 below). 211 3. Extension to IMAP CREATE command to set special-use attributes 213 As an OPTIONAL feature, a server MAY allow clients to designate a 214 mailbox, at creation, as having one or more special uses. This 215 extension defines the "USE" parameter to the IMAP CREATE command for 216 that purpose (using the syntax defined in RFC 4466 section 2.2 217 [RFC4466]). The new OPTIONAL "USE" parameter is followed by a 218 parenthesized list of zero or more special-use attributes, as defined 219 above. 221 In some server implementations, some special uses may imply automatic 222 action by the server. For example, creation of a "\Junk" mailbox 223 might cause the server to start placing messages that have been 224 evaluated as spam into the mailbox. 226 In some server implementations, some special uses may result in a 227 mailbox with unusual characteristics or side effects. For example, 228 creation of an "\All" mailbox might cause the server to create a 229 virtual mailbox, rather than a standard one, and that mailbox might 230 behave in unexpected ways (COPY into it might fail, for example). 232 Servers MAY allow the creation of a special-use mailbox even if one 233 so designated already exists, having the effect of moving the special 234 use from the old mailbox to the new one. Alternatively, servers MAY 235 refuse the creation, considering the designation to be a conflict. 237 If the server can not create a mailbox with the designated special 238 use defined, for whatever reason, it MUST NOT create the mailbox, and 239 MUST respond to the CREATE command with a tagged NO response. If the 240 reason for the failure is related to the special-use attribute (the 241 specified special use is not supported or cannot be assigned to the 242 specified mailbox), the server SHOULD include the new "USEATTR" 243 response code in the tagged response (see Section 5.3 for an 244 example). 246 An IMAP server that supports this OPTIONAL feature will advertise the 247 CREATE-SPECIAL-USE capability string. Clients MUST NOT use the "USE" 248 parameter unless the server advertises the capability. Note that 249 this capability string is different from the SPECIAL-USE string 250 defined above, and a server that supports both functions MUST 251 advertise both capability strings. 253 4. IMAP METADATA entry for special-use attributes 255 If a server supports this extension and the METADATA extension 256 [RFC5464], it SHOULD tie the special-use attributes for a mailbox to 257 its metadata entry "/shared/specialuse". The value of /shared/ 258 specialuse is either NIL (if there are no special-use attributes for 259 that mailbox) or a space-separated list of special-use attributes, 260 presented the same way they would be presented in the LIST command 261 response. 263 Such a server MAY allow the setting of special-use attributes through 264 the METADATA mechanisms, thereby allowing clients to change the 265 special uses of existing mailboxes. These changes might have side 266 effects, as the server automatically adjusts the special uses 267 accordingly, just as it might do with CREATE USE, above. See 268 Section 5.4 for an example. 270 A server that supports this MUST check the validity of changes to the 271 special-use attributes that are done through the metadata. It MUST 272 NOT allow a client to set invalid or unsupported attributes, nor to 273 create conflicting or otherwise invalid situations. 275 5. Examples 277 5.1. Example of an IMAP LIST command 279 This example shows an IMAP LIST response from a server that supports 280 this extension. Note that not all of the attributes are used. This 281 server also supports the Child Mailbox extension [RFC3348]. 283 C: t1 LIST "" "%" 284 S: * LIST (\Marked \HasNoChildren) "/" Inbox 285 S: * LIST (\HasNoChildren) "/" ToDo 286 S: * LIST (\HasChildren) "/" Projects 287 S: * LIST (\Sent \HasNoChildren) "/" SentMail 288 S: * LIST (\Marked \Drafts \HasNoChildren) "/" MyDrafts 289 S: * LIST (\Trash \HasNoChildren) "/" Trash 290 S: t1 OK done 292 5.2. Example of an extended IMAP LIST command 294 This example shows an IMAP LIST response from a server that supports 295 this extension. The client uses the extended IMAP LIST command. 297 C: t1 CAPABILITY 298 S: * CAPABILITY IMAP4rev1 SPECIAL-USE 299 S: t1 OK done 301 C: t2 LIST "" "%" RETURN (SPECIAL-USE) 302 S: * LIST (\Marked) "/" Inbox 303 S: * LIST () "/" ToDo 304 S: * LIST () "/" Projects 305 S: * LIST (\Sent) "/" SentMail 306 S: * LIST (\Marked \Drafts) "/" MyDrafts 307 S: * LIST (\Trash) "/" Trash 308 S: t2 OK done 310 Here, the client also includes the "SPECIAL-USE" selection option for 311 the same list. The "SPECIAL-USE" return option could also have been 312 specified, but it is unnecessary, as it is implied by the selection 313 option. Note that in this case, mailboxes that do not have a 314 special-use attribute are not listed. Also note that we've used the 315 wildcard "*", rather than "%", to make sure we see all special-use 316 mailboxes, even ones that might not be at the namespace's root. 318 C: t3 LIST (SPECIAL-USE) "" "*" 319 S: * LIST (\Sent) "/" SentMail 320 S: * LIST (\Marked \Drafts) "/" MyDrafts 321 S: * LIST (\Trash) "/" Trash 322 S: t3 OK done 324 5.3. Example of an IMAP CREATE command 326 This example shows an IMAP CREATE command that might be used to 327 create a mailbox designated to hold draft and sent messages. It also 328 attempts to create a mailbox that will contain all the user's 329 messages, but the server does not support that special use for this 330 user's message store. 332 C: t1 CAPABILITY 333 S: * CAPABILITY IMAP4rev1 CREATE-SPECIAL-USE 334 S: t1 OK done 336 C: t2 CREATE MySpecial (USE (\Drafts \Sent)) 337 S: t2 OK MySpecial created 339 C: t3 CREATE Everything (USE (\All)) 340 S: t3 NO [USEATTR] \All not supported 342 5.4. Example of using IMAP METADATA to manipulate special-use 343 attributes 345 This example shows how IMAP METADATA can be used to manipulate 346 special-use attributes, if the operation is supported on the server. 348 ==> Starting point: 349 C: t1 LIST "" "%" RETURN (SPECIAL-USE) 350 S: * LIST (\Sent) "/" SentMail 351 S: * LIST (\Drafts) "/" MyDrafts 352 S: * LIST () "/" SavedDrafts 353 S: * LIST (\Trash) "/" Trash 354 S: t1 OK done 356 ==> Demonstrate the connection: 357 C: t2 GETMETADATA "MyDrafts" /shared/specialuse 358 S: * METADATA "MyDrafts" (/shared/specialuse "\Drafts") 359 S: t2 OK done 361 ==> Set new use for SavedDrafts; MyDrafts changes automatically: 362 C: t3 SETMETADATA "SavedDrafts" (/shared/specialuse "\Drafts") 363 S: * METADATA "MyDrafts" (/shared/specialuse NIL) 364 S: t3 OK SETMETADATA complete 366 ==> Remove special use for SentMail: 367 C: t4 SETMETADATA "SentMail" (/shared/specialuse NIL) 368 S: t4 OK SETMETADATA complete 370 ==> Check the results: 371 C: t5 LIST "" "%" RETURN (SPECIAL-USE) 372 S: * LIST () "/" SentMail 373 S: * LIST () "/" MyDrafts 374 S: * LIST (\Drafts) "/" SavedDrafts 375 S: * LIST (\Trash) "/" Trash 376 S: t5 OK done 378 6. Formal Syntax 380 The following syntax specification uses the augmented Backus-Naur 381 Form (BNF) as described in [RFC5234]. 383 create-param =/ "USE" SP "(" [use-attr *(SP use-attr)] ")" 384 ; Extends "create-param" from RFC 4466 [RFC4466] 386 mbx-list-oflag =/ use-attr 387 ; Extends "mbx-list-oflag" from IMAP base [RFC3501] 389 list-select-independent-opt =/ "SPECIAL-USE" 390 ; Extends "list-select-independent-opt" from 391 ; LIST-extended [RFC5258] 393 return-option =/ "SPECIAL-USE" 394 ; Extends "return-option" from 395 ; LIST-extended [RFC5258] 397 resp-text-code =/ "USEATTR" 398 ; Extends "resp-text-code" from 399 ; IMAP [RFC3501] 401 use-attr = "\All" / "\Archive" / "\Drafts" / "\Flagged" / 402 "\Junk" / "\Sent" / "\Trash" / use-attr-ext 404 use-attr-ext = "\" atom 405 ; Reserved for future extensions. Clients 406 ; MUST ignore list attributes they do not understand 407 ; Server implementations MUST NOT generate 408 ; extension attributes except as defined by 409 ; future standards-track revisions of or 410 ; extensions to this specification. 412 7. Security Considerations 414 LIST response: There are no security issues with conveying special- 415 use information to a client. 417 CREATE command "USE" parameter: In some server implementations, some 418 special uses may imply automatic action by the server. For example, 419 creation of a "\Junk" mailbox might cause the server to start placing 420 messages that have been evaluated as spam into the mailbox. 421 Implementors SHOULD consider the consequences of allowing a user (or 422 client program) to designate the target of such automatic action. 424 8. IANA Considerations 426 8.1. Registration of USEATTR IMAP response code 428 This document defines a new IMAP response code. IANA is asked to add 429 "USEATTR" to the IMAP Response Codes registry. 431 8.2. Registration of CREATE-SPECIAL-USE IMAP capability 433 This document defines a new IMAP capability. IANA is asked to add 434 "CREATE-SPECIAL-USE" to the IMAP 4 Capabilities registry. 436 8.3. Registration of SPECIAL-USE IMAP capability 438 This document defines a new IMAP capability. IANA is asked to add 439 "SPECIAL-USE" to the IMAP 4 Capabilities registry. 441 8.4. Registration of SPECIAL-USE selection option 443 This document defines a new IMAP4 List Extended selection option. 444 IANA is asked to add "SPECIAL-USE" to the IMAP4 List Extended 445 registry, as follows: 447 To: iana@iana.org 448 Subject: Registration of LIST-EXTENDED selection option SPECIAL-USE 449 LIST-EXTENDED option name: SPECIAL-USE 450 LIST-EXTENDED option type: SELECTION 451 Implied return option(s): SPECIAL-USE 452 LIST-EXTENDED option description: Limit the list to special-use 453 mailboxes only 454 Published specification: [[this RFC]] 455 Security considerations: none 456 Intended usage: COMMON 457 Person and email address to contact for further information: Authors' 458 Addresses at the end of [[this RFC]] 459 Owner/Change controller: iesg@ietf.org 461 8.5. Registration of SPECIAL-USE return option 463 This document defines a new IMAP4 List Extended return option. IANA 464 is asked to add "SPECIAL-USE" to the IMAP4 List Extended registry, as 465 follows: 467 To: iana@iana.org 468 Subject: Registration of LIST-EXTENDED return option SPECIAL-USE 469 LIST-EXTENDED option name: SPECIAL-USE 470 LIST-EXTENDED option type: RETURN 471 LIST-EXTENDED option description: Request special-use mailbox 472 information 473 Published specification: [[this RFC]] 474 Security considerations: none 475 Intended usage: COMMON 476 Person and email address to contact for further information: Authors' 477 Addresses at the end of [[this RFC]] 478 Owner/Change controller: iesg@ietf.org 480 8.6. Registration of SPECIAL-USE metadata 482 This document defines a new IMAP METADATA entry. IANA is asked to 483 add the following to the IMAP METADATA Mailbox Entry registry: 485 To: iana@iana.org 486 Subject: IMAP METADATA Entry Registration 487 Type: Mailbox 488 Name: /shared/specialuse 489 Description: Defines any special-use features of a mailbox. See the 490 reference specification for details of its use. 491 Content-type: text/plain; charset=us-ascii 492 RFC Number: [[this RFC]] 493 Contact: MORG mailing list mailto:morg@ietf.org 495 9. References 497 9.1. Normative References 499 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 500 Requirement Levels", BCP 14, RFC 2119, March 1997. 502 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 503 4rev1", RFC 3501, March 2003. 505 [RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 506 ABNF", RFC 4466, April 2006. 508 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 509 Specifications: ABNF", STD 68, RFC 5234, January 2008. 511 [RFC5258] Leiba, B. and A. Melnikov, "Internet Message Access 512 Protocol version 4 - LIST Command Extensions", RFC 5258, 513 June 2008. 515 [RFC5464] Daboo, C., "The IMAP METADATA Extension", RFC 5464, 516 February 2009. 518 9.2. Informative References 520 [RFC3348] Gahrns, M. and R. Cheng, "The Internet Message Action 521 Protocol (IMAP4) Child Mailbox Extension", RFC 3348, 522 July 2002. 524 Authors' Addresses 526 Barry Leiba 527 Huawei Technologies 529 Phone: +1 646 827 0648 530 Email: barryleiba@computer.org 531 URI: http://internetmessagingtechnology.org/ 533 Jamie Nicolson 534 Google 536 Email: nicolson@google.com