Friday Dec 21, 2012

CalConnect Consensus Scheduling Workshop

Oracle is hosting the next Calconnect interop fest and roundtable. Both events are limited to members of the Calconnect consortium, but the workshop on consensus scheduling is open to all.

Consensus scheduling is the process by whereby a group comes to agreement on when to hold a meeting. While we all know that here are 7 things you need to know about consensus scheduling, this workshop will probably allow you to discover many more.

Monday Sep 26, 2011

Smart CalDAV Clients (Scheduling Assistant)

The ecosystem of CalDAV clients is growing at a steady pace but this is the first time that I get to see a client that goes beyond the usual end user desktop/mobile calendar application. The Scheduling Assistant (see https://wiki.jasig.org/display/SA/Home ) helps people with lots of 1:1 appointments (e.g. academic advisors) manage their calendar by formalizing appointment requests. Those requests have to be made through a specialized web UI and are then translated into events in each participant's calendar.

Hopefully, there will be more and more smart clients like this one to leverage the CalDAV protocol.

This How To page will help you configure the Scheduling Assistant with Oracle Communications Calendar Server.

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.

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