idnits 2.17.1 draft-ietf-imapext-2086upd-08.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 1200. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1172. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1179. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1185. ** 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 27, 2005) is 6871 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 776, but not defined == Missing Reference: 'UIDVALIDITY 3857529045' is mentioned on line 777, but not defined == Missing Reference: 'UIDNEXT 4392' is mentioned on line 778, 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 27, 2005 5 Expires: December 29, 2005 7 IMAP4 ACL extension 8 draft-ietf-imapext-2086upd-08 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 29, 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 . . . . . . . . . . . . . . . . . . . . . . . . 22 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 89 9. Internationalization Considerations . . . . . . . . . . . . . 24 90 A. Changes since RFC 2086 . . . . . . . . . . . . . . . . . . . . 24 91 B. Compatibility with RFC 2086 . . . . . . . . . . . . . . . . . 25 92 C. Known deficiencies . . . . . . . . . . . . . . . . . . . . . . 25 93 D. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 94 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 95 10.1 Normative References . . . . . . . . . . . . . . . . . . . 26 96 10.2 Informative References . . . . . . . . . . . . . . . . . . 27 97 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 27 98 Intellectual Property and Copyright Statements . . . . . . . . 28 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 access identifiers, which rights are required for 109 different IMAP4 commands; how READ-WRITE/READ-ONLY response codes are 110 related to ACL. 112 2. Access Control 114 The ACL extension is present in any IMAP4 implementation which 115 returns "ACL" as one of the supported capabilities to the CAPABILITY 116 command. 118 A server implementation conformant to this document MUST also return 119 rights (see below) not defined in Section 2.2 in the "RIGHTS=" 120 capability. 122 An access control list is a set of pairs. 123 An ACL applies to a mailbox name. 125 Access identifier (or just "identifier") is a UTF-8 [UTF-8] string. 126 The identifier "anyone" is reserved to refer to the universal 127 identity (all authentications, including anonymous). All user name 128 strings accepted by the LOGIN or AUTHENTICATE commands to 129 authenticate to the IMAP server are reserved as identifiers for the 130 corresponding users. Identifiers starting with a dash ("-") are 131 reserved for "negative rights", described below. All other 132 identifier strings are interpreted in an implementation-defined 133 manner. 135 Rights is a string listing a (possibly empty) set of alphanumeric 136 characters, each character listing a set of operations which is being 137 controlled. Lowercase letters are reserved for "standard" rights, 138 listed in Section 2.1. (Note that for compatibility with deployed 139 clients and servers uppercase rights are not allowed). The set of 140 standard rights can only be extended by a standards-track document. 141 Digits are reserved for implementation or site defined rights. 143 An implementation MAY tie rights together or MAY force rights to 144 always or never be granted to particular identifiers. For example, 145 in an implementation that uses UNIX mode bits, the rights "swite" are 146 tied, the "a" right is always granted to the owner of a mailbox and 147 is never granted to another user. If rights are tied in an 148 implementation, the implementation must be conservative in granting 149 rights in response to SETACL commands--unless all rights in a tied 150 set are specified, none of that set should be included in the ACL 151 entry for that identifier. A client can discover the set of rights 152 which may be granted to a given identifier in the ACL for a given 153 mailbox name by using the LISTRIGHTS command. 155 It is possible for multiple identifiers in an access control list to 156 apply to a given user. For example, an ACL may include rights to be 157 granted to the identifier matching the user, one or more 158 implementation-defined identifiers matching groups which include the 159 user, and/or the identifier "anyone". How these rights are combined 160 to determine the user's access is implementation-defined. An 161 implementation may choose, for example, to use the union of the 162 rights granted to the applicable identifiers. An implementation may 163 instead choose, for example, to only use those rights granted to the 164 most specific identifier present in the ACL. A client can determine 165 the set of rights granted to the logged-in user for a given mailbox 166 name by using the MYRIGHTS command. 168 When an identifier in an ACL starts with a dash ("-"), that indicates 169 that associated rights are to be removed from the identifier that is 170 prefixed by the dash. This is referred to as a "negative right". 171 This differs from DELETEACL in that a negative right is added to the 172 ACL, and is a part of the calculation of the rights. 174 Let's assume that an identifier "fred" refers to a user with login 175 "fred". If the identifier "-fred" is granted the "w" right, that 176 indicates that the "w" right is to be removed from users matching the 177 identifier "fred", even though the user "fred" might have the "w" 178 right as a consequence of some other identifier in the ACL. A 179 DELETEACL of "fred" simply deletes the identifier "fred" from the 180 ACL; it does not affect any rights that the user "fred" may get from 181 another entry in the ACL, in particular it doesn't affect rights 182 granted to the identifier "-fred". 184 Server implementations are not required to support "negative right" 185 identifiers. 187 2.1 Standard rights 189 The currently defined standard rights are (note that the list below 190 doesn't list all commands that use a particular right): 192 l - lookup (mailbox is visible to LIST/LSUB commands, SUBSCRIBE 193 mailbox) 194 r - read (SELECT the mailbox, perform STATUS) 195 s - keep seen/unseen information across sessions (set or clear 196 \SEEN flag via STORE, also set \SEEN during APPEND/COPY/ 197 FETCH BODY[...]) 198 w - write (set or clear flags other than \SEEN and \DELETED via 199 STORE, also set them during APPEND/COPY) 200 i - insert (perform APPEND, COPY into mailbox) 201 p - post (send mail to submission address for mailbox, 202 not enforced by IMAP4 itself) 203 k - create mailboxes (CREATE new sub-mailboxes in any 204 implementation-defined hierarchy, parent mailbox for the new 205 mailbox name in RENAME) 206 x - delete mailbox (DELETE mailbox, old mailbox name in RENAME) 207 t - delete messages (set or clear \DELETED flag via STORE, set 208 \DELETED flag during APPEND/COPY) 209 e - perform EXPUNGE and expunge as a part of CLOSE. 210 a - administer (perform SETACL/DELETEACL/GETACL) 212 2.1.1 Obsolete rights 214 Due to ambiguity in RFC 2086 some existing RFC 2086 server 215 implementations use the "c" right to control the DELETE command. 216 Others chose to use the "d" right to control the DELETE command. For 217 the former group, let's define the "create" right as union of the "k" 218 and "x" rights, and the "delete" right as union of the "e" and "t" 219 rights. For the latter group, let's define the "create" rights as a 220 synonym to the "k" right, and the "delete" right as union of the "e", 221 "t" and "x" rights. 223 For compatibility with RFC 2086 this section defines two virtual 224 rights "d" and "c". 226 If a client includes the "d" right in a rights list, then it MUST be 227 treated as if the client had included every member of the "delete" 228 right. (It is not an error for a client to specify both the "d" 229 right and one or more members of the "delete" right, but the effect 230 is no different than if just the "d" right or all members of the 231 "delete" right had been specified). 233 When any of the "delete" member rights is set in a list of rights, 234 the server MUST also include the "d" right when returning the list in 235 a MYRIGHTS or ACL response. This is so to enable older clients 236 conforming to RFC 2086 to work with newer servers. (*) 238 Example: C: A001 SeTacl INBOX/Drafts David lrswida 239 S: A001 OK Setacl complete 241 The client has specified the "d" right in the SETACL command above 242 and it expands to "et" on the server: 244 C: A002 getacl INBOX/Drafts 245 S: * ACL INBOX Fred rwipslxetda David lrswideta 246 S: A002 OK Getacl complete 248 If the identifier specified in the LISTRIGHTS command can be granted 249 any of the "delete" member rights on a mailbox, then the server MUST 250 include the "d" right in the corresponding LISTRIGHTS response. (*) 251 If the member rights aren't tied to non-member rights, then the "d" 252 right is returned by itself in the LISTRIGHTS response. If any of 253 the member rights needs to be tied to one (or more) non-member right, 254 then the "d" right and all of the member rights need to be tied to 255 the same non-member right(s) (**). 257 If a client includes the "c" right in a rights list, then it MUST be 258 treated as if the client had included every member of the "create" 259 right. (It is not an error for a client to specify both the "c" 260 right and one or more members of the "create" right, but the effect 261 is no different than if just the "c" right or all members of the 262 "create" right had been specified). 264 When any of the "create" member rights is set in a list of rights, 265 the server MUST also include the "c" right when returning the list in 266 a MYRIGHTS or ACL response. This is so to enable older clients 267 conforming to RFC 2086 to work with newer servers. (*) 269 Example: C: A003 Setacl INBOX/Drafts Byron lrswikda 270 S: A001 OK Setacl complete 271 C: A002 getAcl INBOX/Drafts 272 S: * ACL INBOX Fred rwipslxeta Byron lrswikcdeta 273 S: A002 OK Getacl complete 275 The client has specified the "d" right in the SETACL command above 276 and it expands to "et" on the server: As the client has specified 277 the "k" right (which is a member of the "c" right), the server also 278 returns the "c" right. 280 If the identifier specified in the LISTRIGHTS command can be granted 281 any of the "create" member rights on a mailbox, then the server MUST 282 include the "c" right in the corresponding LISTRIGHTS response. (*) 283 If the member rights aren't tied to non-member rights, then the "c" 284 right is returned by itself in the LISTRIGHTS response. If any of 285 the member rights needs to be tied to one (or more) non-member right, 286 then the "c" right and all of the member rights need to be tied to 287 the same non-member right(s) (**). 289 Example: The server that ties the rights as follows 291 lr s w i p k x t 293 and c=k 295 will return: 297 S: * LISTRIGHTS archive/imap anyone "" 298 lr s w i p k x t c d 300 Example: The server that ties the rights as follows 302 lr s w i p k xte 304 and c=k 306 will return: 308 S: * LISTRIGHTS archive/imap anyone "" 309 lr s w i p k xte c d 311 Example: The server that ties the rights as follows 313 lr s w i p k x te 315 and c=k 317 will return: 319 S: * LISTRIGHTS archive/imap anyone "" 320 lr s w i p k c x te d 322 Example: The server that ties the rights as follows 324 lr swte i p k x 326 and c=kx 328 will return: 330 S: * LISTRIGHTS archive/imap anyone "" 331 lr swted i p k x c 333 (*) Clients conforming to this document MUST ignore the virtual "d" 334 and "c" rights in MYRIGHTS, ACL and LISTRIGHTS responses. 336 (**) The IMAPEXT Working Group has debated this issue in great length 337 and after reviewing existing ACL implementations concluded that this 338 is a reasonable restriction. 340 2.2 Rights defined in RFC 2086 342 The "RIGHTS=" capability MUST NOT include any of the rights defined 343 in RFC 2086: "l", "r", "s", "w", "i", "p", "a", "c", "d", and the 344 digits ("0" .. "9"). 346 3. Access control management commands and responses 348 Servers, when processing a command that has an identifier as a 349 parameter (i.e. any of SETACL, DELETEACL and LISTRIGHTS commands), 350 SHOULD first prepare the received identifier using "SASLprep" profile 351 [SASLprep] of the "stringprep" algorithm [Stringprep]. If the 352 preparation of the identifier fails or results in an empty string, 353 the server MUST refuse to perform the command with a BAD response. 354 Note that Section 6 recommends additional identifier's verification 355 steps. 357 3.1 SETACL command 359 Arguments: mailbox name 360 identifier 361 access right modification 363 Data: no specific data for this command 365 Result: OK - setacl completed 366 NO - setacl failure: can't set acl 367 BAD - arguments invalid 369 The SETACL command changes the access control list on the specified 370 mailbox so that the specified identifier is granted permissions as 371 specified in the third argument. 373 The third argument is a string containing an optional plus ("+") or 374 minus ("-") prefix, followed by zero or more rights characters. If 375 the string starts with a plus, the following rights are added to any 376 existing rights for the identifier. If the string starts with a 377 minus, the following rights are removed from any existing rights for 378 the identifier. If the string does not start with a plus or minus, 379 the rights replace any existing rights for the identifier. 381 Note that an unrecognized right MUST cause the command to return the 382 BAD response. In particular, server MUST NOT silently ignore 383 unrecognized rights. 385 Example: C: A001 GETACL INBOX/Drafts 386 S: * ACL INBOX/Drafts Fred rwipslxetad Chris lrswi 387 S: A001 OK Getacl complete 388 C: A002 SETACL INBOX/Drafts Chris +cda 389 S: A002 OK Setacl complete 390 C: A003 GETACL INBOX/Drafts 391 S: * ACL INBOX/Drafts Fred rwipslxetad Chris lrswicdakxet 392 S: A003 OK Getacl complete 394 C: A035 SETACL INBOX/Drafts John lrQswicda 395 S: A035 BAD Uppercase rights are not allowed 397 C: A036 SETACL INBOX/Drafts John lrqswicda 398 S: A036 BAD The q right is not supported 400 3.2 DELETEACL command 402 Arguments: mailbox name 403 identifier 405 Data: no specific data for this command 407 Result: OK - deleteacl completed 408 NO - deleteacl failure: can't delete acl 409 BAD - arguments invalid 411 The DELETEACL command removes any pair for the 412 specified identifier from the access control list for the specified 413 mailbox. 415 Example: C: B001 getacl INBOX 416 S: * ACL INBOX Fred rwipslxetad -Fred wetd $team w 417 S: B001 OK Getacl complete 418 C: B002 DeleteAcl INBOX Fred 419 S: B002 OK Deleteacl complete 420 C: B003 GETACL INBOX 421 S: * ACL INBOX -Fred wetd $team w 422 S: B003 OK Getacl complete 424 3.3 GETACL command 426 Arguments: mailbox name 428 Data: untagged responses: ACL 430 Result: OK - getacl completed 431 NO - getacl failure: can't get acl 432 BAD - arguments invalid 434 The GETACL command returns the access control list for mailbox in an 435 untagged ACL response. 437 Some implementations MAY permit multiple forms of an identifier to 438 reference the same IMAP account. Usually, such implementations will 439 have a canonical form that is stored internally. An ACL response 440 caused by an GETACL command MAY include a canonicalized form of the 441 identifier which might be different from the one used in the 442 corresponding SETACL command. 444 Example: C: A002 GETACL INBOX 445 S: * ACL INBOX Fred rwipsldexta 446 S: A002 OK Getacl complete 448 3.4 LISTRIGHTS command 450 Arguments: mailbox name 451 identifier 453 Data: untagged responses: LISTRIGHTS 455 Result: OK - listrights completed 456 NO - listrights failure: can't get rights list 457 BAD - arguments invalid 459 The LISTRIGHTS command takes a mailbox name and an identifier and 460 returns information about what rights can be granted to the 461 identifier in the ACL for the mailbox. 463 Some implementations MAY permit multiple forms of an identifier to 464 reference the same IMAP account. Usually, such implementations will 465 have a canonical form that is stored internally. A LISTRIGHTS 466 response caused by a LISTRIGHTS command MUST always return the same 467 form of an identifier as specified by the client. This is to allow 468 the client to correlate the response with the command. 470 Example: C: a001 LISTRIGHTS ~/Mail/saved smith 471 S: * LISTRIGHTS ~/Mail/saved smith la r swicdkxte 472 S: a001 OK Listrights completed 474 Example: C: a005 listrights archive/imap anyone 475 S: * LISTRIGHTS archive.imap anyone "" 476 l r s w i p k x t e c d a 0 1 2 3 4 5 6 7 8 9 477 S: a005 Listrights successful 479 3.5 MYRIGHTS command 481 Arguments: mailbox name 483 Data: untagged responses: MYRIGHTS 485 Result: OK - myrights completed 486 NO - myrights failure: can't get rights 487 BAD - arguments invalid 489 The MYRIGHTS command returns the set of rights that the user has to 490 mailbox in an untagged MYRIGHTS reply. 492 Example: C: A003 MYRIGHTS INBOX 493 S: * MYRIGHTS INBOX rwiptsldaex 494 S: A003 OK Myrights complete 496 3.6 ACL response 498 Data: mailbox name 499 zero or more identifier rights pairs 501 The ACL response occurs as a result of a GETACL command. The first 502 string is the mailbox name for which this ACL applies. This is 503 followed by zero or more pairs of strings, each pair contains the 504 identifier for which the entry applies followed by the set of rights 505 that the identifier has. 507 Section 2.1.1 details additional server requirements related to 508 handling of the virtual "d" and "c" rights. 510 3.7 LISTRIGHTS response 512 Data: mailbox name 513 identifier 514 required rights 515 list of optional rights 517 The LISTRIGHTS response occurs as a result of a LISTRIGHTS command. 518 The first two strings are the mailbox name and identifier for which 519 this rights list applies. Following the identifier is a string 520 containing the (possibly empty) set of rights the identifier will 521 always be granted in the mailbox. 523 Following this are zero or more strings each containing a set of 524 rights the identifier can be granted in the mailbox. Rights 525 mentioned in the same string are tied together. The server MUST 526 either grant all tied rights to the identifier in the mailbox or 527 grant none. Section 2.1.1 details additional server requirements 528 related to handling of the virtual "d" and "c" rights. 530 The same right MUST NOT be listed more than once in the LISTRIGHTS 531 command. 533 3.8 MYRIGHTS response 535 Data: mailbox name 536 rights 538 The MYRIGHTS response occurs as a result of a MYRIGHTS command. The 539 first string is the mailbox name for which these rights apply. The 540 second string is the set of rights that the client has. 542 Section 2.1.1 details additional server requirements related to 543 handling of the virtual "d" and "c" rights. 545 4. Rights required to perform different IMAP4rev1 commands 547 Before executing a command an ACL compliant server MUST check which 548 rights are required to perform it. This section groups command by 549 functions they perform and list the rights required. It also gives 550 the detailed description of any special processing required. 552 For the purpose of this section the UID counterpart of a command is 553 considered to be the same command, e.g. both UID COPY and COPY 554 commands require the same set of rights. 556 The table below summarizes different rights or their combinations 557 that are required in order to perform different IMAP operations. As 558 it is not always possible to express complex right checking and 559 interactions, the description after the table should be used as the 560 primary reference. 562 +-------------------+---+---+---+---+---+---+---+---+---+---+---+---+ 563 |Operations\Rights | l | r | s | w | i | k | x | t | e | a |Any|Non| 564 +-------------------+---+---+---+---+---+---+---+---+---+---+---+---+ 565 | commands in authenticated state | 566 +-------------------------------------------------------------------+ 567 | LIST | + | | | | | | | | | | | | 568 | SUBSCRIBE | * | | | | | | | | | | | * | 569 | UNSUBSCRIBE | | | | | | | | | | | | + | 570 | LSUB | * | | | | | | | | | | | * | 571 |CREATE (for parent)| | | | | | + | | | | | | | 572 | DELETE | | | | | | | + | ? | ? | | | | 573 | RENAME | | | | | | + | + | | | | | | 574 |SELECT/EXAMINE/ | | + | | | | | | | | | | | 575 | STATUS | | + | | | | | | | | | | | 576 | SETACL/DELETEACL | | | | | | | | | | + | | | 577 | GETACL/LISTRIGHTS | | | | | | | | | | + | | | 578 | MYRIGHTS | | | | | | | | | | | + | | 579 | APPEND | | | ? | ? | + | | | ? | | | | | 580 +-------------------------------------------------------------------+ 581 | commands in selected state | 582 +-------------------------------------------------------------------+ 583 | COPY | | | ? | ? | + | | | ? | | | | | 584 | EXPUNGE/CLOSE | | | | | | | | | + | | | | 585 | FETCH | | | ? | | | | | | | | | | 586 | STORE flags | | | ? | ? | | | | ? | | | | | 587 +-------------------+---+---+---+---+---+---+---+---+---+---+---+---+ 589 Note: for all commands in the selected state the "r" is implied, 590 because it is required to SELECT/EXAMINE a mailbox. Servers are not 591 required to check presence of the "r" right once a mailbox is 592 successfully selected. 594 Legend: 595 + - The right is required 596 * - Only one of the rights marked with * is required 597 (see description below) 598 ? - The right is OPTIONAL (see description below) 599 "Any" - at least one of the "l", "r", "i", "k", "x", "a" rights is 600 required 601 "Non" - No rights required to perform the command 603 Listing and subscribing/unsubscribing mailboxes: 604 LIST - "l" right is required. However, unlike other commands 605 (e.g. SELECT) the server MUST NOT return a NO response if it 606 can't list a mailbox. 607 Note that if the user has "l" right to a mailbox "A/B", but not to 608 its parent mailbox "A", the LIST command should behave as if the 609 mailbox "A" doesn't exist, for example: 611 C: A777 LIST "" * 612 S: * LIST (\NoInferiors) "/" "A/B" 613 S: * LIST () "/" "C" 614 S: * LIST (\NoInferiors) "/" "C/D" 615 S: A777 OK LIST completed 617 SUBSCRIBE - "l" right is required only if the server checks for 618 mailbox existence when performing SUBSCRIBE. 620 UNSUBSCRIBE - no rights required to perform this operation. 622 LSUB - "l" right is required only if the server checks for mailbox 623 existence when performing SUBSCRIBE. However, unlike other 624 commands (e.g. SELECT) the server MUST NOT return a NO response 625 if it can't list a subscribed mailbox. 627 Mailbox management: 628 CREATE - "k" right on a nearest existing parent mailbox. When a 629 new mailbox is created it SHOULD inherit the ACL from the parent 630 mailbox (if one exists) in the defined hierarchy. 632 DELETE - "x" right on the mailbox. Note that some servers don't 633 allow to delete a non-empty mailbox. If this is the case, the 634 user would also need "r", "e" and "t" rights, in order to open the 635 mailbox and empty it. 637 The DELETE command MUST delete the ACL associated with the deleted 638 mailbox. 640 RENAME - Moving a mailbox from one parent to another requires the 641 "x" right on the mailbox itself and the "k" right for the new 642 parent. For example, if the user wants to rename mailbox named 643 "A/B/C" to "D/E", the user must have the "x" right for the mailbox 644 "A/B/C" and the "k" right for the mailbox "D". 645 The RENAME command SHOULD NOT change the ACLs on the renamed 646 mailbox and submailboxes. 648 Copying or appending messages: 649 Before performing a COPY/APPEND command the server MUST check if 650 the user has "i" right for the target mailbox. If the user 651 doesn't have "i" right, the operation fails. Otherwise for each 652 copied/appended message the server MUST check if the user has "t" 653 right - when the message has \Deleted flag set "s" right - when 654 the message has \Seen flag set "w" right for all other message 655 flags. Only when the user has a particular right the 656 corresponding flags are stored for the newly created message. The 657 server MUST NOT fail a COPY/APPEND if the user has no rights to 658 set a particular flag. 660 Example: C: A003 MYRIGHTS TargetMailbox 661 S: * MYRIGHTS TargetMailbox rwis 662 S: A003 OK Myrights complete 664 C: A004 FETCH 1:3 (FLAGS) 665 S: * 1 FETCH (FLAGS (\Draft \Deleted) 666 S: * 2 FETCH (FLAGS (\Answered) 667 S: * 3 FETCH (FLAGS ($Forwarded \Seen) 668 S: A004 OK Fetch Completed 670 C: A005 COPY 1:3 TargetMailbox 671 S: A005 OK Copy completed 673 C: A006 SELECT TargetMailbox 674 ... 675 S: A006 Select Completed 677 Let's assume that the copied messages received message numbers 678 77:79. 680 C: A007 FETCH 77:79 (FLAGS) 681 S: * 77 FETCH (FLAGS (\Draft)) 682 S: * 78 FETCH (FLAGS (\Answered)) 683 S: * 79 FETCH (FLAGS ($Forwarded \Seen)) 684 S: A007 OK Fetch Completed 686 \Deleted flag was lost on COPY, as the user has no "t" right in 687 the target mailbox. 688 If the MYRIGHTS command with the tag A003 would have returned: 690 S: * MYRIGHTS TargetMailbox rsti 692 the response from the FETCH with the tag A007 would have been: 694 C: A007 FETCH 77:79 (FLAGS) 695 S: * 77 FETCH (FLAGS (\Deleted)) 696 S: * 78 FETCH (FLAGS ()) 697 S: * 79 FETCH (FLAGS (\Seen)) 698 S: A007 OK Fetch Completed 700 In the latter case \Answered, $Forwarded and \Draft flags were 701 lost on COPY, as the user has no "w" right in the target mailbox. 703 Expunging the selected mailbox: 704 EXPUNGE - "e" right on the selected mailbox. 706 CLOSE - "e" right on the selected mailbox. If the server is 707 unable to expunge the mailbox because the user doesn't have the 708 "e" right, the server MUST ignore expunge request, close the 709 mailbox and return tagged OK response. 711 Fetch information about a mailbox and its messages: 712 SELECT/EXAMINE/STATUS - "r" right on the mailbox. 714 FETCH - A FETCH request that implies setting \Seen flag MUST NOT 715 set it, if the current user doesn't have "s" right. 717 Changing flags: 718 STORE - the server MUST check if the user has "t" right - when the 719 user modifies \Deleted flag "s" right - when the user modifies 720 \Seen flag "w" right for all other message flags. STORE operation 721 SHOULD NOT fail if the user has rights to modify at least one flag 722 specified in the STORE, as the tagged NO response to a STORE 723 command is not handled very well by deployed clients. 725 Changing ACLs: 726 SETACL/DELETEACL - "a" right on the mailbox. 728 Reading ACLs: 729 GETACL - "a" right on the mailbox. 731 MYRIGHTS - any of the following rights is required to perform the 732 operation: "l", "r", "i", "k", "x", "a". 734 LISTRIGHTS - "a" right on the mailbox. 736 5. Other considerations 738 5.1 Additional requirements and Implementation notes 740 5.1.1 Servers 742 This document defines an additional capability that is used to 743 announce the list of extra rights (excluding the ones defined in the 744 RFC 2086) supported by the server. The set of rights MUST include 745 "t", "e", "x" and "k". Note that the extra rights can appear in any 746 order. 748 Example: C: 1 capability 749 S: * CAPABILITY IMAP4REV1 STARTTLS LITERAL+ 750 ACL RIGHTS=texk 751 S: 1 OK completed 753 Any server implementing an ACL extension MUST accurately reflect the 754 current user's rights in FLAGS and PERMANENTFLAGS responses. 756 Example: C: A142 SELECT INBOX 757 S: * 172 EXISTS 758 S: * 1 RECENT 759 S: * OK [UNSEEN 12] Message 12 is first unseen 760 S: * OK [UIDVALIDITY 3857529045] UIDs valid 761 S: * OK [UIDNEXT 4392] Predicted next UID 762 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 763 S: * OK [PERMANENTFLAGS (\Seen \Answered \Flagged \*)] L 764 S: A142 OK [READ-WRITE] SELECT completed 765 C: A143 MYRIGHTS INBOX 766 S: * MYRIGHTS INBOX lrwis 767 S: A143 OK completed 769 Note that in order to get better performance the client MAY pipeline 770 SELECT and MYRIGHTS commands: 772 C: A142 SELECT INBOX 773 C: A143 MYRIGHTS INBOX 774 S: * 172 EXISTS 775 S: * 1 RECENT 776 S: * OK [UNSEEN 12] Message 12 is first unseen 777 S: * OK [UIDVALIDITY 3857529045] UIDs valid 778 S: * OK [UIDNEXT 4392] Predicted next UID 779 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 780 S: * OK [PERMANENTFLAGS (\Seen \Answered \Flagged \*)] L 781 S: A142 OK [READ-WRITE] SELECT completed 782 S: * MYRIGHTS INBOX lrwis 783 S: A143 OK completed 785 Servers MAY cache the rights a user has on a mailbox when the mailbox 786 is selected, so that if a client's rights on a mailbox are changed 787 with SETACL or DELETEACL, commands specific to the selected state 788 (e.g., STORE, EXPUNGE) might not reflect the changed rights until the 789 mailbox is re-selected. If the server checks the rights on each 790 command, then it SHOULD send FLAGS and PERMANENTFLAGS responses if 791 they have changed. If such server detects that the user no longer 792 has read access to the mailbox, it MAY send an untagged BYE response 793 and close connection. It MAY also refuse to execute all commands 794 specific to the selected state until the mailbox is closed, however 795 server implementors should note that most clients don't handle NO 796 responses very well. 798 An ACL server MAY modify one or more ACL for one or more identifier 799 as a side effect of modifying the ACL specified in a SETACL/ 800 DELETEACL. If the server does that it MUST send untagged ACL 801 response(s) to notify the client about the changes made. 803 An ACL server implementation MUST treat received ACL modification 804 commands as a possible ambiguity with respect to subsequent commands 805 affected by the ACL, as described in section 5.5 of [IMAP4]. Hence a 806 pipeline SETACL + MYRIGHTS is an ambiguity with respect to the 807 server, meaning that the server must execute the SETACL command to 808 completion before the MYRIGHTS. However, clients are permitted to 809 send such a pipeline. 811 5.1.2 Clients 813 The following requirement is put on clients in order to allow for 814 future extensibility. A client implementation that allows a user to 815 read and update ACLs MUST preserve unrecognized rights that it 816 doesn't allow the user to change. I.e., if the client 818 1) can read ACLs 819 and 820 2) can update ACLs 821 but 822 3) doesn't allow the user to change the rights the client doesn't 823 recognize, then it MUST preserve unrecognized rights. 825 Otherwise the client could risk unintentionally removing permissions 826 it doesn't understand. 828 5.2 Mapping of ACL rights to READ-WRITE and READ-ONLY response codes 830 A particular ACL server implementation MAY allow "shared multiuser 831 access" to some mailboxes. "Shared multiuser access" to a mailbox 832 means that multiple different users are able to access the same 833 mailbox, if they have proper access rights. "Shared multiuser 834 access" to the mailbox doesn't mean that the ACL for the mailbox is 835 currently set to allow access by multiple users. Let's denote a 836 "shared multiuser write access" as a "shared multiuser access" when a 837 user can be granted flag modification rights (any of "w", "s" or 838 "t"). 840 Section 4 describes which rights are required for modifying different 841 flags. 843 If the ACL server implements some flags as shared for a mailbox 844 (i.e., the ACL for the mailbox MAY be set up so that changes to those 845 flags are visible to another user), let's call the set of rights 846 associated with these flags (as described in Section 4) for that 847 mailbox collectively as "shared flag rights". Note that "shared flag 848 rights" set MAY be different for different mailboxes. 850 If the server doesn't support "shared multiuser write access" to a 851 mailbox or doesn't implement shared flags on the mailbox, "shared 852 flag rights" for the mailbox is defined to be the empty set. 854 Example 1: Mailbox "banan" allows "shared multiuser write access" and 855 implements flags \Deleted, \Answered and $MDNSent as 856 shared flags. "Shared flag rights" for the mailbox "banan" 857 is a set containing flags "t" (because system flag 858 \Deleted requires "t" right) and "w" (because both 859 \Answered and $MDNSent require "w" right). 861 Example 2: Mailbox "apple" allows "shared multiuser write access" and 862 implements \Seen system flag as shared flag. "Shared flag 863 rights" for the mailbox "apple" contains "s" right, 864 because system flag \Seen requires "s" right. 866 Example 3: Mailbox "pear" allows "shared multiuser write access" and 867 implements flags \Seen, \Draft as shared flags. "Shared 868 flag rights" for the mailbox "apple" is a set containing 869 flags "s" (because system flag \Seen requires "s" right) 870 and "w" (because system flag \Draft requires "w" right). 872 The server MUST include a READ-ONLY response code in the tagged OK 873 response to a SELECT command if none of the following rights is 874 granted to the current user: 876 "i", "e" and "shared flag rights"*. 878 The server SHOULD include a READ-WRITE response code in the tagged OK 879 response if at least one of the "i", "e" or "shared flag rights"* is 880 granted to the current user. 882 * - Note that a future extension to this document can extend the list 883 of rights that causes the server to return the READ-WRITE response 884 code. 886 Example 1 (continued): The user that has "lrs" rights for the mailbox 887 "banan". The server returns READ-ONLY response 888 code on SELECT, as none of "iewt" rights is 889 granted to the user. 891 Example 2 (continued): The user that has "rit" rights for the mailbox 892 "apple". The server returns READ-WRITE 893 response code on SELECT, as the user has "i" 894 right. 896 Example 3 (continued): The user that has "rset" rights for the 897 mailbox "pear". The server returns READ-WRITE 898 response code on SELECT, as the user has "e" 899 and "s" rights. 901 6. Security Considerations 903 An implementation MUST make sure the ACL commands themselves do not 904 give information about mailboxes with appropriately restricted ACL's. 905 For example, when a user agent executes a GETACL command on a mailbox 906 that the user has no permission to LIST, the server would respond to 907 that request with the same error that would be used if the mailbox 908 did not exist, thus revealing no existence information, much less the 909 mailbox's ACL. 911 IMAP clients implementing ACL that are able to modify ACLs SHOULD 912 warn a user that wants to give full access (or even just the "a" 913 right) to the special identifier "anyone". 915 This document relies on [SASLprep] to describe steps required to 916 perform identifier canonicalization (preparation). The preparation 917 algorithm in SASLPrep was specifically designed such that its output 918 is canonical, and it is well-formed. However, due to an anomaly 919 [PR29] in the specification of Unicode normalization, canonical 920 equivalence is not guaranteed for a select few character sequences. 921 Identifiers prepared with SASLPrep can be stored and returned by an 922 ACL server. The anomaly affects ACL manipulation and evaluation of 923 identifiers containing the selected character sequences. These 924 sequences, however, do not appear in well-formed text. In order to 925 address this problem ACL server MAY reject identifiers containing 926 sequences described in [PR29] by sending the tagged BAD response. 927 This is in addition to the requirement to reject identifiers that 928 fail SASLPrep preparation as described in Section 3. 930 Other security considerations described in [IMAP4] are relevant to 931 this document. In particular, ACL information is sent in the clear 932 over the network unless confidentiality protection is negotiated. 934 This can be accomplished either by the use of STARTTLS, negotiated 935 privacy protection in the AUTHENTICATE command, or some other 936 protection mechanism. 938 7. Formal Syntax 940 Formal syntax is defined using ABNF [ABNF], extending the ABNF rules 941 in section 9 of [IMAP4]. Elements not defined here can be found in 942 the [ABNF] and [IMAP4]. 944 Except as noted otherwise, all alphabetic characters are case- 945 insensitive. The use of upper or lower case characters to define 946 token strings is for editorial clarity only. Implementations MUST 947 accept these strings in a case-insensitive fashion. 949 LOWER-ALPHA = %x61-7A ;; a-z 951 acl-data = "ACL" SP mailbox *(SP identifier SP 952 rights) 954 capability =/ rights-capa 955 ;;capability is defined in [IMAP4] 957 command-auth =/ setacl / deleteacl / getacl / 958 listrights / myrights 959 ;;command-auth is defined in [IMAP4] 961 deleteacl = "DELETEACL" SP mailbox SP identifier 963 getacl = "GETACL" SP mailbox 965 identifier = astring 967 listrights = "LISTRIGHTS" SP mailbox SP identifier 969 listrights-data = "LISTRIGHTS" SP mailbox SP identifier 970 SP rights *(SP rights) 972 mailbox-data =/ acl-data / listrights-data / myrights-data 973 ;;mailbox-data is defined in [IMAP4] 975 mod-rights = astring 976 ;; +rights to add, -rights to remove 977 ;; rights to replace 979 myrights = "MYRIGHTS" SP mailbox 981 myrights-data = "MYRIGHTS" SP mailbox SP rights 983 new-rights = 1*LOWER-ALPHA 984 ;; MUST include "t", "e", "x" and "k". 985 ;; MUST NOT include standard rights listed 986 ;; in section 2.2 988 rights = astring 989 ;; only lowercase ASCII letters and digits 990 ;; are allowed. 992 rights-capa = "RIGHTS=" new-rights 993 ;; RIGHTS=... capability 995 setacl = "SETACL" SP mailbox SP identifier 996 SP mod-rights 998 8. IANA Considerations 1000 IMAP4 capabilities are registered by publishing a standards track or 1001 IESG approved experimental RFC. The registry is currently located 1002 at: 1004 http://www.iana.org/assignments/imap4-capabilities 1006 This document defines the RIGHTS= IMAP capability. IANA is requested 1007 to add this capability to the registry. 1009 9. Internationalization Considerations 1011 Section 3 states requirements on servers regarding 1012 internationalization of identifiers. 1014 Appendix A. Changes since RFC 2086 1016 1. Changed the charset of "identifier" from US-ASCII to UTF-8. 1017 2. Specified that mailbox deletion is controled by the "x" right 1018 and EXPUNGE is controlled by the "e" right. 1019 3. Added the "t" right that controls STORE \Deleted. Redefined the 1020 "d" right to be a macro for "e", "t" and possibly "x". 1021 4. Added the "k" right that controls CREATE. Redefined the "c" 1022 right to be a macro for "k" and possibly "x". 1023 5. Specified that the "a" right also controls DELETEACL. 1024 6. Specified that the "r" right also controls STATUS. 1025 7. Removed the requirement to check the "r" right for CHECK, SEARCH 1026 and FETCH, as this is required for SELECT/EXAMINE to be 1027 successful. 1028 8. LISTRIGHTS requires the "a" right on the mailbox (same as 1029 SETACL). 1030 9. Deleted "PARTIAL", this is a deprecated feature of RFC 1730. 1031 10. Specified that the "w" right controls setting flags other than 1032 \Seen and \Deleted on APPEND. Also specified that the "s" right 1033 controls the \Seen flag and that the "t" right controls the 1034 \Deleted flag. 1035 11. Specified that SUBSCRIBE is NOT allowed with the "r" right. 1036 12. Specified that the "l" right controls SUBSCRIBE. 1037 13. GETACL is NOT allowed with the "r" right, even though there are 1038 several implementations that allows that. If a user only has 1039 "r" right, GETACL can disclose information about identifiers 1040 existing on the mail system. 1041 14. Clarified that RENAME requires the "k" right for the new parent 1042 and the "x" right for the old name. 1043 15. Added new section that describes which rights are required 1044 and/or checked when performing various IMAP commands. 1046 16. Added mail client security considerations when dealing with 1047 special identifier "anyone". 1048 17. Clarified that negative rights are not the same as DELETEACL. 1049 18. Added "Compatibility with RFC 2086" section. 1050 19. Added section about mapping of ACL rights to READ-WRITE and 1051 READ-ONLY response codes. 1052 20. Changed BNF to ABNF. 1053 21. Added "Implementation Notes" section. 1054 22. Updated "References" section. 1055 23. Added more examples. 1056 24. Clarified when the virtual "c" and "d" rights are returned in 1057 ACL, MYRIGHTS and LISTRIGHTS responses. 1059 Appendix B. Compatibility with RFC 2086 1061 This non-normative section gives guidelines how an existing RFC 2086 1062 server implementation may be updated to comply with this document. 1064 This document splits the "d" right into several new different rights: 1065 "t", "e" and possibly "x" (see Section 2.1.1 for more details). The 1066 "d" right remains for backwards-compatibility but it is a virtual 1067 right. There are two approaches for RFC2086 server implementors to 1068 handle the "d" right and the new rights that have replaced it: 1070 a. "t", "e" (and possibly "x) together - almost no changes. 1071 b. Implement separate "x", "t" and "e". Return the "d" right in a 1072 MYRIGHTS response or an ACL response containing ACL information 1073 when any of the "t", "e" (and "x") is granted. 1075 In a similar manner this document splits the "c" right into several 1076 new different rights: "k" and possibly "x" (see Section 2.1.1 for 1077 more details). The "c" right remains for backwards-compatibility but 1078 it is a virtual right. Again, RFC2086 server implementors can choose 1079 to tie rights or to implement separate rights, as described above. 1081 Also check Sections Section 5.1.1 and Section 5.1.2, as well as the 1082 Appendix A to see other changes required. Server implementors should 1083 check which rights are required to invoke different IMAP4 commands as 1084 described in Section 4. 1086 Appendix C. Known deficiencies 1088 This specification has some known deficiencies including: 1090 1. This is inadequate to provide complete read-write access to 1091 mailboxes protected by Unix-style rights bits because there is no 1092 equivalent to "chown" and "chgrp" commands nor is there a good 1093 way to discover such limitations are present. 1095 2. Because this extension leaves the specific semantics of how 1096 rights are combined by the server as implementation defined, the 1097 ability to build a user-friendly interface is limited. 1098 3. Users, groups, and special identifiers (e.g. anyone) exist in the 1099 same namespace. 1101 The work-in-progress "ACL2" extension is intended to redesign this 1102 extension to address these deficiencies without the constraint of 1103 backwards-compatibility and may eventually supercede this facility. 1104 However, RFC 2086 is deployed in multiple implementations so this 1105 intermediate step which fixes the straightforward deficiencies in a 1106 backwards compatible fashion is considered worthwhile. 1108 Appendix D. Acknowledgments 1110 This document is a revision of the RFC 2086 written by John G. Myers. 1112 Editor appreciates comments received from Mark Crispin, Chris Newman, 1113 Cyrus Daboo, John G. Myers, Dave Cridland, Ken Murchison, Steve Hole, 1114 Vladimir Butenko, Larry Greenfield, Robert Siemborski, Harrie 1115 Hazewinkel, Philip Guenther, Brian Candler, Curtis King, Lyndon 1116 Nerenberg, Lisa Dusseault, Arnt Gulbrandsen and other participants of 1117 the IMAPEXT working group. 1119 10. References 1121 10.1 Normative References 1123 [KEYWORDS] 1124 Bradner, S., "Key words for use in RFCs to Indicate 1125 Requirement Levels", BCP 14, RFC 2119, March 1997. 1127 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1128 Specifications: ABNF", RFC 2234, November 1997. 1130 [IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1131 4rev1", RFC 3501, March 2003. 1133 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 1134 10646", STD 63, RFC 3629, November 2003. 1136 [Stringprep] 1137 Hoffman, P. and M. Blanchet, "Preparation of 1138 Internationalized Strings ("stringprep")", RFC 3454, 1139 December 2002. 1141 [SASLprep] 1142 Zeilenga, K., "SASLprep: Stringprep Profile for User Names 1143 and Passwords", RFC 4013, February 2005. 1145 10.2 Informative References 1147 [RFC2086] Myers, J., "IMAP4 ACL extension", RFC 2086, January 1997. 1149 [PR29] "Public Review Issue #29: Normalization Issue", 1150 February 2004, . 1152 Author's Address 1154 Alexey Melnikov 1155 Isode Ltd. 1156 5 Castle Business Village 1157 36 Station Road 1158 Hampton, Middlesex TW12 2BX 1159 GB 1161 Email: alexey.melnikov@isode.com 1163 Intellectual Property Statement 1165 The IETF takes no position regarding the validity or scope of any 1166 Intellectual Property Rights or other rights that might be claimed to 1167 pertain to the implementation or use of the technology described in 1168 this document or the extent to which any license under such rights 1169 might or might not be available; nor does it represent that it has 1170 made any independent effort to identify any such rights. Information 1171 on the procedures with respect to rights in RFC documents can be 1172 found in BCP 78 and BCP 79. 1174 Copies of IPR disclosures made to the IETF Secretariat and any 1175 assurances of licenses to be made available, or the result of an 1176 attempt made to obtain a general license or permission for the use of 1177 such proprietary rights by implementers or users of this 1178 specification can be obtained from the IETF on-line IPR repository at 1179 http://www.ietf.org/ipr. 1181 The IETF invites any interested party to bring to its attention any 1182 copyrights, patents or patent applications, or other proprietary 1183 rights that may cover technology that may be required to implement 1184 this standard. Please address the information to the IETF at 1185 ietf-ipr@ietf.org. 1187 The IETF has been notified of intellectual property rights claimed in 1188 regard to some or all of the specification contained in this 1189 document. For more information consult the online list of claimed 1190 rights. 1192 Disclaimer of Validity 1194 This document and the information contained herein are provided on an 1195 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1196 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1197 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1198 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1199 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1200 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1202 Copyright Statement 1204 Copyright (C) The Internet Society (2005). This document is subject 1205 to the rights, licenses and restrictions contained in BCP 78, and 1206 except as set forth therein, the authors retain all their rights. 1208 Acknowledgment 1210 Funding for the RFC Editor function is currently provided by the 1211 Internet Society.