Subject: Re: [lemonade] Re: Planning for meeting in Minneapolis
From: Lisa Dusseault <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked], IMAP Extensions WG <[email-masked]>
Date: Mon, 31 Jan 2005 17:34:45 -0800
List-Id: <ietf-imapext.imc.org>

So, does this mean that we don't need to yank CondStore out of the RFC 
queue?

thanks,
Lisa

On Jan 31, 2005, at 10:44 AM, Alexey Melnikov wrote:

> Lisa Dusseault wrote:
>
>> Alexey needs to propose what changes to make to CondStore, as a 
>> concrete written proposal to the list.
>
> I've just submitted a new draft that describes how CONDSTORE 
> modification sequences can be used to track expunged messages. Before 
> it is announced, people can find it at:
> http://ietf.webdav.org/imapext/draft-melnikov-imap-expunged-00.txt
>
> I will welcome all suggestions, especially on issues marked with <<>> 
> in the document.
>
> I can rework RECONNECT to reference the new document, if people feel 
> it is a good idea.
>
> Alexey
>
>
> _______________________________________________
> lemonade mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/lemonade

Subject: expunged draft
From: Timo Sirainen <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>, [email-masked]
Date: Mon, 31 Jan 2005 22:51:33 +0200
Sender: [email-masked]

--=-GKQMz1/DmeuHdswXxMKD
Content-Type: text/plain; charset=iso-8859-7
Content-Transfer-Encoding: quoted-printable

On Mon, 2005-01-31 at 18:44 +0000, Alexey Melnikov wrote:
> I've just submitted a new draft that describes how CONDSTORE=20
> modification sequences can be used to track expunged messages. Before it=20
> is announced, people can find it at:
> http://ietf.webdav.org/imapext/draft-melnikov-imap-expunged-00.txt
>=20
> I will welcome all suggestions, especially on issues marked with <<>> in=20
> the document.

It shows that HIGHESTMODSEQ update is sent after EXPUNGE command. What
about when other session did the EXPUNGE and we're seeing untagged
EXPUNGEs? Maybe always send it after untagged expunges (and don't
mention EXPUNGE command at all)?

Servers supporting UNSELECT should most likely also send HIGHESTMODSEQ
just as with CLOSE, but this isn't mentioned. And what about with
SELECT? Maybe just point out more generally that "when using a command
which closes the mailbox, send HIGHESTMODSEQ". Perhaps LOGOUT should do
that too?

   <<What if the server can=A2t remember some expunged UIDs, for example
   the provided mod-sequence is too old? Can the server just return
   all UIDs not in the UID set? This can generate additional traffic,
   but should be Ok otherwise.>>

Yes, I think so.

In 3.4 EXPUNGED Response it seems rather useless trying to rewrite what
RFC3501 says about EXPUNGEs. Just point out that it works exactly as
normal untagged EXPUNGE? It would be really bad if they accidentally got
different rules.

Maybe rename the EXPUNGED to UIDEXPUNGE or similar to make it more clear
that it's sending UIDs and not sequences?

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

--=-GKQMz1/DmeuHdswXxMKD--

Date: Mon, 31 Jan 2005 15:42:46 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Cyrus Daboo <[email-masked]>
CC: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: List of WGLC changes to 2086upd-02
Sender: [email-masked]

Cyrus Daboo wrote:

> Hi Ken,
> 
> --On January 31, 2005 2:53:09 PM -0500 Ken Murchison <[email-masked]> 
> wrote:
> 
>>> I've changed the text to require the server to send the virtual "d"/"c"
>>> right in MYRIGHTS/ACL responses when any of the member rights is 
>>> granted.
>>> The 02 text required that all member rights must be granted, before the
>>> virtual right can be returned.
>>
>>
>> What was the rationale for this change?  If all that is set on a mailbox
>> is 'x', reporting 'd' is incorrect.  This will make the client think that
>> it can delete and expunge messages, but it can't.  The only way for the
>> client to get around this is to "reset" the already set 'd' right, which
>> seems counter-intuitive to me.
>>
>> I think its best to keep things the way that you had them.  This way the
>> client will *know* that it can't delete and expunge messages (and also
>> incorrectly assume that it can't DELETE the mailbox, but this is the
>> lesser of two evils IMO) and try to set the 'd' right first.
>>
> 
> I was under the impression that the virtual rights would only be set 
> when ALL the member rights were on, NOT when any member right was on. At 
> least that is what I was trying to say during the interim meeting.
> 
> Here is my rationale (which is based purely on my client 
> implementation): right now the client will disable the 'Delete Message' 
> and 'Expunge Mailbox' UI elements if the 'd' right is set. If a 2086bis 
> server were to report 'd' when 'x' was set and 't' was not set, then the 
> user would be unable to delete messages because the UI was locked out, 
> even though that action is allowed by the server. I would much rather 
> not have 'd' come back in that case, so that both UI items were enabled, 
> but the 'Delete Message' one would result in an IMAP NO response with 
> appropriate error handling in the client. At some point the client can 
> be upgraded to understand the new ACL bits and this will no longer be an 
> issue.

OK, so you'd rather get false positives via MYRIGHTS/ACL rather than 
false negatives.  The logic on the server it trivial either way, and 
since you're the client author and have to deal with this, I'll defer to 
you.  Its too bad we don't have something like a NEEDRIGHT response code 
which can tell the 2086 client which right is required for the failed 
command to succeed.

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

Date: Mon, 31 Jan 2005 15:13:40 -0500
From: Cyrus Daboo <[email-masked]>
To: Ken Murchison <[email-masked]>, Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: List of WGLC changes to 2086upd-02
Sender: [email-masked]

Hi Ken,

--On January 31, 2005 2:53:09 PM -0500 Ken Murchison <[email-masked]> wrote:

>> I've changed the text to require the server to send the virtual "d"/"c"
>> right in MYRIGHTS/ACL responses when any of the member rights is granted.
>> The 02 text required that all member rights must be granted, before the
>> virtual right can be returned.
>
> What was the rationale for this change?  If all that is set on a mailbox
> is 'x', reporting 'd' is incorrect.  This will make the client think that
> it can delete and expunge messages, but it can't.  The only way for the
> client to get around this is to "reset" the already set 'd' right, which
> seems counter-intuitive to me.
>
> I think its best to keep things the way that you had them.  This way the
> client will *know* that it can't delete and expunge messages (and also
> incorrectly assume that it can't DELETE the mailbox, but this is the
> lesser of two evils IMO) and try to set the 'd' right first.
>

I was under the impression that the virtual rights would only be set when 
ALL the member rights were on, NOT when any member right was on. At least 
that is what I was trying to say during the interim meeting.

Here is my rationale (which is based purely on my client implementation): 
right now the client will disable the 'Delete Message' and 'Expunge 
Mailbox' UI elements if the 'd' right is set. If a 2086bis server were to 
report 'd' when 'x' was set and 't' was not set, then the user would be 
unable to delete messages because the UI was locked out, even though that 
action is allowed by the server. I would much rather not have 'd' come back 
in that case, so that both UI items were enabled, but the 'Delete Message' 
one would result in an IMAP NO response with appropriate error handling in 
the client. At some point the client can be upgraded to understand the new 
ACL bits and this will no longer be an issue.

-- 
Cyrus Daboo

Date: Mon, 31 Jan 2005 14:53:09 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Alexey Melnikov <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: List of WGLC changes to 2086upd-02
Sender: [email-masked]

Alexey Melnikov wrote:

> 
> Below I've listed all changes caused by the WGLC comments (excluding 
> fixing few typos, superfluous commas and and new section 3.1.1 that I 
> will describe separately):

> 
> 11). In Appendix B. ("Compatibility with RFC 2086"):
> 
> I've changed the text to require the server to send the virtual "d"/"c" 
> right in MYRIGHTS/ACL responses when any of the member rights is granted.
> The 02 text required that all member rights must be granted, before the 
> virtual right can be returned.

What was the rationale for this change?  If all that is set on a mailbox 
is 'x', reporting 'd' is incorrect.  This will make the client think 
that it can delete and expunge messages, but it can't.  The only way for 
the client to get around this is to "reset" the already set 'd' right, 
which seems counter-intuitive to me.

I think its best to keep things the way that you had them.  This way the 
client will *know* that it can't delete and expunge messages (and also 
incorrectly assume that it can't DELETE the mailbox, but this is the 
lesser of two evils IMO) and try to set the 'd' right first.

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

Date: Mon, 31 Jan 2005 11:44:51 -0800
From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked], Barry Leiba <[email-masked]>, Dave Cridland <[email-masked]>
Subject: Re: Planning for meeting in Minneapolis
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Mon, 31 Jan 2005, Arnt Gulbrandsen wrote:
>> Note that SEARCH, SORT, and THREAD have the possibility of an extension for 
>> a "standing SEARCH" functionality, in which you get a unsolicited SEARCH 
>> when the mailbox changes.
> Not really. Suppose the client has issued a new SEARCH command 0.000000001 
> seconds before receiving the unsolicited SEARCH response. That problem can be 
> worked around, of course, but the workarounds I can imagine aren't pretty.

I didn't say that there weren't issues that would have to be addressed 
before something like this could be done.  That is, in fact, one of the 
big reasons why it hasn't been done yet.

Nevertheless, I was referring to an architectural aspect of IMAP; and in 
that, "any response is possible at any time."  Software which expects a 
particular response from a particular command is broken.  Just the other 
day, I had to deal with a client author who insisted that UW imapd was 
broken because it can issue untagged OK and untagged NO in the course of 
doing a SEARCH.

-- Mark --

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

Date: Mon, 31 Jan 2005 18:46:24 +0000
From: Alexey Melnikov <[email-masked]>
To: "Stephane H. Maes" <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Notes from today's meeting
Sender: [email-masked]

Lisa Dusseault wrote:

> By the way, I'd like to thank Oracle, and Stephane Maes, for the 
> facilities used at the IMAPEXT interim meeting.  The location was 
> pleasant for all and convenient (well, speaking for myself, at least ).

And the food was great too :-).

Date: Mon, 31 Jan 2005 18:44:48 +0000
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
CC: [email-masked]
Subject: Re: Planning for meeting in Minneapolis
Sender: [email-masked]

Lisa Dusseault wrote:

> Alexey needs to propose what changes to make to CondStore, as a 
> concrete written proposal to the list.

I've just submitted a new draft that describes how CONDSTORE 
modification sequences can be used to track expunged messages. Before it 
is announced, people can find it at:
http://ietf.webdav.org/imapext/draft-melnikov-imap-expunged-00.txt

I will welcome all suggestions, especially on issues marked with <<>> in 
the document.

I can rework RECONNECT to reference the new document, if people feel it 
is a good idea.

Alexey

Date: Mon, 31 Jan 2005 19:32:15 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Planning for meeting in Minneapolis
Cc: Barry Leiba <[email-masked]>, Mark Crispin <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Mark Crispin writes:
> Note that SEARCH, SORT, and THREAD have the possibility of an 
> extension for a "standing SEARCH" functionality, in which you get a 
> unsolicited SEARCH when the mailbox changes.

Not really. Suppose the client has issued a new SEARCH command 
0.000000001 seconds before receiving the unsolicited SEARCH response. 
That problem can be worked around, of course, but the workarounds I can 
imagine aren't pretty.

> Any new response which can not be handled in isolation is 
> fundamentally broken.

I agree with this. Such responses just don't fit IMAP.

Arnt

content-class: urn:content-classes:message
Subject: RE: Planning for meeting in Minneapolis
Date: Mon, 31 Jan 2005 10:53:35 -0600
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext Mark Crispin
> Sent: Monday, January 31, 2005 11:33 AM
...
> On Mon, 31 Jan 2005, Dave Cridland wrote:
> > a) The CHILDINFO extension blob proposal was arrived at 
> partly because 
> > clients are often deliberately programmed such that 
> commands are used merely 
> > to elicit reponses, and the responses are often handled in 
> isolation, without 
> > actually knowing the command in progress.
> > Feel free to call this a case of bad programming, it's 
> nevertheless quite 
> > common, as far as I'm aware - I do it myself.
> 
> It's *not* bad programming.  It's the fundamental design of IMAP.

This was my understanding as well. I'm glad you confirmed this.

This is the fundamental difference between a truly unsolicited 
response as opposed to a simple untagged response. I find this
to be an IMAP strength.

Mike

Date: Mon, 31 Jan 2005 08:33:09 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: Barry Leiba <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Planning for meeting in Minneapolis
Sender: [email-masked]

On Mon, 31 Jan 2005, Dave Cridland wrote:
> a) The CHILDINFO extension blob proposal was arrived at partly because 
> clients are often deliberately programmed such that commands are used merely 
> to elicit reponses, and the responses are often handled in isolation, without 
> actually knowing the command in progress.
> Feel free to call this a case of bad programming, it's nevertheless quite 
> common, as far as I'm aware - I do it myself.

It's *not* bad programming.  It's the fundamental design of IMAP.

Note that SEARCH, SORT, and THREAD have the possibility of an extension 
for a "standing SEARCH" functionality, in which you get a unsolicited 
SEARCH when the mailbox changes.

Any new response which can not be handled in isolation is fundamentally 
broken.

-- Mark --

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

Date: Mon, 31 Jan 2005 16:16:42 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Planning for meeting in Minneapolis
Cc: Barry Leiba <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Dave Cridland writes:
> "New" LIST wouldn't be the first command whose responses cannot be 
> parsed in isolation - SEARCH, SORT, and THREAD all require knowledge 
> of the command issued - but I'm concerned that "old" LIST didn't 
> behave this way, and I suspect that a number of clients will require 
> significant rewriting to take advantage of selection options (other 
> than REMOTE).

If that turns out to be the case, and the specification remains hard to 
understand for people of such modest intelligence as myself, then I 
wouldn't be surprised if the LIST command in the base specification has 
a long life in front of it.

Arnt

From: Dave Cridland <[email-masked]>
To: Barry Leiba <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Planning for meeting in Minneapolis
Date: Mon, 31 Jan 2005 10:44:07 +0000
Sender: [email-masked]

On Fri Jan 28 23:28:31 2005, Barry Leiba wrote:
> > If the client pipelines requests that result in ambiguous
> > responses, well, "Doctor it hurts when I do _this_...".
> 
> Or put more IETF-ly, clients MUST NOT send simultaneous LIST commands,
> the responses from which they would not be able to sort out
> unambiguously.

My only niggles about this are:

a) The CHILDINFO extension blob proposal was arrived at partly because clients are often deliberately programmed such that commands are used merely to elicit reponses, and the responses are often handled in isolation, without actually knowing the command in progress.

Feel free to call this a case of bad programming, it's nevertheless quite common, as far as I'm aware - I do it myself. Arnt Gulbrandsen raised the issue, as well as (I believe) others. [Yes, I know I came up with the beginnings of CHILDINFO, but I didn't come up with the reason, and I'm not wed to the syntax.]

"New" LIST wouldn't be the first command whose responses cannot be parsed in isolation - SEARCH, SORT, and THREAD all require knowledge of the command issued - but I'm concerned that "old" LIST didn't behave this way, and I suspect that a number of clients will require significant rewriting to take advantage of selection options (other than REMOTE).

So I feel it's more "Doctor, it's suddenly started hurting when I do _this_". I admit it's not as funny phrased that way.

b) It precludes sending unsolicited LIST responses in some extension or other. Some extensions have been proposed which do this, I think, mostly in the LEMONADE area. It's quite useful for, for instance, notifications about creation and renaming of mailboxes - otherwise a client has to pick a refresh time for the LIST, which may be expensive in terms of bandwidth.

I feel we might be in the process of locking doors before we've had a chance to look inside.

Dave.

Date: Fri, 28 Jan 2005 18:28:31 -0500
From: Barry Leiba <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: Planning for meeting in Minneapolis
Sender: [email-masked]

> These were discussed fairly completely during the meeting and we came
> to consensus that
> -) MATCHPARENT would stay; not much point in making LIST extendable if
>    things that can reasonably be options are instead implicitly
>    triggered

Yes, but we decided to call it "recursivematch".

> -) \placeholder and \hassubmailboxes will be replaced by a single flag
>    named something like \hasmatchingchild.  Whether the returned name
>    itself matches can be trivially deduced from the other returned
>    flags.

Correct, and "\hasmatchingchildren" was what we were calling it.  I'm
open to other names, but I think this name makes its purpose clear
(where "hassubmailboxes" did not).

> If the client pipelines requests that result in ambiguous
> responses, well, "Doctor it hurts when I do _this_...".

Or put more IETF-ly, clients MUST NOT send simultaneous LIST commands,
the responses from which they would not be able to sort out
unambiguously.

> -) keeping the CHILDREN option and its behavior separate from
>    MATCHPARENT was deemed to be clearer than merging them.  CHILDREN
>    would be changed to require exact responses:

In other words, correct implementation of CHILDREN *will* be required
by the LISTEXT spec, but the "\haschildren" and "\hasnochildren" flags
will only be returned if they're asked for.  We DO need the
"\hasnochildren" flag to distinguish the absence of children from the
case where the server decides to send an unsolicited LIST response at
the same time as it's responding to a LIST command.

We've gone back and forth on this one, and I hope we have now decided
it firmly.  The reasoning is that clients that want the has<no>children
help will do the work with a series of commands anyway, and even if
it's not convenient for some server implementations to provide it, it's
still a LOT cheaper for them to do it in the server than for the client
to have to request them separately.

