Subject: Re: Storing annotations colours on IMAP servers
From: Lisa Dusseault <[email-masked]>
To: kael <[email-masked]>
Cc: [email-masked]
Date: Thu, 30 Dec 2004 11:26:47 -0800
List-Id: <ietf-imapext.imc.org>

I imagine users wouldn't define annotations in any case; client 
developers would, and as you suggest, it's possible to standardize a 
name for the colour annotation as well as a syntax.  That work isn't 
within the charter of this WG but this is probably a decent place to 
try to drum up participation.

I can't think of any way to synchronize colours with current MUAs.  
They're already deployed with support only for adding their own 
colouring and storing it locally, as you illustrate with Thunderbird 
and Mulberry.

Lisa

On Dec 30, 2004, at 11:14 AM, kael wrote:

> On 30.12.2004 19:17, Lisa Dusseault wrote:
>> The annotate draft  
>> <http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate 
>> -11.txt> allows client-specific annotations to be added to the mail  
>> store, if the server supports it.  You could either define a  
>> proprietary annotation (and not share colour information with other  
>> clients, but make it available to be synchronized via the server) or  
>> work out some agreed scheme which other clients could use as well.
>
> How could colors be synchronized with (current) MUAs ?
>
> Actually, I was thinking that IMAP servers could have the ability to 
> store that kind of information _by default_ which could help to make 
> "gains productivity".
>
> Users would have neither to define annotations name nor their color 
> each time they configure a MUA.
>
> This page http://researchweb.watson.ibm.com/history/index.htm gave me 
> the idea - visualization tools are very useful when they use colors.
>
> Currently, it's great to use IMAP: nomad users configure the MUA and 
> get all their emails. But each time, users have to re-configure 
> keywords name and colors - personal experience with Mulberry and 
> Thunderbird's labels, unfortunately not interoperable (or compatible 
> ?).
>
> So waiting for the /ACAP Renaissance/, maybe IMAP could help and 
> annotations colors could be standardized  - maybe as "attributes" ?
>
> -- 
> kael -- http://kevan.org/extispicious.cgi?name=ubi.quito.us
>
> "We're in the process of creating a planetary nervous system"
> _The network is the blog_ by Jon Udell -
> http://weblog.infoworld.com/udell/2004/12/17.html#a1136

Date: Thu, 30 Dec 2004 20:14:54 +0100
From: kael <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Cc: [email-masked]
Subject: Re: Storing annotations colours on IMAP servers
Sender: [email-masked]

On 30.12.2004 19:17, Lisa Dusseault wrote:
> The annotate draft  
> <http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate 
> -11.txt> allows client-specific annotations to be added to the mail  
> store, if the server supports it.  You could either define a  
> proprietary annotation (and not share colour information with other  
> clients, but make it available to be synchronized via the server) or  
> work out some agreed scheme which other clients could use as well.

How could colors be synchronized with (current) MUAs ?

Actually, I was thinking that IMAP servers could have the ability to 
store that kind of information _by default_ which could help to make 
"gains productivity".

Users would have neither to define annotations name nor their color each 
time they configure a MUA.

This page http://researchweb.watson.ibm.com/history/index.htm gave me 
the idea - visualization tools are very useful when they use colors.

Currently, it's great to use IMAP: nomad users configure the MUA and get 
all their emails. But each time, users have to re-configure keywords 
name and colors - personal experience with Mulberry and Thunderbird's 
labels, unfortunately not interoperable (or compatible ?).

So waiting for the /ACAP Renaissance/, maybe IMAP could help and 
annotations colors could be standardized  - maybe as "attributes" ?

-- 
kael -- http://kevan.org/extispicious.cgi?name=ubi.quito.us

"We're in the process of creating a planetary nervous system"
_The network is the blog_ by Jon Udell -
http://weblog.infoworld.com/udell/2004/12/17.html#a1136

Cc: [email-masked]
From: Lisa Dusseault <[email-masked]>
Subject: Re: Storing annotations colours on IMAP servers
Date: Thu, 30 Dec 2004 10:17:54 -0800
To: kael <[email-masked]>
Sender: [email-masked]

The annotate draft  
<http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate 
-11.txt> allows client-specific annotations to be added to the mail  
store, if the server supports it.  You could either define a  
proprietary annotation (and not share colour information with other  
clients, but make it available to be synchronized via the server) or  
work out some agreed scheme which other clients could use as well.

Lisa

On Dec 29, 2004, at 1:02 AM, kael wrote:

>
> Hello,
>
> Could annotations (and keywords) colours be stored on IMAP servers ?
>
> Thank you very much.
>
> -- 
> kael
>

Date: Wed, 29 Dec 2004 10:02:46 +0100
From: kael <[email-masked]>
To: [email-masked]
Subject: Storing annotations colours on IMAP servers
Sender: [email-masked]

Hello,

Could annotations (and keywords) colours be stored on IMAP servers ?

Thank you very much.

-- 
kael

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Fwd: Interim Meeting for IMAPEXT
Date: Tue, 28 Dec 2004 11:22:27 -0800
Sender: [email-masked]

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

I got the interim meeting announcement in just under the wire... *whew*

Please continue to let me know if you plan to attend or what you'd like 
to discuss.  So far, Barry Leiba, Randy Gellens, Alexey Melnikov and I 
are on the side of probably attending, and Mark and Cyrus on the side 
of probably not attending.   That means we'll have all the authors of 
LISTEXT and half the authors of ANNOTATE, available to heckle them 
about their draft lateness :)

We may also discuss 2086upd but only if something surprising turns up.  
So far it looks like the last call is generating some changes but 
nothing requiring a reset.

Stephane Maes is kindly looking into letting us use the same Oracle 
space that the Lemonade WG is using.

Lisa

Begin forwarded message:

> From: Lisa Dusseault <[email-masked]>
> Date: December 21, 2004 11:31:05 AM PST
> To: [email-masked]
> Cc: Subject: Interim Meeting for IMAPEXT
>
> We are organizing an interim meeting for IMAPEXT in the San Francisco
> Bay Area for the afternoon of Jan 20. (The meeting location and time
> will be alongside the LEMONADE WG interim meeting which has an
> overlapping membership).
>
> I've already announced this intent on the IMAPEXT mailing list and
> would like to announce it more widely even though we don't as yet know
> the exact location.
>
> Scott Hollenbeck has indicated his approval.
>
> Location: TBD, near San Francisco/Redwood Shores, CA
> Date: Jan 20, 2:00 pm to 5:00 pm
> Hotel: See LEMONADE WG interim meeting information
>
> Agenda (Draft)
> ===========
>
> - resolve ANNOTATE open issues with authors
> - Discuss LISTEXT extensions
> - Resume work on ACL draft
>
>
> --Thanks,
> Lisa Dusseault
>
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce

--Apple-Mail-4--746987174
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=US-ASCII

I got the interim meeting announcement in just under the wire...
*whew*  

Please continue to let me know if you plan to attend or what you'd
like to discuss.  So far, Barry Leiba, Randy Gellens, Alexey Melnikov
and I are on the side of probably attending, and Mark and Cyrus on the
side of probably not attending.   That means we'll have all the
authors of LISTEXT and half the authors of ANNOTATE, available to
heckle them about their draft lateness :)

We may also discuss 2086upd but only if something surprising turns up. 
So far it looks like the last call is generating some changes but
nothing requiring a reset.

Stephane Maes is kindly looking into letting us use the same Oracle
space that the Lemonade WG is using.

Lisa

Begin forwarded message:

<excerpt><bold><color><param>0000,0000,0000</param>From:
</color></bold>Lisa Dusseault <<[email-masked]>

<bold><color><param>0000,0000,0000</param>Date:
</color></bold>December 21, 2004 11:31:05 AM PST

<bold><color><param>0000,0000,0000</param>To:
</color></bold>[email-masked]

<bold><color><param>0000,0000,0000</param>Cc: Subject: </color>Interim
Meeting for IMAPEXT

</bold>

We are organizing an interim meeting for IMAPEXT in the San Francisco

Bay Area for the afternoon of Jan 20. (The meeting location and time

will be alongside the LEMONADE WG interim meeting which has an

overlapping membership).

