Alexey Melnikov | 2 Dec 16:32 2004

Changes to the 2086upd draft


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.

(Continue reading)

Philip Guenther | 2 Dec 18:05 2004

Re: Changes to the 2086upd draft


Alexey Melnikov <Alexey.Melnikov <at> isode.com> 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
(Continue reading)

Alexey Melnikov | 2 Dec 18:17 2004

Re: Changes to the 2086upd draft


Philip Guenther wrote:

>Alexey Melnikov <Alexey.Melnikov <at> isode.com> 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 
(Continue reading)

Internet-Drafts | 3 Dec 13:14 2004
Picon

I-D ACTION:draft-ietf-imapext-2086upd-02.txt

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 
i-d-announce-request <at> ietf.org 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".

(Continue reading)

Alexey Melnikov | 6 Dec 13:58 2004

What is wrong with UIDPLUS


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 <mrc <at> CAC.Washington.EDU>
To: 	Alexey Melnikov <Alexey.Melnikov <at> isode.com>
CC: 	lemonade <at> ietf.org
References: 	<xvCWKzHs0AmX1RWv/CzKrQ.md5 <at> prosecco> 
<Pine.LNX.4.62.0412020851050.31738 <at> shiva0.cac.washington.edu> 
<VT6mF/4YC8jYDrntTTRMdw.md5 <at> [10.0.0.9]> 
<Pine.LNX.4.62.0412020930160.31738 <at> shiva0.cac.washington.edu> 
<dpq2p6Wtz1NiW6hlnOiyRg.md5 <at> [10.0.0.9]> 
<Pine.LNX.4.62.0412021119310.10843 <at> shiva1.cac.washington.edu> 
<41B3541D.2000904 <at> isode.com>

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, 
(Continue reading)

Lisa Dusseault | 8 Dec 19:01 2004

IMAPEXT Interim WG meeting


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

Lisa Dusseault | 9 Dec 01:28 2004

WG last call for IMAP ACL small-scope changes (RFC2086bis)


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

Alexey Melnikov | 21 Dec 22:47 2004

Re: WG last call for IMAP ACL small-scope changes (RFC2086bis)


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
(Continue reading)

Rob Siemborski | 22 Dec 17:43 2004
Picon

Re: WG last call for IMAP ACL small-scope changes (RFC2086bis)


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.
(Continue reading)

Alexey Melnikov | 22 Dec 22:36 2004

Re: WG last call for IMAP ACL small-scope changes (RFC2086bis)


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?


Gmane