Network Working Group C. Daboo Internet-Draft ISAMET, Inc. Expires: August 15, 2005 February 14, 2005 Problems in Calendaring and Scheduling Standards draft-daboo-calsify-issues-00 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 15, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Current calendaring and scheduling standards are fraught with a number of significant problems, that have hindered wide deployments of interoperable products. This informational document lists the problems with the current standards documents as a means to help identity areas where revisions of the documents are required. Daboo Expires August 15, 2005 [Page 1] Internet-Draft Calsify Problems February 2005 Table of Contents 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 3. Interoperability Problems . . . . . . . . . . . . . . . . . . 3 4. Other Issues . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1 Recurrences . . . . . . . . . . . . . . . . . . . . . . . 4 4.2 Timezones . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Specification Problems . . . . . . . . . . . . . . . . . . . . 5 5.1 ABNF Usage . . . . . . . . . . . . . . . . . . . . . . . . 5 5.2 ABNF and iTIP conformance tables . . . . . . . . . . . . . 5 5.3 Document Errata . . . . . . . . . . . . . . . . . . . . . 5 6. Other Issues . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1 Internationalization . . . . . . . . . . . . . . . . . . . 5 6.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Possible Courses of Action . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . 9 Daboo Expires August 15, 2005 [Page 2] Internet-Draft Calsify Problems February 2005 1. Introduction and Overview Calendaring and Scheduling is defined in [1], [2] and [3], and additionally summarised by [4]. These documents define the iCalendar syntax and semantics, the 'interoperability' profile for handling scheduling, and an email 'binding' for scheduling operations. [4] provides an overview of internet calendaring. These specifications have been available for several years now and there are many implementations based on them. However, a number of interoperability problems exist between these implementations, some due to bugs in the specifications, some due to lack of clarity in the specifications and some due to under specification of key behaviors. As a result, interoperable calendaring and scheduling has not been truly achieved. The purpose of this information draft is to list known problems with the specifications in order to provide an input for an effort to revise the original specifications. This document does not attempt to define how those revisions should be done, but it does provide a summary of some possible courses of action. Discussion of internet calendaring changes is taking place on the ietf-calsify mailing list: List-Subscribe: List-Archive: 2. Conventions Used in This Document Conventions for notations are as in [5]. 3. Interoperability Problems This section summarises results of recent interoperability testing events described in [6] and [7]. The following table summarises the level of support for the three specifications for the participants of the interop event: +---------------+-----------------+---------------------+ | Specification | Items Supported | Items Not Supported | +---------------+-----------------+---------------------+ | RFC2445 | 114 | 6 | | RFC2446 | 15 | 5 | | RFC2447 | 8 | 5 | +---------------+-----------------+---------------------+ Daboo Expires August 15, 2005 [Page 3] Internet-Draft Calsify Problems February 2005 Common problems found include: 1. VJOURNALs are not used. Should they be removed? 2. VTODOs not generally supported in iTIP. 3. Handling or RRULEs/RDATEs in iTIP is inconsistent, particularly when specific instances are rescheduled. 4. Inconsistent VALARM support. [[Comment.1: Should the interop tables and more specific details be included here?]] 4. Other Issues 4.1 Recurrences Recurrence and in particular exceptions to recurrences are known to be problematic. Some implementations do not support all of the BYxxx rule elements - in particular BYSETPOS. There is a lack of understanding of how RECURRENCE-ID works to override instances, particularly when the original item is rescheduled. How does the SEQUENCE number change when one instance is rescheduled? Does the SEQUENCE for that instance only change, or does it change on the 'master' component as well. Is the SEQUENCE number being overloaded in iTIP to also refer to a 'transaction sequence' as opposed to a modification count? [[Comment.2: How well supported is RECURRENCE-ID with RANGE=THISANDPRIOR/THISANDFUTURE?]] 4.2 Timezones Timezones can be specified on iCalendar properties that use a DATE-TIME value. VTIMEZONE components are not standardised and several implementations generate them in different ways. Some will use a fully specified VTIMEZONE component containing all the rules known for that timezone. Others will produce timezones that only contain information for daylight savings shifts for the year time-range covering the period of the event. However both will use the same timezone id. One solution to this is a timezone registry as proposed in [8] Timezones are required for recurring events that span a daylight savings boundary if using a rule to specify the recurrence. Daboo Expires August 15, 2005 [Page 4] Internet-Draft Calsify Problems February 2005 Timezone information also needs to be preserved to ensure users that enter dates in a timezone other than their display default timezone are able to edit the date at a later point using the original timezone information. 5. Specification Problems 5.1 ABNF Usage There are a number of issues with the ABNF. Including inconsistencies between textual description of how many times items are supposed to appear, and their definition in ABNF. The structure of the ABNF is such that it makes it hard to add extensions. The ABNF also uses comments to indicate the frequency of occurrence of items, rather than using proper ABNF constructs to specify that. The only problem with revising the ABNF is the lack of a simple ABNF construct for an 'unordered list' of items (i.e. a set of items that can appear in any order). That may need to be addressed via an extension to ABNF. 5.2 ABNF and iTIP conformance tables Does there need to be both ABNF in 2445 and conformance tables as in 2446. Aren't these saying the same thing? 5.3 Document Errata There are several errors in the examples. Some of these have been documented in the RFC Editor Errata pages [9] and elsewhere [10]. 6. Other Issues 6.1 Internationalization The iCalendar data format recommends use of UTF8 for all textual data, but goes no further than that in terms of internationalization issues. However, some textual values in the iCalendar data are used for comparisons which may take place in different clients or servers. For example, iCalendar processors are likely to attempt matches of the UID of a component arriving via iTIP with any existing components in a store. The iCalendar specs do not explicitly point out the issues with this with respect to different unicode normalisations that may occur. Whilst it is probably not necessary to define a stringprep [11] profile for iCalendar, there should at least be an 'Internationalization Considerations' section that makes it clear that clients may need to 'normalise' certain text values that can be used in comparisons. Daboo Expires August 15, 2005 [Page 5] Internet-Draft Calsify Problems February 2005 6.2 Security Assuming that scheduling becomes more popular as more interoperable products are deployed, the unpleasant possibility of 'calendar spam' ('scam' ???) and malicious scheduling requests arises, as described in [4]. Currently [3] lacks appropriate text describing how security checks for the various address elements should be done to verify the authenticity of the message. The possible sources of identity are the email address headers, a certificate/key identity provided via a multipart/signed email message and iCalendar ORGANISER/ATTENDEE/ SENDER values. 7. Possible Courses of Action Here is a suggested list of possible courses of action that can be taken to improve calendaring and scheduling interoperability: a. Fix known errata in the rfc's. b. Fix ambiguities in the rfc's. c. Redesign recurrences: 1. Simplify RRULEs etc by limiting the possible combinations of each and the set of BYxxx values that are supported in any one rule. 2. Disallow unbounded recurrences on timed events etc. 3. Disallow unbounded recurrences in all cases. 4. Remove EXRULEs. 5. Remove RRULEs and EXRULEs - only use dates. This has the side-effect of removing the need to specify timezones. d. Revise the set of documents as follows: 1. 'iCalendar Syntax' document 2. 'Basic Calendaring with iCalendar' document 3. 'Scheduling operations with iCalendar' document 4. 'Scheduling via Email' document e. Split 2445 into two: 1. 'Basic' document with a set of features that covers a minimum set of interoperable capabilities in calendaring 2. 'Advanced' document with a set of features to cover more complex issues which are know to be problematic. f. Split 2445 into several documents: 1. 'Core' syntax/semantics encompassing VEVENT component items only 2. other documents for syntax/semantics for other types of component VTODO, VJOURNAL etc. g. Leave all features of 2445 and provide a document describing which parts of 2445 are known to work well with recommendations to use those only. Daboo Expires August 15, 2005 [Page 6] Internet-Draft Calsify Problems February 2005 h. Completely rewrite semantics of calendaring and scheduling, with the possibility of changing the syntax to use XML. 8 References [1] Dawson, F. and Stenerson, D., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 2445, November 1998. [2] Silverberg, S., Mansour, S., Dawson, F. and R. Hopson, "iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries", RFC 2446, November 1998. [3] Dawson, F., Mansour, S. and S. Silverberg, "iCalendar Message-Based Interoperability Protocol (iMIP)", RFC 2447, November 1998. [4] Mahoney, B., Babics, G. and A. Taler, "Guide to Internet Calendaring", RFC 3283, June 2002. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [6] Calendaring and Scheduling Consortium, "Calconnect IV", http:/ /www.calconnect.org/interop/ uc%20berkeley%20interop%20testing.pdf. [7] Calendaring and Scheduling Consortium, "Calconnect IV Results", http://www.calconnect.org/interop/8-2004-results.pdf. [8] Royer, D., "Time Zone Registry", draft-royer-timezone-registry-01, January 2005. [9] RFC Editor, "RFC 2445 Errata", http://www.rfc-editor.org/errata.html. [10] Busboom, E., "RFC 2445 Issues", http://www.softwarestudio.org/iCal/2445Issues.html. [11] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002. Daboo Expires August 15, 2005 [Page 7] Internet-Draft Calsify Problems February 2005 Author's Address Cyrus Daboo ISAMET, Inc. 5001 Baum Blvd. Suite 650 Pittsburgh, PA 15213 US EMail: daboo@isamet.com Appendix A. Acknowledgments Thanks to the Calendaring and Scheduling Consortium for holding interoperability events and publishing the results. Many of the issues and proposed solutions come from the comments of participants on the ietf-calsify and ietf-calendar mailing lists. Daboo Expires August 15, 2005 [Page 8] Internet-Draft Calsify Problems February 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Daboo Expires August 15, 2005 [Page 9]