Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: [email-masked]
Date: Wed, 31 May 2000 19:48:09 -0700 (PDT)
List-Id: <ietf-imapext.imc.org>

On Wed, 31 May 2000 15:16:49 -0700, Cyrus Daboo wrote:
> >> 'The server SHOULD issue an untagged MYRIGHTS response
> > I agree completely, but you can't do this in the RFC 2086 framework,
> > because a base level IMAP client would complain about getting a MYRIGHTS
> > response.
> Not if its a resp-cond-state:
> * OK [MYRIGHTS lrwia] myrights ACL response

Well, yes and no.

Yes, that is certainly valid in the base spec.  No, because a resp-cond-status
of MYRIGHTS is different from an RFC 2086 MYRIGHTS response.

That seems to be splitting hairs, but it means we'd have two ways of doing the
same response forever, unless the untagged MYRIGHTS response is deprecated in
favor of the resp-cond-state.  That might be a good idea, actually; it could
be carried in the tagged OK response for the MYRIGHTS command and not use an
untagged response at all.

However, I still contend that leveraging off the LIST response would be a
better idea.  It could be useful for the client to get \NoInferiors state at
SELECT time; and there's a lot more that could be delivered as well.

There's another reason why I advocate a LIST response; I think that the
current GETACL, LISTRIGHTS, and MYRIGHTS commands should be deprecated in
favor of an extended form of LIST.  That way, we could use wildcards, and
avoid the current situation where a client does a LIST then a MYRIGHTS for
each returned mailbox.

PS: Ofhand observation: the interesting rights at SELECT time are lipca.  The
client can infer r from being able to select, and swd from PERMANENTFLAGS.

Date: Wed, 31 May 2000 15:16:49 -0700
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt
Sender: [email-masked]

--On Wednesday, May 31, 2000 3:10 PM -0700 Mark Crispin 
<[email-masked]> wrote:

>> 'The server SHOULD issue an untagged MYRIGHTS response (as a
>> response-cond-state [IMAP4] response) when a client issues the SELECT or
>> EXAMINE command for a mailbox when the ACL extension is present'
>
> I agree completely, but you can't do this in the RFC 2086 framework,
> because a base level IMAP client would complain about getting a MYRIGHTS
> response.

Not if its a resp-cond-state:

a SELECT INBOX
...
...
* OK [MYRIGHTS lrwia] myrights ACL response
a OK

>From what I see in RFC2060 'resp_text_code' is designed so clients should 
accept data not defined in the base-spec.

-- 
Cyrus Daboo

Date: Wed, 31 May 2000 16:37:57 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Steve Hole <[email-masked]>
cc: John Gardiner Myers <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Mon, 29 May 2000, Steve Hole wrote:
> I think that (2) (identifier theory) is where we are going to run aground.
> A flexible identifier theory and semantic strikes me as being a strategy
> much like flexible hierarchy notation.     This scares me.

Let's be clear on this.  I don't intend that "UNIX owner" or "UNIX group"
be defined as such in ACL.  Rather, it should be possible to express these
concepts as part of a general (not flexible!) mechanism.

By general, I mean "a mechanism whose ideal state is full implementation"
as opposed to "flexible" which means "a mechanism which expresses
contradictory models, and therefore would never be fully implemented."

Hierarchy is "flexible"; what I propose for identifiers is "general".

My idea basically boils down to this:
 1) a mechanism to define identifiers: global, per-mailbox, and perhaps
    also per-user (I don't need the last one, but perhaps other people
    do).  Defined identifiers can be defined in terms of other
    defined identifiers.
 2) a system of naming that makes the type of identifier unambiguous.
 3) a mechanism to look up (expands) the definition of a defined
    identifier.

The impact of this is:
 . definition of identifier nomenclature
 . command to define an identifier
 . command to get the definition of an identifier

Note that there is no specific "change group" or "change owner"; however,
the necessary functionality is there.  The semantics of other existing ACL
mechanisms can be done the same way.

I also don't think that it's necessary for the specification to enshrine
"owner" or "group" in the UNIX sense, but perhaps it may be good to
document a particular convention for per-mailbox nomenclature of defined
identifiers of these two.

At the specification level, all that should matter is that these
per-mailbox identifiers have ACLs; the per-mailbox identifier that
corresponds to UNIX owner expands to one or more RFC 2086 user name
identifiers, and the per-mailbox identifier that corresponds to UNIX group
expands to a global defined identifier (which in turn expands to one or
more RFC 2086 user name identifiers).

Of course, the server is always permitted to respond NO to an operation
which it does not agree to do.

A separate issue is the lack of an identifier that includes everybody
except for anonymous.  Since excluding anonymous is the normal case, it
doesn't really work well to have negative rights for anonymous on all
ACLs.

> It was collosal mistake to
> select in favour of the "what the server is able to express" model for
> hierarchy and we should not make the same mistake for ACL identifiers.

I don't think that the example of hierarchy really applies here.  In
hierarchy, two models which were fundamentally hostile to each other were
shoehorned together.  In this case, we're talking about extensions to the
existing framework that everybody can implement, and probably would want
to implement.

It is possible to implement RFC 2086 ACL in UNIX now (inheritance and the
"c" right in the draft is a different matter).  The problem is that the
result isn't very useful and/or would give clients unpleasant surprises
(e.g. implicit DELETEACL).  I don't think that you want that.

With these extensions, the only differences would be in what the server
will say OK or NO to.  You wouldn't have the \NoSelect or \NoInferiors
which are specific to how a particular model works.  There would be no
"chgrp" operator, but there would be an operator that I would implement
with chgrp() (and some other server would do it some other way).

Date: Wed, 31 May 2000 16:05:54 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Steve Hole <[email-masked]>
cc: John Gardiner Myers <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt
Organization: Networks & Distributed Computing
Sender: [email-masked]

> Inheritance (3) will be a very interesting discussion, but because
> formalization of it is a "new thing" we *should* be able to converge on
> that as well.

My position is that it is better not to have inheritance at all rather
than the definition in the draft.  If you have inheritance, it is
relatively simple to work around a lack of inheritance in the ACL
specification.

Otherwise, you need a complex specification of how inheritance works;
either by being able to stipulate when inheritance happens or by having a
priority mechanism which indicates when inheritance applies.  The problem
comes in with negative rights.

Consider this example: a particular mailbox is open to anyone except
those who are members of a particular group (overriding anyone inheritance
with a negative right) but user fred who is in that group has access
(overriding the group negative right).  This is something that people want
to do, and it's easy to do in UNIX.  The draft makes it impossible; once a
negative right is acquired through inheritance there's no way to lose it.

I identified some missing functionality in inheritance, but I wouldn't be
at all surprised if someone else finds other missing functionality.  I
don't think that it's possible to make a simple definition of inheritance
that is going to have long-term viability.

I contend that inheritance is a rathole, and an unnecessary one at that.

If, on the other hand, there is no inheritance, then the problem doesn't
exist.  Even better, negative rights can also be deleted from the
specification since all you need to do the equivalent is add an ACL for
the identifier without that right.

Date: Wed, 31 May 2000 16:04:50 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Steve Hole <[email-masked]>
cc: John Gardiner Myers <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Mon, 29 May 2000, Steve Hole wrote:
> (1)   The interpretation of various rights identifiers.
> (2)   The definition/management of identifiers.
> (3)   Rights inheritance.

I think that this is a good summary.  Add a fourth issue:

(4) Structure of ACL commands and (especially) responses.

This relates to things such as issuing automatic ACL responses at SELECT
time; the ability to have wildcards in mailbox names; the ability to
replace the entire ACL and/or redefine ACL for multiple identifiers; the
ability to query potential rights for multiple identifiers.

> We have had trouble with (1)
> ourselves and I think that it should be fairly easy to come to concensus
> on.

I hope so.  Since rights tying exists, it would be better to add a new
right rather than to overload existing rights with semantics that may not
necessarily make sense to tie together.  I'm thinking here about the "c"
right, which should not be overloaded with "delete mailbox".

Date: Wed, 31 May 2000 15:10:30 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Sat, 27 May 2000, Cyrus Daboo wrote:
> What I would like to see is a new REPLACEACL command that takes a mailbox
> spec, similar to the LIST command, and a list of identifier-rights pairs.
> This command would remove all the existing rights on the matching mailboxes
> and then add all the rights specified in the command. This effectively
> 'propagates' a set of rights to a group of mailboxes in a single command.

Yes!  This is one of the important operations I feel is missing in RFC
2086; the current SETACL is actually a "modify ACL" or "add ACL" as
opposed to a "set ACL".  It's one of the things that I want to do in
ACLPLUS.

> 'The server SHOULD issue an untagged MYRIGHTS response (as a
> response-cond-state [IMAP4] response) when a client issues the SELECT or
> EXAMINE command for a mailbox when the ACL extension is present'

I agree completely, but you can't do this in the RFC 2086 framework,
because a base level IMAP client would complain about getting a MYRIGHTS
response.

My idea in ACLPLUS is to deprecate all the existing RFC 2086 responses
(basically, only in response to one of the RFC 2086 commands) in favor of
extensions to the LIST response.  The advantage with using the LIST
response is that the base level specification already has the framework in
place for such extensions; all you have to do are a few minor tweaks to
the ACL responses to make them comply with that framework.

Here's how the RFC 2086 response examples would look in ACLPLUS
        * ACL INBOX Fred rwipslda
=>      * LIST (\NoInferiors \ACL:Fred=rwipslda) "" INBOX

        * LISTRIGHTS ~/Mail/saved smith la r swicd
=>      * LIST (\NoInferiors \RIGHTS:smith=la_r_swicd) "" INBOX

        * MYRIGHTS INBOX
=>      * LIST (\NoInferiors \MYRIGHTS=rwipslda) "" INBOX

Of course, these could be combined in a single LIST response.  This opens
up the other pending issue of LIST command extensions, but I think that
LIST responses can be extended independently.

Date: Tue, 30 May 2000 08:20:10 +0200
To: Pete Resnick <[email-masked]>, Mark Crispin <[email-masked]>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>
Subject: Re: On the nature of WG discussion (Was: I-D  ACTION:draft-ietf-imapext-acl-00.txt)
Cc: [email-masked]
Sender: [email-masked]

At 00.25 -0500 00-05-30, Pete Resnick wrote:
>Again, if the WG consensus is that we'd get more done if 2086 were 
>made Historic (and you may choose to try to convince the WG of 
>this), I'm perfectly happy to go to the IESG. Personally, at this 
>point I think it's a waste of time to pursue and we'd be better off 
>concentrating on what we want in the current ACL document.

An RFC doesn't have to be made historic for "errors to be corrected". 
One can publish a new RFC which updates the older one, or replaces it.

As Pete states, we have the IETF wide last call and the appeals 
process for exactly the reasons mentioned.

FWIW: I do agree with Pete when he states that looking at the current 
document is what you should do.

     Patrik
     Area Director, Applications Area

Date: Tue, 30 May 2000 00:25:20 -0500
To: Mark Crispin <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: On the nature of WG discussion (Was: I-D ACTION:draft-ietf-imapext-acl-00.txt)
Cc: [email-masked]
Sender: [email-masked]

I think Steve Hole's last message is a good starting place for 
discussion of ACL issues; I hope discussion continues from there. 
However, there were some process points in Mark's message that I 
wanted to address: Though I thought about not saying anything, I 
think the answers are worth everyone's time so that we all understand 
how the work in this WG should go.

On 5/26/00 at 11:40 AM -0700, Mark Crispin wrote:

>Are you unaware that there is a team of people here at UW working on 
>email development?  I'm speaking about the concerns of the entire 
>team.
[...and...]
>I don't think that you really mean to say that you go along with 
>whichever organization packs the meeting room with the most number 
>of its employees.

First things first: Nobody in the WG can make claims to speak on 
behalf of larger entities. We are a gathering of individuals and we 
speak as such. That doesn't mean that you can't say things like "The 
folks I work with would really have an easier time implementing if 
the document did A instead of B" or "I've talked to some folks at XYZ 
company or university and they are really not going to like 
implementing A in their client." That's interesting information. 
However, talking about "our opinion of X" or saying "we think Y" 
without saying how you came to the conclusion that you are all of 
this one mind just isn't going to fly.

On the flip side, organizations who try to pack the meeting room with 
employees aren't going to accomplish too much either. If I ask for 
the consensus of the room and I hear a lot of humming but not a lot 
of explanation of why a particular position is correct, and that 
humming all comes from a bunch of people working on the same 
implementation, I take it for what its worth, which amounts to about 
1 person. This is about a consensus of technical opinion, not a count 
of heads. Of course, if two well reasoning people are disagree and 
one has done a widely deployed implementation and the other hasn't 
written a line of code, the former person will have a little more 
weight behind them.

I hope both of these points are obvious, but I wanted to make sure 
that people understood where I am at.

>>We have by no means had sufficient discussion IN THIS WORKING GROUP 
>>to determine whether your concerns *won't* be addressed.
>
>The past three and a half years worth of discussion is to be started 
>over from the beginning?

No, but the content of previous discussions need to be brought into 
this WG and we need to see whether this particular gathering of folks 
(some of whom are new to the discussion) will turn in a different 
direction from the one that does not address your concerns. I think a 
very short period of time will tell.

Now, a few things on this last section:

>Will you request IESG to withdraw RFC 2086 from Proposed Standard 
>status, so that a clean start can be made?

I won't request anything of the IESG at this point. First of all, I'm 
in no position personally to do that; I speak for the WG in this 
capacity. To that end, so far it seems that the WG wants the ACL 
draft to correct problems in 2086 and advance it. I have not heard 
from the WG that they want to move 2086 to Historical and start again 
with a new Proposed Standard. If I start to hear that, I will of 
course take that feedback to the IESG.

>UW did not approve RFC 2086. It should never have gotten on standards-track.

As far as I know, UW has no standing to approve or disapprove 
anything. Certainly no single person has approval power in the IETF, 
and organizations have no formal standing whatsoever. This kind of 
statement holds no weight with me at all.

Now, certainly there was an IESG last call on 2086 before its 
release. If you and other folks you work with at UW thought that 2086 
did not belong on the standards track for technical reasons, you had 
an opportunity to voice your opinion at that time. If you felt that 
your opinions were unjustly disregarded by the IESG, or that the 
approval was ram-rodded without having an opportunity to make your 
opinions known, there is a clear appeals process in the IETF.  I do 
not think, however, that rehashing a 3 1/2-year old decision in this 
forum does anything to advance our work.

Again, if the WG consensus is that we'd get more done if 2086 were 
made Historic (and you may choose to try to convince the WG of this), 
I'm perfectly happy to go to the IESG. Personally, at this point I 
think it's a waste of time to pursue and we'd be better off 
concentrating on what we want in the current ACL document.

pr
-- 
Pete Resnick <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102

From: Steve Hole <[email-masked]>
Date: Mon, 29 May 2000 15:01:47 -0600
To: John Gardiner Myers <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt
Cc: [email-masked]
Sender: [email-masked]

On Fri, 26 May 2000 10:53:30 -0700 John Gardiner Myers 
<[email-masked]> wrote:

> 
> After much thought, confirmed by discussion at Adelaide, I've concluded
> that Mark's concerns are best addressed by his pursuing a separate
> extension.  The models of access control are sufficiently different that
> an extension trying to address both (or all) models will necessarily be
> over complex and difficult to implement on the client side.

Having read through the thead,  I think Mark's proposals could be broken 
into three areas:

(1)   The interpretation of various rights identifiers.

(2)   The definition/management of identifiers.

(3)   Rights inheritance.

I say think, because the discussion rolled out over several messages and 
it was hard to pull it together.    I am sorry Mark if I have 
misrepresented or forgotten something.

I would say the (1) and (3) are very germane to any ACL model and bear
serious discussion for the draft at hand.   We have had trouble with (1) 
ourselves and I think that it should be fairly easy to come to concensus 
on.   

Inheritance (3) will be a very interesting discussion, but because 
formalization of it is a "new thing" we *should* be able to converge on 
that as well.

I think that (2) (identifier theory) is where we are going to run aground.
A flexible identifier theory and semantic strikes me as being a strategy 
much like flexible hierarchy notation.     This scares me.  Putting on my 
client developer hat, I would opt for the "one true semantic" for
identifiers.    It just seems so much easier to implement and to create UI
for.    It is easier to explain to users.    Of course, the definition for
the "one true semantic" is up for discussion.    We should not settle for 
a compromise the way we did last time, because it clearly led to 
interoperability problems.

If the chain of events for folder hierarchy design repeats itself with ACL 
identifiers, then I expect that we will very quickly get to a discussion on
what the "service is able to express" versus what the "client wants to 
see".   I will be very clear about this.    It was collosal mistake to 
select in favour of the "what the server is able to express" model for 
hierarchy and we should not make the same mistake for ACL identifiers.    
We should select for ease of use in the client in this situation.    The 
model to be chosen can be debated, but there must be only one in the end. 
If may be true that there is a simple representation that has the 
flexibility required -- great!    We won't know that until we have seen 
the various options.

Mark.   I encourage you to post the fragments of your proposal to the 
working group mailing list prior to posting a draft.     It would be very 
useful to look at the specifics without waiting for the process.    As you
have noted, it has been too long already.   I for one would be very 
interested in seeing the identifier model in some detail. 

I would also like to see the detailed discussion these three areas (or 
more if there are more) broken into separate threads.   It is a little 
taxing to try to deal with the conceptual issues behind all three at once.

Cheers.
---
Steve Hole
Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

From: Steve Hole <[email-masked]>
Date: Mon, 29 May 2000 13:45:44 -0600
To: Cyrus Daboo <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt
Cc: [email-masked]
Sender: [email-masked]

On Sat, 27 May 2000 13:12:11 -0400 Cyrus Daboo <[email-masked]> wrote:

> 9) One other behaviour that I would like to see added as a SHOULD 
> requirement on the server:
> 
> 'The server SHOULD issue an untagged MYRIGHTS response (as a 
> response-cond-state [IMAP4] response) when a client issues the SELECT or 
> EXAMINE command for a mailbox when the ACL extension is present'

This would be a *very* nice thing to do.

---
Steve Hole
Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

Date: Sat, 27 May 2000 13:12:11 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt
Sender: [email-masked]

Here are some issues related to the ACL draft:

1) [IMAP4] reference points to RFC1730 but should point to RFC2060.

2) In section 3, the 'r' right should also be tied to the STATUS command.

3) Does not having the 'l' right mean that any mailbox operations are 
denied? For example if the 'l' right is missing, but the 'r' right is 
present, can a client still issue a SELECT on the mailbox? It might not 
'see' the mailbox but it might know it exists. I think this needs to be 
made clear. Also how do the SUBSCRIBE and UNSUBSCRIBE commands tie in with 
this? Are they tied to the 'l' right or the 'r' right?

4) Since its possible to set flags in the APPEND command there needs to be 
a discussion of how the 'w' and 'i' bits interact, or at least the 
description for 'w' should also indicate that setting the flag via APPEND 
is also controlled via that right.

5) Right now 2060 mandates that a server send [READ-ONLY] or (optionally) 
[READ-WRITE] responses during a SELECT or EXAMINE. Which rights are these 
tied to? For example, if the 'w' write exists (i.e can change flags other 
than delete) but the 'd' right does not exist (can't delete or expunge) is 
the mailbox read-only or read-write? This actually affects the behaviour of 
non-ACL aware clients. ACL-aware clients are going to be smart enought to 
figure out the correct behaviour based on what the current users rights are 
to a mailbox, but non-ACL clients can only base their behaviour from the 
read-only/read-write responses.

6) As a reminder to implemetors, I think there needs to be a statement that 
the FLAGS and PERMANENTFLAGS responses as part of the SELECT command should 
accurately reflect the current user's rights.

7) I think the behaviour of the 'l' with respect to mailbox hierarchies 
needs to be explained more. Specifically what happens in the case where a 
user has the 'l' right to mailbox 'A/A' but not to mailbox 'A'? Should 
'A/A' be returned in LIST or should the absence of the 'l' right on the 
parent mailbox allow a server to not bother looking for 'l' rights on the 
child mailboxes.

8) One thing that has come from our (now three years of) experience of 
doing ACLs in Mulberry is that users frequently want to take a set of ACLs 
on one mailbox and apply those to another mailbox, or mailboxes, e.g. 
'propagation' of rights from one mailbox to its child hierarchy. Right now 
a client has to do this by issuing multiple DELETEACL and SETACL commands 
for each mailbox in the list. This is very inefficient.

What I would like to see is a new REPLACEACL command that takes a mailbox 
spec, similar to the LIST command, and a list of identifier-rights pairs. 
This command would remove all the existing rights on the matching mailboxes 
and then add all the rights specified in the command. This effectively 
'propagates' a set of rights to a group of mailboxes in a single command.

9) One other behaviour that I would like to see added as a SHOULD 
requirement on the server:

'The server SHOULD issue an untagged MYRIGHTS response (as a 
response-cond-state [IMAP4] response) when a client issues the SELECT or 
EXAMINE command for a mailbox when the ACL extension is present'

I don't know about other clients, but we always issue a MYRIGHTS command 
after doing a SELECT or EXAMINE in order to figure out what UI items need 
to be enabled or disabled on the newly opened mailbox, e.g. 
enabling/disabling or certain flag commands based on the 'w' right. Having 
MYRIGHTS sent as an untagged response to SELECT or EXAMINE would remove the 
need for the extra command from the client. I would suggest that most 
ACL-aware clients are going to want MYRIGHTs on mailboxes they select so 
this would be a welcome change.

-- 
Cyrus Daboo

Date: Fri, 26 May 2000 11:40:53 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt
To: Pete Resnick <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Fri, 26 May 2000 13:18:13 -0500, Pete Resnick wrote:
> As you no doubt know, the working group was only recently chartered.
> There have been several things delayed because of that. I now fully
> believe that we are moving along with work.

I remain skeptical.  I was extremely disappointed by the lack of progress in
Oslo and DC.

Not to mentioned being told, over and over again, that RFC 2086 is cast in
stone, and that the only problem was my environment is "obsolete" and not
worth worrying about.

> >We were promised over a year ago that our concerns with ACL would be
> >addressed.
> Who is "we"?

Are you unaware that there is a team of people here at UW working on email
development?  I'm speaking about the concerns of the entire team.

> To date, the only person I have heard on these issues is
> you.

I don't think that you really mean to say that you go along with whichever
organization packs the meeting room with the most number of its employees.

> There was consensus in the room at Australia that requiring ACLs to
> strictly conform to Unix semantics was potentially damaging to the
> protocol and that we should stick to solving the problems in the
> currently deployed base.

Nobody ever said "require ACLs to strictly conform to Unix semantics".  That's
a strawman with no purpose other than to be burned down.

If you want me to take this discussion seriously, don't use such strawmen.

> We have by no means had sufficient
> discussion IN THIS WORKING GROUP to determine whether your concerns
> *won't* be addressed.

The past three and a half years worth of discussion is to be started over from
the beginning?

