idnits 2.17.1 draft-ietf-imapext-list-extensions-17.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1440. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1417. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1424. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1430. ** 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 'Intended status' indicated for this document; assuming Proposed Standard 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 (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 (April 26, 2006) is 6546 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 Updates: 2193 (if approved) A. Melnikov 5 Obsoletes: 3348 (if approved) Isode Limited 6 Expires: October 28, 2006 April 26, 2006 8 IMAP4 LIST Command Extensions 9 draft-ietf-imapext-list-extensions-17 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on October 28, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 IMAP4 has two commands for listing mailboxes: LIST and LSUB. As we 43 have added extensions, such as Mailbox Referrals, that have required 44 specialized lists we have had to expand the number of list commands, 45 since each extension must add its function to both LIST and LSUB, and 46 these commands are not, as they are defined, extensible. If we've 47 needed the extensions to work together, we've had to add a set of 48 commands to mix the different options, the set increasing in size 49 with each new extension. This document describes an extension to the 50 base LIST command that will allow these additions to be done with 51 mutually compatible options to the LIST command, avoiding the 52 exponential increase in specialized list commands. 54 Note 56 A revised version of this draft document will be submitted to the RFC 57 editor as a Proposed Standard for the Internet Community. Discussion 58 and suggestions for improvement are requested, and should be sent to 59 ietf-imapext@imc.org. 61 This document obsoletes RFC 3348 and updates RFC 2193. 63 Table of Contents 65 1. Conventions used in this document . . . . . . . . . . . . . 4 67 2. Introduction and overview . . . . . . . . . . . . . . . . . 5 69 3. Extended LIST Command . . . . . . . . . . . . . . . . . . . 7 70 3.1 Initial list of selection options . . . . . . . . . . . . . 9 71 3.2 Initial list of return options . . . . . . . . . . . . . . . 11 72 3.3 General principles for returning LIST responses . . . . . . 11 73 3.4 Additional requirements on LIST-EXTENDED clients . . . . . . 12 74 3.5 CHILDINFO extended data item . . . . . . . . . . . . . . . . 12 76 4. The CHILDREN return Option . . . . . . . . . . . . . . . . . 15 78 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17 80 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 24 82 7. Internationalization Considerations . . . . . . . . . . . . 28 84 8. Security Considerations . . . . . . . . . . . . . . . . . . 29 86 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 30 87 9.1 Guidelines for IANA . . . . . . . . . . . . . . . . . . . . 30 88 9.2 Registration procedure and Change control . . . . . . . . . 30 89 9.3 Registration template for LIST-EXTENDED options . . . . . . 31 90 9.4 Initial LIST-EXTENDED option registrations . . . . . . . . . 32 91 9.5 Registration template for LIST-EXTENDED extended data item . 34 92 9.6 Initial LIST-EXTENDED extended data item registrations . . . 35 94 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 96 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 97 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 37 98 11.2 informative References . . . . . . . . . . . . . . . . . . . 37 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 37 102 Intellectual Property and Copyright Statements . . . . . . . 39 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 key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119 [Kwds]. 113 The term "canonical LIST pattern" refers to the canonical pattern 114 constructed internally by the server from the reference and mailbox 115 name arguments (Section 6.3.8 of [IMAP4]). The [IMAP4] LIST command 116 returns only mailboxes that match the canonical LIST pattern. 118 Other terms are introduced where they are referenced for the first 119 time. 121 2. Introduction and overview 123 The LIST command is extended by amending the syntax to allow options 124 and multiple patterns to be specified. The list of options replaces 125 the several commands that are currently used to mix and match the 126 information requested. The new syntax is backward- compatible, with 127 no ambiguity: the new syntax is being used if one of the following 128 conditions is true: 130 1. if the first word after the command name begins with a 131 parenthesis ("LIST selection options"); 133 2. if the second word after the command name begins with a 134 parenthesis ("multiple mailbox patterns"); 136 3. if the LIST command has more than 2 parameters ("LIST return 137 options"); 139 Otherwise the original syntax is used. 141 By adding options to the LIST command, we are announcing the intent 142 to phase out and eventually to deprecate the RLIST and RLSUB commands 143 described in [MBRef]. We are also defining the mechanism to request 144 extended mailbox information, such as is described in the "Child 145 Mailbox Extension" [CMbox]. The base LSUB command is not deprecated 146 by this extension; rather, this extension adds a way to obtain 147 subscription information with more options, with those server 148 implementations that support it. Clients that simply need a list of 149 subscribed mailboxes, as provided by the LSUB command, SHOULD 150 continue to use that command. 152 This document defines an IMAP4 extension that is identified by the 153 capability string "LIST-EXTENDED". The LIST-EXTENDED extension makes 154 the following changes to the IMAP4 protocol, which are described in 155 more detail in Section 3 and Section 4: 157 a. defines new syntax for LIST command options. 159 b. extends LIST to allow for multiple mailbox patterns. 161 c. adds LIST command selection options: SUBSCRIBED, REMOTE and 162 RECURSIVEMATCH. 164 d. adds LIST command return options: SUBSCRIBED and CHILDREN. 166 e. adds new mailbox attributes: "\NonExistent", "\Subscribed", 167 "\Remote", "\HasChildren" and "\HasNoChildren". 169 f. adds CHILDINFO extended data item. 171 3. Extended LIST Command 173 This extension updates the syntax of the LIST command to allow for 174 multiple mailbox patterns to be specified, if they are enclosed in 175 parentheses. A mailbox name matches a list of mailbox patterns if it 176 matches at least one mailbox pattern. If a mailbox name matches 177 multiple mailbox patterns from the list, the server SHOULD return 178 only a single LIST response. 180 Note that the non-extended LIST command is required to treat an empty 181 ("" string) mailbox name argument as a special request to return the 182 hierarchy delimiter and the root name of the name given in the 183 reference parameter (as per [IMAP4]). However ANY extended LIST 184 command (extended in any of 3 ways specified in Section 2, or any 185 combination of thereof) MUST NOT treat the empty mailbox name as such 186 special request and any regular processing described in this document 187 applies. In particular, if an extended LIST command has multiple 188 mailbox names and one (or more) of them is the empty string, the 189 empty string MUST be ignored for the purpose of matching. 191 Some servers might restrict which patterns are allowed in a LIST 192 command. If a server doesn't accept a particular pattern, it MUST 193 silently ignore it. 195 The LIST command syntax is also extended in two additional ways: by 196 adding a parenthesized list of command options between the command 197 name and the reference name (LIST selection options) and an optional 198 list of options at the end that control what kind of information 199 should be returned (LIST return options). See the formal syntax in 200 Section 6 for specific details. 202 A LIST selection option tells the server which mailbox names should 203 be selected by the LIST operation. The server should return 204 information about all mailbox names that match any of the "canonical 205 LIST pattern" (as described above) and satisfy additional selection 206 criteria (if any) specified by the LIST selection options. Let's 207 call any such mailbox name a "matched mailbox name". When multiple 208 selection options are specified, the server MUST return information 209 about mailbox names that satisfy every selection option, unless a 210 description of a particular specified option prescribes special 211 rules. An example of an option prescribing special rules is the 212 RECURSIVEMATCH selection option described later in this section. We 213 will use the term "selection criteria" when referring collectively to 214 all selection options specified in a LIST command. 216 A LIST return option controls which information is returned for each 217 matched mailbox name. Note that return options MUST NOT cause the 218 server to report information about additional mailbox names. If the 219 client has not specified any return option, only information about 220 attributes should be returned by the server. (Of course the server 221 is allowed to include any other information at will.) 223 Both selection and return command options will be defined in this 224 document and in approved extension documents; each option will be 225 enabled by a capability string (one capability may enable multiple 226 options), and a client MUST NOT send an option for which the server 227 has not advertised support. A server MUST respond to options it does 228 not recognize with a BAD response. The client SHOULD NOT specify any 229 option more than once, however if the client does this, the server 230 MUST act as if it received the option only once. The order in which 231 options are specified by the client is not significant. 233 In general, each selection option except for RECURSIVEMATCH will have 234 a corresponding return option. The REMOTE selection option is an 235 anomaly in this regard, and does not have a corresponding return 236 option. That is because it expands, rather than restricts, the set 237 of mailboxes that are returned. Future extensions to this 238 specification should keep parallelism in mind, and define a pair of 239 corresponding options. 241 This extension is identified by the capability string "LIST- 242 EXTENDED", and support for it is a prerequisite for any future 243 extensions that require specialized forms of the LIST command. Such 244 extensions MUST refer to this document and MUST add their function 245 through command options as described herein. Note that extensions 246 that don't require support for an extended LIST command, but use 247 extended LIST responses (see below), don't need to advertise the 248 "LIST-EXTENDED" capability string. 250 This extension also defines extensions to the LIST response, allowing 251 a series of extended fields at the end, a parenthesized list of 252 tagged data (also referred to as "extended data item"). The first 253 element of an extended field is a tag, which identifies type of the 254 data. Tags MUST be registered with IANA, as described in Section 9.5 255 of this document. An example of such extended set might be 257 tablecloth (("edge" "lacy") ("color" "red"))) (X-Sample "text")) 259 or... 261 tablecloth ("edge" "lacy")) (X-Sample "text" "more text")) 263 See the formal syntax, in Section 6, for the full syntactic details. 264 The server MUST NOT return any extended data item, unless the client 265 has expressed its ability to support extended LIST responses, for 266 example by using an extended LIST command. The server MAY return 267 data in the extended fields that was not directly solicited by the 268 client in the corresponding LIST command. For example, the client 269 can enable extra extended fields by using another IMAP extension that 270 make use of the extended LIST responses. The client MUST ignore all 271 extended fields it doesn't recognize. 273 The LIST-EXTENDED capability also defines several new mailbox 274 attributes. 276 The "\NonExistent" attribute indicates that a mailbox name does not 277 refer to an existing mailbox. Note that this attribute is not 278 meaningful by itself, as mailbox names that match the canonical LIST 279 pattern but don't exist must not be returned unless one of the two 280 conditions listed below is also satisfied: 282 a. the mailbox name also satisfies the selection criteria (for 283 example, it is subscribed and the "SUBSCRIBED" selection option 284 has been specified) 286 b. "RECURSIVEMATCH" has been specified, and the mailbox name has at 287 least one descendant mailbox name that does not match the LIST 288 pattern and does match the selection criteria. 290 In practice this means that the "\NonExistent" attribute is usually 291 returned with one or more of "\Subscribed", "\Remote", "\HasChildren" 292 or the CHILDINFO extended data item (see their description below). 294 The "\NonExistent" attribute implies "\NoSelect". The "\NonExistent" 295 attribute MUST be supported and MUST be accurately computed. 297 3.1 Initial list of selection options 299 The selection options defined in this specification are 301 SUBSCRIBED - causes the LIST command to list subscribed names, rather 302 than the existing mailboxes. This will often be a subset of the 303 actual mailboxes. It's also possible for this list to contain the 304 names of mailboxes that don't exist. In any case, the list MUST 305 include exactly those mailbox names that match the canonical list 306 pattern and are subscribed to. This option is intended to 307 supplement the LSUB command. Of particular note are the mailbox 308 attributes as returned by this option, compared with what is 309 returned by LSUB. With the latter, the attributes returned may 310 not reflect the actual attribute status on the mailbox name, and 311 the \NoSelect attribute has a second special meaning (it indicates 312 that this mailbox is not, itself, subscribed, but that it has 313 descendant mailboxes that are). With the SUBSCRIBED selection 314 option described here, the attributes are accurate, complete, and 315 have no special meanings. "LSUB" and "LIST (SUBSCRIBED)" are, 316 thus, not the same thing, and some servers must do significant 317 extra work to respond to "LIST (SUBSCRIBED)". Because of this, 318 clients SHOULD continue to use "LSUB" unless they specifically 319 want the additional information 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 for 378 all matching mailbox names. The "\Subscribed" attribute MUST be 379 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 | returned | 488 | | selection | that meets the | LIST-EXTENDED | 489 | | criteria | selection | attributes and | 490 | | | criteria | CHILDINFO | 491 +----------------+----------------+----------------+----------------+ 492 | no | no | no | no LIST | 493 | | | | response | 494 | | | | returned | 495 | | | | | 496 | yes | no | no | no LIST | 497 | | | | response | 498 | | | | returned | 499 | | | | | 500 | no | yes | no | (\NonExistent | 501 | | | | ) | 502 | | | | | 503 | yes | yes | no | () | 504 | | | | | 505 | no | no | yes | (\NonExistent) | 506 | | | | + CHILDINFO | 507 | | | | | 508 | yes | no | yes | () + CHILDINFO | 509 | | | | | 510 | no | yes | yes | (\NonExistent | 511 | | | | ) + | 512 | | | | CHILDINFO | 513 | | | | | 514 | yes | yes | yes | () + | 515 | | | | CHILDINFO | 516 +----------------+----------------+----------------+----------------+ 518 where is one or more attributes that correspond to the 519 selection criteria, for example for the SUBSCRIBED option the 520 is \Subscribed. 522 4. The CHILDREN return Option 524 The CHILDREN return option implements the Child Mailbox Extension, 525 originally proposed by Mike Gahrns and Raymond Cheng, of Microsoft 526 Corporation. Most of the information in this section is taken 527 directly from their original specification [CMbox]. The CHILDREN 528 return option is simply an indication that the client wants this 529 information; a server MAY provide it even if the option is not 530 specified. 532 Many IMAP4 [IMAP4] clients present to the user a hierarchical view of 533 the mailboxes that a user has access to. Rather than initially 534 presenting to the user the entire mailbox hierarchy, it is often 535 preferable to show to the user a collapsed outline list of the 536 mailbox hierarchy (particularly if there is a large number of 537 mailboxes). The user can then expand the collapsed outline hierarchy 538 as needed. It is common to include within the collapsed hierarchy a 539 visual clue (such as a ''+'') to indicate that there are child 540 mailboxes under a particular mailbox. When the visual clue is 541 clicked the hierarchy list is expanded to show the child mailboxes. 542 The CHILDREN return option provides a mechanism for a client to 543 efficiently determine if a particular mailbox has children, without 544 issuing a LIST "" * or a LIST "" % for each mailbox name. The 545 CHILDREN return option defines two new attributes that MUST be 546 returned within a LIST response: \HasChildren and \HasNoChildren. 547 While these attributes MAY be returned in response to any LIST 548 command, the CHILDREN return option is provided to indicate that the 549 client particularly wants this information. If the CHILDREN return 550 option is present, the server MUST return these attributes even if 551 their computation is expensive. 553 \HasChildren 555 The presence of this attribute indicates that the mailbox has 556 child mailboxes. A server SHOULD NOT set this attribute if 557 there are child mailboxes, and the user does not have 558 permissions to access any of them. In this case, \HasNoChildren 559 SHOULD be used. In many cases, however, a server may not be 560 able to efficiently compute whether a user has access to any 561 child mailbox. Note that even though the \HasChildren attribute 562 for a mailbox must be correct at the time of processing of the 563 mailbox, a client must be prepared to deal with a situation when 564 a mailbox is marked with the \HasChildren attribute, but no 565 child mailbox appears in the response to the LIST command. This 566 might happen, for example, due to children mailboxes beig 567 deleted or made inaccessible to the user (using access control) 568 by another client before the server is able to list them. 570 \HasNoChildren 572 The presence of this attribute indicates that the mailbox has NO 573 child mailboxes that are accessible to the currently 574 authenticated user. 576 It is an error for the server to return both a \HasChildren and a 577 \HasNoChildren attribute in the same LIST response. 579 Note: the \HasNoChildren attribute should not be confused with the 580 IMAP4 [IMAP4] defined attribute \NoInferiors which indicates that no 581 child mailboxes exist now and none can be created in the future. 583 5. Examples 585 1: The first example shows the complete local hierarchy that will be 586 used for the other examples. 588 C: A01 LIST "" "*" 589 S: * LIST (\Marked \NoInferiors) "/" "inbox" 590 S: * LIST () "/" "Fruit" 591 S: * LIST () "/" "Fruit/Apple" 592 S: * LIST () "/" "Fruit/Banana" 593 S: * LIST () "/" "Tofu" 594 S: * LIST () "/" "Vegetable" 595 S: * LIST () "/" "Vegetable/Broccoli" 596 S: * LIST () "/" "Vegetable/Corn" 597 S: A01 OK done 599 2: In the next example we'll see the subscribed mailboxes. This is 600 similar to, but not equivalent with, . Note that 601 the mailbox called "Fruit/Peach" is subscribed to, but does not 602 actually exist (perhaps it was deleted while still subscribed). 603 The "Fruit" mailbox is not subscribed to, but it has two 604 subscribed children. The "Vegetable" mailbox is subscribed and 605 has two children, one of them is subscribed as well. 607 C: A02 LIST (SUBSCRIBED) "" "*" 608 S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox" 609 S: * LIST (\Subscribed) "/" "Fruit/Banana" 610 S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach" 611 S: * LIST (\Subscribed) "/" "Vegetable" 612 S: * LIST (\Subscribed) "/" "Vegetable/Broccoli" 613 S: A02 OK done 615 3: The next example shows the use of the CHILDREN option. The 616 client, without having to list the second level of hierarchy, now 617 knows which of the top-level mailboxes have submailboxes 618 (children) and which do not. Note that it's not necessary for 619 the server to return the \HasNoChildren attribute for the inbox, 620 because the \NoInferiors attribute already implies that, and has 621 a stronger meaning. 623 C: A03 LIST () "" "%" RETURN (CHILDREN) 624 S: * LIST (\Marked \NoInferiors) "/" "inbox" 625 S: * LIST (\HasChildren) "/" "Fruit" 626 S: * LIST (\HasNoChildren) "/" "Tofu" 627 S: * LIST (\HasChildren) "/" "Vegetable" 628 S: A03 OK done 630 4: In this example we see more mailboxes that reside on another 631 server. This is similar to the command . 633 C: A04 LIST (REMOTE) "" "%" RETURN (CHILDREN) 634 S: * LIST (\Marked \NoInferiors) "/" "inbox" 635 S: * LIST (\HasChildren) "/" "Fruit" 636 S: * LIST (\HasNoChildren) "/" "Tofu" 637 S: * LIST (\HasChildren) "/" "Vegetable" 638 S: * LIST (\Remote) "/" "Bread" 639 S: * LIST (\HasChildren \Remote) "/" "Meat" 640 S: A04 OK done 642 5: The following example also requests the server to include 643 mailboxes that reside on another server. The server returns 644 information about all mailboxes which are subscribed. This is 645 similar to the command . We also see the use of 646 two selection options. 648 C: A05 LIST (REMOTE SUBSCRIBED) "" "*" 649 S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox" 650 S: * LIST (\Subscribed) "/" "Fruit/Banana" 651 S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach" 652 S: * LIST (\Subscribed) "/" "Vegetable" 653 S: * LIST (\Subscribed) "/" "Vegetable/Broccoli" 654 S: * LIST (\Remote \Subscribed) "/" "Bread" 655 S: A05 OK done 657 6: The following example requests the server to include mailboxes 658 that reside on another server. The server is asked to return 659 subscription information for all returned mailboxes. This is 660 different from the example above. 662 Note that the output of this command is not a superset of the 663 output in the previous example, as it doesn't include LIST 664 response for the non-existent "Fruit/Peach". 666 C: A06 LIST (REMOTE) "" "*" RETURN (SUBSCRIBED) 667 S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox" 668 S: * LIST () "/" "Fruit" 669 S: * LIST () "/" "Fruit/Apple" 670 S: * LIST (\Subscribed) "/" "Fruit/Banana" 671 S: * LIST () "/" "Tofu" 672 S: * LIST (\Subscribed) "/" "Vegetable" 673 S: * LIST (\Subscribed) "/" "Vegetable/Broccoli" 674 S: * LIST () "/" "Vegetable/Corn" 675 S: * LIST (\Remote \Subscribed) "/" "Bread" 676 S: * LIST (\Remote) "/" "Meat" 677 S: A06 OK done 679 7: In the following example the client has specified multiple 680 mailbox patterns. Note that this example does not use the 681 mailbox hierarchy used in the previous examples. 683 C: BBB LIST "" ("INBOX" "Drafts" "Sent/%") 684 S: * LIST () "/" "INBOX" 685 S: * LIST (\NoInferiors) "/" "Drafts" 686 S: * LIST () "/" "Sent/March2004" 687 S: * LIST (\Marked) "/" "Sent/December2003" 688 S: * LIST () "/" "Sent/August2004" 689 S: BBB OK done 691 8: The following example demonstrates the difference between the 692 \HasChildren attribute and the CHILDINFO extended data item. 694 Let's assume there is the following hierarchy: 696 C: C01 LIST "" "*" 697 S: * LIST (\Marked \NoInferiors) "/" "inbox" 698 S: * LIST () "/" "Foo" 699 S: * LIST () "/" "Foo/Bar" 700 S: * LIST () "/" "Foo/Baz" 701 S: * LIST () "/" "Moo" 702 S: C01 OK done 704 If the client asks RETURN (CHILDREN) it will get this: 706 C: CA3 LIST "" "%" RETURN (CHILDREN) 707 S: * LIST (\Marked \NoInferiors) "/" "inbox" 708 S: * LIST (\HasChildren) "/" "Foo" 709 S: * LIST (\HasNoChildren) "/" "Moo" 710 S: CA3 OK done 711 A) Let's also assume that the mailbox "Foo/Baz" is the only 712 subscribed mailbox. Then we get this result: 714 C: C02 LIST (SUBSCRIBED) "" "*" 715 S: * LIST (\Subscribed) "/" "Foo/Baz" 716 S: C02 OK done 718 Now, if the client issues , the server 719 will return no mailboxes (as the mailboxes "Moo", "Foo" and 720 "Inbox" are NOT subscribed). However, if the client issues this: 722 C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" 723 S: * LIST () "/" "Foo" ("CHILDINFO" ("SUBSCRIBED")) 724 S: C04 OK done 726 i.e. the mailbox "Foo" is not subscribed, but it has a child that 727 is. 729 A1) If the mailbox "Foo" had also been subscribed, the last 730 command would return this: 732 C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" 733 S: * LIST (\Subscribed) "/" "Foo" ("CHILDINFO" ("SUBSCRIBED")) 734 S: C04 OK done 736 or even this: 738 C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" 739 S: * LIST (\Subscribed \HasChildren) "/" "Foo" ("CHILDINFO" 740 ("SUBSCRIBED")) 741 S: C04 OK done 743 A2) If we assume instead that the mailbox "Foo" is not part of 744 the original hierarchy and is not subscribed, the last command 745 will give this result: 747 C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" 748 S: * LIST (\NonExistent) "/" "Foo" ("CHILDINFO" ("SUBSCRIBED")) 749 S: C04 OK done 751 B) Now, let's assume that no mailbox is subscribed. In this case 752 the command will return 753 no responses, as there are no subscribed children (even though 754 "Foo" has children). 756 C) And finally, suppose that only the mailboxes "Foo" and "Moo" 757 are subscribed. In that case we see this result: 759 C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" RETURN (CHILDREN) 760 S: * LIST (\HasChildren \Subscribed) "/" "Foo" 761 S: * LIST (\HasNoChildren \Subscribed) "/" "Moo" 762 S: C04 OK done 764 (which means that the mailbox "Foo" has children, but none of 765 them is subscribed). 767 9: The following example demonstrates that the CHILDINFO extended 768 data item is returned whether children mailboxes match the 769 canonical LIST pattern or not. 771 Let's assume there is the following hierarchy: 773 C: D01 LIST "" "*" 774 S: * LIST (\Marked \NoInferiors) "/" "inbox" 775 S: * LIST () "/" "foo2" 776 S: * LIST () "/" "foo2/bar1" 777 S: * LIST () "/" "foo2/bar2" 778 S: * LIST () "/" "baz2" 779 S: * LIST () "/" "baz2/bar2" 780 S: * LIST () "/" "baz2/bar22" 781 S: * LIST () "/" "baz2/bar222" 782 S: * LIST () "/" "eps2" 783 S: * LIST () "/" "eps2/mamba" 784 S: * LIST () "/" "qux2/bar2" 785 S: D01 OK done 787 And that the following mailboxes are subscribed: 789 C: D02 LIST (SUBSCRIBED) "" "*" 790 S: * LIST (\Subscribed) "/" "foo2/bar1" 791 S: * LIST (\Subscribed) "/" "foo2/bar2" 792 S: * LIST (\Subscribed) "/" "baz2/bar2" 793 S: * LIST (\Subscribed) "/" "baz2/bar22" 794 S: * LIST (\Subscribed) "/" "baz2/bar222" 795 S: * LIST (\Subscribed) "/" "eps2" 796 S: * LIST (\Subscribed) "/" "eps2/mamba" 797 S: * LIST (\Subscribed) "/" "qux2/bar2" 798 S: D02 OK done 800 The client issues the following command first: 802 C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*2" 803 S: * LIST () "/" "foo2" ("CHILDINFO" ("SUBSCRIBED")) 804 S: * LIST (\Subscribed) "/" "foo2/bar2" 805 S: * LIST () "/" "baz2" ("CHILDINFO" ("SUBSCRIBED")) 806 S: * LIST (\Subscribed) "/" "baz2/bar2" 807 S: * LIST (\Subscribed) "/" "baz2/bar22" 808 S: * LIST (\Subscribed) "/" "baz2/bar222" 809 S: * LIST (\Subscribed) "/" "eps2" ("CHILDINFO" ("SUBSCRIBED")) 810 S: * LIST (\Subscribed) "/" "qux2/bar2" 811 S: D03 OK done 813 and the server may also include 815 S: * LIST (\NonExistent) "/" "qux2" ("CHILDINFO" ("SUBSCRIBED")) 817 The CHILDINFO extended data item is returned for mailboxes 818 "foo2", "baz2" and "eps2", because all of them have subscribed 819 children, even though for the mailbox "foo2" only one of the two 820 subscribed children match the pattern, for the mailbox "baz2" all 821 the subscribed children match the pattern and for the mailbox 822 "eps2" none of the subscribed children matches the pattern. 824 Note that if the client issues 826 C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*" 827 S: * LIST () "/" "foo2" ("CHILDINFO" ("SUBSCRIBED")) 828 S: * LIST (\Subscribed) "/" "foo2/bar1" 829 S: * LIST (\Subscribed) "/" "foo2/bar2" 830 S: * LIST () "/" "baz2" ("CHILDINFO" ("SUBSCRIBED")) 831 S: * LIST (\Subscribed) "/" "baz2/bar2" 832 S: * LIST (\Subscribed) "/" "baz2/bar22" 833 S: * LIST (\Subscribed) "/" "baz2/bar222" 834 S: * LIST (\Subscribed) "/" "eps2" ("CHILDINFO" ("SUBSCRIBED")) 835 S: * LIST (\Subscribed) "/" "eps2/mamba" 836 S: * LIST (\Subscribed) "/" "qux2/bar2" 837 S: D03 OK done 839 the LIST responses for mailboxes "foo2", "baz2" and "eps2" still 840 have the CHILDINFO extended data item, even though this 841 information is redundant and the client can determine it by 842 itself. 844 10: The following example shows usage of multiple mailbox patterns. 845 It also demonstrates that the presence of the CHILDINFO extended 846 data item doesn't necessarily imply \HasChildren. 848 C: a1 LIST "" ("foo" "foo/*") 849 S: * LIST () "/" foo 850 S: a1 OK done 852 C: a2 LIST (SUBSCRIBED) "" "foo/*" 853 S: * LIST (\Subscribed \NonExistent) "/" foo/bar 854 S: a2 OK done 856 C: a3 LIST (SUBSCRIBED RECURSIVEMATCH) "" foo RETURN (CHILDREN) 857 S: * LIST (\HasNoChildren) "/" foo ("CHILDINFO" ("SUBSCRIBED")) 858 S: a3 OK done 860 11: The following example shows how a server that supports missing 861 mailbox hierarchy elements can signal to a client that didn't 862 specify the RECURSIVEMATH selection option that there is a child 863 mailbox that matches the selection criteria. 865 C: a1 LIST (REMOTE) "" * 866 S: * LIST () "/" music/rock 867 S: * LIST (\Remote) "/" also/jazz 868 S: a1 OK done 870 C: a2 LIST () "" % 871 S: * LIST (\NonExistent \HasChildren) "/" music 872 S: a2 OK done 874 C: a3 LIST (REMOTE) "" % 875 S: * LIST (\NonExistent \HasChildren) "/" music 876 S: * LIST (\NonExistent \HasChildren) "/" also 877 S: a3 OK done 879 6. Formal Syntax 881 The following syntax specification uses the augmented Backus-Naur 882 Form (BNF) as described in [ABNF]. Terms not defined here are taken 883 from [IMAP4]. In particular, note that the version of "mailbox-list" 884 below, which defines the payload of the LIST response, updates the 885 version defined in the IMAP specification. It is pointed to by 886 "mailbox-data", which is defined in [IMAP4]. 888 "vendor-token" is defined in [ACAP]. Note that this normative 889 reference to ACAP will be an issue in moving this spec forward, since 890 it introduces a dependency on ACAP. The definitions of "vendor- 891 token" and of the IANA registry must eventually go somewhere else, in 892 a document that can be moved forward on the standards track 893 independently of ACAP. 895 childinfo-extended-item = "CHILDINFO" SP "(" 896 list-select-base-opt-quoted 897 *(SP list-select-base-opt-quoted) ")" 898 ; Extended data item (mbox-list-extended-item) ; returned 899 when the RECURSIVEMATCH 900 ; selection option is specified. 901 ; Note 1: the CHILDINFO tag can be returned 902 ; with and without surrounding quotes, as per 903 ; mbox-list-extended-item-tag production. 904 ; Note 2: The selection options are always returned 905 quoted, 906 ; unlike their specification in the extended LIST 907 ; command. 909 child-mbox-flag = "\HasChildren" / "\HasNoChildren" 910 ; attributes for CHILDREN return option, at most one 911 ; possible per LIST response 913 eitem-standard-tag = atom 914 ; a tag for extended list data defined in a Standard 915 ; Track or Experimental RFC. 917 eitem-vendor-tag = vendor-tag 918 ; a vendor specific tag for extended list data 920 list = "LIST" [SP list-select-opts] SP mailbox SP mbox-or-pat 921 [SP list-return-opts] 923 list-return-opts = "RETURN" SP 924 "(" [return-option *(SP return-option)] ")" 925 ; list return options, e.g. CHILDREN 927 list-select-base-opt = "SUBSCRIBED" / option-extension 928 ; options that can be used by themselves 930 list-select-base-opt-quoted = <"> list-select-base-opt <"> 932 list-select-independent-opt = "REMOTE" / option-extension 933 ; options that do not syntactically interact with 934 ; other options 936 list-select-mod-opt = "RECURSIVEMATCH" / option-extension 937 ; options that require a list-select-base-opt 938 ; to also be present 940 list-select-opt = list-select-base-opt / list-select-independent-opt 941 / list-select-mod-opt 942 ; An option registration template is described in 943 ; Section 9.3 of this document. 945 list-select-opts = "(" [ 946 (*(list-select-opt SP) list-select-base-opt 947 *(SP list-select-opt)) 948 / (list-select-independent-opt 949 *(SP list-select-independent-opt)) 950 ] ")" 951 ; Any number of options may be in any order. 952 ; If a list-select-mod-opt appears, then a 953 ; list-select-base-opt must also appear. 954 ; This allows these: 955 ; () 956 ; (REMOTE) 957 ; (SUBSCRIBED) 958 ; (SUBSCRIBED REMOTE) 959 ; (SUBSCRIBED RECURSIVEMATCH) 960 ; (SUBSCRIBED REMOTE RECURSIVEMATCH) 961 ; But does NOT allow these: 962 ; (RECURSIVEMATCH) 963 ; (REMOTE RECURSIVEMATCH) 965 mailbox-list = "(" [mbx-list-flags] ")" SP 966 (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox 967 [SP mbox-list-extended] 968 ; This is the list information pointed to by the ABNF 969 item ; "mailbox-data", which is defined in [IMAP4] 971 mbox-list-extended = "(" [mbox-list-extended-item 972 *(SP mbox-list-extended-item)] ")" 974 mbox-list-extended-item = mbox-list-extended-item-tag SP tagged-ext- 975 val 977 mbox-list-extended-item-tag = astring 978 ; The content MUST conform to either "eitem-vendor-tag" 979 ; or "eitem-standard-tag" ABNF productions. 980 ; A tag registration template is described in this 981 ; document in Section 9.5. 983 mbox-list-oflag = child-mbox-flag / "\NonExistent" / "\Subscribed" / 984 "\Remote" 986 mbox-or-pat = list-mailbox / patterns 988 option-extension = (option-standard-tag / option-vendor-tag) 989 [SP option-value] 991 option-standard-tag = atom 992 ; an option defined in a Standards Track or 993 ; Experimental RFC 995 option-val-comp = astring / 996 option-val-comp *(SP option-val-comp) / 997 "(" option-val-comp ")" 999 option-value = "(" option-val-comp ")" 1001 option-vendor-tag = vendor-token "-" atom 1002 ; a vendor specific option, non-standard 1004 patterns = "(" list-mailbox *(SP list-mailbox) ")" 1006 return-option = "SUBSCRIBED" / "CHILDREN" / option-extension 1008 tagged-ext-comp = astring / 1010 tagged-ext-comp *(SP tagged-ext-comp) / 1012 "(" tagged-ext-comp ")" 1014 ;; Extensions that follow this general 1016 ;; syntax should use nstring instead of 1018 ;; astring when appropriate in the context 1020 ;; of the extension. 1022 ;; Note that a message set or a "number" 1024 ;; can always be represented as an "atom". 1026 ;; An URL should be represented as 1028 ;; a "quoted" string. 1030 tagged-ext-simple = sequence-set / number 1032 tagged-ext-val = tagged-ext-simple / 1034 "(" [tagged-ext-comp] ")" 1036 7. Internationalization Considerations 1038 The LIST command selection option types defined in this specification 1039 involve simple tests of mailbox properties. However, future 1040 extensions to LIST-EXTENDED may define selection options that do more 1041 sophisticated tests. In the case of a test that requires matching 1042 text, in the presence of the COMPARATOR [I18N] extension, the active 1043 comparator must be used to do comparisons. Such LIST-EXTENDED 1044 extensions MUST indicate in their specification the interaction with 1045 the COMPARATOR [I18N] extension. 1047 8. Security Considerations 1049 This document describes syntactic changes to the specification of the 1050 IMAP4 commands LIST, LSUB, RLIST, and RLSUB, and the modified LIST 1051 command has the same security considerations as those commands. They 1052 are described in [IMAP4] and [MBRef]. 1054 The Child Mailbox Extension provides a client a more efficient means 1055 of determining whether a particular mailbox has children. If a 1056 mailbox has children, but the currently authenticated user does not 1057 have access to any of them, the server SHOULD respond with a 1058 \HasNoChildren attribute. In many cases, however, a server may not 1059 be able to efficiently compute whether a user has access to any child 1060 mailbox. If such a server responds with a \HasChildren attribute, 1061 when in fact the currently authenticated user does not have access to 1062 any child mailboxes, potentially more information is conveyed about 1063 the mailbox than intended. In most situations this will not be a 1064 security concern, because if information regarding whether a mailbox 1065 has children is considered sensitive, a user would not be granted 1066 access to that mailbox in the first place. 1068 The CHILDINFO extended data item has the same security considerations 1069 as the \HasChildren attribute described above. 1071 9. IANA Considerations 1073 9.1 Guidelines for IANA 1075 It is requested that IANA creates two new registries for LIST- 1076 EXTENDED options and LIST-EXTENDED response data. The templates and 1077 the initial registrations are detailed below. 1079 9.2 Registration procedure and Change control 1081 Registration of a LIST-EXTENDED option is done by filling in the 1082 template in Section 9.3 and sending it via electronic mail to 1083 iana@iana.org. Registration of a LIST-EXTENDED extended data item is 1084 done by filling in the template in Section 9.5 and sending it via 1085 electronic mail to iana@iana.org. IANA has the right to reject 1086 obviously bogus registrations, but will perform no review of claims 1087 made in the registration form. 1089 A LIST-EXTENDED option/extended data item name that starts with "V-" 1090 is reserved for vendor specific options/extended data items. All 1091 options, whether they are vendor specific or global, should be 1092 registered with IANA. If a LIST-EXTENDED extended data item is 1093 returned as a result of requesting a particular LIST-EXTENDED option, 1094 the name of the option SHOULD be used as the name of the LIST- 1095 EXTENDED extended data item. 1097 Each vendor specific options/extended data item MUST start with their 1098 vendor-token ("vendor prefix"). The vendor-token MUST be registered 1099 with IANA, using the [ACAP] vendor subtree registry. 1101 Standard LIST-EXTENDED option/extended data item names are case 1102 insensitive. If the vendor prefix is omitted from a vendor specific 1103 LIST-EXTENDED option/extended data item name, the rest is case 1104 insensitive. The vendor prefix itself is not case-sensitive, as it 1105 might contain non-ASCII characters. 1107 While the registration procedures do not require it, authors of LIST- 1108 EXTENDED options/extended data items are encouraged to seek community 1109 review and comment whenever that is feasible. Authors may seek 1110 community review by posting a specification of their proposed 1111 mechanism as an Internet- Draft. LIST-EXTENDED options/extended data 1112 items intended for widespread use should be standardized through the 1113 normal IETF process, when appropriate. 1115 Comments on registered LIST-EXTENDED options/extended response data 1116 should first be sent to the "owner" of the mechanism and/or to the 1117 IMAPEXT WG mailing list. Submitters of comments may, after a 1118 reasonable attempt to contact the owner, request IANA to attach their 1119 comment to the registration itself. If IANA approves of this, the 1120 comment will be made accessible in conjunction with the registration 1121 LIST-EXTENDED options/ extended response data itself. 1123 Once a LIST-EXTENDED registration has been published by IANA, the 1124 author may request a change to its definition. The change request 1125 follows the same procedure as the registration request. 1127 The owner of a LIST-EXTENDED registration may pass responsibility for 1128 the registered option/extended data item to another person or agency 1129 by informing IANA; this can be done without discussion or review. 1131 The IESG may reassign responsibility for a LIST-EXTENDED option/ 1132 extended data item. The most common case of this will be to enable 1133 changes to be made to mechanisms where the author of the registration 1134 has died, moved out of contact or is otherwise unable to make changes 1135 that are important to the community. 1137 LIST-EXTENDED registrations may not be deleted; mechanisms which are 1138 no longer believed appropriate for use can be declared OBSOLETE by a 1139 change to their "intended use" field; such LIST-EXTENDED options/ 1140 extended data items will be clearly marked in the lists published by 1141 IANA. 1143 The IESG is considered to be the owner of all LIST-EXTENDED options/ 1144 extended data items which are on the IETF standards track. 1146 9.3 Registration template for LIST-EXTENDED options 1148 To: iana@iana.org 1149 Subject: Registration of LIST-EXTENDED option X 1151 LIST-EXTENDED option name: 1153 LIST-EXTENDED option type: (One of SELECTION or RETURN) 1155 Implied return options(s), if the option type is SELECTION: (zero or 1156 more) 1158 LIST-EXTENDED option description: 1160 Published specification (optional, recommended): 1162 Security considerations: 1164 Intended usage: 1165 (One of COMMON, LIMITED USE or OBSOLETE) 1166 Person and email address to contact for further information: 1168 Owner/Change controller: 1170 (Any other information that the author deems interesting may be added 1171 below this line.) 1173 9.4 Initial LIST-EXTENDED option registrations 1175 It is requested that the LIST-EXTENDED option registry be populated 1176 with the following entries: 1178 1. To: iana@iana.org 1179 Subject: Registration of LIST-EXTENDED option SUBSCRIBED 1181 LIST-EXTENDED option name: SUBSCRIBED 1183 LIST-EXTENDED option type: SELECTION 1185 Implied return options(s): SUBSCRIBED 1187 LIST-EXTENDED option description: Causes the LIST command to list 1188 subscribed mailboxes, rather than the actual mailboxes. 1190 Published specification : XXXX, Section 3. 1192 Security considerations: XXXX, Section 8. 1194 Intended usage: COMMON 1196 Person and email address to contact for further information: 1197 Alexey Melnikov 1199 Owner/Change controller: iesg@ietf.org 1201 2. To: iana@iana.org 1202 Subject: Registration of LIST-EXTENDED option REMOTE 1204 LIST-EXTENDED option name: REMOTE 1206 LIST-EXTENDED option type: SELECTION 1208 Implied return options(s): (none) 1210 LIST-EXTENDED option description: causes the LIST command to 1211 return remote mailboxes as well as local ones, as described in 1212 RFC 2193. 1214 Published specification : XXXX, Section 3. 1216 Security considerations: XXXX, Section 8. 1218 Intended usage: COMMON 1220 Person and email address to contact for further information: 1221 Alexey Melnikov 1223 Owner/Change controller: iesg@ietf.org 1225 3. To: iana@iana.org 1226 Subject: Registration of LIST-EXTENDED option SUBSCRIBED 1228 LIST-EXTENDED option name: SUBSCRIBED 1230 LIST-EXTENDED option type: RETURN 1232 LIST-EXTENDED option description: Causes the LIST command to 1233 return subscription state. 1235 Published specification : XXXX, Section 3. 1237 Security considerations: XXXX, Section 8. 1239 Intended usage: COMMON 1241 Person and email address to contact for further information: 1242 Alexey Melnikov 1244 Owner/Change controller: iesg@ietf.org 1246 4. To: iana@iana.org 1247 Subject: Registration of LIST-EXTENDED option RECURSIVEMATCH 1249 LIST-EXTENDED option name: RECURSIVEMATCH 1251 LIST-EXTENDED option type: SELECTION 1253 Implied return options(s): (none) 1255 LIST-EXTENDED option description: Requests that CHILDINFO 1256 extended data item (childinfo-extended-item) is to be returned. 1258 Published specification : XXXX, Section 3. 1260 Security considerations: XXXX, Section 8. 1262 Intended usage: COMMON 1264 Person and email address to contact for further information: 1265 Alexey Melnikov 1267 Owner/Change controller: iesg@ietf.org 1269 5. To: iana@iana.org 1270 Subject: Registration of LIST-EXTENDED option CHILDREN 1272 LIST-EXTENDED option name: CHILDREN 1274 LIST-EXTENDED option type: RETURN 1276 LIST-EXTENDED option description: Requests mailbox child 1277 information. 1279 Published specification : XXXX, Section 3 and Section 4. 1281 Security considerations: XXXX, Section 8. 1283 Intended usage: COMMON 1285 Person and email address to contact for further information: 1286 Alexey Melnikov 1288 Owner/Change controller: iesg@ietf.org 1290 9.5 Registration template for LIST-EXTENDED extended data item 1292 To: iana@iana.org 1293 Subject: Registration of X LIST-EXTENDED extended data item 1295 LIST-EXTENDED extended data item tag: 1297 LIST-EXTENDED extended data item description: 1299 Which LIST-EXTENDED option(s) (and their types) causes this extended 1300 data item to be returned (if any): 1302 Published specification (optional, recommended): 1304 Security considerations: 1306 Intended usage: 1307 (One of COMMON, LIMITED USE or OBSOLETE) 1309 Person and email address to contact for further information: 1311 Owner/Change controller: 1313 (Any other information that the author deems interesting may be added 1314 below this line.) 1316 9.6 Initial LIST-EXTENDED extended data item registrations 1318 It is requested that the LIST-EXTENDED extended data item registry be 1319 populated with the following entries: 1321 1. To: iana@iana.org 1322 Subject: Registration of CHILDINFO LIST-EXTENDED extended data 1323 item 1325 LIST-EXTENDED extended data item tag: CHILDINFO 1327 LIST-EXTENDED extended data item description: The CHILDINFO 1328 extended data item describes the selection criteria that has 1329 caused it to be returned and indicates that the mailbox has one 1330 or more child mailbox that match the selection criteria. 1332 Which LIST-EXTENDED option(s) (and their types) causes this 1333 extended data item to be returned (if any): RECURSIVEMATCH 1334 selection option 1336 Published specification : XXXX, Section 3.5. 1338 Security considerations: XXXX, Section 8. 1340 Intended usage: COMMON 1342 Person and email address to contact for further information: 1343 Alexey Melnikov 1345 Owner/Change controller: iesg@ietf.org 1347 10. Acknowledgements 1349 Mike Gahrns and Raymond Cheng of Microsoft Corporation originally 1350 devised the Child Mailbox Extension and proposed it in 1997; the 1351 idea, as well as most of the text in Section 4, is theirs. 1353 This document is the result of discussions on the IMAP4 and IMAPEXT 1354 mailing lists and is meant to reflect consensus of those groups. In 1355 particular, Mark Crispin, Philip Guenther, Cyrus Daboo, Timo 1356 Sirainen, Ken Murchison, Rob Siemborski, Steve Hole, Arnt 1357 Gulbrandsen, Larry Greenfield, Dave Cridland and Pete Maclean were 1358 active participants in those discussions or made suggestions to this 1359 document. 1361 11. References 1363 11.1 Normative References 1365 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1366 Specifications: ABNF", RFC 4234, October 2005. 1368 [ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration 1369 Access Protocol", RFC 2244, November 1997. 1371 [I18N] Newman, C. and A. Gulbrandsen, "ACAP -- Application 1372 Configuration Access Protocol", draft-ietf-imapext-i18n 1373 (work in progress), February 2006. 1375 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 1376 4rev1", RFC 3501, March 2003. 1378 [Kwds] Bradner, S., "Key words for use in RFCs to Indicate 1379 Requirement Levels", RFC 2119, March 1997. 1381 [MBRef] Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193, 1382 September 1997. 1384 11.2 informative References 1386 [CMbox] Gahrns, M. and R. Cheng, "", RFC 3348, July 2002. 1388 Authors' Addresses 1390 Barry Leiba 1391 IBM T.J. Watson Research Center 1392 19 Skyline Drive 1393 Hawthorne, NY 10532 1394 US 1396 Phone: +1 914 784 7941 1397 Email: leiba@watson.ibm.com 1398 Alexey Melnikov 1399 Isode Limited 1400 5 Castle Business Village 1401 36 Station Road 1402 Hampton, Middlesex TW12 2BX 1403 UK 1405 Email: Alexey.Melnikov@isode.com 1406 URI: http://www.melnikov.ca/ 1408 Intellectual Property Statement 1410 The IETF takes no position regarding the validity or scope of any 1411 Intellectual Property Rights or other rights that might be claimed to 1412 pertain to the implementation or use of the technology described in 1413 this document or the extent to which any license under such rights 1414 might or might not be available; nor does it represent that it has 1415 made any independent effort to identify any such rights. Information 1416 on the procedures with respect to rights in RFC documents can be 1417 found in BCP 78 and BCP 79. 1419 Copies of IPR disclosures made to the IETF Secretariat and any 1420 assurances of licenses to be made available, or the result of an 1421 attempt made to obtain a general license or permission for the use of 1422 such proprietary rights by implementers or users of this 1423 specification can be obtained from the IETF on-line IPR repository at 1424 http://www.ietf.org/ipr. 1426 The IETF invites any interested party to bring to its attention any 1427 copyrights, patents or patent applications, or other proprietary 1428 rights that may cover technology that may be required to implement 1429 this standard. Please address the information to the IETF at 1430 ietf-ipr@ietf.org. 1432 Disclaimer of Validity 1434 This document and the information contained herein are provided on an 1435 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1436 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1437 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1438 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1439 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1440 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1442 Copyright Statement 1444 Copyright (C) The Internet Society (2006). This document is subject 1445 to the rights, licenses and restrictions contained in BCP 78, and 1446 except as set forth therein, the authors retain all their rights. 1448 Acknowledgment 1450 Funding for the RFC Editor function is currently provided by the 1451 Internet Society.