Contacts and Calendars Standard

[Dave Cridland [Home]]

Can I throw a spanner in the works by suggesting that, rather than
define a standard place for the Calendar and Contact details, we should
define a standard way to find that place?

Contact lists:
 - Come in two flavours, "directories" and "personal addressbooks". This
is discussed in more detail in Chris Newman's addressbook ACAP dataset
specification, currently in draft, but going through last call.
 - Directories are usually remote, usually accessed through LDAP.
 - Personal addressbooks come in lots of different flavours, both local
and remote, and many clients support more than one.
 - Most clients offer some means of selecting which addressbooks to
"expand", "auto complete", or "search" through. Different clients search
using different attributes - the full name, the nickname.

I think forcing the contact list to be one specific format - vCard -
which has to be local and may not be entirely suitable (Does vCard have
a nickname field, for instance?) would be somewhat restrictive.
Whichever method is used, we have to consider that although most PIM/MUA
applications can *export* to vCard, they often store more data than
this. Vendor extensions are pretty much essential.

There may be more than one way to access a contact list, incidentally -
for instance, via ACAP or via a cached or replicated local copy.

ACAP addressbooks are in use by more than one implementation (about
three, to greater or lesser degrees), and I have to say, having tried
working with two of them, it makes life much easier. I wish it were
supported elsewhere.

LDAP personal addressbooks are also implemented to greater or lesser
degrees, but generally LDAP is used by MUAs in a read-only way.

For local contact lists, almost every PIM/MUA has its own format and
suchlike.


Calendars:
 - Two sorts of calendar data, loosely.
 - Free/busy time, some of which is normally shared between users.
 - Events, which contain the details, and is not normally shared between
users (even though multiple users may have the same event in their
calendars).

For Calendars, there's been an upcoming protocol for some time based on
iCalendar for remote access to a Calendar server, output by the calsch
working group. If anyone can read through the entire draft specification
without developing a headache, I'll be very impressed. :-)

There's also Apple's iCal application, which stores data for "sharing"
via webdav (okay, so they invented a URI scheme for it, but it's still
webdav on port 80). The shared data is iCalendar objects.

Outlook also can share iCalendar data via webdav, as I understand
things, although TBH, I've never got it to work.

And of course most calendaring data is currently handled by proprietory
protocols and servers.


Email:

For email, we're well aware that there are generally two local mailbox
formats, and two remote ones. (Okay, I'm discounting proprietory mail
access protocols, such as Exchange's MS-RPC profile, and whatever it is
that Lotus Notes uses).

It's worth considering that nobody here is really specifying where "the
mailbox" is, but where either of "The INBOX" is, or "The maildrop" is,
or "The local mailstore" is. It'd be trivial, incidentally, to define
some method of finding the format *and* location of the local
mailstore(s), and require that a fully conformant app understands mbox
and Maildir at minimum, optionally more. MUAs should create new local
mailboxes in one of the standard formats, though.


Hope this helps somewhat.

Dave.