Subject: IMAP,ACL,NAMESPACE,Mozilla,Outlook.
From: "Richard Bang" <[email-masked]>
To: <[email-masked]>
Date: Thu, 30 Sep 2004 19:09:29 +0100
List-Id: <ietf-imapext.imc.org>

Hi,

Could someone correct me if im wrong, but as I see things at the current
state of play it is not possible to implement a shared folder scheme that
will work will all IMAP clients (and allow some of them to configure the
sharing rights).

I have managed to get ACL and NAMESPACE to work with Mozilla, but this
forces me to use name spaces for shared items and this instantly breaks
Outlook (& Express).

While it is trivial to make it work with either, and if I had the ability to
know which flavour of client was running, I could make it work with both, it
does not seem that there is a selection of namespace/acl settings that allow
Mozilla to be happy AND Outlook to be happy.

If I am wrong them please could someone suggest a name space that will work
with both.

Please don't reply with "Don't support Outlook its terrible" because I
support what my customers want me to support not the other way round.

It is not my intention to flame or irritate, just to express frustration and
ask for help.

I have a personal folder structure where any folder may or may not be shared
with one or more other users. I do not see any way to show this in either
NAMESPACE or ACL. May I suggest that a future revision of ACL includes a
LIST tag that explicitly identifies a resource that could be shared and also
one that is currently shared. This would then prevent the requirement of
structuring the store to match the clients expectation.

If there is currently a way of doing this please let me know.

For now I will require all customers to use our resource management tool.

Regards

Richard.

To: Richard Bang <[email-masked]>
Cc: [email-masked]
From: Philip Guenther <[email-masked]>
Subject: Re: ACL question. 
Date: Thu, 30 Sep 2004 08:47:37 -0700
Sender: [email-masked]

Richard Bang <[email-masked]> writes:
>I now get:
>005 getacl "shared/lindsay/inbox"
>* ACL "shared/lindsay/inbox" lindsay plrswida richard plrsw
>005 OK getacl completed
>
>And
>
>008 listrights "shared/lindsay/inbox" "bob"
>* LISTRIGHTS "shared/lindsay/inbox" bob "" plr sw i d a
>008 OK listrights completed

Those look okay, though tieing 'p' to 'l' and 'r' instead of 'i' seems
kinda weird.  <shrug>  Whether the 'p' right has any effect is
implementation defined anyway.

>Given the above response is the following considered valid?
>
>007 setacl "shared/lindsay/inbox" "bob" r
>007 NO Access Denied

Sure, the client failed to include the rights tied to 'r', so the server
is supposed to reject the request.  To quote section 3 or RFC 2086:
   An implementation may tie rights together or may force rights to
   always or never be granted to particular identifiers.  <...>  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. <...>

Philip Guenther

From: "Richard Bang" <[email-masked]>
To: <[email-masked]>
Subject: RE: ACL question. 
Date: Thu, 30 Sep 2004 16:13:58 +0100
Sender: [email-masked]

Hi,

My reading of 4.4 was that "what rights may be granted" meant "what rights
were granted", silly me.

Thanks for clearing that up for me.

I now get:
005 getacl "shared/lindsay/inbox"
* ACL "shared/lindsay/inbox" lindsay plrswida richard plrsw
005 OK getacl completed

And

008 listrights "shared/lindsay/inbox" "bob"
* LISTRIGHTS "shared/lindsay/inbox" bob "" plr sw i d a
008 OK listrights completed

Given the above response is the following considered valid?

007 setacl "shared/lindsay/inbox" "bob" r
007 NO Access Denied

Thanks again for the help.

Richard.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Philip Guenther
> Sent: 30 September 2004 15:30
> To: Richard Bang
> Cc: [email-masked]
> Subject: Re: ACL question. 
> 
> 
> "Richard Bang" <[email-masked]> writes:
> >I've just implemented ACL into my server and I'm testing it 
> with the latest
> >Mozilla.
> ...
> >005 getacl "shared/[email-masked]/inbox"
> >* ACL "shared/lindsay/inbox" lindsay plrswida
> >* ACL "shared/lindsay/inbox" richard plr
> >005 OK getacl completed
> 
> You should be sending one ACL response for the mailbox that lists all
> the identifer+rights pairs, ala:
> 
> * ACL "shared/lindsay/inbox" lindsay plrswida richard plr
> 
> As is, it looks like the rights on the mailbox changed mid-command.
> 
> ...
> >008 listrights "shared/lindsay/inbox" "bob"
> >* LISTRIGHTS "shared/lindsay/inbox"
> >008 OK listrights completed
> 
> That response doesn't match the syntax.  Where's the identifier or
> required rights?  If there are any rights that can be given 
> to bob, then
> you better list them off, say:
> 
> * LISTRIGHTS "shared/lindsay/inbox" "bob" "" l r s p w i d a
> 
> ...assuming bob can be given those rights.  Read section 5.2 
> of RFC 2086
> closely.
> 
> 
> Philip Guenther
> 
> 

Date: Thu, 30 Sep 2004 15:48:09 +0100
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: Major changes in draft-ietf-imapext-list-extensions-09
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Alexey Melnikov writes:
>
>> Barry wanted to retrofit multimailbox search to use LISTEXT syntax, he
>> asked for multiple patterns.
>>
>> Just think of this as a more generic mailbox pattern (we don't want to
>> have regular expression here ;-)).
>
> Might want to add a note to section 3.1 then, saying explicitly that 
> if multiple  wildcards match a given mailbox, it is to be returned 
> only once. 

Will do, thanks.

> I'd love to see a realistic example justifying the patterns list, 
> though. If noone can come up with even one real and good example, then 
> IMO the list should go away again. 

How about <LIST "" ("INBOX" "Drafts" "Sent")>?

> Btw. 3.1 is headlined "principals". The correct spelling is principles.

Fixed.

> And since I'm being pedantic, please cut the BiCapitalization. Or if 
> it has to stay, at least be consistent. If \NonExistent has to stay, 
> \HasSubmailboxes should be either \HasSubMailboxes or \HasSubMailBoxes. 

Ok :-).

>> I think you are right. I will change this to BAD, so if you object -
>> speak up now.
>
> Oh, good. I missed that and already used Bad ;)

Date: Thu, 30 Sep 2004 15:38:58 +0100
From: Alexey Melnikov <[email-masked]>
To: Richard Bang <[email-masked]>
CC: [email-masked]
Subject: Re: ACL question.
Sender: [email-masked]

Richard Bang wrote:

>Hi,
>
>I've just implemented ACL into my server and I'm testing it with the latest
>Mozilla.
>
>While Mozilla correctly identifies the access rights available to all
>folders, it does NOT allow me to share anything, even if I have the "a"
>right.
>
I think you are looking for solution in a wrong place.
"a" means "administer". It doesn't control or tell whether a mailbox is 
shared or not.

My best guess about your problem is that your server doesn't support 
NAMESPACE, thus Mozilla treats all mailboxes as "private".
Note, that using ACL extension one might be able to share a private 
mailbox (if server implementation allows sharing), but there is 
currently no way to convey this in IMAP.

Alexey

To: "Richard Bang" <[email-masked]>
Cc: [email-masked]
From: Philip Guenther <[email-masked]>
Subject: Re: ACL question. 
Date: Thu, 30 Sep 2004 07:30:17 -0700
Sender: [email-masked]

"Richard Bang" <[email-masked]> writes:
>I've just implemented ACL into my server and I'm testing it with the latest
>Mozilla.
...
>005 getacl "shared/[email-masked]/inbox"
>* ACL "shared/lindsay/inbox" lindsay plrswida
>* ACL "shared/lindsay/inbox" richard plr
>005 OK getacl completed

You should be sending one ACL response for the mailbox that lists all
the identifer+rights pairs, ala:

* ACL "shared/lindsay/inbox" lindsay plrswida richard plr

As is, it looks like the rights on the mailbox changed mid-command.

...
>008 listrights "shared/lindsay/inbox" "bob"
>* LISTRIGHTS "shared/lindsay/inbox"
>008 OK listrights completed

That response doesn't match the syntax.  Where's the identifier or
required rights?  If there are any rights that can be given to bob, then
you better list them off, say:

* LISTRIGHTS "shared/lindsay/inbox" "bob" "" l r s p w i d a

...assuming bob can be given those rights.  Read section 5.2 of RFC 2086
closely.

Philip Guenther

Date: Thu, 30 Sep 2004 10:18:16 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Alexey Melnikov <[email-masked]>
CC: [email-masked]
Subject: Re: listext-09 comments
Sender: [email-masked]

Alexey Melnikov wrote:

> Ken Murchison wrote:
> 
>>>>> I implemented Barry's last LISTEXT draft in Cyrus well over a year 
>>>>> ago (possibly two), but haven't looked into updating to the latest 
>>>>> draft yet.
>>>>
>>>>
>>> What capability does that version advertise?
>>
>>
>> LISTEXT LIST-SUBSCRIBED
>>
>> If you're worried about wide deployment of something that isn't up do 
>> date with the latest spec, LISTEXT support in Cyrus is currently a 
>> compile-time option, so I doubt you'll see very many of them in the wild.
> 
> 
> I will change the capability name before publication. I am not telling 
> anyone what it would be ;-).

I don't feel that its necessary, but I'm not going to stop you.

-- 
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: Thu, 30 Sep 2004 15:13:21 +0100
From: Alexey Melnikov <[email-masked]>
To: Ken Murchison <[email-masked]>
CC: [email-masked]
Subject: Re: listext-09 comments
Sender: [email-masked]

Ken Murchison wrote:

>>>> I implemented Barry's last LISTEXT draft in Cyrus well over a year 
>>>> ago (possibly two), but haven't looked into updating to the latest 
>>>> draft yet.
>>>
>> What capability does that version advertise?
>
> LISTEXT LIST-SUBSCRIBED
>
> If you're worried about wide deployment of something that isn't up do 
> date with the latest spec, LISTEXT support in Cyrus is currently a 
> compile-time option, so I doubt you'll see very many of them in the wild.

I will change the capability name before publication. I am not telling 
anyone what it would be ;-).

Alexey

From: "Richard Bang" <[email-masked]>
To: <[email-masked]>
Subject: ACL question.
Date: Thu, 30 Sep 2004 15:03:34 +0100
Sender: [email-masked]

Hi,

I've just implemented ACL into my server and I'm testing it with the latest
Mozilla.

While Mozilla correctly identifies the access rights available to all
folders, it does NOT allow me to share anything, even if I have the "a"
right.

A test session looks like this

* OK IMAP4 IMAP4rev1 Server
001 CAPABILITY
* CAPABILITY IMAP4 IMAP4REV1 AUTH=CRAM-MD5 AUTH=LOGIN ACL IDLE XTRASH
001 OK CAPABILITY completed
002 LOGIN xxx yyy
002 OK LOGIN completed
003 lsub "" "*"
* LSUB () "/" "Inbox"
* LSUB () "/" "Sent Items"
* LSUB () "/" "Drafts"
* LSUB () "/" "temp"
* LSUB () "/" "test"
* LSUB () "/" "trash"
* LSUB () "/" "barsoum"
* LSUB (\NoSelect) "/" "Shared"
* LSUB (\NoSelect) "/" "Shared/lindsay"
* LSUB () "/" "Shared/lindsay/inbox"
003 OK LSUB completed
004 getacl "INBOX"
004 OK getacl completed
005 getacl "shared/[email-masked]/inbox"
* ACL "shared/lindsay/inbox" lindsay plrswida
* ACL "shared/lindsay/inbox" richard plr
005 OK getacl completed
006 myrights "shared/lindsay/inbox"
* MYRIGHTS "shared/lindsay/inbox" plr
006 OK myrights completed
007 setacl "shared/lindsay/inbox" "bob" r
007 NO Access Denied
008 listrights "shared/lindsay/inbox" "bob"
* LISTRIGHTS "shared/lindsay/inbox"
008 OK listrights completed
009 deleteacl "shared/lindsay" "lindsay"
009 NO Access Denied
010 setacl "barsoum" "bob" r
010 OK setacl completed