> There was some discussion of requiring LIST to return BAD if
> MATCHPARENT was used with a pattern containing '*', but I'm not sure
> that was dropped later as being too restrictive.

It was dropped.  We decided, after thinking about it, that it's not
*really* a problem.  The consensus at the end was that there need be no
restrictions on when "recursivematch" can be used.

There was the issue of recursion loops, and we decided to allow a
server, probably with a MAY clause, to limit the depth.  We did not
pick a minimum depth that MUST be implemented, so we should pick one
here.

We should have examples in the jabber log, assuming that Rob was able
accurately to enter my scratchings on the white-boards, since I
annoyingly refused to write from left to right.  Should we copy those
examples here, or just point to the jabber logs?

Barry

--
Barry Leiba, Pervasive Computing Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam

From: Philip Guenther <[email-masked]>
To: Lisa Dusseault <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Planning for meeting in Minneapolis 
Date: Fri, 28 Jan 2005 14:33:30 -0800
Sender: [email-masked]

(Resubmitting from my subscribed address... <sigh>)

Lisa Dusseault <[email-masked]> writes:
>Philip owes a write-up that describes how to replace /MatchParent 
>/PlaceHolder in LISTEXT by Jan 28

There were three proposed changes:
-) remove the MATCHPARENT flag and instead trigger the behavior if the
   pattern ends with a '%'; this would have the benefit of making
   extended and unextended LIST behave similarly
-) eliminate \placeholder and \hassubmailbox and instead include a
   CHILDINFO blob when the returned name has a matching submailbox;
   this would make LIST responses unambiguous even when pipelined
-) (if MATCHPARENT stays, then) drop the CHILDREN option as well as the
   restriction on MATCHPARENT that another selection option must be
   present; MATCHPARENT without any other selection options would return
   equivalent info to that which had been returned by the CHILDREN
   option

These were discussed fairly completely during the meeting and we came to
consensus that
-) MATCHPARENT would stay; not much point in making LIST extendable if
   things that can reasonably be options are instead implicitly
   triggered
-) \placeholder and \hassubmailboxes will be replaced by a single flag
   named something like \hasmatchingchild.  Whether the returned name
   itself matches can be trivially deduced from the other returned
   flags.  (E.g., a \placeholder from the SUBSCRIBED selection option
   will instead have the new flag but _won't_ have the \subscribed flag)
   If the client pipelines requests that result in ambiguous responses,
   well, "Doctor it hurts when I do _this_...".  Servers will be banned
   from returning the new flag except in direct response to a client
   request.
-) keeping the CHILDREN option and its behavior separate from
   MATCHPARENT was deemed to be clearer than merging them.  CHILDREN
   would be changed to require exact responses: absence of the
   \haschildren flag in a response that matched a client request with
   the CHILDREN option would mean the name does not have any
   (accessible) submailboxes.

Unclear was whether the MATCHPARENT option should be renamed (again).  A
couple other names were bounced around but I don't recall any that stood
out as obviously clearer.

There was some discussion of requiring LIST to return BAD if
MATCHPARENT was used with a pattern containing '*', but I'm not sure
that was dropped later as being too restrictive.  It would eliminate
some of the weird cases in the MATCHPARENT description, as it would
outlaw the possibility of a mailbox and one of its children being
matched by the same parent.

Philip Guenther

Cc: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: Planning for meeting in Minneapolis 
Date: Fri, 28 Jan 2005 14:27:52 -0800
To: Philip Guenther <[email-masked]>
Sender: [email-masked]

>
> Unclear was whether the MATCHPARENT option should be renamed (again).  
> A
> couple other names were bounced around but I don't recall any that 
> stood
> out as obviously clearer.

Personally I preferred RECURSIVE but I'll be happy to just tally folks' 
votes instead.

Lisa

To: Lisa Dusseault <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Planning for meeting in Minneapolis 
Date: Fri, 28 Jan 2005 14:24:03 -0800
From: Philip Guenther <[email-masked]>
Sender: [email-masked]

Lisa Dusseault <[email-masked]> writes:
>Philip owes a write-up that describes how to replace /MatchParent 
>/PlaceHolder in LISTEXT by Jan 28

There were three proposed changes:
-) remove the MATCHPARENT flag and instead trigger the behavior if the
   pattern ends with a '%'; this would have the benefit of making
   extended and unextended LIST behave similarly
-) eliminate \placeholder and \hassubmailbox and instead include a
   CHILDINFO blob when the returned name has a matching submailbox;
   this would make LIST responses unambiguous even when pipelined
-) (if MATCHPARENT stays, then) drop the CHILDREN option as well as the
   restriction on MATCHPARENT that another selection option must be
   present; MATCHPARENT without any other selection options would return
   equivalent info to that which had been returned by the CHILDREN
   option

These were discussed fairly completely during the meeting and we came to
consensus that
-) MATCHPARENT would stay; not much point in making LIST extendable if
   things that can reasonably be options are instead implicitly
   triggered
-) \placeholder and \hassubmailboxes will be replaced by a single flag
   named something like \hasmatchingchild.  Whether the returned name
   itself matches can be trivially deduced from the other returned
   flags.  (E.g., a \placeholder from the SUBSCRIBED selection option
   will instead have the new flag but _won't_ have the \subscribed flag)
   If the client pipelines requests that result in ambiguous responses,
   well, "Doctor it hurts when I do _this_...".  Servers will be banned
   from returning the new flag except in direct response to a client
   request.
-) keeping the CHILDREN option and its behavior separate from
   MATCHPARENT was deemed to be clearer than merging them.  CHILDREN
   would be changed to require exact responses: absence of the
   \haschildren flag in a response that matched a client request with
   the CHILDREN option would mean the name does not have any
   (accessible) submailboxes.

Unclear was whether the MATCHPARENT option should be renamed (again).  A
couple other names were bounced around but I don't recall any that stood
out as obviously clearer.

There was some discussion of requiring LIST to return BAD if
MATCHPARENT was used with a pattern containing '*', but I'm not sure
that was dropped later as being too restrictive.  It would eliminate
some of the weird cases in the MATCHPARENT description, as it would
outlaw the possibility of a mailbox and one of its children being
matched by the same parent.

Philip Guenther

Date: Thu, 27 Jan 2005 22:51:18 +0000
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: List of WGLC changes to 2086upd-02
Sender: [email-masked]

Below I've listed all changes caused by the WGLC comments (excluding 
fixing few typos, superfluous commas and and new section 3.1.1 that I 
will describe separately):

1). Added new section 3.2 "Rights defined in RFC 2086". It reads:

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

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

2). In section 3:

changed:

    A DELETEACL of "fred" simply deletes the identifier "fred"
    from the ACL; it does not affect any rights that the user "fred"
    may get from another entry in the ACL.

to:

    A DELETEACL of "fred" simply deletes the identifier "fred"
    from the ACL; it does not affect any rights that the user "fred"
    may get from another entry in the ACL, in particular it doesn't affect
    rights granted to the identifier "-fred".

3). Added DELETEACL example in section 4.2:

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

4). Fixed examples in section 4.3 (GETACL command):

It should be:
               S: * ACL INBOX Fred rwipsldexta
instead of
               S: * ACL INBOX Fred rwipslda

5). Examples in section 4.4 (LISTRIGHTS command) also must be fixed. The 
final examples depend on our decision on LISTRIGHTS/virtual rights 
resolution.

6). Fixed examples in section 4.5 (MYRIGHTS command):

Should be
               S: * MYRIGHTS INBOX rwiptsldaex
instead of

               S: * MYRIGHTS INBOX rwipslda

7). Added the following text to each of the following sections: 4.6. 
(ACL response), 4.7. (LISTRIGHTS response) and 4.8. (MYRIGHTS response):
 
      Section 3.1.1 details additional server requirements related to 
handling
      of the virtual "d" and "c" rights.

8). In section 5: clarified which rights are required for the DELETE 
command:

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

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

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

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

9). In section 6.1.1:

Added the "l" right for the INBOX in the example and added a pipelined 
version of the example:

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

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

10). In section 8. ("Formal Syntax"):

 Changed the "new_rights" production to only allow for LOWER_ALPHA. 
Draft 02 allowed for digits as well.

11). In Appendix B. ("Compatibility with RFC 2086"):

I've changed the text to require the server to send the virtual "d"/"c" 
right in MYRIGHTS/ACL responses when any of the member rights is granted.
The 02 text required that all member rights must be granted, before the 
virtual right can be returned.

Alexey

Date: Thu, 27 Jan 2005 22:13:19 +0000
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: Last remaining RFC2086bis issue: LISTRIGHTS and virtual rights
Sender: [email-masked]

Alexey Melnikov wrote:

> Alexey Melnikov wrote:
>
>> Dave and Ken have raised a new issue with LISTRIGHTS command and 
>> virtual rights. The current text as written suggests that if any 
>> member right is tied to another right, which is not a member of the 
>> same virtual right, or if member rights are not tied together, then 
>> the server is not allowed to list the virtual right in a LISTRIGHTS 
>> response. For example, if "t" is tied to "sw", the server can't 
>> return "d". This will confuse legacy clients.
>>
>> There are several alternatives how to deal with the issue:
>> 1). Live with the current limitation and do nothing.
>>
[...]

>> 3). If member rights are not tied together, the virtual right is 
>> listed by itself. For the example listed above:
>>
>> * LISTRIGHTS INBOX someone "" "tws" "ei" "lr" "p" "k" "x" "a" "c" "d"
>
> Actually, whether the "d" right is returned here is still an open 
> issue: if the "d" right is not returned, a legacy client might limit 
> functionality available to users.

Never mind, this is just case #1.

> If the "d" right is returned, the server is lying, because the "d" 
> right can't be granted by itself.

Date: Thu, 27 Jan 2005 21:40:00 +0000
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Last remaining RFC2086bis issue: LISTRIGHTS and virtual rights
Sender: [email-masked]

Alexey Melnikov wrote:

> Dave and Ken have raised a new issue with LISTRIGHTS command and 
> virtual rights. The current text as written suggests that if any 
> member right is tied to another right, which is not a member of the 
> same virtual right, or if member rights are not tied together, then 
> the server is not allowed to list the virtual right in a LISTRIGHTS 
> response. For example, if "t" is tied to "sw", the server can't return 
> "d". This will confuse legacy clients.
>
> There are several alternatives how to deal with the issue:
> 1). Live with the current limitation and do nothing.
>
> 2). In the described case the server should list the virtual right as 
> tied to a union of all the rights the individual members are tied to. 
> If member rights are not tied, the virtual right is listed by itself. 
> For example, a c=>kx server might return:
>
> * LISTRIGHTS INBOX someone "" "tws" "ei" "lr" "p" "k" "x" "a" "c" "dwsi"
>
> Where the draft currently says:
> * LISTRIGHTS INBOX someone "" "tws" "ei" "lr" "p" "k" "x" "a"
>
> In this case the client must ignore all strings containing virtual 
> rights.
>
> 3). If member rights are not tied together, the virtual right is 
> listed by itself. For the example listed above:
>
> * LISTRIGHTS INBOX someone "" "tws" "ei" "lr" "p" "k" "x" "a" "c" "d"

Actually, whether the "d" right is returned here is still an open issue: 
if the "d" right is not returned, a legacy client might limit 
functionality available to users. If the "d" right is returned, the 
server is lying, because the "d" right can't be granted by itself.

> 4). Dave has suggested to add a new optional parameter to LISTRIGHTS 
> to signal that the client is a new client and it understands new 
> rights. When the parameter is specified, the server will not return 
> virtual rights.
> =========
> I don't like the proposal #1,

I meant #2, of course.

> as I think it might confuse clients: it might make clients believe 
> that the "w" right is tied to the "i" right, when it is not.
> #4 seems like the cleanest solution, however I am concerned that we 
> are spending too much effort on fixing ACL, instead of finishing ACL2.

After discussion at the interim IETF I've got impression that people 
don't want to go with #4 either.

So basically the WG has to choose between #1 (virtual right is not 
advertised) and #3.

#3 seems to be more permissive, as opposed to #1, which is too 
restrictive, but the server is allowed to fail SETACL for any reason anyway.

So I would prefer #3.

> Comments?

Anyone?

-- 
Alexey Melnikov
__________________________________________
Isode Limited, http://www.isode.com

Cell: +44 7753759732

IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.html

Personal Home Page: http://www.melnikov.ca
__________________________________________

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Planning for meeting in Minneapolis
Date: Wed, 26 Jan 2005 17:19:21 -0800
Sender: [email-masked]

I would like to meet again in Minneapolis.  We make decent progress in 
meetings and maybe this will be our final push.  In a best-case 
scenario we could last call everything but ACL before then and focus on 
ACL in the meeting, but I never count on the best-case scenario :)

Any agenda requests, conflicts to avoid, authors who can't make it 
(Alexey)?  if so let me know ... if not,  start registering and making 
your travel plans.

As a reminder, here are the deliverables from last week's meeting:

Alexey to post all 2086upd changes to list by January 28 (Friday) 
barring further hardware problems.
Alexey also to publish new 2086upd draft to send to IESG.
Randy & Cyrus: New annotate draft promised for January 31, which we 
intend to do WG last-call
Alexey needs to propose what changes to make to CondStore, as a 
concrete written proposal to the list.
Philip owes a write-up that describes how to replace /MatchParent 
/PlaceHolder in LISTEXT by Jan 28

Other tasks not listed as deliverables in the notes:
  - after Philip's write-up and ensuing discussion, we'll surely need 
another LISTEXT draft from Barry and Alexey
  - at some point an updated draft for ACL.

Finally, the deadline for updating Internet-Drafts for Minneapolis is 
listed (http://www.ietf.org/meetings/cutoff_dates_62.html) as February 
21.

Lisa

Date: Mon, 24 Jan 2005 15:58:37 -0500
From: Cyrus Daboo <[email-masked]>
To: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>
cc: "Stephane H. Maes" <[email-masked]>
Subject: Re: Notes from today's meeting
Sender: [email-masked]

Hi Lisa,

--On January 24, 2005 12:17:02 PM -0800 Lisa Dusseault 
<[email-masked]> wrote:

> By the way, I'd like to thank Oracle, and Stephane Maes, for the
> facilities used at the IMAPEXT interim meeting.  The location was
> pleasant for all and convenient (well, speaking for myself, at least ).
>

Thanks also to Pete for allowing me true audio-visual virtual presence at 
the meeting via iChatAV...

-- 
Cyrus Daboo

Cc: "Stephane H. Maes" <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: Notes from today's meeting
Date: Mon, 24 Jan 2005 12:17:02 -0800
To: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

By the way, I'd like to thank Oracle, and Stephane Maes, for the 
facilities used at the IMAPEXT interim meeting.  The location was 
pleasant for all and convenient (well, speaking for myself, at least ).

Lisa

On Jan 20, 2005, at 4:56 PM, Lisa Dusseault wrote:

>
> I've posted the notes from today's meeting:
>
> http://ietf.webdav.org/imapext/notes/Jan2005InterimNotes.txt
>
> Please review and see if there are any corrections, then I will submit 
> for the official IETF record.
>
> Lisa
>

From: Steve Hole <[email-masked]>
Date: Fri, 21 Jan 2005 13:15:16 -0700
To: [email-masked]
Subject: RE: more details on agenda
Cc: [email-masked]
Sender: [email-masked]

On Fri, 21 Jan 2005 10:37:07 -0600 [email-masked] wrote:

> You should read Lisa's follow on mtg minutes. It clarifies the 
> actual discussion regarding CONSTORE much better. The "lack of 
> strong support" referred to sending it back through last call 
> after the factual changes were made.
> 
> There was support for the actual changes Alexey proposed 
> to make to the draft. 

I did read it later and it answered my questions.   All good.

Cheers.
---
Steve Hole
Chief Technical Officer - Electronic Billing and Payment Systems
ACI Worldwide

Email: [email-masked]
Phone: 780 424 4922

Cc: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: more details on agenda
Date: Fri, 21 Jan 2005 08:49:28 -0800
To: Steve Hole <[email-masked]>
Sender: [email-masked]

Sorry, that was my confusing short form.

The Conditional Store draft is already in the RFC Editor's queue, 
having been approved by the WG and by the IESG.  However, it can't 
leave the RFC Editor's queue until all its dependencies have gotten to 
RFC publication status as well, including its dependencies on the 
Annotate draft.  We hope to get Annotate to WG last call Real Soon Now, 
so that should help unblock it.  There is sufficient support for this 
draft that nobody would consider "cancelling" it, especially not at 
this point.

Alexey & Cyrus, however, found a problem in the draft after it was 
approved by the WG and the IESG: some ambiguity or lack of 
specification in what should or shouldn't be updated on expunge 
actions.  So, on the list, Alexey proposed removing the CondStore draft 
from the RFC Editor's queue to fix that problem.  That would require 
the WG to reconsider the draft and do another WG last call, then have 
it go through the IESG approval again.  Initially when Alexey proposed 
this I saw no answer on the list -- I interpreted that as "no support 
for Alexey's suggestion" (although it could also be argued to be no 
opposition).  As it turns out, people in the room yesterday felt some 
reluctant support for Alexey's suggestion although they're not sure 
yet.

Another option we discussed was the possibility of obsoleting the 
CondStore specification, by replacing it with one which fixes the 
problem, essentially immediately -- leaving the one in RFC Editor queue 
to finish on its own without disruption.

