Internet DRAFT - draft-daboo-calsify-issues
draft-daboo-calsify-issues
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:
<http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>
List-Archive:
<http://lists.osafoundation.org/pipermail/ietf-calsify>
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]
