IETF 64 Calsify WG

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 Desruisseauxltbernard.desruisseaux_at_oracle.
  comgt
• Chris Stonerltcstoner1_at_us.ibm.comgt

4
RFC2445bis Status Update

• Submitted draft 00
• http//www.ietf.org/internet-drafts/draft-ietf-cal
  sify-rfc2445bis-00.txt
• Setup rfc2445bis Issues List
• http//ietf.webdav.org/calsify/rfc2445bis/rfc2445b
  is-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 Store
7
Shared Calendar Store
8
Shared Calendar
9
RFC 2446bis Update

• Cyrus Dabooltcyrus_at_daboo.namegt

10
RFC 2447bis Update

• Alexey Melnikovltalexey.melnikov_at_isode.comgt

11
Calendaring and Scheduling Consortium Report

• Pat Egenltpregen_at_calconnect.orggt

12
Minimum Interoperability Results

• Determined after holding 4 interops
• Results from 4 vendors
• Things that work for everyone
• Things that dont work or are notsupported for
  everyone

13
RFC 2445 - What works/what doesnt

• 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 doesnt

• 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 doesnt

• Almost everyone supports the majority of this
  specification
• Most do NOT support the security considerations

16
Sept 05 Interop

• 9 organizations represented
• Org Products Tested
• EVDB EVDB Server iCalendar
• IBM Lotus Notes 7 iCalendar,iTIP,iMIP
• Isamet Isamet server/client/mobile CalDAV,
  iCalendar
• Mozilla Thunderbird iCalendar
• Novell Hula Server CalDAV
• Oracle Collaboration Suite CalDAV, iCalendar
• OSAF Chandler CalDAV, iCalendar
• RPI RPI Calendar Server CalDAV
• Sun Sun Calendar Server iCalendar,iTIP,iMIP

17
Interop Results

• CalDAV moving along rapidly
• iCalendar
• Getting a clearer picture of what works, and what
  doesnt
• 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 CasesCalConnect Use Case TC

• Jeff McCulloughltjeffmc_at_berkeley.edugt

20
Min-IOP Use Cases

• Overview
• Functionality thats 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 Thats 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 (contd)

• 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 (contd)

• 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 (contd)

• RecurrenceSimilar 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 Pagehttp//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 OSs (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.