Mozilla does this:

.....
26 getacl "barsoum"
* ACL "barsoum" [email-masked] plrswida
* ACL "barsoum" [email-masked] plrswi
* ACL "barsoum" [email-masked] plr
26 OK getacl completed
27 myrights "barsoum"
* MYRIGHTS "barsoum" plrswida
27 OK myrights completed

Is anyone able to tell me what I'm doing wrong that is stopping Mozilla
recognising folders are shared, it lists them all as personal folders and
not shared, when clearly its not the case.

Any help would be greatly appreciated.

Regards

Richard Bang

Floosietek Ltd
[email-masked]
http://www.floosietek.com

Date: Thu, 30 Sep 2004 16:02:56 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Major changes in draft-ietf-imapext-list-extensions-09
Cc: Alexey Melnikov <[email-masked]>, Philip Guenther <[email-masked]>
Sender: [email-masked]

Alexey Melnikov writes:
> Barry wanted to retrofit multimailbox search to use LISTEXT syntax, he
> asked for multiple patterns.
>
> Just think of this as a more generic mailbox pattern (we don't want to
> have regular expression here ;-)).

Might want to add a note to section 3.1 then, saying explicitly that if 
multiple  wildcards match a given mailbox, it is to be returned only 
once.

I'd love to see a realistic example justifying the patterns list, 
though. If noone can come up with even one real and good example, then 
IMO the list should go away again.

Btw. 3.1 is headlined "principals". The correct spelling is principles. 
And since I'm being pedantic, please cut the BiCapitalization. Or if it 
has to stay, at least be consistent. If \NonExistent has to stay, 
\HasSubmailboxes should be either \HasSubMailboxes or \HasSubMailBoxes.

> I think you are right. I will change this to BAD, so if you object -
> speak up now.

Oh, good. I missed that and already used Bad ;)

Arnt

Date: Thu, 30 Sep 2004 09:51:43 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Philip Guenther <[email-masked]>
CC: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: listext-09 comments
Sender: [email-masked]

Philip Guenther wrote:

> Arnt Gulbrandsen <[email-masked]> writes:
> 
>>Ken Murchison writes:
> 
> ...
> 
>>>I implemented Barry's last LISTEXT draft in Cyrus well over a year ago 
>>>(possibly two), but haven't looked into updating to the latest draft 
>>>yet.
> 
> 
> What capability does that version advertise?

LISTEXT LIST-SUBSCRIBED

If you're worried about wide deployment of something that isn't up do 
date with the latest spec, LISTEXT support in Cyrus is currently a 
compile-time option, so I doubt you'll see very many of them in the wild.

-- 
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: Wed, 29 Sep 2004 20:33:12 +0100
From: Alexey Melnikov <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Major changes in draft-ietf-imapext-list-extensions-09
Sender: [email-masked]

>>>- The multiple pattern part of the extension hasn't gotten much
>>> discussion.  Indeed, I had completely overlooked it until I made a
>>> close read of the grammar while whipping up a test implementation.
>>>
>>That is because it was added in the last revision ;-).
>>    
>Well, that explains the silence.  I have no particularly opinion on it
>other than a desire to not let it complicate things more than they are.
>Is this something that clients actually do, doing multiple listings with
>different patterns?  Is this useful complexity?
>
>>> (I presume
>>> this was added as a performance enhancement for _servers_, as it
>>> should have no real effect on _protocol_ performance compared to
>>> simply pipelining the requests.)
>>>
>>The client can save few bytes ;-).
>>    
>Seriously, that's never been a primary concern for IMAP; saving RTTs is.
>If byte count was a worry then there would be push-back on the length of
>the names of the LISTEXT options.

Barry wanted to retrofit multimailbox search to use LISTEXT syntax, he
asked for multiple patterns.

Just think of this as a more generic mailbox pattern (we don't want to
have regular expression here ;-)).

>In section 3:
>        A server MUST respond to options it does not recognize with
>        a NO response.
>Shouldn't that be a BAD response?

I think you are right. I will change this to BAD, so if you object -
speak up now.

>In section 5 (Examples), I find the layout a bit difficult to keep
>straight: the text describing, for example, example 3, comes _before_
>the line "Example 3:", so that my first inclination is to read it as an
>explanation of the previous protocol exchange instead of as a lead-in to
>the next exchange.  Perhaps the "Example #:" lines should be moved up
>before the paragraph and de-indented one level?  Or maybe the text
>should be moved to after the protocol exchange and recast as an
>explanation instead of an introduction?

Good point, I've done the latter.

>Some of the responses in the examples are, if I understand correctly,
>permitted but not required.  Since a server implementation can always
>send additional unrelated responses, there's no real 'maximal' set of
>permitted responses, so I think the examples should document the minimum
>required set of responses.  For example, I don't think the second LIST
>response in example 2 ("Fruit" as a \PlaceHolder) is actually required:
>all of the submailboxes of "Fruit" that are selected are also matched.
>
>Indeed, when the pattern is "*", the server should never need to send a
>\PlaceHolder response and should be able to omit the \HasSubmailboxes
>flag from the responses it does send, no?

I would like to allow for simple minded implementations that generate
\PlaceHolder/\HasSubmailboxes without checking what kind of pattern is
used. However I don't want to prevent smart implementations, that don't
send them for "*".

>  I believe this is supported
>by the current wording, though perhaps it should be stated that a server
>is only _required_ to send a \Placeholder or \HasSubmailboxes response
>if the matched mailbox has at least one selected but unmatched
>submailbox, but is _permitted_ to send one of those if the matched
>mailbox has any selected submailboxes at all.  If people agree with
>that and feel it to be a clearer expression of the intent of
>\Placeholder and \HasSubmailboxes, then I'll propose specific wording
>changes, probably replacing some of the current description.

Yes, I think that was the intent. In fact the draft says:

    The MATCHPARENT selection option described below REQUIRES that the
    "\Placeholder" and the "\HasSubmailboxes" attributes be accurately
    computed.

Any clarifications would be welcomed.

Alexey

Date: Thu, 30 Sep 2004 12:33:40 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: listext-09 comments
Cc: Ken Murchison <[email-masked]>, Philip Guenther <[email-masked]>
Sender: [email-masked]

Philip Guenther writes:
> Passing of multiple patterns was added in rev -09, so his parser 
> doesn't support that at all. I missed the error when implementing 
> because I 'knew' what those productions were supposed to do and 
> simply used the "parse a list of astring" call in my code.

Thanks. I guess the sky isn't falling this week either ;)

Arnt

To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked], Ken Murchison <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: listext-09 comments 
Date: Thu, 30 Sep 2004 03:28:47 -0700
Sender: [email-masked]

Arnt Gulbrandsen <[email-masked]> writes:
>Ken Murchison writes:
...
>> I implemented Barry's last LISTEXT draft in Cyrus well over a year ago 
>> (possibly two), but haven't looked into updating to the latest draft 
>> yet.

What capability does that version advertise?

>And you didn't note the missing SP? Or does your parser work without the SP?

Passing of multiple patterns was added in rev -09, so his parser
doesn't support that at all.  I missed the error when implementing
because I 'knew' what those productions were supposed to do and
simply used the "parse a list of astring" call in my code.

Philip Guenther

Date: Thu, 30 Sep 2004 12:07:15 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: listext-09 comments
Cc: Ken Murchison <[email-masked]>
Sender: [email-masked]

Ken Murchison writes:
> Arnt Gulbrandsen wrote:
>> 3. The patterns production could be changed to (spot the new SP):
>>
>>      patterns = "(" list-mailbox *(SP list-mailbox) ")"
>>
>> (Am I the first to implement? Surely not!)
>
> I implemented Barry's last LISTEXT draft in Cyrus well over a year ago 
> (possibly two), but haven't looked into updating to the latest draft 
> yet.

And you didn't note the missing SP? Or does your parser work without the SP?

Arnt

Date: Wed, 29 Sep 2004 23:24:51 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: listext-09 comments
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> 
> Comments.
> 
> 1. Shortening the lines a little would be good. Some of them are as much 
> as 84 characters, RFCs generally are no more than 75 or so. (A printout 
> looked very bad.)
> 
> 2. The mbox_or_pat production could be named mbox-or-pat. Would fit the 
> naming convention.
> 
> 3. The patterns production could be changed to (spot the new SP):
> 
>      patterns = "(" list-mailbox *(SP list-mailbox) ")"
> 
> (Am I the first to implement? Surely not!)

I implemented Barry's last LISTEXT draft in Cyrus well over a year ago 
(possibly two), but haven't looked into updating to the latest draft yet.

-- 
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: Wed, 29 Sep 2004 18:30:16 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: listext-09 comments
Sender: [email-masked]

Comments.

1. Shortening the lines a little would be good. Some of them are as much 
as 84 characters, RFCs generally are no more than 75 or so. (A printout 
looked very bad.)

2. The mbox_or_pat production could be named mbox-or-pat. Would fit the 
naming convention.

3. The patterns production could be changed to (spot the new SP):

      patterns = "(" list-mailbox *(SP list-mailbox) ")"

(Am I the first to implement? Surely not!)

More sure to come, but I have to run off buy groceries now ;)

Arnt

From: Dave Cridland <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Major changes in draft-ietf-imapext-list-extensions-09
Date: Thu, 23 Sep 2004 09:40:00 +0100
Sender: [email-masked]

On Thu Sep 23 08:37:10 2004, Arnt Gulbrandsen wrote:
> 
> Alexey Melnikov writes:
>> On a related note, has anybody seen an IMAP client that uses 
>> pipelining?
> 
> I know of three, actually. One released, one maybe, one not.

You can add another one to the "maybe" column, too - my little client 
does pipeline for one or two things, but not LIST as yet. Nothing 
prevents this, it simply happens not to. (FWIW, it'll handle the case 
of the server responding to commands out of order, as well, because 
it's the same code as for ACAP, and the ACAP server does.)

On top of that, SquirrelMail, the PHP-based webmail client, does 
pipelining last I looked, specifically pipelining LIST as it receives 
responses from LSUB. (I don't know if this one was the "released" one 
Arnt mentioned.)

I've always thought of pipelining as quite common, actually, but 
generally used in special cases rather than as the norm.

Dave.

Date: Thu, 23 Sep 2004 09:37:10 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Major changes in draft-ietf-imapext-list-extensions-09
Sender: [email-masked]

Alexey Melnikov writes:
> On a related note, has anybody seen an IMAP client that uses pipelining?

I know of three, actually. One released, one maybe, one not.

I'll not name names, since one of them is an unreleased commercial 
product. (I've no connection to the vendor, except that someone working 
there once listened to some advice of mine.)

Arnt

To: Alexey Melnikov <[email-masked]>
From: Philip Guenther <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Major changes in draft-ietf-imapext-list-extensions-09 
Date: Wed, 22 Sep 2004 20:41:08 -0700
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:
...
>>- The multiple pattern part of the extension hasn't gotten much
>>  discussion.  Indeed, I had completely overlooked it until I made a
>>  close read of the grammar while whipping up a test implementation.
>>
>That is because it was added in the last revision ;-).

Well, that explains the silence.  I have no particularly opinion on it
other than a desire to not let it complicate things more than they are.
Is this something that clients actually do, doing multiple listings with
different patterns?  Is this useful complexity?

>>  (I presume
>>  this was added as a performance enhancement for _servers_, as it
>>  should have no real effect on _protocol_ performance compared to
>>  simply pipelining the requests.)
>>
>The client can save few bytes ;-).

Seriously, that's never been a primary concern for IMAP; saving RTTs is.
If byte count was a worry then there would be push-back on the length of
the names of the LISTEXT options.

In section 3:
        A server MUST respond to options it does not recognize with
        a NO response.
Shouldn't that be a BAD response?

In section 5 (Examples), I find the layout a bit difficult to keep
straight: the text describing, for example, example 3, comes _before_
the line "Example 3:", so that my first inclination is to read it as an
explanation of the previous protocol exchange instead of as a lead-in to
the next exchange.  Perhaps the "Example #:" lines should be moved up
before the paragraph and de-indented one level?  Or maybe the text
should be moved to after the protocol exchange and recast as an
explanation instead of an introduction?