I've already announced this intent on the IMAPEXT mailing list and

would like to announce it more widely even though we don't as yet know

the exact location.

Scott Hollenbeck has indicated his approval.

Location: TBD, near San Francisco/Redwood Shores, CA

Date: Jan 20, 2:00 pm to 5:00 pm

Hotel: See LEMONADE WG interim meeting information

Agenda (Draft)

===========

- resolve ANNOTATE open issues with authors

- Discuss LISTEXT extensions

- Resume work on ACL draft

--Thanks,

Lisa Dusseault

_______________________________________________

IETF-Announce mailing list

[email-masked]

https://www1.ietf.org/mailman/listinfo/ietf-announce

</excerpt>
--Apple-Mail-4--746987174--

Date: Sat, 25 Dec 2004 10:42:49 +0000
From: Alexey Melnikov <[email-masked]>
To: Rob Siemborski <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: WG last call for IMAP ACL small-scope changes (RFC2086bis)
Sender: [email-masked]

Rob Siemborski wrote:

> On Wed, 8 Dec 2004, Lisa Dusseault wrote:
>
>> I call your attention to this draft:
>>
>> http://www.ietf.org/internet-drafts/draft-ietf-imapext-2086upd-02.txt
>
> Sorry I've been absent from the list -- I've been rearranging my life 
> for the last few months.  Its likely I'd be able to make the interim 
> meeting if it happens.
>
> I'm really glad to see this work being done :)
>
> 1 note:
>
> 3)
>    A server implementation conformant to this document MUST also return
>    rights (see below) not defined in RFC 2086 in the "RIGHTS=" capability
>    response.
>
> The ABNF for this indicates that digits are also allowed, yet digits 
> are technically "defined" as "optional" in RFC2086.  Can this be 
> clarified to indicate that it includes only optional rights that are 
> implemented by the server, or that this applies to only standard 
> rights (and thus the ABNF is fixed).
>
> I'm not convinced that the client is able to do anything with 
> knowledge of optional rights that are implemented by the server 
> without more context, and since they are already defined in 2086, I 
> think I lean towards the later, but I'm willing to hear other opinions.

Ok, here is my change to address this issue:

In section 3:

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

Added new section 3.2:

3.2.   Rights defined in RFC 2086.

   For convenience, this section lists the rights which were defined in
   the RFC 2086:
    "l", "r", "s", "w", "i", "p", "a", "c", "d" and digit rights
    ("0" .. "9").

   The listed rights MUST NOT be returned in the "RIGHTS=" capability
   string.

Updated ABNF:

   new_rights      = 1*LOWER_ALPHA
                      ;; MUST include "t", "e", "x" and "k".
                      ;; MUST NOT include standard rights listed
                      ;; in section 3.2
...
   rights_capa     = "RIGHTS=" new_rights
                      ;; RIGHTS=... capability

Date: Fri, 24 Dec 2004 11:18:37 +0000
From: Alexey Melnikov <[email-masked]>
To: Rob Siemborski <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: WG last call for IMAP ACL small-scope changes (RFC2086bis)
Sender: [email-masked]

Rob Siemborski wrote:

> On Wed, 22 Dec 2004, Alexey Melnikov wrote:
>
>>> 3)
>>>    A server implementation conformant to this document MUST also return
>>>    rights (see below) not defined in RFC 2086 in the "RIGHTS=" 
>>> capability
>>>    response.
>>>
>>> The ABNF for this indicates that digits are also allowed, yet digits 
>>> are technically "defined" as "optional" in RFC2086.  Can this be 
>>> clarified to indicate that it includes only optional rights that are 
>>> implemented by the server, or that this applies to only standard 
>>> rights (and thus the ABNF is fixed).
>>>
>>> I'm not convinced that the client is able to do anything with 
>>> knowledge of optional rights that are implemented by the server 
>>> without more context, and since they are already defined in 2086, I 
>>> think I lean towards the later, but I'm willing to hear other opinions.
>>
>> The latter sounds better to me. Do you want me to clarify the text or 
>> do you want tighter ABNF as well?
>
> I don't see a reason for the ABNF to allow digits when the text does not.

Ok, but I will not explicitly prohibit in ABNF rights defined in 2086.

Date: Thu, 23 Dec 2004 14:17:40 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: WG last call for IMAP ACL small-scope changes (RFC2086bis)
Sender: [email-masked]

On Wed, 22 Dec 2004, Alexey Melnikov wrote:

>> 3)
>>    A server implementation conformant to this document MUST also return
>>    rights (see below) not defined in RFC 2086 in the "RIGHTS=" capability
>>    response.
>> 
>> The ABNF for this indicates that digits are also allowed, yet digits are 
>> technically "defined" as "optional" in RFC2086.  Can this be clarified to 
>> indicate that it includes only optional rights that are implemented by the 
>> server, or that this applies to only standard rights (and thus the ABNF is 
>> fixed).
>> 
>> I'm not convinced that the client is able to do anything with knowledge of 
>> optional rights that are implemented by the server without more context, 
>> and since they are already defined in 2086, I think I lean towards the 
>> later, but I'm willing to hear other opinions.
>
> The latter sounds better to me. Do you want me to clarify the text or do you 
> want tighter ABNF as well?

I don't see a reason for the ABNF to allow digits when the text does not.

-Rob

-------------------------------------------------------------------------
Rob Siemborski        |     PGP:0x5CE32FCC     |      [email-masked] 
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

Date: Wed, 22 Dec 2004 21:36:33 +0000
From: Alexey Melnikov <[email-masked]>
To: Rob Siemborski <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: WG last call for IMAP ACL small-scope changes (RFC2086bis)
Sender: [email-masked]

Rob Siemborski wrote:

> 1 note:
>
> 3)
>    A server implementation conformant to this document MUST also return
>    rights (see below) not defined in RFC 2086 in the "RIGHTS=" capability
>    response.
>
> The ABNF for this indicates that digits are also allowed, yet digits 
> are technically "defined" as "optional" in RFC2086.  Can this be 
> clarified to indicate that it includes only optional rights that are 
> implemented by the server, or that this applies to only standard 
> rights (and thus the ABNF is fixed).
>
> I'm not convinced that the client is able to do anything with 
> knowledge of optional rights that are implemented by the server 
> without more context, and since they are already defined in 2086, I 
> think I lean towards the later, but I'm willing to hear other opinions.

The latter sounds better to me. Do you want me to clarify the text or do 
you want tighter ABNF as well?

Date: Wed, 22 Dec 2004 11:43:47 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: WG last call for IMAP ACL small-scope changes (RFC2086bis)
Sender: [email-masked]

On Wed, 8 Dec 2004, Lisa Dusseault wrote:

> I call your attention to this draft:
>
> http://www.ietf.org/internet-drafts/draft-ietf-imapext-2086upd-02.txt

Sorry I've been absent from the list -- I've been rearranging my life 
for the last few months.  Its likely I'd be able to make the interim 
meeting if it happens.

I'm really glad to see this work being done :)

1 note:

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

The ABNF for this indicates that digits are also allowed, yet digits are 
technically "defined" as "optional" in RFC2086.  Can this be clarified to 
indicate that it includes only optional rights that are implemented by the 
server, or that this applies to only standard rights (and thus the ABNF is 
fixed).

I'm not convinced that the client is able to do anything with knowledge of 
optional rights that are implemented by the server without more context, 
and since they are already defined in 2086, I think I lean towards the 
later, but I'm willing to hear other opinions.

-Rob

-------------------------------------------------------------------------
Rob Siemborski        |     PGP:0x5CE32FCC     |      [email-masked] 
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

Date: Tue, 21 Dec 2004 21:47:49 +0000
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: WG last call for IMAP ACL small-scope changes (RFC2086bis)
Sender: [email-masked]

Lisa Dusseault wrote:

> I call your attention to this draft:
>
> http://www.ietf.org/internet-drafts/draft-ietf-imapext-2086upd-02.txt
>
> It was extracted from a more ambitious update to IMAP ACLs so it's not 
> as fresh as it looks from its 02 age.  Alexey has some minor edits to 
> make (which he'll list in reply to this email), but we believe it's 
> ready for WG last call.
>
> Because of the current and imminent winter observances and vacations, 
> last call will go until Jan 4.  Happy holidays I-D reading!

Ok, here is a list of changes I've done to my copy:

1). Clarified that DELETEACL "fred" doesn't affect the identifier 
"-fred". New text reads (section 3, second paragraph from the bottom):

   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, in particular it doesn't affect
   rights granted to the identifier "-fred".

