idnits 2.17.1 draft-ietf-imapext-list-extensions-18.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 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1408. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1419. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1426. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1432. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- 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 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). (Using the creation date from RFC2193, updated by this document, for RFC5378 checks: 1997-05-18) -- 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 (September 21, 2006) is 6427 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 4234 (ref. 'ABNF') (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 3501 (ref. 'IMAP4') (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 3348 (ref. 'CMbox') (Obsoleted by RFC 5258) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IMAP Extensions Working Group B. Leiba 3 Internet-Draft IBM T.J. Watson Research Center 4 Obsoletes: 3348 (if approved) A. Melnikov 5 Updates: 2193 (if approved) Isode Limited 6 Intended status: Standards Track September 21, 2006 7 Expires: March 25, 2007 9 IMAP4 LIST Command Extensions 10 draft-ietf-imapext-list-extensions-18 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on March 25, 2007. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 IMAP4 has two commands for listing mailboxes: LIST and LSUB. As we 44 have added extensions, such as Mailbox Referrals, that have required 45 specialized lists we have had to expand the number of list commands, 46 since each extension must add its function to both LIST and LSUB, and 47 these commands are not, as they are defined, extensible. If we've 48 needed the extensions to work together, we've had to add a set of 49 commands to mix the different options, the set increasing in size 50 with each new extension. This document describes an extension to the 51 base LIST command that will allow these additions to be done with 52 mutually compatible options to the LIST command, avoiding the 53 exponential increase in specialized list commands. 55 Note 57 A revised version of this draft document will be submitted to the RFC 58 editor as a Proposed Standard for the Internet Community. Discussion 59 and suggestions for improvement are requested, and should be sent to 60 ietf-imapext@imc.org. 62 This document obsoletes RFC 3348 and updates RFC 2193. 64 Table of Contents 66 1. Conventions used in this document . . . . . . . . . . . . . 5 68 2. Introduction and overview . . . . . . . . . . . . . . . . . 6 70 3. Extended LIST Command . . . . . . . . . . . . . . . . . . . 8 71 3.1. Initial list of selection options . . . . . . . . . . . . . 10 72 3.2. Initial list of return options . . . . . . . . . . . . . . . 12 73 3.3. General principles for returning LIST responses . . . . . . 12 74 3.4. Additional requirements on LIST-EXTENDED clients . . . . . . 13 75 3.5. CHILDINFO extended data item . . . . . . . . . . . . . . . . 13 77 4. The CHILDREN return Option . . . . . . . . . . . . . . . . . 16 79 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18 81 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 25 83 7. Internationalization Considerations . . . . . . . . . . . . 29 85 8. Security Considerations . . . . . . . . . . . . . . . . . . 30 87 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 31 88 9.1. Guidelines for IANA . . . . . . . . . . . . . . . . . . . . 31 89 9.2. Registration procedure and Change control . . . . . . . . . 31 90 9.3. Registration template for LIST-EXTENDED options . . . . . . 32 91 9.4. Initial LIST-EXTENDED option registrations . . . . . . . . . 33 92 9.5. Registration template for LIST-EXTENDED extended data 93 item . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 94 9.6. Initial LIST-EXTENDED extended data item registrations . . . 36 96 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 98 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 99 11.1. Normative References . . . . . . . . . . . . . . . . . . . . 38 100 11.2. informative References . . . . . . . . . . . . . . . . . . . 38 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 39 102 Intellectual Property and Copyright Statements . . . . . . . 40 104 1. Conventions used in this document 106 In examples, "C:" indicates lines sent by a client that is connected 107 to a server. "S:" indicates lines sent by the server to the client. 109 The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are 110 used in this document as specified in RFC 2119 [Kwds]. 112 The term "canonical LIST pattern" refers to the canonical pattern 113 constructed internally by the server from the reference and mailbox 114 name arguments (Section 6.3.8 of [IMAP4]). The [IMAP4] LIST command 115 returns only mailboxes that match the canonical LIST pattern. 117 Other terms are introduced where they are referenced for the first 118 time. 120 2. Introduction and overview 122 The LIST command is extended by amending the syntax to allow options 123 and multiple patterns to be specified. The list of options replaces 124 the several commands that are currently used to mix and match the 125 information requested. The new syntax is backward- compatible, with 126 no ambiguity: the new syntax is being used if one of the following 127 conditions is true: 129 1. if the first word after the command name begins with a 130 parenthesis ("LIST selection options"); 132 2. if the second word after the command name begins with a 133 parenthesis ("multiple mailbox patterns"); 135 3. if the LIST command has more than 2 parameters ("LIST return 136 options"); 138 Otherwise the original syntax is used. 140 By adding options to the LIST command, we are announcing the intent 141 to phase out and eventually to deprecate the RLIST and RLSUB commands 142 described in [MBRef]. We are also defining the mechanism to request 143 extended mailbox information, such as is described in the "Child 144 Mailbox Extension" [CMbox]. The base LSUB command is not deprecated 145 by this extension; rather, this extension adds a way to obtain 146 subscription information with more options, with those server 147 implementations that support it. Clients that simply need a list of 148 subscribed mailboxes, as provided by the LSUB command, SHOULD 149 continue to use that command. 151 This document defines an IMAP4 extension that is identified by the 152 capability string "LIST-EXTENDED". The LIST-EXTENDED extension makes 153 the following changes to the IMAP4 protocol, which are described in 154 more detail in Section 3 and Section 4: 156 a. defines new syntax for LIST command options. 158 b. extends LIST to allow for multiple mailbox patterns. 160 c. adds LIST command selection options: SUBSCRIBED, REMOTE and 161 RECURSIVEMATCH. 163 d. adds LIST command return options: SUBSCRIBED and CHILDREN. 165 e. adds new mailbox attributes: "\NonExistent", "\Subscribed", 166 "\Remote", "\HasChildren" and "\HasNoChildren". 168 f. adds CHILDINFO extended data item. 170 3. Extended LIST Command 172 This extension updates the syntax of the LIST command to allow for 173 multiple mailbox patterns to be specified, if they are enclosed in 174 parentheses. A mailbox name matches a list of mailbox patterns if it 175 matches at least one mailbox pattern. If a mailbox name matches 176 multiple mailbox patterns from the list, the server SHOULD return 177 only a single LIST response. 179 Note that the non-extended LIST command is required to treat an empty 180 ("" string) mailbox name argument as a special request to return the 181 hierarchy delimiter and the root name of the name given in the 182 reference parameter (as per [IMAP4]). However ANY extended LIST 183 command (extended in any of 3 ways specified in Section 2, or any 184 combination of thereof) MUST NOT treat the empty mailbox name as such 185 special request and any regular processing described in this document 186 applies. In particular, if an extended LIST command has multiple 187 mailbox names and one (or more) of them is the empty string, the 188 empty string MUST be ignored for the purpose of matching. 190 Some servers might restrict which patterns are allowed in a LIST 191 command. If a server doesn't accept a particular pattern, it MUST 192 silently ignore it. 194 The LIST command syntax is also extended in two additional ways: by 195 adding a parenthesized list of command options between the command 196 name and the reference name (LIST selection options) and an optional 197 list of options at the end that control what kind of information 198 should be returned (LIST return options). See the formal syntax in 199 Section 6 for specific details. 201 A LIST selection option tells the server which mailbox names should 202 be selected by the LIST operation. The server should return 203 information about all mailbox names that match any of the "canonical 204 LIST pattern" (as described above) and satisfy additional selection 205 criteria (if any) specified by the LIST selection options. Let's 206 call any such mailbox name a "matched mailbox name". When multiple 207 selection options are specified, the server MUST return information 208 about mailbox names that satisfy every selection option, unless a 209 description of a particular specified option prescribes special 210 rules. An example of an option prescribing special rules is the 211 RECURSIVEMATCH selection option described later in this section. We 212 will use the term "selection criteria" when referring collectively to 213 all selection options specified in a LIST command. 215 A LIST return option controls which information is returned for each 216 matched mailbox name. Note that return options MUST NOT cause the 217 server to report information about additional mailbox names. If the 218 client has not specified any return option, only information about 219 attributes should be returned by the server. (Of course the server 220 is allowed to include any other information at will.) 222 Both selection and return command options will be defined in this 223 document and in approved extension documents; each option will be 224 enabled by a capability string (one capability may enable multiple 225 options), and a client MUST NOT send an option for which the server 226 has not advertised support. A server MUST respond to options it does 227 not recognize with a BAD response. The client SHOULD NOT specify any 228 option more than once, however if the client does this, the server 229 MUST act as if it received the option only once. The order in which 230 options are specified by the client is not significant. 232 In general, each selection option except for RECURSIVEMATCH will have 233 a corresponding return option. The REMOTE selection option is an 234 anomaly in this regard, and does not have a corresponding return 235 option. That is because it expands, rather than restricts, the set 236 of mailboxes that are returned. Future extensions to this 237 specification should keep parallelism in mind, and define a pair of 238 corresponding options. 240 This extension is identified by the capability string "LIST- 241 EXTENDED", and support for it is a prerequisite for any future 242 extensions that require specialized forms of the LIST command. Such 243 extensions MUST refer to this document and MUST add their function 244 through command options as described herein. Note that extensions 245 that don't require support for an extended LIST command, but use 246 extended LIST responses (see below), don't need to advertise the 247 "LIST-EXTENDED" capability string. 249 This extension also defines extensions to the LIST response, allowing 250 a series of extended fields at the end, a parenthesized list of 251 tagged data (also referred to as "extended data item"). The first 252 element of an extended field is a tag, which identifies type of the 253 data. Tags MUST be registered with IANA, as described in Section 9.5 254 of this document. An example of such extended set might be 256 tablecloth (("edge" "lacy") ("color" "red"))) (X-Sample "text")) 258 or... 260 tablecloth ("edge" "lacy")) (X-Sample "text" "more text")) 262 See the formal syntax, in Section 6, for the full syntactic details. 263 The server MUST NOT return any extended data item, unless the client 264 has expressed its ability to support extended LIST responses, for 265 example by using an extended LIST command. The server MAY return 266 data in the extended fields that was not directly solicited by the 267 client in the corresponding LIST command. For example, the client 268 can enable extra extended fields by using another IMAP extension that 269 make use of the extended LIST responses. The client MUST ignore all 270 extended fields it doesn't recognize. 272 The LIST-EXTENDED capability also defines several new mailbox 273 attributes. 275 The "\NonExistent" attribute indicates that a mailbox name does not 276 refer to an existing mailbox. Note that this attribute is not 277 meaningful by itself, as mailbox names that match the canonical LIST 278 pattern but don't exist must not be returned unless one of the two 279 conditions listed below is also satisfied: 281 a. the mailbox name also satisfies the selection criteria (for 282 example, it is subscribed and the "SUBSCRIBED" selection option 283 has been specified) 285 b. "RECURSIVEMATCH" has been specified, and the mailbox name has at 286 least one descendant mailbox name that does not match the LIST 287 pattern and does match the selection criteria. 289 In practice this means that the "\NonExistent" attribute is usually 290 returned with one or more of "\Subscribed", "\Remote", "\HasChildren" 291 or the CHILDINFO extended data item (see their description below). 293 The "\NonExistent" attribute implies "\NoSelect". The "\NonExistent" 294 attribute MUST be supported and MUST be accurately computed. 296 3.1. Initial list of selection options 298 The selection options defined in this specification are 300 SUBSCRIBED - causes the LIST command to list subscribed names, 301 rather than the existing mailboxes. This will often be a subset 302 of the actual mailboxes. It's also possible for this list to 303 contain the names of mailboxes that don't exist. In any case, the 304 list MUST include exactly those mailbox names that match the 305 canonical list pattern and are subscribed to. This option is 306 intended to supplement the LSUB command. Of particular note are 307 the mailbox attributes as returned by this option, compared with 308 what is returned by LSUB. With the latter, the attributes 309 returned may not reflect the actual attribute status on the 310 mailbox name, and the \NoSelect attribute has a second special 311 meaning (it indicates that this mailbox is not, itself, 312 subscribed, but that it has descendant mailboxes that are). With 313 the SUBSCRIBED selection option described here, the attributes are 314 accurate, complete, and have no special meanings. "LSUB" and 315 "LIST (SUBSCRIBED)" are, thus, not the same thing, and some 316 servers must do significant extra work to respond to "LIST 317 (SUBSCRIBED)". Because of this, clients SHOULD continue to use 318 "LSUB" unless they specifically want the additional information 319 offered by "LIST (SUBSCRIBED)". 321 This option defines a new mailbox attribute, "\Subscribed", that 322 indicates that a mailbox name is subscribed to. The "\Subscribed" 323 attribute MUST be supported and MUST be accurately computed when 324 the SUBSCRIBED selection option is specified. 326 Note that the SUBSCRIBED selection option implies the SUBSCRIBED 327 return option (see below). 329 REMOTE - causes the LIST command to show remote mailboxes as well as 330 local ones, as described in [MBRef]. This option is intended to 331 replace the RLIST command and, in conjunction with the SUBSCRIBED 332 selection option, the RLSUB command. 334 This option defines a new mailbox attribute, "\Remote", that 335 indicates that a mailbox is a remote mailbox. The "\Remote" 336 attribute MUST be accurately computed when the REMOTE option is 337 specified. 339 The REMOTE selection option has no interaction with other options. 340 Its effect is to tell the server to apply the other options, if 341 any, to remote mailboxes, in addition to local ones. In 342 particular, it has no interaction with RECURSIVEMATCH (see below). 343 A request for (REMOTE RECURSIVEMATCH) is invalid, because a 344 request for (RECURSIVEMATCH) is. A request for (REMOTE 345 RECURSIVEMATCH SUBSCRIBED) is asking for all subscribed mailboxes, 346 both local and remote. 348 RECURSIVEMATCH - this option forces the server to return information 349 about parent mailboxes that don't match other selection options, 350 but have some submailboxes that do. Information about children is 351 returned in the CHILDINFO extended data item, as described in 352 Section 3.5. 354 Note 1: In order for a parent mailbox to be returned, it still has 355 to match the canonical LIST pattern. 357 Note 2: When returning the CHILDINFO extended data item, it 358 doesn't matter if the submailbox matches the canonical LIST 359 pattern or not. See also example 9 in Section 5. 361 The RECURSIVEMATCH option MUST NOT occur as the only selection 362 option (nor only with REMOTE), as it only makes sense when other 363 selection options are also used. The server MUST return BAD 364 tagged response in such case. 366 Note that even if the RECURSIVEMATCH option is specified, the 367 client MUST still be able to handle a case when a CHILDINFO 368 extended data item is returned and there are no submailboxes that 369 meet the selection criteria of the subsequent LIST command, as 370 they can be deleted/renamed after the LIST response was sent, but 371 before the client had a chance to access them. 373 3.2. Initial list of return options 375 The return options defined in this specification are 377 SUBSCRIBED - causes the LIST command to return subscription state 378 for all matching mailbox names. The "\Subscribed" attribute MUST 379 be supported and MUST be accurately computed when the SUBSCRIBED 380 return option is specified. Further, all mailbox flags MUST be 381 accurately computed (this differs from the behaviour of the LSUB 382 command). 384 CHILDREN - Requests mailbox child information as originally proposed 385 in [CMbox]. See Section 4, below, for details. This option MUST 386 be supported by all servers. 388 3.3. General principles for returning LIST responses 390 This section outlines several principles that can be used by server 391 implementations of this document to decide if a LIST response should 392 be returned, as well as how many responses and what kind of 393 information they may contain. 395 1. Exactly one LIST response should be returned for each mailbox 396 name which matches the canonical LIST pattern. Server 397 implementors must not assume that clients will be able to 398 assemble mailbox attributes and other information returned in 399 multiple LIST responses. 401 2. There are only two reasons for including a matching mailbox name 402 in the responses to the LIST command (Note that the server is 403 allowed to return unsolicited responses at any time. Such 404 responses are not governed by this rule): 406 A. the mailbox name also satisfies the selection criteria; 408 B. the mailbox name doesn't satisfy the selection criteria, but 409 it has at least one descendant mailbox name that satisfies 410 the selection criteria and that doesn't match the canonical 411 LIST pattern. 412 For more information on this case see the CHILDINFO extended 413 data item described in Section 3.5. Note that the CHILDINFO 414 extended data item can only be returned when the 415 RECURSIVEMATCH selection option is specified. 417 3. Attributes returned in the same LIST response must be treated 418 additively. For example the following response 420 S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach" 422 means that the "Fruit/Peach" mailbox doesn't exist, but it is 423 subscribed. 425 3.4. Additional requirements on LIST-EXTENDED clients 427 All clients that support this extension MUST treat an attribute with 428 a stronger meaning, as implying any attribute that can be inferred 429 from it. For example, the client must treat presence of the 430 \NoInferiors attribute as if the \HasNoChildren attribute was also 431 sent by the server. 433 The following table summarizes inference rules described in 434 Section 3. 436 +--------------------+-------------------+ 437 | returned attribute | implied attribute | 438 +--------------------+-------------------+ 439 | \NoInferiors | \HasNoChildren | 440 | | | 441 | \NonExistent | \NoSelect | 442 +--------------------+-------------------+ 444 3.5. CHILDINFO extended data item 446 The CHILDINFO extended data item MUST NOT be returned unless the 447 client has specified the RECURSIVEMATCH selection option. 449 The CHILDINFO extended data item in a LIST response describes the 450 selection criteria that has caused it to be returned and indicates 451 that the mailbox has at least one descendant mailbox that matches the 452 selection criteria. 454 The LSUB command indicates this condition by using the "\NoSelect" 455 attribute, but the LIST (SUBSCRIBED) command MUST NOT do that, since 456 "\NoSelect" retains its original meaning here. Further, the 457 CHILDINFO extended data item is more general, in that it can be used 458 with any extended set of selection criteria. 460 Note: Some servers allow for mailboxes to exist without requiring 461 their parent to exist. For example, a mailbox "Customers/ABC" can 462 exist while the mailbox "Customers" does not. As CHILDINFO extended 463 data item is not allowed if the RECURSIVEMATCH selection option is 464 not specified, such servers SHOULD use the "\NonExistent 465 \HasChildren" attribute pair to signal to the client that there is a 466 descendant mailbox that matches the selection criteria. See example 467 11 in Section 5. 469 The returned selection criteria allow the client to distinguish a 470 solicited response from an unsolicited one, as well as to distinguish 471 among solicited responses caused by multiple pipelined LIST commands 472 that specify different criteria. 474 Servers SHOULD ONLY return a non-matching mailbox name along with 475 CHILDINFO if at least one matching child is not also being returned. 476 That is, servers SHOULD suppress redundant CHILDINFO responses. 478 Examples 8 and 10 in Section 5 demonstrate the difference between 479 present CHILDINFO extended data item and the "\HasChildren" 480 attribute. 482 The following table summarizes interaction between the "\NonExistent" 483 attribute and CHILDINFO (the first collumn describes if the parent 484 mailbox exists): 486 +--------+--------------+--------------------+----------------------+ 487 | exists | meets the | has a child that | returned | 488 | | selection | meets the | LIST-EXTENDED | 489 | | criteria | selection criteria | attributes and | 490 | | | | CHILDINFO | 491 +--------+--------------+--------------------+----------------------+ 492 | no | no | no | no LIST response | 493 | | | | returned | 494 | | | | | 495 | yes | no | no | no LIST response | 496 | | | | returned | 497 | | | | | 498 | no | yes | no | (\NonExistent | 499 | | | | ) | 500 | | | | | 501 | yes | yes | no | () | 502 | | | | | 503 | no | no | yes | (\NonExistent) + | 504 | | | | CHILDINFO | 505 | | | | | 506 | yes | no | yes | () + CHILDINFO | 507 | | | | | 508 | no | yes | yes | (\NonExistent | 509 | | | | ) + CHILDINFO | 510 | | | | | 511 | yes | yes | yes | () + CHILDINFO | 512 +--------+--------------+--------------------+----------------------+ 514 where is one or more attributes that correspond to the 515 selection criteria, for example for the SUBSCRIBED option the 516 is \Subscribed. 518 4. The CHILDREN return Option 520 The CHILDREN return option implements the Child Mailbox Extension, 521 originally proposed by Mike Gahrns and Raymond Cheng, of Microsoft 522 Corporation. Most of the information in this section is taken 523 directly from their original specification [CMbox]. The CHILDREN 524 return option is simply an indication that the client wants this 525 information; a server MAY provide it even if the option is not 526 specified. 528 Many IMAP4 [IMAP4] clients present to the user a hierarchical view of 529 the mailboxes that a user has access to. Rather than initially 530 presenting to the user the entire mailbox hierarchy, it is often 531 preferable to show to the user a collapsed outline list of the 532 mailbox hierarchy (particularly if there is a large number of 533 mailboxes). The user can then expand the collapsed outline hierarchy 534 as needed. It is common to include within the collapsed hierarchy a 535 visual clue (such as a ''+'') to indicate that there are child 536 mailboxes under a particular mailbox. When the visual clue is 537 clicked the hierarchy list is expanded to show the child mailboxes. 538 The CHILDREN return option provides a mechanism for a client to 539 efficiently determine if a particular mailbox has children, without 540 issuing a LIST "" * or a LIST "" % for each mailbox name. The 541 CHILDREN return option defines two new attributes that MUST be 542 returned within a LIST response: \HasChildren and \HasNoChildren. 543 While these attributes MAY be returned in response to any LIST 544 command, the CHILDREN return option is provided to indicate that the 545 client particularly wants this information. If the CHILDREN return 546 option is present, the server MUST return these attributes even if 547 their computation is expensive. 549 \HasChildren 551 The presence of this attribute indicates that the mailbox has 552 child mailboxes. A server SHOULD NOT set this attribute if 553 there are child mailboxes, and the user does not have 554 permissions to access any of them. In this case, \HasNoChildren 555 SHOULD be used. In many cases, however, a server may not be 556 able to efficiently compute whether a user has access to any 557 child mailbox. Note that even though the \HasChildren attribute 558 for a mailbox must be correct at the time of processing of the 559 mailbox, a client must be prepared to deal with a situation when 560 a mailbox is marked with the \HasChildren attribute, but no 561 child mailbox appears in the response to the LIST command. This 562 might happen, for example, due to children mailboxes beig 563 deleted or made inaccessible to the user (using access control) 564 by another client before the server is able to list them. 566 \HasNoChildren 568 The presence of this attribute indicates that the mailbox has NO 569 child mailboxes that are accessible to the currently 570 authenticated user. 572 It is an error for the server to return both a \HasChildren and a 573 \HasNoChildren attribute in the same LIST response. 575 Note: the \HasNoChildren attribute should not be confused with the 576 IMAP4 [IMAP4] defined attribute \NoInferiors which indicates that no 577 child mailboxes exist now and none can be created in the future. 579 5. Examples 581 1: The first example shows the complete local hierarchy that will 582 be used for the other examples. 584 C: A01 LIST "" "*" 585 S: * LIST (\Marked \NoInferiors) "/" "inbox" 586 S: * LIST () "/" "Fruit" 587 S: * LIST () "/" "Fruit/Apple" 588 S: * LIST () "/" "Fruit/Banana" 589 S: * LIST () "/" "Tofu" 590 S: * LIST () "/" "Vegetable" 591 S: * LIST () "/" "Vegetable/Broccoli" 592 S: * LIST () "/" "Vegetable/Corn" 593 S: A01 OK done 595 2: In the next example we'll see the subscribed mailboxes. This is 596 similar to, but not equivalent with, . Note that 597 the mailbox called "Fruit/Peach" is subscribed to, but does not 598 actually exist (perhaps it was deleted while still subscribed). 599 The "Fruit" mailbox is not subscribed to, but it has two 600 subscribed children. The "Vegetable" mailbox is subscribed and 601 has two children, one of them is subscribed as well. 603 C: A02 LIST (SUBSCRIBED) "" "*" 604 S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox" 605 S: * LIST (\Subscribed) "/" "Fruit/Banana" 606 S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach" 607 S: * LIST (\Subscribed) "/" "Vegetable" 608 S: * LIST (\Subscribed) "/" "Vegetable/Broccoli" 609 S: A02 OK done 611 3: The next example shows the use of the CHILDREN option. The 612 client, without having to list the second level of hierarchy, 613 now knows which of the top-level mailboxes have submailboxes 614 (children) and which do not. Note that it's not necessary for 615 the server to return the \HasNoChildren attribute for the inbox, 616 because the \NoInferiors attribute already implies that, and has 617 a stronger meaning. 619 C: A03 LIST () "" "%" RETURN (CHILDREN) 620 S: * LIST (\Marked \NoInferiors) "/" "inbox" 621 S: * LIST (\HasChildren) "/" "Fruit" 622 S: * LIST (\HasNoChildren) "/" "Tofu" 623 S: * LIST (\HasChildren) "/" "Vegetable" 624 S: A03 OK done 626 4: In this example we see more mailboxes that reside on another 627 server. This is similar to the command . 629 C: A04 LIST (REMOTE) "" "%" RETURN (CHILDREN) 630 S: * LIST (\Marked \NoInferiors) "/" "inbox" 631 S: * LIST (\HasChildren) "/" "Fruit" 632 S: * LIST (\HasNoChildren) "/" "Tofu" 633 S: * LIST (\HasChildren) "/" "Vegetable" 634 S: * LIST (\Remote) "/" "Bread" 635 S: * LIST (\HasChildren \Remote) "/" "Meat" 636 S: A04 OK done 638 5: The following example also requests the server to include 639 mailboxes that reside on another server. The server returns 640 information about all mailboxes which are subscribed. This is 641 similar to the command . We also see the use of 642 two selection options. 644 C: A05 LIST (REMOTE SUBSCRIBED) "" "*" 645 S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox" 646 S: * LIST (\Subscribed) "/" "Fruit/Banana" 647 S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach" 648 S: * LIST (\Subscribed) "/" "Vegetable" 649 S: * LIST (\Subscribed) "/" "Vegetable/Broccoli" 650 S: * LIST (\Remote \Subscribed) "/" "Bread" 651 S: A05 OK done 653 6: The following example requests the server to include mailboxes 654 that reside on another server. The server is asked to return 655 subscription information for all returned mailboxes. This is 656 different from the example above. 658 Note that the output of this command is not a superset of the 659 output in the previous example, as it doesn't include LIST 660 response for the non-existent "Fruit/Peach". 662 C: A06 LIST (REMOTE) "" "*" RETURN (SUBSCRIBED) 663 S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox" 664 S: * LIST () "/" "Fruit" 665 S: * LIST () "/" "Fruit/Apple" 666 S: * LIST (\Subscribed) "/" "Fruit/Banana" 667 S: * LIST () "/" "Tofu" 668 S: * LIST (\Subscribed) "/" "Vegetable" 669 S: * LIST (\Subscribed) "/" "Vegetable/Broccoli" 670 S: * LIST () "/" "Vegetable/Corn" 671 S: * LIST (\Remote \Subscribed) "/" "Bread" 672 S: * LIST (\Remote) "/" "Meat" 673 S: A06 OK done 675 7: In the following example the client has specified multiple 676 mailbox patterns. Note that this example does not use the 677 mailbox hierarchy used in the previous examples. 679 C: BBB LIST "" ("INBOX" "Drafts" "Sent/%") 680 S: * LIST () "/" "INBOX" 681 S: * LIST (\NoInferiors) "/" "Drafts" 682 S: * LIST () "/" "Sent/March2004" 683 S: * LIST (\Marked) "/" "Sent/December2003" 684 S: * LIST () "/" "Sent/August2004" 685 S: BBB OK done 687 8: The following example demonstrates the difference between the 688 \HasChildren attribute and the CHILDINFO extended data item. 690 Let's assume there is the following hierarchy: 692 C: C01 LIST "" "*" 693 S: * LIST (\Marked \NoInferiors) "/" "inbox" 694 S: * LIST () "/" "Foo" 695 S: * LIST () "/" "Foo/Bar" 696 S: * LIST () "/" "Foo/Baz" 697 S: * LIST () "/" "Moo" 698 S: C01 OK done 700 If the client asks RETURN (CHILDREN) it will get this: 702 C: CA3 LIST "" "%" RETURN (CHILDREN) 703 S: * LIST (\Marked \NoInferiors) "/" "inbox" 704 S: * LIST (\HasChildren) "/" "Foo" 705 S: * LIST (\HasNoChildren) "/" "Moo" 706 S: CA3 OK done 707 A) Let's also assume that the mailbox "Foo/Baz" is the only 708 subscribed mailbox. Then we get this result: 710 C: C02 LIST (SUBSCRIBED) "" "*" 711 S: * LIST (\Subscribed) "/" "Foo/Baz" 712 S: C02 OK done 714 Now, if the client issues , the server 715 will return no mailboxes (as the mailboxes "Moo", "Foo" and 716 "Inbox" are NOT subscribed). However, if the client issues 717 this: 719 C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" 720 S: * LIST () "/" "Foo" ("CHILDINFO" ("SUBSCRIBED")) 721 S: C04 OK done 723 i.e. the mailbox "Foo" is not subscribed, but it has a child 724 that is. 726 A1) If the mailbox "Foo" had also been subscribed, the last 727 command would return this: 729 C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" 730 S: * LIST (\Subscribed) "/" "Foo" ("CHILDINFO" ("SUBSCRIBED")) 731 S: C04 OK done 733 or even this: 735 C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" 736 S: * LIST (\Subscribed \HasChildren) "/" "Foo" ("CHILDINFO" 737 ("SUBSCRIBED")) 738 S: C04 OK done 740 A2) If we assume instead that the mailbox "Foo" is not part of 741 the original hierarchy and is not subscribed, the last command 742 will give this result: 744 C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" 745 S: * LIST (\NonExistent) "/" "Foo" ("CHILDINFO" ("SUBSCRIBED")) 746 S: C04 OK done 748 B) Now, let's assume that no mailbox is subscribed. In this 749 case the command will 750 return no responses, as there are no subscribed children (even 751 though "Foo" has children). 753 C) And finally, suppose that only the mailboxes "Foo" and "Moo" 754 are subscribed. In that case we see this result: 756 C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" RETURN (CHILDREN) 757 S: * LIST (\HasChildren \Subscribed) "/" "Foo" 758 S: * LIST (\HasNoChildren \Subscribed) "/" "Moo" 759 S: C04 OK done 761 (which means that the mailbox "Foo" has children, but none of 762 them is subscribed). 764 9: The following example demonstrates that the CHILDINFO extended 765 data item is returned whether children mailboxes match the 766 canonical LIST pattern or not. 768 Let's assume there is the following hierarchy: 770 C: D01 LIST "" "*" 771 S: * LIST (\Marked \NoInferiors) "/" "inbox" 772 S: * LIST () "/" "foo2" 773 S: * LIST () "/" "foo2/bar1" 774 S: * LIST () "/" "foo2/bar2" 775 S: * LIST () "/" "baz2" 776 S: * LIST () "/" "baz2/bar2" 777 S: * LIST () "/" "baz2/bar22" 778 S: * LIST () "/" "baz2/bar222" 779 S: * LIST () "/" "eps2" 780 S: * LIST () "/" "eps2/mamba" 781 S: * LIST () "/" "qux2/bar2" 782 S: D01 OK done 784 And that the following mailboxes are subscribed: 786 C: D02 LIST (SUBSCRIBED) "" "*" 787 S: * LIST (\Subscribed) "/" "foo2/bar1" 788 S: * LIST (\Subscribed) "/" "foo2/bar2" 789 S: * LIST (\Subscribed) "/" "baz2/bar2" 790 S: * LIST (\Subscribed) "/" "baz2/bar22" 791 S: * LIST (\Subscribed) "/" "baz2/bar222" 792 S: * LIST (\Subscribed) "/" "eps2" 793 S: * LIST (\Subscribed) "/" "eps2/mamba" 794 S: * LIST (\Subscribed) "/" "qux2/bar2" 795 S: D02 OK done 797 The client issues the following command first: 799 C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*2" 800 S: * LIST () "/" "foo2" ("CHILDINFO" ("SUBSCRIBED")) 801 S: * LIST (\Subscribed) "/" "foo2/bar2" 802 S: * LIST () "/" "baz2" ("CHILDINFO" ("SUBSCRIBED")) 803 S: * LIST (\Subscribed) "/" "baz2/bar2" 804 S: * LIST (\Subscribed) "/" "baz2/bar22" 805 S: * LIST (\Subscribed) "/" "baz2/bar222" 806 S: * LIST (\Subscribed) "/" "eps2" ("CHILDINFO" ("SUBSCRIBED")) 807 S: * LIST (\Subscribed) "/" "qux2/bar2" 808 S: D03 OK done 810 and the server may also include 812 S: * LIST (\NonExistent) "/" "qux2" ("CHILDINFO" ("SUBSCRIBED")) 814 The CHILDINFO extended data item is returned for mailboxes 815 "foo2", "baz2" and "eps2", because all of them have subscribed 816 children, even though for the mailbox "foo2" only one of the two 817 subscribed children match the pattern, for the mailbox "baz2" 818 all the subscribed children match the pattern and for the 819 mailbox "eps2" none of the subscribed children matches the 820 pattern. 822 Note that if the client issues 824 C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*" 825 S: * LIST () "/" "foo2" ("CHILDINFO" ("SUBSCRIBED")) 826 S: * LIST (\Subscribed) "/" "foo2/bar1" 827 S: * LIST (\Subscribed) "/" "foo2/bar2" 828 S: * LIST () "/" "baz2" ("CHILDINFO" ("SUBSCRIBED")) 829 S: * LIST (\Subscribed) "/" "baz2/bar2" 830 S: * LIST (\Subscribed) "/" "baz2/bar22" 831 S: * LIST (\Subscribed) "/" "baz2/bar222" 832 S: * LIST (\Subscribed) "/" "eps2" ("CHILDINFO" ("SUBSCRIBED")) 833 S: * LIST (\Subscribed) "/" "eps2/mamba" 834 S: * LIST (\Subscribed) "/" "qux2/bar2" 835 S: D03 OK done 837 the LIST responses for mailboxes "foo2", "baz2" and "eps2" still 838 have the CHILDINFO extended data item, even though this 839 information is redundant and the client can determine it by 840 itself. 842 10: The following example shows usage of multiple mailbox patterns. 843 It also demonstrates that the presence of the CHILDINFO extended 844 data item doesn't necessarily imply \HasChildren. 846 C: a1 LIST "" ("foo" "foo/*") 847 S: * LIST () "/" foo 848 S: a1 OK done 850 C: a2 LIST (SUBSCRIBED) "" "foo/*" 851 S: * LIST (\Subscribed \NonExistent) "/" foo/bar 852 S: a2 OK done 854 C: a3 LIST (SUBSCRIBED RECURSIVEMATCH) "" foo RETURN (CHILDREN) 855 S: * LIST (\HasNoChildren) "/" foo ("CHILDINFO" ("SUBSCRIBED")) 856 S: a3 OK done 858 11: The following example shows how a server that supports missing 859 mailbox hierarchy elements can signal to a client that didn't 860 specify the RECURSIVEMATH selection option that there is a child 861 mailbox that matches the selection criteria. 863 C: a1 LIST (REMOTE) "" * 864 S: * LIST () "/" music/rock 865 S: * LIST (\Remote) "/" also/jazz 866 S: a1 OK done 868 C: a2 LIST () "" % 869 S: * LIST (\NonExistent \HasChildren) "/" music 870 S: a2 OK done 872 C: a3 LIST (REMOTE) "" % 873 S: * LIST (\NonExistent \HasChildren) "/" music 874 S: * LIST (\NonExistent \HasChildren) "/" also 875 S: a3 OK done 877 6. Formal Syntax 879 The following syntax specification uses the augmented Backus-Naur 880 Form (BNF) as described in [ABNF]. Terms not defined here are taken 881 from [IMAP4]. In particular, note that the version of "mailbox-list" 882 below, which defines the payload of the LIST response, updates the 883 version defined in the IMAP specification. It is pointed to by 884 "mailbox-data", which is defined in [IMAP4]. 886 "vendor-token" is defined in [ACAP]. Note that this normative 887 reference to ACAP will be an issue in moving this spec forward, since 888 it introduces a dependency on ACAP. The definitions of "vendor- 889 token" and of the IANA registry must eventually go somewhere else, in 890 a document that can be moved forward on the standards track 891 independently of ACAP. 893 childinfo-extended-item = "CHILDINFO" SP "(" 894 list-select-base-opt-quoted 895 *(SP list-select-base-opt-quoted) ")" 896 ; Extended data item (mbox-list-extended-item) 897 ; returned when the RECURSIVEMATCH 898 ; selection option is specified. 899 ; Note 1: the CHILDINFO tag can be returned 900 ; with and without surrounding quotes, as per 901 ; mbox-list-extended-item-tag production. 902 ; Note 2: The selection options are always returned 903 ; quoted, unlike their specification in 904 ; the extended LIST command. 906 child-mbox-flag = "\HasChildren" / "\HasNoChildren" 907 ; attributes for CHILDREN return option, at most one 908 ; possible per LIST response 910 eitem-standard-tag = atom 911 ; a tag for extended list data defined in a Standard 912 ; Track or Experimental RFC. 914 eitem-vendor-tag = vendor-tag 915 ; a vendor specific tag for extended list data 917 list = "LIST" [SP list-select-opts] SP mailbox SP mbox-or-pat 918 [SP list-return-opts] 920 list-return-opts = "RETURN" SP 921 "(" [return-option *(SP return-option)] ")" 922 ; list return options, e.g. CHILDREN 924 list-select-base-opt = "SUBSCRIBED" / option-extension 925 ; options that can be used by themselves 927 list-select-base-opt-quoted = DQUOTE list-select-base-opt DQUOTE 929 list-select-independent-opt = "REMOTE" / option-extension 930 ; options that do not syntactically interact with 931 ; other options 933 list-select-mod-opt = "RECURSIVEMATCH" / option-extension 934 ; options that require a list-select-base-opt 935 ; to also be present 937 list-select-opt = list-select-base-opt / list-select-independent-opt 938 / list-select-mod-opt 939 ; An option registration template is described in 940 ; Section 9.3 of this document. 942 list-select-opts = "(" [ 943 (*(list-select-opt SP) list-select-base-opt 944 *(SP list-select-opt)) 945 / (list-select-independent-opt 946 *(SP list-select-independent-opt)) 947 ] ")" 948 ; Any number of options may be in any order. 949 ; If a list-select-mod-opt appears, then a 950 ; list-select-base-opt must also appear. 951 ; This allows these: 952 ; () 953 ; (REMOTE) 954 ; (SUBSCRIBED) 955 ; (SUBSCRIBED REMOTE) 956 ; (SUBSCRIBED RECURSIVEMATCH) 957 ; (SUBSCRIBED REMOTE RECURSIVEMATCH) 958 ; But does NOT allow these: 959 ; (RECURSIVEMATCH) 960 ; (REMOTE RECURSIVEMATCH) 962 mailbox-list = "(" [mbx-list-flags] ")" SP 963 (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox 964 [SP mbox-list-extended] 965 ; This is the list information pointed to by the ABNF 966 ; item "mailbox-data", which is defined in [IMAP4] 968 mbox-list-extended = "(" [mbox-list-extended-item 969 *(SP mbox-list-extended-item)] ")" 971 mbox-list-extended-item = mbox-list-extended-item-tag SP 972 tagged-ext-val 974 mbox-list-extended-item-tag = astring 975 ; The content MUST conform to either "eitem-vendor-tag" 976 ; or "eitem-standard-tag" ABNF productions. 977 ; A tag registration template is described in this 978 ; document in Section 9.5. 980 mbox-list-oflag = child-mbox-flag / "\NonExistent" / "\Subscribed" / 981 "\Remote" 983 mbox-or-pat = list-mailbox / patterns 985 option-extension = (option-standard-tag / option-vendor-tag) 986 [SP option-value] 988 option-standard-tag = atom 989 ; an option defined in a Standards Track or 990 ; Experimental RFC 992 option-val-comp = astring / 993 option-val-comp *(SP option-val-comp) / 994 "(" option-val-comp ")" 996 option-value = "(" option-val-comp ")" 997 option-vendor-tag = vendor-token "-" atom 998 ; a vendor specific option, non-standard 1000 patterns = "(" list-mailbox *(SP list-mailbox) ")" 1002 return-option = "SUBSCRIBED" / "CHILDREN" / option-extension 1004 tagged-ext-comp = astring / 1005 tagged-ext-comp *(SP tagged-ext-comp) / 1006 "(" tagged-ext-comp ")" 1007 ; Extensions that follow this general 1008 ; syntax should use nstring instead of 1009 ; astring when appropriate in the context 1010 ; of the extension. 1011 ; Note that a message set or a "number" 1012 ; can always be represented as an "atom". 1013 ; An URL should be represented as 1014 ; a "quoted" string. 1016 tagged-ext-simple = sequence-set / number 1018 tagged-ext-val = tagged-ext-simple / 1019 "(" [tagged-ext-comp] ")" 1021 7. Internationalization Considerations 1023 The LIST command selection option types defined in this specification 1024 involve simple tests of mailbox properties. However, future 1025 extensions to LIST-EXTENDED may define selection options that do more 1026 sophisticated tests. In the case of a test that requires matching 1027 text, in the presence of the COMPARATOR [I18N] extension, the active 1028 comparator must be used to do comparisons. Such LIST-EXTENDED 1029 extensions MUST indicate in their specification the interaction with 1030 the COMPARATOR [I18N] extension. 1032 8. Security Considerations 1034 This document describes syntactic changes to the specification of the 1035 IMAP4 commands LIST, LSUB, RLIST, and RLSUB, and the modified LIST 1036 command has the same security considerations as those commands. They 1037 are described in [IMAP4] and [MBRef]. 1039 The Child Mailbox Extension provides a client a more efficient means 1040 of determining whether a particular mailbox has children. If a 1041 mailbox has children, but the currently authenticated user does not 1042 have access to any of them, the server SHOULD respond with a 1043 \HasNoChildren attribute. In many cases, however, a server may not 1044 be able to efficiently compute whether a user has access to any child 1045 mailbox. If such a server responds with a \HasChildren attribute, 1046 when in fact the currently authenticated user does not have access to 1047 any child mailboxes, potentially more information is conveyed about 1048 the mailbox than intended. In most situations this will not be a 1049 security concern, because if information regarding whether a mailbox 1050 has children is considered sensitive, a user would not be granted 1051 access to that mailbox in the first place. 1053 The CHILDINFO extended data item has the same security considerations 1054 as the \HasChildren attribute described above. 1056 9. IANA Considerations 1058 9.1. Guidelines for IANA 1060 It is requested that IANA creates two new registries for LIST- 1061 EXTENDED options and LIST-EXTENDED response data. The templates and 1062 the initial registrations are detailed below. 1064 9.2. Registration procedure and Change control 1066 Registration of a LIST-EXTENDED option is done by filling in the 1067 template in Section 9.3 and sending it via electronic mail to 1068 iana@iana.org. Registration of a LIST-EXTENDED extended data item is 1069 done by filling in the template in Section 9.5 and sending it via 1070 electronic mail to iana@iana.org. IANA has the right to reject 1071 obviously bogus registrations, but will perform no review of claims 1072 made in the registration form. 1074 A LIST-EXTENDED option/extended data item name that starts with "V-" 1075 is reserved for vendor specific options/extended data items. All 1076 options, whether they are vendor specific or global, should be 1077 registered with IANA. If a LIST-EXTENDED extended data item is 1078 returned as a result of requesting a particular LIST-EXTENDED option, 1079 the name of the option SHOULD be used as the name of the LIST- 1080 EXTENDED extended data item. 1082 Each vendor specific options/extended data item MUST start with their 1083 vendor-token ("vendor prefix"). The vendor-token MUST be registered 1084 with IANA, using the [ACAP] vendor subtree registry. 1086 Standard LIST-EXTENDED option/extended data item names are case 1087 insensitive. If the vendor prefix is omitted from a vendor specific 1088 LIST-EXTENDED option/extended data item name, the rest is case 1089 insensitive. The vendor prefix itself is not case-sensitive, as it 1090 might contain non-ASCII characters. 1092 While the registration procedures do not require it, authors of LIST- 1093 EXTENDED options/extended data items are encouraged to seek community 1094 review and comment whenever that is feasible. Authors may seek 1095 community review by posting a specification of their proposed 1096 mechanism as an Internet- Draft. LIST-EXTENDED options/extended data 1097 items intended for widespread use should be standardized through the 1098 normal IETF process, when appropriate. 1100 Comments on registered LIST-EXTENDED options/extended response data 1101 should first be sent to the "owner" of the mechanism and/or to the 1102 IMAPEXT WG mailing list. Submitters of comments may, after a 1103 reasonable attempt to contact the owner, request IANA to attach their 1104 comment to the registration itself. If IANA approves of this, the 1105 comment will be made accessible in conjunction with the registration 1106 LIST-EXTENDED options/ extended response data itself. 1108 Once a LIST-EXTENDED registration has been published by IANA, the 1109 author may request a change to its definition. The change request 1110 follows the same procedure as the registration request. 1112 The owner of a LIST-EXTENDED registration may pass responsibility for 1113 the registered option/extended data item to another person or agency 1114 by informing IANA; this can be done without discussion or review. 1116 The IESG may reassign responsibility for a LIST-EXTENDED option/ 1117 extended data item. The most common case of this will be to enable 1118 changes to be made to mechanisms where the author of the registration 1119 has died, moved out of contact or is otherwise unable to make changes 1120 that are important to the community. 1122 LIST-EXTENDED registrations may not be deleted; mechanisms which are 1123 no longer believed appropriate for use can be declared OBSOLETE by a 1124 change to their "intended use" field; such LIST-EXTENDED options/ 1125 extended data items will be clearly marked in the lists published by 1126 IANA. 1128 The IESG is considered to be the owner of all LIST-EXTENDED options/ 1129 extended data items which are on the IETF standards track. 1131 9.3. Registration template for LIST-EXTENDED options 1133 To: iana@iana.org 1134 Subject: Registration of LIST-EXTENDED option X 1136 LIST-EXTENDED option name: 1138 LIST-EXTENDED option type: (One of SELECTION or RETURN) 1140 Implied return options(s), if the option type is SELECTION: (zero or 1141 more) 1143 LIST-EXTENDED option description: 1145 Published specification (optional, recommended): 1147 Security considerations: 1149 Intended usage: 1150 (One of COMMON, LIMITED USE or OBSOLETE) 1151 Person and email address to contact for further information: 1153 Owner/Change controller: 1155 (Any other information that the author deems interesting may be added 1156 below this line.) 1158 9.4. Initial LIST-EXTENDED option registrations 1160 It is requested that the LIST-EXTENDED option registry be populated 1161 with the following entries: 1163 1. To: iana@iana.org 1164 Subject: Registration of LIST-EXTENDED option SUBSCRIBED 1166 LIST-EXTENDED option name: SUBSCRIBED 1168 LIST-EXTENDED option type: SELECTION 1170 Implied return options(s): SUBSCRIBED 1172 LIST-EXTENDED option description: Causes the LIST command to list 1173 subscribed mailboxes, rather than the actual mailboxes. 1175 Published specification : XXXX, Section 3. 1177 Security considerations: XXXX, Section 8. 1179 Intended usage: COMMON 1181 Person and email address to contact for further information: 1182 Alexey Melnikov 1184 Owner/Change controller: iesg@ietf.org 1186 2. To: iana@iana.org 1187 Subject: Registration of LIST-EXTENDED option REMOTE 1189 LIST-EXTENDED option name: REMOTE 1191 LIST-EXTENDED option type: SELECTION 1193 Implied return options(s): (none) 1195 LIST-EXTENDED option description: causes the LIST command to 1196 return remote mailboxes as well as local ones, as described in 1197 RFC 2193. 1199 Published specification : XXXX, Section 3. 1201 Security considerations: XXXX, Section 8. 1203 Intended usage: COMMON 1205 Person and email address to contact for further information: 1206 Alexey Melnikov 1208 Owner/Change controller: iesg@ietf.org 1210 3. To: iana@iana.org 1211 Subject: Registration of LIST-EXTENDED option SUBSCRIBED 1213 LIST-EXTENDED option name: SUBSCRIBED 1215 LIST-EXTENDED option type: RETURN 1217 LIST-EXTENDED option description: Causes the LIST command to 1218 return subscription state. 1220 Published specification : XXXX, Section 3. 1222 Security considerations: XXXX, Section 8. 1224 Intended usage: COMMON 1226 Person and email address to contact for further information: 1227 Alexey Melnikov 1229 Owner/Change controller: iesg@ietf.org 1231 4. To: iana@iana.org 1232 Subject: Registration of LIST-EXTENDED option RECURSIVEMATCH 1234 LIST-EXTENDED option name: RECURSIVEMATCH 1236 LIST-EXTENDED option type: SELECTION 1238 Implied return options(s): (none) 1240 LIST-EXTENDED option description: Requests that CHILDINFO 1241 extended data item (childinfo-extended-item) is to be returned. 1243 Published specification : XXXX, Section 3. 1245 Security considerations: XXXX, Section 8. 1247 Intended usage: COMMON 1249 Person and email address to contact for further information: 1250 Alexey Melnikov 1252 Owner/Change controller: iesg@ietf.org 1254 5. To: iana@iana.org 1255 Subject: Registration of LIST-EXTENDED option CHILDREN 1257 LIST-EXTENDED option name: CHILDREN 1259 LIST-EXTENDED option type: RETURN 1261 LIST-EXTENDED option description: Requests mailbox child 1262 information. 1264 Published specification : XXXX, Section 3 and Section 4. 1266 Security considerations: XXXX, Section 8. 1268 Intended usage: COMMON 1270 Person and email address to contact for further information: 1271 Alexey Melnikov 1273 Owner/Change controller: iesg@ietf.org 1275 9.5. Registration template for LIST-EXTENDED extended data item 1277 To: iana@iana.org 1278 Subject: Registration of X LIST-EXTENDED extended data item 1280 LIST-EXTENDED extended data item tag: 1282 LIST-EXTENDED extended data item description: 1284 Which LIST-EXTENDED option(s) (and their types) causes this extended 1285 data item to be returned (if any): 1287 Published specification (optional, recommended): 1289 Security considerations: 1291 Intended usage: 1292 (One of COMMON, LIMITED USE or OBSOLETE) 1294 Person and email address to contact for further information: 1296 Owner/Change controller: 1298 (Any other information that the author deems interesting may be added 1299 below this line.) 1301 9.6. Initial LIST-EXTENDED extended data item registrations 1303 It is requested that the LIST-EXTENDED extended data item registry be 1304 populated with the following entries: 1306 1. To: iana@iana.org 1307 Subject: Registration of CHILDINFO LIST-EXTENDED extended data 1308 item 1310 LIST-EXTENDED extended data item tag: CHILDINFO 1312 LIST-EXTENDED extended data item description: The CHILDINFO 1313 extended data item describes the selection criteria that has 1314 caused it to be returned and indicates that the mailbox has one 1315 or more child mailbox that match the selection criteria. 1317 Which LIST-EXTENDED option(s) (and their types) causes this 1318 extended data item to be returned (if any): RECURSIVEMATCH 1319 selection option 1321 Published specification : XXXX, Section 3.5. 1323 Security considerations: XXXX, Section 8. 1325 Intended usage: COMMON 1327 Person and email address to contact for further information: 1328 Alexey Melnikov 1330 Owner/Change controller: iesg@ietf.org 1332 10. Acknowledgements 1334 Mike Gahrns and Raymond Cheng of Microsoft Corporation originally 1335 devised the Child Mailbox Extension and proposed it in 1997; the 1336 idea, as well as most of the text in Section 4, is theirs. 1338 This document is the result of discussions on the IMAP4 and IMAPEXT 1339 mailing lists and is meant to reflect consensus of those groups. In 1340 particular, Mark Crispin, Philip Guenther, Cyrus Daboo, Timo 1341 Sirainen, Ken Murchison, Rob Siemborski, Steve Hole, Arnt 1342 Gulbrandsen, Larry Greenfield, Dave Cridland and Pete Maclean were 1343 active participants in those discussions or made suggestions to this 1344 document. 1346 11. References 1348 11.1. Normative References 1350 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1351 Specifications: ABNF", RFC 4234, October 2005. 1353 [ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration 1354 Access Protocol", RFC 2244, November 1997. 1356 [I18N] Newman, C. and A. Gulbrandsen, "ACAP -- Application 1357 Configuration Access Protocol", draft-ietf-imapext-i18n 1358 (work in progress), February 2006. 1360 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 1361 4rev1", RFC 3501, March 2003. 1363 [Kwds] Bradner, S., "Key words for use in RFCs to Indicate 1364 Requirement Levels", RFC 2119, March 1997. 1366 [MBRef] Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193, 1367 September 1997. 1369 11.2. informative References 1371 [CMbox] Gahrns, M. and R. Cheng, "", RFC 3348, July 2002. 1373 Authors' Addresses 1375 Barry Leiba 1376 IBM T.J. Watson Research Center 1377 19 Skyline Drive 1378 Hawthorne, NY 10532 1379 US 1381 Phone: +1 914 784 7941 1382 Email: leiba@watson.ibm.com 1384 Alexey Melnikov 1385 Isode Limited 1386 5 Castle Business Village 1387 36 Station Road 1388 Hampton, Middlesex TW12 2BX 1389 UK 1391 Email: Alexey.Melnikov@isode.com 1392 URI: http://www.melnikov.ca/ 1394 Full Copyright Statement 1396 Copyright (C) The Internet Society (2006). 1398 This document is subject to the rights, licenses and restrictions 1399 contained in BCP 78, and except as set forth therein, the authors 1400 retain all their rights. 1402 This document and the information contained herein are provided on an 1403 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1404 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1405 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1406 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1407 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1408 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1410 Intellectual Property 1412 The IETF takes no position regarding the validity or scope of any 1413 Intellectual Property Rights or other rights that might be claimed to 1414 pertain to the implementation or use of the technology described in 1415 this document or the extent to which any license under such rights 1416 might or might not be available; nor does it represent that it has 1417 made any independent effort to identify any such rights. Information 1418 on the procedures with respect to rights in RFC documents can be 1419 found in BCP 78 and BCP 79. 1421 Copies of IPR disclosures made to the IETF Secretariat and any 1422 assurances of licenses to be made available, or the result of an 1423 attempt made to obtain a general license or permission for the use of 1424 such proprietary rights by implementers or users of this 1425 specification can be obtained from the IETF on-line IPR repository at 1426 http://www.ietf.org/ipr. 1428 The IETF invites any interested party to bring to its attention any 1429 copyrights, patents or patent applications, or other proprietary 1430 rights that may cover technology that may be required to implement 1431 this standard. Please address the information to the IETF at 1432 ietf-ipr@ietf.org. 1434 Acknowledgment 1436 Funding for the RFC Editor function is provided by the IETF 1437 Administrative Support Activity (IASA).