Some of the responses in the examples are, if I understand correctly,
permitted but not required.  Since a server implementation can always
send additional unrelated responses, there's no real 'maximal' set of
permitted responses, so I think the examples should document the minimum
required set of responses.  For example, I don't think the second LIST
response in example 2 ("Fruit" as a \PlaceHolder) is actually required:
all of the submailboxes of "Fruit" that are selected are also matched.

Indeed, when the pattern is "*", the server should never need to send a
\PlaceHolder response and should be able to omit the \HasSubmailboxes
flag from the responses it does send, no?  I believe this is supported
by the current wording, though perhaps it should be stated that a server
is only _required_ to send a \Placeholder or \HasSubmailboxes response
if the matched mailbox has at least one selected but unmatched
submailbox, but is _permitted_ to send one of those if the matched
mailbox has any selected submailboxes at all.  If people agree with
that and feel it to be a clearer expression of the intent of
\Placeholder and \HasSubmailboxes, then I'll propose specific wording
changes, probably replacing some of the current description.

What does a response with \Placeholder or \HasSubmailboxes mean when
MATCHPARENT is used with REMOTE but without SUBSCRIBED?  I see three
possible answers:
a) it means the mailbox has at least one submailbox that is remote
b) is means the mailbox has at least one submailbox, local or remote
c) (b), but that's the same as \HasChildren, so MATCHPARENT shouldn't be
   allowed with just REMOTE: it should require SUBSCRIBED or some other
   option that affects the selection criteria.

IMO, the current text says (b).  Switching it to (a) would require a
major rethink of the concept of "selected", or would effectively declare
MATCHPARENT as having ad hoc interaction with each selection option.  I
would just as soon go with (c) and can help with text to that effect.

Depending on how that question is settled, I may have an argument that
in response to <LIST (SUBSCRIBED MATCHPARENT) "" "%">, responses with
the \Placeholder flag also need the \Subscribed flag to avoid
ambiguity.

To make this all concrete, I've implemented my understanding of the
X-DRAFT-W09-LISTEXT extension and should soon be able to point people at
a server running it so they can compare their expectation to it,
probably via an anonymous account that can list a hierarchy with a good
mix of mailboxes, both subscribed and not, including trees that match
some of the examples.  The server doesn't support remote mailboxes, so
those examples won't reproduce exactly.  If you're interested, fire me a
note and I'll give you the info on how to connect.

Philip Guenther

Date: Wed, 22 Sep 2004 18:17:40 +0100
From: Alexey Melnikov <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Major changes in draft-ietf-imapext-list-extensions-09
Sender: [email-masked]

Philip Guenther wrote:

>Other thoughts/comments:
>
>- if an option is repeated in an option list, is the server required to,
>  permitted to, or forbidden from rejecting the command with a BAD
>  response?
>
IMHO, I think the server should allow this, but the client SHOULD NOT do 
this.
But I am fine with prohibiting this as well.
And I agree that this has to be clarified.

>- The multiple pattern part of the extension hasn't gotten much
>  discussion.  Indeed, I had completely overlooked it until I made a
>  close read of the grammar while whipping up a test implementation.
>
That is because it was added in the last revision ;-).

>  Perhaps this change should be mentioned in the abstract?
>
Ok. Can you propose any text?

>  (I presume
>  this was added as a performance enhancement for _servers_, as it
>  should have no real effect on _protocol_ performance compared to
>  simply pipelining the requests.)
>
The client can save few bytes ;-).

On a related note, has anybody seen an IMAP client that uses pipelining?

>- The LIST command requires special processing when the pattern argument
>  is the empty string.  How does LISTEXT interact with that?  Is the
>  special processing skipped when SUBSCRIBED is used?  Should the server
>  be permitted to ignore the MATCHPARENT and/or CHILDREN options for the
>  response generated by the empty pattern?  Is there any special result
>  or change if the empty pattern is one of multiple patterns in a LIST
>  command?
>
These are all good questions. I think that for simplicity when there are 
multiple patterns, the empty string should not have a special meaning 
and should be ignored.

>- Is a folder that doesn't exist but that meets the selection criteria
>  sufficient to trigger a \HasSubmailboxes or \Placeholder responses?
>  If so, then \HasSubmailboxes and \Placeholder do _not_ imply
>  \HasChildren.  E.g., consider the following:
>	a1 LIST "" ("foo" "foo/*")
>	* LIST () "/" foo
>	a1 OK done
>	a2 LIST (SUBSCRIBED) "" "foo/*"
>	* LIST (\Subscribed \NonExistent) "/" foo/bar
>	a2 OK done
>	a3 LIST (SUBSCRIBED MATCHPARENT) "" foo RETURN (CHILDREN)
>	* LIST (\Subscribed \Placeholder \HasNoChildren) "/" foo
>	a3 OK done
>  
>
Hmm, this is an interesting edge case. I think you are right, I should 
remove any mentioning of \HasSubmailboxes/\PlaceHolder implying 
\HasChildren.
I should also add your example to the document.

Alexey

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-2086upd-00.txt
Date: Mon, 13 Sep 2004 16:05:35 -0400
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-00.txt
	Pages		: 0
	Date		: 2004-9-13
	
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-00.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-00.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-00.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-00.txt

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

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

--OtherAccess--

--NextPart--

To: Mark Crispin <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: Major changes in draft-ietf-imapext-list-extensions-09 
Date: Sun, 12 Sep 2004 23:33:22 -0700
Sender: [email-masked]

Mark Crispin <[email-masked]> writes:
...
>You need to fix the list-select-option and/or list-select/opts rule in the 
>formal syntax so as to enforce this ban.
>
>Suggest:
>    list-select-opts   = "(" [list-select-option *(SP list-select-option)]
>                         [SP "MATCHPARENT"] ")"
>                         ; list selection options, e.g. REMOTE
>
>and then remove MATCHPARENT from list-select-option.

I think you meant to move a close-bracket in that, to instead get:
     list-select-opts   = "(" [list-select-option *(SP list-select-option)
                          [SP "MATCHPARENT"]] ")"

but that requires that MATCHPARENT be last in the match option list.  If
you want the grammar to forbid MATCHPARENT without another match option,
I would suggest:

list-select-opts = "(" [*(list-select-mod-opt SP) list-select-base-opt
			*(SP list-select-opt)] ")"

list-select-opt = list-select-mod-opt / list-select-base-opt

list-select-base-opt = "SUBSCRIBED" / "REMOTE" / option-extension
			; options that can be used by themselves

list-select-mod-opt = "MATCHPARENT" / option-extension
			; options that require a list-select-base-opt
			; to also be present

Other thoughts/comments:

- if an option is repeated in an option list, is the server required to,
  permitted to, or forbidden from rejecting the command with a BAD
  response?

- The multiple pattern part of the extension hasn't gotten much
  discussion.  Indeed, I had completely overlooked it until I made a
  close read of the grammar while whipping up a test implementation.
  Perhaps this change should be mentioned in the abstract?  (I presume
  this was added as a performance enhancement for _servers_, as it
  should have no real effect on _protocol_ performance compared to
  simply pipelining the requests.)

- The LIST command requires special processing when the pattern argument
  is the empty string.  How does LISTEXT interact with that?  Is the
  special processing skipped when SUBSCRIBED is used?  Should the server
  be permitted to ignore the MATCHPARENT and/or CHILDREN options for the
  response generated by the empty pattern?  Is there any special result
  or change if the empty pattern is one of multiple patterns in a LIST
  command?

- Is a folder that doesn't exist but that meets the selection criteria
  sufficient to trigger a \HasSubmailboxes or \Placeholder responses?
  If so, then \HasSubmailboxes and \Placeholder do _not_ imply
  \HasChildren.  E.g., consider the following:
	a1 LIST "" ("foo" "foo/*")
	* LIST () "/" foo
	a1 OK done
	a2 LIST (SUBSCRIBED) "" "foo/*"
	* LIST (\Subscribed \NonExistent) "/" foo/bar
	a2 OK done
	a3 LIST (SUBSCRIBED MATCHPARENT) "" foo RETURN (CHILDREN)
	* LIST (\Subscribed \Placeholder \HasNoChildren) "/" foo
	a3 OK done

Philip Guenther

Date: Fri, 10 Sep 2004 13:28:56 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Major changes in draft-ietf-imapext-list-extensions-09
Sender: [email-masked]

On Thu, 9 Sep 2004, Alexey Melnikov wrote:
> 1). Add a requirement that the MATCHPARENT selection option can't be used as 
> the only selection option

You need to fix the list-select-option and/or list-select/opts rule in the 
formal syntax so as to enforce this ban.

Suggest:

    list-select-opts   = "(" [list-select-option *(SP list-select-option)]
                         [SP "MATCHPARENT"] ")"
                         ; list selection options, e.g. REMOTE

and then remove MATCHPARENT from list-select-option.

Nit:

The document has many over-long lines.  This will need to be fixed before 
it goes to RFC anyway, so you might as well fix it now.

-- 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-list-extensions-09.txt
Date: Fri, 10 Sep 2004 15:55:55 -0400
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 LIST Command Extensions
	Author(s)	: B. Leiba, A. Melnikov
	Filename	: draft-ietf-imapext-list-extensions-09.txt
	Pages		: 0
	Date		: 2004-9-10
	
IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we
have added extensions that have required specialized lists (see
[MboxRefer] for an example) we have had to expand the number of list
commands, since each extension must add its function to both LIST and
LSUB, and these commands are not, as they are defined, extensible.
If we've needed the extensions to work together, we've had to add a
set of commands to mix the different options, the set increasing in
size with each new extension.  This document describes an extension
to the base LIST command that will allow these additions to be done
with mutually compatible options to the LIST command, avoiding the
exponential increase in specialized list commands.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-list-extensions-09.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-list-extensions-09.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-list-extensions-09.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-list-extensions-09.txt

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

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

--OtherAccess--

--NextPart--

Date: Thu, 09 Sep 2004 20:48:14 +0100
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Major changes in draft-ietf-imapext-list-extensions-09
Sender: [email-masked]

I've just submitted LISTEXT-09, that should be announced soon.
Below is the list of changes:

1). Add a requirement that the MATCHPARENT selection option can't be 
used as the only selection option (as per Cyrus Daboo suggestion):

          The MATCHPARENT option MUST NOT occur as the only selection 
option,
          as it only makes sense when other selection options are also used.
          The server MUST return BAD tagged response in such case.

2). Removed the REMOTE return option as it is redundant (as per recent 
post by Dave Cridland)

3). Clarified the purpose of selection options and return options. 
Clarified how multiple selection options can interact.

4). Clarified when a server implementing another extension that depends 
on LISTEXT has to return the LISTEXT capability in a CAPABILITY response.

5). Clarified the purpose of \Placeholder and \HasSubmailboxes flags.

6). I've changed all occurrences of "flag" to "attribute", to be more 
consistent. I've noticed that the RFC 3501 mostly uses the term 
"attribute", but sometimes (especially in ABNF comments) it uses the 
term "flag".

7). Added a new section with additional requirements on clients:

   All clients that support this extension MUST treat an attribute with
   a stronger meaning, as implying any attribute that can be inferred 
from it.
   For example, the client must treat presense of the \NoInferiors attribute
   as if the \HasNoChildren attribute was also sent by the server.

And added a table at the end that summarizes all described "inference" 
rules.

8). Various other editorial changes and clarifications (in particular 
"s/match option/selection option" and updated the text to use "mailbox 
name" instead of "mailbox" where appropriate). I've also added more 
examples. Can somebody check the example #8 and #9 in the new draft? Is 
the example #9 useful?
========
I have two new minor issues to discuss (actually, we kind of discussed 
one of them a bit):

1). Do we need to add a special section for unsolicited responses?
Do we want to require properly computed \Remote and \Subscribed
attributes in all unsolicited LIST responses?

(I tend to answer "yes". This should even work with unextended LIST, as
all clients should ignore unrecognized mailbox attributes.)