The following example was added to the section describing DELETEACL 
(section 4.2):

   Example:    C: B001 GETACL INBOX
               S: * ACL INBOX Fred rwipslxeta -Fred wet $team w
               S: B001 OK Getacl complete
               C: B002 DELETEACL INBOX Fred
               S: B002 OK Deleteacl complete
               C: B003 GETACL INBOX
               S: * ACL INBOX -Fred wet $team w
               S: B003 OK Getacl complete

2). Removed several commas when no needed (as per Philip). Also 
corrected few cases where singular was used instead of plural (as per Ken).

3). Corrected examples in sections 4.3, 4.4 and 4.5: new rights defined 
in the document were not listed.

Fixed examples:

In section 4.3:
   Example:    C: A002 GETACL INBOX
               S: * ACL INBOX Fred rwipsldexta
               S: A002 OK Getacl complete

In section 4.4:
   Example:    C: a001 LISTRIGHTS ~/Mail/saved smith
               S: * LISTRIGHTS ~/Mail/saved smith la r swicdkxte
               S: a001 OK Listrights completed

               C: a005 LISTRIGHTS archive.imap anyone
               S: * LISTRIGHTS archive.imap anyone "" l r s w i p k x t
               e a 0 1 2 3 4 5 6 7 8 9
               S: a005 Listrights successful

In section 4.5:
   Example:    C: A003 MYRIGHTS INBOX
               S: * MYRIGHTS INBOX rwiptsldaex
               S: A003 OK Myrights complete

4). Updated description of rights needed for DELETE command as per 
question asked by Philip. New description:

    DELETE - "x" right on the mailbox. Note that some servers don't allow
             to delete a non-empty mailbox. If this is the case, the user
             would also need "r", "e" and "t" rights, in order to open the
             mailbox and empty it.

Is this clear enough?

5). Dave has requested that section 6.1.1 shows an example when MYRIGHTS 
and SELECT commands are pipelined. I've added:

    Note that in order to get better performance the client may pipeline
    SELECT and MYRIGHTS commands:

               C: A142 SELECT INBOX
               C: A143 MYRIGHTS INBOX
               S: * 172 EXISTS
               S: * 1 RECENT
               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
               S: * MYRIGHTS INBOX lrwis
               S: A143 OK completed

Alexey

P.S. Dave also found an issue with LISTRIGHTS command and virtual 
rights. I will post a separate message on this.

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: WG last call for IMAP ACL small-scope changes (RFC2086bis)
Date: Wed, 8 Dec 2004 16:28:02 -0800
Sender: [email-masked]

I call your attention to this draft:

http://www.ietf.org/internet-drafts/draft-ietf-imapext-2086upd-02.txt

It was extracted from a more ambitious update to IMAP ACLs so it's not 
as fresh as it looks from its 02 age.  Alexey has some minor edits to 
make (which he'll list in reply to this email), but we believe it's 
ready for WG last call.

Because of the current and imminent winter observances and vacations, 
last call will go until Jan 4.  Happy holidays I-D reading!

Lisa

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: IMAPEXT Interim WG meeting
Date: Wed, 8 Dec 2004 10:01:55 -0800
Sender: [email-masked]

The Lemonade WG is getting together in the Bay Area for an interim WG 
meeting Jan 19 and Jan 20.  The Lemonade chairs left the afternoon of 
Jan 20 unbooked, so we could get together and work on IMAPEXT stuff 
that afternoon if there's enough interest.  I've already checked to see 
if some of the authors of our drafts can make it and some can.

I'll need to get official IESG approval I think, but I thought it would 
be good to suggest a time and get feedback.

Lisa

Date: Mon, 06 Dec 2004 12:58:58 +0000
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: What is wrong with UIDPLUS
Sender: [email-masked]

I am forwarding Mark's message so it can be found in IMAPEXT archive.

-------- Original Message --------
Subject: 	Re: [lemonade] URLFETCH Partial Fetches
Date: 	Sun, 5 Dec 2004 11:41:07 -0800 (PST)
From: 	Mark Crispin <[email-masked]>
To: 	Alexey Melnikov <[email-masked]>
CC: 	[email-masked]
References: 	<xvCWKzHs0AmX1RWv/CzKrQ.md5@prosecco> 
<[email-masked]> 
<VT6mF/4YC8jYDrntTTRMdw.md5@[10.0.0.9]> 
<[email-masked]> 
<dpq2p6Wtz1NiW6hlnOiyRg.md5@[10.0.0.9]> 
<[email-masked]> 
<[email-masked]>

On Sun, 5 Dec 2004, Alexey Melnikov wrote:
> I am curious to know what are the problems with UIDPLUS?

Good question, Alexey!

I've been taking a long hard look at UIDPLUS lately, as I may have to 
implement it.

UIDPLUS bundles two orthogonal functionalities: the UID EXPUNGE command, 
and the APPENDUID and COPYUID responses.  There is no implementation 
dependendency between the two; they should not be in the same capability.

But the worst part is that APPENDUID and COPYUID are poorly thought out, 
especially in light of the interaction with MULTIAPPEND.

There should have been a single response for all cases, not the current 
situation where very similar, but not quite the same, responses are used. 
In some mail stores, certain cases of COPY end up having to be implemented 
as APPEND internally; this creates an added implementation burden to 
generate the correct COPYUID.

When multiple messages are involved, APPENDUID/COPYUID suffer from the 
flaw that a set<->set mapping needs to be calculated; the excuse being 
that if monotonically increasing UIDs are assigned then the response is 
less chatty than alternatives.  It's also an invitation to bugs.  There 
should be an explicit source->destination mapping for each message, not 
"match this set with that set".

In some mail stores, it can be very expensive to return APPENDUID/COPYUID 
data, *especially* in those cases where the IMAP server vendor does not 
control the delivery mechanism.  In fact, UIDPLUS could be called the 
FCTGTMSFASS (Force Customers To Get Their Mail Software From A Single 
Source) extension to IMAP.  Since IMAP requires strictly ascending UIDs, 
it is impossible to assign a UID to a newly APPENDed or COPYed message 
without assurance than any new mail delivered to the mailbox has also had 
a UID assigned.

Hence FCTGTMSFASS; if the mail delivery agent is from another vendor that 
assurance may be absent and the IMAP server has to fix things.  This, in 
turn, requires a sort of read/write open that assigns UIDs but doesn't 
affect \Recent flags or the RECENT count in the next open.  That also 
means that you can't use "no UID was assigned when mailbox opened" to mean 
\Recent -- the \Recent flag has to be maintained independently.

All this is not cheap, although with a lot of extra programming much of 
the extra cost can be ameliorated.  Among other things, this means 
additional mailbox metadata in order to avoid taking the worst-case fixup 
path each time.

Better would have been to have two new commands that would return new 
responses (instead of response codes).  This would save servers the work 
if the client does not care (the majority of clients!), and also would 
have allowed much more flexibility in the response syntax.

In conclusion, I believe that UIDPLUS:
 1) bundles together things that did not need to be bundled;
 2) creates server burdens that often are unnecessary;
 3) has a incredibly kludgy design in order to avoid adding new commands
    and responses.
In some ways, the third sin is the worst of all, and caused the other two 
sins.

I've often criticized ACL, but it is well-designed.  The problem with is 
that ACL is a *very* hard problem.  The difficulty is *far* worse when you 
attempt to export external legacy facilities.  Similar comments can be 
made about certain other troublesome extensions (e.g. QUOTA).

UIDPLUS, on the other hand, stands out as expediency over good design.

I fear that it's much too late to fix it now.  We're stuck with the wart. 
But we can learn from the mistake, and avoid similar mistakes in the 
future.

That I think is the important point to move forward.  What seems to be 
simple and expedient today can have long-term deleterious consequences in 
the future.  It's often difficult, and frustrating!!, to be delayed in 
discussions on how to do things right when an attractive shortcut seems to 
exist.  It's even more frustrating when deadlines are faced and/or needs 
are unmet.

