draft-ietf-imapext-acl-09.txt   draft-ietf-imapext-acl-10.txt 
IMAPEXT Working Group A. Melnikov IMAPEXT Working Group A. Melnikov
Internet Draft Editor Internet Draft Editor
Document: draft-ietf-imapext-acl-09.txt August 2003 Document: draft-ietf-imapext-acl-10.txt July 2004
Expires: January 2005
IMAP4 ACL extension IMAP4 ACL extension
Status of this Memo Status of this Memo
This document is an Internet Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of RFC 2026. patent or other IPR claims of which I am aware have been disclosed, or
will be disclosed, and any of which I become aware will be disclosed,
in accordance with RFC 3668.
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. Internet Drafts are draft documents valid for a maximum of Drafts. Internet Drafts are draft documents valid for a maximum of
six months. Internet Drafts may be updated, replaced, or obsoleted six months. Internet Drafts may be updated, replaced, or obsoleted
by other documents at any time. It is not appropriate to use by other documents at any time. It is not appropriate to use
Internet Drafts as reference material or to cite them other than as Internet Drafts as reference material or to cite them other than as
``work in progress''. ``work in progress''.
skipping to change at line 71 skipping to change at line 75
3 Introduction and Overview ................................. X 3 Introduction and Overview ................................. X
3.1 Access Control ........................................... X 3.1 Access Control ........................................... X
3.2 Access calculation model ................................. X 3.2 Access calculation model ................................. X
3.3 Rights required to perform different IMAP4rev1 commands .. X 3.3 Rights required to perform different IMAP4rev1 commands .. X
4 ACL manipulation commands ................................. X 4 ACL manipulation commands ................................. X
4.1 ACL STORE ................................................ X 4.1 ACL STORE ................................................ X
4.2 ACL DELETE ............................................... X 4.2 ACL DELETE ............................................... X
4.3 ACL SET .................................................. X 4.3 ACL SET .................................................. X
4.4 LIST with the ACL parameter .............................. X 4.4 LIST with the ACL parameter .............................. X
4.5 LIST with the MYRIGHTS parameter ......................... X 4.5 LIST with the MYRIGHTS parameter ......................... X
4.6 LIST with the POSTADDRESS parameter ...................... X
5 ACL related responses ..................................... X 5 ACL related responses ..................................... X
5.1 Extended LIST response with ACL information .............. X 5.1 Extended LIST response with ACL information .............. X
5.2 RIGHTS-INFO .............................................. X 5.2 RIGHTS-INFO .............................................. X
5.3 ACLFAILED untagged response .............................. X 5.3 ACLFAILED untagged response .............................. X
5.4 Extended LIST response with MYRIGHTS information ......... X 5.4 Extended LIST response with MYRIGHTS information ......... X
5.5 Extended LIST response with POSTADDRESS information ...... X 5.5 MYRIGHTS response code ................................... X
5.6 MYRIGHTS response code ................................... X
6 Formal Syntax ............................................. X 6 Formal Syntax ............................................. X
7 IANA considerations ....................................... X 7 IANA considerations ....................................... X
7.1 ACL access calculation rule Registration Template ........ X 7.1 ACL access calculation rule Registration Template ........ X
7.2 Initial Registrations .................................... X 7.2 Initial Registrations .................................... X
7.2.1 Registration: UNION access calculation rule ............ X 7.2.1 Registration: UNION access calculation rule ............ X
7.2.2 Registration: MOST-SPECIFIC access calculation rule .... X 7.2.2 Registration: MOST-SPECIFIC access calculation rule .... X
8 Security Considerations ................................... X 8 Security Considerations ................................... X
9 Other considerations ...................................... X 9 Other considerations ...................................... X
9.1 Compatibility with RFC 2086 .............................. X 9.1 Compatibility with RFC 2086 .............................. X
9.2 Mapping of ACL rights to READ-WRITE and READ-ONLY 9.2 Mapping of ACL rights to READ-WRITE and READ-ONLY
skipping to change at line 125 skipping to change at line 127
The ACL (Access Control List) extension of the Internet Message Access The ACL (Access Control List) extension of the Internet Message Access
Protocol [IMAP4] permits mailbox access control lists to be retrieved Protocol [IMAP4] permits mailbox access control lists to be retrieved
and manipulated through the IMAP protocol. and manipulated through the IMAP protocol.
The ACL extension is present in any IMAP4 implementation which The ACL extension is present in any IMAP4 implementation which
returns a capability starting with "ACL2=" prefix as one of the returns a capability starting with "ACL2=" prefix as one of the
supported capabilities to the CAPABILITY command. The prefix is supported capabilities to the CAPABILITY command. The prefix is
followed by "rule identifier" as described in 7.1. followed by "rule identifier" as described in 7.1.
<<Is LISTEXT capability required for all ACL2 server?>>
The document contains the following parts: section 3.1 provides the The document contains the following parts: section 3.1 provides the
definition of different classes of identifiers and defines standard definition of different classes of identifiers and defines standard
rights; section 3.2 introduces access calculation model, i.e. it rights; section 3.2 introduces access calculation model, i.e. it
describes how to calculate from an ACL which rigths apply to a particular describes how to calculate from an ACL which rigths apply to a particular
user; section 3.3 summarizes relationship of different access rights with user; section 3.3 summarizes relationship of different access rights with
IMAP commands; section 4 introduces new IMAP commands the client can use IMAP commands; section 4 introduces new IMAP commands the client can use
to manipulate ACLs; section 5 defines new ACL related responses; and to manipulate ACLs; section 5 defines new ACL related responses; and
section 9 lists important considerations for compatibility with [IMAP4], section 9 lists important considerations for compatibility with [IMAP4],
RFC 2086 and some IMAP extensions. RFC 2086 and some IMAP extensions.
skipping to change at line 186 skipping to change at line 190
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, CHECK, FETCH, SEARCH, r - read (SELECT the mailbox, perform STATUS, CHECK, FETCH, SEARCH,
COPY from mailbox) COPY from mailbox)
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, APPEND or COPY)
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) APPEND or 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. LIST (POSTADDRESS) command can be used not enforced by IMAP4 itself.
to get an email address, that can be used for posting to the mailbox,
if one exist)
c - create mailboxes (CREATE new sub-mailboxes in any c - 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)
When a new mailbox is created it SHOULD inherit rights from When a new mailbox is created it SHOULD inherit rights from
the parent mailbox (if one exists) in the defined hierarchy. the parent mailbox (if one exists) in the defined hierarchy.
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
d - This right is defined for backward compatibility with ACL d - This right is defined for backward compatibility with ACL
skipping to change at line 375 skipping to change at line 377
C: A005 COPY 1:3 TargetMailbox C: A005 COPY 1:3 TargetMailbox
S: A005 OK Copy completed S: A005 OK Copy completed
C: A006 SELECT TargetMailbox C: A006 SELECT TargetMailbox
... ...
S: A006 Select Completed S: A006 Select Completed
Let's assume that the copied messages received message numbers 77:79. Let's assume that the copied messages received message numbers 77:79.
C: A007 FETCH 77:79 (FLAGS) C: A007 FETCH 77:79 (FLAGS)
S: * 77 FETCH (FLAGS (\Draft) S: * 77 FETCH (FLAGS (\Draft))
S: * 78 FETCH (FLAGS (\Answered) S: * 78 FETCH (FLAGS (\Answered))
S: * 79 FETCH (FLAGS ($Forwarded \Seen) S: * 79 FETCH (FLAGS ($Forwarded \Seen))
S: A007 OK Fetch Completed S: A007 OK Fetch Completed
\Deleted flag was lost on COPY, as the user has no "t" right in the \Deleted flag was lost on COPY, as the user has no "t" right in the
target mailbox. target mailbox.
If the LIST (MYRIGHT) command with the tag A003 would have returned: If the LIST (MYRIGHT) command with the tag A003 would have returned:
S: * LIST () "/" TargetMailbox (("MYRIGHTS" "rsti")) S: * LIST () "/" TargetMailbox (("MYRIGHTS" "rsti"))
the response from the FETCH with the tag A007 would have been: the response from the FETCH with the tag A007 would have been:
C: A007 FETCH 77:79 (FLAGS) C: A007 FETCH 77:79 (FLAGS)
S: * 77 FETCH (FLAGS (\Deleted) S: * 77 FETCH (FLAGS (\Deleted))
S: * 78 FETCH (FLAGS () S: * 78 FETCH (FLAGS ())
S: * 79 FETCH (FLAGS (\Seen) S: * 79 FETCH (FLAGS (\Seen))
S: A007 OK Fetch Completed S: A007 OK Fetch Completed
In the latter case \Answered, $Forwarded and \Draft flags were lost In the latter case \Answered, $Forwarded and \Draft flags were lost
on COPY, as the user has no "w" right in the target mailbox. on COPY, as the user has no "w" right in the target mailbox.
Expunging the selected mailbox: Expunging the selected mailbox:
EXPUNGE - "e" right on the selected mailbox. EXPUNGE - "e" right on the selected mailbox.
CLOSE - "e" right on the selected mailbox. If the server is unable to CLOSE - "e" right on the selected mailbox. If the server is unable to
expunge the mailbox because the user doesn't have the "e" right, expunge the mailbox because the user doesn't have the "e" right,
skipping to change at line 625 skipping to change at line 627
The user must have any of the following rights to perform this operation: The user must have any of the following rights to perform this operation:
"l", "r", "i", "c", "x", "e", "a". "l", "r", "i", "c", "x", "e", "a".
If the user doesn't have any right from the above list, the server If the user doesn't have any right from the above list, the server
MUST behave as if the mailbox doesn't exist. MUST behave as if the mailbox doesn't exist.
Example: C: A002 LIST (MYRIGHTS) "" INBOX Example: C: A002 LIST (MYRIGHTS) "" INBOX
S: * LIST () "/" INBOX (("MYRIGHTS" "rwipsldexta")) S: * LIST () "/" INBOX (("MYRIGHTS" "rwipsldexta"))
S: A002 OK List with acl info completed S: A002 OK List with acl info completed
4.6. LIST with the POSTADDRESS parameter
This document defines a new option POSTADDRESS to the LIST command that requests
the server to return an email address that can be used to post email to a mailbox,
that matches the LIST mailbox name. The POSTADDRESS option causes the server
to return LIST with POSTADDRESS information (see 5.5).
Example: C: A002 LIST (POSTADDRESS) "" INBOX
S: * LIST () "/" INBOX (("POSTADDRESS" "user1@example.com"))
S: A002 OK List with postaddress info completed
5. ACL related responses 5. ACL related responses
5.1. Extended LIST response with ACL information 5.1. Extended LIST response with ACL information
Contents: name attributes Contents: name attributes
hierarchy delimiter hierarchy delimiter
mailbox name mailbox name
ACL information (zero or more identifier rights pairs) ACL information (zero or more identifier rights pairs)
This version of LIST response occurs as a result of an LIST (ACL) command. This version of LIST response occurs as a result of an LIST (ACL) command.
skipping to change at line 731 skipping to change at line 722
LIST response as defined by mbox-list-extended ABNF element of [LISTEXT]. LIST response as defined by mbox-list-extended ABNF element of [LISTEXT].
The meaning of "name attributes" and "hierarchy delimiter" is described in The meaning of "name attributes" and "hierarchy delimiter" is described in
section 7.2.2 of [IMAP4]. This is followed by the extension part that section 7.2.2 of [IMAP4]. This is followed by the extension part that
includes "MYRIGHTS" tag followed by the set of rights that the user has. includes "MYRIGHTS" tag followed by the set of rights that the user has.
<<Should this be simplified so that we don't repeat general LIST[EXT] stuff?>> <<Should this be simplified so that we don't repeat general LIST[EXT] stuff?>>
Example: S: * LIST () "/" Sent (("MYRIGHTS" "lrwiste")) Example: S: * LIST () "/" Sent (("MYRIGHTS" "lrwiste"))
5.5. Extended LIST response with POSTADDRESS information 5.5. MYRIGHTS response code
Contents: name attributes
hierarchy delimiter
mailbox name
email address for posting to the mailbox
This version of LIST response occurs as a result of a LIST (POSTADDRESS)
command. The proposed syntax conforms to the syntax of an extended
LIST response as defined by mbox-list-extended ABNF element of [LISTEXT].
The meaning of "name attributes" and "hierarchy delimiter" is described in
section 7.2.2 of [IMAP4]. This is followed by the extension part that
includes "POSTADDRESS" tag followed by an email address that can be used
to post email to the mailbox.
Example: S: * LIST () "/" Sent (("POSTADDRESS" "user+Sent@imap.example.com"))
5.6. MYRIGHTS response code
Data: rights Data: rights
The MYRIGHTS response code is sent in an untagged OK response The MYRIGHTS response code is sent in an untagged OK response
that results from SELECT/EXAMINE. Also this response code can be that results from SELECT/EXAMINE. Also this response code can be
sent at any time after opening a mailbox when the server detects sent at any time after opening a mailbox when the server detects
that the set of rights allowed for the logged in user has changed. that the set of rights allowed for the logged in user has changed.
The MYRIGHTS response code is equivalent to the MYRIGHTS data returned The MYRIGHTS response code is equivalent to the MYRIGHTS data returned
in an untagged LIST response for the selected mailbox. in an untagged LIST response for the selected mailbox.
skipping to change at line 793 skipping to change at line 766
acl_data = "NIL" | acl_data_nonemp acl_data = "NIL" | acl_data_nonemp
;; NIL, or one or more parenthesized identifier/rights pairs ;; NIL, or one or more parenthesized identifier/rights pairs
acl_data_nonemp = "(" ace *( SP ace ) ")" acl_data_nonemp = "(" ace *( SP ace ) ")"
always_granted = rights always_granted = rights
deleteacl = "DELETE" SP mbox_or_pat SP identifier deleteacl = "DELETE" SP mbox_or_pat SP identifier
option =/ "ACL" | "MYRIGHTS" | "POSTADDRESS" option =/ "ACL" | "MYRIGHTS"
;; <option> is defined in [LISTEXT] ;; <option> is defined in [LISTEXT]
identifier = astring identifier = astring
;; UTF-8 string with syntax of ident_syntax ;; UTF-8 string with syntax of ident_syntax
ident_syntax = ident | "-" ident ident_syntax = ident | "-" ident
ident = ident_special | ident_user | ident_group | ident = ident_special | ident_user | ident_group |
ident_vendor ident_vendor
skipping to change at line 848 skipping to change at line 821
mbox_or_pat = mailbox / patterns mbox_or_pat = mailbox / patterns
patterns = "(" list-mailbox *(list-mailbox) ")" patterns = "(" list-mailbox *(list-mailbox) ")"
partialfail_rsp = "ACLFAILED" SP mailbox partialfail_rsp = "ACLFAILED" SP mailbox
[SP ["[" resp-text-code "]" SP] text] [SP ["[" resp-text-code "]" SP] text]
;; May contain optional failure reason followed by a ;; May contain optional failure reason followed by a
;; human readable text ;; human readable text
postaddress_data
= "(" <"> "POSTADDRESS" <"> SP email_address ")"
;; postaddress_data conforms to the syntax of
;; mbox-list-extended-item from [LISTEXT]
email_address = nstring
;; NIL if email address is not known
UTF8-CHAR = CHAR | UTF8-2 | UTF8-3 | UTF8-4 | UTF8-5 | UTF8-6 UTF8-CHAR = CHAR | UTF8-2 | UTF8-3 | UTF8-4 | UTF8-5 | UTF8-6
CHAR = %x01-7F CHAR = %x01-7F
UTF8-loworder = %x80-BF UTF8-loworder = %x80-BF
UTF8-2 = %xC1-DF UTF8-loworder UTF8-2 = %xC1-DF UTF8-loworder
;; Disallow overlong sequences beginning with 0xC0. ;; Disallow overlong sequences beginning with 0xC0.
UTF8-3 = (%xE0 %xA0-BF UTF8-loworder) | UTF8-3 = (%xE0 %xA0-BF UTF8-loworder) |
skipping to change at line 961 skipping to change at line 926
memo memo
8. Security Considerations 8. 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 LIST (ACL) command on a mailbox for which the user has For example, a LIST (ACL) command on a mailbox for which the user has
insufficient rights should not admit the mailbox exists, much less insufficient rights should not admit the mailbox exists, much less
return the mailbox's ACL. return the mailbox's ACL.
<<Add security considerations for POSTADDRESS option: address harvesting
for spam, rights required>>
IMAP clients implementing ACL2 that are able to modify ACLs SHOULD IMAP clients implementing ACL2 that are able to modify ACLs SHOULD
warn a user that wants to give full access (or even just "a" right) warn a user that wants to give full access (or even just "a" right)
to the special identifier "anyone". to the special identifier "anyone".
9. Other considerations 9. Other considerations
9.1. Compatibility with RFC 2086 9.1. Compatibility with RFC 2086
This section gives guidelines how an existing RFC 2086 implementation This section gives guidelines how an existing RFC 2086 implementation
may be modified to support ACL2. may be modified to support ACL2.
skipping to change at line 1137 skipping to change at line 1099
Larry Greenfield, Vladimir Butenko, Dave Cridland, Harrie Hazewinkel Larry Greenfield, Vladimir Butenko, Dave Cridland, Harrie Hazewinkel
and other participants of the IMAPEXT working group. and other participants of the IMAPEXT working group.
13. Editor's Address 13. Editor's Address
Alexey Melnikov Alexey Melnikov
mailto: mel@isode.com mailto: mel@isode.com
Isode Limited Isode Limited
14. Full Copyright Statement 14. IPR Disclosure Acknowledgement
Copyright (C) The Internet Society 2003. All Rights Reserved. By submitting this Internet-Draft, I certify that any applicable
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
RFC 3668.
This document and translations of it may be copied and furnished to 15. Intellectual Property Statement
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be The IETF takes no position regarding the validity or scope of any
revoked by the Internet Society or its successors or assigns. intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
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.
This document and the information contained herein is provided on an The IETF invites any interested party to bring to its attention any
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING copyrights, patents or patent applications, or other proprietary
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING rights which may cover technology that may be required to practice
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION this standard. Please address the information to the IETF Executive
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF Director.
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
16. Full Copyright Statement
Copyright (C) The Internet Society (2004). 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
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Appendix A. Changes since RFC 2086 Appendix A. Changes since RFC 2086
1. Changed the charset of "identifier" from US-ASCII to UTF-8. 1. Changed the charset of "identifier" from US-ASCII to UTF-8.
2. Changed identifier syntax. Now all users must start with "user=" 2. Changed identifier syntax. Now all users must start with "user="
prefix. Specified that identifiers starting with a "group=" prefix are prefix. Specified that identifiers starting with a "group=" prefix are
reserved for groups and implementation defined aliases. reserved for groups and implementation defined aliases.
3. Specified that mailbox deletion is controled by the "x" right and 3. Specified that mailbox deletion is controled by the "x" right and
skipping to change at line 1291 skipping to change at line 1273
the format of an email for posting to a mailbox is out of scope. the format of an email for posting to a mailbox is out of scope.
43. Added a table that describes all operations and right required to 43. Added a table that describes all operations and right required to
perform them. perform them.
44. Fixed several MYRIGHTS examples. 44. Fixed several MYRIGHTS examples.
45. Updated ABNF to reflect recent changes ("MYRIGHTS" to "LIST (MYRIGHTS)" 45. Updated ABNF to reflect recent changes ("MYRIGHTS" to "LIST (MYRIGHTS)"
and "ACL GET" to "LIST (ACL)") and "ACL GET" to "LIST (ACL)")
46. Added LIST (POSTADDRESS). 46. Updated ACL ABNF to represent an empty ACL with NIL, instead of "()".
47. Updated ACL ABNF to represent an empty ACL with NIL, instead of "()".
48. Added "anonymous" as a synonym for the "anyone". 47. Added "anonymous" as a synonym for the "anyone".
49. Moved section about interaction of ACL2 with the QUOTA extension to 48. Moved section about interaction of ACL2 with the QUOTA extension to
the QUOTA+ document. the QUOTA+ document.
50. Clarified that "anonymous", "anyone", "authuser", "administrators" 49. Clarified that "anonymous", "anyone", "authuser", "administrators"
should be treated as groups. should be treated as groups.
51. Changed ACL definition to be an "ordered list", instead of a "set". 50. Changed ACL definition to be an "ordered list", instead of a "set".
This has no effect on UNION model, but changes MOST-SPECIFIC. This has no effect on UNION model, but changes MOST-SPECIFIC.
52. Clarified that for the MOST-SPECIFIC model the first group in an ACL 51. Clarified that for the MOST-SPECIFIC model the first group in an ACL
that contains the user wins. that contains the user wins.
 End of changes. 

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