So this would be a good thing to discuss further: how bad a problem, 
are there workarounds for clients, what's the set of possible technical 
and process solutions?

Lisa

On Jan 21, 2005, at 7:49 AM, Steve Hole wrote:

> On Thu, 20 Jan 2005 13:34:30 -0800 Lisa Dusseault 
> <[email-masked]>
> wrote:
>
>> CondStore
>>   - Alexey proposed making changes which is generally not advised
>>   - no evidence of strong support
>>   - fix post RFC?
>
> Hmm ...
>
> No evidence of strong support within the group?
>
> We are intensely interested in this particular draft as it provides a
> capability for an IMAP mailbox to act as a queue for automatically
> processed messages -- the moral equivalent of MQSeries done on Internet
> email.
>
> We are already processing SOAP messages this way ... and it works
> wonderfully.
>
> So, I'm very interested in this proceeding.   We have implemented the
> current version of the CONDSTORE draft.   This note seems to indicate 
> that
> there is something wrong with the draft?   I must have missed 
> something.
>
> Cheers.
>
> ---
> Steve Hole
> Chief Technical Officer - Electronic Billing and Payment Systems
> ACI Worldwide
>
> Email: [email-masked]
> Phone: 780 424 4922
>
>

content-class: urn:content-classes:message
Subject: RE: more details on agenda
Date: Fri, 21 Jan 2005 10:37:07 -0600
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

You should read Lisa's follow on mtg minutes. It clarifies the 
actual discussion regarding CONSTORE much better. The "lack of 
strong support" referred to sending it back through last call 
after the factual changes were made.

There was support for the actual changes Alexey proposed 
to make to the draft. 

Mike

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext Steve Hole
> Sent: Friday, January 21, 2005 10:50 AM
> To: Lisa Dusseault
> Cc: IMAP Extensions WG
> Subject: Re: more details on agenda
> 
> 
> 
> On Thu, 20 Jan 2005 13:34:30 -0800 Lisa Dusseault 
> <[email-masked]> 
> wrote:
> 
> > CondStore
> >   - Alexey proposed making changes which is generally not advised
> >   - no evidence of strong support
> >   - fix post RFC?
> 
> Hmm ...
> 
> No evidence of strong support within the group?
> 
> We are intensely interested in this particular draft as it provides a 
> capability for an IMAP mailbox to act as a queue for automatically 
> processed messages -- the moral equivalent of MQSeries done 
> on Internet 
> email.   
> 
> We are already processing SOAP messages this way ... and it works 
> wonderfully.
> 
> So, I'm very interested in this proceeding.   We have implemented the 
> current version of the CONDSTORE draft.   This note seems to 
> indicate that
> there is something wrong with the draft?   I must have missed 
> something.
> 
> Cheers.
> 
> ---
> Steve Hole
> Chief Technical Officer - Electronic Billing and Payment Systems
> ACI Worldwide
> 
> Email: [email-masked]
> Phone: 780 424 4922
> 
> 
> 

From: Steve Hole <[email-masked]>
Date: Fri, 21 Jan 2005 08:49:38 -0700
To: Lisa Dusseault <[email-masked]>
Subject: Re: more details on agenda
Cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Thu, 20 Jan 2005 13:34:30 -0800 Lisa Dusseault <[email-masked]> 
wrote:

> CondStore
>   - Alexey proposed making changes which is generally not advised
>   - no evidence of strong support
>   - fix post RFC?

Hmm ...

No evidence of strong support within the group?

We are intensely interested in this particular draft as it provides a 
capability for an IMAP mailbox to act as a queue for automatically 
processed messages -- the moral equivalent of MQSeries done on Internet 
email.   

We are already processing SOAP messages this way ... and it works 
wonderfully.

So, I'm very interested in this proceeding.   We have implemented the 
current version of the CONDSTORE draft.   This note seems to indicate that
there is something wrong with the draft?   I must have missed something.

Cheers.

---
Steve Hole
Chief Technical Officer - Electronic Billing and Payment Systems
ACI Worldwide

Email: [email-masked]
Phone: 780 424 4922

Date: Fri, 21 Jan 2005 16:19:30 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: more details on agenda
Cc: Scott Hollenbeck <[email-masked]>, Lisa Dusseault <[email-masked]>
Sender: [email-masked]

Lisa Dusseault writes:
> That sounds feasible to me; I think that means we do a WG last call on 
> i18n soonish, because then we'll be all set for it to go to IESG as 
> soon as comparator does.  (Unless i18n went to WG last call already 
> and I didn't notice?)

It didn't. Until it's updated for comparator-03, it shouldn't. But 
comparator-03 seems to be all i18n needs, so I suppose WGLC is okay 
once I've done that update.

(The LC order feels weird to me, though.)

Arnt

Cc: [email-masked], "'Arnt Gulbrandsen'" <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: more details on agenda
Date: Fri, 21 Jan 2005 06:55:09 -0800
To: "Scott Hollenbeck" <[email-masked]>
Sender: [email-masked]

That sounds feasible to me; I think that means we do a WG last call on 
i18n soonish, because then we'll be all set for it to go to IESG as 
soon as comparator does.  (Unless i18n went to WG last call already and 
I didn't notice?)

Lisa

On Jan 21, 2005, at 5:43 AM, Scott Hollenbeck wrote:

>
>> -----Original Message-----
>> From: Arnt Gulbrandsen [mailto:[email-masked]]
>> Sent: Thursday, January 20, 2005 6:07 PM
>> To: [email-masked]
>> Subject: Re: more details on agenda
>>
>>
>>
>> Lisa Dusseault writes:
>>> Status of i18n: need to submit to IESG
>>>  - no real hurry because blocked behind comparator draft,
>> but why not
>>>  get off our plate?
>>>  - Proposed action: Remind Arnt to get it off his plate
>>
>> I thought IESG submission had to wait for the comparator draft. I'm
>> fuzzy on the details, but last summer, I thought the comparator draft
>> might well force some sort of substantial change to the imap i18n
>> draft, something that would invalidate IESG blessing.
>
> draft-ietf-imapext-sort-17 is blocked while it waits for both the i18n 
> and
> comparator drafts.  I'd prefer to bring both the i18n and comparator 
> drafts
> to the IESG at the same time to better clarify their relationship.
>
> -Scott-
>

From: "Scott Hollenbeck" <[email-masked]>
To: "'Arnt Gulbrandsen'" <[email-masked]>, [email-masked]
Subject: RE: more details on agenda
Date: Fri, 21 Jan 2005 08:43:39 -0500
Importance: Normal
Sender: [email-masked]

> -----Original Message-----
> From: Arnt Gulbrandsen [mailto:[email-masked]] 
> Sent: Thursday, January 20, 2005 6:07 PM
> To: [email-masked]
> Subject: Re: more details on agenda
> 
> 
> 
> Lisa Dusseault writes:
> > Status of i18n: need to submit to IESG
> >  - no real hurry because blocked behind comparator draft, 
> but why not 
> >  get off our plate?
> >  - Proposed action: Remind Arnt to get it off his plate
> 
> I thought IESG submission had to wait for the comparator draft. I'm 
> fuzzy on the details, but last summer, I thought the comparator draft 
> might well force some sort of substantial change to the imap i18n 
> draft, something that would invalidate IESG blessing.

draft-ietf-imapext-sort-17 is blocked while it waits for both the i18n and
comparator drafts.  I'd prefer to bring both the i18n and comparator drafts
to the IESG at the same time to better clarify their relationship.

-Scott-

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Notes from today's meeting
Date: Thu, 20 Jan 2005 16:56:02 -0800
Sender: [email-masked]

I've posted the notes from today's meeting:

http://ietf.webdav.org/imapext/notes/Jan2005InterimNotes.txt

Please review and see if there are any corrections, then I will submit 
for the official IETF record.

Lisa

Cc: [email-masked]
From: Lisa Dusseault <[email-masked]>
Subject: Re: more details on agenda
Date: Thu, 20 Jan 2005 15:37:28 -0800
To: Arnt Gulbrandsen <[email-masked]>
Sender: [email-masked]

Anyway, I should also explain that that was an off-the-cuff agenda 
entry and reflects only the muddled state of my brain, not the 
conclusion of the discussion: for that you'll have to wait for the 
notes.  :)

Lisa

On Jan 20, 2005, at 3:06 PM, Arnt Gulbrandsen wrote:

>
> Lisa Dusseault writes:
>> Status of i18n: need to submit to IESG
>>  - no real hurry because blocked behind comparator draft, but why not 
>>  get off our plate?
>>  - Proposed action: Remind Arnt to get it off his plate
>
> I thought IESG submission had to wait for the comparator draft. I'm 
> fuzzy on the details, but last summer, I thought the comparator draft 
> might well force some sort of substantial change to the imap i18n 
> draft, something that would invalidate IESG blessing.
>
> I'll re-read comparator-03 and i18n-04 closely and see if I still 
> think so. My Friday is a little crimped (real-estate agent in the 
> morning + tax advisor in the afternoon = great day), so next week is 
> more likely.
>
> Arnt
>

Cc: [email-masked]
From: Lisa Dusseault <[email-masked]>
Subject: Re: more details on agenda
Date: Thu, 20 Jan 2005 15:32:09 -0800
To: Arnt Gulbrandsen <[email-masked]>
Sender: [email-masked]

I asked around if there was any likelihood that it would force a 
substantial change but then again I'm not sure I asked the right set of 
people.  It is a tradeoff-- holding onto it in case we want to change 
it, vs. getting it off our plate to avoid having yet another thing on 
our plate at this point.

There is no process objection to submitting i18n to IESG before 
comparator gets submitted to IESG -- that's what happened with 
cond-store and annotate.  And I guess that is an illustrative case as 
there's a proposal to yank cond-store back although it's not due to 
changes in annotate.

lias

On Jan 20, 2005, at 3:06 PM, Arnt Gulbrandsen wrote:

>
> Lisa Dusseault writes:
>> Status of i18n: need to submit to IESG
>>  - no real hurry because blocked behind comparator draft, but why not 
>>  get off our plate?
>>  - Proposed action: Remind Arnt to get it off his plate
>
> I thought IESG submission had to wait for the comparator draft. I'm 
> fuzzy on the details, but last summer, I thought the comparator draft 
> might well force some sort of substantial change to the imap i18n 
> draft, something that would invalidate IESG blessing.
>
> I'll re-read comparator-03 and i18n-04 closely and see if I still 
> think so. My Friday is a little crimped (real-estate agent in the 
> morning + tax advisor in the afternoon = great day), so next week is 
> more likely.
>
> Arnt
>

Date: Fri, 21 Jan 2005 00:06:40 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: more details on agenda
Sender: [email-masked]

Lisa Dusseault writes:
> Status of i18n: need to submit to IESG
>  - no real hurry because blocked behind comparator draft, but why not 
>  get off our plate?
>  - Proposed action: Remind Arnt to get it off his plate

I thought IESG submission had to wait for the comparator draft. I'm 
fuzzy on the details, but last summer, I thought the comparator draft 
might well force some sort of substantial change to the imap i18n 
draft, something that would invalidate IESG blessing.

I'll re-read comparator-03 and i18n-04 closely and see if I still think 
so. My Friday is a little crimped (real-estate agent in the morning + 
tax advisor in the afternoon = great day), so next week is more likely.

Arnt

Date: Thu, 20 Jan 2005 16:57:29 -0500
From: Cyrus Daboo <[email-masked]>
To: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Hallway discussion on views, cursors, windows
Sender: [email-masked]

Hi Lisa,

--On January 20, 2005 1:25:36 PM -0800 Lisa Dusseault 
<[email-masked]> wrote:

> Expired draft archived:
> http://ietf.webdav.org/imapext/archive/draft-ietf-imapext-view-00.txt
>
> anybody who wants to provide more history than I have, go ahead...
>

I have now uploaded the latest versions of the view and window drafts to 
the Webdav server:

<http://ietf.webdav.org/imapext/archive/draft-ietf-imapext-view-03.txt>
<http://ietf.webdav.org/imapext/archive/window.txt>

-- 
Cyrus Daboo

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: more details on agenda
Date: Thu, 20 Jan 2005 13:34:30 -0800
Sender: [email-masked]

Here's the agenda for today, so far,  based off the charter  
deliverables:

Status of i18n: need to submit to IESG
  - no real hurry because blocked behind comparator draft, but why not  
get off our plate?
  - Proposed action: Remind Arnt to get it off his plate

2086bis
  - Need draft with changes from last call
  - Confirm that changes are minor enough
  - references to Annotate gone?

Annotate
  -  
http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-11.txt
  - Randy, Cyrus
  - authors need to follow up with draft to last-call -- due date?

ListExt
  -  
http://www.ietf.org/internet-drafts/draft-ietf-imapext-list-extensions 
-10.txt
  - Barry, Alexey

CondStore
  - Alexey proposed making changes which is generally not advised
  - no evidence of strong support
  - fix post RFC?

ACL2
  - ready for next steps?

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Hallway discussion on views, cursors, windows
Date: Thu, 20 Jan 2005 13:25:36 -0800
Sender: [email-masked]

We had a hallway discussion today amongst the locally-present Lemonade  
and IMAPEXT people about whether the work on views, cursors/windows or  
virtual mailboxes ought to continue.  This is a set of work which was  
intended to let clients work with a subset of a large mailbox in  
various ways.

As I understand, this work was initially in IMAPEXT but eventually got  
dropped.  Today's discussion did not revive that work within IMAPEXT  
but we thought that if there was enough interest, then those interested  
parties could get together and work on that and probably get it charted  
in Lemonade or whatever WG follows Lemonade.

Some pointers to historic work:
http://www.ietf.org/internet-drafts/draft-wener-lemonade-msgfilter 
-01.txt
Expired draft archived:  
http://ietf.webdav.org/imapext/archive/draft-ietf-imapext-view-00.txt

anybody who wants to provide more history than I have, go ahead...

lisa

Date: Thu, 20 Jan 2005 15:15:27 -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: Interim meeting
Sender: [email-masked]

The interim IMAPext meeting in San Francisco will start formally at 2 pm 
PST, but people will start informal discussions at 1 pm PST. The jabber 
room will be in use for anyone that wants to participate remotely...

[email-masked]

-- 
Cyrus Daboo

Date: Tue, 11 Jan 2005 11:49:49 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: [email-masked]
Subject: Re: RIGHTS=kxet, CONDSTORE, implementation
Sender: [email-masked]

On Mon, 10 Jan 2005, Dave Cridland wrote:

> Disabling some options and actions, yes. Is the result of MYRIGHTS supposed 
> to be used for anything else? :-)
>
> As for the emulation, it's really just so I can ask the library if I have "k" 
> on a mailbox, rather than having to ask it whether RIGHTS and ACL is 
> supported first. I suppose I'd have done better if I'd tried to provide a 
> bitfield, or a slew of methods called can_delete, but the API I wrote happens 
> to use strings of rights.
[snip]
> As in not bothering to send a DELETE if the client is in a position to know 
> that the command will fail.

Yes, I agree, but this is the very problem in ACL that 2086bis is trying 
to fix.

> But for the DELETE+ACL case, I think I'll relax the rules and assume it's 
> always granted unless RIGHTS is available and says not. The other new rights 
> are easy to handle.

That makes sense.  I agree that for the most part, you can predict what is 
going to happen somewhat reliably.

> Similar, although more conservative, assumptions can be made if the server 
> doesn't support ACL at all - I can assume the 'r' right is granted if a 
> SELECT suceeds at all, obviously, but I can also make a reasonable guess 
> about the 'w' right based on READ-WRITE/READ-ONLY response codes and FLAGS 
> responses.

Yes. READ-WRITE/READ-ONLY isn't really good enough to fully describe the 
situation (espiecailly on a server that splits s and w).

>> I don't think SELECT is overloaded -- this behavior is necessary for 
>> non-LISTEXT servers.  If SELECT is telling the server to open a mailbox, 
>> in the MAILBOX-REFERRALS case the server fails, and sends back a NO, with 
>> an extra status response of where to try again.  I don't think this is 
>> overloaded (unless you are explicitly trying to use SELECT to preemptively 
>> cache locations of mailboxes, which is probably not a good idea anyway).
>
> It depends on whether, when you ask the client to open "foo", you want it to 
> try a SELECT foo, fail, catch the error, and switch to another IMAP server, 
> or whether you want the client to simply open a connection immediately to 
> another server.
>
> I'd rather not wait for the additional round-trip, if at all possible. If by 
> "not a good idea", you mean that in some cases the REFERRAL will be dynamic, 
> then that shouldn't be a problem - so is the mailbox listing I could 
> hypothetically obtain the data from, and it could always be made optional 
> data anyway, forcing the client to issue SELECT or whatever.

