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

From: Randall Gellens <[email-masked]>
Date: Thu, 10 Aug 2006 18:19:27 -0700

At 12:27 PM +0300 8/1/06, <[email-masked]> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

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

Randall Gellens [mailto:[email-masked]] wrote, at 11 August 2006
02:19:
>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?

Certainly my motivation for discussing this general area was issue (3)
above: we have no interest in implementing a Trash mailbox
(deleted/expunge works for us) but we do definitely want to avoid
showing other clients special-purpose mailboxes to the user, or
synchronzing them.

Randall: I respectfully disagree that your arguments above are arguments
against providing ways for clients to identify mailboxes.  Specific
responses:
(1) But even if they don't use a Trash, they may use Sent
Items/Drafts/Outbox mailboxes.
(2) But if clients that currently do use a Trash mailbox could spot an
existing one and re-use it, that would avoid the proliferation of
Trash/Deleted Items/Wastebasket mailboxes that can occur.
(3) If a client can identify other clients' Trash mailbox, it can avoid
synchronizing it.  If it can't, there's the risk that it will be
synchronized inadvertently. That would also confuse the end user: seeing
a Trash mailbox that doesn't hold newly deleted messages.

At least one of our use cases involves three clients in use for any one
account:
* A desktop client such as Eudora or Thunderbird
* A webmail client provided by the server vendor
* A mobile client

This is actually not an unusual setup for users in our target market, so
anything that helps inter-client interoperability is key for us.

ACAP would help with the Special-purpose Mailboxes problem, but as far
as I can tell, there are very few servers that implement it (and none of
the target server vendors for our client have any plans to implement
it).  For a client developer, especially in the mobile phone market, the
assumption must always be that one must interoperate with what is out
there now.  We have no control over the servers with which a customer
would expect our client to interoperate.  But given that the Lemonade
profiles and standards have a fair degree of momentum now, raising
problems such as special-purpose mailboxes here is about the best chance
we have of making our lives easier in the future!

Regards to all
Ben
EMCC Software Ltd

---

From: Ray Cromwell <[email-masked]>
Date: Fri, 11 Aug 2006 00:33:34 -0700

Randall Gellens wrote:

> 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 
> 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.
>
I think METADATA can accomplish this with Server Entries too, e.g. 
"/specialmailboxes" -> trash.shared = name of trash mailbox, 
sent.shared=name of sent mailbox, draft.shared=name of draft mailbox, 
etc. I think there may be cases where you don't neccessarily want to 
indicate a real mailbox to be used, but merely want to indicate a 
mnemonic that the client should use for customer support purposes (e.g. 
there is no real "Trash" mailbox on the server, but the clients support 
best practices of using flags to group deleted messages into a special 
Trash virtual "mailbox" on the client. Cingular may want all clients to 
call this "Trash" in the US, but Orange may want all clients to call it 
"Rubbish", and Bell-Microsoft might want it called "Recycle Bin" :) ) 
All of this modulo i18n/l10n concerns. Granted, it's not a compelling 
usecase, just stream of consciousness.

-Ray

---

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

Ray Cromwell [mailto:[email-masked]] wrote, at 11 August 2006
08:34:
>Cingular may want all clients to call this "Trash" in the US, but
Orange may want
>all clients to call it "Rubbish", and Bell-Microsoft might want it
called "Recycle Bin" :)
Actually, that'd be "Wastebasket" or "Deleted Items" in the UK :)
"Rubbish" would be like Americans calling it "Garbage"... perhaps that'd
be for spam messages.

Regards
ben
EMCC Software Ltd