> As far as we should all be concerned, the clock has only
> now started ticking.

Will you request IESG to withdraw RFC 2086 from Proposed Standard status, so
that a clean start can be made?  UW did not approve RFC 2086.  It should never
have gotten on standards-track.

I've heard the excuse of "RFC 2086 is standards-track and it's too late to
change the framework now" too many times in the past three years.  There's no
point in further discussion as long as that excuse remains.

> I look forward to discussion of these items. If there are more
> issues, bring them up now.

OK:

Other than inheritance and the problem with the "c" right, the system of
rights is more or less acceptable.

To recap:
1) there needs to be a "+" prefix (or suffix, I don't really care) which
stipulates that the rights are to be inherited as described in the new I-D.
Otherwise, another applicable identifier (e.g. the user name) can override the
rights.  Actually, the "+" means "mandatory application without override".
The I-D insists that mandatory application is the only way, which means that
there is no way to "disable access for everybody in a group except for one
user".
2) Delete and rename mailbox needs to be separate; perhaps an "x" right since
it insists upon this alphabet soup of one letter codes.

A minor nit is the "d" right; it should not specify "perform EXPUNGE".  But I
think that I can just ignore that part without breaking things.

Given that IMAP is so chatty otherwise and the ACL commands don't allow
wildcards, the alphabet soup makes little sense; but since I plan to allow
wildcards in ACLPLUS I'm willing to leave this alone.

The primary problem with RFC 2086 is that the system of identifiers in ACLs is
inflexible.  We don't need a specific "change owner" and "change group"
operation.  We just need identifier semantics that can represent those
operations.  This is best done by a general purpose mechanism to define
certain forms of identifiers, and to query the definition of an identifier.

This new theory of identifiers is the beating heart of ACLPLUS.  It defines
the semantics of $xxx identifiers, and it adds two operators: one to define a
$xxx identifier, and one to query its definition.

Less important is a redesign of the commands and responses, with the RFC 2086
commands/responses retained for compatibility.  The new commands and responses
are considerably more powerful than RFC 2086.  However, this is a completely
secondary agenda; although it's a better design it's not crucial for the
functionality.

> Let's start with trying to address the issues in
> the current framework and move on from there.

The current framework is broken.

I do not purpose to create a framework that is hopelessly biased towards
another model.  Instead, I purpose to create a framework that encompasses both
models in a clean and well-defined manner.

I've been told repeatedly that it is not possible, and shouldn't be done.  It
seems that the only way that I can prove otherwise is by doing it.

> You releasing a competing draft at this point will
> inevitably slow our work down, and potentially lead to the above
> horrors.

I'm sorry that's it's come to this, but I have yet to hear anything that will
change it.

> So, may
> I assume that you put your work on hold until we have had some
> further discussion in the WG?

Unfortunately, the answer is no.  It's been held off for three and a half
years.  That's long enough.

I've been very patient.  Unfortunately, it seems that the only way to make
progress happen is for me to proceed.

Until/unless there is  concrete progress towards addressing our issues, , my
work will proceed.

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-imapext
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt
Date: Fri, 26 May 2000 12:25:42 -0700
Organization: Netscape Communications Corporation
Lines: 78
NNTP-Posting-Host: 192.18.126.70
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms076459EEC1E6830A8B1F22CE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Pete Resnick wrote:
> Having 2 ACL extensions does not enhance interoperability.

In this case, having two extensions can enhance interoperability.

Part of the reason the ACL draft has been delayed is that Mark had
comments I did not know how to address without creating an
overcomplicated mess.  Mark has stated that he wants to expose all
semantics of Unix file permissions, including the "change owner" and
"change group" operations.

An extension that allows servers to expose all of the Unix file
permission semantics and also allows servers to expose all of the ACL
semantics implemented by the Cyrus server will also allow a whole range
of intermediate semantics, with some aspects from Unix and some aspects
from the original ACL.  A conforming client would be required to be able
to deal with all of these and would have a difficult time figuring out
what the rules are on any particular server.

Two extensions would cut out all of the intermediate states, simplifying
clients and allowing them to know which type of server they are talking
to.
--------------ms076459EEC1E6830A8B1F22CE
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms076459EEC1E6830A8B1F22CE--

Date: Fri, 26 May 2000 11:28:24 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt
To: John Gardiner Myers <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Fri, 26 May 2000 10:53:30 -0700, John Gardiner Myers wrote:
> After much thought, confirmed by discussion at Adelaide, I've concluded
> that Mark's concerns are best addressed by his pursuing a separate
> extension.

Thank you, John.

Given that I purpose to create an upwards-compatible extension to RFC 2086,
would you give careful consideration to the following in your I-D:
 1) The two issues that I addressed in your latest I-D which will break
    compatibility (inheritance and the "c" right).  I think that the change to
    inheritance in the I-D is a bad enough move that, if unfixed, it would
    accellerate the withering away of ACL in favor of ACLPLUS.  The "c" right
    issue is less serious, but it would be a needless incompatibility.
 2) Changing the defintion of $xxx to be "reserved" instead of the current
    poorly-defined "group".
 3) Maintaining compatibility otherwise, so as not to preclude the possibility
    of a reunification.
 4) Possible wording in your document that says that any capability that
    starts with ACL is compatible with ACL (e.g. what is done with SORT) to
    promote interoperability.

> The models of access control are sufficiently different that
> an extension trying to address both (or all) models will necessarily be
> over complex and difficult to implement on the client side.

As you should know by now, I strongly disagree with this conclusion.  However,
the only way that I can prove my position is by delivering the goods, and I
shall proceed to do so.

I believe that presently you'll find that the additions in ACLPLUS are
sufficient desirable that you will decide to implement it after all.

Date: Fri, 26 May 2000 13:18:13 -0500
To: Mark Crispin <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt
Cc: [email-masked]
Sender: [email-masked]

On 5/26/00 at 12:19 AM -0700, Mark Crispin wrote:

>The working group has been ineffective up to now.  The lack of 
>progress has been remarkable.

As you no doubt know, the working group was only recently chartered. 
There have been several things delayed because of that. I now fully 
believe that we are moving along with work. Indeed, at each of the 
face-to-face meetings we have had as a BOF, we have made great 
progress on resolving many issues.

>So have some rather crude politics; I'll remind you that IMAPEXT has 
>not even permitted the SORT and THREAD I-D's to come out with a 
>"draft-ietf-imapext" file name.

Mark, as you full well know, given my message to you (which you 
replied to) of 8/18/99, message id 
<[email-masked]>, there were no crude 
politics involved here at all: As I explained, I was away on vacation 
when Natalia sent me the message asking whether these drafts could be 
under the working group. When I returned (the day I sent you the 
message), I sent her a message asking her to rename the drafts. I am 
quite sure that she would be happy to put them under the working 
group name if you resubmitted the documents.

I think you should follow the general guideline that ad hominem 
attacks like this should be kept out of the working group 
discussions. If you want to accuse me of doing something malicious, 
take it to private mail. In this case, you are wrong in your 
assessment.

>We were promised over a year ago that our concerns with ACL would be 
>addressed.

Who is "we"? To date, the only person I have heard on these issues is 
you. One person does not a consensus make. If there are others 
involved here, I would like their comments to appear on the mailing 
list as well.

>Yet, at the last IETF in Australia, the document editor stated that 
>those concerns weren't going to be addressed by ACL.

There was consensus in the room at Australia that requiring ACLs to 
strictly conform to Unix semantics was potentially damaging to the 
protocol and that we should stick to solving the problems in the 
currently deployed base. However, if you have specific issues that 
you want addressed, either post them to the list or send them 
directly to the document editor. We have by no means had sufficient 
discussion IN THIS WORKING GROUP to determine whether your concerns 
*won't* be addressed.

>The current document editor has stonewalled for three years. Time has run out.

Nonsense. (1) I do not want these personal attacks in the working 
group. (2) The current document editor has only now gotten out the 
-00 draft. As far as we should all be concerned, the clock has only 
now started ticking.

Now, you have identified two issues that the working group should address:

>...mandatory rights inheritance, with no way to override an 
>inherited negative right

>...overloading of "c" to mean "can create inferiors" and "can delete 
>this mailbox"...

>I have offered suggestions for how these problems in the new I-D can 
>be resolved.

I look forward to discussion of these items. If there are more 
issues, bring them up now.

>Doing so would maintain some semblance of compatibility between ACL 
>and ACLPLUS.  It would also keep the door open for a reunification.

"Reunification" is not a desirable goal. The premise is 
"disunification". Let's start with trying to address the issues in 
the current framework and move on from there.

>The design of ACLPLUS is almost finished.  It will happen.  I prefer 
>that IMAPEXT be willing to adopt these extensions into a single ACL 
>specification as optional ACL facilities.
>
>If not, there will be two specifications.

This is exactly the kind of hostile stonewalling you are arguing we 
should not be doing. You are one voice among many. Make your voice 
heard and convince others that your concerns are valid. Do not 
attempt to strongarm people. It is destructive and has no place in 
this discussion.

>If, on the other hand, the hostile stonewalling continues, we'll end 
>up with interoperability problems.  We'll have egg on our collective 
>faces.  The trade rags will have a field day.

I agree. So let's stop. John has released his first draft. You have 
made comments. Both of those are constructive moves in the correct 
direction. You releasing a competing draft at this point will 
inevitably slow our work down, and potentially lead to the above 
horrors. Let's do some work over these next 2 months and see where we 
are, not change direction when we're barely out of the gate.

>Even at this stage, it isn't too late; but time is running out.

I'm glad to hear that at least you believe it isn't too late. So, may 
I assume that you put your work on hold until we have had some 
further discussion in the WG?

>If there is a serious intention to resolve these differences 
>constructively, I am willing to arrange a face-to-face meeting with 
>the interested parties here in Seattle.

Let's go on the assumption that there is a serious intention to 
resolve these differences constructively. We only have 2 months until 
we meet in Pittsburgh. Let us try to work through these issues on the 
list. If we cannot, we can use the face-to-face meeting in Pittsburgh 
to resolve differences. Is that acceptable? I have been on the road 5 
of the past 9 weeks and I (and my significant other) would really 
prefer that I not travel between now and then.

pr
-- 
Pete Resnick <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102

Date: Fri, 26 May 2000 13:18:08 -0500
To: John Gardiner Myers <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt
Cc: [email-masked]
Sender: [email-masked]

On 5/26/00 at 10:53 AM -0700, John Gardiner Myers wrote:

>I've concluded that Mark's concerns are best addressed by his 
>pursuing a separate extension.

I would like to hear further discussion on this point from other 
members of the working group. Having 2 ACL extensions does not 
enhance interoperability. My inclination is to try to get something 
that will satisfy both sets of concerns rather than have competing 
documents. If that can't be done to either side's satisfaction, we 
can revisit the issue later. However, Mark has made some comments on 
the document; I encourage him (and others) to make more. Let's see if 
there is consensus (either positively or negatively) on what to do 
about them before we start making decisions about new extensions.

I can almost assure you that the IESG will not accept two ACL 
documents from this WG; my guess is that they won't accept any 
document while there are two competing documents in existence.

pr
-- 
Pete Resnick <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-imapext
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt
Date: Fri, 26 May 2000 10:53:30 -0700
Organization: Netscape Communications Corporation
Lines: 64
NNTP-Posting-Host: 192.18.126.70
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms7F155AEDA087592CCD3AAFC5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

After much thought, confirmed by discussion at Adelaide, I've concluded
that Mark's concerns are best addressed by his pursuing a separate
extension.  The models of access control are sufficiently different that
an extension trying to address both (or all) models will necessarily be
over complex and difficult to implement on the client side.