2). There is the following text in the current LISTEXT draft:
 >   In some instances a server that supports the Child Mailbox Extension
 >   might not be able to determine whether a mailbox has children.  For
 >   example it may have difficulty determining whether there are child
 >   mailboxes when LISTing mailboxes while operating in a particular
 >   namespace.

Should the same be done for \HasSubmailboxes/\PlaceHolder?
(I tend to say "no", but some people might argue that this is additional
burden for server implementations).

Alexey

Date: Fri, 3 Sep 2004 20:24:59 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Dave Cridland <[email-masked]>, [email-masked]
Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10)
Sender: [email-masked]

On Tue, 24 Aug 2004, Alexey Melnikov wrote:

>> 's' is used for the per-user \SEEN flag in ACL[2]. \SEEN is the only 
>> per-user data I'm aware of in an IMAP4 shared mailbox. 
>
> I don't think ACL2 says that 's' only controls private (per-user) \Seen even 
> though Cyrus Imap implements the \Seen flag as private.

This is true, as I understand it, it only controls \Seen.

> I've implemented 
> \Seen as a shared flag once. Having said that, I don't like overloading the 
> meaning of different ACL rights.

Indeed, this will get us right back where we are now with ACL, where the 
delete right is inconveinently overloaded.

-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-----

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Meeting notes
Date: Wed, 1 Sep 2004 10:50:14 -0700
Sender: [email-masked]

Here are the notes from the IMAPEXT WG meeting, which I adapted from 
the Jabber logs (thanks note-takers Ned and others)

---

TOPIC: Status of i18n and sort drafts

Summary: These are blocked on the comparator draft, which needs IANA 
review and buyin.  Chris Newman reports that he has had a meeting with 
Michelle Cotton (IANA) and progress was made

TOPIC: List extensions

Issue: What to do about \Placeholder (Mark Crispin has asked if we can 
get rid of it).  We need comments from mail client writers on how 
useful different flags and options are - Mark thinks it is 
overengineered.  After discussion, we asked client people to post to 
the list asking if they would use \Placeholder.  Alexey Melnikov will 
formulate the question and post it to the list and Cyrus Daboo to try 
to answer.

Issue: Currently filter/select concepts are combined.  Propose: Two 
parts, one to match mailboxes, other to control info returned.
   e.g. LIST <match-options> mailbox-spec RETURN <return-options>
Some argument that all options need to be returned.  Cyrus argues that 
this is good for use with ANNOTATEMORE.  Lisa proposed that we could 
change only the name to be clearer, e.g.  changing <return-options> to 
<also-return>.  In this proposal, any responses that are implied by 
what you're asking for will be provided automatically.  E.g. if you say 
"no standard flags" you'll still get subscribed if you're querying on 
that.  A Proposal will be sent to the list.

TOPIC: Annotate draft

ACL issues: Cyrus says he tried to keep ACL as informative.  Noted that 
ACL can be referenced because it is already an RFC; ACL2 is not done 
yet. All the bits needed are in ACL but some of the explanation of what 
the bits mean appears to be missing, specifically what the old 
[READ-ONLY] and [READ-WRITE] mean and whether ACL should imply one or 
the other.  Pete Resnick is concerned about how mailbox access rights 
tie into annotations.  ACL2 apparently resolves this but is not ready 
to reference.   Shared annotations only interact with 
read-only/read-write -- private annotations are where the problem is.   
Pete argues for clearly separating these things.   One option is to 
base it on ACL2 and add another bit controlling the ability to write 
private annotations.

Proposal for ACL issue: could solve this with a new bit added to _old_ 
ACL.   Chris Newman, channeling Mark Crispin, says adding stuff to ACL 
is bad because there are implementation that do not/cannot support old 
ACL.

Need to warn that clients should not copy ACL bits they do not 
recognize -- they may inadvertently set or clear the bit.  If they 
delete the flag they will remove rights.  We need to add this text to 
security considerations of annotate.  This also needs to be added to 
ACL2.

Issue: Shared v private annotations.  We need text in draft of the 
meaning or private annotations; make it clear that this is per-user 
(not access restricted).  Cyrus suggests changing name from .prv to 
.user.  This issue is left to document editor.

Issue: Security considerations may be weak. Lisa asks for addiitional 
review of this section.

Issue: Can set \deleted flag with D right, can set it with annotations 
with different rights.  Put another way: What is "allowed to set 
annotation is on" but "allowed to set \deleted flag" is off?

Issue:  What happens if you set the shared and private versions of the 
annotation flags to different values?  Answer: This is 
server-dependent.  Then how does the client learn where
  to go to set them?

Proposal 1: Don't use the suffix on flags in annotate, at least for 
special-cases \seen and \deleted.  These two would not use suffix (or 
either suffix would be identical).  Focusing on \seen for the moment:  
for \seen, FETCH implicitly updates something (per-user or shared, 
depending on server)

Proposal 2: Don't map flags to annotate.   Problem with this is that 
old clients will use flags. new ones use annotations, don't interop...

Resolution: Need a history review of why the tie was done in the first 
place.) Punting to the list.

TOPIC: ACL2

This draft waits for LISTEXT - depends on LISTEXT syntax.

Proposal:  Publish separately an update to existing IMAP ACL doc, 
containing the complete list of rights linked to the appropriate 
operations.  This would also clarify when to return 
read-only/read-write.

Proposal (for update to existing ACL doc): RIGHTS=rightlist capability. 
  Some skepticism that "this will just be a little tweak to ACL" is what 
led to the present ACL2 delay.

TOPIC Charter bashing.

See revised charter (already posted).

Cc: Alexey Melnikov <[email-masked]>, [email-masked]
From: Lisa Dusseault <[email-masked]>
Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10)
Date: Wed, 1 Sep 2004 09:08:23 -0700
To: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

>
> There is also another issue that comes up. What happens if the 'm' 
> right is removed or all ACLs for a user are removed from a mailbox. Do 
> any private annotations for that user get deleted as well? Should 
> there be a way for the admin of a mailbox to delete all private 
> annotations of specific users? They would never have the ability to 
> actually read or change only delete outright.
>
>
I believe that would be implementation-specific, or up to the 
administrator, and should not be part of the standard.  This situation 
isn't unique to annotations.  Any time a storage system has permissions 
that can be changed, there's a chance the user could create data then 
have the permission to view that data removed later.

Lisa

Date: Wed, 01 Sep 2004 16:17:34 +0100
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: [email-masked]
Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10)
Sender: [email-masked]

Cyrus Daboo wrote:

> There is also another issue that comes up. What happens if the 'm' 
> right is removed or all ACLs for a user are removed from a mailbox. Do 
> any private annotations for that user get deleted as well?

I think this should be left up to implementations.

This is somewhat similar to deleting users (or domains, for servers that 
support multiple domains). MessagingDirect server never bothered 
deleting ACLs once a user/domain was deleted, because it is just to 
expensive to do.

Date: Wed, 01 Sep 2004 10:37:54 -0400
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: [email-masked]
Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10)
Sender: [email-masked]

Hi Alexey,

--On Wednesday, September 1, 2004 11:16 AM +0100 Alexey Melnikov 
<[email-masked]> wrote:

>>|               |               |                                   |
>>
> Do you actually mean that private annotations are not readable unless 'm'
> right is granted? Show me how this is useful (unless you meant 'r' here).

I see 'm' as meaning that private annotations are allowed - and that means 
being able to both read and write. With your suggestion having 'r' set and 
not 'm' is kind of useless because you can't create any private annotations 
to read. Is there ever going to be a case where you would allow a user to 
create/write a private annotation and then remove their right to change or 
delete it? 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.

There is also another issue that comes up. What happens if the 'm' right is 
removed or all ACLs for a user are removed from a mailbox. Do any private 
annotations for that user get deleted as well? Should there be a way for 
the admin of a mailbox to delete all private annotations of specific users? 
They would never have the ability to actually read or change only delete 
outright.

-- 
Cyrus Daboo

Date: Wed, 01 Sep 2004 11:39:37 +0100
From: Alexey Melnikov <[email-masked]>
To: IMAP Mailing List <[email-masked]>, IMAP Extensions WG <[email-masked]>, Lemonade WG <[email-masked]>
Subject: [Fwd: I-D ACTION:draft-melnikov-imap-disc-04.txt]
Sender: [email-masked]

I've just submitted a new revision of the "Synchronization operations 
for disconnected IMAP4 clients" document. I intend to publish the 
document soon, so I would like to solicit review of the document.

-------- Original Message --------
Subject: 	I-D ACTION:draft-melnikov-imap-disc-04.txt
Date: 	Tue, 31 Aug 2004 15:31:17 -0400
From: 	[email-masked]
Reply-To: 	[email-masked]
To: 	[email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Synchronization operations for disconnected IMAP4 clients
	Author(s)	: A. Melnikov
	Filename	: draft-melnikov-imap-disc-04.txt
	Pages		: 0
	Date		: 2004-8-31
	
This document attempts to address some of the issues involved in building a disconnected IMAP4 client.  In particular, it deals with the issues of what might be called the 'driver' portion of the synchronization tool: the portion of the code responsible for issuing the correct set of IMAP4 commands to synchronize the disconnected client in the way that is most likely to make the human who uses the disconnected client happy.
This note describes different strategies that can be used by disconnected clients as well as shows how to use IMAP protocol in order to minimize the time of synchronization process.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-melnikov-imap-disc-04.txt

Date: Wed, 01 Sep 2004 11:26:15 +0100
From: Alexey Melnikov <[email-masked]>
To: Dave Cridland <[email-masked]>
CC: Cyrus Daboo <[email-masked]>, [email-masked]
Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10)
Sender: [email-masked]

Dave Cridland wrote:

> Aside from this, adding rights does, of course, work. It seems to me 
> that in the absence of these extended rights, the client can assume 
> the same semantics as above, which are - I think - calculable from the 
> existing 2086 rights. (Not that it matters enormously.) 

READ-ONLY/READ-WRITE must be consistent with the ACL2 document. The 
client doesn't have to have two codepaths to check if a private/shared 
annotation is writeable.

> As long as the server implementors [of which I'm not one] think it's 
> fair to add in extra rights for this purpose, I'm perfectly happy with 
> it as a client implementor.

Add a new right is usually a single bit in a flag bitmask, and a lot of 
bugs in other places :-). But this is not a rocket science.

I am more concerned about the need to upgrade existing ACLs. It might be 
difficult to explain to inexperienced users that they have to change 
ACLs on their mailboxes, in order to allow there new annotate-aware 
client to write them.
Alternatively a server implementor may choose to automatically upgrade 
all ACLs, which might not be trivial.

Alexey

Date: Wed, 01 Sep 2004 11:16:41 +0100
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: [email-masked]
Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10)
Sender: [email-masked]

Cyrus Daboo wrote:

>+---------------+---------------+-----------------------------------+
>  
>
>|               |               |                                   |
>  
>
>|               | read private  | Any mailbox with the 'm' right.   |
>  
>
>|               |               |                                   |
>
Do you actually mean that private annotations are not readable unless 
'm' right is granted? Show me how this is useful (unless you meant 'r' 
here).

>  
>
>|               +---------------+-----------------------------------+
>  
>
>|               |               |                                   |
>  
>
>| Server        | write private | Any mailbox with the 'm' right.   |
>  
>
>| with          |               |                                   |
>  
>
>| ACL/RIGHTS    +---------------+-----------------------------------+
>  
>
>| Extensions    |               |                                   |
>  
>
>|               | read shared   | Any mailbox with the 'r' right.   |
>  
>
>|               |               |                                   |
>  
>
>|               +---------------+-----------------------------------+
>  
>
>|               |               |                                   |
>  
>
>|               | write shared  | Any mailbox with the 'n' right.   |
>  
>
>|               |               |                                   |
>  
>
>+---------------+---------------+-----------------------------------+
>  
>
And to be consistent with READ-ONLY/READ-WRITE response code, I will update ACL[2] to say that:
a). 'm' right doesn't affect READ-ONLY/READ-WRITE
b). the presence of the 'n' right causes the server to return READ-WRITE.

(And I am fine with the changes that you've made as the result of Dave's request).

