1 / 32

IETF 64 Calsify WG

IETF 64 Calsify WG. November 7, 2005 Vancouver, BC. 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

genica
Download Presentation

IETF 64 Calsify WG

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation 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

  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 Store

  7. Shared Calendar Store

  8. Shared Calendar

  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 notsupported – 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 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 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 CasesCalConnect 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 realizethat 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) • 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 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.

More Related