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

From: <[email-masked]>
Date: Wed, 21 Jun 2006 15:32:41 +0300

Dave, I have this thought:
If there was a MOVE command for IMAP, it would be easy I think.
This (future) MOVE extension would move email(s) and/or folders (even recursively if needed) without coping/deleting the emails directly to another folder preserving the message-id.
Then, the client could easily use MOVE to put all deleted messages to a specific folder (Trash, Deleted item, etc), right?
Then, there would be no need to use the flags at all - those messages in the Trash folder would be just normal emails until the user decides to permanently delete those emails.
This should be easy to specify, right?

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: 21 June, 2006 14:01
To: Ordogh Zoltan (Nokia-TP-MSW/Tampere)
Cc: Enhancements to Internet email to support diverse service enivronments; Burger, Eric; Randall Gellens; Ionescu Catalin (Nokia-TP-MSW/Tampere)
Subject: RE: [lemonade] Notifications for multiple devices per user

On Wed Jun 21 11:15:29 2006, [email-masked] wrote:
> Thank You Dave and others,
> Would it be possible to enhance this?

I don't believe so, no.

To present a trash mailbox similar to the typical desktop metaphor, you would need to handle the equivalent of multi-mailbox backed virtual folders whose backing was detirmined in realtime using wildcards expanded according to the current user.

I sincerely doubt that this is a practical proposition for many server implementations, and it would be extremely difficult to specify.

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

---

From: Dave Cridland <[email-masked]>
Date: Wed, 21 Jun 2006 14:19:08 +0100

> If there was a MOVE command for IMAP, it would be easy I think.

No, it's the same issue, albeit you miss out a round-trip.

> This (future) MOVE extension would move email(s) and/or folders 
> (even recursively if needed) without coping/deleting the emails 
> directly to another folder preserving the message-id.

RENAME already moves mailboxes.

A MOVE is directly and completely equivalent to a sequence of COPY, 
STORE, UID EXPUNGE, albeit the latter requires UIDPLUS support.

> Then, the client could easily use MOVE to put all deleted messages 
> to a specific folder (Trash, Deleted item, etc), right?

Wrong. :-)

> Then, there would be no need to use the flags at all - those 
> messages in the Trash folder would be just normal emails until the 
> user decides to permanently delete those emails.
No. The problem is that this only works for personal mailboxes. 
Shared mailboxes would require a shared trash mailbox. For a shared 
trash mailbox, you'd need per-message ACLs, since you presumably want 
to have the same rights on a message both before and after it's 
deleted.

Moreover, this wouldn't then work interoperably with all the existing 
clients which expect an in-situ two-stage deletion mechanism.

Dave.

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 21 Jun 2006 09:21:34 -0400

Hi Zoltan,

--On June 21, 2006 3:32:41 PM +0300 [email-masked] wrote:

> This (future) MOVE extension would move email(s) and/or folders (even
> recursively if needed) without coping/deleting the emails directly to
> another folder preserving the message-id. Then, the client could easily
> use MOVE to put all deleted messages to a specific folder (Trash, Deleted
> item, etc), right? Then, there would be no need to use the flags at all -
> those messages in the Trash folder would be just normal emails until the
> user decides to permanently delete those emails. This should be easy to
> specify, right?

Unfortunately the idea of MOVE has been shot down many times in the past - 
I suggest you review IMAP and IMAPext mailing lists to see the discussion 
of all that. Frankly its not worth fighting to get it now. Yes it would 
make Trash and move operations (which are a much more common user action 
than a copy) more reliable - but server vendors in the past have made it 
plain that its 'hard' to do so there was never any interest in implementing.

Frankly I think the discussion of a statement that clients should not use 
Trash is all wrong - what we should do is write a 'best common practices 
for implementing Trash properly with IMAP' document to help client author's 
get it done right (subject to the limitations that do exist).

-- 
Cyrus Daboo

---

From: Mark Crispin <[email-masked]>
Date: Wed, 21 Jun 2006 08:43:06 -0700 (PDT)

