Subject: RE: [lemonade] Notifications for multiple devices per user

From: <[email-masked]>
Date: Tue, 1 Aug 2006 12:33:33 +0300

Hi Dave,
There are some disadvantages listed in this draft.
Earlier I suggested to standardize a MOVE command, but it has been turned down for some reason - however moving emails from one mailbox to another (like inbox to trash) would be just the perfect candidate to support it.
So, if the LEMONADE profile were to add a MOVE command, You could strike though a few disadvantages in the IMAP TRASH draft. 

Best regards: Zoltán Ördögh
E-mail: zoltan dot ordogh at nokia dot com
Phone: +358 50 386 0566

-----Original Message-----
From: ext Dave Cridland [mailto:[email-masked]] 
Sent: 01 August, 2006 01:07
To: Mark Crispin
Cc: Enhancements to Internet email to support diverse service enivronments
Subject: RE: [lemonade] Notifications for multiple devices per user

On Mon Jul 31 16:34:44 2006, Mark Crispin wrote:
> On Mon, 31 Jul 2006, Ben Last wrote:
>> Thus we have no
>> reliable way to identify the Trash (or Outbox, or Sent folders) 
>> created by other IMAP clients.  Has there been discussion on this?
> 
> One simple answer is "don't use a Trash mailbox, use the native IMAP 
> delete/expunge model instead."
> 
> 
http://dave.cridland.net/draft-cridland-imap-trash.txt

(Which was sufficiently contentious that I've not submitted, but will do if there's demand).

> The need to identify a sent-message mailbox is a different matter, 
> provided that we agree upon a firm, immutable definition of what 
> constitutes a sent-message mailbox with no wiggle-room for fools to 
> create non-interoperable situations.  ACAP was supposed to solve that 
> problem...

I think you're oversimplifying the problem in any case - there's two
problems:

The first relates to the difficulty in identifying the difference between a message you intend to send (perhaps assembling it on the server with CATENATE) and one that actually has been successfully sent. Whether all the messages in the same category happen to be in a specific mailbox or not is another matter.

The second relates to interoperable configuration between clients, such that different clients automatically reflect the user's stated preferences. This is the problem that was solved by ACAP very well nearly a decade ago, a solution which I happily use every time I send a message.

Dave.
--
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Philip Guenther <[email-masked]>
Date: Tue, 1 Aug 2006 04:07:03 -0700

On Tue, 1 Aug 2006, [email-masked] wrote:
> There are some disadvantages listed in this draft. Earlier I suggested 
> to standardize a MOVE command, but it has been turned down for some 
> reason

"Some reason"?  I seem to recall a number of responses describing 
implementation problems and questioning the benefits.

> - however moving emails from one mailbox to another (like inbox to 
> trash) would be just the perfect candidate to support it. So, if the 
> LEMONADE profile were to add a MOVE command, You could strike though a 
> few disadvantages in the IMAP TRASH draft.

But which disadvantages does it remove, the easy ones or the hard ones? 
As far as I can tell, it doesn't solve any of the hard ones on Dave's 
list.  Yes, it solves the quota problem, but only for servers where quotas 
strictly follow the QUOTA extension and not those based on actual 
filesystem quotas.

Dave, here's another item for your I-D: in the native method, both steps 
are atomic and idempotent; in the Trash mailbox method, the mark+copy+ 
expunge process is neither atomic nor idempotent.  This means that 
concurrent clients may result in multiple copies of a message in the Trash 
mailbox.

(I've seen a client where each time you hit the delete button, it would 
open a new session to the mailbox and use that to do the mark+copy+ 
expunge.  That's not a bad idea, except that if you hit the delete button 
more than once then it would open multiple sessions, each session 'moving' 
the *same* messages to the Trash mailbox.)

Hmm, weren't you going to add a bit about quotas and how Trash mailboxes 
interact poorly with them?

Philip Guenther

---

From: <[email-masked]>
Date: Tue, 1 Aug 2006 14:37:04 +0300

Hi Philip,
Please find my responses inline, tagged with [ZÖr].

-----Original Message-----
From: ext Philip Guenther [mailto:[email-masked]] 
Sent: 01 August, 2006 14:07
To: Ordogh Zoltan (Nokia-TP-MSW/Tampere)
Cc: [email-masked]; [email-masked]
Subject: RE: [lemonade] Notifications for multiple devices per user

> to standardize a MOVE command, but it has been turned down for some 

"Some reason"?  I seem to recall a number of responses describing implementation problems and questioning the benefits.
[ZÖr] Yes, I did not want to quote the entire discussion here - I call it some reason because I disagree: I believe that it does add value and implementation problems are a good thing - they force a better architecture in the long run - so we should address this. Also, the command was suggested to be optional so it should not cause any problems for those unwilling to implement it. So that implementation problem You mention I only see as a minor problem in exchange for a much bigger benefit (think about mobile phones having to copy mails: download, upload, extra roundtrips) . But that's about it, I do not wish to open this discussion again (yet).

