1

IETF 64 Calsify WG

November 7, 2005

Vancouver, BC

2

Agenda• Administrative Issues – 5 mins

– Agenda bash, blue sheet, scribes, …

• RFC 2445bis Update – 10 mins• RFC 2446bis Update – 10 mins• RFC 2447bis Update – 10 mins• Calconnect information sharing and news –

10 mins• Calconnect Min-IOP Use cases – 10 mins• AOB/Padding – 5 mins

3

RFC 2445bis Update

Bernard Desruisseaux<bernard.desruisseaux@oracle.com>

Chris Stoner<cstoner1@us.ibm.com>

4

RFC2445bis – Status Update

• Submitted draft –00– http://www.ietf.org/internet-drafts/draft-ietf-calsify-rfc2445bis-00.txt

• Setup rfc2445bis Issues List– http://ietf.webdav.org/calsify/rfc2445bis/rfc2445bis-issues.html

• Collected list of issues with rfc2445– http://ietf.webdav.org/calsify/rfc2445bis/rfc2445-issues.txt

5

RFC2445bis – Active threads• VFREEBUSY

– Can it be used to block off time in calendars?– How to derive FREEBUSY from VEVENT in a calendar?

• Should the PARTSTAT parameter of the ATTENDEE property of the calendar owner be considered?

• Calendar owner specific properties / components?– CATEGORIES– CLASS– PRIORITY– STATUS (?)– TRANSP– VALARM

• What about shared calendars?

6

Personal Calendar StoreBEGIN:VCALENDARVERSION:2.0PRODID:-//ACME//ACME Cal 1.0//ENBEGIN:VEVENTUID:355532-2232@example.comDTSTAMP:20051101T184720ZCREATED:20051101T184720ZDTSTART:20051103T110000ZDTEND:20051103T130000ZRDATE:20051104T110000ZTRANSP:OPAQUESTATUS:CONFIRMEDPRIORITY:1CLASS:PRIVATECATEGORIES:MEETINGSUMMARY:Discuss iCalendar modelORGANIZER;CN=Bernard Desruisseaux:mailto:bernard@ex ample.comATTENDEE;CUTYPE=INDIVIDUAL;CN=Chris Stoner;PARTSTAT =DECLINED:mailto:chris@example.comATTENDEE;CUTYPE=INDIVIDUAL;CN=Bernard Desruisseaux; PARTSTAT=TENTATIVE:mailto:bernard@example.comBEGIN:VALARMTRIGGER:-PT15MACTION:AUDIOEND:VALARMEND:VEVENTEND:VCALENDAR

Event

Recurrenceinstance

AttendeeAttendee

Recurrenceinstance

AttendeeAttendee

Bernard's copy Chris's copy

Cal

enda

r st

ore

BernardiC

alen

dar

repr

esen

tatio

n

BEGIN:VCALENDARVERSION:2.0PRODID:-//ACME//ACME Cal 1.0//ENBEGIN:VEVENTUID:355532-2232@example.comDTSTAMP:20051101T184720ZCREATED:20051101T184720ZDTSTART:20051103T110000ZDTEND:20051103T130000ZRDATE:20051104T110000ZTRANSP:TRANSPARENTSTATUS:CONFIRMEDPRIORITY:2CLASS:CONFIDENTIALCATEGORIES:APPOINTMENTSUMMARY:Discuss iCalendar modelORGANIZER;CN=Bernard Desruisseaux:mailto:bernard@ex ample.comATTENDEE;CUTYPE=INDIVIDUAL;CN=Chris Stoner;PARTSTAT =DECLINED:mailto:chris@example.comATTENDEE;CUTYPE=INDIVIDUAL;CN=Bernard Desruisseaux; PARTSTAT=TENTATIVE:mailto:bernard@example.comEND:VEVENTEND:VCALENDAR

Chris

Event

Recurrenceinstance

AttendeeAttendee

Recurrenceinstance

AttendeeAttendee

7

Shared Calendar StoreBEGIN:VCALENDARVERSION:2.0PRODID:-//ACME//ACME Cal 1.0//ENBEGIN:VEVENTUID:355532-2232@example.comDTSTAMP:20051101T184720ZCREATED:20051101T184720ZDTSTART:20051103T110000ZDTEND:20051103T130000ZRDATE:20051104T110000ZTRANSP:OPAQUESTATUS:CONFIRMEDPRIORITY:1CLASS:PRIVATECATEGORIES:MEETINGSUMMARY:Discuss iCalendar modelORGANIZER;CN=Bernard Desruisseaux:mailto:bernard@ex ample.comATTENDEE;CUTYPE=INDIVIDUAL;CN=Chris Stoner;PARTSTAT =DECLINED:mailto:chris@example.comATTENDEE;CUTYPE=INDIVIDUAL;CN=Bernard Desruisseaux; PARTSTAT=TENTATIVE:mailto:bernard@example.comBEGIN:VALARMTRIGGER:-PT15MACTION:AUDIOEND:VALARMEND:VEVENTEND:VCALENDAR

