Subject: Re: [lemonade] Clarification on LEMONADE "use"

From: Dan Karp <[email-masked]>
Date: Sat, 7 Nov 2009 15:46:16 -0800 (PST)

> Clearly, given the modular nature of LEMONADE, I would not expect
> anyone to implement all of LEMONADE. Does that change anyone's
> hesitation to say "yes"?

Is there a minimum subset required to answer "yes"?

---

From: Eric Burger <[email-masked]>
Date: Sun, 8 Nov 2009 10:49:59 +0900

Given I'm looking to do some PR saying, "look at how many people are  
implementing LEMONADE," I would offer anything goes.

Of course, the minimum useful set is Profile 1.

---

From: Ned Freed <[email-masked]>
Date: Sun, 08 Nov 2009 15:54:43 -0800 (PST)

> implementing LEMONADE," I would offer anything goes.

Then I'm afraid you need to start being a lot more realistic about all this.

> Of course, the minimum useful set is Profile 1.

That's simply not true. The LEMONADE profile includes any number of things that
are in no way essential to the effective operation of clients in general and
mobile clients in particular.

I'll first pick on a specification I wrote as a particularly obvious example of
this: ENHANCEDSTATUSCODES. This extension provides some real utility, sure, 
but not having it would hardly have the effect of making the remainer of
LEMONADE "useless" or for that matter making a client significantly less
usable.

This is readily demonstrable, BTW, in that very few clients - of any sort -
take advantage of this extension to present localized error messages.

That said, assuming I thought having a LEMONDATE profile makes (which I don't -
I have always believed that profiles are at best pointless and often actively
counterproductive), I would have no problem with ENHANCEDSTATUSCODE being part
of it. Why? Because it's a very simple extension to implement, often involving
nothing but a handful of changes to constant strings. So the cost is low and
the benefits are worth that small cost.

The same cannot be said for BINARYMIME. The cost here is very significant, both
in terms of implementation and operational difficulties. IMNSHO these costs
far, far, far outweigh the benefits the extension delivers. In fact I believe
the costs are so high we've never finished up and activated the latent support
for BINARYMIME in our product and, absent some significant change in the
operqtional, almost certainly never will.

These are just two examples; there are plenty of others, especially once you
get past SMTP and into the IMAP and Sieve requirements. As one final example,
although we have seen any number of requests for additional comparator
capabilities (mostly ones that ignore or compress whitespace in some way), we
have yet to receive a single request for i;unicode-casemap comparator support,
so based on our experience in the field I see less than zero jusitification for
its inclusion in the profile.

In summary, as long as you insist that RFC 5550 represents the useful minimium
that has to be there, I'm doubtful you're going to see much if any suport for
this PR effort of yours. If, OTOH, you want to talk about support for specific
capabilities LEMONADE provides without reference to the profile, then that's a
conversation I for one would not be adverse to having.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Sun, 08 Nov 2009 21:39:13 -0800 (PST)

> > As one final example, although we have seen any number of requests for
> > additional comparator capabilities (mostly ones that ignore or compress
> > whitespace in some way), we have yet to receive a single request for
> > i;unicode-casemap comparator support, so based on our experience in the
> > field I see less than zero jusitification for its inclusion in the
> > profile.

> So much for i18n! :(

First of all, this was in the context of Sieve, not IMAP. See RFC 5500, section
6. AFAIK the LEMONADE profile says nothing about supporting i;unicode-casemap
in IMAP searches, although perhaps that's implicit in its requirement of
support for ESEARCH or some other extension.

Now, as for the impact on i18n, my observation has been that there's something
of a gap between what the standards say needs to be done and what actual users
ask for. This is a case in point - we have a lot of customers all over the
world and we therefore take i18n issues pretty seriously, but the one
comparator several groups really seem to want Sieve support for is the one that
ignores whitespace. Why case-insensitivity isn't a comparable priority, I have
no idea.

> I think that is because hardly anyone uses IMAP SEARCH (nor, for that
> matter, ENVELOPE and BODYSTRUCTURE).  They all treat IMAP as a glorified
> POP, and download messages to the client for subsequent processing.

Since I wasn't talking about IMAP SEARCH this isn't especially relevant to the
matter at hand, but FWIW, we support clients that make very heavy use of IMAP
SEARCH, so much so that we've invested a lot of effort in preindexing support
for it.

				Ned

---

From: Mark Crispin <[email-masked]>
Date: Sun, 8 Nov 2009 19:21:25 -0800 (PST)

> Then I'm afraid you need to start being a lot more realistic about all this.

+1

> That's simply not true. The LEMONADE profile includes any number of 
> things that are in no way essential to the effective operation of 
> clients in general and mobile clients in particular.

+1

So much for i18n! :(

If matters were otherwise, the utterly broken IMAP servers of the world 
would have been fixed long ago.

Curiously, we actually have a priority for i;unicode-casemap and SORT, but 
not for LEMONADE.

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