Subject: [lemonade] Why we should let the IMAP specification become more rich, rather than poor

From: Philip Van Hoof <[email-masked]>
Date: Tue, 24 Jun 2008 13:17:51 +0200

This is a personal opinion.

With Lemonade we finally have the opportunity to improve the IMAP spec
and to let IMAP servers advertise richness of features in a marketing-
meaningful way.

My opinion is that we have seen four kinds of IMAP servers:

- Free software ones that get a lot right
- Free software ones that get most (or at least a lot) wrong
- Commercial ones that get most right
- Commercial ones that are actually trying to sell their closed protocol
  instead, but offer a crippled "old IMAP" interface for marketing
  purposes (we do IMAP too, look at us!)

For several years it was possible to say that for example Google's
recent IMAP server offering is a rather poor IMAP server because
UNSELECT, IDLE, NAMESPACE, QUOTA, XLIST, CHILDREN and something weird
called XYZZY is not really that much of a big deal for a modern IMAP
server ... nowadays.

My guess is that this XYZZY is that item #4 in the list above: XYZZY was
a magic word used in one of the earliest computer adventure games -
Colossal Cavern. It would transport you between two different parts of
the map.

Nowadays you can, however funny XYZZY is, effectively say that Google's
IMAP server is just not a Lemonade-ready IMAP server:

 - No CONDSTORE, no RSYNC
 - No CATENATE
 - No UIDPLUS

Let's hope that for marketing this will be meaningful someday and that
we that way can convince vendors like Google to do a better job.

ps. I don't care how good the extensions behind XYZZY are. Not specified
in an open way means that they don't exist for my E-mail clients. 

-- 
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://pvanhoof.be/blog
http://codeminded.be

_______________________________________________
lemonade mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Timo Sirainen <[email-masked]>
Date: Tue, 24 Jun 2008 14:54:27 +0300

>   purposes (we do IMAP too, look at us!)

I had hoped that maybe at some point my imaptest tool's results could
motivate at least some servers to get themselves more compliant:
http://imapwiki.org/ImapTest/ServerStatus

The "failures" number may be somewhat inflated for some servers, because
the tests don't currently always uniquely test a single thing, but for
example if \Recent flag handling isn't correct multiple tests can fail.
Also the 34 as maximum should probably be changed at some point to the
actual number of commands that tested successfully, instead of the
number of files that tested things (which contain about 1-30 tests
each).

I was also planning on writing tests for Lemonade extensions at some
point, but since I haven't implemented half of Lemonade yet myself there
hasn't been much motivation yet.
_______________________________________________
lemonade mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Philip Van Hoof <[email-masked]>
Date: Tue, 24 Jun 2008 15:01:56 +0200

> in an open way means that they don't exist for my E-mail clients. 

Would it make sense to claim in the RFC that you MUST NOT call yourself
an IMAP server if you advertise capabilities that are not publicized as
either RFC or in proposal at IETF?

Opinion:

For me that would make a lot of sense. I don't really like how Google is
polluting the CAPABILITY line with their closed things (again, no matter
how funny they pick the capability names).

They can call it GMAP, whatever.

---

From: <[email-masked]>
Date: Tue, 24 Jun 2008 11:24:39 -0400

An RFC/IETF proposal defines a particular usage and scope. Declaring
negative definitions is out of scope
Thanks,
Bill Oxley
Messaging Engineer
Cox Communications

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Philip Van Hoof
Sent: Tuesday, June 24, 2008 9:02 AM
To: Enhancements to Internet email to support diverse service
enivronments
Subject: Re: [lemonade] Why we should let the IMAP specification become
morerich, rather than poor

Opinion: