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

From: "Ben Last" <[email-masked]>
Date: Tue, 1 Aug 2006 07:42:58 +0100

On 31 July 2006 16:35, Mark Crispin wrote:
>On Mon, 31 Jul 2006, Ben Last wrote:
>> 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?
>One simple answer is "don't use a Trash mailbox, use the native IMAP
delete/expunge model instead."
Thanks, Mark: an excellent point, and we do indeed use that model.
However, the server that's our primary development target provides a
webmail interface that creates its own "Deleted Items", "Sent Items" and
"Drafts" folders.  Thus there are strong suggestions that our client
should use these.  But since our client, as one might expect, is a
generic P-IMAP one, we don't want to hard-wire in folder names,
especially since (as I mentioned) these folder names are subject to
localization, customization and user-modification.

>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.
I understand your argument, but there are clients out there that do
this, and mobile LEMONADE-speaking clients such as ours must
interoperate with them.

>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...
Is there not a more general requirement; to be able to identify certain
"special-case" folders?  Some clients use a "Drafts/Sent" model, others
an "Drafts/Outbox/Sent" model.  Being able, from the results of a
variant of LIST, for example, to identify these folders by type, not
name, would make client development and interoperability with existing
clients much easier.  And whether one deprecates a Trash folder or not,
if a PC client creates it and other clients can identify it, then at
least they have the option to use it!

The same mechanism (some unambiguous way to identify folders without
basing it on names) could go some way to avoiding the huge
re-downloading cost of renaming or moving a folder.

Best regards to all
Ben

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

---

From: <[email-masked]>
Date: Tue, 1 Aug 2006 12:29:01 +0300

Mark,
Yes, this is certainly a good opinion, however it does not solve the problem of identifying the special mailboxes. 

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

-----Original Message-----
From: ext Mark Crispin [mailto:[email-masked]] 
Sent: 31 July, 2006 18:35
To: Ben Last
Cc: [email-masked]
Subject: RE: [lemonade] Notifications for multiple devices per user

> created by other IMAP clients.  Has there been discussion on this?

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: Mark Crispin <[email-masked]>
Date: Tue, 1 Aug 2006 08:36:22 -0700 (PDT)

> Yes, this is certainly a good opinion, however it does not solve the problem of identifying the special mailboxes.

You inadvertantly referred to a major problem by using the plural 
"mailboxes".

This is a slippery slope, and it opens up the way to define a Trash 
mailbox in IMAP.

I agree that we need a means to identify the location of sent messages.

I am less certain about drafts or a pending queue for outgoing messages 
(to be pulled by URLFETCH).  I would like to see a more convincing use 
case for multiple clients using the same name.  I tend to suspect that 
clients are less likely to be able to do useful things with a different 
client's draft than at first appearance.

I am completely opposed to any definition of a Trash mailbox in IMAP.

-- Mark --

http://panda.com/mrc

---

From: "Ben Last" <[email-masked]>
Date: Wed, 2 Aug 2006 07:38:21 +0100

>At 01 August 2006 16:36, Mark Crispin wrote:
>>Yes, this is certainly a good opinion, however it does not solve the
problem of identifying the special mailboxes.
"mailboxes".
>This is a slippery slope, and it opens up the way to define a Trash
mailbox in IMAP.
I'm not clear which part of Zoltan's message exactly is the slippery
slope, but the rationale I have for a way to identify special mailboxes
comes from a rather different perspective: the need for mobile clients
to interoperate with systems that are already out there and in
production use.  At least one such system creates its own
Sent/Outbox/Trash folders and whilst I agree with Mark on the general
awkwardness and non-IMAP-nature of a Trash, the fact remains that our
mobile client will see Trash folders in the response to a LIST and has,
right now, no way to know that is anything other than a regular folder,
potentially leading to interesting, inefficient and non-useful behaviour
if it tries to synchronize it :)

>I agree that we need a means to identify the location of sent messages.
If such a mechanism is generalized to allow identification of "special"
folders, then it allows a client to, at the very least, identify and
ignore a Trash folder.  It then imposes no obligation on any client to
*use* a Trash folder.

case for multiple
>clients using the same name.  I tend to suspect that clients are less
likely to be able to do useful things with a different client's draft
than at first appearance.
Agreed (on the last point), but again, it allows clients to avoid
synchronizing folders that should not be synchronized.  It also allows
clients to choose to store their own drafts in that same folder; it does
not impose on them any requirement to process other client's drafts.

Mark: I guess my point is that I respect (and in general agree with) the
reasons that you have for opposing the implementation of a Trash folder
in IMAP, but a way to identify a Trash folder does not count (in my
humble view) as a way to *implement* it and in fact provides a way for
clients to avoid needing to implement it (or, even worse, appear to
provide it to the user by inadvertently showing some other client's
Trash folder).

Regards to all
ben

---

From: Mark Crispin <[email-masked]>
Date: Tue, 1 Aug 2006 23:55:33 -0700 (PDT)

> provide it to the user by inadvertently showing some other client's

I strongly disagree.  I feel that it would be a terrible mistake for any 
portion of any IMAP related specification to identify a token called a 
Trash mailbox (not "folder"; there is no such thing as a "folder" in IMAP 
and the word "folder" is not suitable for use in IMAP due to its 
ambiguity).

It would effectively bless a Trash mailbox, and opens the possibility of 
something adding it to its profile.

As matters stand now, Trash is completely outside of IMAP.  Any software 
that attempts to use Trash has no guarantee of interoperability or even 
that it will work at all.  This is a feature, not a bug.

-- Mark --

http://panda.com/mrc

---

From: "Ben Last" <[email-masked]>
Date: Wed, 2 Aug 2006 07:59:37 +0100

At 02 August 2006 07:56, Mark Crispin wrote:
>I strongly disagree.  I feel that it would be a terrible mistake for
any portion of any IMAP related specification to identify
>a token called a Trash mailbox (not "folder"; there is no such thing as
a "folder" in IMAP and the word "folder" is not
>suitable for use in IMAP due to its ambiguity).
Apologies for the inadvertent use of incorrect terminology :)

>It would effectively bless a Trash mailbox, and opens the possibility
of something adding it to its profile.
I disagree here, and I guess we'll have to continue to differ: I don't
see the way to identify the folder as any form of "blessing".  What if
there were a mechanism to identify folders that are "reserved for other
clients, may do terrible things like implement a Trash and should not be
synchronized to or attended to by other clients"?  That would help
address my concerns.

>As matters stand now, Trash is completely outside of IMAP.  Any
software that attempts to use Trash has no guarantee of interoperability
>or even that it will work at all.  This is a feature, not a bug.
And yet there is at least one major, industrial strength mail server,
that uses LEMONADE IMAP to present itself to mobile clients that uses a
Trash mailbox/view/whatever.  This is a fact of the real world, and
unfortunately we cannot make it go away.  All I want to do is find a
sensible, optimal way to work with what exists.

Best regards
Ben

---

From: Mark Crispin <[email-masked]>
Date: Wed, 2 Aug 2006 08:11:39 -0700 (PDT)

> synchronized to or attended to by other clients"?  That would help

What is there was a mechanism in IMAP to set the secret backdoor that 
allows complete root-level access to the entire system?  Or to send 
unlimited anonymous email?

Do you honestly believe that having such mechanisms defined wouldn't 
encourage some fool to implement them?

> sensible, optimal way to work with what exists.

What you are really saying is:

A mail server vendor made a terrible design mistake in its implementation 
of IMAP for LEMONADE, and now you expect the IMAP protocol to cover for 
this vendor's mistake.

The only appropriate answer to such a request is "no".  1000 times "no".

We should not break protocols to cover for vendor's broken products.

-- Mark --

http://panda.com/mrc

---

From: "Ben Last" <[email-masked]>
Date: Thu, 3 Aug 2006 09:57:10 +0100

Mark Crispin wrote at 02 August 2006 16:12:
>A mail server vendor made a terrible design mistake in its
implementation of IMAP
>for LEMONADE, and now you expect the IMAP protocol to cover for this
vendor's mistake.
Actually, no, that's not what I'm saying.  Mark, with all due respect,
taking my argument to extremes and making a straw-man response to that
extreme does not help the debate.

What I am really saying is that there are systems out there, installed
and running in the real world, that operate in certain ways, and
allowing clients to detect those ways and deal with them is beneficial
to real companies building real products for real users.  The problem of
detecting folders that should not be synchronized is an important one to
mobile clients (where the consequences of repeated download are bad and
can involve serious data charges for end users).  The LEMONADE working
group has such mobile client concerns as one of its reasons for being.
Thus I was interested in discussing ways in which the problem might be
addressed.  I apologise for inadvertently pushing your buttons on the
issue of Trash folders being bad: as I have previously stated, I tend to
agree with you on that.

>We should not break protocols to cover for vendor's broken products.
I completely agree.  At no point did I suggest that we do so.

To reframe part of the problem, then, in a manner less contentious: are
there any proposals for mechanisms by which a client can be aware that a
folder has been renamed, so that it may avoid redownloading the entire
contents of that folder?

Best regards
Ben
EMCC Software Ltd

---

From: <[email-masked]>
Date: Thu, 3 Aug 2006 14:01:48 +0300

Mark,
I think
"What if there was a mechanism in IMAP to set the secret backdoor that allows complete root-level access to the entire system?  Or to send unlimited anonymous email?"
is pretty far from what we are discussing here. Nobody asks for secret backdoors - all that we want is the possibility to identify special mailboxes.

"Do you honestly believe that having such mechanisms defined wouldn't encourage some fool to implement them?"
Yes, exactly: implementation is the intent. Why would we propose such thing otherwise? Call me a fool if You like, but we want to provide a better email experience where the emails are organized in a better way. The better way here means that specific emails are put to their respective mailbox.

Could You elaborate this ""terrible design mistake in its implementation of IMAP" - I am confused. I thought that it is the IMAP standard that lacks the possibility of identifying special mailboxes.

"The only appropriate answer to such a request is "no".  1000 times "no"."
Just keeping saying no does not solve the problem. Providing a solution does.
Could You tell me how will different client implementations know which mailbox they will use to store the "trash", "sent", "junk", etc emails in an interoperable manner? (Consider now foreign language clients - not English ones where the mailboxes are probably called "trash", "sent" and "junk". "Probably" indicates that it is an issue with English clients as well.)

"We should not break protocols to cover for vendor's broken products.""
Identifying the special mailboxes does not break the protocol in any way. In fact, identifying the special mailboxes has nothing to do with the protocol itself - it is merely a configuration setting so that each client that connects knows how to behave.

Thank You.

-----Original Message-----
From: ext Mark Crispin [mailto:[email-masked]] 
Sent: 02 August, 2006 18:12
To: Ben Last
Cc: [email-masked]
Subject: RE: [lemonade] Notifications for multiple devices per user

On Wed, 2 Aug 2006, Ben Last wrote:
> there were a mechanism to identify folders that are "reserved for 
> other clients, may do terrible things like implement a Trash and 
> should not be synchronized to or attended to by other clients"?  That 
> would help address my concerns.

What is there was a mechanism in IMAP to set the secret backdoor that allows complete root-level access to the entire system?  Or to send unlimited anonymous email?

Do you honestly believe that having such mechanisms defined wouldn't encourage some fool to implement them?

> that uses LEMONADE IMAP to present itself to mobile clients that uses 
> a Trash mailbox/view/whatever.  This is a fact of the real world, and 

A mail server vendor made a terrible design mistake in its implementation of IMAP for LEMONADE, and now you expect the IMAP protocol to cover for this vendor's mistake.

-- Mark --

http://panda.com/mrc

---

From: Mark Crispin <[email-masked]>
Date: Thu, 3 Aug 2006 08:43:59 -0700 (PDT)

> extreme does not help the debate.

The problem is that it is neither a strawman nor an extreme: it leads 
exactly to the extremely undesirable outcome of an IMAP specification 
containing the concept of a Trash mailbox.  It has been made clear that 
some individuals have that intent.

> to real companies building real products for real users.

If those systems do not comply with the specification, then those systems 
are defective and should be fixed.  The specification should not bend to 
accomodate the defective systems.

> The problem of
> can involve serious data charges for end users).

That problem is one that should be solved for sent messages mailbox and 
the like.  However, the solution to that problem MUST NOT be used as a 
backdoor to install the concept of a Trash mailbox into IMAP.

> folder has been renamed, so that it may avoid redownloading the entire

That is an entirely different problem.  Sadly, I do not have much hope for 
a solution to that problem, as it imposes a mandate (effectively, a 
mailbox name history) that may not be feasible to implement in some 
servers.

Personally, I feel that IMAP RENAME itself is fundamentally flawed, and 
should be removed from IMAP.  The functionality is infrequently used, as 
as noted causes terrible problems.

-- Mark --

http://panda.com/mrc

---

From: Mark Crispin <[email-masked]>
Date: Thu, 3 Aug 2006 09:14:33 -0700 (PDT)

On Thu, 3 Aug 2006, [email-masked] wrote:
> Could You elaborate this ""terrible design mistake in its implementation 
> of IMAP" - I am confused. I thought that it is the IMAP standard that 
> lacks the possibility of identifying special mailboxes.

It is a terrible design mistake for an IMAP client to implement message 
removal by moving messages to a mailbox named "Trash" or the like.

The correct way to implement message removal is to use IMAP's name 
delete/expunge model.  That model is in IMAP, and is specified in that 
fashion, for a reason.

> Just keeping saying no does not solve the problem. Providing a solution does.

Excuse me.

This matter has already been discussed and thoroughly explained.  You 
yourself admitted that in a previous message in this thread.  You also 
admitted that you disregarded the explanation.

Just bringing up the same issue for discussion repeatedly does not solve 
the problem.  What's more, it leads to unpleasant suspicions that your 
intent is to wear people down until they capitulate and grant you your 
desired outcome.

> Could You tell me how will different client implementations know which 
> mailbox they will use to store the "trash", "sent", "junk", etc emails 
> in an interoperable manner? (Consider now foreign language clients - not 
> English ones where the mailboxes are probably called "trash", "sent" and 
> "junk". "Probably" indicates that it is an issue with English clients as 
> well.)

There is no problem at all with sharing configuration with mailboxes for 
sent messages, nor, for that matter, a mailbox that identifies a 
repository of spam messages that are to be analyzed by spam filtering 
software to improve the filters.

Supposedly, we have a protocol that does that: ACAP.

The problem is solely with using that mechanism to define a "trash" 
mailbox; that is, a mailbox used to receive messages that the user wants 
removed and subjected to a later "empty trash" operation.  This is an 
unnatural and non-interoperable use of IMAP that (as has been discussed to 
death) creates substantial problems -- all to make it easier for a lazy 
programmer to show a trash-type GUI to the user.

