[lemonade] Special-Purpose Mailboxes (was Notifications for multiple devices per user)

[Randall Gellens <randy at qualcomm.com>]

At 12:27 PM +0300 8/1/06, <Zoltan.Ordogh at nokia.com> wrote:
>  I would like to express my support on "define an standardized list 
> of Annotations for this and other such "special" mailboxes".
>  Identifying the special folders does not mean that they are going 
> to be used in every implementation, while it gives the benefit of 
> knowing what/where are those "special" mailboxes as well as helps a 
> lot with localization issues.
>
>  I think the following "special" mailboxes should be identified:
>  Trash: to store emails that have been deleted by the user - but not 
> marked as deleted yet e.g. expunge won't purge them.
>  Calendar: to store emails that contain vCalendar or other content 
> that includes calendar information.
>  Contacts: to store emails that contain vCard or other content that 
> includes contact information.
>  Drafts: to store emails that the user composed but did not send yet.
>  Junk: to store emails that the server decided to isolate.
>  Sent: to store emails that the use has sent.
>
>  I understand Draft, Trash, Junk and Sent would be the most often 
> used ones, while Contacts and Calendar would be used less often.

I agree that clients need a way to cooperate on which mailboxes are 
used for special purposes.  The metadata (a/k/a annotatemore) draft 
is one potential way to do this, but it has a problem: while clients 
can use it to discover that a specific mailbox has been tagged with a 
special purpose, I'm not sure they can use it to go the other way: 
connect to a server and learn which mailbox to use for a specific 
special purpose.  We could hack around this by putting an annotation 
on Inbox, but that has the potential for inconsistent states, which 
would be a problem.

ACAP does provide a way to do just that: it can tell a client the 
name of the mailbox to use for each special purpose.

Because of the many problems with Trash mailboxes (as documented in 
Dave's Trash draft), I can see benefit in having a recommended 
alternative, such as the logical Trash mailbox concept, improved 
through extensions if needed.  Given the widespread use of Trash 
mailboxes, I can also see benefit in having a way to identify to 
clients which mailboxes are so used by other clients.  However, I can 
also see three reasons not to do this: (1) it seems unlikely that 
existing clients will be updated to specify the Trash mailbox they 
are using, so having a way for them to do so won't help; (2) since 
existing clients use different names for the Trash mailbox, anyone 
using multiple clients probably has multiple Trash mailboxes; (3) it 
is unclear that mobile clients will want to synchronize a Trash 
mailbox created by other clients: why waste bandwidth and memory 
caching messages that the user has already marked for deletion?
--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Television is simply automated day-dreaming.
      --Lee Lovinger, _Quote_, July 30, 1967

_______________________________________________
lemonade mailing list
lemonade at ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade