Subject: Re: More questions about IMAP ACL
From: Mark Crispin <[email-masked]>
To: Paul Smith <[email-masked]>
Cc: [email-masked]
Date: Thu, 11 Oct 2001 11:56:47 -0700 (PDT)
List-Id: <ietf-imapext.imc.org>

On Thu, 11 Oct 2001 09:32:55 +0100, Paul Smith wrote:
> I don't think throwing away and replacing RFC 2086 is a good idea at all.
> I'd vote for a different extension as well. To 'replace' RFC 2086, you'd
> either have to call the new extension ACL as well (endless confusion), or
> call it ACLPLUS or ACL2 or something. In that case, anyone who wants
> interoperability would still implement ACL as well as ACLPLUS/ACL2/whatever
> just to allow maximum interoperability.

I think that we're loudly agreeing.

> Create a new standard and 'deprecate' RFC 2086, but don't replace it.

That's exactly what I advocate.

> (BTW, I'm not really convinced by your arguments that there's anything
> wrong with the current ACL standard apart from its ambiguities - you seem
> to be saying that it's not workable on a UNIX back-end, but I don't believe
> that, the abstraction layer you have to write may be a bit more complex,
> but you'd get it to work. In our Windows IMAP server we wrote our own ACL
> implementation from scratch - the OS has nothing at all to do with it, you
> could do the same on any OS. The ambiguities are the main problem IMHO.)

I agree that the ambiguities in RFC 2086 are the main problem if you implement
your own ACL mechanism separate from the operating system.  However, that is
not an option for me.

I have worked out the abstraction layer between RFC 2086 and the UNIX access
control model.  If it were just a matter of complexity, I wouldn't be
squawking.  The problem is that the abstraction layer removes too much
functionality from both RFC 2086 and UNIX access control, resulting in a
subset that is too limited to be useful.

Another problem is that, either way, the RFC 2086 inheritance rules and the
overloading of certain rights render it impossible to present certain UNIX
access control configurations.  Put another way, an ACL from a UNIX server is
a lie.

The first problem can be resolved by removing the RFC 2086 requirement that
identifiers be a "user name string accepted by the LOGIN or AUTHENTICATE
command" (RFC 2086, page 2).  Instead, create a mechanism by which identifiers
can be defined (and one possible definition be a user name), and by which a
client can get the identifier.

For example, all you have to do to make an RFC 2086 server comply is to hack
it so the following scenario works:
	a008 GETACLIDENTIFER fred
	* ACLIDENTIFIER fred user=fred
	a008 OK done!
	a009 SETACLIDENTIFER fred user=bill
	a009 NO identifiers in this server must be a user name

I will implement rules in naming identifiers even if the RFC 2086 successor
does not.  However, I think that it would be desirable for the RFC 2086
successor to have the rules so that clients can use knowledge of the rules.

In any case, the mapping of ACL identifier to user name must go.

As for the second problem, I think that I have compelling arguments (not the
least being simplicity) for abolishing inheritance and negative rights, and
for additional granularity in rights.  Anyway, few people seem to dispute the
need for the latter.

Date: Thu, 11 Oct 2001 09:30:22 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: re: Historical question: CAPABILITY and the extensions
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Thu, 11 Oct 2001 13:36:41 +0200, Arnt Gulbrandsen wrote:
> It can't really be changed, but I'm curious: Why is the CAPABILITY
> command argumentless?

In general, we have tried to eschew "big switches", and instead make new
features be driven by new commands.  This isn't religion: we have talked about
"big switches" for i18n purposes.  But, in general, it is felt that protocol
modalities are a bad idea since they make the protocol too complex.

Date: Thu, 11 Oct 2001 13:36:41 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Historical question: CAPABILITY and the extensions
Sender: [email-masked]

It can't really be changed, but I'm curious: Why is the CAPABILITY
command argumentless?

If its grammar were like that of the CAPABILITY response, then
extensions could add responses just like commands, message data items,
sort keys, etc. This seems a strange omission; why is it like that?

There's an easy workaround: An extension that wants a unilateral
"* BLAH 1234" can specify "* OK [BLAH 1234]" instead.  But still, I'm
curious.

No prizes for guessing which draft I was just reading ;)

--Arnt

Date: Thu, 11 Oct 2001 09:32:55 +0100
To: Mark Crispin <[email-masked]>
From: Paul Smith <[email-masked]>
Subject: Re: More questions about IMAP ACL
Cc: [email-masked]
Sender: [email-masked]

> > We can always define a different extension if people want different
> > behavior.
>
>This is extremely unwise IMHO.  IESG has already said that they won't advance
>two IMAP ACL extensions.  The best way to make that outcome happen is to
>refuse to accomodate non-AFS requirements.
>
>I think that we need to bite the bullet and create a replacement extension.
>Window-dressing on RFC 2086 is a mistake.

I don't think throwing away and replacing RFC 2086 is a good idea at all. 
I'd vote for a different extension as well. To 'replace' RFC 2086, you'd 
either have to call the new extension ACL as well (endless confusion), or 
call it ACLPLUS or ACL2 or something. In that case, anyone who wants 
interoperability would still implement ACL as well as ACLPLUS/ACL2/whatever 
just to allow maximum interoperability.

Create a new standard and 'deprecate' RFC 2086, but don't replace it.

(BTW, I'm not really convinced by your arguments that there's anything 
wrong with the current ACL standard apart from its ambiguities - you seem 
to be saying that it's not workable on a UNIX back-end, but I don't believe 
that, the abstraction layer you have to write may be a bit more complex, 
but you'd get it to work. In our Windows IMAP server we wrote our own ACL 
implementation from scratch - the OS has nothing at all to do with it, you 
could do the same on any OS. The ambiguities are the main problem IMHO.)

Paul				VPOP3 - Internet Email Server/Gateway
[email-masked]			http://www.pscs.co.uk/

Organization: ACI Worldwide - Advanced Technology Group
To: Mark Crispin <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, Lawrence Greenfield <[email-masked]>, [email-masked]
Subject: Re: More questions about IMAP ACL 
Date: Wed, 10 Oct 2001 15:20:10 -0600
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

There are two show-stoppers that I can see:

1) If we specify a naming scheme for users vs. groups in ACLs,
   we're usurping part of the existing namespace for identifiers,

2) Splitting of message and folder delete rights.

Either of these breaks backwards compatibility, so I don't see that
we have any alternative but to move the current ACL spec to
historic when we introduce the new spec.

--lyndon

Date: Wed, 10 Oct 2001 12:58:22 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: More questions about IMAP ACL
To: Alexey Melnikov <[email-masked]>
cc: Lawrence Greenfield <[email-masked]>, [email-masked]
Sender: [email-masked]

On Wed, 10 Oct 2001 13:13:26 -0600, Alexey Melnikov wrote:
> Can we define two IMAP extensions: one is fixed version of RFC 2086 and
> another that is a superset of the first with new functionality?

I am not opposed to this idea if it can be accomplished.  I'm not sure that it
can.  For example, if a server distinguishes between two new rights, how is
that represented in the old way?

Doing a lot of the extension work in naming semantics would help compatibility
a lot, which is why I advocated that.  But a client is going to need some
additional commands to do some of the things.  Then there's the rathole of
inheritance (I've said my position on that topic many times, hopefully there's
no need to repeat it)...

I'm not sure how we can be upwards-compatible yet make desirable changes.  I
believe that we can be upwards-upgradable, especially for clients, without too
much problem.  Most of the ACL => ACLPLUS upgrade burden will be on servers,
which is as it should be.

> Correct me if I am wrong,
> but I believe IESG will have problems with two *competing* ACL extensions,
> not with two compatible.

Should we succeed in this regard, the superset extension will probably be the
only one that advances.  Since I believe that the new functionality can be
easily implemented (at least as a no-op) this should be alright with the
oldline ACLers.

The problem will be changing the inheritance rules as I advocate.  I feel that
it should be done, but I see problems if clients know about RFC2086's
inheritance rules.  If we're lucky, clients don't.

Date: Wed, 10 Oct 2001 13:13:26 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Mark Crispin <[email-masked]>
CC: Lawrence Greenfield <[email-masked]>, [email-masked]
Subject: Re: More questions about IMAP ACL
Sender: [email-masked]

Mark Crispin wrote:

> > We can always define a different extension if people want different
> > behavior.
>
> This is extremely unwise IMHO.  IESG has already said that they won't advance
> two IMAP ACL extensions.

Can we define two IMAP extensions: one is fixed version of RFC 2086 and another
that is a superset of the first with new functionality? Correct me if I am wrong,
but I believe IESG will have problems with two *competing* ACL extensions, not
with two compatible.

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

I speak for myself only, not for my employer.
__________________________________________

Date: Wed, 10 Oct 2001 11:24:14 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: More questions about IMAP ACL
To: Lawrence Greenfield <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Wed, 10 Oct 2001 14:21:36 -0400, Lawrence Greenfield wrote:
> We already have interoperability on RFC 2086.  I'd be in favor of
> minimal changes.

The problem is not the interoperability of RFC 2086, but the implementability
and usefulness of such an implementation.

My analysis suggests that I would badly break the RFC 2086 world if UW imapd
started supporting ACL.  What makes sense in UW imapd would greatly confuse a
client which assumes that AFS style world implied by RFC 2086.  The language
in RFC 2086 that was designed to allow a filesystem access control model has
ambiguities that you can drive a truck through!

An additional problem is missing functionality.  It may not be important to
AFS users (since that functionality isn't there), but when you have an access
control model that is the *intersection* of AFS and UNIX you have a very small
one indeed.

> We can always define a different extension if people want different
> behavior.

This is extremely unwise IMHO.  IESG has already said that they won't advance
two IMAP ACL extensions.  The best way to make that outcome happen is to
refuse to accomodate non-AFS requirements.

I think that we need to bite the bullet and create a replacement extension.
Window-dressing on RFC 2086 is a mistake.

I believe that with a better abstraction layer in IMAP ACL, it is possible to
create a union of AFS and UNIX access control that solves the problems without
making either an AFS or UNIX back end look deficient.  I believe that such an
abstraction layer should be the primary focus of our efforts.

We can certainly use RFC 2086 as a starting point.  I have no particular
problem with the access rights.  It's primarily naming and rights inheritance
which are the problem.

Date: Wed, 10 Oct 2001 14:21:36 -0400
From: Lawrence Greenfield <[email-masked]>
To: [email-masked]
Subject: Re: More questions about IMAP ACL
Sender: [email-masked]

   Date: Wed, 10 Oct 2001 00:47:43 -0600
   From: Alexey Melnikov <[email-masked]>

   I have couple generic questions about IMAP ACL:

   1). Should the document be fully backward compatible with RFC 2086? (for
   example, dropping identifiers starting with dash will break
   compatibility).

I don't think that's possible if we want to add an "x" right.

   2). Should the document extend functionality or just fix RFC 2086?

We already have interoperability on RFC 2086.  I'd be in favor of
minimal changes.

We can always define a different extension if people want different
behavior.

Larry

Date: Wed, 10 Oct 2001 11:04:49 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: More questions about IMAP ACL
To: Alexey Melnikov <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Wed, 10 Oct 2001 12:01:58 -0600, Alexey Melnikov wrote:
> Should we define a new capability name?

I say yes.  Let's leave ACL as RFC 2086, and define ACLPLUS.

Date: Wed, 10 Oct 2001 12:01:58 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: [email-masked]
Subject: Re: More questions about IMAP ACL
Sender: [email-masked]

Alexey Melnikov wrote:

> I have couple generic questions about IMAP ACL:
>
> 1). Should the document be fully backward compatible with RFC 2086? (for
> example, dropping identifiers starting with dash will break
> compatibility).

It just came to me, that adding new rights is not backward compatible
change: some servers don't support storing of arbitrary rights. Also old
servers will use "d" flag for STORE \Deleted, EXPUNGE and DELETE. This will
be a problem for clients. Should we define a new capability name?

> 2). Should the document extend functionality or just fix RFC 2086?

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

I speak for myself only, not for my employer.
__________________________________________

Date: Wed, 10 Oct 2001 12:38:39 -0400
From: Lawrence Greenfield <[email-masked]>
To: [email-masked], Alexey Melnikov <[email-masked]>
Subject: Re: Question about existing implementations of ACL (RFC 2086)
Sender: [email-masked]

   Date: Wed, 10 Oct 2001 00:22:38 -0600
   From: Alexey Melnikov <[email-masked]>
   Organization: ACI WorldWide / MessagingDirect

   [I am trying to collect some implementation feedback before I submit new
   revision of ACL draft.]

   Anybody implemented groups in IMAP ACL? What naming schemes different
   implementations use?

We implement groups with several different authorization modules:

. The one we use on campus is AFS PTS groups, which don't collide with
  our user identifiers.  (All PTS groups have ":" in them, all PTS
  users don't.)

. The Unix /etc/group authorization module prefixes all Unix groups
  with "group:".

. There's a krb authorization module that allows for wildcards (ie,
  "[email-masked]" or "[email-masked]") which work like groups.

Larry

Date: Wed, 10 Oct 2001 00:49:26 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: re: More questions about IMAP ACL
To: Alexey Melnikov <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Wed, 10 Oct 2001 00:47:43 -0600, Alexey Melnikov wrote:
> 1). Should the document be fully backward compatible with RFC 2086?

Try, but don't allow that to keep you from doing the right thing when
necessary.

> 2). Should the document extend functionality or just fix RFC 2086?

It should extend functionality.

Date: Wed, 10 Oct 2001 00:47:43 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: [email-masked]
Subject: More questions about IMAP ACL
Sender: [email-masked]

I have couple generic questions about IMAP ACL:

1). Should the document be fully backward compatible with RFC 2086? (for
example, dropping identifiers starting with dash will break
compatibility).
2). Should the document extend functionality or just fix RFC 2086?

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

I speak for myself only, not for my employer.
__________________________________________

Date: Wed, 10 Oct 2001 00:22:38 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: [email-masked]
Subject: Question about existing implementations of ACL (RFC 2086)
Sender: [email-masked]

Hi,

[I am trying to collect some implementation feedback before I submit new
revision of ACL draft.]

Anybody implemented groups in IMAP ACL? What naming schemes different
implementations use?
Any special prefix?

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

I speak for myself only, not for my employer.
__________________________________________

Date: Tue, 9 Oct 2001 22:38:40 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: IMAP, UseNet and UTF-8 Newsgroups names
To: Simon Josefsson <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Sun, 07 Oct 2001 15:20:06 +0200, Simon Josefsson wrote:
> Ok, good. Maybe a reference to the USEFOR message syntax is
> appropriate, since news doesn't use RFC 822.

I'm one of those people who believe that the notion that news doesn't use RFC
[2]822 is fundamentally wrong-headed, and as I result I don't accept it.  2822
is the message format syntax.  News is a type of message.

I know that it is possible to argue this point forever.  If you disagree with
me, let's agree to disagree and not waste time arguing about it.

> Out of curiosity, can you post to news via IMAP as well?

There is no posting in IMAP.  IMAP clients use SMTP and NNTP for mail and news
posting, respectively.

> > My intention has always been that "all the 8-bit world is UTF-8", and that
> > 8-bit characters in mailbox names and headers are unambiguously UTF-8.
> I think this should be clarified in the draft, right now the draft
> references only RFC 822 (+ MIME) which clearly forbids 8-bit
> characters in headers.