On Wed, 21 Jun 2006, Cyrus Daboo wrote:
> Trash is all wrong - what we should do is write a 'best common practices for 
> implementing Trash properly with IMAP' document to help client author's get 
> it done right (subject to the limitations that do exist).

Clients definitely should NOT use a mailbox as Trash in the IMAP protocol.

What clients present to the user as a graphical interface is another 
matter entirely.

-- 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: Cyrus Daboo <[email-masked]>
Date: Wed, 21 Jun 2006 11:46:32 -0400

Hi Mark,

--On June 21, 2006 8:43:06 AM -0700 Mark Crispin <[email-masked]> 
wrote:

>> Frankly I think the discussion of a statement that clients should not
>> use  Trash is all wrong - what we should do is write a 'best common
>> practices for  implementing Trash properly with IMAP' document to help
>> client author's get  it done right (subject to the limitations that do
>> exist).
>

Well how are you supposed to do trash accumulated from multiple mailboxes? 
And no, having a 'virtual' trash per-mailbox is not acceptable.

-- 
Cyrus Daboo

---

From: Mark Crispin <[email-masked]>
Date: Wed, 21 Jun 2006 09:15:00 -0700 (PDT)

> And no, having a 'virtual' trash per-mailbox is not acceptable.

Well how are you supposed to put back a message from the trash without 
causing a new instance of that message?  You can't if you use a trash 
mailbox!

Sometimes, it just isn't possible to get everything that you want; and you 
have to choose the least harmful alternative.

Personally, I think that it is overrated to have a feature of having a 
trash that, at all times, holds all deleted messages in all mailboxes. 
There simply is no user expectation of a corresponding feature in any 
other facility!

Filesystems?  If you study the Windows or Macintosh filesystems carefully 
(I have), you'll discover that the trash is far less integrated that you 
might expect.  You MAY have trash sharing between two local hard drives, 
but typically not with network mounted filesystems.  Removable filesystems 
often implement dragging to trash as immediate delete then expunge with no 
undelete possible.  If you unmount a hard drive, its part of the trash is 
immediately emptied.

To put it another way, the designers of trash in other contexts have not 
attempted to do what is alleged to be "necessary" in IMAP.  When you talk 
about "user expectations", you really mean an expectation that you 
created.  In the course of creating that expectation, you damage other 
expectations that IMAP intended to offer.

One of these damaged expectations is the ability, when over disk quota, to 
be able to delete some data and by doing so get under disk quota.

Another one is the ability to undo a delete.  IMAP delete is undoable, but 
moving to a trash mailbox is not.

-- Mark --

http://panda.com/mrc

---

From: Mark Crispin <[email-masked]>
Date: Wed, 21 Jun 2006 09:16:37 -0700 (PDT)

On Wed, 21 Jun 2006, Arnt Gulbrandsen wrote:
> Mark Crispin writes:
>> What clients present to the user as a graphical interface is another matter 
>> entirely.
> How about LISTing all of the user's mailboxes, SELECTing each in turn, and 
> using SEARCH DELETED to present a Trash mailbox?

That's a very good thing for a competitor's client to do, especially if 
you also control the server.  Anything that makes your competitor's 
product work substantially worse than your product is always a good 
thing.

-- Mark --

http://panda.com/mrc

---

From: Randall Gellens <[email-masked]>
Date: Wed, 21 Jun 2006 12:25:42 -0700

>  This should be easy to specify, right?

The UIDPLUS extension allows a client to do a COPY and learn the UID 
of the message in its new mailbox.  This becomes effectively a MOVE. 
However, with this or your MOVE suggestion, no other client knows 
what happened.  To other clients, it appears that a message was 
deleted and a new message appeared in a different mailbox.  Other 
clients don't know these are the same message.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
I have made it a rule, whenever in my power, to avoid becoming the
draughtsman of papers to be reviewed by a public body.
              --Benjamin Franklin

---

From: Randall Gellens <[email-masked]>
Date: Wed, 21 Jun 2006 12:36:07 -0700

At 11:46 AM -0400 6/21/06, Cyrus Daboo wrote:

>  Well how are you supposed to do trash accumulated from multiple 
> mailboxes? And no, having a 'virtual' trash per-mailbox is not 
> acceptable.

