idnits 2.17.1 draft-ietf-imapext-list-extensions-10.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 1187. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1225. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1198. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1205. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1211. ** 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 1264 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 143 instances of too long lines in the document, the longest one being 12 characters in excess of 72. ** There are 3 instances of lines with control characters in the document. ** 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 (October 2004) is 7134 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 3501 (ref. 'IMAP4') (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 3348 (ref. 'ChildMbox') (Obsoleted by RFC 5258) Summary: 12 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IMAP Extensions Working Group B. Leiba 2 Internet Draft IBM T.J. Watson Research Center 3 A. Melnikov 4 Isode Limited 5 Expires April 2005 October 2004 7 IMAP4 LIST Command Extensions 8 draft-ietf-imapext-list-extensions-10.txt 10 Status of this Document 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, or 14 will be disclosed, and any of which I become aware will be disclosed, 15 in accordance with RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 A revised version of this draft document will be submitted to the RFC 33 editor as an Proposed Standard for the Internet Community. 34 Discussion and suggestions for improvement are requested, and should 35 be sent to ietf-imapext@imc.org. 37 This documents obsoletes RFC 3348 and updates RFC 2193. 39 Abstract 41 IMAP4 has two commands for listing mailboxes: LIST and LSUB. As we 42 have added extensions that have required specialized lists (see 43 [MboxRefer] for an example) we have had to expand the number of list 44 commands, since each extension must add its function to both LIST and 45 LSUB, and these commands are not, as they are defined, extensible. 46 If we've needed the extensions to work together, we've had to add a 47 set of commands to mix the different options, the set increasing in 48 size with each new extension. This document describes an extension 49 to the base LIST command that will allow these additions to be done 50 with mutually compatible options to the LIST command, avoiding the 51 exponential increase in specialized list commands. 53 1. Conventions used in this document 55 In examples, "C:" indicates lines sent by a client that is connected 56 to a server. "S:" indicates lines sent by the server to the client. 58 The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are 59 used in this document as specified in RFC 2119 [Keywords]. 61 The term "canonical LIST pattern" refers to 62 the canonical pattern constructed internally by the server from 63 the reference and mailbox name arguments (Section 6.3.8 of [IMAP4]). 64 The [IMAP4] LIST command returns only mailboxes that match the 65 canonical LIST pattern. 67 Other terms are introduced where they are referenced for the first time. 69 <> 71 2. Introduction and overview 73 The extensions to the LIST command is accomplished by amending 74 the syntax to allow options to be specified. The list of options 75 replaces the several commands that are currently used to mix and 76 match the information requested. The new syntax is backward- 77 compatible, with no ambiguity: the new syntax is being used if one of 78 the following conditions is true: 79 1). if the first word after the command name begins with a 80 parenthesis ("LIST selection options"); 81 2). if the second word after the command name begins with a 82 parenthesis ("multiple mailbox patterns"); 83 3). if the LIST command has more than 2 parameters 84 ("LIST return options"); 86 Otherwise the original syntax is used. 88 By adding options to the LIST command, we are announcing the intent 89 to phase out and eventually to deprecate the RLIST and RLSUB commands 90 described in [MboxRefer]. We are also defining the mechanism to 91 request extended mailbox information, such as is described in the 92 "Child Mailbox Extension" [ChildMbox]. The base 93 LSUB command is not deprecated by this extension; rather, this 94 extension adds a way to obtain subscription information with more 95 options, with those server implementations that support it. Clients 96 that simply need a list of subscribed mailboxes, as provided by the 97 LSUB command, SHOULD continue to use that command. 99 This document defines an IMAP4 extension that is identified by the 100 capability string "X-DRAFT-W10-LISTEXT" <>. 102 The X-DRAFT-W10-LISTEXT extension makes the 103 following changes to the IMAP4 protocol, which are described in 104 more details in sections 3 and 4 of this document: 106 a. defines new syntax for LIST command options. 107 b. extend LIST to allow for multiple mailbox patterns. 108 c. adds LIST command selection options: SUBSCRIBED, REMOTE and 109 MATCHPARENT. 110 d. adds LIST command return options: SUBSCRIBED and CHILDREN. 111 e. adds new mailbox attributes: "\NonExistent", "\PlaceHolder", 112 "\Subscribed", "\Remote", "\HasSubMailboxes", 113 "\HasChildren" and "\HasNoChildren". 115 3. Extended LIST Command 117 This extension updates the syntax of the LIST command to allow for multiple 118 mailbox patterns to be specified, if they are enclosed in parantheses. 119 A mailbox name match a list of mailbox patterns if it matches at least 120 one mailbox pattern. Note that if a mailbox name matches multiple mailbox 121 patterns from the list, the server should return only a single LIST 122 response. 124 Note that the non-extended LIST command is required to treat an empty 125 ("" string) mailbox name argument as a special request to return the 126 hierarchy delimiter and the root name of the name given in the 127 reference parameter (as per [IMAP4]). However ANY extended LIST command 128 (extended in any of 3 ways specified in section 2, or any combination of 129 therof) MUST NOT treat the empty mailbox name as such special request 130 and any regular processing described in this document applies. 131 In particular, if an extended LIST command has multiple mailbox names 132 and one (or more) of them is the empty string, the empty string MUST be 133 ignored for the purpose of matching. <> 137 The LIST command syntax is also extended in two additional ways: by adding a 138 parenthesized list of command options between the command name and the 139 reference name (LIST selection options) and an optional list of options at 140 the end that control what kind of information should be returned (LIST return 141 options). See the formal syntax in section 6 for specific details. 143 A LIST selection option tells the server which mailbox names should be 144 selected by the LIST operation. 145 The server should return information about all mailbox names that match any 146 of the "canonical LIST pattern" (as described above) and satisfy additional 147 selection criteria (if any) specified by the LIST selection options. Let's 148 call any such mailbox name a "matched mailbox name". 149 When multiple selection options are specified, the server must return 150 information about mailbox names that satisfy every selection option, unless 151 a description of a particular specified option prescribes special rules. 152 An example of an option prescribing special rules is the MATCHPARENT 153 selection option described later in this section. 154 We will use the term "selection criteria" when referring collectively to all 155 selection options specified in a LIST command. 157 A LIST return option controls which information is returned for each matched 158 mailbox name. Note that return options MUST NOT cause the server to report 159 information about additional mailbox names. If the client has not specified 160 any return option, only information about attributes should be returned by 161 the server. (Of course the server is allowed to include any other information 162 at will) 164 Both selection and return command options will be defined in this document 165 and in approved extension documents; each option will be enabled by a 166 capability string (one capability may enable multiple options), and a client 167 MUST NOT send an option for which the server has not advertised support. 168 A server MUST respond to options it does not recognize with a BAD response. 169 The client SHOULD NOT specify any option more than once, however if the 170 client does this, the server MUST act as if it recieved the option only once. 172 This extension is identified by the capability string "X-DRAFT-W10-LISTEXT" 173 <>, and 174 support for it is a prerequisite for any future extensions that 175 require specialized forms of the LIST command. Such extensions MUST 176 refer to this document and MUST add their function through command 177 options as described herein. 178 Note that extensions that don't require support for an extended LIST 179 command, but use extended LIST responses (see below), don't need to advertise 180 the "X-DRAFT-W10-LISTEXT" capability string. <> 183 This extension also defines extensions to the LIST response, allowing 184 a series of extended fields at the end, a parenthesized list of tagged 185 data (also referred to as "extended data item"). The first element of 186 an extended field is a tag, which identifies type of the data. Tags 187 MUST be registered with IANA, as described in section 8.5 of this 188 document. An example of such extended set might be 190 ((tablecloth (("fringe" "lacy")("color" "white")))(X-Sample 191 "text")) 193 or... 195 ((tablecloth ("fringe" "lacy"))(X-Sample "text" "and even more text")) 197 See the formal grammar, below, for the full syntactic details. 198 The server MAY return data in the extended fields that was not solicited 199 by the client. The client MUST ignore all extended fields it doesn't 200 recognize. 202 The X-DRAFT-W10-LISTEXT <> 203 capability also defines several new mailbox attributes. 205 The "\PlaceHolder" attribute indicates that the designated mailbox does not 206 meet the selection criteria of the given LIST command, but that it 207 has one or more child mailbox that might (unspecified whether any, 208 all, or none match the canonical LIST pattern). 209 The LSUB command indicates this condition by using the "\NoSelect" 210 attribute, but the LIST (SUBSCRIBED) command MUST NOT do that, since 211 "\NoSelect" retains its original meaning here. Further, the 212 "\PlaceHolder" attribute is more general, in that it can be used with any 213 extended set of selection criteria. 215 The "\HasSubMailboxes" attribute indicates that the designated mailbox meets 216 the selection criteria of the given LIST command and also has one or more 217 child mailbox that might (unspecified whether any, all, or none match the 218 canonical LIST pattern). 220 The "\Placeholder" and the "\HasSubMailboxes" attributes MUST only be 221 returned when the client has specified the MATCHPARENT selection option. 223 When the MATCHPARENT selection option was specified by the client, 224 the absence of both \PlaceHolder and \HasSubMailboxes means that the 225 mailbox meets the selection criteria, but doesn't have any children that 226 also meets the selection criteria and doesn't match the canonical LIST 227 pattern. However, absence of both \PlaceHolder and \HasSubMailboxes doesn't 228 tell whether there are any children that meet the selection criteria and 229 match the canonical LIST pattern. 231 The "\PlaceHolder" and the "\HasSubMailboxes" attributes are mutually 232 exclusive. 234 Examples 8 and 10 in section 5 demonstrates the difference between 235 "\Placeholder"/""\HasSubMailboxes" and "\HasChildren" attributes. 237 The "\NonExistent" attribute indicates that a mailbox does not actually 238 exist. Note that this attribute is not meaningful by itself, as mailboxes 239 that match the canonical LIST pattern but don't exist must not be returned 240 unless one of the two conditions listed below is also satisfied: 242 a) the mailbox also satisfies the selection criteria 244 b) the mailbox has at least one child mailbox that satisfies the selection 245 criteria, but doesn't match the canonical LIST pattern. 247 In practice this means that the "\NonExistent" attribute is usually returned 248 with one or more of "\PlaceHolder"/"\HasSubMailboxes", "\Subscribed", 249 "\Remote" (see their description below). 251 The "\NonExistent" attribute implies "\NoSelect". The "\NonExistent" 252 attribute MUST be supported and MUST be accurately computed. 254 The following table summarizes when "\NonExistent", "\PlaceHolder" or 255 "\HasSubMailboxes" attributes are to be returned (Note that 256 "\PlaceHolder" or "\HasSubMailboxes" attributes are only returned 257 when MATCHPARENT selection option is specified): 259 +------+------------+---------------------+--------------------------------+ 260 |exists| meets the | has a child that | returned | 262 | | selection | meets the selection | LISTEXT attributes | 263 | | criteria | criteria | | 264 +------+------------+---------------------+--------------------------------+ 265 | no | no | no | no LIST response returned | 266 | yes | no | no | no LIST response returned | 267 | no | yes | no | (\NonExistent) | 268 | yes | yes | no | () | 269 | no | no | yes | (\NonExistent \PlaceHolder) | 270 | yes | no | yes | (\PlaceHolder) | 271 | no | yes | yes | (\NonExistent \HasSubMailboxes)| 272 | yes | yes | yes | (\HasSubMailboxes) | 273 +------+------------+---------------------+--------------------------------+ 275 The selection options defined in this specification are 277 SUBSCRIBED - causes the LIST command to list subscribed 278 names, rather than the existing mailboxes. This will often 279 be a subset of the actual mailboxes. It's also possible for 280 this list to contain the names of mailboxes that don't exist. 281 In any case, the list MUST include exactly those mailbox names 282 that match the canonical list pattern and are subscribed to. This 283 option is intended to supplement the LSUB command. 284 Of particular note are the mailbox attributes as returned by this 285 option, compared with what is returned by LSUB. With the 286 latter, the attributes returned may not reflect the actual attribute 287 status on the mailbox name, and the \NoSelect attribute has a special 288 meaning (it indicates that this mailbox is not, itself, 289 subscribed, but that it has child mailboxes that are). With 290 the SUBSCRIBED selection option described here, the attributes are 291 accurate, complete, and have no special meanings. 292 "LSUB" and "LIST (SUBSCRIBED)" are, thus, not the same thing, 293 and some servers must do significant extra work to respond to 294 "LIST (SUBSCRIBED)". Because of this, clients SHOULD continue 295 to use "LSUB" unless they specifically want the additional 296 information offered by "LIST (SUBSCRIBED)". 298 This option defines a new mailbox attribute, "\Subscribed", that 299 indicates that a mailbox name is subscribed to. The "\Subscribed" 300 attribute MUST be supported and MUST be accurately computed 301 when the SUBSCRIBED selection option is specified. 303 Note that the SUBSCRIBED selection option implies the SUBSCRIBED 304 return option (see below). 306 REMOTE - causes the LIST command to show remote mailboxes as 307 well as local ones, as described in [MboxRefer]. This option 308 is intended to replace the RLIST command and, in conjunction 309 with the SUBSCRIBED selection option, the RLSUB command. 311 This option defines a new mailbox attribute, "\Remote", that 312 indicates that a mailbox is a remote mailbox. The "\Remote" 313 attribute MUST be accurately computed when the REMOTE option is 314 specified. 316 Note that a server implementation that doesn't support 317 any remote mailboxes is compliant with this specification 318 as long as it accepts and ignores the REMOTE selection option. 320 MATCHPARENT - when this option is specified, the "\Placeholder" 321 and the "\HasSubMailboxes" attributes MUST be accurate (see their 322 description above). This might force the server to return 323 information about parent mailboxes that don't match other 324 selection options, but have some submailboxes that do. 326 Note 1: In order for a parent mailbox to be returned, it still 327 has to match the canonical LIST pattern. 329 Note 2: When calculating "\Placeholder"/"\HasSubMailboxes" 330 attributes, it doesn't matter if the submailbox matches 331 the canonical LIST pattern or not. See also example 9 in 332 section 5. 334 The MATCHPARENT option MUST NOT occur as the only selection option, 335 as it only makes sense when other selection options are also used. 336 The server MUST return BAD tagged response in such case. 338 Note that even if MATCHPARENT option is specified, the client 339 MUST still be able to handle a case when a "\PlaceHolder"/ 340 "\HasSubMailboxes" is returned and there are no submailboxes 341 that meet the selection criteria of the given LIST command, 342 as they can be deleted/renamed after the LIST response was sent, 343 but before the client had a chance to access them. 345 The return options defined in this specification are 347 SUBSCRIBED - causes the LIST command to return subscription 348 state for all matching mailbox names. The "\Subscribed" 349 attribute MUST be supported and MUST be accurately computed 350 when the SUBSCRIBED return option is specified. 352 CHILDREN - Requests mailbox child information as originally 353 proposed in [ChildMbox]. See section 4, below, for details. 354 This option MUST be accepted by all servers, however it MAY 355 be ignored. 357 3.1. General principles for returning LIST responses 359 This section outlines several principles that can be used by server 360 implementations of this document to decide if a LIST response should be 361 returned, as well as how many responses and what kind of information 362 they may contain. 364 1) Exactly one LIST response should be returned for each mailbox 365 name which matches the canonical LIST pattern. 366 Server implementors must not assume that clients will be able to 367 assemble mailbox attributes and other information returned in multiple 368 LIST responses. 370 2) There are only two reasons for including a matching mailbox name 371 in the responses to the LIST command (Note that the server is allowed 372 to return unsolicited responses at any time. Such responses are not 373 governed by this rule): 375 a) the mailbox name also satisfies the selection criteria; 377 b) the mailbox name doesn't satisfy the selection criteria, but 378 it has at least one child mailbox name that satisfies the 379 selection criteria and that doesn't match the canonical LIST 380 pattern. 381 For more information on this case see the \PlaceHolder 382 attribute description in Section 3. Note that the "\Placeholder" 383 attribute can only be returned when the MATCHPARENT selection 384 option is specified. 386 3) Attributes returned in the same LIST response must be treated additively. 387 For example the following response 389 S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach" 391 means that the "Fruit/Peach" mailbox doesn't exist, but it is 392 subscribed. 394 3.2. Additional requirements on LISTEXT clients 396 All clients that support this extension MUST treat an attribute with 397 a stronger meaning, as implying any attribute that can be inferred from it. 398 For example, the client must treat presence of the \NoInferiors attribute 399 as if the \HasNoChildren attribute was also sent by the server. 401 The following table summarizes inference rules described in section 3. 403 +--------------------+-------------------+ 404 | returned attribute | implied attribute | 406 +--------------------+-------------------+ 407 | \NoInferiors | \HasNoChildren | 408 | \NonExistent | \NoSelect | 409 +--------------------+-------------------+ 411 4. The CHILDREN return Option 413 The CHILDREN return option implements the Child Mailbox Extension, 414 originally proposed by Mike Gahrns and Raymond Cheng, of Microsoft 415 Corporation. Most of the information in this section is taken 416 directly from their original specification [ChildMbox]. The CHILDREN 417 return option is simply an indication that the client wants this 418 information; a server MAY provide it even if the option is not 419 specified, or MAY ignore the option entirely. 420 Many IMAP4 [IMAP4] clients present to the user a hierarchical view of 421 the mailboxes that a user has access to. Rather than initially 422 presenting to the user the entire mailbox hierarchy, it is often 423 preferable to show to the user a collapsed outline list of the 424 mailbox hierarchy (particularly if there is a large number of 425 mailboxes). The user can then expand the collapsed outline hierarchy 426 as needed. It is common to include within the collapsed hierarchy a 427 visual clue (such as a ''+'') to indicate that there are child 428 mailboxes under a particular mailbox. When the visual clue is 429 clicked the hierarchy list is expanded to show the child mailboxes. 430 The CHILDREN return option provides a mechanism for a client to 431 efficiently determine if a particular mailbox has children, without 432 issuing a LIST "" * or a LIST "" % for each mailbox name. 433 The CHILDREN return option defines two new attributes that MAY be 434 returned within a LIST response: \HasChildren and \HasNoChildren. 435 While these attributes MAY be returned in response to any LIST 436 command, the CHILDREN return option is provided to indicate that the client 437 particularly wants this information. If the CHILDREN return option 438 is present, the server SHOULD return these attributes even if their 439 computation is expensive. 441 \HasChildren - The presence of this attribute indicates that the 442 mailbox has child mailboxes. 443 A server SHOULD NOT set this attribute if there are child 444 mailboxes, and the user does not have permissions to access any 445 of them. In this case, \HasNoChildren SHOULD be used. 446 In many cases, however, a server may not be able to efficiently 447 compute whether a user has access to all child mailboxes. As 448 such a client MUST be prepared to accept the \HasChildren 449 attribute as a hint. That is, a mailbox MAY be flagged with the 450 \HasChildren attribute, but no child mailboxes will appear in 451 the LIST response. 453 \HasNoChildren - The presence of this attribute indicates that the 454 mailbox has NO child mailboxes that are accessible to the 455 currently authenticated user. 457 In some instances a server that supports the LISTEXT extension 458 might not be able to determine whether a mailbox has children. For 459 example it may have difficulty determining whether there are child 460 mailboxes when LISTing mailboxes while operating in a particular 461 namespace. 462 In these cases, a server MAY exclude both the \HasChildren and 463 \HasNoChildren attributes in the LIST response. As such, a client 464 can not make any assumptions about whether a mailbox has children 465 based upon the absence of a single attribute. In particular, some 466 servers may not be able to combine the SUBSCRIBED selection option 467 and CHILDREN return option. Such servers MUST honour the SUBSCRIBED 468 selection option, and they will simply ignore the CHILDREN return option 469 if both are requested. It is an error for the server to return both a 470 \HasChildren and a \HasNoChildren attribute in a LIST response. 472 Note: the \HasNoChildren attribute should not be confused with the 473 IMAP4 [IMAP4] defined attribute \NoInferiors which indicates that no 474 child mailboxes exist now and none can be created in the future. 476 5. Examples 478 Example 1: 480 The first example shows the complete local hierarchy that will be 481 used for the other examples. 483 C: A01 LIST "" "*" 484 S: * LIST (\Marked \NoInferiors) "/" "inbox" 485 S: * LIST () "/" "Fruit" 486 S: * LIST () "/" "Fruit/Apple" 487 S: * LIST () "/" "Fruit/Banana" 488 S: * LIST () "/" "Tofu" 489 S: * LIST () "/" "Vegetable" 490 S: * LIST () "/" "Vegetable/Broccoli" 491 S: * LIST () "/" "Vegetable/Corn" 492 S: A01 OK done 494 Example 2: 496 In the next example, we'll see the subscribed mailboxes. This is 497 similar to, but not equivalent with, . Note that the mailbox 498 called "Fruit/Peach" is subscribed to, but does not actually exist 499 (perhaps it was deleted while still subscribed). The "Fruit" 500 mailbox is not subscribed to, but it has two subscribed children. 501 The "Vegetable" mailbox is subscribed and has two children, one 502 of them is subscribed as well. 504 C: A02 LIST (SUBSCRIBED) "" "*" 505 S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox" 506 S: * LIST (\Subscribed) "/" "Fruit/Banana" 507 S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach" 508 S: * LIST (\Subscribed) "/" "Vegetable/Broccoli" 509 S: A02 OK done 511 Example 3: 513 The next example shows the use of the CHILDREN option. The client, 514 without having to list the second level of hierarchy, now knows which 515 of the top-level mailboxes have submailboxes (children) and which do 516 not. Note that it's not necessary for the server to return the 517 \HasNoChildren attribute for the inbox, because the \NoInferiors attribute 518 already implies that, and has a stronger meaning. 520 C: A03 LIST () "" "%" RETURN (CHILDREN) 521 S: * LIST (\Marked \NoInferiors) "/" "inbox" 522 S: * LIST (\HasChildren) "/" "Fruit" 523 S: * LIST (\HasNoChildren) "/" "Tofu" 524 S: * LIST (\HasChildren) "/" "Vegetable" 525 S: A03 OK done 527 Example 4: 529 In this example we see more mailboxes, which reside on another server 530 to which we may obtain referrals. This is similar to the command 531 . Note that in the case of the remote mailboxes, the 532 server might or might not be able to include CHILDREN information; 533 it includes it if it can, and omits it if it can't. 535 C: A04 LIST (REMOTE) "" "%" RETURN (CHILDREN) 536 S: * LIST (\Marked \NoInferiors) "/" "inbox" 537 S: * LIST (\HasChildren) "/" "Fruit" 538 S: * LIST (\HasNoChildren) "/" "Tofu" 539 S: * LIST (\HasChildren) "/" "Vegetable" 540 S: * LIST (\Remote) "/" "Bread" 541 S: * LIST (\HasChildren \Remote) "/" "Meat" 542 S: A04 OK done 544 Example 5: 546 The following example also requests the server to include mailboxes, 547 which reside on another server. The server returns information about 548 all mailboxes which are subscribed. This is similar to the command 549 . We also see the use of two selection options. 551 C: A05 LIST (REMOTE SUBSCRIBED) "" "*" 552 S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox" 553 S: * LIST (\Subscribed) "/" "Fruit/Banana" 554 S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach" 555 S: * LIST (\Subscribed) "/" "Vegetable" 556 S: * LIST (\Subscribed) "/" "Vegetable/Broccoli" 557 S: * LIST (\Remote \Subscribed) "/" "Bread" 558 S: A05 OK done 560 Example 6: 562 The following example requests the server to include mailboxes, 563 which reside on another server. The server is requested to return 564 subscription information for all returned mailboxes. This is different 565 from the example above. 567 Note that the output of this command is not a superset of the output 568 in the previous example, as it doesn't include LIST response for the 569 non-existent "Fruit/Peach". 571 C: A06 LIST (REMOTE) "" "*" RETURN (SUBSCRIBED) 572 S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox" 573 S: * LIST () "/" "Fruit" 574 S: * LIST () "/" "Fruit/Apple" 575 S: * LIST (\Subscribed) "/" "Fruit/Banana" 576 S: * LIST () "/" "Tofu" 577 S: * LIST (\Subscribed) "/" "Vegetable" 578 S: * LIST (\Subscribed) "/" "Vegetable/Broccoli" 579 S: * LIST () "/" "Vegetable/Corn" 580 S: * LIST (\Remote \Subscribed) "/" "Bread" 581 S: * LIST (\Remote) "/" "Meat" 582 S: A06 OK done 584 Example 7: 586 In the following example the client has specified multiple mailbox 587 patterns. Note that this example doesn't use the mailbox hierarchy 588 used in the previous examples. 590 C: BBB LIST "" ("INBOX" "Drafts" "Sent/%") 591 S: * LIST () "/" "INBOX" 592 S: * LIST (\NoInferiors) "/" "Drafts" 593 S: * LIST () "/" "Sent/March2004" 594 S: * LIST (\Marked) "/" "Sent/December2003" 595 S: * LIST () "/" "Sent/August2004" 596 S: BBB OK done 598 Example 8: 600 The following example demonstates the difference between 601 \HasChildren and \PlaceHolder/\SubMailboxes. 603 Let's assume there is the following hierarchy: 605 C: C01 LIST "" "*" 606 S: * LIST (\Marked \NoInferiors) "/" "inbox" 607 S: * LIST () "/" "Foo" 608 S: * LIST () "/" "Foo/Bar" 609 S: * LIST () "/" "Foo/Baz" 610 S: * LIST () "/" "Moo" 611 S: C01 OK done 613 If the client asks RETURN (CHILDREN) it will get: 615 C: CA3 LIST "" "%" RETURN (CHILDREN) 616 S: * LIST (\Marked \NoInferiors) "/" "inbox" 617 S: * LIST (\HasChildren) "/" "Foo" 618 S: * LIST (\HasNoChildren) "/" "Moo" 619 S: CA3 OK done 621 A). Let's also assume that the mailbox "Foo/Baz" is the only 622 subscribed mailbox. Then 624 C: C02 LIST (SUBSCRIBED) "" "*" 625 S: * LIST (\Subscribed) "/" "Foo/Baz" 626 S: C02 OK done 628 Now, if the client issues , the server will 629 return no mailboxes (as the mailboxes "Moo", "Foo" and "Inbox" are NOT 630 subscribed). However, if the client issues: 632 C: C04 LIST (SUBSCRIBED MATCHPARENT) "" "%" 633 S: * LIST (\PlaceHolder) "/" "Foo" 634 S: C04 OK done 636 i.e. the mailbox "Foo" is not subscribed, but it has a child that is. 638 A1). If the mailbox "Foo" would have been subscribed instead, the last 639 command would return: 641 S: * LIST (\HasSubMailboxes \Subscribed) "/" "Foo" 643 or even 645 S: * LIST (\HasSubMailboxes \HasChildren \Subscribed) "/" "Foo" 647 A2). If we assume instead that the mailbox "Foo" is not part of the 648 original hierarchy and is not subscribed, the last command will 649 return 651 S: * LIST (\PlaceHolder \NonExistent) "/" "Foo" 653 B). Now, let's assume that no mailbox is subscribed. In this case 654 the command will return 655 no responses, as there are no subscribed children (even though 656 "Foo" has children). 658 C). And finally, let's assume that the mailboxes "Foo" and "Moo" are 659 subscribed. In this case the command: 661 C: LIST (SUBSCRIBED MATCHPARENT) "" "%" RETURN (CHILDREN) 663 will return: 665 S: * LIST (\HasChildren \Subscribed) "/" "Foo" 666 S: * LIST (\HasNoChildren \Subscribed) "/" "Moo" 668 Which means that the mailbox "Foo" has children, but none of them 669 is subscribed. 671 Example 9: 673 The following example demonstrates that the calculation of \PlaceHolder 674 (or \HasSubMailboxes) attributes is not affected by the fact that 675 children mailboxes match the canonical LIST pattern. 677 Let's assume there is the following hierarchy: 679 C: D01 LIST "" "*" 680 S: * LIST (\Marked \NoInferiors) "/" "inbox" 681 S: * LIST () "/" "foo2" 682 S: * LIST () "/" "foo2/bar1" 683 S: * LIST () "/" "foo2/bar2" 684 S: * LIST () "/" "baz2" 685 S: * LIST () "/" "baz2/bar2" 686 S: * LIST () "/" "baz2/bar22" 687 S: * LIST () "/" "baz2/bar222" 688 S: * LIST () "/" "eps2" 689 S: * LIST () "/" "eps2/mamba" 690 S: * LIST () "/" "quux2/bar2" 691 S: D01 OK done 693 And that the following mailboxes are subscribed: 695 C: D02 LIST (SUBSCRIBED) "" "*" 696 S: * LIST (\Subscribed) "/" "foo2/bar1" 697 S: * LIST (\Subscribed) "/" "foo2/bar2" 698 S: * LIST (\Subscribed) "/" "baz2/bar2" 699 S: * LIST (\Subscribed) "/" "baz2/bar22" 700 S: * LIST (\Subscribed) "/" "baz2/bar222" 701 S: * LIST (\Subscribed) "/" "eps2" 702 S: * LIST (\Subscribed) "/" "eps2/mamba" 703 S: * LIST (\Subscribed) "/" "quux2/bar2" 704 S: D02 OK done 706 The client issues the following command first: 708 C: D03 LIST (MATCHPARENT SUBSCRIBED) "" "*2" 709 S: * LIST (\PlaceHolder) "/" "foo2" 710 S: * LIST (\Subscribed) "/" "foo2/bar2" 711 S: * LIST (\PlaceHolder) "/" "baz2" 712 S: * LIST (\Subscribed) "/" "baz2/bar2" 713 S: * LIST (\Subscribed) "/" "baz2/bar22" 714 S: * LIST (\Subscribed) "/" "baz2/bar222" 715 S: * LIST (\HasSubMailboxes \Subscribed) "/" "eps2" 716 S: * LIST (\Subscribed) "/" "quux2/bar2" 717 S: D03 OK done 719 and the server may also include 721 S: * LIST (\PlaceHolder \NonExistent) "/" "quux2" 723 The \PlaceHolder attribute is returned for mailboxes "foo2" and 724 "baz2" (and the \HasSubMailboxes is returned for the mailbox "eps2"), 725 because all of them have subscribed children, 726 even though for the mailbox "foo2" only one of the two subscribed 727 children match the pattern, for the mailbox "baz2" all the subscribed 728 children match the pattern and for the mailbox "eps2" none of the 729 subscribed children match the pattern. 731 Note that if the client issues 733 C: D03 LIST (MATCHPARENT SUBSCRIBED) "" "*" 734 S: * LIST (\PlaceHolder) "/" "foo2" 735 S: * LIST (\Subscribed) "/" "foo2/bar1" 736 S: * LIST (\Subscribed) "/" "foo2/bar2" 737 S: * LIST (\PlaceHolder) "/" "baz2" 738 S: * LIST (\Subscribed) "/" "baz2/bar2" 739 S: * LIST (\Subscribed) "/" "baz2/bar22" 740 S: * LIST (\Subscribed) "/" "baz2/bar222" 741 S: * LIST (\HasSubMailboxes \Subscribed) "/" "eps2" 742 S: * LIST (\Subscribed) "/" "eps2/mamba" 743 S: * LIST (\Subscribed) "/" "quux2/bar2" 744 S: D03 OK done 746 the mailboxes "foo2", "baz2" and "eps2" still have the same 747 \PlaceHolder/\HasSubMailboxes attribute, even though this information 748 is redundant and the client can determine it by itself. 750 Example 10: 752 The following example shows usage of multiple mailbox patterns. 753 It also demonstrates that \HasSubmailboxes/\PlaceHolder attributes 754 don't necessarily imply \HasChildren. 756 C: a1 LIST "" ("foo" "foo/*") 757 S: * LIST () "/" foo 758 S: a1 OK done 760 C: a2 LIST (SUBSCRIBED) "" "foo/*" 761 S: * LIST (\Subscribed \NonExistent) "/" foo/bar 762 S: a2 OK done 764 C: a3 LIST (SUBSCRIBED MATCHPARENT) "" foo RETURN (CHILDREN) 765 S: * LIST (\Placeholder \HasNoChildren) "/" foo 766 S: a3 OK done 768 6. Formal Syntax 770 The following syntax specification uses the augmented Backus-Naur 771 Form (BNF) as described in [ABNF]. Terms not defined here are taken 772 from [IMAP4]. "vendor-token" is defined in [ACAP]. 774 child-mbox-flag = "\HasChildren" / "\HasNoChildren" 775 ; attributes for CHILDREN return option, at most one 776 ; possible per LIST response 778 list = "LIST" [SP list-select-opts] SP mailbox SP mbox-or-pat 779 [SP list-return-opts] 781 list-select-opts = "(" [*(list-select-mod-opt SP) list-select-base-opt 782 *(SP list-select-opt)] ")" 783 ; list selection options, e.g. REMOTE 785 list-return-opts = "RETURN" SP "(" [return-option *(SP return-option)] ")" 786 ; list return options, e.g. CHILDREN 788 mparent-mbox-flag = "\PlaceHolder" / "\HasSubMailboxes" 789 ; attributes for MATCHPARENT selection option, 790 ; at most one possible per LIST response 792 mailbox-list = "(" [mbx-list-flags] ")" SP 793 (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox 794 [SP mbox-list-extended] 796 mbox-list-extended = "(" [mbox-list-extended-item 797 *(SP mbox-list-extended-item)] ")" 799 mbox-list-extended-item = "(" mbox-list-extended-item-data ")" 801 mbox-list-extended-item-data = mbox-list-extended-item-tag SP nstring-list 803 mbox-list-extended-item-tag = astring 804 ; The content MUST conform to either "eitem-vendor-tag" or 805 ; "eitem-standard-tag" ABNF productions. 806 ; A tag registration template is described in section 807 ; 8.5 of this document. 809 mbox-or-pat = list-mailbox / patterns 811 patterns = "(" list-mailbox *(SP list-mailbox) ")" 813 eitem-vendor-tag = vendor-tag 814 ; a vendor specific tag for extended list data 816 eitem-standard-tag = atom 817 ; a tag for extended list data defined in a Standard 818 ; Track or Experimental RFC. 820 nstring-list = nstring / 821 "(" [nstring-list *(SP nstring-list)] ")" 822 ;; a recursive list definition 824 mbox-list-oflag = child-mbox-flag / mparent-mbox-flag / "\NonExistent" / 825 / "\Subscribed" / "\Remote" 827 list-select-opt = list-sel-mod-opt / list-sel-base-opt 828 ; An option registration template is described in 829 ; section 8.3 of this document. 831 list-sel-base-opt = "SUBSCRIBED" / "REMOTE" / option-extension 832 ; options that can be used by themselves 834 list-sel-mod-opt = "MATCHPARENT" / option-extension 835 ; options that require a list-select-base-opt 836 ; to also be present 838 return-option = "SUBSCRIBED" / "CHILDREN" / 839 option-extension 841 option-extension = option-vendor-tag / option-standard-tag 843 option-vendor-tag = vendor-tag 844 ; a vendor specific option 846 option-standard-tag= atom 847 ; an option defined in a Standard Track or 848 ; Experimental RFC 850 vendor-tag = vendor-token "-" atom 852 7. Security Considerations 854 This document describes syntactic changes to the specification of the 855 IMAP4 commands LIST, LSUB, RLIST, and RLSUB, and the modified LIST 856 command has the same security considerations as those commands. They 857 are described in [IMAP4] and [MboxRefer]. 859 The Child Mailbox Extension provides a client a more efficient means 860 of determining whether a particular mailbox has children. If a 861 mailbox has children, but the currently authenticated user does not 862 have access to any of them, the server SHOULD respond with a 863 \HasNoChildren attribute. In many cases, however, a server may not 864 be able to efficiently compute whether a user has access to all child 865 mailboxes. If such a server responds with a \HasChildren attribute, 866 when in fact the currently authenticated user does not have access to 867 any child mailboxes, potentially more information is conveyed about 868 the mailbox than intended. In most situations this will not be a 869 security concern, because if information regarding whether a mailbox 870 has children is considered sensitive, a user would not be granted 871 access to that mailbox in the first place. 873 8. IANA Considerations 875 8.1. Guidelines for IANA 877 It is requested that IANA creates two new registries for LISTEXT 878 options and LISTEXT extended response data. The templates and 879 the initial registrations are detailed below. 881 8.2. Registration procedure and Change control 883 Registration of a LISTEXT option is done by filling in the template 884 in section 8.3 and sending it via electronic mail to . 885 Registration of a LISTEXT extended data item is done by filling in the 886 template in section 8.5 and sending it via electronic mail to . 887 IANA has the right to reject obviously bogus registrations, but will 888 perform no review of claims made in the registration form. 890 A LISTEXT option/extended data item name that starts with "V-" is reserved 891 for vendor specific options/extended data items. All options, whether 892 they are vendor specific or global, should be registered with IANA. 893 If a LISTEXT extended data item is returned as a result of requesting 894 a particular LISTEXT option, the name of the option SHOULD be used 895 as the name of the LISTEXT extended data item. 897 Each vendor specific options/extended data item MUST start with their 898 vendor-token ("vendor prefix"). The vendor-token MUST be registered 899 with IANA, using the [ACAP] vendor subtree registry. 901 Standard LISTEXT option/extended data item names are case insensitive. 902 If the vendor prefix is omitted from a vendor specific LISTEXT 903 option/extended data item name, the rest is case insensitive. The vendor 904 prefix itself is not case-sensitive, as it might contain non-ASCII 905 characters. 907 While the registration procedures do not require it, authors of LISTEXT 908 options/extended data items are encouraged to seek community review and 909 comment whenever that is feasible. Authors may seek community review by 910 posting a specification of their proposed mechanism as an Internet- 911 Draft. LISTEXT options/extended data items intended for widespread use 912 should be standardized through the normal IETF process, when appropriate. 914 Comments on registered LISTEXT options/extended response data should 915 first be sent to the "owner" of the mechanism and/or to the IMAPEXT WG 916 mailing list. 917 Submitters of comments may, after a reasonable attempt to contact the 918 owner, request IANA to attach their comment to the registration itself. 919 If IANA approves of this, the comment will be 920 made accessible in conjunction with the registration LISTEXT options/ 921 extended response data itself. 923 Once a LISTEXT registration has been published by IANA, the 924 author may request a change to its definition. The change request 925 follows the same procedure as the registration request. 927 The owner of a LISTEXT registration may pass responsibility for the 928 registered option/extended data item to another person or agency by 929 informing IANA; this can be done without discussion or review. 931 The IESG may reassign responsibility for a LISTEXT option/extended data item. 932 The most common case of this will be to enable changes to be made to 933 mechanisms where the author of the registration has died, moved out 934 of contact or is otherwise unable to make changes that are important 935 to the community. 937 LISTEXT registrations may not be deleted; mechanisms which are 938 no longer believed appropriate for use can be declared OBSOLETE by a 939 change to their "intended use" field; such LISTEXT options/extended data 940 items will be clearly marked in the lists published by IANA. 942 The IESG is considered to be the owner of all LISTEXT options/extended data items 943 which are on the IETF standards track. 945 8.3. Registration template for LISTEXT options 947 To: iana@iana.org 948 Subject: Registration of LISTEXT option X 950 LISTEXT option name: 952 LISTEXT option type: (One of SELECTION or RETURN) 954 Implied return options(s), if the option type is SELECTION: (zero or more) 956 LISTEXT option description: 958 Published specification (optional, recommended): 960 Security considerations: 962 Intended usage: 963 (One of COMMON, LIMITED USE or OBSOLETE) 965 Person & email address to contact for further information: 967 Owner/Change controller: 969 (Any other information that the author deems interesting may be 970 added below this line.) 972 8.4. Initial LISTEXT option registrations 974 It is requested that the LISTEXT option registry is being populated 975 with the following entries: 977 1) 979 To: iana@iana.org 980 Subject: Registration of LISTEXT option SUBSCRIBED 982 LISTEXT option name: SUBSCRIBED 984 LISTEXT option type: SELECTION 986 Implied return options(s): SUBSCRIBED 988 LISTEXT option description: Causes the LIST command to list 989 subscribed mailboxes, rather than the actual mailboxes. 991 Published specification : this RFC, section 3. 993 Security considerations: this RFC, section 7. 995 Intended usage: COMMON 997 Person & email address to contact for further information: 998 Alexey Melnikov 1000 Owner/Change controller: IESG 1002 2) 1004 To: iana@iana.org 1005 Subject: Registration of LISTEXT option REMOTE 1007 LISTEXT option name: REMOTE 1009 LISTEXT option type: SELECTION 1011 Implied return options(s): (none) 1013 LISTEXT option description: causes the LIST command to return 1014 remote mailboxes as well as local ones, as described in 1015 RFC 2193. 1017 Published specification : this RFC, section 3. 1019 Security considerations: this RFC, section 7. 1021 Intended usage: COMMON 1023 Person & email address to contact for further information: 1024 Alexey Melnikov 1026 Owner/Change controller: IESG 1028 3) 1030 To: iana@iana.org 1031 Subject: Registration of LISTEXT option SUBSCRIBED 1033 LISTEXT option name: SUBSCRIBED 1035 LISTEXT option type: RETURN 1037 LISTEXT option description: Causes the LIST command to return 1038 subscription state. 1040 Published specification : this RFC, section 3. 1042 Security considerations: this RFC, section 7. 1044 Intended usage: COMMON 1046 Person & email address to contact for further information: 1047 Alexey Melnikov 1049 Owner/Change controller: IESG 1051 4) 1053 To: iana@iana.org 1054 Subject: Registration of LISTEXT option MATCHPARENT 1056 LISTEXT option name: MATCHPARENT 1058 LISTEXT option type: SELECTION 1060 Implied return options(s): (none) 1062 LISTEXT option description: Requests that \Placeholder/ 1063 \HasSubMailboxes attributes are to be returned. 1065 Published specification : this RFC, sections 3. 1067 Published specification : this RFC 1069 Security considerations: this RFC, section 7. 1071 Intended usage: COMMON 1073 Person & email address to contact for further information: 1074 Alexey Melnikov 1076 Owner/Change controller: IESG 1078 5) 1080 To: iana@iana.org 1081 Subject: Registration of LISTEXT option CHILDREN 1083 LISTEXT option name: CHILDREN 1085 LISTEXT option type: RETURN 1087 LISTEXT option description: Requests mailbox child information. 1089 Published specification : this RFC, sections 3 and 4. 1091 Published specification : this RFC 1093 Security considerations: this RFC, section 7. 1095 Intended usage: COMMON 1097 Person & email address to contact for further information: 1098 Alexey Melnikov 1100 Owner/Change controller: IESG 1102 8.5. Registration template for LISTEXT extended data item 1104 To: iana@iana.org 1105 Subject: Registration of LISTEXT extended data item X 1107 LISTEXT extended data item tag: 1109 LISTEXT extended data item description: 1111 Which LISTEXT option(s) (and their types) causes this extended 1112 data item to be returned (if any): 1114 Published specification (optional, recommended): 1116 Security considerations: 1118 Intended usage: 1119 (One of COMMON, LIMITED USE or OBSOLETE) 1121 Person & email address to contact for further information: 1123 Owner/Change controller: 1125 (Any other information that the author deems interesting may be 1126 added below this line.) 1128 9. References 1130 9.1. Normative References 1132 [Keywords] Bradner, S., "Key words for use in RFCs to Indicate 1133 Requirement Levels", RFC 2119, Harvard University, March 1997. 1135 [ABNF] Crocker, D., and Overell, P. "Augmented BNF for Syntax 1136 Specifications: ABNF", RFC 2234, November 1997. 1138 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 1139 4rev1", RFC 3501, University of Washington, March 2003. 1141 [MboxRefer] Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193, 1142 Microsoft Corporation, September 1997. 1144 [ChildMbox] Gahrns, M. & Cheng, R., "IMAP4 Child Mailbox Extension", 1145 RFC 3348, Microsoft Corporation, July 2002. 1147 [ACAP] Newman, C. and J. Myers, "ACAP -- Application 1148 Configuration Access Protocol", RFC 2244, November 1997. 1150 10. Acknowledgements 1152 Mike Gahrns and Raymond Cheng of Microsoft Corporation originally 1153 devised the Child Mailbox Extension and proposed it in 1997; the 1154 idea, as well as most of the text in section 4, is theirs. 1156 This document is the result of discussions on the IMAP4 and IMAPEXT 1157 mailing lists and is meant to reflect consensus of those groups. 1158 In particular, Mark Crispin, Philip Guenther, Cyrus Daboo, Timo Sirainen, 1159 Ken Murchison, Rob Siemborski, Steve Hole, Arnt Gulbrandsen, Larry 1160 Greenfield, Dave Cridland and Pete Maclean were active participants 1161 in this discussion or made suggestions to this document. 1163 11. Author's Address 1165 Barry Leiba 1166 IBM T.J. Watson Research Center 1167 30 Saw Mill River Road 1168 Hawthorne, NY 10532 1169 Phone: 1-914-784-7941 1170 Email: leiba@watson.ibm.com 1172 Alexey Melnikov 1173 Isode Limited 1174 5 Castle Business Village 1175 36 Station Road 1176 Hampton, Middlesex 1177 TW12 2BX, UK 1179 Email: Alexey.Melnikov@isode.com 1180 Home page: http://www.melnikov.ca/ 1182 12. IPR Disclosure Acknowledgement 1184 By submitting this Internet-Draft, we certify that any applicable 1185 patent or other IPR claims of which I am aware have been disclosed, 1186 and any of which we become aware will be disclosed, in accordance with 1187 RFC 3668. 1189 13. Intellectual Property 1191 The IETF takes no position regarding the validity or scope of any 1192 Intellectual Property Rights or other rights that might be claimed to 1193 pertain to the implementation or use of the technology described in 1194 this document or the extent to which any license under such rights 1195 might or might not be available; nor does it represent that it has 1196 made any independent effort to identify any such rights. Information 1197 on the procedures with respect to rights in RFC documents can be 1198 found in BCP 78 and BCP 79. 1200 Copies of IPR disclosures made to the IETF Secretariat and any 1201 assurances of licenses to be made available, or the result of an 1202 attempt made to obtain a general license or permission for the use of 1203 such proprietary rights by implementers or users of this 1204 specification can be obtained from the IETF on-line IPR repository at 1205 http://www.ietf.org/ipr. 1207 The IETF invites any interested party to bring to its attention any 1208 copyrights, patents or patent applications, or other proprietary 1209 rights that may cover technology that may be required to implement 1210 this standard. Please address the information to the IETF at 1211 ietf-ipr@ietf.org. 1213 14. Full Copyright Statement 1215 Copyright (C) The Internet Society (2004). This document is subject 1216 to the rights, licenses and restrictions contained in BCP 78, and 1217 except as set forth therein, the authors retain all their rights. 1219 This document and the information contained herein are provided on an 1220 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1221 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1222 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1223 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1224 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1225 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1227 Acknowledgement 1229 Funding for the RFC Editor function is currently provided by 1230 the Internet Society.