Alexey

From: "Richard Bang" <[email-masked]>
To: <[email-masked]>
Subject: IMAP,ACL,NAMESPACE,Mozilla,Outlook.
Date: Thu, 30 Sep 2004 19:09:29 +0100
Sender: [email-masked]

Hi,

Could someone correct me if im wrong, but as I see things at the current
state of play it is not possible to implement a shared folder scheme that
will work will all IMAP clients (and allow some of them to configure the
sharing rights).

I have managed to get ACL and NAMESPACE to work with Mozilla, but this
forces me to use name spaces for shared items and this instantly breaks
Outlook (& Express).

While it is trivial to make it work with either, and if I had the ability to
know which flavour of client was running, I could make it work with both, it
does not seem that there is a selection of namespace/acl settings that allow
Mozilla to be happy AND Outlook to be happy.

If I am wrong them please could someone suggest a name space that will work
with both.

Please don't reply with "Don't support Outlook its terrible" because I
support what my customers want me to support not the other way round.

It is not my intention to flame or irritate, just to express frustration and
ask for help.

I have a personal folder structure where any folder may or may not be shared
with one or more other users. I do not see any way to show this in either
NAMESPACE or ACL. May I suggest that a future revision of ACL includes a
LIST tag that explicitly identifies a resource that could be shared and also
one that is currently shared. This would then prevent the requirement of
structuring the store to match the clients expectation.

If there is currently a way of doing this please let me know.

For now I will require all customers to use our resource management tool.

Regards

Richard.

To: Richard Bang <[email-masked]>
Cc: [email-masked]
From: Philip Guenther <[email-masked]>
Subject: Re: ACL question. 
Date: Thu, 30 Sep 2004 08:47:37 -0700
Sender: [email-masked]

Richard Bang <[email-masked]> writes:
>I now get:
>005 getacl "shared/lindsay/inbox"
>* ACL "shared/lindsay/inbox" lindsay plrswida richard plrsw
>005 OK getacl completed
>
>And
>
>008 listrights "shared/lindsay/inbox" "bob"
>* LISTRIGHTS "shared/lindsay/inbox" bob "" plr sw i d a
>008 OK listrights completed

Those look okay, though tieing 'p' to 'l' and 'r' instead of 'i' seems
kinda weird.  <shrug>  Whether the 'p' right has any effect is
implementation defined anyway.

>Given the above response is the following considered valid?
>
>007 setacl "shared/lindsay/inbox" "bob" r
>007 NO Access Denied

Sure, the client failed to include the rights tied to 'r', so the server
is supposed to reject the request.  To quote section 3 or RFC 2086:
   An implementation may tie rights together or may force rights to
   always or never be granted to particular identifiers.  <...>  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. <...>

Philip Guenther

From: "Richard Bang" <[email-masked]>
To: <[email-masked]>
Subject: RE: ACL question. 
Date: Thu, 30 Sep 2004 16:13:58 +0100
Sender: [email-masked]

Hi,

My reading of 4.4 was that "what rights may be granted" meant "what rights
were granted", silly me.

Thanks for clearing that up for me.

I now get:
005 getacl "shared/lindsay/inbox"
* ACL "shared/lindsay/inbox" lindsay plrswida richard plrsw
005 OK getacl completed

And

008 listrights "shared/lindsay/inbox" "bob"
* LISTRIGHTS "shared/lindsay/inbox" bob "" plr sw i d a
008 OK listrights completed

Given the above response is the following considered valid?

007 setacl "shared/lindsay/inbox" "bob" r
007 NO Access Denied

Thanks again for the help.

Richard.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Philip Guenther
> Sent: 30 September 2004 15:30
> To: Richard Bang
> Cc: [email-masked]
> Subject: Re: ACL question. 
> 
> 
> "Richard Bang" <[email-masked]> writes:
> >I've just implemented ACL into my server and I'm testing it 
> with the latest
> >Mozilla.
> ...
> >005 getacl "shared/[email-masked]/inbox"
> >* ACL "shared/lindsay/inbox" lindsay plrswida
> >* ACL "shared/lindsay/inbox" richard plr
> >005 OK getacl completed
> 
> You should be sending one ACL response for the mailbox that lists all
> the identifer+rights pairs, ala:
> 
> * ACL "shared/lindsay/inbox" lindsay plrswida richard plr
> 
> As is, it looks like the rights on the mailbox changed mid-command.
> 
> ...
> >008 listrights "shared/lindsay/inbox" "bob"
> >* LISTRIGHTS "shared/lindsay/inbox"
> >008 OK listrights completed
> 
> That response doesn't match the syntax.  Where's the identifier or
> required rights?  If there are any rights that can be given 
> to bob, then
> you better list them off, say:
> 
> * LISTRIGHTS "shared/lindsay/inbox" "bob" "" l r s p w i d a
> 
> ...assuming bob can be given those rights.  Read section 5.2 
> of RFC 2086
> closely.
> 
> 
> Philip Guenther
> 
> 

Date: Thu, 30 Sep 2004 15:48:09 +0100
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: Major changes in draft-ietf-imapext-list-extensions-09
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Alexey Melnikov writes:
>
>> Barry wanted to retrofit multimailbox search to use LISTEXT syntax, he
>> asked for multiple patterns.
>>
>> Just think of this as a more generic mailbox pattern (we don't want to
>> have regular expression here ;-)).
>
> Might want to add a note to section 3.1 then, saying explicitly that 
> if multiple  wildcards match a given mailbox, it is to be returned 
> only once. 

Will do, thanks.

> I'd love to see a realistic example justifying the patterns list, 
> though. If noone can come up with even one real and good example, then 
> IMO the list should go away again. 

How about <LIST "" ("INBOX" "Drafts" "Sent")>?

> Btw. 3.1 is headlined "principals". The correct spelling is principles.

Fixed.

> And since I'm being pedantic, please cut the BiCapitalization. Or if 
> it has to stay, at least be consistent. If \NonExistent has to stay, 
> \HasSubmailboxes should be either \HasSubMailboxes or \HasSubMailBoxes. 

Ok :-).

>> I think you are right. I will change this to BAD, so if you object -
>> speak up now.
>
> Oh, good. I missed that and already used Bad ;)

Date: Thu, 30 Sep 2004 15:38:58 +0100
From: Alexey Melnikov <[email-masked]>
To: Richard Bang <[email-masked]>
CC: [email-masked]
Subject: Re: ACL question.
Sender: [email-masked]

Richard Bang wrote:

>Hi,
>
>I've just implemented ACL into my server and I'm testing it with the latest
>Mozilla.
>
>While Mozilla correctly identifies the access rights available to all
>folders, it does NOT allow me to share anything, even if I have the "a"
>right.
>
I think you are looking for solution in a wrong place.
"a" means "administer". It doesn't control or tell whether a mailbox is 
shared or not.

My best guess about your problem is that your server doesn't support 
NAMESPACE, thus Mozilla treats all mailboxes as "private".
Note, that using ACL extension one might be able to share a private 
mailbox (if server implementation allows sharing), but there is 
currently no way to convey this in IMAP.

Alexey

To: "Richard Bang" <[email-masked]>
Cc: [email-masked]
From: Philip Guenther <[email-masked]>
Subject: Re: ACL question. 
Date: Thu, 30 Sep 2004 07:30:17 -0700
Sender: [email-masked]

"Richard Bang" <[email-masked]> writes:
>I've just implemented ACL into my server and I'm testing it with the latest
>Mozilla.
...
>005 getacl "shared/[email-masked]/inbox"
>* ACL "shared/lindsay/inbox" lindsay plrswida
>* ACL "shared/lindsay/inbox" richard plr
>005 OK getacl completed

You should be sending one ACL response for the mailbox that lists all
the identifer+rights pairs, ala:

* ACL "shared/lindsay/inbox" lindsay plrswida richard plr

As is, it looks like the rights on the mailbox changed mid-command.

...
>008 listrights "shared/lindsay/inbox" "bob"
>* LISTRIGHTS "shared/lindsay/inbox"
>008 OK listrights completed

That response doesn't match the syntax.  Where's the identifier or
required rights?  If there are any rights that can be given to bob, then
you better list them off, say:

* LISTRIGHTS "shared/lindsay/inbox" "bob" "" l r s p w i d a

...assuming bob can be given those rights.  Read section 5.2 of RFC 2086
closely.

Philip Guenther

Date: Thu, 30 Sep 2004 10:18:16 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Alexey Melnikov <[email-masked]>
CC: [email-masked]
Subject: Re: listext-09 comments
Sender: [email-masked]

Alexey Melnikov wrote:

> Ken Murchison wrote:
> 
>>>>> I implemented Barry's last LISTEXT draft in Cyrus well over a year 
>>>>> ago (possibly two), but haven't looked into updating to the latest 
>>>>> draft yet.
>>>>
>>>>
>>> What capability does that version advertise?
>>
>>
>> LISTEXT LIST-SUBSCRIBED
>>
>> If you're worried about wide deployment of something that isn't up do 
>> date with the latest spec, LISTEXT support in Cyrus is currently a 
>> compile-time option, so I doubt you'll see very many of them in the wild.
> 
> 
> I will change the capability name before publication. I am not telling 
> anyone what it would be ;-).

I don't feel that its necessary, but I'm not going to stop you.

-- 
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: Thu, 30 Sep 2004 15:13:21 +0100
From: Alexey Melnikov <[email-masked]>
To: Ken Murchison <[email-masked]>
CC: [email-masked]
Subject: Re: listext-09 comments
Sender: [email-masked]

Ken Murchison wrote:

>>>> I implemented Barry's last LISTEXT draft in Cyrus well over a year 
>>>> ago (possibly two), but haven't looked into updating to the latest 
>>>> draft yet.
>>>
>> What capability does that version advertise?
>
> LISTEXT LIST-SUBSCRIBED
>
> If you're worried about wide deployment of something that isn't up do 
> date with the latest spec, LISTEXT support in Cyrus is currently a 
> compile-time option, so I doubt you'll see very many of them in the wild.

I will change the capability name before publication. I am not telling 
anyone what it would be ;-).

Alexey

From: "Richard Bang" <[email-masked]>
To: <[email-masked]>
Subject: ACL question.
Date: Thu, 30 Sep 2004 15:03:34 +0100
Sender: [email-masked]

Hi,

I've just implemented ACL into my server and I'm testing it with the latest
Mozilla.

While Mozilla correctly identifies the access rights available to all
folders, it does NOT allow me to share anything, even if I have the "a"
right.

A test session looks like this

* OK IMAP4 IMAP4rev1 Server
001 CAPABILITY
* CAPABILITY IMAP4 IMAP4REV1 AUTH=CRAM-MD5 AUTH=LOGIN ACL IDLE XTRASH
001 OK CAPABILITY completed
002 LOGIN xxx yyy
002 OK LOGIN completed
003 lsub "" "*"
* LSUB () "/" "Inbox"
* LSUB () "/" "Sent Items"
* LSUB () "/" "Drafts"
* LSUB () "/" "temp"
* LSUB () "/" "test"
* LSUB () "/" "trash"
* LSUB () "/" "barsoum"
* LSUB (\NoSelect) "/" "Shared"
* LSUB (\NoSelect) "/" "Shared/lindsay"
* LSUB () "/" "Shared/lindsay/inbox"
003 OK LSUB completed
004 getacl "INBOX"
004 OK getacl completed
005 getacl "shared/[email-masked]/inbox"
* ACL "shared/lindsay/inbox" lindsay plrswida
* ACL "shared/lindsay/inbox" richard plr
005 OK getacl completed
006 myrights "shared/lindsay/inbox"
* MYRIGHTS "shared/lindsay/inbox" plr
006 OK myrights completed
007 setacl "shared/lindsay/inbox" "bob" r
007 NO Access Denied
008 listrights "shared/lindsay/inbox" "bob"
* LISTRIGHTS "shared/lindsay/inbox"
008 OK listrights completed
009 deleteacl "shared/lindsay" "lindsay"
009 NO Access Denied
010 setacl "barsoum" "bob" r
010 OK setacl completed

Mozilla does this:

.....
26 getacl "barsoum"
* ACL "barsoum" [email-masked] plrswida
* ACL "barsoum" [email-masked] plrswi
* ACL "barsoum" [email-masked] plr
26 OK getacl completed
27 myrights "barsoum"
* MYRIGHTS "barsoum" plrswida
27 OK myrights completed

Is anyone able to tell me what I'm doing wrong that is stopping Mozilla
recognising folders are shared, it lists them all as personal folders and
not shared, when clearly its not the case.

Any help would be greatly appreciated.

Regards

Richard Bang

Floosietek Ltd
[email-masked]
http://www.floosietek.com

Date: Thu, 30 Sep 2004 16:02:56 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Major changes in draft-ietf-imapext-list-extensions-09
Cc: Alexey Melnikov <[email-masked]>, Philip Guenther <[email-masked]>
Sender: [email-masked]

Alexey Melnikov writes:
> Barry wanted to retrofit multimailbox search to use LISTEXT syntax, he
> asked for multiple patterns.
>
> Just think of this as a more generic mailbox pattern (we don't want to
> have regular expression here ;-)).

Might want to add a note to section 3.1 then, saying explicitly that if 
multiple  wildcards match a given mailbox, it is to be returned only 
once.

I'd love to see a realistic example justifying the patterns list, 
though. If noone can come up with even one real and good example, then 
IMO the list should go away again.

Btw. 3.1 is headlined "principals". The correct spelling is principles. 
And since I'm being pedantic, please cut the BiCapitalization. Or if it 
has to stay, at least be consistent. If \NonExistent has to stay, 
\HasSubmailboxes should be either \HasSubMailboxes or \HasSubMailBoxes.

> I think you are right. I will change this to BAD, so if you object -
> speak up now.

Oh, good. I missed that and already used Bad ;)

Arnt

Date: Thu, 30 Sep 2004 09:51:43 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Philip Guenther <[email-masked]>
CC: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: listext-09 comments
Sender: [email-masked]

Philip Guenther wrote:

> Arnt Gulbrandsen <[email-masked]> writes:
> 
>>Ken Murchison writes:
> 
> ...
> 
>>>I implemented Barry's last LISTEXT draft in Cyrus well over a year ago 
>>>(possibly two), but haven't looked into updating to the latest draft 
>>>yet.
> 
> 
> What capability does that version advertise?

LISTEXT LIST-SUBSCRIBED

If you're worried about wide deployment of something that isn't up do 
date with the latest spec, LISTEXT support in Cyrus is currently a 
compile-time option, so I doubt you'll see very many of them in the wild.

-- 
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: Wed, 29 Sep 2004 20:33:12 +0100
From: Alexey Melnikov <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Major changes in draft-ietf-imapext-list-extensions-09
Sender: [email-masked]

>>>- The multiple pattern part of the extension hasn't gotten much
>>> discussion.  Indeed, I had completely overlooked it until I made a
>>> close read of the grammar while whipping up a test implementation.
>>>
>>That is because it was added in the last revision ;-).
>>    
>Well, that explains the silence.  I have no particularly opinion on it
>other than a desire to not let it complicate things more than they are.
>Is this something that clients actually do, doing multiple listings with
>different patterns?  Is this useful complexity?
>
>>> (I presume
>>> this was added as a performance enhancement for _servers_, as it
>>> should have no real effect on _protocol_ performance compared to
>>> simply pipelining the requests.)
>>>
>>The client can save few bytes ;-).
>>    
>Seriously, that's never been a primary concern for IMAP; saving RTTs is.
>If byte count was a worry then there would be push-back on the length of
>the names of the LISTEXT options.

Barry wanted to retrofit multimailbox search to use LISTEXT syntax, he
asked for multiple patterns.

Just think of this as a more generic mailbox pattern (we don't want to
have regular expression here ;-)).

>In section 3:
>        A server MUST respond to options it does not recognize with
>        a NO response.
>Shouldn't that be a BAD response?

I think you are right. I will change this to BAD, so if you object -
speak up now.

>In section 5 (Examples), I find the layout a bit difficult to keep
>straight: the text describing, for example, example 3, comes _before_
>the line "Example 3:", so that my first inclination is to read it as an
>explanation of the previous protocol exchange instead of as a lead-in to
>the next exchange.  Perhaps the "Example #:" lines should be moved up
>before the paragraph and de-indented one level?  Or maybe the text
>should be moved to after the protocol exchange and recast as an
>explanation instead of an introduction?

Good point, I've done the latter.

>Some of the responses in the examples are, if I understand correctly,
>permitted but not required.  Since a server implementation can always
>send additional unrelated responses, there's no real 'maximal' set of
>permitted responses, so I think the examples should document the minimum
>required set of responses.  For example, I don't think the second LIST
>response in example 2 ("Fruit" as a \PlaceHolder) is actually required:
>all of the submailboxes of "Fruit" that are selected are also matched.
>
>Indeed, when the pattern is "*", the server should never need to send a
>\PlaceHolder response and should be able to omit the \HasSubmailboxes
>flag from the responses it does send, no?

I would like to allow for simple minded implementations that generate
\PlaceHolder/\HasSubmailboxes without checking what kind of pattern is
used. However I don't want to prevent smart implementations, that don't
send them for "*".

>  I believe this is supported
>by the current wording, though perhaps it should be stated that a server
>is only _required_ to send a \Placeholder or \HasSubmailboxes response
>if the matched mailbox has at least one selected but unmatched
>submailbox, but is _permitted_ to send one of those if the matched
>mailbox has any selected submailboxes at all.  If people agree with
>that and feel it to be a clearer expression of the intent of
>\Placeholder and \HasSubmailboxes, then I'll propose specific wording
>changes, probably replacing some of the current description.

Yes, I think that was the intent. In fact the draft says:

    The MATCHPARENT selection option described below REQUIRES that the
    "\Placeholder" and the "\HasSubmailboxes" attributes be accurately
    computed.

Any clarifications would be welcomed.

Alexey

Date: Thu, 30 Sep 2004 12:33:40 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: listext-09 comments
Cc: Ken Murchison <[email-masked]>, Philip Guenther <[email-masked]>
Sender: [email-masked]

Philip Guenther writes:
> Passing of multiple patterns was added in rev -09, so his parser 
> doesn't support that at all. I missed the error when implementing 
> because I 'knew' what those productions were supposed to do and 
> simply used the "parse a list of astring" call in my code.

Thanks. I guess the sky isn't falling this week either ;)

Arnt

To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked], Ken Murchison <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: listext-09 comments 
Date: Thu, 30 Sep 2004 03:28:47 -0700
Sender: [email-masked]

Arnt Gulbrandsen <[email-masked]> writes:
>Ken Murchison writes:
...
>> I implemented Barry's last LISTEXT draft in Cyrus well over a year ago 
>> (possibly two), but haven't looked into updating to the latest draft 
>> yet.

What capability does that version advertise?

>And you didn't note the missing SP? Or does your parser work without the SP?

Passing of multiple patterns was added in rev -09, so his parser
doesn't support that at all.  I missed the error when implementing
because I 'knew' what those productions were supposed to do and
simply used the "parse a list of astring" call in my code.

Philip Guenther

Date: Thu, 30 Sep 2004 12:07:15 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: listext-09 comments
Cc: Ken Murchison <[email-masked]>
Sender: [email-masked]

Ken Murchison writes:
> Arnt Gulbrandsen wrote:
>> 3. The patterns production could be changed to (spot the new SP):
>>
>>      patterns = "(" list-mailbox *(SP list-mailbox) ")"
>>
>> (Am I the first to implement? Surely not!)
>
> I implemented Barry's last LISTEXT draft in Cyrus well over a year ago 
> (possibly two), but haven't looked into updating to the latest draft 
> yet.

And you didn't note the missing SP? Or does your parser work without the SP?

Arnt

Date: Wed, 29 Sep 2004 23:24:51 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: listext-09 comments
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> 
> Comments.
> 
> 1. Shortening the lines a little would be good. Some of them are as much 
> as 84 characters, RFCs generally are no more than 75 or so. (A printout 
> looked very bad.)
> 
> 2. The mbox_or_pat production could be named mbox-or-pat. Would fit the 
> naming convention.
> 
> 3. The patterns production could be changed to (spot the new SP):
> 
>      patterns = "(" list-mailbox *(SP list-mailbox) ")"
> 
> (Am I the first to implement? Surely not!)

I implemented Barry's last LISTEXT draft in Cyrus well over a year ago 
(possibly two), but haven't looked into updating to the latest draft yet.

-- 
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: Wed, 29 Sep 2004 18:30:16 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: listext-09 comments
Sender: [email-masked]

Comments.

1. Shortening the lines a little would be good. Some of them are as much 
as 84 characters, RFCs generally are no more than 75 or so. (A printout 
looked very bad.)

2. The mbox_or_pat production could be named mbox-or-pat. Would fit the 
naming convention.

3. The patterns production could be changed to (spot the new SP):

      patterns = "(" list-mailbox *(SP list-mailbox) ")"

(Am I the first to implement? Surely not!)

More sure to come, but I have to run off buy groceries now ;)

Arnt

From: Dave Cridland <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Major changes in draft-ietf-imapext-list-extensions-09
Date: Thu, 23 Sep 2004 09:40:00 +0100
Sender: [email-masked]

On Thu Sep 23 08:37:10 2004, Arnt Gulbrandsen wrote:
> 
> Alexey Melnikov writes:
>> On a related note, has anybody seen an IMAP client that uses 
>> pipelining?
> 
> I know of three, actually. One released, one maybe, one not.

You can add another one to the "maybe" column, too - my little client 
does pipeline for one or two things, but not LIST as yet. Nothing 
prevents this, it simply happens not to. (FWIW, it'll handle the case 
of the server responding to commands out of order, as well, because 
it's the same code as for ACAP, and the ACAP server does.)

On top of that, SquirrelMail, the PHP-based webmail client, does 
pipelining last I looked, specifically pipelining LIST as it receives 
responses from LSUB. (I don't know if this one was the "released" one 
Arnt mentioned.)

I've always thought of pipelining as quite common, actually, but 
generally used in special cases rather than as the norm.

Dave.

Date: Thu, 23 Sep 2004 09:37:10 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Major changes in draft-ietf-imapext-list-extensions-09
Sender: [email-masked]

Alexey Melnikov writes:
> On a related note, has anybody seen an IMAP client that uses pipelining?

I know of three, actually. One released, one maybe, one not.

I'll not name names, since one of them is an unreleased commercial 
product. (I've no connection to the vendor, except that someone working 
there once listened to some advice of mine.)

Arnt

To: Alexey Melnikov <[email-masked]>
From: Philip Guenther <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Major changes in draft-ietf-imapext-list-extensions-09 
Date: Wed, 22 Sep 2004 20:41:08 -0700
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:
...
>>- The multiple pattern part of the extension hasn't gotten much
>>  discussion.  Indeed, I had completely overlooked it until I made a
>>  close read of the grammar while whipping up a test implementation.
>>
>That is because it was added in the last revision ;-).

Well, that explains the silence.  I have no particularly opinion on it
other than a desire to not let it complicate things more than they are.
Is this something that clients actually do, doing multiple listings with
different patterns?  Is this useful complexity?

>>  (I presume
>>  this was added as a performance enhancement for _servers_, as it
>>  should have no real effect on _protocol_ performance compared to
>>  simply pipelining the requests.)
>>
>The client can save few bytes ;-).

Seriously, that's never been a primary concern for IMAP; saving RTTs is.
If byte count was a worry then there would be push-back on the length of
the names of the LISTEXT options.

In section 3:
        A server MUST respond to options it does not recognize with
        a NO response.
Shouldn't that be a BAD response?

In section 5 (Examples), I find the layout a bit difficult to keep
straight: the text describing, for example, example 3, comes _before_
the line "Example 3:", so that my first inclination is to read it as an
explanation of the previous protocol exchange instead of as a lead-in to
the next exchange.  Perhaps the "Example #:" lines should be moved up
before the paragraph and de-indented one level?  Or maybe the text
should be moved to after the protocol exchange and recast as an
explanation instead of an introduction?

