idnits 2.17.1 draft-ietf-imapext-2086upd-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 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1170. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1142. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1149. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1155. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC2086, but the abstract doesn't seem to directly say this. It does mention RFC2086 though, so this could be OK. 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 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 (June 12, 2005) is 6887 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) == Missing Reference: 'UNSEEN 12' is mentioned on line 772, but not defined == Missing Reference: 'UIDVALIDITY 3857529045' is mentioned on line 773, but not defined == Missing Reference: 'UIDNEXT 4392' is mentioned on line 774, but not defined ** 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 3454 (ref. 'Stringprep') (Obsoleted by RFC 7564) ** Obsolete normative reference: RFC 4013 (ref. 'SASLprep') (Obsoleted by RFC 7613) -- Obsolete informational reference (is this intentional?): RFC 2086 (Obsoleted by RFC 4314) Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual A. Melnikov 3 Internet-Draft Isode Ltd. 4 Obsoletes: 2086 (if approved) June 12, 2005 5 Expires: December 14, 2005 7 IMAP4 ACL extension 8 draft-ietf-imapext-2086upd-07 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet- 20 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. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 14, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 The ACL (Access Control List) extension (RFC 2086) of the Internet 42 Message Access Protocol (IMAP) permits mailbox access control lists 43 to be retrieved and manipulated through the IMAP protocol. 45 This document is a revision of RFC 2086. It defines several new 46 access control rights and clarifies which rights are required for 47 different IMAP commands. 49 Conventions used in this document 51 In examples, "C:" and "S:" indicate lines sent by the client and 52 server respectively. 54 In all examples "/" character is used as hierarchy separator. 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 60 The phrase "ACL server" is just a short cut for saying "IMAP server 61 that supports ACL extension as defined in this document". 63 Table of Contents 65 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 4 66 2. Access Control . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.1 Standard rights . . . . . . . . . . . . . . . . . . . . . 5 68 2.1.1 Obsolete rights . . . . . . . . . . . . . . . . . . . 6 69 2.2 Rights defined in RFC 2086 . . . . . . . . . . . . . . . . 9 70 3. Access control management commands and responses . . . . . . . 9 71 3.1 SETACL command . . . . . . . . . . . . . . . . . . . . . . 9 72 3.2 DELETEACL command . . . . . . . . . . . . . . . . . . . . 10 73 3.3 GETACL command . . . . . . . . . . . . . . . . . . . . . . 11 74 3.4 LISTRIGHTS command . . . . . . . . . . . . . . . . . . . . 11 75 3.5 MYRIGHTS command . . . . . . . . . . . . . . . . . . . . . 12 76 3.6 ACL response . . . . . . . . . . . . . . . . . . . . . . . 12 77 3.7 LISTRIGHTS response . . . . . . . . . . . . . . . . . . . 12 78 3.8 MYRIGHTS response . . . . . . . . . . . . . . . . . . . . 13 79 4. Rights required to perform different IMAP4rev1 commands . . . 13 80 5. Other considerations . . . . . . . . . . . . . . . . . . . . . 17 81 5.1 Additional requirements and Implementation notes . . . . . 17 82 5.1.1 Servers . . . . . . . . . . . . . . . . . . . . . . . 17 83 5.1.2 Clients . . . . . . . . . . . . . . . . . . . . . . . 19 84 5.2 Mapping of ACL rights to READ-WRITE and READ-ONLY 85 response codes . . . . . . . . . . . . . . . . . . . . . . 19 86 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 87 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 21 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 89 9. Internationalization Considerations . . . . . . . . . . . . . 23 90 A. Changes since RFC 2086 . . . . . . . . . . . . . . . . . . . . 23 91 B. Compatibility with RFC 2086 . . . . . . . . . . . . . . . . . 24 92 C. Known deficiencies . . . . . . . . . . . . . . . . . . . . . . 24 93 D. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 94 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 95 10.1 Normative References . . . . . . . . . . . . . . . . . . . 25 96 10.2 Informative References . . . . . . . . . . . . . . . . . . 26 97 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 26 98 Intellectual Property and Copyright Statements . . . . . . . . 27 100 1. Introduction and Overview 102 The ACL (Access Control List) extension of the Internet Message 103 Access Protocol [IMAP4] permits mailbox access control lists to be 104 retrieved and manipulated through the IMAP protocol. 106 This document is a revision of RFC 2086 [RFC2086]. It tries to 107 clarify different ambiguities in RFC 2086, in particular use of UTF-8 108 [UTF-8] in identifiers, which rights are required for different IMAP4 109 commands; how READ-WRITE/READ-ONLY response codes are related to ACL. 111 2. Access Control 113 The ACL extension is present in any IMAP4 implementation which 114 returns "ACL" as one of the supported capabilities to the CAPABILITY 115 command. 117 A server implementation conformant to this document MUST also return 118 rights (see below) not defined in Section 2.2 in the "RIGHTS=" 119 capability. 121 An access control list is a set of pairs. An ACL 122 applies to a mailbox name. 124 Identifier is a UTF-8 [UTF-8] string. The identifier "anyone" is 125 reserved to refer to the universal identity (all authentications, 126 including anonymous). All user name strings accepted by the LOGIN or 127 AUTHENTICATE commands to authenticate to the IMAP server are reserved 128 as identifiers for the corresponding users. Identifiers starting 129 with a dash ("-") are reserved for "negative rights", described 130 below. All other identifier strings are interpreted in an 131 implementation-defined manner. 133 Rights is a string listing a (possibly empty) set of alphanumeric 134 characters, each character listing a set of operations which is being 135 controlled. Lowercase letters are reserved for "standard" rights, 136 listed in Section 2.1. (Note that for compatibility with deployed 137 clients and servers uppercase rights are not allowed). The set of 138 standard rights can only be extended by a standards-track document. 139 Digits are reserved for implementation or site defined rights. 141 An implementation MAY tie rights together or MAY force rights to 142 always or never be granted to particular identifiers. For example, 143 in an implementation that uses UNIX mode bits, the rights "swite" are 144 tied, the "a" right is always granted to the owner of a mailbox and 145 is never granted to another user. If rights are tied in an 146 implementation, the implementation must be conservative in granting 147 rights in response to SETACL commands--unless all rights in a tied 148 set are specified, none of that set should be included in the ACL 149 entry for that identifier. A client can discover the set of rights 150 which may be granted to a given identifier in the ACL for a given 151 mailbox name by using the LISTRIGHTS command. 153 It is possible for multiple identifiers in an access control list to 154 apply to a given user. For example, an ACL may include rights to be 155 granted to the identifier matching the user, one or more 156 implementation-defined identifiers matching groups which include the 157 user, and/or the identifier "anyone". How these rights are combined 158 to determine the user's access is implementation-defined. An 159 implementation may choose, for example, to use the union of the 160 rights granted to the applicable identifiers. An implementation may 161 instead choose, for example, to only use those rights granted to the 162 most specific identifier present in the ACL. A client can determine 163 the set of rights granted to the logged-in user for a given mailbox 164 name by using the MYRIGHTS command. 166 When an identifier in an ACL starts with a dash ("-"), that indicates 167 that associated rights are to be removed from the identifier that is 168 prefixed by the dash. This is referred to as a "negative right". 169 This differs from DELETEACL in that a negative right is added to the 170 ACL, and is a part of the calculation of the rights. 172 Let's assume that an identifier "fred" refers to a user with login 173 "fred". If the identifier "-fred" is granted the "w" right, that 174 indicates that the "w" right is to be removed from users matching the 175 identifier "fred", even though the user "fred" might have the "w" 176 right as a consequence of some other identifier in the ACL. A 177 DELETEACL of "fred" simply deletes the identifier "fred" from the 178 ACL; it does not affect any rights that the user "fred" may get from 179 another entry in the ACL, in particular it doesn't affect rights 180 granted to the identifier "-fred". 182 Server implementations are not required to support "negative right" 183 identifiers. 185 2.1 Standard rights 187 The currently defined standard rights are (note that the list below 188 doesn't list all commands that use a particular right): 190 l - lookup (mailbox is visible to LIST/LSUB commands, SUBSCRIBE 191 mailbox) 192 r - read (SELECT the mailbox, perform STATUS) 193 s - keep seen/unseen information across sessions (set or clear 194 \SEEN flag via STORE, also set \SEEN during APPEND/COPY/ 195 FETCH BODY[...]) 196 w - write (set or clear flags other than \SEEN and \DELETED via 197 STORE, also set them during APPEND/COPY) 198 i - insert (perform APPEND, COPY into mailbox) 199 p - post (send mail to submission address for mailbox, 200 not enforced by IMAP4 itself) 201 k - create mailboxes (CREATE new sub-mailboxes in any 202 implementation-defined hierarchy, parent mailbox for the new 203 mailbox name in RENAME) 204 x - delete mailbox (DELETE mailbox, old mailbox name in RENAME) 205 t - delete messages (set or clear \DELETED flag via STORE, set 206 \DELETED flag during APPEND/COPY) 207 e - perform EXPUNGE and expunge as a part of CLOSE. 208 a - administer (perform SETACL/DELETEACL/GETACL) 210 2.1.1 Obsolete rights 212 Due to ambiguity in RFC 2086 some existing RFC 2086 server 213 implementations use the "c" right to control the DELETE command. 214 Others chose to use the "d" right to control the DELETE command. For 215 the former group, let's define the "create" right as union of the "k" 216 and "x" rights, and the "delete" right as union of the "e" and "t" 217 rights. For the latter group, let's define the "create" rights as a 218 synonym to the "k" right, and the "delete" right as union of the "e", 219 "t" and "x" rights. 221 For compatibility with RFC 2086 this section defines two virtual 222 rights "d" and "c". 224 If a client includes the "d" right in a rights list, then it MUST be 225 treated as if the client had included every member of the "delete" 226 right. (It is not an error for a client to specify both the "d" 227 right and one or more members of the "delete" right, but the effect 228 is no different than if just the "d" right or all members of the 229 "delete" right had been specified). 231 When any of the "delete" member rights is set in a list of rights, 232 the server MUST also include the "d" right when returning the list in 233 a MYRIGHTS or ACL response. This is so to enable older clients 234 conforming to RFC 2086 to work with newer servers. (*) 236 Example: C: A001 SeTacl INBOX/Drafts David lrswida 237 S: A001 OK Setacl complete 239 The client has specified the "d" right in the SETACL command above 240 and it expands to "et" on the server: 242 C: A002 getacl INBOX/Drafts 243 S: * ACL INBOX Fred rwipslxetda David lrswideta 244 S: A002 OK Getacl complete 246 If the identifier specified in the LISTRIGHTS command can be granted 247 any of the "delete" member rights on a mailbox, then the server MUST 248 include the "d" right in the corresponding LISTRIGHTS response. (*) 249 If the member rights aren't tied to non-member rights, then the "d" 250 right is returned by itself in the LISTRIGHTS response. If any of 251 the member rights needs to be tied to one (or more) non-member right, 252 then the "d" right and all of the member rights need to be tied to 253 the same non-member right(s) (**). 255 If a client includes the "c" right in a rights list, then it MUST be 256 treated as if the client had included every member of the "create" 257 right. (It is not an error for a client to specify both the "c" 258 right and one or more members of the "create" right, but the effect 259 is no different than if just the "c" right or all members of the 260 "create" right had been specified). 262 When any of the "create" member rights is set in a list of rights, 263 the server MUST also include the "c" right when returning the list in 264 a MYRIGHTS or ACL response. This is so to enable older clients 265 conforming to RFC 2086 to work with newer servers. (*) 267 Example: C: A003 Setacl INBOX/Drafts Byron lrswikda 268 S: A001 OK Setacl complete 269 C: A002 getAcl INBOX/Drafts 270 S: * ACL INBOX Fred rwipslxeta Byron lrswikcdeta 271 S: A002 OK Getacl complete 273 The client has specified the "d" right in the SETACL command above 274 and it expands to "et" on the server: As the client has specified 275 the "k" right (which is a member of the "c" right), the server also 276 returns the "c" right. 278 If the identifier specified in the LISTRIGHTS command can be granted 279 any of the "create" member rights on a mailbox, then the server MUST 280 include the "c" right in the corresponding LISTRIGHTS response. (*) 281 If the member rights aren't tied to non-member rights, then the "c" 282 right is returned by itself in the LISTRIGHTS response. If any of 283 the member rights needs to be tied to one (or more) non-member right, 284 then the "c" right and all of the member rights need to be tied to 285 the same non-member right(s) (**). 287 Example: The server that ties the rights as follows 289 lr s w i p k x t 291 and c=k 293 will return: 295 S: * LISTRIGHTS archive/imap anyone "" 296 lr s w i p k x t c d 298 Example: The server that ties the rights as follows 300 lr s w i p k xte 302 and c=k 304 will return: 306 S: * LISTRIGHTS archive/imap anyone "" 307 lr s w i p k xte c d 309 Example: The server that ties the rights as follows 311 lr s w i p k x te 313 and c=k 315 will return: 317 S: * LISTRIGHTS archive/imap anyone "" 318 lr s w i p k c x te d 320 Example: The server that ties the rights as follows 322 lr swte i p k x 324 and c=kx 326 will return: 328 S: * LISTRIGHTS archive/imap anyone "" 329 lr swted i p k x c 331 (*) Clients conforming to this document MUST ignore the virtual "d" 332 and "c" rights in MYRIGHTS, ACL and LISTRIGHTS responses. 334 (**) The IMAPEXT Working Group has debated this issue in great length 335 and after reviewing existing ACL implementations concluded that this 336 is a reasonable restriction. 338 2.2 Rights defined in RFC 2086 340 The "RIGHTS=" capability MUST NOT include any of the rights defined 341 in RFC 2086: "l", "r", "s", "w", "i", "p", "a", "c", "d", and the 342 digits ("0" .. "9"). 344 3. Access control management commands and responses 346 Servers, when processing a command that has an identifier as a 347 parameter (i.e. any of SETACL, DELETEACL and LISTRIGHTS commands), 348 SHOULD first prepare the received identifier using "SASLprep" profile 349 [SASLprep] of the "stringprep" algorithm [Stringprep]. If the 350 preparation of the identifier fails or results in an empty string, 351 the server MUST refuse to perform the command with a BAD response. 353 3.1 SETACL command 355 Arguments: mailbox name 356 identifier 357 access right modification 359 Data: no specific data for this command 361 Result: OK - setacl completed 362 NO - setacl failure: can't set acl 363 BAD - arguments invalid 365 The SETACL command changes the access control list on the specified 366 mailbox so that the specified identifier is granted permissions as 367 specified in the third argument. 369 The third argument is a string containing an optional plus ("+") or 370 minus ("-") prefix, followed by zero or more rights characters. If 371 the string starts with a plus, the following rights are added to any 372 existing rights for the identifier. If the string starts with a 373 minus, the following rights are removed from any existing rights for 374 the identifier. If the string does not start with a plus or minus, 375 the rights replace any existing rights for the identifier. 377 Note that an unrecognized right MUST cause the command to return the 378 BAD response. In particular, server MUST NOT silently ignore 379 unrecognized rights. 381 Example: C: A001 GETACL INBOX/Drafts 382 S: * ACL INBOX/Drafts Fred rwipslxetad Chris lrswi 383 S: A001 OK Getacl complete 384 C: A002 SETACL INBOX/Drafts Chris +cda 385 S: A002 OK Setacl complete 386 C: A003 GETACL INBOX/Drafts 387 S: * ACL INBOX/Drafts Fred rwipslxetad Chris lrswicdakxet 388 S: A003 OK Getacl complete 390 C: A035 SETACL INBOX/Drafts John lrQswicda 391 S: A035 BAD Uppercase rights are not allowed 393 C: A036 SETACL INBOX/Drafts John lrqswicda 394 S: A036 BAD The q right is not supported 396 3.2 DELETEACL command 398 Arguments: mailbox name 399 identifier 401 Data: no specific data for this command 403 Result: OK - deleteacl completed 404 NO - deleteacl failure: can't delete acl 405 BAD - arguments invalid 407 The DELETEACL command removes any pair for the 408 specified identifier from the access control list for the specified 409 mailbox. 411 Example: C: B001 getacl INBOX 412 S: * ACL INBOX Fred rwipslxetad -Fred wetd $team w 413 S: B001 OK Getacl complete 414 C: B002 DeleteAcl INBOX Fred 415 S: B002 OK Deleteacl complete 416 C: B003 GETACL INBOX 417 S: * ACL INBOX -Fred wetd $team w 418 S: B003 OK Getacl complete 420 3.3 GETACL command 422 Arguments: mailbox name 424 Data: untagged responses: ACL 426 Result: OK - getacl completed 427 NO - getacl failure: can't get acl 428 BAD - arguments invalid 430 The GETACL command returns the access control list for mailbox in an 431 untagged ACL response. 433 Some implementations MAY permit multiple forms of an identifier to 434 reference the same IMAP account. Usually, such implementations will 435 have a canonical form that is stored internally. An ACL response 436 caused by an GETACL command MAY include a canonicalized form of the 437 identifier which might be different from the one used in the 438 corresponding SETACL command. 440 Example: C: A002 GETACL INBOX 441 S: * ACL INBOX Fred rwipsldexta 442 S: A002 OK Getacl complete 444 3.4 LISTRIGHTS command 446 Arguments: mailbox name 447 identifier 449 Data: untagged responses: LISTRIGHTS 451 Result: OK - listrights completed 452 NO - listrights failure: can't get rights list 453 BAD - arguments invalid 455 The LISTRIGHTS command takes a mailbox name and an identifier and 456 returns information about what rights can be granted to the 457 identifier in the ACL for the mailbox. 459 Some implementations MAY permit multiple forms of an identifier to 460 reference the same IMAP account. Usually, such implementations will 461 have a canonical form that is stored internally. A LISTRIGHTS 462 response caused by a LISTRIGHTS command MUST always return the same 463 form of an identifier as specified by the client. This is to allow 464 the client to correlate the response with the command. 466 Example: C: a001 LISTRIGHTS ~/Mail/saved smith 467 S: * LISTRIGHTS ~/Mail/saved smith la r swicdkxte 468 S: a001 OK Listrights completed 470 Example: C: a005 listrights archive/imap anyone 471 S: * LISTRIGHTS archive.imap anyone "" 472 l r s w i p k x t e c d a 0 1 2 3 4 5 6 7 8 9 473 S: a005 Listrights successful 475 3.5 MYRIGHTS command 477 Arguments: mailbox name 479 Data: untagged responses: MYRIGHTS 481 Result: OK - myrights completed 482 NO - myrights failure: can't get rights 483 BAD - arguments invalid 485 The MYRIGHTS command returns the set of rights that the user has to 486 mailbox in an untagged MYRIGHTS reply. 488 Example: C: A003 MYRIGHTS INBOX 489 S: * MYRIGHTS INBOX rwiptsldaex 490 S: A003 OK Myrights complete 492 3.6 ACL response 494 Data: mailbox name 495 zero or more identifier rights pairs 497 The ACL response occurs as a result of a GETACL command. The first 498 string is the mailbox name for which this ACL applies. This is 499 followed by zero or more pairs of strings, each pair contains the 500 identifier for which the entry applies followed by the set of rights 501 that the identifier has. 503 Section 2.1.1 details additional server requirements related to 504 handling of the virtual "d" and "c" rights. 506 3.7 LISTRIGHTS response 508 Data: mailbox name 509 identifier 510 required rights 511 list of optional rights 513 The LISTRIGHTS response occurs as a result of a LISTRIGHTS command. 514 The first two strings are the mailbox name and identifier for which 515 this rights list applies. Following the identifier is a string 516 containing the (possibly empty) set of rights the identifier will 517 always be granted in the mailbox. 519 Following this are zero or more strings each containing a set of 520 rights the identifier can be granted in the mailbox. Rights 521 mentioned in the same string are tied together. The server MUST 522 either grant all tied rights to the identifier in the mailbox or 523 grant none. Section 2.1.1 details additional server requirements 524 related to handling of the virtual "d" and "c" rights. 526 The same right MUST NOT be listed more than once in the LISTRIGHTS 527 command. 529 3.8 MYRIGHTS response 531 Data: mailbox name 532 rights 534 The MYRIGHTS response occurs as a result of a MYRIGHTS command. The 535 first string is the mailbox name for which these rights apply. The 536 second string is the set of rights that the client has. 538 Section 2.1.1 details additional server requirements related to 539 handling of the virtual "d" and "c" rights. 541 4. Rights required to perform different IMAP4rev1 commands 543 Before executing a command an ACL compliant server MUST check which 544 rights are required to perform it. This section groups command by 545 functions they perform and list the rights required. It also gives 546 the detailed description of any special processing required. 548 For the purpose of this section the UID counterpart of a command is 549 considered to be the same command, e.g. both UID COPY and COPY 550 commands require the same set of rights. 552 The table below summarizes different rights or their combinations 553 that are required in order to perform different IMAP operations. As 554 it is not always possible to express complex right checking and 555 interactions, the description after the table should be used as the 556 primary reference. 558 +-------------------+---+---+---+---+---+---+---+---+---+---+---+---+ 559 |Operations\Rights | l | r | s | w | i | k | x | t | e | a |Any|Non| 560 +-------------------+---+---+---+---+---+---+---+---+---+---+---+---+ 561 | commands in authenticated state | 562 +-------------------------------------------------------------------+ 563 | LIST | + | | | | | | | | | | | | 564 | SUBSCRIBE | * | | | | | | | | | | | * | 565 | UNSUBSCRIBE | | | | | | | | | | | | + | 566 | LSUB | * | | | | | | | | | | | * | 567 |CREATE (for parent)| | | | | | + | | | | | | | 568 | DELETE | | | | | | | + | ? | ? | | | | 569 | RENAME | | | | | | + | + | | | | | | 570 |SELECT/EXAMINE/ | | + | | | | | | | | | | | 571 | STATUS | | + | | | | | | | | | | | 572 | SETACL/DELETEACL | | | | | | | | | | + | | | 573 | GETACL/LISTRIGHTS | | | | | | | | | | + | | | 574 | MYRIGHTS | | | | | | | | | | | + | | 575 | APPEND | | | ? | ? | + | | | ? | | | | | 576 +-------------------------------------------------------------------+ 577 | commands in selected state | 578 +-------------------------------------------------------------------+ 579 | COPY | | | ? | ? | + | | | ? | | | | | 580 | EXPUNGE/CLOSE | | | | | | | | | + | | | | 581 | FETCH | | | ? | | | | | | | | | | 582 | STORE flags | | | ? | ? | | | | ? | | | | | 583 +-------------------+---+---+---+---+---+---+---+---+---+---+---+---+ 585 Note: for all commands in the selected state the "r" is implied, 586 because it is required to SELECT/EXAMINE a mailbox. Servers are not 587 required to check presence of the "r" right once a mailbox is 588 successfully selected. 590 Legend: 591 + - The right is required 592 * - Only one of the rights marked with * is required 593 (see description below) 594 ? - The right is OPTIONAL (see description below) 595 "Any" - at least one of the "l", "r", "i", "k", "x", "a" rights is 596 required 597 "Non" - No rights required to perform the command 599 Listing and subscribing/unsubscribing mailboxes: 600 LIST - "l" right is required. However, unlike other commands 601 (e.g. SELECT) the server MUST NOT return a NO response if it 602 can't list a mailbox. 603 Note that if the user has "l" right to a mailbox "A/B", but not to 604 its parent mailbox "A", the LIST command should behave as if the 605 mailbox "A" doesn't exist, for example: 607 C: A777 LIST "" * 608 S: * LIST (\NoInferiors) "/" "A/B" 609 S: * LIST () "/" "C" 610 S: * LIST (\NoInferiors) "/" "C/D" 611 S: A777 OK LIST completed 613 SUBSCRIBE - "l" right is required only if the server checks for 614 mailbox existence when performing SUBSCRIBE. 616 UNSUBSCRIBE - no rights required to perform this operation. 618 LSUB - "l" right is required only if the server checks for mailbox 619 existence when performing SUBSCRIBE. However, unlike other 620 commands (e.g. SELECT) the server MUST NOT return a NO response 621 if it can't list a subscribed mailbox. 623 Mailbox management: 624 CREATE - "k" right on a nearest existing parent mailbox. When a 625 new mailbox is created it SHOULD inherit the ACL from the parent 626 mailbox (if one exists) in the defined hierarchy. 628 DELETE - "x" right on the mailbox. Note that some servers don't 629 allow to delete a non-empty mailbox. If this is the case, the 630 user would also need "r", "e" and "t" rights, in order to open the 631 mailbox and empty it. 633 The DELETE command MUST delete the ACL associated with the deleted 634 mailbox. 636 RENAME - Moving a mailbox from one parent to another requires the 637 "x" right on the mailbox itself and the "k" right for the new 638 parent. For example, if the user wants to rename mailbox named 639 "A/B/C" to "D/E", the user must have the "x" right for the mailbox 640 "A/B/C" and the "k" right for the mailbox "D". 641 The RENAME command SHOULD NOT change the ACLs on the renamed 642 mailbox and submailboxes. 644 Copying or appending messages: 645 Before performing a COPY/APPEND command the server MUST check if 646 the user has "i" right for the target mailbox. If the user 647 doesn't have "i" right, the operation fails. Otherwise for each 648 copied/appended message the server MUST check if the user has "t" 649 right - when the message has \Deleted flag set "s" right - when 650 the message has \Seen flag set "w" right for all other message 651 flags. Only when the user has a particular right the 652 corresponding flags are stored for the newly created message. The 653 server MUST NOT fail a COPY/APPEND if the user has no rights to 654 set a particular flag. 656 Example: C: A003 MYRIGHTS TargetMailbox 657 S: * MYRIGHTS TargetMailbox rwis 658 S: A003 OK Myrights complete 660 C: A004 FETCH 1:3 (FLAGS) 661 S: * 1 FETCH (FLAGS (\Draft \Deleted) 662 S: * 2 FETCH (FLAGS (\Answered) 663 S: * 3 FETCH (FLAGS ($Forwarded \Seen) 664 S: A004 OK Fetch Completed 666 C: A005 COPY 1:3 TargetMailbox 667 S: A005 OK Copy completed 669 C: A006 SELECT TargetMailbox 670 ... 671 S: A006 Select Completed 673 Let's assume that the copied messages received message numbers 674 77:79. 676 C: A007 FETCH 77:79 (FLAGS) 677 S: * 77 FETCH (FLAGS (\Draft)) 678 S: * 78 FETCH (FLAGS (\Answered)) 679 S: * 79 FETCH (FLAGS ($Forwarded \Seen)) 680 S: A007 OK Fetch Completed 682 \Deleted flag was lost on COPY, as the user has no "t" right in 683 the target mailbox. 684 If the MYRIGHTS command with the tag A003 would have returned: 686 S: * MYRIGHTS TargetMailbox rsti 688 the response from the FETCH with the tag A007 would have been: 690 C: A007 FETCH 77:79 (FLAGS) 691 S: * 77 FETCH (FLAGS (\Deleted)) 692 S: * 78 FETCH (FLAGS ()) 693 S: * 79 FETCH (FLAGS (\Seen)) 694 S: A007 OK Fetch Completed 696 In the latter case \Answered, $Forwarded and \Draft flags were 697 lost on COPY, as the user has no "w" right in the target mailbox. 699 Expunging the selected mailbox: 700 EXPUNGE - "e" right on the selected mailbox. 702 CLOSE - "e" right on the selected mailbox. If the server is 703 unable to expunge the mailbox because the user doesn't have the 704 "e" right, the server MUST ignore expunge request, close the 705 mailbox and return tagged OK response. 707 Fetch information about a mailbox and its messages: 708 SELECT/EXAMINE/STATUS - "r" right on the mailbox. 710 FETCH - A FETCH request that implies setting \Seen flag MUST NOT 711 set it, if the current user doesn't have "s" right. 713 Changing flags: 714 STORE - the server MUST check if the user has "t" right - when the 715 user modifies \Deleted flag "s" right - when the user modifies 716 \Seen flag "w" right for all other message flags. STORE operation 717 SHOULD NOT fail if the user has rights to modify at least one flag 718 specified in the STORE, as the tagged NO response to a STORE 719 command is not handled very well by deployed clients. 721 Changing ACLs: 722 SETACL/DELETEACL - "a" right on the mailbox. 724 Reading ACLs: 725 GETACL - "a" right on the mailbox. 727 MYRIGHTS - any of the following rights is required to perform the 728 operation: "l", "r", "i", "k", "x", "a". 730 LISTRIGHTS - "a" right on the mailbox. 732 5. Other considerations 734 5.1 Additional requirements and Implementation notes 736 5.1.1 Servers 738 This document defines an additional capability that is used to 739 announce the list of extra rights (excluding the ones defined in the 740 RFC 2086) supported by the server. The set of rights MUST include 741 "t", "e", "x" and "k". Note that the extra rights can appear in any 742 order. 744 Example: C: 1 capability 745 S: * CAPABILITY IMAP4REV1 STARTTLS LITERAL+ 746 ACL RIGHTS=texk 747 S: 1 OK completed 749 Any server implementing an ACL extension MUST accurately reflect the 750 current user's rights in FLAGS and PERMANENTFLAGS responses. 752 Example: C: A142 SELECT INBOX 753 S: * 172 EXISTS 754 S: * 1 RECENT 755 S: * OK [UNSEEN 12] Message 12 is first unseen 756 S: * OK [UIDVALIDITY 3857529045] UIDs valid 757 S: * OK [UIDNEXT 4392] Predicted next UID 758 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 759 S: * OK [PERMANENTFLAGS (\Seen \Answered \Flagged \*)] L 760 S: A142 OK [READ-WRITE] SELECT completed 761 C: A143 MYRIGHTS INBOX 762 S: * MYRIGHTS INBOX lrwis 763 S: A143 OK completed 765 Note that in order to get better performance the client MAY pipeline 766 SELECT and MYRIGHTS commands: 768 C: A142 SELECT INBOX 769 C: A143 MYRIGHTS INBOX 770 S: * 172 EXISTS 771 S: * 1 RECENT 772 S: * OK [UNSEEN 12] Message 12 is first unseen 773 S: * OK [UIDVALIDITY 3857529045] UIDs valid 774 S: * OK [UIDNEXT 4392] Predicted next UID 775 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 776 S: * OK [PERMANENTFLAGS (\Seen \Answered \Flagged \*)] L 777 S: A142 OK [READ-WRITE] SELECT completed 778 S: * MYRIGHTS INBOX lrwis 779 S: A143 OK completed 781 Servers MAY cache the rights a user has on a mailbox when the mailbox 782 is selected, so that if a client's rights on a mailbox are changed 783 with SETACL or DELETEACL, commands specific to the selected state 784 (e.g., STORE, EXPUNGE) might not reflect the changed rights until the 785 mailbox is re-selected. If the server checks the rights on each 786 command, then it SHOULD send FLAGS and PERMANENTFLAGS responses if 787 they have changed. If such server detects that the user no longer 788 has read access to the mailbox, it MAY send an untagged BYE response 789 and close connection. It MAY also refuse to execute all commands 790 specific to the selected state until the mailbox is closed, however 791 server implementors should note that most clients don't handle NO 792 responses very well. 794 An ACL server MAY modify one or more ACL for one or more identifier 795 as a side effect of modifying the ACL specified in a SETACL/ 796 DELETEACL. If the server does that it MUST send untagged ACL 797 response(s) to notify the client about the changes made. 799 An ACL server implementation MUST treat received ACL modification 800 commands as a possible ambiguity with respect to subsequent commands 801 affected by the ACL, as described in section 5.5 of [IMAP4]. Hence a 802 pipeline SETACL + MYRIGHTS is an ambiguity with respect to the 803 server, meaning that the server must execute the SETACL command to 804 completion before the MYRIGHTS. However, clients are permitted to 805 send such a pipeline. 807 5.1.2 Clients 809 The following requirement is put on clients in order to allow for 810 future extensibility. A client implementation that allows a user to 811 read and update ACLs MUST preserve unrecognized rights that it 812 doesn't allow the user to change. I.e., if the client 814 1) can read ACLs 815 and 816 2) can update ACLs 817 but 818 3) doesn't allow the user to change the rights the client doesn't 819 recognize, then it MUST preserve unrecognized rights. 821 Otherwise the client could risk unintentionally removing permissions 822 it doesn't understand. 824 5.2 Mapping of ACL rights to READ-WRITE and READ-ONLY response codes 826 A particular ACL server implementation MAY allow "shared multiuser 827 access" to some mailboxes. "Shared multiuser access" to a mailbox 828 means that multiple different users are able to access the same 829 mailbox, if they have proper access rights. "Shared multiuser 830 access" to the mailbox doesn't mean that the ACL for the mailbox is 831 currently set to allow access by multiple users. Let's denote a 832 "shared multiuser write access" as a "shared multiuser access" when a 833 user can be granted flag modification rights (any of "w", "s" or 834 "t"). 836 Section 4 describes which rights are required for modifying different 837 flags. 839 If the ACL server implements some flags as shared for a mailbox 840 (i.e., the ACL for the mailbox MAY be set up so that changes to those 841 flags are visible to another user), let's call the set of rights 842 associated with these flags (as described in Section 4) for that 843 mailbox collectively as "shared flag rights". Note that "shared flag 844 rights" set MAY be different for different mailboxes. 846 If the server doesn't support "shared multiuser write access" to a 847 mailbox or doesn't implement shared flags on the mailbox, "shared 848 flag rights" for the mailbox is defined to be the empty set. 850 Example 1: Mailbox "banan" allows "shared multiuser write access" and 851 implements flags \Deleted, \Answered and $MDNSent as 852 shared flags. "Shared flag rights" for the mailbox "banan" 853 is a set containing flags "t" (because system flag 854 \Deleted requires "t" right) and "w" (because both 855 \Answered and $MDNSent require "w" right). 857 Example 2: Mailbox "apple" allows "shared multiuser write access" and 858 implements \Seen system flag as shared flag. "Shared flag 859 rights" for the mailbox "apple" contains "s" right, 860 because system flag \Seen requires "s" right. 862 Example 3: Mailbox "pear" allows "shared multiuser write access" and 863 implements flags \Seen, \Draft as shared flags. "Shared 864 flag rights" for the mailbox "apple" is a set containing 865 flags "s" (because system flag \Seen requires "s" right) 866 and "w" (because system flag \Draft requires "w" right). 868 The server MUST include a READ-ONLY response code in the tagged OK 869 response to a SELECT command if none of the following rights is 870 granted to the current user: 872 "i", "e" and "shared flag rights"*. 874 The server SHOULD include a READ-WRITE response code in the tagged OK 875 response if at least one of the "i", "e" or "shared flag rights"* is 876 granted to the current user. 878 * - Note that a future extension to this document can extend the list 879 of rights that causes the server to return the READ-WRITE response 880 code. 882 Example 1 (continued): The user that has "lrs" rights for the mailbox 883 "banan". The server returns READ-ONLY response 884 code on SELECT, as none of "iewt" rights is 885 granted to the user. 887 Example 2 (continued): The user that has "rit" rights for the mailbox 888 "apple". The server returns READ-WRITE 889 response code on SELECT, as the user has "i" 890 right. 892 Example 3 (continued): The user that has "rset" rights for the 893 mailbox "pear". The server returns READ-WRITE 894 response code on SELECT, as the user has "e" 895 and "s" rights. 897 6. Security Considerations 899 An implementation MUST make sure the ACL commands themselves do not 900 give information about mailboxes with appropriately restricted ACL's. 901 For example, when a user agent executes a GETACL command on a mailbox 902 that the user has no permission to LIST, the server would respond to 903 that request with the same error that would be used if the mailbox 904 did not exist, thus revealing no existence information, much less the 905 mailbox's ACL. 907 IMAP clients implementing ACL that are able to modify ACLs SHOULD 908 warn a user that wants to give full access (or even just the "a" 909 right) to the special identifier "anyone". 911 7. Formal Syntax 913 Formal syntax is defined using ABNF [ABNF], extending the ABNF rules 914 in section 9 of [IMAP4]. Elements not defined here can be found in 915 the [ABNF] and [IMAP4]. 917 Except as noted otherwise, all alphabetic characters are case- 918 insensitive. The use of upper or lower case characters to define 919 token strings is for editorial clarity only. Implementations MUST 920 accept these strings in a case-insensitive fashion. 922 LOWER-ALPHA = %x61-7A ;; a-z 924 acl-data = "ACL" SP mailbox *(SP identifier SP 925 rights) 927 capability =/ rights-capa 928 ;;capability is defined in [IMAP4] 930 command-auth =/ setacl / deleteacl / getacl / 931 listrights / myrights 932 ;;command-auth is defined in [IMAP4] 934 deleteacl = "DELETEACL" SP mailbox SP identifier 936 getacl = "GETACL" SP mailbox 938 identifier = astring 940 listrights = "LISTRIGHTS" SP mailbox SP identifier 942 listrights-data = "LISTRIGHTS" SP mailbox SP identifier 943 SP rights *(SP rights) 945 mailbox-data =/ acl-data / listrights-data / myrights-data 946 ;;mailbox-data is defined in [IMAP4] 948 mod-rights = astring 949 ;; +rights to add, -rights to remove 950 ;; rights to replace 952 myrights = "MYRIGHTS" SP mailbox 954 myrights-data = "MYRIGHTS" SP mailbox SP rights 956 new-rights = 1*LOWER-ALPHA 957 ;; MUST include "t", "e", "x" and "k". 958 ;; MUST NOT include standard rights listed 959 ;; in section 2.2 961 rights = astring 962 ;; only lowercase ASCII letters and digits 963 ;; are allowed. 965 rights-capa = "RIGHTS=" new-rights 966 ;; RIGHTS=... capability 968 setacl = "SETACL" SP mailbox SP identifier 969 SP mod-rights 971 8. IANA Considerations 973 IMAP4 capabilities are registered by publishing a standards track or 974 IESG approved experimental RFC. The registry is currently located 975 at: 977 http://www.iana.org/assignments/imap4-capabilities 979 This document defines the RIGHTS= IMAP capability. IANA is requested 980 to add this capability to the registry. 982 9. Internationalization Considerations 984 Section 3 states requirements on servers regarding 985 internationalization of identifiers. 987 Appendix A. Changes since RFC 2086 989 1. Changed the charset of "identifier" from US-ASCII to UTF-8. 990 2. Specified that mailbox deletion is controled by the "x" right 991 and EXPUNGE is controlled by the "e" right. 992 3. Added the "t" right that controls STORE \Deleted. Redefined the 993 "d" right to be a macro for "e", "t" and possibly "x". 994 4. Added the "k" right that controls CREATE. Redefined the "c" 995 right to be a macro for "k" and possibly "x". 996 5. Specified that the "a" right also controls DELETEACL. 997 6. Specified that the "r" right also controls STATUS. 998 7. Removed the requirement to check the "r" right for CHECK, SEARCH 999 and FETCH, as this is required for SELECT/EXAMINE to be 1000 successful. 1001 8. LISTRIGHTS requires the "a" right on the mailbox (same as 1002 SETACL). 1003 9. Deleted "PARTIAL", this is a deprecated feature of RFC 1730. 1004 10. Specified that the "w" right controls setting flags other than 1005 \Seen and \Deleted on APPEND. Also specified that the "s" right 1006 controls the \Seen flag and that the "t" right controls the 1007 \Deleted flag. 1008 11. Specified that SUBSCRIBE is NOT allowed with the "r" right. 1009 12. Specified that the "l" right controls SUBSCRIBE. 1010 13. GETACL is NOT allowed with the "r" right, even though there are 1011 several implementations that allows that. If a user only has 1012 "r" right, GETACL can disclose information about identifiers 1013 existing on the mail system. 1014 14. Clarified that RENAME requires the "k" right for the new parent 1015 and the "x" right for the old name. 1016 15. Added new section that describes which rights are required 1017 and/or checked when performing various IMAP commands. 1019 16. Added mail client security considerations when dealing with 1020 special identifier "anyone". 1021 17. Clarified that negative rights are not the same as DELETEACL. 1022 18. Added "Compatibility with RFC 2086" section. 1023 19. Added section about mapping of ACL rights to READ-WRITE and 1024 READ-ONLY response codes. 1025 20. Changed BNF to ABNF. 1026 21. Added "Implementation Notes" section. 1027 22. Updated "References" section. 1028 23. Added more examples. 1029 24. Clarified when the virtual "c" and "d" rights are returned in 1030 ACL, MYRIGHTS and LISTRIGHTS responses. 1032 Appendix B. Compatibility with RFC 2086 1034 This non-normative section gives guidelines how an existing RFC 2086 1035 server implementation may be updated to comply with this document. 1037 This document splits the "d" right into several new different rights: 1038 "t", "e" and possibly "x" (see Section 2.1.1 for more details). The 1039 "d" right remains for backwards-compatibility but it is a virtual 1040 right. There are two approaches for RFC2086 server implementors to 1041 handle the "d" right and the new rights that have replaced it: 1043 a. "t", "e" (and possibly "x) together - almost no changes. 1044 b. Implement separate "x", "t" and "e". Return the "d" right in a 1045 MYRIGHTS response or an ACL response containing ACL information 1046 when any of the "t", "e" (and "x") is granted. 1048 In a similar manner this document splits the "c" right into several 1049 new different rights: "k" and possibly "x" (see Section 2.1.1 for 1050 more details). The "c" right remains for backwards-compatibility but 1051 it is a virtual right. Again, RFC2086 server implementors can choose 1052 to tie rights or to implement separate rights, as described above. 1054 Also check Sections Section 5.1.1 and Section 5.1.2, as well as the 1055 Appendix A to see other changes required. Server implementors should 1056 check which rights are required to invoke different IMAP4 commands as 1057 described in Section 4. 1059 Appendix C. Known deficiencies 1061 This specification has some known deficiencies including: 1063 1. This is inadequate to provide complete read-write access to 1064 mailboxes protected by Unix-style rights bits because there is no 1065 equivalent to "chown" and "chgrp" commands nor is there a good 1066 way to discover such limitations are present. 1068 2. Because this extension leaves the specific semantics of how 1069 rights are combined by the server as implementation defined, the 1070 ability to build a user-friendly interface is limited. 1071 3. Users, groups, and special identifiers (e.g. anyone) exist in the 1072 same namespace. 1074 The work-in-progress "ACL2" extension is intended to redesign this 1075 extension to address these deficiencies without the constraint of 1076 backwards-compatibility and may eventually supercede this facility. 1077 However, RFC 2086 is deployed in multiple implementations so this 1078 intermediate step which fixes the straightforward deficiencies in a 1079 backwards compatible fashion is considered worthwhile. 1081 Appendix D. Acknowledgments 1083 This document is a revision of the RFC 2086 written by John G. Myers. 1085 Editor appreciates comments received from Mark Crispin, Chris Newman, 1086 Cyrus Daboo, John G. Myers, Dave Cridland, Ken Murchison, Steve Hole, 1087 Vladimir Butenko, Larry Greenfield, Robert Siemborski, Harrie 1088 Hazewinkel, Philip Guenther, Brian Candler, Curtis King, Lyndon 1089 Nerenberg, Lisa Dusseault, Arnt Gulbrandsen and other participants of 1090 the IMAPEXT working group. 1092 10. References 1094 10.1 Normative References 1096 [KEYWORDS] 1097 Bradner, S., "Key words for use in RFCs to Indicate 1098 Requirement Levels", BCP 14, RFC 2119, March 1997. 1100 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1101 Specifications: ABNF", RFC 2234, November 1997. 1103 [IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1104 4rev1", RFC 3501, March 2003. 1106 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 1107 10646", STD 63, RFC 3629, November 2003. 1109 [Stringprep] 1110 Hoffman, P. and M. Blanchet, "Preparation of 1111 Internationalized Strings ("stringprep")", RFC 3454, 1112 December 2002. 1114 [SASLprep] 1115 Zeilenga, K., "SASLprep: Stringprep Profile for User Names 1116 and Passwords", RFC 4013, February 2005. 1118 10.2 Informative References 1120 [RFC2086] Myers, J., "IMAP4 ACL extension", RFC 2086, January 1997. 1122 Author's Address 1124 Alexey Melnikov 1125 Isode Ltd. 1126 5 Castle Business Village 1127 36 Station Road 1128 Hampton, Middlesex TW12 2BX 1129 GB 1131 Email: alexey.melnikov@isode.com 1133 Intellectual Property Statement 1135 The IETF takes no position regarding the validity or scope of any 1136 Intellectual Property Rights or other rights that might be claimed to 1137 pertain to the implementation or use of the technology described in 1138 this document or the extent to which any license under such rights 1139 might or might not be available; nor does it represent that it has 1140 made any independent effort to identify any such rights. Information 1141 on the procedures with respect to rights in RFC documents can be 1142 found in BCP 78 and BCP 79. 1144 Copies of IPR disclosures made to the IETF Secretariat and any 1145 assurances of licenses to be made available, or the result of an 1146 attempt made to obtain a general license or permission for the use of 1147 such proprietary rights by implementers or users of this 1148 specification can be obtained from the IETF on-line IPR repository at 1149 http://www.ietf.org/ipr. 1151 The IETF invites any interested party to bring to its attention any 1152 copyrights, patents or patent applications, or other proprietary 1153 rights that may cover technology that may be required to implement 1154 this standard. Please address the information to the IETF at 1155 ietf-ipr@ietf.org. 1157 The IETF has been notified of intellectual property rights claimed in 1158 regard to some or all of the specification contained in this 1159 document. For more information consult the online list of claimed 1160 rights. 1162 Disclaimer of Validity 1164 This document and the information contained herein are provided on an 1165 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1166 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1167 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1168 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1169 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1170 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1172 Copyright Statement 1174 Copyright (C) The Internet Society (2005). This document is subject 1175 to the rights, licenses and restrictions contained in BCP 78, and 1176 except as set forth therein, the authors retain all their rights. 1178 Acknowledgment 1180 Funding for the RFC Editor function is currently provided by the 1181 Internet Society.