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

From: "Burger, Eric" <[email-masked]>
Date: Tue, 13 Jun 2006 05:01:07 -0400

I would offer that nothing changes for VFOLDERs referencing VFOLDERs.

Take the case of MIDDLE referencing BOTTOM, where BOTTOM is a real
mailbox.  In order to do the right thing when BOTTOM is manipulated
(renamed or deleted), the server has to have a data structure with all
of the VFOLDERs that reference the base folder.  In other words, the
server needs to keep track of VFOLDER dependencies, whether we allow
recursive VFOLDER definition or not.  For example, if the user renames
BOTTOM to BASE, the expression calculating MIDDLE needs to be updated to
reference BASE.

Once that infrastructure is in place, then recursion happens for free if
we treat VFOLDERs as mailboxes.  In the example given below, we have TOP
referencing the VFOLDER MIDDLE referencing the real mailbox BOTTOM.  If
we manipulate MIDDLE, like deleting it, it would take the appropriate
action on TOP.  In this case, it would delete TOP.  Likewise, if we
delete BOTTOM, that deletes MIDDLE, which deletes TOP.

-----Original Message-----
From: Randall Gellens [mailto:[email-masked]] 
Sent: Friday, June 09, 2006 8:59 PM
To: Lisa Dusseault; Alexey Melnikov
Cc: Lemonade WG
Subject: Re: [lemonade] Notifications for multiple devices per user

At 4:40 PM -0700 6/9/06, Lisa Dusseault wrote:

>  There's an alternative architecture for the same use case, and 
> that's to let the notification server (SIP or XMPP, in particular) 
> do fanout.  Then the IMAP server simply sends the notification to 
> the user's notification address (plus some application field if 
> specified) and the user decides which devices subscribe to those 
> notifications.
>
>  I could be wrong but I think some of those kinds of servers can 
> gateway to SMS so that would even work in.
>
>  lisa
>
>  On Jun 7, 2006, at 5:54 AM, Alexey Melnikov wrote:
>
>>  In my private discussion with Zoltan he raised a question about 
>> IMAP server ability to store notification information (i.e. where 
>> the notification is to be sent) for multiple devices per user. Is 
>> this the requirement the WG wants to consider when thinking about 
>> notifications?

Depending on the device capability, it is conceivable that the user 
might want different criteria.  So the more capable the device, the 
more state changes and new messages it is aware of, but the more 
limited devices would only know about the most urgent messages.