Event

Recurrenceinstance

AttendeeAttendee

Recurrenceinstance

AttendeeAttendeeCal

enda

r st

ore

BernardiC

alen

dar

repr

esen

tatio

n

BEGIN:VCALENDARVERSION:2.0PRODID:-//ACME//ACME Cal 1.0//ENBEGIN:VEVENTUID:355532-2232@example.comDTSTAMP:20051101T184720ZCREATED:20051101T184720ZDTSTART:20051103T110000ZDTEND:20051103T130000ZRDATE:20051104T110000ZTRANSP:TRANSPARENTSTATUS:CONFIRMEDPRIORITY:2CLASS:CONFIDENTIALCATEGORIES:APPOINTMENTSUMMARY:Discuss iCalendar modelORGANIZER;CN=Bernard Desruisseaux:mailto:bernard@ex ample.comATTENDEE;CUTYPE=INDIVIDUAL;CN=Chris Stoner;PARTSTAT =DECLINED:mailto:chris@example.comATTENDEE;CUTYPE=INDIVIDUAL;CN=Bernard Desruisseaux; PARTSTAT=TENTATIVE:mailto:bernard@example.comEND:VEVENTEND:VCALENDAR

Chris

8

Shared CalendarBEGIN:VCALENDARVERSION:2.0PRODID:-//ACME//ACME Cal 1.0//ENBEGIN:VEVENTUID:355532-2232@example.comDTSTAMP:20051101T184720ZCREATED:20051101T184720ZDTSTART:20051103T110000ZDTEND:20051103T130000ZRDATE:20051104T110000ZTRANSP:OPAQUESTATUS:CONFIRMEDPRIORITY:1CLASS:PRIVATECATEGORIES:MEETINGTRANSP:TRANSPARENTSTATUS:CONFIRMEDPRIORITY:2CLASS:CONFIDENTIALCATEGORIES:APPOINTMENTSUMMARY:Discuss iCalendar modelORGANIZER;CN=Bernard Desruisseaux:mailto:bernard@ex ample.comATTENDEE;CUTYPE=INDIVIDUAL;CN=Chris Stoner;PARTSTAT =DECLINED:mailto:chris@example.comATTENDEE;CUTYPE=INDIVIDUAL;CN=Bernard Desruisseaux; PARTSTAT=TENTATIVE:mailto:bernard@example.comBEGIN:VALARMTRIGGER:-PT15MACTION:AUDIOEND:VALARMEND:VEVENTEND:VCALENDAR

Event

Recurrenceinstance

AttendeeAttendee

Recurrenceinstance

AttendeeAttendeeCal

enda

r st

ore

Bernard

iCal

enda

r re

pres

enta

tion

Chris

Ber

nard

Chr

isB

erna

rd

9

RFC 2446bis Update

Cyrus Daboo<cyrus@daboo.name>

10

RFC 2447bis Update

Alexey Melnikov<alexey.melnikov@isode.com>

11

Calendaring and Scheduling Consortium Report

Pat Egen<pregen@calconnect.org>

12

Minimum Interoperability Results

• Determined after holding 4 interops– Results from 4 vendors– Things that work for everyone– Things that don’t work or are not

supported – for everyone

13

RFC 2445 - What works/what doesn’t

• Most items in the spec are supported by the majority of applications

• Everyone does NOT do:– Separate values in a list with commas– Journaling– Specify individual VTIMEZONE

components for each unique TZID

• Most do NOT do alarms

14

RFC 2446 - What works/what doesn’t

• Most do handle VEvent Publish and Request

• Most do NOT handle Freebusy Publish, Request or Reply

• Most do NOT handle VTodos Publish, Request or Reply

• Everyone does NOT handle VJournal Publish, Request or Reply

15

RFC 2447 - What works/what doesn’t

• Almost everyone supports the majority of this specification

• Most do NOT support the security considerations

16

Sept 05 Interop

• 9 organizations representedOrg Products TestedEVDB EVDB Server iCalendarIBM Lotus Notes 7

iCalendar,iTIP,iMIPIsamet Isamet server/client/mobile CalDAV, iCalendarMozilla Thunderbird iCalendarNovell Hula Server CalDAVOracle Collaboration Suite CalDAV, iCalendarOSAF Chandler CalDAV, iCalendarRPI RPI Calendar Server CalDAVSun Sun Calendar Server

iCalendar,iTIP,iMIP

17

Interop Results

• CalDAV moving along rapidly• iCalendar

– Getting a clearer picture of what works, and what doesn’t

– Biggest issues• Recurrence rules and rdates• Timezones• Exdates• Escaping characters• Handling problems with meetings without endtime or