The prohibition is quite intentional; people should not have the idea that
they have license to do this in IMAP.

> RFC822.HEADER, SEARCH HEADER etc all needs to be described as being
> UTF-8.

Someday, RFC822.HEADER may return a UTF-8 string.  But not now; and for the
time being it is forbidden.

SEARCH already has a CHARSET argument.

> Which probably means they will have
> to use literals instead of strings...  which adds roundtrips.

In the case of RFC822.HEADER, it already does use a literal because of the
newlines.

To: Mark Crispin <[email-masked]>
Cc: [email-masked]
Subject: Re: IMAP, UseNet and UTF-8 Newsgroups names
From: Simon Josefsson <[email-masked]>
Date: Sun, 07 Oct 2001 15:20:06 +0200
Lines: 50
Sender: [email-masked]

Mark Crispin <[email-masked]> writes:

>> Is the UseNet-via-IMAP widely used at all?
>
> Yes, it's used.

Ok, good. Maybe a reference to the USEFOR message syntax is
appropriate, since news doesn't use RFC 822.

Out of curiosity, can you post to news via IMAP as well?  Is the
distribution based on the APPEND mailbox name, or what is in the
Newsgroups field?

>> The immediate problems that comes to mind is unencoded 8-bit
>> characters in headers. UTF-8 newsgroups breaks this.  Recommending
>> that Newsgroups: should be RFC 2047 encoded during IMAP transport may
>> be one solution, but it has some issues (which charset? Always UTF-8
>> or just any that matches? etc).
>
> My intention has always been that "all the 8-bit world is UTF-8", and that
> 8-bit characters in mailbox names and headers are unambiguously UTF-8.

I think this should be clarified in the draft, right now the draft
references only RFC 822 (+ MIME) which clearly forbids 8-bit
characters in headers.  UTF-8 is not mentioned except for mailbox
names.  Adding a references for message syntax to USEFOR would solve
this (but would require a careful look through the document to see if
something else needs to be updated as well).

RFC822.HEADER, SEARCH HEADER etc all needs to be described as being
UTF-8 (if this is the intention).  Which probably means they will have
to use literals instead of strings...  which adds roundtrips.

> The historical problem has been the insistance of certain individuals in
> Europe that 8-bits means ISO 8859-1.

And ISO-2022 in CJK, or KOI-8 in Russia, etc...  all non-ASCII places.

If you need non-ASCII characters to talk with people, you jump for the
easiest solution.  UTF-8 didn't exist at the time, neither did MIME,
so it's hard to blame them.  (Maybe for persisting the habit, but
habits are hard to break, especially 10+ year old ones.)

> I am quite happy to let newsgroups suffer the pain and horror caused
> by this shortsightedness first.

News will only have a small problem, it is 8bit clean and charsets
depend on MIME or where you read, and headers will now be UTF-8.  Mail
will have bigger problems, especially in applications such as IMAP
that deals with both news and mail.

Date: Sun, 7 Oct 2001 05:40:11 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: re: IMAP, UseNet and UTF-8 Newsgroups names
To: Simon Josefsson <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Sun, 07 Oct 2001 13:57:11 +0200, Simon Josefsson wrote:
> First, is it the intention that reading UseNet via IMAP is officially
> supported?

Yes.