Better each model have its own extension.  Then the client will know
which world the server is in and will not have to deal with hybrid
models that don't exist in practice.
--------------ms7F155AEDA087592CCD3AAFC5
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms7F155AEDA087592CCD3AAFC5--

Date: Fri, 26 May 2000 00:19:01 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt
To: Pete Resnick <[email-masked]>
cc: Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

On Fri, 26 May 2000 01:17:06 -0500, Pete Resnick wrote:
> To do
> so would undermine the effectiveness of the working group and would
> leave the potential for huge interoperability problems in the future.

Unfortunately, the time to have worried about this has passed.

The working group has been ineffective up to now.  The lack of progress has
been remarkable.  So have some rather crude politics; I'll remind you that
IMAPEXT has not even permitted the SORT and THREAD I-D's to come out with a
"draft-ietf-imapext" file name.

We were promised over a year ago that our concerns with ACL would be
addressed.  Yet, at the last IETF in Australia, the document editor stated
that those concerns weren't going to be addressed by ACL.

> However, I strongly suggest that you not produce a different document
> unless and until *both* (a) there is no sign of coming to an
> agreement with the current document editor *and* (b) the working
> group decides that we need another document to compare to.

Unfortunately, this is no longer possible.  The current document editor has
stonewalled for three years.  Time has run out.  The working group can take
the lead on our effort; it can follow our effort; or it can ignore our effort;
but it can no longer stand in the way.

I know what I would counsel, but it's your decision.

The new I-D is much worse than RFC 2086.  The requirement in the new I-D for
mandatory rights inheritance, with no way to override an inherited negative
right, is a non-starter and (in my opinion) a terrible idea.  I can't believe
that it is seriously proposed.  It doesn't affect Cyrus; Cyrus doesn't have
groups.  It affects me to the point that it blocks my implementation.

Similarly, overloading of "c" to mean "can create inferiors" and "can delete
this mailbox" is also a non-starter.  These are independent rights in my
world.  I can't implement this overloading.

I have offered suggestions for how these problems in the new I-D can be
resolved.  Doing so would maintain some semblance of compatibility between ACL
and ACLPLUS.  It would also keep the door open for a reunification.

The design of ACLPLUS is almost finished.  It will happen.  I prefer that
IMAPEXT be willing to adopt these extensions into a single ACL specification
as optional ACL facilities.

If not, there will be two specifications.  Even then, the situation can still
be salvaged, with face-saving for all.  It just requires a sincere effort to
maintain upwards compatibility from ACL to ACLPLUS: ACL must not do anything
that breaks ACLPLUS, and ACLPLUS must remain a proper superset of ACL.  There
are no technical barriers; it just requires will.  If there's a lack of will,
it isn't on my part.

If, on the other hand, the hostile stonewalling continues, we'll end up with
interoperability problems.  We'll have egg on our collective faces.  The trade
rags will have a field day.  If that happens, so be it.

I'm sorry that it has come to this.  I did not want it.  I've spent three
years trying to resolve this, and getting repeatedly rebuffed.

I still do not want it.  There are positive steps that you can take to remedy
the situation.  I have seen no sign yet.  All I've seen are endless delays on
everything we want, while certain other agendas are rammed through.

Even at this stage, it isn't too late; but time is running out.

I hope to hear a positive answer.

If there is a serious intention to resolve these differences constructively, I
am willing to arrange a face-to-face meeting with the interested parties here
in Seattle.

-- Mark --

Date: Fri, 26 May 2000 01:17:06 -0500
To: Mark Crispin <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt
Cc: Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

In my role as chair:

On 5/25/00 at 7:46 PM -0700, Mark Crispin wrote:

>I am working on an upwards-compatible replacement for ACL called ACLPLUS which
>addresses these (and other) deficiencies.  Any RFC 2086 implementation will be
>able to talk to an ACLPLUS implementation, although the function set will be
>limited to what RFC 2086 supports.
>
>I urge that action be deferred until I have a chance to produce an Internet
>Draft containing my ACLPLUS specification.

I'm sorry, but I don't find this course of action acceptable. The 
working group has identified a document editor, and that document 
editor has produced a -00 version for this draft. In my mind, -00 
means this is a first cut. Mark, you (and others) have made some 
comments, and I expect the editor to address those comments, either 
by making changes to the document to satisfy you (or more importantly 
a rough consensus of the working group with or without you), or to 
convince us that the current text is sufficient. In either case, this 
is something that the working group's designated editor needs to do 
without the threat of someone running off and writing some other 
competing document outside of the scope of this working group. To do 
so would undermine the effectiveness of the working group and would 
leave the potential for huge interoperability problems in the future.

If you wish to submit suggested text to the document editor for how 
you think these issues should be addressed, I encourage you to do so. 
However, I strongly suggest that you not produce a different document 
unless and until *both* (a) there is no sign of coming to an 
agreement with the current document editor *and* (b) the working 
group decides that we need another document to compare to. Neither of 
those criteria are currently satisfied.

pr
-- 
Pete Resnick <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102

Date: Thu, 25 May 2000 21:25:30 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt
To: Lawrence Greenfield <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Fri, 26 May 2000 00:09:55 -0400 (EDT), Lawrence Greenfield wrote:
> Why should group management be part of IMAP?

That's like asking "why should ACL management be part of IMAP?".

First of all, it's wrong to think in terms of groups.  Think in terms of
defined identifier sets.  A "group" is simply one type of defined identifier
set.

> What is problematic about it?  It's a straightforward algorithm to
> implement in deciding whether to grant or deny rights.

It is problematic because it does not express an existing valid access
configuration, in which an identifier (containing a user) is exempted from a
negative right applied to another identifer (also containing that user).

> The proposed modification complicates semantics significantly.  Is
> there operational experience that this level of flexibility is needed?

Yes.  Existing protection codes which I have today behave this way.

> I think this draft fixes a number of known problems with the current
> ACL extension in a compatible, straightforward way.

This draft contains a set of four trivial changes.  One change is mandated by
IAB; one change is a handwave; and the last two changes are bugs.

Yes, the overloading of the "c" right for mailbox deletion is also a bug.
First, it is ambiguous about what can be deleted: it should be the mailbox
itself (not inferiors) but that needs to be stated.  Also, the ability to
create inferiors does not necessarily mean the ability to delete the mailbox.

We need a separate "x" right for mailbox deletion.

It doesn't really matter now, since ACLPLUS is going to happen.  After three
years of being stonewalled, time has run out.

Date: Fri, 26 May 2000 00:09:55 -0400 (EDT)
From: Lawrence Greenfield <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt
Sender: [email-masked]

   Date: Thu, 25 May 2000 19:46:45 -0700 (PDT)
   From: Mark Crispin <[email-masked]>

[...]
   PROBLEM: The group facility doesn't address the problem, and in
   fact creates more problems than it solves; it completely swallows
   the entire $ syntax for a functionality that isn't otherwise
   specified (e.g. how do you manage groups?).

Why should group management be part of IMAP?  Groups logically come
from an authorization server; whether that's an LDAP server sitting
somewhere, or (unfortunately) an AFS PTS server somewhere else, it
really doesn't matter---it's the authorization server's decision
whether an authorization identifier is included in a group.

[...]
   Although removing the ambiguity is a good idea, I question whether
   it's really such a good idea to insist upon inheritance.  In
   particular, the inheritance of negative rights is problematic.

What is problematic about it?  It's a straightforward algorithm to
implement in deciding whether to grant or deny rights.

The proposed modification complicates semantics significantly.  Is
there operational experience that this level of flexibility is needed?

I think this draft fixes a number of known problems with the current
ACL extension in a compatible, straightforward way.

Larry

Date: Thu, 25 May 2000 19:46:45 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt
To: Simon Josefsson <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

I have reviewed the subject Internet Draft.  It's completely inadequate for
the task at hand.  It looks like all the discussion of the past three years
has gone in one ear and out the other.

PROBLEM: The group facility doesn't address the problem, and in fact creates
more problems than it solves; it completely swallows the entire $ syntax for a
functionality that isn't otherwise specified (e.g. how do you manage groups?).

RECOMMENDATION: The draft be modified to reserve names beginning with $ for
use by an extension to ACL.

PROBLEM: Unlike RFC 2086, this new draft requires rights inheritance; that is,
an identifier automatically has the rights of "anyone" unless these are
specifically denied as negative rights.  RFC 2086 allowed implementations to
decide if rights were inherited or not.

Although removing the ambiguity is a good idea, I question whether it's really
such a good idea to insist upon inheritance.  In particular, the inheritance
of negative rights is problematic.

RECOMMENDATION: The draft should be modified to indicate whether or not an
identifier has inheritance semantics.  I suggest using + for this purpose.  In
other words:
	+anyone lr
means that all users can list and read the mailbox unless specifically denied
by a - identifier, whereas:
	anyone lr
means that all users who aren't otherwise listed by an identifier can read and
list the mailbox.  Also, + and - can be combined to cause negative rights
inheritance.

For example
	fred lr -$G$students lr anyone lr
means that everybody except for members of the students group can read and
list; however fred can also read and list even though he's a member of
students.  On the other hand
	+-anyone lr
means that nobody can read or list the file, no matter who (this is what - is
defined to do in the draft).

I am working on an upwards-compatible replacement for ACL called ACLPLUS which
addresses these (and other) deficiencies.  Any RFC 2086 implementation will be
able to talk to an ACLPLUS implementation, although the function set will be
limited to what RFC 2086 supports.

I urge that action be deferred until I have a chance to produce an Internet
Draft containing my ACLPLUS specification.

To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt
From: Simon Josefsson <[email-masked]>
Date: 25 May 2000 14:54:27 +0200
Lines: 15
Sender: [email-masked]

Two little thoughts

. If identifiers starting with dollar signs are reserved for groups,
  why don't describe what "groups" are and how they work too?  I'd
  really like IMAP ACLs on groups of users, but I'm not sure there is
  enough detail to implement it server-independently.

. Perhaps it should be noted in the security considerations that the
  ACL evaluation now required might breach security if rfc2086-ACL's
  are used in a server implementing this draft?

I dunno much about the draft, or anything, at all, so feel free to
ignore my comments if they doesn't make sense.