The solution to this problem is exclusion of a "trash" mailbox in any form 
from any proposal which purports to identify sent messages and the like; 
and a stipulation that any attempt to include "trash" will be tantamount 
to a poison-pill that kills the entire proposal.

The interoperable way to do message removal is with the native IMAP 
delete/expunge model and ***NOT*** with a "trash" mailbox.  I will 
vigorously oppose any proposal that attempts to make matters otherwise.

> Identifying the special mailboxes does not break the protocol in any 
> way. In fact, identifying the special mailboxes has nothing to do with 
> the protocol itself - it is merely a configuration setting so that each 
> client that connects knows how to behave.

It all depends upon what the special mailbox is.

A kludge that avoids the proper IMAP way of doing things is not something 
that belongs in any IMAP-sanctioned identification mechanism.  Trash is 
such a kludge, and discussion should not be open for it.

Now, it IS a reasonable discussion to investigate means by which a GUI 
with a trash-type user display can use the native IMAP delete/expunge 
model (without a "trash" mailbox) more effectively than is possible today.

I understand, and sympathize with, the desire of a client to present a 
trash-type visual artifact that represents deleted messages in multiple 
mailboxes.  I understand, and sympathize with, the technical difficulties 
that clients face in doing so.  I agree that IMAP can, and should, do 
better.

Nonetheless, a "trash" mailbox is not the solution.  It is a kludge that 
creates new problems and breaks interoperability.  It makes the kludge to 
insert it into a means of sharing configuration (which is supposed to be 
ACAP's job!) of such things as a sent messages mailbox.

The only thing worse would be a mailbox called OUTBOX which, when appended 
to, gets its headers parsed and the message passed to SMTP for delivery. 
There are lots of people who want this, and say "it's easy to do, just 
pass it to sendmail."  That doesn't make it right.

The sooner that we drop discussion on a Trash mailbox and move on to the 
real tasks:
  . how to share configuration
  . how to make it easier for a GUI to present a Trash user metaphor while
    using the native IMAP delete/expunge model
the better.

-- Mark --

http://panda.com/mrc

---

From: Dave Cridland <[email-masked]>
Date: Thu, 03 Aug 2006 17:48:46 +0100

On Thu Aug  3 12:01:48 2006, [email-masked] wrote:
> "Do you honestly believe that having such mechanisms defined 
> wouldn't encourage some fool to implement them?"
> Yes, exactly: implementation is the intent. Why would we propose 
> such thing otherwise? Call me a fool if You like, but we want to 
> provide a better email experience where the emails are organized in 
> a better way. The better way here means that specific emails are 
> put to their respective mailbox.
> 
> 
Actually, recent practise seems to be moving away from the use of 
multiple mailboxes for organizational purposes, and toward an 
organizational method based on arbitrary "tagging" and metadata.

The latter is passing through Last Call now as Experimental, in the 
form of ANNOTATE, and the former has existed for a decade as keywords.

Of course, this change in practise isn't a technical change, it's 
just the swing of personal taste - 5 years ago I was dutifully 
ripping out-moded "keyword" systems out of software, because everyone 
wanted to organize data in heirarchical containers, whereas now the 
same facility is highly popular simply by renaming it to "tagging".

> Could You tell me how will different client implementations know 
> which mailbox they will use to store the "trash", "sent", "junk", 
> etc emails in an interoperable manner? (Consider now foreign 
> language clients - not English ones where the mailboxes are 
> probably called "trash", "sent" and "junk". "Probably" indicates 
> that it is an issue with English clients as well.)
> 
> 
Junk messages have a proposal for using standardized keywords for 
marking and processing.

Deleted messages have the same.

There is, I think, no clear consensus on what you might find in a 
"sent" or "sent items" mailbox - mainly due to a lack of 
specification - but in any case, I feel that for consistency if no 
other reason we should strive to mark such messages with keywords.

It may well be that clients have a UI-based desire to present deleted 
messages, for example, within a single unified container, but on 
desktop operating systems, for example, this is not modelled as a 
simple directory - it's a much more complex area, as you'll see from 
specifications such as http://www.ramendik.ru/docs/trashspec.html - 
this mandates a considerable amount of metadata to be stored with the 
deleted file to allow the operation to be reversible. Note that in 
this case, the trash directory has contents very different from the 
directories the original content was trashed from, and this isn't 
unusual.

Modelling a trash mailbox by using real IMAP mailboxes simply doesn't 
work, just as making a trash directory on a filesystem by using a 
simple directory also doesn't work.

It is, however, possible to model them by using server-side support 
to provide a non-mailbox container (perhaps similar to a virtual 
mailbox), which listed all messages throughout the server marked as 
\Deleted for which the user could SELECT the containing mailbox. I'm 
not sure I'm aware of any server implementor who would be keen to 
implement that, though, because it involves server-wide searching, 
which is generally painful.

I think the closest idea I've seen suggested so far was Randall 
Gellens's suggestion of a "trash heirarchy".

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: <[email-masked]>
Date: Fri, 4 Aug 2006 12:06:12 +0300

Hi Mark,
Thank You for Your response.
Please see my comments below with [ZÖr] tags.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Mark Crispin
Sent: 03 August, 2006 19:15
To: Ordogh Zoltan (Nokia-TP-MSW/Tampere)
Cc: [email-masked]; [email-masked]
Subject: RE: [lemonade] Notifications for multiple devices per user

On Thu, 3 Aug 2006, [email-masked] wrote:
> Could You elaborate this ""terrible design mistake in its 
> implementation of IMAP" - I am confused. I thought that it is the IMAP 
> standard that lacks the possibility of identifying special mailboxes.

It is a terrible design mistake for an IMAP client to implement message removal by moving messages to a mailbox named "Trash" or the like.
The correct way to implement message removal is to use IMAP's name delete/expunge model.  That model is in IMAP, and is specified in that fashion, for a reason.

[ZÖr] I do not see this as a terrible mistake - I see this as an implementation choice to offer (in my opinion) better  and interoperable service. Interoperable meaning that two completely different clients will both understand where to place "sent items"for example.
If You do not want to allow identifying a "trash" mailbox on Your server, You simply disallow updating the related setting - leaving it empty - an reply to a client with a "bad" or whatever response so the client understands that Your server does not allow this. I do not see any problems in making implementation decisions - even the standard itself could express a way to explicitly disable identifying "undesired" special mailboxes.

Excuse me.

[ZÖr] No biggie, just want to speed up things - so I need to make You talk to figure out what's on Your mind and from a "no" I can't do that.

This matter has already been discussed and thoroughly explained.  You yourself admitted that in a previous message in this thread.  You also admitted that you disregarded 
the explanation.

[ZÖr] That was regarding the MOVE command - yes, I gave up because I have been given an alternative solution (even though I do not like the alternative solution because it is a workaround and it is the client that needs to mess around instead of giving a simple command to the server). And yes, I will bring it up over and over again whenever someone mentions anything to which a MOVE command would be appropriate. People get older, forget things - so eventually it will happen.

Just bringing up the same issue for discussion repeatedly does not solve the problem.  What's more, it leads to unpleasant suspicions that your intent is to wear people down until they capitulate and grant you your desired outcome.

[ZÖr] I disagree. This is the basis for standardization - people come up with ideas, and present them. Some people do not like it, fine. Later on someone else comes with the same idea, so these two agree that "hey: if they don't want to standardize it, fine: we will implement it anyway". So these guys implement it, and make a better service than anyone else and then You wish You have made it a standard. I believe everything should be standardized - so if someone decides to implement it then the solution will be available for the taking and it will be interoperable with others.
Your second sentence is valid - however, it does not conflict with any rule to do such thing. Not nice, I agree, but it seems that there is no interoperable solution that solve the problem in question - thus all I can do is keep asking addressing the problem.

> in an interoperable manner? (Consider now foreign language clients - 
> not English ones where the mailboxes are probably called "trash", 
> "sent" and "junk". "Probably" indicates that it is an issue with 
> English clients as
> well.)

There is no problem at all with sharing configuration with mailboxes for sent messages, nor, for that matter, a mailbox that identifies a repository of spam messages that are to be analyzed by spam filtering software to improve the filters.

The problem is solely with using that mechanism to define a "trash" 
mailbox; that is, a mailbox used to receive messages that the user wants removed and subjected to a later "empty trash" operation.  This is an unnatural and non-interoperable use of IMAP that (as has been discussed to
death) creates substantial problems -- all to make it easier for a lazy programmer to show a trash-type GUI to the user.

The solution to this problem is exclusion of a "trash" mailbox in any form from any proposal which purports to identify sent messages and the like; and a stipulation that any attempt to include "trash" will be tantamount to a poison-pill that kills the entire proposal.

The interoperable way to do message removal is with the native IMAP delete/expunge model and ***NOT*** with a "trash" mailbox.  I will vigorously oppose any proposal that attempts to make matters otherwise.

[ZÖr] Ok, so I try to recap this: Your problem is not the fact that we would like to identify special mailboxes, your problem is that we included "trash" in it, right?. Then it would be beneficial if we separated these two arguments: one about identifying special mailboxes and one about the list of special mailboxes to be identified.

> the protocol itself - it is merely a configuration setting so that 
> each client that connects knows how to behave.

A kludge that avoids the proper IMAP way of doing things is not something that belongs in any IMAP-sanctioned identification mechanism.  Trash is such a kludge, and discussion should not be open for it.

Now, it IS a reasonable discussion to investigate means by which a GUI with a trash-type user display can use the native IMAP delete/expunge model (without a "trash" mailbox) more effectively than is possible today.

I understand, and sympathize with, the desire of a client to present a trash-type visual artifact that represents deleted messages in multiple mailboxes.  I understand, and sympathize with, the technical difficulties that clients face in doing so.  I agree that IMAP can, and should, do better.

[ZÖr] So, when should we expect the next IMAP revision? :-)