Is the problem with presenting a client-generated virtual Trash 
mailbox that it would only contain messages in mailboxes that have 
been locally synched?

I suppose clients could present a Trash mailbox that contains child 
mailboxes, each of which has the same name as a mailbox that the 
client synchronizes.  That might help, but I'm not sure.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
The fewer episodes of a TV show one has seen, the greater the chance
that one has already viewed the episode one is watching.
                                                   --Randall Gellens

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 21 Jun 2006 17:50:47 +0200

> What clients present to the user as a graphical interface is another 

How about LISTing all of the user's mailboxes, SELECTing each in turn, 
and using SEARCH DELETED to present a Trash mailbox?

Arnt

---

From: Dave Cridland <[email-masked]>
Date: Wed, 21 Jun 2006 12:00:32 +0100

I don't believe so, no.

To present a trash mailbox similar to the typical desktop metaphor, 
you would need to handle the equivalent of multi-mailbox backed 
virtual folders whose backing was detirmined in realtime using 
wildcards expanded according to the current user.

I sincerely doubt that this is a practical proposition for many 
server implementations, and it would be extremely difficult to 
specify.

Dave.

---

From: <[email-masked]>
Date: Wed, 21 Jun 2006 14:47:02 +0300

Ok, thank You. It seems I must accept this fact. 

-----Original Message-----
From: ext Dave Cridland [mailto:[email-masked]] 
Sent: 21 June, 2006 14:01
To: Ordogh Zoltan (Nokia-TP-MSW/Tampere)
Cc: Enhancements to Internet email to support diverse service enivronments; Burger, Eric; Randall Gellens; Ionescu Catalin (Nokia-TP-MSW/Tampere)
Subject: RE: [lemonade] Notifications for multiple devices per user

I don't believe so, no.

Dave.

---

From: Dave Cridland <[email-masked]>
Date: Wed, 21 Jun 2006 12:00:32 +0100

I don't believe so, no.

Dave.

---

From: <[email-masked]>
Date: Wed, 21 Jun 2006 14:47:02 +0300

-----Original Message-----
From: ext Dave Cridland [mailto:[email-masked]] 
Sent: 21 June, 2006 14:01
To: Ordogh Zoltan (Nokia-TP-MSW/Tampere)
Cc: Enhancements to Internet email to support diverse service enivronments; Burger, Eric; Randall Gellens; Ionescu Catalin (Nokia-TP-MSW/Tampere)
Subject: RE: [lemonade] Notifications for multiple devices per user

I don't believe so, no.

Dave.

---

From: Ray Cromwell <[email-masked]>
Date: Wed, 21 Jun 2006 17:50:39 -0700

Randall Gellens wrote:

> However, with this or your MOVE suggestion, no other client knows what 
> happened.  To other clients, it appears that a message was deleted and 
> a new message appeared in a different mailbox.  Other clients don't 
> know these are the same message.

 Ah,  but we could solve that problem but introducing revision control 
semantics to IMAP,  so clients could track the entire history of 
modification to the message j/k :)  Hmm, the pieces are already there. 
Maildir + SVN.

-Ray

---

From: <[email-masked]>
Date: Thu, 22 Jun 2006 15:40:29 +0300

Hi Randall,
this is exactly what I tried to avoid with the MOVE command. But there is another aspect to it as well: if the message gets a new ID, the client will have to re-download a mail that it already has. Repeated transfer bad.

-----Original Message-----
From: ext Randall Gellens [mailto:[email-masked]] 
Sent: 21 June, 2006 22:26
To: Ordogh Zoltan (Nokia-TP-MSW/Tampere)
Cc: [email-masked]
Subject: RE: [lemonade] Notifications for multiple devices per user

At 3:32 PM +0300 6/21/06, <[email-masked]> wrote:

> another folder preserving the message-id.
>  Then, the client could easily use MOVE to put all deleted messages to 
> a specific folder (Trash, Deleted item, etc), right?
>  Then, there would be no need to use the flags at all - those messages 
> in the Trash folder would be just normal emails until the user decides 
> to permanently delete those emails.