Some of the responses in the examples are, if I understand correctly,
permitted but not required.  Since a server implementation can always
send additional unrelated responses, there's no real 'maximal' set of
permitted responses, so I think the examples should document the minimum
required set of responses.  For example, I don't think the second LIST
response in example 2 ("Fruit" as a \PlaceHolder) is actually required:
all of the submailboxes of "Fruit" that are selected are also matched.

Indeed, when the pattern is "*", the server should never need to send a
\PlaceHolder response and should be able to omit the \HasSubmailboxes
flag from the responses it does send, no?  I believe this is supported
by the current wording, though perhaps it should be stated that a server
is only _required_ to send a \Placeholder or \HasSubmailboxes response
if the matched mailbox has at least one selected but unmatched
submailbox, but is _permitted_ to send one of those if the matched
mailbox has any selected submailboxes at all.  If people agree with
that and feel it to be a clearer expression of the intent of
\Placeholder and \HasSubmailboxes, then I'll propose specific wording
changes, probably replacing some of the current description.

What does a response with \Placeholder or \HasSubmailboxes mean when
MATCHPARENT is used with REMOTE but without SUBSCRIBED?  I see three
possible answers:
a) it means the mailbox has at least one submailbox that is remote
b) is means the mailbox has at least one submailbox, local or remote
c) (b), but that's the same as \HasChildren, so MATCHPARENT shouldn't be
   allowed with just REMOTE: it should require SUBSCRIBED or some other
   option that affects the selection criteria.

IMO, the current text says (b).  Switching it to (a) would require a
major rethink of the concept of "selected", or would effectively declare
MATCHPARENT as having ad hoc interaction with each selection option.  I
would just as soon go with (c) and can help with text to that effect.

Depending on how that question is settled, I may have an argument that
in response to <LIST (SUBSCRIBED MATCHPARENT) "" "%">, responses with
the \Placeholder flag also need the \Subscribed flag to avoid
ambiguity.

To make this all concrete, I've implemented my understanding of the
X-DRAFT-W09-LISTEXT extension and should soon be able to point people at
a server running it so they can compare their expectation to it,
probably via an anonymous account that can list a hierarchy with a good
mix of mailboxes, both subscribed and not, including trees that match
some of the examples.  The server doesn't support remote mailboxes, so
those examples won't reproduce exactly.  If you're interested, fire me a
note and I'll give you the info on how to connect.

Philip Guenther

Date: Wed, 22 Sep 2004 18:17:40 +0100
From: Alexey Melnikov <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Major changes in draft-ietf-imapext-list-extensions-09
Sender: [email-masked]

Philip Guenther wrote:

>Other thoughts/comments:
>
>- if an option is repeated in an option list, is the server required to,
>  permitted to, or forbidden from rejecting the command with a BAD
>  response?
>
IMHO, I think the server should allow this, but the client SHOULD NOT do 
this.
But I am fine with prohibiting this as well.
And I agree that this has to be clarified.

>- The multiple pattern part of the extension hasn't gotten much
>  discussion.  Indeed, I had completely overlooked it until I made a
>  close read of the grammar while whipping up a test implementation.
>
That is because it was added in the last revision ;-).

>  Perhaps this change should be mentioned in the abstract?
>
Ok. Can you propose any text?

>  (I presume
>  this was added as a performance enhancement for _servers_, as it
>  should have no real effect on _protocol_ performance compared to
>  simply pipelining the requests.)
>
The client can save few bytes ;-).

On a related note, has anybody seen an IMAP client that uses pipelining?

>- The LIST command requires special processing when the pattern argument
>  is the empty string.  How does LISTEXT interact with that?  Is the
>  special processing skipped when SUBSCRIBED is used?  Should the server
>  be permitted to ignore the MATCHPARENT and/or CHILDREN options for the
>  response generated by the empty pattern?  Is there any special result
>  or change if the empty pattern is one of multiple patterns in a LIST
>  command?
>
These are all good questions. I think that for simplicity when there are 
multiple patterns, the empty string should not have a special meaning 
and should be ignored.

>- Is a folder that doesn't exist but that meets the selection criteria
>  sufficient to trigger a \HasSubmailboxes or \Placeholder responses?
>  If so, then \HasSubmailboxes and \Placeholder do _not_ imply
>  \HasChildren.  E.g., consider the following:
>	a1 LIST "" ("foo" "foo/*")
>	* LIST () "/" foo
>	a1 OK done
>	a2 LIST (SUBSCRIBED) "" "foo/*"
>	* LIST (\Subscribed \NonExistent) "/" foo/bar
>	a2 OK done
>	a3 LIST (SUBSCRIBED MATCHPARENT) "" foo RETURN (CHILDREN)
>	* LIST (\Subscribed \Placeholder \HasNoChildren) "/" foo
>	a3 OK done
>  
>
Hmm, this is an interesting edge case. I think you are right, I should 
remove any mentioning of \HasSubmailboxes/\PlaceHolder implying 
\HasChildren.
I should also add your example to the document.

Alexey

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-2086upd-00.txt
Date: Mon, 13 Sep 2004 16:05:35 -0400
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-00.txt
	Pages		: 0
	Date		: 2004-9-13
	
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-00.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-00.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-00.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-00.txt

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

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

--OtherAccess--

--NextPart--

To: Mark Crispin <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: Major changes in draft-ietf-imapext-list-extensions-09 
Date: Sun, 12 Sep 2004 23:33:22 -0700
Sender: [email-masked]

Mark Crispin <[email-masked]> writes:
...
>You need to fix the list-select-option and/or list-select/opts rule in the 
>formal syntax so as to enforce this ban.
>
>Suggest:
>    list-select-opts   = "(" [list-select-option *(SP list-select-option)]
>                         [SP "MATCHPARENT"] ")"
>                         ; list selection options, e.g. REMOTE
>
>and then remove MATCHPARENT from list-select-option.

I think you meant to move a close-bracket in that, to instead get:
     list-select-opts   = "(" [list-select-option *(SP list-select-option)
                          [SP "MATCHPARENT"]] ")"

but that requires that MATCHPARENT be last in the match option list.  If
you want the grammar to forbid MATCHPARENT without another match option,
I would suggest:

list-select-opts = "(" [*(list-select-mod-opt SP) list-select-base-opt
			*(SP list-select-opt)] ")"

list-select-opt = list-select-mod-opt / list-select-base-opt

list-select-base-opt = "SUBSCRIBED" / "REMOTE" / option-extension
			; options that can be used by themselves

list-select-mod-opt = "MATCHPARENT" / option-extension
			; options that require a list-select-base-opt
			; to also be present

Other thoughts/comments:

- if an option is repeated in an option list, is the server required to,
  permitted to, or forbidden from rejecting the command with a BAD
  response?

- The multiple pattern part of the extension hasn't gotten much
  discussion.  Indeed, I had completely overlooked it until I made a
  close read of the grammar while whipping up a test implementation.
  Perhaps this change should be mentioned in the abstract?  (I presume
  this was added as a performance enhancement for _servers_, as it
  should have no real effect on _protocol_ performance compared to
  simply pipelining the requests.)

- The LIST command requires special processing when the pattern argument
  is the empty string.  How does LISTEXT interact with that?  Is the
  special processing skipped when SUBSCRIBED is used?  Should the server
  be permitted to ignore the MATCHPARENT and/or CHILDREN options for the
  response generated by the empty pattern?  Is there any special result
  or change if the empty pattern is one of multiple patterns in a LIST
  command?

- Is a folder that doesn't exist but that meets the selection criteria
  sufficient to trigger a \HasSubmailboxes or \Placeholder responses?
  If so, then \HasSubmailboxes and \Placeholder do _not_ imply
  \HasChildren.  E.g., consider the following:
	a1 LIST "" ("foo" "foo/*")
	* LIST () "/" foo
	a1 OK done
	a2 LIST (SUBSCRIBED) "" "foo/*"
	* LIST (\Subscribed \NonExistent) "/" foo/bar
	a2 OK done
	a3 LIST (SUBSCRIBED MATCHPARENT) "" foo RETURN (CHILDREN)
	* LIST (\Subscribed \Placeholder \HasNoChildren) "/" foo
	a3 OK done

Philip Guenther

Date: Fri, 10 Sep 2004 13:28:56 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Major changes in draft-ietf-imapext-list-extensions-09
Sender: [email-masked]

On Thu, 9 Sep 2004, Alexey Melnikov wrote:
> 1). Add a requirement that the MATCHPARENT selection option can't be used as 
> the only selection option

You need to fix the list-select-option and/or list-select/opts rule in the 
formal syntax so as to enforce this ban.

Suggest:

    list-select-opts   = "(" [list-select-option *(SP list-select-option)]
                         [SP "MATCHPARENT"] ")"
                         ; list selection options, e.g. REMOTE

and then remove MATCHPARENT from list-select-option.

Nit:

The document has many over-long lines.  This will need to be fixed before 
it goes to RFC anyway, so you might as well fix it now.

-- 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-list-extensions-09.txt
Date: Fri, 10 Sep 2004 15:55:55 -0400
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 LIST Command Extensions
	Author(s)	: B. Leiba, A. Melnikov
	Filename	: draft-ietf-imapext-list-extensions-09.txt
	Pages		: 0
	Date		: 2004-9-10
	
IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we
have added extensions that have required specialized lists (see
[MboxRefer] for an example) we have had to expand the number of list
commands, since each extension must add its function to both LIST and
LSUB, and these commands are not, as they are defined, extensible.
If we've needed the extensions to work together, we've had to add a
set of commands to mix the different options, the set increasing in
size with each new extension.  This document describes an extension
to the base LIST command that will allow these additions to be done
with mutually compatible options to the LIST command, avoiding the
exponential increase in specialized list commands.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-list-extensions-09.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-list-extensions-09.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-list-extensions-09.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-list-extensions-09.txt

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

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

--OtherAccess--

--NextPart--

Date: Thu, 09 Sep 2004 20:48:14 +0100
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Major changes in draft-ietf-imapext-list-extensions-09
Sender: [email-masked]

I've just submitted LISTEXT-09, that should be announced soon.
Below is the list of changes:

1). Add a requirement that the MATCHPARENT selection option can't be 
used as the only selection option (as per Cyrus Daboo suggestion):

          The MATCHPARENT option MUST NOT occur as the only selection 
option,
          as it only makes sense when other selection options are also used.
          The server MUST return BAD tagged response in such case.

2). Removed the REMOTE return option as it is redundant (as per recent 
post by Dave Cridland)

3). Clarified the purpose of selection options and return options. 
Clarified how multiple selection options can interact.

4). Clarified when a server implementing another extension that depends 
on LISTEXT has to return the LISTEXT capability in a CAPABILITY response.

5). Clarified the purpose of \Placeholder and \HasSubmailboxes flags.

6). I've changed all occurrences of "flag" to "attribute", to be more 
consistent. I've noticed that the RFC 3501 mostly uses the term 
"attribute", but sometimes (especially in ABNF comments) it uses the 
term "flag".

7). Added a new section with additional requirements on clients:

   All clients that support this extension MUST treat an attribute with
   a stronger meaning, as implying any attribute that can be inferred 
from it.
   For example, the client must treat presense of the \NoInferiors attribute
   as if the \HasNoChildren attribute was also sent by the server.

And added a table at the end that summarizes all described "inference" 
rules.

8). Various other editorial changes and clarifications (in particular 
"s/match option/selection option" and updated the text to use "mailbox 
name" instead of "mailbox" where appropriate). I've also added more 
examples. Can somebody check the example #8 and #9 in the new draft? Is 
the example #9 useful?
========
I have two new minor issues to discuss (actually, we kind of discussed 
one of them a bit):

1). Do we need to add a special section for unsolicited responses?
Do we want to require properly computed \Remote and \Subscribed
attributes in all unsolicited LIST responses?

(I tend to answer "yes". This should even work with unextended LIST, as
all clients should ignore unrecognized mailbox attributes.)