duration specified

18

Test Suites

• We are in the process of developing test suites for:– CalDAV– iCalendar

19

Min-IOP Use Cases

CalConnect Use Case TC

Jeff McCullough<jeffmc@berkeley.edu>

20

Min-IOP Use Cases

• Overview

• Functionality that’s covered

• Calendaring Use Cases

• Scheduling Use Cases

• Recommendations

21

Overview

Min-IOP Use Case document was created by the Use Case Technical Committee of the Calendaring and Scheduling Consortium. The document defines the use cases for minimum interoperability of calendaring and scheduling. Minimum interoperability is the basic level of functionality our collective experience tells us is necessary to have a useful system. We realize that in some cases it may be more than is currently offered by “basic” calendaring and scheduling applications.

22

Functionality That’s Covered

• Setting up regularly scheduled events• Scheduling with people in other timezones.• Scheduling while traveling to other timezones.• Scheduling and Negotiating meetings with others• Announcing events

23

Calendaring Use Cases

• General Calendaring– Basic invitation– Events with no end time– Alarms/Reminders

24

Calendaring Use Cases (cont’d)• Basic Recurrence (Intervals)

For the basic recurrence intervals below, a calendar user/organizer may wish to create meetings/events that are unbounded, i.e. no clear end date. Some examples include birthdays, anniversaries, staff meetings. While different implementations may or may not allow creation of these types of meetings/events, the unboundedness should be retained when the meeting/event is transferred between systems.

– Every Nth interval– Day of week/month– Nth date of month– Custom list of dates– Basic combinations– Exceptions

25

Calendaring Use Cases (cont’d)

• Basic Time Zone– Meetings across time zones

• Repeating meeting involving multiple time zones• Events with begin and end times in different time zones

– Meetings involving daylight savings time• Monthly meetings• Shift work• Flight schedules• Changes in Daylight Saving Time definitions

26

Scheduling Use Cases• Inviting Attendees

– Invitations for users on and off your server– Track responses– Modify a meeting– Modify a meeting with alert– Cancel a meeting

• Responding– Accept an invitation– Counter a non-repeating meeting– View attendance list (acceptance)

• Free/Busy Time– See free/busy time of another user

27

Scheduling Use Cases (cont’d)• Recurrence

Similar to basic recurrence, changes to unbounded, repeating meetings/events should retain their unboundedness when a change is made to one or all instances of the meeting/event.

– Change all instances– Change one instance – Extend a series– Add an extra date that is an exception to the series– Change the body of all instances– Change the body of one instance– Add/Remove attendee to all instances– Add/Remove attendee to one instance– This and future

• Time zone– Meeting across time zone with reschedule

28

Recommendations• Functionality to keep

– Recommend keeping the functionality exposed in the min-iop use cases for bis documents: iCalendar - 2445, iTip - 2446, and iMip - 2447

• General• Basic recurrence• Basic time zone• Inviting attendees• Responding to invitations• Free/Busy lookups• Scheduling recurrence• Scheduling time zone

• Functionality to defer– Recommend deferring:

• Tasks• Journals• Delegation• Designation• Repeating meeting countering

29

Open Discussion

30

References• CalConnect Home Page

http://www.calconnect.org

31

Additional Slides

32

Timezone Questionnaire Results

• Basic Timezone Support – Support for the basic VTIMEZONE component and properties seemed to be fairly complete, with most vendors both

consuming and producing such components. Note that “producing” a VTIMEZONE component usually means copying a component out of a standard library provided in the product. We are not aware of any iCalendar products that generate VTIMEZONE components on-the-fly from some other data source.

– It was clear that a number of products prefer to operate in UTC and will “downgrade” DATE-TIME values to UTC if a timezone was included.

– Most products include a built-in set of timezone definitions, ranging in number from 50 to 380. These came from a variety of different sources, including the Olsen timezone database, timezone information built into OS’s (e.g. Windows), those provided with other environments (Java). The naming of these components usually followed the scheme of the original data source. In one case a private namespace was used for timezone names.

– Only 1/3 of products provide a way to update the built-in timezone via some automated process. – Only 1/4 of products were able to adjust future events, tasks etc when a timezone definition changed. – About 2/3 products would take in timezone definitions from outside sources. A number of products would attempt to match

an “external” definition to the built-in ones and substitute any matching built-in definition in place of the “external” one. • Timezone Registry

– About 2/3 of respondents said they would use a standard timezone registry if one were available. However, given the wide variety of timezone naming schemes for built-in timezones, its not clear how long it would take for products to adopt any registry scheme if it were to become available.

• Other Comments – One issue that was raised and not answered, was whether products are capable of handling multiple STANDARD and

DAYLIGHT components in a single VTIMEZONE. That is important for dealing with timezone definition changes.