I had been thinking that this would be handled by Sieve, with various 
rules sending notifications to different devices.  This would imply 
that the rules would need to be updated as devices change.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Chance that an American cannot name a single right protected by the
First Amendment: 1 in 3.                           (Harper's Index)

_______________________________________________
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: <[email-masked]>
Date: Tue, 20 Jun 2006 13:14:39 +0300

It only gets more difficult when the user can rename a real folder (e.g. Deleted items->Trash).
BTW: can the user do this?
If yes, where is the mapping stored? (mapping that tell that "Trash" is the place to store deleted mails).
Or, is it achieved using "decorative names" - how to assign a "decorative name" to a folder? (decorative name meaning the name of the folder that is supposed to be shown on the UI only).
Thank You.

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

-----Original Message-----
From: ext Burger, Eric [mailto:[email-masked]] 
Sent: 13 June, 2006 12:01
To: Randall Gellens
Cc: Lemonade WG
Subject: RE: [lemonade] Notifications for multiple devices per user

Take the case of MIDDLE referencing BOTTOM, where BOTTOM is a real mailbox.  In order to do the right thing when BOTTOM is manipulated (renamed or deleted), the server has to have a data structure with all of the VFOLDERs that reference the base folder.  In other words, the server needs to keep track of VFOLDER dependencies, whether we allow recursive VFOLDER definition or not.  For example, if the user renames BOTTOM to BASE, the expression calculating MIDDLE needs to be updated to reference BASE.

Once that infrastructure is in place, then recursion happens for free if we treat VFOLDERs as mailboxes.  In the example given below, we have TOP referencing the VFOLDER MIDDLE referencing the real mailbox BOTTOM.  If we manipulate MIDDLE, like deleting it, it would take the appropriate action on TOP.  In this case, it would delete TOP.  Likewise, if we delete BOTTOM, that deletes MIDDLE, which deletes TOP.

-----Original Message-----
From: Randall Gellens [mailto:[email-masked]]
Sent: Friday, June 09, 2006 8:59 PM
To: Lisa Dusseault; Alexey Melnikov
Cc: Lemonade WG
Subject: Re: [lemonade] Notifications for multiple devices per user

At 4:40 PM -0700 6/9/06, Lisa Dusseault wrote:

>  There's an alternative architecture for the same use case, and that's 
> to let the notification server (SIP or XMPP, in particular) do fanout.  
> Then the IMAP server simply sends the notification to the user's 
> notification address (plus some application field if
>>  In my private discussion with Zoltan he raised a question about IMAP 
>> server ability to store notification information (i.e. where the 
>> notification is to be sent) for multiple devices per user. Is this 
>> the requirement the WG wants to consider when thinking about 
>> notifications?

Depending on the device capability, it is conceivable that the user might want different criteria.  So the more capable the device, the more state changes and new messages it is aware of, but the more limited devices would only know about the most urgent messages.

I had been thinking that this would be handled by Sieve, with various rules sending notifications to different devices.  This would imply that the rules would need to be updated as devices change.
--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: --------------- Chance that an American cannot name a single right protected by the
First Amendment: 1 in 3.                           (Harper's Index)

---

From: Dave Cridland <[email-masked]>
Date: Tue, 20 Jun 2006 13:49:47 +0100

On Tue Jun 20 11:14:39 2006, [email-masked] wrote:
> If yes, where is the mapping stored? (mapping that tell that 
> "Trash" is the place to store deleted mails).

Deleted messages are stored in the folder they were deleted from. 
IMAP has a two stage delete, first you flag, then you EXPUNGE.

You can think of it as "first you delete, then you empty trash", if 
you prefer, and it can be presented much like that.

Physically moving the messages to a seperate folder involves first 
copying them, then going through IMAP's two-stage delete, and at some 
point, selecting the trash mailbox, and going through IMAP's 
two-stage delete there, too, in order to empty trash. It's possible, 
but given that IMAP already provides the two stage deletion that a 
Trash metaphor seeks to provide, I've never seen the point of going 
through so many round-trips. In addition, you can run out of quota 
whilst "deleting" messages using that mechanism, which yields quite 
amusing error messages.

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

---

From: Mark Crispin <[email-masked]>
Date: Tue, 20 Jun 2006 08:28:06 -0700 (PDT)

On Tue, 20 Jun 2006, Dave Cridland wrote:
> Physically moving the messages to a seperate folder involves first copying 
> them, then going through IMAP's two-stage delete, and at some point, 
> selecting the trash mailbox, and going through IMAP's two-stage delete there, 
> too, in order to empty trash. It's possible, but given that IMAP already 
> provides the two stage deletion that a Trash metaphor seeks to provide, I've 
> never seen the point of going through so many round-trips. In addition, you 
> can run out of quota whilst "deleting" messages using that mechanism, which 
> yields quite amusing error messages.

There's another, far worse, consequence of using a Trash mailbox instead 
of the native IMAP delete/expunge model.  You can not restore a deleted 
message with Trash; you are forced to write a *new* copy, with a new UID, 
that will get re-downloaded by other clients.  This is even for a 
fumble-finger that is immediately undone.

I understand why novice programmers do the move to a Trash mailbox: they 
can not separate what is presented to the user from what goes on 
internally.

They also think that they are "saving work" by doing this, since "empty 
trash" becomes a one-shot operation on a single mailbox.  Never mind all 
the extra work that is undertaken to get to this stage!

-- 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: Randall Gellens <[email-masked]>
Date: Tue, 20 Jun 2006 11:25:23 -0700

At 1:49 PM +0100 6/20/06, Dave Cridland wrote:

> copying them, then going through IMAP's two-stage delete, and at 
> some point, selecting the trash mailbox, and going through IMAP's 
> two-stage delete there, too, in order to empty trash. It's 
> possible, but given that IMAP already provides the two stage 
> deletion that a Trash metaphor seeks to provide, I've never seen 
> the point of going through so many round-trips. In addition, you 
> can run out of quota whilst "deleting" messages using that 
> mechanism, which yields quite amusing error messages.

A client can certainly present deleted messages as being in a 
separate (virtual) mailbox even though the messages remain in their 
original mailbox.  This has a few advantages, including the ease of 
restoring the message to its former mailbox if the user undeletes it. 
However, the clients that I've used don't do that.  They either copy 
the message to a trash mailbox and then delete and expunge it from 
the former mailbox, or they leave it where it is, and either show it 
to the user (marked as deleted) or hide it.

Are there clients that present deleted messages as being in a 
(virtual) trash mailbox?

I suppose one concern would be user confusion: if the user looks at 
the mailboxes using another client or a web interface, the virtual 
trash mailbox would not be there.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Attaccabottonai (ah-TAHKA-bo-TONE-eye; Italian; noun): a doleful bore
who buttonholes people and tells sad, pointless tales.

---

From: Mark Crispin <[email-masked]>
Date: Tue, 20 Jun 2006 11:27:27 -0700

On Tue, 20 Jun 2006, Randall Gellens wrote:
> Are there clients that present deleted messages as being in a (virtual) trash 
> mailbox?

I know that such exist, but I don't know their names.

-- Mark --

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

---

From: Dave Cridland <[email-masked]>
Date: Tue, 20 Jun 2006 20:18:24 +0100

On Tue Jun 20 19:25:23 2006, Randall Gellens wrote:
>>  You can think of it as "first you delete, then you empty trash", 
>> if you prefer, and it can be presented much like that.
>> 
>>  Physically moving the messages to a seperate folder involves 
>> first copying them, then going through IMAP's two-stage delete, 
>> and at some point, selecting the trash mailbox, and going through 
>> IMAP's two-stage delete there, too, in order to empty trash. It's 
> restoring the message to its former mailbox if the user undeletes 
> it. However, the clients that I've used don't do that.  They either 
> copy the message to a trash mailbox and then delete and expunge it 
> from the former mailbox, or they leave it where it is, and either 
> show it to the user (marked as deleted) or hide it.
> 
> 
It's easier to present them as "every mailbox has a trash can" - ie, 
don't present the trash as a distinct mailbox, present it as a 
feature of the mailbox. That way you don't have to emulate a 
multi-mailbox backed virtual folder.

I don't do this, although many of my users usually ask me how to stop 
it showing the deleted messages in the summary. (Define a view that 
does UNDELETED, and use that).

> trash mailbox would not be there.

Well, it would be if your web interface or other client read your 
preferences from a common location and knew to present deleted 
messages using the metaphor you preferred. We could write one. Call 
it ACAP. Maybe have an Email Account Dataset specification for this 
kind of stuff.

But that's just a crazy idea, I know.

Dave.

---

From: Lyndon Nerenberg <[email-masked]>
Date: Tue, 20 Jun 2006 23:14:38 -0700

> Are there clients that present deleted messages as being in a  

I have yet to come across one.  All the non-trash-folder clients I've  
worked with provide a switch that makes the deleted messages visible  
(or not) in the folder's message index list.

> trash mailbox would not be there.

Which leads me to conclude we desperately need a "Doh! Don't Do IMAP  
Trash This Way, And Here's Why" RFC.  Written in little tiny  
syllables, with a lot of pictures.

Why is it so hard for client writers to grok this concept?  I'm not  
asking this rhetorically.  It's such a simple concept that I'm  
stunned by how hard it seems to be for people to wrap their heads  
around it.  What do we need to do to explain the concept in a way  
that everyone "gets it" ???

--lyndon

---

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

On Wed Jun 21 07:14:38 2006, Lyndon Nerenberg wrote:
> Which leads me to conclude we desperately need a "Doh! Don't Do 
> IMAP  Trash This Way, And Here's Why" RFC.  Written in little tiny  
Well, I basically agree, so whilst I've not done the pictures, I've 
done my best to find and document the reasons why trash mailboxes are 
a bad idea on IMAP. Strangely, while thinking about them, I found a 
couple more (such as interaction with shared mailboxes, and reliance 
on UIDPLUS for any reasonable efficiency).

See 
http://svn.dave.cridland.net/svn/ietf-drafts/draft-cridland-imap-trash.xml 
for some XML2RFC source, or temporarily 
http://dave.cridland.net/draft-cridland-imap-trash.txt

I suggest that discussion of this, if anyone feels it's worthwhile, 
should probably take place on the IMAP protocol list, rather than 
here.

Dave.

---

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

Hi Dave,

--On June 21, 2006 12:05:48 PM +0100 Dave Cridland <[email-masked]> 
wrote:

> Well, I basically agree, so whilst I've not done the pictures, I've done
> my best to find and document the reasons why trash mailboxes are a bad
> idea on IMAP.

I'm sorry but this is just wrong - if the Trash metaphor is what users are 
comfortable with then that's what the client should use. The protocol 
should not dictate how information is presented to the user and should be 
flexible enough (within limits) to provide ways for clients to do that.

Lets face it, the main reason clients do Trash with IMAP is that that's 
what POP clients typically did plus users are already familiar and 
comfortable with that UI metaphor because that is what most file system 
browsers also use. I doubt very much it was done just because that's what 
the developers wanted.

-- 
Cyrus Daboo

---

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

On Wed Jun 21 14:14:30 2006, Cyrus Daboo wrote:
> --On June 21, 2006 12:05:48 PM +0100 Dave Cridland 
> <[email-masked]> wrote:
> 
> I'm sorry but this is just wrong - if the Trash metaphor is what 
> users are comfortable with then that's what the client should use. 
> The protocol should not dictate how information is presented to the 
> user and should be flexible enough (within limits) to provide ways 
> for clients to do that.
> 
> 
But the protocol simply doesn't provide that, and without some quite 
extraordinary server support, it won't.

I'm sure it's possible, in principle, for a server to present a Trash 
mailbox that is automatically populated with all messages marked with 
the \Deleted flag in any mailbox the current user has access to, but 
for the vast majority of implementations, I think that's impractical.

> Lets face it, the main reason clients do Trash with IMAP is that 
> that's what POP clients typically did plus users are already 
> familiar and comfortable with that UI metaphor because that is what 
> most file system browsers also use. I doubt very much it was done 
> just because that's what the developers wanted.

Indeed, users are familiar with a trash container with a relatively 
wide scope, and many client authors have provided such a container at 
either client-wide or server-wide scope.

The only mechanism I can see for providing that in client-side IMAP 
would involve continuously searching all available mailboxes for 
messages marked as \Deleted, and presenting the results as a locally 
generated virtual mailbox, or else using a real mailbox as an 
artificial trash mailbox, which has both interoperability and 
(lesser) efficiency problems.

The closest I can provide is a per-mailbox trash container, which is, 
I agree, a considerably reduced scope by comparison to what's 
typically implemented, and therefore expected, by the user. On the 
plus side, such a mechanism is fully interoperable with any server or 
client conforming to RFC3501 (Or, I think, even much older 
specifications).

You state in another message that what we should do in write a "best 
common practises for implementing Trash properly with IMAP", and 
that's one aim of what I've written - it may well be that there's a 
much better method for providing a metaphor closer to the expectation 
of the typical user, but I don't see it.

Dave.

---

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

Hi Dave,

--On June 21, 2006 2:34:09 PM +0100 Dave Cridland <[email-masked]> wrote:

> The only mechanism I can see for providing that in client-side IMAP would
> involve continuously searching all available mailboxes for messages
> marked as \Deleted, and presenting the results as a locally generated
> virtual mailbox, or else using a real mailbox as an artificial trash
> mailbox, which has both interoperability and (lesser) efficiency problems.

But that is exactly what I am talking about as that's how clients have 
already implemented it and that's what all the complaints about interop 
have been about. I don't care about 'virtual' trash - just about making the 
copy-to-Trash work (which for the most part it does).

-- 
Cyrus Daboo

---

From: Dave Cridland <[email-masked]>
Date: Wed, 21 Jun 2006 16:05:59 +0100

On Wed Jun 21 14:42:53 2006, Cyrus Daboo wrote:
> But that is exactly what I am talking about as that's how clients 
> have already implemented it and that's what all the complaints 
> about interop have been about. I don't care about 'virtual' trash - 
> just about making the copy-to-Trash work (which for the most part 
> it does).

I could suggest a method for finding the name of the mailbox to use, 
I suppose, by using NAMESPACE, but that adds another extension. I 
don't like relying on extensions to handle cases like deletion. Most 
of the other problems are insoluble, and I'm not even sure that "for 
the most part it does" is true, unless you only use clients that do a 
compatible trash mailbox.

Of course, there are especially poor ways to do trash mailboxes, and 
I can add text to warn against them.

Dave.

---

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

At 11:14 PM -0700 6/20/06, Lyndon Nerenberg wrote:

>  I have yet to come across one.  All the non-trash-folder clients 
> I've worked with provide a switch that makes the deleted messages 
> visible (or not) in the folder's message index list.
>
>>  I suppose one concern would be user confusion: if the user looks 
>> at the mailboxes using another client or a web interface, the 
>> virtual trash mailbox would not be there.
>

Don't do IMAP trash which way?  The Trash mailbox, the show/hide 
deleted messages, or the virtual trash mailbox way?

> that everyone "gets it" ???

Which concept (sorry for being dense)?

-------------- Randomly-selected tag: ---------------
Procedures!  Of course, that's what you'd use with a *sophisticated*
machine like this.  Procedures.    --'Ceaser Smith' in _Hot_Millions_

---

From: Lyndon Nerenberg <[email-masked]>
Date: Wed, 21 Jun 2006 15:38:34 -0600 (MDT)

> Don't do IMAP trash which way?  The Trash mailbox, the show/hide deleted 
> messages, or the virtual trash mailbox way?

Sorry ... I was referring to the "move it all into a single Trash mailbox" 
model.