Contacts and Calendars Standard

[Dave Cridland [Home]]

On Wed, 2003-07-16 at 06:50, Jeroen ten Berge wrote:
> > Van: Daniel Farrell [mailto:daniel at farrells.org]
> > 
> > Ok, there seems to be some very different takes on what we 
> > are trying to
> > specify.  I'll clarify my position.  I want to define local storage
> > places for calendars, contacts and possibly mailboxes for desktop
> > users.  The corporate environment is beyond this and should include
> > servers and such.  So...
> I agree, local desktop, not corporate use (they allready have dir's and imap)

Eh? What is this, "freedesktop.org - developing the desktop platform of
the 90's"? Is it really just me who thinks that it's at least worthwhile
exploring the possibility of not *always* storing everything on the
local machine?

In any case - directories != personal addressbooks. They never have, and
never will, which is why *every* MUA has some form of personal
addressbook, whether it's local, via IMSP, or ACAP, or MAPI PAB, or
whatever. It's not just a coincidence. You don't put your girlfriend's
email address in the company directory, do you?

Personal addressbooks are not always local, and given that the largest
use of ACAP currently is for personal addressbooks, I think it's
worthwhile looking into at least being able to specify that the user
would *like* to access their remote addressbook.

(Which I do from Mulberry or Squirrelmail, these days, and jolly nice it
is too.)

> > For calendars(and tasks) people seem to accept iCalendar as the way to
> > go.  I'm happy with that.
> I haven't looked at it, but it probably is ok.

And the (many) remote protocols in use or in development? Or are we
intent on producing limited standards which only affect single machine
installations?

All the current remote protocols based on open standards (WebDAV, ICAL,
CAP) all use iCalendar formatted data, anyway.

I'm not suggesting that all applications need to support all of these,
just suggesting that it might be nice if those that did weren't
penalised for it, and those that didn't could at least explain such to
the user.

> That's exactly in favor of the end-user ;)

Unless they do not actually use local mailboxes. But that's another
issue, already solved.

> > Having investigated the mail formats some more I'd actually suggest UW
> > IMAP's mbx instead of plain mbox.  It seems to solve the problems mbox
> > has.  And again, this doesn't replace your local server setup.  I want
> > to specify this for future desktop users who won't have a local server
> > setup.
> I disagree here, i'd personaly like the Maildir type the best, allready most MUA's are familiar with this type of setup, i guess it's faster than mbox too and more secure, if a file get's corrupted, it wouldn't cause all mail to get corrupted. I hope everybody will drop mbox and mbx in favor of Maildir, i've yet to hear any reason why not...

So we've established that different people would prefer different
formats. Several times over, in fact.

It seems to me that what we want is:
a) Some method for finding folders (local or otherwise).
b) Some method for discovering the format (People tell me this can and
should be done automatically. I'll believe that, but why force the MUA
to do this discovery every time?)
c) A base set of mailbox formats that must be supported, including the
locking semantics.
d) A subset of the above (or exactly the same set) which should be used
for new mailboxes.

At minimum, this appears to be:

a) It's always local and at some predefined location.
b) Guess.
c) Maildir and mbox
d) Maildir and mbox

Obviously, clients based on, say, c-client will be able to cope with
many more mailbox formats and conventions than those coded
independently. But c-client doesn't support Maildir, as I recall, so
perhaps the base specification (The MUSTs, in IETF-speak) should only
deal with mbox, with a SHOULD for Maildir. (And a MAY for all the
others.)

Dave.