idnits 2.17.1 draft-ietf-imapext-2086upd-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 531. -- Found old boilerplate from RFC 3978, Section 5.5 on line 567. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 673 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 99 instances of too long lines in the document, the longest one being 13 characters in excess of 72. ** The abstract seems to contain references ([IMAP4], [RFC2086]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates 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 (Using the creation date from RFC2086, updated by this document, for RFC5378 checks: 1995-12-18) -- 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 (September 2004) is 7156 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: 'LISTEXT' is mentioned on line 355, but not defined == Missing Reference: 'UNSEEN 12' is mentioned on line 410, but not defined == Missing Reference: 'UIDVALIDITY 3857529045' is mentioned on line 411, but not defined == Missing Reference: 'UIDNEXT 4392' is mentioned on line 412, but not defined == Unused Reference: 'UTF-8' is defined on line 502, but no explicit reference was found in the text ** 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 2086 (Obsoleted by RFC 4314) ** Obsolete normative reference: RFC 2279 (ref. 'UTF-8') (Obsoleted by RFC 3629) -- No information found for draft-ietf-imapext-annotate-XX - is the name correct? Summary: 18 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IMAPEXT Working Group A. Melnikov 2 Internet Draft Editor 3 Document: draft-ietf-imapext-2086upd-00.txt September 2004 4 Updates: 2086, <<3501?>> 5 Expires: March 2005 7 IMAP4 ACL extension - 8 updated list of rights 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, or 14 will be disclosed, and any of which I become aware will be disclosed, 15 in accordance with RFC 3668. 17 Internet Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its Areas, and its Working Groups. Note that 19 other groups may also distribute working documents as Internet 20 Drafts. Internet Drafts are draft documents valid for a maximum of 21 six months. Internet Drafts may be updated, replaced, or obsoleted 22 by other documents at any time. It is not appropriate to use 23 Internet Drafts as reference material or to cite them other than as 24 ``work in progress''. 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or 33 munnari.oz.au. 35 A revised version of this draft document will be submitted to the RFC 36 editor as a Proposed Standard for the Internet Community. Discussion 37 and suggestions for improvement are requested. Distribution of this 38 draft is unlimited. 40 Abstract 42 The ACL (Access Control List) extension [RFC2086] of the Internet Message 43 Access Protocol [IMAP4] permits mailbox access control lists to be 44 manipulated through the IMAP protocol. 46 This document updates the list of rights defined in RFC 2086. It 47 also clarifies which rights are required for different IMAP commands. 49 0. Open issues and ToDo list 51 This section will be removed when the draft will be published as RFC. 52 It is intended to simplify discussion. 54 1). Do we want to add a requirement to send MYRIGHTS response on 55 SELECT/EXAMINE? 57 1. Conventions Used in this Document 59 In examples, "C:" and "S:" indicate lines sent by the client and 60 server respectively. 62 In all examples "/" character is used as hierarchy separator. 64 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 66 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 68 2. Introduction and Overview 70 The ACL (Access Control List) extension of the Internet Message Access 71 Protocol [IMAP4] permits mailbox access control lists to be retrieved 72 and manipulated through the IMAP protocol. 74 This document updates Section 3 of the RFC 2086. It also clarifies 75 different aspects of the RFC 2086, in particular use of UTF-8 in 76 identifiers, which rights are required for different IMAP4 commands; 77 how READ-WRITE/READ-ONLY response codes are related to ACL>> 79 3. Access Control 81 This section replaces Section 3 of the RFC 2086. 83 The ACL extension is present in any IMAP4 implementation which 84 returns "ACL" as one of the supported capabilities to the CAPABILITY 85 command. 87 A server implementation conformant to this document MUST also return 88 rights (see below) not defined in RFC 2086 in the "RIGHTS=" capability 89 response. 91 An access control list is an ordered list of pairs. 92 An ACL applies to a mailbox. 94 Identifier is a UTF-8 string. The identifier "anyone" is reserved 95 to refer to the universal identity (all authentications, including 96 anonymous). All user name strings accepted by the LOGIN or 97 AUTHENTICATE commands to authenticate to the IMAP server are reserved 98 as identifiers for the corresponding user. Identifiers starting with 99 a dash ("-") are reserved for "negative rights", described below. 100 All other identifier strings are interpreted in an implementation- 101 defined manner. 103 Rights is a string listing a (possibly empty) set of alphanumeric 104 characters, each character listing a set of operations which is being 105 controlled. Letters are reserved for ''standard'' rights, listed 106 below. The set of standard rights may only be extended by a 107 standards-track document. Digits are reserved for implementation or 108 site defined rights. The currently defined standard rights are 109 (note, that the list below doesn't list all commands that use a 110 particular right): 112 l - lookup (mailbox is visible to LIST/LSUB commands, SUBSCRIBE mailbox) 113 r - read (SELECT the mailbox, perform STATUS) 114 s - keep seen/unseen information across sessions (set or clear \SEEN flag 115 via STORE, APPEND or COPY) 116 w - write (set or clear flags other than \SEEN and \DELETED via STORE, 117 APPEND or COPY) 118 i - insert (perform APPEND, COPY into mailbox) 119 p - post (send mail to submission address for mailbox, 120 not enforced by IMAP4 itself. 121 c - create mailboxes (CREATE new sub-mailboxes in any 122 implementation-defined hierarchy, parent mailbox for the new 123 mailbox name in RENAME) 124 When a new mailbox is created it SHOULD inherit rights from 125 the parent mailbox (if one exists) in the defined hierarchy. 126 x - delete mailbox (DELETE mailbox, old mailbox name in RENAME) 127 t - delete messages (set or clear \DELETED flag via STORE, set \DELETED flag 128 during APPEND/COPY) 129 e - perform EXPUNGE and expunge as a part of CLOSE 130 d - This right is defined for backward compatibility with ACL 131 extension (RFC 2086). If a client sets "d" right, the server MUST 132 set "x", "e" and "t" rights. When the client clears the "d" right, 133 the server MUST clear "x", "e" and "t" rights. When all three of "x", 134 "e" and "t" are set, the server MUST return "d" right in response to 135 a LIST (ACL) command. If "x", "e" and "t" rights are not tied together, 136 "d" right MUST NOT be returned in a LISTRIGHTS response. 137 a - administer (perform SETACL/DELETEACL/GETACL) 138 n - write shared annotations [ANNOTATE] 140 <> 142 An implementation may tie rights together or may force rights to 143 always or never be granted to particular identifiers. For example, 144 in an implementation that uses unix mode bits, the rights "swite" are 145 tied, the "a" right is always granted to the owner of a mailbox and 146 is never granted to another user. If rights are tied in an 147 implementation, the implementation must be conservative in granting 148 rights in response to SETACL commands--unless all rights in a tied 149 set are specified, none of that set should be included in the ACL 150 entry for that identifier. A client may discover the set of rights 151 which may be granted to a given identifier in the ACL for a given 152 mailbox by using the LISTRIGHTS command. 154 It is possible for multiple identifiers in an access control list to 155 apply to a given user (or other authentication identity). For 156 example, an ACL may include rights to be granted to the identifier 157 matching the user, one or more implementation-defined identifiers 158 matching groups which include the user, and/or the identifier 159 "anyone". How these rights are combined to determine the user's 160 access is implementation-defined. An implementation may choose, for 161 example, to use the union of the rights granted to the applicable 162 identifiers. An implementation may instead choose, for example, to 163 only use those rights granted to the most specific identifier present 164 in the ACL. A client may determine the set of rights granted to the 165 logged-in user for a given mailbox by using the MYRIGHTS command. 167 When an identifier in an ACL starts with a dash ("-"), that indicates 168 that associated rights are to be removed from the identifier that is 169 prefixed by the dash. This is referred to as a "negative right". 170 This differs from DELETEACL in that a negative right is added to the 171 ACL, and is a part of the calculation of the rights. 173 Let's assume that an identifier "fred" refers to a user with login "fred". 174 If the identifier "-fred" is granted the "w" right, 175 that indicates that the "w" right is to be removed from users matching 176 the identifier "fred", even though the user "fred" might have 177 the "w" right as a consequence of some other identifier in the ACL. 178 A DELETEACL of "fred" simply deletes the identifier "fred" 179 from the ACL; it does not affect any rights that the user "fred" 180 may get from another entry in the ACL. 182 Server implementations are not required to support "negative right" 183 identifiers. 185 4. Rights required to perform different IMAP4rev1 commands 187 Before executing a command an ACL compliant server must check which rights 188 are required to perform it. This section groups command by functions 189 they perform and list the rights required. It also gives the detailed 190 description of any special processing required. 192 The table below summarizes different rights or their combinations that are 193 required in order to perform different IMAP operations. As it is not always 194 possible to express complex right checking and interactions, the description 195 after the table should be used as the primary reference. 197 +---------------------+---+---+---+---+---+---+---+---+---+---+-----+------+ 198 | Operations\Rights | l | r | s | w | i | c | x | t | e | a | Any | None | 199 +---------------------+---+---+---+---+---+---+---+---+---+---+-----+------+ 200 | LIST | + | | | | | | | | | | | | 201 | SUBSCRIBE | * | | | | | | | | | | | * | 202 | UNSUBSCRIBE | | | | | | | | | | | | + | 203 | LSUB | * | | | | | | | | | | | * | 204 | CREATE (for parent) | | | | | | + | | | | | | | 205 | DELETE | | | | | | | + | | | | | | 206 | RENAME | | | | | | + | + | | | | | | 207 | COPY/APPEND | | | ? | ? | + | | | ? | | | | | 208 | EXPUNGE/CLOSE | | | | | | | | | + | | | | 209 |SELECT/EXAMINE/STATUS| | + | | | | | | | | | | | 210 | FETCH | | | ? | | | | | | | | | | 211 | STORE flags | | | ? | ? | | | | ? | | | | | 212 | SETACL/DELETEACL | | | | | | | | | | + | | | 213 | GETACL | | | | | | | | | | + | | | 214 | MYRIGHTS/LISTRIGHTS | | | | | | | | | | | + | | 215 +---------------------+---+---+---+---+---+---+---+---+---+---+-----+------+ 217 Legend: 218 + - The right is required 219 * - Only one of the rights marked with * is required (see description below) 220 ? - The right is optional (see description below) 221 "Any" - at least one of the "l", "r", "i", "c", "x", "e", "a" rights is 222 required 223 "None" - No rights required to perform the command 225 Listing and subscribing/unsubscribing mailboxes: 226 LIST - "l" right is required. 228 Note, that if the user has "l" right to a mailbox "A/B", but not to its parent 229 mailbox "A", the LIST command should behave as if the mailbox "A" doesn't exist, 230 for example: 231 C: A777 LIST "" * 232 S: * LIST (\NoInferiors) "/" "A/B" 233 S: * LIST () "/" "C" 234 S: * LIST (\NoInferiors) "/" "C/D" 235 S: A777 OK LIST completed 237 SUBSCRIBE - "l" right is required only if the server checks for mailbox existence 238 when performing SUBSCRIBE. 240 UNSUBSCRIBE - no rights required to perform this operation. 242 LSUB - "l" right is required only if the server checks for mailbox existence when 243 performing SUBSCRIBE. 245 Mailbox management: 246 CREATE - "c" right on a nearest existing parent mailbox. When a new 247 mailbox is created it SHOULD inherit rights from the parent 248 mailbox (if one exists) in the defined hierarchy. 250 DELETE - "x" right on the mailbox. 252 RENAME - Moving a mailbox from one parent to another 253 requires "x" right on the mailbox itself and "c" right for 254 the new parent. For example, if the user wants to rename 255 mailbox named "A/B/C" to "D/E", the user must have "x" right 256 for the mailbox "A/B/C" and "c" right for the mailbox "D". 258 Copying or appending messages: 260 Before performing a COPY/APPEND command the server MUST check if the 261 user has "i" right for the target mailbox. If the user doesn't have "i" 262 right, the operation fails. Otherwise for each copied/appended message 263 the server MUST check if the user has 264 "t" right - when the message has \Deleted flag set 265 "s" right - when the message has \Seen flag set 266 "w" right for all other message flags. 267 Only when the user has a particular right the corresponding flags are 268 stored for the newly created message. The server MUST NOT fail 269 a COPY/APPEND if the user has no rights to set a particular flag. 271 Example: C: A003 MYRIGHTS TargetMailbox 272 S: * MYRIGHTS TargetMailbox rwis 273 S: A003 OK Myrights complete 275 C: A004 FETCH 1:3 (FLAGS) 276 S: * 1 FETCH (FLAGS (\Draft \Deleted) 277 S: * 2 FETCH (FLAGS (\Answered) 278 S: * 3 FETCH (FLAGS ($Forwarded \Seen) 279 S: A004 OK Fetch Completed 281 C: A005 COPY 1:3 TargetMailbox 282 S: A005 OK Copy completed 284 C: A006 SELECT TargetMailbox 285 ... 286 S: A006 Select Completed 288 Let's assume that the copied messages received message numbers 77:79. 290 C: A007 FETCH 77:79 (FLAGS) 291 S: * 77 FETCH (FLAGS (\Draft)) 292 S: * 78 FETCH (FLAGS (\Answered)) 293 S: * 79 FETCH (FLAGS ($Forwarded \Seen)) 294 S: A007 OK Fetch Completed 296 \Deleted flag was lost on COPY, as the user has no "t" right in the 297 target mailbox. 299 If the MYRIGHTS command with the tag A003 would have returned: 300 S: * MYRIGHTS TargetMailbox rsti 302 the response from the FETCH with the tag A007 would have been: 304 C: A007 FETCH 77:79 (FLAGS) 305 S: * 77 FETCH (FLAGS (\Deleted)) 306 S: * 78 FETCH (FLAGS ()) 307 S: * 79 FETCH (FLAGS (\Seen)) 308 S: A007 OK Fetch Completed 310 In the latter case \Answered, $Forwarded and \Draft flags were lost 311 on COPY, as the user has no "w" right in the target mailbox. 313 Expunging the selected mailbox: 314 EXPUNGE - "e" right on the selected mailbox. 316 CLOSE - "e" right on the selected mailbox. If the server is unable to 317 expunge the mailbox because the user doesn't have the "e" right, 318 the server MUST ignore expunge request, close the mailbox 319 and return tagged OK response. 321 Fetch information about a mailbox and its messages: 322 SELECT/EXAMINE/STATUS - "r" right on the mailbox. 324 FETCH - A FETCH request that implies setting \Seen flag MUST NOT set it, 325 if the current user doesn't have "s" right. 327 Changing flags: 328 STORE - the server MUST check if the user has 329 "t" right - when the user modifies \Deleted flag 330 "s" right - when the user modifies \Seen flag 331 "w" right for all other message flags. 332 STORE operation SHOULD NOT fail if the user has rights to modify at least 333 one flag specified in the STORE, as the tagged NO response to a STORE 334 command is not handled very well by deployed clients. 336 Changing ACLs: 337 SETACL/DELETEACL - "a" right on the mailbox. 339 Reading ACLs: 340 GETACL - "a" right on the mailbox. 342 MYRIGHTS - any of the following rights is required to perform 343 the operation: "l", "r", "i", "c", "x", "e", "a". 345 LISTRIGHTS - same as MYRIGHTS. <> <> 347 5. Formal Syntax 349 This document doesn't change the formal syntax of commands/ 350 responses defined in the Section 6 of RFC 2086. However, 351 the "identifier" production is now allowed to carry any UTF-8 string. 353 Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4]. 354 Non-terminals referenced but not defined below are as defined by 355 [IMAP4] or [LISTEXT]. 357 Except as noted otherwise, all alphabetic characters are 358 case-insensitive. The use of upper or lower case characters to 359 define token strings is for editorial clarity only. Implementations 360 MUST accept these strings in a case-insensitive fashion. 362 rights_capa = "RIGTHS=" new_rights 363 ;; RIGHTS=... capability 365 new_rights = atom 366 ;; MUST include "t", "e", "x" and "n" <> 368 6. Security Considerations 370 An implementation must make sure the ACL commands themselves do not 371 give information about mailboxes with appropriately restricted ACL's. 372 For example, a GETACL command on a mailbox for which the user has 373 insufficient rights should not admit that the mailbox exists, much less 374 return the mailbox's ACL. 376 LISTRIGHTS command MUST NOT check that a particular identifier exists, 377 however it SHOULD recognize special identifiers like "anyone". 379 IMAP clients implementing ACL that are able to modify ACLs SHOULD 380 warn a user that wants to give full access (or even just "a" right) 381 to the special identifier "anyone". 383 7. Other considerations 385 7.1. Additional requirements and Implementation notes 387 This document defines an additional capability that is used to announce 388 the list of extra rights (excluding the ones defined in the RFC 2086) 389 supported by the server. The set of rights MUST include "t", "e", "x" 390 and "n" <>. Note, that the extra rights can appear in any order. 392 Example: C: 1 capability 393 S: * CAPABILITY IMAP4REV1 STARTTLS LITERAL+ ACL RIGTHS=texn<<>> 394 S: 1 OK completed 396 A client implementation that allows a user to read and update ACL MUST 397 preserve unrecognized rights that it doesn't allow the user to change 398 when updating the rights. Otherwise the client may unintentionally remove 399 permissions. 401 Any server implementing an ACL extension MUST accurately reflect the current 402 user's rights in FLAGS and PERMANENTFLAGS responses. 404 Example: C: A141 MYRIGHTS INBOX 405 S: * MYRIGHTS INBOX rwis 406 S: A141 OK Myrights complete 407 C: A142 SELECT INBOX 408 S: * 172 EXISTS 409 S: * 1 RECENT 410 S: * OK [UNSEEN 12] Message 12 is first unseen 411 S: * OK [UIDVALIDITY 3857529045] UIDs valid 412 S: * OK [UIDNEXT 4392] Predicted next UID 413 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 414 S: * OK [PERMANENTFLAGS (\Seen \Answered \Flagged \*)] Limited 415 S: A142 OK [READ-WRITE] SELECT completed 417 An ACL server MAY modify one or more ACL for one or more identifier as a 418 side effect of modifying the ACL specified in a SETACL/DELETEACL. 419 If the server does that it MUST send untagged ACL response to notify the 420 client about the changes made. 422 7.2. Mapping of ACL rights to READ-WRITE and READ-ONLY response codes 424 A particular ACL server implementation may allow "shared multiuser 425 access" to some mailboxes. "Shared multiuser access" to a mailbox means 426 that multiple different users are able to access the same mailbox, 427 if they have proper access rights. "Shared multiuser access" to the 428 mailbox doesn't mean that the ACL for the mailbox is currently set 429 to allow access by multiple users. Let's denote a "shared multiuser 430 write access" as a "shared multiuser access" when a user may be 431 granted flag modification rights (any of "w", "s" or "t"). 433 Section 4 describes which rights are required for modifying different flags. 435 If the ACL server implements some flags as shared for a mailbox (i.e., 436 the ACL for the mailbox may be set up so that changes to those flags are 437 visible to another user), let's call the set of rights associated with these 438 flags (as described in Section 4) for that mailbox collectively as 439 "shared flag rights". Note, that "shared flag rights" set MAY be different 440 for different mailboxes. 442 If the server doesn't support "shared multiuser write access" to a 443 mailbox or doesn't implement shared flags on the mailbox, "shared flag 444 rights" for the mailbox is defined to be the empty set. 446 Example 1: Mailbox "banan" allows "shared multiuser write access" and 447 implements flags \Deleted, \Answered and $MDNSent as 448 shared flags. "Shared flag rights" for the mailbox "banan" 449 is a set containing flags "t" (because system flag \Deleted 450 requires "t" right) and "w" (because both \Answered and 451 $MDNSent require "w" right). 453 Example 2: Mailbox "apple" allows "shared multiuser write access" and 454 implements \Seen system flag as shared flag. "Shared flag 455 rights" for the mailbox "apple" contains "s" right, 456 because system flag \Seen requires "s" right. 458 Example 3: Mailbox "pear" allows "shared multiuser write access" and 459 implements flags \Seen, \Draft as shared flags. "Shared flag 460 rights" for the mailbox "apple" is a set containing flags "s" 461 (because system flag \Seen requires "s" right) and "w" 462 (because system flag \Draft requires "w" right). 464 The server MUST include a READ-ONLY prefix in the tagged OK response to 465 a SELECT command if none of the following rights is granted to the 466 current user: 467 "i", "e" and "shared flag rights". 468 The server SHOULD include a READ-WRITE prefix in the tagged OK response 469 if at least one of the "i", "e" or "shared flag rights" is granted to the 470 current user. 472 Example 1 (continued): The user that has "lrs" rights for the mailbox 473 "banan". The server returns READ-ONLY response 474 code on SELECT, as none of "iewt" rights is 475 granted to the user. 477 Example 2 (continued): The user that has "rit" rights for the mailbox 478 "apple". The server returns READ-WRITE response 479 code on SELECT, as the user has "i" right. 481 Example 3 (continued): The user that has "rset" rights for the mailbox 482 "pear". The server returns READ-WRITE response 483 code on SELECT, as the user has "e" and "s" rights. 485 8. References 487 8.1. Normative References 489 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 490 Requirement Levels", RFC 2119, Harvard University, March 1997. 492 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: 493 ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd, 494 November 1997. 496 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 497 4rev1", RFC 3501, University of Washington, March 2003. 499 [RFC2086] Myers, J., "IMAP4 ACL extension", RFC 2086, Carnegie Mellon, 500 January 1997 502 [UTF-8] Yergeau, F., "UTF-8, a transformation format of IS0 10646", 503 RFC 2279, Alis Technologies, January 1998. 505 8.2. Informative References 507 [ANNOTATE] Gellens, R. and C. Daboo, "IMAP ANNOTATE Extension", 508 work in progress, draft-ietf-imapext-annotate-XX.txt 510 9. Aknowledgement 512 This document is a revision of the RFC 2086 written by John G. Myers. 514 Editor appreciates comments received from Mark Crispin, Chris Newman, 515 Cyrus Daboo, John G. Myers, Steve Hole, Curtis King, Lyndon Nerenberg, 516 Larry Greenfield, Robert Siemborski, Vladimir Butenko, Dave Cridland, 517 Harrie Hazewinkel and other participants of the IMAPEXT working group. 519 10. Editor's Address 521 Alexey Melnikov 522 email: alexey.melnikov@isode.com 524 Isode Limited 526 11. IPR Disclosure Acknowledgement 528 By submitting this Internet-Draft, I certify that any applicable 529 patent or other IPR claims of which I am aware have been disclosed, 530 and any of which I become aware will be disclosed, in accordance with 531 RFC 3668. 533 12. Intellectual Property Statement 535 The IETF takes no position regarding the validity or scope of any 536 intellectual property or other rights that might be claimed to 537 pertain to the implementation or use of the technology described in 538 this document or the extent to which any license under such rights 539 might or might not be available; neither does it represent that it 540 has made any effort to identify any such rights. Information on the 541 IETF's procedures with respect to rights in standards-track and 542 standards-related documentation can be found in BCP-11. Copies of 543 claims of rights made available for publication and any assurances of 544 licenses to be made available, or the result of an attempt made to 545 obtain a general license or permission for the use of such 546 proprietary rights by implementors or users of this specification can 547 be obtained from the IETF Secretariat. 549 The IETF invites any interested party to bring to its attention any 550 copyrights, patents or patent applications, or other proprietary 551 rights which may cover technology that may be required to practice 552 this standard. Please address the information to the IETF Executive 553 Director. 555 13. Full Copyright Statement 557 Copyright (C) The Internet Society (2004). This document is subject 558 to the rights, licenses and restrictions contained in BCP 78 and 559 except as set forth therein, the authors retain all their rights. 561 This document and the information contained herein are provided on an 562 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 563 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 564 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 565 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 566 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 567 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 569 Acknowledgement 571 Funding for the RFC Editor function is currently provided by the 572 Internet Society. 574 Appendix A. Changes since RFC 2086 576 1. Changed the charset of "identifier" from US-ASCII to UTF-8. 578 2. Specified that mailbox deletion is controled by the "x" right and 579 EXPUNGE is controlled by "e" right. 581 3. Clarified that RENAME requires "c" right for the new parent and "x" 582 right for the old name. 584 4. Added "t" right that controls STORE \Deleted. Redefined "d" to be a 585 macro for "e", "x" and "t". 587 5. Specified that "a" right also controls DELETEACL. 589 6. Specified that "r" right also controls STATUS. 591 7. Removed the requirement to check the "r" right for CHECK, SEARCH and 592 FETCH, as this is required for SELECT/EXAMINE to be successful. 594 8. LISTRIGHTS requires same rights as MYRIGHTS. 596 9. Deleted "PARTIAL", this is a deprecated feature of RFC1730. 598 10. Specified that "w" controls setting flags other than \Seen and 599 \Deleted on APPEND. Same for "s" and "t" flags. 601 11. SUBSCRIBE is NOT allowed with "r" right. 603 12. Specified that "l" controls SUBSCRIBE. 605 13. GETACL is NOT allowed with "r" right, even though there are several 606 implementations that allows that. If a user only has "r" right, 607 GETACL can disclose information about identifiers existing on the 608 mail system. 610 14. Added new section that describes which rights are required and/or 611 checked when performing various IMAP commands. 613 15. Added mail client security considerations when dealing with special 614 identifier "anyone". 616 16. Clarified that negative rights are not the same as DELETEACL. 618 17. Added note that a server can modify an ACL for any identifier(s) as a 619 side effect of performing SETACL/DELETEACL. Also specified that 620 the server MUST send untagged ACL response if it does that. 621 <> 623 18. Added section about mapping of ACL rights to READ-WRITE and READ-ONLY 624 response codes. 626 19. Added "Compatibility with RFC 2086" section. 628 20. Added "Implementation Notes" section. 630 21. Updated "References" section. 632 Appendix B. Compatibility with RFC 2086 634 This section gives guidelines how an existing RFC 2086 server 635 implementation may be updated to comply with this document. 637 This document replaces "d" right with 3 new different rights "x", "t" 638 and "e". The server should implement one of the following two 639 approaches to handle "d" and the new rights that have replaced it. 641 a). Tie "x", "t" and "e" together - almost no changes 642 b). Implement separate "x", "t" and "e". Return "d" right in a LIST 643 response containing ACL information when all three of "x", "t" 644 and "e" are granted. 646 Also check Sections 7.1 and 7.2, as well as the appendix A to see 647 other changes required. Server implementors should check which rights 648 are required to invoke different IMAP4 commands as described in 649 Section 4.