Nonetheless, a "trash" mailbox is not the solution.  It is a kludge that creates new problems and breaks interoperability.  It makes the kludge to insert it into a means of sharing configuration (which is supposed to be ACAP's job!) of such things as a sent messages mailbox.

The only thing worse would be a mailbox called OUTBOX which, when appended to, gets its headers parsed and the message passed to SMTP for delivery. 
There are lots of people who want this, and say "it's easy to do, just pass it to sendmail."  That doesn't make it right.

The sooner that we drop discussion on a Trash mailbox and move on to the real tasks:
  . how to share configuration
  . how to make it easier for a GUI to present a Trash user metaphor while
    using the native IMAP delete/expunge model the better.

[ZÖr] The "trash" mailbox is not on my agenda, I used it as examples along with the others. However, I do see benefit of identifying such mailbox (otherwise those who need it will simply place everything in the "junk" mailbox instead, or impement proprietary solutions that might confuse the clients - which is even worse than what You are afraid of in case of "trash").

-- Mark --

http://panda.com/mrc

---

From: <[email-masked]>
Date: Fri, 4 Aug 2006 12:34:56 +0300

Hi Dave, I added some comments/questions below. 

-----Original Message-----
From: ext Dave Cridland [mailto:[email-masked]] 
Sent: 03 August, 2006 19:49
To: Ordogh Zoltan (Nokia-TP-MSW/Tampere)
Cc: Enhancements to Internet email to support diverse service enivronments; Mark Crispin; Ben Last
Subject: RE: [lemonade] Notifications for multiple devices per user

Actually, recent practise seems to be moving away from the use of multiple mailboxes for organizational purposes, and toward an organizational method based on arbitrary "tagging" and metadata.

The latter is passing through Last Call now as Experimental, in the form of ANNOTATE, and the former has existed for a decade as keywords.

Of course, this change in practise isn't a technical change, it's just the swing of personal taste - 5 years ago I was dutifully ripping out-moded "keyword" systems out of software, because everyone wanted to organize data in heirarchical containers, whereas now the same facility is highly popular simply by renaming it to "tagging".

[ZÖr] I agree with this, however when the clients are designed to arrange emails in a hierarchical structure, it is important to identify what goes where.

Junk messages have a proposal for using standardized keywords for marking and processing.
Deleted messages have the same.

[ZÖr] It is a good thing - however I would like to see the junk messages separated anyway - to prevent accidentally opening them up. Tagging them is a good idea and does not conflict with storing them in a different mailbox.

There is, I think, no clear consensus on what you might find in a "sent" or "sent items" mailbox - mainly due to a lack of specification - but in any case, I feel that for consistency if no other reason we should strive to mark such messages with keywords.

[ZÖr] My understanding on this is that the IMAP server will not know which messages are sent - it is the client that created copies of emails (so client could tag the messages). I have this understanding based on the FCC problem description, please correct me if I am wrong.

Modelling a trash mailbox by using real IMAP mailboxes simply doesn't work, just as making a trash directory on a filesystem by using a simple directory also doesn't work.

[ZÖr] I do not need a "trash" mailbox, but I do not see why it would not work. User hits delete, and instead of tagging them deleted, client moves them to some other mailbox. In that other mailbox user can hit delete, where client marks them deleted. User hits empty, and then the mails marked for deletion are expunged. If someone was to do something like this - what would be the problem? (It even supports undelete until expunge).

---

From: Tony Finch <[email-masked]>
Date: Fri, 4 Aug 2006 15:20:13 +0100

On Thu, 3 Aug 2006, Dave Cridland wrote:
>
> I think the closest idea I've seen suggested so far was Randall Gellens's
> suggestion of a "trash heirarchy".

Our hacked Cyrus has a similar thing for recovering expunged messages
which have not yet been removed from disk.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
FISHER: WEST OR NORTHWEST 4 OR 5 BECOMING VARIABLE 3 OR 4. FAIR. MODERATE OR
GOOD.

---

From: Mark Crispin <[email-masked]>
Date: Fri, 4 Aug 2006 09:18:24 -0700 (PDT)

Please fix your mail reader to use proper reply text conventions.

On Fri, 4 Aug 2006, [email-masked] wrote:
> And yes, I will bring it up over and over again whenever 
> someone mentions anything to which a MOVE command would be appropriate. 
> People get older, forget things - so eventually it will happen.

I recommend against doing so.  That technique may work elsewhere.  Within 
the context of the IETF and its personalities, it generally lead to 
negative effects on the perpetrator.

> Ok, so I try to recap this: Your problem is not the fact that we 
> would like to identify special mailboxes, your problem is that we 
> included "trash" in it, right?. Then it would be beneficial if we 
> separated these two arguments: one about identifying special mailboxes 
> and one about the list of special mailboxes to be identified.

No, it would be beneficial if you remove "trash" entirely from your 
proposal.

A "trash" mailbox is not a role mailbox such as "sent messages" or 
"drafts".  It is a functionality modification to IMAP.  It is orthogonal 
to the problem of identifying role mailboxes, and its presence in the 
proposal is sabotaging the entire proposal.

> > mailboxes.  I understand, and sympathize with, the technical 
> > difficulties that clients face in doing so.  I agree that IMAP can, and 
> > should, do better.
> So, when should we expect the next IMAP revision? :-)

