draft-ietf-imapext-2086upd-05.txt   draft-ietf-imapext-2086upd-06.txt 
Network Working Group A. Melnikov Network Working Group A. Melnikov
Internet Draft Editor Internet Draft Editor
Document: draft-ietf-imapext-2086upd-05.txt April 2005 Document: draft-ietf-imapext-2086upd-06.txt April 2005
Updates: <<3501?>>
Obsoletes: 2086 Obsoletes: 2086
Expires: October 2005 Expires: October 2005
IMAP4 ACL extension IMAP4 ACL extension
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
skipping to change at line 43 skipping to change at line 42
munnari.oz.au. munnari.oz.au.
A revised version of this draft document will be submitted to the RFC A revised version of this draft document will be submitted to the RFC
editor as a Proposed Standard for the Internet Community. Discussion editor as a Proposed Standard for the Internet Community. Discussion
and suggestions for improvement are requested. Distribution of this and suggestions for improvement are requested. Distribution of this
draft is unlimited. draft is unlimited.
Abstract Abstract
The ACL (Access Control List) extension (RFC 2086) of the Internet The ACL (Access Control List) extension (RFC 2086) of the Internet
Message Access Protocol (IMAP4rev1) permits mailbox access control Message Access Protocol (IMAP) permits mailbox access control
lists to be retrieved and manipulated through the IMAP protocol. lists to be retrieved and manipulated through the IMAP protocol.
This document is a revision of the RFC 2086. It defines several new This document is a revision of RFC 2086. It defines several new
access control rights and clarifies which rights are required for access control rights and clarifies which rights are required for
different IMAP commands. different IMAP commands.
1. Conventions Used in this Document 1. Conventions Used in this Document
In examples, "C:" and "S:" indicate lines sent by the client and In examples, "C:" and "S:" indicate lines sent by the client and
server respectively. server respectively.
In all examples "/" character is used as hierarchy separator. In all examples "/" character is used as hierarchy separator.
skipping to change at line 70 skipping to change at line 69
The phrase "ACL server" is just a short cut for saying "IMAP server The phrase "ACL server" is just a short cut for saying "IMAP server
that supports ACL extension as defined in this document". that supports ACL extension as defined in this document".
2. Introduction and Overview 2. Introduction and Overview
The ACL (Access Control List) extension of the Internet Message The ACL (Access Control List) extension of the Internet Message
Access Protocol [IMAP4] permits mailbox access control lists to be Access Protocol [IMAP4] permits mailbox access control lists to be
retrieved and manipulated through the IMAP protocol. retrieved and manipulated through the IMAP protocol.
This document is a revision of the RFC 2086. It tries to clarify This document is a revision of RFC 2086. It tries to clarify
different ambiguities in the RFC 2086, in particular use of UTF-8 different ambiguities in RFC 2086, in particular use of UTF-8
[UTF-8] in identifiers, which rights are required for different IMAP4 [UTF-8] in identifiers, which rights are required for different IMAP4
commands; how READ-WRITE/READ-ONLY response codes are related to ACL. commands; how READ-WRITE/READ-ONLY response codes are related to ACL.
3. Access Control 3. Access Control
The ACL extension is present in any IMAP4 implementation which The ACL extension is present in any IMAP4 implementation which
returns "ACL" as one of the supported capabilities to the CAPABILITY returns "ACL" as one of the supported capabilities to the CAPABILITY
command. command.
A server implementation conformant to this document MUST also return A server implementation conformant to this document MUST also return
skipping to change at line 102 skipping to change at line 101
as identifiers for the corresponding users. Identifiers starting as identifiers for the corresponding users. Identifiers starting
with a dash ("-") are reserved for "negative rights", described with a dash ("-") are reserved for "negative rights", described
below. All other identifier strings are interpreted in an below. All other identifier strings are interpreted in an
implementation-defined manner. implementation-defined manner.
Rights is a string listing a (possibly empty) set of alphanumeric Rights is a string listing a (possibly empty) set of alphanumeric
characters, each character listing a set of operations which is being characters, each character listing a set of operations which is being
controlled. Lowercase letters are reserved for "standard" rights, controlled. Lowercase letters are reserved for "standard" rights,
listed in section 3.1. (Note that for compatibility with deployed listed in section 3.1. (Note that for compatibility with deployed
clients and servers uppercase rights are not allowed). The set of clients and servers uppercase rights are not allowed). The set of
standard rights may only be extended by a standards-track document. standard rights can only be extended by a standards-track document.
Digits are reserved for implementation or site defined rights. Digits are reserved for implementation or site defined rights.
An implementation MAY tie rights together or may force rights to An implementation MAY tie rights together or MAY force rights to
always or never be granted to particular identifiers. For example, always or never be granted to particular identifiers. For example,
in an implementation that uses UNIX mode bits, the rights "swite" are in an implementation that uses UNIX mode bits, the rights "swite" are
tied, the "a" right is always granted to the owner of a mailbox and tied, the "a" right is always granted to the owner of a mailbox and
is never granted to another user. If rights are tied in an is never granted to another user. If rights are tied in an
implementation, the implementation must be conservative in granting implementation, the implementation must be conservative in granting
rights in response to SETACL commands--unless all rights in a tied rights in response to SETACL commands--unless all rights in a tied
set are specified, none of that set should be included in the ACL set are specified, none of that set should be included in the ACL
entry for that identifier. A client may discover the set of rights entry for that identifier. A client can discover the set of rights
which may be granted to a given identifier in the ACL for a given which may be granted to a given identifier in the ACL for a given
mailbox name by using the LISTRIGHTS command. mailbox name by using the LISTRIGHTS command.
It is possible for multiple identifiers in an access control list to It is possible for multiple identifiers in an access control list to
apply to a given user. For apply to a given user. For
example, an ACL may include rights to be granted to the identifier example, an ACL may include rights to be granted to the identifier
matching the user, one or more implementation-defined identifiers matching the user, one or more implementation-defined identifiers
matching groups which include the user, and/or the identifier matching groups which include the user, and/or the identifier
"anyone". How these rights are combined to determine the user's "anyone". How these rights are combined to determine the user's
access is implementation-defined. An implementation may choose, for access is implementation-defined. An implementation may choose, for
example, to use the union of the rights granted to the applicable example, to use the union of the rights granted to the applicable
identifiers. An implementation may instead choose, for example, to identifiers. An implementation may instead choose, for example, to
only use those rights granted to the most specific identifier present only use those rights granted to the most specific identifier present
in the ACL. A client may determine the set of rights granted to the in the ACL. A client can determine the set of rights granted to the
logged-in user for a given mailbox name by using the MYRIGHTS logged-in user for a given mailbox name by using the MYRIGHTS
command. command.
When an identifier in an ACL starts with a dash ("-"), that indicates When an identifier in an ACL starts with a dash ("-"), that indicates
that associated rights are to be removed from the identifier that is that associated rights are to be removed from the identifier that is
prefixed by the dash. This is referred to as a "negative right". prefixed by the dash. This is referred to as a "negative right".
This differs from DELETEACL in that a negative right is added to the This differs from DELETEACL in that a negative right is added to the
ACL, and is a part of the calculation of the rights. ACL, and is a part of the calculation of the rights.
Let's assume that an identifier "fred" refers to a user with login Let's assume that an identifier "fred" refers to a user with login
skipping to change at line 301 skipping to change at line 300
a reasonable restriction. a reasonable restriction.
3.2. Rights defined in RFC 2086. 3.2. Rights defined in RFC 2086.
The "RIGHTS=" capability MUST NOT include any of the rights defined The "RIGHTS=" capability MUST NOT include any of the rights defined
in RFC 2086: "l", "r", "s", "w", "i", "p", "a", "c", "d", and the digits in RFC 2086: "l", "r", "s", "w", "i", "p", "a", "c", "d", and the digits
("0" .. "9"). ("0" .. "9").
4. Access control management commands and responses 4. Access control management commands and responses
Servers, when processing a command that have an identifier Servers, when processing a command that has an identifier
as a parameter (i.e. any of SETACL, DELETEACL and LISTRIGHTS commands), as a parameter (i.e. any of SETACL, DELETEACL and LISTRIGHTS commands),
SHOULD first prepare the received identifier using "SASLprep" profile SHOULD first prepare the received identifier using "SASLprep" profile
[SASLprep] of the "stringprep" algorithm [StringPrep]. If the [SASLprep] of the "stringprep" algorithm [StringPrep]. If the
preparation of the identifier fails or results in an empty string, the preparation of the identifier fails or results in an empty string, the
server MUST refuse to perform the command with a BAD response. server MUST refuse to perform the command with a BAD response.
4.1. SETACL command 4.1. SETACL command
Arguments: mailbox name Arguments: mailbox name
identifier identifier
skipping to change at line 389 skipping to change at line 388
Data: untagged responses: ACL Data: untagged responses: ACL
Result: OK - getacl completed Result: OK - getacl completed
NO - getacl failure: can't get acl NO - getacl failure: can't get acl
BAD - arguments invalid BAD - arguments invalid
The GETACL command returns the access control list for mailbox in The GETACL command returns the access control list for mailbox in
an untagged ACL response. an untagged ACL response.
Some implementations may permit multiple forms of an Some implementations MAY permit multiple forms of an
identifier to reference the same IMAP account. Usually, such identifier to reference the same IMAP account. Usually, such
implementations will have a canonical form that is stored internally. implementations will have a canonical form that is stored internally.
An ACL response caused by an GETACL command MAY include a An ACL response caused by an GETACL command MAY include a
canonicalized form of the identifier which might be canonicalized form of the identifier which might be
different from the one used in the corresponding SETACL command. different from the one used in the corresponding SETACL command.
Example: C: A002 GETACL INBOX Example: C: A002 GETACL INBOX
S: * ACL INBOX Fred rwipsldexta S: * ACL INBOX Fred rwipsldexta
S: A002 OK Getacl complete S: A002 OK Getacl complete
skipping to change at line 412 skipping to change at line 411
Arguments: mailbox name Arguments: mailbox name
identifier identifier
Data: untagged responses: LISTRIGHTS Data: untagged responses: LISTRIGHTS
Result: OK - listrights completed Result: OK - listrights completed
NO - listrights failure: can't get rights list NO - listrights failure: can't get rights list
BAD - arguments invalid BAD - arguments invalid
The LISTRIGHTS command takes a mailbox name and an identifier and The LISTRIGHTS command takes a mailbox name and an identifier and
returns information about what rights may be granted to the identifier returns information about what rights can be granted to the identifier
in the ACL for the mailbox. in the ACL for the mailbox.
Some implementations may permit multiple forms of an Some implementations MAY permit multiple forms of an
identifier to reference the same IMAP account. Usually, such identifier to reference the same IMAP account. Usually, such
implementations will have a canonical form that is stored internally. implementations will have a canonical form that is stored internally.
A LISTRIGHTS response caused by a LISTRIGHTS command MUST always A LISTRIGHTS response caused by a LISTRIGHTS command MUST always
return the same form of an identifier as specified return the same form of an identifier as specified
by the client. This is to allow the client to correlate the response by the client. This is to allow the client to correlate the response
with the command. with the command.
Example: C: a001 LISTRIGHTS ~/Mail/saved smith Example: C: a001 LISTRIGHTS ~/Mail/saved smith
S: * LISTRIGHTS ~/Mail/saved smith la r swicdkxte S: * LISTRIGHTS ~/Mail/saved smith la r swicdkxte
S: a001 OK Listrights completed S: a001 OK Listrights completed
skipping to change at line 477 skipping to change at line 476
required rights required rights
list of optional rights list of optional rights
The LISTRIGHTS response occurs as a result of a LISTRIGHTS The LISTRIGHTS response occurs as a result of a LISTRIGHTS
command. The first two strings are the mailbox name and identifier command. The first two strings are the mailbox name and identifier
for which this rights list applies. Following the identifier is a for which this rights list applies. Following the identifier is a
string containing the (possibly empty) set of rights the string containing the (possibly empty) set of rights the
identifier will always be granted in the mailbox. identifier will always be granted in the mailbox.
Following this are zero or more strings each containing a set of Following this are zero or more strings each containing a set of
rights the identifier may be granted in the mailbox. Rights rights the identifier can be granted in the mailbox. Rights
mentioned in the same string are tied together. The server MUST mentioned in the same string are tied together. The server MUST
either grant all tied rights to the identifier in the mailbox or either grant all tied rights to the identifier in the mailbox or
grant none. Section 3.1.1 details additional server requirements grant none. Section 3.1.1 details additional server requirements
related to handling of the virtual "d" and "c" rights. related to handling of the virtual "d" and "c" rights.
The same right MUST NOT be listed more than once in the LISTRIGHTS The same right MUST NOT be listed more than once in the LISTRIGHTS
command. command.
4.8. MYRIGHTS response 4.8. MYRIGHTS response
skipping to change at line 781 skipping to change at line 780
it doesn't understand. it doesn't understand.
6.2. Mapping of ACL rights to READ-WRITE and READ-ONLY response codes 6.2. Mapping of ACL rights to READ-WRITE and READ-ONLY response codes
A particular ACL server implementation MAY allow "shared multiuser A particular ACL server implementation MAY allow "shared multiuser
access" to some mailboxes. "Shared multiuser access" to a mailbox means access" to some mailboxes. "Shared multiuser access" to a mailbox means
that multiple different users are able to access the same mailbox, that multiple different users are able to access the same mailbox,
if they have proper access rights. "Shared multiuser access" to the if they have proper access rights. "Shared multiuser access" to the
mailbox doesn't mean that the ACL for the mailbox is currently set mailbox doesn't mean that the ACL for the mailbox is currently set
to allow access by multiple users. Let's denote a "shared multiuser to allow access by multiple users. Let's denote a "shared multiuser
write access" as a "shared multiuser access" when a user may be write access" as a "shared multiuser access" when a user can be
granted flag modification rights (any of "w", "s" or "t"). granted flag modification rights (any of "w", "s" or "t").
Section 5 describes which rights are required for modifying different flags. Section 5 describes which rights are required for modifying different flags.
If the ACL server implements some flags as shared for a mailbox (i.e., If the ACL server implements some flags as shared for a mailbox (i.e.,
the ACL for the mailbox MAY be set up so that changes to those flags are the ACL for the mailbox MAY be set up so that changes to those flags are
visible to another user), let's call the set of rights associated with these visible to another user), let's call the set of rights associated with these
flags (as described in Section 5) for that mailbox collectively as flags (as described in Section 5) for that mailbox collectively as
"shared flag rights". Note that "shared flag rights" set MAY be different "shared flag rights". Note that "shared flag rights" set MAY be different
for different mailboxes. for different mailboxes.
skipping to change at line 823 skipping to change at line 822
(because system flag \Draft requires "w" right). (because system flag \Draft requires "w" right).
The server MUST include a READ-ONLY response code in the tagged OK response to The server MUST include a READ-ONLY response code in the tagged OK response to
a SELECT command if none of the following rights is granted to the a SELECT command if none of the following rights is granted to the
current user: current user:
"i", "e" and "shared flag rights"*. "i", "e" and "shared flag rights"*.
The server SHOULD include a READ-WRITE response code in the tagged OK response The server SHOULD include a READ-WRITE response code in the tagged OK response
if at least one of the "i", "e" or "shared flag rights"* is granted to the if at least one of the "i", "e" or "shared flag rights"* is granted to the
current user. current user.
* - Note that a future extension to this document may extend the list of * - Note that a future extension to this document can extend the list of
rights that causes the server to return the READ-WRITE response code. rights that causes the server to return the READ-WRITE response code.
Example 1 (continued): The user that has "lrs" rights for the mailbox Example 1 (continued): The user that has "lrs" rights for the mailbox
"banan". The server returns READ-ONLY response "banan". The server returns READ-ONLY response
code on SELECT, as none of "iewt" rights is code on SELECT, as none of "iewt" rights is
granted to the user. granted to the user.
Example 2 (continued): The user that has "rit" rights for the mailbox Example 2 (continued): The user that has "rit" rights for the mailbox
"apple". The server returns READ-WRITE response "apple". The server returns READ-WRITE response
code on SELECT, as the user has "i" right. code on SELECT, as the user has "i" right.
skipping to change at line 854 skipping to change at line 853
that the user has no permission to LIST, the server would respond to that that the user has no permission to LIST, the server would respond to that
request with the same error that would be used if the mailbox did not exist, request with the same error that would be used if the mailbox did not exist,
thus revealing no existence information, much less the mailbox's ACL. thus revealing no existence information, much less the mailbox's ACL.
IMAP clients implementing ACL that are able to modify ACLs SHOULD IMAP clients implementing ACL that are able to modify ACLs SHOULD
warn a user that wants to give full access (or even just the "a" right) warn a user that wants to give full access (or even just the "a" right)
to the special identifier "anyone". to the special identifier "anyone".
8. Formal Syntax 8. Formal Syntax
Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4]. Formal syntax is defined using ABNF [ABNF], extending the ABNF rules
Non-terminals referenced but not defined below are as defined by in section 9 of [IMAP]. The IMAP4 ABNF should be imported first before
[IMAP4]. attempting to validate these rules.
Except as noted otherwise, all alphabetic characters are Except as noted otherwise, all alphabetic characters are
case-insensitive. The use of upper or lower case characters to case-insensitive. The use of upper or lower case characters to
define token strings is for editorial clarity only. Implementations define token strings is for editorial clarity only. Implementations
MUST accept these strings in a case-insensitive fashion. MUST accept these strings in a case-insensitive fashion.
LOWER-ALPHA = %x61-7A ;; a-z LOWER-ALPHA = %x61-7A ;; a-z
acl-data = "ACL" SP mailbox *(SP identifier SP acl-data = "ACL" SP mailbox *(SP identifier SP
rights) rights)
capability =/ rights-capa capability =/ rights-capa
;;capability is defined in [IMAP4]
command-auth =/ setacl / deleteacl / getacl / command-auth =/ setacl / deleteacl / getacl /
listrights / myrights listrights / myrights
;;command-auth is defined in [IMAP4]
deleteacl = "DELETEACL" SP mailbox SP identifier deleteacl = "DELETEACL" SP mailbox SP identifier
getacl = "GETACL" SP mailbox getacl = "GETACL" SP mailbox
identifier = astring identifier = astring
listrights = "LISTRIGHTS" SP mailbox SP identifier listrights = "LISTRIGHTS" SP mailbox SP identifier
listrights-data = "LISTRIGHTS" SP mailbox SP identifier listrights-data = "LISTRIGHTS" SP mailbox SP identifier
SP rights *(SP rights) SP rights *(SP rights)
mailbox-data =/ acl-data / listrights-data / myrights-data mailbox-data =/ acl-data / listrights-data / myrights-data
;;mailbox-data is defined in [IMAP4]
mod-rights = astring mod-rights = astring
;; +rights to add, -rights to remove ;; +rights to add, -rights to remove
;; rights to replace ;; rights to replace
myrights = "MYRIGHTS" SP mailbox myrights = "MYRIGHTS" SP mailbox
myrights-data = "MYRIGHTS" SP mailbox SP rights myrights-data = "MYRIGHTS" SP mailbox SP rights
new-rights = 1*LOWER-ALPHA new-rights = 1*LOWER-ALPHA
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/