idnits 2.17.1 draft-ietf-imapext-list-extensions-06.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 3979, Section 5, paragraph 1 on line 637. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 644. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 650. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 597), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 597. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** 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. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == 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 676 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 26 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 (November 2004) is 7102 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: 13 errors (**), 0 flaws (~~), 4 warnings (==), 5 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 Document: draft-ietf-imapext-list-extensions-06.txt May 2004 5 Expires November 2004 7 IMAP4 LIST Command Extensions 9 Status of this Document 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 A revised version of this draft document will be submitted to the RFC 28 editor as an Proposed Standard for the Internet Community. 29 Discussion and suggestions for improvement are requested, and should 30 be sent to ietf-imapext@imc.org. This document will expire before 31 31 November 2004. Distribution of this memo is unlimited. 33 This documents obsoletes RFC 3348 and updates RFC 2193. 35 Abstract 37 IMAP4 has two commands for listing mailboxes: LIST and LSUB. As we 38 have added extensions that have required specialized lists (see 39 [MboxRefer] for an example) we have had to expand the number of list 40 commands, since each extension must add its function to both LIST and 41 LSUB, and these commands are not, as they are defined, extensible. 42 If we've needed the extensions to work together, we've had to add a 43 set of commands to mix the different options, the set increasing in 44 size with each new extension. This document describes an extension 45 to the base LIST command that will allow these additions to be done 46 with mutually compatible options to the LIST command, avoiding the 47 exponential increase in specialized list commands. 49 1. Conventions used in this document 51 In examples, "C:" indicates lines sent by a client that is connected 52 to a server. "S:" indicates lines sent by the server to the client. 54 The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are 55 used in this document as specified in RFC 2119 [Keywords]. 57 2. Introduction and overview 59 The extensions to the LIST command will be accomplished by amending 60 the syntax to allow options to be specified. The list of options 61 will replace the several commands that are currently used to mix and 62 match the information requested. The new syntax is backward- 63 compatible, with no ambiguity: if the first word after the command 64 name begins with a parenthesis, the new syntax is being used; if it 65 does not, it's in the original syntax. 67 By adding options to the LIST command, we are announcing the intent 68 to phase out and eventually to deprecate the RLIST and RLSUB commands 69 described in [MboxRefer]. We are also defining the mechanism to 70 request extended mailbox information, such as is described in the 71 "Child Mailbox Extension" [ChildMbox]. The base 72 LSUB command is not deprecated by this extension; rather, this 73 extension adds a way to obtain subscription information with more 74 options, with those server implementations that support it. Clients 75 that simply need a list of subscribed mailboxes, as provided by the 76 LSUB command, SHOULD continue to use that command. 78 This document defines an IMAP4 extension that is identified by the 79 capability string "LISTEXT". The LISTEXT extension makes the 80 following changes to the IMAP4 protocol, which are described in 81 more details in sections 3 and 4 of this document: 83 a. defines new syntax for LIST command options. 84 b. adds LIST command options: SUBSCRIBED, REMOTE and CHILDREN 85 c. adds new mailbox flags "\NonExistent", "\PlaceHolder", 86 "\HasChildren" and "\HasNoChildren". 88 3. LIST Command Options 90 The LIST command syntax is extended by adding a parenthesized list of 91 command options between the command name and the reference name (see 92 the formal syntax in section 6 for specific details). Command 93 options will be defined in this document and in approved extension 94 documents; each option will be enabled by a capability string (one 95 capability may enable multiple options), and a client MUST NOT send 96 an option for which the server has not advertised support. A server 97 MUST respond to options it does not recognize with a NO response. 99 This extension is identified by the capability string "LISTEXT", and 100 support for it is a prerequisite for any future extensions that 101 require specialized forms of the LIST command. Such extensions MUST 102 refer to this document and MUST add their function through command 103 options as described herein. 104 This extension also defines extensions to the LIST response, allowing 105 a series of extended fields at the end, a parenthesized list of tagged 106 data (also referred to as "extended data item"). The first element of 107 an extended field is a tag, which identifies type of the data. Tags 108 MUST be registered with IANA, as described in section 8.5 of this 109 document. An example of such extended set might be 111 ((tablecloth (("fringe" "lacy")("color" "white")))(X-Sample 112 "text")) 114 or... 116 ((tablecloth ("fringe" "lacy"))(X-Sample "text" "and even more text")) 118 See the formal grammar, below, for the full syntatic details. 119 The server MAY return data in the extended fields that was not solicited 120 by the client. The client MUST ignore all extended fields it doesn't 121 recognize. 123 The options defined in this specification are 125 SUBSCRIBED - causes the LIST command to list subscribed 126 mailboxes, rather than the actual mailboxes. This will often 127 be a subset of the actual mailboxes. It's also possible for 128 this list to contain the names of mailboxes that don't exist. 129 In any case, the list MUST include exactly those mailbox names 130 that match the selection criteria and are subscribed to. This 131 option is intended to supplement the LSUB command. 132 Of particular note are the mailbox flags as returned by this 133 option, compared with what is returned by LSUB. With the 134 latter, the flags returned may not reflect the actual flag 135 status on the mailbox, and the \NoSelect flag has a special 136 meaning (it indicates that this mailbox is not, itself, 137 subscribed, but that it has child mailboxes that are). With 138 the SUBSCRIBED option described here, the flags are accurate 139 and complete, and have no special meanings. 140 "LSUB" and "LIST (SUBSCRIBED)" are, thus, not the same thing, 141 and some servers must do significant extra work to respond to 142 "LIST (SUBSCRIBED)". Because of this, clients SHOULD continue 143 to use "LSUB" unless they specifically want the additional 144 information offered by "LIST (SUBSCRIBED)". 146 This option defines a new mailbox flag, "\NonExistent", that 147 indicates that a mailbox is subscribed to, but does not 148 actually exist. The "\NonExistent" flag MUST be supported and 149 MUST be accurately computed. 151 REMOTE - causes the LIST command to show remote mailboxes as 152 well as local ones, as described in [MboxRefer]. This option 153 is intended to replace the RLIST command and, in conjunction 154 with the SUBSCRIBED option, the RLSUB command. This option is 155 only available on servers that also support RFC 2193. 157 CHILDREN - Requests mailbox child information as originally 158 proposed in [ChildMbox]. See section 4, below, for details. 159 Support for this is optional, but this option MUST be accepted 160 by all servers (though it MAY be ignored). 162 The LISTEXT capability also defines a new mailbox flag, 163 "\PlaceHolder", that indicates that the designated mailbox does not 164 meet the selection criteria of the given LIST command, but that it 165 has one or more child mailboxes that do <>. 166 The LSUB command indicates this condition by using the "\NoSelect" 167 flag, but the LIST (SUBSCRIBED) command MUST NOT do that, since 168 "\NoSelect" retains its original meaning here. Further, the 169 "\PlaceHolder" flag is more general, in that it can be used with any 170 extended set of selection criteria. 172 4. The CHILDREN Option 174 The CHILDREN option implements the Child Mailbox Extension, 175 originally proposed by Mike Gahrns and Raymond Cheng, of Microsoft 176 Corporation. Most of the information in this section is taken 177 directly from their original specification [ChildMbox]. The CHILDREN 178 option is simply an indication that the client wants this 179 information; a server MAY provide it even if the option is not 180 specified, or MAY ignore the option entirely. 181 Many IMAP4 [IMAP4] clients present to the user a hierarchical view of 182 the mailboxes that a user has access to. Rather than initially 183 presenting to the user the entire mailbox hierarchy, it is often 184 preferable to show to the user a collapsed outline list of the 185 mailbox hierarchy (particularly if there is a large number of 186 mailboxes). The user can then expand the collapsed outline hierarchy 187 as needed. It is common to include within the collapsed hierarchy a 188 visual clue (such as a ''+'') to indicate that there are child 189 mailboxes under a particular mailbox. When the visual clue is 190 clicked the hierarchy list is expanded to show the child mailboxes. 191 The Child Mailbox Extension provides a mechanism for a client to 192 efficiently determine if a particular mailbox has children, without 193 issuing a LIST "" * or a LIST "" % for each mailbox name. 194 The Child Mailbox Extension defines two new attributes that MAY be 195 returned within a LIST response: \HasChildren and \HasNoChildren. 196 While these attributes MAY be returned in response to any LIST 197 command, the CHILDREN option is provided to indicate that the client 198 particularly wants this information. If the CHILDREN option is 199 present, the server SHOULD return these attributes even if their 200 computation is expensive. 202 \HasChildren - The presence of this attribute indicates that the mailbox 203 has child mailboxes. 204 A server SHOULD NOT set this attribute if there are child 205 mailboxes, and the user does not have permissions to access any 206 of them. In this case, \HasNoChildren SHOULD be used. 207 In many cases, however, a server may not be able to efficiently 208 compute whether a user has access to all child mailboxes. As 209 such a client MUST be prepared to accept the \HasChildren 210 attribute as a hint. That is, a mailbox MAY be flagged with the 211 \HasChildren attribute, but no child mailboxes will appear in 212 the LIST response. 214 \HasNoChildren - The presence of this attribute indicates that the 215 mailbox has NO child mailboxes that are accessible to the 216 currently authenticated user. 218 In some instances a server that supports the Child Mailbox Extension 219 might not be able to determine whether a mailbox has children. For 220 example it may have difficulty determining whether there are child 221 mailboxes when LISTing mailboxes while operating in a particular 222 namespace. 223 In these cases, a server MAY exclude both the \HasChildren and 224 \HasNoChildren attributes in the LIST response. As such, a client 225 can not make any assumptions about whether a mailbox has children 226 based upon the absence of a single attribute. In particular, some 227 servers may not be able to combine the SUBSCRIBED and CHILDREN 228 options. Such servers MUST honour the SUBSCRIBED option, and they 229 will simply ignore the CHILDREN option if both are requested. 230 It is an error for the server to return both a \HasChildren and a 231 \HasNoChildren attribute in a LIST response. 233 Note: the \HasNoChildren attribute should not be confused with the 234 IMAP4 [IMAP4] defined attribute \NoInferiors which indicates that no 235 child mailboxes exist now and none can be created in the future. 237 5. Examples 239 The first example shows the complete local hierarchy that will be 240 used for the other examples. 242 C: A01 LIST "" "*" 243 S: * LIST (\Marked \NoInferiors) "/" "inbox" 244 S: * LIST () "/" "Fruit" 245 S: * LIST () "/" "Fruit/Apple" 246 S: * LIST () "/" "Fruit/Banana" 247 S: * LIST () "/" "Tofu" 248 S: * LIST () "/" "Vegetable" 249 S: * LIST () "/" "Vegetable/Broccoli" 250 S: A01 OK done 252 In the next example, we'll see the subscribed mailboxes. This is 253 similar, but not equivalent, to . Note that the mailbox 254 called "Fruit/Peach" is subscribed to, but does not actually exist 255 (perhaps it was deleted while still subscribed). And the "Fruit" 256 mailbox is not subscribed to, but it has two subscribed children. 258 C: A02 LIST (SUBSCRIBED) "" "*" 259 S: * LIST (\Marked \NoInferiors) "/" "inbox" 260 S: * LIST (\PlaceHolder) "/" "Fruit" 261 S: * LIST () "/" "Fruit/Banana" 262 S: * LIST (\NonExistent) "/" "Fruit/Peach" 263 S: A02 OK done 265 The next example shows the use of the CHILDREN option. The client, 266 without having to list the second level of hierarchy, now knows which 267 of the top-level mailboxes have sub-mailboxes (children) and which do 268 not. Note that it's not necessary for the server to return the 269 \HasNoChildren flag for the inbox, because the \NoInferiors flag 270 already implies that, and has a stronger meaning. 272 C: A03 LIST (CHILDREN) "" "%" 273 S: * LIST (\Marked \NoInferiors) "/" "inbox" 274 S: * LIST (\HasChildren) "/" "Fruit" 275 S: * LIST (\HasNoChildren) "/" "Tofu" 276 S: * LIST (\HasChildren) "/" "Vegetable" 277 S: A03 OK done 279 In this example we see more mailboxes, which reside on another server 280 to which we may obtain referrals. This is similar to the command 281 . We also see the mixing of two options. Note that in 282 the case of the remote mailboxes, the server might or might not be 283 able to include CHILDREN information; it includes it if it can, and 284 omits it if it can't. 286 C: A04 LIST (REMOTE CHILDREN) "" "%" 287 S: * LIST (\Marked \NoInferiors) "/" "inbox" 288 S: * LIST (\HasChildren) "/" "Fruit" 289 S: * LIST (\HasNoChildren) "/" "Tofu" 290 S: * LIST (\HasChildren) "/" "Vegetable" 291 S: * LIST () "/" "Bread" 292 S: * LIST (\HasChildren) "/" "Meat" 293 S: A04 OK done 295 6. Formal Syntax 297 The following syntax specification uses the augmented Backus-Naur 298 Form (BNF) as described in [ABNF]. Terms not defined here are taken 299 from [IMAP4]. 301 child-mbox-flag = "\HasChildren" / "\HasNoChildren" 302 ; flags for Child Mailbox Extension, at most one 303 ; possible per LIST response 305 list = "LIST" [SP list-options] SP mailbox SP list-mailbox 307 list-options = "(" [option *(SP option)] ")" 309 mailbox-list = "(" [mbx-list-flags] ")" SP 310 (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox 311 [SP mbox-list-extended] 313 mbox-list-extended = "(" [mbox-list-extended-item 314 *(SP mbox-list-extended-item)] ")" 316 mbox-list-extended-item = "(" mbox-list-extended-item-data ")" 318 mbox-list-extended-item-data = mbox-list-extended-item-tag SP nstring-list 320 mbox-list-extended-item-tag = vendor-tag / standard-tag 321 ; A tag registration template is described in section 322 ; 8.5 of this document. 324 vendor-tag = "V-" atom 325 ; a vendor specific tag for extended list data 327 standard-tag = atom 328 ; a tag for extended list data defined in a Standard 329 ; Track or Experimental RFC. 331 nstring-list = nstring / 332 "(" [nstring-list *(SP nstring-list)] ")" 333 ;; a recursive list definition 335 mbox-list-oflag = child-mbox-flag / "\NonExistent" / "\PlaceHolder" 337 option = "SUBSCRIBED" / "CHILDREN" / "REMOTE" / 338 option-extension 339 ; An option registration template is described in section 340 ; 8.3 of this document. 342 option-extension = option-vendor / option-public 344 option-vendor = "V-" atom 345 ; a vendor specific option 347 option-public = atom 348 ; an option defined in a Standard Track or 349 ; Experimental RFC 351 7. Security Considerations 353 This document describes syntactic changes to the specification of the 354 IMAP4 commands LIST, LSUB, RLIST, and RLSUB, and the modified LIST 355 command has the same security considerations as those commands. They 356 are described in [IMAP4] and [MboxRefer]. 358 The Child Mailbox Extension provides a client a more efficient means 359 of determining whether a particular mailbox has children. If a 360 mailbox has children, but the currently authenticated user does not 361 have access to any of them, the server SHOULD respond with a 362 \HasNoChildren attribute. In many cases, however, a server may not 363 be able to efficiently compute whether a user has access to all child 364 mailboxes. If such a server responds with a \HasChildren attribute, 365 when in fact the currently authenticated user does not have access to 366 any child mailboxes, potentially more information is conveyed about 367 the mailbox than intended. In most situations this will not be a 368 security concern, because if information regarding whether a mailbox 369 has children is considered sensitive, a user would not be granted 370 access to that mailbox in the first place. 372 8. IANA Considerations 374 8.1. Guidelines for IANA 376 It is requested that IANA creates two new registries for LISTEXT 377 options and LISTEXT extended response data. The templates and 378 the initial registrations are detailed below. 380 8.2. Registration procedure and Change control 382 Registration of a LISTEXT option is done by filling in the template 383 in section 8.3 and sending it via electronic mail to . 384 Registration of a LISTEXT extended data item is done by filling in the 385 template in section 8.5 and sending it via electronic mail to . 386 IANA has the right to reject obviously bogus registrations, but will 387 perform no review of claims made in the registration form. 389 A LISTEXT option/extended data item name that starts with "V-" is reserved 390 for vendor specific options/extended data items. All options, whether 391 they are vendor specific or global, should be registered with IANA. 392 If a LISTEXT extended data item is returned as a result of requesting 393 a particular LISTEXT option, the name of the option SHOULD be used 394 as the name of the LISTEXT extended data item. 395 LISTEXT option/extended data item names are case insensitive. 397 While the registration procedures do not require it, authors of LISTEXT 398 options/extended data items are encouraged to seek community review and 399 comment whenever that is feasible. Authors may seek community review by 400 posting a specification of their proposed mechanism as an Internet- 401 Draft. LISTEXT options/extended data items intended for widespread use 402 should be standardized through the normal IETF process, when appropriate. 404 Comments on registered LISTEXT options/extended response data should 405 first be sent to the "owner" of the mechanism and/or to the IMAPEXT WG 406 mailing list. 407 Submitters of comments may, after a reasonable attempt to contact the 408 owner, request IANA to attach their comment to the registration itself. 409 If IANA approves of this, the comment will be 410 made accessible in conjunction with the registration LISTEXT options/ 411 extended response data itself. 413 Once a LISTEXT registration has been published by IANA, the 414 author may request a change to its definition. The change request 415 follows the same procedure as the registration request. 417 The owner of a LISTEXT registration may pass responsibility for the 418 registered option/extended data item to another person or agency by 419 informing IANA; this can be done without discussion or review. 421 The IESG may reassign responsibility for a LISTEXT option/extended data item. 422 The most common case of this will be to enable changes to be made to 423 mechanisms where the author of the registration has died, moved out 424 of contact or is otherwise unable to make changes that are important 425 to the community. 427 LISTEXT registrations may not be deleted; mechanisms which are 428 no longer believed appropriate for use can be declared OBSOLETE by a 429 change to their "intended use" field; such LISTEXT options/extended data 430 items will be clearly marked in the lists published by IANA. 432 The IESG is considered to be the owner of all LISTEXT options/extended data items 433 which are on the IETF standards track. 435 8.3. Registration template for LISTEXT options 437 To: iana@iana.org 438 Subject: Registration of LISTEXT option X 440 LISTEXT option name: 442 LISTEXT option description: 444 Published specification (optional, recommended): 446 Security considerations: 448 Intended usage: 449 (One of COMMON, LIMITED USE or OBSOLETE) 451 Person & email address to contact for further information: 453 Owner/Change controller: 455 (Any other information that the author deems interesting may be 456 added below this line.) 458 8.4. Initial LISTEXT option registrations 460 It is requested that the LISTEXT option registry is being populated 461 with the following entries: 463 1) 465 To: iana@iana.org 466 Subject: Registration of LISTEXT option SUBSCRIBED 468 LISTEXT option name: SUBSCRIBED 470 LISTEXT option description: Causes the LIST command to list 471 subscribed mailboxes, rather than the actual mailboxes. 473 Published specification : this RFC, section 3. 475 Security considerations: this RFC, section 7. 477 Intended usage: COMMON 479 Person & email address to contact for further information: 480 Alexey Melnikov 482 Owner/Change controller: IESG 484 2) 486 To: iana@iana.org 487 Subject: Registration of LISTEXT option REMOTE 489 LISTEXT option name: REMOTE 491 LISTEXT option description: causes the LIST command to return 492 remote mailboxes as well as local ones, as described in 493 RFC 2193. 495 Published specification : this RFC, section 3. 497 Security considerations: this RFC, section 7. 499 Intended usage: COMMON 501 Person & email address to contact for further information: 502 Alexey Melnikov 504 Owner/Change controller: IESG 506 3) 508 To: iana@iana.org 509 Subject: Registration of LISTEXT option CHILDREN 511 LISTEXT option name: CHILDREN 513 LISTEXT option description: Requests mailbox child information. 515 Published specification : this RFC, sections 3 and 4. 517 Published specification : this RFC 519 Security considerations: this RFC, section 7. 521 Intended usage: COMMON 523 Person & email address to contact for further information: 524 Alexey Melnikov 526 Owner/Change controller: IESG 528 8.5. Registration template for LISTEXT extended data item 530 To: iana@iana.org 531 Subject: Registration of LISTEXT extended data item X 533 LISTEXT extended data item tag: 535 LISTEXT extended data item description: 537 Which LISTEXT option(s) causes this extended data item 538 to be returned (if any): 540 Published specification (optional, recommended): 542 Security considerations: 544 Intended usage: 545 (One of COMMON, LIMITED USE or OBSOLETE) 547 Person & email address to contact for further information: 549 Owner/Change controller: 551 (Any other information that the author deems interesting may be 552 added below this line.) 554 9. References 556 9.1. Normative References 558 [Keywords]; Bradner, S.; "Key words for use in RFCs to Indicate 559 Requirement Levels"; RFC 2119; Harvard University; March 1997. 561 [ABNF]; Crocker, D., and Overell, P. "Augmented BNF for Syntax 562 Specifications: ABNF", RFC 2234, November 1997. 564 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 565 4rev1", RFC 3501, University of Washington, March 2003. 567 [MboxRefer]; Gahrns, M.; "IMAP4 Mailbox Referrals"; RFC 2193; 568 Microsoft Corporation; September 1997. 570 [ChildMbox]; Gahrns, M. & Cheng, R.; "IMAP4 Child Mailbox Extension"; 571 RFC 3348; Microsoft Corporation; July 2002. 573 10. Acknowledgements 575 Mike Gahrns and Raymond Cheng of Microsoft Corporation originally 576 devised the Child Mailbox Extension and proposed it in 1997; the 577 idea, as well as most of the text in section 4, is theirs. 579 This document is the result of discussions on the IMAP4 mailing list 580 and is meant to reflect consensus of this group. In particular, 581 Mark Crispin, Cyrus Daboo, Timo Sirainen, Ken Murchison, Alexey 582 Melnikov, Rob Siemborski, Steve Hole, Arnt Gulbrandsen, Larry 583 Greenfield, Phlip Guenther and Pete Maclean were active participants 584 in this discussion or made suggestions to this document. 586 11. Author's Address 588 Barry Leiba 589 IBM T.J. Watson Research Center 590 30 Saw Mill River Road 591 Hawthorne, NY 10532 592 Phone: 1-914-784-7941 593 Email: leiba@watson.ibm.com 595 12. Full Copyright Statement 597 Copyright (C) The Internet Society 2004. All Rights Reserved. 599 This document and translations of it may be copied and furnished to 600 others, and derivative works that comment on or otherwise explain it 601 or assist in its implementation may be prepared, copied, published 602 and distributed, in whole or in part, without restriction of any 603 kind, provided that the above copyright notice and this paragraph 604 are included on all such copies and derivative works. However, this 605 document itself may not be modified in any way, such as by removing 606 the copyright notice or references to the Internet Society or other 607 Internet organizations, except as needed for the purpose of 608 developing Internet standards in which case the procedures for 609 copyrights defined in the Internet Standards process must be 610 followed, or as required to translate it into languages other than 611 English. 613 The limited permissions granted above are perpetual and will not be 614 revoked by the Internet Society or its successors or assigns. 616 This document and the information contained herein is provided on an 617 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 618 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 619 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 620 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 621 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 623 Acknowledgement 625 Funding for the RFC Editor function is currently provided by 626 the Internet Society. 628 13. Intellectual Property 630 The IETF takes no position regarding the validity or scope of any 631 Intellectual Property Rights or other rights that might be claimed to 632 pertain to the implementation or use of the technology described in 633 this document or the extent to which any license under such rights 634 might or might not be available; nor does it represent that it has 635 made any independent effort to identify any such rights. Information 636 on the procedures with respect to rights in RFC documents can be 637 found in BCP 78 and BCP 79. 639 Copies of IPR disclosures made to the IETF Secretariat and any 640 assurances of licenses to be made available, or the result of an 641 attempt made to obtain a general license or permission for the use of 642 such proprietary rights by implementers or users of this 643 specification can be obtained from the IETF on-line IPR repository at 644 http://www.ietf.org/ipr. 646 The IETF invites any interested party to bring to its attention any 647 copyrights, patents or patent applications, or other proprietary 648 rights that may cover technology that may be required to implement 649 this standard. Please address the information to the IETF at 650 ietf-ipr@ietf.org.