On a non-listext server, you can't skip the round trip though, the only 
way to find out where the mailbox is is to issue the select (well, ok, 
any command that generates a referral).  This is also 
good, as mailbox location can change (though it is true they generally 
don't), and just relying on a listext response you saw a week ago 
probably isn't good either.

> I'm far more likely to use another command where I know the mailbox is 
> remote, in fact, like STATUS, and of course I *will* know the mailbox is 
> remote in the LISTEXT case. I'd rather not needlessly unselect the current 
> mailbox.

Sure.

-Rob

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

From: Dave Cridland <[email-masked]>
To: Rob Siemborski <[email-masked]>
Cc: <[email-masked]>
Subject: Re: RIGHTS=kxet, CONDSTORE, implementation
Date: Mon, 10 Jan 2005 20:13:36 +0000
Sender: [email-masked]

On Mon Jan 10 16:53:30 2005, Rob Siemborski wrote:
> On Mon, 10 Jan 2005, Dave Cridland wrote:
>> I've been gradually implementing ACL support, and I've attempted to do so by emulating the 'kxet' rights where not supported. (This means anywhere, since I don't have access to a server implementation supporting RIGHTS). I'm making the rash assumption that this is a sane way of writing a RFC2086upd client. (I've not yet made it emulate rights based on the READ-ONLY/READ-WRITE response code where no ACL support at all is available, but I will.)
> 
> What meaning does it have to "emulate" RIGHTS support on the client side? Does this mean you are trying to disable options based on what rights you see?  This won't work on most ACL servers because of....
> 

Disabling some options and actions, yes. Is the result of MYRIGHTS supposed to be used for anything else? :-)

As for the emulation, it's really just so I can ask the library if I have "k" on a mailbox, rather than having to ask it whether RIGHTS and ACL is supported first. I suppose I'd have done better if I'd tried to provide a bitfield, or a slew of methods called can_delete, but the API I wrote happens to use strings of rights.

> 
>> I've found that trying to emulate the 'x' right is particularly tricky, since I can only assume:
>> 
>> 'd' => 'et'
>> 'c' => 'k'
>> 
>> So I'm currently assuming the 'x' right is always granted where 'c' or 'd' is granted. (Obviously the client copes with the case where the DELETE fails anyway.)
> 
> This is really a problem with the existing spec and current implementations if you're using this the way I expect..
> 

As in not bothering to send a DELETE if the client is in a position to know that the command will fail.

> 
>> Given that, in the case where we simply don't know whether a right is supported or not, we want to assume it's granted, is this a reasonable assumption, or should I assume the 'x' right is *always* granted (which is effectively what existing clients do anyway)?
> 
> Yes, you should assume it is granted, and let the server tell you it isn't.  Otherwise you're going to have a very fustrated user when the client isn't letting them do (foo) but the server will.  (This is why UNIX apps that look at the unix mode bits directly to see if they can save a file are broken -- they should test if the filesystem actually permits access, not if the mode bits are set).
> 

I agree with the UNIX thing, since the mode bits don't describe everything, and the cost of just doing it and coping with the error condition is slight. (At least, assuming that the error condition is the exception rather than the rule.) Moreover, if the permissions change between a check and actual usage, then there's a potential security hole.

However, if a network client is in a position to know that a command will fail, then it shouldn't be sending those bits across the wire, that's just wasted bandwidth, and a round-trip as well. If the server is explicitly stating that the client may not perform some action, but will actually allow it, then I don't think it's the client that's broken. That's rather like supporting an extension but not advertising it, then saying clients should just issue the command anyway. (The situation where the server says something is possible but turns out to refuse to perform the action is, on the other hand, allowable.)

But for the DELETE+ACL case, I think I'll relax the rules and assume it's always granted unless RIGHTS is available and says not. The other new rights are easy to handle.

> 
>> Incidentally, I've not yet thought of any other problems with a RIGHTS aware client talking to a plain ACL server, but I've not yet done ACL editing, where I suspect that the 'x' right will rear its ugly head again.
> 
> There shouldn't be.  Its implicit that a RIGHTS client supports ACL servers.
> 

I agree that there shouldn't be. I'll be happier that there isn't when I've got a working implementation in front of me to demonstrate it as a fact.

> 
>> Nothing I've found so far appears to be a showstopper, but it might be beneficial to client authors to have some idea of handling legacy support for older servers (ie, all current ones) covered in the RFC.
> 
> If the server doesn't advertise RIGHTS, the client shouldn't assume that it does or try to make it fit somehow.  Just treat it as an ACL server as if you knew nothing else.
> 

I certainly don't assume that if ACL is supported, then RIGHTS is. I do, however, assume that if ACL but not RIGHTS is supported, then I have the 'k' right if the server tells my client I have the 'c' right, for instance.

Similar, although more conservative, assumptions can be made if the server doesn't support ACL at all - I can assume the 'r' right is granted if a SELECT suceeds at all, obviously, but I can also make a reasonable guess about the 'w' right based on READ-WRITE/READ-ONLY response codes and FLAGS responses.

> 
>> 3) LISTEXT
>> 
>> I've not yet implemented this, however, I was thinking of implementing this, ACL2, and MAILBOX-REFERRALS at the same time. In particular, I have noticed that LIST (REMOTE) could reasonably provide the REFERRAL URIs in an extended LIST item, in order to save clients from having to SELECT the mailbox to discover it. This SELECT  generates an additional round-trip, of course, and I feel overloads SELECT's meaning as well.
> 
> We discussed this at one point, I don't remember the outcome.
> 

I'll go archive hunting.

> 
> I don't think SELECT is overloaded -- this behavior is necessary for non-LISTEXT servers.  If SELECT is telling the server to open a mailbox, in the MAILBOX-REFERRALS case the server fails, and sends back a NO, with an extra status response of where to try again.  I don't think this is overloaded (unless you are explicitly trying to use SELECT to preemptively cache locations of mailboxes, which is probably not a good idea anyway).
> 

It depends on whether, when you ask the client to open "foo", you want it to try a SELECT foo, fail, catch the error, and switch to another IMAP server, or whether you want the client to simply open a connection immediately to another server.

I'd rather not wait for the additional round-trip, if at all possible. If by "not a good idea", you mean that in some cases the REFERRAL will be dynamic, then that shouldn't be a problem - so is the mailbox listing I could hypothetically obtain the data from, and it could always be made optional data anyway, forcing the client to issue SELECT or whatever.

I'm far more likely to use another command where I know the mailbox is remote, in fact, like STATUS, and of course I *will* know the mailbox is remote in the LISTEXT case. I'd rather not needlessly unselect the current mailbox.

Dave.

Date: Mon, 10 Jan 2005 11:53:30 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: [email-masked]
Subject: Re: RIGHTS=kxet, CONDSTORE, implementation
Sender: [email-masked]

On Mon, 10 Jan 2005, Dave Cridland wrote:

> I've been gradually implementing ACL support, and I've attempted to do so by 
> emulating the 'kxet' rights where not supported. (This means anywhere, since 
> I don't have access to a server implementation supporting RIGHTS). I'm making 
> the rash assumption that this is a sane way of writing a RFC2086upd client. 
> (I've not yet made it emulate rights based on the READ-ONLY/READ-WRITE 
> response code where no ACL support at all is available, but I will.)

What meaning does it have to "emulate" RIGHTS support on the client side? 
Does this mean you are trying to disable options based on what rights you 
see?  This won't work on most ACL servers because of....

> I've found that trying to emulate the 'x' right is particularly tricky, since 
> I can only assume:
>
> 'd' => 'et'
> 'c' => 'k'
>
> So I'm currently assuming the 'x' right is always granted where 'c' or 'd' is 
> granted. (Obviously the client copes with the case where the DELETE fails 
> anyway.)

This is really a problem with the existing spec and current 
implementations if you're using this the way I expect..

> Given that, in the case where we simply don't know whether a right is 
> supported or not, we want to assume it's granted, is this a reasonable 
> assumption, or should I assume the 'x' right is *always* granted (which is 
> effectively what existing clients do anyway)?

Yes, you should assume it is granted, and let the server tell you it 
isn't.  Otherwise you're going to have a very fustrated user when the 
client isn't letting them do (foo) but the server will.  (This is why UNIX 
apps that look at the unix mode bits directly to see if they can save a 
file are broken -- they should test if the filesystem actually permits 
access, not if the mode bits are set).

> Incidentally, I've not yet thought of any other problems with a RIGHTS aware 
> client talking to a plain ACL server, but I've not yet done ACL editing, 
> where I suspect that the 'x' right will rear its ugly head again.

There shouldn't be.  Its implicit that a RIGHTS client supports ACL 
servers.

> Nothing I've found so far appears to be a showstopper, but it might be 
> beneficial to client authors to have some idea of handling legacy support for 
> older servers (ie, all current ones) covered in the RFC.

If the server doesn't advertise RIGHTS, the client shouldn't assume that 
it does or try to make it fit somehow.  Just treat it as an ACL server as 
if you knew nothing else.

> 3) LISTEXT
>
> I've not yet implemented this, however, I was thinking of implementing this, 
> ACL2, and MAILBOX-REFERRALS at the same time. In particular, I have noticed 
> that LIST (REMOTE) could reasonably provide the REFERRAL URIs in an extended 
> LIST item, in order to save clients from having to SELECT the mailbox to 
> discover it. This SELECT  generates an additional round-trip, of course, and 
> I feel overloads SELECT's meaning as well.

We discussed this at one point, I don't remember the outcome.

I don't think SELECT is overloaded -- this behavior is necessary for 
non-LISTEXT servers.  If SELECT is telling the server to open a mailbox, 
in the MAILBOX-REFERRALS case the server fails, and sends back a NO, with 
an extra status response of where to try again.  I don't think this is 
overloaded (unless you are explicitly trying to use SELECT to preemptively 
cache locations of mailboxes, which is probably not a good idea anyway).

-Rob

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

Date: Mon, 10 Jan 2005 11:27:25 -0500
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
CC: Lisa Dusseault <[email-masked]>
Subject: Re: WG last call for IMAP ACL small-scope changes (RFC2086bis)
Sender: [email-masked]

Lisa Dusseault wrote:

>
> This is the end of the last call period for 
> draft-ietf-imapext-2086upd-02.txt.  I didn't see any issues that I 
> considered required a "reset", so the next step is for Alexey to 
> produce another draft with the changes resulting from last call, and 
> we will submit that to the IESG.
>
> Alexey, when you do this please post your changes from 02 to 03 on the 
> list.

My laptop has died recently, so I don't have the latest copy. For now, 
WG members have to check the mailing list archive.

Dave and Ken have raised a new issue with LISTRIGHTS command and virtual 
rights. The current text as written suggests that if any member right is 
tied to another right, which is not a member of the same virtual right, 
or if member rights are not tied together, then the server is not 
allowed to list the virtual right in a LISTRIGHTS response. For example, 
if "t" is tied to "sw", the server can't return "d". This will confuse 
legacy clients.

There are several alternatives how to deal with the issue:
1). Live with the current limitation and do nothing.

2). In the described case the server should list the virtual right as 
tied to a union of all the rights the individual members are tied to. If 
member rights are not tied, the virtual right is listed by itself. For 
example, a c=>kx server might return:

* LISTRIGHTS INBOX someone "" "tws" "ei" "lr" "p" "k" "x" "a" "c" "dwsi"

Where the draft currently says:
* LISTRIGHTS INBOX someone "" "tws" "ei" "lr" "p" "k" "x" "a"

In this case the client must ignore all strings containing virtual rights.

3). If member rights are not tied together, the virtual right is listed 
by itself. For the example listed above:

* LISTRIGHTS INBOX someone "" "tws" "ei" "lr" "p" "k" "x" "a" "c" "d"

4). Dave has suggested to add a new optional parameter to LISTRIGHTS to 
signal that the client is a new client and it understands new rights. 
When the parameter is specified, the server will not return virtual rights.
=========
I don't like the proposal #1, as I think it might confuse clients: it 
might make clients believe that the "w" right is tied to the "i" right, 
when it is not.
#4 seems like the cleanest solution, however I am concerned that we are 
spending too much effort on fixing ACL, instead of finishing ACL2.

Comments?

Alexey

From: Dave Cridland <[email-masked]>
To: <[email-masked]>
Subject: RIGHTS=kxet, CONDSTORE, implementation
Date: Mon, 10 Jan 2005 14:16:46 +0000
Sender: [email-masked]

Hiya folks,

I've been on a client-side implementation frenzy, and thought I'd 
share my experiences. I've no access to any server implementation of 
any of these - an account on such a server would be greatly 
appreciated. In particular, I'd like CONDSTORE, ANNOTATE, and LISTEXT 
- the RIGHTS stuff, while interesting, is more interesting in as much 
as how to cope without it.

My strategy, incidentally, is to emulate unsupported extensions 
wherever possible.

The client is written in Python, using the wxPython GUI toolkit, and 
should run on Windows, UNIX, and Mac OS X. It does require an account 
on a reasonably full ACAP server implementation, but this does give 
it full roaming and kiosk-mode ability. I'm quite happy to provide 
the source under GPL, and/or an ACAP account.

1) RIGHTS

I've been gradually implementing ACL support, and I've attempted to 
do so by emulating the 'kxet' rights where not supported. (This means 
anywhere, since I don't have access to a server implementation 
supporting RIGHTS). I'm making the rash assumption that this is a 
sane way of writing a RFC2086upd client. (I've not yet made it 
emulate rights based on the READ-ONLY/READ-WRITE response code where 
no ACL support at all is available, but I will.)

I've found that trying to emulate the 'x' right is particularly 
tricky, since I can only assume:

'd' => 'et'
'c' => 'k'

So I'm currently assuming the 'x' right is always granted where 'c' 
or 'd' is granted. (Obviously the client copes with the case where 
the DELETE fails anyway.)

Given that, in the case where we simply don't know whether a right is 
supported or not, we want to assume it's granted, is this a 
reasonable assumption, or should I assume the 'x' right is *always* 
granted (which is effectively what existing clients do anyway)?

Incidentally, I've not yet thought of any other problems with a 
RIGHTS aware client talking to a plain ACL server, but I've not yet 
done ACL editing, where I suspect that the 'x' right will rear its 
ugly head again.

Nothing I've found so far appears to be a showstopper, but it might 
be beneficial to client authors to have some idea of handling legacy 
support for older servers (ie, all current ones) covered in the RFC.

2) CONDSTORE

This seems remarkably straightforward to implement, although again 
I've no real implementation to test against. I do, however, forsee 
some problems when dealing with ANNOTATE in addition, since I'm a 
little unclear on whether the sequence:

C1: a01 FETCH 1 (FLAGS ANNOTATION ("/comment" "value.priv"))
S1: * 1 FETCH (MODSEQ (1) FLAGS (\Seen) ANNOTATION ("/comment" 
("value.priv" "My comment")))
S1: a01 OK
C2: a02 STORE 1 +FLAGS (\Answered)
S2: * 1 FETCH (MODSEQ (2) FLAGS (\Seen \Answered))
S2: a02 OK
C1: a03 FETCH 1 (FLAGS ANNOTATION ("/comment" "value.priv")) 
(CHANGEDSINCE 1)
S1: * FETCH ...
S1: a03 OK

... should return the comment (which is unchanged) or just the flags 
(which is changed).

My reading of 3.3.1 suggests that the comment will be returned as 
well, even though it hasn't changed, because CHANGEDSINCE affects 
message selection, rather than metadata items returned.

Changing this, such that CHANGEDSINCE simply suppressed items that 
haven't changed (excepting UID) would make more sense to me. I can of 
course do this by issuing multiple pipelined fetches, one for every 
item, in effect, which I have to do for items I don't have cached at 
all. (Currently, in fact, I re-fetch the FLAGS unconditionally if I'm 
fetching anything else, since the additional cost of the data 
returned is less than the cost of asking for it seperately, but this 
changes with ANNOTATE).

My second issue is that an extended EXPUNGE would be useful, allowing 
me to "EXPUNGE (UNCHANGEDSINCE 1)" to permanently remove all messages 
flagged as \Deleted which haven't been altered [presumably] without 
my knowledge. Similarly, an extended UID EXPUNGE would be useful, 
too. Given that EXPUNGing the wrong messages is irreparable damage, 
that seems a sensible addition if it can be implemented, which I 
assume it can be with the same effort as FETCH (CHANGEDSINCE ...).

Finally, I'm not sure how good 64-bit arithmetic is under some 
environments - I'm actually developing under Python on a 64-bit 
system, which is probably a recipe for non-portability when I forget 
to use long() rather than int(), but it has the 64-bit support, at 
least, and most C and C++ compilers support some 64-bit unsigned 
integer, but I'm not so sure about Perl, Java, etc. I'd not object to 
the MODSEQ being a string, since this is easily compared, and has 
precedence in ACAP (with the "modtime" attribute).

3) LISTEXT

I've not yet implemented this, however, I was thinking of 
implementing this, ACL2, and MAILBOX-REFERRALS at the same time. In 
particular, I have noticed that LIST (REMOTE) could reasonably 
provide the REFERRAL URIs in an extended LIST item, in order to save 
clients from having to SELECT the mailbox to discover it. This SELECT 
  generates an additional round-trip, of course, and I feel overloads 
SELECT's meaning as well.

In addition, this renders the \Remote mailbox flag redundant, of 
course.

Dave.

Cc: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: WG last call for IMAP ACL small-scope changes (RFC2086bis)
Date: Tue, 4 Jan 2005 10:49:03 -0800
To: Lisa Dusseault <[email-masked]>
Sender: [email-masked]

This is the end of the last call period for 
draft-ietf-imapext-2086upd-02.txt.  I didn't see any issues that I 
considered required a "reset", so the next step is for Alexey to 
produce another draft with the changes resulting from last call, and we 
will submit that to the IESG.

Alexey, when you do this please post your changes from 02 to 03 on the 
list.

Thanks!
Lisa

