1 ietf 64 calsify wg november 7, 2005 vancouver, bc
TRANSCRIPT
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
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:[email protected]: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:[email protected];CUTYPE=INDIVIDUAL;CN=Bernard Desruisseaux; PARTSTAT=TENTATIVE:mailto:[email protected]: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:[email protected]: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:[email protected];CUTYPE=INDIVIDUAL;CN=Bernard Desruisseaux; PARTSTAT=TENTATIVE:mailto:[email protected]:VEVENTEND:VCALENDAR
Chris
Event
Recurrenceinstance
AttendeeAttendee
Recurrenceinstance
AttendeeAttendee
7
Shared Calendar StoreBEGIN:VCALENDARVERSION:2.0PRODID:-//ACME//ACME Cal 1.0//ENBEGIN:VEVENTUID:[email protected]: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:[email protected];CUTYPE=INDIVIDUAL;CN=Bernard Desruisseaux; PARTSTAT=TENTATIVE:mailto:[email protected]: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:[email protected]: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:[email protected];CUTYPE=INDIVIDUAL;CN=Bernard Desruisseaux; PARTSTAT=TENTATIVE:mailto:[email protected]:VEVENTEND:VCALENDAR
Chris
8
Shared CalendarBEGIN:VCALENDARVERSION:2.0PRODID:-//ACME//ACME Cal 1.0//ENBEGIN:VEVENTUID:[email protected]: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:[email protected];CUTYPE=INDIVIDUAL;CN=Bernard Desruisseaux; PARTSTAT=TENTATIVE:mailto:[email protected]: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
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
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.