There is no need to wait for a new IMAP revision.  This problem could 
conceivably be solved with an extension.

Perhaps, if we weren't wasting time on this dead-end thread, some of us 
may be able to find time to work on such an extension.

> The "trash" mailbox is not on my agenda, I used it as examples along 
> with the others.

Then remove it from the proposal!

> However, I do see benefit of identifying such mailbox 
> (otherwise those who need it will simply place everything in the "junk" 
> mailbox instead, or impement proprietary solutions that might confuse 
> the clients - which is even worse than what You are afraid of in case of 
> "trash").

That's the situation faced today by any client that uses "trash" instead 
of the proper delete/expunge model.  It has served as a deterrant; I know 
client authors who gritted their teeth, and did the right thing even 
though a trash mailbox would have made their job easier.

Rather than remove the deterrant, I prefer to help out the client authors 
who try to do the right thing.  Certainly, a better job can be done; but 
undermining the client authors who did the right thing (which is what 
would happen if an IMAP specification defined a trash mailbox) is NOT 
"doing a better job"!

-- Mark --

http://panda.com/mrc

---

From: <[email-masked]>
Date: Mon, 7 Aug 2006 10:50:23 +0300

Hi Mark,
a couple of comments.

>Please fix your mail reader to use proper reply text conventions.
Is this better? I guess for this particular mailing list it is, but now
my own colleagues will tell me the same thing (to revert back as it was
before). :-)

>I recommend against doing so.  That technique may work 
>elsewhere.  Within the context of the IETF and its 
>personalities, it generally lead to negative effects on the 
>perpetrator.
Oh, I do not mind such negative effects - I am here to improve the
standards, not my relationship with people.

>A "trash" mailbox is not a role mailbox such as "sent 
>messages" or "drafts".  It is a functionality modification to 
>IMAP.  It is orthogonal to the problem of identifying role 
>mailboxes, and its presence in the proposal is sabotaging the 
>entire proposal.
There is something I here that I do not understand. One can do it
already, today - without any extensions.
The only thing missing is an interoperable way that makes sure that each
and every client understands that if they want to use the trash, then
this and that is the right place to store the trash - which has nothing
to do with the protocol itself, it is merely a common setting for all
clients stored on the server.
As I said before I have no desire to implement such thing (yet) so You
can consider it removed from my proposal.

But: I would like to take Ben's side here for a second (the rest of the
mail is as such).
I am sorry to say that You did not present a valid technical argument
against Ben's proposal - the arguments presented are based on history,
what the intent of the author was and that it does not fit into the IMAP
picture, etc. The answer to history is evolution. If the author's intent
was not to allow "trashing mails", He would have made sure that it was
not possible. Since it is allowed by the protocol I believe there is no
problem with it at all.
If the working group decides that "no, we don't want an interoperable
way to identify trash folder between clients", You achieve nothing more
than force clients to do proprietary implementations to achieve this  -
which is the exact opposite what standards are made for. And this is the
particular point that bugs me the most.

>That's the situation faced today by any client that uses 
>"trash" instead of the proper delete/expunge model.  It has 
>served as a deterrant; I know client authors who gritted their 
>teeth, and did the right thing even though a trash mailbox 
>would have made their job easier.
I feel sorry for those client implementors - they were forced doing
something that some people think to be the right thing. I also find it
sad that they were so weak-willed that they accepted this when the
protocol allows "trashing" as well - perhaps they were doing a client
for themselves only for a small group of people and not trying to
satisfy a quickly evolving market that involves quite a lot of people.
Then again, I do not think that "trashing" was proposed to "make the
client's job easy". Consider this:
At home I collect to the garbage to a bag, and take it out every now and
then. What You saying here is that I should let the garbage laying on
the floor, put a PostIt on them that says "garbage", and I can collect
them any time I want. You are right - it achieves the exact same thing:
the garbage will be gone eventually, however the second model has
several drawbacks. The most disturbing ones are:
 - it takes a lot of time to colllect the garbage from every room (you
need to look carefully)
 - garbage all over the house is just gross.
I believe "trashing" was proposed to make the user's life easier: to
implement a more efficient email disposal mechnism that the users are
used to and feels more 'natural'.

---

From: Randall Gellens <[email-masked]>
Date: Thu, 10 Aug 2006 17:53:46 -0700

At 12:06 PM +0300 8/4/06, <[email-masked]> wrote:

>  [ZÖr] I disagree. This is the basis for 
> standardization - people come up with ideas, 
> and present them. Some people do not like it, 
> fine. Later on someone else comes with the same 
> idea, so these two agree that "hey: if they 
> don't want to standardize it, fine: we will 
> implement it anyway". So these guys implement 
> it, and make a better service than anyone else 
> and then You wish You have made it a standard. 
> I believe everything should be standardized - 
> so if someone decides to implement it then the 
> solution will be available for the taking and 
> it will be interoperable with others.

That behavior is problematic for standardized 
protocols.  Just because two people agree to 
implement a bad idea does not make it a good 
idea.  It leads to poor interoperability as some 
people do it one way and others do it another. 
The two people who went off in a huff and 
implemented what they want after their specific 
proposal was not accepted are guilty of the same 
attitude they accuse the other participants of 
engaging in: ignoring what others are saying.

If someone comes in with a problem he or she 
wants to solve, the group should indeed listen 
and see if it can be solved and if so what is the 
best way.  The group shouldn't dismiss the person 
out of hand.  But if the person proposes a very 
specific approach to the problem and the group 
points out fundamental difficulties with that 
approach, the person should likewise listen to 
the objections and work together to find better 
solutions.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
It is the business of the future to be dangerous.

---

From: Randall Gellens <[email-masked]>
Date: Thu, 10 Aug 2006 17:58:50 -0700

>  used to and feels more 'natural'.

This is a poor analogy, because there are fundamental differences 
between the physical world and the virtual one of protocols.  First, 
garbage can only exist in one place: it cannot appear to you as if it 
is neatly in the rubbish bin when it is actually all over your floor. 
You'd stumble on it, you'd smell it, you'd kick it around.  You'd 
know it was there, even if it was somehow invisible.  You also would 
open your rubbish bin and not see it.  So it is very different.

With IMAP, messages can be in one place as far as the server is 
concerned, yet appear to be somewhere else as far as the user is 
concerned.  Dave's Trash draft does a nice job of describing this.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Kids Make Nutritious Snacks
--Newspaper headline

---

From: <[email-masked]>
Date: Fri, 11 Aug 2006 12:23:43 +0300

Hi Randall,