On Dec 8, 2004, at 4:28 PM, Lisa Dusseault wrote:

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

Cc: [email-masked], IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: [lemonade] Re: Planning for meeting in Minneapolis
Date: Mon, 31 Jan 2005 17:34:45 -0800
To: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

So, does this mean that we don't need to yank CondStore out of the RFC 
queue?

thanks,
Lisa

On Jan 31, 2005, at 10:44 AM, Alexey Melnikov wrote:

> Lisa Dusseault wrote:
>
>> Alexey needs to propose what changes to make to CondStore, as a 
>> concrete written proposal to the list.
>
> I've just submitted a new draft that describes how CONDSTORE 
> modification sequences can be used to track expunged messages. Before 
> it is announced, people can find it at:
> http://ietf.webdav.org/imapext/draft-melnikov-imap-expunged-00.txt
>
> I will welcome all suggestions, especially on issues marked with <<>> 
> in the document.
>
> I can rework RECONNECT to reference the new document, if people feel 
> it is a good idea.
>
> Alexey
>
>
> _______________________________________________
> lemonade mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/lemonade

Subject: expunged draft
From: Timo Sirainen <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>, [email-masked]
Date: Mon, 31 Jan 2005 22:51:33 +0200
Sender: [email-masked]

--=-GKQMz1/DmeuHdswXxMKD
Content-Type: text/plain; charset=iso-8859-7
Content-Transfer-Encoding: quoted-printable

On Mon, 2005-01-31 at 18:44 +0000, Alexey Melnikov wrote:
> I've just submitted a new draft that describes how CONDSTORE=20
> modification sequences can be used to track expunged messages. Before it=20
> is announced, people can find it at:
> http://ietf.webdav.org/imapext/draft-melnikov-imap-expunged-00.txt
>=20
> I will welcome all suggestions, especially on issues marked with <<>> in=20
> the document.

It shows that HIGHESTMODSEQ update is sent after EXPUNGE command. What
about when other session did the EXPUNGE and we're seeing untagged
EXPUNGEs? Maybe always send it after untagged expunges (and don't
mention EXPUNGE command at all)?

Servers supporting UNSELECT should most likely also send HIGHESTMODSEQ
just as with CLOSE, but this isn't mentioned. And what about with
SELECT? Maybe just point out more generally that "when using a command
which closes the mailbox, send HIGHESTMODSEQ". Perhaps LOGOUT should do
that too?

   <<What if the server can=A2t remember some expunged UIDs, for example
   the provided mod-sequence is too old? Can the server just return
   all UIDs not in the UID set? This can generate additional traffic,
   but should be Ok otherwise.>>

Yes, I think so.

In 3.4 EXPUNGED Response it seems rather useless trying to rewrite what
RFC3501 says about EXPUNGEs. Just point out that it works exactly as
normal untagged EXPUNGE? It would be really bad if they accidentally got
different rules.

Maybe rename the EXPUNGED to UIDEXPUNGE or similar to make it more clear
that it's sending UIDs and not sequences?

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

--=-GKQMz1/DmeuHdswXxMKD--

Date: Mon, 31 Jan 2005 15:42:46 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Cyrus Daboo <[email-masked]>
CC: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: List of WGLC changes to 2086upd-02
Sender: [email-masked]

Cyrus Daboo wrote:

> Hi Ken,
> 
> --On January 31, 2005 2:53:09 PM -0500 Ken Murchison <[email-masked]> 
> wrote:
> 
>>> I've changed the text to require the server to send the virtual "d"/"c"
>>> right in MYRIGHTS/ACL responses when any of the member rights is 
>>> granted.
>>> The 02 text required that all member rights must be granted, before the
>>> virtual right can be returned.
>>
>>
>> What was the rationale for this change?  If all that is set on a mailbox
>> is 'x', reporting 'd' is incorrect.  This will make the client think that
>> it can delete and expunge messages, but it can't.  The only way for the
>> client to get around this is to "reset" the already set 'd' right, which
>> seems counter-intuitive to me.
>>
>> I think its best to keep things the way that you had them.  This way the
>> client will *know* that it can't delete and expunge messages (and also
>> incorrectly assume that it can't DELETE the mailbox, but this is the
>> lesser of two evils IMO) and try to set the 'd' right first.
>>
> 
> I was under the impression that the virtual rights would only be set 
> when ALL the member rights were on, NOT when any member right was on. At 
> least that is what I was trying to say during the interim meeting.
> 
> Here is my rationale (which is based purely on my client 
> implementation): right now the client will disable the 'Delete Message' 
> and 'Expunge Mailbox' UI elements if the 'd' right is set. If a 2086bis 
> server were to report 'd' when 'x' was set and 't' was not set, then the 
> user would be unable to delete messages because the UI was locked out, 
> even though that action is allowed by the server. I would much rather 
> not have 'd' come back in that case, so that both UI items were enabled, 
> but the 'Delete Message' one would result in an IMAP NO response with 
> appropriate error handling in the client. At some point the client can 
> be upgraded to understand the new ACL bits and this will no longer be an 
> issue.

OK, so you'd rather get false positives via MYRIGHTS/ACL rather than 
false negatives.  The logic on the server it trivial either way, and 
since you're the client author and have to deal with this, I'll defer to 
you.  Its too bad we don't have something like a NEEDRIGHT response code 
which can tell the 2086 client which right is required for the failed 
command to succeed.

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

Date: Mon, 31 Jan 2005 15:13:40 -0500
From: Cyrus Daboo <[email-masked]>
To: Ken Murchison <[email-masked]>, Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: List of WGLC changes to 2086upd-02
Sender: [email-masked]

Hi Ken,

--On January 31, 2005 2:53:09 PM -0500 Ken Murchison <[email-masked]> wrote:

>> I've changed the text to require the server to send the virtual "d"/"c"
>> right in MYRIGHTS/ACL responses when any of the member rights is granted.
>> The 02 text required that all member rights must be granted, before the
>> virtual right can be returned.
>
> What was the rationale for this change?  If all that is set on a mailbox
> is 'x', reporting 'd' is incorrect.  This will make the client think that
> it can delete and expunge messages, but it can't.  The only way for the
> client to get around this is to "reset" the already set 'd' right, which
> seems counter-intuitive to me.
>
> I think its best to keep things the way that you had them.  This way the
> client will *know* that it can't delete and expunge messages (and also
> incorrectly assume that it can't DELETE the mailbox, but this is the
> lesser of two evils IMO) and try to set the 'd' right first.
>

I was under the impression that the virtual rights would only be set when 
ALL the member rights were on, NOT when any member right was on. At least 
that is what I was trying to say during the interim meeting.

Here is my rationale (which is based purely on my client implementation): 
right now the client will disable the 'Delete Message' and 'Expunge 
Mailbox' UI elements if the 'd' right is set. If a 2086bis server were to 
report 'd' when 'x' was set and 't' was not set, then the user would be 
unable to delete messages because the UI was locked out, even though that 
action is allowed by the server. I would much rather not have 'd' come back 
in that case, so that both UI items were enabled, but the 'Delete Message' 
one would result in an IMAP NO response with appropriate error handling in 
the client. At some point the client can be upgraded to understand the new 
ACL bits and this will no longer be an issue.

-- 
Cyrus Daboo

Date: Mon, 31 Jan 2005 14:53:09 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Alexey Melnikov <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: List of WGLC changes to 2086upd-02
Sender: [email-masked]

Alexey Melnikov wrote:

> 
> Below I've listed all changes caused by the WGLC comments (excluding 
> fixing few typos, superfluous commas and and new section 3.1.1 that I 
> will describe separately):

> 
> 11). In Appendix B. ("Compatibility with RFC 2086"):
> 
> I've changed the text to require the server to send the virtual "d"/"c" 
> right in MYRIGHTS/ACL responses when any of the member rights is granted.
> The 02 text required that all member rights must be granted, before the 
> virtual right can be returned.

What was the rationale for this change?  If all that is set on a mailbox 
is 'x', reporting 'd' is incorrect.  This will make the client think 
that it can delete and expunge messages, but it can't.  The only way for 
the client to get around this is to "reset" the already set 'd' right, 
which seems counter-intuitive to me.

I think its best to keep things the way that you had them.  This way the 
client will *know* that it can't delete and expunge messages (and also 
incorrectly assume that it can't DELETE the mailbox, but this is the 
lesser of two evils IMO) and try to set the 'd' right first.

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

Date: Mon, 31 Jan 2005 11:44:51 -0800
From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked], Barry Leiba <[email-masked]>, Dave Cridland <[email-masked]>
Subject: Re: Planning for meeting in Minneapolis
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Mon, 31 Jan 2005, Arnt Gulbrandsen wrote:
>> Note that SEARCH, SORT, and THREAD have the possibility of an extension for 
>> a "standing SEARCH" functionality, in which you get a unsolicited SEARCH 
>> when the mailbox changes.
> Not really. Suppose the client has issued a new SEARCH command 0.000000001 
> seconds before receiving the unsolicited SEARCH response. That problem can be 
> worked around, of course, but the workarounds I can imagine aren't pretty.

I didn't say that there weren't issues that would have to be addressed 
before something like this could be done.  That is, in fact, one of the 
big reasons why it hasn't been done yet.

Nevertheless, I was referring to an architectural aspect of IMAP; and in 
that, "any response is possible at any time."  Software which expects a 
particular response from a particular command is broken.  Just the other 
day, I had to deal with a client author who insisted that UW imapd was 
broken because it can issue untagged OK and untagged NO in the course of 
doing a SEARCH.

-- Mark --

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

Date: Mon, 31 Jan 2005 18:46:24 +0000
From: Alexey Melnikov <[email-masked]>
To: "Stephane H. Maes" <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Notes from today's meeting
Sender: [email-masked]

Lisa Dusseault wrote:

> By the way, I'd like to thank Oracle, and Stephane Maes, for the 
> facilities used at the IMAPEXT interim meeting.  The location was 
> pleasant for all and convenient (well, speaking for myself, at least ).

And the food was great too :-).

Date: Mon, 31 Jan 2005 18:44:48 +0000
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
CC: [email-masked]
Subject: Re: Planning for meeting in Minneapolis
Sender: [email-masked]

Lisa Dusseault wrote:

> Alexey needs to propose what changes to make to CondStore, as a 
> concrete written proposal to the list.

I've just submitted a new draft that describes how CONDSTORE 
modification sequences can be used to track expunged messages. Before it 
is announced, people can find it at:
http://ietf.webdav.org/imapext/draft-melnikov-imap-expunged-00.txt

I will welcome all suggestions, especially on issues marked with <<>> in 
the document.

I can rework RECONNECT to reference the new document, if people feel it 
is a good idea.

Alexey

Date: Mon, 31 Jan 2005 19:32:15 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Planning for meeting in Minneapolis
Cc: Barry Leiba <[email-masked]>, Mark Crispin <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Mark Crispin writes:
> Note that SEARCH, SORT, and THREAD have the possibility of an 
> extension for a "standing SEARCH" functionality, in which you get a 
> unsolicited SEARCH when the mailbox changes.

Not really. Suppose the client has issued a new SEARCH command 
0.000000001 seconds before receiving the unsolicited SEARCH response. 
That problem can be worked around, of course, but the workarounds I can 
imagine aren't pretty.

> Any new response which can not be handled in isolation is 
> fundamentally broken.

I agree with this. Such responses just don't fit IMAP.

Arnt

content-class: urn:content-classes:message
Subject: RE: Planning for meeting in Minneapolis
Date: Mon, 31 Jan 2005 10:53:35 -0600
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext Mark Crispin
> Sent: Monday, January 31, 2005 11:33 AM
...
> On Mon, 31 Jan 2005, Dave Cridland wrote:
> > a) The CHILDINFO extension blob proposal was arrived at 
> partly because 
> > clients are often deliberately programmed such that 
> commands are used merely 
> > to elicit reponses, and the responses are often handled in 
> isolation, without 
> > actually knowing the command in progress.
> > Feel free to call this a case of bad programming, it's 
> nevertheless quite 
> > common, as far as I'm aware - I do it myself.
> 
> It's *not* bad programming.  It's the fundamental design of IMAP.

This was my understanding as well. I'm glad you confirmed this.

This is the fundamental difference between a truly unsolicited 
response as opposed to a simple untagged response. I find this
to be an IMAP strength.

Mike

Date: Mon, 31 Jan 2005 08:33:09 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: Barry Leiba <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Planning for meeting in Minneapolis
Sender: [email-masked]

On Mon, 31 Jan 2005, Dave Cridland wrote:
> a) The CHILDINFO extension blob proposal was arrived at partly because 
> clients are often deliberately programmed such that commands are used merely 
> to elicit reponses, and the responses are often handled in isolation, without 
> actually knowing the command in progress.
> Feel free to call this a case of bad programming, it's nevertheless quite 
> common, as far as I'm aware - I do it myself.

It's *not* bad programming.  It's the fundamental design of IMAP.

Note that SEARCH, SORT, and THREAD have the possibility of an extension 
for a "standing SEARCH" functionality, in which you get a unsolicited 
SEARCH when the mailbox changes.

Any new response which can not be handled in isolation is fundamentally 
broken.

-- Mark --

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

Date: Mon, 31 Jan 2005 16:16:42 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Planning for meeting in Minneapolis
Cc: Barry Leiba <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Dave Cridland writes:
> "New" LIST wouldn't be the first command whose responses cannot be 
> parsed in isolation - SEARCH, SORT, and THREAD all require knowledge 
> of the command issued - but I'm concerned that "old" LIST didn't 
> behave this way, and I suspect that a number of clients will require 
> significant rewriting to take advantage of selection options (other 
> than REMOTE).

If that turns out to be the case, and the specification remains hard to 
understand for people of such modest intelligence as myself, then I 
wouldn't be surprised if the LIST command in the base specification has 
a long life in front of it.

Arnt

From: Dave Cridland <[email-masked]>
To: Barry Leiba <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Planning for meeting in Minneapolis
Date: Mon, 31 Jan 2005 10:44:07 +0000
Sender: [email-masked]

On Fri Jan 28 23:28:31 2005, Barry Leiba wrote:
> > If the client pipelines requests that result in ambiguous
> > responses, well, "Doctor it hurts when I do _this_...".
> 
> Or put more IETF-ly, clients MUST NOT send simultaneous LIST commands,
> the responses from which they would not be able to sort out
> unambiguously.

My only niggles about this are:

a) The CHILDINFO extension blob proposal was arrived at partly because clients are often deliberately programmed such that commands are used merely to elicit reponses, and the responses are often handled in isolation, without actually knowing the command in progress.

Feel free to call this a case of bad programming, it's nevertheless quite common, as far as I'm aware - I do it myself. Arnt Gulbrandsen raised the issue, as well as (I believe) others. [Yes, I know I came up with the beginnings of CHILDINFO, but I didn't come up with the reason, and I'm not wed to the syntax.]

"New" LIST wouldn't be the first command whose responses cannot be parsed in isolation - SEARCH, SORT, and THREAD all require knowledge of the command issued - but I'm concerned that "old" LIST didn't behave this way, and I suspect that a number of clients will require significant rewriting to take advantage of selection options (other than REMOTE).

So I feel it's more "Doctor, it's suddenly started hurting when I do _this_". I admit it's not as funny phrased that way.

b) It precludes sending unsolicited LIST responses in some extension or other. Some extensions have been proposed which do this, I think, mostly in the LEMONADE area. It's quite useful for, for instance, notifications about creation and renaming of mailboxes - otherwise a client has to pick a refresh time for the LIST, which may be expensive in terms of bandwidth.

I feel we might be in the process of locking doors before we've had a chance to look inside.

Dave.

Date: Fri, 28 Jan 2005 18:28:31 -0500
From: Barry Leiba <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: Planning for meeting in Minneapolis
Sender: [email-masked]

> These were discussed fairly completely during the meeting and we came
> to consensus that
> -) MATCHPARENT would stay; not much point in making LIST extendable if
>    things that can reasonably be options are instead implicitly
>    triggered

Yes, but we decided to call it "recursivematch".

> -) \placeholder and \hassubmailboxes will be replaced by a single flag
>    named something like \hasmatchingchild.  Whether the returned name
>    itself matches can be trivially deduced from the other returned
>    flags.

Correct, and "\hasmatchingchildren" was what we were calling it.  I'm
open to other names, but I think this name makes its purpose clear
(where "hassubmailboxes" did not).

> If the client pipelines requests that result in ambiguous
> responses, well, "Doctor it hurts when I do _this_...".

Or put more IETF-ly, clients MUST NOT send simultaneous LIST commands,
the responses from which they would not be able to sort out
unambiguously.

> -) keeping the CHILDREN option and its behavior separate from
>    MATCHPARENT was deemed to be clearer than merging them.  CHILDREN
>    would be changed to require exact responses:

In other words, correct implementation of CHILDREN *will* be required
by the LISTEXT spec, but the "\haschildren" and "\hasnochildren" flags
will only be returned if they're asked for.  We DO need the
"\hasnochildren" flag to distinguish the absence of children from the
case where the server decides to send an unsolicited LIST response at
the same time as it's responding to a LIST command.

We've gone back and forth on this one, and I hope we have now decided
it firmly.  The reasoning is that clients that want the has<no>children
help will do the work with a series of commands anyway, and even if
it's not convenient for some server implementations to provide it, it's
still a LOT cheaper for them to do it in the server than for the client
to have to request them separately.

> There was some discussion of requiring LIST to return BAD if
> MATCHPARENT was used with a pattern containing '*', but I'm not sure
> that was dropped later as being too restrictive.

It was dropped.  We decided, after thinking about it, that it's not
*really* a problem.  The consensus at the end was that there need be no
restrictions on when "recursivematch" can be used.

There was the issue of recursion loops, and we decided to allow a
server, probably with a MAY clause, to limit the depth.  We did not
pick a minimum depth that MUST be implemented, so we should pick one
here.

We should have examples in the jabber log, assuming that Rob was able
accurately to enter my scratchings on the white-boards, since I
annoyingly refused to write from left to right.  Should we copy those
examples here, or just point to the jabber logs?

Barry

--
Barry Leiba, Pervasive Computing Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam

From: Philip Guenther <[email-masked]>
To: Lisa Dusseault <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Planning for meeting in Minneapolis 
Date: Fri, 28 Jan 2005 14:33:30 -0800
Sender: [email-masked]

(Resubmitting from my subscribed address... <sigh>)

Lisa Dusseault <[email-masked]> writes:
>Philip owes a write-up that describes how to replace /MatchParent 
>/PlaceHolder in LISTEXT by Jan 28

There were three proposed changes:
-) remove the MATCHPARENT flag and instead trigger the behavior if the
   pattern ends with a '%'; this would have the benefit of making
   extended and unextended LIST behave similarly
-) eliminate \placeholder and \hassubmailbox and instead include a
   CHILDINFO blob when the returned name has a matching submailbox;
   this would make LIST responses unambiguous even when pipelined
-) (if MATCHPARENT stays, then) drop the CHILDREN option as well as the
   restriction on MATCHPARENT that another selection option must be
   present; MATCHPARENT without any other selection options would return
   equivalent info to that which had been returned by the CHILDREN
   option

These were discussed fairly completely during the meeting and we came to
consensus that
-) MATCHPARENT would stay; not much point in making LIST extendable if
   things that can reasonably be options are instead implicitly
   triggered
-) \placeholder and \hassubmailboxes will be replaced by a single flag
   named something like \hasmatchingchild.  Whether the returned name
   itself matches can be trivially deduced from the other returned
   flags.  (E.g., a \placeholder from the SUBSCRIBED selection option
   will instead have the new flag but _won't_ have the \subscribed flag)
   If the client pipelines requests that result in ambiguous responses,
   well, "Doctor it hurts when I do _this_...".  Servers will be banned
   from returning the new flag except in direct response to a client
   request.
-) keeping the CHILDREN option and its behavior separate from
   MATCHPARENT was deemed to be clearer than merging them.  CHILDREN
   would be changed to require exact responses: absence of the
   \haschildren flag in a response that matched a client request with
   the CHILDREN option would mean the name does not have any
   (accessible) submailboxes.

Unclear was whether the MATCHPARENT option should be renamed (again).  A
couple other names were bounced around but I don't recall any that stood
out as obviously clearer.

There was some discussion of requiring LIST to return BAD if
MATCHPARENT was used with a pattern containing '*', but I'm not sure
that was dropped later as being too restrictive.  It would eliminate
some of the weird cases in the MATCHPARENT description, as it would
outlaw the possibility of a mailbox and one of its children being
matched by the same parent.

Philip Guenther

Cc: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: Planning for meeting in Minneapolis 
Date: Fri, 28 Jan 2005 14:27:52 -0800
To: Philip Guenther <[email-masked]>
Sender: [email-masked]

>
> Unclear was whether the MATCHPARENT option should be renamed (again).  
> A
> couple other names were bounced around but I don't recall any that 
> stood
> out as obviously clearer.

Personally I preferred RECURSIVE but I'll be happy to just tally folks' 
votes instead.

Lisa

To: Lisa Dusseault <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Planning for meeting in Minneapolis 
Date: Fri, 28 Jan 2005 14:24:03 -0800
From: Philip Guenther <[email-masked]>
Sender: [email-masked]

Lisa Dusseault <[email-masked]> writes:
>Philip owes a write-up that describes how to replace /MatchParent 
>/PlaceHolder in LISTEXT by Jan 28

There were three proposed changes:
-) remove the MATCHPARENT flag and instead trigger the behavior if the
   pattern ends with a '%'; this would have the benefit of making
   extended and unextended LIST behave similarly
-) eliminate \placeholder and \hassubmailbox and instead include a
   CHILDINFO blob when the returned name has a matching submailbox;
   this would make LIST responses unambiguous even when pipelined
-) (if MATCHPARENT stays, then) drop the CHILDREN option as well as the
   restriction on MATCHPARENT that another selection option must be
   present; MATCHPARENT without any other selection options would return
   equivalent info to that which had been returned by the CHILDREN
   option

These were discussed fairly completely during the meeting and we came to
consensus that
-) MATCHPARENT would stay; not much point in making LIST extendable if
   things that can reasonably be options are instead implicitly
   triggered
-) \placeholder and \hassubmailboxes will be replaced by a single flag
   named something like \hasmatchingchild.  Whether the returned name
   itself matches can be trivially deduced from the other returned
   flags.  (E.g., a \placeholder from the SUBSCRIBED selection option
   will instead have the new flag but _won't_ have the \subscribed flag)
   If the client pipelines requests that result in ambiguous responses,
   well, "Doctor it hurts when I do _this_...".  Servers will be banned
   from returning the new flag except in direct response to a client
   request.
-) keeping the CHILDREN option and its behavior separate from
   MATCHPARENT was deemed to be clearer than merging them.  CHILDREN
   would be changed to require exact responses: absence of the
   \haschildren flag in a response that matched a client request with
   the CHILDREN option would mean the name does not have any
   (accessible) submailboxes.

Unclear was whether the MATCHPARENT option should be renamed (again).  A
couple other names were bounced around but I don't recall any that stood
out as obviously clearer.

There was some discussion of requiring LIST to return BAD if
MATCHPARENT was used with a pattern containing '*', but I'm not sure
that was dropped later as being too restrictive.  It would eliminate
some of the weird cases in the MATCHPARENT description, as it would
outlaw the possibility of a mailbox and one of its children being
matched by the same parent.

Philip Guenther

Date: Thu, 27 Jan 2005 22:51:18 +0000
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: List of WGLC changes to 2086upd-02
Sender: [email-masked]

Below I've listed all changes caused by the WGLC comments (excluding 
fixing few typos, superfluous commas and and new section 3.1.1 that I 
will describe separately):

1). Added new section 3.2 "Rights defined in RFC 2086". It reads:

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

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

2). In section 3:

changed:

    A DELETEACL of "fred" simply deletes the identifier "fred"
    from the ACL; it does not affect any rights that the user "fred"
    may get from another entry in the ACL.

to:

    A DELETEACL of "fred" simply deletes the identifier "fred"
    from the ACL; it does not affect any rights that the user "fred"
    may get from another entry in the ACL, in particular it doesn't affect
    rights granted to the identifier "-fred".

3). Added DELETEACL example in section 4.2:

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

4). Fixed examples in section 4.3 (GETACL command):

It should be:
               S: * ACL INBOX Fred rwipsldexta
instead of
               S: * ACL INBOX Fred rwipslda

5). Examples in section 4.4 (LISTRIGHTS command) also must be fixed. The 
final examples depend on our decision on LISTRIGHTS/virtual rights 
resolution.

6). Fixed examples in section 4.5 (MYRIGHTS command):

Should be
               S: * MYRIGHTS INBOX rwiptsldaex
instead of

               S: * MYRIGHTS INBOX rwipslda

7). Added the following text to each of the following sections: 4.6. 
(ACL response), 4.7. (LISTRIGHTS response) and 4.8. (MYRIGHTS response):
 
      Section 3.1.1 details additional server requirements related to 
handling
      of the virtual "d" and "c" rights.

8). In section 5: clarified which rights are required for the DELETE 
command:

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

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

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

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

9). In section 6.1.1:

Added the "l" right for the INBOX in the example and added a pipelined 
version of the example:

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

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

10). In section 8. ("Formal Syntax"):

 Changed the "new_rights" production to only allow for LOWER_ALPHA. 
Draft 02 allowed for digits as well.

11). In Appendix B. ("Compatibility with RFC 2086"):

I've changed the text to require the server to send the virtual "d"/"c" 
right in MYRIGHTS/ACL responses when any of the member rights is granted.
The 02 text required that all member rights must be granted, before the 
virtual right can be returned.

Alexey

Date: Thu, 27 Jan 2005 22:13:19 +0000
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: Last remaining RFC2086bis issue: LISTRIGHTS and virtual rights
Sender: [email-masked]

Alexey Melnikov wrote:

> Alexey Melnikov wrote:
>
>> Dave and Ken have raised a new issue with LISTRIGHTS command and 
>> virtual rights. The current text as written suggests that if any 
>> member right is tied to another right, which is not a member of the 
>> same virtual right, or if member rights are not tied together, then 
>> the server is not allowed to list the virtual right in a LISTRIGHTS 
>> response. For example, if "t" is tied to "sw", the server can't 
>> return "d". This will confuse legacy clients.
>>
>> There are several alternatives how to deal with the issue:
>> 1). Live with the current limitation and do nothing.
>>
[...]

>> 3). If member rights are not tied together, the virtual right is 
>> listed by itself. For the example listed above:
>>
>> * LISTRIGHTS INBOX someone "" "tws" "ei" "lr" "p" "k" "x" "a" "c" "d"
>
> Actually, whether the "d" right is returned here is still an open 
> issue: if the "d" right is not returned, a legacy client might limit 
> functionality available to users.

Never mind, this is just case #1.

> If the "d" right is returned, the server is lying, because the "d" 
> right can't be granted by itself.

Date: Thu, 27 Jan 2005 21:40:00 +0000
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Last remaining RFC2086bis issue: LISTRIGHTS and virtual rights
Sender: [email-masked]

Alexey Melnikov wrote:

> Dave and Ken have raised a new issue with LISTRIGHTS command and 
> virtual rights. The current text as written suggests that if any 
> member right is tied to another right, which is not a member of the 
> same virtual right, or if member rights are not tied together, then 
> the server is not allowed to list the virtual right in a LISTRIGHTS 
> response. For example, if "t" is tied to "sw", the server can't return 
> "d". This will confuse legacy clients.
>
> There are several alternatives how to deal with the issue:
> 1). Live with the current limitation and do nothing.
>
> 2). In the described case the server should list the virtual right as 
> tied to a union of all the rights the individual members are tied to. 
> If member rights are not tied, the virtual right is listed by itself. 
> For example, a c=>kx server might return:
>
> * LISTRIGHTS INBOX someone "" "tws" "ei" "lr" "p" "k" "x" "a" "c" "dwsi"
>
> Where the draft currently says:
> * LISTRIGHTS INBOX someone "" "tws" "ei" "lr" "p" "k" "x" "a"
>
> In this case the client must ignore all strings containing virtual 
> rights.
>
> 3). If member rights are not tied together, the virtual right is 
> listed by itself. For the example listed above:
>
> * LISTRIGHTS INBOX someone "" "tws" "ei" "lr" "p" "k" "x" "a" "c" "d"

Actually, whether the "d" right is returned here is still an open issue: 
if the "d" right is not returned, a legacy client might limit 
functionality available to users. If the "d" right is returned, the 
server is lying, because the "d" right can't be granted by itself.

> 4). Dave has suggested to add a new optional parameter to LISTRIGHTS 
> to signal that the client is a new client and it understands new 
> rights. When the parameter is specified, the server will not return 
> virtual rights.
> =========
> I don't like the proposal #1,

I meant #2, of course.

> as I think it might confuse clients: it might make clients believe 
> that the "w" right is tied to the "i" right, when it is not.
> #4 seems like the cleanest solution, however I am concerned that we 
> are spending too much effort on fixing ACL, instead of finishing ACL2.

After discussion at the interim IETF I've got impression that people 
don't want to go with #4 either.

So basically the WG has to choose between #1 (virtual right is not 
advertised) and #3.

#3 seems to be more permissive, as opposed to #1, which is too 
restrictive, but the server is allowed to fail SETACL for any reason anyway.

So I would prefer #3.

> Comments?

Anyone?

-- 
Alexey Melnikov
__________________________________________
Isode Limited, http://www.isode.com

Cell: +44 7753759732

IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.html

Personal Home Page: http://www.melnikov.ca
__________________________________________

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Planning for meeting in Minneapolis
Date: Wed, 26 Jan 2005 17:19:21 -0800
Sender: [email-masked]

I would like to meet again in Minneapolis.  We make decent progress in 
meetings and maybe this will be our final push.  In a best-case 
scenario we could last call everything but ACL before then and focus on 
ACL in the meeting, but I never count on the best-case scenario :)

Any agenda requests, conflicts to avoid, authors who can't make it 
(Alexey)?  if so let me know ... if not,  start registering and making 
your travel plans.

As a reminder, here are the deliverables from last week's meeting:

Alexey to post all 2086upd changes to list by January 28 (Friday) 
barring further hardware problems.
Alexey also to publish new 2086upd draft to send to IESG.
Randy & Cyrus: New annotate draft promised for January 31, which we 
intend to do WG last-call
Alexey needs to propose what changes to make to CondStore, as a 
concrete written proposal to the list.
Philip owes a write-up that describes how to replace /MatchParent 
/PlaceHolder in LISTEXT by Jan 28

Other tasks not listed as deliverables in the notes:
  - after Philip's write-up and ensuing discussion, we'll surely need 
another LISTEXT draft from Barry and Alexey
  - at some point an updated draft for ACL.

Finally, the deadline for updating Internet-Drafts for Minneapolis is 
listed (http://www.ietf.org/meetings/cutoff_dates_62.html) as February 
21.

Lisa

Date: Mon, 24 Jan 2005 15:58:37 -0500
From: Cyrus Daboo <[email-masked]>
To: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>
cc: "Stephane H. Maes" <[email-masked]>
Subject: Re: Notes from today's meeting
Sender: [email-masked]

Hi Lisa,

--On January 24, 2005 12:17:02 PM -0800 Lisa Dusseault 
<[email-masked]> wrote:

> By the way, I'd like to thank Oracle, and Stephane Maes, for the
> facilities used at the IMAPEXT interim meeting.  The location was
> pleasant for all and convenient (well, speaking for myself, at least ).
>

Thanks also to Pete for allowing me true audio-visual virtual presence at 
the meeting via iChatAV...

-- 
Cyrus Daboo

Cc: "Stephane H. Maes" <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: Notes from today's meeting
Date: Mon, 24 Jan 2005 12:17:02 -0800
To: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

By the way, I'd like to thank Oracle, and Stephane Maes, for the 
facilities used at the IMAPEXT interim meeting.  The location was 
pleasant for all and convenient (well, speaking for myself, at least ).

Lisa

On Jan 20, 2005, at 4:56 PM, Lisa Dusseault wrote:

>
> I've posted the notes from today's meeting:
>
> http://ietf.webdav.org/imapext/notes/Jan2005InterimNotes.txt
>
> Please review and see if there are any corrections, then I will submit 
> for the official IETF record.
>
> Lisa
>

From: Steve Hole <[email-masked]>
Date: Fri, 21 Jan 2005 13:15:16 -0700
To: [email-masked]
Subject: RE: more details on agenda
Cc: [email-masked]
Sender: [email-masked]

On Fri, 21 Jan 2005 10:37:07 -0600 [email-masked] wrote:

> You should read Lisa's follow on mtg minutes. It clarifies the 
> actual discussion regarding CONSTORE much better. The "lack of 
> strong support" referred to sending it back through last call 
> after the factual changes were made.
> 
> There was support for the actual changes Alexey proposed 
> to make to the draft. 

I did read it later and it answered my questions.   All good.

Cheers.
---
Steve Hole
Chief Technical Officer - Electronic Billing and Payment Systems
ACI Worldwide

Email: [email-masked]
Phone: 780 424 4922

Cc: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: more details on agenda
Date: Fri, 21 Jan 2005 08:49:28 -0800
To: Steve Hole <[email-masked]>
Sender: [email-masked]

Sorry, that was my confusing short form.

The Conditional Store draft is already in the RFC Editor's queue, 
having been approved by the WG and by the IESG.  However, it can't 
leave the RFC Editor's queue until all its dependencies have gotten to 
RFC publication status as well, including its dependencies on the 
Annotate draft.  We hope to get Annotate to WG last call Real Soon Now, 
so that should help unblock it.  There is sufficient support for this 
draft that nobody would consider "cancelling" it, especially not at 
this point.

Alexey & Cyrus, however, found a problem in the draft after it was 
approved by the WG and the IESG: some ambiguity or lack of 
specification in what should or shouldn't be updated on expunge 
actions.  So, on the list, Alexey proposed removing the CondStore draft 
from the RFC Editor's queue to fix that problem.  That would require 
the WG to reconsider the draft and do another WG last call, then have 
it go through the IESG approval again.  Initially when Alexey proposed 
this I saw no answer on the list -- I interpreted that as "no support 
for Alexey's suggestion" (although it could also be argued to be no 
opposition).  As it turns out, people in the room yesterday felt some 
reluctant support for Alexey's suggestion although they're not sure 
yet.

Another option we discussed was the possibility of obsoleting the 
CondStore specification, by replacing it with one which fixes the 
problem, essentially immediately -- leaving the one in RFC Editor queue 
to finish on its own without disruption.