But the results of doing it right are worth it.

-- Mark --

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

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-2086upd-02.txt
Date: Fri, 03 Dec 2004 07:14:34 -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
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-imapext-2086upd-02.txt
	Pages		: 0
	Date		: 2004-12-2
	
The ACL (Access Control List) extension (RFC 2086) of the Internet
   Message Access Protocol (IMAP4rev1) permits mailbox access control
   lists to be manipulated through the IMAP protocol.

   This document is a revision of the RFC 2086. It defines several new
   access control rights and 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-02.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-02.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-02.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-02.txt

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

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

--OtherAccess--

--NextPart--

Date: Thu, 02 Dec 2004 17:17:37 +0000
From: Alexey Melnikov <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Changes to the 2086upd draft
Sender: [email-masked]

Philip Guenther wrote:

>Alexey Melnikov <[email-masked]> writes:
>...
>  
>
>>8). Declared uppercase rights illegal, due to backward compatibility.
>>
>>9). Removed MYRIGHTS response code, because David Cridland has pointed 
>>out that there would be a compatibility issue for servers that implement 
>>both 2086upd and ACL, caused by issue # 8.
>>    
>>
>
>I don't understand the logic on this.  If an existing server gives a
>meaning to uppercase rights other than "same as the lowercase" then it
>is not compliant with the ACL RFC, which reserves all letters for
>standards-track extensions.
>
>On top of that, how could the appearance of such illegal rights in a new
>MYRIGHTS response code be more of a problem than their appearance in
>other ACL responses?  The ban applies to the ACL commands too...
>  
>
A server that supports both ACL and ACL2 would have to lowercase rights 
in the MYRIGHTS response code.
As there is no way for the server to know if the client supports ACL or 
ACL2, this means that *every* ACL2 server MUST always lowercase rights 
in MYRIGHTS, which creates a special case for ACL2-only servers. And 
server implementors can easily miss it.

David also pointed out that the client can pipeline SELECT with MYRIGHTS 
anyway, so we have a workaround for ACL.

>(Did I miss this on the list?)
>  
>
No, this was off the list discussion between David, Cyrus and myself.

>>10). Updated the description of rights required for the DELETE command 
>>to read:
>>
>>   DELETE - "x" right on the mailbox. Note, that some servers don't allow
>>            to delete a non-empty mailbox. If this is the case, the user
>>            also need both "e" and "t" rights, in order to make the mailbox
>>            empty first.
>>    
>>
>
>Is this saying that some servers, when told to DELETE a non-empty
>mailbox, must internally perform STORE and EXPUNGE commands, such that
>the DELETE will fail if the user has the "x" right but not both the "e"
>and "t" rights?  Or is this saying that some servers will fail a DELETE
>of a non-empty mailbox and that clients MAY work around this brokeness
>by doing the STORE and EXPUNGE themselves?
>  
>
I meant the latter, although there are some existing servers that do the 
former.

>At least in the latter case, the "r" right would also be required.
>  
>
Right.

>("Note that..." doesn't take a comma.  That should be fixed in a couple
>other places in the draft.)
>  
>
Fixed, thanks.

To: Alexey Melnikov <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: Changes to the 2086upd draft 
Date: Thu, 02 Dec 2004 09:05:49 -0800
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:
...
>8). Declared uppercase rights illegal, due to backward compatibility.
>
>9). Removed MYRIGHTS response code, because David Cridland has pointed 
>out that there would be a compatibility issue for servers that implement 
>both 2086upd and ACL, caused by issue # 8.

I don't understand the logic on this.  If an existing server gives a
meaning to uppercase rights other than "same as the lowercase" then it
is not compliant with the ACL RFC, which reserves all letters for
standards-track extensions.

On top of that, how could the appearance of such illegal rights in a new
MYRIGHTS response code be more of a problem than their appearance in
other ACL responses?  The ban applies to the ACL commands too...

(Did I miss this on the list?)

>10). Updated the description of rights required for the DELETE command 
>to read:
>
>    DELETE - "x" right on the mailbox. Note, that some servers don't allow
>             to delete a non-empty mailbox. If this is the case, the user
>             also need both "e" and "t" rights, in order to make the mailbox
>             empty first.

Is this saying that some servers, when told to DELETE a non-empty
mailbox, must internally perform STORE and EXPUNGE commands, such that
the DELETE will fail if the user has the "x" right but not both the "e"
and "t" rights?  Or is this saying that some servers will fail a DELETE
of a non-empty mailbox and that clients MAY work around this brokeness
by doing the STORE and EXPUNGE themselves?

At least in the latter case, the "r" right would also be required.

("Note that..." doesn't take a comma.  That should be fixed in a couple
other places in the draft.)

Philip Guenther

Date: Thu, 02 Dec 2004 15:32:09 +0000
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Changes to the 2086upd draft
Sender: [email-masked]

I've just submitted a new revision of 2086upd. I've done the following 
changes to the document:

1). Redefined "c" as a virtual right, added "k" right that controls 
CREATE. "c" can be "kx" or just "k", depending on a server 
implementation. (Issue raised by Ken Murchison).
A new section was created to talk about this, text was rewritten.
Please check the section 3.1.1. in the latest draft.

2). Add the rest of 2086 (commands/responses) to the 2086upd (new 
section 4) as suggested by Chris Newman. BNF was changed to ABNF in the 
process.

3). Moved description of standard rights into a separate subsection of 
section 3. This will make it easier to reference in ACL2.

4). Changed "mailbox" to "mailbox name" in a few places. An ACL can 
apply to a non-selectable mailbox, so I thought that the term "mailbox 
name" would be more appropriate.

5). Added "UTF-8 + SASLPrep" as per Chris' comment (section 4):

   Servers, when processing a command that have an authentication identifier
   as a parameter (i.e. any of SETACL, DELETEACL and LISTRIGHTS commands),
   SHOULD first prepare the received identifier using "SASLprep" profile
   [SASLprep] of the "stringprep" algorithm [StringPrep].  If the
   preparation of the identifier fails or results in an empty string, the
   server MUST refuse to perform the command with a BAD response.

6). Added text about handling of unrecognized rights, as suggested by 
Philip Guenther:

In section talking about SETACL:

      Note, that an unrecognized right MUST cause the command to return
      the BAD response. In particular, server MUST NOT silently ignore
      unrecognized rights.

And added the following examples:

   Example:    C: A001 SETACL INBOX.Drafts Chris lrswicda
               S: A001 OK Setacl complete

               C: A035 SETACL INBOX.Drafts John lrQswicda
               S: A035 BAD Uppercase rights are not allowed

               C: A036 SETACL INBOX.Drafts John lrqswicda
               S: A036 BAD The q right is not supported

7). Added few clarifications about identifier canonicalization as 
suggested by Chris Newman:

In section 4.3. GETACL command:

      Some implementations may permit multiple forms of an authentication
      identifier to reference the same IMAP account. Usually, such
      implementations will have a canonical form that is stored internally.
      An ACL response caused by an GETACL command may include a
      canonicalized form of the authentication identifier which might be
      different from the one used in the corresponding SETACL command.

In section 4.4. LISTRIGHTS command:

      Some implementations may permit multiple forms of an authentication
      identifier to reference the same IMAP account. Usually, such
      implementations will have a canonical form that is stored internally.
      A LISTRIGHTS response caused by a LISTRIGHTS command MUST always
      return the same form of an authentication identifier as specified
      by the client. This is to allow the client to correlate the response
      with the command.

8). Declared uppercase rights illegal, due to backward compatibility.

9). Removed MYRIGHTS response code, because David Cridland has pointed 
out that there would be a compatibility issue for servers that implement 
both 2086upd and ACL, caused by issue # 8.

10). Updated the description of rights required for the DELETE command 
to read:

    DELETE - "x" right on the mailbox. Note, that some servers don't allow
             to delete a non-empty mailbox. If this is the case, the user
             also need both "e" and "t" rights, in order to make the mailbox
             empty first.

             The DELETE command MUST delete the ACL associated with the
             deleted mailbox.

Is it Ok with everyone?

11). Added IANA considerations section.

