Re: I-D ACTION:draft-ietf-imapext-acl-00.txt

[Mark Crispin <[e-mail]>]

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.