(Wasn't there talk of a major re-design of IMAP ACLs?)

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-acl-00.txt
Date: Thu, 25 May 2000 06:35:17 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.

	Title		: IMAP4 ACL extension
	Author(s)	: J. Myers
	Filename	: draft-ietf-imapext-acl-00.txt
	Pages		: 9
	Date		: 24-May-00
	
The ACL extension of the Internet Message Access Protocol [IMAP4]
permits access control lists to be manipulated through the IMAP
protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-acl-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imapext-acl-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-acl-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-acl-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-imapext-acl-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

From: "Charlie Fletcher - www.ukdata.com" <[email-masked]>
To: "Finance Director" <[email-masked]>
Subject: Instant On-Line Credit Reports
Date: Tue, 9 May 2000 16:34:00 +0100
Sender: [email-masked]

Do you need fast accurate information to assist you when appraising
potential customers, and suppliers?

The UK Data internet website www.ukdata.com contains 28 million pages of
data with full information on every UK company!

Credit Reports-Director Searches-Accounts-Annual Returns

All of these products and many more are available to you immediately, and
can be downloaded to and printed from your personal computer.

Free samples of all reports are available at www.ukdata.com.

Please also visit www.formacompany.co.uk the on-line company formation
website

Thank You

Charles Fletcher
www.ukdata.com an instant report on every UK business
www.formacompany.co.uk the on-line company formation site
www.irishdata.ie - instant reports on all Irish companies

Date: Wed, 31 May 2000 19:48:09 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt
To: Cyrus Daboo <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Wed, 31 May 2000 15:16:49 -0700, Cyrus Daboo wrote:
> >> 'The server SHOULD issue an untagged MYRIGHTS response
> > I agree completely, but you can't do this in the RFC 2086 framework,
> > because a base level IMAP client would complain about getting a MYRIGHTS
> > response.
> Not if its a resp-cond-state:
> * OK [MYRIGHTS lrwia] myrights ACL response

Well, yes and no.

Yes, that is certainly valid in the base spec.  No, because a resp-cond-status
of MYRIGHTS is different from an RFC 2086 MYRIGHTS response.

That seems to be splitting hairs, but it means we'd have two ways of doing the
same response forever, unless the untagged MYRIGHTS response is deprecated in
favor of the resp-cond-state.  That might be a good idea, actually; it could
be carried in the tagged OK response for the MYRIGHTS command and not use an
untagged response at all.

However, I still contend that leveraging off the LIST response would be a
better idea.  It could be useful for the client to get \NoInferiors state at
SELECT time; and there's a lot more that could be delivered as well.

There's another reason why I advocate a LIST response; I think that the
current GETACL, LISTRIGHTS, and MYRIGHTS commands should be deprecated in
favor of an extended form of LIST.  That way, we could use wildcards, and
avoid the current situation where a client does a LIST then a MYRIGHTS for
each returned mailbox.

PS: Ofhand observation: the interesting rights at SELECT time are lipca.  The
client can infer r from being able to select, and swd from PERMANENTFLAGS.

Date: Wed, 31 May 2000 15:16:49 -0700
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt
Sender: [email-masked]

--On Wednesday, May 31, 2000 3:10 PM -0700 Mark Crispin 
<[email-masked]> wrote:

>> 'The server SHOULD issue an untagged MYRIGHTS response (as a
>> response-cond-state [IMAP4] response) when a client issues the SELECT or
>> EXAMINE command for a mailbox when the ACL extension is present'
>
> I agree completely, but you can't do this in the RFC 2086 framework,
> because a base level IMAP client would complain about getting a MYRIGHTS
> response.

Not if its a resp-cond-state:

a SELECT INBOX
...
...
* OK [MYRIGHTS lrwia] myrights ACL response
a OK

>From what I see in RFC2060 'resp_text_code' is designed so clients should 
accept data not defined in the base-spec.

-- 
Cyrus Daboo

Date: Wed, 31 May 2000 16:37:57 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Steve Hole <[email-masked]>
cc: John Gardiner Myers <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Mon, 29 May 2000, Steve Hole wrote:
> I think that (2) (identifier theory) is where we are going to run aground.
> A flexible identifier theory and semantic strikes me as being a strategy
> much like flexible hierarchy notation.     This scares me.

Let's be clear on this.  I don't intend that "UNIX owner" or "UNIX group"
be defined as such in ACL.  Rather, it should be possible to express these
concepts as part of a general (not flexible!) mechanism.

By general, I mean "a mechanism whose ideal state is full implementation"
as opposed to "flexible" which means "a mechanism which expresses
contradictory models, and therefore would never be fully implemented."

Hierarchy is "flexible"; what I propose for identifiers is "general".

My idea basically boils down to this:
 1) a mechanism to define identifiers: global, per-mailbox, and perhaps
    also per-user (I don't need the last one, but perhaps other people
    do).  Defined identifiers can be defined in terms of other
    defined identifiers.
 2) a system of naming that makes the type of identifier unambiguous.
 3) a mechanism to look up (expands) the definition of a defined
    identifier.

The impact of this is:
 . definition of identifier nomenclature
 . command to define an identifier
 . command to get the definition of an identifier

Note that there is no specific "change group" or "change owner"; however,
the necessary functionality is there.  The semantics of other existing ACL
mechanisms can be done the same way.

I also don't think that it's necessary for the specification to enshrine
"owner" or "group" in the UNIX sense, but perhaps it may be good to
document a particular convention for per-mailbox nomenclature of defined
identifiers of these two.

At the specification level, all that should matter is that these
per-mailbox identifiers have ACLs; the per-mailbox identifier that
corresponds to UNIX owner expands to one or more RFC 2086 user name
identifiers, and the per-mailbox identifier that corresponds to UNIX group
expands to a global defined identifier (which in turn expands to one or
more RFC 2086 user name identifiers).

Of course, the server is always permitted to respond NO to an operation
which it does not agree to do.

A separate issue is the lack of an identifier that includes everybody
except for anonymous.  Since excluding anonymous is the normal case, it
doesn't really work well to have negative rights for anonymous on all
ACLs.

> It was collosal mistake to
> select in favour of the "what the server is able to express" model for
> hierarchy and we should not make the same mistake for ACL identifiers.

I don't think that the example of hierarchy really applies here.  In
hierarchy, two models which were fundamentally hostile to each other were
shoehorned together.  In this case, we're talking about extensions to the
existing framework that everybody can implement, and probably would want
to implement.

It is possible to implement RFC 2086 ACL in UNIX now (inheritance and the
"c" right in the draft is a different matter).  The problem is that the
result isn't very useful and/or would give clients unpleasant surprises
(e.g. implicit DELETEACL).  I don't think that you want that.

With these extensions, the only differences would be in what the server
will say OK or NO to.  You wouldn't have the \NoSelect or \NoInferiors
which are specific to how a particular model works.  There would be no
"chgrp" operator, but there would be an operator that I would implement
with chgrp() (and some other server would do it some other way).

Date: Wed, 31 May 2000 16:05:54 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Steve Hole <[email-masked]>
cc: John Gardiner Myers <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt
Organization: Networks & Distributed Computing
Sender: [email-masked]

> Inheritance (3) will be a very interesting discussion, but because
> formalization of it is a "new thing" we *should* be able to converge on
> that as well.

My position is that it is better not to have inheritance at all rather
than the definition in the draft.  If you have inheritance, it is
relatively simple to work around a lack of inheritance in the ACL
specification.

Otherwise, you need a complex specification of how inheritance works;
either by being able to stipulate when inheritance happens or by having a
priority mechanism which indicates when inheritance applies.  The problem
comes in with negative rights.

Consider this example: a particular mailbox is open to anyone except
those who are members of a particular group (overriding anyone inheritance
with a negative right) but user fred who is in that group has access
(overriding the group negative right).  This is something that people want
to do, and it's easy to do in UNIX.  The draft makes it impossible; once a
negative right is acquired through inheritance there's no way to lose it.

I identified some missing functionality in inheritance, but I wouldn't be
at all surprised if someone else finds other missing functionality.  I
don't think that it's possible to make a simple definition of inheritance
that is going to have long-term viability.

I contend that inheritance is a rathole, and an unnecessary one at that.

If, on the other hand, there is no inheritance, then the problem doesn't
exist.  Even better, negative rights can also be deleted from the
specification since all you need to do the equivalent is add an ACL for
the identifier without that right.

Date: Wed, 31 May 2000 16:04:50 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Steve Hole <[email-masked]>
cc: John Gardiner Myers <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Mon, 29 May 2000, Steve Hole wrote:
> (1)   The interpretation of various rights identifiers.
> (2)   The definition/management of identifiers.
> (3)   Rights inheritance.

I think that this is a good summary.  Add a fourth issue:

(4) Structure of ACL commands and (especially) responses.

This relates to things such as issuing automatic ACL responses at SELECT
time; the ability to have wildcards in mailbox names; the ability to
replace the entire ACL and/or redefine ACL for multiple identifiers; the
ability to query potential rights for multiple identifiers.

> We have had trouble with (1)
> ourselves and I think that it should be fairly easy to come to concensus
> on.

I hope so.  Since rights tying exists, it would be better to add a new
right rather than to overload existing rights with semantics that may not
necessarily make sense to tie together.  I'm thinking here about the "c"
right, which should not be overloaded with "delete mailbox".

Date: Wed, 31 May 2000 15:10:30 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Sat, 27 May 2000, Cyrus Daboo wrote:
> What I would like to see is a new REPLACEACL command that takes a mailbox
> spec, similar to the LIST command, and a list of identifier-rights pairs.
> This command would remove all the existing rights on the matching mailboxes
> and then add all the rights specified in the command. This effectively
> 'propagates' a set of rights to a group of mailboxes in a single command.

Yes!  This is one of the important operations I feel is missing in RFC
2086; the current SETACL is actually a "modify ACL" or "add ACL" as
opposed to a "set ACL".  It's one of the things that I want to do in
ACLPLUS.

> 'The server SHOULD issue an untagged MYRIGHTS response (as a
> response-cond-state [IMAP4] response) when a client issues the SELECT or
> EXAMINE command for a mailbox when the ACL extension is present'

I agree completely, but you can't do this in the RFC 2086 framework,
because a base level IMAP client would complain about getting a MYRIGHTS
response.

My idea in ACLPLUS is to deprecate all the existing RFC 2086 responses
(basically, only in response to one of the RFC 2086 commands) in favor of
extensions to the LIST response.  The advantage with using the LIST
response is that the base level specification already has the framework in
place for such extensions; all you have to do are a few minor tweaks to
the ACL responses to make them comply with that framework.

Here's how the RFC 2086 response examples would look in ACLPLUS
        * ACL INBOX Fred rwipslda
=>      * LIST (\NoInferiors \ACL:Fred=rwipslda) "" INBOX

        * LISTRIGHTS ~/Mail/saved smith la r swicd
=>      * LIST (\NoInferiors \RIGHTS:smith=la_r_swicd) "" INBOX

        * MYRIGHTS INBOX
=>      * LIST (\NoInferiors \MYRIGHTS=rwipslda) "" INBOX

Of course, these could be combined in a single LIST response.  This opens
up the other pending issue of LIST command extensions, but I think that
LIST responses can be extended independently.

Date: Tue, 30 May 2000 08:20:10 +0200
To: Pete Resnick <[email-masked]>, Mark Crispin <[email-masked]>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>
Subject: Re: On the nature of WG discussion (Was: I-D  ACTION:draft-ietf-imapext-acl-00.txt)
Cc: [email-masked]
Sender: [email-masked]

At 00.25 -0500 00-05-30, Pete Resnick wrote:
>Again, if the WG consensus is that we'd get more done if 2086 were 
>made Historic (and you may choose to try to convince the WG of 
>this), I'm perfectly happy to go to the IESG. Personally, at this 
>point I think it's a waste of time to pursue and we'd be better off 
>concentrating on what we want in the current ACL document.

An RFC doesn't have to be made historic for "errors to be corrected". 
One can publish a new RFC which updates the older one, or replaces it.

As Pete states, we have the IETF wide last call and the appeals 
process for exactly the reasons mentioned.

FWIW: I do agree with Pete when he states that looking at the current 
document is what you should do.

     Patrik
     Area Director, Applications Area

Date: Tue, 30 May 2000 00:25:20 -0500
To: Mark Crispin <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: On the nature of WG discussion (Was: I-D ACTION:draft-ietf-imapext-acl-00.txt)
Cc: [email-masked]
Sender: [email-masked]

I think Steve Hole's last message is a good starting place for 
discussion of ACL issues; I hope discussion continues from there. 
However, there were some process points in Mark's message that I 
wanted to address: Though I thought about not saying anything, I 
think the answers are worth everyone's time so that we all understand 
how the work in this WG should go.

On 5/26/00 at 11:40 AM -0700, Mark Crispin wrote:

>Are you unaware that there is a team of people here at UW working on 
>email development?  I'm speaking about the concerns of the entire 
>team.
[...and...]
>I don't think that you really mean to say that you go along with 
>whichever organization packs the meeting room with the most number 
>of its employees.

First things first: Nobody in the WG can make claims to speak on 
behalf of larger entities. We are a gathering of individuals and we 
speak as such. That doesn't mean that you can't say things like "The 
folks I work with would really have an easier time implementing if 
the document did A instead of B" or "I've talked to some folks at XYZ 
company or university and they are really not going to like 
implementing A in their client." That's interesting information. 
However, talking about "our opinion of X" or saying "we think Y" 
without saying how you came to the conclusion that you are all of 
this one mind just isn't going to fly.

On the flip side, organizations who try to pack the meeting room with 
employees aren't going to accomplish too much either. If I ask for 
the consensus of the room and I hear a lot of humming but not a lot 
of explanation of why a particular position is correct, and that 
humming all comes from a bunch of people working on the same 
implementation, I take it for what its worth, which amounts to about 
1 person. This is about a consensus of technical opinion, not a count 
of heads. Of course, if two well reasoning people are disagree and 
one has done a widely deployed implementation and the other hasn't 
written a line of code, the former person will have a little more 
weight behind them.

I hope both of these points are obvious, but I wanted to make sure 
that people understood where I am at.

>>We have by no means had sufficient discussion IN THIS WORKING GROUP 
>>to determine whether your concerns *won't* be addressed.
>
>The past three and a half years worth of discussion is to be started 
>over from the beginning?

No, but the content of previous discussions need to be brought into 
this WG and we need to see whether this particular gathering of folks 
(some of whom are new to the discussion) will turn in a different 
direction from the one that does not address your concerns. I think a 
very short period of time will tell.

Now, a few things on this last section:

>Will you request IESG to withdraw RFC 2086 from Proposed Standard 
>status, so that a clean start can be made?

I won't request anything of the IESG at this point. First of all, I'm 
in no position personally to do that; I speak for the WG in this 
capacity. To that end, so far it seems that the WG wants the ACL 
draft to correct problems in 2086 and advance it. I have not heard 
from the WG that they want to move 2086 to Historical and start again 
with a new Proposed Standard. If I start to hear that, I will of 
course take that feedback to the IESG.

>UW did not approve RFC 2086. It should never have gotten on standards-track.

As far as I know, UW has no standing to approve or disapprove 
anything. Certainly no single person has approval power in the IETF, 
and organizations have no formal standing whatsoever. This kind of 
statement holds no weight with me at all.

Now, certainly there was an IESG last call on 2086 before its 
release. If you and other folks you work with at UW thought that 2086 
did not belong on the standards track for technical reasons, you had 
an opportunity to voice your opinion at that time. If you felt that 
your opinions were unjustly disregarded by the IESG, or that the 
approval was ram-rodded without having an opportunity to make your 
opinions known, there is a clear appeals process in the IETF.  I do 
not think, however, that rehashing a 3 1/2-year old decision in this 
forum does anything to advance our work.

Again, if the WG consensus is that we'd get more done if 2086 were 
made Historic (and you may choose to try to convince the WG of this), 
I'm perfectly happy to go to the IESG. Personally, at this point I 
think it's a waste of time to pursue and we'd be better off 
concentrating on what we want in the current ACL document.

pr
-- 
Pete Resnick <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102

From: Steve Hole <[email-masked]>
Date: Mon, 29 May 2000 15:01:47 -0600
To: John Gardiner Myers <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt
Cc: [email-masked]
Sender: [email-masked]

On Fri, 26 May 2000 10:53:30 -0700 John Gardiner Myers 
<[email-masked]> wrote:

> 
> After much thought, confirmed by discussion at Adelaide, I've concluded
> that Mark's concerns are best addressed by his pursuing a separate
> extension.  The models of access control are sufficiently different that
> an extension trying to address both (or all) models will necessarily be
> over complex and difficult to implement on the client side.

Having read through the thead,  I think Mark's proposals could be broken 
into three areas:

(1)   The interpretation of various rights identifiers.

(2)   The definition/management of identifiers.

(3)   Rights inheritance.

I say think, because the discussion rolled out over several messages and 
it was hard to pull it together.    I am sorry Mark if I have 
misrepresented or forgotten something.

I would say the (1) and (3) are very germane to any ACL model and bear
serious discussion for the draft at hand.   We have had trouble with (1) 
ourselves and I think that it should be fairly easy to come to concensus 
on.   

Inheritance (3) will be a very interesting discussion, but because 
formalization of it is a "new thing" we *should* be able to converge on 
that as well.

I think that (2) (identifier theory) is where we are going to run aground.
A flexible identifier theory and semantic strikes me as being a strategy 
much like flexible hierarchy notation.     This scares me.  Putting on my 
client developer hat, I would opt for the "one true semantic" for
identifiers.    It just seems so much easier to implement and to create UI
for.    It is easier to explain to users.    Of course, the definition for
the "one true semantic" is up for discussion.    We should not settle for 
a compromise the way we did last time, because it clearly led to 
interoperability problems.

If the chain of events for folder hierarchy design repeats itself with ACL 
identifiers, then I expect that we will very quickly get to a discussion on
what the "service is able to express" versus what the "client wants to 
see".   I will be very clear about this.    It was collosal mistake to 
select in favour of the "what the server is able to express" model for 
hierarchy and we should not make the same mistake for ACL identifiers.    
We should select for ease of use in the client in this situation.    The 
model to be chosen can be debated, but there must be only one in the end. 
If may be true that there is a simple representation that has the 
flexibility required -- great!    We won't know that until we have seen 
the various options.

Mark.   I encourage you to post the fragments of your proposal to the 
working group mailing list prior to posting a draft.     It would be very 
useful to look at the specifics without waiting for the process.    As you
have noted, it has been too long already.   I for one would be very 
interested in seeing the identifier model in some detail. 

I would also like to see the detailed discussion these three areas (or 
more if there are more) broken into separate threads.   It is a little 
taxing to try to deal with the conceptual issues behind all three at once.

Cheers.
---
Steve Hole
Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

From: Steve Hole <[email-masked]>
Date: Mon, 29 May 2000 13:45:44 -0600
To: Cyrus Daboo <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt
Cc: [email-masked]
Sender: [email-masked]

On Sat, 27 May 2000 13:12:11 -0400 Cyrus Daboo <[email-masked]> wrote:

> 9) One other behaviour that I would like to see added as a SHOULD 
> requirement on the server:
> 
> 'The server SHOULD issue an untagged MYRIGHTS response (as a 
> response-cond-state [IMAP4] response) when a client issues the SELECT or 
> EXAMINE command for a mailbox when the ACL extension is present'

This would be a *very* nice thing to do.

---
Steve Hole
Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

Date: Sat, 27 May 2000 13:12:11 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt
Sender: [email-masked]

Here are some issues related to the ACL draft:

1) [IMAP4] reference points to RFC1730 but should point to RFC2060.

2) In section 3, the 'r' right should also be tied to the STATUS command.

3) Does not having the 'l' right mean that any mailbox operations are 
denied? For example if the 'l' right is missing, but the 'r' right is 
present, can a client still issue a SELECT on the mailbox? It might not 
'see' the mailbox but it might know it exists. I think this needs to be 
made clear. Also how do the SUBSCRIBE and UNSUBSCRIBE commands tie in with 
this? Are they tied to the 'l' right or the 'r' right?

4) Since its possible to set flags in the APPEND command there needs to be 
a discussion of how the 'w' and 'i' bits interact, or at least the 
description for 'w' should also indicate that setting the flag via APPEND 
is also controlled via that right.

5) Right now 2060 mandates that a server send [READ-ONLY] or (optionally) 
[READ-WRITE] responses during a SELECT or EXAMINE. Which rights are these 
tied to? For example, if the 'w' write exists (i.e can change flags other 
than delete) but the 'd' right does not exist (can't delete or expunge) is 
the mailbox read-only or read-write? This actually affects the behaviour of 
non-ACL aware clients. ACL-aware clients are going to be smart enought to 
figure out the correct behaviour based on what the current users rights are 
to a mailbox, but non-ACL clients can only base their behaviour from the 
read-only/read-write responses.

6) As a reminder to implemetors, I think there needs to be a statement that 
the FLAGS and PERMANENTFLAGS responses as part of the SELECT command should 
accurately reflect the current user's rights.

7) I think the behaviour of the 'l' with respect to mailbox hierarchies 
needs to be explained more. Specifically what happens in the case where a 
user has the 'l' right to mailbox 'A/A' but not to mailbox 'A'? Should 
'A/A' be returned in LIST or should the absence of the 'l' right on the 
parent mailbox allow a server to not bother looking for 'l' rights on the 
child mailboxes.

8) One thing that has come from our (now three years of) experience of 
doing ACLs in Mulberry is that users frequently want to take a set of ACLs 
on one mailbox and apply those to another mailbox, or mailboxes, e.g. 
'propagation' of rights from one mailbox to its child hierarchy. Right now 
a client has to do this by issuing multiple DELETEACL and SETACL commands 
for each mailbox in the list. This is very inefficient.

What I would like to see is a new REPLACEACL command that takes a mailbox 
spec, similar to the LIST command, and a list of identifier-rights pairs. 
This command would remove all the existing rights on the matching mailboxes 
and then add all the rights specified in the command. This effectively 
'propagates' a set of rights to a group of mailboxes in a single command.

9) One other behaviour that I would like to see added as a SHOULD 
requirement on the server:

'The server SHOULD issue an untagged MYRIGHTS response (as a 
response-cond-state [IMAP4] response) when a client issues the SELECT or 
EXAMINE command for a mailbox when the ACL extension is present'

I don't know about other clients, but we always issue a MYRIGHTS command 
after doing a SELECT or EXAMINE in order to figure out what UI items need 
to be enabled or disabled on the newly opened mailbox, e.g. 
enabling/disabling or certain flag commands based on the 'w' right. Having 
MYRIGHTS sent as an untagged response to SELECT or EXAMINE would remove the 
need for the extra command from the client. I would suggest that most 
ACL-aware clients are going to want MYRIGHTs on mailboxes they select so 
this would be a welcome change.

-- 
Cyrus Daboo

Date: Fri, 26 May 2000 11:40:53 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt
To: Pete Resnick <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Fri, 26 May 2000 13:18:13 -0500, Pete Resnick wrote:
> As you no doubt know, the working group was only recently chartered.
> There have been several things delayed because of that. I now fully
> believe that we are moving along with work.

I remain skeptical.  I was extremely disappointed by the lack of progress in
Oslo and DC.

Not to mentioned being told, over and over again, that RFC 2086 is cast in
stone, and that the only problem was my environment is "obsolete" and not
worth worrying about.

> >We were promised over a year ago that our concerns with ACL would be
> >addressed.
> Who is "we"?

Are you unaware that there is a team of people here at UW working on email
development?  I'm speaking about the concerns of the entire team.

> To date, the only person I have heard on these issues is
> you.

I don't think that you really mean to say that you go along with whichever
organization packs the meeting room with the most number of its employees.

> There was consensus in the room at Australia that requiring ACLs to
> strictly conform to Unix semantics was potentially damaging to the
> protocol and that we should stick to solving the problems in the
> currently deployed base.

Nobody ever said "require ACLs to strictly conform to Unix semantics".  That's
a strawman with no purpose other than to be burned down.

If you want me to take this discussion seriously, don't use such strawmen.

> We have by no means had sufficient
> discussion IN THIS WORKING GROUP to determine whether your concerns
> *won't* be addressed.

The past three and a half years worth of discussion is to be started over from
the beginning?