>From: ext Randall Gellens [mailto:[email-masked]] 
>Sent: 11 August, 2006 03:59
>To: Ordogh Zoltan (Nokia-TP-MSW/Tampere); [email-masked]
>Cc: [email-masked]
>Subject: Trash (was 'Notifications for multiple devices per user')
>
>>  At home I collect to the garbage to a bag, and take it out 
>every now 
>> and  then. What You saying here is that I should let the garbage 
>> laying on  the floor, put a PostIt on them that says 
>"garbage", and I 
>> can collect  them any time I want. You are right - it 
>achieves the exact same thing:
>>   - it takes a lot of time to colllect the garbage from every room 
>> (you  need to look carefully)
>This is a poor analogy, because there are fundamental 
>differences between the physical world and the virtual one of 
>protocols.  First, garbage can only exist in one place: it 
>cannot appear to you as if it is neatly in the rubbish bin 
>when it is actually all over your floor. 
>You'd stumble on it, you'd smell it, you'd kick it around.  
>You'd know it was there, even if it was somehow invisible.  
>You also would open your rubbish bin and not see it.  So it is 
>very different.
>
>With IMAP, messages can be in one place as far as the server 
>is concerned, yet appear to be somewhere else as far as the 
>user is concerned.  Dave's Trash draft does a nice job of 
>describing this.

It might be a poor analogy, but I think it's valid. I would not want to smell and kick around the invisible garbage. Also, if garbage were invisible, I would want it in my garbage bin.
What if the user connected using a client that does not support Dave's draft? All that invisible garbage becomes visible again and then the user is confused.

---

From: <[email-masked]>
Date: Fri, 11 Aug 2006 13:30:09 +0300

