Subject: Re: Updated draft-ietf-imapext-2086upd (ACL)
From: Dave Cridland <[email-masked]>
To: Philip Guenther <[email-masked]>
Cc: <[email-masked]>
Date: Tue, 30 Nov 2004 09:54:34 +0000
List-Id: <ietf-imapext.imc.org>

On Mon Nov 29 22:23:45 2004, Philip Guenther wrote:
> 
> Ken Murchison <[email-masked]> writes:
> ...
> >Yes.  The draft makes the false assumption that *all* existing 
> >implementations use the 'd' right to control DELETE.  Cyrus made 
> the >decision a while back to separate mailbox ops (DELETE) from 
> message ops >(\Deleted and EXPUNGE).  Its unfortunate that RFC 2086 
> was >vague/ambiguous w.r.t. DELETE.
> ...
> >One easy way to do this might be to make 'c' a macro in the new 
> draft >just like 'd' and create a new bit for CREATE (e.g. 'k')  
> Then the >mapping would be:
> >
> >Cyrus:  'c' -> "kx", 'd' -> "te"
> >Others: 'c' -> "k",  'd' -> "xte"
> 
> This makes sense to me, but our server has this problem too, being
> distantly derived from Cyrus.  Does anyone actually know of a server
> that controls DELETE with the 'd' right?

CommunigatePro does, but *also* controls it with the "c" right on the 
parent.

(In other words, given A/B, issuing DELETE A/B requires "c" right in 
A and "d" right in B)

I would guess that Sun's implementation might require the parent "c" 
right, as well, given that their JavaMail [client] API documents that 
as required, but that's pure speculation on my part - I can't access 
their server implementation's documentation.

Dave.

To: Ken Murchison <[email-masked]>
Cc: Brian Candler <[email-masked]>, Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: Updated draft-ietf-imapext-2086upd (ACL) 
Date: Mon, 29 Nov 2004 14:23:45 -0800
Sender: [email-masked]

Ken Murchison <[email-masked]> writes:
...
>Yes.  The draft makes the false assumption that *all* existing 
>implementations use the 'd' right to control DELETE.  Cyrus made the 
>decision a while back to separate mailbox ops (DELETE) from message ops 
>(\Deleted and EXPUNGE).  Its unfortunate that RFC 2086 was 
>vague/ambiguous w.r.t. DELETE.
...
>One easy way to do this might be to make 'c' a macro in the new draft 
>just like 'd' and create a new bit for CREATE (e.g. 'k')  Then the 
>mapping would be:
>
>Cyrus:  'c' -> "kx", 'd' -> "te"
>Others: 'c' -> "k",  'd' -> "xte"

This makes sense to me, but our server has this problem too, being
distantly derived from Cyrus.  Does anyone actually know of a server
that controls DELETE with the 'd' right?

Philip Guenther

From: Dave Cridland <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>, Lisa Dusseault <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Date: Thu, 25 Nov 2004 13:14:10 +0000
Sender: [email-masked]

On Tue Nov 23 21:41:25 2004, Alexey Melnikov wrote:
> Suggested text:
>   Rights is a string listing a (possibly empty) set of alphanumeric
>   characters, each character listing a set of operations which is 
> being
>   controlled.  Lowercase letters are reserved for ''standard'' 
> rights, listed
>   below.  (Note that for compatibility with deployed clients and
>   servers uppercase rights are not allowed).
> 
> And update ABNF to enforce this.
> 
> 
That's fine by me.

> In the ACL2 document we should say something like this:
>  Unlike the RFC 2086, the letter rights are case-insensitive, so 
> the right "R" is the same as the right "r".
> 
> 
That's also fine by me.

Dave.

To: Alexey Melnikov <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt 
Date: Wed, 24 Nov 2004 10:56:52 -0800
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:
>Suggested text:
>   Rights is a string listing a (possibly empty) set of alphanumeric
>   characters, each character listing a set of operations which is being
>   controlled.  Lowercase letters are reserved for ''standard'' rights,
>   listed below.  (Note that for compatibility with deployed clients and
>   servers uppercase rights are not allowed).

I can live with this.

Philip Guenther

Date: Tue, 23 Nov 2004 21:41:25 +0000
From: Alexey Melnikov <[email-masked]>
To: Lisa Dusseault <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

Lisa Dusseault wrote:

> Looks like there was actually unanimity among seven voters to require 
> both clients and servers to send only lower-case rights in 2086upd, 
> but some quibbling about other details (whether to accept upper-case, 
> what precise wording to use).  Cyrus' proposed wording was:
>
>> 'Rights in 2086upd are case-insenstive, however clients and servers 
>> MUST use lower-case rights to be compatible with clients or servers 
>> supporting the original 2086 specification.'
>
> Philip suggested a slight modification that servers that advertise 
> support for 2086upd should be able to accept upper-case rights as well 
> (but not send them, if I understand).
>
> Alexey and Dave suggested that the spec not even use the word 
> "case-insensitive" to not confuse people.
>
> So Alexey, how about you propose new text for 2086upd?

Suggested text:
   Rights is a string listing a (possibly empty) set of alphanumeric
   characters, each character listing a set of operations which is being
   controlled.  Lowercase letters are reserved for ''standard'' rights, 
listed
   below.  (Note that for compatibility with deployed clients and
   servers uppercase rights are not allowed).

And update ABNF to enforce this.

In the ACL2 document we should say something like this:
  Unlike the RFC 2086, the letter rights are case-insensitive, so the 
right "R" is the same as the right "r".

From: Lisa Dusseault <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Date: Tue, 23 Nov 2004 10:01:01 -0800
To: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

Looks like there was actually unanimity among seven voters to require 
both clients and servers to send only lower-case rights in 2086upd, but 
some quibbling about other details (whether to accept upper-case, what 
precise wording to use).  Cyrus' proposed wording was:

> 'Rights in 2086upd are case-insenstive, however clients and servers 
> MUST use lower-case rights to be compatible with clients or servers 
> supporting the original 2086 specification.'

Philip suggested a slight modification that servers that advertise 
support for 2086upd should be able to accept upper-case rights as well 
(but not send them, if I understand).

Alexey and Dave suggested that the spec not even use the word 
"case-insensitive" to not confuse people.

So Alexey, how about you propose new text for 2086upd?

Lisa

Date: Tue, 23 Nov 2004 16:14:40 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Cc: Alexey Melnikov <[email-masked]>, Philip Guenther <[email-masked]>, Lisa Dusseault <[email-masked]>
Sender: [email-masked]

Alexey Melnikov writes:
> So I am in favor of saying that upper-case rights in 2086upd are not allowed.
>
> And I agree that ACL2 should relax this to make rights case-insensitive.

I'm happy with that.

Arnt

Date: Tue, 23 Nov 2004 15:02:57 +0000
From: Alexey Melnikov <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

Philip Guenther wrote:

>I'm in favor of requiring servers that advertise the RIGHTS capability
>to treat rights as case-insensitive.  This requirement would (obviously)
>not be retroactive to implementation that only support ACL and not
>RIGHTS, so it does not invalidate any implementations.  I find the
>described behavior of existing implementations largely irrelevant to
>this decision: upgrading an implementation from just ACL to ACL+RIGHTS
>is clearly going to require code changes for the new rights; adding a
>"tolower()" call would just be one of those changes.
>
>For the benefit of client implementors, a note could be added that warns
>that there exist common ACL implementations that predate this
>requirement and therefore that clients MUST send the standard rights as
>lowercase letters when talking to a server that does not support the
>RIGHTS extension.
>  
>
As there is no way for a client to announce its capabilities, the server 
MUST always send rights in lower-case.

I just really see no point of saying that rights are case-insensitive 
when there are effectively case-sensitive for existing ACL implementations.

>Leaving the meaning of uppercase rights implementation defined doesn't
>help anyone and means we simply get to have this same discussion all
>over again come ACL2.
>  
>
I agree, we need to either disallow upper-case rights or make them equal 
to the lower-case counterparts.
I don't think anybody has presented a good argument for making 
upper-case and lower-case rights different.

However, I share David's concern that even mentioning the word 
"case-insensitive" will mislead some implementors.
So I am in favor of saying that upper-case rights in 2086upd are not 
allowed.

And I agree that ACL2 should relax this to make rights case-insensitive.

To: Lisa Dusseault <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt 
Date: Mon, 22 Nov 2004 18:04:08 -0800
From: Philip Guenther <[email-masked]>
Sender: [email-masked]

I'm in favor of requiring servers that advertise the RIGHTS capability
to treat rights as case-insensitive.  This requirement would (obviously)
not be retroactive to implementation that only support ACL and not
RIGHTS, so it does not invalidate any implementations.  I find the
described behavior of existing implementations largely irrelevant to
this decision: upgrading an implementation from just ACL to ACL+RIGHTS
is clearly going to require code changes for the new rights; adding a
"tolower()" call would just be one of those changes.

For the benefit of client implementors, a note could be added that warns
that there exist common ACL implementations that predate this
requirement and therefore that clients MUST send the standard rights as
lowercase letters when talking to a server that does not support the
RIGHTS extension.

Leaving the meaning of uppercase rights implementation defined doesn't
help anyone and means we simply get to have this same discussion all
over again come ACL2.

Philip Guenther

From: Dave Cridland <[email-masked]>
To: Philip Guenther <[email-masked]>
Cc: Mark Crispin <[email-masked]>, Alexey Melnikov <[email-masked]>, <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt 
Date: Mon, 22 Nov 2004 10:29:22 +0000
Sender: [email-masked]

On Fri Nov 19 23:50:04 2004, Philip Guenther wrote:
> Furthermore, I would suggest that servers SHOULD return a BAD 
> response
> if a client specifies an unknown right.  Silently ignoring part of 
> what
> a client says is a recipe for later dissension...like the current
> discussion.

Indeed. That doesn't solve the existing problem, though.

> On one point:
> 
> Dave Cridland <[email-masked]> writes:
> ...
> >And ACL2 is a total replacement, in effect. RFC2086 will die out, 
> >along with this specification too, and while there will be a 
> >compatibility option in most implementations, that's something 
> that >will fall out of use quite happily by itself.
> 
> I disagree that ACL2 should be a complete replacement; with the 
> possible
> exception of adding another right or two, ACL2 should simply refer 
> to
> 2086upd for their definition and syntax.  ACL2 implementations are 
> going
> to need to support plain ACL for a goodly time to come; we should do
> everything we can to avoid unnecessary incompatibilities between 
> them.
> 
> (Even simply repeating the text from 2086upd in ACL2 would be error
> prone.  Would a latter erratum automatically apply to both?  What 
> if the
> text got editted slightly differently when republished?)

No, agreed. So we stick to the rights letters and definitions, but 
ACL2 simply makes them case-insensitive for its interface.

2086upd issues a blanket-ban on uppercase rights being defined, in 
preparation for this.

This should result in simpler language, and I believe greater 
interoperability.

Dave.

From: Dave Cridland <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Cc: Jutta Degener <[email-masked]>, IMAP Extensions WG <[email-masked]>, Mark Crispin <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, Alexey Melnikov <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Date: Mon, 22 Nov 2004 10:25:32 +0000
Sender: [email-masked]

On Sat Nov 20 17:25:43 2004, Lisa Dusseault wrote:
> Ok, can we get summarizing arguments from the different positions 
> here (case-sensitive v. case-insensitive ACL tokens) and tell me 
> your vote?  I can't see a clear consensus yet despite a fair amount 
> of discussion over this choice.

Summary:
1) Existing RFC2086 implementations assume case-sensitivity:
Refs: See source code of implementations.
2) Existing, widely deployed implementations break silently when 
case-insensitivity is assumed.
Refs: Tested against Cyrus IMAPd. SETACL with uppercase rights 
discards those rights, returns OK.
3) Definition of rights as case-insensitive is more likely to lead to 
clients which send uppercase rights - even though against the 
standard, the resultant wording has considerable scope to confuse.

If broken implementations sending uppercase rights to existing 
implementations received a BAD in return, I'd vote for this. However, 
they don't, and a silent discarding of rights is likely to cause 
newly released software to fail to interoperate with existing 
implementations.

Therefore, as much as I would personally like case-insensitive right 
letters, I have to vote against changing the existing syntax, on the 
basis of interoperability.

In ACL2, I'd be happy to see the ACL SET/STORE/DELETE syntax use 
case-insensitive rights - I'm not against the change, merely the 
timing of it.

Dave.

Date: Sat, 20 Nov 2004 12:59:13 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>, Alexey Melnikov <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

On Sat, 20 Nov 2004, Cyrus Daboo wrote:
> 'Rights in 2086upd are case-insenstive, however clients and servers MUST use 
> lower-case rights to be compatible with clients or servers supporting the 
> original 2086 specification.'

OK.

> As long as the lower-case requirement applies to servers as well as clients I 
> vote for case-insensitivity.

I agree to this.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Sat, 20 Nov 2004 14:42:54 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, Lisa Dusseault <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, Alexey Melnikov <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

Hi Mark,

--On November 20, 2004 11:09:44 -0800 Mark Crispin <[email-masked]> 
wrote:

> On Sat, 20 Nov 2004, Lisa Dusseault wrote:
>> Ok, can we get summarizing arguments from the different positions here
>> (case-sensitive v. case-insensitive ACL tokens) and tell me your vote?
>> I  can't see a clear consensus yet despite a fair amount of discussion
>> over this  choice.
>
> Mark votes for mandatory case-insensitivity in servers which claim to be
> 2086upd compliant (ACL2 goes without saying), and for a prohibition on
> clients sending upper-case to 2086 and 2086upd servers.  The latter
> provision is subject to review in ACL2.
>

That's not good enough because it potentially breaks existing clients which 
expect case-sensitive (lower-case) values from the server. The proper way 
to do this is:

'Rights in 2086upd are case-insenstive, however clients and servers MUST 
use lower-case rights to be compatible with clients or servers supporting 
the original 2086 specification.'

As long as the lower-case requirement applies to servers as well as clients 
I vote for case-insensitivity. However, if that requirement on the server 
is not applied, then I vote for case-sensitivity in 2086upd.

-- 
Cyrus Daboo

Date: Sat, 20 Nov 2004 11:09:44 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Lisa Dusseault <[email-masked]>
cc: Jutta Degener <[email-masked]>, IMAP Extensions WG <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, Alexey Melnikov <[email-masked]>, Dave Cridland <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

On Sat, 20 Nov 2004, Lisa Dusseault wrote:
> Ok, can we get summarizing arguments from the different positions here 
> (case-sensitive v. case-insensitive ACL tokens) and tell me your vote?  I 
> can't see a clear consensus yet despite a fair amount of discussion over this 
> choice.

Mark votes for mandatory case-insensitivity in servers which claim to be 
2086upd compliant (ACL2 goes without saying), and for a prohibition on 
clients sending upper-case to 2086 and 2086upd servers.  The latter 
provision is subject to review in ACL2.

The intent is to install case-insensitivity by transition; by putting 
servers on notice that they must fix any case-sensitivity to be 2086upd 
compliant, without breaking any existing behavior.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

From: Lisa Dusseault <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Date: Sat, 20 Nov 2004 09:25:43 -0800
To: Jutta Degener <[email-masked]>, IMAP Extensions WG <[email-masked]>, Mark Crispin <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, Alexey Melnikov <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Ok, can we get summarizing arguments from the different positions here 
(case-sensitive v. case-insensitive ACL tokens) and tell me your vote?  
I can't see a clear consensus yet despite a fair amount of discussion 
over this choice.

I need to know your vote even if you've already stated your position 
because some opinions were given before much discussion happened, and I 
need to know if the discussion changed anybody's mind.  Also welcoming 
input from those who've stayed silent so far.

Lisa

Date: Sat, 20 Nov 2004 15:55:18 +0000
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: [email-masked]
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

Mark Crispin wrote:

>> However, do you honestly think that client authors will change their 
>> code to send uppercase rights? (I mean, discounting the kinds of 
>> authors who deliberately do weird things because they can.)
>
> I don't think that; I *know* that.

Mark, can you elaborate?

Date: Fri, 19 Nov 2004 16:14:18 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, [email-masked], Jutta Degener <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Fri, 19 Nov 2004, Dave Cridland wrote:
> Nor will they use 2086upd servers either. As I understand things, 2086upd is 
> fully intended to be a stopgap until ACL2. Let's treat it like one.

If the transition isn't started with 2086upd, it won't happen.

> Wait... You "know" client authors will actively edit their code and put in 
> uppercase rights, then lowercase them for backwards compatibility with "pure" 
> RFC2086 servers if/when they encounter them?
> Why?

Yes, I know.  There are a number of reasons of doing this, few of which 
have anything to do with technical excellence.  For example, some client 
authors intentionally build software that works differentially with 
specific servers.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

To: Dave Cridland <[email-masked]>
Cc: Mark Crispin <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked], Arnt Gulbrandsen <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt 
Date: Fri, 19 Nov 2004 15:50:04 -0800
From: Philip Guenther <[email-masked]>
Sender: [email-masked]

I'm in favor of Mark's proposed clarification that rights MUST be
treated as case-insensitive.

Furthermore, I would suggest that servers SHOULD return a BAD response
if a client specifies an unknown right.  Silently ignoring part of what
a client says is a recipe for later dissension...like the current
discussion.

On one point:

Dave Cridland <[email-masked]> writes:
...
>And ACL2 is a total replacement, in effect. RFC2086 will die out, 
>along with this specification too, and while there will be a 
>compatibility option in most implementations, that's something that 
>will fall out of use quite happily by itself.

I disagree that ACL2 should be a complete replacement; with the possible
exception of adding another right or two, ACL2 should simply refer to
2086upd for their definition and syntax.  ACL2 implementations are going
to need to support plain ACL for a goodly time to come; we should do
everything we can to avoid unnecessary incompatibilities between them.

(Even simply repeating the text from 2086upd in ACL2 would be error
prone.  Would a latter erratum automatically apply to both?  What if the
text got editted slightly differently when republished?)

Philip Guenther

From: Dave Cridland <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, <[email-masked]>, Jutta Degener <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, Brian Candler <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Date: Fri, 19 Nov 2004 19:59:47 +0000
Sender: [email-masked]

On Fri Nov 19 17:48:33 2004, Mark Crispin wrote:
> On Fri, 19 Nov 2004, Brian Candler wrote:
>> That's if I understand correctly: the ACL2 proposal is being 
>> dropped.
> 
> Is ACL2 being dropped?
> 
> I oppose that.

Likewise.

ACL2 isn't being dropped, at least not unless we can't last-call it 
by 2005/02/05, as far as I'm aware.

Dave.

From: Dave Cridland <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, <[email-masked]>, Jutta Degener <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Date: Fri, 19 Nov 2004 19:56:46 +0000
Sender: [email-masked]

On Fri Nov 19 16:41:53 2004, Mark Crispin wrote:
> On Fri, 19 Nov 2004, Dave Cridland wrote:
>> It solves no problems, it adds complexity.
>> Adding complexity has a history of adding problems.
>> Therefore we cannot (or, if you prefer, should not) make this 
>> change.
>> What's there to understand? This isn't rocket science...
> 
> IMAP is a protocol which stipulates case-independence in its tokens 
> throughout.  Only data, such as message data or (optionally) 
> mailbox names are case-dependent, but even then INBOX is 
> case-independent.
> 
> ACL rights are an IMAP token.  The only reason why anyone ever 
> thought that they would be case-dependent was that the syntax rule 
> used was astring in order to avoid having to decide upon a syntax 
> for empty rights. This was a design mistake in 2086.  I have been 
> objecting to 2086's design mistakes repeatedly for many years.
> 
> Therefore, ACL rights are the only IMAP token which is 
> case-dependent. This solves no problems (the additional 26 rights 
> are not needed), it adds complexity.  Adding complexity has a 
> history of adding problems. Therefore we cannnot (or, if you 
> prefer, should not) make this change. What's there to understand?  
> This isn't rocket science...
> 
> 
I agree with all of that, which may surprise you.

It's an argument *against* RFC2086, however, and not an argument 
*for* changing it now.

In fact, the text you copied from my email stipulates "[...] make 
this change [...]". RFC2086 has *made* a change, a bad one I agree, 
but it's one we should live with until ACL2.

>> I've yet to see *any* technical argument for (a) here - lots of 
>> discussion about whether it's more in the "spirit of IMAP", etc. 
>> Nothing about whether it's actually a useful or sensible thing to 
>> do, especially in this specification.
> 
> The best way to ruin a technical specification is to ignore the 
> original spirit and graft on something that is totally foreign.
> 
> 
And again, I agree - RFC2086 wasn't a terribly good way of handling 
ACLs. It was under-specified, has a confusing array of rights, and is 
generally against the spirit of IMAP.

I can't stand many things about it, and this includes the way that 
rights are named right at the top of the list.

But the spirit of RFC2086 - in fact, more than that, the actual 
implementations - use a case-sensitive interpretation throughout. 

> C++ is an excellent example.
> 
> 
Well, I personally like the language, but I'll raise you Perl, 
although arguably that didn't have a spirit to be broken when OO was 
grafted on. Perhaps XLISP?

>>> Simply define that any 2086upd (and ACL2) compliant server MUST 
>>> have case-insensitive rights,...
>>> 	*AND*
>>> define that servers MUST send rights as lower case (MUST NOT send 
>>> rights
>>> as upper case)
>> The two above suggest that rights remain case-sensitive to all 
>> intents and purposes.
>> I fail to see any practical difference that this makes.
> 
> Not quite.  They establish the framework for the future.  In 
> particular, they instruct new implementations to read 
> case-insensitive, even though at present they must only send 
> lowercase.  Some time in the future, the latter part of the 
> previous sentence will be moot; nobody will use pre-2086upd servers 
> any more.
> 
> 
Nor will they use 2086upd servers either. As I understand things, 
2086upd is fully intended to be a stopgap until ACL2. Let's treat it 
like one.

>> However, do you honestly think that client authors will change 
>> their code to send uppercase rights? (I mean, discounting the 
>> kinds of authors who deliberately do weird things because they 
>> can.)
> 
> I don't think that; I *know* that.
> 
> 
Wait... You "know" client authors will actively edit their code and 
put in uppercase rights, then lowercase them for backwards 
compatibility with "pure" RFC2086 servers if/when they encounter them?

Why?

>> Now, on the contrary position, will there be new client authors 
>> who misunderstand, or simply fail to read, the specification, hear 
>> that "rights are case-insensitive", and break interoperability 
>> with older servers? I believe this will be the case - hence the 
>> reason why additional complexity tends to cause problems.
> 
> Pre-2086upd servers will rapidly become extinct, and clients will 
> be written that can only handle 2086upd.
> 
> Otherwise, there is no point to 2086upd, and this entire effort 
> should be abandoned as a waste of time.

It's not a waste of time - it clarifies 2086 enormously, sets down 
useful rules (rather than inferences) for what rights control what, 
and transitioning from 2086upd to ACL2 should prove much simpler.

And ACL2 is a total replacement, in effect. RFC2086 will die out, 
along with this specification too, and while there will be a 
compatibility option in most implementations, that's something that 
will fall out of use quite happily by itself.

The *only* thing we need to do to ensure that we can have 
case-insensitive rights in the future - should we want them, and not 
simply replace them with a much more IMAP-like syntax[*] - is to 
stress that rights are all lowercase - at least for now.

Banning them outright would be simpler:

The sentence beginning "Rights is a string listing..." in section 3 
gets replaced with "Rights is a string listing a (possibly empty) set 
of lower case US-ASCII letters and digits, each character listing a 
set of operations which is being controlled."

The ANBF gets adjusted accordingly to rule out uppercase rights.

That's a simple clarification of RFC2086, well within the scope of 
this draft, perfectly sensible, won't break anything even if misread, 
leaves all our options open.

Dave.
* - Think syntax like A002 ACL SET (INBOX Personal/*) user=Fred 
(\Read \Write \Insert \Seen \Deleted) - although I've not thought 
about a clearer syntax for the user=Fred ugliness, nor the flag names.

Date: Fri, 19 Nov 2004 10:33:40 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Lisa Dusseault <[email-masked]>
cc: Jutta Degener <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, [email-masked], Brian Candler <[email-masked]>, Alexey Melnikov <[email-masked]>, Dave Cridland <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

On Fri, 19 Nov 2004, Lisa Dusseault wrote:
> That's not the plan... the plan is to get 2086upd done quickly then get back 
> to ACL2.

That's what I had been led to believe.  Thank you Lisa for restating this.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Cc: Jutta Degener <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, [email-masked], Brian Candler <[email-masked]>, Alexey Melnikov <[email-masked]>, Dave Cridland <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Date: Fri, 19 Nov 2004 10:22:43 -0800
To: Mark Crispin <[email-masked]>
Sender: [email-masked]

That's not the plan... the plan is to get 2086upd done quickly then get 
back to ACL2.

lisa

On Nov 19, 2004, at 9:48 AM, Mark Crispin wrote:

>
> On Fri, 19 Nov 2004, Brian Candler wrote:
>> That's if I understand correctly: the ACL2 proposal is being dropped.
>
> Is ACL2 being dropped?
>
> I oppose that.
>
> -- Mark --
>
> http://staff.washington.edu/mrc
> Science does not emerge from voting, party politics, or public debate.
> Si vis pacem, para bellum.
>

Date: Fri, 19 Nov 2004 09:48:33 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Brian Candler <[email-masked]>
cc: Dave Cridland <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked], Jutta Degener <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

On Fri, 19 Nov 2004, Brian Candler wrote:
> That's if I understand correctly: the ACL2 proposal is being dropped.

Is ACL2 being dropped?

I oppose that.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Fri, 19 Nov 2004 17:19:01 +0000
From: Brian Candler <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Dave Cridland <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked], Jutta Degener <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

On Fri, Nov 19, 2004 at 08:41:53AM -0800, Mark Crispin wrote:
> Therefore, ACL rights are the only IMAP token which is case-dependent. 
> This solves no problems (the additional 26 rights are not needed), it 
> adds complexity.

I can't see any complexity with the one-to-one mapping of US-ASCII
characters to rights; a two-to-one mapping looks more complex to me. It adds
complexity in servers parsing commands, and clients parsing responses.

A server, after all, may not be able to lowercase the entire line which
comes in, so it still has to do this token by token. Mailbox names, apart
from [Ii][Nn][Bb][Oo][Xx], are permitted to be case-sensitive, but clients
have to be aware that they could also be case-insensitive. Now *that* added
a hell of a lot of complexity; with UTF-7 encoded Unicode mailbox names,
determining whether two characters are the same disregarding case is a
non-trivial task.

> >However, do you honestly think that client authors will change their code 
> >to send uppercase rights? (I mean, discounting the kinds of authors who 
> >deliberately do weird things because they can.)
> 
> I don't think that; I *know* that.

Sure, give them the option and at least one person will. But I don't see
what benefit would have accrued by giving them the ability to do so, when
you could just say that they can't.

> Pre-2086upd servers will rapidly become extinct, and clients will be 
> written that can only handle 2086upd.
> 
> Otherwise, there is no point to 2086upd, and this entire effort should be 
> abandoned as a waste of time.

I don't see the logic there. There clearly are things that are broken in rfc
2086 in the sense that they need clarifying - the rights needed to delete
mailboxes, for instance. Some or indeed most existing applications may
already behave "correctly", due to luck or telepathy in interpreting the
original interpretation, and therefore not need changing.

That's if I understand correctly: the ACL2 proposal is being dropped. *That*
would have been a replacement, leading to three types of clients/servers:
those that do ACL1, those that do ACL2, and those which do both.

Making 2086upd instead should leave the majority of existing 2086
implementations compliant with 2086upd; that is, in most cases they should
not need to be changed to become 2086upd compliant. Or am I misunderstanding
the thrust of the 2086upd concept?

Regards,

Brian.

Date: Fri, 19 Nov 2004 08:41:53 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, [email-masked], Jutta Degener <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

On Fri, 19 Nov 2004, Dave Cridland wrote:
> It solves no problems, it adds complexity.
> Adding complexity has a history of adding problems.
> Therefore we cannot (or, if you prefer, should not) make this change.
> What's there to understand? This isn't rocket science...

IMAP is a protocol which stipulates case-independence in its tokens 
throughout.  Only data, such as message data or (optionally) mailbox names 
are case-dependent, but even then INBOX is case-independent.

ACL rights are an IMAP token.  The only reason why anyone ever thought 
that they would be case-dependent was that the syntax rule used was 
astring in order to avoid having to decide upon a syntax for empty rights. 
This was a design mistake in 2086.  I have been objecting to 2086's design 
mistakes repeatedly for many years.

Therefore, ACL rights are the only IMAP token which is case-dependent. 
This solves no problems (the additional 26 rights are not needed), it 
adds complexity.  Adding complexity has a history of adding problems. 
Therefore we cannnot (or, if you prefer, should not) make this change. 
What's there to understand?  This isn't rocket science...

> I've yet to see *any* technical argument for (a) here - lots of discussion 
> about whether it's more in the "spirit of IMAP", etc. Nothing about whether 
> it's actually a useful or sensible thing to do, especially in this 
> specification.

The best way to ruin a technical specification is to ignore the original 
spirit and graft on something that is totally foreign.

C++ is an excellent example.

>> Simply define that any 2086upd (and ACL2) compliant server MUST have 
>> case-insensitive rights,...
>> 	*AND*
>> define that servers MUST send rights as lower case (MUST NOT send rights
>> as upper case)
> The two above suggest that rights remain case-sensitive to all intents and 
> purposes.
> I fail to see any practical difference that this makes.

Not quite.  They establish the framework for the future.  In particular, 
they instruct new implementations to read case-insensitive, even though at 
present they must only send lowercase.  Some time in the future, the 
latter part of the previous sentence will be moot; nobody will use 
pre-2086upd servers any more.

> However, do you honestly think that client authors will change their code to 
> send uppercase rights? (I mean, discounting the kinds of authors who 
> deliberately do weird things because they can.)

I don't think that; I *know* that.

> Now, on the contrary position, will there be new client authors who 
> misunderstand, or simply fail to read, the specification, hear that "rights 
> are case-insensitive", and break interoperability with older servers? I 
> believe this will be the case - hence the reason why additional complexity 
> tends to cause problems.

Pre-2086upd servers will rapidly become extinct, and clients will be 
written that can only handle 2086upd.

Otherwise, there is no point to 2086upd, and this entire effort should be 
abandoned as a waste of time.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

From: Dave Cridland <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, <[email-masked]>, Jutta Degener <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Date: Fri, 19 Nov 2004 16:05:10 +0000
Sender: [email-masked]

On Thu Nov 18 16:01:47 2004, Mark Crispin wrote:
> On Thu, 18 Nov 2004, Dave Cridland wrote:
>> Therefore, we cannot make rights case-insensitive. Any attempt to 
>> do so would appear to create more problems than it could possibly 
>> solve.
> 
> I don't understand why.
> 
> 
It solves no problems, it adds complexity.

Adding complexity has a history of adding problems.

Therefore we cannot (or, if you prefer, should not) make this change.

What's there to understand? This isn't rocket science...

> You identified that there is a problem that would be caused by an 
> abrupt transition.  So don't have an abrupt transition.  This isn't 
> rocket science; we know how to do this.
> 
> 
[As an aside, all abrupt transitions in protocols cause problems...]

Indeed - but there are two ways of avoiding an abrupt transition. 
Either:

a) Use some careful language in the specification, defining a set of 
rules by which there is, in effect, no transition apparent for 
innocent implementations.
b) Not have a transition at all.

(a) can be done - I appreciate that changes are possible, and indeed 
sometimes needed to further the protocol. The outlined rules you 
state do indeed provide this.

I think (b) has more technical merit in this circumstance, however. 
In fact, I've yet to see *any* technical argument for (a) here - lots 
of discussion about whether it's more in the "spirit of IMAP", etc. 
Nothing about whether it's actually a useful or sensible thing to do, 
especially in this specification.

> Simply define that any 2086upd (and ACL2) compliant server MUST 
> have case-insensitive rights,...
> 	*AND*
> define that servers MUST send rights as lower case (MUST NOT send 
> rights
> as upper case)

The two above suggest that rights remain case-sensitive to all 
intents and purposes.

I fail to see any practical difference that this makes. I see an 
aesthetic difference - we can now say "They're case-insensitive", but 
I don't see any *real* difference. This *is* adding complexity, to 
the language used if nothing else.

Case-insensitive means "upper and lower case are treated 
identically". This says "upper and lower case are treated 
identically, except that you can't use upper case". Some cases are 
less insensitive than others, if you like literary paraphrasing.

> 	*AND*
> define that clients MUST send rights as lower case (MUST NOT send 
> rights as upper case) to pre-2086upd servers.
> 
> If there is no way for a client to detect a pre-2086upd server, 
> then simply remove "to pre-2086upd servers" in the last part.
> 
> 
There is a way to detirmine if the server supports the extra rights, 
and, by inference, is RFC2086-upd or not, true.

However, do you honestly think that client authors will change their 
code to send uppercase rights? (I mean, discounting the kinds of 
authors who deliberately do weird things because they can.)

The only circumstance I can think of is clients which send XET rather 
than xet - the new rights being added as capitals. I can't really see 
this being an advantage to the author to do so, and I strongly 
suspect that all existent implementations of RFC2086 will use the 
lowercase characters for consistency anyway.

Now, on the contrary position, will there be new client authors who 
misunderstand, or simply fail to read, the specification, hear that 
"rights are case-insensitive", and break interoperability with older 
servers? I believe this will be the case - hence the reason why 
additional complexity tends to cause problems.

The interoperability break is particularly disturbing - it's a silent 
breakage in at least one widely deployed implementation, for example:

C: A01 SETACL INBOX foo lrS
S: A01 OK Completed
C: A02 GETACL INBOX
S: * ACL INBOX dwd lrswipcda foo lr
S: A02 OK Completed

> In ACL2, this can be removed entirely, at least for ACL2 only 
> software.
> 
> 
For ACL2, which is now a long way off, we can make different 
decisions.

It's worth reserving all uppercase rights in this specification to 
keep the options open.

>> lswiPda is currently treated by many clients and servers as lswida.
> 
> How many clients rely upon this behavior by sending lswiPda 
> assuming that the server will see it as lswida?

None, because P isn't a defined right. However, if we wave some 
mythical case-insensitivity at client authors, somebody somewhere 
*will* misread (or not read) this, and get very, very confused about 
why their rights aren't being set by the server. (Apologies for 
answering your rhetorical question.)

Dave.

Date: Thu, 18 Nov 2004 13:26:13 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, Jutta Degener <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

Hi Mark,

--On November 17, 2004 14:24:30 -0800 Mark Crispin <[email-masked]> 
wrote:

>> (Personally, I'd prefer case-*in*sensitivity - I have trouble
>> remembering which case meant what, why shouldn't other people;
>> but our implementations don't behave like that now.)
>
> This is my preference as well, and is consistant with the rest of IMAP.
>
> Unless there is an intent to use upper-case rights in the future to mean
> something different, would it be possible to transit to a case
> insensitive regime by stating that rights are case-insensitive, but that
> clients MUST send rights as lowercase?

My client will not recognize rights from a server if they are upper case, 
so the server would have to send lowercase rights as well to be backwards 
compatible, at which point the rights are effectively case sensitive.

WRT use of upper-case, I know at some point in the ACL2 debate we had 
talked about a simplified model of rights for 'simple' clients: e.g. 'RWX' 
style rights that would be tied in some well-defined way to the underlying 
lower case rights. So my feeling is we should reserve uppercase rights for 
now.

-- 
Cyrus Daboo

Date: Thu, 18 Nov 2004 18:00:56 +0000
From: Alexey Melnikov <[email-masked]>
To: Dave Cridland <[email-masked]>
CC: [email-masked]
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

Dave Cridland wrote:

>> Having said that I have to admit that I don't have a strong opinion 
>> on the issue. I would slightly prefere prohibiting uppercase rights - 
>> many existing clients will not treat them the same way as their 
>> lowercase counterparts.
>
> Indeed, Arnt has to start begging for mercy right now, it seems - 
> lswiPda is currently treated by many clients and servers as lswida.
>
> Cyrus IMAPd, 

Which is arguably a bug.

> as well as every client I've examined the source for (not many) ignore 
> unrecognised rights, which include all uppercase ones.

2086upd requires that all clients that can do SETACL preserve 
unrecognized rights.

For clients that only use GETACL/MYRIGHTS, it is ok to ignore 
unrecognized rights.

Date: Thu, 18 Nov 2004 17:49:02 +0000
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: Dave Cridland <[email-masked]>, [email-masked]
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

Mark Crispin wrote:

> On Thu, 18 Nov 2004, Dave Cridland wrote:
>
>> Therefore, we cannot make rights case-insensitive. Any attempt to do 
>> so would appear to create more problems than it could possibly solve.
>
> I don't understand why.
>
> You identified that there is a problem that would be caused by an 
> abrupt transition.  So don't have an abrupt transition.  This isn't 
> rocket science; we know how to do this.
>
> Simply define that any 2086upd (and ACL2) compliant server MUST have 
> case-insensitive rights,...
>     *AND*
> define that servers MUST send rights as lower case (MUST NOT send rights
> as upper case)
>     *AND*
> define that clients MUST send rights as lower case (MUST NOT send 
> rights as upper case) to pre-2086upd servers.

The 2086upd document defines a new capability, so we can do that. And 
the client will be able to detect pre-2086upd servers.

> If there is no way for a client to detect a pre-2086upd server, then 
> simply remove "to pre-2086upd servers" in the last part.
>
> In ACL2, this can be removed entirely, at least for ACL2 only software.

Yes.

Date: Thu, 18 Nov 2004 08:01:47 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, [email-masked], Jutta Degener <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

On Thu, 18 Nov 2004, Dave Cridland wrote:
> Therefore, we cannot make rights case-insensitive. Any attempt to do so would 
> appear to create more problems than it could possibly solve.

I don't understand why.

You identified that there is a problem that would be caused by an abrupt 
transition.  So don't have an abrupt transition.  This isn't rocket 
science; we know how to do this.

Simply define that any 2086upd (and ACL2) compliant server MUST have 
case-insensitive rights,...
 	*AND*
define that servers MUST send rights as lower case (MUST NOT send rights
as upper case)
 	*AND*
define that clients MUST send rights as lower case (MUST NOT send rights 
as upper case) to pre-2086upd servers.

If there is no way for a client to detect a pre-2086upd server, then 
simply remove "to pre-2086upd servers" in the last part.

In ACL2, this can be removed entirely, at least for ACL2 only software.

> lswiPda is currently treated by many clients and servers as lswida.

How many clients rely upon this behavior by sending lswiPda assuming that 
the server will see it as lswida?

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

From: Dave Cridland <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: <[email-masked]>, Jutta Degener <[email-masked]>, Mark Crispin <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Date: Thu, 18 Nov 2004 15:38:42 +0000
Sender: [email-masked]

On Thu Nov 18 13:19:25 2004, Alexey Melnikov wrote:
> Arnt Gulbrandsen wrote:
>> Mark Crispin writes:
>>> On Wed, 17 Nov 2004, Jutta Degener wrote:
>>> 
>>>> (Personally, I'd prefer case-*in*sensitivity - I have trouble 
>>>> remembering which case meant what, why shouldn't other people; 
>>>> but our implementations don't behave like that now.)
>>> 
>>> This is my preference as well, and is consistant with the rest of 
>>> IMAP.
>>> 
>>> Unless there is an intent to use upper-case rights in the future 
>>> to mean something different, would it be possible to transit to a 
>>> case insensitive regime by stating that rights are 
>>> case-insensitive, but that clients MUST send rights as lowercase?
>> 
>> 
>> I strongly agree. It's hard enough to remember lswipda, if lswiPda 
>> were someday to be different I'd have to beg for mercy. Mark's 
>> suggestion is a good way forward, IMO.
> 
> I remember we were using "S" as as an example, i.e. "s" controls 
> the private \Seen and "S" might control the shared \Seen flag.
> So if we are going to allow for upper case rights, they have to be 
> somehow related to the corresponding lowercase ones.
> 
> 
That seems fair, though we'd have to try to ensure that they followed 
the same relationship where possible, hence "n" would become "N", and 
"m" would become "n".

I'm not fussed on using uppercase rights at all, though.

> Having said that I have to admit that I don't have a strong opinion 
> on the issue. I would slightly prefere prohibiting uppercase rights 
> - many existing clients will not treat them the same way as their 
> lowercase counterparts.

Indeed, Arnt has to start begging for mercy right now, it seems - 
lswiPda is currently treated by many clients and servers as lswida.

Cyrus IMAPd, as well as every client I've examined the source for 
(not many) ignore unrecognised rights, which include all uppercase 
ones.

They all appear to transform the rights string into a bitfield using 
code very similar to:

{
	char * p( rights ); /* assuming rights is a char * */
	unsigned rights_bitfield( 0 );
	while( *p ) {
		switch( *p ) {
		case 'a':
			rights_bitfield |= IMAP_ACL_ADMIN;
			break;
		/* etc, without a default: */
		}
	}
}

Hence unknown rights are completely ignored (good for clients, not so 
sure this is correct for a server) and this includes uppercase rights.

Therefore, we cannot make rights case-insensitive. Any attempt to do 
so would appear to create more problems than it could possibly solve.

Dave.

Date: Thu, 18 Nov 2004 13:19:25 +0000
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked], Jutta Degener <[email-masked]>, Mark Crispin <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Mark Crispin writes:
>
>> On Wed, 17 Nov 2004, Jutta Degener wrote:
>>
>>> (Personally, I'd prefer case-*in*sensitivity - I have trouble 
>>> remembering which case meant what, why shouldn't other people; but 
>>> our implementations don't behave like that now.)
>>
>> This is my preference as well, and is consistant with the rest of IMAP.
>>
>> Unless there is an intent to use upper-case rights in the future to 
>> mean something different, would it be possible to transit to a case 
>> insensitive regime by stating that rights are case-insensitive, but 
>> that clients MUST send rights as lowercase?
>
>
> I strongly agree. It's hard enough to remember lswipda, if lswiPda 
> were someday to be different I'd have to beg for mercy. Mark's 
> suggestion is a good way forward, IMO.

I remember we were using "S" as as an example, i.e. "s" controls the 
private \Seen and "S" might control the shared \Seen flag.
So if we are going to allow for upper case rights, they have to be 
somehow related to the corresponding lowercase ones.

Having said that I have to admit that I don't have a strong opinion on 
the issue. I would slightly prefere prohibiting uppercase rights - many 
existing clients will not treat them the same way as their lowercase 
counterparts.

Alexey

Date: Thu, 18 Nov 2004 13:16:37 +0000
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Lyndon Nerenberg writes:
>
>> Just to be Devil's Advocate:
>>
>> 1) Are we sure 36 rights will be enough?
>
> Viewed from an i14y/testing viewpoint, 36 rights is Too Much. If the 
> standard ever becomes that complex and finegrained, then IMO, even 
> sane and reasonable client developers may develop specifically for the 
> two most common servers.

I agree that 36 rights is too much.

Date: Thu, 18 Nov 2004 12:05:05 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Cc: Lyndon Nerenberg <[email-masked]>, Jutta Degener <[email-masked]>, Mark Crispin <[email-masked]>
Sender: [email-masked]

Lyndon Nerenberg writes:
> Just to be Devil's Advocate:
>
> 1) Are we sure 36 rights will be enough?

Viewed from an i14y/testing viewpoint, 36 rights is Too Much. If the 
standard ever becomes that complex and finegrained, then IMO, even sane 
and reasonable client developers may develop specifically for the two 
most common servers.

Arnt

Date: Thu, 18 Nov 2004 11:59:45 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Cc: Jutta Degener <[email-masked]>, Mark Crispin <[email-masked]>
Sender: [email-masked]

Mark Crispin writes:
> On Wed, 17 Nov 2004, Jutta Degener wrote:
>> (Personally, I'd prefer case-*in*sensitivity - I have trouble 
>> remembering which case meant what, why shouldn't other people; but 
>> our implementations don't behave like that now.)
>
> This is my preference as well, and is consistant with the rest of IMAP.
>
> Unless there is an intent to use upper-case rights in the future to 
> mean something different, would it be possible to transit to a case 
> insensitive regime by stating that rights are case-insensitive, but 
> that clients MUST send rights as lowercase?

I strongly agree. It's hard enough to remember lswipda, if lswiPda were 
someday to be different I'd have to beg for mercy. Mark's suggestion is 
a good way forward, IMO.

Arnt

From: Dave Cridland <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>, Alexey Melnikov <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Date: Thu, 18 Nov 2004 10:01:07 +0000
Sender: [email-masked]

On Wed Nov 17 20:43:07 2004, Cyrus Daboo wrote:
> --On November 17, 2004 20:27:35 +0000 Alexey Melnikov 
> <[email-masked]> wrote:
> 
>>> Leave it the same as 2086 (original), but perhaps call extra 
>>> attention
>>> to the fact that it is case-sensitive.
>> 
>> RFC 2086 was silent on the issue. I believe the intention was to 
>> make
>> rights case-sensitive.
> 
> OK, well I guess we will have to find out what real implementations 
> did and make sure it is clear in 2086upd which way it should be. I 
> can tell you that my implementation treats the rights as 
> case-sensitive.

I can tell you that Mutt and Mozilla Mail/News also both appear to 
treat rights as case-sensitive. I could be wrong, but it looks that 
way. I can't tell you what the server implementations do, although I 
know Cyrus IMAPd just ignores any unknown rights, including 
upper-case ones.

I strongly suspect that everything treats them as case-sensitive.

Dave.

From: Dave Cridland <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>, Mark Crispin <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Date: Thu, 18 Nov 2004 09:17:42 +0000
Sender: [email-masked]

On Thu Nov 18 02:18:55 2004, Lyndon Nerenberg wrote:
> 
> --On 2004-11-17 5:58 PM -0800 Mark Crispin <[email-masked]> 
> wrote:
> 
>> If we aren't certain, is it a mistake to have single-character 
>> rights?
> 
> Not if they are UTF-8 characters :-P
> 
> 
Rights are defined in 2086 as US-ASCII.

Nice try, though. :-)

Dave.

Date: Wed, 17 Nov 2004 18:18:55 -0800
From: Lyndon Nerenberg <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

--On 2004-11-17 5:58 PM -0800 Mark Crispin <[email-masked]> 
wrote:

> If we aren't certain, is it a mistake to have single-character rights?

Not if they are UTF-8 characters :-P

> I agree that, because 2086 rights are an <astring>, IMAP's case
> folding rules do not require 2806 rights to be case insensitive.  I
> disagree with your conclusion that they are required to be case
> sensitive.  I consider IMAP to be silent on this point.

But I defer to ABNF, where everything is case-sensitive unless 
explicitly stated otherwise. (Yes, ACL predates ABNF spec.)

No matter, I'm just issuing a heads-up. I won't go non-linear if 
case-folding is the consensus.

--lyndon

Date: Wed, 17 Nov 2004 17:58:50 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>
cc: Jutta Degener <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Wed, 17 Nov 2004, Lyndon Nerenberg wrote:
> 1) Are we sure 36 rights will be enough?

I don't know.  Are we?

If we aren't certain, is it a mistake to have single-character rights?

> 2) <astring> is not case-folded. Since <rights> are an <astring> I would 
> argue that <rights> MUST be case sensitive. (Nothing in 2086 calls out for 
> case-folding, therefore it cannot be assumed by any conforming 
> implementation.)

I agree that, because 2086 rights are an <astring>, IMAP's case folding 
rules do not require 2806 rights to be case insensitive.  I disagree with 
your conclusion that they are required to be case sensitive.  I consider 
IMAP to be silent on this point.

However, as the original architect of IMAP, I consider it to be a mistake 
that rights are an astring as opposed to an atom equivalent.  That is, I 
think that it would have been closer to the "spirit of IMAP" if it were 
something like:

    mod_rights      ::= ["+" / "-"] rights

    rights          ::= 1*right / "-"

    right           ::= ALPHA / DIGIT
                          ; Case-insensitive

where "-" means "empty rights", or (if 36 rights aren't enough):

    rights          ::= 1*right / nil

    right           ::= atom

In fact, if it weren't for the "chattiness" objections that are commonly 
made about IMAP, I would consider the latter to be the True IMAP Way.

However, I am just mumbling here.  I am not seriously suggesting that it 
be changed at this late date, so everybody please lower your hackles... 
:-)

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Wed, 17 Nov 2004 17:40:29 -0800
From: Lyndon Nerenberg <[email-masked]>
To: Mark Crispin <[email-masked]>, Jutta Degener <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

--On 2004-11-17 2:24 PM -0800 Mark Crispin <[email-masked]> 
wrote:

> Unless there is an intent to use upper-case rights in the future to
> mean something different, would it be possible to transit to a case
> insensitive regime by stating that rights are case-insensitive, but
> that clients MUST send rights as lowercase?

Just to be Devil's Advocate:

1) Are we sure 36 rights will be enough?

2) <astring> is not case-folded. Since <rights> are an <astring> I 
would argue that <rights> MUST be case sensitive. (Nothing in 2086 
calls out for case-folding, therefore it cannot be assumed by any 
conforming implementation.)

--lyndon

Date: Wed, 17 Nov 2004 14:24:30 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Jutta Degener <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Wed, 17 Nov 2004, Jutta Degener wrote:
> (Personally, I'd prefer case-*in*sensitivity - I have trouble
> remembering which case meant what, why shouldn't other people;
> but our implementations don't behave like that now.)

This is my preference as well, and is consistant with the rest of IMAP.

Unless there is an intent to use upper-case rights in the future to mean 
something different, would it be possible to transit to a case insensitive 
regime by stating that rights are case-insensitive, but that clients MUST 
send rights as lowercase?

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Wed, 17 Nov 2004 14:16:10 -0800
From: Jutta Degener <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

On Wed, Nov 17, 2004 at 03:43:07PM -0500, Cyrus Daboo wrote:
> OK, well I guess we will have to find out what real implementations did and 
> make sure it is clear in 2086upd which way it should be. I can tell you 
> that my implementation treats the rights as case-sensitive.

Sendmail's does, too.

(Personally, I'd prefer case-*in*sensitivity - I have trouble 
remembering which case meant what, why shouldn't other people;
but our implementations don't behave like that now.)

Jutta Degener <[email-masked]>

Date: Wed, 17 Nov 2004 15:43:07 -0500
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

Hi Alexey,

--On November 17, 2004 20:27:35 +0000 Alexey Melnikov 
<[email-masked]> wrote:

>> Leave it the same as 2086 (original), but perhaps call extra attention
>> to the fact that it is case-sensitive.
>
> RFC 2086 was silent on the issue. I believe the intention was to make
> rights case-sensitive.

OK, well I guess we will have to find out what real implementations did and 
make sure it is clear in 2086upd which way it should be. I can tell you 
that my implementation treats the rights as case-sensitive.

-- 
Cyrus Daboo

Date: Wed, 17 Nov 2004 20:27:35 +0000
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

Cyrus Daboo wrote:

> Hi Alexey,
>
> --On November 17, 2004 19:10:16 +0000 Alexey Melnikov 
> <[email-masked]> wrote:
>
>> The document says that all rights are case-sensitive, i.e. "r" is not 
>> the
>> same as "R". Is this is problem?
>> Currently there are not uppercase rights assigned.
>
> Leave it the same as 2086 (original), but perhaps call extra attention 
> to the fact that it is case-sensitive.

RFC 2086 was silent on the issue. I believe the intention was to make 
rights case-sensitive.

Date: Wed, 17 Nov 2004 15:25:26 -0500
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

Hi Alexey,

--On November 17, 2004 19:10:16 +0000 Alexey Melnikov 
<[email-masked]> wrote:

> The document says that all rights are case-sensitive, i.e. "r" is not the
> same as "R". Is this is problem?
> Currently there are not uppercase rights assigned.

Leave it the same as 2086 (original), but perhaps call extra attention to 
the fact that it is case-sensitive.

-- 
Cyrus Daboo

Date: Wed, 17 Nov 2004 19:10:16 +0000
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

The document says that all rights are case-sensitive, i.e. "r" is not 
the same as "R". Is this is problem?
Currently there are not uppercase rights assigned.

Date: Wed, 17 Nov 2004 18:11:20 +0000
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: 2086upd + ANNOTATE dependency
Sender: [email-masked]

Ken Murchison wrote:

> Cyrus Daboo wrote:
>
>> What I propose is to remove all references to ANNOTATE in 2086upd. 
>> The ANNOTATE document will define the new ACL bits and have a 
>> normative reference to 2086upd. That way 2086upd can progress quickly 
>> without being blocked on ANNOTATE (which itself is blocked on 
>> SORT/THREAD/i18n).
>
> Agreed.

If we are going this route, the ANNOTATE document must be updated to say 
that the "n" right (writing shared annotations) is a part of the "shared 
flag rights" as defined in section 5.2 of the 2086upd ("Mapping of ACL 
rights to READ-WRITE and READ-ONLY response codes").

From: Dave Cridland <[email-masked]>
To: Ken Murchison <[email-masked]>
Cc: Brian Candler <[email-masked]>, Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>, Philip Guenther <[email-masked]>
Subject: Re: Updated draft-ietf-imapext-2086upd (ACL)
Date: Wed, 17 Nov 2004 14:12:06 +0000
Sender: [email-masked]

On Mon Nov 15 20:27:02 2004, Ken Murchison wrote:
> Interop with both old and new clients will be a problem.  I don't 
> have all of the answers yet, I'd have to discuss this with the 
> other Cyrus guys to see if we can work out a solution.  I'm just 
> pointing out that the current wording in the draft doesn't work 
> with all implementations.

My initial thought was that you'd be right, for two reasons:

1) Client authors may have independently made the same interpretation.
2) Client authors may have deliberately copied Cyrus IMAPd's 
interpretation, given that it's a widely known and used RFC2086 
server implementation.

To see if this was the case, I decided to read through several IMAP 
client implementations. My overall assumption was that open-sourced 
implementations would be most likely to show (2) above, and hence 
would be visible and a reasonable sample.

I looked for two key features of the code:

a) A suppression of the UI for folder deletion based on MYRIGHTS 
output.
b) A suppression of actual deletion based on MYRIGHTS output.

I read through the source code for Balsa, Mutt, and Mozilla.

I have found no evidence for either happening.

I'm also told that Evolution doesn't support RFC2086 at all.

Documentation for APIs, however, suggests differently.

Both Sun's JavaMail documentation and perl's IMAP::Admin module 
documentation makes the claim that the "c" right allows for DELETE 
(and RENAME) on submailboxes.

Communigate Pro's documentation states that deleting a mailbox 
requires both the "c" right on the parent *and* the "d" right on the 
mailbox itself.

Incidentally, Cyrus's major problem is that the "x" right needs to be 
granted, as I understand it, on all submailboxes of a parent which 
has the "c" right - "c" cannot therefore be a macro for "kx", where 
"k" is for CREATE (and is the current "c").

I have no real conclusions about this - I'd be interested in knowing 
what any other clients are doing.

My general feeling is that the current draft can stand, but I'd 
appreciate knowing a little more about other implementations.

Dave.

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-2086upd-01.txt
Date: Tue, 16 Nov 2004 16:13:24 -0500
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 - updated list of rights
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-imapext-2086upd-01.txt
	Pages		: 0
	Date		: 2004-11-16
	
The ACL (Access Control List) extension [RFC2086] of the Internet Message
Access Protocol [IMAP4] permits mailbox access control lists to be
manipulated through the IMAP protocol.

This document updates the list of rights defined in RFC 2086. It
also clarifies which rights are required for different IMAP commands.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-2086upd-01.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-2086upd-01.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-2086upd-01.txt

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

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

--OtherAccess--

--NextPart--

Date: Mon, 15 Nov 2004 22:37:03 +0000
From: Brian Candler <[email-masked]>
To: Ken Murchison <[email-masked]>
Cc: Philip Guenther <[email-masked]>, Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Updated draft-ietf-imapext-2086upd (ACL)
Sender: [email-masked]

On Mon, Nov 15, 2004 at 03:27:02PM -0500, Ken Murchison wrote:
> >So, would
> >there be any way at all for the user of an old client to set or clear
> >the "x" right?  If setting or clearing the "c" right was to also affect
> >the "x" right then how would a new (RIGHTS-aware) client set or clear
> >the "c" right without affecting the "x" right?
> 
> Interop with both old and new clients will be a problem.  I don't have 
> all of the answers yet, I'd have to discuss this with the other Cyrus 
> guys to see if we can work out a solution.  I'm just pointing out that 
> the current wording in the draft doesn't work with all implementations.
> 
> One easy way to do this might be to make 'c' a macro in the new draft 
> just like 'd' and create a new bit for CREATE (e.g. 'k')  Then the 
> mapping would be:
> 
> Cyrus:  'c' -> "kx", 'd' -> "te"
> Others: 'c' -> "k",  'd' -> "xte"

Would it be a problem to make 'd' more permissive? Let me think aloud.

For example: imagine for a moment that c and x are tied (which is in effect
the current behaviour of Cyrus, IIUC)

Now, suppose we defined the 'd' right as implying e,t,x plus any rights tied
to those rights. Then if a client asked for 'd' they would get e+t+x+c.

Now: a client which asks for 'd' (intending "delete or expunge mail") will
find themselves also getting create submailbox and delete mailbox rights. I
don't know if Cyrus has any policy engine which lets you control which
rights requests are granted or refused; if it doesn't, then the worst that
will happen is that the person administering the ACL will end up adding more
rights to a particular user than they intended. And that will only happen if
the software used to set up the ACL only understands RFC2086 flags.

So what am I proposing? Maybe that the 'd' flag implies 'e','t','x' plus any
other flags that the implementation considers necessary. Or maybe that the
'd' flag implies *any* implementation-defined set of flags, but where the
recommended set is 'e','t' and 'x'; the goal being that the virtual 'd' flag
implies whatever set of flags is necessary so that the client has no fewer
rights than they would have had before when asking for 'd'. That's fine;
then the problem with Cyrus is that if you ask for 'c', you still get fewer
rights than you would have had before when asking for 'c'. If the client
understand RFC-2086upd then it can ask for 'x'; if not then it can ask for
'd', although it will end up with perhaps more rights than are needed.

Of course, if you are migrating from Cyrus version X (RFC-2086) to version Y
(RFC-2086upd), then any existing mailbox rights can be changed as part of
this migration. i.e. c becomes cx, d becomes xte. So this will only really
affect *ACL administrators* who are using *RFC-2086 clients* which also *do
not use LISTRIGHTS* to present the possible rights available to the
end-user.

Oh well, enough thinking aloud, as I don't seem to be getting very far :-)

Regards,

Brian.

Date: Mon, 15 Nov 2004 15:27:02 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Philip Guenther <[email-masked]>
CC: Brian Candler <[email-masked]>, Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Updated draft-ietf-imapext-2086upd (ACL)
Sender: [email-masked]

Philip Guenther wrote:

> Ken Murchison <[email-masked]> writes:
> ...
> 
>>>The difference would be that the client would be required to request both
>>>"c" and "x" in order to set this bit; but it would know that is necessary if
>>>it made use of the LISTRIGHTS information which indicated they were tied.
>>
>>We don't want to do this.  Spitting 'x' from 'c' is a migration issue 
>>specific to Cyrus, which we will have to handle.    As soon as we 
>>implement this update any existing ACL which has "c" will have to be 
>>reported as "cx".  The 'x' right will then have to be explicitly removed.
> 
> 
> ...if they don't want the user to have both rights but only create.
> 
> ...
> 
>>My problem is that the draft assumes that 'x' is a "sub-ACL" of 'd', 
>>which is not the case in Cyrus.  If a user sets 'd' in Cyrus, the server 
>>shouldn't have to set 'x' (because the draft says MUST) if it doesn't 
>>apply.  I have no problem with 'd' being a macro for 'e' and 't', but 
>>whether this macro also includes 'd' should be implementation specific.
> 
> 
> So you're proposing that an implementation (Cyrus) be allowed to not
> set/clear the "x" right when the "d" right is set/cleared.

Yes.  The draft makes the false assumption that *all* existing 
implementations use the 'd' right to control DELETE.  Cyrus made the 
decision a while back to separate mailbox ops (DELETE) from message ops 
(\Deleted and EXPUNGE).  Its unfortunate that RFC 2086 was 
vague/ambiguous w.r.t. DELETE.

> So, would
> there be any way at all for the user of an old client to set or clear
> the "x" right?  If setting or clearing the "c" right was to also affect
> the "x" right then how would a new (RIGHTS-aware) client set or clear
> the "c" right without affecting the "x" right?

Interop with both old and new clients will be a problem.  I don't have 
all of the answers yet, I'd have to discuss this with the other Cyrus 
guys to see if we can work out a solution.  I'm just pointing out that 
the current wording in the draft doesn't work with all implementations.

One easy way to do this might be to make 'c' a macro in the new draft 
just like 'd' and create a new bit for CREATE (e.g. 'k')  Then the 
mapping would be:

Cyrus:  'c' -> "kx", 'd' -> "te"
Others: 'c' -> "k",  'd' -> "xte"

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

To: Ken Murchison <[email-masked]>
Cc: Brian Candler <[email-masked]>, Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Updated draft-ietf-imapext-2086upd (ACL) 
Date: Mon, 15 Nov 2004 11:57:15 -0800
From: Philip Guenther <[email-masked]>
Sender: [email-masked]

Ken Murchison <[email-masked]> writes:
...
>> The difference would be that the client would be required to request both
>> "c" and "x" in order to set this bit; but it would know that is necessary if
>> it made use of the LISTRIGHTS information which indicated they were tied.
>
>We don't want to do this.  Spitting 'x' from 'c' is a migration issue 
>specific to Cyrus, which we will have to handle.    As soon as we 
>implement this update any existing ACL which has "c" will have to be 
>reported as "cx".  The 'x' right will then have to be explicitly removed.

...if they don't want the user to have both rights but only create.

...
>My problem is that the draft assumes that 'x' is a "sub-ACL" of 'd', 
>which is not the case in Cyrus.  If a user sets 'd' in Cyrus, the server 
>shouldn't have to set 'x' (because the draft says MUST) if it doesn't 
>apply.  I have no problem with 'd' being a macro for 'e' and 't', but 
>whether this macro also includes 'd' should be implementation specific.

So you're proposing that an implementation (Cyrus) be allowed to not
set/clear the "x" right when the "d" right is set/cleared.  So, would
there be any way at all for the user of an old client to set or clear
the "x" right?  If setting or clearing the "c" right was to also affect
the "x" right then how would a new (RIGHTS-aware) client set or clear
the "c" right without affecting the "x" right?

Philip Guenther

Date: Mon, 15 Nov 2004 14:21:20 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Brian Candler <[email-masked]>
CC: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Updated draft-ietf-imapext-2086upd (ACL)
Sender: [email-masked]

Brian Candler wrote:

> On Mon, Nov 15, 2004 at 12:45:46PM -0500, Ken Murchison wrote:
> 
>>I think we need to add language that says that 'x' must be associated 
>>with whichever ACL bit was previously used for DELETE, and not assume 
>>that its 'd'.
> 
> 
> I'm not sure there is a problem, because RFC2086 explicitly allows the
> server to tie together whichever bits it likes in whichever way is
> convenient to it:
> 
>    An implementation may tie rights together or may force rights to
>    always or never be granted to particular identifiers.  For example,
>    in an implementation that uses unix mode bits, the rights "wisd" are
>    tied, the "a" right is always granted to the owner of a mailbox and
>    is never granted to another user.  If rights are tied in an
>    implementation, the implementation must be conservative in granting
>    rights in response to SETACL commands--unless all rights in a tied
>    set are specified, none of that set should be included in the ACL
>    entry for that identifier.  A client may discover the set of rights
>    which may be granted to a given identifier in the ACL for a given
>    mailbox by using the LISTRIGHTS command.

I'm fully aware of this, but we don't want to tie any rights together. 
That's the whole point of the new specs.

> So in Cyrus you can have a single bit internally, which (if set) is reported
> to the client as "cx".

We already have one and its 'c'.

> The difference would be that the client would be required to request both
> "c" and "x" in order to set this bit; but it would know that is necessary if
> it made use of the LISTRIGHTS information which indicated they were tied.

We don't want to do this.  Spitting 'x' from 'c' is a migration issue 
specific to Cyrus, which we will have to handle.    As soon as we 
implement this update any existing ACL which has "c" will have to be 
reported as "cx".  The 'x' right will then have to be explicitly removed.

> Now, "d" being an alias for e+t+x is a bit of a special case. But at least
> it is a single, well-defined special case; and also note that "d" is not a
> real bit in its own right, but a virtual bit synthesised from (e && t && x).
> I can't see a clean way to do what you seem to be suggesting, which is to
> associate "x" with another bit, apart from the mechanism which is already
> there which allows bits to be tied together.
> 
> Can you be more specific on what you are proposing?

My problem is that the draft assumes that 'x' is a "sub-ACL" of 'd', 
which is not the case in Cyrus.  If a user sets 'd' in Cyrus, the server 
shouldn't have to set 'x' (because the draft says MUST) if it doesn't 
apply.  I have no problem with 'd' being a macro for 'e' and 't', but 
whether this macro also includes 'd' should be implementation specific.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Mon, 15 Nov 2004 13:52:53 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: 2086upd + ANNOTATE dependency
Sender: [email-masked]

Cyrus Daboo wrote:

> What I propose is to remove all references to ANNOTATE in 2086upd. The 
> ANNOTATE document will define the new ACL bits and have a normative 
> reference to 2086upd. That way 2086upd can progress quickly without 
> being blocked on ANNOTATE (which itself is blocked on SORT/THREAD/i18n).

Agreed.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Mon, 15 Nov 2004 18:32:22 +0000
From: Brian Candler <[email-masked]>
To: Ken Murchison <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Updated draft-ietf-imapext-2086upd (ACL)
Sender: [email-masked]

On Mon, Nov 15, 2004 at 12:45:46PM -0500, Ken Murchison wrote:
> I think we need to add language that says that 'x' must be associated 
> with whichever ACL bit was previously used for DELETE, and not assume 
> that its 'd'.

I'm not sure there is a problem, because RFC2086 explicitly allows the
server to tie together whichever bits it likes in whichever way is
convenient to it:

   An implementation may tie rights together or may force rights to
   always or never be granted to particular identifiers.  For example,
   in an implementation that uses unix mode bits, the rights "wisd" are
   tied, the "a" right is always granted to the owner of a mailbox and
   is never granted to another user.  If rights are tied in an
   implementation, the implementation must be conservative in granting
   rights in response to SETACL commands--unless all rights in a tied
   set are specified, none of that set should be included in the ACL
   entry for that identifier.  A client may discover the set of rights
   which may be granted to a given identifier in the ACL for a given
   mailbox by using the LISTRIGHTS command.

So in Cyrus you can have a single bit internally, which (if set) is reported
to the client as "cx".

The difference would be that the client would be required to request both
"c" and "x" in order to set this bit; but it would know that is necessary if
it made use of the LISTRIGHTS information which indicated they were tied.

Now, "d" being an alias for e+t+x is a bit of a special case. But at least
it is a single, well-defined special case; and also note that "d" is not a
real bit in its own right, but a virtual bit synthesised from (e && t && x).
I can't see a clean way to do what you seem to be suggesting, which is to
associate "x" with another bit, apart from the mechanism which is already
there which allows bits to be tied together.

Can you be more specific on what you are proposing?

Regards,

Brian.

Date: Mon, 15 Nov 2004 12:47:31 -0500
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: 2086upd + ANNOTATE dependency
Sender: [email-masked]

Should 2086upd mention ANNOTATE at all? Right now it does define the 'n' 
right but has very little to say about it, other than providing the 
informative reference to ANNOTATE. That reference really ought to be 
normative since the meaning of 'n' (and 'm') are important. However, this 
adds a two-way dependency between 2086upd and ANNOTATE.

What I propose is to remove all references to ANNOTATE in 2086upd. The 
ANNOTATE document will define the new ACL bits and have a normative 
reference to 2086upd. That way 2086upd can progress quickly without being 
blocked on ANNOTATE (which itself is blocked on SORT/THREAD/i18n).

-- 
Cyrus Daboo

Date: Mon, 15 Nov 2004 12:45:46 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Alexey Melnikov <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Updated draft-ietf-imapext-2086upd (ACL)
Sender: [email-masked]

I just noticed something in this draft, and ACL2 for that matter, which 
may cause problems with Cyrus.  The draft seems to assume that the old 
'd' right was used to allow the DELETE command, where RFC 2086 was vague 
on this (in fact it never mentions DELETE or RENAME).  All current Cyrus 
code uses the 'c' right for both CREATE and DELETE.  So for Cyrus, 
associating the new 'x' right with 'd' doesn't make any sense, it would 
probably be associated with 'c'.

I think we need to add language that says that 'x' must be associated 
with whichever ACL bit was previously used for DELETE, and not assume 
that its 'd'.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Mon, 15 Nov 2004 12:08:13 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: IMAP Extensions WG <[email-masked]>
CC: Alexey Melnikov <[email-masked]>
Subject: Re: Outstanding issues for draft-ietf-imapext-2086upd-00 (ACL)
Sender: [email-masked]

Dave Cridland wrote:
> 
> On Mon Nov 15 12:45:30 2004, Alexey Melnikov wrote:
> 
>> Alexey Melnikov wrote:
>>
>>> The second issue:
>>>
>>> Which rights are required for the LISTRIGHTS command?
>>>
>>> Currently the document says:
>>>
>>>    MYRIGHTS - any of the following rights is required to perform
>>>     the operation: "l", "r", "i", "c", "x", "a".*
>>>
>>>    LISTRIGHTS - same as MYRIGHTS.
>>>
>>> Some of the existing servers follow this suggestion. Some allow for
>>> LISTRIGHTS if "r" and/or "a" is granted.
>>>
>>> Philip has suggested (and I agree) to only allow LISTRIGHTS when the "a"
>>> right is granted, as LISTRIGHTS information is only useful
>>> if you can also do SETACL. Also, such information shouldn't be disclosed
>>> to users that have insufficient rights.
>>
>>
>> So, any comments on changing LISTRIGHTS to require the "a" right?
> 
> 
> As a client implementor of sorts, I can't see any reason for using 
> LISTRIGHTS if I didn't intend to use the results to frame a SETACL or 
> DELETEACL.
> 
> Hence I'm in agreement - make it require "a".

I'm also in agreement.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Mon, 15 Nov 2004 16:51:39 +0000
From: Alexey Melnikov <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: [email-masked]
Subject: Re: Clarification of "d" right in imapext-acl
Sender: [email-masked]

Philip Guenther wrote:

>Alexey Melnikov <[email-masked]> writes:
>  
>
>>Philip Guenther wrote:
>>    
>>
>>>Please review the 2086upd draft as soon as possible, as it should be
>>>going to working group last call Real Soon Now.  Only one substantive
>>>change was discussed at the IETF meeting last week: instead of returning
>>>a MYRIGHTS response, the SELECT command should return a MYRIGHTS
>>>response _code_.  So, for example, this line from the SELECT example in
>>>section 7.1.1:
>>>              S: * MYRIGHTS INBOX rwis
>>>will end up instead reading:
>>>              S: * OK [MYRIGHTS INBOX rwis] Blah blah your rights
>>>      
>>>
>>The ACL2 document defines MYRIGHTS response code, but it doesn't include 
>>a mailbox name. Is it Ok?
>>    
>>
>
>So it should instead read:
>                 S: * OK [MYRIGHTS rwis] No more, no less
>
>
>The Formal Syntax needs to define the syntax for that as an extension of
>resp-text-code:
>
>resp-text-code  =/ myrights_rspcod
>
>myrights_rspcod = "MYRIGHTS" SP rights
>
>rights          = atom
>                   ;; MUST NOT contain leading "+" or "-"
>                   ;; MUST be treated as case-sensitive
>
>Hmm, interesting: ACL2 used 'quoted' instead of 'atom' for rights.
>Since a non-ATOM-CHAR right can't appear in the RIGHT=... capability, no
>point in allowing them here in the MYRIGHTS response code.
>  
>
I agree.

>The UTF-8 reference should be updated the RFC 3629.
>
Done.

>It should be noted
>somewhere that an identifier containing non-US-ASCII characters MUST be
>represented as a literal and not a quoted-string or atom.
>  
>
This just follows from rules for literals defined in RFC 3501.

From: Dave Cridland <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Outstanding issues for draft-ietf-imapext-2086upd-00 (ACL)
Date: Mon, 15 Nov 2004 16:44:33 +0000
Sender: [email-masked]

On Mon Nov 15 12:45:30 2004, Alexey Melnikov wrote:
> Alexey Melnikov wrote:
>> The second issue:
>> 
>> Which rights are required for the LISTRIGHTS command?
>> 
>> Currently the document says:
>> 
>>    MYRIGHTS - any of the following rights is required to perform
>>     the operation: "l", "r", "i", "c", "x", "a".*
>> 
>>    LISTRIGHTS - same as MYRIGHTS.
>> 
>> Some of the existing servers follow this suggestion. Some allow for
>> LISTRIGHTS if "r" and/or "a" is granted.
>> 
>> Philip has suggested (and I agree) to only allow LISTRIGHTS when 
>> the "a"
>> right is granted, as LISTRIGHTS information is only useful
>> if you can also do SETACL. Also, such information shouldn't be 
>> disclosed
>> to users that have insufficient rights.
> 
> So, any comments on changing LISTRIGHTS to require the "a" right?

As a client implementor of sorts, I can't see any reason for using 
LISTRIGHTS if I didn't intend to use the results to frame a SETACL or 
DELETEACL.

Hence I'm in agreement - make it require "a".

Dave.

To: Alexey Melnikov <[email-masked]>
From: Philip Guenther <[email-masked]>
Cc: Brian Candler <[email-masked]>, [email-masked]
Subject: Re: Clarification of "d" right in imapext-acl 
Date: Mon, 15 Nov 2004 08:17:46 -0800
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:
>Philip Guenther wrote:
>>Please review the 2086upd draft as soon as possible, as it should be
>>going to working group last call Real Soon Now.  Only one substantive
>>change was discussed at the IETF meeting last week: instead of returning
>>a MYRIGHTS response, the SELECT command should return a MYRIGHTS
>>response _code_.  So, for example, this line from the SELECT example in
>>section 7.1.1:
>>               S: * MYRIGHTS INBOX rwis
>>will end up instead reading:
>>               S: * OK [MYRIGHTS INBOX rwis] Blah blah your rights
>
>The ACL2 document defines MYRIGHTS response code, but it doesn't include 
>a mailbox name. Is it Ok?

So it should instead read:
                 S: * OK [MYRIGHTS rwis] No more, no less

The Formal Syntax needs to define the syntax for that as an extension of
resp-text-code:

resp-text-code  =/ myrights_rspcod

myrights_rspcod = "MYRIGHTS" SP rights

rights          = atom
                   ;; MUST NOT contain leading "+" or "-"
                   ;; MUST be treated as case-sensitive

Hmm, interesting: ACL2 used 'quoted' instead of 'atom' for rights.
Since a non-ATOM-CHAR right can't appear in the RIGHT=... capability, no
point in allowing them here in the MYRIGHTS response code.

The UTF-8 reference should be updated the RFC 3629.  It should be noted
somewhere that an identifier containing non-US-ASCII characters MUST be
represented as a literal and not a quoted-string or atom.

Philip Guenther

To: Brian Candler <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
From: Philip Guenther <[email-masked]>
Subject: Re: Clarification of "d" right in imapext-acl 
Date: Mon, 15 Nov 2004 07:36:28 -0800
Sender: [email-masked]

Brian Candler <[email-masked]> writes:
...
>I don't think it need be so complicated; how about just
>
>  If a client includes the "d" right in a rights list, then it is to be
>  treated as if the client had included the "x", "e" and "t" rights.
>
>(You could add: It is not an error for a client to specify both "d" and one
>or more of "x", "e" and "t", but the effect no different than if just "d" or
>all of "x", "e" and "t" had been specified)

I like this wording, including the parenthetical addition.

...
>I don't like the wording "clears the "d" right from a rights list", because
>IIUC you can't ask for individual flags to be set or cleared; you can only
>ask for the entire set of flags to be replaced with a new set.
...

If the third argument to SETACL starts with a "+" or "-" then it is a
modification to the existing rights for that identifier and not a
complete replacement.  I think your wording above covers that
sufficiently by virtue of not referring to the operation at all.
Less is more...

Philip Guenther

Date: Mon, 15 Nov 2004 14:39:19 +0000
From: Brian Candler <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Philip Guenther <[email-masked]>, [email-masked]
Subject: Re: Clarification of "d" right in imapext-acl
Sender: [email-masked]

On Mon, Nov 15, 2004 at 01:57:53PM +0000, Alexey Melnikov wrote:
> I think the following text in the appendix B could have caused the 
> confusion:
> 
>   This document replaces the "d" right with 3 new different rights "x", 
> "t" and "e".
> 
> Any suggestion how to improve this?

I don't think that's necessarily the source of confusion, but it could be
elaborated:

  This document splits the "d" right into 3 new different rights "x", "t"
and "e". The "d" right remains for backwards-compatibility but it is a
virtual right. If a client requests the "d" right, it is treated as if it
requested all of "x", "t" and "e". The server returns the "d" right if and
only if all of "x", "t" and "e" are set.

> I've changed this to:
>   If a client request clears the "d" right from a rights lists, then 
> the server MUST also clear
>   any of the "x", "e", and "t" rights, unless one or more of them is 
> also specified in the same rights list.
> 
> Is this any better?
> 
> Or maybe even:
>   If a client request clears the "d" right from a rights lists, then 
> the server MUST first clear
>   all of the "x", "e", and "t" rights. If all of the "x", "e", and "t" 
> rights are specified in the same rights list, they are then set as usual.
> ?

I don't think it need be so complicated; how about just

  If a client includes the "d" right in a rights list, then it is to be
  treated as if the client had included the "x", "e" and "t" rights.

(You could add: It is not an error for a client to specify both "d" and one
or more of "x", "e" and "t", but the effect no different than if just "d" or
all of "x", "e" and "t" had been specified)

I don't like the wording "clears the "d" right from a rights list", because
IIUC you can't ask for individual flags to be set or cleared; you can only
ask for the entire set of flags to be replaced with a new set. So the only
issue is, if the replacement set contains "d", how is it to be handled? And
I think the answer is, just as if "x", "e" and "t" had been specified.

Regards,

Brian.

Date: Mon, 15 Nov 2004 13:57:53 +0000
From: Alexey Melnikov <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: Brian Candler <[email-masked]>, [email-masked]
Subject: Re: Clarification of "d" right in imapext-acl
Sender: [email-masked]

Philip Guenther wrote:

>>The one implementation I have access to is courier-imap, and that behaves as
>>follows:
>>
>>- If e,t or x (but not all three) are set, return those flags for LIST (ACL)
>> and none for GETACL
>>- If all three are set, return only "d" for both LIST (ACL) and GETACL
>>    
>>
>
>The description of the 'd' right in the ACL2 and RIGHTS drafts are the
>same:
>   d - This right is defined for backward compatibility with ACL
>       extension (RFC 2086). If a client sets "d" right, the server MUST
>       set "x", "e" and "t" rights. When the client clears the "d" right,
>       the server MUST clear "x", "e" and "t" rights. When all three of "x",
>       "e" and "t" are set, the server MUST return "d" right in response to
>       a LIST (ACL) command. If "x", "e" and "t" rights are not tied together,
>       "d" right MUST NOT be returned in a <RIGHTS-INFO/LISTRIGHTS> response.
>
>Since it doesn't say "...MUST _instead_ return "d" right..." and doesn't
>say that clients should treat the 'd' right as implying the "etx"
>rights, I don't see how the text gives the server the license to leave
>out the "etx" rights when returning the 'd' right in LIST (ACL).
>
I think the following text in the appendix B could have caused the 
confusion:

   This document replaces the "d" right with 3 new different rights "x", 
"t" and "e".

Any suggestion how to improve this?

>  The
>*server* must make the d->etx implication when changing rights, but the
>client isn't required to make it when reading them.
>
>
>Perhaps most of the the description of the 'd' right should be moved
>out of the list into its own paragraph?  The list of rights would just
>say:
>   d - This right is defined for backward compatibility with ACL
>       extension (RFC 2086).  See below for details on how servers
>       should interpret it in commands that alter ACLs and when it
>       should be included in responses that return ACLs or lists of
>       rights.
>
>Then later:
>   If a client request sets the "d" right in a rights list, the server
>   MUST set the "x", "e", and "t" rights.  If a client request clears
>   the "d" right from a rights lists, then the server MUST also clear
>   any of the "x", "e", and "t" rights that are not simultaneously being
>   set.
>
I've changed this to:
   If a client request clears the "d" right from a rights lists, then 
the server MUST also clear
   any of the "x", "e", and "t" rights, unless one or more of them is 
also specified in the same rights list.

Is this any better?

Or maybe even:
   If a client request clears the "d" right from a rights lists, then 
the server MUST first clear
   all of the "x", "e", and "t" rights. If all of the "x", "e", and "t" 
rights are specified in the same rights list, they are then set as usual.
?

>  When all three of the "x", "e", and "t" rights are set in a
>   list of rights, the server MUST also include the "d" right when
>   returning that list in a MYRIGHTS or ACL response.  If the "x", "e",
>   and "t" rights are not tied together, the "d" right MUST NOT be
>   returned in a LISTRIGHTS response.
>
>(The phrasing about "simultaneously being set" is to make it clear that
>even though the request
>	tag SETACL "foo" "guenther" "lrswt"
>doesn't include (and may be clearing) the "d" right, the "t" right
>should still be set.)
>
>
>  
>

Date: Mon, 15 Nov 2004 12:45:30 +0000
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: Outstanding issues for draft-ietf-imapext-2086upd-00 (ACL)
Sender: [email-masked]

Alexey Melnikov wrote:

> Actually, I believe there are only two. One relates to whether the "m"
> right only controls writability of private annotations, or whether it
> also controls readability. I've sent a separate message on this.

I believe that this issue is closed now.

> The second issue:
>
> Which rights are required for the LISTRIGHTS command?
>
> Currently the document says:
>
>    MYRIGHTS - any of the following rights is required to perform
>     the operation: "l", "r", "i", "c", "x", "a".*
>
>    LISTRIGHTS - same as MYRIGHTS.
>
> Some of the existing servers follow this suggestion. Some allow for
> LISTRIGHTS if "r" and/or "a" is granted.
>
> Philip has suggested (and I agree) to only allow LISTRIGHTS when the "a"
> right is granted, as LISTRIGHTS information is only useful
> if you can also do SETACL. Also, such information shouldn't be disclosed
> to users that have insufficient rights.

So, any comments on changing LISTRIGHTS to require the "a" right?

> Alexey
>
> * - Note, that the STORE related rights ("w", "s", "t", "m" and "n") are
> not part of this list, because the client must be able to open a mailbox
> (i.e. "r") before performing a STORE command. The list also used to
> contain the "e" right (which controls EXPUNGE), I've deleted it for the
> same reason.

Date: Mon, 15 Nov 2004 12:32:43 +0000
From: Alexey Melnikov <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: Brian Candler <[email-masked]>, [email-masked]
Subject: Re: Clarification of "d" right in imapext-acl
Sender: [email-masked]

Philip Guenther wrote:

>Please review the 2086upd draft as soon as possible, as it should be
>going to working group last call Real Soon Now.  Only one substantive
>change was discussed at the IETF meeting last week: instead of returning
>a MYRIGHTS response, the SELECT command should return a MYRIGHTS
>response _code_.  So, for example, this line from the SELECT example in
>section 7.1.1:
>               S: * MYRIGHTS INBOX rwis
>will end up instead reading:
>               S: * OK [MYRIGHTS INBOX rwis] Blah blah your rights
>(Can't return a new response unless the client indicated it expected it
>by using some new syntax.  That's why the UNSEEN, UIDVALIDITY, UIDNEXT,
>and PERMANENTFLAGS values are returned as response codes instead of
>responses.)
>  
>
The ACL2 document defines MYRIGHTS response code, but it doesn't include 
a mailbox name. Is it Ok?

Date: Mon, 15 Nov 2004 12:16:42 +0000
From: Alexey Melnikov <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: Brian Candler <[email-masked]>, [email-masked]
Subject: Re: Clarification of "d" right in imapext-acl
Sender: [email-masked]

Brian Candler wrote:

>On Sun, Nov 14, 2004 at 03:04:19PM -0800, Philip Guenther wrote:
>  
>
>>Perhaps most of the the description of the 'd' right should be moved
>>out of the list into its own paragraph?  The list of rights would just
>>say:
>>   d - This right is defined for backward compatibility with ACL
>>       extension (RFC 2086).  See below for details on how servers
>>       should interpret it in commands that alter ACLs and when it
>>       should be included in responses that return ACLs or lists of
>>       rights.
>>
>>Then later:
>>   If a client request sets the "d" right in a rights list, the server
>>   MUST set the "x", "e", and "t" rights.  If a client request clears
>>   the "d" right from a rights lists, then the server MUST also clear
>>   any of the "x", "e", and "t" rights that are not simultaneously being
>>   set.  When all three of the "x", "e", and "t" rights are set in a
>>   list of rights, the server MUST also include the "d" right when
>>   returning that list in a MYRIGHTS or ACL response.  If the "x", "e",
>>   and "t" rights are not tied together, the "d" right MUST NOT be
>>   returned in a LISTRIGHTS response.
>>
>>(The phrasing about "simultaneously being set" is to make it clear that
>>even though the request
>>	tag SETACL "foo" "guenther" "lrswt"
>>doesn't include (and may be clearing) the "d" right, the "t" right
>>should still be set.)
>>    
>>
>
>Yes, that looks better.
>  
>
I think I want to rephrase the "simultaneously being set" part, but the 
idea looks good.

>>A few more nits on the 2086upd draft: the reference to LISTEXT in the
>>Formal Syntax should be removed.  In Appendix B, replace "a LIST
>>response" with "MYRIGHTS and ACL responses" and replace "ACL2" with
>>"RIGHTS".
>>    
>>
>
>I spotted those too :-)
>  
>
Fixed now. Thanks for spotting this.

Date: Mon, 15 Nov 2004 08:33:36 +0000
From: Brian Candler <[email-masked]>
To: Philip Guenther <[email-masked]>
Cc: [email-masked], Alexey Melnikov <[email-masked]>
Subject: Re: Clarification of "d" right in imapext-acl
Sender: [email-masked]

On Sun, Nov 14, 2004 at 03:04:19PM -0800, Philip Guenther wrote:
> Perhaps most of the the description of the 'd' right should be moved
> out of the list into its own paragraph?  The list of rights would just
> say:
>    d - This right is defined for backward compatibility with ACL
>        extension (RFC 2086).  See below for details on how servers
>        should interpret it in commands that alter ACLs and when it
>        should be included in responses that return ACLs or lists of
>        rights.
> 
> Then later:
>    If a client request sets the "d" right in a rights list, the server
>    MUST set the "x", "e", and "t" rights.  If a client request clears
>    the "d" right from a rights lists, then the server MUST also clear
>    any of the "x", "e", and "t" rights that are not simultaneously being
>    set.  When all three of the "x", "e", and "t" rights are set in a
>    list of rights, the server MUST also include the "d" right when
>    returning that list in a MYRIGHTS or ACL response.  If the "x", "e",
>    and "t" rights are not tied together, the "d" right MUST NOT be
>    returned in a LISTRIGHTS response.
> 
> (The phrasing about "simultaneously being set" is to make it clear that
> even though the request
> 	tag SETACL "foo" "guenther" "lrswt"
> doesn't include (and may be clearing) the "d" right, the "t" right
> should still be set.)

Yes, that looks better.

> A few more nits on the 2086upd draft: the reference to LISTEXT in the
> Formal Syntax should be removed.  In Appendix B, replace "a LIST
> response" with "MYRIGHTS and ACL responses" and replace "ACL2" with
> "RIGHTS".

I spotted those too :-)

Regards,

Brian.

To: Brian Candler <[email-masked]>
Cc: [email-masked], Alexey Melnikov <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: Clarification of "d" right in imapext-acl 
Date: Sun, 14 Nov 2004 15:04:19 -0800
Sender: [email-masked]

Brian Candler <[email-masked]> writes:
>According to draft-ietf-imapext-acl-10.txt section 3.1:
...
>RFC 2086 allows standards-track documents to define additional rights; if
>the intention is that LIST (ACL) and GETACL are permitted to return exactly
>the same set of flags under all circumstances, or not, then I think this
>should be made explicit.

At the San Diego meeting, the working group decided to put ACL2 on hold
for a moment in favor of turning out a quick revision of RFC 2086 that
added some additional rights (etxmn) and clarified exactly which rights
were required for which commands.  Alexey sent the current version of
that doc, draft-ietf-imapext-2086upd-01.txt, to the list on Nov 7:
	http://www.imc.org/ietf-imapext/mail-archive/msg02242.html

That revision isn't in the I-D repository yet.

Now, this affects your question/query in that the "etx" rights are being
added without changing the commands, so they will definitely be returned
by the GETACL command in an implementation supporting the RIGHTS
extension defined in the above draft.

As for returning the 'd' right from LIST (ACL), the draft currently is
specific about requiring it.  Permitting the server to leave it out when
GETACL is required to return it would make the text more complicated
for, IMO, no real gain.

(Once LISTEXT and RIGHTS are published, the ACL2 draft will shrink a
*lot*)

Please review the 2086upd draft as soon as possible, as it should be
going to working group last call Real Soon Now.  Only one substantive
change was discussed at the IETF meeting last week: instead of returning
a MYRIGHTS response, the SELECT command should return a MYRIGHTS
response _code_.  So, for example, this line from the SELECT example in
section 7.1.1:
               S: * MYRIGHTS INBOX rwis
will end up instead reading:
               S: * OK [MYRIGHTS INBOX rwis] Blah blah your rights
(Can't return a new response unless the client indicated it expected it
by using some new syntax.  That's why the UNSEEN, UIDVALIDITY, UIDNEXT,
and PERMANENTFLAGS values are returned as response codes instead of
responses.)

>The one implementation I have access to is courier-imap, and that behaves as
>follows:
>
>- If e,t or x (but not all three) are set, return those flags for LIST (ACL)
>  and none for GETACL
>- If all three are set, return only "d" for both LIST (ACL) and GETACL

The description of the 'd' right in the ACL2 and RIGHTS drafts are the
same:
   d - This right is defined for backward compatibility with ACL
       extension (RFC 2086). If a client sets "d" right, the server MUST
       set "x", "e" and "t" rights. When the client clears the "d" right,
       the server MUST clear "x", "e" and "t" rights. When all three of "x",
       "e" and "t" are set, the server MUST return "d" right in response to
       a LIST (ACL) command. If "x", "e" and "t" rights are not tied together,
       "d" right MUST NOT be returned in a <RIGHTS-INFO/LISTRIGHTS> response.

Since it doesn't say "...MUST _instead_ return "d" right..." and doesn't
say that clients should treat the 'd' right as implying the "etx"
rights, I don't see how the text gives the server the license to leave
out the "etx" rights when returning the 'd' right in LIST (ACL).  The
*server* must make the d->etx implication when changing rights, but the
client isn't required to make it when reading them.

Perhaps most of the the description of the 'd' right should be moved
out of the list into its own paragraph?  The list of rights would just
say:
   d - This right is defined for backward compatibility with ACL
       extension (RFC 2086).  See below for details on how servers
       should interpret it in commands that alter ACLs and when it
       should be included in responses that return ACLs or lists of
       rights.

Then later:
   If a client request sets the "d" right in a rights list, the server
   MUST set the "x", "e", and "t" rights.  If a client request clears
   the "d" right from a rights lists, then the server MUST also clear
   any of the "x", "e", and "t" rights that are not simultaneously being
   set.  When all three of the "x", "e", and "t" rights are set in a
   list of rights, the server MUST also include the "d" right when
   returning that list in a MYRIGHTS or ACL response.  If the "x", "e",
   and "t" rights are not tied together, the "d" right MUST NOT be
   returned in a LISTRIGHTS response.

(The phrasing about "simultaneously being set" is to make it clear that
even though the request
	tag SETACL "foo" "guenther" "lrswt"
doesn't include (and may be clearing) the "d" right, the "t" right
should still be set.)

A few more nits on the 2086upd draft: the reference to LISTEXT in the
Formal Syntax should be removed.  In Appendix B, replace "a LIST
response" with "MYRIGHTS and ACL responses" and replace "ACL2" with
"RIGHTS".  There are also a few remaining places where <"foo" right>
should be changed to <the "foo" right> (e.g., in the last paragraph of
section 6).

>Whether or not that's the intention of the draft, IMO the wording could be
>made clearer.

Would the above text do so?

Philip Guenther

Date: Sat, 13 Nov 2004 11:52:06 +0000
From: Brian Candler <[email-masked]>
To: [email-masked]
Subject: Clarification of "d" right in imapext-acl
Sender: [email-masked]

According to draft-ietf-imapext-acl-10.txt section 3.1:

   d - This right is defined for backward compatibility with ACL
       extension (RFC 2086). If a client sets "d" right, the server MUST
       set "x", "e" and "t" rights. When the client clears the "d" right,
       the server MUST clear "x", "e" and "t" rights. When all three of "x",
       "e" and "t" are set, the server MUST return "d" right in response to
       a LIST (ACL) command.

and later in section 9.1:

    b). Implement separate "x", "t" and "e". Return "d" right in a LIST 
        response containing ACL information when all three of "x", "t"
        and "e" are granted.

However I don't think it's clear whether this means that the LIST (ACL)
command should return the d flag *in addition* to etx, or *instead of* etx.

Also, it's not clear to me whether the old GETACL command is permitted to
return the e, t or x flags separately if they exist, or hide them. But if it
has to hide them, i.e. GETACL is supposed to be implemented differently to
LIST (ACL) for the benefit of RFC 2086 clients, then is there any need for
LIST (ACL) to return a "d" flag at all? LIST (ACL) is an ACL2 command, so
any ACL2 client should understand 'e','t' and 'x' separately anyway.

RFC 2086 allows standards-track documents to define additional rights; if
the intention is that LIST (ACL) and GETACL are permitted to return exactly
the same set of flags under all circumstances, or not, then I think this
should be made explicit.

The one implementation I have access to is courier-imap, and that behaves as
follows:

- If e,t or x (but not all three) are set, return those flags for LIST (ACL)
  and none for GETACL
- If all three are set, return only "d" for both LIST (ACL) and GETACL

Whether or not that's the intention of the draft, IMO the wording could be
made clearer.

Regards,

Brian Candler.

* OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE ACL ACL2=UNION STARTTLS] Courier-IMAP ready. Copyright 1998-2004 Double Precision, Inc.  See COPYING for distribution information.
a login [email-masked] XXXXXXXX
a OK LOGIN Ok.
a acl store "INBOX.mytest" "user=[email-masked]" "et"
* LIST (\HasNoChildren) "." "INBOX.mytest" (("ACL" (("owner" "acdilrsw")("user=[email-masked]" "et"))))
a OK ACL STORE completed.
a list (acl) "" "INBOX.mytest"
* LIST (\HasNoChildren) "." "INBOX.mytest" (("ACL" (("owner" "acdilrsw")("user=[email-masked]" "et"))))
a OK LIST completed
a getacl "INBOX.mytest"
* ACL "INBOX.mytest" "owner" "acdilrsw" "[email-masked]" ""
a OK GETACL completed.
a acl store "INBOX.mytest" "user=[email-masked]" "etx"
* LIST (\HasNoChildren) "." "INBOX.mytest" (("ACL" (("owner" "acdilrsw")("user=[email-masked]" "d"))))
a OK ACL STORE completed.
a list (acl) "" "INBOX.mytest"
* LIST (\HasNoChildren) "." "INBOX.mytest" (("ACL" (("owner" "acdilrsw")("user=[email-masked]" "d"))))
a OK LIST completed
a getacl "INBOX.mytest"
* ACL "INBOX.mytest" "owner" "acdilrsw" "[email-masked]" "d"
a OK GETACL completed.
a logout
* BYE Courier-IMAP server shutting down
a OK LOGOUT completed

Date: Fri, 12 Nov 2004 14:30:20 -0500
From: Cyrus Daboo <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: Notes for IMAPEXT WG meeting at IETF61
Sender: [email-masked]

Hi Arnt,

--On Friday, November 12, 2004 17:53:02 EST +0100 Arnt Gulbrandsen 
<[email-masked]> wrote:

>> Multiple-mailbox-match in LISTEXT: looks like there's consensus to add
>> it.  We will take this to the list to see if there's any objectors on
>> the list.
>
> There's me, sort of. But if it's okay to send two responses when a
> mailbox matches two patterns, I'll be quiet. (I don't remember right now.
> There was some discussion, wasn't there?)

Clients have to potential cope with that situation today with regular LIST 
so having the server do it with LISTEXT, whilst not ideal, should not cause 
problems. I think we ought to say 'servers SHOULD suppress duplicate 
mailboxes in the response' and leave it at that.

-- 
Cyrus Daboo

Date: Fri, 12 Nov 2004 17:53:02 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Notes for IMAPEXT WG meeting at IETF61
Sender: [email-masked]

Lisa Dusseault writes:
> Multiple-mailbox-match in LISTEXT: looks like there's consensus to add 
> it.  We will take this to the list to see if there's any objectors on 
> the list.

There's me, sort of. But if it's okay to send two responses when a 
mailbox matches two patterns, I'll be quiet. (I don't remember right 
now. There was some discussion, wasn't there?)

Arnt

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Notes location
Date: Fri, 12 Nov 2004 08:14:46 -0800
Sender: [email-masked]

I forwarded the notes to the WG and also uploaded them to 
http://ietf.webdav.org/imapext/.  I also added a link there to the 
Jabber room logs.  There were no presentations at this meeting.

Lisa

To: [email-masked], IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Notes for IMAPEXT WG meeting at IETF61
Date: Fri, 12 Nov 2004 07:49:55 -0800
Sender: [email-masked]

LISTEXT STATUS

Discussion of /Placeholder: Philip promised to send a mail about a 
simplification of /Placeholder.  Cyrus and Barry agree that LISTEXT is 
too complicated and we need to back off that.

Question about which client people initially asked for features in 
LISTEXT (prompted by observation that LISTEXT has now become rather 
complex)? Cyrus, David Cridland, Mark Crispin.. who else?

Suggestion that the /matchparent stuff may be simplifiable -- get rid 
of it.  Any wildcard query (%) could be seen as a request for 
matchparent -- otherwise the server must not return it.

Multiple-mailbox-match in LISTEXT: looks like there's consensus to add 
it.  We will take this to the list to see if there's any objectors on 
the list.

We will defer to the mailing list for what to do with /NOSELECT, 
/NONEXISTENT, /DELETED...

Cyrus and Philip are on the hook to suggest a simplified model to 
Alexey and Barry for matchparent... the next version of this may get 
last-called.

---
ACL STATUS

Discussion on 2086 upd:  Looks good, needs to be kept simple and 
finished soon.  Scott and Chris promise to review 2086upd

---
ANNOTATE STATUS

Discussion on Annotate: lots of discussion over what rights to use for 
private and public annotations.

Proposal: that the ability to read private annotations is controlled by 
the 'r' ACL bit, and the ability to write private annotations is 
controlled by the new 'm' ACL bit.  This means that 'r' controls 
readability for both private and shared annotations.  There were no 
sticking objections to this proposal (however Barry and Chris would 
prefer another proposal.)

2nd issue with ANNOTATE: Interactions with the CATENATE draft.  
Resolution: Cyrus will add text to deal with this and there will be a 
new dependency of Annotate on Catenate

3rd issue: APPEND: a slight interaction here with annotate, which Cyrus 
will add to the draft.

We plan to last call the  next version of Annotate on the day it comes 
out.

---
ANNOTATEMORE

Plug for AnnotateMore -- Chris and Philip promised to review, Cyrus 
will ask LEMONADE list for review.

content-class: urn:content-classes:message
Subject: RE: Comments on ANNOTATEMORE
Date: Thu, 11 Nov 2004 06:20:24 -0600
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: ext Cyrus Daboo [mailto:[email-masked]]
> Sent: Thursday, November 11, 2004 1:01 AM
...
> > The ANNOTATE draft does allow for attribute value pairs to be sent
> > in unsolicited responses with the SELECT parameter "(ANNOTATE)".
> > There does not seem to be an analog in ANNOTATEMORE.
> 
> No, that's not the case. Section 3.2 of ANNOTATE states that 

Which statement are you refuting the first or the second? Both
maybe?

> the (ANNOTATE) 
> parameter on SELECT turns on unsolicited annotation responses 
> as defined by 
> Section 3.4. Section 3.4 states that unsolicited responses 
> MUST NOT include 
> the annotation data. i.e. the ANNOTATION responses resulting from 
> (ANNOTATE) on SELECT do not include the annotation values.

I'm confused. Here is an excerpt from draft-ietf-imapext-annotate-11.txt
sec 3.4.

   Servers MUST NOT include ANNOTATION data in unsolicited responses
   unless the client used the ANNOTATE select parameter when it issued
   the last SELECT or EXAMINE command.  This restriction avoids sending
   ANNOTATION data to a client unless the client explicitly asks for it.

   Servers SHOULD send ANNOTATION message data items in unsolicited
   FETCH responses if an annotation entry is changed by a third-party,
   and the ANNOTATE select parameter was used.  This allows servers to
   keep clients updated with changes to annotations by other clients.

This seems clear to me. I must be missing something about your point.

Mike

Date: Thu, 11 Nov 2004 01:00:46 -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: Comments on ANNOTATEMORE
Sender: [email-masked]

Hi Michael,

--On Wednesday, November 10, 2004 14:49:06 EST -0600 
[email-masked] wrote:

>> This behaves the same way as unsolicited ANNOTATE responses
>> in the ANNOTATE
>> extension. The reason for this behaviour is that clients may
>
> The ANNOTATE draft does allow for attribute value pairs to be sent
> in unsolicited responses with the SELECT parameter "(ANNOTATE)".
> There does not seem to be an analog in ANNOTATEMORE.

No, that's not the case. Section 3.2 of ANNOTATE states that the (ANNOTATE) 
parameter on SELECT turns on unsolicited annotation responses as defined by 
Section 3.4. Section 3.4 states that unsolicited responses MUST NOT include 
the annotation data. i.e. the ANNOTATION responses resulting from 
(ANNOTATE) on SELECT do not include the annotation values.

Perhaps this needs to be made more explicit?

-- 
Cyrus Daboo

content-class: urn:content-classes:message
Subject: RE: Comments on ANNOTATEMORE 
Date: Wed, 10 Nov 2004 21:03:12 -0600
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: ext Philip Guenther [mailto:[email-masked]]
> Sent: Wednesday, November 10, 2004 5:35 PM
...
> >> /checkperiod is meant to be the user preference for polling 
> >> interval. i.e. 
> >> the client will use that value to determine what interval it 
> >> should poll 
> >> the mailbox (using STATUS or NOOP). It is not under control 
> >> of the server 
> >> and is not used by the server. I can add text to clarify that.
> >
> >As described I don't see it having much value. I see it having 
> >much more value as a server set value. So I would suggest you 
> >don't add the clarification and leave it as either client or 
> >server set.
> 
> What would a server-set version of checkperiod tell the client?  I'm
> trying to envision an interpretation that wouldn't imply that 
> the server
> can see into the future.

A server can see into the future. It is called extrapolation.

> >I'm talking about 3rd party changes as described in ANNOTATE sec 3.4
> >last two paragraphs. These would not be redundant. I could see them
> >as being uninteresting to some clients, but for the same reason you 
> >allow unsolicited responses with data in ANNOTATE sec 3.4 they may be
> >interesting to some clients. To those clients it would be nice to
> >have the data contained in the response.
> 
> Given the possible size of annotations (as compared to the 
> size of flags
> updates), defaulting to not sending values seems wise to me.

I agree. I understand that point. 

You do agree the ANNOTATE draft does have a way to allow data to be 
included in unsolicited responses? Why would it not be wise to allow 
such a capability to be turned on for non-message annotations? Note, 
I'm not talking about the default.

Maybe the answer is there is no clean way to do it. Message 
annotations have the SELECT (ANNOTATE) switch. Where you would
hang such a switch with non-message annotations I'm not sure.

Mike

To: [email-masked]
Cc: [email-masked]
Subject: Re: Comments on ANNOTATEMORE 
Date: Wed, 10 Nov 2004 14:34:49 -0800
From: Philip Guenther <[email-masked]>
Sender: [email-masked]

[email-masked] writes:
>Cyrus Daboo <[email-masked]> writes:
...
>> /checkperiod is meant to be the user preference for polling 
>> interval. i.e. 
>> the client will use that value to determine what interval it 
>> should poll 
>> the mailbox (using STATUS or NOOP). It is not under control 
>> of the server 
>> and is not used by the server. I can add text to clarify that.
>
>As described I don't see it having much value. I see it having 
>much more value as a server set value. So I would suggest you 
>don't add the clarification and leave it as either client or 
>server set.

What would a server-set version of checkperiod tell the client?  I'm
trying to envision an interpretation that wouldn't imply that the server
can see into the future.

Note that ANNOTATEMORE arose in part from the difficulties in
implementing ACAP and several of the initial entries are there to
take over for ACAP profiles of client configuration.

...
>I'm talking about 3rd party changes as described in ANNOTATE sec 3.4
>last two paragraphs. These would not be redundant. I could see them
>as being uninteresting to some clients, but for the same reason you 
>allow unsolicited responses with data in ANNOTATE sec 3.4 they may be
>interesting to some clients. To those clients it would be nice to
>have the data contained in the response.

Given the possible size of annotations (as compared to the size of flags
updates), defaulting to not sending values seems wise to me.

Philip Guenther

content-class: urn:content-classes:message
Subject: RE: Comments on ANNOTATEMORE
Date: Wed, 10 Nov 2004 14:49:06 -0600
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: ext Cyrus Daboo [mailto:[email-masked]]
> Sent: Wednesday, November 10, 2004 10:58 AM
> > Section 2.2.1.2
> >
> > I don't understand the usefulness of /check and /checkperiod.
> > Who sets checkperiod? Mail arrival is variable so the only
...
> /checkperiod is meant to be the user preference for polling 
> interval. i.e. 
> the client will use that value to determine what interval it 
> should poll 
> the mailbox (using STATUS or NOOP). It is not under control 
> of the server 
> and is not used by the server. I can add text to clarify that.

As described I don't see it having much value. I see it having 
much more value as a server set value. So I would suggest you 
don't add the clarification and leave it as either client or 
server set.

> 
> It is sometimes useful to be able to 'suspend' checking of a 
> mailbox, hence 
...

Agreed.

> > Section 3.3
...
> i.e. there is no need for the server to send back the 
> annotation data that 
> the client has just set using SETANNOTATION - that 
> information is redundant 
> as the OK response implies those changes have succeeded.

Agreed.

> 
> >
> > Section 3.4.2
> >
> > Why do unsolicited ANNOTATION responses not contain attributes
> > and values? Wouldn't they be more useful if they contained the
> > new data? Maybe they MAY as descibed in section 3.3?
> 
> This behaves the same way as unsolicited ANNOTATE responses 
> in the ANNOTATE 
> extension. The reason for this behaviour is that clients may 

The ANNOTATE draft does allow for attribute value pairs to be sent 
in unsolicited responses with the SELECT parameter "(ANNOTATE)". 
There does not seem to be an analog in ANNOTATEMORE.

> not care about 
> some annotations and therefore sending the data is redundant ande 
> potentially wastes bandwidth. It is more efficient to tell 
> the client that 
> some changes have happened and then have the client go and 
> fetch the data 
> for only the ones it is really interested in. i.e. we are 
> trying to prevent 
> the server forcing data on the client that it does not need.

I'm talking about 3rd party changes as described in ANNOTATE sec 3.4
last two paragraphs. These would not be redundant. I could see them
as being uninteresting to some clients, but for the same reason you 
allow unsolicited responses with data in ANNOTATE sec 3.4 they may be
interesting to some clients. To those clients it would be nice to
have the data contained in the response.

Mike

Date: Wed, 10 Nov 2004 10:57:39 -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Comments on ANNOTATEMORE
Sender: [email-masked]

Hi [email-masked],

--On Wednesday, November 10, 2004 9:17:31 EST -0600 [email-masked] 
wrote:

> Section 2.2.1.2
>
> I don't understand the usefulness of /check and /checkperiod.
> Who sets checkperiod? Mail arrival is variable so the only
> reasonable thing to do is to have it modified by the server
> using some learning algorithm that changed the value as the
> inter-mail arrival times changed.
>
> Or maybe you were thinking about some server imposed polling
> throttle?
>
> /check is redundant. The existence of /checkperiod implies
> /check=true.

/checkperiod is meant to be the user preference for polling interval. i.e. 
the client will use that value to determine what interval it should poll 
the mailbox (using STATUS or NOOP). It is not under control of the server 
and is not used by the server. I can add text to clarify that.

It is sometimes useful to be able to 'suspend' checking of a mailbox, hence 
having a separate 'turn check on/off' value that does not affect the period 
is useful. i.e. you don't have to remember what the last period when 
restoring checking after it has been suspended.

>
> Section 3.3
>
> The paragraph immediately following the "Result:" section
> describes behavior for unsolicited responses. I'm unclear if
> this is referring to the potential untagged responses returned
> due to the SETANNOTATION, or to unsolicited responses in general,
> for example, during a NOOP.

The first paragraph in section 3.3 is confusing. The policy is that 
unsolicited responses can be sent at any appropriate time (including during 
SETANNOTATION), however the server does not need to send ANNOTATION 
responses that are the direct result of the SETANNOTATION command itself - 
i.e. there is no need for the server to send back the annotation data that 
the client has just set using SETANNOTATION - that information is redundant 
as the OK response implies those changes have succeeded.

>
> Section 3.4.2
>
> Why do unsolicited ANNOTATION responses not contain attributes
> and values? Wouldn't they be more useful if they contained the
> new data? Maybe they MAY as descibed in section 3.3?

This behaves the same way as unsolicited ANNOTATE responses in the ANNOTATE 
extension. The reason for this behaviour is that clients may not care about 
some annotations and therefore sending the data is redundant ande 
potentially wastes bandwidth. It is more efficient to tell the client that 
some changes have happened and then have the client go and fetch the data 
for only the ones it is really interested in. i.e. we are trying to prevent 
the server forcing data on the client that it does not need.

-- 
Cyrus Daboo

content-class: urn:content-classes:message
Subject: Comments on ANNOTATEMORE
Date: Wed, 10 Nov 2004 09:17:31 -0600
From: <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Section 2.2.1.2

I don't understand the usefulness of /check and /checkperiod. 
Who sets checkperiod? Mail arrival is variable so the only 
reasonable thing to do is to have it modified by the server 
using some learning algorithm that changed the value as the
inter-mail arrival times changed.

Or maybe you were thinking about some server imposed polling 
throttle?

/check is redundant. The existence of /checkperiod implies 
/check=true.

Section 3.3 

The paragraph immediately following the "Result:" section 
describes behavior for unsolicited responses. I'm unclear if 
this is referring to the potential untagged responses returned
due to the SETANNOTATION, or to unsolicited responses in general, 
for example, during a NOOP.

Section 3.4.2

Why do unsolicited ANNOTATION responses not contain attributes 
and values? Wouldn't they be more useful if they contained the
new data? Maybe they MAY as descibed in section 3.3?

Mike

Date: Tue, 9 Nov 2004 08:56:56 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, Alexey Melnikov <[email-masked]>, kael <[email-masked]>, [email-masked]
Subject: Re: Question about the SORT and THREAD extensions
Sender: [email-masked]

On Tue, 9 Nov 2004, Dave Cridland wrote:
> I confess to being totally bewildered by the FROM, TO and CC sort keys, as 
> they all appear to only sort on the local-part of the email address - that 
> *is* the "bit before the @", right? So different domains collate equally? I 
> can't understand why this should be the case.

In practice, not all that many people use those keys.

The idea is to tend to collect messages from a single person together, 
based upon the tendency of people to have the same local-part for his 
email address even though they may use many different sites.  Note that 
word "tend".

It's useful, in some very limited cases.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

From: Dave Cridland <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, kael <[email-masked]>, <[email-masked]>
Subject: Re: Question about the SORT and THREAD extensions
Date: Tue, 09 Nov 2004 16:12:33 +0000
Sender: [email-masked]

On Tue Nov  9 12:25:17 2004, Arnt Gulbrandsen wrote:
> Dave Cridland writes:
>> For an actual SORT, no matter how quick the sort implementation on 
>> the server is, for large mailboxes that's still a noticeable chunk 
>> of bandwidth chewage for the result - the sort results for a 50k 
>> message folder weigh in at 282k[1].
> 
> "sort (subject date) charset us-ascii since 2004-11-08 not since 
> 2004-11-09" should have only a small response, even if the mailbox 
> is big.
> 
> 
You mentioned timezones being problematic, but I'll just clarify - 
the DATE and ARRIVAL sort keys sort by first normalizing the relevant 
date (RFC2822 header and INTERNALDATE respectively) into UTC. The 
date-orientated search keys (In this case SINCE) search by discarding 
the time and timezone, which can result in a different date.

But back to the point... Yes, you can chop up SORT results for a 
"group by" style feature using the SEARCH key, and this will, in 
general, reduce the number of numbers given in the SORT response. But 
realistically, only for date/time related metadata.

For a sort or group by sender, or subject, this wouldn't be possible:

SUBJECT search keys use a substring match of the full header value - 
using a US-ASCII charset does this without MIME decoding. SUBJECT 
sort key uses the base subject, not the real one, and always decodes. 
Hence it's impossible to, for instance, divide the messages up into 
chunks with subjects beginning "a", etc, because:
a) The "base subject", which you actually want, isn't being searched, 
so you need to SORT the full mailbox.
b) You can't do a prefix search anyway.

FROM is just as curious, sorting as it does only on the local-part of 
the From address, but substring searching throughout the entire 
header, optionally MIME decoding as above.

I confess to being totally bewildered by the FROM, TO and CC sort 
keys, as they all appear to only sort on the local-part of the email 
address - that *is* the "bit before the @", right? So different 
domains collate equally? I can't understand why this should be the 
case.

This would appear to mean that it's totally impossible to use SORT to 
generate the collation from which a group by sender listing could 
actually be generated. This seems intuitively wrong to me, but 
accurate according to the specification.

Dave.

Date: Tue, 9 Nov 2004 13:25:17 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Question about the SORT and THREAD extensions
Cc: Alexey Melnikov <[email-masked]>, Dave Cridland <[email-masked]>, [email-masked]
Sender: [email-masked]

Dave Cridland writes:
> For an actual SORT, no matter how quick the sort implementation on the 
> server is, for large mailboxes that's still a noticeable chunk of 
> bandwidth chewage for the result - the sort results for a 50k message 
> folder weigh in at 282k[1].

"sort (subject date) charset us-ascii since 2004-11-08 not since 
2004-11-09" should have only a small response, even if the mailbox is 
big.

(Kael: When you implement the "yesterday" group, remember to consider 
the timezone issues. I think that command doesn't quite match what you 
want.)

Arnt

From: Dave Cridland <[email-masked]>
To: kael <[email-masked]>
Cc: IMAP extensions Mailing List <[email-masked]>, Alexey Melnikov <[email-masked]>
Subject: Re: Question about the SORT and THREAD extensions
Date: Tue, 09 Nov 2004 10:40:18 +0000
Sender: [email-masked]

On Mon Nov  8 17:21:05 2004, kael wrote:
> 
> On 08.11.2004 17:55, Alexey Melnikov wrote:
> 
>> Yes (ARRIVAL or DATE sort criterion, depending on what you mean: 
>> delivery date or the Date header)...
> 
> I deduce that, except for keywords, the implementation of the IMAP 
> SORT and THREAD extensions for Mozilla/Thunderbird could be done in 
> consideration of the new _Message Grouping_ feature 
> http://kb.mozillazine.org/index.phtml?title=Thunderbird_:_FAQs_:_Message_Grouping, 
> couldn't it. That would be great !

Well, yes and no, really.

On the one hand, messages can be sorted by *all* the criteria listed 
in that webpage, on the (minor) assumption that labels could be 
implemented as annotations rather than keywords. (I'm assuming here 
that it's one label per message, which many possible labels, in which 
case keywords could become problematic - servers don't always support 
an infinite number of keywords, so annotations would be a better fit.)

On the other hand, every time a new message arrived, it would have to 
be sorted. Currently, that can either be done by re-sorting the 
entire folder server-side, or else sorting locally.

For an actual SORT, no matter how quick the sort implementation on 
the server is, for large mailboxes that's still a noticeable chunk of 
bandwidth chewage for the result - the sort results for a 50k message 
folder weigh in at 282k[1].

For client-side sorts, you can't actually give a straight figure for 
the transfer, but it's likely to tend towards something much smaller 
as time passes and data is cached - ultimately down to the size of 
the data used as a sort key for the new message, usually quite small.

So in actual practise, it's probably not worthwhile using the SORT 
except, possibly, for the first hit, depending on how much data is 
cached client-side to begin with.

Dave.

Footnote:
1) In Python: len('* SORT' + ''.join( [str(x) for x in 
range(1,50000)] ))/1024.0 - across a fairly typical 512kbit/s DSL 
line, that's about 4.5 seconds of *transfer* time alone. Of course, I 
might have mucked up the calculation.

Date: Mon, 08 Nov 2004 18:21:05 +0100
From: kael <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: IMAP extensions Mailing List <[email-masked]>
Subject: Re: Question about the SORT and THREAD extensions
Sender: [email-masked]

On 08.11.2004 17:55, Alexey Melnikov wrote:

> Yes (ARRIVAL or DATE sort criterion, depending on what you mean: 
> delivery date or the Date header)...

I deduce that, except for keywords, the implementation of the IMAP SORT 
and THREAD extensions for Mozilla/Thunderbird could be done in 
consideration of the new _Message Grouping_ feature 
http://kb.mozillazine.org/index.phtml?title=Thunderbird_:_FAQs_:_Message_Grouping, 
couldn't it. That would be great !

Thanks for your replies.

-- 
kael

Date: Mon, 08 Nov 2004 16:55:27 +0000
From: Alexey Melnikov <[email-masked]>
To: kael <[email-masked]>
CC: IMAP extensions Mailing List <[email-masked]>
Subject: Re: Question about the SORT and THREAD extensions
Sender: [email-masked]

kael wrote:

> On 08.11.2004 14:56, Alexey Melnikov wrote:
>
>> If you asking about grouping by message age, than the answer is
>> "yes". The SORT extension would be sufficient for this.
>
> Does the SORT extension allow to group messages by date,

Yes (ARRIVAL or DATE sort criterion, depending on what you mean: 
delivery date or the Date header)

> keywords,

No.

> senders, subject,

Yes and yes.

> etc like Thunderbird 0.9 does - please, look at the
> attachments ? I have never been able to sort messages like this with
> Mulberry.

From: Dave Cridland <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>, Alexey Melnikov <[email-masked]>, Philip Guenther <[email-masked]>
Subject: Re: Annotate
Date: Mon, 08 Nov 2004 15:58:42 +0000
Sender: [email-masked]

On Mon Nov  8 15:17:11 2004, Cyrus Daboo wrote:
> --On Monday, November 8, 2004 14:54:19 EST +0000 Alexey Melnikov 
> <[email-masked]> wrote:
>>>> I'd personally suggest that if the server supports read-write
>>>> annotations, it MUST support creation of arbitrary, 
>>>> non-operational
>>>> attributes.
>>> Is a server that only supports preconfigured namespaces an active 
>>> danger
>>> to interoperability?  If not, then I think "MUST" is 
>>> inappropriate.
>> Unfortunately, there is no way to distinguish a read-write ANNOTATE
>> server that supports reconfigured namespaces from a full read-write
>> server. So yes, this might be a problem. At least it makes writing 
>> client
>> more difficult.
> I think servers SHOULD allow clients to create and use arbitrary 
> annotation entries be they in the vendor namespace or elsewhere 
> (the later being e.g. new standard annotations that have been 
> defined since the server was deployed). However, as with everything 
> in IMAP, the client MUST be prepared to handle the server saying NO.
> 
> So I think what we say is: 'servers SHOULD allow creation and use 
> of arbitrary annotation entries in the vendor namespace or 
> elsewhere, but client MUST handle the case where a server prevents 
> that and responds with a NO response', or something to that effect.

I'll certainly agree, of course, that any STORE to annotation may 
result in a NO, and of course, a client has to handle this.

To my mind, not allowing arbitrary attributes ranks at near the same 
level as not having persistent UIDs for a mailbox. It's something a 
client has to cope with, but shouldn't ever have to experience in the 
field. I'll concede that even this makes a MUST too strong, but 
perhaps a SHOULD with a note?

Philip used the phrase "active danger to interoperability" - a server 
which does not support storage of arbitrary attributes against a 
message in a mailbox for which the client has the rights required 
isn't actively endangering interoperability because, of course, it's 
acting so close to a server which doesn't support ANNOTATE at all.

What it is doing is missing out on a golden opportunity to provide a 
method for new features - such as, maybe, a resent-to attribute - to 
be created by one client, used by another, and standardized quickly 
and rapidly based on real operational experience. That's hurting 
interoperability badly, in my opinion.

As well as that, it's losing the ability to transfer mailboxes from 
one IMAP server to another without losing potentially highly valuable 
metadata, especially in the case where multiple clients are used.

If persistent UIDs aren't available, then the message store is badly 
designed for use with IMAP. If arbitrary annotations aren't 
supported, then the message store is badly designed for use with 
ANNOTATE.

Dave.

Date: Mon, 08 Nov 2004 10:17:11 -0500
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Philip Guenther <[email-masked]>
cc: Dave Cridland <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Annotate
Sender: [email-masked]

Hi Alexey,

--On Monday, November 8, 2004 14:54:19 EST +0000 Alexey Melnikov 
<[email-masked]> wrote:

>>> I'd personally suggest that if the server supports read-write
>>> annotations, it MUST support creation of arbitrary, non-operational
>>> attributes.
>>>
>>>
>> Is a server that only supports preconfigured namespaces an active danger
>> to interoperability?  If not, then I think "MUST" is inappropriate.
>>
>>
> Unfortunately, there is no way to distinguish a read-write ANNOTATE
> server that supports reconfigured namespaces from a full read-write
> server. So yes, this might be a problem. At least it makes writing client
> more difficult.

I think servers SHOULD allow clients to create and use arbitrary annotation 
entries be they in the vendor namespace or elsewhere (the later being e.g. 
new standard annotations that have been defined since the server was 
deployed). However, as with everything in IMAP, the client MUST be prepared 
to handle the server saying NO.

So I think what we say is: 'servers SHOULD allow creation and use of 
arbitrary annotation entries in the vendor namespace or elsewhere, but 
client MUST handle the case where a server prevents that and responds with 
a NO response', or something to that effect.

-- 
Cyrus Daboo

Date: Mon, 08 Nov 2004 14:54:19 +0000
From: Alexey Melnikov <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: Dave Cridland <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Annotate
Sender: [email-masked]

Philip Guenther wrote:

>>I'd personally suggest that if the server supports read-write 
>>annotations, it MUST support creation of arbitrary, non-operational 
>>attributes.
>>    
>>
>Is a server that only supports preconfigured namespaces an active danger
>to interoperability?  If not, then I think "MUST" is inappropriate.
>  
>
Unfortunately, there is no way to distinguish a read-write ANNOTATE 
server that supports reconfigured namespaces from a full read-write 
server. So yes, this might be a problem. At least it makes writing 
client more difficult.

To: Dave Cridland <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Annotate 
Date: Mon, 08 Nov 2004 06:29:28 -0800
From: Philip Guenther <[email-masked]>
Sender: [email-masked]

Dave Cridland <[email-masked]> writes:
>On Sat Nov  6 12:55:43 2004, Alexey Melnikov wrote:
>> Timo Sirainen wrote:
...
>>> Servers MUST(?) support new namespaces created by clients.
>> 
>> I think this should be "SHOULD". We want to encourage ANNOTATE 
>> servers. Implementing a read-only ANNOTATE is much easier.
>> 
>> 
>Yes, but the need for clients to store vendor-private stuff in a 
>nice, neat, semi-interoperable manner really shouldn't be 
>underestimated. Dropping this to a SHOULD is perhaps too far.

As described in RFC 2119, "SHOULD" is a fairly strong statement, with
"MUST" being for the do-or-die stuff only.  A quick scan of the IMAP RFC
finds a goodly number of uses of "SHOULD" that a server or client would
be very unwise to blithely disregard.

>I'd personally suggest that if the server supports read-write 
>annotations, it MUST support creation of arbitrary, non-operational 
>attributes.

Is a server that only supports preconfigured namespaces an active danger
to interoperability?  If not, then I think "MUST" is inappropriate.

Philip Guenther

Date: Mon, 08 Nov 2004 13:56:04 +0000
From: Alexey Melnikov <[email-masked]>
To: kael <[email-masked]>
CC: [email-masked]
Subject: Re: Question about the SORT and THREAD extensions
Sender: [email-masked]

kael wrote:

> Hello,
>
> Can [could] the SORT and THREAD extensions handle messages like this 
> http://www.deftone.com/blogzilla/archives/new_thunderbird_feature_message_grouping.html 
> ?

If you asking about grouping by message age, than the answer is "yes". 
The SORT extension would be sufficient for this.

From: Dave Cridland <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, IMAP Extensions WG <[email-masked]>, Timo Sirainen <[email-masked]>
Subject: Re: Annotate
Date: Mon, 08 Nov 2004 10:25:08 +0000
Sender: [email-masked]

On Sat Nov  6 12:55:43 2004, Alexey Melnikov wrote:
> Timo Sirainen wrote:
>> On 1.11.2004, at 20:09, Cyrus Daboo wrote:
>>>> I thought clients weren't allowed to make up their own 
>>>> annotation entry
>>>> names? Or what does this mean?
>>> 
>>> 
>>> If a client wants to create a 'boolean' (on/off) type property 
>>> associated with a message it has two options: use an IMAP keyword 
>>> (either private or registered), or create a vendor (or new 
>>> standard) annotation entry. The former gives no control over 
>>> private/shared state, whereas the latter does. So if there is a 
>>> specific need for such a property that does need explicit 
>>> private/shared behavior then the client can use annotations in 
>>> lieu of IMAP keywords.
>> 
>> 
>> I thought vendor namespaces meant that servers could create them, 
>> not clients. Maybe put at the beginning of 2.2.1 something like:
>> 
>> Vendor namespaces can be created by either clients or servers.
> 
> Yes.
> 
>> Servers MUST(?) support new namespaces created by clients.
> 
> I think this should be "SHOULD". We want to encourage ANNOTATE 
> servers. Implementing a read-only ANNOTATE is much easier.
> 
> 
Yes, but the need for clients to store vendor-private stuff in a 
nice, neat, semi-interoperable manner really shouldn't be 
underestimated. Dropping this to a SHOULD is perhaps too far.

I'd personally suggest that if the server supports read-write 
annotations, it MUST support creation of arbitrary, non-operational 
attributes.

The alternative is to encourage clients to avoid them entirely, 
either via keywords, which, having no namespace, have the potential 
to clash, or via messages containing client-specific data within. 
Both are effectively a poor emulation of ANNOTATE.

I said "semi-interoperable" earlier, and this is such an awful term 
it probably needs some explanation. What I mean is that:

a) The various client-specific annotations don't actually interfere 
with each other. You're not faced with keywords that your client 
might intend using for something else, you're not faced with 
mailboxes containing "special" messages.
b) It's a lot easier to switch a client from using a client-specific 
usage of ANNOTATE into a standard usage of ANNOTATE, than to switch a 
client from using Something Weird to ANNOTATE.
c) Chances are that several clients will spontaneously interoperate 
by deliberately using each other's client-specific extensions. (They 
do this with their local configurations already, remember - this 
would be a lot easier.)

Dave.

Date: Sun, 07 Nov 2004 16:28:28 -0800
From: Lyndon Nerenberg <[email-masked]>
To: [email-masked], IMAP Extensions WG <[email-masked]>
Subject: Re: Comments about CLEARIDLE
Sender: [email-masked]

--On 2004-11-7 5:18 PM +0000 Alexey Melnikov 
<[email-masked]> wrote:

>
> One thing the needs discussing is whether the problem of receiving
> flag changes/new mail notifications for multiple mailboxes (over a
> single connection) is worth solving. I frankly don't know for sure.

It has been brought up enough times over the last five years that I am
convinced it is. I wrote a non-published draft a few years back that
proposed a solution to the multiple-mailbox newmail notification 
problem.
And since the issue has come up once again over the last few months I 
have
updated the draft and will submit it after the IETF.

--lyndon

Date: Sun, 07 Nov 2004 17:18:22 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: [email-masked], IMAP Extensions WG <[email-masked]>
Subject: Comments about CLEARIDLE
Sender: [email-masked]

[Also crossposting this to IMAPEXT.]

> Clearidle (See attached)
>   The IMAPRev4 specification supports unsolicited responses being sent
>   to a client at any time. The IDLE specification defines a way for a 
>   client to sit in an idle connection waiting to receive these   
> responses. This document clarifies and extends the set of responses   
> that a client may receive while in the idle state. The desire is to   
> allow a client to predict exactly what set of unsolicited responses   
> it can rely on receiving when listening on an idle connection.

One thing the needs discussing is whether the problem of receiving flag 
changes/new mail notifications for multiple mailboxes (over a single 
connection) is worth solving. I frankly don't know for sure.

I will try to emphasize some specific technical issues with this document.

 >2.1 LIST Response
 >
 >   Currently the LIST response occurs as the result of a LIST command.
 >   This document modifies the syntax of a LIST response and also defines
 >   it's occurrence as a legal unsolicited response that could be received
 >   on IDLE connections associated with a user.
 >
 >   Two new name attributes are defined:
 >
 >   \Deleted
 >       The mailbox has been deleted and no longer exists. After a LIST
 >       response with this attribute is seen the server will no longer
 >       show the named folder in any LIST commands. There MUST NOT be
 >       any other name attributes sent along with this attribute.

I suggest you review the LISTEXT extension (currently 
draft-ietf-imapext-list-extensions-10.txt).
\Deleted is the same as \NonExistent.

 >   \Renamed
 >       The mailbox has been renamed. A second LIST response MUST
 >       immediately follow indicating the new name.
[...]
 >     3) If a folder is renamed two LIST responses are sent. The first
 >     indicating the old name and a \Renamed attribute and a second
 >     response MUST immediately follow the first indicating the new name.

This might be less obvious for people not following IMAPEXT, but there 
was a proposal to have REFERRAL data returned in LIST responses. It 
serves exactly this purpose. See 
<http://www.imc.org/ietf-imapext/mail-archive/msg01921.html>, item # 5.
It also avoids the proposed hack (sorry, I can't find a better word) of 
tying two LIST responses together.

 >2.2 FETCH Response
 >
 >   Currently the FETCH response occurs as the result of a FETCH command
 >   or as an unsolicited response on an IDLE connection. This document
 >   clarifies exactly what form of response should be sent when the
 >   specified events occur on the server.
[...]
 >   New Message Arrival      
 >       An unsolicited FETCH response with envelope, body, flag and uid
 >       data MUST be sent on all IDLE connections.
 >
 >       Example:
 >          S: * 1 FETCH (UID 34 FLAGS (\Recent) ENVELOPE (...) BODY (...))

Actually no, BODY must not be in this list, as it is potentially very 
big. You surely wouldn't want to push a 10Mb message to you cell phone.
I also suggest to replace the ENVELOPE with the BODYSTRUCTURE.

 >3.1.1 Mailbox Identification Syntax
 >
 >   While in the Authenticated state there is no way to implicitly
 >   determine which mailbox the response applies to. While this is not a
 >   problem for some responses such as the LIST response it does pose a
 >   problem for responses that are mail message specific.
[...]
 >   Example:
 >      S: * 22 EXISTS (imap://mail/inbox)

Why can't we just you the STATUS response?

        S: * STATUS INBOX (MESSAGES 231 RECENT 7)

Alexey

Cc: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: Proposed agenda for IMAPEXT
Date: Sat, 6 Nov 2004 20:36:16 -0800
To: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

On Nov 6, 2004, at 10:30 AM, Alexey Melnikov wrote:

> Lisa Dusseault wrote:
> ...
>>
>> 1. Sorting, threading, and viewing (to be dealt with by one or more
>>   mechanisms)
>>  - 
>> <http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-17.txt>
>>     status: still blocked on comparator (as is i18n draft)
>
> Are you proposing that the WG discusses the i18 draft?

Not really -- just to explain the status, because I dont' think there's 
anything to discuss.  (Let me know if I'm wrong!)

lisa

Date: Sat, 06 Nov 2004 18:30:44 +0000
From: Alexey Melnikov <[email-masked]>
To: Lisa Dusseault <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Proposed agenda for IMAPEXT
Sender: [email-masked]

Lisa Dusseault wrote:

> I'm sorry this is so late, but here it is anyway.  Suggestions 
> welcome.   Note the new ACL draft link which hasn't been commented on 
> here on the  list -- if you get a chance to read that draft by Monday 
> that would be  super.
>
> Agenda for IMAPEXT meeting at 61st IETF
> Monday, Nov 8,  1530-1730
>
> 0.  Agenda bashing, find note taker and jabber scribe:
> (10 minutes)
>
> 1. Sorting, threading, and viewing (to be dealt with by one or more
>   mechanisms)
>  - <http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-17.txt>
>     status: still blocked on comparator (as is i18n draft)

Are you proposing that the WG discusses the i18 draft?

>  -  <http://www.ietf.org/internet-drafts/draft-ietf-imapext-list- 
> extensions-10.txt>
>     Barry Leiba will discuss
>     Still issues on  /Placeholder from last meeting, which Alexey and  
> Cyrus were tasked with resolving
> (40 minutes)
>
> 2. Access Control Lists
>  - <http://www.ietf.org/internet-drafts/draft-ietf-imapext-acl-10.txt>
>     Not updated since last meeting -- probably still blocked on LISTEXT.

Yes. I have some local changes, but LISTEXT and
draft-ietf-imapext-2086upd-00.txt take higher priorities right now.

>  -  
> <http://www.ietf.org/internet-drafts/draft-ietf-imapext-2086upd-00.txt>
>     READ THIS if you're coming to the meeting!  Or even if you're not.

Yes, please.

>   It hasn't been discussed on the list yet.
> (30 minutes)

I am not sure that it will take that long, I think the document is
pretty much done.

> 3. Message-level annotations
>  -  <http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate 
> -11.txt>
>     Changes since last meeting...
>     Open issue: use of the 'm' bit for ACL of private annotations

More specifically use of the "m" bit for reading of private annotations.

>     At least one more draft required
>  (40 minutes)

Hopefully this discussion would be short as well.

Date: Sat, 06 Nov 2004 16:29:57 +0000
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: STATUS command as an LISTEXT extension
Sender: [email-masked]

I don't want to start a religious war on whether STATUS should be
allowed to be a LISTEXT extension (because it can be as slow as SELECT
for some mailstores/implementations), but below I have an example of how
this might look like using existing LISTEXT syntax:

ABNF:

   return-option      =/ status-option

   status-option      = "STATUS=" status-att-comlist

   status-att-comlist = status-att *("," status-att)
                        ;; Comma separated list of status-att

   status-item-data   = "STATUS" SP "(" status-att-list ")"
                        ;; conforms to the mbox-list-extended-item-data
                        ;; syntax

Example:

       C: CA3 LIST "" "%" RETURN (STATUS=UIDVALIDITY,UIDNEXT,MESSAGES)
       S: * LIST (\Marked \NoInferiors) "/" "inbox" ((STATUS (UIDVALIDITY
           50505050 MESSAGES 231 UIDNEXT 44292)))
       S: * LIST () "/" "Foo" ((STATUS (UIDVALIDITY 467676708 MESSAGES 12
           UIDNEXT 100)))
       S: * LIST () "/" "Moo" ((STATUS (UIDVALIDITY 32 MESSAGES 711
UIDNEXT 9560)))
       S: CA3 OK done

Date: Sat, 06 Nov 2004 16:29:29 +0000
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>, "Vladimir A. Butenko" <[email-masked]>
Subject: Outstanding issues for draft-ietf-imapext-2086upd-00 (ACL)
Sender: [email-masked]

Actually, I believe there are only two. One relates to whether the "m"
right only controls writability of private annotations, or whether it
also controls readability. I've sent a separate message on this.

The second issue:

Which rights are required for the LISTRIGHTS command?

Currently the document says:

    MYRIGHTS - any of the following rights is required to perform
     the operation: "l", "r", "i", "c", "x", "a".*

    LISTRIGHTS - same as MYRIGHTS.

Some of the existing servers follow this suggestion. Some allow for
LISTRIGHTS if "r" and/or "a" is granted.

Philip has suggested (and I agree) to only allow LISTRIGHTS when the "a"
right is granted, as LISTRIGHTS information is only useful
if you can also do SETACL. Also, such information shouldn't be disclosed
to users that have insufficient rights.

Alexey

* - Note, that the STORE related rights ("w", "s", "t", "m" and "n") are
not part of this list, because the client must be able to open a mailbox
(i.e. "r") before performing a STORE command. The list also used to
contain the "e" right (which controls EXPUNGE), I've deleted it for the
same reason.

Date: Sat, 06 Nov 2004 16:29:18 +0000
From: Alexey Melnikov <[email-masked]>
To: Timo Sirainen <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Listext
Sender: [email-masked]

Timo Sirainen wrote:

> > 3.1. General principles for returning LIST responses
>
> Are these a MUST? Especially the "don't return mailbox more than once" 
> rule?

I would like to make the one you've mentioned a MUST. However it is not
going to be practical. I think they all SHOULDs.

However, if a single LIST command returns more than one extended LIST
response for a mailbox, we need to state some safe assumptions for
clients, e.g. the client can use mailbox flags from the latest LIST
response (and ignore all previous). I don't think many existing client
will be able to cope with multiple LIST responses for the same mailbox.

Alexey

Date: Sat, 06 Nov 2004 13:07:23 +0000
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: Randall Gellens <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Moving the ANNOTATE document forward
Sender: [email-masked]

Alexey Melnikov wrote:

> >   The 'm' right controls both read and write access to .priv annotation
> >   values.  When it is on, access to .priv annotations is allowed, when
> >   it is off, access to .priv annotations is disallowed.
>
> I still don't like using the "m" right for reading private 
> annotations, but we can discuss this during face to face meeting.

Ok, let me try to describe my concern.
 From the table in the ANNOTATE document:

   +===============+===============+===================================+
   |               |               |                                   |
   | No ACL        | read .priv    | Any mailbox that can be SELECTED  |
   |               | values        | or EXAMINED.                      |
   |               |               |                                   |
   +---------------+---------------+-----------------------------------+
   |               |               |                                   |
   | With ACL      | read .priv    | Any mailbox with the 'm'          |
   |               | values        | ACL right.                        |
   |               |               |                                   |
   +---------------+---------------+-----------------------------------+

Which means that a well behaving ANNOTATE&ACL-aware client needs to know 
whether the server supports ACL or not. Why? Because when the client 
opens a mailbox, it can't assume that private annotations are readable, 
because for the ACL-aware server the "m" right doesn't control if the 
mailbox can be SELECT/EXAMINEd or not.

Now, if we just say that both private and shared annotations are 
readable if the mailbox can be SELECT/EXAMINEd (i.e. the ACL "r" right), 
everything becomes much simpler (and consistent).

Cyrus has said:

 >The other benefit of 'm' as it stands now is that it gives servers a way
 >to optimise their storage because users without 'm' will never need a
 >private annotation store for that mailbox.

This may be true only for certain types of mailstores, but in general 
this is not true. Reporting any kind of annotations is trivial, whether 
the server can store them, or it just generates them on the fly (i.e. 
read-only private annotations). Checking the right "m" on FETCH just to 
make sure that private annotations can be read is just more work for the 
server. Most servers cache user's rights upon mailbox open and never try 
to refetch ACL for the selected mailbox. I.e. most servers never check 
ACLs on FETCH.

Alexey

Date: Sat, 06 Nov 2004 12:55:43 +0000
From: Alexey Melnikov <[email-masked]>
To: Timo Sirainen <[email-masked]>
CC: Cyrus Daboo <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Annotate
Sender: [email-masked]

Timo Sirainen wrote:

> On 1.11.2004, at 20:09, Cyrus Daboo wrote:
>
>>>     The 'm' right controls both read and write access to .priv 
>>> annotation
>>>     values.  When it is on, access to .priv annotations is allowed, 
>>> when
>>>     it is off, access to .priv annotations is disallowed.
>>>
>>> Is this really needed? I think private annotations should work the same
>>> way as private flags. You can always read them, and you can write 
>>> them if
>>> it's possible to permanently save flags.
>>
>> In an ACL-aware server there are different ways to control the flag 
>> state 's' and 'w' bits. As a result I think there should also be a 
>> way to enable/disable private annotations independently - hence the 
>> 'm' bit. I know Alexey had some concerns with 'm' too so this is 
>> still an open issue.
>
> Well, perhaps it would be useful to have "m" for writing because of 
> that, but I think "r" would be more logical for reading private 
> annotations.

I agree (a separate message on this is coming).

>>> I thought clients weren't allowed to make up their own annotation entry
>>> names? Or what does this mean?
>>
>>
>> If a client wants to create a 'boolean' (on/off) type property 
>> associated with a message it has two options: use an IMAP keyword 
>> (either private or registered), or create a vendor (or new standard) 
>> annotation entry. The former gives no control over private/shared 
>> state, whereas the latter does. So if there is a specific need for 
>> such a property that does need explicit private/shared behavior then 
>> the client can use annotations in lieu of IMAP keywords.
>
>
> I thought vendor namespaces meant that servers could create them, not 
> clients. Maybe put at the beginning of 2.2.1 something like:
>
> Vendor namespaces can be created by either clients or servers.

Yes.

> Servers MUST(?) support new namespaces created by clients.

I think this should be "SHOULD". We want to encourage ANNOTATE servers. 
Implementing a read-only ANNOTATE is much easier.

>> Here is some alternate text for the above paragraph that I am 
>> proposing to use instead. Note this also includes a sentence to 
>> address the first point you made:
>>
>>     Clients that need to implement a property on a message that is
>>     either 'on' or 'off' and which requires separate private and shared
>>     state can use an annotation to represent that property as opposed
>>     to using IMAP Keywords, which cannot reliably discriminate the
>>     private and shared state. However, clients MUST NOT use annotations
>>     to replace existing IMAP flag behavior, which would cause
>>     interoperability problems with non-ANNOTATE aware clients.
>>
>> If that is not suitable, please suggest some other text or 
>> clarifications.
>
> Looks good to me.

Looks good to me too.

Alexey

Date: Sat, 06 Nov 2004 00:24:44 +0000
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Updated draft-ietf-imapext-2086upd (ACL)
Sender: [email-masked]

--------------010108000909080309050706
Content-type: text/plain; charset="us-ascii"

I forgot to submit it. I think I've addressed all but one issue raised 
by Philip. I will send a separate message on this.
Apart from the issue, I think the document is ready for Last Call.

Alexey

--------------010108000909080309050706
Content-type: text/plain; name="draft-ietf-imapext-2086upd-01.txt"
Content-transfer-encoding: 7bit
Content-Disposition: inline;
 filename="draft-ietf-imapext-2086upd-01.txt"

IMAPEXT Working Group                                        A. Melnikov
Internet Draft                                                    Editor
Document: draft-ietf-imapext-2086upd-01.txt                November 2004
Updates: 2086, <<3501?>>
Expires: May 2005

                          IMAP4 ACL extension -
                        updated list of rights

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed, or
   will be disclosed, and any of which I become aware will be disclosed,
   in accordance with RFC 3668.

   Internet Drafts are working documents of the Internet Engineering
   Task Force (IETF), its Areas, and its Working Groups.  Note that
   other groups may also distribute working documents as Internet
   Drafts. Internet Drafts are draft documents valid for a maximum of
   six months.  Internet Drafts may be updated, replaced, or obsoleted
   by other documents at any time.  It is not appropriate to use
   Internet Drafts as reference material or to cite them other than as
   ``work in progress''.

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.

     Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or
     munnari.oz.au.

   A revised version of this draft document will be submitted to the RFC
   editor as a Proposed Standard for the Internet Community.  Discussion
   and suggestions for improvement are requested.  Distribution of this
   draft is unlimited.

Abstract

   The ACL (Access Control List) extension [RFC2086] of the Internet Message
   Access Protocol [IMAP4] permits mailbox access control lists to be
   manipulated through the IMAP protocol.

   This document updates the list of rights defined in RFC 2086. It
   also clarifies which rights are required for different IMAP commands.

1.   Conventions Used in this Document

   In examples, "C:" and "S:" indicate lines sent by the client and
   server respectively.

   In all examples "/" character is used as hierarchy separator.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [KEYWORDS].

2.   Introduction and Overview

   The ACL (Access Control List) extension of the Internet Message Access
   Protocol [IMAP4] permits mailbox access control lists to be retrieved
   and manipulated through the IMAP protocol.

   This document updates Section 3 of the RFC 2086. It also clarifies
   different aspects of the RFC 2086, in particular use of UTF-8 in
   identifiers, which rights are required for different IMAP4 commands;
   how READ-WRITE/READ-ONLY response codes are related to ACL>>

3.   Access Control

   This section replaces Section 3 of the RFC 2086.

   The ACL extension is present in any IMAP4 implementation which
   returns "ACL" as one of the supported capabilities to the CAPABILITY
   command.

   A server implementation conformant to this document MUST also return
   rights (see below) not defined in RFC 2086 in the "RIGHTS=" capability
   response.

   An access control list is a set of <identifier,rights> pairs.
   An ACL applies to a mailbox.

   Identifier is a UTF-8 string.  The identifier "anyone" is reserved
   to refer to the universal identity (all authentications, including
   anonymous). All user name strings accepted by the LOGIN or
   AUTHENTICATE commands to authenticate to the IMAP server are reserved
   as identifiers for the corresponding user.  Identifiers starting with
   a dash ("-") are reserved for "negative rights", described below.
   All other identifier strings are interpreted in an implementation-
   defined manner.

   Rights is a string listing a (possibly empty) set of alphanumeric
   characters, each character listing a set of operations which is being
   controlled.  Letters are reserved for ''standard'' rights, listed
   below.  The set of standard rights may only be extended by a
   standards-track document.  Digits are reserved for implementation or
   site defined rights.  The currently defined standard rights are
   (note, that the list below doesn't list all commands that use a
   particular right):

   l - lookup (mailbox is visible to LIST/LSUB commands, SUBSCRIBE mailbox)
   r - read (SELECT the mailbox, perform STATUS)
   s - keep seen/unseen information across sessions (set or clear \SEEN flag 
       via STORE, APPEND or COPY)
   w - write (set or clear flags other than \SEEN and \DELETED via STORE,
       APPEND or COPY)
   i - insert (perform APPEND, COPY into mailbox)
   p - post (send mail to submission address for mailbox,
       not enforced by IMAP4 itself.
   c - create mailboxes (CREATE new sub-mailboxes in any
       implementation-defined hierarchy, parent mailbox for the new 
       mailbox name in RENAME)
   x - delete mailbox (DELETE mailbox, old mailbox name in RENAME)
   t - delete messages (set or clear \DELETED flag via STORE, set \DELETED flag
       during APPEND/COPY)
   e - perform EXPUNGE and expunge as a part of CLOSE
   d - This right is defined for backward compatibility with ACL
       extension (RFC 2086). If a client sets "d" right, the server MUST
       set "x", "e" and "t" rights. When the client clears the "d" right,
       the server MUST clear "x", "e" and "t" rights. When all three of "x",
       "e" and "t" are set, the server MUST return "d" right in response to
       a LIST (ACL) command. If "x", "e" and "t" rights are not tied together,
       "d" right MUST NOT be returned in a LISTRIGHTS response.
   a - administer (perform SETACL/DELETEACL/GETACL)
   m - <<read/>>write private annotations [ANNOTATE]
   n - write shared annotations [ANNOTATE]

   An implementation may tie rights together or may force rights to
   always or never be granted to particular identifiers.  For example,
   in an implementation that uses unix mode bits, the rights "swite" are
   tied, the "a" right is always granted to the owner of a mailbox and
   is never granted to another user.  If rights are tied in an
   implementation, the implementation must be conservative in granting
   rights in response to SETACL commands--unless all rights in a tied
   set are specified, none of that set should be included in the ACL
   entry for that identifier. A client may discover the set of rights
   which may be granted to a given identifier in the ACL for a given
   mailbox by using the LISTRIGHTS command.

   It is possible for multiple identifiers in an access control list to
   apply to a given user (or other authentication identity).  For
   example, an ACL may include rights to be granted to the identifier
   matching the user, one or more implementation-defined identifiers
   matching groups which include the user, and/or the identifier
   "anyone".  How these rights are combined to determine the user's
   access is implementation-defined.  An implementation may choose, for
   example, to use the union of the rights granted to the applicable
   identifiers.  An implementation may instead choose, for example, to
   only use those rights granted to the most specific identifier present
   in the ACL. A client may determine the set of rights granted to the
   logged-in user for a given mailbox by using the MYRIGHTS command.

   When an identifier in an ACL starts with a dash ("-"), that indicates
   that associated rights are to be removed from the identifier that is
   prefixed by the dash. This is referred to as a "negative right". 
   This differs from DELETEACL in that a negative right is added to the
   ACL, and is a part of the calculation of the rights.

   Let's assume that an identifier "fred" refers to a user with login "fred".
   If the identifier "-fred" is granted the "w" right,
   that indicates that the "w" right is to be removed from users matching
   the identifier "fred", even though the user "fred" might have
   the "w" right as a consequence of some other identifier in the ACL.
   A DELETEACL of "fred" simply deletes the identifier "fred"
   from the ACL; it does not affect any rights that the user "fred"
   may get from another entry in the ACL.

   Server implementations are not required to support "negative right"
   identifiers.

4.   Rights required to perform different IMAP4rev1 commands

   Before executing a command an ACL compliant server must check which rights
   are required to perform it. This section groups command by functions
   they perform and list the rights required. It also gives the detailed
   description of any special processing required.

   The table below summarizes different rights or their combinations that are
   required in order to perform different IMAP operations. As it is not always
   possible to express complex right checking and interactions, the description
   after the table should be used as the primary reference.

   +---------------------+---+---+---+---+---+---+---+---+---+---+-----+------+
   | Operations\Rights   | l | r | s | w | i | c | x | t | e | a | Any | None |
   +---------------------+---+---+---+---+---+---+---+---+---+---+-----+------+
   |       LIST          | + |   |   |   |   |   |   |   |   |   |     |      |
   |    SUBSCRIBE        | * |   |   |   |   |   |   |   |   |   |     |   *  |
   |   UNSUBSCRIBE       |   |   |   |   |   |   |   |   |   |   |     |   +  |
   |       LSUB          | * |   |   |   |   |   |   |   |   |   |     |   *  |
   | CREATE (for parent) |   |   |   |   |   | + |   |   |   |   |     |      |
   |      DELETE         |   |   |   |   |   |   | + |   |   |   |     |      |
   |      RENAME         |   |   |   |   |   | + | + |   |   |   |     |      |
   |   COPY/APPEND       |   |   | ? | ? | + |   |   | ? |   |   |     |      |
   |  EXPUNGE/CLOSE      |   |   |   |   |   |   |   |   | + |   |     |      |
   |SELECT/EXAMINE/STATUS|   | + |   |   |   |   |   |   |   |   |     |      |
   |       FETCH         |   |   | ? |   |   |   |   |   |   |   |     |      |
   |    STORE flags      |   |   | ? | ? |   |   |   | ? |   |   |     |      |
   |   SETACL/DELETEACL  |   |   |   |   |   |   |   |   |   | + |     |      |
   |       GETACL        |   |   |   |   |   |   |   |   |   | + |     |      |
   | MYRIGHTS/LISTRIGHTS |   |   |   |   |   |   |   |   |   |   |  +  |      |
   +---------------------+---+---+---+---+---+---+---+---+---+---+-----+------+

   Legend:
    + - The right is required
    * - Only one of the rights marked with * is required (see description below)
    ? - The right is optional (see description below)
    "Any" - at least one of the "l", "r", "i", "c", "x", "a" rights is
            required
    "None" - No rights required to perform the command

   Listing and subscribing/unsubscribing mailboxes:
    LIST - "l" right is required.

    Note, that if the user has "l" right to a mailbox "A/B", but not to its parent
    mailbox "A", the LIST command should behave as if the mailbox "A" doesn't exist,
    for example:
               C: A777 LIST "" *
               S: * LIST (\NoInferiors) "/" "A/B"
               S: * LIST () "/" "C"
               S: * LIST (\NoInferiors) "/" "C/D"
               S: A777 OK LIST completed

    SUBSCRIBE - "l" right is required only if the server checks for mailbox existence
           when performing SUBSCRIBE.

    UNSUBSCRIBE - no rights required to perform this operation.

    LSUB - "l" right is required only if the server checks for mailbox existence when
           performing SUBSCRIBE.

   Mailbox management:
    CREATE - "c" right on a nearest existing parent mailbox. When a new
             mailbox is created it SHOULD inherit the ACL from the parent
             mailbox (if one exists) in the defined hierarchy.

    DELETE - "x" right on the mailbox.

    RENAME - Moving a mailbox from one parent to another
             requires "x" right on the mailbox itself and "c" right for
             the new parent. For example, if the user wants to rename
             mailbox named "A/B/C" to "D/E", the user must have "x" right
             for the mailbox "A/B/C" and "c" right for the mailbox "D".

             The RENAME command SHOULD NOT change the ACLs on the renamed
             mailbox and submailboxes.

   Copying or appending messages:

    Before performing a COPY/APPEND command the server MUST check if the
    user has "i" right for the target mailbox. If the user doesn't have "i"
    right, the operation fails. Otherwise for each copied/appended message
    the server MUST check if the user has
     "t" right - when the message has \Deleted flag set
     "s" right - when the message has \Seen flag set
     "w" right for all other message flags.
    Only when the user has a particular right the corresponding flags are
    stored for the newly created message. The server MUST NOT fail
    a COPY/APPEND if the user has no rights to set a particular flag.

   Example:    C: A003 MYRIGHTS TargetMailbox
               S: * MYRIGHTS TargetMailbox rwis
               S: A003 OK Myrights complete

               C: A004 FETCH 1:3 (FLAGS)
               S: * 1 FETCH (FLAGS (\Draft \Deleted)
               S: * 2 FETCH (FLAGS (\Answered)
               S: * 3 FETCH (FLAGS ($Forwarded \Seen)
               S: A004 OK Fetch Completed

               C: A005 COPY 1:3 TargetMailbox
               S: A005 OK Copy completed

               C: A006 SELECT TargetMailbox
                  ...
               S: A006 Select Completed

       Let's assume that the copied messages received message numbers 77:79.

               C: A007 FETCH 77:79 (FLAGS)
               S: * 77 FETCH (FLAGS (\Draft))
               S: * 78 FETCH (FLAGS (\Answered))
               S: * 79 FETCH (FLAGS ($Forwarded \Seen))
               S: A007 OK Fetch Completed

       \Deleted flag was lost on COPY, as the user has no "t" right in the
       target mailbox.

       If the MYRIGHTS command with the tag A003 would have returned:
               S: * MYRIGHTS TargetMailbox rsti

       the response from the FETCH with the tag A007 would have been:

               C: A007 FETCH 77:79 (FLAGS)
               S: * 77 FETCH (FLAGS (\Deleted))
               S: * 78 FETCH (FLAGS ())
               S: * 79 FETCH (FLAGS (\Seen))
               S: A007 OK Fetch Completed

       In the latter case \Answered, $Forwarded and \Draft flags were lost
       on COPY, as the user has no "w" right in the target mailbox.

   Expunging the selected mailbox:
    EXPUNGE - "e" right on the selected mailbox.

    CLOSE - "e" right on the selected mailbox. If the server is unable to
            expunge the mailbox because the user doesn't have the "e" right,
            the server MUST ignore expunge request, close the mailbox
            and return tagged OK response.

   Fetch information about a mailbox and its messages:
    SELECT/EXAMINE/STATUS - "r" right on the mailbox.

    FETCH - A FETCH request that implies setting \Seen flag MUST NOT set it,
            if the current user doesn't have "s" right.

   Changing flags:
    STORE - the server MUST check if the user has
     "t" right - when the user modifies \Deleted flag
     "s" right - when the user modifies \Seen flag
     "w" right for all other message flags.
     STORE operation SHOULD NOT fail if the user has rights to modify at least
     one flag specified in the STORE, as the tagged NO response to a STORE
     command is not handled very well by deployed clients.

   Changing ACLs:
    SETACL/DELETEACL - "a" right on the mailbox.

   Reading ACLs:
    GETACL - "a" right on the mailbox.

    MYRIGHTS - any of the following rights is required to perform
     the operation: "l", "r", "i", "c", "x", "a".

<<A previous version included "e" in the list. This explanation will be deleted
before publication:

Is there a particular reason why "s", "w", "t", "m" and "n" are excluded from
this list? - Yes, because flags can't be changed unless the "r" is also granted
(i.e. the mailbox can be SELECTed/EXAMINEd). But the same applies to "e"!>>

    LISTRIGHTS - same as MYRIGHTS. <<?>> <<Same rights as for GETACL?>>

5.   Formal Syntax

   This document doesn't change the formal syntax of commands/
   responses defined in the Section 6 of RFC 2086. However,
   the "identifier" production is now allowed to carry any UTF-8 string.

   Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4].
   Non-terminals referenced but not defined below are as defined by
   [IMAP4] or [LISTEXT].

   Except as noted otherwise, all alphabetic characters are
   case-insensitive.  The use of upper or lower case characters to
   define token strings is for editorial clarity only.  Implementations
   MUST accept these strings in a case-insensitive fashion.

   rights_capa      = "RIGHTS=" new_rights
                      ;; RIGHTS=... capability

   new_rights       = atom
                      ;; MUST include "t", "e", "x", "m" and "n"

6.   Security Considerations

   An implementation must make sure the ACL commands themselves do not
   give information about mailboxes with appropriately restricted ACL's.
   For example, a GETACL command on a mailbox for which the user has
   insufficient rights should not admit that the mailbox exists, much less
   return the mailbox's ACL.

   LISTRIGHTS command MUST NOT check that a particular identifier exists,
   however it SHOULD recognize special identifiers like "anyone".

   IMAP clients implementing ACL that are able to modify ACLs SHOULD
   warn a user that wants to give full access (or even just "a" right)
   to the special identifier "anyone".

7.  Other considerations

7.1. Additional requirements and Implementation notes

7.1.1. Servers

   This document defines an additional capability that is used to announce
   the list of extra rights (excluding the ones defined in the RFC 2086)
   supported by the server. The set of rights MUST include "t", "e", "x", "m"
   and "n". Note, that the extra rights can appear in any order.

   Example:    C: 1 capability
               S: * CAPABILITY IMAP4REV1 STARTTLS LITERAL+ ACL RIGHTS=texnm
               S: 1 OK completed

   The presence of the "RIGHTS=" capability also declares that the server
   always returns the MYRIGHTS untagged response upon SELECT/EXAMINE.
   The MYRIGHTS response SHOULD also be sent any time when the server detects
   that the set of rights allowed for the logged in user in the opened
   mailbox has changed.

   Any server implementing an ACL extension MUST accurately reflect the current
   user's rights in FLAGS and PERMANENTFLAGS responses.

   Example:    C: A142 SELECT INBOX
               S: * 172 EXISTS
               S: * 1 RECENT
               S: * MYRIGHTS INBOX rwis
               S: * OK [UNSEEN 12] Message 12 is first unseen
               S: * OK [UIDVALIDITY 3857529045] UIDs valid
               S: * OK [UIDNEXT 4392] Predicted next UID
               S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
               S: * OK [PERMANENTFLAGS (\Seen \Answered \Flagged \*)] Limited
               S: A142 OK [READ-WRITE] SELECT completed

   Servers MAY cache the rights a user has on a mailbox when the mailbox
   is selected, so that if a client's rights on a mailbox are changed with
   SETACL or DELETEACL, commands specific to the selected state (e.g., STORE,
   EXPUNGE) might not reflect the changed rights until the mailbox is
   re-selected. If the server checks the rights on each command, then it SHOULD
   send FLAGS and PERMANENTFLAGS responses if they have changed.

   An ACL server MAY modify one or more ACL for one or more identifier as a
   side effect of modifying the ACL specified in a SETACL/DELETEACL.
   If the server does that it MUST send untagged ACL response to notify the
   client about the changes made.

7.1.2. Clients

   A client implementation that allows a user to read and update ACLs MUST
   preserve unrecognized rights that it doesn't allow the user to change
   when updating the rights. Otherwise the client may unintentionally remove
   permissions.

7.2. Mapping of ACL rights to READ-WRITE and READ-ONLY response codes

   A particular ACL server implementation may allow "shared multiuser
   access" to some mailboxes. "Shared multiuser access" to a mailbox means
   that multiple different users are able to access the same mailbox,
   if they have proper access rights. "Shared multiuser access" to the
   mailbox doesn't mean that the ACL for the mailbox is currently set
   to allow access by multiple users. Let's denote a "shared multiuser
   write access" as a "shared multiuser access" when a user may be
   granted flag modification rights (any of "w", "s" or "t").

   Section 4 describes which rights are required for modifying different flags.

   If the ACL server implements some flags as shared for a mailbox (i.e.,
   the ACL for the mailbox may be set up so that changes to those flags are
   visible to another user), let's call the set of rights associated with these
   flags (as described in Section 4) for that mailbox collectively as
   "shared flag rights". Note, that "shared flag rights" set MAY be different
   for different mailboxes.

   If the server doesn't support "shared multiuser write access" to a
   mailbox or doesn't implement shared flags on the mailbox, "shared flag
   rights" for the mailbox is defined to be the empty set.

   Example 1: Mailbox "banan" allows "shared multiuser write access" and
              implements flags \Deleted, \Answered and $MDNSent as
              shared flags. "Shared flag rights" for the mailbox "banan"
              is a set containing flags "t" (because system flag \Deleted
              requires "t" right) and "w" (because both \Answered and
              $MDNSent require "w" right).

   Example 2: Mailbox "apple" allows "shared multiuser write access" and
              implements \Seen system flag as shared flag. "Shared flag
              rights" for the mailbox "apple" contains "s" right,
              because system flag \Seen requires "s" right.

   Example 3: Mailbox "pear" allows "shared multiuser write access" and
              implements flags \Seen, \Draft as shared flags. "Shared flag
              rights" for the mailbox "apple" is a set containing flags "s"
              (because system flag \Seen requires "s" right) and "w"
              (because system flag \Draft requires "w" right).

   The server MUST include a READ-ONLY prefix in the tagged OK response to
   a SELECT command if none of the following rights is granted to the
   current user:
    "i", "e" and "shared flag rights".
   The server SHOULD include a READ-WRITE prefix in the tagged OK response
   if at least one of the "i", "e" or "shared flag rights" is granted to the
   current user.

   Example 1 (continued): The user that has "lrs" rights for the mailbox
                          "banan". The server returns READ-ONLY response
                          code on SELECT, as none of "iewt" rights is
                          granted to the user.

   Example 2 (continued): The user that has "rit" rights for the mailbox
                          "apple". The server returns READ-WRITE response
                          code on SELECT, as the user has "i" right.

   Example 3 (continued): The user that has "rset" rights for the mailbox
                          "pear". The server returns READ-WRITE response
                          code on SELECT, as the user has "e" and "s" rights.

8.   References

8.1.   Normative References

   [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
   Requirement Levels", RFC 2119, Harvard University, March 1997.

   [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
   ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd,
   November 1997.

   [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
   4rev1", RFC 3501, University of Washington, March 2003.

   [RFC2086] Myers, J., "IMAP4 ACL extension", RFC 2086, Carnegie Mellon,
   January 1997

   [UTF-8] Yergeau, F., "UTF-8, a transformation format of IS0 10646",
   RFC 2279, Alis Technologies, January 1998.

8.2.   Informative References

   [ANNOTATE] Gellens, R. and C. Daboo, "IMAP ANNOTATE Extension",
   work in progress, draft-ietf-imapext-annotate-XX.txt

9.   Acknowledgment

   This document is an update to the RFC 2086 written by John G. Myers.

   Editor appreciates comments received from Mark Crispin, Chris Newman,
   Cyrus Daboo, John G. Myers, Steve Hole, Curtis King, Lyndon Nerenberg,
   Larry Greenfield, Robert Siemborski, Vladimir Butenko, Dave Cridland,
   Harrie Hazewinkel, Philip Guenther and other participants of the IMAPEXT
   working group.

10.  Editor's Address

   Alexey Melnikov
   email: [email-masked]

   Isode Limited

11.  IPR Disclosure Acknowledgement

    By submitting this Internet-Draft, I certify that any applicable
    patent or other IPR claims of which I am aware have been disclosed,
    and any of which I become aware will be disclosed, in accordance with
    RFC 3668.

12.  Intellectual Property Statement

    The IETF takes no position regarding the validity or scope of any
    intellectual property or other rights that might be claimed to
    pertain to the implementation or use of the technology described in
    this document or the extent to which any license under such rights
    might or might not be available; neither does it represent that it
    has made any effort to identify any such rights. Information on the
    IETF's procedures with respect to rights in standards-track and
    standards-related documentation can be found in BCP-11. Copies of
    claims of rights made available for publication and any assurances of
    licenses to be made available, or the result of an attempt made to
    obtain a general license or permission for the use of such
    proprietary rights by implementors or users of this specification can
    be obtained from the IETF Secretariat.

    The IETF invites any interested party to bring to its attention any
    copyrights, patents or patent applications, or other proprietary
    rights which may cover technology that may be required to practice
    this standard. Please address the information to the IETF Executive
    Director.

13.  Full Copyright Statement

    Copyright (C) The Internet Society (2004).  This document is subject
    to the rights, licenses and restrictions contained in BCP 78 and
    except as set forth therein, the authors retain all their rights.

    This document and the information contained herein are provided on an
    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

    Funding for the RFC Editor function is currently provided by the
    Internet Society.

Appendix A. Changes since RFC 2086

   1. Changed the charset of "identifier" from US-ASCII to UTF-8.

   2. Specified that mailbox deletion is controled by the "x" right and
      EXPUNGE is controlled by the "e" right.

   3. Clarified that RENAME requires the "c" right for the new parent and
      the "x" right for the old name.

   4. Added the "t" right that controls STORE \Deleted. Redefined "d"
      to be a macro for "e", "x" and "t".

   5. Specified that the "a" right also controls DELETEACL.

   6. Specified that the "r" right also controls STATUS.

   7. Removed the requirement to check the "r" right for CHECK, SEARCH and
      FETCH, as this is required for SELECT/EXAMINE to be successful.

   8. LISTRIGHTS requires same rights as MYRIGHTS.

   9. Deleted "PARTIAL", this is a deprecated feature of RFC1730.

  10. Specified that the "w" right controls setting flags other than \Seen
      and \Deleted on APPEND. Also specified that the "s" right controls
      the \Seen flag and that the "t" right controls the \Deleted flag.

  11. SUBSCRIBE is NOT allowed with the "r" right.

  12. Specified that the "l" right controls SUBSCRIBE.

  13. GETACL is NOT allowed with the "r" right, even though there are
      several implementations that allows that. If a user only has "r"
      right, GETACL can disclose information about identifiers existing
      on the mail system.

  14. Added new section that describes which rights are required and/or
      checked when performing various IMAP commands.

  15. Added mail client security considerations when dealing with special
      identifier "anyone".

  16. Clarified that negative rights are not the same as DELETEACL.

  17. Added note that a server can modify an ACL for any identifier(s) as a
      side effect of performing SETACL/DELETEACL. Also specified that
      the server MUST send untagged ACL response if it does that.

  18. Added section about mapping of ACL rights to READ-WRITE and READ-ONLY
      response codes.

  19. Added "Compatibility with RFC 2086" section.

  20. Added "Implementation Notes" section.

  21. Updated "References" section.

  22. Added requirement for a SELECT/EXAMINE to return the MYRIGHTS
      response.

  23. Added the "m" and "n" rights for ANNOTATE.

Appendix B. Compatibility with RFC 2086

   This section gives guidelines how an existing RFC 2086 server
   implementation may be updated to comply with this document.

   This document replaces the "d" right with 3 new different rights "x",
   "t" and "e". The server should implement one of the following two
   approaches to handle "d" and the new rights that have replaced it.

    a). Tie "x", "t" and "e" together - almost no changes.
    b). Implement separate "x", "t" and "e". Return "d" right in a LIST
        response containing ACL information when all three of "x", "t"
        and "e" are granted.

   Additional work required to implement ACL2 when RFC 2086 is already
   implemented:

   1). Send the MYRIGHTS untagged response on a successful SELECT/EXAMINE.

   Also check Sections 7.1 and 7.2, as well as the appendix A to see
   other changes required. Server implementors should check which rights
   are required to invoke different IMAP4 commands as described in
   Section 4.

--------------010108000909080309050706--

Date: Sat, 06 Nov 2004 14:42:41 +0100
From: kael <[email-masked]>
To: [email-masked]
Subject: Question about the SORT and THREAD extensions 
Sender: [email-masked]

Hello,

Can [could] the SORT and THREAD extensions handle messages like this 
http://www.deftone.com/blogzilla/archives/new_thunderbird_feature_message_grouping.html 
?

-- 
kael

http://del.icio.us/ubi.quito.us

To: [email-masked], IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Proposed agenda for IMAPEXT
Date: Fri, 5 Nov 2004 13:10:04 -0800
Sender: [email-masked]

I'm sorry this is so late, but here it is anyway.  Suggestions welcome.  
  Note the new ACL draft link which hasn't been commented on here on the  
list -- if you get a chance to read that draft by Monday that would be  
super.

Agenda for IMAPEXT meeting at 61st IETF
Monday, Nov 8,  1530-1730

0.  Agenda bashing, find note taker and jabber scribe:
(10 minutes)

1. Sorting, threading, and viewing (to be dealt with by one or more
   mechanisms)
  - <http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-17.txt>
     status: still blocked on comparator (as is i18n draft)
  -  
<http://www.ietf.org/internet-drafts/draft-ietf-imapext-list- 
extensions-10.txt>
     Barry Leiba will discuss
     Still issues on  /Placeholder from last meeting, which Alexey and  
Cyrus were tasked with resolving
(40 minutes)

2. Access Control Lists
  - <http://www.ietf.org/internet-drafts/draft-ietf-imapext-acl-10.txt>
     Not updated since last meeting -- probably still blocked on LISTEXT.
  -  
<http://www.ietf.org/internet-drafts/draft-ietf-imapext-2086upd-00.txt>
     READ THIS if you're coming to the meeting!  Or even if you're not.  
It hasn't been discussed on the list yet.
(30 minutes)

3. Message-level annotations
  -  
<http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate 
-11.txt>
     Changes since last meeting...
     Open issue: use of the 'm' bit for ACL of private annotations
     At least one more draft required
  (40 minutes)

Date: Fri, 05 Nov 2004 16:26:39 +0000
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>, [email-masked]
Subject: Not being able to attend IMAPEXT/Lemonade
Sender: [email-masked]

Due to little trick that UK Home Office has played on me, I am still not 
in possession of my passport. My flight is tomorrow at noon. So I will 
most likely miss the IMAPEXT and Lemonade meetings. I will try to 
participate in jabber.

Alexey

Cc: IMAP Extensions WG <[email-masked]>
From: Timo Sirainen <[email-masked]>
Subject: Re: Annotate
Date: Mon, 1 Nov 2004 20:44:09 +0200
To: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

--Apple-Mail-16-768365339
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

On 1.11.2004, at 20:09, Cyrus Daboo wrote:

>>     The 'm' right controls both read and write access to .priv 
>> annotation
>>     values.  When it is on, access to .priv annotations is allowed, 
>> when
>>     it is off, access to .priv annotations is disallowed.
>>
>> Is this really needed? I think private annotations should work the 
>> same
>> way as private flags. You can always read them, and you can write 
>> them if
>> it's possible to permanently save flags.
>
> In an ACL-aware server there are different ways to control the flag 
> state 's' and 'w' bits. As a result I think there should also be a way 
> to enable/disable private annotations independently - hence the 'm' 
> bit. I know Alexey had some concerns with 'm' too so this is still an 
> open issue.

Well, perhaps it would be useful to have "m" for writing because of 
that, but I think "r" would be more logical for reading private 
annotations.

>> I thought clients weren't allowed to make up their own annotation 
>> entry
>> names? Or what does this mean?
>
> If a client wants to create a 'boolean' (on/off) type property 
> associated with a message it has two options: use an IMAP keyword 
> (either private or registered), or create a vendor (or new standard) 
> annotation entry. The former gives no control over private/shared 
> state, whereas the latter does. So if there is a specific need for 
> such a property that does need explicit private/shared behavior then 
> the client can use annotations in lieu of IMAP keywords.

I thought vendor namespaces meant that servers could create them, not 
clients. Maybe put at the beginning of 2.2.1 something like:

Vendor namespaces can be created by either clients or servers. Servers 
MUST(?) support new namespaces created by clients.

> Here is some alternate text for the above paragraph that I am 
> proposing to use instead. Note this also includes a sentence to 
> address the first point you made:
>
> 	Clients that need to implement a property on a message that is
> 	either 'on' or 'off' and which requires separate private and shared
> 	state can use an annotation to represent that property as opposed
> 	to using IMAP Keywords, which cannot reliably discriminate the
> 	private and shared state. However, clients MUST NOT use annotations
> 	to replace existing IMAP flag behavior, which would cause
> 	interoperability problems with non-ANNOTATE aware clients.
>
> If that is not suitable, please suggest some other text or 
> clarifications.

Looks good to me.

--Apple-Mail-16-768365339
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

--Apple-Mail-16-768365339--

Date: Mon, 01 Nov 2004 13:09:06 -0500
From: Cyrus Daboo <[email-masked]>
To: Timo Sirainen <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Annotate
Sender: [email-masked]

Hi Timo,

--On Monday, November 1, 2004 7:27:45 PM EST +0200 Timo Sirainen 
<[email-masked]> wrote:

> Some comments:
>
>     Clients MUST NOT use annotations in lieu of equivalent IMAP base
>     specification facilities.  For example, use of a "seen" flag in the
>     vendor namespace together with ".PEEK" in fetches.  Such behaviour
>     would significantly reduce IMAP interoperability.
>
> I don't understand the example. What does .PEEK fetches have to do with
> \Seen flag, except without it the \Seen flag might change?

In this example we are saying that a 'rogue' client might choose to bypass 
the standard IMAP seen behavior by using .PEEK fetches (that do not change 
the IMAP \Seen flag) and instead use their own private seen annotation that 
is used to indicate seen state in that client. That hurts interop because a 
message that appears seen in one client, does not appear seen in another.

What I think will be best is to remove the text you quoted, and instead 
insert a comment in the flags section (actually this will appear in the new 
text I propose below in response to your last point).

>     If a server supports annotations, then it MUST store all annotation
>     data permanently, i.e.  there is no concept of 'session only'
>     annotations that would correspond to the behaviour of 'session' flags
>     as defined in the IMAP base specification.  The exception to this is
>     IMAP flags (which are accessible directly through annotations) which
>     may be 'session only' as determined by the FLAGS and PERMANENTFLAGS
>     responses to a SELECT or EXAMINE command.
>
> Since IMAP flags can no longer be modified with ANNOTATE, the exception
> should probably be removed.

OK, I will remove that last sentence.

>     The 'm' right controls both read and write access to .priv annotation
>     values.  When it is on, access to .priv annotations is allowed, when
>     it is off, access to .priv annotations is disallowed.
>
> Is this really needed? I think private annotations should work the same
> way as private flags. You can always read them, and you can write them if
> it's possible to permanently save flags.

In an ACL-aware server there are different ways to control the flag state 
's' and 'w' bits. As a result I think there should also be a way to 
enable/disable private annotations independently - hence the 'm' bit. I 
know Alexey had some concerns with 'm' too so this is still an open issue.

>     /flags
>        Defines the top-level of entries for flags associated with an
>        entire message.  The "value" attribute of each of the entries
>        described below must be either "1", "0" or NIL.  "1" corresponds
>        to the flag being set.
>
> NIL isn't defined here. Does it mean "not set"? For example:

NIL should be removed. The flag value must be either 1 or 0, and both .priv 
and .shared will be the same. NIL only made sense when annotate was 
discriminating  between private/shared flag behavior, which it no longer 
does.

>     Clients that need to implement shared and private 'flags' can create
>     their own annotation entries for those, completely bypassing the base
>     IMAP flag/keyword behaviour.
>
> I thought clients weren't allowed to make up their own annotation entry
> names? Or what does this mean?

If a client wants to create a 'boolean' (on/off) type property associated 
with a message it has two options: use an IMAP keyword (either private or 
registered), or create a vendor (or new standard) annotation entry. The 
former gives no control over private/shared state, whereas the latter does. 
So if there is a specific need for such a property that does need explicit 
private/shared behavior then the client can use annotations in lieu of IMAP 
keywords.

Here is some alternate text for the above paragraph that I am proposing to 
use instead. Note this also includes a sentence to address the first point 
you made:

	Clients that need to implement a property on a message that is
	either 'on' or 'off' and which requires separate private and shared
	state can use an annotation to represent that property as opposed
	to using IMAP Keywords, which cannot reliably discriminate the
	private and shared state. However, clients MUST NOT use annotations
	to replace existing IMAP flag behavior, which would cause
	interoperability problems with non-ANNOTATE aware clients.

If that is not suitable, please suggest some other text or clarifications.
-- 
Cyrus Daboo

To: IMAP Extensions WG <[email-masked]>
From: Timo Sirainen <[email-masked]>
Subject: Annotate
Date: Mon, 1 Nov 2004 19:27:45 +0200
Sender: [email-masked]

--Apple-Mail-15-763781542
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

Some comments:

    Clients MUST NOT use annotations in lieu of equivalent IMAP base
    specification facilities.  For example, use of a "seen" flag in the
    vendor namespace together with ".PEEK" in fetches.  Such behaviour
    would significantly reduce IMAP interoperability.

I don't understand the example. What does .PEEK fetches have to do with 
\Seen flag, except without it the \Seen flag might change?

    If a server supports annotations, then it MUST store all annotation
    data permanently, i.e.  there is no concept of 'session only'
    annotations that would correspond to the behaviour of 'session' flags
    as defined in the IMAP base specification.  The exception to this is
    IMAP flags (which are accessible directly through annotations) which
    may be 'session only' as determined by the FLAGS and PERMANENTFLAGS
    responses to a SELECT or EXAMINE command.

Since IMAP flags can no longer be modified with ANNOTATE, the exception 
should probably be removed.

    The 'm' right controls both read and write access to .priv annotation
    values.  When it is on, access to .priv annotations is allowed, when
    it is off, access to .priv annotations is disallowed.

Is this really needed? I think private annotations should work the same 
way as private flags. You can always read them, and you can write them 
if it's possible to permanently save flags.

    /flags
       Defines the top-level of entries for flags associated with an
       entire message.  The "value" attribute of each of the entries
       described below must be either "1", "0" or NIL.  "1" corresponds
       to the flag being set.

NIL isn't defined here. Does it mean "not set"? For example:

/flags/\Seen.shared = 1
/flags/\Seen.private = NIL
  -> private \Seen flag set

/flags/\Seen.shared = 1
/flags/\Seen.private = 0
  -> private \Seen flag not set

Or should server do this internally and always return 1/0 seen flag? So 
NIL would only be useful for shared? Or should it also there default to 
1/0?

    Clients that need to implement shared and private 'flags' can create
    their own annotation entries for those, completely bypassing the base
    IMAP flag/keyword behaviour.

I thought clients weren't allowed to make up their own annotation entry 
names? Or what does this mean?

--Apple-Mail-15-763781542
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

--Apple-Mail-15-763781542--

From: Dave Cridland <[email-masked]>
To: Philip Guenther <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Updated draft-ietf-imapext-2086upd (ACL) 
Date: Tue, 30 Nov 2004 09:54:34 +0000
Sender: [email-masked]

On Mon Nov 29 22:23:45 2004, Philip Guenther wrote:
> 
> Ken Murchison <[email-masked]> writes:
> ...
> >Yes.  The draft makes the false assumption that *all* existing 
> >implementations use the 'd' right to control DELETE.  Cyrus made 
> the >decision a while back to separate mailbox ops (DELETE) from 
> message ops >(\Deleted and EXPUNGE).  Its unfortunate that RFC 2086 
> was >vague/ambiguous w.r.t. DELETE.
> ...
> >One easy way to do this might be to make 'c' a macro in the new 
> draft >just like 'd' and create a new bit for CREATE (e.g. 'k')  
> Then the >mapping would be:
> >
> >Cyrus:  'c' -> "kx", 'd' -> "te"
> >Others: 'c' -> "k",  'd' -> "xte"
> 
> This makes sense to me, but our server has this problem too, being
> distantly derived from Cyrus.  Does anyone actually know of a server
> that controls DELETE with the 'd' right?

CommunigatePro does, but *also* controls it with the "c" right on the 
parent.

(In other words, given A/B, issuing DELETE A/B requires "c" right in 
A and "d" right in B)

I would guess that Sun's implementation might require the parent "c" 
right, as well, given that their JavaMail [client] API documents that 
as required, but that's pure speculation on my part - I can't access 
their server implementation's documentation.

Dave.

To: Ken Murchison <[email-masked]>
Cc: Brian Candler <[email-masked]>, Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: Updated draft-ietf-imapext-2086upd (ACL) 
Date: Mon, 29 Nov 2004 14:23:45 -0800
Sender: [email-masked]

Ken Murchison <[email-masked]> writes:
...
>Yes.  The draft makes the false assumption that *all* existing 
>implementations use the 'd' right to control DELETE.  Cyrus made the 
>decision a while back to separate mailbox ops (DELETE) from message ops 
>(\Deleted and EXPUNGE).  Its unfortunate that RFC 2086 was 
>vague/ambiguous w.r.t. DELETE.
...
>One easy way to do this might be to make 'c' a macro in the new draft 
>just like 'd' and create a new bit for CREATE (e.g. 'k')  Then the 
>mapping would be:
>
>Cyrus:  'c' -> "kx", 'd' -> "te"
>Others: 'c' -> "k",  'd' -> "xte"

This makes sense to me, but our server has this problem too, being
distantly derived from Cyrus.  Does anyone actually know of a server
that controls DELETE with the 'd' right?

Philip Guenther

From: Dave Cridland <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>, Lisa Dusseault <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Date: Thu, 25 Nov 2004 13:14:10 +0000
Sender: [email-masked]

On Tue Nov 23 21:41:25 2004, Alexey Melnikov wrote:
> Suggested text:
>   Rights is a string listing a (possibly empty) set of alphanumeric
>   characters, each character listing a set of operations which is 
> being
>   controlled.  Lowercase letters are reserved for ''standard'' 
> rights, listed
>   below.  (Note that for compatibility with deployed clients and
>   servers uppercase rights are not allowed).
> 
> And update ABNF to enforce this.
> 
> 
That's fine by me.

> In the ACL2 document we should say something like this:
>  Unlike the RFC 2086, the letter rights are case-insensitive, so 
> the right "R" is the same as the right "r".
> 
> 
That's also fine by me.

Dave.

To: Alexey Melnikov <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt 
Date: Wed, 24 Nov 2004 10:56:52 -0800
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:
>Suggested text:
>   Rights is a string listing a (possibly empty) set of alphanumeric
>   characters, each character listing a set of operations which is being
>   controlled.  Lowercase letters are reserved for ''standard'' rights,
>   listed below.  (Note that for compatibility with deployed clients and
>   servers uppercase rights are not allowed).

I can live with this.

Philip Guenther

Date: Tue, 23 Nov 2004 21:41:25 +0000
From: Alexey Melnikov <[email-masked]>
To: Lisa Dusseault <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

Lisa Dusseault wrote:

> Looks like there was actually unanimity among seven voters to require 
> both clients and servers to send only lower-case rights in 2086upd, 
> but some quibbling about other details (whether to accept upper-case, 
> what precise wording to use).  Cyrus' proposed wording was:
>
>> 'Rights in 2086upd are case-insenstive, however clients and servers 
>> MUST use lower-case rights to be compatible with clients or servers 
>> supporting the original 2086 specification.'
>
> Philip suggested a slight modification that servers that advertise 
> support for 2086upd should be able to accept upper-case rights as well 
> (but not send them, if I understand).
>
> Alexey and Dave suggested that the spec not even use the word 
> "case-insensitive" to not confuse people.
>
> So Alexey, how about you propose new text for 2086upd?

Suggested text:
   Rights is a string listing a (possibly empty) set of alphanumeric
   characters, each character listing a set of operations which is being
   controlled.  Lowercase letters are reserved for ''standard'' rights, 
listed
   below.  (Note that for compatibility with deployed clients and
   servers uppercase rights are not allowed).

And update ABNF to enforce this.

In the ACL2 document we should say something like this:
  Unlike the RFC 2086, the letter rights are case-insensitive, so the 
right "R" is the same as the right "r".

From: Lisa Dusseault <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Date: Tue, 23 Nov 2004 10:01:01 -0800
To: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

Looks like there was actually unanimity among seven voters to require 
both clients and servers to send only lower-case rights in 2086upd, but 
some quibbling about other details (whether to accept upper-case, what 
precise wording to use).  Cyrus' proposed wording was:

> 'Rights in 2086upd are case-insenstive, however clients and servers 
> MUST use lower-case rights to be compatible with clients or servers 
> supporting the original 2086 specification.'

Philip suggested a slight modification that servers that advertise 
support for 2086upd should be able to accept upper-case rights as well 
(but not send them, if I understand).

Alexey and Dave suggested that the spec not even use the word 
"case-insensitive" to not confuse people.

So Alexey, how about you propose new text for 2086upd?

Lisa

Date: Tue, 23 Nov 2004 16:14:40 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Cc: Alexey Melnikov <[email-masked]>, Philip Guenther <[email-masked]>, Lisa Dusseault <[email-masked]>
Sender: [email-masked]

Alexey Melnikov writes:
> So I am in favor of saying that upper-case rights in 2086upd are not allowed.
>
> And I agree that ACL2 should relax this to make rights case-insensitive.

I'm happy with that.

Arnt

Date: Tue, 23 Nov 2004 15:02:57 +0000
From: Alexey Melnikov <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

Philip Guenther wrote:

>I'm in favor of requiring servers that advertise the RIGHTS capability
>to treat rights as case-insensitive.  This requirement would (obviously)
>not be retroactive to implementation that only support ACL and not
>RIGHTS, so it does not invalidate any implementations.  I find the
>described behavior of existing implementations largely irrelevant to
>this decision: upgrading an implementation from just ACL to ACL+RIGHTS
>is clearly going to require code changes for the new rights; adding a
>"tolower()" call would just be one of those changes.
>
>For the benefit of client implementors, a note could be added that warns
>that there exist common ACL implementations that predate this
>requirement and therefore that clients MUST send the standard rights as
>lowercase letters when talking to a server that does not support the
>RIGHTS extension.
>  
>
As there is no way for a client to announce its capabilities, the server 
MUST always send rights in lower-case.

I just really see no point of saying that rights are case-insensitive 
when there are effectively case-sensitive for existing ACL implementations.

>Leaving the meaning of uppercase rights implementation defined doesn't
>help anyone and means we simply get to have this same discussion all
>over again come ACL2.
>  
>
I agree, we need to either disallow upper-case rights or make them equal 
to the lower-case counterparts.
I don't think anybody has presented a good argument for making 
upper-case and lower-case rights different.

However, I share David's concern that even mentioning the word 
"case-insensitive" will mislead some implementors.
So I am in favor of saying that upper-case rights in 2086upd are not 
allowed.

And I agree that ACL2 should relax this to make rights case-insensitive.

To: Lisa Dusseault <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt 
Date: Mon, 22 Nov 2004 18:04:08 -0800
From: Philip Guenther <[email-masked]>
Sender: [email-masked]

I'm in favor of requiring servers that advertise the RIGHTS capability
to treat rights as case-insensitive.  This requirement would (obviously)
not be retroactive to implementation that only support ACL and not
RIGHTS, so it does not invalidate any implementations.  I find the
described behavior of existing implementations largely irrelevant to
this decision: upgrading an implementation from just ACL to ACL+RIGHTS
is clearly going to require code changes for the new rights; adding a
"tolower()" call would just be one of those changes.

For the benefit of client implementors, a note could be added that warns
that there exist common ACL implementations that predate this
requirement and therefore that clients MUST send the standard rights as
lowercase letters when talking to a server that does not support the
RIGHTS extension.

Leaving the meaning of uppercase rights implementation defined doesn't
help anyone and means we simply get to have this same discussion all
over again come ACL2.

Philip Guenther

From: Dave Cridland <[email-masked]>
To: Philip Guenther <[email-masked]>
Cc: Mark Crispin <[email-masked]>, Alexey Melnikov <[email-masked]>, <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt 
Date: Mon, 22 Nov 2004 10:29:22 +0000
Sender: [email-masked]

On Fri Nov 19 23:50:04 2004, Philip Guenther wrote:
> Furthermore, I would suggest that servers SHOULD return a BAD 
> response
> if a client specifies an unknown right.  Silently ignoring part of 
> what
> a client says is a recipe for later dissension...like the current
> discussion.

Indeed. That doesn't solve the existing problem, though.

> On one point:
> 
> Dave Cridland <[email-masked]> writes:
> ...
> >And ACL2 is a total replacement, in effect. RFC2086 will die out, 
> >along with this specification too, and while there will be a 
> >compatibility option in most implementations, that's something 
> that >will fall out of use quite happily by itself.
> 
> I disagree that ACL2 should be a complete replacement; with the 
> possible
> exception of adding another right or two, ACL2 should simply refer 
> to
> 2086upd for their definition and syntax.  ACL2 implementations are 
> going
> to need to support plain ACL for a goodly time to come; we should do
> everything we can to avoid unnecessary incompatibilities between 
> them.
> 
> (Even simply repeating the text from 2086upd in ACL2 would be error
> prone.  Would a latter erratum automatically apply to both?  What 
> if the
> text got editted slightly differently when republished?)

No, agreed. So we stick to the rights letters and definitions, but 
ACL2 simply makes them case-insensitive for its interface.

2086upd issues a blanket-ban on uppercase rights being defined, in 
preparation for this.

This should result in simpler language, and I believe greater 
interoperability.

Dave.

From: Dave Cridland <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Cc: Jutta Degener <[email-masked]>, IMAP Extensions WG <[email-masked]>, Mark Crispin <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, Alexey Melnikov <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Date: Mon, 22 Nov 2004 10:25:32 +0000
Sender: [email-masked]

On Sat Nov 20 17:25:43 2004, Lisa Dusseault wrote:
> Ok, can we get summarizing arguments from the different positions 
> here (case-sensitive v. case-insensitive ACL tokens) and tell me 
> your vote?  I can't see a clear consensus yet despite a fair amount 
> of discussion over this choice.

Summary:
1) Existing RFC2086 implementations assume case-sensitivity:
Refs: See source code of implementations.
2) Existing, widely deployed implementations break silently when 
case-insensitivity is assumed.
Refs: Tested against Cyrus IMAPd. SETACL with uppercase rights 
discards those rights, returns OK.
3) Definition of rights as case-insensitive is more likely to lead to 
clients which send uppercase rights - even though against the 
standard, the resultant wording has considerable scope to confuse.

If broken implementations sending uppercase rights to existing 
implementations received a BAD in return, I'd vote for this. However, 
they don't, and a silent discarding of rights is likely to cause 
newly released software to fail to interoperate with existing 
implementations.

Therefore, as much as I would personally like case-insensitive right 
letters, I have to vote against changing the existing syntax, on the 
basis of interoperability.

In ACL2, I'd be happy to see the ACL SET/STORE/DELETE syntax use 
case-insensitive rights - I'm not against the change, merely the 
timing of it.

Dave.

Date: Sat, 20 Nov 2004 12:59:13 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>, Alexey Melnikov <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

On Sat, 20 Nov 2004, Cyrus Daboo wrote:
> 'Rights in 2086upd are case-insenstive, however clients and servers MUST use 
> lower-case rights to be compatible with clients or servers supporting the 
> original 2086 specification.'

OK.

> As long as the lower-case requirement applies to servers as well as clients I 
> vote for case-insensitivity.

I agree to this.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Sat, 20 Nov 2004 14:42:54 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, Lisa Dusseault <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, Alexey Melnikov <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

Hi Mark,

--On November 20, 2004 11:09:44 -0800 Mark Crispin <[email-masked]> 
wrote:

> On Sat, 20 Nov 2004, Lisa Dusseault wrote:
>> Ok, can we get summarizing arguments from the different positions here
>> (case-sensitive v. case-insensitive ACL tokens) and tell me your vote?
>> I  can't see a clear consensus yet despite a fair amount of discussion
>> over this  choice.
>
> Mark votes for mandatory case-insensitivity in servers which claim to be
> 2086upd compliant (ACL2 goes without saying), and for a prohibition on
> clients sending upper-case to 2086 and 2086upd servers.  The latter
> provision is subject to review in ACL2.
>

That's not good enough because it potentially breaks existing clients which 
expect case-sensitive (lower-case) values from the server. The proper way 
to do this is:

'Rights in 2086upd are case-insenstive, however clients and servers MUST 
use lower-case rights to be compatible with clients or servers supporting 
the original 2086 specification.'

As long as the lower-case requirement applies to servers as well as clients 
I vote for case-insensitivity. However, if that requirement on the server 
is not applied, then I vote for case-sensitivity in 2086upd.

-- 
Cyrus Daboo

Date: Sat, 20 Nov 2004 11:09:44 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Lisa Dusseault <[email-masked]>
cc: Jutta Degener <[email-masked]>, IMAP Extensions WG <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, Alexey Melnikov <[email-masked]>, Dave Cridland <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

On Sat, 20 Nov 2004, Lisa Dusseault wrote:
> Ok, can we get summarizing arguments from the different positions here 
> (case-sensitive v. case-insensitive ACL tokens) and tell me your vote?  I 
> can't see a clear consensus yet despite a fair amount of discussion over this 
> choice.

Mark votes for mandatory case-insensitivity in servers which claim to be 
2086upd compliant (ACL2 goes without saying), and for a prohibition on 
clients sending upper-case to 2086 and 2086upd servers.  The latter 
provision is subject to review in ACL2.

The intent is to install case-insensitivity by transition; by putting 
servers on notice that they must fix any case-sensitivity to be 2086upd 
compliant, without breaking any existing behavior.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

From: Lisa Dusseault <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Date: Sat, 20 Nov 2004 09:25:43 -0800
To: Jutta Degener <[email-masked]>, IMAP Extensions WG <[email-masked]>, Mark Crispin <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, Alexey Melnikov <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Ok, can we get summarizing arguments from the different positions here 
(case-sensitive v. case-insensitive ACL tokens) and tell me your vote?  
I can't see a clear consensus yet despite a fair amount of discussion 
over this choice.

I need to know your vote even if you've already stated your position 
because some opinions were given before much discussion happened, and I 
need to know if the discussion changed anybody's mind.  Also welcoming 
input from those who've stayed silent so far.

Lisa

Date: Sat, 20 Nov 2004 15:55:18 +0000
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: [email-masked]
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

Mark Crispin wrote:

>> However, do you honestly think that client authors will change their 
>> code to send uppercase rights? (I mean, discounting the kinds of 
>> authors who deliberately do weird things because they can.)
>
> I don't think that; I *know* that.

Mark, can you elaborate?

Date: Fri, 19 Nov 2004 16:14:18 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, [email-masked], Jutta Degener <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Fri, 19 Nov 2004, Dave Cridland wrote:
> Nor will they use 2086upd servers either. As I understand things, 2086upd is 
> fully intended to be a stopgap until ACL2. Let's treat it like one.

If the transition isn't started with 2086upd, it won't happen.

> Wait... You "know" client authors will actively edit their code and put in 
> uppercase rights, then lowercase them for backwards compatibility with "pure" 
> RFC2086 servers if/when they encounter them?
> Why?

Yes, I know.  There are a number of reasons of doing this, few of which 
have anything to do with technical excellence.  For example, some client 
authors intentionally build software that works differentially with 
specific servers.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

To: Dave Cridland <[email-masked]>
Cc: Mark Crispin <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked], Arnt Gulbrandsen <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt 
Date: Fri, 19 Nov 2004 15:50:04 -0800
From: Philip Guenther <[email-masked]>
Sender: [email-masked]

I'm in favor of Mark's proposed clarification that rights MUST be
treated as case-insensitive.

Furthermore, I would suggest that servers SHOULD return a BAD response
if a client specifies an unknown right.  Silently ignoring part of what
a client says is a recipe for later dissension...like the current
discussion.

On one point:

Dave Cridland <[email-masked]> writes:
...
>And ACL2 is a total replacement, in effect. RFC2086 will die out, 
>along with this specification too, and while there will be a 
>compatibility option in most implementations, that's something that 
>will fall out of use quite happily by itself.

I disagree that ACL2 should be a complete replacement; with the possible
exception of adding another right or two, ACL2 should simply refer to
2086upd for their definition and syntax.  ACL2 implementations are going
to need to support plain ACL for a goodly time to come; we should do
everything we can to avoid unnecessary incompatibilities between them.

(Even simply repeating the text from 2086upd in ACL2 would be error
prone.  Would a latter erratum automatically apply to both?  What if the
text got editted slightly differently when republished?)

Philip Guenther

From: Dave Cridland <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, <[email-masked]>, Jutta Degener <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, Brian Candler <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Date: Fri, 19 Nov 2004 19:59:47 +0000
Sender: [email-masked]

On Fri Nov 19 17:48:33 2004, Mark Crispin wrote:
> On Fri, 19 Nov 2004, Brian Candler wrote:
>> That's if I understand correctly: the ACL2 proposal is being 
>> dropped.
> 
> Is ACL2 being dropped?
> 
> I oppose that.

Likewise.

ACL2 isn't being dropped, at least not unless we can't last-call it 
by 2005/02/05, as far as I'm aware.

Dave.

From: Dave Cridland <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, <[email-masked]>, Jutta Degener <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Date: Fri, 19 Nov 2004 19:56:46 +0000
Sender: [email-masked]

On Fri Nov 19 16:41:53 2004, Mark Crispin wrote:
> On Fri, 19 Nov 2004, Dave Cridland wrote:
>> It solves no problems, it adds complexity.
>> Adding complexity has a history of adding problems.
>> Therefore we cannot (or, if you prefer, should not) make this 
>> change.
>> What's there to understand? This isn't rocket science...
> 
> IMAP is a protocol which stipulates case-independence in its tokens 
> throughout.  Only data, such as message data or (optionally) 
> mailbox names are case-dependent, but even then INBOX is 
> case-independent.
> 
> ACL rights are an IMAP token.  The only reason why anyone ever 
> thought that they would be case-dependent was that the syntax rule 
> used was astring in order to avoid having to decide upon a syntax 
> for empty rights. This was a design mistake in 2086.  I have been 
> objecting to 2086's design mistakes repeatedly for many years.
> 
> Therefore, ACL rights are the only IMAP token which is 
> case-dependent. This solves no problems (the additional 26 rights 
> are not needed), it adds complexity.  Adding complexity has a 
> history of adding problems. Therefore we cannnot (or, if you 
> prefer, should not) make this change. What's there to understand?  
> This isn't rocket science...
> 
> 
I agree with all of that, which may surprise you.

It's an argument *against* RFC2086, however, and not an argument 
*for* changing it now.

In fact, the text you copied from my email stipulates "[...] make 
this change [...]". RFC2086 has *made* a change, a bad one I agree, 
but it's one we should live with until ACL2.

>> I've yet to see *any* technical argument for (a) here - lots of 
>> discussion about whether it's more in the "spirit of IMAP", etc. 
>> Nothing about whether it's actually a useful or sensible thing to 
>> do, especially in this specification.
> 
> The best way to ruin a technical specification is to ignore the 
> original spirit and graft on something that is totally foreign.
> 
> 
And again, I agree - RFC2086 wasn't a terribly good way of handling 
ACLs. It was under-specified, has a confusing array of rights, and is 
generally against the spirit of IMAP.

I can't stand many things about it, and this includes the way that 
rights are named right at the top of the list.

But the spirit of RFC2086 - in fact, more than that, the actual 
implementations - use a case-sensitive interpretation throughout. 

> C++ is an excellent example.
> 
> 
Well, I personally like the language, but I'll raise you Perl, 
although arguably that didn't have a spirit to be broken when OO was 
grafted on. Perhaps XLISP?

>>> Simply define that any 2086upd (and ACL2) compliant server MUST 
>>> have case-insensitive rights,...
>>> 	*AND*
>>> define that servers MUST send rights as lower case (MUST NOT send 
>>> rights
>>> as upper case)
>> The two above suggest that rights remain case-sensitive to all 
>> intents and purposes.
>> I fail to see any practical difference that this makes.
> 
> Not quite.  They establish the framework for the future.  In 
> particular, they instruct new implementations to read 
> case-insensitive, even though at present they must only send 
> lowercase.  Some time in the future, the latter part of the 
> previous sentence will be moot; nobody will use pre-2086upd servers 
> any more.
> 
> 
Nor will they use 2086upd servers either. As I understand things, 
2086upd is fully intended to be a stopgap until ACL2. Let's treat it 
like one.

>> However, do you honestly think that client authors will change 
>> their code to send uppercase rights? (I mean, discounting the 
>> kinds of authors who deliberately do weird things because they 
>> can.)
> 
> I don't think that; I *know* that.
> 
> 
Wait... You "know" client authors will actively edit their code and 
put in uppercase rights, then lowercase them for backwards 
compatibility with "pure" RFC2086 servers if/when they encounter them?

Why?

>> Now, on the contrary position, will there be new client authors 
>> who misunderstand, or simply fail to read, the specification, hear 
>> that "rights are case-insensitive", and break interoperability 
>> with older servers? I believe this will be the case - hence the 
>> reason why additional complexity tends to cause problems.
> 
> Pre-2086upd servers will rapidly become extinct, and clients will 
> be written that can only handle 2086upd.
> 
> Otherwise, there is no point to 2086upd, and this entire effort 
> should be abandoned as a waste of time.

It's not a waste of time - it clarifies 2086 enormously, sets down 
useful rules (rather than inferences) for what rights control what, 
and transitioning from 2086upd to ACL2 should prove much simpler.

And ACL2 is a total replacement, in effect. RFC2086 will die out, 
along with this specification too, and while there will be a 
compatibility option in most implementations, that's something that 
will fall out of use quite happily by itself.

The *only* thing we need to do to ensure that we can have 
case-insensitive rights in the future - should we want them, and not 
simply replace them with a much more IMAP-like syntax[*] - is to 
stress that rights are all lowercase - at least for now.

Banning them outright would be simpler:

The sentence beginning "Rights is a string listing..." in section 3 
gets replaced with "Rights is a string listing a (possibly empty) set 
of lower case US-ASCII letters and digits, each character listing a 
set of operations which is being controlled."

The ANBF gets adjusted accordingly to rule out uppercase rights.

That's a simple clarification of RFC2086, well within the scope of 
this draft, perfectly sensible, won't break anything even if misread, 
leaves all our options open.

Dave.
* - Think syntax like A002 ACL SET (INBOX Personal/*) user=Fred 
(\Read \Write \Insert \Seen \Deleted) - although I've not thought 
about a clearer syntax for the user=Fred ugliness, nor the flag names.

Date: Fri, 19 Nov 2004 10:33:40 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Lisa Dusseault <[email-masked]>
cc: Jutta Degener <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, [email-masked], Brian Candler <[email-masked]>, Alexey Melnikov <[email-masked]>, Dave Cridland <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

On Fri, 19 Nov 2004, Lisa Dusseault wrote:
> That's not the plan... the plan is to get 2086upd done quickly then get back 
> to ACL2.

That's what I had been led to believe.  Thank you Lisa for restating this.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Cc: Jutta Degener <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, [email-masked], Brian Candler <[email-masked]>, Alexey Melnikov <[email-masked]>, Dave Cridland <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Date: Fri, 19 Nov 2004 10:22:43 -0800
To: Mark Crispin <[email-masked]>
Sender: [email-masked]

That's not the plan... the plan is to get 2086upd done quickly then get 
back to ACL2.

lisa

On Nov 19, 2004, at 9:48 AM, Mark Crispin wrote:

>
> On Fri, 19 Nov 2004, Brian Candler wrote:
>> That's if I understand correctly: the ACL2 proposal is being dropped.
>
> Is ACL2 being dropped?
>
> I oppose that.
>
> -- Mark --
>
> http://staff.washington.edu/mrc
> Science does not emerge from voting, party politics, or public debate.
> Si vis pacem, para bellum.
>

Date: Fri, 19 Nov 2004 09:48:33 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Brian Candler <[email-masked]>
cc: Dave Cridland <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked], Jutta Degener <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

On Fri, 19 Nov 2004, Brian Candler wrote:
> That's if I understand correctly: the ACL2 proposal is being dropped.

Is ACL2 being dropped?

I oppose that.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Fri, 19 Nov 2004 17:19:01 +0000
From: Brian Candler <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Dave Cridland <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked], Jutta Degener <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

On Fri, Nov 19, 2004 at 08:41:53AM -0800, Mark Crispin wrote:
> Therefore, ACL rights are the only IMAP token which is case-dependent. 
> This solves no problems (the additional 26 rights are not needed), it 
> adds complexity.

I can't see any complexity with the one-to-one mapping of US-ASCII
characters to rights; a two-to-one mapping looks more complex to me. It adds
complexity in servers parsing commands, and clients parsing responses.

A server, after all, may not be able to lowercase the entire line which
comes in, so it still has to do this token by token. Mailbox names, apart
from [Ii][Nn][Bb][Oo][Xx], are permitted to be case-sensitive, but clients
have to be aware that they could also be case-insensitive. Now *that* added
a hell of a lot of complexity; with UTF-7 encoded Unicode mailbox names,
determining whether two characters are the same disregarding case is a
non-trivial task.

> >However, do you honestly think that client authors will change their code 
> >to send uppercase rights? (I mean, discounting the kinds of authors who 
> >deliberately do weird things because they can.)
> 
> I don't think that; I *know* that.

Sure, give them the option and at least one person will. But I don't see
what benefit would have accrued by giving them the ability to do so, when
you could just say that they can't.

> Pre-2086upd servers will rapidly become extinct, and clients will be 
> written that can only handle 2086upd.
> 
> Otherwise, there is no point to 2086upd, and this entire effort should be 
> abandoned as a waste of time.

I don't see the logic there. There clearly are things that are broken in rfc
2086 in the sense that they need clarifying - the rights needed to delete
mailboxes, for instance. Some or indeed most existing applications may
already behave "correctly", due to luck or telepathy in interpreting the
original interpretation, and therefore not need changing.

That's if I understand correctly: the ACL2 proposal is being dropped. *That*
would have been a replacement, leading to three types of clients/servers:
those that do ACL1, those that do ACL2, and those which do both.

Making 2086upd instead should leave the majority of existing 2086
implementations compliant with 2086upd; that is, in most cases they should
not need to be changed to become 2086upd compliant. Or am I misunderstanding
the thrust of the 2086upd concept?

Regards,

Brian.

Date: Fri, 19 Nov 2004 08:41:53 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, [email-masked], Jutta Degener <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

On Fri, 19 Nov 2004, Dave Cridland wrote:
> It solves no problems, it adds complexity.
> Adding complexity has a history of adding problems.
> Therefore we cannot (or, if you prefer, should not) make this change.
> What's there to understand? This isn't rocket science...

IMAP is a protocol which stipulates case-independence in its tokens 
throughout.  Only data, such as message data or (optionally) mailbox names 
are case-dependent, but even then INBOX is case-independent.

ACL rights are an IMAP token.  The only reason why anyone ever thought 
that they would be case-dependent was that the syntax rule used was 
astring in order to avoid having to decide upon a syntax for empty rights. 
This was a design mistake in 2086.  I have been objecting to 2086's design 
mistakes repeatedly for many years.

Therefore, ACL rights are the only IMAP token which is case-dependent. 
This solves no problems (the additional 26 rights are not needed), it 
adds complexity.  Adding complexity has a history of adding problems. 
Therefore we cannnot (or, if you prefer, should not) make this change. 
What's there to understand?  This isn't rocket science...

> I've yet to see *any* technical argument for (a) here - lots of discussion 
> about whether it's more in the "spirit of IMAP", etc. Nothing about whether 
> it's actually a useful or sensible thing to do, especially in this 
> specification.

The best way to ruin a technical specification is to ignore the original 
spirit and graft on something that is totally foreign.

C++ is an excellent example.

>> Simply define that any 2086upd (and ACL2) compliant server MUST have 
>> case-insensitive rights,...
>> 	*AND*
>> define that servers MUST send rights as lower case (MUST NOT send rights
>> as upper case)
> The two above suggest that rights remain case-sensitive to all intents and 
> purposes.
> I fail to see any practical difference that this makes.

Not quite.  They establish the framework for the future.  In particular, 
they instruct new implementations to read case-insensitive, even though at 
present they must only send lowercase.  Some time in the future, the 
latter part of the previous sentence will be moot; nobody will use 
pre-2086upd servers any more.

> However, do you honestly think that client authors will change their code to 
> send uppercase rights? (I mean, discounting the kinds of authors who 
> deliberately do weird things because they can.)

I don't think that; I *know* that.

> Now, on the contrary position, will there be new client authors who 
> misunderstand, or simply fail to read, the specification, hear that "rights 
> are case-insensitive", and break interoperability with older servers? I 
> believe this will be the case - hence the reason why additional complexity 
> tends to cause problems.

Pre-2086upd servers will rapidly become extinct, and clients will be 
written that can only handle 2086upd.

Otherwise, there is no point to 2086upd, and this entire effort should be 
abandoned as a waste of time.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

From: Dave Cridland <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, <[email-masked]>, Jutta Degener <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Date: Fri, 19 Nov 2004 16:05:10 +0000
Sender: [email-masked]

On Thu Nov 18 16:01:47 2004, Mark Crispin wrote:
> On Thu, 18 Nov 2004, Dave Cridland wrote:
>> Therefore, we cannot make rights case-insensitive. Any attempt to 
>> do so would appear to create more problems than it could possibly 
>> solve.
> 
> I don't understand why.
> 
> 
It solves no problems, it adds complexity.

Adding complexity has a history of adding problems.

Therefore we cannot (or, if you prefer, should not) make this change.

What's there to understand? This isn't rocket science...

> You identified that there is a problem that would be caused by an 
> abrupt transition.  So don't have an abrupt transition.  This isn't 
> rocket science; we know how to do this.
> 
> 
[As an aside, all abrupt transitions in protocols cause problems...]

Indeed - but there are two ways of avoiding an abrupt transition. 
Either:

a) Use some careful language in the specification, defining a set of 
rules by which there is, in effect, no transition apparent for 
innocent implementations.
b) Not have a transition at all.

(a) can be done - I appreciate that changes are possible, and indeed 
sometimes needed to further the protocol. The outlined rules you 
state do indeed provide this.

I think (b) has more technical merit in this circumstance, however. 
In fact, I've yet to see *any* technical argument for (a) here - lots 
of discussion about whether it's more in the "spirit of IMAP", etc. 
Nothing about whether it's actually a useful or sensible thing to do, 
especially in this specification.

> Simply define that any 2086upd (and ACL2) compliant server MUST 
> have case-insensitive rights,...
> 	*AND*
> define that servers MUST send rights as lower case (MUST NOT send 
> rights
> as upper case)

The two above suggest that rights remain case-sensitive to all 
intents and purposes.

I fail to see any practical difference that this makes. I see an 
aesthetic difference - we can now say "They're case-insensitive", but 
I don't see any *real* difference. This *is* adding complexity, to 
the language used if nothing else.

Case-insensitive means "upper and lower case are treated 
identically". This says "upper and lower case are treated 
identically, except that you can't use upper case". Some cases are 
less insensitive than others, if you like literary paraphrasing.

> 	*AND*
> define that clients MUST send rights as lower case (MUST NOT send 
> rights as upper case) to pre-2086upd servers.
> 
> If there is no way for a client to detect a pre-2086upd server, 
> then simply remove "to pre-2086upd servers" in the last part.
> 
> 
There is a way to detirmine if the server supports the extra rights, 
and, by inference, is RFC2086-upd or not, true.

However, do you honestly think that client authors will change their 
code to send uppercase rights? (I mean, discounting the kinds of 
authors who deliberately do weird things because they can.)

The only circumstance I can think of is clients which send XET rather 
than xet - the new rights being added as capitals. I can't really see 
this being an advantage to the author to do so, and I strongly 
suspect that all existent implementations of RFC2086 will use the 
lowercase characters for consistency anyway.

Now, on the contrary position, will there be new client authors who 
misunderstand, or simply fail to read, the specification, hear that 
"rights are case-insensitive", and break interoperability with older 
servers? I believe this will be the case - hence the reason why 
additional complexity tends to cause problems.

The interoperability break is particularly disturbing - it's a silent 
breakage in at least one widely deployed implementation, for example:

C: A01 SETACL INBOX foo lrS
S: A01 OK Completed
C: A02 GETACL INBOX
S: * ACL INBOX dwd lrswipcda foo lr
S: A02 OK Completed

> In ACL2, this can be removed entirely, at least for ACL2 only 
> software.
> 
> 
For ACL2, which is now a long way off, we can make different 
decisions.

It's worth reserving all uppercase rights in this specification to 
keep the options open.

>> lswiPda is currently treated by many clients and servers as lswida.
> 
> How many clients rely upon this behavior by sending lswiPda 
> assuming that the server will see it as lswida?

None, because P isn't a defined right. However, if we wave some 
mythical case-insensitivity at client authors, somebody somewhere 
*will* misread (or not read) this, and get very, very confused about 
why their rights aren't being set by the server. (Apologies for 
answering your rhetorical question.)

Dave.

Date: Thu, 18 Nov 2004 13:26:13 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, Jutta Degener <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

Hi Mark,

--On November 17, 2004 14:24:30 -0800 Mark Crispin <[email-masked]> 
wrote:

>> (Personally, I'd prefer case-*in*sensitivity - I have trouble
>> remembering which case meant what, why shouldn't other people;
>> but our implementations don't behave like that now.)
>
> This is my preference as well, and is consistant with the rest of IMAP.
>
> Unless there is an intent to use upper-case rights in the future to mean
> something different, would it be possible to transit to a case
> insensitive regime by stating that rights are case-insensitive, but that
> clients MUST send rights as lowercase?

My client will not recognize rights from a server if they are upper case, 
so the server would have to send lowercase rights as well to be backwards 
compatible, at which point the rights are effectively case sensitive.

WRT use of upper-case, I know at some point in the ACL2 debate we had 
talked about a simplified model of rights for 'simple' clients: e.g. 'RWX' 
style rights that would be tied in some well-defined way to the underlying 
lower case rights. So my feeling is we should reserve uppercase rights for 
now.

-- 
Cyrus Daboo

Date: Thu, 18 Nov 2004 18:00:56 +0000
From: Alexey Melnikov <[email-masked]>
To: Dave Cridland <[email-masked]>
CC: [email-masked]
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

Dave Cridland wrote:

>> Having said that I have to admit that I don't have a strong opinion 
>> on the issue. I would slightly prefere prohibiting uppercase rights - 
>> many existing clients will not treat them the same way as their 
>> lowercase counterparts.
>
> Indeed, Arnt has to start begging for mercy right now, it seems - 
> lswiPda is currently treated by many clients and servers as lswida.
>
> Cyrus IMAPd, 

Which is arguably a bug.

> as well as every client I've examined the source for (not many) ignore 
> unrecognised rights, which include all uppercase ones.

2086upd requires that all clients that can do SETACL preserve 
unrecognized rights.

For clients that only use GETACL/MYRIGHTS, it is ok to ignore 
unrecognized rights.

Date: Thu, 18 Nov 2004 17:49:02 +0000
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: Dave Cridland <[email-masked]>, [email-masked]
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

Mark Crispin wrote:

> On Thu, 18 Nov 2004, Dave Cridland wrote:
>
>> Therefore, we cannot make rights case-insensitive. Any attempt to do 
>> so would appear to create more problems than it could possibly solve.
>
> I don't understand why.
>
> You identified that there is a problem that would be caused by an 
> abrupt transition.  So don't have an abrupt transition.  This isn't 
> rocket science; we know how to do this.
>
> Simply define that any 2086upd (and ACL2) compliant server MUST have 
> case-insensitive rights,...
>     *AND*
> define that servers MUST send rights as lower case (MUST NOT send rights
> as upper case)
>     *AND*
> define that clients MUST send rights as lower case (MUST NOT send 
> rights as upper case) to pre-2086upd servers.

The 2086upd document defines a new capability, so we can do that. And 
the client will be able to detect pre-2086upd servers.

> If there is no way for a client to detect a pre-2086upd server, then 
> simply remove "to pre-2086upd servers" in the last part.
>
> In ACL2, this can be removed entirely, at least for ACL2 only software.

Yes.

Date: Thu, 18 Nov 2004 08:01:47 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, [email-masked], Jutta Degener <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

On Thu, 18 Nov 2004, Dave Cridland wrote:
> Therefore, we cannot make rights case-insensitive. Any attempt to do so would 
> appear to create more problems than it could possibly solve.

I don't understand why.

You identified that there is a problem that would be caused by an abrupt 
transition.  So don't have an abrupt transition.  This isn't rocket 
science; we know how to do this.

Simply define that any 2086upd (and ACL2) compliant server MUST have 
case-insensitive rights,...
 	*AND*
define that servers MUST send rights as lower case (MUST NOT send rights
as upper case)
 	*AND*
define that clients MUST send rights as lower case (MUST NOT send rights 
as upper case) to pre-2086upd servers.

If there is no way for a client to detect a pre-2086upd server, then 
simply remove "to pre-2086upd servers" in the last part.

In ACL2, this can be removed entirely, at least for ACL2 only software.

> lswiPda is currently treated by many clients and servers as lswida.

How many clients rely upon this behavior by sending lswiPda assuming that 
the server will see it as lswida?

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

From: Dave Cridland <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: <[email-masked]>, Jutta Degener <[email-masked]>, Mark Crispin <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Date: Thu, 18 Nov 2004 15:38:42 +0000
Sender: [email-masked]

On Thu Nov 18 13:19:25 2004, Alexey Melnikov wrote:
> Arnt Gulbrandsen wrote:
>> Mark Crispin writes:
>>> On Wed, 17 Nov 2004, Jutta Degener wrote:
>>> 
>>>> (Personally, I'd prefer case-*in*sensitivity - I have trouble 
>>>> remembering which case meant what, why shouldn't other people; 
>>>> but our implementations don't behave like that now.)
>>> 
>>> This is my preference as well, and is consistant with the rest of 
>>> IMAP.
>>> 
>>> Unless there is an intent to use upper-case rights in the future 
>>> to mean something different, would it be possible to transit to a 
>>> case insensitive regime by stating that rights are 
>>> case-insensitive, but that clients MUST send rights as lowercase?
>> 
>> 
>> I strongly agree. It's hard enough to remember lswipda, if lswiPda 
>> were someday to be different I'd have to beg for mercy. Mark's 
>> suggestion is a good way forward, IMO.
> 
> I remember we were using "S" as as an example, i.e. "s" controls 
> the private \Seen and "S" might control the shared \Seen flag.
> So if we are going to allow for upper case rights, they have to be 
> somehow related to the corresponding lowercase ones.
> 
> 
That seems fair, though we'd have to try to ensure that they followed 
the same relationship where possible, hence "n" would become "N", and 
"m" would become "n".

I'm not fussed on using uppercase rights at all, though.

> Having said that I have to admit that I don't have a strong opinion 
> on the issue. I would slightly prefere prohibiting uppercase rights 
> - many existing clients will not treat them the same way as their 
> lowercase counterparts.

Indeed, Arnt has to start begging for mercy right now, it seems - 
lswiPda is currently treated by many clients and servers as lswida.

Cyrus IMAPd, as well as every client I've examined the source for 
(not many) ignore unrecognised rights, which include all uppercase 
ones.

They all appear to transform the rights string into a bitfield using 
code very similar to:

{
	char * p( rights ); /* assuming rights is a char * */
	unsigned rights_bitfield( 0 );
	while( *p ) {
		switch( *p ) {
		case 'a':
			rights_bitfield |= IMAP_ACL_ADMIN;
			break;
		/* etc, without a default: */
		}
	}
}

Hence unknown rights are completely ignored (good for clients, not so 
sure this is correct for a server) and this includes uppercase rights.

Therefore, we cannot make rights case-insensitive. Any attempt to do 
so would appear to create more problems than it could possibly solve.

Dave.

Date: Thu, 18 Nov 2004 13:19:25 +0000
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked], Jutta Degener <[email-masked]>, Mark Crispin <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Mark Crispin writes:
>
>> On Wed, 17 Nov 2004, Jutta Degener wrote:
>>
>>> (Personally, I'd prefer case-*in*sensitivity - I have trouble 
>>> remembering which case meant what, why shouldn't other people; but 
>>> our implementations don't behave like that now.)
>>
>> This is my preference as well, and is consistant with the rest of IMAP.
>>
>> Unless there is an intent to use upper-case rights in the future to 
>> mean something different, would it be possible to transit to a case 
>> insensitive regime by stating that rights are case-insensitive, but 
>> that clients MUST send rights as lowercase?
>
>
> I strongly agree. It's hard enough to remember lswipda, if lswiPda 
> were someday to be different I'd have to beg for mercy. Mark's 
> suggestion is a good way forward, IMO.

I remember we were using "S" as as an example, i.e. "s" controls the 
private \Seen and "S" might control the shared \Seen flag.
So if we are going to allow for upper case rights, they have to be 
somehow related to the corresponding lowercase ones.

Having said that I have to admit that I don't have a strong opinion on 
the issue. I would slightly prefere prohibiting uppercase rights - many 
existing clients will not treat them the same way as their lowercase 
counterparts.

Alexey

Date: Thu, 18 Nov 2004 13:16:37 +0000
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Lyndon Nerenberg writes:
>
>> Just to be Devil's Advocate:
>>
>> 1) Are we sure 36 rights will be enough?
>
> Viewed from an i14y/testing viewpoint, 36 rights is Too Much. If the 
> standard ever becomes that complex and finegrained, then IMO, even 
> sane and reasonable client developers may develop specifically for the 
> two most common servers.

I agree that 36 rights is too much.

Date: Thu, 18 Nov 2004 12:05:05 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Cc: Lyndon Nerenberg <[email-masked]>, Jutta Degener <[email-masked]>, Mark Crispin <[email-masked]>
Sender: [email-masked]

Lyndon Nerenberg writes:
> Just to be Devil's Advocate:
>
> 1) Are we sure 36 rights will be enough?

Viewed from an i14y/testing viewpoint, 36 rights is Too Much. If the 
standard ever becomes that complex and finegrained, then IMO, even sane 
and reasonable client developers may develop specifically for the two 
most common servers.

Arnt

Date: Thu, 18 Nov 2004 11:59:45 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Cc: Jutta Degener <[email-masked]>, Mark Crispin <[email-masked]>
Sender: [email-masked]

Mark Crispin writes:
> On Wed, 17 Nov 2004, Jutta Degener wrote:
>> (Personally, I'd prefer case-*in*sensitivity - I have trouble 
>> remembering which case meant what, why shouldn't other people; but 
>> our implementations don't behave like that now.)
>
> This is my preference as well, and is consistant with the rest of IMAP.
>
> Unless there is an intent to use upper-case rights in the future to 
> mean something different, would it be possible to transit to a case 
> insensitive regime by stating that rights are case-insensitive, but 
> that clients MUST send rights as lowercase?

I strongly agree. It's hard enough to remember lswipda, if lswiPda were 
someday to be different I'd have to beg for mercy. Mark's suggestion is 
a good way forward, IMO.

Arnt

From: Dave Cridland <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>, Alexey Melnikov <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Date: Thu, 18 Nov 2004 10:01:07 +0000
Sender: [email-masked]

On Wed Nov 17 20:43:07 2004, Cyrus Daboo wrote:
> --On November 17, 2004 20:27:35 +0000 Alexey Melnikov 
> <[email-masked]> wrote:
> 
>>> Leave it the same as 2086 (original), but perhaps call extra 
>>> attention
>>> to the fact that it is case-sensitive.
>> 
>> RFC 2086 was silent on the issue. I believe the intention was to 
>> make
>> rights case-sensitive.
> 
> OK, well I guess we will have to find out what real implementations 
> did and make sure it is clear in 2086upd which way it should be. I 
> can tell you that my implementation treats the rights as 
> case-sensitive.

I can tell you that Mutt and Mozilla Mail/News also both appear to 
treat rights as case-sensitive. I could be wrong, but it looks that 
way. I can't tell you what the server implementations do, although I 
know Cyrus IMAPd just ignores any unknown rights, including 
upper-case ones.

I strongly suspect that everything treats them as case-sensitive.

Dave.

From: Dave Cridland <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>, Mark Crispin <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Date: Thu, 18 Nov 2004 09:17:42 +0000
Sender: [email-masked]

On Thu Nov 18 02:18:55 2004, Lyndon Nerenberg wrote:
> 
> --On 2004-11-17 5:58 PM -0800 Mark Crispin <[email-masked]> 
> wrote:
> 
>> If we aren't certain, is it a mistake to have single-character 
>> rights?
> 
> Not if they are UTF-8 characters :-P
> 
> 
Rights are defined in 2086 as US-ASCII.

Nice try, though. :-)

Dave.

Date: Wed, 17 Nov 2004 18:18:55 -0800
From: Lyndon Nerenberg <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

--On 2004-11-17 5:58 PM -0800 Mark Crispin <[email-masked]> 
wrote:

> If we aren't certain, is it a mistake to have single-character rights?

Not if they are UTF-8 characters :-P

> I agree that, because 2086 rights are an <astring>, IMAP's case
> folding rules do not require 2806 rights to be case insensitive.  I
> disagree with your conclusion that they are required to be case
> sensitive.  I consider IMAP to be silent on this point.

But I defer to ABNF, where everything is case-sensitive unless 
explicitly stated otherwise. (Yes, ACL predates ABNF spec.)

No matter, I'm just issuing a heads-up. I won't go non-linear if 
case-folding is the consensus.

--lyndon

Date: Wed, 17 Nov 2004 17:58:50 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>
cc: Jutta Degener <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Wed, 17 Nov 2004, Lyndon Nerenberg wrote:
> 1) Are we sure 36 rights will be enough?

I don't know.  Are we?

If we aren't certain, is it a mistake to have single-character rights?

> 2) <astring> is not case-folded. Since <rights> are an <astring> I would 
> argue that <rights> MUST be case sensitive. (Nothing in 2086 calls out for 
> case-folding, therefore it cannot be assumed by any conforming 
> implementation.)

I agree that, because 2086 rights are an <astring>, IMAP's case folding 
rules do not require 2806 rights to be case insensitive.  I disagree with 
your conclusion that they are required to be case sensitive.  I consider 
IMAP to be silent on this point.

However, as the original architect of IMAP, I consider it to be a mistake 
that rights are an astring as opposed to an atom equivalent.  That is, I 
think that it would have been closer to the "spirit of IMAP" if it were 
something like:

    mod_rights      ::= ["+" / "-"] rights

    rights          ::= 1*right / "-"

    right           ::= ALPHA / DIGIT
                          ; Case-insensitive

where "-" means "empty rights", or (if 36 rights aren't enough):

    rights          ::= 1*right / nil

    right           ::= atom

In fact, if it weren't for the "chattiness" objections that are commonly 
made about IMAP, I would consider the latter to be the True IMAP Way.

However, I am just mumbling here.  I am not seriously suggesting that it 
be changed at this late date, so everybody please lower your hackles... 
:-)

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Wed, 17 Nov 2004 17:40:29 -0800
From: Lyndon Nerenberg <[email-masked]>
To: Mark Crispin <[email-masked]>, Jutta Degener <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

--On 2004-11-17 2:24 PM -0800 Mark Crispin <[email-masked]> 
wrote:

> Unless there is an intent to use upper-case rights in the future to
> mean something different, would it be possible to transit to a case
> insensitive regime by stating that rights are case-insensitive, but
> that clients MUST send rights as lowercase?

Just to be Devil's Advocate:

1) Are we sure 36 rights will be enough?

2) <astring> is not case-folded. Since <rights> are an <astring> I 
would argue that <rights> MUST be case sensitive. (Nothing in 2086 
calls out for case-folding, therefore it cannot be assumed by any 
conforming implementation.)

--lyndon

Date: Wed, 17 Nov 2004 14:24:30 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Jutta Degener <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Wed, 17 Nov 2004, Jutta Degener wrote:
> (Personally, I'd prefer case-*in*sensitivity - I have trouble
> remembering which case meant what, why shouldn't other people;
> but our implementations don't behave like that now.)

This is my preference as well, and is consistant with the rest of IMAP.

Unless there is an intent to use upper-case rights in the future to mean 
something different, would it be possible to transit to a case insensitive 
regime by stating that rights are case-insensitive, but that clients MUST 
send rights as lowercase?

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Wed, 17 Nov 2004 14:16:10 -0800
From: Jutta Degener <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

On Wed, Nov 17, 2004 at 03:43:07PM -0500, Cyrus Daboo wrote:
> OK, well I guess we will have to find out what real implementations did and 
> make sure it is clear in 2086upd which way it should be. I can tell you 
> that my implementation treats the rights as case-sensitive.

Sendmail's does, too.

(Personally, I'd prefer case-*in*sensitivity - I have trouble 
remembering which case meant what, why shouldn't other people;
but our implementations don't behave like that now.)

Jutta Degener <[email-masked]>

Date: Wed, 17 Nov 2004 15:43:07 -0500
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

Hi Alexey,

--On November 17, 2004 20:27:35 +0000 Alexey Melnikov 
<[email-masked]> wrote:

>> Leave it the same as 2086 (original), but perhaps call extra attention
>> to the fact that it is case-sensitive.
>
> RFC 2086 was silent on the issue. I believe the intention was to make
> rights case-sensitive.

OK, well I guess we will have to find out what real implementations did and 
make sure it is clear in 2086upd which way it should be. I can tell you 
that my implementation treats the rights as case-sensitive.

-- 
Cyrus Daboo

Date: Wed, 17 Nov 2004 20:27:35 +0000
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

Cyrus Daboo wrote:

> Hi Alexey,
>
> --On November 17, 2004 19:10:16 +0000 Alexey Melnikov 
> <[email-masked]> wrote:
>
>> The document says that all rights are case-sensitive, i.e. "r" is not 
>> the
>> same as "R". Is this is problem?
>> Currently there are not uppercase rights assigned.
>
> Leave it the same as 2086 (original), but perhaps call extra attention 
> to the fact that it is case-sensitive.

RFC 2086 was silent on the issue. I believe the intention was to make 
rights case-sensitive.

Date: Wed, 17 Nov 2004 15:25:26 -0500
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

Hi Alexey,

--On November 17, 2004 19:10:16 +0000 Alexey Melnikov 
<[email-masked]> wrote:

> The document says that all rights are case-sensitive, i.e. "r" is not the
> same as "R". Is this is problem?
> Currently there are not uppercase rights assigned.

Leave it the same as 2086 (original), but perhaps call extra attention to 
the fact that it is case-sensitive.

-- 
Cyrus Daboo

Date: Wed, 17 Nov 2004 19:10:16 +0000
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: One remaining issue in draft-ietf-imapext-2086upd-01.txt
Sender: [email-masked]

The document says that all rights are case-sensitive, i.e. "r" is not 
the same as "R". Is this is problem?
Currently there are not uppercase rights assigned.

Date: Wed, 17 Nov 2004 18:11:20 +0000
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: 2086upd + ANNOTATE dependency
Sender: [email-masked]

Ken Murchison wrote:

> Cyrus Daboo wrote:
>
>> What I propose is to remove all references to ANNOTATE in 2086upd. 
>> The ANNOTATE document will define the new ACL bits and have a 
>> normative reference to 2086upd. That way 2086upd can progress quickly 
>> without being blocked on ANNOTATE (which itself is blocked on 
>> SORT/THREAD/i18n).
>
> Agreed.

If we are going this route, the ANNOTATE document must be updated to say 
that the "n" right (writing shared annotations) is a part of the "shared 
flag rights" as defined in section 5.2 of the 2086upd ("Mapping of ACL 
rights to READ-WRITE and READ-ONLY response codes").

From: Dave Cridland <[email-masked]>
To: Ken Murchison <[email-masked]>
Cc: Brian Candler <[email-masked]>, Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>, Philip Guenther <[email-masked]>
Subject: Re: Updated draft-ietf-imapext-2086upd (ACL)
Date: Wed, 17 Nov 2004 14:12:06 +0000
Sender: [email-masked]

On Mon Nov 15 20:27:02 2004, Ken Murchison wrote:
> Interop with both old and new clients will be a problem.  I don't 
> have all of the answers yet, I'd have to discuss this with the 
> other Cyrus guys to see if we can work out a solution.  I'm just 
> pointing out that the current wording in the draft doesn't work 
> with all implementations.

My initial thought was that you'd be right, for two reasons:

1) Client authors may have independently made the same interpretation.
2) Client authors may have deliberately copied Cyrus IMAPd's 
interpretation, given that it's a widely known and used RFC2086 
server implementation.

To see if this was the case, I decided to read through several IMAP 
client implementations. My overall assumption was that open-sourced 
implementations would be most likely to show (2) above, and hence 
would be visible and a reasonable sample.

I looked for two key features of the code:

a) A suppression of the UI for folder deletion based on MYRIGHTS 
output.
b) A suppression of actual deletion based on MYRIGHTS output.

I read through the source code for Balsa, Mutt, and Mozilla.

I have found no evidence for either happening.

I'm also told that Evolution doesn't support RFC2086 at all.

Documentation for APIs, however, suggests differently.

Both Sun's JavaMail documentation and perl's IMAP::Admin module 
documentation makes the claim that the "c" right allows for DELETE 
(and RENAME) on submailboxes.

Communigate Pro's documentation states that deleting a mailbox 
requires both the "c" right on the parent *and* the "d" right on the 
mailbox itself.

Incidentally, Cyrus's major problem is that the "x" right needs to be 
granted, as I understand it, on all submailboxes of a parent which 
has the "c" right - "c" cannot therefore be a macro for "kx", where 
"k" is for CREATE (and is the current "c").

I have no real conclusions about this - I'd be interested in knowing 
what any other clients are doing.

My general feeling is that the current draft can stand, but I'd 
appreciate knowing a little more about other implementations.

Dave.

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-2086upd-01.txt
Date: Tue, 16 Nov 2004 16:13:24 -0500
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 - updated list of rights
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-imapext-2086upd-01.txt
	Pages		: 0
	Date		: 2004-11-16
	
The ACL (Access Control List) extension [RFC2086] of the Internet Message
Access Protocol [IMAP4] permits mailbox access control lists to be
manipulated through the IMAP protocol.

This document updates the list of rights defined in RFC 2086. It
also clarifies which rights are required for different IMAP commands.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-2086upd-01.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-2086upd-01.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-2086upd-01.txt

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

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

--OtherAccess--

--NextPart--

Date: Mon, 15 Nov 2004 22:37:03 +0000
From: Brian Candler <[email-masked]>
To: Ken Murchison <[email-masked]>
Cc: Philip Guenther <[email-masked]>, Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Updated draft-ietf-imapext-2086upd (ACL)
Sender: [email-masked]

On Mon, Nov 15, 2004 at 03:27:02PM -0500, Ken Murchison wrote:
> >So, would
> >there be any way at all for the user of an old client to set or clear
> >the "x" right?  If setting or clearing the "c" right was to also affect
> >the "x" right then how would a new (RIGHTS-aware) client set or clear
> >the "c" right without affecting the "x" right?
> 
> Interop with both old and new clients will be a problem.  I don't have 
> all of the answers yet, I'd have to discuss this with the other Cyrus 
> guys to see if we can work out a solution.  I'm just pointing out that 
> the current wording in the draft doesn't work with all implementations.
> 
> One easy way to do this might be to make 'c' a macro in the new draft 
> just like 'd' and create a new bit for CREATE (e.g. 'k')  Then the 
> mapping would be:
> 
> Cyrus:  'c' -> "kx", 'd' -> "te"
> Others: 'c' -> "k",  'd' -> "xte"

Would it be a problem to make 'd' more permissive? Let me think aloud.

For example: imagine for a moment that c and x are tied (which is in effect
the current behaviour of Cyrus, IIUC)

Now, suppose we defined the 'd' right as implying e,t,x plus any rights tied
to those rights. Then if a client asked for 'd' they would get e+t+x+c.

Now: a client which asks for 'd' (intending "delete or expunge mail") will
find themselves also getting create submailbox and delete mailbox rights. I
don't know if Cyrus has any policy engine which lets you control which
rights requests are granted or refused; if it doesn't, then the worst that
will happen is that the person administering the ACL will end up adding more
rights to a particular user than they intended. And that will only happen if
the software used to set up the ACL only understands RFC2086 flags.

So what am I proposing? Maybe that the 'd' flag implies 'e','t','x' plus any
other flags that the implementation considers necessary. Or maybe that the
'd' flag implies *any* implementation-defined set of flags, but where the
recommended set is 'e','t' and 'x'; the goal being that the virtual 'd' flag
implies whatever set of flags is necessary so that the client has no fewer
rights than they would have had before when asking for 'd'. That's fine;
then the problem with Cyrus is that if you ask for 'c', you still get fewer
rights than you would have had before when asking for 'c'. If the client
understand RFC-2086upd then it can ask for 'x'; if not then it can ask for
'd', although it will end up with perhaps more rights than are needed.

Of course, if you are migrating from Cyrus version X (RFC-2086) to version Y
(RFC-2086upd), then any existing mailbox rights can be changed as part of
this migration. i.e. c becomes cx, d becomes xte. So this will only really
affect *ACL administrators* who are using *RFC-2086 clients* which also *do
not use LISTRIGHTS* to present the possible rights available to the
end-user.

Oh well, enough thinking aloud, as I don't seem to be getting very far :-)

Regards,

Brian.

Date: Mon, 15 Nov 2004 15:27:02 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Philip Guenther <[email-masked]>
CC: Brian Candler <[email-masked]>, Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Updated draft-ietf-imapext-2086upd (ACL)
Sender: [email-masked]

Philip Guenther wrote:

> Ken Murchison <[email-masked]> writes:
> ...
> 
>>>The difference would be that the client would be required to request both
>>>"c" and "x" in order to set this bit; but it would know that is necessary if
>>>it made use of the LISTRIGHTS information which indicated they were tied.
>>
>>We don't want to do this.  Spitting 'x' from 'c' is a migration issue 
>>specific to Cyrus, which we will have to handle.    As soon as we 
>>implement this update any existing ACL which has "c" will have to be 
>>reported as "cx".  The 'x' right will then have to be explicitly removed.
> 
> 
> ...if they don't want the user to have both rights but only create.
> 
> ...
> 
>>My problem is that the draft assumes that 'x' is a "sub-ACL" of 'd', 
>>which is not the case in Cyrus.  If a user sets 'd' in Cyrus, the server 
>>shouldn't have to set 'x' (because the draft says MUST) if it doesn't 
>>apply.  I have no problem with 'd' being a macro for 'e' and 't', but 
>>whether this macro also includes 'd' should be implementation specific.
> 
> 
> So you're proposing that an implementation (Cyrus) be allowed to not
> set/clear the "x" right when the "d" right is set/cleared.

Yes.  The draft makes the false assumption that *all* existing 
implementations use the 'd' right to control DELETE.  Cyrus made the 
decision a while back to separate mailbox ops (DELETE) from message ops 
(\Deleted and EXPUNGE).  Its unfortunate that RFC 2086 was 
vague/ambiguous w.r.t. DELETE.

> So, would
> there be any way at all for the user of an old client to set or clear
> the "x" right?  If setting or clearing the "c" right was to also affect
> the "x" right then how would a new (RIGHTS-aware) client set or clear
> the "c" right without affecting the "x" right?

Interop with both old and new clients will be a problem.  I don't have 
all of the answers yet, I'd have to discuss this with the other Cyrus 
guys to see if we can work out a solution.  I'm just pointing out that 
the current wording in the draft doesn't work with all implementations.

One easy way to do this might be to make 'c' a macro in the new draft 
just like 'd' and create a new bit for CREATE (e.g. 'k')  Then the 
mapping would be:

Cyrus:  'c' -> "kx", 'd' -> "te"
Others: 'c' -> "k",  'd' -> "xte"

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

To: Ken Murchison <[email-masked]>
Cc: Brian Candler <[email-masked]>, Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Updated draft-ietf-imapext-2086upd (ACL) 
Date: Mon, 15 Nov 2004 11:57:15 -0800
From: Philip Guenther <[email-masked]>
Sender: [email-masked]

Ken Murchison <[email-masked]> writes:
...
>> The difference would be that the client would be required to request both
>> "c" and "x" in order to set this bit; but it would know that is necessary if
>> it made use of the LISTRIGHTS information which indicated they were tied.
>
>We don't want to do this.  Spitting 'x' from 'c' is a migration issue 
>specific to Cyrus, which we will have to handle.    As soon as we 
>implement this update any existing ACL which has "c" will have to be 
>reported as "cx".  The 'x' right will then have to be explicitly removed.

...if they don't want the user to have both rights but only create.

...
>My problem is that the draft assumes that 'x' is a "sub-ACL" of 'd', 
>which is not the case in Cyrus.  If a user sets 'd' in Cyrus, the server 
>shouldn't have to set 'x' (because the draft says MUST) if it doesn't 
>apply.  I have no problem with 'd' being a macro for 'e' and 't', but 
>whether this macro also includes 'd' should be implementation specific.

So you're proposing that an implementation (Cyrus) be allowed to not
set/clear the "x" right when the "d" right is set/cleared.  So, would
there be any way at all for the user of an old client to set or clear
the "x" right?  If setting or clearing the "c" right was to also affect
the "x" right then how would a new (RIGHTS-aware) client set or clear
the "c" right without affecting the "x" right?

Philip Guenther

Date: Mon, 15 Nov 2004 14:21:20 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Brian Candler <[email-masked]>
CC: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Updated draft-ietf-imapext-2086upd (ACL)
Sender: [email-masked]

Brian Candler wrote:

> On Mon, Nov 15, 2004 at 12:45:46PM -0500, Ken Murchison wrote:
> 
>>I think we need to add language that says that 'x' must be associated 
>>with whichever ACL bit was previously used for DELETE, and not assume 
>>that its 'd'.
> 
> 
> I'm not sure there is a problem, because RFC2086 explicitly allows the
> server to tie together whichever bits it likes in whichever way is
> convenient to it:
> 
>    An implementation may tie rights together or may force rights to
>    always or never be granted to particular identifiers.  For example,
>    in an implementation that uses unix mode bits, the rights "wisd" are
>    tied, the "a" right is always granted to the owner of a mailbox and
>    is never granted to another user.  If rights are tied in an
>    implementation, the implementation must be conservative in granting
>    rights in response to SETACL commands--unless all rights in a tied
>    set are specified, none of that set should be included in the ACL
>    entry for that identifier.  A client may discover the set of rights
>    which may be granted to a given identifier in the ACL for a given
>    mailbox by using the LISTRIGHTS command.

I'm fully aware of this, but we don't want to tie any rights together. 
That's the whole point of the new specs.

> So in Cyrus you can have a single bit internally, which (if set) is reported
> to the client as "cx".

We already have one and its 'c'.

> The difference would be that the client would be required to request both
> "c" and "x" in order to set this bit; but it would know that is necessary if
> it made use of the LISTRIGHTS information which indicated they were tied.

We don't want to do this.  Spitting 'x' from 'c' is a migration issue 
specific to Cyrus, which we will have to handle.    As soon as we 
implement this update any existing ACL which has "c" will have to be 
reported as "cx".  The 'x' right will then have to be explicitly removed.

> Now, "d" being an alias for e+t+x is a bit of a special case. But at least
> it is a single, well-defined special case; and also note that "d" is not a
> real bit in its own right, but a virtual bit synthesised from (e && t && x).
> I can't see a clean way to do what you seem to be suggesting, which is to
> associate "x" with another bit, apart from the mechanism which is already
> there which allows bits to be tied together.
> 
> Can you be more specific on what you are proposing?

My problem is that the draft assumes that 'x' is a "sub-ACL" of 'd', 
which is not the case in Cyrus.  If a user sets 'd' in Cyrus, the server 
shouldn't have to set 'x' (because the draft says MUST) if it doesn't 
apply.  I have no problem with 'd' being a macro for 'e' and 't', but 
whether this macro also includes 'd' should be implementation specific.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Mon, 15 Nov 2004 13:52:53 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: 2086upd + ANNOTATE dependency
Sender: [email-masked]

Cyrus Daboo wrote:

> What I propose is to remove all references to ANNOTATE in 2086upd. The 
> ANNOTATE document will define the new ACL bits and have a normative 
> reference to 2086upd. That way 2086upd can progress quickly without 
> being blocked on ANNOTATE (which itself is blocked on SORT/THREAD/i18n).

Agreed.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Mon, 15 Nov 2004 18:32:22 +0000
From: Brian Candler <[email-masked]>
To: Ken Murchison <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Updated draft-ietf-imapext-2086upd (ACL)
Sender: [email-masked]

On Mon, Nov 15, 2004 at 12:45:46PM -0500, Ken Murchison wrote:
> I think we need to add language that says that 'x' must be associated 
> with whichever ACL bit was previously used for DELETE, and not assume 
> that its 'd'.

I'm not sure there is a problem, because RFC2086 explicitly allows the
server to tie together whichever bits it likes in whichever way is
convenient to it:

   An implementation may tie rights together or may force rights to
   always or never be granted to particular identifiers.  For example,
   in an implementation that uses unix mode bits, the rights "wisd" are
   tied, the "a" right is always granted to the owner of a mailbox and
   is never granted to another user.  If rights are tied in an
   implementation, the implementation must be conservative in granting
   rights in response to SETACL commands--unless all rights in a tied
   set are specified, none of that set should be included in the ACL
   entry for that identifier.  A client may discover the set of rights
   which may be granted to a given identifier in the ACL for a given
   mailbox by using the LISTRIGHTS command.

So in Cyrus you can have a single bit internally, which (if set) is reported
to the client as "cx".

The difference would be that the client would be required to request both
"c" and "x" in order to set this bit; but it would know that is necessary if
it made use of the LISTRIGHTS information which indicated they were tied.

Now, "d" being an alias for e+t+x is a bit of a special case. But at least
it is a single, well-defined special case; and also note that "d" is not a
real bit in its own right, but a virtual bit synthesised from (e && t && x).
I can't see a clean way to do what you seem to be suggesting, which is to
associate "x" with another bit, apart from the mechanism which is already
there which allows bits to be tied together.

Can you be more specific on what you are proposing?

Regards,

Brian.

Date: Mon, 15 Nov 2004 12:47:31 -0500
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: 2086upd + ANNOTATE dependency
Sender: [email-masked]

Should 2086upd mention ANNOTATE at all? Right now it does define the 'n' 
right but has very little to say about it, other than providing the 
informative reference to ANNOTATE. That reference really ought to be 
normative since the meaning of 'n' (and 'm') are important. However, this 
adds a two-way dependency between 2086upd and ANNOTATE.

What I propose is to remove all references to ANNOTATE in 2086upd. The 
ANNOTATE document will define the new ACL bits and have a normative 
reference to 2086upd. That way 2086upd can progress quickly without being 
blocked on ANNOTATE (which itself is blocked on SORT/THREAD/i18n).

-- 
Cyrus Daboo

Date: Mon, 15 Nov 2004 12:45:46 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Alexey Melnikov <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Updated draft-ietf-imapext-2086upd (ACL)
Sender: [email-masked]

I just noticed something in this draft, and ACL2 for that matter, which 
may cause problems with Cyrus.  The draft seems to assume that the old 
'd' right was used to allow the DELETE command, where RFC 2086 was vague 
on this (in fact it never mentions DELETE or RENAME).  All current Cyrus 
code uses the 'c' right for both CREATE and DELETE.  So for Cyrus, 
associating the new 'x' right with 'd' doesn't make any sense, it would 
probably be associated with 'c'.

I think we need to add language that says that 'x' must be associated 
with whichever ACL bit was previously used for DELETE, and not assume 
that its 'd'.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Mon, 15 Nov 2004 12:08:13 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: IMAP Extensions WG <[email-masked]>
CC: Alexey Melnikov <[email-masked]>
Subject: Re: Outstanding issues for draft-ietf-imapext-2086upd-00 (ACL)
Sender: [email-masked]

Dave Cridland wrote:
> 
> On Mon Nov 15 12:45:30 2004, Alexey Melnikov wrote:
> 
>> Alexey Melnikov wrote:
>>
>>> The second issue:
>>>
>>> Which rights are required for the LISTRIGHTS command?
>>>
>>> Currently the document says:
>>>
>>>    MYRIGHTS - any of the following rights is required to perform
>>>     the operation: "l", "r", "i", "c", "x", "a".*
>>>
>>>    LISTRIGHTS - same as MYRIGHTS.
>>>
>>> Some of the existing servers follow this suggestion. Some allow for
>>> LISTRIGHTS if "r" and/or "a" is granted.
>>>
>>> Philip has suggested (and I agree) to only allow LISTRIGHTS when the "a"
>>> right is granted, as LISTRIGHTS information is only useful
>>> if you can also do SETACL. Also, such information shouldn't be disclosed
>>> to users that have insufficient rights.
>>
>>
>> So, any comments on changing LISTRIGHTS to require the "a" right?
> 
> 
> As a client implementor of sorts, I can't see any reason for using 
> LISTRIGHTS if I didn't intend to use the results to frame a SETACL or 
> DELETEACL.
> 
> Hence I'm in agreement - make it require "a".

I'm also in agreement.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Mon, 15 Nov 2004 16:51:39 +0000
From: Alexey Melnikov <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: [email-masked]
Subject: Re: Clarification of "d" right in imapext-acl
Sender: [email-masked]

Philip Guenther wrote:

>Alexey Melnikov <[email-masked]> writes:
>  
>
>>Philip Guenther wrote:
>>    
>>
>>>Please review the 2086upd draft as soon as possible, as it should be
>>>going to working group last call Real Soon Now.  Only one substantive
>>>change was discussed at the IETF meeting last week: instead of returning
>>>a MYRIGHTS response, the SELECT command should return a MYRIGHTS
>>>response _code_.  So, for example, this line from the SELECT example in
>>>section 7.1.1:
>>>              S: * MYRIGHTS INBOX rwis
>>>will end up instead reading:
>>>              S: * OK [MYRIGHTS INBOX rwis] Blah blah your rights
>>>      
>>>
>>The ACL2 document defines MYRIGHTS response code, but it doesn't include 
>>a mailbox name. Is it Ok?
>>    
>>
>
>So it should instead read:
>                 S: * OK [MYRIGHTS rwis] No more, no less
>
>
>The Formal Syntax needs to define the syntax for that as an extension of
>resp-text-code:
>
>resp-text-code  =/ myrights_rspcod
>
>myrights_rspcod = "MYRIGHTS" SP rights
>
>rights          = atom
>                   ;; MUST NOT contain leading "+" or "-"
>                   ;; MUST be treated as case-sensitive
>
>Hmm, interesting: ACL2 used 'quoted' instead of 'atom' for rights.
>Since a non-ATOM-CHAR right can't appear in the RIGHT=... capability, no
>point in allowing them here in the MYRIGHTS response code.
>  
>
I agree.

>The UTF-8 reference should be updated the RFC 3629.
>
Done.

>It should be noted
>somewhere that an identifier containing non-US-ASCII characters MUST be
>represented as a literal and not a quoted-string or atom.
>  
>
This just follows from rules for literals defined in RFC 3501.

From: Dave Cridland <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Outstanding issues for draft-ietf-imapext-2086upd-00 (ACL)
Date: Mon, 15 Nov 2004 16:44:33 +0000
Sender: [email-masked]

On Mon Nov 15 12:45:30 2004, Alexey Melnikov wrote:
> Alexey Melnikov wrote:
>> The second issue:
>> 
>> Which rights are required for the LISTRIGHTS command?
>> 
>> Currently the document says:
>> 
>>    MYRIGHTS - any of the following rights is required to perform
>>     the operation: "l", "r", "i", "c", "x", "a".*
>> 
>>    LISTRIGHTS - same as MYRIGHTS.
>> 
>> Some of the existing servers follow this suggestion. Some allow for
>> LISTRIGHTS if "r" and/or "a" is granted.
>> 
>> Philip has suggested (and I agree) to only allow LISTRIGHTS when 
>> the "a"
>> right is granted, as LISTRIGHTS information is only useful
>> if you can also do SETACL. Also, such information shouldn't be 
>> disclosed
>> to users that have insufficient rights.
> 
> So, any comments on changing LISTRIGHTS to require the "a" right?

As a client implementor of sorts, I can't see any reason for using 
LISTRIGHTS if I didn't intend to use the results to frame a SETACL or 
DELETEACL.

Hence I'm in agreement - make it require "a".

Dave.

To: Alexey Melnikov <[email-masked]>
From: Philip Guenther <[email-masked]>
Cc: Brian Candler <[email-masked]>, [email-masked]
Subject: Re: Clarification of "d" right in imapext-acl 
Date: Mon, 15 Nov 2004 08:17:46 -0800
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:
>Philip Guenther wrote:
>>Please review the 2086upd draft as soon as possible, as it should be
>>going to working group last call Real Soon Now.  Only one substantive
>>change was discussed at the IETF meeting last week: instead of returning
>>a MYRIGHTS response, the SELECT command should return a MYRIGHTS
>>response _code_.  So, for example, this line from the SELECT example in
>>section 7.1.1:
>>               S: * MYRIGHTS INBOX rwis
>>will end up instead reading:
>>               S: * OK [MYRIGHTS INBOX rwis] Blah blah your rights
>
>The ACL2 document defines MYRIGHTS response code, but it doesn't include 
>a mailbox name. Is it Ok?

So it should instead read:
                 S: * OK [MYRIGHTS rwis] No more, no less

The Formal Syntax needs to define the syntax for that as an extension of
resp-text-code:

resp-text-code  =/ myrights_rspcod

myrights_rspcod = "MYRIGHTS" SP rights

rights          = atom
                   ;; MUST NOT contain leading "+" or "-"
                   ;; MUST be treated as case-sensitive

Hmm, interesting: ACL2 used 'quoted' instead of 'atom' for rights.
Since a non-ATOM-CHAR right can't appear in the RIGHT=... capability, no
point in allowing them here in the MYRIGHTS response code.

The UTF-8 reference should be updated the RFC 3629.  It should be noted
somewhere that an identifier containing non-US-ASCII characters MUST be
represented as a literal and not a quoted-string or atom.

Philip Guenther

To: Brian Candler <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
From: Philip Guenther <[email-masked]>
Subject: Re: Clarification of "d" right in imapext-acl 
Date: Mon, 15 Nov 2004 07:36:28 -0800
Sender: [email-masked]

Brian Candler <[email-masked]> writes:
...
>I don't think it need be so complicated; how about just
>
>  If a client includes the "d" right in a rights list, then it is to be
>  treated as if the client had included the "x", "e" and "t" rights.
>
>(You could add: It is not an error for a client to specify both "d" and one
>or more of "x", "e" and "t", but the effect no different than if just "d" or
>all of "x", "e" and "t" had been specified)

I like this wording, including the parenthetical addition.

...
>I don't like the wording "clears the "d" right from a rights list", because
>IIUC you can't ask for individual flags to be set or cleared; you can only
>ask for the entire set of flags to be replaced with a new set.
...

If the third argument to SETACL starts with a "+" or "-" then it is a
modification to the existing rights for that identifier and not a
complete replacement.  I think your wording above covers that
sufficiently by virtue of not referring to the operation at all.
Less is more...

Philip Guenther

Date: Mon, 15 Nov 2004 14:39:19 +0000
From: Brian Candler <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Philip Guenther <[email-masked]>, [email-masked]
Subject: Re: Clarification of "d" right in imapext-acl
Sender: [email-masked]

On Mon, Nov 15, 2004 at 01:57:53PM +0000, Alexey Melnikov wrote:
> I think the following text in the appendix B could have caused the 
> confusion:
> 
>   This document replaces the "d" right with 3 new different rights "x", 
> "t" and "e".
> 
> Any suggestion how to improve this?

I don't think that's necessarily the source of confusion, but it could be
elaborated:

  This document splits the "d" right into 3 new different rights "x", "t"
and "e". The "d" right remains for backwards-compatibility but it is a
virtual right. If a client requests the "d" right, it is treated as if it
requested all of "x", "t" and "e". The server returns the "d" right if and
only if all of "x", "t" and "e" are set.

> I've changed this to:
>   If a client request clears the "d" right from a rights lists, then 
> the server MUST also clear
>   any of the "x", "e", and "t" rights, unless one or more of them is 
> also specified in the same rights list.
> 
> Is this any better?
> 
> Or maybe even:
>   If a client request clears the "d" right from a rights lists, then 
> the server MUST first clear
>   all of the "x", "e", and "t" rights. If all of the "x", "e", and "t" 
> rights are specified in the same rights list, they are then set as usual.
> ?

I don't think it need be so complicated; how about just

  If a client includes the "d" right in a rights list, then it is to be
  treated as if the client had included the "x", "e" and "t" rights.

(You could add: It is not an error for a client to specify both "d" and one
or more of "x", "e" and "t", but the effect no different than if just "d" or
all of "x", "e" and "t" had been specified)

I don't like the wording "clears the "d" right from a rights list", because
IIUC you can't ask for individual flags to be set or cleared; you can only
ask for the entire set of flags to be replaced with a new set. So the only
issue is, if the replacement set contains "d", how is it to be handled? And
I think the answer is, just as if "x", "e" and "t" had been specified.

Regards,

Brian.

Date: Mon, 15 Nov 2004 13:57:53 +0000
From: Alexey Melnikov <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: Brian Candler <[email-masked]>, [email-masked]
Subject: Re: Clarification of "d" right in imapext-acl
Sender: [email-masked]

Philip Guenther wrote:

>>The one implementation I have access to is courier-imap, and that behaves as
>>follows:
>>
>>- If e,t or x (but not all three) are set, return those flags for LIST (ACL)
>> and none for GETACL
>>- If all three are set, return only "d" for both LIST (ACL) and GETACL
>>    
>>
>
>The description of the 'd' right in the ACL2 and RIGHTS drafts are the
>same:
>   d - This right is defined for backward compatibility with ACL
>       extension (RFC 2086). If a client sets "d" right, the server MUST
>       set "x", "e" and "t" rights. When the client clears the "d" right,
>       the server MUST clear "x", "e" and "t" rights. When all three of "x",
>       "e" and "t" are set, the server MUST return "d" right in response to
>       a LIST (ACL) command. If "x", "e" and "t" rights are not tied together,
>       "d" right MUST NOT be returned in a <RIGHTS-INFO/LISTRIGHTS> response.
>
>Since it doesn't say "...MUST _instead_ return "d" right..." and doesn't
>say that clients should treat the 'd' right as implying the "etx"
>rights, I don't see how the text gives the server the license to leave
>out the "etx" rights when returning the 'd' right in LIST (ACL).
>
I think the following text in the appendix B could have caused the 
confusion:

   This document replaces the "d" right with 3 new different rights "x", 
"t" and "e".

Any suggestion how to improve this?

>  The
>*server* must make the d->etx implication when changing rights, but the
>client isn't required to make it when reading them.
>
>
>Perhaps most of the the description of the 'd' right should be moved
>out of the list into its own paragraph?  The list of rights would just
>say:
>   d - This right is defined for backward compatibility with ACL
>       extension (RFC 2086).  See below for details on how servers
>       should interpret it in commands that alter ACLs and when it
>       should be included in responses that return ACLs or lists of
>       rights.
>
>Then later:
>   If a client request sets the "d" right in a rights list, the server
>   MUST set the "x", "e", and "t" rights.  If a client request clears
>   the "d" right from a rights lists, then the server MUST also clear
>   any of the "x", "e", and "t" rights that are not simultaneously being
>   set.
>
I've changed this to:
   If a client request clears the "d" right from a rights lists, then 
the server MUST also clear
   any of the "x", "e", and "t" rights, unless one or more of them is 
also specified in the same rights list.

Is this any better?

Or maybe even:
   If a client request clears the "d" right from a rights lists, then 
the server MUST first clear
   all of the "x", "e", and "t" rights. If all of the "x", "e", and "t" 
rights are specified in the same rights list, they are then set as usual.
?

>  When all three of the "x", "e", and "t" rights are set in a
>   list of rights, the server MUST also include the "d" right when
>   returning that list in a MYRIGHTS or ACL response.  If the "x", "e",
>   and "t" rights are not tied together, the "d" right MUST NOT be
>   returned in a LISTRIGHTS response.
>
>(The phrasing about "simultaneously being set" is to make it clear that
>even though the request
>	tag SETACL "foo" "guenther" "lrswt"
>doesn't include (and may be clearing) the "d" right, the "t" right
>should still be set.)
>
>
>  
>

Date: Mon, 15 Nov 2004 12:45:30 +0000
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: Outstanding issues for draft-ietf-imapext-2086upd-00 (ACL)
Sender: [email-masked]

Alexey Melnikov wrote:

> Actually, I believe there are only two. One relates to whether the "m"
> right only controls writability of private annotations, or whether it
> also controls readability. I've sent a separate message on this.

I believe that this issue is closed now.

> The second issue:
>
> Which rights are required for the LISTRIGHTS command?
>
> Currently the document says:
>
>    MYRIGHTS - any of the following rights is required to perform
>     the operation: "l", "r", "i", "c", "x", "a".*
>
>    LISTRIGHTS - same as MYRIGHTS.
>
> Some of the existing servers follow this suggestion. Some allow for
> LISTRIGHTS if "r" and/or "a" is granted.
>
> Philip has suggested (and I agree) to only allow LISTRIGHTS when the "a"
> right is granted, as LISTRIGHTS information is only useful
> if you can also do SETACL. Also, such information shouldn't be disclosed
> to users that have insufficient rights.

So, any comments on changing LISTRIGHTS to require the "a" right?

> Alexey
>
> * - Note, that the STORE related rights ("w", "s", "t", "m" and "n") are
> not part of this list, because the client must be able to open a mailbox
> (i.e. "r") before performing a STORE command. The list also used to
> contain the "e" right (which controls EXPUNGE), I've deleted it for the
> same reason.

Date: Mon, 15 Nov 2004 12:32:43 +0000
From: Alexey Melnikov <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: Brian Candler <[email-masked]>, [email-masked]
Subject: Re: Clarification of "d" right in imapext-acl
Sender: [email-masked]

Philip Guenther wrote:

>Please review the 2086upd draft as soon as possible, as it should be
>going to working group last call Real Soon Now.  Only one substantive
>change was discussed at the IETF meeting last week: instead of returning
>a MYRIGHTS response, the SELECT command should return a MYRIGHTS
>response _code_.  So, for example, this line from the SELECT example in
>section 7.1.1:
>               S: * MYRIGHTS INBOX rwis
>will end up instead reading:
>               S: * OK [MYRIGHTS INBOX rwis] Blah blah your rights
>(Can't return a new response unless the client indicated it expected it
>by using some new syntax.  That's why the UNSEEN, UIDVALIDITY, UIDNEXT,
>and PERMANENTFLAGS values are returned as response codes instead of
>responses.)
>  
>
The ACL2 document defines MYRIGHTS response code, but it doesn't include 
a mailbox name. Is it Ok?

Date: Mon, 15 Nov 2004 12:16:42 +0000
From: Alexey Melnikov <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: Brian Candler <[email-masked]>, [email-masked]
Subject: Re: Clarification of "d" right in imapext-acl
Sender: [email-masked]

Brian Candler wrote:

>On Sun, Nov 14, 2004 at 03:04:19PM -0800, Philip Guenther wrote:
>  
>
>>Perhaps most of the the description of the 'd' right should be moved
>>out of the list into its own paragraph?  The list of rights would just
>>say:
>>   d - This right is defined for backward compatibility with ACL
>>       extension (RFC 2086).  See below for details on how servers
>>       should interpret it in commands that alter ACLs and when it
>>       should be included in responses that return ACLs or lists of
>>       rights.
>>
>>Then later:
>>   If a client request sets the "d" right in a rights list, the server
>>   MUST set the "x", "e", and "t" rights.  If a client request clears
>>   the "d" right from a rights lists, then the server MUST also clear
>>   any of the "x", "e", and "t" rights that are not simultaneously being
>>   set.  When all three of the "x", "e", and "t" rights are set in a
>>   list of rights, the server MUST also include the "d" right when
>>   returning that list in a MYRIGHTS or ACL response.  If the "x", "e",
>>   and "t" rights are not tied together, the "d" right MUST NOT be
>>   returned in a LISTRIGHTS response.
>>
>>(The phrasing about "simultaneously being set" is to make it clear that
>>even though the request
>>	tag SETACL "foo" "guenther" "lrswt"
>>doesn't include (and may be clearing) the "d" right, the "t" right
>>should still be set.)
>>    
>>
>
>Yes, that looks better.
>  
>
I think I want to rephrase the "simultaneously being set" part, but the 
idea looks good.

>>A few more nits on the 2086upd draft: the reference to LISTEXT in the
>>Formal Syntax should be removed.  In Appendix B, replace "a LIST
>>response" with "MYRIGHTS and ACL responses" and replace "ACL2" with
>>"RIGHTS".
>>    
>>
>
>I spotted those too :-)
>  
>
Fixed now. Thanks for spotting this.

Date: Mon, 15 Nov 2004 08:33:36 +0000
From: Brian Candler <[email-masked]>
To: Philip Guenther <[email-masked]>
Cc: [email-masked], Alexey Melnikov <[email-masked]>
Subject: Re: Clarification of "d" right in imapext-acl
Sender: [email-masked]

On Sun, Nov 14, 2004 at 03:04:19PM -0800, Philip Guenther wrote:
> Perhaps most of the the description of the 'd' right should be moved
> out of the list into its own paragraph?  The list of rights would just
> say:
>    d - This right is defined for backward compatibility with ACL
>        extension (RFC 2086).  See below for details on how servers
>        should interpret it in commands that alter ACLs and when it
>        should be included in responses that return ACLs or lists of
>        rights.
> 
> Then later:
>    If a client request sets the "d" right in a rights list, the server
>    MUST set the "x", "e", and "t" rights.  If a client request clears
>    the "d" right from a rights lists, then the server MUST also clear
>    any of the "x", "e", and "t" rights that are not simultaneously being
>    set.  When all three of the "x", "e", and "t" rights are set in a
>    list of rights, the server MUST also include the "d" right when
>    returning that list in a MYRIGHTS or ACL response.  If the "x", "e",
>    and "t" rights are not tied together, the "d" right MUST NOT be
>    returned in a LISTRIGHTS response.
> 
> (The phrasing about "simultaneously being set" is to make it clear that
> even though the request
> 	tag SETACL "foo" "guenther" "lrswt"
> doesn't include (and may be clearing) the "d" right, the "t" right
> should still be set.)

Yes, that looks better.

> A few more nits on the 2086upd draft: the reference to LISTEXT in the
> Formal Syntax should be removed.  In Appendix B, replace "a LIST
> response" with "MYRIGHTS and ACL responses" and replace "ACL2" with
> "RIGHTS".

I spotted those too :-)

Regards,

Brian.

To: Brian Candler <[email-masked]>
Cc: [email-masked], Alexey Melnikov <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: Clarification of "d" right in imapext-acl 
Date: Sun, 14 Nov 2004 15:04:19 -0800
Sender: [email-masked]

Brian Candler <[email-masked]> writes:
>According to draft-ietf-imapext-acl-10.txt section 3.1:
...
>RFC 2086 allows standards-track documents to define additional rights; if
>the intention is that LIST (ACL) and GETACL are permitted to return exactly
>the same set of flags under all circumstances, or not, then I think this
>should be made explicit.

At the San Diego meeting, the working group decided to put ACL2 on hold
for a moment in favor of turning out a quick revision of RFC 2086 that
added some additional rights (etxmn) and clarified exactly which rights
were required for which commands.  Alexey sent the current version of
that doc, draft-ietf-imapext-2086upd-01.txt, to the list on Nov 7:
	http://www.imc.org/ietf-imapext/mail-archive/msg02242.html

That revision isn't in the I-D repository yet.

Now, this affects your question/query in that the "etx" rights are being
added without changing the commands, so they will definitely be returned
by the GETACL command in an implementation supporting the RIGHTS
extension defined in the above draft.

As for returning the 'd' right from LIST (ACL), the draft currently is
specific about requiring it.  Permitting the server to leave it out when
GETACL is required to return it would make the text more complicated
for, IMO, no real gain.

(Once LISTEXT and RIGHTS are published, the ACL2 draft will shrink a
*lot*)

Please review the 2086upd draft as soon as possible, as it should be
going to working group last call Real Soon Now.  Only one substantive
change was discussed at the IETF meeting last week: instead of returning
a MYRIGHTS response, the SELECT command should return a MYRIGHTS
response _code_.  So, for example, this line from the SELECT example in
section 7.1.1:
               S: * MYRIGHTS INBOX rwis
will end up instead reading:
               S: * OK [MYRIGHTS INBOX rwis] Blah blah your rights
(Can't return a new response unless the client indicated it expected it
by using some new syntax.  That's why the UNSEEN, UIDVALIDITY, UIDNEXT,
and PERMANENTFLAGS values are returned as response codes instead of
responses.)

>The one implementation I have access to is courier-imap, and that behaves as
>follows:
>
>- If e,t or x (but not all three) are set, return those flags for LIST (ACL)
>  and none for GETACL
>- If all three are set, return only "d" for both LIST (ACL) and GETACL

The description of the 'd' right in the ACL2 and RIGHTS drafts are the
same:
   d - This right is defined for backward compatibility with ACL
       extension (RFC 2086). If a client sets "d" right, the server MUST
       set "x", "e" and "t" rights. When the client clears the "d" right,
       the server MUST clear "x", "e" and "t" rights. When all three of "x",
       "e" and "t" are set, the server MUST return "d" right in response to
       a LIST (ACL) command. If "x", "e" and "t" rights are not tied together,
       "d" right MUST NOT be returned in a <RIGHTS-INFO/LISTRIGHTS> response.

Since it doesn't say "...MUST _instead_ return "d" right..." and doesn't
say that clients should treat the 'd' right as implying the "etx"
rights, I don't see how the text gives the server the license to leave
out the "etx" rights when returning the 'd' right in LIST (ACL).  The
*server* must make the d->etx implication when changing rights, but the
client isn't required to make it when reading them.

Perhaps most of the the description of the 'd' right should be moved
out of the list into its own paragraph?  The list of rights would just
say:
   d - This right is defined for backward compatibility with ACL
       extension (RFC 2086).  See below for details on how servers
       should interpret it in commands that alter ACLs and when it
       should be included in responses that return ACLs or lists of
       rights.

Then later:
   If a client request sets the "d" right in a rights list, the server
   MUST set the "x", "e", and "t" rights.  If a client request clears
   the "d" right from a rights lists, then the server MUST also clear
   any of the "x", "e", and "t" rights that are not simultaneously being
   set.  When all three of the "x", "e", and "t" rights are set in a
   list of rights, the server MUST also include the "d" right when
   returning that list in a MYRIGHTS or ACL response.  If the "x", "e",
   and "t" rights are not tied together, the "d" right MUST NOT be
   returned in a LISTRIGHTS response.

(The phrasing about "simultaneously being set" is to make it clear that
even though the request
	tag SETACL "foo" "guenther" "lrswt"
doesn't include (and may be clearing) the "d" right, the "t" right
should still be set.)

A few more nits on the 2086upd draft: the reference to LISTEXT in the
Formal Syntax should be removed.  In Appendix B, replace "a LIST
response" with "MYRIGHTS and ACL responses" and replace "ACL2" with
"RIGHTS".  There are also a few remaining places where <"foo" right>
should be changed to <the "foo" right> (e.g., in the last paragraph of
section 6).

>Whether or not that's the intention of the draft, IMO the wording could be
>made clearer.

Would the above text do so?

Philip Guenther

Date: Sat, 13 Nov 2004 11:52:06 +0000
From: Brian Candler <[email-masked]>
To: [email-masked]
Subject: Clarification of "d" right in imapext-acl
Sender: [email-masked]

According to draft-ietf-imapext-acl-10.txt section 3.1:

   d - This right is defined for backward compatibility with ACL
       extension (RFC 2086). If a client sets "d" right, the server MUST
       set "x", "e" and "t" rights. When the client clears the "d" right,
       the server MUST clear "x", "e" and "t" rights. When all three of "x",
       "e" and "t" are set, the server MUST return "d" right in response to
       a LIST (ACL) command.

and later in section 9.1:

    b). Implement separate "x", "t" and "e". Return "d" right in a LIST 
        response containing ACL information when all three of "x", "t"
        and "e" are granted.

However I don't think it's clear whether this means that the LIST (ACL)
command should return the d flag *in addition* to etx, or *instead of* etx.

Also, it's not clear to me whether the old GETACL command is permitted to
return the e, t or x flags separately if they exist, or hide them. But if it
has to hide them, i.e. GETACL is supposed to be implemented differently to
LIST (ACL) for the benefit of RFC 2086 clients, then is there any need for
LIST (ACL) to return a "d" flag at all? LIST (ACL) is an ACL2 command, so
any ACL2 client should understand 'e','t' and 'x' separately anyway.

RFC 2086 allows standards-track documents to define additional rights; if
the intention is that LIST (ACL) and GETACL are permitted to return exactly
the same set of flags under all circumstances, or not, then I think this
should be made explicit.

The one implementation I have access to is courier-imap, and that behaves as
follows:

- If e,t or x (but not all three) are set, return those flags for LIST (ACL)
  and none for GETACL
- If all three are set, return only "d" for both LIST (ACL) and GETACL

Whether or not that's the intention of the draft, IMO the wording could be
made clearer.

Regards,

Brian Candler.

* OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE ACL ACL2=UNION STARTTLS] Courier-IMAP ready. Copyright 1998-2004 Double Precision, Inc.  See COPYING for distribution information.
a login [email-masked] XXXXXXXX
a OK LOGIN Ok.
a acl store "INBOX.mytest" "user=[email-masked]" "et"
* LIST (\HasNoChildren) "." "INBOX.mytest" (("ACL" (("owner" "acdilrsw")("user=[email-masked]" "et"))))
a OK ACL STORE completed.
a list (acl) "" "INBOX.mytest"
* LIST (\HasNoChildren) "." "INBOX.mytest" (("ACL" (("owner" "acdilrsw")("user=[email-masked]" "et"))))
a OK LIST completed
a getacl "INBOX.mytest"
* ACL "INBOX.mytest" "owner" "acdilrsw" "[email-masked]" ""
a OK GETACL completed.
a acl store "INBOX.mytest" "user=[email-masked]" "etx"
* LIST (\HasNoChildren) "." "INBOX.mytest" (("ACL" (("owner" "acdilrsw")("user=[email-masked]" "d"))))
a OK ACL STORE completed.
a list (acl) "" "INBOX.mytest"
* LIST (\HasNoChildren) "." "INBOX.mytest" (("ACL" (("owner" "acdilrsw")("user=[email-masked]" "d"))))
a OK LIST completed
a getacl "INBOX.mytest"
* ACL "INBOX.mytest" "owner" "acdilrsw" "[email-masked]" "d"
a OK GETACL completed.
a logout
* BYE Courier-IMAP server shutting down
a OK LOGOUT completed

Date: Fri, 12 Nov 2004 14:30:20 -0500
From: Cyrus Daboo <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: Notes for IMAPEXT WG meeting at IETF61
Sender: [email-masked]

Hi Arnt,

--On Friday, November 12, 2004 17:53:02 EST +0100 Arnt Gulbrandsen 
<[email-masked]> wrote:

>> Multiple-mailbox-match in LISTEXT: looks like there's consensus to add
>> it.  We will take this to the list to see if there's any objectors on
>> the list.
>
> There's me, sort of. But if it's okay to send two responses when a
> mailbox matches two patterns, I'll be quiet. (I don't remember right now.
> There was some discussion, wasn't there?)

Clients have to potential cope with that situation today with regular LIST 
so having the server do it with LISTEXT, whilst not ideal, should not cause 
problems. I think we ought to say 'servers SHOULD suppress duplicate 
mailboxes in the response' and leave it at that.

-- 
Cyrus Daboo

Date: Fri, 12 Nov 2004 17:53:02 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Notes for IMAPEXT WG meeting at IETF61
Sender: [email-masked]

Lisa Dusseault writes:
> Multiple-mailbox-match in LISTEXT: looks like there's consensus to add 
> it.  We will take this to the list to see if there's any objectors on 
> the list.

There's me, sort of. But if it's okay to send two responses when a 
mailbox matches two patterns, I'll be quiet. (I don't remember right 
now. There was some discussion, wasn't there?)

Arnt

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Notes location
Date: Fri, 12 Nov 2004 08:14:46 -0800
Sender: [email-masked]

I forwarded the notes to the WG and also uploaded them to 
http://ietf.webdav.org/imapext/.  I also added a link there to the 
Jabber room logs.  There were no presentations at this meeting.

Lisa

To: [email-masked], IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Notes for IMAPEXT WG meeting at IETF61
Date: Fri, 12 Nov 2004 07:49:55 -0800
Sender: [email-masked]

LISTEXT STATUS

Discussion of /Placeholder: Philip promised to send a mail about a 
simplification of /Placeholder.  Cyrus and Barry agree that LISTEXT is 
too complicated and we need to back off that.

Question about which client people initially asked for features in 
LISTEXT (prompted by observation that LISTEXT has now become rather 
complex)? Cyrus, David Cridland, Mark Crispin.. who else?

Suggestion that the /matchparent stuff may be simplifiable -- get rid 
of it.  Any wildcard query (%) could be seen as a request for 
matchparent -- otherwise the server must not return it.

Multiple-mailbox-match in LISTEXT: looks like there's consensus to add 
it.  We will take this to the list to see if there's any objectors on 
the list.

We will defer to the mailing list for what to do with /NOSELECT, 
/NONEXISTENT, /DELETED...

Cyrus and Philip are on the hook to suggest a simplified model to 
Alexey and Barry for matchparent... the next version of this may get 
last-called.

---
ACL STATUS

Discussion on 2086 upd:  Looks good, needs to be kept simple and 
finished soon.  Scott and Chris promise to review 2086upd

---
ANNOTATE STATUS

Discussion on Annotate: lots of discussion over what rights to use for 
private and public annotations.

Proposal: that the ability to read private annotations is controlled by 
the 'r' ACL bit, and the ability to write private annotations is 
controlled by the new 'm' ACL bit.  This means that 'r' controls 
readability for both private and shared annotations.  There were no 
sticking objections to this proposal (however Barry and Chris would 
prefer another proposal.)

2nd issue with ANNOTATE: Interactions with the CATENATE draft.  
Resolution: Cyrus will add text to deal with this and there will be a 
new dependency of Annotate on Catenate

3rd issue: APPEND: a slight interaction here with annotate, which Cyrus 
will add to the draft.

We plan to last call the  next version of Annotate on the day it comes 
out.

---
ANNOTATEMORE

Plug for AnnotateMore -- Chris and Philip promised to review, Cyrus 
will ask LEMONADE list for review.

content-class: urn:content-classes:message
Subject: RE: Comments on ANNOTATEMORE
Date: Thu, 11 Nov 2004 06:20:24 -0600
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: ext Cyrus Daboo [mailto:[email-masked]]
> Sent: Thursday, November 11, 2004 1:01 AM
...
> > The ANNOTATE draft does allow for attribute value pairs to be sent
> > in unsolicited responses with the SELECT parameter "(ANNOTATE)".
> > There does not seem to be an analog in ANNOTATEMORE.
> 
> No, that's not the case. Section 3.2 of ANNOTATE states that 

Which statement are you refuting the first or the second? Both
maybe?

> the (ANNOTATE) 
> parameter on SELECT turns on unsolicited annotation responses 
> as defined by 
> Section 3.4. Section 3.4 states that unsolicited responses 
> MUST NOT include 
> the annotation data. i.e. the ANNOTATION responses resulting from 
> (ANNOTATE) on SELECT do not include the annotation values.

I'm confused. Here is an excerpt from draft-ietf-imapext-annotate-11.txt
sec 3.4.

   Servers MUST NOT include ANNOTATION data in unsolicited responses
   unless the client used the ANNOTATE select parameter when it issued
   the last SELECT or EXAMINE command.  This restriction avoids sending
   ANNOTATION data to a client unless the client explicitly asks for it.

   Servers SHOULD send ANNOTATION message data items in unsolicited
   FETCH responses if an annotation entry is changed by a third-party,
   and the ANNOTATE select parameter was used.  This allows servers to
   keep clients updated with changes to annotations by other clients.

This seems clear to me. I must be missing something about your point.

Mike

Date: Thu, 11 Nov 2004 01:00:46 -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: Comments on ANNOTATEMORE
Sender: [email-masked]

Hi Michael,

--On Wednesday, November 10, 2004 14:49:06 EST -0600 
[email-masked] wrote:

>> This behaves the same way as unsolicited ANNOTATE responses
>> in the ANNOTATE
>> extension. The reason for this behaviour is that clients may
>
> The ANNOTATE draft does allow for attribute value pairs to be sent
> in unsolicited responses with the SELECT parameter "(ANNOTATE)".
> There does not seem to be an analog in ANNOTATEMORE.

No, that's not the case. Section 3.2 of ANNOTATE states that the (ANNOTATE) 
parameter on SELECT turns on unsolicited annotation responses as defined by 
Section 3.4. Section 3.4 states that unsolicited responses MUST NOT include 
the annotation data. i.e. the ANNOTATION responses resulting from 
(ANNOTATE) on SELECT do not include the annotation values.

Perhaps this needs to be made more explicit?

-- 
Cyrus Daboo

content-class: urn:content-classes:message
Subject: RE: Comments on ANNOTATEMORE 
Date: Wed, 10 Nov 2004 21:03:12 -0600
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: ext Philip Guenther [mailto:[email-masked]]
> Sent: Wednesday, November 10, 2004 5:35 PM
...
> >> /checkperiod is meant to be the user preference for polling 
> >> interval. i.e. 
> >> the client will use that value to determine what interval it 
> >> should poll 
> >> the mailbox (using STATUS or NOOP). It is not under control 
> >> of the server 
> >> and is not used by the server. I can add text to clarify that.
> >
> >As described I don't see it having much value. I see it having 
> >much more value as a server set value. So I would suggest you 
> >don't add the clarification and leave it as either client or 
> >server set.
> 
> What would a server-set version of checkperiod tell the client?  I'm
> trying to envision an interpretation that wouldn't imply that 
> the server
> can see into the future.

A server can see into the future. It is called extrapolation.

> >I'm talking about 3rd party changes as described in ANNOTATE sec 3.4
> >last two paragraphs. These would not be redundant. I could see them
> >as being uninteresting to some clients, but for the same reason you 
> >allow unsolicited responses with data in ANNOTATE sec 3.4 they may be
> >interesting to some clients. To those clients it would be nice to
> >have the data contained in the response.
> 
> Given the possible size of annotations (as compared to the 
> size of flags
> updates), defaulting to not sending values seems wise to me.

I agree. I understand that point. 

You do agree the ANNOTATE draft does have a way to allow data to be 
included in unsolicited responses? Why would it not be wise to allow 
such a capability to be turned on for non-message annotations? Note, 
I'm not talking about the default.

Maybe the answer is there is no clean way to do it. Message 
annotations have the SELECT (ANNOTATE) switch. Where you would
hang such a switch with non-message annotations I'm not sure.

Mike

To: [email-masked]
Cc: [email-masked]
Subject: Re: Comments on ANNOTATEMORE 
Date: Wed, 10 Nov 2004 14:34:49 -0800
From: Philip Guenther <[email-masked]>
Sender: [email-masked]

[email-masked] writes:
>Cyrus Daboo <[email-masked]> writes:
...
>> /checkperiod is meant to be the user preference for polling 
>> interval. i.e. 
>> the client will use that value to determine what interval it 
>> should poll 
>> the mailbox (using STATUS or NOOP). It is not under control 
>> of the server 
>> and is not used by the server. I can add text to clarify that.
>
>As described I don't see it having much value. I see it having 
>much more value as a server set value. So I would suggest you 
>don't add the clarification and leave it as either client or 
>server set.

What would a server-set version of checkperiod tell the client?  I'm
trying to envision an interpretation that wouldn't imply that the server
can see into the future.

Note that ANNOTATEMORE arose in part from the difficulties in
implementing ACAP and several of the initial entries are there to
take over for ACAP profiles of client configuration.

...
>I'm talking about 3rd party changes as described in ANNOTATE sec 3.4
>last two paragraphs. These would not be redundant. I could see them
>as being uninteresting to some clients, but for the same reason you 
>allow unsolicited responses with data in ANNOTATE sec 3.4 they may be
>interesting to some clients. To those clients it would be nice to
>have the data contained in the response.

Given the possible size of annotations (as compared to the size of flags
updates), defaulting to not sending values seems wise to me.

Philip Guenther

content-class: urn:content-classes:message
Subject: RE: Comments on ANNOTATEMORE
Date: Wed, 10 Nov 2004 14:49:06 -0600
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: ext Cyrus Daboo [mailto:[email-masked]]
> Sent: Wednesday, November 10, 2004 10:58 AM
> > Section 2.2.1.2
> >
> > I don't understand the usefulness of /check and /checkperiod.
> > Who sets checkperiod? Mail arrival is variable so the only
...
> /checkperiod is meant to be the user preference for polling 
> interval. i.e. 
> the client will use that value to determine what interval it 
> should poll 
> the mailbox (using STATUS or NOOP). It is not under control 
> of the server 
> and is not used by the server. I can add text to clarify that.

As described I don't see it having much value. I see it having 
much more value as a server set value. So I would suggest you 
don't add the clarification and leave it as either client or 
server set.

> 
> It is sometimes useful to be able to 'suspend' checking of a 
> mailbox, hence 
...

Agreed.

> > Section 3.3
...
> i.e. there is no need for the server to send back the 
> annotation data that 
> the client has just set using SETANNOTATION - that 
> information is redundant 
> as the OK response implies those changes have succeeded.

Agreed.

> 
> >
> > Section 3.4.2
> >
> > Why do unsolicited ANNOTATION responses not contain attributes
> > and values? Wouldn't they be more useful if they contained the
> > new data? Maybe they MAY as descibed in section 3.3?
> 
> This behaves the same way as unsolicited ANNOTATE responses 
> in the ANNOTATE 
> extension. The reason for this behaviour is that clients may 

The ANNOTATE draft does allow for attribute value pairs to be sent 
in unsolicited responses with the SELECT parameter "(ANNOTATE)". 
There does not seem to be an analog in ANNOTATEMORE.

> not care about 
> some annotations and therefore sending the data is redundant ande 
> potentially wastes bandwidth. It is more efficient to tell 
> the client that 
> some changes have happened and then have the client go and 
> fetch the data 
> for only the ones it is really interested in. i.e. we are 
> trying to prevent 
> the server forcing data on the client that it does not need.

I'm talking about 3rd party changes as described in ANNOTATE sec 3.4
last two paragraphs. These would not be redundant. I could see them
as being uninteresting to some clients, but for the same reason you 
allow unsolicited responses with data in ANNOTATE sec 3.4 they may be
interesting to some clients. To those clients it would be nice to
have the data contained in the response.

Mike

Date: Wed, 10 Nov 2004 10:57:39 -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Comments on ANNOTATEMORE
Sender: [email-masked]

Hi [email-masked],

--On Wednesday, November 10, 2004 9:17:31 EST -0600 [email-masked] 
wrote:

> Section 2.2.1.2
>
> I don't understand the usefulness of /check and /checkperiod.
> Who sets checkperiod? Mail arrival is variable so the only
> reasonable thing to do is to have it modified by the server
> using some learning algorithm that changed the value as the
> inter-mail arrival times changed.
>
> Or maybe you were thinking about some server imposed polling
> throttle?
>
> /check is redundant. The existence of /checkperiod implies
> /check=true.

/checkperiod is meant to be the user preference for polling interval. i.e. 
the client will use that value to determine what interval it should poll 
the mailbox (using STATUS or NOOP). It is not under control of the server 
and is not used by the server. I can add text to clarify that.

It is sometimes useful to be able to 'suspend' checking of a mailbox, hence 
having a separate 'turn check on/off' value that does not affect the period 
is useful. i.e. you don't have to remember what the last period when 
restoring checking after it has been suspended.

>
> Section 3.3
>
> The paragraph immediately following the "Result:" section
> describes behavior for unsolicited responses. I'm unclear if
> this is referring to the potential untagged responses returned
> due to the SETANNOTATION, or to unsolicited responses in general,
> for example, during a NOOP.

The first paragraph in section 3.3 is confusing. The policy is that 
unsolicited responses can be sent at any appropriate time (including during 
SETANNOTATION), however the server does not need to send ANNOTATION 
responses that are the direct result of the SETANNOTATION command itself - 
i.e. there is no need for the server to send back the annotation data that 
the client has just set using SETANNOTATION - that information is redundant 
as the OK response implies those changes have succeeded.

>
> Section 3.4.2
>
> Why do unsolicited ANNOTATION responses not contain attributes
> and values? Wouldn't they be more useful if they contained the
> new data? Maybe they MAY as descibed in section 3.3?

This behaves the same way as unsolicited ANNOTATE responses in the ANNOTATE 
extension. The reason for this behaviour is that clients may not care about 
some annotations and therefore sending the data is redundant ande 
potentially wastes bandwidth. It is more efficient to tell the client that 
some changes have happened and then have the client go and fetch the data 
for only the ones it is really interested in. i.e. we are trying to prevent 
the server forcing data on the client that it does not need.

-- 
Cyrus Daboo

content-class: urn:content-classes:message
Subject: Comments on ANNOTATEMORE
Date: Wed, 10 Nov 2004 09:17:31 -0600
From: <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Section 2.2.1.2

I don't understand the usefulness of /check and /checkperiod. 
Who sets checkperiod? Mail arrival is variable so the only 
reasonable thing to do is to have it modified by the server 
using some learning algorithm that changed the value as the
inter-mail arrival times changed.

Or maybe you were thinking about some server imposed polling 
throttle?

/check is redundant. The existence of /checkperiod implies 
/check=true.

Section 3.3 

The paragraph immediately following the "Result:" section 
describes behavior for unsolicited responses. I'm unclear if 
this is referring to the potential untagged responses returned
due to the SETANNOTATION, or to unsolicited responses in general, 
for example, during a NOOP.

Section 3.4.2

Why do unsolicited ANNOTATION responses not contain attributes 
and values? Wouldn't they be more useful if they contained the
new data? Maybe they MAY as descibed in section 3.3?

Mike

Date: Tue, 9 Nov 2004 08:56:56 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, Alexey Melnikov <[email-masked]>, kael <[email-masked]>, [email-masked]
Subject: Re: Question about the SORT and THREAD extensions
Sender: [email-masked]

On Tue, 9 Nov 2004, Dave Cridland wrote:
> I confess to being totally bewildered by the FROM, TO and CC sort keys, as 
> they all appear to only sort on the local-part of the email address - that 
> *is* the "bit before the @", right? So different domains collate equally? I 
> can't understand why this should be the case.

In practice, not all that many people use those keys.

The idea is to tend to collect messages from a single person together, 
based upon the tendency of people to have the same local-part for his 
email address even though they may use many different sites.  Note that 
word "tend".

It's useful, in some very limited cases.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

From: Dave Cridland <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, kael <[email-masked]>, <[email-masked]>
Subject: Re: Question about the SORT and THREAD extensions
Date: Tue, 09 Nov 2004 16:12:33 +0000
Sender: [email-masked]

On Tue Nov  9 12:25:17 2004, Arnt Gulbrandsen wrote:
> Dave Cridland writes:
>> For an actual SORT, no matter how quick the sort implementation on 
>> the server is, for large mailboxes that's still a noticeable chunk 
>> of bandwidth chewage for the result - the sort results for a 50k 
>> message folder weigh in at 282k[1].
> 
> "sort (subject date) charset us-ascii since 2004-11-08 not since 
> 2004-11-09" should have only a small response, even if the mailbox 
> is big.
> 
> 
You mentioned timezones being problematic, but I'll just clarify - 
the DATE and ARRIVAL sort keys sort by first normalizing the relevant 
date (RFC2822 header and INTERNALDATE respectively) into UTC. The 
date-orientated search keys (In this case SINCE) search by discarding 
the time and timezone, which can result in a different date.

But back to the point... Yes, you can chop up SORT results for a 
"group by" style feature using the SEARCH key, and this will, in 
general, reduce the number of numbers given in the SORT response. But 
realistically, only for date/time related metadata.

For a sort or group by sender, or subject, this wouldn't be possible:

SUBJECT search keys use a substring match of the full header value - 
using a US-ASCII charset does this without MIME decoding. SUBJECT 
sort key uses the base subject, not the real one, and always decodes. 
Hence it's impossible to, for instance, divide the messages up into 
chunks with subjects beginning "a", etc, because:
a) The "base subject", which you actually want, isn't being searched, 
so you need to SORT the full mailbox.
b) You can't do a prefix search anyway.

FROM is just as curious, sorting as it does only on the local-part of 
the From address, but substring searching throughout the entire 
header, optionally MIME decoding as above.

I confess to being totally bewildered by the FROM, TO and CC sort 
keys, as they all appear to only sort on the local-part of the email 
address - that *is* the "bit before the @", right? So different 
domains collate equally? I can't understand why this should be the 
case.

This would appear to mean that it's totally impossible to use SORT to 
generate the collation from which a group by sender listing could 
actually be generated. This seems intuitively wrong to me, but 
accurate according to the specification.

Dave.

Date: Tue, 9 Nov 2004 13:25:17 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Question about the SORT and THREAD extensions
Cc: Alexey Melnikov <[email-masked]>, Dave Cridland <[email-masked]>, [email-masked]
Sender: [email-masked]

Dave Cridland writes:
> For an actual SORT, no matter how quick the sort implementation on the 
> server is, for large mailboxes that's still a noticeable chunk of 
> bandwidth chewage for the result - the sort results for a 50k message 
> folder weigh in at 282k[1].

"sort (subject date) charset us-ascii since 2004-11-08 not since 
2004-11-09" should have only a small response, even if the mailbox is 
big.

(Kael: When you implement the "yesterday" group, remember to consider 
the timezone issues. I think that command doesn't quite match what you 
want.)

Arnt

From: Dave Cridland <[email-masked]>
To: kael <[email-masked]>
Cc: IMAP extensions Mailing List <[email-masked]>, Alexey Melnikov <[email-masked]>
Subject: Re: Question about the SORT and THREAD extensions
Date: Tue, 09 Nov 2004 10:40:18 +0000
Sender: [email-masked]

On Mon Nov  8 17:21:05 2004, kael wrote:
> 
> On 08.11.2004 17:55, Alexey Melnikov wrote:
> 
>> Yes (ARRIVAL or DATE sort criterion, depending on what you mean: 
>> delivery date or the Date header)...
> 
> I deduce that, except for keywords, the implementation of the IMAP 
> SORT and THREAD extensions for Mozilla/Thunderbird could be done in 
> consideration of the new _Message Grouping_ feature 
> http://kb.mozillazine.org/index.phtml?title=Thunderbird_:_FAQs_:_Message_Grouping, 
> couldn't it. That would be great !

Well, yes and no, really.

On the one hand, messages can be sorted by *all* the criteria listed 
in that webpage, on the (minor) assumption that labels could be 
implemented as annotations rather than keywords. (I'm assuming here 
that it's one label per message, which many possible labels, in which 
case keywords could become problematic - servers don't always support 
an infinite number of keywords, so annotations would be a better fit.)

On the other hand, every time a new message arrived, it would have to 
be sorted. Currently, that can either be done by re-sorting the 
entire folder server-side, or else sorting locally.

For an actual SORT, no matter how quick the sort implementation on 
the server is, for large mailboxes that's still a noticeable chunk of 
bandwidth chewage for the result - the sort results for a 50k message 
folder weigh in at 282k[1].

For client-side sorts, you can't actually give a straight figure for 
the transfer, but it's likely to tend towards something much smaller 
as time passes and data is cached - ultimately down to the size of 
the data used as a sort key for the new message, usually quite small.

So in actual practise, it's probably not worthwhile using the SORT 
except, possibly, for the first hit, depending on how much data is 
cached client-side to begin with.

Dave.

Footnote:
1) In Python: len('* SORT' + ''.join( [str(x) for x in 
range(1,50000)] ))/1024.0 - across a fairly typical 512kbit/s DSL 
line, that's about 4.5 seconds of *transfer* time alone. Of course, I 
might have mucked up the calculation.

Date: Mon, 08 Nov 2004 18:21:05 +0100
From: kael <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: IMAP extensions Mailing List <[email-masked]>
Subject: Re: Question about the SORT and THREAD extensions
Sender: [email-masked]

On 08.11.2004 17:55, Alexey Melnikov wrote:

> Yes (ARRIVAL or DATE sort criterion, depending on what you mean: 
> delivery date or the Date header)...

I deduce that, except for keywords, the implementation of the IMAP SORT 
and THREAD extensions for Mozilla/Thunderbird could be done in 
consideration of the new _Message Grouping_ feature 
http://kb.mozillazine.org/index.phtml?title=Thunderbird_:_FAQs_:_Message_Grouping, 
couldn't it. That would be great !

Thanks for your replies.

-- 
kael

Date: Mon, 08 Nov 2004 16:55:27 +0000
From: Alexey Melnikov <[email-masked]>
To: kael <[email-masked]>
CC: IMAP extensions Mailing List <[email-masked]>
Subject: Re: Question about the SORT and THREAD extensions
Sender: [email-masked]

kael wrote:

> On 08.11.2004 14:56, Alexey Melnikov wrote:
>
>> If you asking about grouping by message age, than the answer is
>> "yes". The SORT extension would be sufficient for this.
>
> Does the SORT extension allow to group messages by date,

Yes (ARRIVAL or DATE sort criterion, depending on what you mean: 
delivery date or the Date header)

> keywords,

No.

> senders, subject,

Yes and yes.

> etc like Thunderbird 0.9 does - please, look at the
> attachments ? I have never been able to sort messages like this with
> Mulberry.

From: Dave Cridland <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>, Alexey Melnikov <[email-masked]>, Philip Guenther <[email-masked]>
Subject: Re: Annotate
Date: Mon, 08 Nov 2004 15:58:42 +0000
Sender: [email-masked]

On Mon Nov  8 15:17:11 2004, Cyrus Daboo wrote:
> --On Monday, November 8, 2004 14:54:19 EST +0000 Alexey Melnikov 
> <[email-masked]> wrote:
>>>> I'd personally suggest that if the server supports read-write
>>>> annotations, it MUST support creation of arbitrary, 
>>>> non-operational
>>>> attributes.
>>> Is a server that only supports preconfigured namespaces an active 
>>> danger
>>> to interoperability?  If not, then I think "MUST" is 
>>> inappropriate.
>> Unfortunately, there is no way to distinguish a read-write ANNOTATE
>> server that supports reconfigured namespaces from a full read-write
>> server. So yes, this might be a problem. At least it makes writing 
>> client
>> more difficult.
> I think servers SHOULD allow clients to create and use arbitrary 
> annotation entries be they in the vendor namespace or elsewhere 
> (the later being e.g. new standard annotations that have been 
> defined since the server was deployed). However, as with everything 
> in IMAP, the client MUST be prepared to handle the server saying NO.
> 
> So I think what we say is: 'servers SHOULD allow creation and use 
> of arbitrary annotation entries in the vendor namespace or 
> elsewhere, but client MUST handle the case where a server prevents 
> that and responds with a NO response', or something to that effect.

I'll certainly agree, of course, that any STORE to annotation may 
result in a NO, and of course, a client has to handle this.

To my mind, not allowing arbitrary attributes ranks at near the same 
level as not having persistent UIDs for a mailbox. It's something a 
client has to cope with, but shouldn't ever have to experience in the 
field. I'll concede that even this makes a MUST too strong, but 
perhaps a SHOULD with a note?

Philip used the phrase "active danger to interoperability" - a server 
which does not support storage of arbitrary attributes against a 
message in a mailbox for which the client has the rights required 
isn't actively endangering interoperability because, of course, it's 
acting so close to a server which doesn't support ANNOTATE at all.

What it is doing is missing out on a golden opportunity to provide a 
method for new features - such as, maybe, a resent-to attribute - to 
be created by one client, used by another, and standardized quickly 
and rapidly based on real operational experience. That's hurting 
interoperability badly, in my opinion.

As well as that, it's losing the ability to transfer mailboxes from 
one IMAP server to another without losing potentially highly valuable 
metadata, especially in the case where multiple clients are used.

If persistent UIDs aren't available, then the message store is badly 
designed for use with IMAP. If arbitrary annotations aren't 
supported, then the message store is badly designed for use with 
ANNOTATE.

Dave.

Date: Mon, 08 Nov 2004 10:17:11 -0500
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Philip Guenther <[email-masked]>
cc: Dave Cridland <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Annotate
Sender: [email-masked]

Hi Alexey,

--On Monday, November 8, 2004 14:54:19 EST +0000 Alexey Melnikov 
<[email-masked]> wrote:

>>> I'd personally suggest that if the server supports read-write
>>> annotations, it MUST support creation of arbitrary, non-operational
>>> attributes.
>>>
>>>
>> Is a server that only supports preconfigured namespaces an active danger
>> to interoperability?  If not, then I think "MUST" is inappropriate.
>>
>>
> Unfortunately, there is no way to distinguish a read-write ANNOTATE
> server that supports reconfigured namespaces from a full read-write
> server. So yes, this might be a problem. At least it makes writing client
> more difficult.

I think servers SHOULD allow clients to create and use arbitrary annotation 
entries be they in the vendor namespace or elsewhere (the later being e.g. 
new standard annotations that have been defined since the server was 
deployed). However, as with everything in IMAP, the client MUST be prepared 
to handle the server saying NO.

So I think what we say is: 'servers SHOULD allow creation and use of 
arbitrary annotation entries in the vendor namespace or elsewhere, but 
client MUST handle the case where a server prevents that and responds with 
a NO response', or something to that effect.

-- 
Cyrus Daboo

Date: Mon, 08 Nov 2004 14:54:19 +0000
From: Alexey Melnikov <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: Dave Cridland <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Annotate
Sender: [email-masked]

Philip Guenther wrote:

>>I'd personally suggest that if the server supports read-write 
>>annotations, it MUST support creation of arbitrary, non-operational 
>>attributes.
>>    
>>
>Is a server that only supports preconfigured namespaces an active danger
>to interoperability?  If not, then I think "MUST" is inappropriate.
>  
>
Unfortunately, there is no way to distinguish a read-write ANNOTATE 
server that supports reconfigured namespaces from a full read-write 
server. So yes, this might be a problem. At least it makes writing 
client more difficult.

To: Dave Cridland <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Annotate 
Date: Mon, 08 Nov 2004 06:29:28 -0800
From: Philip Guenther <[email-masked]>
Sender: [email-masked]

Dave Cridland <[email-masked]> writes:
>On Sat Nov  6 12:55:43 2004, Alexey Melnikov wrote:
>> Timo Sirainen wrote:
...
>>> Servers MUST(?) support new namespaces created by clients.
>> 
>> I think this should be "SHOULD". We want to encourage ANNOTATE 
>> servers. Implementing a read-only ANNOTATE is much easier.
>> 
>> 
>Yes, but the need for clients to store vendor-private stuff in a 
>nice, neat, semi-interoperable manner really shouldn't be 
>underestimated. Dropping this to a SHOULD is perhaps too far.

As described in RFC 2119, "SHOULD" is a fairly strong statement, with
"MUST" being for the do-or-die stuff only.  A quick scan of the IMAP RFC
finds a goodly number of uses of "SHOULD" that a server or client would
be very unwise to blithely disregard.

>I'd personally suggest that if the server supports read-write 
>annotations, it MUST support creation of arbitrary, non-operational 
>attributes.

Is a server that only supports preconfigured namespaces an active danger
to interoperability?  If not, then I think "MUST" is inappropriate.

Philip Guenther

Date: Mon, 08 Nov 2004 13:56:04 +0000
From: Alexey Melnikov <[email-masked]>
To: kael <[email-masked]>
CC: [email-masked]
Subject: Re: Question about the SORT and THREAD extensions
Sender: [email-masked]

kael wrote:

> Hello,
>
> Can [could] the SORT and THREAD extensions handle messages like this 
> http://www.deftone.com/blogzilla/archives/new_thunderbird_feature_message_grouping.html 
> ?

If you asking about grouping by message age, than the answer is "yes". 
The SORT extension would be sufficient for this.

From: Dave Cridland <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, IMAP Extensions WG <[email-masked]>, Timo Sirainen <[email-masked]>
Subject: Re: Annotate
Date: Mon, 08 Nov 2004 10:25:08 +0000
Sender: [email-masked]

On Sat Nov  6 12:55:43 2004, Alexey Melnikov wrote:
> Timo Sirainen wrote:
>> On 1.11.2004, at 20:09, Cyrus Daboo wrote:
>>>> I thought clients weren't allowed to make up their own 
>>>> annotation entry
>>>> names? Or what does this mean?
>>> 
>>> 
>>> If a client wants to create a 'boolean' (on/off) type property 
>>> associated with a message it has two options: use an IMAP keyword 
>>> (either private or registered), or create a vendor (or new 
>>> standard) annotation entry. The former gives no control over 
>>> private/shared state, whereas the latter does. So if there is a 
>>> specific need for such a property that does need explicit 
>>> private/shared behavior then the client can use annotations in 
>>> lieu of IMAP keywords.
>> 
>> 
>> I thought vendor namespaces meant that servers could create them, 
>> not clients. Maybe put at the beginning of 2.2.1 something like:
>> 
>> Vendor namespaces can be created by either clients or servers.
> 
> Yes.
> 
>> Servers MUST(?) support new namespaces created by clients.
> 
> I think this should be "SHOULD". We want to encourage ANNOTATE 
> servers. Implementing a read-only ANNOTATE is much easier.
> 
> 
Yes, but the need for clients to store vendor-private stuff in a 
nice, neat, semi-interoperable manner really shouldn't be 
underestimated. Dropping this to a SHOULD is perhaps too far.

I'd personally suggest that if the server supports read-write 
annotations, it MUST support creation of arbitrary, non-operational 
attributes.

The alternative is to encourage clients to avoid them entirely, 
either via keywords, which, having no namespace, have the potential 
to clash, or via messages containing client-specific data within. 
Both are effectively a poor emulation of ANNOTATE.

I said "semi-interoperable" earlier, and this is such an awful term 
it probably needs some explanation. What I mean is that:

a) The various client-specific annotations don't actually interfere 
with each other. You're not faced with keywords that your client 
might intend using for something else, you're not faced with 
mailboxes containing "special" messages.
b) It's a lot easier to switch a client from using a client-specific 
usage of ANNOTATE into a standard usage of ANNOTATE, than to switch a 
client from using Something Weird to ANNOTATE.
c) Chances are that several clients will spontaneously interoperate 
by deliberately using each other's client-specific extensions. (They 
do this with their local configurations already, remember - this 
would be a lot easier.)

Dave.

Date: Sun, 07 Nov 2004 16:28:28 -0800
From: Lyndon Nerenberg <[email-masked]>
To: [email-masked], IMAP Extensions WG <[email-masked]>
Subject: Re: Comments about CLEARIDLE
Sender: [email-masked]

--On 2004-11-7 5:18 PM +0000 Alexey Melnikov 
<[email-masked]> wrote:

>
> One thing the needs discussing is whether the problem of receiving
> flag changes/new mail notifications for multiple mailboxes (over a
> single connection) is worth solving. I frankly don't know for sure.

It has been brought up enough times over the last five years that I am
convinced it is. I wrote a non-published draft a few years back that
proposed a solution to the multiple-mailbox newmail notification 
problem.
And since the issue has come up once again over the last few months I 
have
updated the draft and will submit it after the IETF.

--lyndon

Date: Sun, 07 Nov 2004 17:18:22 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: [email-masked], IMAP Extensions WG <[email-masked]>
Subject: Comments about CLEARIDLE
Sender: [email-masked]

[Also crossposting this to IMAPEXT.]

> Clearidle (See attached)
>   The IMAPRev4 specification supports unsolicited responses being sent
>   to a client at any time. The IDLE specification defines a way for a 
>   client to sit in an idle connection waiting to receive these   
> responses. This document clarifies and extends the set of responses   
> that a client may receive while in the idle state. The desire is to   
> allow a client to predict exactly what set of unsolicited responses   
> it can rely on receiving when listening on an idle connection.

One thing the needs discussing is whether the problem of receiving flag 
changes/new mail notifications for multiple mailboxes (over a single 
connection) is worth solving. I frankly don't know for sure.

I will try to emphasize some specific technical issues with this document.

 >2.1 LIST Response
 >
 >   Currently the LIST response occurs as the result of a LIST command.
 >   This document modifies the syntax of a LIST response and also defines
 >   it's occurrence as a legal unsolicited response that could be received
 >   on IDLE connections associated with a user.
 >
 >   Two new name attributes are defined:
 >
 >   \Deleted
 >       The mailbox has been deleted and no longer exists. After a LIST
 >       response with this attribute is seen the server will no longer
 >       show the named folder in any LIST commands. There MUST NOT be
 >       any other name attributes sent along with this attribute.

I suggest you review the LISTEXT extension (currently 
draft-ietf-imapext-list-extensions-10.txt).
\Deleted is the same as \NonExistent.

 >   \Renamed
 >       The mailbox has been renamed. A second LIST response MUST
 >       immediately follow indicating the new name.
[...]
 >     3) If a folder is renamed two LIST responses are sent. The first
 >     indicating the old name and a \Renamed attribute and a second
 >     response MUST immediately follow the first indicating the new name.

This might be less obvious for people not following IMAPEXT, but there 
was a proposal to have REFERRAL data returned in LIST responses. It 
serves exactly this purpose. See 
<http://www.imc.org/ietf-imapext/mail-archive/msg01921.html>, item # 5.
It also avoids the proposed hack (sorry, I can't find a better word) of 
tying two LIST responses together.

 >2.2 FETCH Response
 >
 >   Currently the FETCH response occurs as the result of a FETCH command
 >   or as an unsolicited response on an IDLE connection. This document
 >   clarifies exactly what form of response should be sent when the
 >   specified events occur on the server.
[...]
 >   New Message Arrival      
 >       An unsolicited FETCH response with envelope, body, flag and uid
 >       data MUST be sent on all IDLE connections.
 >
 >       Example:
 >          S: * 1 FETCH (UID 34 FLAGS (\Recent) ENVELOPE (...) BODY (...))

Actually no, BODY must not be in this list, as it is potentially very 
big. You surely wouldn't want to push a 10Mb message to you cell phone.
I also suggest to replace the ENVELOPE with the BODYSTRUCTURE.

 >3.1.1 Mailbox Identification Syntax
 >
 >   While in the Authenticated state there is no way to implicitly
 >   determine which mailbox the response applies to. While this is not a
 >   problem for some responses such as the LIST response it does pose a
 >   problem for responses that are mail message specific.
[...]
 >   Example:
 >      S: * 22 EXISTS (imap://mail/inbox)

Why can't we just you the STATUS response?

        S: * STATUS INBOX (MESSAGES 231 RECENT 7)

Alexey

Cc: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: Proposed agenda for IMAPEXT
Date: Sat, 6 Nov 2004 20:36:16 -0800
To: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

On Nov 6, 2004, at 10:30 AM, Alexey Melnikov wrote:

> Lisa Dusseault wrote:
> ...
>>
>> 1. Sorting, threading, and viewing (to be dealt with by one or more
>>   mechanisms)
>>  - 
>> <http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-17.txt>
>>     status: still blocked on comparator (as is i18n draft)
>
> Are you proposing that the WG discusses the i18 draft?

Not really -- just to explain the status, because I dont' think there's 
anything to discuss.  (Let me know if I'm wrong!)

lisa

Date: Sat, 06 Nov 2004 18:30:44 +0000
From: Alexey Melnikov <[email-masked]>
To: Lisa Dusseault <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Proposed agenda for IMAPEXT
Sender: [email-masked]

Lisa Dusseault wrote:

> I'm sorry this is so late, but here it is anyway.  Suggestions 
> welcome.   Note the new ACL draft link which hasn't been commented on 
> here on the  list -- if you get a chance to read that draft by Monday 
> that would be  super.
>
> Agenda for IMAPEXT meeting at 61st IETF
> Monday, Nov 8,  1530-1730
>
> 0.  Agenda bashing, find note taker and jabber scribe:
> (10 minutes)
>
> 1. Sorting, threading, and viewing (to be dealt with by one or more
>   mechanisms)
>  - <http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-17.txt>
>     status: still blocked on comparator (as is i18n draft)

Are you proposing that the WG discusses the i18 draft?

>  -  <http://www.ietf.org/internet-drafts/draft-ietf-imapext-list- 
> extensions-10.txt>
>     Barry Leiba will discuss
>     Still issues on  /Placeholder from last meeting, which Alexey and  
> Cyrus were tasked with resolving
> (40 minutes)
>
> 2. Access Control Lists
>  - <http://www.ietf.org/internet-drafts/draft-ietf-imapext-acl-10.txt>
>     Not updated since last meeting -- probably still blocked on LISTEXT.

Yes. I have some local changes, but LISTEXT and
draft-ietf-imapext-2086upd-00.txt take higher priorities right now.

>  -  
> <http://www.ietf.org/internet-drafts/draft-ietf-imapext-2086upd-00.txt>
>     READ THIS if you're coming to the meeting!  Or even if you're not.

Yes, please.

>   It hasn't been discussed on the list yet.
> (30 minutes)

I am not sure that it will take that long, I think the document is
pretty much done.

> 3. Message-level annotations
>  -  <http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate 
> -11.txt>
>     Changes since last meeting...
>     Open issue: use of the 'm' bit for ACL of private annotations

More specifically use of the "m" bit for reading of private annotations.

>     At least one more draft required
>  (40 minutes)

Hopefully this discussion would be short as well.

Date: Sat, 06 Nov 2004 16:29:57 +0000
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: STATUS command as an LISTEXT extension
Sender: [email-masked]

I don't want to start a religious war on whether STATUS should be
allowed to be a LISTEXT extension (because it can be as slow as SELECT
for some mailstores/implementations), but below I have an example of how
this might look like using existing LISTEXT syntax:

ABNF:

   return-option      =/ status-option

   status-option      = "STATUS=" status-att-comlist

   status-att-comlist = status-att *("," status-att)
                        ;; Comma separated list of status-att

   status-item-data   = "STATUS" SP "(" status-att-list ")"
                        ;; conforms to the mbox-list-extended-item-data
                        ;; syntax

Example:

       C: CA3 LIST "" "%" RETURN (STATUS=UIDVALIDITY,UIDNEXT,MESSAGES)
       S: * LIST (\Marked \NoInferiors) "/" "inbox" ((STATUS (UIDVALIDITY
           50505050 MESSAGES 231 UIDNEXT 44292)))
       S: * LIST () "/" "Foo" ((STATUS (UIDVALIDITY 467676708 MESSAGES 12
           UIDNEXT 100)))
       S: * LIST () "/" "Moo" ((STATUS (UIDVALIDITY 32 MESSAGES 711
UIDNEXT 9560)))
       S: CA3 OK done

Date: Sat, 06 Nov 2004 16:29:29 +0000
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>, "Vladimir A. Butenko" <[email-masked]>
Subject: Outstanding issues for draft-ietf-imapext-2086upd-00 (ACL)
Sender: [email-masked]

Actually, I believe there are only two. One relates to whether the "m"
right only controls writability of private annotations, or whether it
also controls readability. I've sent a separate message on this.

The second issue:

Which rights are required for the LISTRIGHTS command?

Currently the document says:

    MYRIGHTS - any of the following rights is required to perform
     the operation: "l", "r", "i", "c", "x", "a".*

    LISTRIGHTS - same as MYRIGHTS.

Some of the existing servers follow this suggestion. Some allow for
LISTRIGHTS if "r" and/or "a" is granted.

Philip has suggested (and I agree) to only allow LISTRIGHTS when the "a"
right is granted, as LISTRIGHTS information is only useful
if you can also do SETACL. Also, such information shouldn't be disclosed
to users that have insufficient rights.

Alexey

* - Note, that the STORE related rights ("w", "s", "t", "m" and "n") are
not part of this list, because the client must be able to open a mailbox
(i.e. "r") before performing a STORE command. The list also used to
contain the "e" right (which controls EXPUNGE), I've deleted it for the
same reason.

Date: Sat, 06 Nov 2004 16:29:18 +0000
From: Alexey Melnikov <[email-masked]>
To: Timo Sirainen <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Listext
Sender: [email-masked]

Timo Sirainen wrote:

> > 3.1. General principles for returning LIST responses
>
> Are these a MUST? Especially the "don't return mailbox more than once" 
> rule?

I would like to make the one you've mentioned a MUST. However it is not
going to be practical. I think they all SHOULDs.

However, if a single LIST command returns more than one extended LIST
response for a mailbox, we need to state some safe assumptions for
clients, e.g. the client can use mailbox flags from the latest LIST
response (and ignore all previous). I don't think many existing client
will be able to cope with multiple LIST responses for the same mailbox.

Alexey

Date: Sat, 06 Nov 2004 13:07:23 +0000
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: Randall Gellens <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Moving the ANNOTATE document forward
Sender: [email-masked]

Alexey Melnikov wrote:

> >   The 'm' right controls both read and write access to .priv annotation
> >   values.  When it is on, access to .priv annotations is allowed, when
> >   it is off, access to .priv annotations is disallowed.
>
> I still don't like using the "m" right for reading private 
> annotations, but we can discuss this during face to face meeting.

Ok, let me try to describe my concern.
 From the table in the ANNOTATE document:

   +===============+===============+===================================+
   |               |               |                                   |
   | No ACL        | read .priv    | Any mailbox that can be SELECTED  |
   |               | values        | or EXAMINED.                      |
   |               |               |                                   |
   +---------------+---------------+-----------------------------------+
   |               |               |                                   |
   | With ACL      | read .priv    | Any mailbox with the 'm'          |
   |               | values        | ACL right.                        |
   |               |               |                                   |
   +---------------+---------------+-----------------------------------+

Which means that a well behaving ANNOTATE&ACL-aware client needs to know 
whether the server supports ACL or not. Why? Because when the client 
opens a mailbox, it can't assume that private annotations are readable, 
because for the ACL-aware server the "m" right doesn't control if the 
mailbox can be SELECT/EXAMINEd or not.

Now, if we just say that both private and shared annotations are 
readable if the mailbox can be SELECT/EXAMINEd (i.e. the ACL "r" right), 
everything becomes much simpler (and consistent).

Cyrus has said:

 >The other benefit of 'm' as it stands now is that it gives servers a way
 >to optimise their storage because users without 'm' will never need a
 >private annotation store for that mailbox.

This may be true only for certain types of mailstores, but in general 
this is not true. Reporting any kind of annotations is trivial, whether 
the server can store them, or it just generates them on the fly (i.e. 
read-only private annotations). Checking the right "m" on FETCH just to 
make sure that private annotations can be read is just more work for the 
server. Most servers cache user's rights upon mailbox open and never try 
to refetch ACL for the selected mailbox. I.e. most servers never check 
ACLs on FETCH.

Alexey

Date: Sat, 06 Nov 2004 12:55:43 +0000
From: Alexey Melnikov <[email-masked]>
To: Timo Sirainen <[email-masked]>
CC: Cyrus Daboo <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Annotate
Sender: [email-masked]

Timo Sirainen wrote:

> On 1.11.2004, at 20:09, Cyrus Daboo wrote:
>
>>>     The 'm' right controls both read and write access to .priv 
>>> annotation
>>>     values.  When it is on, access to .priv annotations is allowed, 
>>> when
>>>     it is off, access to .priv annotations is disallowed.
>>>
>>> Is this really needed? I think private annotations should work the same
>>> way as private flags. You can always read them, and you can write 
>>> them if
>>> it's possible to permanently save flags.
>>
>> In an ACL-aware server there are different ways to control the flag 
>> state 's' and 'w' bits. As a result I think there should also be a 
>> way to enable/disable private annotations independently - hence the 
>> 'm' bit. I know Alexey had some concerns with 'm' too so this is 
>> still an open issue.
>
> Well, perhaps it would be useful to have "m" for writing because of 
> that, but I think "r" would be more logical for reading private 
> annotations.

I agree (a separate message on this is coming).

>>> I thought clients weren't allowed to make up their own annotation entry
>>> names? Or what does this mean?
>>
>>
>> If a client wants to create a 'boolean' (on/off) type property 
>> associated with a message it has two options: use an IMAP keyword 
>> (either private or registered), or create a vendor (or new standard) 
>> annotation entry. The former gives no control over private/shared 
>> state, whereas the latter does. So if there is a specific need for 
>> such a property that does need explicit private/shared behavior then 
>> the client can use annotations in lieu of IMAP keywords.
>
>
> I thought vendor namespaces meant that servers could create them, not 
> clients. Maybe put at the beginning of 2.2.1 something like:
>
> Vendor namespaces can be created by either clients or servers.

Yes.

> Servers MUST(?) support new namespaces created by clients.

I think this should be "SHOULD". We want to encourage ANNOTATE servers. 
Implementing a read-only ANNOTATE is much easier.

>> Here is some alternate text for the above paragraph that I am 
>> proposing to use instead. Note this also includes a sentence to 
>> address the first point you made:
>>
>>     Clients that need to implement a property on a message that is
>>     either 'on' or 'off' and which requires separate private and shared
>>     state can use an annotation to represent that property as opposed
>>     to using IMAP Keywords, which cannot reliably discriminate the
>>     private and shared state. However, clients MUST NOT use annotations
>>     to replace existing IMAP flag behavior, which would cause
>>     interoperability problems with non-ANNOTATE aware clients.
>>
>> If that is not suitable, please suggest some other text or 
>> clarifications.
>
> Looks good to me.

Looks good to me too.

Alexey

Date: Sat, 06 Nov 2004 00:24:44 +0000
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Updated draft-ietf-imapext-2086upd (ACL)
Sender: [email-masked]

--------------010108000909080309050706
Content-type: text/plain; charset="us-ascii"

I forgot to submit it. I think I've addressed all but one issue raised 
by Philip. I will send a separate message on this.
Apart from the issue, I think the document is ready for Last Call.

Alexey

--------------010108000909080309050706
Content-type: text/plain; name="draft-ietf-imapext-2086upd-01.txt"
Content-transfer-encoding: 7bit
Content-Disposition: inline;
 filename="draft-ietf-imapext-2086upd-01.txt"

IMAPEXT Working Group                                        A. Melnikov
Internet Draft                                                    Editor
Document: draft-ietf-imapext-2086upd-01.txt                November 2004
Updates: 2086, <<3501?>>
Expires: May 2005

                          IMAP4 ACL extension -
                        updated list of rights

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed, or
   will be disclosed, and any of which I become aware will be disclosed,
   in accordance with RFC 3668.

   Internet Drafts are working documents of the Internet Engineering
   Task Force (IETF), its Areas, and its Working Groups.  Note that
   other groups may also distribute working documents as Internet
   Drafts. Internet Drafts are draft documents valid for a maximum of
   six months.  Internet Drafts may be updated, replaced, or obsoleted
   by other documents at any time.  It is not appropriate to use
   Internet Drafts as reference material or to cite them other than as
   ``work in progress''.

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.

     Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or
     munnari.oz.au.

   A revised version of this draft document will be submitted to the RFC
   editor as a Proposed Standard for the Internet Community.  Discussion
   and suggestions for improvement are requested.  Distribution of this
   draft is unlimited.

Abstract

   The ACL (Access Control List) extension [RFC2086] of the Internet Message
   Access Protocol [IMAP4] permits mailbox access control lists to be
   manipulated through the IMAP protocol.

   This document updates the list of rights defined in RFC 2086. It
   also clarifies which rights are required for different IMAP commands.

1.   Conventions Used in this Document

   In examples, "C:" and "S:" indicate lines sent by the client and
   server respectively.

   In all examples "/" character is used as hierarchy separator.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [KEYWORDS].

2.   Introduction and Overview

   The ACL (Access Control List) extension of the Internet Message Access
   Protocol [IMAP4] permits mailbox access control lists to be retrieved
   and manipulated through the IMAP protocol.

   This document updates Section 3 of the RFC 2086. It also clarifies
   different aspects of the RFC 2086, in particular use of UTF-8 in
   identifiers, which rights are required for different IMAP4 commands;
   how READ-WRITE/READ-ONLY response codes are related to ACL>>

3.   Access Control

   This section replaces Section 3 of the RFC 2086.

   The ACL extension is present in any IMAP4 implementation which
   returns "ACL" as one of the supported capabilities to the CAPABILITY
   command.

   A server implementation conformant to this document MUST also return
   rights (see below) not defined in RFC 2086 in the "RIGHTS=" capability
   response.

   An access control list is a set of <identifier,rights> pairs.
   An ACL applies to a mailbox.

   Identifier is a UTF-8 string.  The identifier "anyone" is reserved
   to refer to the universal identity (all authentications, including
   anonymous). All user name strings accepted by the LOGIN or
   AUTHENTICATE commands to authenticate to the IMAP server are reserved
   as identifiers for the corresponding user.  Identifiers starting with
   a dash ("-") are reserved for "negative rights", described below.
   All other identifier strings are interpreted in an implementation-
   defined manner.

   Rights is a string listing a (possibly empty) set of alphanumeric
   characters, each character listing a set of operations which is being
   controlled.  Letters are reserved for ''standard'' rights, listed
   below.  The set of standard rights may only be extended by a
   standards-track document.  Digits are reserved for implementation or
   site defined rights.  The currently defined standard rights are
   (note, that the list below doesn't list all commands that use a
   particular right):

   l - lookup (mailbox is visible to LIST/LSUB commands, SUBSCRIBE mailbox)
   r - read (SELECT the mailbox, perform STATUS)
   s - keep seen/unseen information across sessions (set or clear \SEEN flag 
       via STORE, APPEND or COPY)
   w - write (set or clear flags other than \SEEN and \DELETED via STORE,
       APPEND or COPY)
   i - insert (perform APPEND, COPY into mailbox)
   p - post (send mail to submission address for mailbox,
       not enforced by IMAP4 itself.
   c - create mailboxes (CREATE new sub-mailboxes in any
       implementation-defined hierarchy, parent mailbox for the new 
       mailbox name in RENAME)
   x - delete mailbox (DELETE mailbox, old mailbox name in RENAME)
   t - delete messages (set or clear \DELETED flag via STORE, set \DELETED flag
       during APPEND/COPY)
   e - perform EXPUNGE and expunge as a part of CLOSE
   d - This right is defined for backward compatibility with ACL
       extension (RFC 2086). If a client sets "d" right, the server MUST
       set "x", "e" and "t" rights. When the client clears the "d" right,
       the server MUST clear "x", "e" and "t" rights. When all three of "x",
       "e" and "t" are set, the server MUST return "d" right in response to
       a LIST (ACL) command. If "x", "e" and "t" rights are not tied together,
       "d" right MUST NOT be returned in a LISTRIGHTS response.
   a - administer (perform SETACL/DELETEACL/GETACL)
   m - <<read/>>write private annotations [ANNOTATE]
   n - write shared annotations [ANNOTATE]

   An implementation may tie rights together or may force rights to
   always or never be granted to particular identifiers.  For example,
   in an implementation that uses unix mode bits, the rights "swite" are
   tied, the "a" right is always granted to the owner of a mailbox and
   is never granted to another user.  If rights are tied in an
   implementation, the implementation must be conservative in granting
   rights in response to SETACL commands--unless all rights in a tied
   set are specified, none of that set should be included in the ACL
   entry for that identifier. A client may discover the set of rights
   which may be granted to a given identifier in the ACL for a given
   mailbox by using the LISTRIGHTS command.

   It is possible for multiple identifiers in an access control list to
   apply to a given user (or other authentication identity).  For
   example, an ACL may include rights to be granted to the identifier
   matching the user, one or more implementation-defined identifiers
   matching groups which include the user, and/or the identifier
   "anyone".  How these rights are combined to determine the user's
   access is implementation-defined.  An implementation may choose, for
   example, to use the union of the rights granted to the applicable
   identifiers.  An implementation may instead choose, for example, to
   only use those rights granted to the most specific identifier present
   in the ACL. A client may determine the set of rights granted to the
   logged-in user for a given mailbox by using the MYRIGHTS command.

   When an identifier in an ACL starts with a dash ("-"), that indicates
   that associated rights are to be removed from the identifier that is
   prefixed by the dash. This is referred to as a "negative right". 
   This differs from DELETEACL in that a negative right is added to the
   ACL, and is a part of the calculation of the rights.

   Let's assume that an identifier "fred" refers to a user with login "fred".
   If the identifier "-fred" is granted the "w" right,
   that indicates that the "w" right is to be removed from users matching
   the identifier "fred", even though the user "fred" might have
   the "w" right as a consequence of some other identifier in the ACL.
   A DELETEACL of "fred" simply deletes the identifier "fred"
   from the ACL; it does not affect any rights that the user "fred"
   may get from another entry in the ACL.

   Server implementations are not required to support "negative right"
   identifiers.

4.   Rights required to perform different IMAP4rev1 commands

   Before executing a command an ACL compliant server must check which rights
   are required to perform it. This section groups command by functions
   they perform and list the rights required. It also gives the detailed
   description of any special processing required.

   The table below summarizes different rights or their combinations that are
   required in order to perform different IMAP operations. As it is not always
   possible to express complex right checking and interactions, the description
   after the table should be used as the primary reference.

   +---------------------+---+---+---+---+---+---+---+---+---+---+-----+------+
   | Operations\Rights   | l | r | s | w | i | c | x | t | e | a | Any | None |
   +---------------------+---+---+---+---+---+---+---+---+---+---+-----+------+
   |       LIST          | + |   |   |   |   |   |   |   |   |   |     |      |
   |    SUBSCRIBE        | * |   |   |   |   |   |   |   |   |   |     |   *  |
   |   UNSUBSCRIBE       |   |   |   |   |   |   |   |   |   |   |     |   +  |
   |       LSUB          | * |   |   |   |   |   |   |   |   |   |     |   *  |
   | CREATE (for parent) |   |   |   |   |   | + |   |   |   |   |     |      |
   |      DELETE         |   |   |   |   |   |   | + |   |   |   |     |      |
   |      RENAME         |   |   |   |   |   | + | + |   |   |   |     |      |
   |   COPY/APPEND       |   |   | ? | ? | + |   |   | ? |   |   |     |      |
   |  EXPUNGE/CLOSE      |   |   |   |   |   |   |   |   | + |   |     |      |
   |SELECT/EXAMINE/STATUS|   | + |   |   |   |   |   |   |   |   |     |      |
   |       FETCH         |   |   | ? |   |   |   |   |   |   |   |     |      |
   |    STORE flags      |   |   | ? | ? |   |   |   | ? |   |   |     |      |
   |   SETACL/DELETEACL  |   |   |   |   |   |   |   |   |   | + |     |      |
   |       GETACL        |   |   |   |   |   |   |   |   |   | + |     |      |
   | MYRIGHTS/LISTRIGHTS |   |   |   |   |   |   |   |   |   |   |  +  |      |
   +---------------------+---+---+---+---+---+---+---+---+---+---+-----+------+

   Legend:
    + - The right is required
    * - Only one of the rights marked with * is required (see description below)
    ? - The right is optional (see description below)
    "Any" - at least one of the "l", "r", "i", "c", "x", "a" rights is
            required
    "None" - No rights required to perform the command

   Listing and subscribing/unsubscribing mailboxes:
    LIST - "l" right is required.

    Note, that if the user has "l" right to a mailbox "A/B", but not to its parent
    mailbox "A", the LIST command should behave as if the mailbox "A" doesn't exist,
    for example:
               C: A777 LIST "" *
               S: * LIST (\NoInferiors) "/" "A/B"
               S: * LIST () "/" "C"
               S: * LIST (\NoInferiors) "/" "C/D"
               S: A777 OK LIST completed

    SUBSCRIBE - "l" right is required only if the server checks for mailbox existence
           when performing SUBSCRIBE.

    UNSUBSCRIBE - no rights required to perform this operation.

    LSUB - "l" right is required only if the server checks for mailbox existence when
           performing SUBSCRIBE.

   Mailbox management:
    CREATE - "c" right on a nearest existing parent mailbox. When a new
             mailbox is created it SHOULD inherit the ACL from the parent
             mailbox (if one exists) in the defined hierarchy.

    DELETE - "x" right on the mailbox.

    RENAME - Moving a mailbox from one parent to another
             requires "x" right on the mailbox itself and "c" right for
             the new parent. For example, if the user wants to rename
             mailbox named "A/B/C" to "D/E", the user must have "x" right
             for the mailbox "A/B/C" and "c" right for the mailbox "D".

             The RENAME command SHOULD NOT change the ACLs on the renamed
             mailbox and submailboxes.

   Copying or appending messages:

    Before performing a COPY/APPEND command the server MUST check if the
    user has "i" right for the target mailbox. If the user doesn't have "i"
    right, the operation fails. Otherwise for each copied/appended message
    the server MUST check if the user has
     "t" right - when the message has \Deleted flag set
     "s" right - when the message has \Seen flag set
     "w" right for all other message flags.
    Only when the user has a particular right the corresponding flags are
    stored for the newly created message. The server MUST NOT fail
    a COPY/APPEND if the user has no rights to set a particular flag.

   Example:    C: A003 MYRIGHTS TargetMailbox
               S: * MYRIGHTS TargetMailbox rwis
               S: A003 OK Myrights complete

               C: A004 FETCH 1:3 (FLAGS)
               S: * 1 FETCH (FLAGS (\Draft \Deleted)
               S: * 2 FETCH (FLAGS (\Answered)
               S: * 3 FETCH (FLAGS ($Forwarded \Seen)
               S: A004 OK Fetch Completed

               C: A005 COPY 1:3 TargetMailbox
               S: A005 OK Copy completed

               C: A006 SELECT TargetMailbox
                  ...
               S: A006 Select Completed

       Let's assume that the copied messages received message numbers 77:79.

               C: A007 FETCH 77:79 (FLAGS)
               S: * 77 FETCH (FLAGS (\Draft))
               S: * 78 FETCH (FLAGS (\Answered))
               S: * 79 FETCH (FLAGS ($Forwarded \Seen))
               S: A007 OK Fetch Completed

       \Deleted flag was lost on COPY, as the user has no "t" right in the
       target mailbox.

       If the MYRIGHTS command with the tag A003 would have returned:
               S: * MYRIGHTS TargetMailbox rsti

       the response from the FETCH with the tag A007 would have been:

               C: A007 FETCH 77:79 (FLAGS)
               S: * 77 FETCH (FLAGS (\Deleted))
               S: * 78 FETCH (FLAGS ())
               S: * 79 FETCH (FLAGS (\Seen))
               S: A007 OK Fetch Completed

       In the latter case \Answered, $Forwarded and \Draft flags were lost
       on COPY, as the user has no "w" right in the target mailbox.

   Expunging the selected mailbox:
    EXPUNGE - "e" right on the selected mailbox.

    CLOSE - "e" right on the selected mailbox. If the server is unable to
            expunge the mailbox because the user doesn't have the "e" right,
            the server MUST ignore expunge request, close the mailbox
            and return tagged OK response.

   Fetch information about a mailbox and its messages:
    SELECT/EXAMINE/STATUS - "r" right on the mailbox.

    FETCH - A FETCH request that implies setting \Seen flag MUST NOT set it,
            if the current user doesn't have "s" right.

   Changing flags:
    STORE - the server MUST check if the user has
     "t" right - when the user modifies \Deleted flag
     "s" right - when the user modifies \Seen flag
     "w" right for all other message flags.
     STORE operation SHOULD NOT fail if the user has rights to modify at least
     one flag specified in the STORE, as the tagged NO response to a STORE
     command is not handled very well by deployed clients.

   Changing ACLs:
    SETACL/DELETEACL - "a" right on the mailbox.

   Reading ACLs:
    GETACL - "a" right on the mailbox.

    MYRIGHTS - any of the following rights is required to perform
     the operation: "l", "r", "i", "c", "x", "a".

<<A previous version included "e" in the list. This explanation will be deleted
before publication:

Is there a particular reason why "s", "w", "t", "m" and "n" are excluded from
this list? - Yes, because flags can't be changed unless the "r" is also granted
(i.e. the mailbox can be SELECTed/EXAMINEd). But the same applies to "e"!>>

    LISTRIGHTS - same as MYRIGHTS. <<?>> <<Same rights as for GETACL?>>

5.   Formal Syntax

   This document doesn't change the formal syntax of commands/
   responses defined in the Section 6 of RFC 2086. However,
   the "identifier" production is now allowed to carry any UTF-8 string.

   Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4].
   Non-terminals referenced but not defined below are as defined by
   [IMAP4] or [LISTEXT].

   Except as noted otherwise, all alphabetic characters are
   case-insensitive.  The use of upper or lower case characters to
   define token strings is for editorial clarity only.  Implementations
   MUST accept these strings in a case-insensitive fashion.

   rights_capa      = "RIGHTS=" new_rights
                      ;; RIGHTS=... capability

   new_rights       = atom
                      ;; MUST include "t", "e", "x", "m" and "n"

6.   Security Considerations

   An implementation must make sure the ACL commands themselves do not
   give information about mailboxes with appropriately restricted ACL's.
   For example, a GETACL command on a mailbox for which the user has
   insufficient rights should not admit that the mailbox exists, much less
   return the mailbox's ACL.

   LISTRIGHTS command MUST NOT check that a particular identifier exists,
   however it SHOULD recognize special identifiers like "anyone".

   IMAP clients implementing ACL that are able to modify ACLs SHOULD
   warn a user that wants to give full access (or even just "a" right)
   to the special identifier "anyone".

7.  Other considerations

7.1. Additional requirements and Implementation notes

7.1.1. Servers

   This document defines an additional capability that is used to announce
   the list of extra rights (excluding the ones defined in the RFC 2086)
   supported by the server. The set of rights MUST include "t", "e", "x", "m"
   and "n". Note, that the extra rights can appear in any order.

   Example:    C: 1 capability
               S: * CAPABILITY IMAP4REV1 STARTTLS LITERAL+ ACL RIGHTS=texnm
               S: 1 OK completed

   The presence of the "RIGHTS=" capability also declares that the server
   always returns the MYRIGHTS untagged response upon SELECT/EXAMINE.
   The MYRIGHTS response SHOULD also be sent any time when the server detects
   that the set of rights allowed for the logged in user in the opened
   mailbox has changed.

   Any server implementing an ACL extension MUST accurately reflect the current
   user's rights in FLAGS and PERMANENTFLAGS responses.

   Example:    C: A142 SELECT INBOX
               S: * 172 EXISTS
               S: * 1 RECENT
               S: * MYRIGHTS INBOX rwis
               S: * OK [UNSEEN 12] Message 12 is first unseen
               S: * OK [UIDVALIDITY 3857529045] UIDs valid
               S: * OK [UIDNEXT 4392] Predicted next UID
               S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
               S: * OK [PERMANENTFLAGS (\Seen \Answered \Flagged \*)] Limited
               S: A142 OK [READ-WRITE] SELECT completed

   Servers MAY cache the rights a user has on a mailbox when the mailbox
   is selected, so that if a client's rights on a mailbox are changed with
   SETACL or DELETEACL, commands specific to the selected state (e.g., STORE,
   EXPUNGE) might not reflect the changed rights until the mailbox is
   re-selected. If the server checks the rights on each command, then it SHOULD
   send FLAGS and PERMANENTFLAGS responses if they have changed.

   An ACL server MAY modify one or more ACL for one or more identifier as a
   side effect of modifying the ACL specified in a SETACL/DELETEACL.
   If the server does that it MUST send untagged ACL response to notify the
   client about the changes made.

7.1.2. Clients

   A client implementation that allows a user to read and update ACLs MUST
   preserve unrecognized rights that it doesn't allow the user to change
   when updating the rights. Otherwise the client may unintentionally remove
   permissions.

7.2. Mapping of ACL rights to READ-WRITE and READ-ONLY response codes

   A particular ACL server implementation may allow "shared multiuser
   access" to some mailboxes. "Shared multiuser access" to a mailbox means
   that multiple different users are able to access the same mailbox,
   if they have proper access rights. "Shared multiuser access" to the
   mailbox doesn't mean that the ACL for the mailbox is currently set
   to allow access by multiple users. Let's denote a "shared multiuser
   write access" as a "shared multiuser access" when a user may be
   granted flag modification rights (any of "w", "s" or "t").

   Section 4 describes which rights are required for modifying different flags.

   If the ACL server implements some flags as shared for a mailbox (i.e.,
   the ACL for the mailbox may be set up so that changes to those flags are
   visible to another user), let's call the set of rights associated with these
   flags (as described in Section 4) for that mailbox collectively as
   "shared flag rights". Note, that "shared flag rights" set MAY be different
   for different mailboxes.

   If the server doesn't support "shared multiuser write access" to a
   mailbox or doesn't implement shared flags on the mailbox, "shared flag
   rights" for the mailbox is defined to be the empty set.

   Example 1: Mailbox "banan" allows "shared multiuser write access" and
              implements flags \Deleted, \Answered and $MDNSent as
              shared flags. "Shared flag rights" for the mailbox "banan"
              is a set containing flags "t" (because system flag \Deleted
              requires "t" right) and "w" (because both \Answered and
              $MDNSent require "w" right).

   Example 2: Mailbox "apple" allows "shared multiuser write access" and
              implements \Seen system flag as shared flag. "Shared flag
              rights" for the mailbox "apple" contains "s" right,
              because system flag \Seen requires "s" right.

   Example 3: Mailbox "pear" allows "shared multiuser write access" and
              implements flags \Seen, \Draft as shared flags. "Shared flag
              rights" for the mailbox "apple" is a set containing flags "s"
              (because system flag \Seen requires "s" right) and "w"
              (because system flag \Draft requires "w" right).

   The server MUST include a READ-ONLY prefix in the tagged OK response to
   a SELECT command if none of the following rights is granted to the
   current user:
    "i", "e" and "shared flag rights".
   The server SHOULD include a READ-WRITE prefix in the tagged OK response
   if at least one of the "i", "e" or "shared flag rights" is granted to the
   current user.

   Example 1 (continued): The user that has "lrs" rights for the mailbox
                          "banan". The server returns READ-ONLY response
                          code on SELECT, as none of "iewt" rights is
                          granted to the user.

   Example 2 (continued): The user that has "rit" rights for the mailbox
                          "apple". The server returns READ-WRITE response
                          code on SELECT, as the user has "i" right.

   Example 3 (continued): The user that has "rset" rights for the mailbox
                          "pear". The server returns READ-WRITE response
                          code on SELECT, as the user has "e" and "s" rights.

8.   References

8.1.   Normative References

   [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
   Requirement Levels", RFC 2119, Harvard University, March 1997.

   [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
   ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd,
   November 1997.

   [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
   4rev1", RFC 3501, University of Washington, March 2003.

   [RFC2086] Myers, J., "IMAP4 ACL extension", RFC 2086, Carnegie Mellon,
   January 1997

   [UTF-8] Yergeau, F., "UTF-8, a transformation format of IS0 10646",
   RFC 2279, Alis Technologies, January 1998.

8.2.   Informative References

   [ANNOTATE] Gellens, R. and C. Daboo, "IMAP ANNOTATE Extension",
   work in progress, draft-ietf-imapext-annotate-XX.txt

9.   Acknowledgment

   This document is an update to the RFC 2086 written by John G. Myers.

   Editor appreciates comments received from Mark Crispin, Chris Newman,
   Cyrus Daboo, John G. Myers, Steve Hole, Curtis King, Lyndon Nerenberg,
   Larry Greenfield, Robert Siemborski, Vladimir Butenko, Dave Cridland,
   Harrie Hazewinkel, Philip Guenther and other participants of the IMAPEXT
   working group.

10.  Editor's Address

   Alexey Melnikov
   email: [email-masked]

   Isode Limited

11.  IPR Disclosure Acknowledgement

    By submitting this Internet-Draft, I certify that any applicable
    patent or other IPR claims of which I am aware have been disclosed,
    and any of which I become aware will be disclosed, in accordance with
    RFC 3668.

12.  Intellectual Property Statement

    The IETF takes no position regarding the validity or scope of any
    intellectual property or other rights that might be claimed to
    pertain to the implementation or use of the technology described in
    this document or the extent to which any license under such rights
    might or might not be available; neither does it represent that it
    has made any effort to identify any such rights. Information on the
    IETF's procedures with respect to rights in standards-track and
    standards-related documentation can be found in BCP-11. Copies of
    claims of rights made available for publication and any assurances of
    licenses to be made available, or the result of an attempt made to
    obtain a general license or permission for the use of such
    proprietary rights by implementors or users of this specification can
    be obtained from the IETF Secretariat.

    The IETF invites any interested party to bring to its attention any
    copyrights, patents or patent applications, or other proprietary
    rights which may cover technology that may be required to practice
    this standard. Please address the information to the IETF Executive
    Director.

13.  Full Copyright Statement

    Copyright (C) The Internet Society (2004).  This document is subject
    to the rights, licenses and restrictions contained in BCP 78 and
    except as set forth therein, the authors retain all their rights.

    This document and the information contained herein are provided on an
    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

    Funding for the RFC Editor function is currently provided by the
    Internet Society.

Appendix A. Changes since RFC 2086

   1. Changed the charset of "identifier" from US-ASCII to UTF-8.

   2. Specified that mailbox deletion is controled by the "x" right and
      EXPUNGE is controlled by the "e" right.

   3. Clarified that RENAME requires the "c" right for the new parent and
      the "x" right for the old name.

   4. Added the "t" right that controls STORE \Deleted. Redefined "d"
      to be a macro for "e", "x" and "t".

   5. Specified that the "a" right also controls DELETEACL.

   6. Specified that the "r" right also controls STATUS.

   7. Removed the requirement to check the "r" right for CHECK, SEARCH and
      FETCH, as this is required for SELECT/EXAMINE to be successful.

   8. LISTRIGHTS requires same rights as MYRIGHTS.

   9. Deleted "PARTIAL", this is a deprecated feature of RFC1730.

  10. Specified that the "w" right controls setting flags other than \Seen
      and \Deleted on APPEND. Also specified that the "s" right controls
      the \Seen flag and that the "t" right controls the \Deleted flag.

  11. SUBSCRIBE is NOT allowed with the "r" right.

  12. Specified that the "l" right controls SUBSCRIBE.

  13. GETACL is NOT allowed with the "r" right, even though there are
      several implementations that allows that. If a user only has "r"
      right, GETACL can disclose information about identifiers existing
      on the mail system.

  14. Added new section that describes which rights are required and/or
      checked when performing various IMAP commands.

  15. Added mail client security considerations when dealing with special
      identifier "anyone".

  16. Clarified that negative rights are not the same as DELETEACL.

  17. Added note that a server can modify an ACL for any identifier(s) as a
      side effect of performing SETACL/DELETEACL. Also specified that
      the server MUST send untagged ACL response if it does that.

  18. Added section about mapping of ACL rights to READ-WRITE and READ-ONLY
      response codes.

  19. Added "Compatibility with RFC 2086" section.

  20. Added "Implementation Notes" section.

  21. Updated "References" section.

  22. Added requirement for a SELECT/EXAMINE to return the MYRIGHTS
      response.

  23. Added the "m" and "n" rights for ANNOTATE.

Appendix B. Compatibility with RFC 2086

   This section gives guidelines how an existing RFC 2086 server
   implementation may be updated to comply with this document.

   This document replaces the "d" right with 3 new different rights "x",
   "t" and "e". The server should implement one of the following two
   approaches to handle "d" and the new rights that have replaced it.

    a). Tie "x", "t" and "e" together - almost no changes.
    b). Implement separate "x", "t" and "e". Return "d" right in a LIST
        response containing ACL information when all three of "x", "t"
        and "e" are granted.

   Additional work required to implement ACL2 when RFC 2086 is already
   implemented:

   1). Send the MYRIGHTS untagged response on a successful SELECT/EXAMINE.

   Also check Sections 7.1 and 7.2, as well as the appendix A to see
   other changes required. Server implementors should check which rights
   are required to invoke different IMAP4 commands as described in
   Section 4.

--------------010108000909080309050706--

Date: Sat, 06 Nov 2004 14:42:41 +0100
From: kael <[email-masked]>
To: [email-masked]
Subject: Question about the SORT and THREAD extensions 
Sender: [email-masked]

Hello,

Can [could] the SORT and THREAD extensions handle messages like this 
http://www.deftone.com/blogzilla/archives/new_thunderbird_feature_message_grouping.html 
?

-- 
kael

http://del.icio.us/ubi.quito.us

To: [email-masked], IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Proposed agenda for IMAPEXT
Date: Fri, 5 Nov 2004 13:10:04 -0800
Sender: [email-masked]

I'm sorry this is so late, but here it is anyway.  Suggestions welcome.  
  Note the new ACL draft link which hasn't been commented on here on the  
list -- if you get a chance to read that draft by Monday that would be  
super.

Agenda for IMAPEXT meeting at 61st IETF
Monday, Nov 8,  1530-1730

0.  Agenda bashing, find note taker and jabber scribe:
(10 minutes)

1. Sorting, threading, and viewing (to be dealt with by one or more
   mechanisms)
  - <http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-17.txt>
     status: still blocked on comparator (as is i18n draft)
  -  
<http://www.ietf.org/internet-drafts/draft-ietf-imapext-list- 
extensions-10.txt>
     Barry Leiba will discuss
     Still issues on  /Placeholder from last meeting, which Alexey and  
Cyrus were tasked with resolving
(40 minutes)

2. Access Control Lists
  - <http://www.ietf.org/internet-drafts/draft-ietf-imapext-acl-10.txt>
     Not updated since last meeting -- probably still blocked on LISTEXT.
  -  
<http://www.ietf.org/internet-drafts/draft-ietf-imapext-2086upd-00.txt>
     READ THIS if you're coming to the meeting!  Or even if you're not.  
It hasn't been discussed on the list yet.
(30 minutes)

3. Message-level annotations
  -  
<http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate 
-11.txt>
     Changes since last meeting...
     Open issue: use of the 'm' bit for ACL of private annotations
     At least one more draft required
  (40 minutes)

Date: Fri, 05 Nov 2004 16:26:39 +0000
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>, [email-masked]
Subject: Not being able to attend IMAPEXT/Lemonade
Sender: [email-masked]

Due to little trick that UK Home Office has played on me, I am still not 
in possession of my passport. My flight is tomorrow at noon. So I will 
most likely miss the IMAPEXT and Lemonade meetings. I will try to 
participate in jabber.

Alexey

Cc: IMAP Extensions WG <[email-masked]>
From: Timo Sirainen <[email-masked]>
Subject: Re: Annotate
Date: Mon, 1 Nov 2004 20:44:09 +0200
To: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

--Apple-Mail-16-768365339
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

On 1.11.2004, at 20:09, Cyrus Daboo wrote:

>>     The 'm' right controls both read and write access to .priv 
>> annotation
>>     values.  When it is on, access to .priv annotations is allowed, 
>> when
>>     it is off, access to .priv annotations is disallowed.
>>
>> Is this really needed? I think private annotations should work the 
>> same
>> way as private flags. You can always read them, and you can write 
>> them if
>> it's possible to permanently save flags.
>
> In an ACL-aware server there are different ways to control the flag 
> state 's' and 'w' bits. As a result I think there should also be a way 
> to enable/disable private annotations independently - hence the 'm' 
> bit. I know Alexey had some concerns with 'm' too so this is still an 
> open issue.

Well, perhaps it would be useful to have "m" for writing because of 
that, but I think "r" would be more logical for reading private 
annotations.

>> I thought clients weren't allowed to make up their own annotation 
>> entry
>> names? Or what does this mean?
>
> If a client wants to create a 'boolean' (on/off) type property 
> associated with a message it has two options: use an IMAP keyword 
> (either private or registered), or create a vendor (or new standard) 
> annotation entry. The former gives no control over private/shared 
> state, whereas the latter does. So if there is a specific need for 
> such a property that does need explicit private/shared behavior then 
> the client can use annotations in lieu of IMAP keywords.

I thought vendor namespaces meant that servers could create them, not 
clients. Maybe put at the beginning of 2.2.1 something like:

Vendor namespaces can be created by either clients or servers. Servers 
MUST(?) support new namespaces created by clients.

> Here is some alternate text for the above paragraph that I am 
> proposing to use instead. Note this also includes a sentence to 
> address the first point you made:
>
> 	Clients that need to implement a property on a message that is
> 	either 'on' or 'off' and which requires separate private and shared
> 	state can use an annotation to represent that property as opposed
> 	to using IMAP Keywords, which cannot reliably discriminate the
> 	private and shared state. However, clients MUST NOT use annotations
> 	to replace existing IMAP flag behavior, which would cause
> 	interoperability problems with non-ANNOTATE aware clients.
>
> If that is not suitable, please suggest some other text or 
> clarifications.

Looks good to me.

--Apple-Mail-16-768365339
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

--Apple-Mail-16-768365339--

Date: Mon, 01 Nov 2004 13:09:06 -0500
From: Cyrus Daboo <[email-masked]>
To: Timo Sirainen <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Annotate
Sender: [email-masked]

Hi Timo,

--On Monday, November 1, 2004 7:27:45 PM EST +0200 Timo Sirainen 
<[email-masked]> wrote:

> Some comments:
>
>     Clients MUST NOT use annotations in lieu of equivalent IMAP base
>     specification facilities.  For example, use of a "seen" flag in the
>     vendor namespace together with ".PEEK" in fetches.  Such behaviour
>     would significantly reduce IMAP interoperability.
>
> I don't understand the example. What does .PEEK fetches have to do with
> \Seen flag, except without it the \Seen flag might change?

In this example we are saying that a 'rogue' client might choose to bypass 
the standard IMAP seen behavior by using .PEEK fetches (that do not change 
the IMAP \Seen flag) and instead use their own private seen annotation that 
is used to indicate seen state in that client. That hurts interop because a 
message that appears seen in one client, does not appear seen in another.

What I think will be best is to remove the text you quoted, and instead 
insert a comment in the flags section (actually this will appear in the new 
text I propose below in response to your last point).

>     If a server supports annotations, then it MUST store all annotation
>     data permanently, i.e.  there is no concept of 'session only'
>     annotations that would correspond to the behaviour of 'session' flags
>     as defined in the IMAP base specification.  The exception to this is
>     IMAP flags (which are accessible directly through annotations) which
>     may be 'session only' as determined by the FLAGS and PERMANENTFLAGS
>     responses to a SELECT or EXAMINE command.
>
> Since IMAP flags can no longer be modified with ANNOTATE, the exception
> should probably be removed.

OK, I will remove that last sentence.

>     The 'm' right controls both read and write access to .priv annotation
>     values.  When it is on, access to .priv annotations is allowed, when
>     it is off, access to .priv annotations is disallowed.
>
> Is this really needed? I think private annotations should work the same
> way as private flags. You can always read them, and you can write them if
> it's possible to permanently save flags.

In an ACL-aware server there are different ways to control the flag state 
's' and 'w' bits. As a result I think there should also be a way to 
enable/disable private annotations independently - hence the 'm' bit. I 
know Alexey had some concerns with 'm' too so this is still an open issue.

>     /flags
>        Defines the top-level of entries for flags associated with an
>        entire message.  The "value" attribute of each of the entries
>        described below must be either "1", "0" or NIL.  "1" corresponds
>        to the flag being set.
>
> NIL isn't defined here. Does it mean "not set"? For example:

NIL should be removed. The flag value must be either 1 or 0, and both .priv 
and .shared will be the same. NIL only made sense when annotate was 
discriminating  between private/shared flag behavior, which it no longer 
does.

>     Clients that need to implement shared and private 'flags' can create
>     their own annotation entries for those, completely bypassing the base
>     IMAP flag/keyword behaviour.
>
> I thought clients weren't allowed to make up their own annotation entry
> names? Or what does this mean?

If a client wants to create a 'boolean' (on/off) type property associated 
with a message it has two options: use an IMAP keyword (either private or 
registered), or create a vendor (or new standard) annotation entry. The 
former gives no control over private/shared state, whereas the latter does. 
So if there is a specific need for such a property that does need explicit 
private/shared behavior then the client can use annotations in lieu of IMAP 
keywords.

Here is some alternate text for the above paragraph that I am proposing to 
use instead. Note this also includes a sentence to address the first point 
you made:

	Clients that need to implement a property on a message that is
	either 'on' or 'off' and which requires separate private and shared
	state can use an annotation to represent that property as opposed
	to using IMAP Keywords, which cannot reliably discriminate the
	private and shared state. However, clients MUST NOT use annotations
	to replace existing IMAP flag behavior, which would cause
	interoperability problems with non-ANNOTATE aware clients.

If that is not suitable, please suggest some other text or clarifications.
-- 
Cyrus Daboo

To: IMAP Extensions WG <[email-masked]>
From: Timo Sirainen <[email-masked]>
Subject: Annotate
Date: Mon, 1 Nov 2004 19:27:45 +0200
Sender: [email-masked]

--Apple-Mail-15-763781542
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

Some comments:

    Clients MUST NOT use annotations in lieu of equivalent IMAP base
    specification facilities.  For example, use of a "seen" flag in the
    vendor namespace together with ".PEEK" in fetches.  Such behaviour
    would significantly reduce IMAP interoperability.

I don't understand the example. What does .PEEK fetches have to do with 
\Seen flag, except without it the \Seen flag might change?

    If a server supports annotations, then it MUST store all annotation
    data permanently, i.e.  there is no concept of 'session only'
    annotations that would correspond to the behaviour of 'session' flags
    as defined in the IMAP base specification.  The exception to this is
    IMAP flags (which are accessible directly through annotations) which
    may be 'session only' as determined by the FLAGS and PERMANENTFLAGS
    responses to a SELECT or EXAMINE command.

Since IMAP flags can no longer be modified with ANNOTATE, the exception 
should probably be removed.

    The 'm' right controls both read and write access to .priv annotation
    values.  When it is on, access to .priv annotations is allowed, when
    it is off, access to .priv annotations is disallowed.

Is this really needed? I think private annotations should work the same 
way as private flags. You can always read them, and you can write them 
if it's possible to permanently save flags.

    /flags
       Defines the top-level of entries for flags associated with an
       entire message.  The "value" attribute of each of the entries
       described below must be either "1", "0" or NIL.  "1" corresponds
       to the flag being set.

NIL isn't defined here. Does it mean "not set"? For example:

/flags/\Seen.shared = 1
/flags/\Seen.private = NIL
  -> private \Seen flag set

/flags/\Seen.shared = 1
/flags/\Seen.private = 0
  -> private \Seen flag not set

Or should server do this internally and always return 1/0 seen flag? So 
NIL would only be useful for shared? Or should it also there default to 
1/0?

    Clients that need to implement shared and private 'flags' can create
    their own annotation entries for those, completely bypassing the base
    IMAP flag/keyword behaviour.

I thought clients weren't allowed to make up their own annotation entry 
names? Or what does this mean?

--Apple-Mail-15-763781542
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

--Apple-Mail-15-763781542--