So this would be a good thing to discuss further: how bad a problem, 
are there workarounds for clients, what's the set of possible technical 
and process solutions?

Lisa

On Jan 21, 2005, at 7:49 AM, Steve Hole wrote:

> On Thu, 20 Jan 2005 13:34:30 -0800 Lisa Dusseault 
> <[email-masked]>
> wrote:
>
>> CondStore
>>   - Alexey proposed making changes which is generally not advised
>>   - no evidence of strong support
>>   - fix post RFC?
>
> Hmm ...
>
> No evidence of strong support within the group?
>
> We are intensely interested in this particular draft as it provides a
> capability for an IMAP mailbox to act as a queue for automatically
> processed messages -- the moral equivalent of MQSeries done on Internet
> email.
>
> We are already processing SOAP messages this way ... and it works
> wonderfully.
>
> So, I'm very interested in this proceeding.   We have implemented the
> current version of the CONDSTORE draft.   This note seems to indicate 
> that
> there is something wrong with the draft?   I must have missed 
> something.
>
> Cheers.
>
> ---
> Steve Hole
> Chief Technical Officer - Electronic Billing and Payment Systems
> ACI Worldwide
>
> Email: [email-masked]
> Phone: 780 424 4922
>
>

content-class: urn:content-classes:message
Subject: RE: more details on agenda
Date: Fri, 21 Jan 2005 10:37:07 -0600
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

You should read Lisa's follow on mtg minutes. It clarifies the 
actual discussion regarding CONSTORE much better. The "lack of 
strong support" referred to sending it back through last call 
after the factual changes were made.

There was support for the actual changes Alexey proposed 
to make to the draft. 

Mike

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext Steve Hole
> Sent: Friday, January 21, 2005 10:50 AM
> To: Lisa Dusseault
> Cc: IMAP Extensions WG
> Subject: Re: more details on agenda
> 
> 
> 
> On Thu, 20 Jan 2005 13:34:30 -0800 Lisa Dusseault 
> <[email-masked]> 
> wrote:
> 
> > CondStore
> >   - Alexey proposed making changes which is generally not advised
> >   - no evidence of strong support
> >   - fix post RFC?
> 
> Hmm ...
> 
> No evidence of strong support within the group?
> 
> We are intensely interested in this particular draft as it provides a 
> capability for an IMAP mailbox to act as a queue for automatically 
> processed messages -- the moral equivalent of MQSeries done 
> on Internet 
> email.   
> 
> We are already processing SOAP messages this way ... and it works 
> wonderfully.
> 
> So, I'm very interested in this proceeding.   We have implemented the 
> current version of the CONDSTORE draft.   This note seems to 
> indicate that
> there is something wrong with the draft?   I must have missed 
> something.
> 
> Cheers.
> 
> ---
> Steve Hole
> Chief Technical Officer - Electronic Billing and Payment Systems
> ACI Worldwide
> 
> Email: [email-masked]
> Phone: 780 424 4922
> 
> 
> 

From: Steve Hole <[email-masked]>
Date: Fri, 21 Jan 2005 08:49:38 -0700
To: Lisa Dusseault <[email-masked]>
Subject: Re: more details on agenda
Cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Thu, 20 Jan 2005 13:34:30 -0800 Lisa Dusseault <[email-masked]> 
wrote:

> CondStore
>   - Alexey proposed making changes which is generally not advised
>   - no evidence of strong support
>   - fix post RFC?

Hmm ...

No evidence of strong support within the group?

We are intensely interested in this particular draft as it provides a 
capability for an IMAP mailbox to act as a queue for automatically 
processed messages -- the moral equivalent of MQSeries done on Internet 
email.   

We are already processing SOAP messages this way ... and it works 
wonderfully.

So, I'm very interested in this proceeding.   We have implemented the 
current version of the CONDSTORE draft.   This note seems to indicate that
there is something wrong with the draft?   I must have missed something.

Cheers.

---
Steve Hole
Chief Technical Officer - Electronic Billing and Payment Systems
ACI Worldwide

Email: [email-masked]
Phone: 780 424 4922

Date: Fri, 21 Jan 2005 16:19:30 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: more details on agenda
Cc: Scott Hollenbeck <[email-masked]>, Lisa Dusseault <[email-masked]>
Sender: [email-masked]

Lisa Dusseault writes:
> That sounds feasible to me; I think that means we do a WG last call on 
> i18n soonish, because then we'll be all set for it to go to IESG as 
> soon as comparator does.  (Unless i18n went to WG last call already 
> and I didn't notice?)

It didn't. Until it's updated for comparator-03, it shouldn't. But 
comparator-03 seems to be all i18n needs, so I suppose WGLC is okay 
once I've done that update.

(The LC order feels weird to me, though.)

Arnt

Cc: [email-masked], "'Arnt Gulbrandsen'" <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: more details on agenda
Date: Fri, 21 Jan 2005 06:55:09 -0800
To: "Scott Hollenbeck" <[email-masked]>
Sender: [email-masked]

That sounds feasible to me; I think that means we do a WG last call on 
i18n soonish, because then we'll be all set for it to go to IESG as 
soon as comparator does.  (Unless i18n went to WG last call already and 
I didn't notice?)

Lisa

On Jan 21, 2005, at 5:43 AM, Scott Hollenbeck wrote:

>
>> -----Original Message-----
>> From: Arnt Gulbrandsen [mailto:[email-masked]]
>> Sent: Thursday, January 20, 2005 6:07 PM
>> To: [email-masked]
>> Subject: Re: more details on agenda
>>
>>
>>
>> Lisa Dusseault writes:
>>> Status of i18n: need to submit to IESG
>>>  - no real hurry because blocked behind comparator draft,
>> but why not
>>>  get off our plate?
>>>  - Proposed action: Remind Arnt to get it off his plate
>>
>> I thought IESG submission had to wait for the comparator draft. I'm
>> fuzzy on the details, but last summer, I thought the comparator draft
>> might well force some sort of substantial change to the imap i18n
>> draft, something that would invalidate IESG blessing.
>
> draft-ietf-imapext-sort-17 is blocked while it waits for both the i18n 
> and
> comparator drafts.  I'd prefer to bring both the i18n and comparator 
> drafts
> to the IESG at the same time to better clarify their relationship.
>
> -Scott-
>

From: "Scott Hollenbeck" <[email-masked]>
To: "'Arnt Gulbrandsen'" <[email-masked]>, [email-masked]
Subject: RE: more details on agenda
Date: Fri, 21 Jan 2005 08:43:39 -0500
Importance: Normal
Sender: [email-masked]

> -----Original Message-----
> From: Arnt Gulbrandsen [mailto:[email-masked]] 
> Sent: Thursday, January 20, 2005 6:07 PM
> To: [email-masked]
> Subject: Re: more details on agenda
> 
> 
> 
> Lisa Dusseault writes:
> > Status of i18n: need to submit to IESG
> >  - no real hurry because blocked behind comparator draft, 
> but why not 
> >  get off our plate?
> >  - Proposed action: Remind Arnt to get it off his plate
> 
> I thought IESG submission had to wait for the comparator draft. I'm 
> fuzzy on the details, but last summer, I thought the comparator draft 
> might well force some sort of substantial change to the imap i18n 
> draft, something that would invalidate IESG blessing.

draft-ietf-imapext-sort-17 is blocked while it waits for both the i18n and
comparator drafts.  I'd prefer to bring both the i18n and comparator drafts
to the IESG at the same time to better clarify their relationship.

-Scott-

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Notes from today's meeting
Date: Thu, 20 Jan 2005 16:56:02 -0800
Sender: [email-masked]

I've posted the notes from today's meeting:

http://ietf.webdav.org/imapext/notes/Jan2005InterimNotes.txt

Please review and see if there are any corrections, then I will submit 
for the official IETF record.

Lisa

Cc: [email-masked]
From: Lisa Dusseault <[email-masked]>
Subject: Re: more details on agenda
Date: Thu, 20 Jan 2005 15:37:28 -0800
To: Arnt Gulbrandsen <[email-masked]>
Sender: [email-masked]

Anyway, I should also explain that that was an off-the-cuff agenda 
entry and reflects only the muddled state of my brain, not the 
conclusion of the discussion: for that you'll have to wait for the 
notes.  :)

Lisa

On Jan 20, 2005, at 3:06 PM, Arnt Gulbrandsen wrote:

>
> Lisa Dusseault writes:
>> Status of i18n: need to submit to IESG
>>  - no real hurry because blocked behind comparator draft, but why not 
>>  get off our plate?
>>  - Proposed action: Remind Arnt to get it off his plate
>
> I thought IESG submission had to wait for the comparator draft. I'm 
> fuzzy on the details, but last summer, I thought the comparator draft 
> might well force some sort of substantial change to the imap i18n 
> draft, something that would invalidate IESG blessing.
>
> I'll re-read comparator-03 and i18n-04 closely and see if I still 
> think so. My Friday is a little crimped (real-estate agent in the 
> morning + tax advisor in the afternoon = great day), so next week is 
> more likely.
>
> Arnt
>

Cc: [email-masked]
From: Lisa Dusseault <[email-masked]>
Subject: Re: more details on agenda
Date: Thu, 20 Jan 2005 15:32:09 -0800
To: Arnt Gulbrandsen <[email-masked]>
Sender: [email-masked]

I asked around if there was any likelihood that it would force a 
substantial change but then again I'm not sure I asked the right set of 
people.  It is a tradeoff-- holding onto it in case we want to change 
it, vs. getting it off our plate to avoid having yet another thing on 
our plate at this point.

There is no process objection to submitting i18n to IESG before 
comparator gets submitted to IESG -- that's what happened with 
cond-store and annotate.  And I guess that is an illustrative case as 
there's a proposal to yank cond-store back although it's not due to 
changes in annotate.

lias

On Jan 20, 2005, at 3:06 PM, Arnt Gulbrandsen wrote:

>
> Lisa Dusseault writes:
>> Status of i18n: need to submit to IESG
>>  - no real hurry because blocked behind comparator draft, but why not 
>>  get off our plate?
>>  - Proposed action: Remind Arnt to get it off his plate
>
> I thought IESG submission had to wait for the comparator draft. I'm 
> fuzzy on the details, but last summer, I thought the comparator draft 
> might well force some sort of substantial change to the imap i18n 
> draft, something that would invalidate IESG blessing.
>
> I'll re-read comparator-03 and i18n-04 closely and see if I still 
> think so. My Friday is a little crimped (real-estate agent in the 
> morning + tax advisor in the afternoon = great day), so next week is 
> more likely.
>
> Arnt
>

Date: Fri, 21 Jan 2005 00:06:40 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: more details on agenda
Sender: [email-masked]

Lisa Dusseault writes:
> Status of i18n: need to submit to IESG
>  - no real hurry because blocked behind comparator draft, but why not 
>  get off our plate?
>  - Proposed action: Remind Arnt to get it off his plate

I thought IESG submission had to wait for the comparator draft. I'm 
fuzzy on the details, but last summer, I thought the comparator draft 
might well force some sort of substantial change to the imap i18n 
draft, something that would invalidate IESG blessing.

I'll re-read comparator-03 and i18n-04 closely and see if I still think 
so. My Friday is a little crimped (real-estate agent in the morning + 
tax advisor in the afternoon = great day), so next week is more likely.

Arnt

Date: Thu, 20 Jan 2005 16:57:29 -0500
From: Cyrus Daboo <[email-masked]>
To: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Hallway discussion on views, cursors, windows
Sender: [email-masked]

Hi Lisa,

--On January 20, 2005 1:25:36 PM -0800 Lisa Dusseault 
<[email-masked]> wrote:

> Expired draft archived:
> http://ietf.webdav.org/imapext/archive/draft-ietf-imapext-view-00.txt
>
> anybody who wants to provide more history than I have, go ahead...
>

I have now uploaded the latest versions of the view and window drafts to 
the Webdav server:

<http://ietf.webdav.org/imapext/archive/draft-ietf-imapext-view-03.txt>
<http://ietf.webdav.org/imapext/archive/window.txt>

-- 
Cyrus Daboo

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: more details on agenda
Date: Thu, 20 Jan 2005 13:34:30 -0800
Sender: [email-masked]

Here's the agenda for today, so far,  based off the charter  
deliverables:

Status of i18n: need to submit to IESG
  - no real hurry because blocked behind comparator draft, but why not  
get off our plate?
  - Proposed action: Remind Arnt to get it off his plate

2086bis
  - Need draft with changes from last call
  - Confirm that changes are minor enough
  - references to Annotate gone?

Annotate
  -  
http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-11.txt
  - Randy, Cyrus
  - authors need to follow up with draft to last-call -- due date?

ListExt
  -  
http://www.ietf.org/internet-drafts/draft-ietf-imapext-list-extensions 
-10.txt
  - Barry, Alexey

CondStore
  - Alexey proposed making changes which is generally not advised
  - no evidence of strong support
  - fix post RFC?

ACL2
  - ready for next steps?

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Hallway discussion on views, cursors, windows
Date: Thu, 20 Jan 2005 13:25:36 -0800
Sender: [email-masked]

We had a hallway discussion today amongst the locally-present Lemonade  
and IMAPEXT people about whether the work on views, cursors/windows or  
virtual mailboxes ought to continue.  This is a set of work which was  
intended to let clients work with a subset of a large mailbox in  
various ways.

As I understand, this work was initially in IMAPEXT but eventually got  
dropped.  Today's discussion did not revive that work within IMAPEXT  
but we thought that if there was enough interest, then those interested  
parties could get together and work on that and probably get it charted  
in Lemonade or whatever WG follows Lemonade.

Some pointers to historic work:
http://www.ietf.org/internet-drafts/draft-wener-lemonade-msgfilter 
-01.txt
Expired draft archived:  
http://ietf.webdav.org/imapext/archive/draft-ietf-imapext-view-00.txt

anybody who wants to provide more history than I have, go ahead...

lisa

Date: Thu, 20 Jan 2005 15:15:27 -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: Interim meeting
Sender: [email-masked]

The interim IMAPext meeting in San Francisco will start formally at 2 pm 
PST, but people will start informal discussions at 1 pm PST. The jabber 
room will be in use for anyone that wants to participate remotely...

[email-masked]

-- 
Cyrus Daboo

Date: Tue, 11 Jan 2005 11:49:49 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: [email-masked]
Subject: Re: RIGHTS=kxet, CONDSTORE, implementation
Sender: [email-masked]

On Mon, 10 Jan 2005, Dave Cridland wrote:

> Disabling some options and actions, yes. Is the result of MYRIGHTS supposed 
> to be used for anything else? :-)
>
> As for the emulation, it's really just so I can ask the library if I have "k" 
> on a mailbox, rather than having to ask it whether RIGHTS and ACL is 
> supported first. I suppose I'd have done better if I'd tried to provide a 
> bitfield, or a slew of methods called can_delete, but the API I wrote happens 
> to use strings of rights.
[snip]
> As in not bothering to send a DELETE if the client is in a position to know 
> that the command will fail.

Yes, I agree, but this is the very problem in ACL that 2086bis is trying 
to fix.

> But for the DELETE+ACL case, I think I'll relax the rules and assume it's 
> always granted unless RIGHTS is available and says not. The other new rights 
> are easy to handle.

That makes sense.  I agree that for the most part, you can predict what is 
going to happen somewhat reliably.

> Similar, although more conservative, assumptions can be made if the server 
> doesn't support ACL at all - I can assume the 'r' right is granted if a 
> SELECT suceeds at all, obviously, but I can also make a reasonable guess 
> about the 'w' right based on READ-WRITE/READ-ONLY response codes and FLAGS 
> responses.

Yes. READ-WRITE/READ-ONLY isn't really good enough to fully describe the 
situation (espiecailly on a server that splits s and w).

>> I don't think SELECT is overloaded -- this behavior is necessary for 
>> non-LISTEXT servers.  If SELECT is telling the server to open a mailbox, 
>> in the MAILBOX-REFERRALS case the server fails, and sends back a NO, with 
>> an extra status response of where to try again.  I don't think this is 
>> overloaded (unless you are explicitly trying to use SELECT to preemptively 
>> cache locations of mailboxes, which is probably not a good idea anyway).
>
> It depends on whether, when you ask the client to open "foo", you want it to 
> try a SELECT foo, fail, catch the error, and switch to another IMAP server, 
> or whether you want the client to simply open a connection immediately to 
> another server.
>
> I'd rather not wait for the additional round-trip, if at all possible. If by 
> "not a good idea", you mean that in some cases the REFERRAL will be dynamic, 
> then that shouldn't be a problem - so is the mailbox listing I could 
> hypothetically obtain the data from, and it could always be made optional 
> data anyway, forcing the client to issue SELECT or whatever.

