idnits 2.17.1 draft-ietf-imapext-acl-03.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 579 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 33 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** There are 7 instances of lines with control characters in the document. ** The abstract seems to contain references ([IMAP4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack 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 (February 2002) is 8105 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'UTF-8' is defined on line 465, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2060 (ref. 'IMAP4') (Obsoleted by RFC 3501) ** Obsolete normative reference: RFC 2279 (ref. 'UTF-8') (Obsoleted by RFC 3629) Summary: 12 errors (**), 0 flaws (~~), 4 warnings (==), 3 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-acl-03.txt February 2002 5 IMAP4 ACL extension 7 Status of this Memo 9 This document is an Internet Draft and is in full conformance with 10 all provisions of Section 10 of RFC 2026. 12 Internet Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its Areas, and its Working Groups. Note that 14 other groups may also distribute working documents as Internet 15 Drafts. Internet Drafts are draft documents valid for a maximum of 16 six months. Internet Drafts may be updated, replaced, or obsoleted 17 by other documents at any time. It is not appropriate to use 18 Internet Drafts as reference material or to cite them other than as 19 ``work in progress''. 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or 28 munnari.oz.au. 30 A revised version of this draft document will be submitted to the RFC 31 editor as a Proposed Standard for the Internet Community. Discussion 32 and suggestions for improvement are requested. Distribution of this 33 draft is unlimited. 35 0. Open issues 37 This section will be removed when the draft will be published as RFC. 38 It is intended to simplify discussion. 40 1). Should the document define exact syntax for identifiers starting 41 with '$'? For example, the following was proposed by Mark Crispin: 43 Definable identifiers. Server implementations are *NOT* required to 44 use any of these, but if they do, these are their semantics. Note 45 that definable identifiers may expand to other definable identifiers. 47 $G$xxx global identifier xxx. Valid everywhere 48 $U$xxx per-user identifier xxx. Valid only for the logged-in user 49 $M$xxx per-mailbox identifer xxx. Valid only for this mailbox 50 $xxxxx reserved for future definition 52 Non-definable identifiers. Server implementations SHOULD support $WORLD, 53 and MUST support anyone and user names. However, a server can respond 54 with a NO. 56 $WORLD all authorized users but not anonymous 57 $ANONYMOUS anonymous users 58 $DISABLE disabled rights 60 2). Do we need a mechanism to encode login names if they start with 61 $, -? 63 3). Should the annotations (ANNOTATE) be controlled by "w" right? 65 4). Should the "l" right control UNSUBSCRIBE or should a client be able to 66 unsubscribe a mailbox even if the client can't LIST it? 68 1. Abstract 70 The ACL extension of the Internet Message Access Protocol [IMAP4] 71 permits access control lists to be manipulated through the IMAP 72 protocol. 74 2. Conventions Used in this Document 76 In examples, "C:" and "S:" indicate lines sent by the client and 77 server respectively. 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 83 3. Introduction and Overview 85 The ACL extension is present in any IMAP4 implementation which 86 returns a capability starting with "ACL2=" as one of the supported 87 capabilities to the CAPABILITY command. 89 An access control list is a set of pairs. 91 Identifier is a UTF-8 string. The identifier "anyone" is reserved to 92 refer to the universal identity (all authentications, including 93 anonymous). All user name strings accepted by the LOGIN or 94 AUTHENTICATE commands to authenticate to the IMAP server are reserved 95 as identifiers for the corresponding user. Identifiers starting with 96 a dash ("-") are reserved for "negative rights", described below. 97 Identifiers starting with a dollar sign ("$") are reserved for 98 groups and implementation defined aliases. All other identifier strings 99 are interpreted in an implementation-defined manner. 101 Rights is a string listing a (possibly empty) set of alphanumeric 102 characters, each character listing a set of operations which is being 103 controlled. Letters are reserved for ''standard'' rights, listed 104 below. The set of standard rights may only be extended by a 105 standards-track document. Digits are reserved for implementation or 106 site defined rights. The currently defined standard rights are: 108 l - lookup (mailbox is visible to LIST/LSUB commands, SUBSCRIBE/UNSUBSCRIBE 109 mailbox) 110 r - read (SELECT the mailbox, perform STATUS, CHECK, FETCH, PARTIAL, 111 SEARCH, COPY from mailbox) 112 s - keep seen/unseen information across sessions (set or clear \SEEN flag 113 via STORE or APPEND) 114 w - write (set or clear flags other than \SEEN and \DELETED via STORE 115 or APPEND) 116 i - insert (perform APPEND, COPY into mailbox) 117 p - post (send mail to submission address for mailbox, 118 not enforced by IMAP4 itself) 119 c - create mailboxes (CREATE new sub-mailboxes in any 120 implementation-defined hierarchy, parent mailbox for the new 121 mailbox name in RENAME). 122 When a new mailbox is created it SHOULD inherit rights from 123 the parent mailbox (if one exists) in the defined hierarchy. 124 x - delete mailbox (DELETE mailbox, old mailbox name in RENAME) 125 t - delete messages (set or clear \DELETED flag via STORE or APPEND) 126 e - perform EXPUNGE 127 d - if a client sets "d" right, the server MUST set "x", "e" and "t" 128 rights. When the client clears the "d" right, the server MUST 129 clear "x", "e" and "t" rights. When all three of "x", "e" and "t" 130 are set, the server MUST return "d" right in response to a GETACL 131 command. This right is defined for backward compatibility with ACL 132 extension (RFC 2086). 133 a - administer (perform SETACL and DELETEACL) 135 Note, that moving (RENAME command) mailbox from one parent to another 136 requires "x" right on the mailbox itself and "c" right for the new parent. 137 For example, if the user wants to rename mailbox named "A/B/C" 138 ("/" is hierarchy separator) to "D/E", the user must have "x" right 139 for mailbox "A/B/C" and "c" right for mailbox "D". 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 "wisd" 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 may discover the set of rights 150 which may be granted to a given identifier in the ACL for a given 151 mailbox by using the LISTRIGHTS command. 153 When an identifier in an ACL starts with a dash ("-"), that indicates 154 that associated rights are to be removed from the identifier that is 155 prefixed by the dash. This is referred to as a "negative right". For 156 example, if the identifier "-fred" is granted the "w" right, that 157 indicates that the "w" right is to be removed from users matching the 158 identifier "fred". Server implementations are not required to 159 support "negative right" identifiers. 161 It is possible for multiple identifiers in an access control list to 162 apply to a given user (or other authentication identity). For 163 example, an ACL may include rights to be granted to the identifier 164 matching the user, one or more implementation-defined identifiers 165 matching groups which include the user, and/or the identifier 166 "anyone". How these rights are combined to determine the user's 167 access is implementation-defined. The set of rules that describes 168 how access is calculated is defined by a rule identifier (rule-ID). 170 A client may determine the set of rights granted to the logged-in user 171 for a given mailbox by using the MYRIGHTS command. 173 If a server implementing ACL2 uses the union of the rights granted to 174 the applicable identifiers minus the union of the negative rights 175 in order to calculate access, it MUST report "ACL2=UNION" in the server's 176 capability list. 178 An implementation may instead choose to only use those rights granted 179 to the most specific identifier present in the ACL. In this case the 180 server MUST report "ACL2=MOST-SPECIFIC" in the server's capability 181 list. 183 If the server implements any other policy for rights calculation, 184 it MUST be either registered with IANA using the template provided in 7.1 185 or start with "X-". The server MUST report "ACL2=" capability. 187 4. Commands 189 4.1. SETACL 191 Arguments: mailbox name 192 authentication identifier 193 access right modification 195 Data: no specific data for this command 197 Result: OK - setacl completed 198 NO - setacl failure: can't set acl 199 BAD - command unknown or arguments invalid 201 The SETACL command changes the access control list on the 202 specified mailbox so that the specified identifier is granted 203 permissions as specified in the third argument. 205 The third argument is a string containing an optional plus ("+") 206 or minus ("-") prefix, followed by zero or more rights characters. 207 If the string starts with a plus, the following rights are added 208 to any existing rights for the identifier. If the string starts 209 with a minus, the following rights are removed from any existing 210 rights for the identifier. If the string does not start with a 211 plus or minus, the rights replace any existing rights for the 212 identifier. 214 4.2. DELETEACL 216 Arguments: mailbox name 217 authentication identifier 219 Data: no specific data for this command 221 Result: OK - deleteacl completed 222 NO - deleteacl failure: can't delete acl 223 BAD - command unknown or arguments invalid 225 The DELETEACL command removes any pair for the 226 specified identifier from the access control list for the 227 specified mailbox. 229 4.3. GETACL 231 Arguments: mailbox name 233 Data: untagged responses: ACL 235 Result: OK - getacl completed 236 NO - getacl failure: can't get acl 237 BAD - command unknown or arguments invalid 239 The GETACL command returns the access control list for mailbox in 240 an untagged ACL reply. 242 Example: C: A002 GETACL INBOX 243 S: * ACL INBOX Fred rwipslextda 244 S: A002 OK Getacl complete 246 4.4. LISTRIGHTS 248 Arguments: mailbox name 249 authentication identifier 251 Data: untagged responses: LISTRIGHTS 253 Result: OK - listrights completed 254 NO - listrights failure: can't get rights list 255 BAD - command unknown or arguments invalid 257 The LISTRIGHTS command takes a mailbox name and an identifier and 258 returns information about what rights may be granted to the 259 identifier in the ACL for the mailbox. 261 Example: C: a001 LISTRIGHTS ~/Mail/saved smith 262 S: * LISTRIGHTS ~/Mail/saved smith la r swi cdext 263 S: a001 OK Listrights completed 265 C: a005 LISTRIGHTS archive.imap anyone 266 S: * LISTRIGHTS archive.imap anyone "" l r s w i p c dtex a 267 0 1 2 3 4 5 6 7 8 9 268 S: a005 OK Listrights completed 270 4.5. MYRIGHTS 272 Arguments: mailbox name 274 Data: untagged responses: MYRIGHTS 276 Result: OK - myrights completed 277 NO - myrights failure: can't get rights 278 BAD - command unknown or arguments invalid 280 The MYRIGHTS command returns the set of rights that the user has 281 to mailbox in an untagged MYRIGHTS reply. 283 Example: C: A003 MYRIGHTS INBOX 284 S: * MYRIGHTS INBOX rwipsldexa 285 S: A003 OK Myrights complete 287 5. Responses 289 5.1. ACL 291 Data: mailbox name 292 zero or more identifier rights pairs 294 The ACL response occurs as a result of a GETACL command. The 295 first string is the mailbox name for which this ACL applies. This 296 is followed by zero or more pairs of strings, each pair contains 297 the identifier for which the entry applies followed by the set of 298 rights that the identifier has. 300 5.2. LISTRIGHTS 302 Data: mailbox name 303 identifier 304 required rights 305 list of optional rights 307 The LISTRIGHTS response occurs as a result of a LISTRIGHTS 308 command. The first two strings are the mailbox name and 309 identifier for which this rights list applies. Following the 310 identifier is a string containing the (possibly empty) set of 311 rights the identifier will always be granted in the mailbox. 312 Following this are zero or more strings each containing a set of 313 rights the identifier may be granted in the mailbox. Rights 314 mentioned in the same string are tied together--either all must be 315 granted to the identifier in the mailbox or none may be granted. 317 The same right may not be listed more than once in the LISTRIGHTS 318 command. 320 5.3. MYRIGHTS 322 Data: mailbox name 323 rights 325 The MYRIGHTS response occurs as a result of a MYRIGHTS command. 326 The first string is the mailbox name for which these rights apply. 327 The second string is the set of rights that the client has. 329 6. Formal Syntax 331 Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4]. 332 Non-terminals referenced but not defined below are as defined by 333 [IMAP4]. 335 Except as noted otherwise, all alphabetic characters are 336 case-insensitive. The use of upper or lower case characters to 337 define token strings is for editorial clarity only. Implementations 338 MUST accept these strings in a case-insensitive fashion. 340 acl_data = "ACL" SPACE mailbox *(SPACE identifier SPACE rights) 342 deleteacl = "DELETEACL" SPACE mailbox SPACE identifier 344 getacl = "GETACL" SPACE mailbox 346 identifier = astring 347 ;; UTF-8 349 listrights = "LISTRIGHTS" SPACE mailbox SPACE identifier 351 listrights_data = "LISTRIGHTS" SPACE mailbox SPACE identifier 352 SPACE rights *(SPACE rights) 354 mod_rights = astring 355 ;; +rights to add, -rights to remove 357 myrights = "MYRIGHTS" SPACE mailbox 359 myrights_data = "MYRIGHTS" SPACE mailbox SPACE rights 361 resp-text-code =/ myrights_data 363 rights = astring 365 setacl = "SETACL" SPACE mailbox SPACE identifier SPACE mod_rights 367 7. IANA considerations 369 7.1. ACL access calculation rule Registration Template 371 When an access calculation rule for ACL2 extension is registered, the 372 following information is supplied: 374 Rule Identification: specify a string that identifies this 375 rule. Unless the rule is registered with the IANA, the 376 rule's identification must start with "X-". 377 The server supporting a particular rule MUST report 378 "ACL2=" in the capability list. 380 Rule Semantics: specify how access rights for a mailbox are calculated. 382 Negative rights allowed: specify whether "negative right" identifiers are 383 allowed. 385 Groups allowed: specify whether group identifiers are allowed. 387 Special Identifiers: describe whether any implementation defined 388 aliases are allowed and define their meaning. 390 Contact Information: specify the postal and electronic contact 391 information for the author of the feature. 393 8. Initial Registrations 395 8.1. Registration: UNION access calculation rule 397 Rule Identification: UNION 399 Rule Semantics: the union of the rights granted to 400 the applicable identifiers minus the union of the negative rights. 402 Negative rights allowed: Yes. 404 Groups allowed: Yes, but not required. 406 Special Identifiers: No. 408 Contact Information: c.f., the "Editor's Address" section of this 409 memo 411 8.2. Registration: MOST-SPECIFIC access calculation rule 413 Rule Identification: MOST-SPECIFIC 415 Rule Semantics: the rights granted to the most specific identifier 416 present in the ACL are used, i.e. if the user identifier is present, 417 its ACL is used. If no user identifier is present, but a group that 418 includes this user as a member is present, the group ACL is used. 419 If neither user, nor group identifier is present, but an ACL for 420 a special group "anyone" is present, the ACL for "anyone" is used. 422 Negative rights allowed: No. 424 Groups allowed: Yes, but not required. 426 Special Identifiers: No. 428 Contact Information: c.f., the "Editor's Address" section of this 429 memo 431 9. Security Considerations 433 An implementation must make sure the ACL commands themselves do not 434 give information about mailboxes with appropriately restricted ACL's. 435 For example, a GETACL command on a mailbox for which the user has 436 insufficient rights should not admit the mailbox exists, much less 437 return the mailbox's ACL. 439 10. Other considerations 441 10.1. Compatibility with RFC 2086 443 Any server that prohibits a user name in LOGIN/AUTHENTICATE that starts 444 with "$" MUST report "ACL" capability in addition to a "ACL=..." capability. 446 10.2. Implementation notes 448 Any server implementing an ACL2 extension MUST accurately reflect the current 449 user's rights in FLAGS and PERMANENTFLAGS responses. The server SHOULD issue 450 a MYRIGHTS response code in an untagged OK response as a result of a SELECT 451 or EXAMINE command. 453 11. References 455 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 456 Requirement Levels", RFC 2119, Harvard University, March 1997. 458 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: 459 ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd, 460 November 1997. 462 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 463 4rev1", RFC 2060, University of Washington, December 1996. 465 [UTF-8] Yergeau, F., "UTF-8, a transformation format of IS0 10646", 466 RFC 2279. 468 12. Aknowledgement 470 This document is a revision of the RFC 2086 written by John G. Myers. 472 Editor also appreciate comments received from Mark Crispin, Chris Newman, 473 Cyrus Daboo, Curtis King, Lyndon Nerenberg and other members of IMAPEXT 474 working group. 476 13. Editor's Address 478 Alexey Melnikov 479 mailto: mel@messagingdirect.com 481 ACI WorldWide/MessagingDirect 482 #900 10117 - Jasper Ave. 483 Edmonton, Alberta, T5J 1W8, CANADA 485 14. Full Copyright Statement 487 Copyright (C) The Internet Society 2002. All Rights Reserved. 489 This document and translations of it may be copied and furnished to 490 others, and derivative works that comment on or otherwise explain it 491 or assist in its implementation may be prepared, copied, published 492 and distributed, in whole or in part, without restriction of any 493 kind, provided that the above copyright notice and this paragraph 494 are included on all such copies and derivative works. However, this 495 document itself may not be modified in any way, such as by removing 496 the copyright notice or references to the Internet Society or other 497 Internet organizations, except as needed for the purpose of 498 developing Internet standards in which case the procedures for 499 copyrights defined in the Internet Standards process must be 500 followed, or as required to translate it into languages other than 501 English. 503 The limited permissions granted above are perpetual and will not be 504 revoked by the Internet Society or its successors or assigns. 506 This document and the information contained herein is provided on an 507 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 508 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 509 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 510 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 511 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 513 Appendix A. Changes since RFC 2086 515 1. Changed the charset of "identifier" from US-ASCII to UTF-8. 517 2. Specified that identifiers starting with a dollar sign ("$") are 518 reserved for groups and implementation defined aliases. 520 3. Specified that mailbox deletion is controled by the "x" right and 521 EXPUNGE is controlled by "e" right. 523 4. Clarified that RENAME requires "c" right for the new parent and "x" 524 right for the old name. 526 5. Changed capability name from "ACL" to "ACL2" because changes 2 and 3 527 are not backward compatible with ACL RFC. 529 6. Added "t" right that controls STORE \Deleted. Redefined "d" to be a 530 macro for "e", "x" and "t". 532 7. Added "ACL2=UNION" and "ACL2=MOST-SPECIFIC" capabilities and IANA 533 registration template. 535 8. Specified that "a" right also controls DELETEACL 537 9. Specified that "r" right also controls STATUS 539 10. Specified that "w" controls setting flags other than \Seen and \Deleted 540 on APPEND. Same for "s" and "t" flags. 542 11. Specified that "l" controls SUBSCRIBE/UNSUBSCRIBE. 544 12. Added note about compatibility with RFC 2086 546 13. Added "Implementation Notes" section. 548 14. Updated "References" section.