Cc: [email-masked]
From: Lisa Dusseault <[email-masked]>
Subject: Re: Storing annotations colours on IMAP servers
Date: Thu, 30 Dec 2004 11:26:47 -0800
To: kael <[email-masked]>
Sender: [email-masked]

I imagine users wouldn't define annotations in any case; client 
developers would, and as you suggest, it's possible to standardize a 
name for the colour annotation as well as a syntax.  That work isn't 
within the charter of this WG but this is probably a decent place to 
try to drum up participation.

I can't think of any way to synchronize colours with current MUAs.  
They're already deployed with support only for adding their own 
colouring and storing it locally, as you illustrate with Thunderbird 
and Mulberry.

Lisa

On Dec 30, 2004, at 11:14 AM, kael wrote:

> On 30.12.2004 19:17, Lisa Dusseault wrote:
>> The annotate draft  
>> <http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate 
>> -11.txt> allows client-specific annotations to be added to the mail  
>> store, if the server supports it.  You could either define a  
>> proprietary annotation (and not share colour information with other  
>> clients, but make it available to be synchronized via the server) or  
>> work out some agreed scheme which other clients could use as well.
>
> How could colors be synchronized with (current) MUAs ?
>
> Actually, I was thinking that IMAP servers could have the ability to 
> store that kind of information _by default_ which could help to make 
> "gains productivity".
>
> Users would have neither to define annotations name nor their color 
> each time they configure a MUA.
>
> This page http://researchweb.watson.ibm.com/history/index.htm gave me 
> the idea - visualization tools are very useful when they use colors.
>
> Currently, it's great to use IMAP: nomad users configure the MUA and 
> get all their emails. But each time, users have to re-configure 
> keywords name and colors - personal experience with Mulberry and 
> Thunderbird's labels, unfortunately not interoperable (or compatible 
> ?).
>
> So waiting for the /ACAP Renaissance/, maybe IMAP could help and 
> annotations colors could be standardized  - maybe as "attributes" ?
>
> -- 
> kael -- http://kevan.org/extispicious.cgi?name=ubi.quito.us
>
> "We're in the process of creating a planetary nervous system"
> _The network is the blog_ by Jon Udell -
> http://weblog.infoworld.com/udell/2004/12/17.html#a1136

Date: Thu, 30 Dec 2004 20:14:54 +0100
From: kael <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Cc: [email-masked]
Subject: Re: Storing annotations colours on IMAP servers
Sender: [email-masked]

On 30.12.2004 19:17, Lisa Dusseault wrote:
> The annotate draft  
> <http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate 
> -11.txt> allows client-specific annotations to be added to the mail  
> store, if the server supports it.  You could either define a  
> proprietary annotation (and not share colour information with other  
> clients, but make it available to be synchronized via the server) or  
> work out some agreed scheme which other clients could use as well.

How could colors be synchronized with (current) MUAs ?

Actually, I was thinking that IMAP servers could have the ability to 
store that kind of information _by default_ which could help to make 
"gains productivity".

Users would have neither to define annotations name nor their color each 
time they configure a MUA.

This page http://researchweb.watson.ibm.com/history/index.htm gave me 
the idea - visualization tools are very useful when they use colors.

Currently, it's great to use IMAP: nomad users configure the MUA and get 
all their emails. But each time, users have to re-configure keywords 
name and colors - personal experience with Mulberry and Thunderbird's 
labels, unfortunately not interoperable (or compatible ?).

So waiting for the /ACAP Renaissance/, maybe IMAP could help and 
annotations colors could be standardized  - maybe as "attributes" ?

-- 
kael -- http://kevan.org/extispicious.cgi?name=ubi.quito.us

"We're in the process of creating a planetary nervous system"
_The network is the blog_ by Jon Udell -
http://weblog.infoworld.com/udell/2004/12/17.html#a1136

Cc: [email-masked]
From: Lisa Dusseault <[email-masked]>
Subject: Re: Storing annotations colours on IMAP servers
Date: Thu, 30 Dec 2004 10:17:54 -0800
To: kael <[email-masked]>
Sender: [email-masked]

The annotate draft  
<http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate 
-11.txt> allows client-specific annotations to be added to the mail  
store, if the server supports it.  You could either define a  
proprietary annotation (and not share colour information with other  
clients, but make it available to be synchronized via the server) or  
work out some agreed scheme which other clients could use as well.

Lisa

On Dec 29, 2004, at 1:02 AM, kael wrote:

>
> Hello,
>
> Could annotations (and keywords) colours be stored on IMAP servers ?
>
> Thank you very much.
>
> -- 
> kael
>

Date: Wed, 29 Dec 2004 10:02:46 +0100
From: kael <[email-masked]>
To: [email-masked]
Subject: Storing annotations colours on IMAP servers
Sender: [email-masked]

Hello,

Could annotations (and keywords) colours be stored on IMAP servers ?

Thank you very much.

-- 
kael

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Fwd: Interim Meeting for IMAPEXT
Date: Tue, 28 Dec 2004 11:22:27 -0800
Sender: [email-masked]

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

I got the interim meeting announcement in just under the wire... *whew*

Please continue to let me know if you plan to attend or what you'd like 
to discuss.  So far, Barry Leiba, Randy Gellens, Alexey Melnikov and I 
are on the side of probably attending, and Mark and Cyrus on the side 
of probably not attending.   That means we'll have all the authors of 
LISTEXT and half the authors of ANNOTATE, available to heckle them 
about their draft lateness :)

We may also discuss 2086upd but only if something surprising turns up.  
So far it looks like the last call is generating some changes but 
nothing requiring a reset.

Stephane Maes is kindly looking into letting us use the same Oracle 
space that the Lemonade WG is using.

Lisa

Begin forwarded message:

> From: Lisa Dusseault <[email-masked]>
> Date: December 21, 2004 11:31:05 AM PST
> To: [email-masked]
> Cc: Subject: Interim Meeting for IMAPEXT
>
> We are organizing an interim meeting for IMAPEXT in the San Francisco
> Bay Area for the afternoon of Jan 20. (The meeting location and time
> will be alongside the LEMONADE WG interim meeting which has an
> overlapping membership).
>
> I've already announced this intent on the IMAPEXT mailing list and
> would like to announce it more widely even though we don't as yet know
> the exact location.
>
> Scott Hollenbeck has indicated his approval.
>
> Location: TBD, near San Francisco/Redwood Shores, CA
> Date: Jan 20, 2:00 pm to 5:00 pm
> Hotel: See LEMONADE WG interim meeting information
>
> Agenda (Draft)
> ===========
>
> - resolve ANNOTATE open issues with authors
> - Discuss LISTEXT extensions
> - Resume work on ACL draft
>
>
> --Thanks,
> Lisa Dusseault
>
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce

--Apple-Mail-4--746987174
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=US-ASCII

I got the interim meeting announcement in just under the wire...
*whew*  

Please continue to let me know if you plan to attend or what you'd
like to discuss.  So far, Barry Leiba, Randy Gellens, Alexey Melnikov
and I are on the side of probably attending, and Mark and Cyrus on the
side of probably not attending.   That means we'll have all the
authors of LISTEXT and half the authors of ANNOTATE, available to
heckle them about their draft lateness :)

We may also discuss 2086upd but only if something surprising turns up. 
So far it looks like the last call is generating some changes but
nothing requiring a reset.

Stephane Maes is kindly looking into letting us use the same Oracle
space that the Lemonade WG is using.

Lisa

Begin forwarded message:

<excerpt><bold><color><param>0000,0000,0000</param>From:
</color></bold>Lisa Dusseault <<[email-masked]>

<bold><color><param>0000,0000,0000</param>Date:
</color></bold>December 21, 2004 11:31:05 AM PST

<bold><color><param>0000,0000,0000</param>To:
</color></bold>[email-masked]

<bold><color><param>0000,0000,0000</param>Cc: Subject: </color>Interim
Meeting for IMAPEXT

</bold>

We are organizing an interim meeting for IMAPEXT in the San Francisco

Bay Area for the afternoon of Jan 20. (The meeting location and time

will be alongside the LEMONADE WG interim meeting which has an

overlapping membership).

