idnits 2.17.1 draft-ietf-imapext-list-extensions-08.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 937. -- Found old boilerplate from RFC 3978, Section 5.5 on line 975. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 948. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 955. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 961. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 1012 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 104 instances of too long lines in the document, the longest one being 12 characters in excess of 72. ** The abstract seems to contain references ([MboxRefer]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (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.) -- The document date (August 2004) is 7193 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 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3501 (ref. 'IMAP4') (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 3348 (ref. 'ChildMbox') (Obsoleted by RFC 5258) Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IMAP Extensions Working Group B. Leiba 2 Internet Draft IBM T.J. Watson Research Center 3 A. Melnikov 4 Isode Limited 5 Expires February 2004 August 2004 7 IMAP4 LIST Command Extensions 8 draft-ietf-imapext-list-extensions-08.txt 10 Status of this Document 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, or 14 will be disclosed, and any of which I become aware will be disclosed, 15 in accordance with RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 A revised version of this draft document will be submitted to the RFC 33 editor as an Proposed Standard for the Internet Community. 34 Discussion and suggestions for improvement are requested, and should 35 be sent to ietf-imapext@imc.org. This document will expire before 31 36 November 2004. Distribution of this memo is unlimited. 38 This documents obsoletes RFC 3348 and updates RFC 2193. 40 Abstract 42 IMAP4 has two commands for listing mailboxes: LIST and LSUB. As we 43 have added extensions that have required specialized lists (see 44 [MboxRefer] for an example) we have had to expand the number of list 45 commands, since each extension must add its function to both LIST and 46 LSUB, and these commands are not, as they are defined, extensible. 47 If we've needed the extensions to work together, we've had to add a 48 set of commands to mix the different options, the set increasing in 49 size with each new extension. This document describes an extension 50 to the base LIST command that will allow these additions to be done 51 with mutually compatible options to the LIST command, avoiding the 52 exponential increase in specialized list commands. 54 1. Conventions used in this document 56 In examples, "C:" indicates lines sent by a client that is connected 57 to a server. "S:" indicates lines sent by the server to the client. 59 The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are 60 used in this document as specified in RFC 2119 [Keywords]. 62 The term "canonical LIST pattern" refers to 63 the canonical pattern constructed internally by the server from 64 the reference and mailbox name arguments (Section 6.3.8 of [IMAP4]). 65 The [IMAP4] LIST command returns only mailboxes that match the 66 canonical LIST pattern. 68 <> 70 2. Introduction and overview 72 The extensions to the LIST command will be accomplished by amending 73 the syntax to allow options to be specified. The list of options 74 will replace the several commands that are currently used to mix and 75 match the information requested. The new syntax is backward- 76 compatible, with no ambiguity: <>. 80 By adding options to the LIST command, we are announcing the intent 81 to phase out and eventually to deprecate the RLIST and RLSUB commands 82 described in [MboxRefer]. We are also defining the mechanism to 83 request extended mailbox information, such as is described in the 84 "Child Mailbox Extension" [ChildMbox]. The base 85 LSUB command is not deprecated by this extension; rather, this 86 extension adds a way to obtain subscription information with more 87 options, with those server implementations that support it. Clients 88 that simply need a list of subscribed mailboxes, as provided by the 89 LSUB command, SHOULD continue to use that command. 91 This document defines an IMAP4 extension that is identified by the 92 capability string "X-DRAFT-W08-LISTEXT" <>. The LISTEXT extension makes the 94 following changes to the IMAP4 protocol, which are described in 95 more details in sections 3 and 4 of this document: 97 a. defines new syntax for LIST command options. 98 b. extend LIST to allow for multiple mailbox patterns. 99 c. adds LIST command match options: SUBSCRIBED and REMOTE 100 d. adds LIST command return options: SUBSCRIBED, REMOTE, CHILDREN 101 and SUBMAILBOXES. 102 e. adds new mailbox flags "\NonExistent", "\PlaceHolder", 103 "\Subscribed", "\Remote", "\HasSubmailboxes", 104 "\HasChildren" and "\HasNoChildren". 106 2.1. General principals for returning LIST responses 108 This section outlines several principals that can be used by 109 implementors of this document to decide if a LIST response should be 110 returned, as well as how many responses and what kind of information 111 they may contain. 113 1) Exactly one LIST response should be returned for each mailbox 114 name which matches the canonical LIST pattern. 115 Server implementors must not assume that clients will be able to 116 assemble mailbox flags and other information returned in multiple 117 LIST responses. 119 <> 131 3) Flags returned in the same LIST response must be treated additively. 132 For example the following response 134 S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach" 136 means that the "Fruit/Peach" mailbox doesn't exist, but it is 137 subscribed. 139 3. LIST Command Options 141 This extension updates the syntax of the LIST command to allow for multiple 142 mailbox patterns to be specified, if they are enclosed in parantheses. 143 A mailbox match a list of mailbox patterns, if it matches at least one 144 mailbox pattern. 146 The LIST command syntax is also extended in two additional ways: by adding a 147 parenthesized list of command options between the command name and the reference 148 name (LIST match options) and an optional list of options at the end that 149 control what kind of information should be returned (LIST return options). 150 See the formal syntax in section 6 for specific details. A LIST match option 151 tells the server which mailboxes should be selected by the LIST operation. 152 The server should return information about all mailboxes that match any of the 153 "canonical LIST pattern" (as described above) and satisfy additional selection 154 criteria (if any) specified by the LIST match options. Let's call any such 155 mailbox a "matched mailbox". Note, that if multiple match options are specified, 156 the server MUST return information about intersection of mailboxes that satisfy 157 any single match option. 159 A LIST return option controls which information is returned for each matched 160 mailbox. Note, that some return options may cause the server to report 161 information about additional mailboxes (e.g. SUBMAILBOXES). If the client 162 has omitted return options, only flag information should be returned by the 163 server. 165 Both match and return command options will be defined in this document and 166 in approved extension documents; each option will be enabled by a capability 167 string (one capability may enable multiple options), and a client MUST NOT 168 send an option for which the server has not advertised support. A server 169 MUST respond to options it does not recognize with a NO response. 171 This extension is identified by the capability string "X-DRAFT-W08-LISTEXT" 172 <>, <>. Such extensions MUST 175 refer to this document and MUST add their function through command 176 options as described herein. 178 This extension also defines extensions to the LIST response, allowing 179 a series of extended fields at the end, a parenthesized list of tagged 180 data (also referred to as "extended data item"). The first element of 181 an extended field is a tag, which identifies type of the data. Tags 182 MUST be registered with IANA, as described in section 8.5 of this 183 document. An example of such extended set might be 185 ((tablecloth (("fringe" "lacy")("color" "white")))(X-Sample 186 "text")) 188 or... 190 ((tablecloth ("fringe" "lacy"))(X-Sample "text" "and even more text")) 192 See the formal grammar, below, for the full syntatic details. 193 The server MAY return data in the extended fields that was not solicited 194 by the client. The client MUST ignore all extended fields it doesn't 195 recognize. 197 The LISTEXT capability defines several new mailbox flags. 199 The "\PlaceHolder" flag indicates that the designated mailbox does not 200 meet the selection criteria of the given LIST command, but that it 201 has one or more child mailbox that might (unspecified whether any, 202 all, or none match the canonical LIST pattern). 203 The LSUB command indicates this condition by using the "\NoSelect" 204 flag, but the LIST (SUBSCRIBED) command MUST NOT do that, since 205 "\NoSelect" retains its original meaning here. Further, the 206 "\PlaceHolder" flag is more general, in that it can be used with any 207 extended set of selection criteria. 209 The "\HasSubmailboxes" flag indicates that the designated mailbox meets 210 the selection criteria of the given LIST command and also has one or more child 211 mailbox that might (unspecified whether any, all, or none match the canonical 212 LIST pattern). 214 Absence of both \PlaceHolder and \HasSubmailboxes means that the mailbox 215 meets the selection criterion, but doesn't have any children that also 216 meet the selection criterion and don't match the canonical LIST pattern. 217 However, absence of both \PlaceHolder and \HasSubmailboxes doesn't tell 218 whether there are any children that meet the selection criterion and match 219 the canonical LIST pattern. 221 <> 223 The SUBMAILBOXES return option described below REQUIRES that the "\Placeholder" 224 and the "\HasSubmailboxes" flags be accurately computed. 226 The "\Placeholder"/""\HasSubmailboxes" flag implies "\HasChildren". 228 The "\NonExistent" flag indicates that a mailbox does not actually exist. 229 Note that this flag is not meaningful by itself, as mailboxes that match 230 the canonical LIST pattern but don't exist must not be returned unless one 231 of the two conditions listed below is also satisfied: 233 a) the mailbox also satisfy the selection criteria 235 b) the mailbox has at least one child mailbox that satisfies the selection 236 criteria, but doesn't match the canonical LIST pattern. 238 In practice this means that the "\NonExistent" flag is usually returned 239 with one or more of \PlaceHolder/\HasSubmailboxes, \Subscribed, \Remote 240 (see there description below). 242 The "\NonExistent" flag implies "\NoSelect". 243 The "\NonExistent" flag MUST be supported and MUST be accurately computed. 245 The following table summarizes when \NonExistent, \PlaceHolder or 246 \HasSubmailboxes flags are to be returned: 248 +------+------------+---------------------+--------------------------------+ 249 |exists| meets the | has a child that | returned | 251 | | selection | meets the selection | LISTEXT flags | 252 | | criteria | criteria | | 253 +------+------------+---------------------+--------------------------------+ 254 | no | no | no | no LIST response returned | 255 | yes | no | no | no LIST response returned | 256 | no | yes | no | (\NonExistent) | 257 | yes | yes | no | () | 258 | no | no | yes | (\NonExistent \PlaceHolder) | 259 | yes | no | yes | (\PlaceHolder) | 260 | no | yes | yes | (\NonExistent \HasSubmailboxes)| 261 | yes | yes | yes | (\HasSubmailboxes) | 262 +------+------------+---------------------+--------------------------------+ 264 The match options defined in this specification are 266 SUBSCRIBED - causes the LIST command to list subscribed 267 mailboxes, rather than the actual mailboxes. This will often 268 be a subset of the actual mailboxes. It's also possible for 269 this list to contain the names of mailboxes that don't exist. 270 In any case, the list MUST include exactly those mailbox names 271 that match the canonical list pattern and are subscribed to. This 272 option is intended to supplement the LSUB command. 273 Of particular note are the mailbox flags as returned by this 274 option, compared with what is returned by LSUB. With the 275 latter, the flags returned may not reflect the actual flag 276 status on the mailbox, and the \NoSelect flag has a special 277 meaning (it indicates that this mailbox is not, itself, 278 subscribed, but that it has child mailboxes that are). With 279 the SUBSCRIBED match option described here, the flags are accurate 280 and complete, and have no special meanings. 281 "LSUB" and "LIST (SUBSCRIBED)" are, thus, not the same thing, 282 and some servers must do significant extra work to respond to 283 "LIST (SUBSCRIBED)". Because of this, clients SHOULD continue 284 to use "LSUB" unless they specifically want the additional 285 information offered by "LIST (SUBSCRIBED)". 287 This option defines a new mailbox flag, "\Subscribed" that 288 indicates that a mailbox is subscribed to. The "\Subscribed" 289 flag MUST be supported and MUST be accurately computed 290 when the SUBSCRIBED match option is specified. 292 <> 295 REMOTE - causes the LIST command to show remote mailboxes as 296 well as local ones, as described in [MboxRefer]. This option 297 is intended to replace the RLIST command and, in conjunction 298 with the SUBSCRIBED match option, the RLSUB command. 300 This option defines a new mailbox flag, "\Remote", that 301 indicates that a mailbox is a remote mailbox. The "\Remote" 302 flag MUST be accurately computed when the REMOTE option is 303 specified. 305 <> 308 The return options defined in this specification are 310 SUBSCRIBED - causes the LIST command to return subscription 311 state for all matching <>. The "\Subscribed" 312 flag MUST be supported and MUST be accurately computed 313 when the SUBSCRIBED return option is specified. 315 REMOTE - causes the LIST command to show if the matching <> 316 is local or remote. The "\Remote" flag MUST be accurately computed 317 when the REMOTE return option is specified. 319 Note, that a server implementation that doesn't support 320 any remote mailboxes is compliant with this specification 321 as long as it accepts and ignores the REMOTE return option. 323 CHILDREN - Requests mailbox child information as originally 324 proposed in [ChildMbox]. See section 4, below, for details. 325 This option MUST be accepted by all servers, however it MAY 326 be ignored. 328 SUBMAILBOXES - when this option is specified, the "\Placeholder" 329 and the "\HasSubmailboxes" flags MUST be accurate. This might 330 force the server to return information for additional mailboxes. 332 Note, that even it SUBMAILBOXES option is specified, the client 333 still must be able to handle a case when a "\PlaceHolder"/ 334 "\HasSubmailboxes" is returned and there are no submailboxes 335 that meet the selection criteria of the given LIST command, 336 as they can be deleted/renamed after the LIST response was sent, 337 but before the client had a chance to access them. 339 4. The CHILDREN return Option 341 The CHILDREN return option implements the Child Mailbox Extension, 342 originally proposed by Mike Gahrns and Raymond Cheng, of Microsoft 343 Corporation. Most of the information in this section is taken 344 directly from their original specification [ChildMbox]. The CHILDREN 345 return option is simply an indication that the client wants this 346 information; a server MAY provide it even if the option is not 347 specified, or MAY ignore the option entirely. 348 Many IMAP4 [IMAP4] clients present to the user a hierarchical view of 349 the mailboxes that a user has access to. Rather than initially 350 presenting to the user the entire mailbox hierarchy, it is often 351 preferable to show to the user a collapsed outline list of the 352 mailbox hierarchy (particularly if there is a large number of 353 mailboxes). The user can then expand the collapsed outline hierarchy 354 as needed. It is common to include within the collapsed hierarchy a 355 visual clue (such as a ''+'') to indicate that there are child 356 mailboxes under a particular mailbox. When the visual clue is 357 clicked the hierarchy list is expanded to show the child mailboxes. 358 The Child Mailbox Extension provides a mechanism for a client to 359 efficiently determine if a particular mailbox has children, without 360 issuing a LIST "" * or a LIST "" % for each mailbox name. 361 The Child Mailbox Extension defines two new attributes that MAY be 362 returned within a LIST response: \HasChildren and \HasNoChildren. 363 While these attributes MAY be returned in response to any LIST 364 command, the CHILDREN return option is provided to indicate that the client 365 particularly wants this information. If the CHILDREN return option 366 is present, the server SHOULD return these attributes even if their 367 computation is expensive. 369 \HasChildren - The presence of this attribute indicates that the 370 mailbox has child mailboxes. 371 A server SHOULD NOT set this attribute if there are child 372 mailboxes, and the user does not have permissions to access any 373 of them. In this case, \HasNoChildren SHOULD be used. 374 In many cases, however, a server may not be able to efficiently 375 compute whether a user has access to all child mailboxes. As 376 such a client MUST be prepared to accept the \HasChildren 377 attribute as a hint. That is, a mailbox MAY be flagged with the 378 \HasChildren attribute, but no child mailboxes will appear in 379 the LIST response. 381 \HasNoChildren - The presence of this attribute indicates that the 382 mailbox has NO child mailboxes that are accessible to the 383 currently authenticated user. 385 In some instances a server that supports the Child Mailbox Extension 386 might not be able to determine whether a mailbox has children. For 387 example it may have difficulty determining whether there are child 388 mailboxes when LISTing mailboxes while operating in a particular 389 namespace. 390 In these cases, a server MAY exclude both the \HasChildren and 391 \HasNoChildren attributes in the LIST response. As such, a client 392 can not make any assumptions about whether a mailbox has children 393 based upon the absence of a single attribute. In particular, some 394 servers may not be able to combine the SUBSCRIBED match option 395 and CHILDREN return option. Such servers MUST honour the SUBSCRIBED 396 match option, and they will simply ignore the CHILDREN return option 397 if both are requested. It is an error for the server to return both a 398 \HasChildren and a \HasNoChildren attribute in a LIST response. 400 Note: the \HasNoChildren attribute should not be confused with the 401 IMAP4 [IMAP4] defined attribute \NoInferiors which indicates that no 402 child mailboxes exist now and none can be created in the future. 404 5. Examples 406 The first example shows the complete local hierarchy that will be 407 used for the other examples. 409 C: A01 LIST "" "*" 410 S: * LIST (\Marked \NoInferiors) "/" "inbox" 411 S: * LIST () "/" "Fruit" 412 S: * LIST () "/" "Fruit/Apple" 413 S: * LIST () "/" "Fruit/Banana" 414 S: * LIST () "/" "Tofu" 415 S: * LIST () "/" "Vegetable" 416 S: * LIST () "/" "Vegetable/Broccoli" 417 S: * LIST () "/" "Vegetable/Corn" 418 S: A01 OK done 420 In the next example, we'll see the subscribed mailboxes. This is 421 similar, but not equivalent, to . Note that the mailbox 422 called "Fruit/Peach" is subscribed to, but does not actually exist 423 (perhaps it was deleted while still subscribed). The "Fruit" 424 mailbox is not subscribed to, but it has two subscribed children. 425 The "Vegetable" mailbox is subscribed and has two children, one 426 of them is subscribed as well. 428 C: A02 LIST (SUBSCRIBED) "" "*" 429 S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox" 430 S: * LIST (\PlaceHolder) "/" "Fruit" 431 S: * LIST (\Subscribed) "/" "Fruit/Banana" 432 S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach" 433 S: * LIST (\Subscribed \HasSubmailboxes) "/" "Vegetable" 434 S: * LIST (\Subscribed) "/" "Vegetable/Broccoli" 435 S: A02 OK done 437 The next example shows the use of the CHILDREN option. The client, 438 without having to list the second level of hierarchy, now knows which 439 of the top-level mailboxes have sub-mailboxes (children) and which do 440 not. Note that it's not necessary for the server to return the 441 \HasNoChildren flag for the inbox, because the \NoInferiors flag 442 already implies that, and has a stronger meaning. 444 C: A03 LIST () "" "%" RETURN (CHILDREN) 445 S: * LIST (\Marked \NoInferiors) "/" "inbox" 446 S: * LIST (\HasChildren) "/" "Fruit" 447 S: * LIST (\HasNoChildren) "/" "Tofu" 448 S: * LIST (\HasChildren) "/" "Vegetable" 449 S: A03 OK done 451 In this example we see more mailboxes, which reside on another server 452 to which we may obtain referrals. This is similar to the command 453 . Note that in the case of the remote mailboxes, the 454 server might or might not be able to include CHILDREN information; 455 it includes it if it can, and omits it if it can't. 457 C: A04 LIST (REMOTE) "" "%" RETURN (CHILDREN) 458 S: * LIST (\Marked \NoInferiors) "/" "inbox" 459 S: * LIST (\HasChildren) "/" "Fruit" 460 S: * LIST (\HasNoChildren) "/" "Tofu" 461 S: * LIST (\HasChildren) "/" "Vegetable" 462 S: * LIST (\Remote) "/" "Bread" 463 S: * LIST (\HasChildren \Remote) "/" "Meat" 464 S: A04 OK done 466 The following example also requests the server to include mailboxes, 467 which reside on another server. The server returns information about 468 all mailboxes which are subscribed. This is similar to the command 469 . We also see the mixing of two match options. 471 C: A05 LIST (REMOTE SUBSCRIBED) "" "*" 472 S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox" 473 S: * LIST (\Subscribed) "/" "Fruit/Banana" 474 S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach" 475 S: * LIST (\Subscribed) "/" "Vegetable" 476 S: * LIST (\Subscribed) "/" "Vegetable/Broccoli" 477 S: * LIST (\Remote \Subscribed) "/" "Bread" 478 S: A05 OK done 480 The following example requests the server to include mailboxes, 481 which reside on another server. The server is requested to return 482 subscription information for all returned mailboxes. This is different 483 from the example above. <> 487 C: A06 LIST (REMOTE) "" "*" RETURN (SUBSCRIBED) 488 S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox" 489 S: * LIST () "/" "Fruit" 490 S: * LIST () "/" "Fruit/Apple" 491 S: * LIST (\Subscribed) "/" "Fruit/Banana" 492 <> 493 S: * LIST () "/" "Tofu" 494 S: * LIST (\Subscribed) "/" "Vegetable" 495 S: * LIST (\Subscribed) "/" "Vegetable/Broccoli" 496 S: * LIST () "/" "Vegetable/Corn" 497 S: * LIST (\Remote \Subscribed) "/" "Bread" 498 S: * LIST (\Remote) "/" "Meat" 499 S: A06 OK done 501 In the following example the client has specified multiple mailbox 502 patterns. 504 C: BBB LIST "" ("INBOX" "Drafts" "Sent/%") 505 S: * LIST () "/" "INBOX" 506 S: * LIST (\NoInferiors) "/" "Drafts" 507 S: * LIST () "/" "Sent/March2004" 508 S: * LIST (\Marked) "/" "Sent/December2003" 509 S: * LIST () "/" "Sent/August2004" 510 S: BBB OK done 512 6. Formal Syntax 514 The following syntax specification uses the augmented Backus-Naur 515 Form (BNF) as described in [ABNF]. Terms not defined here are taken 516 from [IMAP4]. "vendor-token" is defined in [ACAP]. 518 child-mbox-flag = "\HasChildren" / "\HasNoChildren" 519 ; flags for Child Mailbox Extension, at most one 520 ; possible per LIST response 522 list = "LIST" [SP list-match-opts] SP mailbox SP mbox_or_pat 523 [SP list-return-opts] 525 list-match-opts = "(" [match-option *(SP match-option)] ")" 526 ; list match options, e.g. REMOTE 528 list-return-opts = "RETURN" SP "(" [return-option *(SP return-option)] ")" 529 ; list return options, e.g. CHILDREN 531 mailbox-list = "(" [mbx-list-flags] ")" SP 532 (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox 533 [SP mbox-list-extended] 535 mbox-list-extended = "(" [mbox-list-extended-item 536 *(SP mbox-list-extended-item)] ")" 538 mbox-list-extended-item = "(" mbox-list-extended-item-data ")" 540 mbox-list-extended-item-data = mbox-list-extended-item-tag SP nstring-list 542 mbox-list-extended-item-tag = astring 543 ; The content MUST conform to either "eitem-vendor-tag" or 544 ; "eitem-standard-tag" ABNF productions. 545 ; A tag registration template is described in section 546 ; 8.5 of this document. 548 mbox_or_pat = list-mailbox / patterns 550 patterns = "(" list-mailbox *(list-mailbox) ")" 552 eitem-vendor-tag = vendor-tag 553 ; a vendor specific tag for extended list data 555 eitem-standard-tag = atom 556 ; a tag for extended list data defined in a Standard 557 ; Track or Experimental RFC. 559 nstring-list = nstring / 560 "(" [nstring-list *(SP nstring-list)] ")" 561 ;; a recursive list definition 563 mbox-list-oflag = child-mbox-flag / "\NonExistent" / "\PlaceHolder" / 564 "\HasSubmailboxes" / "\Subscribed" / "\Remote" 566 match-option = "SUBSCRIBED" / "REMOTE" / option-extension 567 ; An option registration template is described in section 568 ; 8.3 of this document. 570 return-option = "SUBSCRIBED" / "REMOTE" / "CHILDREN" / "SUBMAILBOXES" / 571 option-extension 573 option-extension = option-vendor-tag / option-standard-tag 575 option-vendor-tag = vendor-tag 576 ; a vendor specific option 578 option-standard-tag= atom 579 ; an option defined in a Standard Track or 580 ; Experimental RFC 582 vendor-tag = vendor-token "-" atom 584 7. Security Considerations 586 This document describes syntactic changes to the specification of the 587 IMAP4 commands LIST, LSUB, RLIST, and RLSUB, and the modified LIST 588 command has the same security considerations as those commands. They 589 are described in [IMAP4] and [MboxRefer]. 591 The Child Mailbox Extension provides a client a more efficient means 592 of determining whether a particular mailbox has children. If a 593 mailbox has children, but the currently authenticated user does not 594 have access to any of them, the server SHOULD respond with a 595 \HasNoChildren attribute. In many cases, however, a server may not 596 be able to efficiently compute whether a user has access to all child 597 mailboxes. If such a server responds with a \HasChildren attribute, 598 when in fact the currently authenticated user does not have access to 599 any child mailboxes, potentially more information is conveyed about 600 the mailbox than intended. In most situations this will not be a 601 security concern, because if information regarding whether a mailbox 602 has children is considered sensitive, a user would not be granted 603 access to that mailbox in the first place. 605 8. IANA Considerations 607 8.1. Guidelines for IANA 609 It is requested that IANA creates two new registries for LISTEXT 610 options and LISTEXT extended response data. The templates and 611 the initial registrations are detailed below. 613 8.2. Registration procedure and Change control 615 Registration of a LISTEXT option is done by filling in the template 616 in section 8.3 and sending it via electronic mail to . 617 Registration of a LISTEXT extended data item is done by filling in the 618 template in section 8.5 and sending it via electronic mail to . 619 IANA has the right to reject obviously bogus registrations, but will 620 perform no review of claims made in the registration form. 622 A LISTEXT option/extended data item name that starts with "V-" is reserved 623 for vendor specific options/extended data items. All options, whether 624 they are vendor specific or global, should be registered with IANA. 625 If a LISTEXT extended data item is returned as a result of requesting 626 a particular LISTEXT option, the name of the option SHOULD be used 627 as the name of the LISTEXT extended data item. 629 Each vendor specific options/extended data item MUST start with their 630 vendor-token ("vendor prefix"). The vendor-token MUST be registered 631 with IANA, using the [ACAP] vendor subtree registry. 633 Standard LISTEXT option/extended data item names are case insensitive. 634 If the vendor prefix is omitted from a vendor specific LISTEXT 635 option/extended data item name, the rest is case insensitive. The vendor 636 prefix itself is not case-sensitive, as it might contain non-ASCII 637 characters. 639 While the registration procedures do not require it, authors of LISTEXT 640 options/extended data items are encouraged to seek community review and 641 comment whenever that is feasible. Authors may seek community review by 642 posting a specification of their proposed mechanism as an Internet- 643 Draft. LISTEXT options/extended data items intended for widespread use 644 should be standardized through the normal IETF process, when appropriate. 646 Comments on registered LISTEXT options/extended response data should 647 first be sent to the "owner" of the mechanism and/or to the IMAPEXT WG 648 mailing list. 649 Submitters of comments may, after a reasonable attempt to contact the 650 owner, request IANA to attach their comment to the registration itself. 651 If IANA approves of this, the comment will be 652 made accessible in conjunction with the registration LISTEXT options/ 653 extended response data itself. 655 Once a LISTEXT registration has been published by IANA, the 656 author may request a change to its definition. The change request 657 follows the same procedure as the registration request. 659 The owner of a LISTEXT registration may pass responsibility for the 660 registered option/extended data item to another person or agency by 661 informing IANA; this can be done without discussion or review. 663 The IESG may reassign responsibility for a LISTEXT option/extended data item. 664 The most common case of this will be to enable changes to be made to 665 mechanisms where the author of the registration has died, moved out 666 of contact or is otherwise unable to make changes that are important 667 to the community. 669 LISTEXT registrations may not be deleted; mechanisms which are 670 no longer believed appropriate for use can be declared OBSOLETE by a 671 change to their "intended use" field; such LISTEXT options/extended data 672 items will be clearly marked in the lists published by IANA. 674 The IESG is considered to be the owner of all LISTEXT options/extended data items 675 which are on the IETF standards track. 677 8.3. Registration template for LISTEXT options 679 To: iana@iana.org 680 Subject: Registration of LISTEXT option X 682 LISTEXT option name: 684 LISTEXT option type: (One of MATCH or RETURN) 686 <> 688 LISTEXT option description: 690 Published specification (optional, recommended): 692 Security considerations: 694 Intended usage: 695 (One of COMMON, LIMITED USE or OBSOLETE) 697 Person & email address to contact for further information: 699 Owner/Change controller: 701 (Any other information that the author deems interesting may be 702 added below this line.) 704 8.4. Initial LISTEXT option registrations 706 It is requested that the LISTEXT option registry is being populated 707 with the following entries: 709 1) 711 To: iana@iana.org 712 Subject: Registration of LISTEXT option SUBSCRIBED 714 LISTEXT option name: SUBSCRIBED 716 LISTEXT option type: MATCH 718 LISTEXT option description: Causes the LIST command to list 719 subscribed mailboxes, rather than the actual mailboxes. 721 Published specification : this RFC, section 3. 723 Security considerations: this RFC, section 7. 725 Intended usage: COMMON 727 Person & email address to contact for further information: 728 Alexey Melnikov 730 Owner/Change controller: IESG 732 2) 734 To: iana@iana.org 735 Subject: Registration of LISTEXT option REMOTE 737 LISTEXT option name: REMOTE 739 LISTEXT option type: MATCH 741 LISTEXT option description: causes the LIST command to return 742 remote mailboxes as well as local ones, as described in 743 RFC 2193. 745 Published specification : this RFC, section 3. 747 Security considerations: this RFC, section 7. 749 Intended usage: COMMON 751 Person & email address to contact for further information: 752 Alexey Melnikov 754 Owner/Change controller: IESG 756 3) 758 To: iana@iana.org 759 Subject: Registration of LISTEXT option SUBSCRIBED 761 LISTEXT option name: SUBSCRIBED 763 LISTEXT option type: RETURN 765 LISTEXT option description: Causes the LIST command to return 766 subscription state. 768 Published specification : this RFC, section 3. 770 Security considerations: this RFC, section 7. 772 Intended usage: COMMON 774 Person & email address to contact for further information: 775 Alexey Melnikov 777 Owner/Change controller: IESG 779 4) 781 To: iana@iana.org 782 Subject: Registration of LISTEXT option REMOTE 784 LISTEXT option name: REMOTE 786 LISTEXT option type: MATCH 788 LISTEXT option description: causes the LIST command to return 789 if the mailbox is local or remote, as described in 790 RFC 2193. 792 Published specification : this RFC, section 3. 794 Security considerations: this RFC, section 7. 796 Intended usage: COMMON 798 Person & email address to contact for further information: 799 Alexey Melnikov 801 Owner/Change controller: IESG 803 5) 805 To: iana@iana.org 806 Subject: Registration of LISTEXT option SUBMAILBOXES 808 LISTEXT option name: SUBMAILBOXES 810 LISTEXT option type: RETURN 812 LISTEXT option description: Requests that \Placeholder/ 813 \HasSubmailboxes flags are to be accurately computed. 815 Published specification : this RFC, sections 3. 817 Published specification : this RFC 819 Security considerations: this RFC, section 7. 821 Intended usage: COMMON 823 Person & email address to contact for further information: 824 Alexey Melnikov 826 Owner/Change controller: IESG 828 6) 830 To: iana@iana.org 831 Subject: Registration of LISTEXT option CHILDREN 833 LISTEXT option name: CHILDREN 835 LISTEXT option type: RETURN 837 LISTEXT option description: Requests mailbox child information. 839 Published specification : this RFC, sections 3 and 4. 841 Published specification : this RFC 843 Security considerations: this RFC, section 7. 845 Intended usage: COMMON 847 Person & email address to contact for further information: 848 Alexey Melnikov 850 Owner/Change controller: IESG 852 8.5. Registration template for LISTEXT extended data item 854 To: iana@iana.org 855 Subject: Registration of LISTEXT extended data item X 857 LISTEXT extended data item tag: 859 LISTEXT extended data item description: 861 Which LISTEXT option(s) (and their types) causes this extended 862 data item to be returned (if any): 864 Published specification (optional, recommended): 866 Security considerations: 868 Intended usage: 869 (One of COMMON, LIMITED USE or OBSOLETE) 871 Person & email address to contact for further information: 873 Owner/Change controller: 875 (Any other information that the author deems interesting may be 876 added below this line.) 878 9. References 880 9.1. Normative References 882 [Keywords] Bradner, S., "Key words for use in RFCs to Indicate 883 Requirement Levels", RFC 2119, Harvard University, March 1997. 885 [ABNF] Crocker, D., and Overell, P. "Augmented BNF for Syntax 886 Specifications: ABNF", RFC 2234, November 1997. 888 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 889 4rev1", RFC 3501, University of Washington, March 2003. 891 [MboxRefer] Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193, 892 Microsoft Corporation, September 1997. 894 [ChildMbox] Gahrns, M. & Cheng, R., "IMAP4 Child Mailbox Extension", 895 RFC 3348, Microsoft Corporation, July 2002. 897 [ACAP] Newman, C. and J. Myers, "ACAP -- Application 898 Configuration Access Protocol", RFC 2244, November 1997. 900 10. Acknowledgements 902 Mike Gahrns and Raymond Cheng of Microsoft Corporation originally 903 devised the Child Mailbox Extension and proposed it in 1997; the 904 idea, as well as most of the text in section 4, is theirs. 906 This document is the result of discussions on the IMAP4 mailing list 907 and is meant to reflect consensus of this group. In particular, 908 Mark Crispin, Philip Guenther, Cyrus Daboo, Timo Sirainen, 909 Ken Murchison, Rob Siemborski, Steve Hole, Arnt Gulbrandsen, Larry 910 Greenfield and Pete Maclean were active participants 911 in this discussion or made suggestions to this document. 913 11. Author's Address 915 Barry Leiba 916 IBM T.J. Watson Research Center 917 30 Saw Mill River Road 918 Hawthorne, NY 10532 919 Phone: 1-914-784-7941 920 Email: leiba@watson.ibm.com 922 Alexey Melnikov 923 Isode Limited 924 5 Castle Business Village 925 36 Station Road 926 Hampton, Middlesex 927 TW12 2BX, UK 929 Email: Alexey.Melnikov@isode.com 930 URI: http://www.melnikov.ca/ 932 12. IPR Disclosure Acknowledgement 934 By submitting this Internet-Draft, we certify that any applicable 935 patent or other IPR claims of which I am aware have been disclosed, 936 and any of which we become aware will be disclosed, in accordance with 937 RFC 3668. 939 13. Intellectual Property 941 The IETF takes no position regarding the validity or scope of any 942 Intellectual Property Rights or other rights that might be claimed to 943 pertain to the implementation or use of the technology described in 944 this document or the extent to which any license under such rights 945 might or might not be available; nor does it represent that it has 946 made any independent effort to identify any such rights. Information 947 on the procedures with respect to rights in RFC documents can be 948 found in BCP 78 and BCP 79. 950 Copies of IPR disclosures made to the IETF Secretariat and any 951 assurances of licenses to be made available, or the result of an 952 attempt made to obtain a general license or permission for the use of 953 such proprietary rights by implementers or users of this 954 specification can be obtained from the IETF on-line IPR repository at 955 http://www.ietf.org/ipr. 957 The IETF invites any interested party to bring to its attention any 958 copyrights, patents or patent applications, or other proprietary 959 rights that may cover technology that may be required to implement 960 this standard. Please address the information to the IETF at 961 ietf-ipr@ietf.org. 963 14. Full Copyright Statement 965 Copyright (C) The Internet Society (2004). This document is subject 966 to the rights, licenses and restrictions contained in BCP 78, and 967 except as set forth therein, the authors retain all their rights. 969 This document and the information contained herein are provided on an 970 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 971 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 972 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 973 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 974 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 975 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 977 Acknowledgement 979 Funding for the RFC Editor function is currently provided by 980 the Internet Society.