draft-ietf-imapext-2086upd-03.txt   draft-ietf-imapext-2086upd-04.txt 
IMAPEXT Working Group A. Melnikov Network Working Group A. Melnikov
Internet Draft Editor Internet Draft Editor
Document: draft-ietf-imapext-2086upd-03.txt February 2005 Document: draft-ietf-imapext-2086upd-04.txt March 2005
Updates: <<3501?>> Updates: <<3501?>>
Obsoletes: 2086 Obsoletes: 2086
Expires: August 2005 Expires: September 2005
IMAP4 ACL extension IMAP4 ACL extension
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, or 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, will be disclosed, and any of which I become aware will be disclosed,
in accordance with RFC 3668. in accordance with RFC 3668.
Internet Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its Areas, and its Working Groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet other groups may also distribute working documents as Internet-Drafts.
Drafts. Internet Drafts are draft documents valid for a maximum of
six months. Internet Drafts may be updated, replaced, or obsoleted Internet-Drafts are draft documents valid for a maximum of six
by other documents at any time. It is not appropriate to use months and may be updated, replaced, or obsoleted by other documents
Internet Drafts as reference material or to cite them other than as at any time. It is inappropriate to use Internet-Drafts as reference
``work in progress''. material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or
munnari.oz.au. munnari.oz.au.
skipping to change at line 62 skipping to change at line 62
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.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [KEYWORDS]. document are to be interpreted as described in RFC 2119 [KEYWORDS].
The phrase "ACL server" is just a short cut for saying "IMAP server
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 Access The ACL (Access Control List) extension of the Internet Message
Protocol [IMAP4] permits mailbox access control lists to be retrieved Access Protocol [IMAP4] permits mailbox access control lists to be
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 the RFC 2086. It tries to clarify
different ambiguities in the RFC 2086, in particular use of UTF-8 different ambiguities in the 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
rights (see below) not defined in section 3.2 in the "RIGHTS=" rights (see below) not defined in section 3.2 in the "RIGHTS="
capability. capability.
An access control list is a set of <identifier,rights> pairs. An access control list is a set of <identifier,rights> pairs.
An ACL applies to a mailbox name. An ACL applies to a mailbox name.
Identifier is a UTF-8 [UTF-8] string. The identifier "anyone" is reserved Identifier is a UTF-8 [UTF-8] string. The identifier "anyone" is
to refer to the universal identity (all authentications, including reserved to refer to the universal identity (all authentications,
anonymous). All user name strings accepted by the LOGIN or including anonymous). All user name strings accepted by the LOGIN or
AUTHENTICATE commands to authenticate to the IMAP server are reserved AUTHENTICATE commands to authenticate to the IMAP server are reserved
as identifiers for the corresponding users. Identifiers starting with as identifiers for the corresponding users. Identifiers starting
a dash ("-") are reserved for "negative rights", described below. with a dash ("-") are reserved for "negative rights", described
All other identifier strings are interpreted in an implementation- below. All other identifier strings are interpreted in an
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 clients listed in section 3.1. (Note that for compatibility with deployed
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 may 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 may 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 (or other authentication identity). 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 may determine the set of rights granted to the
logged-in user for a given mailbox name by using the MYRIGHTS command. logged-in user for a given mailbox name by using the MYRIGHTS
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 "fred". Let's assume that an identifier "fred" refers to a user with login
If the identifier "-fred" is granted the "w" right, "fred". If the identifier "-fred" is granted the "w" right,
that indicates that the "w" right is to be removed from users matching that indicates that the "w" right is to be removed from users
the identifier "fred", even though the user "fred" might have matching the identifier "fred", even though the user "fred" might
the "w" right as a consequence of some other identifier in the ACL. have the "w" right as a consequence of some other identifier in
A DELETEACL of "fred" simply deletes the identifier "fred" the ACL. A DELETEACL of "fred" simply deletes the identifier "fred"
from the ACL; it does not affect any rights that the user "fred" from the ACL; it does not affect any rights that the user "fred"
may get from another entry in the ACL, in particular it doesn't affect may get from another entry in the ACL, in particular it doesn't
rights granted to the identifier "-fred". affect rights granted to the identifier "-fred".
Server implementations are not required to support "negative right" Server implementations are not required to support "negative right"
identifiers. identifiers.
3.1. Standard rights 3.1. Standard rights
The currently defined standard rights are (note that the list below The currently defined standard rights are (note that the list below
doesn't list all commands that use a particular right): doesn't list all commands that use a particular right):
l - lookup (mailbox is visible to LIST/LSUB commands, SUBSCRIBE mailbox) l - lookup (mailbox is visible to LIST/LSUB commands, SUBSCRIBE mailbox)
r - read (SELECT the mailbox, perform STATUS) r - read (SELECT the mailbox, perform STATUS)
s - keep seen/unseen information across sessions (set or clear \SEEN flag s - keep seen/unseen information across sessions (set or clear \SEEN flag
via STORE, APPEND or COPY) via STORE, also set \SEEN during APPEND/COPY/FETCH BODY[...])
w - write (set or clear flags other than \SEEN and \DELETED via STORE, w - write (set or clear flags other than \SEEN and \DELETED via STORE,
APPEND or COPY) also set them during APPEND/COPY)
i - insert (perform APPEND, COPY into mailbox) i - insert (perform APPEND, COPY into mailbox)
p - post (send mail to submission address for mailbox, p - post (send mail to submission address for mailbox,
not enforced by IMAP4 itself) not enforced by IMAP4 itself)
k - create mailboxes (CREATE new sub-mailboxes in any k - create mailboxes (CREATE new sub-mailboxes in any
implementation-defined hierarchy, parent mailbox for the new implementation-defined hierarchy, parent mailbox for the new
mailbox name in RENAME) mailbox name in RENAME)
x - delete mailbox (DELETE mailbox, old mailbox name in RENAME) x - delete mailbox (DELETE mailbox, old mailbox name in RENAME)
t - delete messages (set or clear \DELETED flag via STORE, set \DELETED flag t - delete messages (set or clear \DELETED flag via STORE, set \DELETED flag
during APPEND/COPY) during APPEND/COPY)
e - perform EXPUNGE and expunge as a part of CLOSE. e - perform EXPUNGE and expunge as a part of CLOSE.
skipping to change at line 195 skipping to change at line 199
(It is not an error for a client to specify both the "d" right and (It is not an error for a client to specify both the "d" right and
one or more members of the "delete" right, but the effect is no different one or more members of the "delete" right, but the effect is no different
than if just the "d" right or all members of the "delete" right had been than if just the "d" right or all members of the "delete" right had been
specified). specified).
When any of the "delete" member rights is set in a list of When any of the "delete" member rights is set in a list of
rights, the server MUST also include the "d" right when returning rights, the server MUST also include the "d" right when returning
the list in a MYRIGHTS or ACL response. This is so to enable older clients the list in a MYRIGHTS or ACL response. This is so to enable older clients
conforming to RFC 2086 to work with newer servers. (*) conforming to RFC 2086 to work with newer servers. (*)
Example: C: A001 SETACL INBOX.Drafts David lrswida Example: C: A001 SETACL INBOX/Drafts David lrswida
S: A001 OK Setacl complete S: A001 OK Setacl complete
The client has specified the "d" right in the SETACL command above and it The client has specified the "d" right in the SETACL command above and it
expands to "et" on the server: expands to "et" on the server:
C: A002 GETACL INBOX.Drafts C: A002 GETACL INBOX/Drafts
S: * ACL INBOX Fred rwipslxetda David lrswideta S: * ACL INBOX Fred rwipslxetda David lrswideta
S: A002 OK Getacl complete S: A002 OK Getacl complete
If the authentication identifier specified in the LISTRIGHTS command can be If the identifier specified in the LISTRIGHTS command can be
granted any of the "delete" member rights to access a mailbox, then the server granted any of the "delete" member rights on a mailbox, then the server
MUST include the "d" right in the corresponding LISTRIGHTS response. (*) MUST include the "d" right in the corresponding LISTRIGHTS response. (*)
If the member rights aren't tied to non-member rights, then the "d" right If the member rights aren't tied to non-member rights, then the "d" right
is returned by itself in the LISTRIGHTS response. If any of the member rights is returned by itself in the LISTRIGHTS response. If any of the member rights
needs to be tied to one (or more) non-member right, then the "d" right and all needs to be tied to one (or more) non-member right, then the "d" right and all
of the member rights need to be tied to the same non-member right(s) (**). of the member rights need to be tied to the same non-member right(s) (**).
If a client includes the "c" right in a rights list, then it MUST be If a client includes the "c" right in a rights list, then it MUST be
treated as if the client had included every member of the "create" right. treated as if the client had included every member of the "create" right.
(It is not an error for a client to specify both the "c" right and (It is not an error for a client to specify both the "c" right and
one or more members of the "create" right, but the effect is no different one or more members of the "create" right, but the effect is no different
than if just the "c" right or all members of the "create" right had been than if just the "c" right or all members of the "create" right had been
specified). specified).
When any of the "create" member rights is set in a list of When any of the "create" member rights is set in a list of
rights, the server MUST also include the "c" right when returning rights, the server MUST also include the "c" right when returning
the list in a MYRIGHTS or ACL response. This is so to enable older clients the list in a MYRIGHTS or ACL response. This is so to enable older clients
conforming to RFC 2086 to work with newer servers. (*) conforming to RFC 2086 to work with newer servers. (*)
Example: C: A003 SETACL INBOX.Drafts Byron lrswikda Example: C: A003 SETACL INBOX/Drafts Byron lrswikda
S: A001 OK Setacl complete S: A001 OK Setacl complete
C: A002 GETACL INBOX.Drafts C: A002 GETACL INBOX/Drafts
S: * ACL INBOX Fred rwipslxeta Byron lrswikcdeta S: * ACL INBOX Fred rwipslxeta Byron lrswikcdeta
S: A002 OK Getacl complete S: A002 OK Getacl complete
The client has specified the "d" right in the SETACL command above and it The client has specified the "d" right in the SETACL command above and it
expands to "et" on the server: As the client has specified the "k" right expands to "et" on the server: As the client has specified the "k" right
(which is a member of the "c" right), the server also returns the "c" right. (which is a member of the "c" right), the server also returns the "c" right.
If the authentication identifier specified in the LISTRIGHTS command can be If the identifier specified in the LISTRIGHTS command can be
granted any of the "create" member rights to access a mailbox, then the server granted any of the "create" member rights on a mailbox, then the server
MUST include the "c" right in the corresponding LISTRIGHTS response. (*) MUST include the "c" right in the corresponding LISTRIGHTS response. (*)
If the member rights aren't tied to non-member rights, then the "c" right If the member rights aren't tied to non-member rights, then the "c" right
is returned by itself in the LISTRIGHTS response. If any of the member rights is returned by itself in the LISTRIGHTS response. If any of the member rights
needs to be tied to one (or more) non-member right, then the "c" right and all needs to be tied to one (or more) non-member right, then the "c" right and all
of the member rights need to be tied to the same non-member right(s) (**). of the member rights need to be tied to the same non-member right(s) (**).
Example: The server that ties the rights as follows Example: The server that ties the rights as follows
lr s w i p k x t lr s w i p k x t
and c=k and c=k
will return: will return:
S: * LISTRIGHTS archive.imap anyone "" lr s w i p k x t c d S: * LISTRIGHTS archive/imap anyone "" lr s w i p k x t c d
Example: The server that ties the rights as follows Example: The server that ties the rights as follows
lr s w i p k xte lr s w i p k xte
and c=k and c=k
will return: will return:
S: * LISTRIGHTS archive.imap anyone "" lr s w i p k xte c d S: * LISTRIGHTS archive/imap anyone "" lr s w i p k xte c d
Example: The server that ties the rights as follows Example: The server that ties the rights as follows
lr s w i p k x te lr s w i p k x te
and c=k and c=k
will return: will return:
S: * LISTRIGHTS archive.imap anyone "" lr s w i p k c x te d S: * LISTRIGHTS archive/imap anyone "" lr s w i p k c x te d
Example: The server that ties the rights as follows Example: The server that ties the rights as follows
lr swte i p k x lr swte i p k x
and c=kx and c=kx
will return: will return:
S: * LISTRIGHTS archive.imap anyone "" lr swted i p k x c S: * LISTRIGHTS archive/imap anyone "" lr swted i p k x c
(*) Clients conforming to this document MUST ignore the virtual "d" and "c" (*) Clients conforming to this document MUST ignore the virtual "d" and "c"
rights in MYRIGHTS, ACL and LISTRIGHTS responses. rights in MYRIGHTS, ACL and LISTRIGHTS responses.
(**) The IMAPEXT Working Group has debated this issue in great length (**) The IMAPEXT Working Group has debated this issue in great length
and after reviewing existing ACL implementations concluded that this is and after reviewing existing ACL implementations concluded that this is
a reasonable restriction. a reasonable restriction.
3.2. Rights defined in RFC 2086. 3.2. Rights defined in RFC 2086.
For convenience, this section lists the rights which were defined in The "RIGHTS=" capability MUST NOT include any of the rights defined
the RFC 2086: in RFC 2086: "l", "r", "s", "w", "i", "p", "a", "c", "d", and the digits
"l", "r", "s", "w", "i", "p", "a", "c", "d" and digit rights
("0" .. "9"). ("0" .. "9").
The listed rights MUST NOT be returned in the "RIGHTS=" capability
string.
4. Access control management commands and responses 4. Access control management commands and responses
Servers, when processing a command that have an authentication identifier Servers, when processing a command that have 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
authentication identifier identifier
access right modification access right modification
Data: no specific data for this command Data: no specific data for this command
Result: OK - setacl completed Result: OK - setacl completed
NO - setacl failure: can't set acl NO - setacl failure: can't set acl
BAD - arguments invalid BAD - arguments invalid
The SETACL command changes the access control list on the The SETACL command changes the access control list on the
specified mailbox so that the specified identifier is granted specified mailbox so that the specified identifier is granted
skipping to change at line 338 skipping to change at line 338
to any existing rights for the identifier. If the string starts to any existing rights for the identifier. If the string starts
with a minus, the following rights are removed from any existing with a minus, the following rights are removed from any existing
rights for the identifier. If the string does not start with a rights for the identifier. If the string does not start with a
plus or minus, the rights replace any existing rights for the plus or minus, the rights replace any existing rights for the
identifier. identifier.
Note that an unrecognized right MUST cause the command to return Note that an unrecognized right MUST cause the command to return
the BAD response. In particular, server MUST NOT silently ignore the BAD response. In particular, server MUST NOT silently ignore
unrecognized rights. unrecognized rights.
Example: C: A001 SETACL INBOX.Drafts Chris lrswicda Example: C: A001 GETACL INBOX/Drafts
S: A001 OK Setacl complete S: * ACL INBOX/Drafts Fred rwipslxetad Chris lrswi
S: A001 OK Getacl complete
C: A002 SETACL INBOX/Drafts Chris +cda
S: A002 OK Setacl complete
C: A003 GETACL INBOX/Drafts
S: * ACL INBOX/Drafts Fred rwipslxetad Chris lrswicdakxet
S: A003 OK Getacl complete
C: A035 SETACL INBOX.Drafts John lrQswicda C: A035 SETACL INBOX/Drafts John lrQswicda
S: A035 BAD Uppercase rights are not allowed S: A035 BAD Uppercase rights are not allowed
C: A036 SETACL INBOX.Drafts John lrqswicda C: A036 SETACL INBOX/Drafts John lrqswicda
S: A036 BAD The q right is not supported S: A036 BAD The q right is not supported
4.2. DELETEACL command 4.2. DELETEACL command
Arguments: mailbox name Arguments: mailbox name
authentication identifier identifier
Data: no specific data for this command Data: no specific data for this command
Result: OK - deleteacl completed Result: OK - deleteacl completed
NO - deleteacl failure: can't delete acl NO - deleteacl failure: can't delete acl
BAD - arguments invalid BAD - arguments invalid
The DELETEACL command removes any <identifier,rights> pair for the The DELETEACL command removes any <identifier,rights> pair for the
specified identifier from the access control list for the specified specified identifier from the access control list for the specified
mailbox. mailbox.
Example: C: B001 GETACL INBOX Example: C: B001 GETACL INBOX
S: * ACL INBOX Fred rwipslxeta -Fred wet $team w S: * ACL INBOX Fred rwipslxetad -Fred wetd $team w
S: B001 OK Getacl complete S: B001 OK Getacl complete
C: B002 DELETEACL INBOX Fred C: B002 DELETEACL INBOX Fred
S: B002 OK Deleteacl complete S: B002 OK Deleteacl complete
C: B003 GETACL INBOX C: B003 GETACL INBOX
S: * ACL INBOX -Fred wet $team w S: * ACL INBOX -Fred wetd $team w
S: B003 OK Getacl complete S: B003 OK Getacl complete
4.3. GETACL command 4.3. GETACL command
Arguments: mailbox name Arguments: mailbox name
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 authentication 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 authentication 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
4.4. LISTRIGHTS command 4.4. LISTRIGHTS command
Arguments: mailbox name Arguments: mailbox name
authentication 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 may 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 authentication 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 authentication 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
Example: C: a005 LISTRIGHTS archive.imap anyone Example: C: a005 LISTRIGHTS archive/imap anyone
S: * LISTRIGHTS archive.imap anyone "" l r s w i p k x t S: * LISTRIGHTS archive.imap anyone "" l r s w i p k x t
e c d a 0 1 2 3 4 5 6 7 8 9 e c d a 0 1 2 3 4 5 6 7 8 9
S: a005 Listrights successful S: a005 Listrights successful
4.5. MYRIGHTS command 4.5. MYRIGHTS command
Arguments: mailbox name Arguments: mailbox name
Data: untagged responses: MYRIGHTS Data: untagged responses: MYRIGHTS
skipping to change at line 473 skipping to change at line 479
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 may be granted in the mailbox. Rights
mentioned in the same string are tied together--either all must be mentioned in the same string are tied together. The server MUST
granted to the identifier in the mailbox or none may be granted. either grant all tied rights to the identifier in the mailbox or
Section 3.1.1 details additional server requirements related to handling grant none. Section 3.1.1 details additional server requirements
of the virtual "d" and "c" rights. related to handling of the virtual "d" and "c" rights.
The same right may 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
Data: mailbox name Data: mailbox name
rights rights
The MYRIGHTS response occurs as a result of a MYRIGHTS command. The MYRIGHTS response occurs as a result of a MYRIGHTS command.
The first string is the mailbox name for which these rights apply. The first string is the mailbox name for which these rights apply.
The second string is the set of rights that the client has. The second string is the set of rights that the client has.
Section 3.1.1 details additional server requirements related to handling Section 3.1.1 details additional server requirements related to handling
of the virtual "d" and "c" rights. of the virtual "d" and "c" rights.
5. Rights required to perform different IMAP4rev1 commands 5. Rights required to perform different IMAP4rev1 commands
Before executing a command an ACL compliant server must check which rights Before executing a command an ACL compliant server MUST check which rights
are required to perform it. This section groups command by functions are required to perform it. This section groups command by functions
they perform and list the rights required. It also gives the detailed they perform and list the rights required. It also gives the detailed
description of any special processing required. description of any special processing required.
For the purpose of this section the UID counterpart of a command is For the purpose of this section the UID counterpart of a command is
considered to be the same command, e.g. both UID COPY and COPY commands considered to be the same command, e.g. both UID COPY and COPY commands
require the same set of rights. require the same set of rights.
The table below summarizes different rights or their combinations that are The table below summarizes different rights or their combinations that are
required in order to perform different IMAP operations. As it is not always required in order to perform different IMAP operations. As it is not always
possible to express complex right checking and interactions, the description possible to express complex right checking and interactions, the description
after the table should be used as the primary reference. after the table should be used as the primary reference.
+---------------------+---+---+---+---+---+---+---+---+---+---+-----+------+ +---------------------+---+---+---+---+---+---+---+---+---+---+-----+------+
| Operations\Rights | l | r | s | w | i | k | x | t | e | a | Any | None | | Operations\Rights | l | r | s | w | i | k | x | t | e | a | Any | None |
+---------------------+---+---+---+---+---+---+---+---+---+---+-----+------+ +---------------------+---+---+---+---+---+---+---+---+---+---+-----+------+
| commands in authenticated state |
+--------------------------------------------------------------------------+
| LIST | + | | | | | | | | | | | | | LIST | + | | | | | | | | | | | |
| SUBSCRIBE | * | | | | | | | | | | | * | | SUBSCRIBE | * | | | | | | | | | | | * |
| UNSUBSCRIBE | | | | | | | | | | | | + | | UNSUBSCRIBE | | | | | | | | | | | | + |
| LSUB | * | | | | | | | | | | | * | | LSUB | * | | | | | | | | | | | * |
| CREATE (for parent) | | | | | | + | | | | | | | | CREATE (for parent) | | | | | | + | | | | | | |
| DELETE | | | | | | | + | ? | ? | | | | | DELETE | | | | | | | + | ? | ? | | | |
| RENAME | | | | | | + | + | | | | | | | RENAME | | | | | | + | + | | | | | |
| COPY/APPEND | | | ? | ? | + | | | ? | | | | |
| EXPUNGE/CLOSE | | | | | | | | | + | | | |
|SELECT/EXAMINE/STATUS| | + | | | | | | | | | | | |SELECT/EXAMINE/STATUS| | + | | | | | | | | | | |
| FETCH | | | ? | | | | | | | | | |
| STORE flags | | | ? | ? | | | | ? | | | | |
| SETACL/DELETEACL | | | | | | | | | | + | | | | SETACL/DELETEACL | | | | | | | | | | + | | |
| GETACL/LISTRIGHTS | | | | | | | | | | + | | | | GETACL/LISTRIGHTS | | | | | | | | | | + | | |
| MYRIGHTS | | | | | | | | | | | + | | | MYRIGHTS | | | | | | | | | | | + | |
| APPEND | | | ? | ? | + | | | ? | | | | |
+--------------------------------------------------------------------------+
| commands in selected state |
+--------------------------------------------------------------------------+
| APPEND | | | ? | ? | + | | | ? | | | | |
| EXPUNGE/CLOSE | | | | | | | | | + | | | |
| FETCH | | | ? | | | | | | | | | |
| STORE flags | | | ? | ? | | | | ? | | | | |
+---------------------+---+---+---+---+---+---+---+---+---+---+-----+------+ +---------------------+---+---+---+---+---+---+---+---+---+---+-----+------+
Note: for all commands in the selected state the "r" is implied, because
it is required to SELECT/EXAMINE a mailbox. Servers are not required
to check presence of the "r" right once a mailbox is successfully
selected.
Legend: Legend:
+ - The right is required + - The right is required
* - Only one of the rights marked with * is required (see description below) * - Only one of the rights marked with * is required (see description below)
? - The right is optional (see description below) ? - The right is OPTIONAL (see description below)
"Any" - at least one of the "l", "r", "i", "k", "x", "a" rights is "Any" - at least one of the "l", "r", "i", "k", "x", "a" rights is
required required
"None" - No rights required to perform the command "None" - No rights required to perform the command
Listing and subscribing/unsubscribing mailboxes: Listing and subscribing/unsubscribing mailboxes:
LIST - "l" right is required. LIST - "l" right is required. However, unlike other commands (e.g. SELECT)
the server MUST NOT return a NO response if it can't list a mailbox.
Note that if the user has "l" right to a mailbox "A/B", but not to its parent Note that if the user has "l" right to a mailbox "A/B", but not to its parent
mailbox "A", the LIST command should behave as if the mailbox "A" doesn't exist, mailbox "A", the LIST command should behave as if the mailbox "A" doesn't exist,
for example: for example:
C: A777 LIST "" * C: A777 LIST "" *
S: * LIST (\NoInferiors) "/" "A/B" S: * LIST (\NoInferiors) "/" "A/B"
S: * LIST () "/" "C" S: * LIST () "/" "C"
S: * LIST (\NoInferiors) "/" "C/D" S: * LIST (\NoInferiors) "/" "C/D"
S: A777 OK LIST completed S: A777 OK LIST completed
SUBSCRIBE - "l" right is required only if the server checks for mailbox existence SUBSCRIBE - "l" right is required only if the server checks for mailbox existence
when performing SUBSCRIBE. when performing SUBSCRIBE.
UNSUBSCRIBE - no rights required to perform this operation. UNSUBSCRIBE - no rights required to perform this operation.
LSUB - "l" right is required only if the server checks for mailbox existence when LSUB - "l" right is required only if the server checks for mailbox existence when
performing SUBSCRIBE. performing SUBSCRIBE. However, unlike other commands (e.g. SELECT)
the server MUST NOT return a NO response if it can't list a subscribed
mailbox.
Mailbox management: Mailbox management:
CREATE - "k" right on a nearest existing parent mailbox. When a new CREATE - "k" right on a nearest existing parent mailbox. When a new
mailbox is created it SHOULD inherit the ACL from the parent mailbox is created it SHOULD inherit the ACL from the parent
mailbox (if one exists) in the defined hierarchy. mailbox (if one exists) in the defined hierarchy.
DELETE - "x" right on the mailbox. Note that some servers don't allow DELETE - "x" right on the mailbox. Note that some servers don't allow
to delete a non-empty mailbox. If this is the case, the user to delete a non-empty mailbox. If this is the case, the user
would also need "r", "e" and "t" rights, in order to open the would also need "r", "e" and "t" rights, in order to open the
mailbox and empty it. mailbox and empty it.
skipping to change at line 699 skipping to change at line 718
S: * OK [UNSEEN 12] Message 12 is first unseen S: * OK [UNSEEN 12] Message 12 is first unseen
S: * OK [UIDVALIDITY 3857529045] UIDs valid S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * OK [UIDNEXT 4392] Predicted next UID S: * OK [UIDNEXT 4392] Predicted next UID
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Seen \Answered \Flagged \*)] Limited S: * OK [PERMANENTFLAGS (\Seen \Answered \Flagged \*)] Limited
S: A142 OK [READ-WRITE] SELECT completed S: A142 OK [READ-WRITE] SELECT completed
C: A143 MYRIGHTS INBOX C: A143 MYRIGHTS INBOX
S: * MYRIGHTS INBOX lrwis S: * MYRIGHTS INBOX lrwis
S: A143 OK completed S: A143 OK completed
Note that in order to get better performance the client may pipeline Note that in order to get better performance the client MAY pipeline
SELECT and MYRIGHTS commands: SELECT and MYRIGHTS commands:
C: A142 SELECT INBOX C: A142 SELECT INBOX
C: A143 MYRIGHTS INBOX C: A143 MYRIGHTS INBOX
S: * 172 EXISTS S: * 172 EXISTS
S: * 1 RECENT S: * 1 RECENT
S: * OK [UNSEEN 12] Message 12 is first unseen S: * OK [UNSEEN 12] Message 12 is first unseen
S: * OK [UIDVALIDITY 3857529045] UIDs valid S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * OK [UIDNEXT 4392] Predicted next UID S: * OK [UIDNEXT 4392] Predicted next UID
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
skipping to change at line 724 skipping to change at line 743
Servers MAY cache the rights a user has on a mailbox when the mailbox Servers MAY cache the rights a user has on a mailbox when the mailbox
is selected, so that if a client's rights on a mailbox are changed with is selected, so that if a client's rights on a mailbox are changed with
SETACL or DELETEACL, commands specific to the selected state (e.g., STORE, SETACL or DELETEACL, commands specific to the selected state (e.g., STORE,
EXPUNGE) might not reflect the changed rights until the mailbox is EXPUNGE) might not reflect the changed rights until the mailbox is
re-selected. If the server checks the rights on each command, then it SHOULD re-selected. If the server checks the rights on each command, then it SHOULD
send FLAGS and PERMANENTFLAGS responses if they have changed. send FLAGS and PERMANENTFLAGS responses if they have changed.
An ACL server MAY modify one or more ACL for one or more identifier as a An ACL server MAY modify one or more ACL for one or more identifier as a
side effect of modifying the ACL specified in a SETACL/DELETEACL. side effect of modifying the ACL specified in a SETACL/DELETEACL.
If the server does that it MUST send untagged ACL response to notify the If the server does that it MUST send untagged ACL response(s) to notify the
client about the changes made. client about the changes made.
6.1.2. Clients 6.1.2. Clients
A client implementation that allows a user to read and update ACLs MUST A client implementation that allows a user to read and update ACLs MUST
preserve unrecognized rights that it doesn't allow the user to change preserve unrecognized rights that it doesn't allow the user to change
when updating the rights. Otherwise the client may unintentionally remove when updating the rights. Otherwise the client could risk unintentionally
permissions. removing permissions.
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 may 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.
If the server doesn't support "shared multiuser write access" to a If the server doesn't support "shared multiuser write access" to a
mailbox or doesn't implement shared flags on the mailbox, "shared flag mailbox or doesn't implement shared flags on the mailbox, "shared flag
rights" for the mailbox is defined to be the empty set. rights" for the mailbox is defined to be the empty set.
Example 1: Mailbox "banan" allows "shared multiuser write access" and Example 1: Mailbox "banan" allows "shared multiuser write access" and
skipping to change at line 802 skipping to change at line 821
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.
Example 3 (continued): The user that has "rset" rights for the mailbox Example 3 (continued): The user that has "rset" rights for the mailbox
"pear". The server returns READ-WRITE response "pear". The server returns READ-WRITE response
code on SELECT, as the user has "e" and "s" rights. code on SELECT, as the user has "e" and "s" rights.
7. Security Considerations 7. Security Considerations
An implementation must make sure the ACL commands themselves do not An implementation MUST make sure the ACL commands themselves do not
give information about mailboxes with appropriately restricted ACL's. give information about mailboxes with appropriately restricted ACL's.
For example, a GETACL command on a mailbox for which the user has For example, when a user agent executes a GETACL command on a mailbox
insufficient rights should not admit that the mailbox exists, much less that the user has no permission to LIST, the server would respond to that
return the mailbox's ACL. 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.
LISTRIGHTS command MUST NOT check that a particular identifier exists,
however it SHOULD recognize special identifiers like "anyone".
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] as modified by [IMAP4].
Non-terminals referenced but not defined below are as defined by Non-terminals referenced but not defined below are as defined by
[IMAP4]. [IMAP4].
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
command-auth =/ setacl / deleteacl / getacl /
listrights / myrights
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)
mod_rights = astring mailbox-data =/ acl-data / listrights-data / myrights-data
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
;; MUST include "t", "e", "x" and "k". ;; MUST include "t", "e", "x" and "k".
;; MUST NOT include standard rights listed ;; MUST NOT include standard rights listed
;; in section 3.2 ;; in section 3.2
rights = astring rights = astring
;; only lowercase ASCII letters and digits ;; only lowercase ASCII letters and digits
;; are allowed. ;; are allowed.
rights_capa = "RIGHTS=" new_rights rights-capa = "RIGHTS=" new-rights
;; RIGHTS=... capability ;; RIGHTS=... capability
setacl = "SETACL" SP mailbox SP identifier setacl = "SETACL" SP mailbox SP identifier
SP mod_rights SP mod-rights
9. IANA Considerations 9. IANA Considerations
IMAP4 capabilities are registered by publishing a standards track or IMAP4 capabilities are registered by publishing a standards track or
IESG approved experimental RFC. The registry is currently located IESG approved experimental RFC. The registry is currently located
at: at:
http://www.iana.org/assignments/imap4-capabilities http://www.iana.org/assignments/imap4-capabilities
This document defines the RIGHTS= IMAP capability. IANA is requested This document defines the RIGHTS= IMAP capability. IANA is requested
to add this capability to the registry. to add this capability to the registry.
10. References 10. Internationalization Considerations
10.1. Normative References Section 4 states requirements on servers regarding internationalization
of identifiers.
11. References
11.1. Normative References
[KEYWORDS] Bradner, "Key words for use in RFCs to Indicate [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, Harvard University, March 1997. Requirement Levels", RFC 2119, Harvard University, March 1997.
[ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd, ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd,
November 1997. November 1997.
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 3501, University of Washington, March 2003. 4rev1", RFC 3501, University of Washington, March 2003.
[UTF-8] Yergeau, F., "UTF-8, a transformation format of IS0 10646", [UTF-8] Yergeau, F., "UTF-8, a transformation format of IS0 10646",
RFC 3629, Alis Technologies, November 2003. RFC 3629, Alis Technologies, November 2003.
[Stringprep] Hoffman, P., Blanchet, M., "Preparation of [Stringprep] Hoffman, P., Blanchet, M., "Preparation of
Internationalized Strings ("stringprep")", RFC 3454, December 2002. Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[SASLprep] Zeilenga, K., "SASLprep: Stringprep profile for user names [SASLprep] Zeilenga, K., "SASLprep: Stringprep profile for User Names
and passwords", Work in progress, draft-ietf-sasl-saslprep-XX.txt. and Passwords", RFC 4013, February 2005.
10.2. Informative References 11.2. Informative References
[RFC2086] Myers, J., "IMAP4 ACL extension", RFC 2086, Carnegie Mellon, [RFC2086] Myers, J., "IMAP4 ACL extension", RFC 2086, Carnegie Mellon,
January 1997. January 1997.
11. Editor's Address 12. Editor's Address
Alexey Melnikov Alexey Melnikov
email: alexey.melnikov@isode.com email: alexey.melnikov@isode.com
Isode Limited Isode Limited
12. IPR Disclosure Acknowledgement 13. IPR Disclosure Acknowledgement
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with and any of which I become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
13. Intellectual Property Statement 14. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed
pertain to the implementation or use of the technology described in to pertain to the implementation or use of the technology
this document or the extent to which any license under such rights described in this document or the extent to which any license
might or might not be available; neither does it represent that it under such rights might or might not be available; nor does it
has made any effort to identify any such rights. Information on the represent that it has made any independent effort to identify any
IETF's procedures with respect to rights in standards-track and such rights. Information on the procedures with respect to rights
standards-related documentation can be found in BCP-11. Copies of in RFC documents can be found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any Copies of IPR disclosures made to the IETF Secretariat and any
copyrights, patents or patent applications, or other proprietary assurances of licenses to be made available, or the result of an
rights which may cover technology that may be required to practice attempt made to obtain a general license or permission for the use
this standard. Please address the information to the IETF Executive of such proprietary rights by implementers or users of this
Director. specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
14. Full Copyright Statement The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
15. Full Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78 and to the rights, licenses and restrictions contained in BCP 78 and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
skipping to change at line 1025 skipping to change at line 1056
22. Updated "References" section. 22. Updated "References" section.
23. Added more examples. 23. Added more examples.
24. Clarified when the virtual "c" and "d" rights are returned in ACL, 24. Clarified when the virtual "c" and "d" rights are returned in ACL,
MYRIGHTS and LISTRIGHTS responses. MYRIGHTS and LISTRIGHTS responses.
Appendix B. Compatibility with RFC 2086 Appendix B. Compatibility with RFC 2086
This section gives guidelines how an existing RFC 2086 server This non-normative section gives guidelines how an existing RFC 2086
implementation may be updated to comply with this document. server implementation may be updated to comply with this document.
This document splits the "d" right into several new different rights: This document splits the "d" right into several new different rights:
"t", "e" and possibly "x" (see section 3.1.1 for more details). The "d" "t", "e" and possibly "x" (see section 3.1.1 for more details). The "d"
right remains for backwards-compatibility but it is a virtual right. right remains for backwards-compatibility but it is a virtual right.
The server should implement one of the following two approaches to There are two approaches for RFC2086 server implementors to
handle the "d" right and the new rights that have replaced it. handle the "d" right and the new rights that have replaced it.
a). "t", "e" (and possibly "x) together - almost no changes. a). "t", "e" (and possibly "x) together - almost no changes.
b). Implement separate "x", "t" and "e". Return the "d" right in a b). Implement separate "x", "t" and "e". Return the "d" right in a
MYRIGHTS response or an ACL response containing ACL MYRIGHTS response or an ACL response containing ACL
information when any of the "t", "e" (and "x") is granted. information when any of the "t", "e" (and "x") is granted.
In a similar manner this document splits the "c" right into several In a similar manner this document splits the "c" right into several
new different rights: "k" and possibly "x" (see section 3.1.1 for more new different rights: "k" and possibly "x" (see section 3.1.1 for more
details). The "c" right remains for backwards-compatibility but it is details). The "c" right remains for backwards-compatibility but it is
a virtual right. The server should implement one of the two approaches a virtual right. Again, RFC2086 server implementors can choose
described above. to tie rights or to implement separate rights, as described above.
Also check Sections 6.1 and 6.2, as well as the appendix A to see Also check Sections 6.1 and 6.2, as well as the appendix A to see
other changes required. Server implementors should check which rights other changes required. Server implementors should check which rights
are required to invoke different IMAP4 commands as described in are required to invoke different IMAP4 commands as described in
Section 5. Section 5.
Appendix C. Known deficiencies Appendix C. Known deficiencies
This specification has some known deficiencies including: This specification has some known deficiencies including:
1. This is inadequate to provide complete read-write access to 1. This is inadequate to provide complete read-write access to
mailboxes protected by Unix-style rights bits because there is no mailboxes protected by Unix-style rights bits because there is no
equivalent to "chown" and "chgrp" commands nor is there a good way equivalent to "chown" and "chgrp" commands nor is there a good way
to discover such limitations are present. to discover such limitations are present.
2. Because this extension leaves the specific semantics of how rights 2. Because this extension leaves the specific semantics of how rights
are combined by the server as implementation defined, the ability are combined by the server as implementation defined, the ability
to build a user-friendly interface is limited. to build a user-friendly interface is limited.
3. Users, groups, and special identifiers (e.g. anyone) exist in the
same namespace.
The work-in-progress "ACL2" extension is intended to redesign this The work-in-progress "ACL2" extension is intended to redesign this
extension to address these deficiencies without the constraint of extension to address these deficiencies without the constraint of
backwards-compatibility and may eventually supercede this facility. backwards-compatibility and may eventually supercede this facility.
However, RFC 2086 is deployed in multiple implementations so this However, RFC 2086 is deployed in multiple implementations so this
intermediate step which fixes the straightforward deficiencies in a intermediate step which fixes the straightforward deficiencies in a
backwards compatible fashion is considered worthwhile. backwards compatible fashion is considered worthwhile.
Appendix D. Acknowledgment Appendix D. Acknowledgment
This document is a revision of the RFC 2086 written by John G. Myers. This document is a revision of the RFC 2086 written by John G. Myers.
Editor appreciates comments received from Mark Crispin, Chris Newman, Editor appreciates comments received from Mark Crispin, Chris Newman,
Cyrus Daboo, John G. Myers, Dave Cridland, Ken Murchison, Steve Hole, Cyrus Daboo, John G. Myers, Dave Cridland, Ken Murchison, Steve Hole,
Vladimir Butenko, Larry Greenfield, Robert Siemborski, Harrie Vladimir Butenko, Larry Greenfield, Robert Siemborski, Harrie
Hazewinkel, Philip Guenther, Brian Candler, Curtis King, Lyndon Hazewinkel, Philip Guenther, Brian Candler, Curtis King, Lyndon
Nerenberg and other participants of the IMAPEXT working group. Nerenberg, Lisa Dusseault and other participants of the IMAPEXT
working group.
 End of changes. 

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