idnits 2.17.1 draft-ietf-imapext-list-extensions-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 777. -- Found old boilerplate from RFC 3978, Section 5.5 on line 815. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 788. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 795. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 801. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 853 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 69 instances of too long lines in the document, the longest one being 12 characters in excess of 72. ** The abstract seems to contain references ([MboxRefer]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2004) is 7223 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3501 (ref. 'IMAP4') (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 3348 (ref. 'ChildMbox') (Obsoleted by RFC 5258) Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IMAP Extensions Working Group B. Leiba 3 Internet Draft IBM T.J. Watson Research Center 4 A. Melnikov (Ed.) 5 Isode Limited 6 Expires January 2004 July 2004 8 IMAP4 LIST Command Extensions 9 draft-ietf-imapext-list-extensions-07.txt 11 Status of this Document 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, or 15 will be disclosed, and any of which I become aware will be disclosed, 16 in accordance with RFC 3668. 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 21 Internet-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 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 A revised version of this draft document will be submitted to the RFC 34 editor as an Proposed Standard for the Internet Community. 35 Discussion and suggestions for improvement are requested, and should 36 be sent to ietf-imapext@imc.org. This document will expire before 31 37 November 2004. Distribution of this memo is unlimited. 39 This documents obsoletes RFC 3348 and updates RFC 2193. 41 Abstract 43 IMAP4 has two commands for listing mailboxes: LIST and LSUB. As we 44 have added extensions that have required specialized lists (see 45 [MboxRefer] for an example) we have had to expand the number of list 46 commands, since each extension must add its function to both LIST and 47 LSUB, and these commands are not, as they are defined, extensible. 48 If we've needed the extensions to work together, we've had to add a 49 set of commands to mix the different options, the set increasing in 50 size with each new extension. This document describes an extension 51 to the base LIST command that will allow these additions to be done 52 with mutually compatible options to the LIST command, avoiding the 53 exponential increase in specialized list commands. 55 1. Conventions used in this document 57 In examples, "C:" indicates lines sent by a client that is connected 58 to a server. "S:" indicates lines sent by the server to the client. 60 The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are 61 used in this document as specified in RFC 2119 [Keywords]. 63 The term "canonical LIST pattern" refers to 64 the canonical pattern constructed internally by the server from 65 the reference and mailbox name arguments (Section 6.3.8 of [IMAP4]). 66 The [IMAP4] LIST command returns only mailboxes that match the 67 canonical LIST pattern. 69 2. Introduction and overview 71 The extensions to the LIST command will be accomplished by amending 72 the syntax to allow options to be specified. The list of options 73 will replace the several commands that are currently used to mix and 74 match the information requested. The new syntax is backward- 75 compatible, with no ambiguity: if the first word after the command 76 name begins with a parenthesis, the new syntax is being used; if it 77 does not, it's in the original syntax. 79 By adding options to the LIST command, we are announcing the intent 80 to phase out and eventually to deprecate the RLIST and RLSUB commands 81 described in [MboxRefer]. We are also defining the mechanism to 82 request extended mailbox information, such as is described in the 83 "Child Mailbox Extension" [ChildMbox]. The base 84 LSUB command is not deprecated by this extension; rather, this 85 extension adds a way to obtain subscription information with more 86 options, with those server implementations that support it. Clients 87 that simply need a list of subscribed mailboxes, as provided by the 88 LSUB command, SHOULD continue to use that command. 90 This document defines an IMAP4 extension that is identified by the 91 capability string "LISTEXT". The LISTEXT extension makes the 92 following changes to the IMAP4 protocol, which are described in 93 more details in sections 3 and 4 of this document: 95 a. defines new syntax for LIST command options. 96 b. adds LIST command options: SUBSCRIBED, REMOTE and CHILDREN 97 c. adds new mailbox flags "\NonExistent", "\PlaceHolder", 98 "\Subscribed", "\Remote", "\HasSubmailboxes", 99 "\HasChildren" and "\HasNoChildren". 101 2.1. General principals for returning LIST responses 103 This section outlines several principals that can be used by 104 implementors of this document to decide if a LIST response should be 105 returned, as well as how many responses and what kind of information 106 they may contain. 108 1) Exactly one LIST response should be returned for each mailbox 109 name which matches the canonical LIST pattern. 110 Server implementors must not assume that clients will be able to 111 assemble mailbox flags and other information returned in multiple 112 LIST responses. 114 <> 126 3) Flags returned in the same LIST response must be treated additively. 127 For example the following response 129 S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach" 131 means that the "Fruit/Peach" mailbox doesn't exist, but it is 132 subscribed. 134 3. LIST Command Options 136 The LIST command syntax is extended by adding a parenthesized list of 137 command options between the command name and the reference name (see 138 the formal syntax in section 6 for specific details). Command 139 options will be defined in this document and in approved extension 140 documents; each option will be enabled by a capability string (one 141 capability may enable multiple options), and a client MUST NOT send 142 an option for which the server has not advertised support. A server 143 MUST respond to options it does not recognize with a NO response. 145 This extension is identified by the capability string "LISTEXT", and 146 support for it is a prerequisite for any future extensions that 147 require specialized forms of the LIST command. Such extensions MUST 148 refer to this document and MUST add their function through command 149 options as described herein. 150 This extension also defines extensions to the LIST response, allowing 151 a series of extended fields at the end, a parenthesized list of tagged 152 data (also referred to as "extended data item"). The first element of 153 an extended field is a tag, which identifies type of the data. Tags 154 MUST be registered with IANA, as described in section 8.5 of this 155 document. An example of such extended set might be 157 ((tablecloth (("fringe" "lacy")("color" "white")))(X-Sample 158 "text")) 160 or... 162 ((tablecloth ("fringe" "lacy"))(X-Sample "text" "and even more text")) 164 See the formal grammar, below, for the full syntatic details. 165 The server MAY return data in the extended fields that was not solicited 166 by the client. The client MUST ignore all extended fields it doesn't 167 recognize. 169 The LISTEXT capability defines several new mailbox flags. 171 The "\PlaceHolder" flag indicates that the designated mailbox does not 172 meet the selection criteria of the given LIST command, but that it 173 has one or more child mailbox that might (unspecified whether any, 174 all, or none match the canonical LIST pattern). 175 The LSUB command indicates this condition by using the "\NoSelect" 176 flag, but the LIST (SUBSCRIBED) command MUST NOT do that, since 177 "\NoSelect" retains its original meaning here. Further, the 178 "\PlaceHolder" flag is more general, in that it can be used with any 179 extended set of selection criteria. 181 The "\HasSubmailboxes" flag indicates that the designated mailbox meets 182 the selection criteria of the given LIST command and also has one or more child 183 mailbox that might (unspecified whether any, all, or none match the canonical 184 LIST pattern). 186 Absence of both \PlaceHolder and \HasSubmailboxes means that the mailbox 187 meets the selection criterion, but doesn't have any children that also 188 meet the selection criterion and don't match the canonical LIST pattern. 189 However, absence of both \PlaceHolder and \HasSubmailboxes doesn't tell 190 whether there are any children that meet the selection criterion and match 191 the canonical LIST pattern. 193 <> 195 The SUBMAILBOXES option described below REQUIRES that the "\Placeholder" 196 and the "\HasSubmailboxes" flags be accurately computed. 198 The "\Placeholder"/""\HasSubmailboxes" flag implies "\HasChildren". 200 The "\NonExistent" flag indicates that a mailbox does not actually exist. 201 Note that this flag is not meaningful by itself, as mailboxes that match 202 the canonical LIST pattern but don't exist must not be returned unless one 203 of the two conditions listed below is also satisfied: 205 a) the mailbox also satisfy the selection criteria 207 b) the mailbox has at least one child mailbox that satisfies the selection 208 criteria, but doesn't match the canonical LIST pattern. 210 In practice this means that the "\NonExistent" flag is usually returned 211 with one or more of \PlaceHolder/\HasSubmailboxes, \Subscribed, \Remote 212 (see there description below). 214 The "\NonExistent" flag implies "\NoSelect". 215 The "\NonExistent" flag MUST be supported and MUST be accurately computed. 217 The following table summarizes when \NonExistent, \PlaceHolder or 218 \HasSubmailboxes flags are to be returned: 220 +------+------------+---------------------+--------------------------------+ 221 |exists| meets the | has a child that | returned | 223 | | selection | meets the selection | LISTEXT flags | 224 | | criteria | criteria | | 225 +------+------------+---------------------+--------------------------------+ 226 | no | no | no | no LIST response returned | 227 | yes | no | no | no LIST response returned | 228 | no | yes | no | (\NonExistent) | 229 | yes | yes | no | () | 230 | no | no | yes | (\NonExistent \PlaceHolder) | 231 | yes | no | yes | (\PlaceHolder) | 232 | no | yes | yes | (\NonExistent \HasSubmailboxes)| 233 | yes | yes | yes | (\HasSubmailboxes) | 234 +------+------------+---------------------+--------------------------------+ 236 The options defined in this specification are 238 SUBSCRIBED - causes the LIST command to list subscribed 239 mailboxes, rather than the actual mailboxes. This will often 240 be a subset of the actual mailboxes. It's also possible for 241 this list to contain the names of mailboxes that don't exist. 242 In any case, the list MUST include exactly those mailbox names 243 that match the selection criteria and are subscribed to. This 244 option is intended to supplement the LSUB command. 245 Of particular note are the mailbox flags as returned by this 246 option, compared with what is returned by LSUB. With the 247 latter, the flags returned may not reflect the actual flag 248 status on the mailbox, and the \NoSelect flag has a special 249 meaning (it indicates that this mailbox is not, itself, 250 subscribed, but that it has child mailboxes that are). With 251 the SUBSCRIBED option described here, the flags are accurate 252 and complete, and have no special meanings. 253 "LSUB" and "LIST (SUBSCRIBED)" are, thus, not the same thing, 254 and some servers must do significant extra work to respond to 255 "LIST (SUBSCRIBED)". Because of this, clients SHOULD continue 256 to use "LSUB" unless they specifically want the additional 257 information offered by "LIST (SUBSCRIBED)". 259 This option defines a new mailbox flag, "\Subscribed" that 260 indicates that a mailbox is subscribed to. The "\Subscribed" 261 flag MUST be supported and MUST be accurately computed 262 when the SUBSCRIBED option is specified. 264 REMOTE - causes the LIST command to show remote mailboxes as 265 well as local ones, as described in [MboxRefer]. This option 266 is intended to replace the RLIST command and, in conjunction 267 with the SUBSCRIBED option, the RLSUB command. This option is 268 only available on servers that also support RFC 2193. 270 This option defines a new mailbox flag, "\Remote", that 271 indicates that a mailbox is a remote mailbox. The "\Remote" 272 flag MUST be accurately computed when the REMOTE option is 273 specified. 275 Note, that a server implementation that doesn't support 276 any remote mailboxes is compliant with this specification 277 as long as it accepts and ignores the REMOTE option. 279 SUBMAILBOXES - when this option is specified, the "\Placeholder" 280 and the "\HasSubmailboxes" flags MUST be accurate. 282 Note, that even it SUBMAILBOXES option is specified, the client 283 still must be able to handle a case when a "\PlaceHolder"/ 284 "\HasSubmailboxes" is returned and there are no submailboxes 285 that meet the selection criteria of the given LIST command, 286 as they can be deleted/renamed after the LIST response was sent, 287 but before the client had a chance to access them. 289 CHILDREN - Requests mailbox child information as originally 290 proposed in [ChildMbox]. See section 4, below, for details. 291 This option MUST be accepted by all servers, however it MAY 292 be ignored. 294 4. The CHILDREN Option 296 The CHILDREN option implements the Child Mailbox Extension, 297 originally proposed by Mike Gahrns and Raymond Cheng, of Microsoft 298 Corporation. Most of the information in this section is taken 299 directly from their original specification [ChildMbox]. The CHILDREN 300 option is simply an indication that the client wants this 301 information; a server MAY provide it even if the option is not 302 specified, or MAY ignore the option entirely. 303 Many IMAP4 [IMAP4] clients present to the user a hierarchical view of 304 the mailboxes that a user has access to. Rather than initially 305 presenting to the user the entire mailbox hierarchy, it is often 306 preferable to show to the user a collapsed outline list of the 307 mailbox hierarchy (particularly if there is a large number of 308 mailboxes). The user can then expand the collapsed outline hierarchy 309 as needed. It is common to include within the collapsed hierarchy a 310 visual clue (such as a ''+'') to indicate that there are child 311 mailboxes under a particular mailbox. When the visual clue is 312 clicked the hierarchy list is expanded to show the child mailboxes. 313 The Child Mailbox Extension provides a mechanism for a client to 314 efficiently determine if a particular mailbox has children, without 315 issuing a LIST "" * or a LIST "" % for each mailbox name. 316 The Child Mailbox Extension defines two new attributes that MAY be 317 returned within a LIST response: \HasChildren and \HasNoChildren. 318 While these attributes MAY be returned in response to any LIST 319 command, the CHILDREN option is provided to indicate that the client 320 particularly wants this information. If the CHILDREN option is 321 present, the server SHOULD return these attributes even if their 322 computation is expensive. 324 \HasChildren - The presence of this attribute indicates that the 325 mailbox has child mailboxes. 326 A server SHOULD NOT set this attribute if there are child 327 mailboxes, and the user does not have permissions to access any 328 of them. In this case, \HasNoChildren SHOULD be used. 329 In many cases, however, a server may not be able to efficiently 330 compute whether a user has access to all child mailboxes. As 331 such a client MUST be prepared to accept the \HasChildren 332 attribute as a hint. That is, a mailbox MAY be flagged with the 333 \HasChildren attribute, but no child mailboxes will appear in 334 the LIST response. 336 \HasNoChildren - The presence of this attribute indicates that the 337 mailbox has NO child mailboxes that are accessible to the 338 currently authenticated user. 340 In some instances a server that supports the Child Mailbox Extension 341 might not be able to determine whether a mailbox has children. For 342 example it may have difficulty determining whether there are child 343 mailboxes when LISTing mailboxes while operating in a particular 344 namespace. 345 In these cases, a server MAY exclude both the \HasChildren and 346 \HasNoChildren attributes in the LIST response. As such, a client 347 can not make any assumptions about whether a mailbox has children 348 based upon the absence of a single attribute. In particular, some 349 servers may not be able to combine the SUBSCRIBED and CHILDREN 350 options. Such servers MUST honour the SUBSCRIBED option, and they 351 will simply ignore the CHILDREN option if both are requested. 352 It is an error for the server to return both a \HasChildren and a 353 \HasNoChildren attribute in a LIST response. 355 Note: the \HasNoChildren attribute should not be confused with the 356 IMAP4 [IMAP4] defined attribute \NoInferiors which indicates that no 357 child mailboxes exist now and none can be created in the future. 359 5. Examples 361 The first example shows the complete local hierarchy that will be 362 used for the other examples. 364 C: A01 LIST "" "*" 365 S: * LIST (\Marked \NoInferiors) "/" "inbox" 366 S: * LIST () "/" "Fruit" 367 S: * LIST () "/" "Fruit/Apple" 368 S: * LIST () "/" "Fruit/Banana" 369 S: * LIST () "/" "Tofu" 370 S: * LIST () "/" "Vegetable" 371 S: * LIST () "/" "Vegetable/Broccoli" 372 S: * LIST () "/" "Vegetable/Corn" 373 S: A01 OK done 375 In the next example, we'll see the subscribed mailboxes. This is 376 similar, but not equivalent, to . Note that the mailbox 377 called "Fruit/Peach" is subscribed to, but does not actually exist 378 (perhaps it was deleted while still subscribed). The "Fruit" 379 mailbox is not subscribed to, but it has two subscribed children. 380 The "Vegetable" mailbox is subscribed and has two children, one 381 of them is subscribed as well. 383 C: A02 LIST (SUBSCRIBED) "" "*" 384 S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox" 385 S: * LIST (\PlaceHolder) "/" "Fruit" 386 S: * LIST (\Subscribed) "/" "Fruit/Banana" 387 S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach" 388 S: * LIST (\Subscribed \HasSubmailboxes) "/" "Vegetable" 389 S: * LIST (\Subscribed) "/" "Vegetable/Broccoli" 390 S: A02 OK done 392 The next example shows the use of the CHILDREN option. The client, 393 without having to list the second level of hierarchy, now knows which 394 of the top-level mailboxes have sub-mailboxes (children) and which do 395 not. Note that it's not necessary for the server to return the 396 \HasNoChildren flag for the inbox, because the \NoInferiors flag 397 already implies that, and has a stronger meaning. 399 C: A03 LIST (CHILDREN) "" "%" 400 S: * LIST (\Marked \NoInferiors) "/" "inbox" 401 S: * LIST (\HasChildren) "/" "Fruit" 402 S: * LIST (\HasNoChildren) "/" "Tofu" 403 S: * LIST (\HasChildren) "/" "Vegetable" 404 S: A03 OK done 406 In this example we see more mailboxes, which reside on another server 407 to which we may obtain referrals. This is similar to the command 408 . We also see the mixing of two options. Note that in 409 the case of the remote mailboxes, the server might or might not be 410 able to include CHILDREN information; it includes it if it can, and 411 omits it if it can't. 413 C: A04 LIST (REMOTE CHILDREN) "" "%" 414 S: * LIST (\Marked \NoInferiors) "/" "inbox" 415 S: * LIST (\HasChildren) "/" "Fruit" 416 S: * LIST (\HasNoChildren) "/" "Tofu" 417 S: * LIST (\HasChildren) "/" "Vegetable" 418 S: * LIST (\Remote) "/" "Bread" 419 S: * LIST (\HasChildren \Remote) "/" "Meat" 420 S: A04 OK done 422 6. Formal Syntax 424 The following syntax specification uses the augmented Backus-Naur 425 Form (BNF) as described in [ABNF]. Terms not defined here are taken 426 from [IMAP4]. "vendor-token" is defined in [ACAP]. 428 child-mbox-flag = "\HasChildren" / "\HasNoChildren" 429 ; flags for Child Mailbox Extension, at most one 430 ; possible per LIST response 432 list = "LIST" [SP list-options] SP mailbox SP list-mailbox 434 list-options = "(" [option *(SP option)] ")" 436 mailbox-list = "(" [mbx-list-flags] ")" SP 437 (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox 438 [SP mbox-list-extended] 440 mbox-list-extended = "(" [mbox-list-extended-item 441 *(SP mbox-list-extended-item)] ")" 443 mbox-list-extended-item = "(" mbox-list-extended-item-data ")" 445 mbox-list-extended-item-data = mbox-list-extended-item-tag SP nstring-list 447 mbox-list-extended-item-tag = astring 448 ; The content MUST conform to either "eitem-vendor-tag" or 449 ; "eitem-standard-tag" ABNF productions. 450 ; A tag registration template is described in section 451 ; 8.5 of this document. 453 eitem-vendor-tag = vendor-tag 454 ; a vendor specific tag for extended list data 456 eitem-standard-tag = atom 457 ; a tag for extended list data defined in a Standard 458 ; Track or Experimental RFC. 460 nstring-list = nstring / 461 "(" [nstring-list *(SP nstring-list)] ")" 462 ;; a recursive list definition 464 mbox-list-oflag = child-mbox-flag / "\NonExistent" / "\PlaceHolder" / 465 "\HasSubmailboxes" / "\Subscribed" / "\Remote" 467 option = "SUBSCRIBED" / "CHILDREN" / "REMOTE" / "SUBMAILBOXES" / 468 option-extension 469 ; An option registration template is described in section 470 ; 8.3 of this document. 472 option-extension = option-vendor-tag / option-standard-tag 474 option-vendor-tag = vendor-tag 475 ; a vendor specific option 477 option-standard-tag= atom 478 ; an option defined in a Standard Track or 479 ; Experimental RFC 481 vendor-tag = vendor-token "-" atom 483 7. Security Considerations 485 This document describes syntactic changes to the specification of the 486 IMAP4 commands LIST, LSUB, RLIST, and RLSUB, and the modified LIST 487 command has the same security considerations as those commands. They 488 are described in [IMAP4] and [MboxRefer]. 490 The Child Mailbox Extension provides a client a more efficient means 491 of determining whether a particular mailbox has children. If a 492 mailbox has children, but the currently authenticated user does not 493 have access to any of them, the server SHOULD respond with a 494 \HasNoChildren attribute. In many cases, however, a server may not 495 be able to efficiently compute whether a user has access to all child 496 mailboxes. If such a server responds with a \HasChildren attribute, 497 when in fact the currently authenticated user does not have access to 498 any child mailboxes, potentially more information is conveyed about 499 the mailbox than intended. In most situations this will not be a 500 security concern, because if information regarding whether a mailbox 501 has children is considered sensitive, a user would not be granted 502 access to that mailbox in the first place. 504 8. IANA Considerations 506 8.1. Guidelines for IANA 508 It is requested that IANA creates two new registries for LISTEXT 509 options and LISTEXT extended response data. The templates and 510 the initial registrations are detailed below. 512 8.2. Registration procedure and Change control 514 Registration of a LISTEXT option is done by filling in the template 515 in section 8.3 and sending it via electronic mail to . 516 Registration of a LISTEXT extended data item is done by filling in the 517 template in section 8.5 and sending it via electronic mail to . 518 IANA has the right to reject obviously bogus registrations, but will 519 perform no review of claims made in the registration form. 521 A LISTEXT option/extended data item name that starts with "V-" is reserved 522 for vendor specific options/extended data items. All options, whether 523 they are vendor specific or global, should be registered with IANA. 524 If a LISTEXT extended data item is returned as a result of requesting 525 a particular LISTEXT option, the name of the option SHOULD be used 526 as the name of the LISTEXT extended data item. 528 Each vendor specific options/extended data item MUST start with their 529 vendor-token ("vendor prefix"). The vendor-token MUST be registered 530 with IANA, using the [ACAP] vendor subtree registry. 532 Standard LISTEXT option/extended data item names are case insensitive. 533 If the vendor prefix is omitted from a vendor specific LISTEXT 534 option/extended data item name, the rest is case insensitive. The vendor 535 prefix itself is not case-sensitive, as it might contain non-ASCII 536 characters. 538 While the registration procedures do not require it, authors of LISTEXT 539 options/extended data items are encouraged to seek community review and 540 comment whenever that is feasible. Authors may seek community review by 541 posting a specification of their proposed mechanism as an Internet- 542 Draft. LISTEXT options/extended data items intended for widespread use 543 should be standardized through the normal IETF process, when appropriate. 545 Comments on registered LISTEXT options/extended response data should 546 first be sent to the "owner" of the mechanism and/or to the IMAPEXT WG 547 mailing list. 548 Submitters of comments may, after a reasonable attempt to contact the 549 owner, request IANA to attach their comment to the registration itself. 550 If IANA approves of this, the comment will be 551 made accessible in conjunction with the registration LISTEXT options/ 552 extended response data itself. 554 Once a LISTEXT registration has been published by IANA, the 555 author may request a change to its definition. The change request 556 follows the same procedure as the registration request. 558 The owner of a LISTEXT registration may pass responsibility for the 559 registered option/extended data item to another person or agency by 560 informing IANA; this can be done without discussion or review. 562 The IESG may reassign responsibility for a LISTEXT option/extended data item. 563 The most common case of this will be to enable changes to be made to 564 mechanisms where the author of the registration has died, moved out 565 of contact or is otherwise unable to make changes that are important 566 to the community. 568 LISTEXT registrations may not be deleted; mechanisms which are 569 no longer believed appropriate for use can be declared OBSOLETE by a 570 change to their "intended use" field; such LISTEXT options/extended data 571 items will be clearly marked in the lists published by IANA. 573 The IESG is considered to be the owner of all LISTEXT options/extended data items 574 which are on the IETF standards track. 576 8.3. Registration template for LISTEXT options 578 To: iana@iana.org 579 Subject: Registration of LISTEXT option X 581 LISTEXT option name: 583 LISTEXT option description: 585 Published specification (optional, recommended): 587 Security considerations: 589 Intended usage: 590 (One of COMMON, LIMITED USE or OBSOLETE) 592 Person & email address to contact for further information: 594 Owner/Change controller: 596 (Any other information that the author deems interesting may be 597 added below this line.) 599 8.4. Initial LISTEXT option registrations 601 It is requested that the LISTEXT option registry is being populated 602 with the following entries: 604 1) 606 To: iana@iana.org 607 Subject: Registration of LISTEXT option SUBSCRIBED 609 LISTEXT option name: SUBSCRIBED 611 LISTEXT option description: Causes the LIST command to list 612 subscribed mailboxes, rather than the actual mailboxes. 614 Published specification : this RFC, section 3. 616 Security considerations: this RFC, section 7. 618 Intended usage: COMMON 620 Person & email address to contact for further information: 621 Alexey Melnikov 623 Owner/Change controller: IESG 625 2) 627 To: iana@iana.org 628 Subject: Registration of LISTEXT option REMOTE 630 LISTEXT option name: REMOTE 632 LISTEXT option description: causes the LIST command to return 633 remote mailboxes as well as local ones, as described in 634 RFC 2193. 636 Published specification : this RFC, section 3. 638 Security considerations: this RFC, section 7. 640 Intended usage: COMMON 642 Person & email address to contact for further information: 643 Alexey Melnikov 645 Owner/Change controller: IESG 647 3) 649 To: iana@iana.org 650 Subject: Registration of LISTEXT option SUBMAILBOXES 652 LISTEXT option name: SUBMAILBOXES 654 LISTEXT option description: Requests that \Placeholder/ 655 \HasSubmailboxes flags are to be accurately computed. 657 Published specification : this RFC, sections 3. 659 Published specification : this RFC 661 Security considerations: this RFC, section 7. 663 Intended usage: COMMON 665 Person & email address to contact for further information: 666 Alexey Melnikov 668 Owner/Change controller: IESG 670 4) 672 To: iana@iana.org 673 Subject: Registration of LISTEXT option CHILDREN 675 LISTEXT option name: CHILDREN 677 LISTEXT option description: Requests mailbox child information. 679 Published specification : this RFC, sections 3 and 4. 681 Published specification : this RFC 683 Security considerations: this RFC, section 7. 685 Intended usage: COMMON 687 Person & email address to contact for further information: 688 Alexey Melnikov 690 Owner/Change controller: IESG 692 8.5. Registration template for LISTEXT extended data item 694 To: iana@iana.org 695 Subject: Registration of LISTEXT extended data item X 697 LISTEXT extended data item tag: 699 LISTEXT extended data item description: 701 Which LISTEXT option(s) causes this extended data item 702 to be returned (if any): 704 Published specification (optional, recommended): 706 Security considerations: 708 Intended usage: 709 (One of COMMON, LIMITED USE or OBSOLETE) 711 Person & email address to contact for further information: 713 Owner/Change controller: 715 (Any other information that the author deems interesting may be 716 added below this line.) 718 9. References 720 9.1. Normative References 722 [Keywords] Bradner, S., "Key words for use in RFCs to Indicate 723 Requirement Levels", RFC 2119, Harvard University, March 1997. 725 [ABNF] Crocker, D., and Overell, P. "Augmented BNF for Syntax 726 Specifications: ABNF", RFC 2234, November 1997. 728 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 729 4rev1", RFC 3501, University of Washington, March 2003. 731 [MboxRefer] Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193, 732 Microsoft Corporation, September 1997. 734 [ChildMbox] Gahrns, M. & Cheng, R., "IMAP4 Child Mailbox Extension", 735 RFC 3348, Microsoft Corporation, July 2002. 737 [ACAP] Newman, C. and J. Myers, "ACAP -- Application 738 Configuration Access Protocol", RFC 2244, November 1997. 740 10. Acknowledgements 742 Mike Gahrns and Raymond Cheng of Microsoft Corporation originally 743 devised the Child Mailbox Extension and proposed it in 1997; the 744 idea, as well as most of the text in section 4, is theirs. 746 This document is the result of discussions on the IMAP4 mailing list 747 and is meant to reflect consensus of this group. In particular, 748 Mark Crispin, Philip Guenther, Cyrus Daboo, Timo Sirainen, 749 Ken Murchison, Rob Siemborski, Steve Hole, Arnt Gulbrandsen, Larry 750 Greenfield and Pete Maclean were active participants 751 in this discussion or made suggestions to this document. 753 11. Author's Address 755 Barry Leiba 756 IBM T.J. Watson Research Center 757 30 Saw Mill River Road 758 Hawthorne, NY 10532 759 Phone: 1-914-784-7941 760 Email: leiba@watson.ibm.com 762 Alexey Melnikov (Editor) 763 Isode Limited 764 5 Castle Business Village 765 36 Station Road 766 Hampton, Middlesex 767 TW12 2BX, UK 769 Email: Alexey.Melnikov@isode.com 770 URI: http://www.melnikov.ca/ 772 12. IPR Disclosure Acknowledgement 774 By submitting this Internet-Draft, we certify that any applicable 775 patent or other IPR claims of which I am aware have been disclosed, 776 and any of which we become aware will be disclosed, in accordance with 777 RFC 3668. 779 13. Intellectual Property 781 The IETF takes no position regarding the validity or scope of any 782 Intellectual Property Rights or other rights that might be claimed to 783 pertain to the implementation or use of the technology described in 784 this document or the extent to which any license under such rights 785 might or might not be available; nor does it represent that it has 786 made any independent effort to identify any such rights. Information 787 on the procedures with respect to rights in RFC documents can be 788 found in BCP 78 and BCP 79. 790 Copies of IPR disclosures made to the IETF Secretariat and any 791 assurances of licenses to be made available, or the result of an 792 attempt made to obtain a general license or permission for the use of 793 such proprietary rights by implementers or users of this 794 specification can be obtained from the IETF on-line IPR repository at 795 http://www.ietf.org/ipr. 797 The IETF invites any interested party to bring to its attention any 798 copyrights, patents or patent applications, or other proprietary 799 rights that may cover technology that may be required to implement 800 this standard. Please address the information to the IETF at 801 ietf-ipr@ietf.org. 803 14. Full Copyright Statement 805 Copyright (C) The Internet Society (2004). This document is subject 806 to the rights, licenses and restrictions contained in BCP 78, and 807 except as set forth therein, the authors retain all their rights. 809 This document and the information contained herein are provided on an 810 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 811 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 812 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 813 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 814 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 815 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 817 Acknowledgement 819 Funding for the RFC Editor function is currently provided by 820 the Internet Society.