draft-ietf-imapext-2086upd-04.txt   draft-ietf-imapext-2086upd-05.txt 
Network Working Group A. Melnikov Network Working Group A. Melnikov
Internet Draft Editor Internet Draft Editor
Document: draft-ietf-imapext-2086upd-04.txt March 2005 Document: draft-ietf-imapext-2086upd-05.txt April 2005
Updates: <<3501?>> Updates: <<3501?>>
Obsoletes: 2086 Obsoletes: 2086
Expires: September 2005 Expires: October 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, each author represents that any
patent or other IPR claims of which I am aware have been disclosed, or applicable patent or other IPR claims of which he or she is aware
will be disclosed, and any of which I become aware will be disclosed, have been or will be disclosed, and any of which he or she becomes
in accordance with RFC 3668. aware will be disclosed, in accordance with Section 6 of BCP 79.
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-Drafts. other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress". material or to cite them other than as "work in progress".
skipping to change at line 740 skipping to change at line 739
S: A142 OK [READ-WRITE] SELECT completed S: A142 OK [READ-WRITE] SELECT completed
S: * MYRIGHTS INBOX lrwis S: * MYRIGHTS INBOX lrwis
S: A143 OK completed S: A143 OK completed
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.
If such server detects that the user no longer has read access to the
mailbox, it MAY send an untagged BYE response and close connection.
It MAY also refuse to execute all commands specific to the selected state
until the mailbox is closed, however server implementors should note that
most clients don't handle NO responses very well.
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(s) 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.
An ACL server implementation MUST treat received ACL modification commands
as a possible ambiguity with respect to subsequent commands affected by the
ACL, as described in section 5.5 of [IMAP4]. Hence a pipeline
SETACL + MYRIGHTS is an ambiguity with respect to the server, meaning that
the server must execute the SETACL command to completion before the MYRIGHTS.
However, clients are permitted to send such a pipeline.
6.1.2. Clients 6.1.2. Clients
The following requirement is put on clients in order to allow for
future extensibility.
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 could risk unintentionally I.e., if the client
removing permissions. 1) can read ACLs
and
2) can update ACLs
but
3) doesn't allow the user to change the rights the client doesn't recognize,
then it MUST preserve unrecognized rights.
Otherwise the client could risk unintentionally removing permissions
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 may be
skipping to change at line 942 skipping to change at line 962
12. 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
13. IPR Disclosure Acknowledgement 13. IPR Disclosure Acknowledgement
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which I am aware have been disclosed, applicable patent or other IPR claims of which he or she is aware
and any of which I become aware will be disclosed, in accordance with have been or will be disclosed, and any of which he or she becomes
RFC 3668. aware will be disclosed, in accordance with Section 6 of BCP 79.
14. 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 Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology to pertain to the implementation or use of the technology
described in this document or the extent to which any license described in this document or the extent to which any license
under such rights might or might not be available; nor does it under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to rights such rights. Information on the procedures with respect to rights
skipping to change at line 973 skipping to change at line 993
at http://www.ietf.org/ipr. at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org. IETF at ietf-ipr@ietf.org.
15. Full Copyright Statement 15. Full Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2005).
to the rights, licenses and restrictions contained in BCP 78 and
except as set forth therein, the authors retain all their rights. This document is subject to the rights, licenses and restrictions
contained in BCP 78, and 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
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgement
skipping to change at line 1112 skipping to change at line 1134
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, Lisa Dusseault and other participants of the IMAPEXT Nerenberg, Lisa Dusseault, Arnt Gulbrandsen and other participants
working group. 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/