2). There is the following text in the current LISTEXT draft:
 >   In some instances a server that supports the Child Mailbox Extension
 >   might not be able to determine whether a mailbox has children.  For
 >   example it may have difficulty determining whether there are child
 >   mailboxes when LISTing mailboxes while operating in a particular
 >   namespace.

Should the same be done for \HasSubmailboxes/\PlaceHolder?
(I tend to say "no", but some people might argue that this is additional
burden for server implementations).

Alexey

Date: Fri, 3 Sep 2004 20:24:59 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Dave Cridland <[email-masked]>, [email-masked]
Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10)
Sender: [email-masked]

On Tue, 24 Aug 2004, Alexey Melnikov wrote:

>> 's' is used for the per-user \SEEN flag in ACL[2]. \SEEN is the only 
>> per-user data I'm aware of in an IMAP4 shared mailbox. 
>
> I don't think ACL2 says that 's' only controls private (per-user) \Seen even 
> though Cyrus Imap implements the \Seen flag as private.

This is true, as I understand it, it only controls \Seen.

> I've implemented 
> \Seen as a shared flag once. Having said that, I don't like overloading the 
> meaning of different ACL rights.

Indeed, this will get us right back where we are now with ACL, where the 
delete right is inconveinently overloaded.

-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-----

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Meeting notes
Date: Wed, 1 Sep 2004 10:50:14 -0700
Sender: [email-masked]

Here are the notes from the IMAPEXT WG meeting, which I adapted from 
the Jabber logs (thanks note-takers Ned and others)

---

TOPIC: Status of i18n and sort drafts

Summary: These are blocked on the comparator draft, which needs IANA 
review and buyin.  Chris Newman reports that he has had a meeting with 
Michelle Cotton (IANA) and progress was made

TOPIC: List extensions

Issue: What to do about \Placeholder (Mark Crispin has asked if we can 
get rid of it).  We need comments from mail client writers on how 
useful different flags and options are - Mark thinks it is 
overengineered.  After discussion, we asked client people to post to 
the list asking if they would use \Placeholder.  Alexey Melnikov will 
formulate the question and post it to the list and Cyrus Daboo to try 
to answer.

Issue: Currently filter/select concepts are combined.  Propose: Two 
parts, one to match mailboxes, other to control info returned.
   e.g. LIST <match-options> mailbox-spec RETURN <return-options>
Some argument that all options need to be returned.  Cyrus argues that 
this is good for use with ANNOTATEMORE.  Lisa proposed that we could 
change only the name to be clearer, e.g.  changing <return-options> to 
<also-return>.  In this proposal, any responses that are implied by 
what you're asking for will be provided automatically.  E.g. if you say 
"no standard flags" you'll still get subscribed if you're querying on 
that.  A Proposal will be sent to the list.

TOPIC: Annotate draft

ACL issues: Cyrus says he tried to keep ACL as informative.  Noted that 
ACL can be referenced because it is already an RFC; ACL2 is not done 
yet. All the bits needed are in ACL but some of the explanation of what 
the bits mean appears to be missing, specifically what the old 
[READ-ONLY] and [READ-WRITE] mean and whether ACL should imply one or 
the other.  Pete Resnick is concerned about how mailbox access rights 
tie into annotations.  ACL2 apparently resolves this but is not ready 
to reference.   Shared annotations only interact with 
read-only/read-write -- private annotations are where the problem is.   
Pete argues for clearly separating these things.   One option is to 
base it on ACL2 and add another bit controlling the ability to write 
private annotations.

Proposal for ACL issue: could solve this with a new bit added to _old_ 
ACL.   Chris Newman, channeling Mark Crispin, says adding stuff to ACL 
is bad because there are implementation that do not/cannot support old 
ACL.

Need to warn that clients should not copy ACL bits they do not 
recognize -- they may inadvertently set or clear the bit.  If they 
delete the flag they will remove rights.  We need to add this text to 
security considerations of annotate.  This also needs to be added to 
ACL2.

Issue: Shared v private annotations.  We need text in draft of the 
meaning or private annotations; make it clear that this is per-user 
(not access restricted).  Cyrus suggests changing name from .prv to 
.user.  This issue is left to document editor.

Issue: Security considerations may be weak. Lisa asks for addiitional 
review of this section.

Issue: Can set \deleted flag with D right, can set it with annotations 
with different rights.  Put another way: What is "allowed to set 
annotation is on" but "allowed to set \deleted flag" is off?

Issue:  What happens if you set the shared and private versions of the 
annotation flags to different values?  Answer: This is 
server-dependent.  Then how does the client learn where
  to go to set them?

Proposal 1: Don't use the suffix on flags in annotate, at least for 
special-cases \seen and \deleted.  These two would not use suffix (or 
either suffix would be identical).  Focusing on \seen for the moment:  
for \seen, FETCH implicitly updates something (per-user or shared, 
depending on server)

Proposal 2: Don't map flags to annotate.   Problem with this is that 
old clients will use flags. new ones use annotations, don't interop...

Resolution: Need a history review of why the tie was done in the first 
place.) Punting to the list.

TOPIC: ACL2

This draft waits for LISTEXT - depends on LISTEXT syntax.

Proposal:  Publish separately an update to existing IMAP ACL doc, 
containing the complete list of rights linked to the appropriate 
operations.  This would also clarify when to return 
read-only/read-write.

Proposal (for update to existing ACL doc): RIGHTS=rightlist capability. 
  Some skepticism that "this will just be a little tweak to ACL" is what 
led to the present ACL2 delay.

TOPIC Charter bashing.

See revised charter (already posted).

Cc: Alexey Melnikov <[email-masked]>, [email-masked]
From: Lisa Dusseault <[email-masked]>
Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10)
Date: Wed, 1 Sep 2004 09:08:23 -0700
To: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

>
> There is also another issue that comes up. What happens if the 'm' 
> right is removed or all ACLs for a user are removed from a mailbox. Do 
> any private annotations for that user get deleted as well? Should 
> there be a way for the admin of a mailbox to delete all private 
> annotations of specific users? They would never have the ability to 
> actually read or change only delete outright.
>
>
I believe that would be implementation-specific, or up to the 
administrator, and should not be part of the standard.  This situation 
isn't unique to annotations.  Any time a storage system has permissions 
that can be changed, there's a chance the user could create data then 
have the permission to view that data removed later.

Lisa

Date: Wed, 01 Sep 2004 16:17:34 +0100
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: [email-masked]
Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10)
Sender: [email-masked]

Cyrus Daboo wrote:

> There is also another issue that comes up. What happens if the 'm' 
> right is removed or all ACLs for a user are removed from a mailbox. Do 
> any private annotations for that user get deleted as well?

I think this should be left up to implementations.

This is somewhat similar to deleting users (or domains, for servers that 
support multiple domains). MessagingDirect server never bothered 
deleting ACLs once a user/domain was deleted, because it is just to 
expensive to do.

Date: Wed, 01 Sep 2004 10:37:54 -0400
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: [email-masked]
Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10)
Sender: [email-masked]

Hi Alexey,

--On Wednesday, September 1, 2004 11:16 AM +0100 Alexey Melnikov 
<[email-masked]> wrote:

>>|               |               |                                   |
>>
> Do you actually mean that private annotations are not readable unless 'm'
> right is granted? Show me how this is useful (unless you meant 'r' here).

I see 'm' as meaning that private annotations are allowed - and that means 
being able to both read and write. With your suggestion having 'r' set and 
not 'm' is kind of useless because you can't create any private annotations 
to read. Is there ever going to be a case where you would allow a user to 
create/write a private annotation and then remove their right to change or 
delete it? 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.

There is also another issue that comes up. What happens if the 'm' right is 
removed or all ACLs for a user are removed from a mailbox. Do any private 
annotations for that user get deleted as well? Should there be a way for 
the admin of a mailbox to delete all private annotations of specific users? 
They would never have the ability to actually read or change only delete 
outright.

-- 
Cyrus Daboo

Date: Wed, 01 Sep 2004 11:39:37 +0100
From: Alexey Melnikov <[email-masked]>
To: IMAP Mailing List <[email-masked]>, IMAP Extensions WG <[email-masked]>, Lemonade WG <[email-masked]>
Subject: [Fwd: I-D ACTION:draft-melnikov-imap-disc-04.txt]
Sender: [email-masked]

I've just submitted a new revision of the "Synchronization operations 
for disconnected IMAP4 clients" document. I intend to publish the 
document soon, so I would like to solicit review of the document.

-------- Original Message --------
Subject: 	I-D ACTION:draft-melnikov-imap-disc-04.txt
Date: 	Tue, 31 Aug 2004 15:31:17 -0400
From: 	[email-masked]
Reply-To: 	[email-masked]
To: 	[email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Synchronization operations for disconnected IMAP4 clients
	Author(s)	: A. Melnikov
	Filename	: draft-melnikov-imap-disc-04.txt
	Pages		: 0
	Date		: 2004-8-31
	
This document attempts to address some of the issues involved in building a disconnected IMAP4 client.  In particular, it deals with the issues of what might be called the 'driver' portion of the synchronization tool: the portion of the code responsible for issuing the correct set of IMAP4 commands to synchronize the disconnected client in the way that is most likely to make the human who uses the disconnected client happy.
This note describes different strategies that can be used by disconnected clients as well as shows how to use IMAP protocol in order to minimize the time of synchronization process.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-melnikov-imap-disc-04.txt

Date: Wed, 01 Sep 2004 11:26:15 +0100
From: Alexey Melnikov <[email-masked]>
To: Dave Cridland <[email-masked]>
CC: Cyrus Daboo <[email-masked]>, [email-masked]
Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10)
Sender: [email-masked]

Dave Cridland wrote:

> Aside from this, adding rights does, of course, work. It seems to me 
> that in the absence of these extended rights, the client can assume 
> the same semantics as above, which are - I think - calculable from the 
> existing 2086 rights. (Not that it matters enormously.) 

READ-ONLY/READ-WRITE must be consistent with the ACL2 document. The 
client doesn't have to have two codepaths to check if a private/shared 
annotation is writeable.

> As long as the server implementors [of which I'm not one] think it's 
> fair to add in extra rights for this purpose, I'm perfectly happy with 
> it as a client implementor.

Add a new right is usually a single bit in a flag bitmask, and a lot of 
bugs in other places :-). But this is not a rocket science.

I am more concerned about the need to upgrade existing ACLs. It might be 
difficult to explain to inexperienced users that they have to change 
ACLs on their mailboxes, in order to allow there new annotate-aware 
client to write them.
Alternatively a server implementor may choose to automatically upgrade 
all ACLs, which might not be trivial.

Alexey

Date: Wed, 01 Sep 2004 11:16:41 +0100
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: [email-masked]
Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10)
Sender: [email-masked]

Cyrus Daboo wrote:

>+---------------+---------------+-----------------------------------+
>  
>
>|               |               |                                   |
>  
>
>|               | read private  | Any mailbox with the 'm' right.   |
>  
>
>|               |               |                                   |
>
Do you actually mean that private annotations are not readable unless 
'm' right is granted? Show me how this is useful (unless you meant 'r' 
here).

>  
>
>|               +---------------+-----------------------------------+
>  
>
>|               |               |                                   |
>  
>
>| Server        | write private | Any mailbox with the 'm' right.   |
>  
>
>| with          |               |                                   |
>  
>
>| ACL/RIGHTS    +---------------+-----------------------------------+
>  
>
>| Extensions    |               |                                   |
>  
>
>|               | read shared   | Any mailbox with the 'r' right.   |
>  
>
>|               |               |                                   |
>  
>
>|               +---------------+-----------------------------------+
>  
>
>|               |               |                                   |
>  
>
>|               | write shared  | Any mailbox with the 'n' right.   |
>  
>
>|               |               |                                   |
>  
>
>+---------------+---------------+-----------------------------------+
>  
>
And to be consistent with READ-ONLY/READ-WRITE response code, I will update ACL[2] to say that:
a). 'm' right doesn't affect READ-ONLY/READ-WRITE
b). the presence of the 'n' right causes the server to return READ-WRITE.

(And I am fine with the changes that you've made as the result of Dave's request).

Alexey