> As far as we should all be concerned, the clock has only
> now started ticking.

Will you request IESG to withdraw RFC 2086 from Proposed Standard status, so
that a clean start can be made?  UW did not approve RFC 2086.  It should never
have gotten on standards-track.

I've heard the excuse of "RFC 2086 is standards-track and it's too late to
change the framework now" too many times in the past three years.  There's no
point in further discussion as long as that excuse remains.

> I look forward to discussion of these items. If there are more
> issues, bring them up now.

OK:

Other than inheritance and the problem with the "c" right, the system of
rights is more or less acceptable.

To recap:
1) there needs to be a "+" prefix (or suffix, I don't really care) which
stipulates that the rights are to be inherited as described in the new I-D.
Otherwise, another applicable identifier (e.g. the user name) can override the
rights.  Actually, the "+" means "mandatory application without override".
The I-D insists that mandatory application is the only way, which means that
there is no way to "disable access for everybody in a group except for one
user".
2) Delete and rename mailbox needs to be separate; perhaps an "x" right since
it insists upon this alphabet soup of one letter codes.

A minor nit is the "d" right; it should not specify "perform EXPUNGE".  But I
think that I can just ignore that part without breaking things.

Given that IMAP is so chatty otherwise and the ACL commands don't allow
wildcards, the alphabet soup makes little sense; but since I plan to allow
wildcards in ACLPLUS I'm willing to leave this alone.

The primary problem with RFC 2086 is that the system of identifiers in ACLs is
inflexible.  We don't need a specific "change owner" and "change group"
operation.  We just need identifier semantics that can represent those
operations.  This is best done by a general purpose mechanism to define
certain forms of identifiers, and to query the definition of an identifier.

This new theory of identifiers is the beating heart of ACLPLUS.  It defines
the semantics of $xxx identifiers, and it adds two operators: one to define a
$xxx identifier, and one to query its definition.

Less important is a redesign of the commands and responses, with the RFC 2086
commands/responses retained for compatibility.  The new commands and responses
are considerably more powerful than RFC 2086.  However, this is a completely
secondary agenda; although it's a better design it's not crucial for the
functionality.

> Let's start with trying to address the issues in
> the current framework and move on from there.

The current framework is broken.

I do not purpose to create a framework that is hopelessly biased towards
another model.  Instead, I purpose to create a framework that encompasses both
models in a clean and well-defined manner.

I've been told repeatedly that it is not possible, and shouldn't be done.  It
seems that the only way that I can prove otherwise is by doing it.

> You releasing a competing draft at this point will
> inevitably slow our work down, and potentially lead to the above
> horrors.

I'm sorry that's it's come to this, but I have yet to hear anything that will
change it.

> So, may
> I assume that you put your work on hold until we have had some
> further discussion in the WG?

Unfortunately, the answer is no.  It's been held off for three and a half
years.  That's long enough.

I've been very patient.  Unfortunately, it seems that the only way to make
progress happen is for me to proceed.

Until/unless there is  concrete progress towards addressing our issues, , my
work will proceed.

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-imapext
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt
Date: Fri, 26 May 2000 12:25:42 -0700
Organization: Netscape Communications Corporation
Lines: 78
NNTP-Posting-Host: 192.18.126.70
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms076459EEC1E6830A8B1F22CE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Pete Resnick wrote:
> Having 2 ACL extensions does not enhance interoperability.

In this case, having two extensions can enhance interoperability.

Part of the reason the ACL draft has been delayed is that Mark had
comments I did not know how to address without creating an
overcomplicated mess.  Mark has stated that he wants to expose all
semantics of Unix file permissions, including the "change owner" and
"change group" operations.

An extension that allows servers to expose all of the Unix file
permission semantics and also allows servers to expose all of the ACL
semantics implemented by the Cyrus server will also allow a whole range
of intermediate semantics, with some aspects from Unix and some aspects
from the original ACL.  A conforming client would be required to be able
to deal with all of these and would have a difficult time figuring out
what the rules are on any particular server.

Two extensions would cut out all of the intermediate states, simplifying
clients and allowing them to know which type of server they are talking
to.
--------------ms076459EEC1E6830A8B1F22CE
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms076459EEC1E6830A8B1F22CE--

Date: Fri, 26 May 2000 11:28:24 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt
To: John Gardiner Myers <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Fri, 26 May 2000 10:53:30 -0700, John Gardiner Myers wrote:
> After much thought, confirmed by discussion at Adelaide, I've concluded
> that Mark's concerns are best addressed by his pursuing a separate
> extension.

Thank you, John.

Given that I purpose to create an upwards-compatible extension to RFC 2086,
would you give careful consideration to the following in your I-D:
 1) The two issues that I addressed in your latest I-D which will break
    compatibility (inheritance and the "c" right).  I think that the change to
    inheritance in the I-D is a bad enough move that, if unfixed, it would
    accellerate the withering away of ACL in favor of ACLPLUS.  The "c" right
    issue is less serious, but it would be a needless incompatibility.
 2) Changing the defintion of $xxx to be "reserved" instead of the current
    poorly-defined "group".
 3) Maintaining compatibility otherwise, so as not to preclude the possibility
    of a reunification.
 4) Possible wording in your document that says that any capability that
    starts with ACL is compatible with ACL (e.g. what is done with SORT) to
    promote interoperability.

> The models of access control are sufficiently different that
> an extension trying to address both (or all) models will necessarily be
> over complex and difficult to implement on the client side.

As you should know by now, I strongly disagree with this conclusion.  However,
the only way that I can prove my position is by delivering the goods, and I
shall proceed to do so.

I believe that presently you'll find that the additions in ACLPLUS are
sufficient desirable that you will decide to implement it after all.

Date: Fri, 26 May 2000 13:18:13 -0500
To: Mark Crispin <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt
Cc: [email-masked]
Sender: [email-masked]

On 5/26/00 at 12:19 AM -0700, Mark Crispin wrote:

>The working group has been ineffective up to now.  The lack of 
>progress has been remarkable.

As you no doubt know, the working group was only recently chartered. 
There have been several things delayed because of that. I now fully 
believe that we are moving along with work. Indeed, at each of the 
face-to-face meetings we have had as a BOF, we have made great 
progress on resolving many issues.

>So have some rather crude politics; I'll remind you that IMAPEXT has 
>not even permitted the SORT and THREAD I-D's to come out with a 
>"draft-ietf-imapext" file name.

Mark, as you full well know, given my message to you (which you 
replied to) of 8/18/99, message id 
<[email-masked]>, there were no crude 
politics involved here at all: As I explained, I was away on vacation 
when Natalia sent me the message asking whether these drafts could be 
under the working group. When I returned (the day I sent you the 
message), I sent her a message asking her to rename the drafts. I am 
quite sure that she would be happy to put them under the working 
group name if you resubmitted the documents.

I think you should follow the general guideline that ad hominem 
attacks like this should be kept out of the working group 
discussions. If you want to accuse me of doing something malicious, 
take it to private mail. In this case, you are wrong in your 
assessment.

>We were promised over a year ago that our concerns with ACL would be 
>addressed.

Who is "we"? To date, the only person I have heard on these issues is 
you. One person does not a consensus make. If there are others 
involved here, I would like their comments to appear on the mailing 
list as well.

>Yet, at the last IETF in Australia, the document editor stated that 
>those concerns weren't going to be addressed by ACL.

There was consensus in the room at Australia that requiring ACLs to 
strictly conform to Unix semantics was potentially damaging to the 
protocol and that we should stick to solving the problems in the 
currently deployed base. However, if you have specific issues that 
you want addressed, either post them to the list or send them 
directly to the document editor. We have by no means had sufficient 
discussion IN THIS WORKING GROUP to determine whether your concerns 
*won't* be addressed.

>The current document editor has stonewalled for three years. Time has run out.

Nonsense. (1) I do not want these personal attacks in the working 
group. (2) The current document editor has only now gotten out the 
-00 draft. As far as we should all be concerned, the clock has only 
now started ticking.

Now, you have identified two issues that the working group should address:

>...mandatory rights inheritance, with no way to override an 
>inherited negative right

>...overloading of "c" to mean "can create inferiors" and "can delete 
>this mailbox"...

>I have offered suggestions for how these problems in the new I-D can 
>be resolved.

I look forward to discussion of these items. If there are more 
issues, bring them up now.

>Doing so would maintain some semblance of compatibility between ACL 
>and ACLPLUS.  It would also keep the door open for a reunification.

"Reunification" is not a desirable goal. The premise is 
"disunification". Let's start with trying to address the issues in 
the current framework and move on from there.

>The design of ACLPLUS is almost finished.  It will happen.  I prefer 
>that IMAPEXT be willing to adopt these extensions into a single ACL 
>specification as optional ACL facilities.
>
>If not, there will be two specifications.

This is exactly the kind of hostile stonewalling you are arguing we 
should not be doing. You are one voice among many. Make your voice 
heard and convince others that your concerns are valid. Do not 
attempt to strongarm people. It is destructive and has no place in 
this discussion.

>If, on the other hand, the hostile stonewalling continues, we'll end 
>up with interoperability problems.  We'll have egg on our collective 
>faces.  The trade rags will have a field day.

I agree. So let's stop. John has released his first draft. You have 
made comments. Both of those are constructive moves in the correct 
direction. You releasing a competing draft at this point will 
inevitably slow our work down, and potentially lead to the above 
horrors. Let's do some work over these next 2 months and see where we 
are, not change direction when we're barely out of the gate.

>Even at this stage, it isn't too late; but time is running out.

I'm glad to hear that at least you believe it isn't too late. So, may 
I assume that you put your work on hold until we have had some 
further discussion in the WG?

>If there is a serious intention to resolve these differences 
>constructively, I am willing to arrange a face-to-face meeting with 
>the interested parties here in Seattle.

Let's go on the assumption that there is a serious intention to 
resolve these differences constructively. We only have 2 months until 
we meet in Pittsburgh. Let us try to work through these issues on the 
list. If we cannot, we can use the face-to-face meeting in Pittsburgh 
to resolve differences. Is that acceptable? I have been on the road 5 
of the past 9 weeks and I (and my significant other) would really 
prefer that I not travel between now and then.

pr
-- 
Pete Resnick <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102

Date: Fri, 26 May 2000 13:18:08 -0500
To: John Gardiner Myers <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt
Cc: [email-masked]
Sender: [email-masked]

On 5/26/00 at 10:53 AM -0700, John Gardiner Myers wrote:

>I've concluded that Mark's concerns are best addressed by his 
>pursuing a separate extension.

I would like to hear further discussion on this point from other 
members of the working group. Having 2 ACL extensions does not 
enhance interoperability. My inclination is to try to get something 
that will satisfy both sets of concerns rather than have competing 
documents. If that can't be done to either side's satisfaction, we 
can revisit the issue later. However, Mark has made some comments on 
the document; I encourage him (and others) to make more. Let's see if 
there is consensus (either positively or negatively) on what to do 
about them before we start making decisions about new extensions.

I can almost assure you that the IESG will not accept two ACL 
documents from this WG; my guess is that they won't accept any 
document while there are two competing documents in existence.

pr
-- 
Pete Resnick <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-imapext
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt
Date: Fri, 26 May 2000 10:53:30 -0700
Organization: Netscape Communications Corporation
Lines: 64
NNTP-Posting-Host: 192.18.126.70
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms7F155AEDA087592CCD3AAFC5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

After much thought, confirmed by discussion at Adelaide, I've concluded
that Mark's concerns are best addressed by his pursuing a separate
extension.  The models of access control are sufficiently different that
an extension trying to address both (or all) models will necessarily be
over complex and difficult to implement on the client side.

