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

From: "Ben Last" <[email-masked]>
Date: Mon, 31 Jul 2006 13:23:51 +0100

>At Thu, 22 Jun 2006 11:38:50 -0700, Randall Gellens wrote:
>>At 3:40 PM +0300 6/22/06, <Zoltan.Ordogh at nokia.com> 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.

At the risk of following up an earlier post after an excessive delay:
has there been discussion on the list of the same effect happening with
renaming of whole folders?  That is, if folder A is renamed as folder B
using one IMAP client, other clients will see A vanish and B appear,
with no way to tell that they are the same folder?  We're currently
seeing this as the worst of all repeated-download scenarios.

Also, on a related topic, despite considerable Googling I haven't
managed to track down whether there are discussions on metadata for
folders.  For example, one server vendor has recommended to us (we're
developing a mobile Symbian LEMONADE client) that we identify the Trash
folder created by their webmail interface by looking for the name
"Trash".  The major problems with this approach are that (a) the name of
the Trash folder varies by language & locale, and is customizable by the
mail server operator and (b) the name of that and all other folders
(except the Inbox) are editable by the mailbox user.  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?

Apologies if asking the question intrudes on far more useful and
relevant list traffic! :)

Regards to all
ben

Ben Last
EMCC Software
[email-masked]

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

---

From: Mark Crispin <[email-masked]>
Date: Mon, 31 Jul 2006 08:34:44 -0700 (PDT)

On Mon, 31 Jul 2006, Ben Last wrote:
> Thus we have no

One simple answer is "don't use a Trash mailbox, use the native IMAP 
delete/expunge model instead."

For me, the razor of the quality of an IMAP client implemention is whether 
or not it uses a Trash mailbox.  If it does, it is poor-quality by [my] 
definition.  It indicates an unimaginative client author who expects data 
in a store to implement and mirror GUI artifacts.  Such individuals tend 
to do things like "hmm, it says here that the * wildcard is harmful and 
should be avoided.  OK, I will a %/% wildcard, and walk the tree manually 
with multiple LIST commands."

I find it amusing that the same working group that is so obsessed with 
minimizing downloads would even consider a Trash mailbox, given the 
enormous costs that it imposes.  Specifically, unlike the native IMAP 
delete/expunge model, there is no way in Trash to undelete a message 
without creating a completely new instance of the message in the mailbox.

The above is my opinion, and may not be shared by others.  But I have a 
right to my opinion.

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...

-- 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: Tony Hansen <[email-masked]>
Date: Mon, 31 Jul 2006 15:43:59 -0400

Mark Crispin wrote:
> constitutes a sent-message mailbox with no wiggle-room for fools to
> create non-interoperable situations.  ACAP was supposed to solve that
> problem...

Can we define an standardized list of Annotations for this and other
such "special" mailboxes?

	Tony Hansen
	[email-masked]

---

From: Dave Cridland <[email-masked]>
Date: Mon, 31 Jul 2006 23:07:22 +0100

On Mon Jul 31 16:34:44 2006, Mark Crispin wrote:
> 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).

> 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

---

From: Mark Crispin <[email-masked]>
Date: Mon, 31 Jul 2006 15:15:28 -0700 (PDT)

On Mon, 31 Jul 2006, Dave Cridland wrote:
> (Which was sufficiently contentious that I've not submitted, but will do if 
> there's demand).

Perhaps it should be, as an individual Informative RFC.

> 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.

I was under the impression that we were talking about a sent-messages 
mailbox, not a drafts or outgoing staging mailbox.  It is, indeed, 
important that the difference between the three (not two!) needs to be 
clearly identified.

If the same mailbox is used for more than one of these purposes (and I 
understand the attraction for doing so), then the means to distinguish 
the state of an individual message needs to be clearly defined; as is the 
means by which this state transitions.  These means need to be 
bulletproof, for some value of "bulletproof".

> 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.

This is what the OP referred to.  However, solving this issue depends on 
solving the first issue.

-- Mark --

http://panda.com/mrc