> It is mentioned in the draft (#news) but everything is
> very RFC 822 centric.  (Which btw should probably be updated to 2822.)

I've just made the update.

> Is the UseNet-via-IMAP widely used at all?

Yes, it's used.

> Maybe noone cares if UTF-8
> newsgroups aren't accessible via IMAP?

People do care.

> The immediate problems that comes to mind is unencoded 8-bit
> characters in headers. UTF-8 newsgroups breaks this.  Recommending
> that Newsgroups: should be RFC 2047 encoded during IMAP transport may
> be one solution, but it has some issues (which charset? Always UTF-8
> or just any that matches? etc).

My intention has always been that "all the 8-bit world is UTF-8", and that
8-bit characters in mailbox names and headers are unambiguously UTF-8.

The historical problem has been the insistance of certain individuals in
Europe that 8-bits means ISO 8859-1.  I am quite happy to let newsgroups
suffer the pain and horror caused by this shortsightedness first.

To: [email-masked]
Subject: IMAP, UseNet and UTF-8 Newsgroups names
From: Simon Josefsson <[email-masked]>
Date: Sun, 07 Oct 2001 13:57:11 +0200
Lines: 16
Sender: [email-masked]

In USEFOR it seems as if Newsgroups: names are to be UTF-8 in the
future.  With a little tweaking, this works fine (over NNTP) in the
client I use, but I wonder how it will integrate with IMAP.

First, is it the intention that reading UseNet via IMAP is officially
supported?  It is mentioned in the draft (#news) but everything is
very RFC 822 centric.  (Which btw should probably be updated to 2822.)

Is the UseNet-via-IMAP widely used at all?  Maybe noone cares if UTF-8
newsgroups aren't accessible via IMAP?

The immediate problems that comes to mind is unencoded 8-bit
characters in headers. UTF-8 newsgroups breaks this.  Recommending
that Newsgroups: should be RFC 2047 encoded during IMAP transport may
be one solution, but it has some issues (which charset? Always UTF-8
or just any that matches? etc).

Date: Thu, 11 Oct 2001 11:56:47 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: More questions about IMAP ACL
To: Paul Smith <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Thu, 11 Oct 2001 09:32:55 +0100, Paul Smith wrote:
> I don't think throwing away and replacing RFC 2086 is a good idea at all.
> I'd vote for a different extension as well. To 'replace' RFC 2086, you'd
> either have to call the new extension ACL as well (endless confusion), or
> call it ACLPLUS or ACL2 or something. In that case, anyone who wants
> interoperability would still implement ACL as well as ACLPLUS/ACL2/whatever
> just to allow maximum interoperability.

I think that we're loudly agreeing.

> Create a new standard and 'deprecate' RFC 2086, but don't replace it.

That's exactly what I advocate.

> (BTW, I'm not really convinced by your arguments that there's anything
> wrong with the current ACL standard apart from its ambiguities - you seem
> to be saying that it's not workable on a UNIX back-end, but I don't believe
> that, the abstraction layer you have to write may be a bit more complex,
> but you'd get it to work. In our Windows IMAP server we wrote our own ACL
> implementation from scratch - the OS has nothing at all to do with it, you
> could do the same on any OS. The ambiguities are the main problem IMHO.)

I agree that the ambiguities in RFC 2086 are the main problem if you implement
your own ACL mechanism separate from the operating system.  However, that is
not an option for me.

I have worked out the abstraction layer between RFC 2086 and the UNIX access
control model.  If it were just a matter of complexity, I wouldn't be
squawking.  The problem is that the abstraction layer removes too much
functionality from both RFC 2086 and UNIX access control, resulting in a
subset that is too limited to be useful.

Another problem is that, either way, the RFC 2086 inheritance rules and the
overloading of certain rights render it impossible to present certain UNIX
access control configurations.  Put another way, an ACL from a UNIX server is
a lie.

The first problem can be resolved by removing the RFC 2086 requirement that
identifiers be a "user name string accepted by the LOGIN or AUTHENTICATE
command" (RFC 2086, page 2).  Instead, create a mechanism by which identifiers
can be defined (and one possible definition be a user name), and by which a
client can get the identifier.

For example, all you have to do to make an RFC 2086 server comply is to hack
it so the following scenario works:
	a008 GETACLIDENTIFER fred
	* ACLIDENTIFIER fred user=fred
	a008 OK done!
	a009 SETACLIDENTIFER fred user=bill
	a009 NO identifiers in this server must be a user name

I will implement rules in naming identifiers even if the RFC 2086 successor
does not.  However, I think that it would be desirable for the RFC 2086
successor to have the rules so that clients can use knowledge of the rules.

In any case, the mapping of ACL identifier to user name must go.

As for the second problem, I think that I have compelling arguments (not the
least being simplicity) for abolishing inheritance and negative rights, and
for additional granularity in rights.  Anyway, few people seem to dispute the
need for the latter.

Date: Thu, 11 Oct 2001 09:30:22 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: re: Historical question: CAPABILITY and the extensions
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Thu, 11 Oct 2001 13:36:41 +0200, Arnt Gulbrandsen wrote:
> It can't really be changed, but I'm curious: Why is the CAPABILITY
> command argumentless?

In general, we have tried to eschew "big switches", and instead make new
features be driven by new commands.  This isn't religion: we have talked about
"big switches" for i18n purposes.  But, in general, it is felt that protocol
modalities are a bad idea since they make the protocol too complex.

Date: Thu, 11 Oct 2001 13:36:41 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Historical question: CAPABILITY and the extensions
Sender: [email-masked]

It can't really be changed, but I'm curious: Why is the CAPABILITY
command argumentless?

If its grammar were like that of the CAPABILITY response, then
extensions could add responses just like commands, message data items,
sort keys, etc. This seems a strange omission; why is it like that?

There's an easy workaround: An extension that wants a unilateral
"* BLAH 1234" can specify "* OK [BLAH 1234]" instead.  But still, I'm
curious.

No prizes for guessing which draft I was just reading ;)

--Arnt

Date: Thu, 11 Oct 2001 09:32:55 +0100
To: Mark Crispin <[email-masked]>
From: Paul Smith <[email-masked]>
Subject: Re: More questions about IMAP ACL
Cc: [email-masked]
Sender: [email-masked]

> > We can always define a different extension if people want different
> > behavior.
>
>This is extremely unwise IMHO.  IESG has already said that they won't advance
>two IMAP ACL extensions.  The best way to make that outcome happen is to
>refuse to accomodate non-AFS requirements.
>
>I think that we need to bite the bullet and create a replacement extension.
>Window-dressing on RFC 2086 is a mistake.

I don't think throwing away and replacing RFC 2086 is a good idea at all. 
I'd vote for a different extension as well. To 'replace' RFC 2086, you'd 
either have to call the new extension ACL as well (endless confusion), or 
call it ACLPLUS or ACL2 or something. In that case, anyone who wants 
interoperability would still implement ACL as well as ACLPLUS/ACL2/whatever 
just to allow maximum interoperability.

Create a new standard and 'deprecate' RFC 2086, but don't replace it.

(BTW, I'm not really convinced by your arguments that there's anything 
wrong with the current ACL standard apart from its ambiguities - you seem 
to be saying that it's not workable on a UNIX back-end, but I don't believe 
that, the abstraction layer you have to write may be a bit more complex, 
but you'd get it to work. In our Windows IMAP server we wrote our own ACL 
implementation from scratch - the OS has nothing at all to do with it, you 
could do the same on any OS. The ambiguities are the main problem IMHO.)

Paul				VPOP3 - Internet Email Server/Gateway
[email-masked]			http://www.pscs.co.uk/

Organization: ACI Worldwide - Advanced Technology Group
To: Mark Crispin <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, Lawrence Greenfield <[email-masked]>, [email-masked]
Subject: Re: More questions about IMAP ACL 
Date: Wed, 10 Oct 2001 15:20:10 -0600
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

There are two show-stoppers that I can see:

1) If we specify a naming scheme for users vs. groups in ACLs,
   we're usurping part of the existing namespace for identifiers,

2) Splitting of message and folder delete rights.

Either of these breaks backwards compatibility, so I don't see that
we have any alternative but to move the current ACL spec to
historic when we introduce the new spec.

--lyndon

Date: Wed, 10 Oct 2001 12:58:22 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: More questions about IMAP ACL
To: Alexey Melnikov <[email-masked]>
cc: Lawrence Greenfield <[email-masked]>, [email-masked]
Sender: [email-masked]

On Wed, 10 Oct 2001 13:13:26 -0600, Alexey Melnikov wrote:
> Can we define two IMAP extensions: one is fixed version of RFC 2086 and
> another that is a superset of the first with new functionality?

I am not opposed to this idea if it can be accomplished.  I'm not sure that it
can.  For example, if a server distinguishes between two new rights, how is
that represented in the old way?

Doing a lot of the extension work in naming semantics would help compatibility
a lot, which is why I advocated that.  But a client is going to need some
additional commands to do some of the things.  Then there's the rathole of
inheritance (I've said my position on that topic many times, hopefully there's
no need to repeat it)...

I'm not sure how we can be upwards-compatible yet make desirable changes.  I
believe that we can be upwards-upgradable, especially for clients, without too
much problem.  Most of the ACL => ACLPLUS upgrade burden will be on servers,
which is as it should be.

> Correct me if I am wrong,
> but I believe IESG will have problems with two *competing* ACL extensions,
> not with two compatible.

Should we succeed in this regard, the superset extension will probably be the
only one that advances.  Since I believe that the new functionality can be
easily implemented (at least as a no-op) this should be alright with the
oldline ACLers.

The problem will be changing the inheritance rules as I advocate.  I feel that
it should be done, but I see problems if clients know about RFC2086's
inheritance rules.  If we're lucky, clients don't.

Date: Wed, 10 Oct 2001 13:13:26 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Mark Crispin <[email-masked]>
CC: Lawrence Greenfield <[email-masked]>, [email-masked]
Subject: Re: More questions about IMAP ACL
Sender: [email-masked]

Mark Crispin wrote:

> > We can always define a different extension if people want different
> > behavior.
>
> This is extremely unwise IMHO.  IESG has already said that they won't advance
> two IMAP ACL extensions.

Can we define two IMAP extensions: one is fixed version of RFC 2086 and another
that is a superset of the first with new functionality? Correct me if I am wrong,
but I believe IESG will have problems with two *competing* ACL extensions, not
with two compatible.

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

I speak for myself only, not for my employer.
__________________________________________

Date: Wed, 10 Oct 2001 11:24:14 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: More questions about IMAP ACL
To: Lawrence Greenfield <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Wed, 10 Oct 2001 14:21:36 -0400, Lawrence Greenfield wrote:
> We already have interoperability on RFC 2086.  I'd be in favor of
> minimal changes.

The problem is not the interoperability of RFC 2086, but the implementability
and usefulness of such an implementation.

My analysis suggests that I would badly break the RFC 2086 world if UW imapd
started supporting ACL.  What makes sense in UW imapd would greatly confuse a
client which assumes that AFS style world implied by RFC 2086.  The language
in RFC 2086 that was designed to allow a filesystem access control model has
ambiguities that you can drive a truck through!

An additional problem is missing functionality.  It may not be important to
AFS users (since that functionality isn't there), but when you have an access
control model that is the *intersection* of AFS and UNIX you have a very small
one indeed.

> We can always define a different extension if people want different
> behavior.

This is extremely unwise IMHO.  IESG has already said that they won't advance
two IMAP ACL extensions.  The best way to make that outcome happen is to
refuse to accomodate non-AFS requirements.

I think that we need to bite the bullet and create a replacement extension.
Window-dressing on RFC 2086 is a mistake.

I believe that with a better abstraction layer in IMAP ACL, it is possible to
create a union of AFS and UNIX access control that solves the problems without
making either an AFS or UNIX back end look deficient.  I believe that such an
abstraction layer should be the primary focus of our efforts.

We can certainly use RFC 2086 as a starting point.  I have no particular
problem with the access rights.  It's primarily naming and rights inheritance
which are the problem.

Date: Wed, 10 Oct 2001 14:21:36 -0400
From: Lawrence Greenfield <[email-masked]>
To: [email-masked]
Subject: Re: More questions about IMAP ACL
Sender: [email-masked]

   Date: Wed, 10 Oct 2001 00:47:43 -0600
   From: Alexey Melnikov <[email-masked]>

   I have couple generic questions about IMAP ACL:

   1). Should the document be fully backward compatible with RFC 2086? (for
   example, dropping identifiers starting with dash will break
   compatibility).