I've already announced this intent on the IMAPEXT mailing list and

would like to announce it more widely even though we don't as yet know

the exact location.

Scott Hollenbeck has indicated his approval.

Location: TBD, near San Francisco/Redwood Shores, CA

Date: Jan 20, 2:00 pm to 5:00 pm

Hotel: See LEMONADE WG interim meeting information

Agenda (Draft)

===========

- resolve ANNOTATE open issues with authors

- Discuss LISTEXT extensions

- Resume work on ACL draft

--Thanks,

Lisa Dusseault

_______________________________________________

IETF-Announce mailing list

[email-masked]

https://www1.ietf.org/mailman/listinfo/ietf-announce

</excerpt>
--Apple-Mail-4--746987174--

Date: Sat, 25 Dec 2004 10:42:49 +0000
From: Alexey Melnikov <[email-masked]>
To: Rob Siemborski <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: WG last call for IMAP ACL small-scope changes (RFC2086bis)
Sender: [email-masked]

Rob Siemborski wrote:

> On Wed, 8 Dec 2004, Lisa Dusseault wrote:
>
>> I call your attention to this draft:
>>
>> http://www.ietf.org/internet-drafts/draft-ietf-imapext-2086upd-02.txt
>
> Sorry I've been absent from the list -- I've been rearranging my life 
> for the last few months.  Its likely I'd be able to make the interim 
> meeting if it happens.
>
> I'm really glad to see this work being done :)
>
> 1 note:
>
> 3)
>    A server implementation conformant to this document MUST also return
>    rights (see below) not defined in RFC 2086 in the "RIGHTS=" capability
>    response.
>
> The ABNF for this indicates that digits are also allowed, yet digits 
> are technically "defined" as "optional" in RFC2086.  Can this be 
> clarified to indicate that it includes only optional rights that are 
> implemented by the server, or that this applies to only standard 
> rights (and thus the ABNF is fixed).
>
> I'm not convinced that the client is able to do anything with 
> knowledge of optional rights that are implemented by the server 
> without more context, and since they are already defined in 2086, I 
> think I lean towards the later, but I'm willing to hear other opinions.

Ok, here is my change to address this issue:

In section 3:

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

Added new section 3.2:

3.2.   Rights defined in RFC 2086.

   For convenience, this section lists the rights which were defined in
   the RFC 2086:
    "l", "r", "s", "w", "i", "p", "a", "c", "d" and digit rights
    ("0" .. "9").

   The listed rights MUST NOT be returned in the "RIGHTS=" capability
   string.

Updated ABNF:

   new_rights      = 1*LOWER_ALPHA
                      ;; MUST include "t", "e", "x" and "k".
                      ;; MUST NOT include standard rights listed
                      ;; in section 3.2
...
   rights_capa     = "RIGHTS=" new_rights
                      ;; RIGHTS=... capability

Date: Fri, 24 Dec 2004 11:18:37 +0000
From: Alexey Melnikov <[email-masked]>
To: Rob Siemborski <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: WG last call for IMAP ACL small-scope changes (RFC2086bis)
Sender: [email-masked]

Rob Siemborski wrote:

> On Wed, 22 Dec 2004, Alexey Melnikov wrote:
>
>>> 3)
>>>    A server implementation conformant to this document MUST also return
>>>    rights (see below) not defined in RFC 2086 in the "RIGHTS=" 
>>> capability
>>>    response.
>>>
>>> The ABNF for this indicates that digits are also allowed, yet digits 
>>> are technically "defined" as "optional" in RFC2086.  Can this be 
>>> clarified to indicate that it includes only optional rights that are 
>>> implemented by the server, or that this applies to only standard 
>>> rights (and thus the ABNF is fixed).
>>>
>>> I'm not convinced that the client is able to do anything with 
>>> knowledge of optional rights that are implemented by the server 
>>> without more context, and since they are already defined in 2086, I 
>>> think I lean towards the later, but I'm willing to hear other opinions.
>>
>> The latter sounds better to me. Do you want me to clarify the text or 
>> do you want tighter ABNF as well?
>
> I don't see a reason for the ABNF to allow digits when the text does not.

Ok, but I will not explicitly prohibit in ABNF rights defined in 2086.

Date: Thu, 23 Dec 2004 14:17:40 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: WG last call for IMAP ACL small-scope changes (RFC2086bis)
Sender: [email-masked]

On Wed, 22 Dec 2004, Alexey Melnikov wrote:

>> 3)
>>    A server implementation conformant to this document MUST also return
>>    rights (see below) not defined in RFC 2086 in the "RIGHTS=" capability
>>    response.
>> 
>> The ABNF for this indicates that digits are also allowed, yet digits are 
>> technically "defined" as "optional" in RFC2086.  Can this be clarified to 
>> indicate that it includes only optional rights that are implemented by the 
>> server, or that this applies to only standard rights (and thus the ABNF is 
>> fixed).
>> 
>> I'm not convinced that the client is able to do anything with knowledge of 
>> optional rights that are implemented by the server without more context, 
>> and since they are already defined in 2086, I think I lean towards the 
>> later, but I'm willing to hear other opinions.
>
> The latter sounds better to me. Do you want me to clarify the text or do you 
> want tighter ABNF as well?

I don't see a reason for the ABNF to allow digits when the text does not.

-Rob

-------------------------------------------------------------------------
Rob Siemborski        |     PGP:0x5CE32FCC     |      [email-masked] 
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

Date: Wed, 22 Dec 2004 21:36:33 +0000
From: Alexey Melnikov <[email-masked]>
To: Rob Siemborski <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: WG last call for IMAP ACL small-scope changes (RFC2086bis)
Sender: [email-masked]

Rob Siemborski wrote:

> 1 note:
>
> 3)
>    A server implementation conformant to this document MUST also return
>    rights (see below) not defined in RFC 2086 in the "RIGHTS=" capability
>    response.
>
> The ABNF for this indicates that digits are also allowed, yet digits 
> are technically "defined" as "optional" in RFC2086.  Can this be 
> clarified to indicate that it includes only optional rights that are 
> implemented by the server, or that this applies to only standard 
> rights (and thus the ABNF is fixed).
>
> I'm not convinced that the client is able to do anything with 
> knowledge of optional rights that are implemented by the server 
> without more context, and since they are already defined in 2086, I 
> think I lean towards the later, but I'm willing to hear other opinions.

The latter sounds better to me. Do you want me to clarify the text or do 
you want tighter ABNF as well?

Date: Wed, 22 Dec 2004 11:43:47 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: WG last call for IMAP ACL small-scope changes (RFC2086bis)
Sender: [email-masked]

On Wed, 8 Dec 2004, Lisa Dusseault wrote:

> I call your attention to this draft:
>
> http://www.ietf.org/internet-drafts/draft-ietf-imapext-2086upd-02.txt

Sorry I've been absent from the list -- I've been rearranging my life 
for the last few months.  Its likely I'd be able to make the interim 
meeting if it happens.

I'm really glad to see this work being done :)

1 note:

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

The ABNF for this indicates that digits are also allowed, yet digits are 
technically "defined" as "optional" in RFC2086.  Can this be clarified to 
indicate that it includes only optional rights that are implemented by the 
server, or that this applies to only standard rights (and thus the ABNF is 
fixed).

I'm not convinced that the client is able to do anything with knowledge of 
optional rights that are implemented by the server without more context, 
and since they are already defined in 2086, I think I lean towards the 
later, but I'm willing to hear other opinions.

-Rob

-------------------------------------------------------------------------
Rob Siemborski        |     PGP:0x5CE32FCC     |      [email-masked] 
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

Date: Tue, 21 Dec 2004 21:47:49 +0000
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: WG last call for IMAP ACL small-scope changes (RFC2086bis)
Sender: [email-masked]

Lisa Dusseault wrote:

> I call your attention to this draft:
>
> http://www.ietf.org/internet-drafts/draft-ietf-imapext-2086upd-02.txt
>
> It was extracted from a more ambitious update to IMAP ACLs so it's not 
> as fresh as it looks from its 02 age.  Alexey has some minor edits to 
> make (which he'll list in reply to this email), but we believe it's 
> ready for WG last call.
>
> Because of the current and imminent winter observances and vacations, 
> last call will go until Jan 4.  Happy holidays I-D reading!

Ok, here is a list of changes I've done to my copy:

1). Clarified that DELETEACL "fred" doesn't affect the identifier 
"-fred". New text reads (section 3, second paragraph from the bottom):

   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, in particular it doesn't affect
   rights granted to the identifier "-fred".

