idnits 2.17.1 draft-ietf-imapext-list-extensions-15.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 1485. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1462. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1469. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1475. ** 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 == 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 (October 2005) is 6768 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 3348 (ref. 'CMbox') (Obsoleted by RFC 5258) ** Obsolete normative reference: RFC 3501 (ref. 'IMAP4') (Obsoleted by RFC 9051) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 8 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: April 4, 2006 October 2005 8 IMAP4 LIST Command Extensions 9 draft-ietf-imapext-list-extensions-15 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 April 4, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 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 . . . . . . . . . . . . . . 3 67 2. Introduction and overview . . . . . . . . . . . . . . . . . . 4 69 3. Extended LIST Command . . . . . . . . . . . . . . . . . . . . 6 70 3.1 General principles for returning LIST responses . . . . . . . 10 71 3.2 Additional requirements on LIST-EXTENDED clients . . . . . . . 11 72 3.3 CHILDINFO extended data item . . . . . . . . . . . . . . . . . 11 74 4. The CHILDREN return Option . . . . . . . . . . . . . . . . . . 14 76 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 26 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 83 8.1 Guidelines for IANA . . . . . . . . . . . . . . . . . . . . . 31 84 8.2 Registration procedure and Change control . . . . . . . . . . 31 85 8.3 Registration template for LIST-EXTENDED options . . . . . . . 32 86 8.4 Initial LIST-EXTENDED option registrations . . . . . . . . . . 33 87 8.5 Registration template for LIST-EXTENDED extended data item . . 35 88 8.6 Initial LIST-EXTENDED extended data item registrations . . . . 36 90 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37 92 10. Normative References . . . . . . . . . . . . . . . . . . . . . 37 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 37 96 Intellectual Property and Copyright Statements . . . . . . . . 39 98 1. Conventions used in this document 100 In examples, "C:" indicates lines sent by a client that is connected 101 to a server. "S:" indicates lines sent by the server to the client. 103 The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are 104 used in this document as specified in RFC 2119 [Kwds]. 106 The term "canonical LIST pattern" refers to the canonical pattern 107 constructed internally by the server from the reference and mailbox 108 name arguments (Section 6.3.8 of [IMAP4]). The [IMAP4] LIST command 109 returns only mailboxes that match the canonical LIST pattern. 111 Other terms are introduced where they are referenced for the first 112 time. 114 2. Introduction and overview 116 The LIST command is extended by amending the syntax to allow options 117 and multiple patterns to be specified. The list of options replaces 118 the several commands that are currently used to mix and match the 119 information requested. The new syntax is backward- compatible, with 120 no ambiguity: the new syntax is being used if one of the following 121 conditions is true: 123 1. if the first word after the command name begins with a 124 parenthesis ("LIST selection options"); 126 2. if the second word after the command name begins with a 127 parenthesis ("multiple mailbox patterns"); 129 3. if the LIST command has more than 2 parameters ("LIST return 130 options"); 132 Otherwise the original syntax is used. 134 By adding options to the LIST command, we are announcing the intent 135 to phase out and eventually to deprecate the RLIST and RLSUB commands 136 described in [MBRef]. We are also defining the mechanism to request 137 extended mailbox information, such as is described in the "Child 138 Mailbox Extension" [CMbox]. The base LSUB command is not deprecated 139 by this extension; rather, this extension adds a way to obtain 140 subscription information with more options, with those server 141 implementations that support it. Clients that simply need a list of 142 subscribed mailboxes, as provided by the LSUB command, SHOULD 143 continue to use that command. 145 This document defines an IMAP4 extension that is identified by the 146 capability string "LIST-EXTENDED". The LIST-EXTENDED extension makes 147 the following changes to the IMAP4 protocol, which are described in 148 more detail in Section 3 and Section 4: 150 a. defines new syntax for LIST command options. 152 b. extends LIST to allow for multiple mailbox patterns. 154 c. adds LIST command selection options: SUBSCRIBED, REMOTE and 155 RECURSIVEMATCH. 157 d. adds LIST command return options: SUBSCRIBED and CHILDREN. 159 e. adds new mailbox attributes: "\NonExistent", "\Subscribed", 160 "\Remote", "\HasChildren" and "\HasNoChildren". 162 f. adds CHILDINFO extended data item. 164 3. Extended LIST Command 166 This extension updates the syntax of the LIST command to allow for 167 multiple mailbox patterns to be specified, if they are enclosed in 168 parentheses. A mailbox name matches a list of mailbox patterns if it 169 matches at least one mailbox pattern. If a mailbox name matches 170 multiple mailbox patterns from the list, the server SHOULD return 171 only a single LIST response. 173 Note that the non-extended LIST command is required to treat an empty 174 ("" string) mailbox name argument as a special request to return the 175 hierarchy delimiter and the root name of the name given in the 176 reference parameter (as per [IMAP4]). However ANY extended LIST 177 command (extended in any of 3 ways specified in Section 2, or any 178 combination of therof) MUST NOT treat the empty mailbox name as such 179 special request and any regular processing described in this document 180 applies. In particular, if an extended LIST command has multiple 181 mailbox names and one (or more) of them is the empty string, the 182 empty string MUST be ignored for the purpose of matching. 184 Some servers might restrict which patterns are allowed in a LIST 185 command. If a server doesn't accept a particular pattern, it MUST 186 silently ignore it. 188 The LIST command syntax is also extended in two additional ways: by 189 adding a parenthesized list of command options between the command 190 name and the reference name (LIST selection options) and an optional 191 list of options at the end that control what kind of information 192 should be returned (LIST return options). See the formal syntax in 193 Section 6 for specific details. 195 A LIST selection option tells the server which mailbox names should 196 be selected by the LIST operation. The server should return 197 information about all mailbox names that match any of the "canonical 198 LIST pattern" (as described above) and satisfy additional selection 199 criteria (if any) specified by the LIST selection options. Let's 200 call any such mailbox name a "matched mailbox name". When multiple 201 selection options are specified, the server MUST return information 202 about mailbox names that satisfy every selection option, unless a 203 description of a particular specified option prescribes special 204 rules. An example of an option prescribing special rules is the 205 RECURSIVEMATCH selection option described later in this section. We 206 will use the term "selection criteria" when referring collectively to 207 all selection options specified in a LIST command. 209 A LIST return option controls which information is returned for each 210 matched mailbox name. Note that return options MUST NOT cause the 211 server to report information about additional mailbox names. If the 212 client has not specified any return option, only information about 213 attributes should be returned by the server. (Of course the server 214 is allowed to include any other information at will.) 216 Both selection and return command options will be defined in this 217 document and in approved extension documents; each option will be 218 enabled by a capability string (one capability may enable multiple 219 options), and a client MUST NOT send an option for which the server 220 has not advertised support. A server MUST respond to options it does 221 not recognize with a BAD response. The client SHOULD NOT specify any 222 option more than once, however if the client does this, the server 223 MUST act as if it received the option only once. The order in which 224 options are specified by the client is not significant. 226 In general, each selection option except for RECURSIVEMATCH will have 227 a corresponding return option. The REMOTE selection option is an 228 anomaly in this regard, and does not have a corresponding return 229 option. That is because it expands, rather than restricts, the set 230 of mailboxes that are returned. Future extensions to this 231 specification should keep parallelism in mind, and define a pair of 232 corresponding options. 234 This extension is identified by the capability string "LIST- 235 EXTENDED", and support for it is a prerequisite for any future 236 extensions that require specialized forms of the LIST command. Such 237 extensions MUST refer to this document and MUST add their function 238 through command options as described herein. Note that extensions 239 that don't require support for an extended LIST command, but use 240 extended LIST responses (see below), don't need to advertise the 241 "LIST-EXTENDED" capability string. 243 This extension also defines extensions to the LIST response, allowing 244 a series of extended fields at the end, a parenthesized list of 245 tagged data (also referred to as "extended data item"). The first 246 element of an extended field is a tag, which identifies type of the 247 data. Tags MUST be registered with IANA, as described in Section 8.5 248 of this document. An example of such extended set might be 250 ((tablecloth (("fringe" "lacy")("color" "white")))(X-Sample 251 "text")) 253 or... 255 ((tablecloth ("fringe" "lacy"))(X-Sample "text" "and even more 256 text")) 258 See the formal syntax, in Section 6, for the full syntactic details. 259 The server MUST NOT return any extended data item, unless the client 260 has expressed its ability to support extended LIST responses, for 261 example by using an extended LIST command. The server MAY return 262 data in the extended fields that was not solicited by the client. 263 The client MUST ignore all extended fields it doesn't recognize. 265 The LIST-EXTENDED capability also defines several new mailbox 266 attributes. 268 The "\NonExistent" attribute indicates that a mailbox does not 269 actually exist. Note that this attribute is not meaningful by 270 itself, as mailboxes that match the canonical LIST pattern but don't 271 exist must not be returned unless one of the two conditions listed 272 below is also satisfied: 274 a. the mailbox also satisfies the selection criteria (for example, 275 its name is subscribed and the "SUBSCRIBED" selection option has 276 been specified) 278 b. "RECURSIVEMATCH" has been specified, and the mailbox has at least 279 one descendant mailbox that does not match the LIST pattern and 280 does match the selection criteria. 282 In practice this means that the "\NonExistent" attribute is usually 283 returned with one or more of "\Subscribed", "\Remote" or the 284 CHILDINFO extended data item (see their description below). 286 The "\NonExistent" attribute implies "\NoSelect". The "\NonExistent" 287 attribute MUST be supported and MUST be accurately computed. 289 The selection options defined in this specification are 291 SUBSCRIBED - causes the LIST command to list subscribed names, rather 292 than the existing mailboxes. This will often be a subset of the 293 actual mailboxes. It's also possible for this list to contain the 294 names of mailboxes that don't exist. In any case, the list MUST 295 include exactly those mailbox names that match the canonical list 296 pattern and are subscribed to. This option is intended to 297 supplement the LSUB command. Of particular note are the mailbox 298 attributes as returned by this option, compared with what is 299 returned by LSUB. With the latter, the attributes returned may 300 not reflect the actual attribute status on the mailbox name, and 301 the \NoSelect attribute has a special meaning (it indicates that 302 this mailbox is not, itself, subscribed, but that it has 303 descendant mailboxes that are). With the SUBSCRIBED selection 304 option described here, the attributes are accurate, complete, and 305 have no special meanings. "LSUB" and "LIST (SUBSCRIBED)" are, 306 thus, not the same thing, and some servers must do significant 307 extra work to respond to "LIST (SUBSCRIBED)". Because of this, 308 clients SHOULD continue to use "LSUB" unless they specifically 309 want the additional information offered by "LIST (SUBSCRIBED)". 311 This option defines a new mailbox attribute, "\Subscribed", that 312 indicates that a mailbox name is subscribed to. The "\Subscribed" 313 attribute MUST be supported and MUST be accurately computed when 314 the SUBSCRIBED selection option is specified. 316 Note that the SUBSCRIBED selection option implies the SUBSCRIBED 317 return option (see below). 319 REMOTE - causes the LIST command to show remote mailboxes as well as 320 local ones, as described in [MBRef]. This option is intended to 321 replace the RLIST command and, in conjunction with the SUBSCRIBED 322 selection option, the RLSUB command. 324 This option defines a new mailbox attribute, "\Remote", that 325 indicates that a mailbox is a remote mailbox. The "\Remote" 326 attribute MUST be accurately computed when the REMOTE option is 327 specified. 329 The REMOTE selection option has no interaction with other options. 330 Its effect is to tell the server to apply the other options, if 331 any, to remote mailboxes, in addition to local ones. In 332 particular, it has no interaction with RECURSIVEMATCH (see below). 333 A request for (REMOTE RECURSIVEMATCH) is invalid, because a 334 request for (RECURSIVEMATCH) is. A request for (REMOTE 335 RECURSIVEMATCH SUBSCRIBED) is asking for all subscribed mailboxes, 336 both local and remote. 338 RECURSIVEMATCH - this option forces the server to return information 339 about parent mailboxes that don't match other selection options, 340 but have some submailboxes that do. Information about children is 341 returned in the CHILDINFO extended data item, as described in 342 Section 3.3. 344 Note 1: In order for a parent mailbox to be returned, it still has 345 to match the canonical LIST pattern. 347 Note 2: When returning the CHILDINFO extended data item, it 348 doesn't matter if the submailbox matches the canonical LIST 349 pattern or not. See also example 9 in Section 5. 351 The RECURSIVEMATCH option MUST NOT occur as the only selection 352 option, as it only makes sense when other selection options are 353 also used. The server MUST return BAD tagged response in such 354 case. 356 Note that even if RECURSIVEMATCH option is specified, the client 357 MUST still be able to handle a case when a CHILDINFO extended data 358 item is returned and there are no submailboxes that meet the 359 selection criteria of the given LIST command, as they can be 360 deleted/renamed after the LIST response was sent, but before the 361 client had a chance to access them. 363 The return options defined in this specification are 365 SUBSCRIBED - causes the LIST command to return subscription state for 366 all matching mailbox names. The "\Subscribed" attribute MUST be 367 supported and MUST be accurately computed when the SUBSCRIBED 368 return option is specified. Further, all mailbox flags MUST be 369 accurately computed (this differs from the behaviour of the LSUB 370 command). 372 CHILDREN - Requests mailbox child information as originally proposed 373 in [CMbox]. See Section 4, below, for details. This option MUST 374 be supported by all servers. 376 3.1 General principles for returning LIST responses 378 This section outlines several principles that can be used by server 379 implementations of this document to decide if a LIST response should 380 be returned, as well as how many responses and what kind of 381 information they may contain. 383 1. Exactly one LIST response should be returned for each mailbox 384 name which matches the canonical LIST pattern. Server 385 implementors must not assume that clients will be able to 386 assemble mailbox attributes and other information returned in 387 multiple LIST responses. 389 2. There are only two reasons for including a matching mailbox name 390 in the responses to the LIST command (Note that the server is 391 allowed to return unsolicited responses at any time. Such 392 responses are not governed by this rule): 394 A. the mailbox name also satisfies the selection criteria; 396 B. the mailbox name doesn't satisfy the selection criteria, but 397 it has at least one descendant mailbox name that satisfies 398 the selection criteria and that doesn't match the canonical 399 LIST pattern. 400 For more information on this case see the CHILDINFO extended 401 data item described in Section 3.3. Note that the CHILDINFO 402 extended data item can only be returned when the 403 RECURSIVEMATCH selection option is specified. 405 3. Attributes returned in the same LIST response must be treated 406 additively. For example the following response 408 S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach" 410 means that the "Fruit/Peach" mailbox doesn't exist, but it is 411 subscribed. 413 3.2 Additional requirements on LIST-EXTENDED clients 415 All clients that support this extension MUST treat an attribute with 416 a stronger meaning, as implying any attribute that can be inferred 417 from it. For example, the client must treat presence of the 418 \NoInferiors attribute as if the \HasNoChildren attribute was also 419 sent by the server. 421 The following table summarizes inference rules described in 422 Section 3. 424 +--------------------+-------------------+ 425 | returned attribute | implied attribute | 426 +--------------------+-------------------+ 427 | \NoInferiors | \HasNoChildren | 428 | | | 429 | \NonExistent | \NoSelect | 430 +--------------------+-------------------+ 432 3.3 CHILDINFO extended data item 434 The CHILDINFO extended data item MUST only be returned when the 435 client has specified the RECURSIVEMATCH selection option. 437 The CHILDINFO extended data item in a LIST response describes the 438 selection criteria that has caused it to be returned and indicates 439 that the mailbox has at least one descendant mailbox that matches the 440 selection criteria. 442 The LSUB command indicates this condition by using the "\NoSelect" 443 attribute, but the LIST (SUBSCRIBED) command MUST NOT do that, since 444 "\NoSelect" retains its original meaning here. Further, the 445 CHILDINFO extended data item is more general, in that it can be used 446 with any extended set of selection criteria. 448 The returned selection criteria allow the client to distinguish a 449 solicited response from an unsolicited one, as well as to distinguish 450 among solicited responses caused by multiple pipelined LIST commands 451 that specify different criteria. 453 Servers SHOULD ONLY return a non-matching mailbox name along with 454 CHILDINFO if at least one matching child is not also being returned. 455 That is, servers SHOULD suppress redundant CHILDINFO responses. 457 Examples 8 and 10 in Section 5 demonstrate the difference between 458 present CHILDINFO extended data item and the "\HasChildren" 459 attribute. 461 The following table summarizes interaction between the "\NonExistent" 462 attribute and CHILDINFO (the first collumn describes if the parent 463 mailbox exists): 465 +----------------+----------------+----------------+----------------+ 466 | exists | meets the | has a child | returned | 467 | | selection | that meets the | LIST-EXTENDED | 468 | | criteria | selection | attributes and | 469 | | | criteria | CHILDINFO | 470 +----------------+----------------+----------------+----------------+ 471 | no | no | no | no LIST | 472 | | | | response | 473 | | | | returned | 474 | | | | | 475 | yes | no | no | no LIST | 476 | | | | response | 477 | | | | returned | 478 | | | | | 479 | no | yes | no | (\NonExistent | 480 | | | | ) | 481 | | | | | 482 | yes | yes | no | () | 483 | | | | | 484 | no | no | yes | (\NonExistent) | 485 | | | | + CHILDINFO | 486 | | | | | 487 | yes | no | yes | () + CHILDINFO | 488 | | | | | 489 | no | yes | yes | (\NonExistent | 490 | | | | ) + | 491 | | | | CHILDINFO | 492 | | | | | 493 | yes | yes | yes | () + | 494 | | | | CHILDINFO | 495 +----------------+----------------+----------------+----------------+ 497 where is one or more attributes that correspond to the 498 selection criteria, for example for the SUBSCRIBED option the 499 is \Subscribed. 501 4. The CHILDREN return Option 503 The CHILDREN return option implements the Child Mailbox Extension, 504 originally proposed by Mike Gahrns and Raymond Cheng, of Microsoft 505 Corporation. Most of the information in this section is taken 506 directly from their original specification [CMbox]. The CHILDREN 507 return option is simply an indication that the client wants this 508 information; a server MAY provide it even if the option is not 509 specified. 511 Many IMAP4 [IMAP4] clients present to the user a hierarchical view of 512 the mailboxes that a user has access to. Rather than initially 513 presenting to the user the entire mailbox hierarchy, it is often 514 preferable to show to the user a collapsed outline list of the 515 mailbox hierarchy (particularly if there is a large number of 516 mailboxes). The user can then expand the collapsed outline hierarchy 517 as needed. It is common to include within the collapsed hierarchy a 518 visual clue (such as a ''+'') to indicate that there are child 519 mailboxes under a particular mailbox. When the visual clue is 520 clicked the hierarchy list is expanded to show the child mailboxes. 521 The CHILDREN return option provides a mechanism for a client to 522 efficiently determine if a particular mailbox has children, without 523 issuing a LIST "" * or a LIST "" % for each mailbox name. The 524 CHILDREN return option defines two new attributes that MAY be 525 returned within a LIST response: \HasChildren and \HasNoChildren. 526 While these attributes MAY be returned in response to any LIST 527 command, the CHILDREN return option is provided to indicate that the 528 client particularly wants this information. If the CHILDREN return 529 option is present, the server MUST return these attributes even if 530 their computation is expensive. 532 \HasChildren 534 The presence of this attribute indicates that the mailbox has 535 child mailboxes. A server SHOULD NOT set this attribute if 536 there are child mailboxes, and the user does not have 537 permissions to access any of them. In this case, \HasNoChildren 538 SHOULD be used. In many cases, however, a server may not be 539 able to efficiently compute whether a user has access to all 540 child mailboxes. As such a client MUST be prepared to accept 541 the \HasChildren attribute as a hint. That is, a mailbox MAY be 542 flagged with the \HasChildren attribute, but no child mailboxes 543 will appear in the LIST response. 545 \HasNoChildren 546 The presence of this attribute indicates that the mailbox has NO 547 child mailboxes that are accessible to the currently 548 authenticated user. 550 In some instances a server that supports the LIST-EXTENDED extension 551 might not be able to determine whether a mailbox has children. For 552 example it may have difficulty determining whether there are child 553 mailboxes when LISTing mailboxes while operating in a particular 554 namespace. In these cases, a server MAY exclude both the 555 \HasChildren and \HasNoChildren attributes in the LIST response. As 556 such, a client can not make any assumptions about whether a mailbox 557 has children based upon the absence of a single attribute. In 558 particular, some servers may not be able to combine the SUBSCRIBED 559 selection option and CHILDREN return option. Such servers MUST 560 honour the SUBSCRIBED selection option, and they will simply ignore 561 the CHILDREN return option if both are requested. It is an error for 562 the server to return both a \HasChildren and a \HasNoChildren 563 attribute in a LIST response. 565 Note: the \HasNoChildren attribute should not be confused with the 566 IMAP4 [IMAP4] defined attribute \NoInferiors which indicates that no 567 child mailboxes exist now and none can be created in the future. 569 5. Examples 571 1: The first example shows the complete local hierarchy that will be 572 used for the other examples. 574 C: A01 LIST "" "*" 576 S: * LIST (\Marked \NoInferiors) "/" "inbox" 578 S: * LIST () "/" "Fruit" 580 S: * LIST () "/" "Fruit/Apple" 582 S: * LIST () "/" "Fruit/Banana" 584 S: * LIST () "/" "Tofu" 586 S: * LIST () "/" "Vegetable" 588 S: * LIST () "/" "Vegetable/Broccoli" 590 S: * LIST () "/" "Vegetable/Corn" 592 S: A01 OK done 594 2: In the next example, we'll see the subscribed mailboxes. This is 595 similar to, but not equivalent with, . Note that 596 the mailbox called "Fruit/Peach" is subscribed to, but does not 597 actually exist (perhaps it was deleted while still subscribed). 598 The "Fruit" mailbox is not subscribed to, but it has two 599 subscribed children. The "Vegetable" mailbox is subscribed and 600 has two children, one of them is subscribed as well. 602 C: A02 LIST (SUBSCRIBED) "" "*" 604 S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox" 606 S: * LIST (\Subscribed) "/" "Fruit/Banana" 608 S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach" 610 S: * LIST (\Subscribed) "/" "Vegetable" 611 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) 625 S: * LIST (\Marked \NoInferiors) "/" "inbox" 627 S: * LIST (\HasChildren) "/" "Fruit" 629 S: * LIST (\HasNoChildren) "/" "Tofu" 631 S: * LIST (\HasChildren) "/" "Vegetable" 633 S: A03 OK done 635 4: In this example we see more mailboxes, which reside on another 636 server to which we may obtain referrals. This is similar to the 637 command . Note that in the case of the remote 638 mailboxes, the server might or might not be able to include 639 CHILDREN information; it includes it if it can, and omits it if 640 it can't. 642 C: A04 LIST (REMOTE) "" "%" RETURN (CHILDREN) 644 S: * LIST (\Marked \NoInferiors) "/" "inbox" 646 S: * LIST (\HasChildren) "/" "Fruit" 648 S: * LIST (\HasNoChildren) "/" "Tofu" 650 S: * LIST (\HasChildren) "/" "Vegetable" 651 S: * LIST (\Remote) "/" "Bread" 653 S: * LIST (\HasChildren \Remote) "/" "Meat" 655 S: A04 OK done 657 5: The following example also requests the server to include 658 mailboxes, which reside on another server. The server returns 659 information about all mailboxes which are subscribed. This is 660 similar to the command . We also see the use of 661 two selection options. 663 C: A05 LIST (REMOTE SUBSCRIBED) "" "*" 665 S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox" 667 S: * LIST (\Subscribed) "/" "Fruit/Banana" 669 S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach" 671 S: * LIST (\Subscribed) "/" "Vegetable" 673 S: * LIST (\Subscribed) "/" "Vegetable/Broccoli" 675 S: * LIST (\Remote \Subscribed) "/" "Bread" 677 S: A05 OK done 679 6: The following example requests the server to include mailboxes, 680 which reside on another server. The server is requested to 681 return subscription information for all returned mailboxes. This 682 is different from the example above. 684 Note that the output of this command is not a superset of the 685 output in the previous example, as it doesn't include LIST 686 response for the non-existent "Fruit/Peach". 688 C: A06 LIST (REMOTE) "" "*" RETURN (SUBSCRIBED) 690 S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox" 691 S: * LIST () "/" "Fruit" 693 S: * LIST () "/" "Fruit/Apple" 695 S: * LIST (\Subscribed) "/" "Fruit/Banana" 697 S: * LIST () "/" "Tofu" 699 S: * LIST (\Subscribed) "/" "Vegetable" 701 S: * LIST (\Subscribed) "/" "Vegetable/Broccoli" 703 S: * LIST () "/" "Vegetable/Corn" 705 S: * LIST (\Remote \Subscribed) "/" "Bread" 707 S: * LIST (\Remote) "/" "Meat" 709 S: A06 OK done 711 7: In the following example the client has specified multiple 712 mailbox patterns. Note that this example doesn't use the mailbox 713 hierarchy used in the previous examples. 715 C: BBB LIST "" ("INBOX" "Drafts" "Sent/%") 717 S: * LIST () "/" "INBOX" 719 S: * LIST (\NoInferiors) "/" "Drafts" 721 S: * LIST () "/" "Sent/March2004" 723 S: * LIST (\Marked) "/" "Sent/December2003" 725 S: * LIST () "/" "Sent/August2004" 727 S: BBB OK done 729 8: The following example demonstates the difference between 730 \HasChildren attribute and CHILDINFO extended data item. 732 Let's assume there is the following hierarchy: 734 C: C01 LIST "" "*" 736 S: * LIST (\Marked \NoInferiors) "/" "inbox" 738 S: * LIST () "/" "Foo" 740 S: * LIST () "/" "Foo/Bar" 742 S: * LIST () "/" "Foo/Baz" 744 S: * LIST () "/" "Moo" 746 S: C01 OK done 748 If the client asks RETURN (CHILDREN) it will get this: 750 C: CA3 LIST "" "%" RETURN (CHILDREN) 752 S: * LIST (\Marked \NoInferiors) "/" "inbox" 754 S: * LIST (\HasChildren) "/" "Foo" 756 S: * LIST (\HasNoChildren) "/" "Moo" 758 S: CA3 OK done 760 A) Let's also assume that the mailbox "Foo/Baz" is the only 761 subscribed mailbox. Then we get this result: 763 C: C02 LIST (SUBSCRIBED) "" "*" 765 S: * LIST (\Subscribed) "/" "Foo/Baz" 767 S: C02 OK done 769 Now, if the client issues , the server 770 will return no mailboxes (as the mailboxes "Moo", "Foo" and 771 "Inbox" are NOT subscribed). However, if the client issues this: 773 C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" 774 S: * LIST () "/" "Foo" (("CHILDINFO" ("SUBSCRIBED"))) 776 S: C04 OK done 778 i.e. the mailbox "Foo" is not subscribed, but it has a child that 779 is. 781 A1) If the mailbox "Foo" had been subscribed instead, the last 782 command would return this: 784 C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" 786 S: * LIST (\Subscribed) "/" "Foo" (("CHILDINFO" 787 ("SUBSCRIBED"))) 789 S: C04 OK done 791 or even this: 793 C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" 795 S: * LIST (\Subscribed \HasChildren) "/" "Foo" (("CHILDINFO" 796 ("SUBSCRIBED"))) 798 S: C04 OK done 800 A2) If we assume instead that the mailbox "Foo" is not part of 801 the original hierarchy and is not subscribed, the last command 802 will give this result: 804 C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" 806 S: * LIST (\NonExistent) "/" "Foo" (("CHILDINFO" 807 ("SUBSCRIBED"))) 809 S: C04 OK done 811 B) Now, let's assume that no mailbox is subscribed. In this case 812 the command will return 813 no responses, as there are no subscribed children (even though 814 "Foo" has children). 816 C) And finally, suppose that only the mailboxes "Foo" and "Moo" 817 are subscribed. In that case we see this result: 819 C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" RETURN 820 (CHILDREN) 822 S: * LIST (\HasChildren \Subscribed) "/" "Foo" 824 S: * LIST (\HasNoChildren \Subscribed) "/" "Moo" 826 S: C04 OK done 828 (which means that the mailbox "Foo" has children, but none of 829 them is subscribed). 831 9: The following example demonstrates that the CHILDINFO extended 832 data item is returned whether children mailboxes match the 833 canonical LIST pattern or not. 835 Let's assume there is the following hierarchy: 837 C: D01 LIST "" "*" 839 S: * LIST (\Marked \NoInferiors) "/" "inbox" 841 S: * LIST () "/" "foo2" 843 S: * LIST () "/" "foo2/bar1" 845 S: * LIST () "/" "foo2/bar2" 847 S: * LIST () "/" "baz2" 849 S: * LIST () "/" "baz2/bar2" 851 S: * LIST () "/" "baz2/bar22" 853 S: * LIST () "/" "baz2/bar222" 855 S: * LIST () "/" "eps2" 857 S: * LIST () "/" "eps2/mamba" 858 S: * LIST () "/" "quux2/bar2" 860 S: D01 OK done 862 And that the following mailboxes are subscribed: 864 C: D02 LIST (SUBSCRIBED) "" "*" 866 S: * LIST (\Subscribed) "/" "foo2/bar1" 868 S: * LIST (\Subscribed) "/" "foo2/bar2" 870 S: * LIST (\Subscribed) "/" "baz2/bar2" 872 S: * LIST (\Subscribed) "/" "baz2/bar22" 874 S: * LIST (\Subscribed) "/" "baz2/bar222" 876 S: * LIST (\Subscribed) "/" "eps2" 878 S: * LIST (\Subscribed) "/" "eps2/mamba" 880 S: * LIST (\Subscribed) "/" "quux2/bar2" 882 S: D02 OK done 884 The client issues the following command first: 886 C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*2" 888 S: * LIST () "/" "foo2" (("CHILDINFO" ("SUBSCRIBED"))) 890 S: * LIST (\Subscribed) "/" "foo2/bar2" 892 S: * LIST () "/" "baz2" (("CHILDINFO" ("SUBSCRIBED"))) 894 S: * LIST (\Subscribed) "/" "baz2/bar2" 896 S: * LIST (\Subscribed) "/" "baz2/bar22" 898 S: * LIST (\Subscribed) "/" "baz2/bar222" 900 S: * LIST (\Subscribed) "/" "eps2" (("CHILDINFO" 901 ("SUBSCRIBED"))) 902 S: * LIST (\Subscribed) "/" "quux2/bar2" 904 S: D03 OK done 906 and the server may also include 908 S: * LIST (\NonExistent) "/" "quux2" (("CHILDINFO" 909 ("SUBSCRIBED"))) 911 The CHILDINFO extended data item is returned for mailboxes 912 "foo2", "baz2" and "eps2", because all of them have subscribed 913 children, even though for the mailbox "foo2" only one of the two 914 subscribed children match the pattern, for the mailbox "baz2" all 915 the subscribed children match the pattern and for the mailbox 916 "eps2" none of the subscribed children match the pattern. 918 Note that if the client issues 920 C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*" 922 S: * LIST () "/" "foo2" (("CHILDINFO" ("SUBSCRIBED"))) 924 S: * LIST (\Subscribed) "/" "foo2/bar1" 926 S: * LIST (\Subscribed) "/" "foo2/bar2" 928 S: * LIST () "/" "baz2" (("CHILDINFO" ("SUBSCRIBED"))) 930 S: * LIST (\Subscribed) "/" "baz2/bar2" 932 S: * LIST (\Subscribed) "/" "baz2/bar22" 934 S: * LIST (\Subscribed) "/" "baz2/bar222" 936 S: * LIST (\Subscribed) "/" "eps2" (("CHILDINFO" 937 ("SUBSCRIBED"))) 939 S: * LIST (\Subscribed) "/" "eps2/mamba" 941 S: * LIST (\Subscribed) "/" "quux2/bar2" 943 S: D03 OK done 945 the LIST responses for mailboxes "foo2", "baz2" and "eps2" still 946 have the CHILDINFO extended data item, even though this 947 information is redundant and the client can determine it by 948 itself. 950 10: The following example shows usage of multiple mailbox patterns. 951 It also demonstrates that the presence of the CHILDINFO extended 952 data item doesn't necessarily imply \HasChildren. 954 C: a1 LIST "" ("foo" "foo/*") 956 S: * LIST () "/" foo 958 S: a1 OK done 960 C: a2 LIST (SUBSCRIBED) "" "foo/*" 962 S: * LIST (\Subscribed \NonExistent) "/" foo/bar 964 S: a2 OK done 966 C: a3 LIST (SUBSCRIBED RECURSIVEMATCH) "" foo RETURN 967 (CHILDREN) 969 S: * LIST (\HasNoChildren) "/" foo (("CHILDINFO" 970 ("SUBSCRIBED"))) 972 S: a3 OK done 974 6. Formal Syntax 976 The following syntax specification uses the augmented Backus-Naur 977 Form (BNF) as described in [ABNF]. Terms not defined here are taken 978 from [IMAP4]. 980 "vendor-token" is defined in [ACAP]. Note that this normative 981 reference to ACAP is an issue in moving this spec forward, since ACAP 982 will never move to Draft Standard. The definitions of "vendor-token" 983 and of the IANA registry must eventually go somewhere else, in a 984 document that can be moved forward on the standards track. 986 childinfo-extended-item = "CHILDINFO" SP "(" 987 list-select-base-opt-quoted 988 *(SP list-select-base-opt-quoted) ")" 989 ; Extended data item returned when the RECURSIVEMATCH 990 ; selection option is specified. 991 ; Note 1: the CHILDINFO tag can be returned 992 ; with and without surrounding quotes, as per 993 ; mbox-list-extended-item-tag production. 994 ; Note 2: The selection options are returned quoted, 995 ; unlike their specification in the extended LIST 996 ; command. 998 child-mbox-flag = "\HasChildren" / "\HasNoChildren" 999 ; attributes for CHILDREN return option, at most one 1000 ; possible per LIST response 1002 eitem-standard-tag = atom 1003 ; a tag for extended list data defined in a Standard 1004 ; Track or Experimental RFC. 1006 eitem-vendor-tag = vendor-tag 1007 ; a vendor specific tag for extended list data 1009 list = "LIST" [SP list-select-opts] SP mailbox SP mbox-or-pat 1010 [SP list-return-opts] 1012 list-return-opts = "RETURN" SP 1013 "(" [return-option *(SP return-option)] ")" 1014 ; list return options, e.g. CHILDREN 1016 list-select-base-opt = "SUBSCRIBED" / option-extension 1017 ; options that can be used by themselves 1019 list-select-base-opt-quoted = <"> list-select-base-opt <"> 1021 list-select-independent-opt = "REMOTE" / option-extension 1022 ; options that do not syntactically interact with 1023 ; other options 1025 list-select-mod-opt = "RECURSIVEMATCH" / option-extension 1026 ; options that require a list-select-base-opt 1027 ; to also be present 1029 list-select-opt = list-select-base-opt / list-select-independent-opt 1030 / list-select-mod-opt 1031 ; An option registration template is described in 1032 ; Section 8.3 of this document. 1034 list-select-opts = "(" [ 1035 (*(list-select-opt SP) list-select-base-opt 1036 *(SP list-select-opt)) 1037 / (list-select-independent-opt 1038 *(SP list-select-independent-opt)) 1039 ] ")" 1040 ; Any number of options may be in any order. 1041 ; If a list-select-mod-opt appears, then a 1042 ; list-select-base-opt must also appear. 1043 ; This allows these: 1044 ; () 1045 ; (REMOTE) 1046 ; (SUBSCRIBED) 1047 ; (SUBSCRIBED REMOTE) 1048 ; (SUBSCRIBED RECURSIVEMATCH) 1049 ; (SUBSCRIBED REMOTE RECURSIVEMATCH) 1050 ; But does NOT allow these: 1051 ; (RECURSIVEMATCH) 1052 ; (REMOTE RECURSIVEMATCH) 1054 mailbox-list = "(" [mbx-list-flags] ")" SP 1055 (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox 1056 [SP mbox-list-extended] 1058 mbox-list-extended = "(" [mbox-list-extended-item 1059 *(SP mbox-list-extended-item)] ")" 1061 mbox-list-extended-item = "(" mbox-list-extended-item-data ")" 1063 mbox-list-extended-item-data = mbox-list-extended-item-tag SP 1064 nstring-list 1066 mbox-list-extended-item-tag = astring 1067 ; The content MUST conform to either "eitem-vendor-tag" 1068 ; or "eitem-standard-tag" ABNF productions. 1069 ; A tag registration template is described in this 1070 ; document in Section 8.5. 1072 mbox-list-oflag = child-mbox-flag / "\NonExistent" / "\Subscribed" / 1073 "\Remote" 1075 mbox-or-pat = list-mailbox / patterns 1077 nstring-list = nstring / 1078 "(" [nstring-list *(SP nstring-list)] ")" 1079 ; a recursive list definition 1081 option-extension = (option-standard-tag / option-vendor-tag) 1082 [SP option-value] 1084 option-standard-tag = atom 1085 ; an option defined in a Standards Track or 1086 ; Experimental RFC 1088 option-val-comp = astring / 1089 option-val-comp *(SP option-val-comp) / 1090 "(" option-val-comp ")" 1092 option-value = "(" option-val-comp ")" 1093 option-vendor-tag = vendor-token "-" atom 1094 ; a vendor specific option, non-standard 1096 patterns = "(" list-mailbox *(SP list-mailbox) ")" 1098 return-option = "SUBSCRIBED" / "CHILDREN" / option-extension 1100 7. Security Considerations 1102 This document describes syntactic changes to the specification of the 1103 IMAP4 commands LIST, LSUB, RLIST, and RLSUB, and the modified LIST 1104 command has the same security considerations as those commands. They 1105 are described in [IMAP4] and [MBRef]. 1107 The Child Mailbox Extension provides a client a more efficient means 1108 of determining whether a particular mailbox has children. If a 1109 mailbox has children, but the currently authenticated user does not 1110 have access to any of them, the server SHOULD respond with a 1111 \HasNoChildren attribute. In many cases, however, a server may not 1112 be able to efficiently compute whether a user has access to all child 1113 mailboxes. If such a server responds with a \HasChildren attribute, 1114 when in fact the currently authenticated user does not have access to 1115 any child mailboxes, potentially more information is conveyed about 1116 the mailbox than intended. In most situations this will not be a 1117 security concern, because if information regarding whether a mailbox 1118 has children is considered sensitive, a user would not be granted 1119 access to that mailbox in the first place. 1121 The CHILDINFO extended data item has the same security considerations 1122 as the \HasChildren attribute described above. 1124 8. IANA Considerations 1126 8.1 Guidelines for IANA 1128 It is requested that IANA creates two new registries for LIST- 1129 EXTENDED options and LIST-EXTENDED response data. The templates and 1130 the initial registrations are detailed below. 1132 8.2 Registration procedure and Change control 1134 Registration of a LIST-EXTENDED option is done by filling in the 1135 template in Section 8.3 and sending it via electronic mail to 1136 iana@iana.org. Registration of a LIST-EXTENDED extended data item is 1137 done by filling in the template in Section 8.5 and sending it via 1138 electronic mail to iana@iana.org. IANA has the right to reject 1139 obviously bogus registrations, but will perform no review of claims 1140 made in the registration form. 1142 A LIST-EXTENDED option/extended data item name that starts with "V-" 1143 is reserved for vendor specific options/extended data items. All 1144 options, whether they are vendor specific or global, should be 1145 registered with IANA. If a LIST-EXTENDED extended data item is 1146 returned as a result of requesting a particular LIST-EXTENDED option, 1147 the name of the option SHOULD be used as the name of the LIST- 1148 EXTENDED extended data item. 1150 Each vendor specific options/extended data item MUST start with their 1151 vendor-token ("vendor prefix"). The vendor-token MUST be registered 1152 with IANA, using the [ACAP] vendor subtree registry. 1154 Standard LIST-EXTENDED option/extended data item names are case 1155 insensitive. If the vendor prefix is omitted from a vendor specific 1156 LIST-EXTENDED option/extended data item name, the rest is case 1157 insensitive. The vendor prefix itself is not case-sensitive, as it 1158 might contain non-ASCII characters. 1160 While the registration procedures do not require it, authors of LIST- 1161 EXTENDED options/extended data items are encouraged to seek community 1162 review and comment whenever that is feasible. Authors may seek 1163 community review by posting a specification of their proposed 1164 mechanism as an Internet- Draft. LIST-EXTENDED options/extended data 1165 items intended for widespread use should be standardized through the 1166 normal IETF process, when appropriate. 1168 Comments on registered LIST-EXTENDED options/extended response data 1169 should first be sent to the "owner" of the mechanism and/or to the 1170 IMAPEXT WG mailing list. Submitters of comments may, after a 1171 reasonable attempt to contact the owner, request IANA to attach their 1172 comment to the registration itself. If IANA approves of this, the 1173 comment will be made accessible in conjunction with the registration 1174 LIST-EXTENDED options/ extended response data itself. 1176 Once a LIST-EXTENDED registration has been published by IANA, the 1177 author may request a change to its definition. The change request 1178 follows the same procedure as the registration request. 1180 The owner of a LIST-EXTENDED registration may pass responsibility for 1181 the registered option/extended data item to another person or agency 1182 by informing IANA; this can be done without discussion or review. 1184 The IESG may reassign responsibility for a LIST-EXTENDED option/ 1185 extended data item. The most common case of this will be to enable 1186 changes to be made to mechanisms where the author of the registration 1187 has died, moved out of contact or is otherwise unable to make changes 1188 that are important to the community. 1190 LIST-EXTENDED registrations may not be deleted; mechanisms which are 1191 no longer believed appropriate for use can be declared OBSOLETE by a 1192 change to their "intended use" field; such LIST-EXTENDED options/ 1193 extended data items will be clearly marked in the lists published by 1194 IANA. 1196 The IESG is considered to be the owner of all LIST-EXTENDED options/ 1197 extended data items which are on the IETF standards track. 1199 8.3 Registration template for LIST-EXTENDED options 1201 To: iana@iana.org 1202 Subject: Registration of LIST-EXTENDED option X 1204 LIST-EXTENDED option name: 1206 LIST-EXTENDED option type: (One of SELECTION or RETURN) 1208 Implied return options(s), if the option type is SELECTION: (zero or 1209 more) 1211 LIST-EXTENDED option description: 1213 Published specification (optional, recommended): 1215 Security considerations: 1217 Intended usage: 1218 (One of COMMON, LIMITED USE or OBSOLETE) 1219 Person and email address to contact for further information: 1221 Owner/Change controller: 1223 (Any other information that the author deems interesting may be added 1224 below this line.) 1226 8.4 Initial LIST-EXTENDED option registrations 1228 It is requested that the LIST-EXTENDED option registry be populated 1229 with the following entries: 1231 1. To: iana@iana.org 1232 Subject: Registration of LIST-EXTENDED option SUBSCRIBED 1234 LIST-EXTENDED option name: SUBSCRIBED 1236 LIST-EXTENDED option type: SELECTION 1238 Implied return options(s): SUBSCRIBED 1240 LIST-EXTENDED option description: Causes the LIST command to list 1241 subscribed mailboxes, rather than the actual mailboxes. 1243 Published specification : XXXX, Section 3. 1245 Security considerations: XXXX, Section 7. 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 2. To: iana@iana.org 1255 Subject: Registration of LIST-EXTENDED option REMOTE 1257 LIST-EXTENDED option name: REMOTE 1259 LIST-EXTENDED option type: SELECTION 1261 Implied return options(s): (none) 1263 LIST-EXTENDED option description: causes the LIST command to 1264 return remote mailboxes as well as local ones, as described in 1265 RFC 2193. 1267 Published specification : XXXX, Section 3. 1269 Security considerations: XXXX, Section 7. 1271 Intended usage: COMMON 1273 Person and email address to contact for further information: 1274 Alexey Melnikov 1276 Owner/Change controller: iesg@ietf.org 1278 3. To: iana@iana.org 1279 Subject: Registration of LIST-EXTENDED option SUBSCRIBED 1281 LIST-EXTENDED option name: SUBSCRIBED 1283 LIST-EXTENDED option type: RETURN 1285 LIST-EXTENDED option description: Causes the LIST command to 1286 return subscription state. 1288 Published specification : XXXX, Section 3. 1290 Security considerations: XXXX, Section 7. 1292 Intended usage: COMMON 1294 Person and email address to contact for further information: 1295 Alexey Melnikov 1297 Owner/Change controller: iesg@ietf.org 1299 4. To: iana@iana.org 1300 Subject: Registration of LIST-EXTENDED option RECURSIVEMATCH 1302 LIST-EXTENDED option name: RECURSIVEMATCH 1304 LIST-EXTENDED option type: SELECTION 1306 Implied return options(s): (none) 1308 LIST-EXTENDED option description: Requests that CHILDINFO 1309 extended data item is to be returned. 1311 Published specification : XXXX, Section 3. 1313 Security considerations: XXXX, Section 7. 1315 Intended usage: COMMON 1317 Person and email address to contact for further information: 1318 Alexey Melnikov 1320 Owner/Change controller: iesg@ietf.org 1322 5. To: iana@iana.org 1323 Subject: Registration of LIST-EXTENDED option CHILDREN 1325 LIST-EXTENDED option name: CHILDREN 1327 LIST-EXTENDED option type: RETURN 1329 LIST-EXTENDED option description: Requests mailbox child 1330 information. 1332 Published specification : XXXX, Section 3 and Section 4. 1334 Security considerations: XXXX, Section 7. 1336 Intended usage: COMMON 1338 Person and email address to contact for further information: 1339 Alexey Melnikov 1341 Owner/Change controller: iesg@ietf.org 1343 8.5 Registration template for LIST-EXTENDED extended data item 1345 To: iana@iana.org 1346 Subject: Registration of X LIST-EXTENDED extended data item 1348 LIST-EXTENDED extended data item tag: 1350 LIST-EXTENDED extended data item description: 1352 Which LIST-EXTENDED option(s) (and their types) causes this extended 1353 data item to be returned (if any): 1355 Published specification (optional, recommended): 1357 Security considerations: 1359 Intended usage: 1360 (One of COMMON, LIMITED USE or OBSOLETE) 1362 Person and email address to contact for further information: 1364 Owner/Change controller: 1366 (Any other information that the author deems interesting may be added 1367 below this line.) 1369 8.6 Initial LIST-EXTENDED extended data item registrations 1371 It is requested that the LIST-EXTENDED extended data item registry be 1372 populated with the following entries: 1374 1. To: iana@iana.org 1375 Subject: Registration of CHILDINFO LIST-EXTENDED extended data 1376 item 1378 LIST-EXTENDED extended data item tag: CHILDINFO 1380 LIST-EXTENDED extended data item description: The CHILDINFO 1381 extended data item describes the selection criteria that has 1382 caused it to be returned and indicates that the mailbox has one 1383 or more child mailbox that match the selection criteria. 1385 Which LIST-EXTENDED option(s) (and their types) causes this 1386 extended data item to be returned (if any): RECURSIVEMATCH 1387 selection option 1389 Published specification : XXXX, Section 3.3. 1391 Security considerations: XXXX, Section 7. 1393 Intended usage: COMMON 1395 Person and email address to contact for further information: 1396 Alexey Melnikov 1398 Owner/Change controller: iesg@ietf.org 1400 9. Acknowledgements 1402 Mike Gahrns and Raymond Cheng of Microsoft Corporation originally 1403 devised the Child Mailbox Extension and proposed it in 1997; the 1404 idea, as well as most of the text in Section 4, is theirs. 1406 This document is the result of discussions on the IMAP4 and IMAPEXT 1407 mailing lists and is meant to reflect consensus of those groups. In 1408 particular, Mark Crispin, Philip Guenther, Cyrus Daboo, Timo 1409 Sirainen, Ken Murchison, Rob Siemborski, Steve Hole, Arnt 1410 Gulbrandsen, Larry Greenfield, Dave Cridland and Pete Maclean were 1411 active participants in those discussions or made suggestions to this 1412 document. 1414 10. Normative References 1416 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1417 Specifications: ABNF", RFC 4234, October 2005. 1419 [ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration 1420 Access Protocol", RFC 2244, November 1997. 1422 [CMbox] Gahrns, M. and R. Cheng, "", RFC 3348, July 2002. 1424 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 1425 4rev1", RFC 3501, March 2003. 1427 [Kwds] Bradner, S., "Key words for use in RFCs to Indicate 1428 Requirement Levels", RFC 2119, March 1997. 1430 [MBRef] Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193, 1431 September 1997. 1433 Authors' Addresses 1435 Barry Leiba 1436 IBM T.J. Watson Research Center 1437 19 Skyline Drive 1438 Hawthorne, NY 10532 1439 US 1441 Phone: +1 914 784 7941 1442 Email: leiba@watson.ibm.com 1443 Alexey Melnikov 1444 Isode Limited 1445 5 Castle Business Village 1446 36 Station Road 1447 Hampton, Middlesex TW12 2BX 1448 UK 1450 Email: Alexey.Melnikov@isode.com 1451 URI: http://www.melnikov.ca/ 1453 Intellectual Property Statement 1455 The IETF takes no position regarding the validity or scope of any 1456 Intellectual Property Rights or other rights that might be claimed to 1457 pertain to the implementation or use of the technology described in 1458 this document or the extent to which any license under such rights 1459 might or might not be available; nor does it represent that it has 1460 made any independent effort to identify any such rights. Information 1461 on the procedures with respect to rights in RFC documents can be 1462 found in BCP 78 and BCP 79. 1464 Copies of IPR disclosures made to the IETF Secretariat and any 1465 assurances of licenses to be made available, or the result of an 1466 attempt made to obtain a general license or permission for the use of 1467 such proprietary rights by implementers or users of this 1468 specification can be obtained from the IETF on-line IPR repository at 1469 http://www.ietf.org/ipr. 1471 The IETF invites any interested party to bring to its attention any 1472 copyrights, patents or patent applications, or other proprietary 1473 rights that may cover technology that may be required to implement 1474 this standard. Please address the information to the IETF at 1475 ietf-ipr@ietf.org. 1477 Disclaimer of Validity 1479 This document and the information contained herein are provided on an 1480 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1481 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1482 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1483 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1484 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1485 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1487 Copyright Statement 1489 Copyright (C) The Internet Society (2005). This document is subject 1490 to the rights, licenses and restrictions contained in BCP 78, and 1491 except as set forth therein, the authors retain all their rights. 1493 Acknowledgment 1495 Funding for the RFC Editor function is currently provided by the 1496 Internet Society.