I don't think that's possible if we want to add an "x" right.

   2). Should the document extend functionality or just fix RFC 2086?

We already have interoperability on RFC 2086.  I'd be in favor of
minimal changes.

We can always define a different extension if people want different
behavior.

Larry

Date: Wed, 10 Oct 2001 11:04:49 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: More questions about IMAP ACL
To: Alexey Melnikov <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Wed, 10 Oct 2001 12:01:58 -0600, Alexey Melnikov wrote:
> Should we define a new capability name?

I say yes.  Let's leave ACL as RFC 2086, and define ACLPLUS.

Date: Wed, 10 Oct 2001 12:01:58 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: [email-masked]
Subject: Re: More questions about IMAP ACL
Sender: [email-masked]

Alexey Melnikov wrote:

> I have couple generic questions about IMAP ACL:
>
> 1). Should the document be fully backward compatible with RFC 2086? (for
> example, dropping identifiers starting with dash will break
> compatibility).

It just came to me, that adding new rights is not backward compatible
change: some servers don't support storing of arbitrary rights. Also old
servers will use "d" flag for STORE \Deleted, EXPUNGE and DELETE. This will
be a problem for clients. Should we define a new capability name?

> 2). Should the document extend functionality or just fix RFC 2086?

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

I speak for myself only, not for my employer.
__________________________________________

Date: Wed, 10 Oct 2001 12:38:39 -0400
From: Lawrence Greenfield <[email-masked]>
To: [email-masked], Alexey Melnikov <[email-masked]>
Subject: Re: Question about existing implementations of ACL (RFC 2086)
Sender: [email-masked]

   Date: Wed, 10 Oct 2001 00:22:38 -0600
   From: Alexey Melnikov <[email-masked]>
   Organization: ACI WorldWide / MessagingDirect

   [I am trying to collect some implementation feedback before I submit new
   revision of ACL draft.]

   Anybody implemented groups in IMAP ACL? What naming schemes different
   implementations use?

We implement groups with several different authorization modules:

. The one we use on campus is AFS PTS groups, which don't collide with
  our user identifiers.  (All PTS groups have ":" in them, all PTS
  users don't.)

. The Unix /etc/group authorization module prefixes all Unix groups
  with "group:".

. There's a krb authorization module that allows for wildcards (ie,
  "[email-masked]" or "[email-masked]") which work like groups.

Larry

Date: Wed, 10 Oct 2001 00:49:26 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: re: More questions about IMAP ACL
To: Alexey Melnikov <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Wed, 10 Oct 2001 00:47:43 -0600, Alexey Melnikov wrote:
> 1). Should the document be fully backward compatible with RFC 2086?

Try, but don't allow that to keep you from doing the right thing when
necessary.

> 2). Should the document extend functionality or just fix RFC 2086?

It should extend functionality.

Date: Wed, 10 Oct 2001 00:47:43 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: [email-masked]
Subject: More questions about IMAP ACL
Sender: [email-masked]

I have couple generic questions about IMAP ACL:

1). Should the document be fully backward compatible with RFC 2086? (for
example, dropping identifiers starting with dash will break
compatibility).
2). Should the document extend functionality or just fix RFC 2086?

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

I speak for myself only, not for my employer.
__________________________________________

Date: Wed, 10 Oct 2001 00:22:38 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: [email-masked]
Subject: Question about existing implementations of ACL (RFC 2086)
Sender: [email-masked]

Hi,

[I am trying to collect some implementation feedback before I submit new
revision of ACL draft.]

Anybody implemented groups in IMAP ACL? What naming schemes different
implementations use?
Any special prefix?

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

I speak for myself only, not for my employer.
__________________________________________

Date: Tue, 9 Oct 2001 22:38:40 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: IMAP, UseNet and UTF-8 Newsgroups names
To: Simon Josefsson <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Sun, 07 Oct 2001 15:20:06 +0200, Simon Josefsson wrote:
> Ok, good. Maybe a reference to the USEFOR message syntax is
> appropriate, since news doesn't use RFC 822.

I'm one of those people who believe that the notion that news doesn't use RFC
[2]822 is fundamentally wrong-headed, and as I result I don't accept it.  2822
is the message format syntax.  News is a type of message.

I know that it is possible to argue this point forever.  If you disagree with
me, let's agree to disagree and not waste time arguing about it.

> Out of curiosity, can you post to news via IMAP as well?

There is no posting in IMAP.  IMAP clients use SMTP and NNTP for mail and news
posting, respectively.

> > My intention has always been that "all the 8-bit world is UTF-8", and that
> > 8-bit characters in mailbox names and headers are unambiguously UTF-8.
> I think this should be clarified in the draft, right now the draft
> references only RFC 822 (+ MIME) which clearly forbids 8-bit
> characters in headers.

