Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "1 IETF 64 Calsify WG November 7, 2005 Vancouver, BC."— Presentation transcript:

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

2 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 3 RFC 2445bis Update Bernard Desruisseaux Chris Stoner

4 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 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 6 Personal Calendar Store

7 7 Shared Calendar Store

8 8 Shared Calendar

9 9 RFC 2446bis Update Cyrus Daboo

10 10 RFC 2447bis Update Alexey Melnikov

11 11 Calendaring and Scheduling Consortium Report Pat Egen

12 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 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 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 15 RFC 2447 - What works/what doesn’t Almost everyone supports the majority of this specification Most do NOT support the security considerations

16 16 Sept 05 Interop 9 organizations represented OrgProductsTested EVDBEVDB ServeriCalendar IBMLotus Notes 7iCalendar,iTIP,iMIP IsametIsamet server/client/mobileCalDAV, iCalendar MozillaThunderbirdiCalendar NovellHula ServerCalDAV OracleCollaboration SuiteCalDAV, iCalendar OSAFChandlerCalDAV, iCalendar RPIRPI Calendar ServerCalDAV SunSun Calendar ServeriCalendar,iTIP,iMIP

17 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 18 Test Suites We are in the process of developing test suites for: –CalDAV –iCalendar

19 19 Min-IOP Use Cases CalConnect Use Case TC Jeff McCullough

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

21 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 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 23 Calendaring Use Cases General Calendaring –Basic invitation –Events with no end time –Alarms/Reminders

24 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 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 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 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 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 29 Open Discussion

30 30 References CalConnect Home Page http://www.calconnect.org

31 31 Additional Slides

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


Download ppt "1 IETF 64 Calsify WG November 7, 2005 Vancouver, BC."

Similar presentations


Ads by Google