CP RSS Channel
About Our Sponsors
Articles & Papers
Technology and Society
|Proposed Calendar Server Extensions for WebDAV (CalDAV).|
Update 2010-02-08: "OASIS Web Services Calendar (WS-Calendar) TC to Create Common Scheduling Standard." — On January 25, 2010 OASIS announced the formation of a new Web Services Calendar (WS-Calendar) Technical Committee, chartered to adapt existing calendaring and scheduling specifications toward development of a "Common Scheduling" standard to define how schedule and event information is passed between and within services. The committee will deliver a specification for creating, retrieving, updating, and deleting calendar events on a schedule. This includes a standard schema and semantics for schedule and interval information for use in other web services. While the initial motivation for WS-Calendar work came from the smart grid domain (schedule and interval for energy transmission and payments), the TC proposers feel that a common scheduling specification for web services would be applicable to a wide range of industry requirements where transactions and business processes depend critically upon scheduling. Time synchronization, schedule alignment, and performance alignment are nearly universal business process concerns, as described in the WS-Calendar TC Charter...
Update: See the Principal References section for later CalDAV specification citations.
[December 31, 2003] IETF has announced the publication of an initial working draft for Calendar Server Extensions for WebDAV (CalDAV). The CalDAV draft been submitted to the IETF CALSCH working group for consideration of the mechanisms designed to enable interoperable calendar access over WebDAV. The draft specification was commissioned at the Fall 2003 Minneapolis meeting of the IETF Calendaring and Scheduling Working Group Working Group and is intended as an exploration of the advantages of using WebDAV as well as a proposal for one way to model calendaring data, with some ideas for how to specify the features that go beyond WebDAV."
Under the initial proposal, a CalDAV server would need to support WebDAV Level 1 and 2, WebDAV ACL, DASL (DAV Searching and Locating), and HTTP/SASL; WebDAV DeltaV support would be optional. The document describes certain features that are required for modern enterprise-level calendar systems are not present in HTTP or WebDAV, including fanout (server supports fanning out scheduling requests on behalf of the client), recurrance (support for recurring appointments are common in calendaring applications), and notifications (optimal way for the server to contact the client).
"A CalDav repository, or server, is a calendaring-aware engine combined with a WebDAV repository. The CalDAV server or repository is the canonical location for calendar data, state information and semantics. The CalDAV server has significant responsibility to ensure that the data is consistent and compliant. Clients may submit requests to change data or download data. Clients may store the calendar offline and attempt to synchronize when reconnected, but changes to the repository occurring in between are not considered to be automatically disposable and clients should consider the repository to be the first authority on state. HTTP Etags and other tools help this work."
Calendar Server Extensions for WebDAV (CalDAV). By Lisa Dusseault (Xythos Software, Inc), with feedback from Cyrus Daboo and Michael Arick. IETF Network Working Group, Internet Draft. Reference: 'draft-dusseault-caldav-00'. November 1, 2003, expires May 1, 2004. 33 pages.
[2004-12: Calendaring and Scheduling Extensions to WebDAV (CalDAV). 'draft-dusseault-caldav-04']
Proposed CalDAV Features
Draft section 2 (Required CalDAV features) lists functionality required of a CalDAV server in order to advertise support for CalDAV or claim compliance. A CalDAV server:
- MUST support WebDAV Level 1 and 2 (all of RFC 2518, including locking)
- MUST support WebDAV ACL
- MAY support WebDAV DeltaV
- MUST support DASL
- MUST support HTTP/SASL
- MUST support property promotion as described in CalDAV v00
- MUST support scheduling fanout as described in CalDAV v00
- MUST support calendaring REPORTs as described in CalDAV v00
"In the five years since WebDAV was standardized, at least three
groups have used WebDAV as a basis to provide Internet calendar
access with a minimum of development effort...
Calendar functionality is found extremely frequently on the Web. Even
calendaring systems designed primarily for access by smart clients
(smart clients are those which have application logic, as opposed to
thin clients or Web browsers) typically also have a Web interface
accessible by thin clients. Some calendaring applications are
available only via Web interfaces, for example those found on systems
such as Yahoo! Groups.
Because of the frequent use of Web interfaces, and the possibility of
supporting Web services, WebDAV is a particularly suitable framework
for calendar data. HTTP URLs to calendar objects can be used
natively in these systems. WebDAV provides property information in
an XML format, easily consumed by Web services which usually import
XML data anyway. Web interfaces can use stylesheets to transform XML
data into HTML presentation.
The concept of using
HTTP/WebDAV as a basis for a calendaring server is by no means a new
concept: it was discussed in the CALSCH working group as early as
1997 or 1998. Several companies have implemented calendaring servers
using HTTP PUT/GET to upload and download iCalendar events, and using
WebDAV PROPFIND to get listings of resources. However, those
implementations do not interoperate because there are many small and
big decisions to be made in how to model calendaring data as WebDAV
resources and properties, as well as how to implement required
features that aren't already part of WebDAV.
WebDAV offers a number of advantages as a framework or basis for
calendar access. Most of these advantages boil down to a significant
reduction in design costs, implementation costs, interoperability
test costs, deployment costs, and the costs of mistakes. Every new
standard author or implementor finds certain small errors and the
IETF spends considerable time and effort remediating these. Some of
the advantages are contingent upon the way WebDAV is used, which is
why this section exploring advantages is inseparable from the rest of
this document for the moment...
The HTTP/WebDAV feature model encourages a wide range of clients,
from extremely simple to very rich. This is because servers must
support a wide range of features, but clients can pick and choose
which features to support. For example, even though a WebDAV server
must support the 'lockdiscovery' property, there's no requirement for
a client to request or parse this property value if it has no need
to. Generally speaking, clients may pick and choose which methods
and properties to support, as long as the client has a reasonable
response to the error conditions which might be returned. A simple
client can merely download and upload iCal objects and use very
little XML or advanced WebDAV functionality..." [excerpted]
The IETF iCalendar RFC "defines the format for specifying iCalendar object methods. An iCalendar object method is a set of usage constraints for the iCalendar object. For example, these methods might define scheduling messages that request an event be scheduled, reply to an event request, send a cancellation notice for an event, modify or replace the definition of an event, provide a counter proposal for an original event request, delegate an event request to another individual, request free or busy time, reply to a free or busy time request, or provide similar scheduling messages for a to-do or journal entry calendar component. The iCalendar Transport-indendent Interoperability Protocol (iTIP, RFC 2446) is one such scheduling protocol..."
- "Internet Calendaring and Scheduling Core Object Specification (iCalendar)." By Frank Dawson (Lotus Development Corporation) and Derik Stenerson (Microsoft Corporation). IETF Network Working Group, Request for Comments #2445. November 1998. Produced by the Internet Engineering Task Force Calendaring and Scheduling Working Group. Line-numbered version. [cache]
- "iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries." By Frank Dawson, Ross Hopson, Steve Mansour, Steve Silverberg, Anik Ganguly, and Robert Moskowitz. IETF Network Working Group, Request for Comments #2446. November 1998. "This document specifies how calendaring systems use iCalendar objects to interoperate with other calendar systems. It does so in a general way so as to allow multiple methods of communication between systems. Subsequent documents specify interoperable methods of communications between systems that use this protocol. The document outlines a model for calendar exchange that defines both static and dynamic event, to-do, journal and free/busy objects. Static objects are used to transmit information from one entity to another without the expectation of continuity or referential integrity with the original item. Dynamic objects are a superset of static objects and will gracefully degrade to their static counterparts for clients that only support static objects. This document specifies an Internet protocol based on the iCalendar object specification that provides scheduling interoperability between different calendar systems. The Internet protocol is called the 'iCalendar Transport-Independent Interoperability Protocol (iTIP)'."
- "iCalendar Message-Based Interoperability Protocol (iMIP)." By By Frank Dawson, Steve Mansour, and Steve Silverberg. November 1998. IETF Network Working Group, Request for Comments #2447. November 1998. This iMIP document "specifies a binding from the iCalendar Transport-independent Interoperability Protocol (iTIP) to Internet email-based transports. Calendaring entries defined by the iCalendar Object Model are composed using constructs from RFC-822, RFC-2045, RFC-2046, RFC-2047, RFC-2048, and RFC-2049. This document is based on discussions within the Internet Engineering Task Force (IETF) Calendaring and Scheduling (CALSCH) working group..."
- "Building an RDF Model: A Quick Look at iCalendar." By Tim Berners-Lee. "I spent a few hours reading 50 pages of the iCalendar RFC2445 with a view to evaluating proposals to put it into XML. My conclusion early on was that the spec should be written in terms of RDF properties, particularly as it has a clear property/value and parameter/value structure..."
- iCalendar SIP-Based Interoperability Protocol. Reference: 'draft-pessi-calsch-isip-00'. October 2002. "This document, proposes a binding from the abstract iCalendar Transport-independent Interoperability Protocol (iTIP) using Session Initiation Protocol (SIP) as transport and SIP/SIPS URIs as addresses. This document proposes using the XML iCalendar or xCal as a mandatory payload format with SIP. XML iCalendar is an XML DTD that corresponds to the iCalendar, Internet Calendaring and Scheduling Core Object Specification defined by RFC 2445. SIP is a application-layer signaling protocol for creating, modifying, and terminating multimedia sessions, retrieving user presence and sending instant messages..."
- "Guideline for use of XML with iCalendar Elements." By Tim Hare. IETF Network Working Group, Internet Draft. Reference: 'draft-hare-xcalendar-00'. May 18, 2004, expires November 16, 2004. 46 pages. "This memo defines a guideline for using XML to represent calendaring information that corresponds to the iCalendar, Internet Calendaring and Scheduling Core Object Specifications..." IETF source: http://www.ietf.org/internet-drafts/draft-hare-xcalendar-00.txt.
- Beyond iCal downloads. "Extend your calendaring with these free applications: CalendarUpload, iCal FTP X, iCal2blog X, PHP iCalendar, Mozilla Calender and Sunbird..."
The IETF xCal draft "defines a XML Document Type Definition (DTD) that corresponds to the iCalendar, Internet Calendaring and Scheduling Core Object Specification defined by RFC 2445. This DTD provides equivalent functionality to the standard format defined by 'Internet Calendaring and Scheduling Core Object Specification (iCalendar)'. Documents structured in accordance with this DTD may also be known as 'XML iCalendar' documents or 'xCal'..."
An attempt has been made to leverage the standard features of the XML syntax in order to represent the component iCalendar semantics. For example, strong data typing is specified using the XML notation declaration. The element type attributes are used to represent many of the calendar properties that provide a "global attribute" capability in an iCalendar object. Binary content in the ATTACH component property may either be specified through an external entity reference to a non-XML binary content or may be included in the XML document's content information, after first being encoding using the BASE64 scheme of RFC 2146. Parameter entities are used to logically group content particles in the XML DTD in order to facilitate reading and comprehension of the structure specified by the iCalendar XML DTD..." [excerpted from Version 02]
- "iCalendar DTD Document (xCal)." By Frank Dawson (Nokia Corporation), Surendra K. Reddy (Oracle), Doug Royer (INET-Consulting LLC), and Eric R. Plamondon (Oracle). IETF Network Working Group, Internet-Draft. July 25, 2002, expires January 23, 2003. Reference: draft-ietf-calsch-many-xcal-02'. 53 pages.
- Version 01. February 15, 2002.
- Version 00. August 20, 2001.
- Mailing list archives for 'xcal-dev'. Maintained by INET-Consulting.com, Inc.
- "iCalendar DTD Document (xCal)" - Local reference page (2001)
"SkiCal is a machine-readable format for the interchange of enhanced yellow-page directory listings. SkiCal expands the traditional property-set of name, address, telephone number and business category, adding structured information about people, places, things, activities and the conditions and terms for interaction with resources. SkiCal provides a structure for information about dates and times, directions, rules and recommendations for participation, pricing and reservation schemes, access information for those with special needs, ownership and responsibilities and promotional material. The referents of these listings, which are both events and persistent resources are referred to in this draft as SkiSources. SkiCal is based on and extends the iCalendar format as defined by RFC-2445, Internet Calendaring and Scheduling Core Object Specification (iCalendar). SkiCal objects are comprised of either VEVENT components with the addition of new properties and property parameters, or the SkiCal specific VOPTIME calendar component described in this memo..."
- SkiCal - An Extension of iCalendar. By Greg FitzPatrick (SkiCal Consortium), Pär Lannerö (Metamatrix), and Niklas Hjelm (Soft Applications). IETF CALSCH Working Group. Reference: 'draft-many-ical-ski-06'. October 25, 2002, expires April 25, 2003.
- Announcement for version 06
- "SkiCal: A DAML+OIL Case Study." By Libby Miller (University of Bristol) and Greg FitzPatrick (SkiCal Consortium). "The iCalendar mime-directory standard is a format for describing events, to-do lists and journals, including associated date-formats, time zones, and alarms. It is used in the calendaring and scheduling applications of most major desktop and PDA personal information managers. SkiCal is an extension to iCalendar which describes public events such as concerts, sports competitions and conferences. DAML+OIL language constructs are capable of describing aspects of SkiCal objects such as price, age restrictions and start and end dates and times with precision and flexibility. SkiCal makes for a practical and useful potential application of DAML+OIL. In our presentation we describe the DAML+OIL language in general terms, and show some ways in which it can be of practical use for creating applications which store and retrieve SkiCal and other event-based information."
The Calendaring and Scheduling Consortium is "focused on the interoperable exchange of calendaring and scheduling information between dissimilar programs, platforms, and technologies. The Consortium's mission is to promote general understanding of and provide mechanisms to allow interoperable calendaring and scheduling methodologies, tools and applications to enter the mainstream of computing... The first Interop will be hosted by the University of California at Berkeley on its Berkeley campus on 29-30 July, 2004...
[December 22, 2005] Update to RFC: Calendar Access Protocol (CAP). Edited by Doug Royer (IntelliCal, LLC), George Babics (Oracle), and Steve Mansour (eBay). IETF Network Working Group. Experimental Request for Comments #4324. 131 pages. "The Calendar Access Protocol (CAP) described in this memo permits a Calendar User (CU) to utilize a Calendar User Agent (CUA) to access an iCAL-based Calendar Store (CS). At the time of this writing, three vendors are implementing CAP, but it has already been determined that some changes are needed. In order to get implementation experience, the participants felt that a CAP specification is needed to preserve many years of work. Many properties in CAP which have had many years of debate, can be used by other iCalendar protocols." [source]
The Calendar Access Protocol (CAP) document 'specifies how a Calendar CUA interacts with a CS to
manage calendar information. In particular, it specifies how to
query, create, modify, and delete iCalendar components (e.g., events,
to-dos, or daily journal entries). It further specifies how to search
for available busy time information. Synchronization with CUAs is not
covered and believed to be possible using CAP.
CAP is specified as a BEEP 'profile'. As such, many aspects of the
protocol (e.g., authentication and privacy) are provided within
BEEP. The protocol data units leverage the standard iCalendar
format iCAL to convey calendar related information.
CAP can also be used to store and fetch iTIP objects and when those
objects are used in this memo, they mean exactly the same as defined
in iTIP. When iCalendar objects are transferred between the CUA and
a CS, some additional properties and parameters may be added and the
CUA is responsible for correctly generating iCalendar objects to non
The definition of new components, properties, parameter's, and value
types are broken into two parts. The first part summarizes and
defined the new objects. The second part provides the detail and any
ABNF for those objects. The ABNF in CAP as in other iCalendar
specifications is order independent. That is properties in a
component may occur in any order and parameters in any property may
occur in any order..." [adapted from version 11]
The W3C RDF Calendar Taskforce is "an informal grouping of individuals interested in calendaring and scheduling, primarily in RDF. Through scenario-lead discussion by email and irc, the taskforce will aim to draft an RDF schema for calendar events. It will also aim to demonstrate the use of RDF in a calendaring and scheduling context. There is a great deal of work being done in the IETF in this area in particular in the IETF Calendaring and Scheduling (calsch) working group, The taskforce will monitor that work; this monitoring will result in a list of calendar resources on the taskforce's homepage. The taskforce is open to anyone interested in RDF calendaring and scheduling..."
"The www-rdf-calendar list is provided for detailed technical discussion of systems, vocabulary and scenarios relating to the use of RDF and XML with calendaring and scheduling tools on the Web."
"Some goals or use cases include:
- RdfCalendar wiki
- RDF Calendar Taskforce
- Mail Archives for W3C list email@example.com
- SWAD-Europe Workshop on the Semantic web and Calendaring October 09, 2002. Bristol, UK. See the meeting announcement.
- Semantic Web calendaring SWAD-Europe Deliverable 3.7, Developer Workshop Report 2.
- RDF Calendar Workspace
- Test directory
- "The RDF Calendar Task Force." By Leigh Dodds. From XML.com (July 25, 2001).
- RDF Calendar Notes
- "RDFiCal: iCalendar in RDF." By Libby Miller (Institute for Learning and Research University of Bristol) and Dan Connolly (W3C). Paper submitted to WWW2004. "This paper describes the development of RDFiCal, an RDF vocabulary (ontology) for describing calendar events based on the iCalendar standard (RFC 2445). It describes the reasons for creating the RDFiCal vocabulary and the iterative community process used to create it. It explains why we decided on a conversion process which was both highly automated and highly social, and describes why we think that modelling iCalendar in RDF is both feasible and useful..."
- "iCalendar to RDFical: a Semantic Web vocabulary created with community process-lite." By Libby Miller (ILRT, University of Bristol). Presentation to Intelligence, Agents, Multimedia Group, University of Southampton, 2003-11-03.
[The proposed] "vCalendar(TM) defines a transport and platform-independent format for exchanging calendaring and scheduling information in an easy, automated, and consistent manner. It captures information about event and "to-do" items that are normally used by applications such as a personal information managers (PIMs) and group schedulers. Programs that use vCalendar can exchange important data about events so that you can schedule meetings with anyone who has a vCalendar-aware program..." [from Internet Mail Consortium]
From RDF Site Summary 1.0 Modules: Event: "With RSS we have the ability grab news and summaries from other websites and display them on our portals. However, a key property of news is that they describe something that just happened. Therefore the most interesting news are the newest news. Not so with events such as conferences, product launches, training courses etc. Events take place on a certain date in the future, and can be announced years or just a few days in advance. So when we announce them, we need to sort them on the date of the event. because the most interesting events are those that are going to happen in the near future.
Imagine that you have a calendar on your website. Imagine then that this calendar can be set up to automatically grab announcements of events from the O'Reilly events website, letting know when the next Perl/Open Source conference is -- or the next IRC chat with Tim -- or the release schedule for a new book. This is what the event module will provide... This specification is not a reimplementation of RFC2445 iCalendar in RDF. In particular, it lacks such things as TODO and repeating events, and there is no intention of adding those parts to the specification..."
<ev:startdate> ( #PCDATA ) [W3CDTF]
<ev:enddate> ( #PCDATA ) [W3CDTF]
<ev:location> ( #PCDATA )
<ev:organizer> ( #PCDATA )
<ev:type> ( #PCDATA )
[July 06, 2004] "IPTC Working Group Releases EventsML 1.0 Business Requirements Document." - A fourth Working Draft of EventsML 1.0 Business Requirements has been produced by members of the IPTC EventsML Working Group. 'EventsML' is the provisional name for a new IPTC standard designed for effective interchange of newsworthy event information. The objective of the International Press Telecommunications Council (IPTC) EventsML Working Group is to "create an XML format to be used in notifications of news worthy events such as press conferences for distributions to news media and others users who have an interest in the information for internal or external purposes." This IPTC standard for describing newsworthy events and associated coverage will address: (1) "Event publishing: communication of information about events, including associated media; (2) Event planning: managing the coverage of breaking news or upcoming newsworthy events, including support for gathering associated media; (3) Event coverage: communication of information about coverage of events by news organizations, often referred to as a 'Daybook'. The proposed standard would include linkage between resulting news packages and event coverage information." Use cases documented in the draft include Planned Event Coverage, News Agency Daybook, Sports League Publishes a Season Schedule, Urgent Breaking News, and Urgent Breaking News. The EventsML specification is intended to be useful to organizations outside the IPTC. A proposed requirement is that it be compatible with other IPTC standards, and that it reuse existing external standards where possible. EventsML should interoperate easily with existing IPTC standards, specifically with the IPTC Subject Reference System, NewsML, SportsML, and NITF." The vCard and vCalendar standards are explicitly identified as specifications which should inform EventsML in terms of interoperability. The designers believe it may be possible to implement most or all of the EventsML requirements using NewsML...
EventsML is one of the IPTC news initiatives. It proposes to "create an XML format to be used in notifications of news worthy events such as press conferences for distributions to news media and others users who have an interest in the information for internal or external purposes." Objectives in the design of the format, according to the 2003-06 Framework draft, include: (1) An XML format that can be a stand-alone or be incorporated into other IPTC standards; (2) Contains relationship entity for relating to and / or from a news item; (3) Ability to extend the use of EventsML as a notification tool but also incorporates into resource management such an assignment desk."
Alan Karben presented an overview at the News Standards Summit; see slide 20 in "SportsML and Other Payload MLs for News." EventsML is for listings that help find readers things to do, including: Event Name; Event Backers; Dates; Places; People (contacts and participants); Categories.
From the report of the IPTC 2003 Autumn Meeting:
It was agreed that the EventsML Working Party will be taken into the Special Content Working Party as it will fit in with other work and it should be possible to make better use of available resources. A brief update on progress made with EventsML since the last meeting was provided by Dominic Chan (Canada Newswire). Initial sets of requirements have been provided by interested parties, consolidated and compared to the existing formats. It appears that vCal and iCal already address 60% to 70% of the IPTC requirements, while both formats have extension facilities. However, neither of these formats is XML based.
Subsequent discussions confirmed that several members -- along with outside parties -- had a real need for an Events language. The main point to be settled was the best way of doing this. To begin with, would it be better to base the system on an existing system such as vCal (or iCal), or to make a totally fresh start? Then, should the program be a purely internal IPTC development our would it be better to approach OASIS to see if it would be possible to gain support for a more widely based development project?
It was pointed out that the support of three OASIS members is needed to form a discussion group. Since IPTC and Reuters are members it was decided to try to find an interested third party to form a group, and establish the general level of interest. An addition consideration is that involving OASIS in the development process could help ensure that details of the planned work are more widely known, and reduce the possibility of other initiatives trying to deal with the same requirements.
In parallel with this approach it was decided to start work on the production of a conceptual model for a possible XML Schema. If a co-operative venture is established this model could be made available as a basis for development, otherwise it can form the basis of an IPTC project. Assuming that a modular design approach is adopted, and sufficient efforts can be made, it is estimated that a completed standard might be available in 12 to 18 months. Since the meeting a new 'Conceptual Schema' folder has been added to the files area of the EventsML discussion group. This area is intended to contain prototype XML Schema for EventsML for discussion -- it already contains an overview..." [from IPTC Mirror newsletter #117, December 2003.]
"The Historical Event Markup and Linking project provides a means of coordinating and navigating disparate historical materials on the internet. It includes: (1) an XML schema for historical events which describes the events' participants, dates, location and keywords; the schema associates these with source materials in print or on the web. (2) XSLT stylesheets that combine conforming documents and generate lists, maps and graphical timelines out of them. HEML integrates these resources using the Cocoon web publishing engine..."
|Receive daily news updates from Managing Editor, Robin Cover.|