idnits 2.17.1 draft-ietf-imapext-list-extensions-12.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.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1333. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1310. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1317. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1323. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 (March 2005) is 6982 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 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3348 (ref. 'CMbox') (Obsoleted by RFC 5258) ** Obsolete normative reference: RFC 3501 (ref. 'IMAP4') (Obsoleted by RFC 9051) Summary: 8 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: September 2, 2005 March 2005 8 IMAP4 LIST Command Extensions 9 draft-ietf-imapext-list-extensions-12 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on September 2, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 IMAP4 has two commands for listing mailboxes: LIST and LSUB. As we 45 have added extensions, such as Mailbox Referrals, that have required 46 specialized lists we have had to expand the number of list commands, 47 since each extension must add its function to both LIST and LSUB, and 48 these commands are not, as they are defined, extensible. If we've 49 needed the extensions to work together, we've had to add a set of 50 commands to mix the different options, the set increasing in size 51 with each new extension. This document describes an extension to the 52 base LIST command that will allow these additions to be done with 53 mutually compatible options to the LIST command, avoiding the 54 exponential increase in specialized list commands. 56 Note 58 A revised version of this draft document will be submitted to the RFC 59 editor as an Proposed Standard for the Internet Community. 60 Discussion and suggestions for improvement are requested, and should 61 be sent to ietf-imapext@imc.org. 63 This document obsoletes RFC 3348 and updates RFC 2193. 65 Table of Contents 67 1. Conventions used in this document . . . . . . . . . . . . . . 4 69 2. Introduction and overview . . . . . . . . . . . . . . . . . . 5 71 3. Extended LIST Command . . . . . . . . . . . . . . . . . . . . 6 72 3.1 General principles for returning LIST responses . . . . . . . 10 73 3.2 Additional requirements on LISTEXT clients . . . . . . . . . . 11 74 3.3 CHILDINFO extended data item . . . . . . . . . . . . . . . . . 11 76 4. The CHILDREN return Option . . . . . . . . . . . . . . . . . . 13 78 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 22 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 85 8.1 Guidelines for IANA . . . . . . . . . . . . . . . . . . . . . 26 86 8.2 Registration procedure and Change control . . . . . . . . . . 26 87 8.3 Registration template for LISTEXT options . . . . . . . . . . 27 88 8.4 Initial LISTEXT option registrations . . . . . . . . . . . . . 28 89 8.5 Registration template for LISTEXT extended data item . . . . . 30 90 8.6 Initial LISTEXT extended data item registrations . . . . . . . 31 92 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 94 10. Normative References . . . . . . . . . . . . . . . . . . . . . 32 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 32 98 Intellectual Property and Copyright Statements . . . . . . . . 34 100 1. Conventions used in this document 102 In examples, "C:" indicates lines sent by a client that is connected 103 to a server. "S:" indicates lines sent by the server to the client. 105 The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are 106 used in this document as specified in RFC 2119 [Kwds]. 108 The term "canonical LIST pattern" refers to the canonical pattern 109 constructed internally by the server from the reference and mailbox 110 name arguments (Section 6.3.8 of [IMAP4]). The [IMAP4] LIST command 111 returns only mailboxes that match the canonical LIST pattern. 113 Other terms are introduced where they are referenced for the first 114 time. 116 2. Introduction and overview 118 The LIST command is extended by amending the syntax to allow options 119 and multiple patterns to be specified. The list of options replaces 120 the several commands that are currently used to mix and match the 121 information requested. The new syntax is backward- compatible, with 122 no ambiguity: the new syntax is being used if one of the following 123 conditions is true: 124 1. if the first word after the command name begins with a 125 parenthesis ("LIST selection options"); 126 2. if the second word after the command name begins with a 127 parenthesis ("multiple mailbox patterns"); 128 3. if the LIST command has more than 2 parameters ("LIST return 129 options"); 131 Otherwise the original syntax is used. 133 By adding options to the LIST command, we are announcing the intent 134 to phase out and eventually to deprecate the RLIST and RLSUB commands 135 described in [MBRef]. We are also defining the mechanism to request 136 extended mailbox information, such as is described in the "Child 137 Mailbox Extension" [CMbox]. The base LSUB command is not deprecated 138 by this extension; rather, this extension adds a way to obtain 139 subscription information with more options, with those server 140 implementations that support it. Clients that simply need a list of 141 subscribed mailboxes, as provided by the LSUB command, SHOULD 142 continue to use that command. 144 This document defines an IMAP4 extension that is identified by the 145 capability string "LISTEXT". The X-DRAFT-W12-LISTEXT extension makes 146 the following changes to the IMAP4 protocol, which are described in 147 more detail in Section 3 and Section 4: 149 a. defines new syntax for LIST command options. 150 b. extends LIST to allow for multiple mailbox patterns. 151 c. adds LIST command selection options: SUBSCRIBED, REMOTE and 152 RECURSIVEMATCH. 153 d. adds LIST command return options: SUBSCRIBED and CHILDREN. 154 e. adds new mailbox attributes: "\NonExistent", "\Subscribed", 155 "\Remote", "\HasChildren" and "\HasNoChildren". 156 f. adds CHILDINFO extended data item. 158 3. Extended LIST Command 160 This extension updates the syntax of the LIST command to allow for 161 multiple mailbox patterns to be specified, if they are enclosed in 162 parantheses. A mailbox name match a list of mailbox patterns if it 163 matches at least one mailbox pattern. Note that if a mailbox name 164 matches multiple mailbox patterns from the list, the server should 165 return only a single LIST response. 167 Note that the non-extended LIST command is required to treat an empty 168 ("" string) mailbox name argument as a special request to return the 169 hierarchy delimiter and the root name of the name given in the 170 reference parameter (as per [IMAP4]). However ANY extended LIST 171 command (extended in any of 3 ways specified in Section 2, or any 172 combination of therof) MUST NOT treat the empty mailbox name as such 173 special request and any regular processing described in this document 174 applies. In particular, if an extended LIST command has multiple 175 mailbox names and one (or more) of them is the empty string, the 176 empty string MUST be ignored for the purpose of matching. 178 Some servers might restrict which patterns are allowed in a LIST 179 command. If a server doesn't accept a particular pattern, it MUST 180 silently ignore it. 182 The LIST command syntax is also extended in two additional ways: by 183 adding a parenthesized list of command options between the command 184 name and the reference name (LIST selection options) and an optional 185 list of options at the end that control what kind of information 186 should be returned (LIST return options). See the formal syntax in 187 Section 6 for specific details. 189 A LIST selection option tells the server which mailbox names should 190 be selected by the LIST operation. The server should return 191 information about all mailbox names that match any of the "canonical 192 LIST pattern" (as described above) and satisfy additional selection 193 criteria (if any) specified by the LIST selection options. Let's 194 call any such mailbox name a "matched mailbox name". When multiple 195 selection options are specified, the server MUST return information 196 about mailbox names that satisfy every selection option, unless a 197 description of a particular specified option prescribes special 198 rules. An example of an option prescribing special rules is the 199 RECURSIVEMATCH selection option described later in this section. We 200 will use the term "selection criteria" when referring collectively to 201 all selection options specified in a LIST command. 203 A LIST return option controls which information is returned for each 204 matched mailbox name. Note that return options MUST NOT cause the 205 server to report information about additional mailbox names. If the 206 client has not specified any return option, only information about 207 attributes should be returned by the server. (Of course the server 208 is allowed to include any other information at will.) 210 Both selection and return command options will be defined in this 211 document and in approved extension documents; each option will be 212 enabled by a capability string (one capability may enable multiple 213 options), and a client MUST NOT send an option for which the server 214 has not advertised support. A server MUST respond to options it does 215 not recognize with a BAD response. The client SHOULD NOT specify any 216 option more than once, however if the client does this, the server 217 MUST act as if it received the option only once. The order in which 218 options are specified by the client is not significant. 220 In general, each selection option except for RECURSIVEMATCH will have 221 a corresponding return option. The REMOTE selection option is an 222 anomaly in this regard, and does not have a corresponding return 223 option. That is because it expands, rather than restricts, the set 224 of mailboxes that are returned. Future extensions to this 225 specification should keep parallelism in mind, and define a pair of 226 corresponding options. 228 This extension is identified by the capability string "LISTEXT", and 229 support for it is a prerequisite for any future extensions that 230 require specialized forms of the LIST command. Such extensions MUST 231 refer to this document and MUST add their function through command 232 options as described herein. Note that extensions that don't require 233 support for an extended LIST command, but use extended LIST responses 234 (see below), don't need to advertise the "LISTEXT" capability string. 236 This extension also defines extensions to the LIST response, allowing 237 a series of extended fields at the end, a parenthesized list of 238 tagged data (also referred to as "extended data item"). The first 239 element of an extended field is a tag, which identifies type of the 240 data. Tags MUST be registered with IANA, as described in Section 8.5 241 of this document. An example of such extended set might be 243 ((tablecloth (("fringe" "lacy")("color" "white")))(X-Sample 244 "text")) 246 or... 248 ((tablecloth ("fringe" "lacy"))(X-Sample "text" "and even more 249 text")) 251 See the formal grammar, below, for the full syntactic details. The 252 server MUST NOT return any extended data item, unless the client has 253 expressed its ability to support extended LIST responses, for example 254 by using an extended LIST command. The server MAY return data in the 255 extended fields that was not solicited by the client. The client 256 MUST ignore all extended fields it doesn't recognize. 258 The LISTEXT capability also defines several new mailbox attributes. 260 The "\NonExistent" attribute indicates that a mailbox does not 261 actually exist. Note that this attribute is not meaningful by 262 itself, as mailboxes that match the canonical LIST pattern but don't 263 exist must not be returned unless one of the two conditions listed 264 below is also satisfied: 266 a. the mailbox also satisfies the selection criteria (for example, 267 its name is subscribed and the "SUBSCRIBED" selection option has 268 been specified) 270 b. "RECURSIVEMATCH" has been specified, and the mailbox has at least 271 one child mailbox that matches the LIST pattern and selection 272 criteria. 274 In practice this means that the "\NonExistent" attribute is usually 275 returned with one or more of "\Subscribed", "\Remote" or the 276 CHILDINFO extended data item (see their description below). 278 The "\NonExistent" attribute implies "\NoSelect". The "\NonExistent" 279 attribute MUST be supported and MUST be accurately computed. 281 The selection options defined in this specification are 283 SUBSCRIBED - causes the LIST command to list subscribed names, rather 284 than the existing mailboxes. This will often be a subset of the 285 actual mailboxes. It's also possible for this list to contain the 286 names of mailboxes that don't exist. In any case, the list MUST 287 include exactly those mailbox names that match the canonical list 288 pattern and are subscribed to. This option is intended to 289 supplement the LSUB command. Of particular note are the mailbox 290 attributes as returned by this option, compared with what is 291 returned by LSUB. With the latter, the attributes returned may 292 not reflect the actual attribute status on the mailbox name, and 293 the \NoSelect attribute has a special meaning (it indicates that 294 this mailbox is not, itself, subscribed, but that it has child 295 mailboxes that are). With the SUBSCRIBED selection option 296 described here, the attributes are accurate, complete, and have no 297 special meanings. "LSUB" and "LIST (SUBSCRIBED)" are, thus, not 298 the same thing, and some servers must do significant extra work to 299 respond to "LIST (SUBSCRIBED)". Because of this, clients SHOULD 300 continue to use "LSUB" unless they specifically want the 301 additional information offered by "LIST (SUBSCRIBED)". 303 This option defines a new mailbox attribute, "\Subscribed", that 304 indicates that a mailbox name is subscribed to. The "\Subscribed" 305 attribute MUST be supported and MUST be accurately computed when 306 the SUBSCRIBED selection option is specified. 308 Note that the SUBSCRIBED selection option implies the SUBSCRIBED 309 return option (see below). 311 REMOTE - causes the LIST command to show remote mailboxes as well as 312 local ones, as described in [MBRef]. This option is intended to 313 replace the RLIST command and, in conjunction with the SUBSCRIBED 314 selection option, the RLSUB command. 316 This option defines a new mailbox attribute, "\Remote", that 317 indicates that a mailbox is a remote mailbox. The "\Remote" 318 attribute MUST be accurately computed when the REMOTE option is 319 specified. 321 Note that a server implementation that doesn't support any remote 322 mailboxes is compliant with this specification as long as it 323 accepts and ignores the REMOTE selection option. Note that if the 324 server choses to ignore the REMOTE selection option, it still has 325 to treat RECURSIVEMATCH REMOTE as a valid combination of selection 326 options (see also the description of the RECURSIVEMATCH option 327 below). 329 RECURSIVEMATCH - this option forces the server to return information 330 about parent mailboxes that don't match other selection options, 331 but have some submailboxes that do. Information about children is 332 returned in the CHILDINFO extended data item, as described in 333 Section 3.3. 335 Note 1: In order for a parent mailbox to be returned, it still has 336 to match the canonical LIST pattern. 338 Note 2: When returning the CHILDINFO extended data item, it 339 doesn't matter if the submailbox matches the canonical LIST 340 pattern or not. See also example 9 in Section 5. [[anchor2: Is 341 this really what we want? Why?]] 343 The RECURSIVEMATCH option MUST NOT occur as the only selection 344 option, as it only makes sense when other selection options are 345 also used. The server MUST return BAD tagged response in such 346 case. 348 Note that even if RECURSIVEMATCH option is specified, the client 349 MUST still be able to handle a case when a CHILDINFO extended data 350 item is returned and there are no submailboxes that meet the 351 selection criteria of the given LIST command, as they can be 352 deleted/renamed after the LIST response was sent, but before the 353 client had a chance to access them. 355 The return options defined in this specification are 357 SUBSCRIBED - causes the LIST command to return subscription state for 358 all matching mailbox names. The "\Subscribed" attribute MUST be 359 supported and MUST be accurately computed when the SUBSCRIBED 360 return option is specified. Further, all mailbox flags MUST be 361 accurately computed (this differs from the behaviour of the LSUB 362 command). 364 CHILDREN - Requests mailbox child information as originally proposed 365 in [CMbox]. See Section 4, below, for details. This option MUST 366 be supported by all servers. 368 3.1 General principles for returning LIST responses 370 This section outlines several principles that can be used by server 371 implementations of this document to decide if a LIST response should 372 be returned, as well as how many responses and what kind of 373 information they may contain. 375 1. Exactly one LIST response should be returned for each mailbox 376 name which matches the canonical LIST pattern. Server 377 implementors must not assume that clients will be able to 378 assemble mailbox attributes and other information returned in 379 multiple LIST responses. 381 2. There are only two reasons for including a matching mailbox name 382 in the responses to the LIST command (Note that the server is 383 allowed to return unsolicited responses at any time. Such 384 responses are not governed by this rule): 386 A. the mailbox name also satisfies the selection criteria; 388 B. the mailbox name doesn't satisfy the selection criteria, but 389 it has at least one child mailbox name that satisfies the 390 selection criteria and that doesn't match the canonical LIST 391 pattern. 392 For more information on this case see the CHILDINFO extended 393 data item described in Section 3.3. Note that the CHILDINFO 394 extended data item can only be returned when the 395 RECURSIVEMATCH selection option is specified. 397 3. Attributes returned in the same LIST response must be treated 398 additively. For example the following response 399 S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach" 401 means that the "Fruit/Peach" mailbox doesn't exist, but it is 402 subscribed. 404 3.2 Additional requirements on LISTEXT clients 406 All clients that support this extension MUST treat an attribute with 407 a stronger meaning, as implying any attribute that can be inferred 408 from it. For example, the client must treat presence of the 409 \NoInferiors attribute as if the \HasNoChildren attribute was also 410 sent by the server. 412 The following table summarizes inference rules described in 413 Section 3. 415 +--------------------+-------------------+ 416 | returned attribute | implied attribute | 417 +--------------------+-------------------+ 418 | \NoInferiors | \HasNoChildren | 419 | | | 420 | \NonExistent | \NoSelect | 421 +--------------------+-------------------+ 423 3.3 CHILDINFO extended data item 425 The CHILDINFO extended data item MUST only be returned when the 426 client has specified the RECURSIVEMATCH selection option. 428 The CHILDINFO extended data item in a LIST response describes the 429 selection criteria that has caused it to be returned and indicates 430 that the mailbox has st least one child mailbox that matches the 431 selection criteria. 433 The LSUB command indicates this condition by using the "\NoSelect" 434 attribute, but the LIST (SUBSCRIBED) command MUST NOT do that, since 435 "\NoSelect" retains its original meaning here. Further, the 436 CHILDINFO extended data item is more general, in that it can be used 437 with any extended set of selection criteria. 439 The returned selection criteria allow the client to distinguish a 440 solicited response from an unsolicited one, as well as to distinguish 441 among solicited responses caused by multiple pipelined LIST commands 442 that specify different criteria. 444 Servers SHOULD ONLY return a non-matching mailbox name along with 445 CHILDINFO if at least one matching child is not also being returned. 447 That is, servers SHOULD suppress redundant CHILDINFO responses. 448 [[anchor3: Should this be a MUST?]] 450 Examples 8 and 10 in Section 5 demonstrate the difference between 451 present CHILDINFO extended data item and the "\HasChildren" 452 attribute. 454 The following table summarizes interaction between the "\NonExistent" 455 attribute and CHILDINFO (the first collumn describes if the parent 456 mailbox exists): 458 +----------------+----------------+----------------+----------------+ 459 | exists | meets the | has a child | returned | 460 | | selection | that meets the | LISTEXT | 461 | | criteria | selection | attributes and | 462 | | | criteria | CHILDINFO | 463 +----------------+----------------+----------------+----------------+ 464 | no | no | no | no LIST | 465 | | | | response | 466 | | | | returned | 467 | | | | | 468 | yes | no | no | no LIST | 469 | | | | response | 470 | | | | returned | 471 | | | | | 472 | no | yes | no | (\NonExistent | 473 | | | | ) | 474 | | | | | 475 | yes | yes | no | () | 476 | | | | | 477 | no | no | yes | (\NonExistent) | 478 | | | | + CHILDINFO | 479 | | | | | 480 | yes | no | yes | () + CHILDINFO | 481 | | | | | 482 | no | yes | yes | (\NonExistent | 483 | | | | ) + | 484 | | | | CHILDINFO | 485 | | | | | 486 | yes | yes | yes | () + | 487 | | | | CHILDINFO | 488 +----------------+----------------+----------------+----------------+ 490 where is one or more attributes that correspond to the 491 selection criteria, for example for the SUBSCRIBED option the 492 is \Subscribed. 494 4. The CHILDREN return Option 496 The CHILDREN return option implements the Child Mailbox Extension, 497 originally proposed by Mike Gahrns and Raymond Cheng, of Microsoft 498 Corporation. Most of the information in this section is taken 499 directly from their original specification [CMbox]. The CHILDREN 500 return option is simply an indication that the client wants this 501 information; a server MAY provide it even if the option is not 502 specified. 504 Many IMAP4 [IMAP4] clients present to the user a hierarchical view of 505 the mailboxes that a user has access to. Rather than initially 506 presenting to the user the entire mailbox hierarchy, it is often 507 preferable to show to the user a collapsed outline list of the 508 mailbox hierarchy (particularly if there is a large number of 509 mailboxes). The user can then expand the collapsed outline hierarchy 510 as needed. It is common to include within the collapsed hierarchy a 511 visual clue (such as a ''+'') to indicate that there are child 512 mailboxes under a particular mailbox. When the visual clue is 513 clicked the hierarchy list is expanded to show the child mailboxes. 514 The CHILDREN return option provides a mechanism for a client to 515 efficiently determine if a particular mailbox has children, without 516 issuing a LIST "" * or a LIST "" % for each mailbox name. The 517 CHILDREN return option defines two new attributes that MAY be 518 returned within a LIST response: \HasChildren and \HasNoChildren. 519 While these attributes MAY be returned in response to any LIST 520 command, the CHILDREN return option is provided to indicate that the 521 client particularly wants this information. If the CHILDREN return 522 option is present, the server MUST return these attributes even if 523 their computation is expensive. 525 \HasChildren 526 The presence of this attribute indicates that the mailbox has 527 child mailboxes. A server SHOULD NOT set this attribute if 528 there are child mailboxes, and the user does not have 529 permissions to access any of them. In this case, \HasNoChildren 530 SHOULD be used. In many cases, however, a server may not be 531 able to efficiently compute whether a user has access to all 532 child mailboxes. As such a client MUST be prepared to accept 533 the \HasChildren attribute as a hint. That is, a mailbox MAY be 534 flagged with the \HasChildren attribute, but no child mailboxes 535 will appear in the LIST response. 537 \HasNoChildren 538 The presence of this attribute indicates that the mailbox has NO 539 child mailboxes that are accessible to the currently 540 authenticated user. 542 In some instances a server that supports the LISTEXT extension might 543 not be able to determine whether a mailbox has children. For example 544 it may have difficulty determining whether there are child mailboxes 545 when LISTing mailboxes while operating in a particular namespace. In 546 these cases, a server MAY exclude both the \HasChildren and 547 \HasNoChildren attributes in the LIST response. As such, a client 548 can not make any assumptions about whether a mailbox has children 549 based upon the absence of a single attribute. In particular, some 550 servers may not be able to combine the SUBSCRIBED selection option 551 and CHILDREN return option. Such servers MUST honour the SUBSCRIBED 552 selection option, and they will simply ignore the CHILDREN return 553 option if both are requested. It is an error for the server to 554 return both a \HasChildren and a \HasNoChildren attribute in a LIST 555 response. 557 Note: the \HasNoChildren attribute should not be confused with the 558 IMAP4 [IMAP4] defined attribute \NoInferiors which indicates that no 559 child mailboxes exist now and none can be created in the future. 561 5. Examples 563 1: The first example shows the complete local hierarchy that will be 564 used for the other examples. 566 C: A01 LIST "" "*" 567 S: * LIST (\Marked \NoInferiors) "/" "inbox" 568 S: * LIST () "/" "Fruit" 569 S: * LIST () "/" "Fruit/Apple" 570 S: * LIST () "/" "Fruit/Banana" 571 S: * LIST () "/" "Tofu" 572 S: * LIST () "/" "Vegetable" 573 S: * LIST () "/" "Vegetable/Broccoli" 574 S: * LIST () "/" "Vegetable/Corn" 575 S: A01 OK done 577 2: In the next example, we'll see the subscribed mailboxes. This is 578 similar to, but not equivalent with, . Note that 579 the mailbox called "Fruit/Peach" is subscribed to, but does not 580 actually exist (perhaps it was deleted while still subscribed). 581 The "Fruit" mailbox is not subscribed to, but it has two 582 subscribed children. The "Vegetable" mailbox is subscribed and 583 has two children, one of them is subscribed as well. 585 C: A02 LIST (SUBSCRIBED) "" "*" 586 S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox" 587 S: * LIST (\Subscribed) "/" "Fruit/Banana" 588 S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach" 589 S: * LIST (\Subscribed) "/" "Vegetable/Broccoli" 590 S: A02 OK done 592 3: The next example shows the use of the CHILDREN option. The 593 client, without having to list the second level of hierarchy, now 594 knows which of the top-level mailboxes have submailboxes 595 (children) and which do not. Note that it's not necessary for 596 the server to return the \HasNoChildren attribute for the inbox, 597 because the \NoInferiors attribute already implies that, and has 598 a stronger meaning. 600 C: A03 LIST () "" "%" RETURN (CHILDREN) 601 S: * LIST (\Marked \NoInferiors) "/" "inbox" 602 S: * LIST (\HasChildren) "/" "Fruit" 603 S: * LIST (\HasNoChildren) "/" "Tofu" 604 S: * LIST (\HasChildren) "/" "Vegetable" 605 S: A03 OK done 607 4: In this example we see more mailboxes, which reside on another 608 server to which we may obtain referrals. This is similar to the 609 command . Note that in the case of the remote 610 mailboxes, the server might or might not be able to include 611 CHILDREN information; it includes it if it can, and omits it if 612 it can't. 614 C: A04 LIST (REMOTE) "" "%" RETURN (CHILDREN) 615 S: * LIST (\Marked \NoInferiors) "/" "inbox" 616 S: * LIST (\HasChildren) "/" "Fruit" 617 S: * LIST (\HasNoChildren) "/" "Tofu" 618 S: * LIST (\HasChildren) "/" "Vegetable" 619 S: * LIST (\Remote) "/" "Bread" 620 S: * LIST (\HasChildren \Remote) "/" "Meat" 621 S: A04 OK done 623 5: The following example also requests the server to include 624 mailboxes, which reside on another server. The server returns 625 information about all mailboxes which are subscribed. This is 626 similar to the command . We also see the use of 627 two selection options. 629 C: A05 LIST (REMOTE SUBSCRIBED) "" "*" 630 S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox" 631 S: * LIST (\Subscribed) "/" "Fruit/Banana" 632 S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach" 633 S: * LIST (\Subscribed) "/" "Vegetable" 634 S: * LIST (\Subscribed) "/" "Vegetable/Broccoli" 635 S: * LIST (\Remote \Subscribed) "/" "Bread" 636 S: A05 OK done 638 6: The following example requests the server to include mailboxes, 639 which reside on another server. The server is requested to 640 return subscription information for all returned mailboxes. This 641 is different from the example above. 643 Note that the output of this command is not a superset of the 644 output in the previous example, as it doesn't include LIST 645 response for the non-existent "Fruit/Peach". 647 C: A06 LIST (REMOTE) "" "*" RETURN (SUBSCRIBED) 648 S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox" 649 S: * LIST () "/" "Fruit" 650 S: * LIST () "/" "Fruit/Apple" 651 S: * LIST (\Subscribed) "/" "Fruit/Banana" 652 S: * LIST () "/" "Tofu" 653 S: * LIST (\Subscribed) "/" "Vegetable" 654 S: * LIST (\Subscribed) "/" "Vegetable/Broccoli" 655 S: * LIST () "/" "Vegetable/Corn" 656 S: * LIST (\Remote \Subscribed) "/" "Bread" 657 S: * LIST (\Remote) "/" "Meat" 658 S: A06 OK done 660 7: In the following example the client has specified multiple 661 mailbox patterns. Note that this example doesn't use the mailbox 662 hierarchy used in the previous examples. 664 C: BBB LIST "" ("INBOX" "Drafts" "Sent/%") 665 S: * LIST () "/" "INBOX" 666 S: * LIST (\NoInferiors) "/" "Drafts" 667 S: * LIST () "/" "Sent/March2004" 668 S: * LIST (\Marked) "/" "Sent/December2003" 669 S: * LIST () "/" "Sent/August2004" 670 S: BBB OK done 672 8: The following example demonstates the difference between 673 \HasChildren attribute and CHILDINFO extended data item. 675 Let's assume there is the following hierarchy: 677 C: C01 LIST "" "*" 678 S: * LIST (\Marked \NoInferiors) "/" "inbox" 679 S: * LIST () "/" "Foo" 680 S: * LIST () "/" "Foo/Bar" 681 S: * LIST () "/" "Foo/Baz" 682 S: * LIST () "/" "Moo" 683 S: C01 OK done 685 If the client asks RETURN (CHILDREN) it will get this: 687 C: CA3 LIST "" "%" RETURN (CHILDREN) 688 S: * LIST (\Marked \NoInferiors) "/" "inbox" 689 S: * LIST (\HasChildren) "/" "Foo" 690 S: * LIST (\HasNoChildren) "/" "Moo" 691 S: CA3 OK done 693 A) Let's also assume that the mailbox "Foo/Baz" is the only 694 subscribed mailbox. Then we get this result: 696 C: C02 LIST (SUBSCRIBED) "" "*" 697 S: * LIST (\Subscribed) "/" "Foo/Baz" 698 S: C02 OK done 700 Now, if the client issues , the server 701 will return no mailboxes (as the mailboxes "Moo", "Foo" and 702 "Inbox" are NOT subscribed). However, if the client issues this: 704 C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" 705 S: * LIST () "/" "Foo" (("CHILDINFO" ("SUBSCRIBED"))) 706 S: C04 OK done 708 i.e. the mailbox "Foo" is not subscribed, but it has a child 709 that is. 711 A1) If the mailbox "Foo" had been subscribed instead, the last 712 command would return this: 714 C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" 715 S: * LIST (\Subscribed) "/" "Foo" (("CHILDINFO" 716 ("SUBSCRIBED"))) 717 S: C04 OK done 719 or even this: 721 C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" 722 S: * LIST (\Subscribed \HasChildren) "/" "Foo" (("CHILDINFO" 723 ("SUBSCRIBED"))) 724 S: C04 OK done 726 A2) If we assume instead that the mailbox "Foo" is not part of 727 the original hierarchy and is not subscribed, the last command 728 will give this result: 730 C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" 731 S: * LIST (\NonExistent) "/" "Foo" (("CHILDINFO" 732 ("SUBSCRIBED"))) 733 S: C04 OK done 735 B) Now, let's assume that no mailbox is subscribed. In this case 736 the command will return 737 no responses, as there are no subscribed children (even though 738 "Foo" has children). 740 C) And finally, suppose that only the mailboxes "Foo" and "Moo" 741 are subscribed. In that case we see this result: 743 C: LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" RETURN (CHILDREN) 744 S: * LIST (\HasChildren \Subscribed) "/" "Foo" 745 S: * LIST (\HasNoChildren \Subscribed) "/" "Moo" 747 (which means that the mailbox "Foo" has children, but none of 748 them is subscribed). 750 9: The following example demonstrates that the CHILDINFO extended 751 data item is returned whether children mailboxes match the 752 canonical LIST pattern or not. 754 Let's assume there is the following hierarchy: 756 C: D01 LIST "" "*" 757 S: * LIST (\Marked \NoInferiors) "/" "inbox" 758 S: * LIST () "/" "foo2" 759 S: * LIST () "/" "foo2/bar1" 760 S: * LIST () "/" "foo2/bar2" 761 S: * LIST () "/" "baz2" 762 S: * LIST () "/" "baz2/bar2" 763 S: * LIST () "/" "baz2/bar22" 764 S: * LIST () "/" "baz2/bar222" 765 S: * LIST () "/" "eps2" 766 S: * LIST () "/" "eps2/mamba" 767 S: * LIST () "/" "quux2/bar2" 768 S: D01 OK done 770 And that the following mailboxes are subscribed: 772 C: D02 LIST (SUBSCRIBED) "" "*" 773 S: * LIST (\Subscribed) "/" "foo2/bar1" 774 S: * LIST (\Subscribed) "/" "foo2/bar2" 775 S: * LIST (\Subscribed) "/" "baz2/bar2" 776 S: * LIST (\Subscribed) "/" "baz2/bar22" 777 S: * LIST (\Subscribed) "/" "baz2/bar222" 778 S: * LIST (\Subscribed) "/" "eps2" 779 S: * LIST (\Subscribed) "/" "eps2/mamba" 780 S: * LIST (\Subscribed) "/" "quux2/bar2" 781 S: D02 OK done 783 The client issues the following command first: 785 C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*2" 786 S: * LIST () "/" "foo2" (("CHILDINFO" ("SUBSCRIBED"))) 787 S: * LIST (\Subscribed) "/" "foo2/bar2" 788 S: * LIST () "/" "baz2" (("CHILDINFO" ("SUBSCRIBED"))) 789 S: * LIST (\Subscribed) "/" "baz2/bar2" 790 S: * LIST (\Subscribed) "/" "baz2/bar22" 791 S: * LIST (\Subscribed) "/" "baz2/bar222" 792 S: * LIST (\Subscribed) "/" "eps2" (("CHILDINFO" 793 ("SUBSCRIBED"))) 794 S: * LIST (\Subscribed) "/" "quux2/bar2" 795 S: D03 OK done 797 and the server may also include 799 S: * LIST (\NonExistent) "/" "quux2" (("CHILDINFO" 800 ("SUBSCRIBED"))) 802 The CHILDINFO extended data item is returned for mailboxes 803 "foo2", "baz2" and "eps2", because all of them have subscribed 804 children, even though for the mailbox "foo2" only one of the two 805 subscribed children match the pattern, for the mailbox "baz2" all 806 the subscribed children match the pattern and for the mailbox 807 "eps2" none of the subscribed children match the pattern. 809 Note that if the client issues 811 C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*" 812 S: * LIST () "/" "foo2" (("CHILDINFO" ("SUBSCRIBED"))) 813 S: * LIST (\Subscribed) "/" "foo2/bar1" 814 S: * LIST (\Subscribed) "/" "foo2/bar2" 815 S: * LIST () "/" "baz2" (("CHILDINFO" ("SUBSCRIBED"))) 816 S: * LIST (\Subscribed) "/" "baz2/bar2" 817 S: * LIST (\Subscribed) "/" "baz2/bar22" 818 S: * LIST (\Subscribed) "/" "baz2/bar222" 819 S: * LIST (\Subscribed) "/" "eps2" (("CHILDINFO" 820 ("SUBSCRIBED"))) 821 S: * LIST (\Subscribed) "/" "eps2/mamba" 822 S: * LIST (\Subscribed) "/" "quux2/bar2" 823 S: D03 OK done 825 the LIST responses for mailboxes "foo2", "baz2" and "eps2" still 826 have the CHILDINFO extended data item, even though this 827 information is redundant and the client can determine it by 828 itself. 830 10: The following example shows usage of multiple mailbox patterns. 831 It also demonstrates that the presence of the CHILDINFO extended 832 data item doesn't necessarily imply \HasChildren. 834 C: a1 LIST "" ("foo" "foo/*") 835 S: * LIST () "/" foo 836 S: a1 OK done 838 C: a2 LIST (SUBSCRIBED) "" "foo/*" 839 S: * LIST (\Subscribed \NonExistent) "/" foo/bar 840 S: a2 OK done 842 C: a3 LIST (SUBSCRIBED RECURSIVEMATCH) "" foo RETURN 843 (CHILDREN) 844 S: * LIST (\HasNoChildren) "/" foo (("CHILDINFO" 845 ("SUBSCRIBED"))) 846 S: a3 OK done 848 6. Formal Syntax 850 The following syntax specification uses the augmented Backus-Naur 851 Form (BNF) as described in [ABNF]. Terms not defined here are taken 852 from [IMAP4]. 854 "vendor-token" is defined in [ACAP]. [[anchor4: This is an issue in 855 moving forward, since ACAP will never move to Draft Standard. Should 856 we define vendor-token here, and also define the IANA registry here? 857 Should we put it into another document? Is there someplace else we 858 can get the same definition?]] 860 childinfo-extended-item = "CHILDINFO" SP "(" 861 list-select-base-opt-quoted 862 *( SP list-select-base-opt-quoted ) ")" 863 ; Extended data item returned when the RECURSIVEMATCH 864 ; selection option is specified. 865 ; Note 1: the CHILDINFO tag can be returned 866 ; with and without surrounding quotes, as per 867 ; mbox-list-extended-item-tag production. 868 ; Note 2: The selection options are returned quoted, 869 ; unlike their specification in the extended LIST 870 ; command. 872 child-mbox-flag = "\HasChildren" / "\HasNoChildren" 873 ; attributes for CHILDREN return option, at most one 874 ; possible per LIST response 876 eitem-standard-tag = atom 877 ; a tag for extended list data defined in a Standard 878 ; Track or Experimental RFC. 880 eitem-vendor-tag = vendor-tag 881 ; a vendor specific tag for extended list data 883 list = "LIST" [SP list-select-opts] SP mailbox SP mbox-or-pat 884 [SP list-return-opts] 886 list-select-opts = "(" [*(list-select-mod-opt SP) 887 list-select-base-opt 888 *(SP list-select-opt)] ")" 889 ; list selection options, e.g. REMOTE 891 list-select-opt = list-select-mod-opt / list-select-base-opt 892 ; An option registration template is described in 893 ; Section 8.3 of this document. 895 list-select-base-opt = "SUBSCRIBED" / "REMOTE" / option-extension 896 ; options that can be used by themselves 898 list-select-base-opt-quoted = <"> list-select-base-opt <"> 900 list-select-mod-opt = "RECURSIVEMATCH" / option-extension 901 ; options that require a list-select-base-opt 902 ; to also be present 904 list-return-opts = "RETURN" SP "(" [return-option *(SP 905 return-option)] ")" 906 ; list return options, e.g. CHILDREN 908 mailbox-list = "(" [mbx-list-flags] ")" SP 909 (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox 910 [SP mbox-list-extended] 912 mbox-list-extended = "(" [mbox-list-extended-item 913 *(SP mbox-list-extended-item)] ")" 915 mbox-list-extended-item = "(" mbox-list-extended-item-data ")" 917 mbox-list-extended-item-data = mbox-list-extended-item-tag SP 918 nstring-list 920 mbox-list-extended-item-tag = astring 921 ; The content MUST conform to either "eitem-vendor-tag" 922 ; or "eitem-standard-tag" ABNF productions. 923 ; A tag registration template is described in this 924 document 925 ; in Section 8.5. 927 mbox-list-oflag = child-mbox-flag / "\NonExistent" / 928 / "\Subscribed" / "\Remote" 930 mbox-or-pat = list-mailbox / patterns 932 nstring-list = nstring / 933 "(" [nstring-list *(SP nstring-list)] ")" 934 ; a recursive list definition 936 option-extension = option-vendor-tag / option-standard-tag 938 option-vendor-tag = vendor-tag 939 ; a vendor specific option 941 option-standard-tag = atom 942 ; an option defined in a Standard Track or 943 ; Experimental RFC 945 patterns = "(" list-mailbox *(SP list-mailbox) ")" 947 return-option = "SUBSCRIBED" / "CHILDREN" / 948 option-extension 950 vendor-tag = vendor-token "-" atom 952 7. Security Considerations 954 This document describes syntactic changes to the specification of the 955 IMAP4 commands LIST, LSUB, RLIST, and RLSUB, and the modified LIST 956 command has the same security considerations as those commands. They 957 are described in [IMAP4] and [MBRef]. 959 The Child Mailbox Extension provides a client a more efficient means 960 of determining whether a particular mailbox has children. If a 961 mailbox has children, but the currently authenticated user does not 962 have access to any of them, the server SHOULD respond with a 963 \HasNoChildren attribute. In many cases, however, a server may not 964 be able to efficiently compute whether a user has access to all child 965 mailboxes. If such a server responds with a \HasChildren attribute, 966 when in fact the currently authenticated user does not have access to 967 any child mailboxes, potentially more information is conveyed about 968 the mailbox than intended. In most situations this will not be a 969 security concern, because if information regarding whether a mailbox 970 has children is considered sensitive, a user would not be granted 971 access to that mailbox in the first place. 973 The CHILDINFO extended data item has the same security considerations 974 as the \HasChildren attribute described above. 976 8. IANA Considerations 978 8.1 Guidelines for IANA 980 It is requested that IANA creates two new registries for LISTEXT 981 options and LISTEXT extended response data. The templates and the 982 initial registrations are detailed below. 984 8.2 Registration procedure and Change control 986 Registration of a LISTEXT option is done by filling in the template 987 in Section 8.3 and sending it via electronic mail to iana@iana.org. 988 Registration of a LISTEXT extended data item is done by filling in 989 the template in Section 8.5 and sending it via electronic mail to 990 iana@iana.org. IANA has the right to reject obviously bogus 991 registrations, but will perform no review of claims made in the 992 registration form. 994 A LISTEXT option/extended data item name that starts with "V-" is 995 reserved for vendor specific options/extended data items. All 996 options, whether they are vendor specific or global, should be 997 registered with IANA. If a LISTEXT extended data item is returned as 998 a result of requesting a particular LISTEXT option, the name of the 999 option SHOULD be used as the name of the LISTEXT extended data item. 1001 Each vendor specific options/extended data item MUST start with their 1002 vendor-token ("vendor prefix"). The vendor-token MUST be registered 1003 with IANA, using the [ACAP] vendor subtree registry. 1005 Standard LISTEXT option/extended data item names are case 1006 insensitive. If the vendor prefix is omitted from a vendor specific 1007 LISTEXT option/extended data item name, the rest is case insensitive. 1008 The vendor prefix itself is not case-sensitive, as it might contain 1009 non-ASCII characters. 1011 While the registration procedures do not require it, authors of 1012 LISTEXT options/extended data items are encouraged to seek community 1013 review and comment whenever that is feasible. Authors may seek 1014 community review by posting a specification of their proposed 1015 mechanism as an Internet- Draft. LISTEXT options/extended data items 1016 intended for widespread use should be standardized through the normal 1017 IETF process, when appropriate. 1019 Comments on registered LISTEXT options/extended response data should 1020 first be sent to the "owner" of the mechanism and/or to the IMAPEXT 1021 WG mailing list. Submitters of comments may, after a reasonable 1022 attempt to contact the owner, request IANA to attach their comment to 1023 the registration itself. If IANA approves of this, the comment will 1024 be made accessible in conjunction with the registration LISTEXT 1025 options/ extended response data itself. 1027 Once a LISTEXT registration has been published by IANA, the author 1028 may request a change to its definition. The change request follows 1029 the same procedure as the registration request. 1031 The owner of a LISTEXT registration may pass responsibility for the 1032 registered option/extended data item to another person or agency by 1033 informing IANA; this can be done without discussion or review. 1035 The IESG may reassign responsibility for a LISTEXT option/extended 1036 data item. The most common case of this will be to enable changes to 1037 be made to mechanisms where the author of the registration has died, 1038 moved out of contact or is otherwise unable to make changes that are 1039 important to the community. 1041 LISTEXT registrations may not be deleted; mechanisms which are no 1042 longer believed appropriate for use can be declared OBSOLETE by a 1043 change to their "intended use" field; such LISTEXT options/extended 1044 data items will be clearly marked in the lists published by IANA. 1046 The IESG is considered to be the owner of all LISTEXT 1047 options/extended data items which are on the IETF standards track. 1049 8.3 Registration template for LISTEXT options 1051 To: iana@iana.org 1052 Subject: Registration of LISTEXT option X 1054 LISTEXT option name: 1056 LISTEXT option type: (One of SELECTION or RETURN) 1058 Implied return options(s), if the option type is SELECTION: (zero or 1059 more) 1061 LISTEXT option description: 1063 Published specification (optional, recommended): 1065 Security considerations: 1067 Intended usage: 1068 (One of COMMON, LIMITED USE or OBSOLETE) 1070 Person and email address to contact for further information: 1072 Owner/Change controller: 1074 (Any other information that the author deems interesting may be added 1075 below this line.) 1077 8.4 Initial LISTEXT option registrations 1079 It is requested that the LISTEXT option registry be populated with 1080 the following entries: 1082 1. To: iana@iana.org 1083 Subject: Registration of LISTEXT option SUBSCRIBED 1085 LISTEXT option name: SUBSCRIBED 1087 LISTEXT option type: SELECTION 1089 Implied return options(s): SUBSCRIBED 1091 LISTEXT option description: Causes the LIST command to list 1092 subscribed mailboxes, rather than the actual mailboxes. 1094 Published specification : XXXX, Section 3. 1096 Security considerations: XXXX, Section 7. 1098 Intended usage: COMMON 1100 Person and email address to contact for further information: 1101 Alexey Melnikov 1103 Owner/Change controller: iesg@ietf.org 1105 2. To: iana@iana.org 1106 Subject: Registration of LISTEXT option REMOTE 1108 LISTEXT option name: REMOTE 1110 LISTEXT option type: SELECTION 1112 Implied return options(s): (none) 1114 LISTEXT option description: causes the LIST command to return 1115 remote mailboxes as well as local ones, as described in RFC 2193. 1117 Published specification : XXXX, Section 3. 1119 Security considerations: XXXX, Section 7. 1121 Intended usage: COMMON 1123 Person and email address to contact for further information: 1124 Alexey Melnikov 1126 Owner/Change controller: iesg@ietf.org 1128 3. To: iana@iana.org 1129 Subject: Registration of LISTEXT option SUBSCRIBED 1131 LISTEXT option name: SUBSCRIBED 1133 LISTEXT option type: RETURN 1135 LISTEXT option description: Causes the LIST command to return 1136 subscription state. 1138 Published specification : XXXX, Section 3. 1140 Security considerations: XXXX, Section 7. 1142 Intended usage: COMMON 1144 Person and email address to contact for further information: 1145 Alexey Melnikov 1147 Owner/Change controller: iesg@ietf.org 1149 4. To: iana@iana.org 1150 Subject: Registration of LISTEXT option RECURSIVEMATCH 1152 LISTEXT option name: RECURSIVEMATCH 1154 LISTEXT option type: SELECTION 1156 Implied return options(s): (none) 1158 LISTEXT option description: Requests that CHILDINFO extended data 1159 item is to be returned. 1161 Published specification : XXXX, Section 3. 1163 Security considerations: XXXX, Section 7. 1165 Intended usage: COMMON 1167 Person and email address to contact for further information: 1168 Alexey Melnikov 1170 Owner/Change controller: iesg@ietf.org 1172 5. To: iana@iana.org 1173 Subject: Registration of LISTEXT option CHILDREN 1175 LISTEXT option name: CHILDREN 1177 LISTEXT option type: RETURN 1179 LISTEXT option description: Requests mailbox child information. 1181 Published specification : XXXX, Section 3 and Section 4. 1183 Security considerations: XXXX, Section 7. 1185 Intended usage: COMMON 1187 Person and email address to contact for further information: 1188 Alexey Melnikov 1190 Owner/Change controller: iesg@ietf.org 1192 8.5 Registration template for LISTEXT extended data item 1194 To: iana@iana.org 1195 Subject: Registration of X LISTEXT extended data item 1197 LISTEXT extended data item tag: 1199 LISTEXT extended data item description: 1201 Which LISTEXT option(s) (and their types) causes this extended data 1202 item to be returned (if any): 1204 Published specification (optional, recommended): 1206 Security considerations: 1208 Intended usage: 1209 (One of COMMON, LIMITED USE or OBSOLETE) 1211 Person and email address to contact for further information: 1213 Owner/Change controller: 1215 (Any other information that the author deems interesting may be added 1216 below this line.) 1218 8.6 Initial LISTEXT extended data item registrations 1220 It is requested that the LISTEXT extended data item registry be 1221 populated with the following entries: 1223 1. To: iana@iana.org 1224 Subject: Registration of CHILDINFO LISTEXT extended data item 1226 LISTEXT extended data item tag: CHILDINFO 1228 LISTEXT extended data item description: The CHILDINFO extended 1229 data item describes the selection criteria that has caused it to 1230 be returned and indicates that the mailbox has one or more child 1231 mailbox that match the selection criteria. 1233 Which LISTEXT option(s) (and their types) causes this extended 1234 data item to be returned (if any): RECURSIVEMATCH selection 1235 option 1237 Published specification : XXXX, Section 3.3. 1239 Security considerations: XXXX, Section 7. 1241 Intended usage: COMMON 1243 Person and email address to contact for further information: 1244 Alexey Melnikov 1246 Owner/Change controller: iesg@ietf.org 1248 9. Acknowledgements 1250 Mike Gahrns and Raymond Cheng of Microsoft Corporation originally 1251 devised the Child Mailbox Extension and proposed it in 1997; the 1252 idea, as well as most of the text in Section 4, is theirs. 1254 This document is the result of discussions on the IMAP4 and IMAPEXT 1255 mailing lists and is meant to reflect consensus of those groups. In 1256 particular, Mark Crispin, Philip Guenther, Cyrus Daboo, Timo 1257 Sirainen, Ken Murchison, Rob Siemborski, Steve Hole, Arnt 1258 Gulbrandsen, Larry Greenfield, Dave Cridland and Pete Maclean were 1259 active participants in those discussions or made suggestions to this 1260 document. 1262 10. Normative References 1264 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1265 Specifications: ABNF", RFC 2234, November 1997. 1267 [ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration 1268 Access Protocol", RFC 2244, November 1997. 1270 [CMbox] Gahrns, M. and R. Cheng, "", RFC 3348, July 2002. 1272 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 1273 4rev1", RFC 3501, March 2003. 1275 [Kwds] Bradner, S., "Key words for use in RFCs to Indicate 1276 Requirement Levels", RFC 2119, March 1997. 1278 [MBRef] Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193, September 1279 1997. 1281 Authors' Addresses 1283 Barry Leiba 1284 IBM T.J. Watson Research Center 1285 30 Saw Mill River Road 1286 Hawthorne, NY 10532 1287 US 1289 Phone: +1 914 784 7941 1290 Email: leiba@watson.ibm.com 1291 Alexey Melnikov 1292 Isode Limited 1293 5 Castle Business Village 1294 36 Station Road 1295 Hampton, Middlesex TW12 2BX 1296 UK 1298 Email: Alexey.Melnikov@isode.com 1299 URI: http://www.melnikov.ca/ 1301 Intellectual Property Statement 1303 The IETF takes no position regarding the validity or scope of any 1304 Intellectual Property Rights or other rights that might be claimed to 1305 pertain to the implementation or use of the technology described in 1306 this document or the extent to which any license under such rights 1307 might or might not be available; nor does it represent that it has 1308 made any independent effort to identify any such rights. Information 1309 on the procedures with respect to rights in RFC documents can be 1310 found in BCP 78 and BCP 79. 1312 Copies of IPR disclosures made to the IETF Secretariat and any 1313 assurances of licenses to be made available, or the result of an 1314 attempt made to obtain a general license or permission for the use of 1315 such proprietary rights by implementers or users of this 1316 specification can be obtained from the IETF on-line IPR repository at 1317 http://www.ietf.org/ipr. 1319 The IETF invites any interested party to bring to its attention any 1320 copyrights, patents or patent applications, or other proprietary 1321 rights that may cover technology that may be required to implement 1322 this standard. Please address the information to the IETF at 1323 ietf-ipr@ietf.org. 1325 Disclaimer of Validity 1327 This document and the information contained herein are provided on an 1328 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1329 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1330 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1331 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1332 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1333 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1335 Copyright Statement 1337 Copyright (C) The Internet Society (2005). This document is subject 1338 to the rights, licenses and restrictions contained in BCP 78, and 1339 except as set forth therein, the authors retain all their rights. 1341 Acknowledgment 1343 Funding for the RFC Editor function is currently provided by the 1344 Internet Society.