The prohibition is quite intentional; people should not have the idea that
they have license to do this in IMAP.

> RFC822.HEADER, SEARCH HEADER etc all needs to be described as being
> UTF-8.

Someday, RFC822.HEADER may return a UTF-8 string.  But not now; and for the
time being it is forbidden.

SEARCH already has a CHARSET argument.

> Which probably means they will have
> to use literals instead of strings...  which adds roundtrips.

In the case of RFC822.HEADER, it already does use a literal because of the
newlines.

To: Mark Crispin <[email-masked]>
Cc: [email-masked]
Subject: Re: IMAP, UseNet and UTF-8 Newsgroups names
From: Simon Josefsson <[email-masked]>
Date: Sun, 07 Oct 2001 15:20:06 +0200
Lines: 50
Sender: [email-masked]

Mark Crispin <[email-masked]> writes:

>> Is the UseNet-via-IMAP widely used at all?
>
> Yes, it's used.

Ok, good. Maybe a reference to the USEFOR message syntax is
appropriate, since news doesn't use RFC 822.

Out of curiosity, can you post to news via IMAP as well?  Is the
distribution based on the APPEND mailbox name, or what is in the
Newsgroups field?

>> The immediate problems that comes to mind is unencoded 8-bit
>> characters in headers. UTF-8 newsgroups breaks this.  Recommending
>> that Newsgroups: should be RFC 2047 encoded during IMAP transport may
>> be one solution, but it has some issues (which charset? Always UTF-8
>> or just any that matches? etc).
>
> My intention has always been that "all the 8-bit world is UTF-8", and that
> 8-bit characters in mailbox names and headers are unambiguously UTF-8.

I think this should be clarified in the draft, right now the draft
references only RFC 822 (+ MIME) which clearly forbids 8-bit
characters in headers.  UTF-8 is not mentioned except for mailbox
names.  Adding a references for message syntax to USEFOR would solve
this (but would require a careful look through the document to see if
something else needs to be updated as well).

RFC822.HEADER, SEARCH HEADER etc all needs to be described as being
UTF-8 (if this is the intention).  Which probably means they will have
to use literals instead of strings...  which adds roundtrips.

> The historical problem has been the insistance of certain individuals in
> Europe that 8-bits means ISO 8859-1.

And ISO-2022 in CJK, or KOI-8 in Russia, etc...  all non-ASCII places.

If you need non-ASCII characters to talk with people, you jump for the
easiest solution.  UTF-8 didn't exist at the time, neither did MIME,
so it's hard to blame them.  (Maybe for persisting the habit, but
habits are hard to break, especially 10+ year old ones.)

> I am quite happy to let newsgroups suffer the pain and horror caused
> by this shortsightedness first.

News will only have a small problem, it is 8bit clean and charsets
depend on MIME or where you read, and headers will now be UTF-8.  Mail
will have bigger problems, especially in applications such as IMAP
that deals with both news and mail.

Date: Sun, 7 Oct 2001 05:40:11 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: re: IMAP, UseNet and UTF-8 Newsgroups names
To: Simon Josefsson <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Sun, 07 Oct 2001 13:57:11 +0200, Simon Josefsson wrote:
> First, is it the intention that reading UseNet via IMAP is officially
> supported?

Yes.

> It is mentioned in the draft (#news) but everything is
> very RFC 822 centric.  (Which btw should probably be updated to 2822.)

I've just made the update.

> Is the UseNet-via-IMAP widely used at all?

Yes, it's used.

> Maybe noone cares if UTF-8
> newsgroups aren't accessible via IMAP?

People do care.

> The immediate problems that comes to mind is unencoded 8-bit
> characters in headers. UTF-8 newsgroups breaks this.  Recommending
> that Newsgroups: should be RFC 2047 encoded during IMAP transport may
> be one solution, but it has some issues (which charset? Always UTF-8
> or just any that matches? etc).

My intention has always been that "all the 8-bit world is UTF-8", and that
8-bit characters in mailbox names and headers are unambiguously UTF-8.

The historical problem has been the insistance of certain individuals in
Europe that 8-bits means ISO 8859-1.  I am quite happy to let newsgroups
suffer the pain and horror caused by this shortsightedness first.

To: [email-masked]
Subject: IMAP, UseNet and UTF-8 Newsgroups names
From: Simon Josefsson <[email-masked]>
Date: Sun, 07 Oct 2001 13:57:11 +0200
Lines: 16
Sender: [email-masked]

In USEFOR it seems as if Newsgroups: names are to be UTF-8 in the
future.  With a little tweaking, this works fine (over NNTP) in the
client I use, but I wonder how it will integrate with IMAP.

First, is it the intention that reading UseNet via IMAP is officially
supported?  It is mentioned in the draft (#news) but everything is
very RFC 822 centric.  (Which btw should probably be updated to 2822.)

Is the UseNet-via-IMAP widely used at all?  Maybe noone cares if UTF-8
newsgroups aren't accessible via IMAP?

The immediate problems that comes to mind is unencoded 8-bit
characters in headers. UTF-8 newsgroups breaks this.  Recommending
that Newsgroups: should be RFC 2047 encoded during IMAP transport may
be one solution, but it has some issues (which charset? Always UTF-8
or just any that matches? etc).