IETF 64 Calsify WG November 7 2005 Vancouver

IETF 64 Calsify WG November 7, 2005 Vancouver, BC 1

Agenda • Administrative Issues – 5 mins – Agenda bash, blue sheet, scribes, … • • RFC 2445 bis Update – 10 mins RFC 2446 bis Update – 10 mins RFC 2447 bis Update – 10 mins Calconnect information sharing and news – 10 mins • Calconnect Min-IOP Use cases – 10 mins • AOB/Padding – 5 mins 2

RFC 2445 bis Update Bernard Desruisseaux <bernard. desruisseaux@oracle. com> Chris Stoner <cstoner 1@us. ibm. com> 3

RFC 2445 bis – Status Update • Submitted draft – 00 – http: //www. ietf. org/internet-drafts/draft-ietf-calsify-rfc 2445 bis-00. txt • Setup rfc 2445 bis Issues List – http: //ietf. webdav. org/calsify/rfc 2445 bis-issues. html • Collected list of issues with rfc 2445 – http: //ietf. webdav. org/calsify/rfc 2445 bis/rfc 2445 -issues. txt 4

RFC 2445 bis – 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? 5

Personal Calendar Store 6

Shared Calendar Store 7

Shared Calendar 8

RFC 2446 bis Update Cyrus Daboo <cyrus@daboo. name> 9

RFC 2447 bis Update Alexey Melnikov <alexey. melnikov@isode. com> 10

Calendaring and Scheduling Consortium Report Pat Egen <pregen@calconnect. org> 11

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 12

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 13

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 14

RFC 2447 - What works/what doesn’t • Almost everyone supports the majority of this specification • Most do NOT support the security considerations 15

Sept 05 Interop • 9 organizations represented Org EVDB IBM Isamet Mozilla Novell Oracle OSAF RPI Sun Products EVDB Server Lotus Notes 7 Isamet server/client/mobile Thunderbird Hula Server Collaboration Suite Chandler RPI Calendar Server Sun Calendar Server Tested i. Calendar, i. TIP, i. MIP Cal. DAV, i. Calendar Cal. DAV i. Calendar, i. TIP, i. MIP 16

Interop Results • Cal. DAV moving along rapidly • i. Calendar – 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 17

Test Suites • We are in the process of developing test suites for: – Cal. DAV – i. Calendar 18

Min-IOP Use Cases Cal. Connect Use Case TC Jeff Mc. Cullough <jeffmc@berkeley. edu> 19

Min-IOP Use Cases • • • Overview Functionality that’s covered Calendaring Use Cases Scheduling Use Cases Recommendations 20

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. 21

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 22

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

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 24

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 25

Scheduling Use Cases • Inviting Attendees – – – Invitations for users on and off your server Track responses 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 26

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 27

Recommendations • Functionality to keep – Recommend keeping the functionality exposed in the min-iop use cases for bis documents: i. Calendar - 2445, i. Tip - 2446, and i. Mip - 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 28

Open Discussion 29

References • Cal. Connect Home Page http: //www. calconnect. org 30

Additional Slides 31

Timezone Questionnaire Results • Basic Timezone Support – – – • Timezone Registry – • 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 i. Calendar 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 S’s (e. g. Windows), those O 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. 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. 32