Subject: Re: [imap5] Where is IMAP5 ?

From: Giovanni Panozzo <[email-masked]>
Date: Wed, 20 Jul 2011 12:36:54 +0200

> - for server developers: IMAP servers already have good storage
> > functionalities and good commands to access them. Why calendar and
> > contacts related function (like search) can't be integrated in the code
> > of cyrus of dovecot ?
> The requirements for email and calendars are VERY different. Just read
> the CalDAV protocol documentation and the draft of CalDAV Scheduling
> and perhaps you will understand.
> Honestly, IMAP is just as good storage for calendars as FTP.

Ok, I can understand this storage organization difference.

I add: a server with one protocol and two storages is simpler than a 
server with two protocols and two storages.

> We don't ask any of that as long as the servers are configured correctly.
>
> In the best case the user enters email address and password. Then we
> determine the POP3/IMAP/SMTP/CalDAV/CardDAV/XMPP settings using
> automatic discovery (Exchange Autodiscover, SRV records or fallback
> .xml file distributed with the installation). We determine the folder
> names using IMAP XLIST or SPECIAL-USE extension and folder layout
> using the IMAP NAMESPACE extension.

The fact YOU did a good job to implement all those things, does not
imply that all software developers will do the same effort on their
client and server software. The world was, is and will be full of client 
problems and badly configured servers. You can't do anything against this.

Only less configuration complexity/parameters and clear standards will
lead to chances to have well configured servers and well behaving clients.

The only perfectly configured server is the one which has NO
configuration parameters :)

> The basic idea behind Microsoft Exchange autodiscover.xml is good. I
> > mean "have the user only enter its email address, its password, and he
> > will be able to access all the PIM information he needs: e-mail,
> > calendar, contacts and whatever IMAP-nextgen will provide".
> > But autodiscover.xml is complex and was born to solve M$ Exchange
> > complexities. I would like to have something more IMAP related and
a bit
> > simpler.
> It's complex only if you make it complex. I've implemented it twice in
> PHP on the server side and once in C# on the client side.

We are discussing of IMAP standard. Many features of autodiscover.xml
are OT and not necessary here (OABUrl, OOFUrl, SPA...). This is what I
call "more complex than needed". And I suspect that there are also
Microsoft patents that cover parts of autodiscover.xml.

---

From: Filip Navara <[email-masked]>
Date: Wed, 20 Jul 2011 13:09:48 +0200

On Wed, Jul 20, 2011 at 12:36 PM, Giovanni Panozzo <[email-masked]> wrote:
> I add: a server with one protocol and two storages is simpler than a server
> with two protocols and two storages.

Obviously you still don't understand it. The protocol differences are
just as big as the storage ones.

A typical query with non-cached CalDAV client could be "give me all
events from default calendar from 18-07-2011 to 24-07-2007 and expand
recurring events into instances".

The similarities go only as far as full cache synchronization goes,
but then all the hard stuff would have to be implemented on the
client-side or you'd have to re-implement CalDAV on IMAP.

> problems and badly configured servers. You can't do anything against this.

Exactly my point.

The infrastructure and protocols are already there. People implement
them poorly not because of the lack of the protocols, but for other
reasons (business, lack of time, lack of interest).

http://www.xkcd.com/927/

> Microsoft patents that cover parts of autodiscover.xml.

I didn't bring up the discussion about auto-configuration. Of course
many of the options of the protocol are useless for IMAP, but that's
not the point. That's like saying we shouldn't use HTTP because
Facebook API uses it. Nobody forces you to use Facebook API with every
HTTP implementation.

Best regards,
Filip Navara

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 20 Jul 2011 09:54:56 -0400

Hi Giovanni,

> lead to chances to have well configured servers and well behaving clients.

Do you really think a new protocol will make people write better code? At 
the end of the day people will do as much or as little as they need to 
satisfy their customers and business case - that has always been true and 
will continue to be.

Frankly the best solution is to have high quality open source libraries and 
documentation that the "lazy" developers can use to implement a solid 
product (probably easier to do for client than server).

-- 
Cyrus Daboo