Wednesday Mar 17, 2010

cross domain freebusy lookups

The iSchedule specification is the basis for cross domain exchange of iTIP messages, starting with freebusy requests (i.e userA@domainZ.com  wants to know the availability of userB@domainY.com).

The spec encompasses discovery (using DNS SRV records + Well-Known URI), cross domain authentication  (based on DKIM), and the actual exchange of iTIP messages between client and server.

iSchedule is not meant to be used directly by browser based applications or Calendar User Agents.

The following post by Rob Yates describes an alternative mechanism (a reference to the Freebusy Read URL would probably belong there), that could be used by browser based application to retrieve freebusy info.

Still trying to understand whether there is a partial overlap between the two approaches.

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:

ORGANIZER;CN=Ciy:mailto:ciny@example.com
ATTENDEE;CN=Ciny;PARTSTAT=ACCEPTED:mailto:ciny@example.com
ATTENDEE;CN=Arnaud;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:mailto:arnaudq@example.com


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  mailto:arnaudq@example.com  and mailto:arnaud.quillaud@example.com  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.

Tuesday Dec 15, 2009

Bundling iTIP REQUESTs

When conveying information about a recurring VEVENT or VTODO, iTIP REQUEST messages usually take one of two forms:

Either they contain a full calendar object, i.e. master + exceptions (from RFC2446-bis):

      BEGIN:VCALENDAR
      METHOD:REQUEST
      PRODID:-//Example/ExampleCalendarClient//EN
      VERSION:2.0
      BEGIN:VEVENT
      UID:123456789@example.com
      SEQUENCE:2
      RDATE:19980304T180000Z
      RDATE:19980311T160000Z
      RDATE:19980315T180000Z
      ORGANIZER:mailto:a@example.com
      ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
      ATTENDEE;RSVP=TRUE:mailto:b@example.com
      SUMMARY:Review Accounts
      DTSTART:19980304T180000Z
      DTEND:19980304T200000Z
      DTSTAMP:19980303T193000Z
      LOCATION:Conference Room A
      STATUS:CONFIRMED
      END:VEVENT
      BEGIN:VEVENT
      UID:123456789@example.com
      SEQUENCE:2
      RECURRENCE-ID:19980311T160000Z
      ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
      ATTENDEE;RSVP=TRUE:mailto:b@example.com
      SUMMARY:Review Accounts
      DTSTART:19980311T160000Z
      DTEND:19980304T180000Z
      DTSTAMP:19980306T193000Z
      LOCATION:The Small conference room
      STATUS:CONFIRMED
      END:VEVENT
      END:VCALENDAR

or they contain a single instance:

      BEGIN:VCALENDAR
      METHOD:REQUEST
      PRODID:-//Example/ExampleCalendarClient//EN
      VERSION:2.0
      BEGIN:VEVENT
      UID:123456789@example.com
      SEQUENCE:1
      RECURRENCE-ID:19980311T180000Z
      ORGANIZER:mailto:a@example.com
      ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
      ATTENDEE;RSVP=TRUE:mailto:b@example.com
      SUMMARY:Review Accounts
      DTSTART:19980311T160000Z
      DTEND:19980311T180000Z
      DTSTAMP:19980306T193000Z
      LOCATION:The Small conference room
      STATUS:CONFIRMED
      END:VEVENT
      END:VCALENDAR

That is at least my observation. I'm having trouble finding out whether:

  • this is just me making assumptions,
  • this is mandated by iTIP/iTIP-bis (but where ?), or by some unwritten convention,
  • this is an artifact of how calendar clients interaction usually works (typically the user can change either all instances or one single instance).

Sending only the master or the master + just a few exceptions could only be interpreted on the attendee side as meaning that the missing exceptions are no longer exceptions (?...). This does not make much sense.

But what about sending multiple instances with different RECURRENCE-ID in one single REQUEST ? For example, one could well change the description of one instance, and reschedule another instance by changing its DTSTART. Bundling those 2 instances into a single REQUEST could make sense. Another scenario is one where an attendee is added to only 3 instances of a recurring event. It seems natural to group those 3 instances into one REQUEST when sending the invitation to this attendee.

But is it legal to do so ? And, more importantly, are clients ready to consume this type of message ?

Thursday May 07, 2009

Group event example using implicit scheduling

The iTIP specification (RFC 2446 or its Calsify successor) contains a group event example showing an initial invitation, a reply and an update to a group event.

The example only shows the messages that are exchanged between the different calendar clients. It does not show what each client would store in the actual calendars of the participants after each step. This is for good reason since iTIP defines only messages between CUAs and also because an iTIP aware client does not necessarily store the actual calendar in iCalendar format (might be a proprietary format).

But in any case, iTIP aware clients have to deal with 2 types of objects:

  • iTIP messages (invitations, responses,...).
  • calendar resources (the event and tasks that users see in their calendar).
The client must handle the complex logic of creating one from another, merging them together,...

Using the new CalDAV Scheduling model, this becomes much simpler since clients do need to worry only about their copy of the event. I'll try to show that by turning the above mentioned iTIP example into a CalDAV Scheduling example.

Organizer A invites B, C, D, and E (See 4.2.1 A Group Event Request in iTIP):

To initiate the group event , the organizer (A) simply creates a regular calendar resource in any of his calendar collections:

>> Request <<

PUT /home/A/calendar/qwue23489.ics HTTP/1.1
If-None-Match: \*
Host: cal.example.com
Content-Type: text/calendar
Content-Length: xxxx
   
BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:Mailto:A@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;CN=BIG A:Mailto:A@example.com
ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=B:Mailto:B@example.com
ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=C:Mailto:C@example.com
ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=Hal:Mailto:D@example.com
ATTENDEE;RSVP=FALSE;TYPE=ROOM:conf_Big@example.com
ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE:Mailto:E@example.com
DTSTAMP:20090611T190000Z
DTSTART:20090701T200000Z
DTEND:20090701T2000000Z
SUMMARY:Conference
UID:calsrv.example.com-873970198738777@example.com
SEQUENCE:0
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR

>> Response <<

HTTP/1.1 201 Created
Content-Length: 0
Date: Thu, 11 Jun 2009 09:32:12 GMT

On storing this calendar resource, the server notices that it is a scheduling resource:

  • the organizer is the owner of the calendar collection,
  • the resource has attendees without a SCHEDULE-AGENT=CLIENT parameter.

As a consequence, the server will automatically deliver a copy of the same event in each attendee's calendar (and put a corresponding iTIP message in their scheduling inbox).

The Organizer client can check whether the delivery succeeded by doing a GET on the just created resource and checking the SCHEDULE-STATUS of each attendee:

>> Request <<

GET /home/A/calendar/qwue23489.ics HTTP/1.1
Host: cal.example.com
   
>> Response <<

HTTP/1.1 200 OK
Content-Type: text/calendar
Content-Length: XXX
Date: Thu, 11 Jun 2009 09:32:24 GMT
ETag: "123456789-000-111"
Schedule-Tag: "123456789-000-111"

BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:Mailto:A@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;CN=BIG A:Mailto:A@example.com
ATTENDEE;SCHEDULE-STATUS="1.2";TYPE=INDIVIDUAL;CN=B:Mailto:B@example.com
ATTENDEE;SCHEDULE-STATUS="1.2";TYPE=INDIVIDUAL;CN=C:Mailto:C@example.com
ATTENDEE;SCHEDULE-STATUS="1.2";TYPE=INDIVIDUAL;CN=Hal:Mailto:D@example.com
ATTENDEE;SCHEDULE-STATUS="1.2";TYPE=ROOM:conf_Big@example.com
ATTENDEE;SCHEDULE-STATUS="1.2";ROLE=NON-PARTICIPANT:Mailto:E@example.com
DTSTAMP:20090611T190000Z
DTSTART:20090701T200000Z
DTEND:20090701T2000000Z
SUMMARY:Conference
UID:calsrv.example.com-873970198738777@example.com
SEQUENCE:0
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR

Reply from attendee B (See 4.2.2 Reply To A Group Event Request in iTIP. )

The calendar client of user B does a synchronization between its local cache and the default calendar collection of user B and fetches the event.

>> Request <<

GET /home/B/calendar/bzyw23492.ics HTTP/1.1
Host: cal.example.com
   
>> Response <<

HTTP/1.1 200 OK
Content-Type: text/calendar
Content-Length: XXX
Date: Thu, 11 Jun 2009 09:34:24 GMT
ETag: "123456789-000-112"
Schedule-Tag: "123456789-000-112"

BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:Mailto:A@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;CN=BIG A:Mailto:A@example.com
ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;TYPE=INDIVIDUAL;CN=B:Mailto:B@example.com
ATTENDEE;TYPE=INDIVIDUAL;CN=C:Mailto:C@example.com
ATTENDEE;TYPE=INDIVIDUAL;CN=Hal:Mailto:D@example.com
ATTENDEE;TYPE=ROOM:conf_Big@example.com
ATTENDEE;ROLE=NON-PARTICIPANT:Mailto:E@example.com
DTSTAMP:20090611T190000Z
DTSTART:20090701T200000Z
DTEND:20090701T2000000Z
SUMMARY:Conference
UID:calsrv.example.com-873970198738777@example.com
SEQUENCE:0
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR

Attendee B accepts the invitation. The CUA simply does so by issuing a PUT on the same (attendee's) calendar resource, with an updated PARTSTAT for Attendee B. It makes use of the conditional If-Schedule-Tag-Match header to avoid minor update by other attendees conflicting with its own change:

>> Request <<

PUT /home/B/calendar/bzyw23492.ics HTTP/1.1
If-Schedule-Tag-Match: "123456789-000-112"
Host: cal.example.com
Content-Type: text/calendar
Content-Length: xxxx   

BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:Mailto:A@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;CN=BIG A:Mailto:A@example.com
ATTENDEE;PARTSTAT=ACCEPTED;TYPE=INDIVIDUAL;CN=B:Mailto:B@example.com
ATTENDEE;TYPE=INDIVIDUAL;CN=C:Mailto:C@example.com
ATTENDEE;TYPE=INDIVIDUAL;CN=Hal:Mailto:D@example.com
ATTENDEE;TYPE=ROOM:conf_Big@example.com
ATTENDEE;ROLE=NON-PARTICIPANT:Mailto:E@example.com
DTSTAMP:20090611T190000Z
DTSTART:20090701T200000Z
DTEND:20090701T2000000Z
SUMMARY:Conference
UID:calsrv.example.com-873970198738777@example.com
SEQUENCE:0
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR
>> Response <<

HTTP/1.1 204 No Content
Content-Length: 0
Date: Thu, 11 Jun 2009 09:34:30 GMT

The server will then automatically process the reply and update the Organizer's copy accordingly.

Organizer receives the reply from Attendee B

The Organizer's CUA fetches the new version of the group meeting:

>> Request <<

GET /home/A/calendar/qwue23489.ics HTTP/1.1
Host: cal.example.com
   
>> Response <<

HTTP/1.1 200 OK
Content-Type: text/calendar
Content-Length: XXX
Date: Thu, 11 Jun 2009 09:40:24 GMT
ETag: "123456789-000-333"
Schedule-Tag: "123456789-000-333"

BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:Mailto:A@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;CN=BIG A:Mailto:A@example.com
ATTENDEE;SCHEDULE-STATUS="2.0";PARTSTAT=ACCEPTED;TYPE=INDIVIDUAL;CN=B:Mailto:B@example.com
ATTENDEE;SCHEDULE-STATUS="1.2";TYPE=INDIVIDUAL;CN=C:Mailto:C@example.com
ATTENDEE;SCHEDULE-STATUS="1.2";TYPE=INDIVIDUAL;CN=Hal:Mailto:D@example.com
ATTENDEE;SCHEDULE-STATUS="1.2";TYPE=ROOM:conf_Big@example.com
ATTENDEE;SCHEDULE-STATUS="1.2";ROLE=NON-PARTICIPANT:Mailto:E@example.com
DTSTAMP:20090611T190000Z
DTSTART:20090701T200000Z
DTEND:20090701T2000000Z
SUMMARY:Conference
UID:calsrv.example.com-873970198738777@example.com
SEQUENCE:0
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR

Of course, this example is only scratching the surface of what it takes to create a good scheduling aware client but it shows that minimal scheduling processing can be achieved at a very low cost.


Friday Jan 16, 2009

Disconnect between icalendar and iTIP mandatory properties

Never noticed it before iTIP validation was added to ical4j but there is a disconnect between the mandatory properties specified by iCalendar and the ones specified in iTIP REQUESTs.

For VEVENT, the SUMMARY is mandatory in iTIP REQUEST but not in iCalendar.

For VTODO, the DTSTART, PRIORITY and SUMMARY are mandatory in iTIP REQUEST but not in iCalendar.

In the context of the new CalDAV scheduling draft where automatic scheduling takes place as soon as a calendar resource has an organizer and attendees, this implicitely means that those calendar resource should also have the iTIP mandatory properties.

For SUMMARY and PRIORITY, client implementers can always add them with a value of null and 0 respectively but for DTSTART, this is more problematic.

When assigning a task to somebody else, it is possible (and actually quite likely) that one would set the DUE date and not the DTSTART.

About

arnaudq

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
Bookmarks