The UIDPLUS extension allows a client to do a COPY and learn the UID of the message in its new mailbox.  This becomes effectively a MOVE. 
However, with this or your MOVE suggestion, no other client knows what happened.  To other clients, it appears that a message was deleted and a new message appeared in a different mailbox.  Other clients don't know these are the same message.
--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: --------------- I have made it a rule, whenever in my power, to avoid becoming the draughtsman of papers to be reviewed by a public body.
              --Benjamin Franklin

---

From: <[email-masked]>
Date: Thu, 22 Jun 2006 15:38:45 +0300

Hi Cyrus,
I did not follow IMAP and IMAPEXT work in the past unfortunately.
I do not see why would it be hard on the server, nor any reason to drop it - this is a discussion that we would not have to repeat here again so I just accept what You have wrote.
As a last resort, we should go for the best practice document.
Thank You.

-----Original Message-----
From: ext Cyrus Daboo [mailto:[email-masked]] 
Sent: 21 June, 2006 16:22
To: Ordogh Zoltan (Nokia-TP-MSW/Tampere); [email-masked]
Cc: [email-masked]
Subject: RE: [lemonade] Notifications for multiple devices per user

Hi Zoltan,

--On June 21, 2006 3:32:41 PM +0300 [email-masked] wrote:

> another folder preserving the message-id. Then, the client could 
> easily use MOVE to put all deleted messages to a specific folder 
> (Trash, Deleted item, etc), right? Then, there would be no need to use 
> the flags at all - those messages in the Trash folder would be just 
> normal emails until the user decides to permanently delete those 
> emails. This should be easy to specify, right?

Unfortunately the idea of MOVE has been shot down many times in the past - I suggest you review IMAP and IMAPext mailing lists to see the discussion of all that. Frankly its not worth fighting to get it now. Yes it would make Trash and move operations (which are a much more common user action than a copy) more reliable - but server vendors in the past have made it plain that its 'hard' to do so there was never any interest in implementing.

Frankly I think the discussion of a statement that clients should not use Trash is all wrong - what we should do is write a 'best common practices for implementing Trash properly with IMAP' document to help client author's get it done right (subject to the limitations that do exist).

--
Cyrus Daboo

---

From: <[email-masked]>
Date: Thu, 22 Jun 2006 15:42:57 +0300

Hi Ray,
would not be such tracking 'too heavy' on the constrained devices (which we are tying to address)?

-----Original Message-----
From: ext Ray Cromwell [mailto:[email-masked]] 
Sent: 22 June, 2006 03:51
To: [email-masked]
Subject: Re: [lemonade] Notifications for multiple devices per user

> know these are the same message.

 Ah,  but we could solve that problem but introducing revision control semantics to IMAP,  so clients could track the entire history of modification to the message j/k :)  Hmm, the pieces are already there. 
Maildir + SVN.

-Ray

---

From: Randall Gellens <[email-masked]>
Date: Thu, 22 Jun 2006 11:38:50 -0700

At 3:40 PM +0300 6/22/06, <[email-masked]> wrote:

>  Hi Randall,
>  this is exactly what I tried to avoid with the MOVE command. But 
> there is another aspect to it as well: if the message gets a new 
> ID, the client will have to re-download a mail that it already has. 
> Repeated transfer bad.

Hi Zoltan,

The change in UID and hence re-downloading isn't another aspect, it's 
the primary aspect of other clients not knowing that these are the 
same message.  The original client, the one that did the COPY, can 
know that these are the same message because UIDPLUS allows it to 
learn the new UID.  The client can then update its cache to reflect 
this.

>  The UIDPLUS extension allows a client to do a COPY and learn the 
> UID of the message in its new mailbox.  This becomes effectively a 
> MOVE.
>  -------------- Randomly-selected tag: --------------- I have made 
> it a rule, whenever in my power, to avoid becoming the draughtsman 
> of papers to be reviewed by a public body.
>                --Benjamin Franklin
>

-------------- Randomly-selected tag: ---------------
In any collection of data, the figure most obviously correct,
beyond all need of checking, is the mistake.