On a non-listext server, you can't skip the round trip though, the only 
way to find out where the mailbox is is to issue the select (well, ok, 
any command that generates a referral).  This is also 
good, as mailbox location can change (though it is true they generally 
don't), and just relying on a listext response you saw a week ago 
probably isn't good either.

> I'm far more likely to use another command where I know the mailbox is 
> remote, in fact, like STATUS, and of course I *will* know the mailbox is 
> remote in the LISTEXT case. I'd rather not needlessly unselect the current 
> mailbox.

Sure.

-Rob

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

From: Dave Cridland <[email-masked]>
To: Rob Siemborski <[email-masked]>
Cc: <[email-masked]>
Subject: Re: RIGHTS=kxet, CONDSTORE, implementation
Date: Mon, 10 Jan 2005 20:13:36 +0000
Sender: [email-masked]

On Mon Jan 10 16:53:30 2005, Rob Siemborski wrote:
> On Mon, 10 Jan 2005, Dave Cridland wrote:
>> I've been gradually implementing ACL support, and I've attempted to do so by emulating the 'kxet' rights where not supported. (This means anywhere, since I don't have access to a server implementation supporting RIGHTS). I'm making the rash assumption that this is a sane way of writing a RFC2086upd client. (I've not yet made it emulate rights based on the READ-ONLY/READ-WRITE response code where no ACL support at all is available, but I will.)
> 
> What meaning does it have to "emulate" RIGHTS support on the client side? Does this mean you are trying to disable options based on what rights you see?  This won't work on most ACL servers because of....
> 

Disabling some options and actions, yes. Is the result of MYRIGHTS supposed to be used for anything else? :-)

As for the emulation, it's really just so I can ask the library if I have "k" on a mailbox, rather than having to ask it whether RIGHTS and ACL is supported first. I suppose I'd have done better if I'd tried to provide a bitfield, or a slew of methods called can_delete, but the API I wrote happens to use strings of rights.

> 
>> I've found that trying to emulate the 'x' right is particularly tricky, since I can only assume:
>> 
>> 'd' => 'et'
>> 'c' => 'k'
>> 
>> So I'm currently assuming the 'x' right is always granted where 'c' or 'd' is granted. (Obviously the client copes with the case where the DELETE fails anyway.)
> 
> This is really a problem with the existing spec and current implementations if you're using this the way I expect..
> 

As in not bothering to send a DELETE if the client is in a position to know that the command will fail.

> 
>> Given that, in the case where we simply don't know whether a right is supported or not, we want to assume it's granted, is this a reasonable assumption, or should I assume the 'x' right is *always* granted (which is effectively what existing clients do anyway)?
> 
> Yes, you should assume it is granted, and let the server tell you it isn't.  Otherwise you're going to have a very fustrated user when the client isn't letting them do (foo) but the server will.  (This is why UNIX apps that look at the unix mode bits directly to see if they can save a file are broken -- they should test if the filesystem actually permits access, not if the mode bits are set).
> 

I agree with the UNIX thing, since the mode bits don't describe everything, and the cost of just doing it and coping with the error condition is slight. (At least, assuming that the error condition is the exception rather than the rule.) Moreover, if the permissions change between a check and actual usage, then there's a potential security hole.

However, if a network client is in a position to know that a command will fail, then it shouldn't be sending those bits across the wire, that's just wasted bandwidth, and a round-trip as well. If the server is explicitly stating that the client may not perform some action, but will actually allow it, then I don't think it's the client that's broken. That's rather like supporting an extension but not advertising it, then saying clients should just issue the command anyway. (The situation where the server says something is possible but turns out to refuse to perform the action is, on the other hand, allowable.)

But for the DELETE+ACL case, I think I'll relax the rules and assume it's always granted unless RIGHTS is available and says not. The other new rights are easy to handle.

> 
>> Incidentally, I've not yet thought of any other problems with a RIGHTS aware client talking to a plain ACL server, but I've not yet done ACL editing, where I suspect that the 'x' right will rear its ugly head again.
> 
> There shouldn't be.  Its implicit that a RIGHTS client supports ACL servers.
> 

I agree that there shouldn't be. I'll be happier that there isn't when I've got a working implementation in front of me to demonstrate it as a fact.

> 
>> Nothing I've found so far appears to be a showstopper, but it might be beneficial to client authors to have some idea of handling legacy support for older servers (ie, all current ones) covered in the RFC.
> 
> If the server doesn't advertise RIGHTS, the client shouldn't assume that it does or try to make it fit somehow.  Just treat it as an ACL server as if you knew nothing else.
> 

I certainly don't assume that if ACL is supported, then RIGHTS is. I do, however, assume that if ACL but not RIGHTS is supported, then I have the 'k' right if the server tells my client I have the 'c' right, for instance.

Similar, although more conservative, assumptions can be made if the server doesn't support ACL at all - I can assume the 'r' right is granted if a SELECT suceeds at all, obviously, but I can also make a reasonable guess about the 'w' right based on READ-WRITE/READ-ONLY response codes and FLAGS responses.

> 
>> 3) LISTEXT
>> 
>> I've not yet implemented this, however, I was thinking of implementing this, ACL2, and MAILBOX-REFERRALS at the same time. In particular, I have noticed that LIST (REMOTE) could reasonably provide the REFERRAL URIs in an extended LIST item, in order to save clients from having to SELECT the mailbox to discover it. This SELECT  generates an additional round-trip, of course, and I feel overloads SELECT's meaning as well.
> 
> We discussed this at one point, I don't remember the outcome.
> 

I'll go archive hunting.

> 
> I don't think SELECT is overloaded -- this behavior is necessary for non-LISTEXT servers.  If SELECT is telling the server to open a mailbox, in the MAILBOX-REFERRALS case the server fails, and sends back a NO, with an extra status response of where to try again.  I don't think this is overloaded (unless you are explicitly trying to use SELECT to preemptively cache locations of mailboxes, which is probably not a good idea anyway).
> 

It depends on whether, when you ask the client to open "foo", you want it to try a SELECT foo, fail, catch the error, and switch to another IMAP server, or whether you want the client to simply open a connection immediately to another server.

I'd rather not wait for the additional round-trip, if at all possible. If by "not a good idea", you mean that in some cases the REFERRAL will be dynamic, then that shouldn't be a problem - so is the mailbox listing I could hypothetically obtain the data from, and it could always be made optional data anyway, forcing the client to issue SELECT or whatever.

I'm far more likely to use another command where I know the mailbox is remote, in fact, like STATUS, and of course I *will* know the mailbox is remote in the LISTEXT case. I'd rather not needlessly unselect the current mailbox.

Dave.

Date: Mon, 10 Jan 2005 11:53:30 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: [email-masked]
Subject: Re: RIGHTS=kxet, CONDSTORE, implementation
Sender: [email-masked]

On Mon, 10 Jan 2005, Dave Cridland wrote:

> I've been gradually implementing ACL support, and I've attempted to do so by 
> emulating the 'kxet' rights where not supported. (This means anywhere, since 
> I don't have access to a server implementation supporting RIGHTS). I'm making 
> the rash assumption that this is a sane way of writing a RFC2086upd client. 
> (I've not yet made it emulate rights based on the READ-ONLY/READ-WRITE 
> response code where no ACL support at all is available, but I will.)

What meaning does it have to "emulate" RIGHTS support on the client side? 
Does this mean you are trying to disable options based on what rights you 
see?  This won't work on most ACL servers because of....

> I've found that trying to emulate the 'x' right is particularly tricky, since 
> I can only assume:
>
> 'd' => 'et'
> 'c' => 'k'
>
> So I'm currently assuming the 'x' right is always granted where 'c' or 'd' is 
> granted. (Obviously the client copes with the case where the DELETE fails 
> anyway.)

This is really a problem with the existing spec and current 
implementations if you're using this the way I expect..

> Given that, in the case where we simply don't know whether a right is 
> supported or not, we want to assume it's granted, is this a reasonable 
> assumption, or should I assume the 'x' right is *always* granted (which is 
> effectively what existing clients do anyway)?

Yes, you should assume it is granted, and let the server tell you it 
isn't.  Otherwise you're going to have a very fustrated user when the 
client isn't letting them do (foo) but the server will.  (This is why UNIX 
apps that look at the unix mode bits directly to see if they can save a 
file are broken -- they should test if the filesystem actually permits 
access, not if the mode bits are set).

> Incidentally, I've not yet thought of any other problems with a RIGHTS aware 
> client talking to a plain ACL server, but I've not yet done ACL editing, 
> where I suspect that the 'x' right will rear its ugly head again.

There shouldn't be.  Its implicit that a RIGHTS client supports ACL 
servers.

> Nothing I've found so far appears to be a showstopper, but it might be 
> beneficial to client authors to have some idea of handling legacy support for 
> older servers (ie, all current ones) covered in the RFC.

If the server doesn't advertise RIGHTS, the client shouldn't assume that 
it does or try to make it fit somehow.  Just treat it as an ACL server as 
if you knew nothing else.

> 3) LISTEXT
>
> I've not yet implemented this, however, I was thinking of implementing this, 
> ACL2, and MAILBOX-REFERRALS at the same time. In particular, I have noticed 
> that LIST (REMOTE) could reasonably provide the REFERRAL URIs in an extended 
> LIST item, in order to save clients from having to SELECT the mailbox to 
> discover it. This SELECT  generates an additional round-trip, of course, and 
> I feel overloads SELECT's meaning as well.

We discussed this at one point, I don't remember the outcome.

I don't think SELECT is overloaded -- this behavior is necessary for 
non-LISTEXT servers.  If SELECT is telling the server to open a mailbox, 
in the MAILBOX-REFERRALS case the server fails, and sends back a NO, with 
an extra status response of where to try again.  I don't think this is 
overloaded (unless you are explicitly trying to use SELECT to preemptively 
cache locations of mailboxes, which is probably not a good idea anyway).

-Rob

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

Date: Mon, 10 Jan 2005 11:27:25 -0500
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
CC: Lisa Dusseault <[email-masked]>
Subject: Re: WG last call for IMAP ACL small-scope changes (RFC2086bis)
Sender: [email-masked]

Lisa Dusseault wrote:

>
> This is the end of the last call period for 
> draft-ietf-imapext-2086upd-02.txt.  I didn't see any issues that I 
> considered required a "reset", so the next step is for Alexey to 
> produce another draft with the changes resulting from last call, and 
> we will submit that to the IESG.
>
> Alexey, when you do this please post your changes from 02 to 03 on the 
> list.

My laptop has died recently, so I don't have the latest copy. For now, 
WG members have to check the mailing list archive.

Dave and Ken have raised a new issue with LISTRIGHTS command and virtual 
rights. The current text as written suggests that if any member right is 
tied to another right, which is not a member of the same virtual right, 
or if member rights are not tied together, then the server is not 
allowed to list the virtual right in a LISTRIGHTS response. For example, 
if "t" is tied to "sw", the server can't return "d". This will confuse 
legacy clients.

There are several alternatives how to deal with the issue:
1). Live with the current limitation and do nothing.

2). In the described case the server should list the virtual right as 
tied to a union of all the rights the individual members are tied to. If 
member rights are not tied, the virtual right is listed by itself. For 
example, a c=>kx server might return:

* LISTRIGHTS INBOX someone "" "tws" "ei" "lr" "p" "k" "x" "a" "c" "dwsi"

Where the draft currently says:
* LISTRIGHTS INBOX someone "" "tws" "ei" "lr" "p" "k" "x" "a"

In this case the client must ignore all strings containing virtual rights.

3). If member rights are not tied together, the virtual right is listed 
by itself. For the example listed above:

* LISTRIGHTS INBOX someone "" "tws" "ei" "lr" "p" "k" "x" "a" "c" "d"

4). Dave has suggested to add a new optional parameter to LISTRIGHTS to 
signal that the client is a new client and it understands new rights. 
When the parameter is specified, the server will not return virtual rights.
=========
I don't like the proposal #1, as I think it might confuse clients: it 
might make clients believe that the "w" right is tied to the "i" right, 
when it is not.
#4 seems like the cleanest solution, however I am concerned that we are 
spending too much effort on fixing ACL, instead of finishing ACL2.

Comments?

Alexey

From: Dave Cridland <[email-masked]>
To: <[email-masked]>
Subject: RIGHTS=kxet, CONDSTORE, implementation
Date: Mon, 10 Jan 2005 14:16:46 +0000
Sender: [email-masked]

Hiya folks,

I've been on a client-side implementation frenzy, and thought I'd 
share my experiences. I've no access to any server implementation of 
any of these - an account on such a server would be greatly 
appreciated. In particular, I'd like CONDSTORE, ANNOTATE, and LISTEXT 
- the RIGHTS stuff, while interesting, is more interesting in as much 
as how to cope without it.

My strategy, incidentally, is to emulate unsupported extensions 
wherever possible.

The client is written in Python, using the wxPython GUI toolkit, and 
should run on Windows, UNIX, and Mac OS X. It does require an account 
on a reasonably full ACAP server implementation, but this does give 
it full roaming and kiosk-mode ability. I'm quite happy to provide 
the source under GPL, and/or an ACAP account.

1) RIGHTS

I've been gradually implementing ACL support, and I've attempted to 
do so by emulating the 'kxet' rights where not supported. (This means 
anywhere, since I don't have access to a server implementation 
supporting RIGHTS). I'm making the rash assumption that this is a 
sane way of writing a RFC2086upd client. (I've not yet made it 
emulate rights based on the READ-ONLY/READ-WRITE response code where 
no ACL support at all is available, but I will.)

I've found that trying to emulate the 'x' right is particularly 
tricky, since I can only assume:

'd' => 'et'
'c' => 'k'

So I'm currently assuming the 'x' right is always granted where 'c' 
or 'd' is granted. (Obviously the client copes with the case where 
the DELETE fails anyway.)

Given that, in the case where we simply don't know whether a right is 
supported or not, we want to assume it's granted, is this a 
reasonable assumption, or should I assume the 'x' right is *always* 
granted (which is effectively what existing clients do anyway)?

Incidentally, I've not yet thought of any other problems with a 
RIGHTS aware client talking to a plain ACL server, but I've not yet 
done ACL editing, where I suspect that the 'x' right will rear its 
ugly head again.

Nothing I've found so far appears to be a showstopper, but it might 
be beneficial to client authors to have some idea of handling legacy 
support for older servers (ie, all current ones) covered in the RFC.

2) CONDSTORE

This seems remarkably straightforward to implement, although again 
I've no real implementation to test against. I do, however, forsee 
some problems when dealing with ANNOTATE in addition, since I'm a 
little unclear on whether the sequence:

C1: a01 FETCH 1 (FLAGS ANNOTATION ("/comment" "value.priv"))
S1: * 1 FETCH (MODSEQ (1) FLAGS (\Seen) ANNOTATION ("/comment" 
("value.priv" "My comment")))
S1: a01 OK
C2: a02 STORE 1 +FLAGS (\Answered)
S2: * 1 FETCH (MODSEQ (2) FLAGS (\Seen \Answered))
S2: a02 OK
C1: a03 FETCH 1 (FLAGS ANNOTATION ("/comment" "value.priv")) 
(CHANGEDSINCE 1)
S1: * FETCH ...
S1: a03 OK

... should return the comment (which is unchanged) or just the flags 
(which is changed).

My reading of 3.3.1 suggests that the comment will be returned as 
well, even though it hasn't changed, because CHANGEDSINCE affects 
message selection, rather than metadata items returned.

Changing this, such that CHANGEDSINCE simply suppressed items that 
haven't changed (excepting UID) would make more sense to me. I can of 
course do this by issuing multiple pipelined fetches, one for every 
item, in effect, which I have to do for items I don't have cached at 
all. (Currently, in fact, I re-fetch the FLAGS unconditionally if I'm 
fetching anything else, since the additional cost of the data 
returned is less than the cost of asking for it seperately, but this 
changes with ANNOTATE).

My second issue is that an extended EXPUNGE would be useful, allowing 
me to "EXPUNGE (UNCHANGEDSINCE 1)" to permanently remove all messages 
flagged as \Deleted which haven't been altered [presumably] without 
my knowledge. Similarly, an extended UID EXPUNGE would be useful, 
too. Given that EXPUNGing the wrong messages is irreparable damage, 
that seems a sensible addition if it can be implemented, which I 
assume it can be with the same effort as FETCH (CHANGEDSINCE ...).

Finally, I'm not sure how good 64-bit arithmetic is under some 
environments - I'm actually developing under Python on a 64-bit 
system, which is probably a recipe for non-portability when I forget 
to use long() rather than int(), but it has the 64-bit support, at 
least, and most C and C++ compilers support some 64-bit unsigned 
integer, but I'm not so sure about Perl, Java, etc. I'd not object to 
the MODSEQ being a string, since this is easily compared, and has 
precedence in ACAP (with the "modtime" attribute).

3) LISTEXT

I've not yet implemented this, however, I was thinking of 
implementing this, ACL2, and MAILBOX-REFERRALS at the same time. In 
particular, I have noticed that LIST (REMOTE) could reasonably 
provide the REFERRAL URIs in an extended LIST item, in order to save 
clients from having to SELECT the mailbox to discover it. This SELECT 
  generates an additional round-trip, of course, and I feel overloads 
SELECT's meaning as well.

In addition, this renders the \Remote mailbox flag redundant, of 
course.

Dave.

Cc: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: WG last call for IMAP ACL small-scope changes (RFC2086bis)
Date: Tue, 4 Jan 2005 10:49:03 -0800
To: Lisa Dusseault <[email-masked]>
Sender: [email-masked]

This is the end of the last call period for 
draft-ietf-imapext-2086upd-02.txt.  I didn't see any issues that I 
considered required a "reset", so the next step is for Alexey to 
produce another draft with the changes resulting from last call, and we 
will submit that to the IESG.

Alexey, when you do this please post your changes from 02 to 03 on the 
list.

Thanks!
Lisa

On Dec 8, 2004, at 4:28 PM, Lisa Dusseault wrote:

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