[ZÖr] This is in the draft:
<quote start>
4.1.  Advantages

      This is more familiar to users of desktop operating systems.

4.2.  Disadvantages

      It is less efficient, using multiple round-trips.
      It is impossible to accurately reverse the first stage of the
      metaphor - doing so requires the client to copy the message back,
      which issues it with a new UID, and can alter the message's
      position in the display.
      For shared mailboxes, deleted messages are generally moved to a
      personal trash folder.
      It relies for safety on the UIDPLUS extension defined in [RFC4315]
      - servers not implementing this extension, or not supporting it
      for the mailboxes involved, will cause additional downloads and
      potentially inadvertant irrevocable deletions.
      It is not interoperable - aside from the issues noted above, there
      is no mechanism for denoting a trash mailbox, and many clients
      vary the name used.
<quote end>
The disadvantage the MOVE command would remove is the first one shown above: no need for multiple roundtrips to copy an email and remove the original (plus, the UID would be kept so it would not be downloaded again to the client). Also, I suspect it would address the third one about UIDPLUS and the last one as well.
So, only the second one would remain - which I believe is not a real problem because You indicate where to move the emails, so You can move it to any mailbox You wish.
While at it, I believe that there is an additional advantage of using Trash mailbox: to have the emails organized better -  the deleted mails do not mix with the ones that one wants to keep there, making it easier to find emails (besides then searched would not be performed on deleted emails either which means performance boost).

---

From: Dave Cridland <[email-masked]>
Date: Tue, 01 Aug 2006 16:07:45 +0100

> [ZÖr] This is in the draft:

I should clarify this is not a draft, strictly. It's a draft of a 
draft.

>       It is less efficient, using multiple round-trips.

MOVE helps this.

>       which issues it with a new UID, and can alter the message's

MOVE doesn't help this.

>       For shared mailboxes, deleted messages are generally moved to 

Nor this.

>       potentially inadvertant irrevocable deletions.

MOVE exchanges this required extension for another, so whilst it 
removes reliance on UIDPLUS, it's replacing it with reliance on an 
extension that's yet to be defined, let alone implemented.

>       is no mechanism for denoting a trash mailbox, and many clients

MOVE does not help this.

> While at it, I believe that there is an additional advantage of 
> using Trash mailbox: to have the emails organized better -  the 
> deleted mails do not mix with the ones that one wants to keep there,

That's related to the view of the mailbox, though. Some form of view 
filter eliminates the deleted messages from the view.

>  making it easier to find emails (besides then searched would not 
> be performed on deleted emails either which means performance 
> boost).

Prepending UNDELETED to the search key ought to be virtually as fast 
as physically removing the messages, though, since it's a search on 
flags.

I'm really not against Trash mailboxes, as such, it's just that IMAP 
doesn't have the concept, and retrofitting it onto existing IMAP 
servers can cause far more problems than it solves.

Dave.

---

From: Mark Crispin <[email-masked]>
Date: Tue, 1 Aug 2006 08:40:07 -0700 (PDT)

On Tue, 1 Aug 2006, Dave Cridland wrote:
> I'm really not against Trash mailboxes, as such, it's just that IMAP doesn't 
> have the concept, and retrofitting it onto existing IMAP servers can cause 
> far more problems than it solves.

I, on the other hand, am completely opposed to adding a Trash mailbox to 
IMAP.  I am also completely opposed to a MOVE command.  These decisions 
were correct when they were made in 1986, and remain correct today.

I strongly suggest to people who want a protocol that has a Trash mailbox 
that they design their own competing protocol to IMAP (there is Exchange 
after all) and use that protocol instead of IMAP.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

---

From: Mark Crispin <[email-masked]>
Date: Tue, 1 Aug 2006 08:45:08 -0700 (PDT)

> after all) and use that protocol instead of IMAP.

There is also a protocol called SMAP that is touted by its creator as 
being superior to IMAP.

The point of this rant is that there is no need to bloat IMAP with 
extraneous functionality; alternatives exist.  As it is, IMAP needs to go 
on a diet.

-- Mark --

http://panda.com/mrc

---

From: Philip Guenther <[email-masked]>
Date: Tue, 1 Aug 2006 05:35:29 -0700

> From: ext Philip Guenther [mailto:[email-masked]]
...
> implementation problems and questioning the benefits. [ZÖr] Yes, I did 
> not want to quote the entire discussion here - I call it some reason 
> because I disagree: I believe that it does add value and implementation 
> problems are a good thing - they force a better architecture in the long 
> run - so we should address this.

No, implementation problems mean you're less likely to have a tight spec 
and more likely to have subtle differences in behavior between 
implementations.  If an implementor has to choose between:

a) a 100% accurate implementation that requires a major architectural
    change,
b) a 95% accurate implementation that doesn't require that major re-arch,
    and
c) not implementing it

then (a) is going to lose out unless that last 5% has a value that the 
implementors can show to their management.

> Also, the command was suggested to be
> optional so it should not cause any problems for those unwilling to 
> implement it.

...until it becomes part of some profile, at which point that 95% solution 
looks _real_ good.  Too bad some clients get confused by the results.

...
>      vary the name used. <quote end>
>
> The disadvantage the MOVE command would remove is the first one shown 
> above: no need for multiple roundtrips to copy an email and remove the 
> original

I think MOVE would *only* save the RTT waiting for the COPY to return OK 
before expunging the messages.  At least as how I understand the methods, 
that still would leave you an RTT slower than the native method.

> (plus, the UID would be kept so it would not be downloaded 
> again to the client).

If you're referring to the second item, ("It is impossible...") then no, 
it can't.  Moving a message from mailbox A to mailbox B and back MUST 
place the message at the end of the mailbox.  The IMAP base spec 
guarantees that messages CANNOT be reinserted into the middle of mailbox 
without changing the UIDVALIDITY and no extension can change that.

> Also, I suspect it would address the third one 
> about UIDPLUS

If you're implying that support for MOVE would require support for 
UIDPLUS, well, you're just _confirming_ the need for UIDPLUS.

> and the last one as well.

I have no idea what you mean by this, as the presence of the MOVE command 
doesn't standardize the name of the Trash mailbox and requiring an 
extension makes the process *less* interoperable.

> So, only the second one would 
> remain - which I believe is not a real problem because You indicate 
> where to move the emails, so You can move it to any mailbox You wish.

The client you use lets you designate _different_ Trash mailboxes to be 
used when deleting messages from different folders?  So you designate a 
separate Trash mailbox for each shared mailbox you use?

How many clients do you know support that?  How many people actually go to 
the bother of using that capability?

> While at it, I believe that there is an additional advantage of using 
> Trash mailbox: to have the emails organized better - the deleted mails 
> do not mix with the ones that one wants to keep there, making it easier 
> to find emails (besides then searched would not be performed on deleted 
> emails either which means performance boost).

tag SEARCH UNDELETED <real criteria here>

Philip Guenther

---

From: Randall Gellens <[email-masked]>
Date: Thu, 10 Aug 2006 17:47:50 -0700

At 2:37 PM +0300 8/1/06, <[email-masked]> wrote:

>  I believe that it does add value and implementation problems are a 
> good thing - they force a better architecture in the long run - so 
> we should address this.

This is an unusual viewpoint: that proposals which are difficult to 
implement are good.  I have to disagree with it.  Such proposals lead 
to fewer implementations than those which are easy to do, and the 
implementations that are done tend to be non-compliant and hence have 
poor interoperability.

>  Also, the command was suggested to be optional so it should not 
> cause any problems for those unwilling to implement it.

This is an attitude that I see often in other standards bodies: that 
the solution to a controversial or objectionable proposal is to make 
it optional.  Optional features harm interoperability because 
implementations cannot rely on them being present.  This has 
especially been a problem with IMAP, which suffers from too much 
variability in server behavior and hence is difficult for clients. 
One of the goals of lemonade is to create a specification which 
covers a number of desirable extensions and hence is easier for 
clients to support, and easier for organizations to specify in their 
RFPs.

>   So that implementation problem You mention I only see as a minor 
> problem in exchange for a much bigger benefit (think about mobile 
> phones having to copy mails: download, upload, extra roundtrips) .

We can work on the underlying problem without necessarily agreeing on 
this specific proposal.

>  But that's about it, I do not wish to open this discussion again (yet).

I'm not sure it is fair to slip in comments such as "objections for 
some reason" (which imply that there were no good reasons for the 
objection) and then say "but I do not wish to reopen the discussion". 
By slipping in the comments on the proposal you have reopened the 
discussion.  I think it would be more productive to focus on the 
specific problems rather than keep re-proposing a specific approach 
which would not solve them.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
And still I persist in wondering if folly must always
be man's nemesis.                    --Edgar Pangborn

---

From: <[email-masked]>
Date: Fri, 11 Aug 2006 12:08:04 +0300

Hi Randall,
Some answers below.

>We can work on the underlying problem without necessarily 
>agreeing on this specific proposal.

>I'm not sure it is fair to slip in comments such as 
>"objections for some reason" (which imply that there were no 
>good reasons for the
>By slipping in the comments on the proposal you have reopened 
>the discussion.  I think it would be more productive to focus 
>on the specific problems rather than keep re-proposing a 
>specific approach which would not solve them.

I would like to address this problem, but so far it seems that other parties are happy with the solution available today, and see no benefit of addressing it - this is the reason why I gave up. If everyone agrees that this is the way to go, what can I do? Solve it in OMA where the operator awareness is much stronger? I would like to do it here in LEMONADE since this is the "natural home" of such extensions.

I am more concerned about bandwidth usage and the number of roundtrips - these are major concerns on mobile networks because:
 - the roundtrips and latencies are typically longer and
 - the amount of data transmitted should be minimal,
hence my persistence regarding this issue.
This is why I am saying that a simple MOVE command would solve it:
Client says: MOVE mailbox/UID to this mailbox
Servers says: OK done, here is the new UID.
or:
Client says: MOVE mailbox to this mailbox
Server says: OK
All done with one roundtrip. I do not think that there is a more efficient way to do this.

Then, there is this version - which might be imporant when the user wants to move all messages:
Client says: MOVE mailbox/* to this mailbox
Servers says: OK done, here are the new UIDs.
however, I am not sure how to solve this because there are several UIDs involved (some kind of mapping of old UIDs to new UIDs is necessary otherwise the client will re-download everything).

I am not sure what You mean by working on the underlying problem - if it makes it as efficient as this, I am more than wiling to drop my proposal and take Yours right away.
Could You elaborate please?
Thank You.

---

From: "Ben Last" <[email-masked]>
Date: Fri, 11 Aug 2006 11:42:53 +0100

[email-masked] [mailto:[email-masked]] wrote at 11
August 2006 10:08:
>Client says: MOVE mailbox/UID to this mailbox Servers says: OK done,
here is the new UID.
>or:
>Client says: MOVE mailbox to this mailbox Server says: OK All done with
one roundtrip. I
>do not think that there is a more efficient way to do this.

That solves the problem for the client doing the move, but doesn't
address the needs of other clients who need to be informed of the move
(in a more efficient manner than EXPUNGE / EXISTS)/.

>...however, I am not sure how to solve this because there are several
UIDs involved (some
>kind of mapping of old UIDs to new UIDs is necessary otherwise the
client will re-download
>everything).

But UIDs are very server-dependent: some servers use what looks like a
timestamp, others use incrementing numbers... I'm not sure that such a
mapping could ever be defined.

Regards
Ben

---

From: Dave Cridland <[email-masked]>
Date: Fri, 11 Aug 2006 12:29:18 +0100

On Fri Aug 11 10:08:04 2006, [email-masked] wrote:
> I would like to address this problem, but so far it seems that 
> other parties are happy with the solution available today, and see 
> no benefit of addressing it - this is the reason why I gave up. If 
> everyone agrees that this is the way to go, what can I do? Solve it 
> in OMA where the operator awareness is much stronger? I would like 
> to do it here in LEMONADE since this is the "natural home" of such 
> extensions.
> 
> 
There's no need to solve it.

> efficient way to do this.
There is an equally efficient method in the normal case:

A01 UID COPY x
A02 UID STORE x +FLAGS.SILENT (\Deleted)

The client has to check the response to A01, and undo the UID STORE 
if it fails, but that's a rare case - it does involve a round-trip, 
but the client need not wait for it.

> Then, there is this version - which might be imporant when the user 
> /

---

From: Dave Cridland <[email-masked]>
Date: Fri, 11 Aug 2006 12:29:18 +0100

A01 UID COPY x

> wants to move all messages:
> however, I am not sure how to solve this because there are several 
> UIDs involved (some kind of mapping of old UIDs to new UIDs is 
> necessary otherwise the client will re-download everything).
> 
> 
UIDPLUS does this for COPY already. So it would do it for MOVE, if 
MOVE were needed. I don't think that MOVE stands up to a balloon 
debate - it's not that it's a bad idea per se, it's more that it's 
not a sufficiently compelling idea that it would be worth having.

Dave.

wants to move all messages:
> however, I am not sure how to solve this because there are several 
> UIDs involved (some kind of mapping of old UIDs to new UIDs is 
> necessary otherwise the client will re-download everything).
> 
> 
UIDPLUS does this for COPY already. So it would do it for MOVE, if 
MOVE were needed. I don't think that MOVE stands up to a balloon 
debate - it's not that it's a bad idea per se, it's more that it's 
not a sufficiently compelling idea that it would be worth having.

Dave.

---

From: "Ben Last" <[email-masked]>
Date: Fri, 11 Aug 2006 13:17:48 +0100

August 2006 12:03:
>Cpaable client could be notified about this with untagged responses
(mailbox1/UID moved to mailbox2/UID,
>mailbox1 moved to mailbox2, mailbox1/* moved to mailbox2/here is the
UID mapping).
Ok, that implies that your proposal needs to suggest formats for those
untagged responses :)  But as Dave Cridland pointed out, there's already
an effective MOVE command using UID COPY/STORE.  Maybe all that you need
propose are untagged response formats, as part of new Lemonade profiles,
to notify clients of UID COPY activities.

Regards
Ben
EMCC Software Ltd

---

From: <[email-masked]>
Date: Fri, 11 Aug 2006 15:45:38 +0300

Dave,
I understand what You mean and how to do this for a single email. My concern here is not moving a single email(*) - there are other use cases.
Most users organize emails to different mailboxes - we can all agree to this, right?
I do not worry here about weekend warriors who use email for fun - they probably move emails one by one as the read them and they can live with the current solution (although in the long run those extra commands accumulate to a larger mobile phone bill).
I worry here about those heavy-weight pros who use email as a tool in their work every day (and do not know how to set up filters to do this automatically). They move several emails (maybe all) at once. They even whole mailboxes into another one. And this is where such MOVE command would come really handy. One can argue that it is not an everyday task and most likely will not be used from a mobile terminal, however I believe that we are yet to see more advanced mobile terminals (bigger screen, better UI) when the whole mobile email standards are ready and the 'real' competition begins.

(*)
I see benefit of adding those two commands into a single command just for the sake of moving single email also: this allows the client not to worry too much about things - the server does all actions and finally tells the client that it's done (or: not done).

>Sent: 11 August, 2006 14:29
>Subject: RE: [lemonade] 'MOVE' (was Notifications for multiple 
>devices per user)
>
>> I would like to address this problem, but so far it seems that other 
>> parties are happy with the solution available today, and see no 
>> benefit of addressing it - this is the reason why I gave up. If 
>> everyone agrees that this is the way to go, what can I do? 
>Solve it in 
>> OMA where the operator awareness is much stronger? I would 
>like to do 
>> it here in LEMONADE since this is the "natural home" of such 
>> extensions.
>> 
>> 
>> Client says: MOVE mailbox to this mailbox Server says: OK All done 
>> with one roundtrip. I do not think that there is a more 
>efficient way 
>> to do this.
>> 
>> 
>The client has to check the response to A01, and undo the UID 
>STORE if it fails, but that's a rare case - it does involve a 
>round-trip, but the client need not wait for it.
>
>
>> Client says: MOVE mailbox/* to this mailbox Servers says: OK done, 
>> here are the new UIDs.
>UIDPLUS does this for COPY already. So it would do it for 
>MOVE, if MOVE were needed. I don't think that MOVE stands up 
>to a balloon debate - it's not that it's a bad idea per se, 
>it's more that it's not a sufficiently compelling idea that it 
>would be worth having.
>
>Dave.
>--

---

From: <[email-masked]>
Date: Fri, 11 Aug 2006 14:02:34 +0300

>That solves the problem for the client doing the move, but 
>doesn't address the needs of other clients who need to be 
>informed of the move (in a more efficient manner than EXPUNGE 
>/ EXISTS)/.

Well, I supposed that the capability for the MOVE command would be
announced the same way as any other extensions.
Cpaable client could be notified about this with untagged responses
(mailbox1/UID moved to mailbox2/UID, mailbox1 moved to mailbox2,
mailbox1/* moved to mailbox2/here is the UID mapping).
The only problem I can see here is with incapable clients: backwards
compatility with older clients that would not support such untagged
responses - I would rather find a workaround for these clients than
having new clients do the workarounds (because the old ones are mostly
fixed-network-based, while the new ones will be using mobile networks as
well).
But, I would not want to go into such details before I get a response
from Randall - He mentioned "working on the underlying problem", I would
like to know what Randall has in mind - it might be actually better than
the current thinking.

>But UIDs are very server-dependent: some servers use what 
>looks like a timestamp, others use incrementing numbers... I'm 
>not sure that such a mapping could ever be defined.

I do not think that we need to worry about this at all. It is the server
that assigns the UID whatever it is, and the client would get a new one
for every message after the move.

---

From: Dave Cridland <[email-masked]>
Date: Fri, 11 Aug 2006 15:55:02 +0100

On Fri Aug 11 13:45:38 2006, [email-masked] wrote:
> I understand what You mean and how to do this for a single email. 
> My concern here is not moving a single email(*) - there are other 
> use cases.

x in my example can be either a single uid, or a uid set. So 
potentially that can move the entire contents of the mailbox. I think 
that renders the rest of your argument a little unsustainable.

> I see benefit of adding those two commands into a single command 
> just for the sake of moving single email also: this allows the 
> client not to worry too much about things - the server does all 
> actions and finally tells the client that it's done (or: not done).

This, of course, is actually the primary objection to MOVE. You're 
expecting that an IMAP server will be able to perform write activity 
on two mailboxes atomically, which is not required by any other part 
of the standard.

At a simple glance at MOVE, it looks remarkably simple, but what 
you're saying is that servers have to potentially rewind the internal 
COPY if the internal STORE fails, all very carefully not allowing 
this to be observed by any session active on the target mailbox. It's 
really not quite as simple as you think.

Basically, it's saving about 30 octets on the wire - probably much 
less after compression etc - for a comparitively rare operation 
that's difficult or impossible to implement atomically on most 
servers.

It is also useful for weak client developers to avoid them having to 
handle proper pipeline processing, I suppose, but it's basically 
going to end up being an expensive and slow client to run anyway if 
the developers can't handle pipelines.

Dave.

---

From: Randall Gellens <[email-masked]>
Date: Tue, 15 Aug 2006 18:03:20 -0700

> to do it here in LEMONADE since this is the "natural home" of such 

You mean propose an IMAP extension in OMA?

>  I am more concerned about bandwidth usage and the number of 
> roundtrips - these are major concerns on mobile networks because:

I don't think anyone here disagrees regarding the need to minimize 
roundtrips especially but also bandwidth.  The disagreement is about 
the advisability of the proposed MOVE extension.

> efficient way to do this.

The current UIDPLUS does as much as this.  Neither that nor MOVE is 
any help at all to other clients (those that sync the mailboxes 
involved but didn't issue the command).

>  I am not sure what You mean by working on the underlying problem

What I mean is: identify the problem.  We see if the problem itself 
is in scope.  If it is, we identify requirements and discuss proposed 
solutions.

As I understand the MOVE suggestion, it doesn't really help over what 
we have now.

-------------- Randomly-selected tag: ---------------
Advertising is 85 percent confusion and 15 percent commission.
                                                 --Fred Allen

---

From: <[email-masked]>
Date: Wed, 16 Aug 2006 10:06:31 +0300

Hi Randall,

>You mean propose an IMAP extension in OMA?
I am not saying it wiil, I am saying it might. You see, in OMA the
operator presence is very strong - if there is enough operator demand
for some feature, it will be done (one way or another). So far we did
not go into too much detail in how the email service will look like - I
guess everyone is waiting for the LEMONADE specs to see what's there and
what's missing. One thing I noticed whil talking with people is that
some talk about pure IMAP serivce, some talk about "Outlook"-like
service where You do have all those special mailboxes (including trash)
and for these people identification of the TRASH mailbox might be quite
important.
My worry here is: if it's not in the LEMONADE Profile, it will have to
be done in OMA. If it's done in OMA, only the OMA-Complicant clients
will be completely interoperable (e.g. when the same mailbox is accessed
from a LEMONADE client, it might mess up the user's mailbox for the OMA
client - for "mess" I mean leaving around flagged messages and not
placing them into the trash).
Then, there is the DS-based email (I am not sure whether You know about
this): There will be a DS-based (Data Synch - formerly known as SyncML)
email solution as well - where they indeed identify the trash (well, in
a proposal I saw it was included). Now, if I accessed the same mailbox
from my office via LEMONADE and during travelling via DS, I (as a user)
might not like what I see.
I would like to emphasize that these things are not important at this
point because we did not go into such detail yet in OMA. But in the near
future they might - and then I would rather have this particular problem
solved in LEMONADE than in OMA.

---

From: Dave Cridland <[email-masked]>
Date: Wed, 16 Aug 2006 19:13:00 +0100

> and for these people identification of the TRASH mailbox might be 

The problem is it probably wouldn't, in practise, because you'd have 
to manually mark which mailbox the third-party client was using, and 
manually configure your desktop client to use the same one as your 
webmail.

> placing them into the trash).

 From an interop standpoint, any trash mailbox using client has to 
deal with \Deleted messages in normal folders anyway.

> might not like what I see.

Well, the DS service can present all the deleted messages as being in 
a seperate folder, much like I'm arguing that any other client can. 
If it doesn't, then this is a poor DS service.

Now, if we can figure out a way clients can present this metaphor 
efficiently, and I think we can, then we can move forward from there 
to seeking ways of making this metaphor more efficient by providing 
suitable extensions. That latter is absolutely in scope for this WG, 
of course.

Dave.

---

From: <[email-masked]>
Date: Thu, 17 Aug 2006 12:35:00 +0300

Hi Dave,
Thank You.

>> and for these people identification of the TRASH mailbox might be 
>> quite important.
>
>The problem is it probably wouldn't, in practise, because 
>you'd have to manually mark which mailbox the third-party 
>client was using, and manually configure your desktop client 
>to use the same one as your webmail.
But if the relevant setting was stored on the server, it would not need
to be configured at all except for the first time (and ultimately all
clients would behave the same way using the same configuration).

>> from a LEMONADE client, it might mess up the user's mailbox for the 
>> OMA client - for "mess" I mean leaving around flagged 
>messages and not 
> From an interop standpoint, any trash mailbox using client 
>has to deal with \Deleted messages in normal folders anyway.
Certainly. I am not worried about the protocol level - I am worried
showing a mixed mailbox to the user (where some mails are in the trash
as expected and some are not).

>If it doesn't, then this is a poor DS service.
One can say that the IMAP<->DS adapter needs to take care of this, yes.
However, the DS-based solution is not limited to IMAP. What if one user
is using DS to access two different mailboxes (one with IMAP and one
with WebDAV/POP/etc)? In this case, the mailboxes are going to behave
differently - and I would prefer delivering the exact same look and feel
independently of the underlying technologies.

>suitable extensions. That latter is absolutely in scope for this WG, 
I agree, of course.

---

From: Randall Gellens <[email-masked]>
Date: Thu, 17 Aug 2006 16:26:29 -0700

At 12:35 PM +0300 8/17/06, <[email-masked]> wrote:

>  I am not worried about the protocol level - I am worried

There's a difference between where a message is on the server, and 
how the message is presented to the user.  If clients want to present 
a distinct "Trash" mailbox to the user, that is fine.  Forcing the 
metaphor to be literally true is a poor use of IMAP and causes 
problems.  Making it easy for clients to efficiently present a Trash 
metaphor to users is a good thing.  I assume the users don't care 
which elements of the protocol are used in which ways by the client. 
They want to manage messages in a way that feels natural for them.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
"SFPD Homicide: Our Day Begins when Yours End" --Slogan seen on back of
San Francisco Police Jacket, as reported by Herb Cain in SF Chronicle

---

From: Mark Crispin <[email-masked]>
Date: Thu, 17 Aug 2006 16:51:01 -0700 (Pacific Daylight Time)

On Thu, 17 Aug 2006, Randall Gellens wrote:
> There's a difference between where a message is on the server, and how the 
> message is presented to the user.  If clients want to present a distinct 
> "Trash" mailbox to the user, that is fine.  Forcing the metaphor to be 
> literally true is a poor use of IMAP and causes problems.  Making it easy for 
> clients to efficiently present a Trash metaphor to users is a good thing.  I 
> assume the users don't care which elements of the protocol are used in which 
> ways by the client. They want to manage messages in a way that feels natural 
> for them.

Strongly agree on all points.

A Trash mailbox (in the IMAP sense, not the user experience) is an 
inadequate kludge to approximate the user experience of a Trash metaphor.

The solution-task therefore is to come up with a method that:
  . makes it easy for clients to present a Trash metaphor
  . is not a kludge
  . is easy for clients and efficient
  . uses IMAP well
  . does not cause problems
  . interoperates well with IMAP clients that do not present a Trash
    metaphor.

A Trash mailbox (in the IMAP sense) fails all of these criteria with the 
possible (and only as a kludge) exception of the first.  Attempts at 
remediation within the context of a Trash mailbox (in the IMAP sense) will 
result in what we call a "kludge tower".  Each subsequent kludge of the 
kludge tower is intended to overcome a weakness of the previous kludge. 
The tower is fragile and complex, and eventually collapses.

I strongly feel that it is better to produce a new mechanism, designed 
explicitly to support the Trash metaphor within IMAP.  Such a mechanism 
would have the following characteristics:
  . keeps track of which mailboxes have deleted messages; clients should
    not be required to scan all mailboxes.
  . maintain a means (perhaps through LISTEXT) to record which mailboxes
    are "in the Trash" without actually doing a DELETE command; and alter
    LIST results based upon this status.
  . possibly also an "empty Trash" operation, which executes the DELETE
    command(s) and SELECT/EXPUNGE command(s) for items in the Trash.  I
    think, but am not certain, that this operation does not need to be
    atomic.

There are plenty of details to work out (e.g., if a non-trash client 
deletes a message, is that message in the Trash?  What if it's a mailbox 
that is not in the default tree?).  But that can be discussed after we 
agree to undertake the effort.

That effort does not belong in Lemonade; it is out of charter.  It belongs 
in IMAPEXT, or perhaps a new WG.

-- Mark --

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

---

From: <[email-masked]>
Date: Tue, 22 Aug 2006 07:56:07 +0300

>>  I am not worried about the protocol level - I am worried  showing a 
>> mixed mailbox to the user (where some mails are in the trash  as 
>> expected and some are not).
>
>There's a difference between where a message is on the server, 
>and how the message is presented to the user.  If clients want 
>to present a distinct "Trash" mailbox to the user, that is 
>fine.  Forcing the metaphor to be literally true is a poor use 
>of IMAP and causes problems.  Making it easy for clients to 
>efficiently present a Trash metaphor to users is a good thing. 
> I assume the users don't care which elements of the protocol 
>are used in which ways by the client. 

Somehow this thread went back to discussing Trash instead of MOVE.
I read through Mark's email as well. I accept what You are saying - my
worry is that the operators will say at the last minute (when LEMONADE
is already done) that they want a separate trash and force us to do
something proprietary (I mean it will be a standard anyway in OMA, but
might not be in line with LEMONADE).

---

From: Randall Gellens <[email-masked]>
Date: Tue, 22 Aug 2006 14:03:12 -0700

>  might not be in line with LEMONADE).

If operators try to mandate a Trash mailbox in OMA, my advise would 
be to try and focus the requirement on what is necessary to permit 
the desired user experience and on interoperability.  In other words, 
if operators want to be sure that their users will see a trash 
metaphor, it should not matter to them if this is implemented with a 
distinct trash mailbox on the server or on the client, as long as the 
solution interoperates.  Doing it on the client is actually more 
interoperable, since it is reversible by any client.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
An algorithm must be seen to be believed.  -- Donald Knuth

---

From: <[email-masked]>
Date: Wed, 23 Aug 2006 08:11:06 +0300

Hi Randall,

>If operators try to mandate a Trash mailbox in OMA, my advise 
>would be to try and focus the requirement on what is necessary 
>to permit the desired user experience and on interoperability. 
> In other words, if operators want to be sure that their users 
>will see a trash metaphor, it should not matter to them if 
>this is implemented with a distinct trash mailbox on the 
>server or on the client, as long as the solution 
>interoperates.  Doing it on the client is actually more 

I agree with You. But for interoperabiity You need to know the name of
the Trash mailbox - this is where the original arguments started from.
We need to identify the name of the trash mailbox - along with other
special mailboxes.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 23 Aug 2006 11:23:55 +0100

>We need to identify the name of the trash mailbox - along with other
Dave Cridland and I will work on a draft that would describe mailbox 
tagging and will also define some initial tags for Sent Mail, Drafts, etc.

Alexey

P.S. Can we please stop discussing this topic now :-), at least until 
people see the first revision of the draft.

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 23 Aug 2006 08:25:01 -0400

Hi Alexey,

> tagging and will also define some initial tags for Sent Mail, Drafts, etc.

I take it this will use the METADATA extension? If so, you will also need 
to write a LISTEXT/METADATA extension to allow clients to 'search' for 
mailboxes containing 'tags' (those mailboxes may not always be at the 
top-level of a hierarchy).

BTW Speaking of tagging, it would be handy to have a way to tag individual 
messages in a mailbox using ANNOTATE, and have the server automatically 
expose the list of all tags in a mailbox via METADATA. That way searching 
all my mailboxes for messages with a specific tag can be broken in two - 
first LISTEXT to find matching mailboxes, then SEARCH within each. That 
avoids the need to SEARCH every mailbox.

-- 
Cyrus Daboo

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 23 Aug 2006 13:27:52 +0100

> Hi Alexey,

Hi Cyrus,

> I take it this will use the METADATA extension?

We are thinking about LISTEXT extension, which can be implemented using 
METADATA.

> If so, you will also need to write a LISTEXT/METADATA extension to 
> allow clients to 'search' for mailboxes containing 'tags' (those 
> mailboxes may not always be at the top-level of a hierarchy).

Exactly.

> BTW Speaking of tagging, it would be handy to have a way to tag 
> individual messages in a mailbox using ANNOTATE, and have the server 
> automatically expose the list of all tags in a mailbox via METADATA. 
> That way searching all my mailboxes for messages with a specific tag 
> can be broken in two - first LISTEXT to find matching mailboxes, then 
> SEARCH within each. That avoids the need to SEARCH every mailbox.

Good idea (but might be difficult for servers), write a draft :-).

---

From: Randall Gellens <[email-masked]>
Date: Wed, 23 Aug 2006 10:26:50 -0700

Hi Zoltan,

At 8:11 AM +0300 8/23/06, <[email-masked]> wrote:

>   >Doing it on the client is actually more
>  the Trash mailbox

Even if there was a mechanism to identify the Trash mailbox, we still 
have two problems: (1) existing clients won't use it; and (2) there 
is no way to know the original mailbox for messages which are in the 
Trash -- hence there is no way to properly undelete messages.

Of course, clients can be updated to start using the mechanism to 
identify the Trash mailbox.  But if clients have to be updated 
anyway, perhaps they can be updated to use the better Trash 
mechanism?  One which would allow them to (1) show the user a Trash 
mailbox, (2) successfully undelete messages, and (3) be more 
efficient in bandwidth and memory.

-------------- Randomly-selected tag: ---------------
The curse of all Art is that the devotee or disciple is always more
certain than the Priest.                          --Rudyard Kipling