Hi Randall,
If we were living in a perfect world, I would agree with what You just said here a 100%.
But we live in a world where money talks. And it is the users who has the money - including You and me(*). Client/server vendors, operators all make a living from their money.
If I can make a client/server/service that the users like more, users will choose my product/service. There is no need to explain what this means, right?
Users do not care what is beneath the surface as long as they get what they want:
 - they do not care how difficult it was to create something;
 - they do not care about poor interoperability (they will just stop using the "old" products and buy the newest gadgets from the provider/manufacturer who gives them what they want and it works with their friend's gadgets);
 - and they do not care that their favourite product is based on a bad idea.
It is their money, they decide what they pay for.
What is a standard worth that does not give us what we need? What if it has potential? It will be ripped apart a thousand times and/or added a lot of new things that make it more usable. Who rips it apart and/or adds new thing is irrelevant. If a scientist (even if all scientists all over the world) thinks it is a bad idea, it is irrelevant. The market dictates and standards need to follow. If standards do not follow, existing ones will be improved (first proprietary, then it becomes de-facto) or new standards will be created.

(*)
Strictly personal opinion follows until the end of my message, feel free to ignore this.
I am paying for and using a couple of services myself, and I am very disappointed sometimes. When I complain to the provider, they tell me that there is no standard way to do it, so they cannot do it. What do I do? Go to another provider. The other provider sells the exact same thing, so I start looking up smaller providers who care about every penny they can get. Tada, they have it. So, I go there and live my life happily.
I understand that picky like me are a minority, but there are good deal of people who re-evaluate every now and then the value they get for their money. Also, another factor is that large providers tend to care less about their customers. So try scaling this up to see what happens in the long run. When people start leaving the bigger providers in favour of smaller providers (less costs, more favourable services), the bigger providers wake up saying: "where did our income go"? They realize that they decided to not to do something because it is not a standard. "Oops. We are late. Let's make sure the things are standardized the next time, so we can remain competitive." What happens is they try to standardize a solution, but the standardization geeks turn them down based on some scientific reasoning (which is valid but does not recognize that users do not care much about scientific reasons), so in the end they have two choices left: one is that they implement some proprietary solution (or simply but it from someone who already has it), or they create another standard (adding anything they need) based on the geeks' standard in another standardization body (where they have more influence) according to their needs without involving those scientific geeks. Does this latter one sound familiar? I see it happening every day.
I am not saying scientific geeks are bad - they reason only based on facts. I am not saying any providers are bad - they reason based on revenues. It's just that things have changed. It's just that the way our little planet is currently. Nowadays everyone is reasoning based on money (or the value they get for their money). The scientific geeks should step out from the universities and research laboratories for a while to see how is the world nowadays. Of course it would not change any scientific facts, but at least it might make them realize that science is not being used in real life as they intended it to be used. Remember Hiroshima? No scientist ever intended to use the power of the atom like that. But it just happened anyway because there was demand for it. Science gives us the tools, but in the end demand dictates how we use them.

>Sent: 11 August, 2006 03:54
>Subject: [lemonade] Standards Process (was 'Notifications for 
>multiple devices per user')
>
>>  [ZÖr] I disagree. This is the basis for standardization - 
>people come 
>> up with ideas, and present them. Some people do not like it, fine. 
>> Later on someone else comes with the same idea, so these two agree 
>> that "hey: if they don't want to standardize it, fine: we will 
>> implement it anyway". So these guys implement it, and make a better 
>> service than anyone else and then You wish You have made it a 
>> standard.
>> I believe everything should be standardized - so if someone 
>decides to 
>> implement it then the solution will be available for the 
>taking and it 
>> will be interoperable with others.
>
>That behavior is problematic for standardized protocols.  Just 
>because two people agree to implement a bad idea does not make 
>it a good idea.  It leads to poor interoperability as some 
>The two people who went off in a huff and implemented what 
>they want after their specific proposal was not accepted are 
>guilty of the same attitude they accuse the other participants 
>of engaging in: ignoring what others are saying.
>
>If someone comes in with a problem he or she wants to solve, 
>the group should indeed listen and see if it can be solved and 
>if so what is the best way.  The group shouldn't dismiss the 
>person out of hand.  But if the person proposes a very 
>specific approach to the problem and the group points out 
>fundamental difficulties with that approach, the person should 
>likewise listen to the objections and work together to find 
>better solutions.
>--
>Randall Gellens
>-------------- Randomly-selected tag: --------------- It is 
>the business of the future to be dangerous.
>

---

From: Dave Cridland <[email-masked]>
Date: Fri, 11 Aug 2006 12:29:14 +0100

On Fri Aug 11 10:23:43 2006, [email-masked] wrote:
> It might be a poor analogy, but I think it's valid. I would not 
> want to smell and kick around the invisible garbage. Also, if 
> garbage were invisible, I would want it in my garbage bin.

Messages marked with the \Deleted flag do not decompose. If they do, 
then your server has some really interesting properties. :-)

If you really want your analogy taken to task, I'll be happy to do 
it, but suffice to say that your analogy describes neither tha trash 
mailbox situation nor the existing standards-based message deletion 
handling very well.

> What if the user connected using a client that does not support 
> Dave's draft? All that invisible garbage becomes visible again and 
> then the user is confused.

The IMAP4rev1 base specification, like many, if not all IMAP 
specifications for over a decade before, define a methods for clients 
to delete messages, and search for undeleted (or deleted) ones.

The Trash draft simply describes methods for making the above look 
like a trash mailbox, or something similar. Clients which simply 
follow the IMAP4rev1 base specification will interoperate with this 
method.

So clients which don't know anything about the draft should be fine, 
and if not, then they aren't following IMAP4rev1.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarksFrom [email-masked] Fri Aug 11 07:56:46 2006
Date: Fri, 11 Aug 2006 12:29:14 +0100
Subject: RE: [lemonade] Trash (was 'Notifications for multiple devices per
	user')
From: Dave Cridland <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: Enhancements to Internet email to support diverse service enivronments
	<[email-masked]>

On Fri Aug 11 10:23:43 2006, [email-masked] wrote:
> It might be a poor analogy, but I think it's valid. I would not 
> want to smell and kick around the invisible garbage. Also, if 
> garbage were invisible, I would want it in my garbage bin.

Messages marked with the \Deleted flag do not decompose. If they do, 
then your server has some really interesting properties. :-)

If you really want your analogy taken to task, I'll be happy to do 
it, but suffice to say that your analogy describes neither tha trash 
mailbox situation nor the existing standards-based message deletion 
handling very well.

> What if the user connected using a client that does not support 
> Dave's draft? All that invisible garbage becomes visible again and 
> then the user is confused.

The IMAP4rev1 base specification, like many, if not all IMAP 
specifications for over a decade before, define a methods for clients 
to delete messages, and search for undeleted (or deleted) ones.

The Trash draft simply describes methods for making the above look 
like a trash mailbox, or something similar. Clients which simply 
follow the IMAP4rev1 base specification will interoperate with this 
method.

So clients which don't know anything about the draft should be fine, 
and if not, then they aren't following IMAP4rev1.

Dave.

---

From: Mark Crispin <[email-masked]>
Date: Fri, 11 Aug 2006 08:22:43 -0700

On Fri, 11 Aug 2006, [email-masked] wrote:
> If we were living in a perfect world, I would agree with what You just 
> said here a 100%. But we live in a world where money talks. And it is 
> the users who has the money - including You and me(*). Client/server 
> vendors, operators all make a living from their money.

You are also supposing a perfect world; that specifications are faithfully 
implemented, and thus if you sucessfully ram through a specification it 
will happen, no matter how vigorously someone objects to it.

There have been many incidents in the past in which vendor A decided that 
vendor B's implementation is a threat.  To respond to this threat, vendor 
A implemented technical means that targeted vendor B's product, and did so 
in a way that made the fault be in vendor B's implementation.  This put 
market pressure on vendor B to "fix" the problem.

Sadly, IMAP has not been immune.  The IMAP community has been better than 
some (think HTML), but we've had our own vendor sabotage-wars.

Such wars leads to no good for anybody.

The ONLY way to avoid this is for EVERYBODY to cooperate in good faith. 
If objections are raised to a proposal, those objections should not be 
airily dismissed ("there was some reason").

For a proposal to succeed, there must be concensus among all parties that 
it is a good idea, or at least not an objectionable idea.

The worst proposals are those which are "simple for me, so I don't care 
that it is not simple for you."  Almost as bad are proposals which 
duplicate existing functionality, but better please someone's sense of 
esthetics.

MOVE is an example of the former.  Trash is an example of the latter.

-- Mark --

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

---

From: Ned Freed <[email-masked]>
Date: Fri, 11 Aug 2006 14:48:39 -0700 (PDT)

> engaging in: ignoring what others are saying.

Exactly so.

> the objections and work together to find better

There's an important caveat here: The problem has to fit within the charter of
the group. Proposals the group is not chartered to consider have no business
being brought up as potential group activities. They can of course be brought
up as topics for a different group where the problem is in scope, or a
character for a new group can be proposed, or the problem can be pursued as a
individual submission.

In the current discussion I cannot see how trash folder handling can be
construed to be in scope for LEMONADE. I hereby raise a point of order asking
for discussion of this topic be curtailed on this list.

As for MOVE, I suppose an argument can be made that this is a bandwidth saving
mechanism and hence in scope.  But I think it's a bit of a stretch. I think
that in order for there to be further discussion of this there needs to be a
concrete proposal on the table that spells out why this is relevant to
LEMONADE.

Notifications about moved messages, OTOH, appear to be in scope. But again,
a concrete proposal would be nice...

				Ned

---

From: Mark Crispin <[email-masked]>
Date: Fri, 11 Aug 2006 18:31:46 -0700

> a concrete proposal would be nice...

I agree; although this should be in the context of notifications of copied 
messages.

It would be nice if we could use Message-ID for this.  I am aware of 
problems in the past with doing so.  Are those problems still relevant in 
today's world?

If we can't use Message-ID, then we probably want some sort of mailbox 
journal to note events such as COPY.  Disconnected clients may find a 
journal to be useful for other reasons too.

-- Mark --

---

From: <[email-masked]>
Date: Tue, 15 Aug 2006 13:07:21 +0300

>> That behavior is problematic for standardized protocols.  
>Just because 
>> two people agree to implement a bad idea does not make it a 
>good idea.  
>> It leads to poor interoperability as some people do it one way and 
>> others do it another.
>> The two people who went off in a huff and implemented what they want 
>> after their specific proposal was not accepted are guilty of 
>the same 
>> attitude they accuse the other participants of engaging in: ignoring 
>> what others are saying.
>
>Exactly so.
I also agree with the logic presented above - but unfortunately we need
to implement what the market dictates. People do not pay for good ideas
or bad ideas - they pay for a service that they like.
Hence, I am here and complaining because implementing standardized
solution (that satisfies everyone and does not cause problems to anyone)
is preferred over working out a proprietary solution (that satisfies
only one but might cause problems for others).

>There's an important caveat here: The problem has to fit 
>within the charter of the group. Proposals the group is not 
>chartered to consider have no business being brought up as 
>potential group activities. They can of course be brought up 
>as topics for a different group where the problem is in scope, 
>or a character for a new group can be proposed, or the problem 
>can be pursued as a individual submission.
LEMONADE=Enhancements to Internet email to support diverse service
environments
To me this looks just the right place for such improvements. Which part
of those suggested improvements does not fit into the picture?

---

From: Randall Gellens <[email-masked]>
Date: Tue, 15 Aug 2006 18:01:57 -0700

At 1:30 PM +0300 8/11/06, <[email-masked]> wrote:

>   - they do not care about poor interoperability (they will just 
> stop using the "old" products and buy the newest gadgets from the 
> provider/manufacturer who gives them what they want and it works 
> with their friend's gadgets);

All very true.

Users don't care (and shouldn't need to care) about standards.

The point of standards is to provide a way for users to not need to care.

If the standard is poor, if it is ambiguous, or if it is contains 
elements that don't work, or are otherwise bad ideas, then the users 
are given implementations that aren't reliable and that don't work.

-------------- Randomly-selected tag: ---------------
Democracy is a form of government in which it is permitted to wonder
aloud what the country could do under first-class management.

---

From: Randall Gellens <[email-masked]>
Date: Tue, 15 Aug 2006 18:35:27 -0700

At 1:30 PM +0300 8/11/06, <[email-masked]> wrote:

>  they do not care about poor interoperability (they will just stop 
> using the "old" products and buy the newest gadgets from the 

What if the poor user has three friends, and each one has a different 
gadget and use different carriers?

>   - and they do not care that their favourite product is based on a bad idea.

Please take a look at RFC 1925 ("Fundamental Truths of Networking"), 
especially Truth #3 (but really, the rest as well are very applicable 
to the discussion here).

ftp://ftp.rfc-editor.org/in-notes/rfc1925.txt
-- 
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: Randall Gellens <[email-masked]>
Date: Tue, 15 Aug 2006 18:42:01 -0700

>  for discussion of this topic be curtailed on this list.

I see benefit in looking at why so many clients use Trash mailboxes 
instead of delete/expunge, and trying to document a better way to 
achieve the user experience, including extensions if needed.  In 
re-reading our charter, I can see arguments either way as to if this 
is in scope here or not.  I think it comes down to how much the pain 
of the current situation is specific to mobiles.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
If we do not change our direction we are likely to end up where we are
headed.

---

From: <[email-masked]>
Date: Wed, 16 Aug 2006 10:36:08 +0300

Good one :-)
10 and 11 (which in the end directs You to 6) might apply here as well.