Better each model have its own extension.  Then the client will know
which world the server is in and will not have to deal with hybrid
models that don't exist in practice.
--------------ms7F155AEDA087592CCD3AAFC5
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms7F155AEDA087592CCD3AAFC5--

Date: Fri, 26 May 2000 00:19:01 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt
To: Pete Resnick <[email-masked]>
cc: Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

On Fri, 26 May 2000 01:17:06 -0500, Pete Resnick wrote:
> To do
> so would undermine the effectiveness of the working group and would
> leave the potential for huge interoperability problems in the future.

Unfortunately, the time to have worried about this has passed.

The working group has been ineffective up to now.  The lack of progress has
been remarkable.  So have some rather crude politics; I'll remind you that
IMAPEXT has not even permitted the SORT and THREAD I-D's to come out with a
"draft-ietf-imapext" file name.

We were promised over a year ago that our concerns with ACL would be
addressed.  Yet, at the last IETF in Australia, the document editor stated
that those concerns weren't going to be addressed by ACL.

> However, I strongly suggest that you not produce a different document
> unless and until *both* (a) there is no sign of coming to an
> agreement with the current document editor *and* (b) the working
> group decides that we need another document to compare to.

Unfortunately, this is no longer possible.  The current document editor has
stonewalled for three years.  Time has run out.  The working group can take
the lead on our effort; it can follow our effort; or it can ignore our effort;
but it can no longer stand in the way.

I know what I would counsel, but it's your decision.

The new I-D is much worse than RFC 2086.  The requirement in the new I-D for
mandatory rights inheritance, with no way to override an inherited negative
right, is a non-starter and (in my opinion) a terrible idea.  I can't believe
that it is seriously proposed.  It doesn't affect Cyrus; Cyrus doesn't have
groups.  It affects me to the point that it blocks my implementation.

Similarly, overloading of "c" to mean "can create inferiors" and "can delete
this mailbox" is also a non-starter.  These are independent rights in my
world.  I can't implement this overloading.

I have offered suggestions for how these problems in the new I-D can be
resolved.  Doing so would maintain some semblance of compatibility between ACL
and ACLPLUS.  It would also keep the door open for a reunification.

The design of ACLPLUS is almost finished.  It will happen.  I prefer that
IMAPEXT be willing to adopt these extensions into a single ACL specification
as optional ACL facilities.

If not, there will be two specifications.  Even then, the situation can still
be salvaged, with face-saving for all.  It just requires a sincere effort to
maintain upwards compatibility from ACL to ACLPLUS: ACL must not do anything
that breaks ACLPLUS, and ACLPLUS must remain a proper superset of ACL.  There
are no technical barriers; it just requires will.  If there's a lack of will,
it isn't on my part.

If, on the other hand, the hostile stonewalling continues, we'll end up with
interoperability problems.  We'll have egg on our collective faces.  The trade
rags will have a field day.  If that happens, so be it.

I'm sorry that it has come to this.  I did not want it.  I've spent three
years trying to resolve this, and getting repeatedly rebuffed.

I still do not want it.  There are positive steps that you can take to remedy
the situation.  I have seen no sign yet.  All I've seen are endless delays on
everything we want, while certain other agendas are rammed through.

Even at this stage, it isn't too late; but time is running out.

I hope to hear a positive answer.

If there is a serious intention to resolve these differences constructively, I
am willing to arrange a face-to-face meeting with the interested parties here
in Seattle.

-- Mark --

Date: Fri, 26 May 2000 01:17:06 -0500
To: Mark Crispin <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt
Cc: Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

In my role as chair:

On 5/25/00 at 7:46 PM -0700, Mark Crispin wrote:

>I am working on an upwards-compatible replacement for ACL called ACLPLUS which
>addresses these (and other) deficiencies.  Any RFC 2086 implementation will be
>able to talk to an ACLPLUS implementation, although the function set will be
>limited to what RFC 2086 supports.
>
>I urge that action be deferred until I have a chance to produce an Internet
>Draft containing my ACLPLUS specification.

I'm sorry, but I don't find this course of action acceptable. The 
working group has identified a document editor, and that document 
editor has produced a -00 version for this draft. In my mind, -00 
means this is a first cut. Mark, you (and others) have made some 
comments, and I expect the editor to address those comments, either 
by making changes to the document to satisfy you (or more importantly 
a rough consensus of the working group with or without you), or to 
convince us that the current text is sufficient. In either case, this 
is something that the working group's designated editor needs to do 
without the threat of someone running off and writing some other 
competing document outside of the scope of this working group. To do 
so would undermine the effectiveness of the working group and would 
leave the potential for huge interoperability problems in the future.

If you wish to submit suggested text to the document editor for how 
you think these issues should be addressed, I encourage you to do so. 
However, I strongly suggest that you not produce a different document 
unless and until *both* (a) there is no sign of coming to an 
agreement with the current document editor *and* (b) the working 
group decides that we need another document to compare to. Neither of 
those criteria are currently satisfied.

pr
-- 
Pete Resnick <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102

Date: Thu, 25 May 2000 21:25:30 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt
To: Lawrence Greenfield <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Fri, 26 May 2000 00:09:55 -0400 (EDT), Lawrence Greenfield wrote:
> Why should group management be part of IMAP?

That's like asking "why should ACL management be part of IMAP?".

First of all, it's wrong to think in terms of groups.  Think in terms of
defined identifier sets.  A "group" is simply one type of defined identifier
set.

> What is problematic about it?  It's a straightforward algorithm to
> implement in deciding whether to grant or deny rights.

It is problematic because it does not express an existing valid access
configuration, in which an identifier (containing a user) is exempted from a
negative right applied to another identifer (also containing that user).

> The proposed modification complicates semantics significantly.  Is
> there operational experience that this level of flexibility is needed?

Yes.  Existing protection codes which I have today behave this way.

> I think this draft fixes a number of known problems with the current
> ACL extension in a compatible, straightforward way.

This draft contains a set of four trivial changes.  One change is mandated by
IAB; one change is a handwave; and the last two changes are bugs.

Yes, the overloading of the "c" right for mailbox deletion is also a bug.
First, it is ambiguous about what can be deleted: it should be the mailbox
itself (not inferiors) but that needs to be stated.  Also, the ability to
create inferiors does not necessarily mean the ability to delete the mailbox.

We need a separate "x" right for mailbox deletion.

It doesn't really matter now, since ACLPLUS is going to happen.  After three
years of being stonewalled, time has run out.

Date: Fri, 26 May 2000 00:09:55 -0400 (EDT)
From: Lawrence Greenfield <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt
Sender: [email-masked]

   Date: Thu, 25 May 2000 19:46:45 -0700 (PDT)
   From: Mark Crispin <[email-masked]>

[...]
   PROBLEM: The group facility doesn't address the problem, and in
   fact creates more problems than it solves; it completely swallows
   the entire $ syntax for a functionality that isn't otherwise
   specified (e.g. how do you manage groups?).

Why should group management be part of IMAP?  Groups logically come
from an authorization server; whether that's an LDAP server sitting
somewhere, or (unfortunately) an AFS PTS server somewhere else, it
really doesn't matter---it's the authorization server's decision
whether an authorization identifier is included in a group.

[...]
   Although removing the ambiguity is a good idea, I question whether
   it's really such a good idea to insist upon inheritance.  In
   particular, the inheritance of negative rights is problematic.

What is problematic about it?  It's a straightforward algorithm to
implement in deciding whether to grant or deny rights.

The proposed modification complicates semantics significantly.  Is
there operational experience that this level of flexibility is needed?

I think this draft fixes a number of known problems with the current
ACL extension in a compatible, straightforward way.

Larry

Date: Thu, 25 May 2000 19:46:45 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt
To: Simon Josefsson <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

I have reviewed the subject Internet Draft.  It's completely inadequate for
the task at hand.  It looks like all the discussion of the past three years
has gone in one ear and out the other.

PROBLEM: The group facility doesn't address the problem, and in fact creates
more problems than it solves; it completely swallows the entire $ syntax for a
functionality that isn't otherwise specified (e.g. how do you manage groups?).

RECOMMENDATION: The draft be modified to reserve names beginning with $ for
use by an extension to ACL.

PROBLEM: Unlike RFC 2086, this new draft requires rights inheritance; that is,
an identifier automatically has the rights of "anyone" unless these are
specifically denied as negative rights.  RFC 2086 allowed implementations to
decide if rights were inherited or not.

Although removing the ambiguity is a good idea, I question whether it's really
such a good idea to insist upon inheritance.  In particular, the inheritance
of negative rights is problematic.

RECOMMENDATION: The draft should be modified to indicate whether or not an
identifier has inheritance semantics.  I suggest using + for this purpose.  In
other words:
	+anyone lr
means that all users can list and read the mailbox unless specifically denied
by a - identifier, whereas:
	anyone lr
means that all users who aren't otherwise listed by an identifier can read and
list the mailbox.  Also, + and - can be combined to cause negative rights
inheritance.

For example
	fred lr -$G$students lr anyone lr
means that everybody except for members of the students group can read and
list; however fred can also read and list even though he's a member of
students.  On the other hand
	+-anyone lr
means that nobody can read or list the file, no matter who (this is what - is
defined to do in the draft).

I am working on an upwards-compatible replacement for ACL called ACLPLUS which
addresses these (and other) deficiencies.  Any RFC 2086 implementation will be
able to talk to an ACLPLUS implementation, although the function set will be
limited to what RFC 2086 supports.

I urge that action be deferred until I have a chance to produce an Internet
Draft containing my ACLPLUS specification.

To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt
From: Simon Josefsson <[email-masked]>
Date: 25 May 2000 14:54:27 +0200
Lines: 15
Sender: [email-masked]

Two little thoughts

. If identifiers starting with dollar signs are reserved for groups,
  why don't describe what "groups" are and how they work too?  I'd
  really like IMAP ACLs on groups of users, but I'm not sure there is
  enough detail to implement it server-independently.

. Perhaps it should be noted in the security considerations that the
  ACL evaluation now required might breach security if rfc2086-ACL's
  are used in a server implementing this draft?

I dunno much about the draft, or anything, at all, so feel free to
ignore my comments if they doesn't make sense.

(Wasn't there talk of a major re-design of IMAP ACLs?)

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-acl-00.txt
Date: Thu, 25 May 2000 06:35:17 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.

	Title		: IMAP4 ACL extension
	Author(s)	: J. Myers
	Filename	: draft-ietf-imapext-acl-00.txt
	Pages		: 9
	Date		: 24-May-00
	
The ACL extension of the Internet Message Access Protocol [IMAP4]
permits access control lists to be manipulated through the IMAP
protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-acl-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imapext-acl-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-acl-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-acl-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-imapext-acl-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

From: "Charlie Fletcher - www.ukdata.com" <[email-masked]>
To: "Finance Director" <[email-masked]>
Subject: Instant On-Line Credit Reports
Date: Tue, 9 May 2000 16:34:00 +0100
Sender: [email-masked]

Do you need fast accurate information to assist you when appraising
potential customers, and suppliers?

The UK Data internet website www.ukdata.com contains 28 million pages of
data with full information on every UK company!

Credit Reports-Director Searches-Accounts-Annual Returns

All of these products and many more are available to you immediately, and
can be downloaded to and printed from your personal computer.

Free samples of all reports are available at www.ukdata.com.

Please also visit www.formacompany.co.uk the on-line company formation
website

Thank You

Charles Fletcher
www.ukdata.com an instant report on every UK business
www.formacompany.co.uk the on-line company formation site
www.irishdata.ie - instant reports on all Irish companies