Monday Jan 18, 2010

use of email addresses as calendar user addresses

The iCalendar standard defines the notion of organizer and attendees (users, groups, resources,...) for scheduling purpose. Those are identified by "calendar user addresses" which in practice are generally mailto: URIs:


The CalDAV scheduling draft offers a way for a client to discover which calendar user addresses are associated with a particular user through the use of the CALDAV:calendar-user-address-set property.

This property can then be used in different ways, depending on the context:

  • When creating a meeting invitation, it can be used to set the ORGANIZER property value.
  • When fetching events from the server, it can be used to determine whether the owner of the calendar is the organizer or an attendee of the meeting by comparing the addresses returned in the calendar-user-address-set with the ORGANIZER and ATTENDEE values.

Client applications need to take into account a few points when doing this comparison though:

First of all, the calendar-user-address-set property is multivalued: a user may have both  and  defined as valid calendar addresses. So CUAs need to look for both values when comparing with the ORGANIZER/ATTENDEE values.

Then, when using mailto: URIs, there is no clear definition of how two such URIs should be compared for equality (as far as I know). For example, if one follows the SMTP definition, the local part of an email address is case sensitive. In the context of a calendar client though, I think it makes sense to:

  • try to preserve the original case when storing calendar addresses.
  • but do case insensitive comparison wherever a comparison is required.

Friday Jul 24, 2009

Email reminders mess (progress on the horizon)

One of my desktops is a Mac Mini and recently, I started to notice that the Apple Mail program would startup by itself at what seemed like random occasions and ask me for very private information like my uid, password etc... (Thunderbird is my main client).

After exonerating my kids I figured out what was happening: I have a family calendar at an ISP who now offers CalDAV access. A few days before I started to notice the ghost Mail, I had setup the Apple iCal calendar client to show that calendar. Most of the events on that calendar have email reminders associated with them. Those reminders are generated by the ISP Server but it looks like my desktop was trying to honor those as well. Would I have configure Apple Mail properly, I would have started to receive 2 copies of each reminders.

The fact that the iCalendar specification remains silent on the subject of who (client or server) should honor VALARM with an ACTION property set to EMAIL is a pretty well known issue but I always thought it was a rather theoritical one (Lightning for example does not honor email alarms). It is the first time that I face it as an end user.

It looks like the new VALARM Extension draft is coming at about the right time for me...

Thursday Jan 29, 2009

VTODO with DUE date in Apple iCal

Following my previous post, I've started to look at how due dates are leveraged by real clients, starting with Apple iCal.

Apple iCal (on Mac OS 10.5) let you create VTODOs ("To Do Items") and store them on a CalDAV Server. By default those todos have no associated dates but one can add a due date (no time):

Here is how such a todo is stored on the CalDAV server:


The VTODO component has a correct DUE property but it also has a DTSTART property which:

  1. comes out of nowhere (not visible in the UI),
  2. has no meaningful value (value hardcoded to 01/01/2004).

Client that takes the DTSTART into consideration to do some processing (e.g. to build a view) might show inconsistent results when processing such a VTODO.

Worth, the DTSTART property has a DATETIME value when the DUE property has a DATE value, causing the VTODO to be invalid per the new calsify spec.

If one tries to add an alarm (trigger -15 minutes before), the VTODO is stored as:


The TRIGGER property is missing a RELATED=END parameter which would link the alarm time to the DUE date. As a consequence, other clients will consider the TRIGGER to be relative to the DTSTART property. Since its value is meaningless (some time in 2004), the alarm will probably disappear (or be triggered as soon as the client fetches the todo).

Thursday Mar 29, 2007

Google joining CalConnect + Info on Apple CalDAV Client/Server

Got 2 interesting info from a UW (Oren Sreebny) blog:

  • Google is joining CalConnect.
  • Some more info on the upcoming Apple CalDAV client/server are now available.

Having Google join CalConnect is good because until now, they've followed their own path,  exposing a proprietary calendar data model and protocol. Given their size and the fact that they offer public APIs in different languages it seems that it is getting traction from developers. This of course means less energy spent on open calendaring standards.

I should add that despite having one of the most mature and rich featured Calendar Product,  we (Sun) have not yet joined CalConnect. But there is hope...

The Apple articles seems to imply that both clients and servers will implement some version of the still in progress Scheduling Extensions to CalDAV IETF Draft. It also seems that they will support attachments in events. Since this is not part of the CalDAV Standard, it will be interesting to see how they've solved that problem. Attachments in calendar events is one of the most awaited feature in our Comms Suite 5 product but we did not have to solve it in a standard way...




« February 2016