The following example was added to the section describing DELETEACL 
(section 4.2):

   Example:    C: B001 GETACL INBOX
               S: * ACL INBOX Fred rwipslxeta -Fred wet $team w
               S: B001 OK Getacl complete
               C: B002 DELETEACL INBOX Fred
               S: B002 OK Deleteacl complete
               C: B003 GETACL INBOX
               S: * ACL INBOX -Fred wet $team w
               S: B003 OK Getacl complete

2). Removed several commas when no needed (as per Philip). Also 
corrected few cases where singular was used instead of plural (as per Ken).

3). Corrected examples in sections 4.3, 4.4 and 4.5: new rights defined 
in the document were not listed.

Fixed examples:

In section 4.3:
   Example:    C: A002 GETACL INBOX
               S: * ACL INBOX Fred rwipsldexta
               S: A002 OK Getacl complete

In section 4.4:
   Example:    C: a001 LISTRIGHTS ~/Mail/saved smith
               S: * LISTRIGHTS ~/Mail/saved smith la r swicdkxte
               S: a001 OK Listrights completed

               C: a005 LISTRIGHTS archive.imap anyone
               S: * LISTRIGHTS archive.imap anyone "" l r s w i p k x t
               e a 0 1 2 3 4 5 6 7 8 9
               S: a005 Listrights successful

In section 4.5:
   Example:    C: A003 MYRIGHTS INBOX
               S: * MYRIGHTS INBOX rwiptsldaex
               S: A003 OK Myrights complete

4). Updated description of rights needed for DELETE command as per 
question asked by Philip. New description:

    DELETE - "x" right on the mailbox. Note that some servers don't allow
             to delete a non-empty mailbox. If this is the case, the user
             would also need "r", "e" and "t" rights, in order to open the
             mailbox and empty it.

Is this clear enough?

5). Dave has requested that section 6.1.1 shows an example when MYRIGHTS 
and SELECT commands are pipelined. I've added:

    Note that in order to get better performance the client may pipeline
    SELECT and MYRIGHTS commands:

               C: A142 SELECT INBOX
               C: A143 MYRIGHTS INBOX
               S: * 172 EXISTS
               S: * 1 RECENT
               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
               S: * MYRIGHTS INBOX lrwis
               S: A143 OK completed

Alexey

P.S. Dave also found an issue with LISTRIGHTS command and virtual 
rights. I will post a separate message on this.

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: WG last call for IMAP ACL small-scope changes (RFC2086bis)
Date: Wed, 8 Dec 2004 16:28:02 -0800
Sender: [email-masked]

I call your attention to this draft:

http://www.ietf.org/internet-drafts/draft-ietf-imapext-2086upd-02.txt

It was extracted from a more ambitious update to IMAP ACLs so it's not 
as fresh as it looks from its 02 age.  Alexey has some minor edits to 
make (which he'll list in reply to this email), but we believe it's 
ready for WG last call.

Because of the current and imminent winter observances and vacations, 
last call will go until Jan 4.  Happy holidays I-D reading!

Lisa

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: IMAPEXT Interim WG meeting
Date: Wed, 8 Dec 2004 10:01:55 -0800
Sender: [email-masked]

The Lemonade WG is getting together in the Bay Area for an interim WG 
meeting Jan 19 and Jan 20.  The Lemonade chairs left the afternoon of 
Jan 20 unbooked, so we could get together and work on IMAPEXT stuff 
that afternoon if there's enough interest.  I've already checked to see 
if some of the authors of our drafts can make it and some can.

I'll need to get official IESG approval I think, but I thought it would 
be good to suggest a time and get feedback.

Lisa

Date: Mon, 06 Dec 2004 12:58:58 +0000
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: What is wrong with UIDPLUS
Sender: [email-masked]

I am forwarding Mark's message so it can be found in IMAPEXT archive.

-------- Original Message --------
Subject: 	Re: [lemonade] URLFETCH Partial Fetches
Date: 	Sun, 5 Dec 2004 11:41:07 -0800 (PST)
From: 	Mark Crispin <[email-masked]>
To: 	Alexey Melnikov <[email-masked]>
CC: 	[email-masked]
References: 	<xvCWKzHs0AmX1RWv/CzKrQ.md5@prosecco> 
<[email-masked]> 
<VT6mF/4YC8jYDrntTTRMdw.md5@[10.0.0.9]> 
<[email-masked]> 
<dpq2p6Wtz1NiW6hlnOiyRg.md5@[10.0.0.9]> 
<[email-masked]> 
<[email-masked]>

On Sun, 5 Dec 2004, Alexey Melnikov wrote:
> I am curious to know what are the problems with UIDPLUS?

Good question, Alexey!

I've been taking a long hard look at UIDPLUS lately, as I may have to 
implement it.

UIDPLUS bundles two orthogonal functionalities: the UID EXPUNGE command, 
and the APPENDUID and COPYUID responses.  There is no implementation 
dependendency between the two; they should not be in the same capability.

But the worst part is that APPENDUID and COPYUID are poorly thought out, 
especially in light of the interaction with MULTIAPPEND.

There should have been a single response for all cases, not the current 
situation where very similar, but not quite the same, responses are used. 
In some mail stores, certain cases of COPY end up having to be implemented 
as APPEND internally; this creates an added implementation burden to 
generate the correct COPYUID.

When multiple messages are involved, APPENDUID/COPYUID suffer from the 
flaw that a set<->set mapping needs to be calculated; the excuse being 
that if monotonically increasing UIDs are assigned then the response is 
less chatty than alternatives.  It's also an invitation to bugs.  There 
should be an explicit source->destination mapping for each message, not 
"match this set with that set".

In some mail stores, it can be very expensive to return APPENDUID/COPYUID 
data, *especially* in those cases where the IMAP server vendor does not 
control the delivery mechanism.  In fact, UIDPLUS could be called the 
FCTGTMSFASS (Force Customers To Get Their Mail Software From A Single 
Source) extension to IMAP.  Since IMAP requires strictly ascending UIDs, 
it is impossible to assign a UID to a newly APPENDed or COPYed message 
without assurance than any new mail delivered to the mailbox has also had 
a UID assigned.

Hence FCTGTMSFASS; if the mail delivery agent is from another vendor that 
assurance may be absent and the IMAP server has to fix things.  This, in 
turn, requires a sort of read/write open that assigns UIDs but doesn't 
affect \Recent flags or the RECENT count in the next open.  That also 
means that you can't use "no UID was assigned when mailbox opened" to mean 
\Recent -- the \Recent flag has to be maintained independently.

All this is not cheap, although with a lot of extra programming much of 
the extra cost can be ameliorated.  Among other things, this means 
additional mailbox metadata in order to avoid taking the worst-case fixup 
path each time.

Better would have been to have two new commands that would return new 
responses (instead of response codes).  This would save servers the work 
if the client does not care (the majority of clients!), and also would 
have allowed much more flexibility in the response syntax.

In conclusion, I believe that UIDPLUS:
 1) bundles together things that did not need to be bundled;
 2) creates server burdens that often are unnecessary;
 3) has a incredibly kludgy design in order to avoid adding new commands
    and responses.
In some ways, the third sin is the worst of all, and caused the other two 
sins.

I've often criticized ACL, but it is well-designed.  The problem with is 
that ACL is a *very* hard problem.  The difficulty is *far* worse when you 
attempt to export external legacy facilities.  Similar comments can be 
made about certain other troublesome extensions (e.g. QUOTA).

UIDPLUS, on the other hand, stands out as expediency over good design.

I fear that it's much too late to fix it now.  We're stuck with the wart. 
But we can learn from the mistake, and avoid similar mistakes in the 
future.

That I think is the important point to move forward.  What seems to be 
simple and expedient today can have long-term deleterious consequences in 
the future.  It's often difficult, and frustrating!!, to be delayed in 
discussions on how to do things right when an attractive shortcut seems to 
exist.  It's even more frustrating when deadlines are faced and/or needs 
are unmet.

But the results of doing it right are worth it.

-- Mark --

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

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-2086upd-02.txt
Date: Fri, 03 Dec 2004 07:14:34 -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
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-imapext-2086upd-02.txt
	Pages		: 0
	Date		: 2004-12-2
	
The ACL (Access Control List) extension (RFC 2086) of the Internet
   Message Access Protocol (IMAP4rev1) permits mailbox access control
   lists to be manipulated through the IMAP protocol.

   This document is a revision of the RFC 2086. It defines several new
   access control rights and 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-02.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-02.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-02.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-02.txt

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

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

--OtherAccess--

--NextPart--

Date: Thu, 02 Dec 2004 17:17:37 +0000
From: Alexey Melnikov <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Changes to the 2086upd draft
Sender: [email-masked]

Philip Guenther wrote:

>Alexey Melnikov <[email-masked]> writes:
>...
>  
>
>>8). Declared uppercase rights illegal, due to backward compatibility.
>>
>>9). Removed MYRIGHTS response code, because David Cridland has pointed 
>>out that there would be a compatibility issue for servers that implement 
>>both 2086upd and ACL, caused by issue # 8.
>>    
>>
>
>I don't understand the logic on this.  If an existing server gives a
>meaning to uppercase rights other than "same as the lowercase" then it
>is not compliant with the ACL RFC, which reserves all letters for
>standards-track extensions.
>
>On top of that, how could the appearance of such illegal rights in a new
>MYRIGHTS response code be more of a problem than their appearance in
>other ACL responses?  The ban applies to the ACL commands too...
>  
>
A server that supports both ACL and ACL2 would have to lowercase rights 
in the MYRIGHTS response code.
As there is no way for the server to know if the client supports ACL or 
ACL2, this means that *every* ACL2 server MUST always lowercase rights 
in MYRIGHTS, which creates a special case for ACL2-only servers. And 
server implementors can easily miss it.

David also pointed out that the client can pipeline SELECT with MYRIGHTS 
anyway, so we have a workaround for ACL.

>(Did I miss this on the list?)
>  
>
No, this was off the list discussion between David, Cyrus and myself.

>>10). Updated the description of rights required for the DELETE command 
>>to read:
>>
>>   DELETE - "x" right on the mailbox. Note, that some servers don't allow
>>            to delete a non-empty mailbox. If this is the case, the user
>>            also need both "e" and "t" rights, in order to make the mailbox
>>            empty first.
>>    
>>
>
>Is this saying that some servers, when told to DELETE a non-empty
>mailbox, must internally perform STORE and EXPUNGE commands, such that
>the DELETE will fail if the user has the "x" right but not both the "e"
>and "t" rights?  Or is this saying that some servers will fail a DELETE
>of a non-empty mailbox and that clients MAY work around this brokeness
>by doing the STORE and EXPUNGE themselves?
>  
>
I meant the latter, although there are some existing servers that do the 
former.

>At least in the latter case, the "r" right would also be required.
>  
>
Right.

>("Note that..." doesn't take a comma.  That should be fixed in a couple
>other places in the draft.)
>  
>
Fixed, thanks.

To: Alexey Melnikov <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: Changes to the 2086upd draft 
Date: Thu, 02 Dec 2004 09:05:49 -0800
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:
...
>8). Declared uppercase rights illegal, due to backward compatibility.
>
>9). Removed MYRIGHTS response code, because David Cridland has pointed 
>out that there would be a compatibility issue for servers that implement 
>both 2086upd and ACL, caused by issue # 8.

I don't understand the logic on this.  If an existing server gives a
meaning to uppercase rights other than "same as the lowercase" then it
is not compliant with the ACL RFC, which reserves all letters for
standards-track extensions.

On top of that, how could the appearance of such illegal rights in a new
MYRIGHTS response code be more of a problem than their appearance in
other ACL responses?  The ban applies to the ACL commands too...

(Did I miss this on the list?)

>10). Updated the description of rights required for the DELETE command 
>to read:
>
>    DELETE - "x" right on the mailbox. Note, that some servers don't allow
>             to delete a non-empty mailbox. If this is the case, the user
>             also need both "e" and "t" rights, in order to make the mailbox
>             empty first.

Is this saying that some servers, when told to DELETE a non-empty
mailbox, must internally perform STORE and EXPUNGE commands, such that
the DELETE will fail if the user has the "x" right but not both the "e"
and "t" rights?  Or is this saying that some servers will fail a DELETE
of a non-empty mailbox and that clients MAY work around this brokeness
by doing the STORE and EXPUNGE themselves?

At least in the latter case, the "r" right would also be required.

("Note that..." doesn't take a comma.  That should be fixed in a couple
other places in the draft.)

Philip Guenther

Date: Thu, 02 Dec 2004 15:32:09 +0000
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Changes to the 2086upd draft
Sender: [email-masked]

I've just submitted a new revision of 2086upd. I've done the following 
changes to the document:

1). Redefined "c" as a virtual right, added "k" right that controls 
CREATE. "c" can be "kx" or just "k", depending on a server 
implementation. (Issue raised by Ken Murchison).
A new section was created to talk about this, text was rewritten.
Please check the section 3.1.1. in the latest draft.

2). Add the rest of 2086 (commands/responses) to the 2086upd (new 
section 4) as suggested by Chris Newman. BNF was changed to ABNF in the 
process.

3). Moved description of standard rights into a separate subsection of 
section 3. This will make it easier to reference in ACL2.

4). Changed "mailbox" to "mailbox name" in a few places. An ACL can 
apply to a non-selectable mailbox, so I thought that the term "mailbox 
name" would be more appropriate.

5). Added "UTF-8 + SASLPrep" as per Chris' comment (section 4):

   Servers, when processing a command that have an authentication identifier
   as a parameter (i.e. any of SETACL, DELETEACL and LISTRIGHTS commands),
   SHOULD first prepare the received identifier using "SASLprep" profile
   [SASLprep] of the "stringprep" algorithm [StringPrep].  If the
   preparation of the identifier fails or results in an empty string, the
   server MUST refuse to perform the command with a BAD response.

6). Added text about handling of unrecognized rights, as suggested by 
Philip Guenther:

In section talking about SETACL:

      Note, that an unrecognized right MUST cause the command to return
      the BAD response. In particular, server MUST NOT silently ignore
      unrecognized rights.

And added the following examples:

   Example:    C: A001 SETACL INBOX.Drafts Chris lrswicda
               S: A001 OK Setacl complete

               C: A035 SETACL INBOX.Drafts John lrQswicda
               S: A035 BAD Uppercase rights are not allowed

               C: A036 SETACL INBOX.Drafts John lrqswicda
               S: A036 BAD The q right is not supported

7). Added few clarifications about identifier canonicalization as 
suggested by Chris Newman:

In section 4.3. GETACL command:

      Some implementations may permit multiple forms of an authentication
      identifier to reference the same IMAP account. Usually, such
      implementations will have a canonical form that is stored internally.
      An ACL response caused by an GETACL command may include a
      canonicalized form of the authentication identifier which might be
      different from the one used in the corresponding SETACL command.

In section 4.4. LISTRIGHTS command:

      Some implementations may permit multiple forms of an authentication
      identifier to reference the same IMAP account. Usually, such
      implementations will have a canonical form that is stored internally.
      A LISTRIGHTS response caused by a LISTRIGHTS command MUST always
      return the same form of an authentication identifier as specified
      by the client. This is to allow the client to correlate the response
      with the command.

8). Declared uppercase rights illegal, due to backward compatibility.

9). Removed MYRIGHTS response code, because David Cridland has pointed 
out that there would be a compatibility issue for servers that implement 
both 2086upd and ACL, caused by issue # 8.

10). Updated the description of rights required for the DELETE command 
to read:

    DELETE - "x" right on the mailbox. Note, that some servers don't allow
             to delete a non-empty mailbox. If this is the case, the user
             also need both "e" and "t" rights, in order to make the mailbox
             empty first.

             The DELETE command MUST delete the ACL associated with the
             deleted mailbox.

Is it Ok with everyone?

11). Added IANA considerations section.