>Sent: 16 August, 2006 04:35
>Subject: RE: [lemonade] Standards Process (was 'Notifications 
>formultiple devices per user')
>
>> provider/manufacturer who gives them what they want and it 
>works with 
>> their friend's gadgets);
>
>What if the poor user has three friends, and each one has a 
>different gadget and use different carriers?
>
>Please take a look at RFC 1925 ("Fundamental Truths of 
>Networking"), especially Truth #3 (but really, the rest as 
>well are very applicable to the discussion here).
>
>-------------- 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: Ned Freed <[email-masked]>
Date: Tue, 15 Aug 2006 19:49:55 -0700 (PDT)

> achieve the user experience, including extensions if needed.

Perhaps as a new work item in IMAPEXT. Not here.

> In re-reading our charter, I can see arguments either way as to if this
> is in scope here or not.

I think such a reading has to be _extremely_ creative, and charters are
intended to be narrowly interpreted. Expect to see far more proscriptive 
charters in the future if this proves not to be the case.

> I think it comes down to how much the pain

None of the discussion I've seen so far has given any indication of this
being specific to mobile devices.

But feel free to prove me wrong - write a draft that explains the aspect
of this issue that is of particular relevance to mobile devices. Until
and unless that happens I see no point in continuing this discussion. This
WG already has lots of work on its plate and this isn't helping move any
of it forward.

				Ned

---

From: "Ben Last" <[email-masked]>
Date: Wed, 16 Aug 2006 07:40:42 +0100

Randall Gellens [mailto:[email-masked]] wrote, at 16 August 2006
>I see benefit in looking at why so many clients use Trash mailboxes
instead of delete/expunge,
>and trying to document a better way to achieve the user experience,
including extensions if
>needed.  In re-reading our charter, I can see arguments either way as
to if this is in scope
>here or not.  I think it comes down to how much the pain of the current
situation is specific
>to mobiles.

Well, one might argue that:
a) A proliferation of Trash mailboxes from other clients affects a
device with a small screen more, since screen real-estate is much more
limited.
b) Any extra bandwidth required to deal with the fact that there are
such mailboxes (including responses to LIST, extra yet unnecessary
synchronizations when other clients move messages to the Trash, etc) is
usually more costly on a mobile device (in terms of both battery life
and real money).
c) I have heard arguments that the Trash metaphor is more familiar now
to more users (because it follows Outlook/Thunderbird, etc) and thus
better on small screen devices where simplicity of interface is
important.

If one grants the above, then the discussion might fall under the
charter.

Regards
Ben
EMCC Software Ltd

---

From: Ned Freed <[email-masked]>
Date: Tue, 15 Aug 2006 09:18:24 -0700 (PDT)

> > > That behavior is problematic for standardized protocols. Just because
> > > two people agree to implement a bad idea does not make it a good idea.

> > > after their specific proposal was not accepted are guilty of the same

> to implement what the market dictates.

Excuse me, but what you need to implement is tangentially related at best to
what this group is supposed to be specifying.

> People do not pay for good ideas

> only one but might cause problems for others).

With all due respect, you're not the first to make these sorts of
market-related arguments - I've seen similar statemetns made dozens if not
hundreds of times in the past 16 years that I've been working in the IETF.
However, the number of cases I've seen where the sorts of comments you are
making gained any sort of traction can be counted on the fingers of one hand
with some digits left over. If you want to gain traction for your ideas, I
strongly recommend that you focus on items that are in scope for the group,
and for those items you need to argue based on cogent technical grounds.

> LEMONADE=Enhancements to Internet email to support diverse service

Not hardly. LEMONADE = the items we're chartered to do and nothing more. The
charter is here:

  http://www.ietf.org/html.charters/lemonade-charter.html

I suggest you read it carefully.

> of those suggested improvements does not fit into the picture?

Whether or not it fits into the picture painted by the WG title is largely
irrelevant. Working group titles are necessarily general in nature - a title
running into hundreds of words would be (obviously) unmanageable. This why we
have charters: They specify fairly precisely what the group is supposed to be
working on, and by omission, what the group is NOT supposed to be doing.

To pick another example, the amount of stuff that could fall under the title
"Open Pluggable Edge Services" is vast, but if you look at the OPES WG charter
you will see that they are currently focusing on a very specific subset of the
edge service problem as it pertains to SMTP. This is how things work in the
IETF.

				Ned

---

From: <[email-masked]>
Date: Tue, 22 Aug 2006 18:25:46 +0300

Hi Ned,

>Excuse me, but what you need to implement is tangentially 
>related at best to what this group is supposed to be specifying.

I think that this statement is valid only if one implements the pure
LEMONADE specifications.
OMA on the other hand provides an Enabler based on LEMONADE, where
additional features/funtionalities might be introduced.

>With all due respect, you're not the first to make these sorts 
>of market-related arguments - I've seen similar statemetns 
>made dozens if not hundreds of times in the past 16 years that 
>I've been working in the IETF.
>However, the number of cases I've seen where the sorts of 
>comments you are making gained any sort of traction can be 
>counted on the fingers of one hand with some digits left over. 
>If you want to gain traction for your ideas, I strongly 
>recommend that you focus on items that are in scope for the 
>group, and for those items you need to argue based on cogent 
>technical grounds.

I am not here to tell You that You should do what the market demands. I
prefer to leave these decisions to LEMONADE group.
Speaking of previous market-related arguments: if You consider operator
presence in IETF, I think that the message is pretty clear.
What I mean to tell You (all) is an early indication that such demand
might indeed pop up and when it does, I would rather see a solution for
the problem standardized here, in LEMONADE/IETF.
How You deal with such "early warnings" is up to the LEMONADE group.
Should the group decide that it is not in the scope, not worth doing, or
any other reason, I accept it. Until this decision though I pursue the
issue for the reason above.
I do believe that it is in the scope - the arguments have been presented
already.

>Not hardly. LEMONADE = the items we're chartered to do and 
>nothing more. The charter is here:
>

I do not understand why I need to read it (or how to read it) carefully
- if careful reading is needed, then it means that the charter is not
good because the details are hidden.
I read it (well, at least I read what was readable, the hidden details
remain hidden to me). This part: "operation on platforms with
constrained resources, or 
communications links with high latency or limited bandwidth" tells me
that it is in the scope.
There is no goal or milestone after 2005 Aug, so does it mean that there
is nothing on the charter?
In any case, I do not think that our arguments should be based on
whether if it is in the scope or not.

>Whether or not it fits into the picture painted by the WG 
>title is largely irrelevant. Working group titles are 
>necessarily general in nature - a title running into hundreds 
>of words would be (obviously) unmanageable. This why we have 
>charters: They specify fairly precisely what the group is 
>supposed to be working on, and by omission, what the group is 
>NOT supposed to be doing.

No, it is not about the title. I quoted above a small portion of the
charter.

>To pick another example, the amount of stuff that could fall 
>under the title "Open Pluggable Edge Services" is vast, but if 
>you look at the OPES WG charter you will see that they are 
>currently focusing on a very specific subset of the edge 
>service problem as it pertains to SMTP. This is how things 
>work in the IETF.

Thank You for pointing this out, however I did not see such limitation
in the LEMONADE charter.