One document matched: draft-reddy-xml-ical-00.txt
Internet-draft Lisa Lippert, Microsoft
<draft-reddy-xml-ical-00.txt> Surendra Reddy, Oracle
Expires May 1999 Doug Royer, Sun Microsystems
November 18, 1998
iCAL in XML
Status of this Memo
This document is an Internet-Draft. 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. Internet-Drafts may be updated, replaced, or
made obsolete by other documents at any time. It is not
appropriate to use Internet-Drafts as reference material or
to cite them other than as a "working draft" or "work in
progress".
To learn the current status of any Internet-Draft, please
check the 1id-abstracts.txt listing contained in the
Internet-Drafts Shadow Directories on ds.internic.net (US
East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West
Coast), or munnari.oz.au (Pacific Rim).
Distribution of this document is unlimited.
Abstract
The motivation for this proposal is the expanded scope and
diversity of the World Wide Web. The World Wide Web provides a
simple and effective means for users to search, browse, retrieve,
and publish information of their own available for others. Now
that Web browsers and servers are ubiquitous on the Internet, it
is worthwhile to use XML to encode calendar objects. The power
and extensibility of XML allows us to represent calendar data
objects as well-formed XML documents.
ICAL is an existing standard format for representing calendar
components. This draft explains how to represent calendar
components in XML that are compatible and easily translatable to
the iCAL format.
Copyright (C) The Internet Society 1998. All Rights
Reserved.
Lippert/Reddy/Royer 1 Expires May 1999
Internet-Draft iCAL in XML November 18, 1998
1.
Contents
1. Contents ...................................................2
2. Introduction ...............................................4
2.1. Problem to be solved ..................................4
2.1.1. Handheld and other thin clients.....................4
2.1.2. Interoperability....................................4
2.2. Overview ..............................................4
2.3. Solution Requirements .................................4
2.4. Terminology ...........................................4
2.5. Definitions ...........................................5
3. Why XML ....................................................5
3.1. Extensible ............................................5
3.1.1. Document Type Definition............................5
3.1.2. Namespaces..........................................5
3.2. De-coupled from UI and from storage format ............6
3.3. Lightweight ...........................................6
3.4. Searchable ............................................7
3.5. Working with XML and original iCAL format .............7
3.5.1. Conversion..........................................7
3.5.2. Supporting both XML-iCAL and original iCAL formats..7
3.6. Related standards .....................................7
3.6.1. ISO 8601 extended data time formats.................7
3.7. Using data types ......................................7
3.8. Internationalization ..................................8
3.8.1. Language support....................................8
3.8.2. Encoding support....................................8
3.9. Security ..............................................8
3.9.1. Encryption..........................................8
4. Details on use of XML ......................................8
4.1. Namespace .............................................8
4.2. Date/time format ......................................9
4.3. Lists of things .......................................9
5. Calendar Component Elements ...............................10
5.1. Calendar Message .....................................10
5.1.1. Example vcalendar..................................10
5.2. vevent XML element ...................................10
5.2.1. Example: Opaque vevent.............................10
5.2.2. Example: Transparent vevent........................11
5.2.3. Example: Annual vevent.............................11
5.3. vtodo XML element ....................................12
5.3.1. Example: vtodo.....................................12
5.4. vjournal XML element ................................13
5.4.1. Example: vjournal..................................13
5.5. vfreebusy XML element ................................14
5.5.1. Example: request for free/busy information.........14
5.5.2. Example: response to free/busy request.............14
5.5.3. Example: published free/busy information...........15
5.6. freebusyreq element ..................................15
5.7. freebusyresp element .................................16
5.8. busytime element .....................................16
5.9. vtimezone XML element ................................16
5.9.1. Example: vtimezone using rdate.....................17
5.9.2. Example: vtimezone with recurrence.................18
5.9.3. Example: vtimezone with end date...................18
Lippert/Reddy/Royer 2 Expires April 1999
Internet-Draft iCAL in XML November 18, 1998
5.10. standard .............................................19
5.11. daylight .............................................19
5.12. valarm XML element ...................................19
5.12.1. Example: Audio valarm ............................20
5.12.2. Example: Display valarm ...........................20
5.12.3. Example: Email valarm .............................20
5.12.4. Example: Procedural valarm ........................21
6. Calendar Property Elements ................................21
6.1. attachments ..........................................21
6.2. attach ...............................................22
6.3. attendees ............................................22
6.4. busystatus Property ..................................23
6.5. categories ...........................................23
6.6. class ................................................23
6.7. cn ...................................................24
6.8. comment ..............................................24
6.8.1. Simple comment example.............................24
6.8.2. Example of multiple comments.......................24
6.8.3. Example comment with alternate location............24
6.9. completed ............................................24
6.10. contact ..............................................25
6.10.1. Simple contact example ............................25
6.10.2. Contact list example ..............................25
6.11. created ..............................................25
6.12. statusdata ...........................................26
6.13. description ..........................................26
6.14. direntry .............................................26
6.15. dtend ................................................26
6.16. dtstamp ..............................................27
6.17. dtstart ..............................................27
6.18. due ..................................................28
6.19. duration .............................................28
6.20. exdates ..............................................29
6.21. exrule ...............................................29
6.22. freebusy .............................................30
6.23. from .................................................30
6.24. lastmodified .........................................31
6.25. location .............................................31
6.25.1. Example location with alternate languages .........31
6.25.2. Example location with alternate representations ...31
6.26. organizer ............................................31
6.27. percentcomplete ......................................32
6.28. priority .............................................32
6.29. rdate ................................................33
6.30. recurid ..............................................33
6.31. relatedto ............................................34
6.32. requeststatus ........................................35
6.32.1. Example of simple requeststatus ...................35
6.32.2. Example requeststatus with data ...................35
6.32.3. Example requeststatus with multiple descriptions ..36
6.33. resources ............................................36
6.34. rrule ................................................36
6.34.1. Alternative rrule format ..........................37
6.35. sequence .............................................37
6.36. sentby ...............................................37
Lippert/Reddy/Royer 3 Expires April 1999
Internet-Draft iCAL in XML November 18, 1998
6.37. status ...............................................37
6.38. statuscode ...........................................38
6.39. summary ..............................................38
6.40. telephoneNumber ......................................38
6.41. trigger ..............................................39
6.41.1. Example trigger from start ........................39
6.41.2. Example trigger at defined time ...................39
6.42. tzurl ................................................39
6.43. uid ..................................................40
7. SECURITY CONSIDERATIONS ...................................40
8. REFERENCES ................................................40
9. Authors' Addresses ........................................40
10. Full Copyright Statement ..............................41
2. Introduction
2.1.Problem to be solved
2.1.1. Handheld and other thin clients
Thin clients, such as handheld computers, have many restrictions
on how much software can be loaded. Since XML is a standard
format used by many other applications such as web browsers,
using XML will lead to smaller footprints to implement
calendaring on thin clients.
2.1.2. Interoperability
The XML format allows calendar data to be used by many
applications. The format will be more widely used if it can be
interpreted by general-purpose clients such as web browsers.
2.2.Overview
2.3.Solution Requirements
The XML format must be easily convertible to and from the
original iCAL format.
To be resolved: How does a client send an XML-iCAL component over
iMIP/iTIP?
To be resolved: How does a client indicate to another client over
iMIP/iTIP which format it prefers?
2.4.Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
"MAY" and "OPTIONAL" are to be interpreted as described in RFC
2119 [2119] and indicate requirement levels for compliant RVP
implementations.
Lippert/Reddy/Royer 4 Expires April 1999
Internet-Draft iCAL in XML November 18, 1998
2.5.Definitions
Component
A component is a vcalendar, vtodo, valarm, or other iCAL
component, which may be expressed in either original iCAL or
proposed XML-iCAL format. The component should express identical
semantics in either format.
3. Why XML
XML is a public format based on SGML to allow the design of new
document types for applications such as calendaring. The v1.0
specification [XML] was accepted by the W3C as a Recommendation
on Feb 10, 1998.
3.1.Extensible
XML is designed to be extensible. Clients can ignore tags which
they do not understand.
3.1.1. Document Type Definition
XML allows a DTD (Document Type Definition) to be sent along with
the XML data. This allows clients to interpret data in
previously unknown formats. So if a vendor decides to extend the
iCalendar XML format, it can include the DTD for
interoperability.
However, DTDs are optional in XML bodies. That means that for
calendaring applications, we can define a standard format for the
basic calendaring data and not include the DTD in every ordinary
component.
3.1.2. Namespaces
XML uses namespaces to distinguish between elements that may have
the same name but for different purposes. This allows XML
formats to be very extensible: newly defined elements can be
assigned to namespaces which distinguish them from old elements
of the same name. The XML namespaces draft is in W3C last call
currently and is a mature draft.
This hypothetical example shows how "Foo Enterprises" could
extend the namespace for their custom calendar store, to allow
events to have ratings:
<C:vevent xmlns:C="urn:schemas:ical:">
<C:dtstart DCD:dt="dateTime.tz">1997-11-02T18:00</C:dtstart>
<C:summary>Interview with Robert Dusseault</C:summary>
<F:rating xmlns:F="http://schemas.foo.com/TV">
PG-13</F:rating>
</C:vevent>
Lippert/Reddy/Royer 5 Expires April 1999
Internet-Draft iCAL in XML November 18, 1998
Clients which are not familiar with the rating element can still
understand the vevent component.
It is also possible to redefine an element with the same name.
For example, a future enhancement to calendar item formats might
redefine start time to allow a range of possible start times:
<C:vevent xmlns:C="urn:schemas:ical:">
<C2:dtstart xmlns:C2="urn:schemas:ical2:"
DCD:dt="dateTime.tz">
<C2:begin>1997-11-02T18:00</C2:begin>
<C2:end>1997-11-02T18:02</C2:end>
</C2:dtstart>
...
</C:vevent>
With the namespace clearly defined for new element styles, an old
client can ignore the element if it doesn't understand the new
format.
It is possible to define a default namespace for an XML document,
which means that the prefix isn't required for all elements. The
example above could be rewritten to avoid prefixes for the
default namespace, as follows:
<vevent xmlns="urn:schemas:ical:">
<dtstart DCD:dt="dateTime.tz">1997-11-02T18:00</dtstart>
<summary>Interview with Robert Dusseault</summary>
<F:rating xmlns:F="http://schemas.foo.com/TV">
PG-13</F:rating>
</vevent>
Note that the namespace prefix is still present for non-default
namespaces such as DCD and the imaginary TV ratings schema. In
the rest of this document, default namespaces will be used for
brevity, although both are equally understood by XML parsers that
support namespaces.
3.2.De-coupled from UI and from storage format
XML was designed to be de-coupled from how information is stored,
and also from how information is displayed. It's the information
"middleman" format. Data in all sorts of storage formats can be
easily converted to XML, and XML can be easily displayed by
special-purpose or general-purpose clients.
3.3.Lightweight
XML parsers are lightweight. The XML format can also be used for
many different kinds of data. Standardizing on one kind of data
format rather than many reduces the requirements for clients.
Lippert/Reddy/Royer 6 Expires April 1999
Internet-Draft iCAL in XML November 18, 1998
Portable devices in particular can benefit from lightweight data
formats.
The XML format results in lengthy data markup documents, but
lends itself nicely to existing compression scheme.
3.4.Searchable
XML was designed to be searchable. It enables searching for
documents "by a person named Winston Churchill" rather than
"containing the string Winston Churchill".
3.5.Working with XML and original iCAL format
3.5.1. Conversion
XML formats can be converted quite simply to and from iCAL
formats.
This format was designed such that conversion to and from XML-
iCAL and original iCAL formats would be simple and preserve all
information.
3.5.2. Supporting both XML-iCAL and original iCAL formats
With MIME multipart documents, it is possible to include both
formats.
For a server that supports both formats and can convert between
the two, SCAP allows clients to specify which format they prefer.
3.6.Related standards
XML works nicely with other standards, such as ISO 8601 data
formats.
3.6.1. ISO 8601 extended data time formats
XML DCDs have already defined a data type for ISO 8601 date time
format (see below).
Because the data typing is extensible, other date/time formats
may also be defined and standardized.
3.7.Using data types
XML data types provide an extensible way of specifying how to
interpret data.
Example:
<dtend DCD:dt="dateTime.tz">2088-04-07T18:39:09-08:00</dtend>
This example shows the dtend expressed in ISO8601 date/time
format with optional timezone offset.
Lippert/Reddy/Royer 7 Expires April 1999
Internet-Draft iCAL in XML November 18, 1998
Data types can also be an integral part of the element
definition, so that the data type may default to a particular
type, or may be restricted to a particular type as in this
example definition:
<!ELEMENT dtend (#PCDATA)>
<!ATTLIST dtend dt:dt CDATA #FIXED "dateTime.tz">
For more information on data types, see [DCD].
3.8.Internationalization
3.8.1. Language support
XML has built-in support for specifying the language of text
elements [XML]. The xml:lang attribute may be inserted to
specify the language of an element which contains text. The
value of the xml:lang attribute is a case-insensitive language
identifier such as "en" for English, or "en-GB" for British
English.
Example:
<summary xml:lang="en-GB">Choose colours for
packaging</summary>
<summary xml:lang="en-US">Choose colors for
packaging</summary>
It is not necessary to put the xml:lang attribute on every
string: the xml:lang attribute can be put on a container
component to apply to every sub-component except noted exceptions
(see example for vcalendar, section 5.1).
3.8.2. Encoding support
XML bodies can be marked with a particular type of encoding, for
example:
<?xml encoding='UTF-8'?>
3.9.Security
3.9.1. Encryption
There are existing ways of encrypting XML.
4. Details on use of XML
Note that XML is case sensitive.
4.1.Namespace
The namespace for all iCAL elements in XML will be
"urn:schemas:ical:"
Lippert/Reddy/Royer 8 Expires April 1999
Internet-Draft iCAL in XML November 18, 1998
4.2.Date/time format
Recommend use of ISO 8601 extended format for date/time data.
This should be fairly easy to convert to iCAL (which uses the ISO
non-extended format), and would result in simpler XML formatting.
This is also defined for use by [DCD], which allows an individual
element's data type to be defined.
Examples:
<dtstart DCD:dt="dateTime.tz">1998-09-09T18:30-08:00</dtstart>
<dtstart DCD:dt="dateTime.tz">1998-09-09</dtstart>
<dtstart DCD:dt="dateTime">1998-09-09</dtstart>
<dtstart DCD:dt="date">1998-09-09</dtstart>
These are all valid because in "dateTime.tz" the time and
timezone are optional, and in dateTime the time is optional.
Recommend use of ISO 8601 extended format also for "duration",
which is defined in [DCD] as the "interval" data type.
4.3.Lists of things
In this document, rather than have multiple ways of doing lists
of things (comma-separated values of one property, vs. several
properties), the <li> or "list" element (standard to HTML) is
used as a list delimiter. The value of the data within the <li>
element depends on the container outside the <li> element. For
example, for the "categories" element the contents of each list
element is a string.
<categories>
<li>XML project<li>
<li>Calendaring<li>
</categories>
The <li> element may be omitted when there is only one item in
the list.
When there are multiple elements such as multiple locations, this
means the extras are alternates, NOT a list. E.g.
<location xml:lang="en">Germany</location
<location xml:lang="no">Tyskland</location>
Lippert/Reddy/Royer 9 Expires April 1999
Internet-Draft iCAL in XML November 18, 1998
5. Calendar Component Elements
5.1.Calendar Message
Calendar messages are [XML] documents that are sent between SCAP
client and server. The XML definition of a Calendar message is as
follows:
<!ELEMENT vcalendar (prodid, (vevent | vtodo | vjournal |
vfreebusy | vtimezone )+)>
5.1.1. Example vcalendar
<?xml version='1.0' encoding='UTF-8'?>
<vcalendar xmlns:C='urn:schemas:ical:' xml:lang='fr'>
<prodid> -//hacksw/handcal//NONSGML v1.0//EN</prodid>
<vevent>
<summary>Une entrevue avec Robert Dusseault</summary>
...
</vevent>
</vcalendar>
5.2.vevent XML element
Name: vevent
Purpose: Provide a grouping of component properties that
describe an event.
Description: A vevent XML element is a grouping of component
properties and an OPTIONAL 'valarm' XML element
that represent a scheduled amount of time on a
calendar.
Definition: <!ELEMENT vevent (attach*, attendee*, categories*,
class?, comment*, contact*, created?, description?,
(dtend | duration)?, dtstart, exdate*, exrule*,
lastmodified?, location?, organizer?, priority?,
rstatus? related*, resources*, rdate*, rrule*,
dtstamp, sequence?, status? summary, transp?, uid,
url?, recurid?)>
5.2.1. Example: Opaque vevent
The following is an example of the 'vevent' calendar component
used to represent a meeting that will also be opaque to searches
for busy time:
Lippert/Reddy/Royer 10 Expires April 1999
Internet-Draft iCAL in XML November 18, 1998
<?xml version='1.0' encoding='UTF8' xml:lang='en' ?>
<vcalendar xmlns='urn:schemas:ical:' >
<prodid> :-//hacksw/handcal//NONSGML 1.0//EN</prodid>
<vevent>
<uid>19970901T130000Z-123401@host.com</uid>
<dtstamp DCD:dt='dateTime.tz'>1997-09-01T13:00</dtstamp>
<dtstart DCD:dt='dateTime.tz'>1997-09-03T16:30</dtstart>
<dtend DCD:dt='dateTime.tz'>1997-09-03T19:00</dtend>
<summary>Annual Employee Review</summary>
<class>PRIVATE</class>
<categories>
<li>BUSINESS</li>
<li>HUMAN RESOURCES</li>
</categories>
</vevent>
</vcalendar>
(Note: The 'xml' element and 'vcalendar' container will be
omitted in further examples.)
5.2.2. Example: Transparent vevent
The following is an example of the 'vevent' calendar component
used to represent a reminder that will not be opaque, but rather
transparent, to searches for busy time:
<vevent xmlns="urn:schemas:ical:">
<uid>19970901T130000Z-123402@host.com</uid>
<dtstamp DCD:dt="dateTime.tz">1997-09-01T13:00</dtstamp>
<dtstart DCD:dt="dateTime.tz">1997-04-01T16:30</dtstart>
<dtend DCD:dt="dateTime.tz">1997-04-02T010:00</dtend>
<summary> Laurel is in sensitivity awareness
class.</summary>
<class>PUBLIC</class>
<categories>
<li>BUSINESS</li>
<li>HUMAN RESOURCES</li>
</categories>
<transp>transparent</transp>
</vevent>
5.2.3. Example: Annual vevent
The following is an example of the "vevent" calendar component
used to represent an anniversary that will occur annually. Since
it takes up no time, it will not appear as opaque in a search
for busy time; no matter what the value of the "transp" property
indicates:
<vevent xmlns="urn:schemas:ical:">
<uid>19970901T130000Z-123403@host.com</uid>
<dtstamp DCD:dt="dateTime.tz">1997-09-01T13:00</dtstamp>
Lippert/Reddy/Royer 11 Expires April 1999
Internet-Draft iCAL in XML November 18, 1998
<dtstart DCD:dt="dateTime.tz">1997-11-02</dtstart>
<summary>Our Blissful Anniversary</summary>
<class>CONFIDENTIAL</class>
<categories>
<li>ANNIVERSARY</li>
<li>PERSONAL</li>
<li>SPECIAL OCCASION</li>
</categories>
<rrule freq="YEARLY"/>
</vevent>
5.3.vtodo XML element
Name: vtodo
Purpose: Provide a grouping of calendar properties that
describe a to-do.
Description: A "vtodo" calendar component is a grouping of
component properties and an OPTIONAL "valarm"
calendar component that represent an action-item or
assignment.
Definition: <!ELEMENT vtodo (attach*, attendee*, categories*,
class?, comment*, contact*, completed?, created?,
description?, (dtend|duration)?, dtstart?, exdate*,
exrule*, lastmodified?, location?, organizer?,
percent?, priority, rstatus? related*, resources*,
rdate*, rrule*, dtstamp, sequence?, status?
summary, transp?, uid, url?, recurid?)>
5.3.1. Example: vtodo
The following is an example of a "vtodo" calendar component:
<vtodo xmlns="urn:schemas:ical:">
<uid>19970901T130000Z-123404@host.com</uid>
<dtstamp>1997-09-01T13:00-8:00</dtstamp>
<dtstart>1997-04-15T13:30:00-8:00</dtstart>
<due>1997-04-16T04:59:59-8:00</due>
<summary>1996 Income Tax Preparation</summary>
<class>CONFIDENTIAL</class>
<categories>
<li>BUSINESS</li>
<li>FAMILY</li>
<li>FINANCE</li>
</categories>
<priority>1</priority>
<status>NEEDS-ACTION</status>
</vtodo>
Lippert/Reddy/Royer 12 Expires April 1999
Internet-Draft iCAL in XML November 18, 1998
5.4. vjournal XML element
Name: vjournal
Purpose: Provide a grouping of component properties that
describe a journal entry.
Description: A "vjournal" calendar component is a grouping of
component properties that represent one or more
descriptive text notes on a particular calendar
date. The "dtstart" property is used to specify the
calendar date that the journal entry is associated
with. Generally, it will have a DATE value data
type, but it MAY also be used to specify a DATE-
TIME value data type.
Examples of a journal entry include a daily record
of a legislative body or a journal entry of
individual telephone contacts for the day or an
ordered list of accomplishments for the day. The
"vjournal" calendar component can also be used to
associate a document with a calendar date.
The "vjournal" calendar component does not take up
time on a calendar. Hence, it does not play a role
in free or busy time searches -- it is as though it
has a time transparency value of transparent. It is
transparent to any such searches.
Definition: <!ELEMENT vjournal (attach*, attendee*,
categories*, class?, comment*, contact*, created?,
description*, dtstart, dtstamp, exdate*, exrule*,
lastmodified?, organizer?, rstatus? related*,
rdate*, rrule*, sequence?, summary, uid, url?,
recurid?)>
5.4.1. Example: vjournal
The following is an example of the "vjournal" calendar component:
<vjournal xmlns="urn:schemas:ical:">
<uid>19970901T130000Z-123405@host.com</uid>
<dtstamp>1997-09-01T13:00</dtstamp>
<dtstart>1997-03-17</dtstart>
<summary>Staff meeting minutes</summary>
<description>
1. Staff meeting: Participants include Joe, Lisa and Bob.
Aurora project plans were reviewed. There is currently no
budget reserves for this project. Lisa will escalate to
management. Next meeting on Tuesday.[LL1]
2. Telephone Conference: ABC Corp. sales representative
called to discuss new printer. Promised to get us a demo
by Friday.
3. Henry Miller (Handsoff Insurance): Car was totaled by
Lippert/Reddy/Royer 13 Expires April 1999
Internet-Draft iCAL in XML November 18, 1998
tree. Is looking into a loaner car. 654-2323 (tel).
</description>
<vjournal>
5.5.vfreebusy XML element
Name: vfreebusy
Purpose: Provide a grouping of component properties that
describe either a request for free/busy time,
describe a response to a request for free/busy time
or describe a published set of busy time.
Description: A "vfreebusy" calendar component is a grouping of
component properties that represents either a
request for, a reply to a request for free or busy
time information or a published set of busy time
information.
The "vfreebusy" calendar component is intended for
use in iCalendar object methods involving requests
for free time, requests for busy time, requests for
both free and busy, and the associated replies. The
recurrence properties ("rrule", "exrule", "rdate",
"exdate") are not permitted within a "vfreebusy"
calendar component. Any recurring events are
resolved into their individual busy time periods
using the "freebusy" property.
Definition: <!ELEMENT vfreebusy( freebusyreq | freebusyresp |
busytime )>
5.5.1. Example: request for free/busy information
The following is an example of a "vfreebusy" calendar component
used to request free or busy time information:
<vfreebusy xmlns="urn:schemas:ical:">
<freebusyreq>
<organizer>MAILTO:jane_doe@host1.com</ORGANIZER>
<attendee>MAILTO:john_public@host2.com</attendee>
<dtstart DCD:dt="dateTime.tz">1997-10-15T05:00</dtstart>
<dtend DCD:dt="dateTime.tz">1997-10-16T05:00</dtend>
<dtstamp DCD:dt="dateTime.tz">1997-09-01T08:30<dtstamp>
<sequence>0</sequence>
<uid>19970901T0830000-uid1@host1.com</uid>
</freebusyreq>
</vfreebusy>
5.5.2. Example: response to free/busy request
The following is an example of a "vfreebusy" calendar component
used to reply to the request with busy time information:
Lippert/Reddy/Royer 14 Expires April 1999
Internet-Draft iCAL in XML November 18, 1998
<vfreebusy xmlns="urn:schemas:ical:">
<freebusyresp href="http://host2.com/busy/jp-01.vcs">
<attendee>MAILTO:john_public@host2.com</attendee>
<dtstamp DCD:dt="dateTime.tz">1997:09:01T10:00</dtstamp>
<C:sequence>0</C:sequence>
<uid>19970901T0830000-uid1@host1.com</uid>
<freebusy>
<li><dtstart>1997-10-15T05:00:00</dtstart>
<duration>PT8H30M</dtstart></li>
<li><dtstart>1997-10-15T16:00:00</dtstart>
<duration>PT5H30M</duration> </li>
<li><dtstart>1997-10-15T22:0:00</dtstart>
<duration>PT6H30M</duration></li>
</freebusy>
</freebusyresp>
<comment DCD:dt="string>This iCalendar file contains busy
time information for the next three months.</comment>
<vfreebusy>
5.5.3. Example: published free/busy information
The following is an example of a "vfreebusy" calendar component
used to published busy time information.
<vfreebusy xmlns="urn:schemas:ical:">
<busytime href="http://www.host.com/cal/fb/jsmith.ifb">
<attendee>MAILTO:jsmith@host.com</attendee>
<dtstart>1998-03-13T14:17:11</dtstart>
<dtend>1998-04-10T14:17:11</dtend>
<freebusy>
<li><dtstart>1998-03-14T23:30:00</dtstart>
<dtend>1998-03-15T00:30:00</dtend></li>
<li><dtstart>1998-03-16T15:30:00</dtstart>
<dtend>1998-03-16T16:30:00</dtend></li>
<li><dtstart>1998-03-18T03:00:00</dtstart>
<dtend>1998-03-18T04:00:00</dtend></li>
</freebusy>
</busytime>
</vfreebusy>
5.6.freebusyreq element
Name: freebusyreq
Purpose: Within a vfreebusy element, provide a request for
free/busy time.
Definition: <!ELEMENT freebusyreq ( attendee, dtstamp, dtstart,
dtend, uid, sequence?)>
The "freebusyreq" component MUST include the
"attendee", "dtstamp", "dtstart", "dtend", and
Lippert/Reddy/Royer 15 Expires April 1999
Internet-Draft iCAL in XML November 18, 1998
"uid" properties. In addition, it MUST include the
"sequence" property if its value is greater than
zero.
5.7.freebusyresp element
Name: freebusyresp
Purpose: Within a vfreebusy, provide a response with
free/busy time
Definition: <!ELEMENT freebusyresp( attendee, dtstamp,
freebusy, uid )>
The "freebusyresp" component MUST include the
"attendee", "dtstamp", "freebusy", and "uid"
properties. In addition, it MUST include the
"sequence" property if its value is greater than
zero.
5.8. busytime element
Name: busytime
Purpose: Within a vfreebusy, provide a busy time chunk
Definition: <!ELEMENT busytime (attendee, dtstamp, dtstart,
dtend, freebusy)>
The "busytime" component MUST include the
"attendee", "dtstamp", "dtstart", "dtend", and
"freebusy" properties.
5.9.vtimezone XML element
Name: vtimezone
Purpose: Provide a grouping of component properties that
defines a time zone.
Description: A time zone is unambiguously defined by the set of
time measurement rules determined by the governing
body for a given geographic area. These rules
describe at a minimum the base offset from UTC for
the time zone, often referred to as the Standard
Time offset.
If present, the "vtimezone" calendar component
defines the set of Standard Time and Daylight
Saving Time observances (or rules) for a particular
time zone for a given interval of time. The
"vtimezone" calendar component cannot be nested
within other calendar components.
Lippert/Reddy/Royer 16 Expires April 1999
Internet-Draft iCAL in XML November 18, 1998
Multiple "vtimezone" calendar components MAY exist
in an iCalendar object. In this situation, each
"vtimezone" MUST represent a unique time zone
definition. This is necessary for some classes of
events, such as airline flights, that start in one
time zone and end in another.
Definition: <!ELEMENT vtimezone ( tzid, lastmodified?, tzurl?,
(standard | daylight)) >
The properties in a "vtimezone" element are: The
mandatory "tzid" property is a text value that
uniquely identifies the "vtimezone" calendar
component within the scope of an iCalendar object.
The optional "lastmodified" property is a UTC value
that specifies the date and time that this timezone
definition was updated. The optional "tzurl"
property is a url value that points to a published
"vtimezone" definiton.
5.9.1. Example: vtimezone using rdate
The following are examples of the "vtimezone" calendar component:
This is a simple example showing time zone information for the
Eastern United States using "rdate" property. Note that this is
only suitable for a recurring event that starts on or later than
April 6, 1997 at 02:00:00 EST (i.e., the earliest effective
transition date and time) and ends no later than April 7, 1998
02:00:00 EST (i.e., latest valid date and time for EST in this
scenario). For example, this can be used for a recurring event
that occurs every Friday, 8am-9am, starting June 1, 1997, ending
December 31, 1997.
<vtimezone xmlns="urn:schemas:ical:">
<tzid>America-New_York</tzid>
<lastmodified DCD:dt="dateTime.tz">
1987-01-01T00:00:00<lastmodified>
<standard>
<dtstart>1997-10-26T02:00:00</dtstart>
<rdate>1997-10-26T02:00:00</rdate>
<tzoffsetfrom>-04:00</tzoffsetfrom>
<tzoffsetto>-05:00</tzoffsetto>
<tzname>EST</tzname>
</standard>
<daylight>
<dtstart>1997-10-26T02:00:00</dtstart>
<rdate>1997-04-06T02:00:00</rdate>
<tzoffsetfrom>-05:00<tzoffsetfrom>
<tzoffsetto>-04:00</tzoffsetto>
<tzname>EDT</tzname>
</daylight>
</vtimezone>
Lippert/Reddy/Royer 17 Expires April 1999
Internet-Draft iCAL in XML November 18, 1998
5.9.2. Example: vtimezone with recurrence
This is a simple example showing the current time zone rules for
the Eastern United States using a rrule recurrence pattern. Note
that there is no effective end date to either of the standard
Time or Daylight Time rules. This information would be valid for
a recurring event starting today and continuing on into the known
future.
<vtimezone xmlns="urn:schemas:ical:">
<tzid>America-New_York<tzid>
<lastmodified DCD:dt="dateTime.tz">
1987-01-01T00:00:00</lastmodified>
<tzurl>http://zones.stdsrus.net/tz/America-New_York</tzurl>
<C:standard>
<dtstart>1967-10-29T02:00:00</dtstart>
<rrule freq="YEARLY" "
byday= -1SU" bymonth="10"/>
<tzoffsetfrom>-04:00</tzoffsetfrom>
<tzoffsetto>-05:00</tzoffsetto>
<tzname>EST</tzname>
</standard>
<daylight>
<dtstart>1987-04-05T02:00:00 </dtstart>
<rrule freq="YEARLY byday=
" "1SU" bymonth="4"/>
<tzoffsetfrom>-05:00</tzoffsetfrom>
<tzoffsetto>-04:00</tzoffsetto>
<tzname>EDT</tzname>
</daylight>
</vtimezone>
5.9.3. Example: vtimezone with end date
This is an example showing a fictitious set of rules for the
Eastern United States, where the Daylight Time rule has an
effective end date (i.e., after that date, Daylight Time is no
longer observed).
<vtimezone xmlns="urn:schemas:ical:">
<tzid>America-New_York</tzid>
<lastmodified DCD:dt="dateTime.tz">
1987-01-01T00:00:00Z</lastmodified>
<standard>
<dtstart>1967-10-29T02:00:00</dtstart>
<rrule freq="YEARLY" byday="-1SU" bymonth="10"/>
<tzoffsetfrom>-04:00<tzoffsetfrom>
<tzofsettto>-05:00</tzoffsetto>
<tzname>EST</tzname>
</standard>
<daylight>
<dtstart>1987-04-05T02:00:00</dtstart>
<rrule freq="YEARLY" byday="1SU" bymonth="1"
Lippert/Reddy/Royer 18 Expires April 1999
Internet-Draft iCAL in XML November 18, 1998
until="19980404T070000"/>
<tzoffsetfrom>-05:00</tzoffsetfrom>
<tzoffsetto>-04:00</tzoffsetto>
<tzname>EDT</tzname>
</daylight>
</vtimezone>
5.10. standard
Name: standard
Purpose: To contain information for the standard (not
daylight-savings) timezone offset rules.
Definition: <!ELEMENT standard ( comment*, dtstart, (rdate |
rrule)?. tzname*, tzoffsetto, tzoffsetfrom)>
5.11. daylight
Name: daylight
Purpose: To contain information about the daylight-savings
timezone offset rules.
Definition: <!ELEMENT daylight ( comment*, dtstart, (rdate |
rrule )?, tzname*, tzoffsetto, tzoffsetfrom)>
5.12. valarm XML element
Name: valarm
Purpose: Provide a grouping of component properties that
define an alarm.
Description: A "valarm" calendar component is a grouping of
component properties that is a reminder or alarm
for an event or a to-do. For example, it may be
used to define a reminder for a pending event or an
overdue to-do. The "valarm" calendar component MUST
include the "alarmtype" and "trigger" properties.
In addition, an AUDIO type of alarm MUST include
the "attach" property to point to a digital sound
resource to be played. The DISPLAY type of alarm
MUST include the "description" property. The EMAIL
type of alarm MUST include the "attendee",
"description" and "summary" properties. The
PROCEDURE type of alarm MUST include the "attach"
property to point to a procedure resource to be
invoked. The "valarm" calendar component MUST only
appear within either a "vevent" or "vtodo" calendar
component. The "valarm" calendar components cannot
be nested. Multiple "valarm" calendar components
MAY be specified.
Lippert/Reddy/Royer 19 Expires April 1999
Internet-Draft iCAL in XML November 18, 1998
Definition: <!ELEMENT valarm ( alarmtype, (trigger, (duration,
repeat)?, attach) | (description, trigger,
(duration, repeat)?) | (attendee*, attach*,
description, trigger, (duration, repeat)?, summary)
| (attach, description?, trigger, (duration,
repeat)?))>
5.12.1. Example: Audio valarm
The following example is for a "valarm" calendar component that
specifies an audio alarm that will sound at a precise time and
repeat 4 more times at 15 minute intervals:
<valarm xmlns="urn:schemas:ical:">
<alarmtype>AUDIO</alarmtype>
<trigger DCD:dt="dateTime.tz">1997-03-17T13:30:00</trigger>
<repeat>4</repeat>
<duration>PT15M</duration>
<attachments>
<attach>ftp://host.com/sounds/bell-01.wav</attach>
</attachments>
</valarm>
5.12.2. Example: Display valarm
The following example is for a "valarm" calendar component that
specifies a display alarm that will trigger 15 minutes before the
scheduled start of the event or the due date/time of the to-do it
is associated with and will repeat 2 more times at 15 minute
intervals:
<valarm xmlns="urn:schemas:ical:">
<alarmtype>DISPLAY</alarmtype>
<description>Breakfast meeting with executive team
</description>
<trigger>PT30M</trigger>
<repeat>2</repeat>
<duration>PT15M</duration>
</valarm>
5.12.3. Example: Email valarm
The following example is for a "valarm" calendar component that
specifies an email alarm that will trigger 2 days before the
scheduled due date/time of a to-do it is associated with. It does
not repeat. The email has a subject, body and attachment link.
<valarm xmlns="urn:schemas:ical:">
<alarmtype>EMAIL</alarmtype>
<attendee>mailto:john_doe@host.com</attendee>
<trigger>P2D</trigger>
<summary>
*** REMINDER: SEND AGENDA FOR WEEKLY STAFF MEETING ***
Lippert/Reddy/Royer 20 Expires April 1999
Internet-Draft iCAL in XML November 18, 1998
</summary>
<description>
A draft agenda needs to be sent out to the attendees to
the weekly managers meeting (MGR-LIST). Attached is a
pointer the document template for the agenda file.
</description>
<attachments>
<attach>http://host.com/templates/agenda.doc</attach>
</attachments>
</valarm>
5.12.4. Example: Procedural valarm
The following example is for a "valarm" calendar component that
specifies a procedural alarm that will trigger at a precise
date/time and will repeat 23 more times at one hour intervals.
The alarm will invoke a procedure file.
<valarm xmlns="urn:schemas:ical:">
<alarmtype>PROCEDURE</alarmtype>
<trigger DCD:dt="dateTime.tz">1998-01-01T05:00:00</trigger>
<repeat>23</repeat>
<duration>PT1H</duration>
<attachments>
<attach>ftp://host.com/procs/felizano.exe</attach>
</attachments>
</valarm>
6. Calendar Property Elements
Property: A property is the definition of an individual attribute
describing a calendar property or a calendar component. Property
names, attribute names and attribute values are case insensitive.
6.1.attachments
Name: attachments
Purpose: This element provides the capability to associate
one or more document objects with a calendar
component.
Description: The element MAY only be used within "vevent",
"vtodo", "vjournal", or "VALARM" calendar
components. This MAY contain multiple attachments.
Example:
<attachments>
<attach>ftp://host.com/pub/sounds/bell-01.wav</attach>
<attach>ftp://host.com/pub/foo.doc</attach>
</attachments>
Lippert/Reddy/Royer 21 Expires April 1999
Internet-Draft iCAL in XML November 18, 1998
6.2.attach
Name: attach
Purpose: The property provides URL to an attachment.
Datatype: Default datatype is a URI which is a pointer to an
attachment. If the value is not a URI, this must
be indicated with a "dt" attribute.
Description: The property must only be specified within an
attachments element. Encoding and file type
information should be indicated with "encoding" and
"type" attributes.
Example: <attachuri DCD:dt="bin.base64" encoding='base64'
type=image/basic>A193CB8872F9882</C:attachuri>
6.3.attendees
Name: attendees
Purpose: The property defines a list of attendees within a
calendar component.
Datatype: The datatype of each list element within the
attendees element is a URI which is a calendar
address. See Calendar Object Specification [iCAL]
for more info.
Description: The element is specified within the "vevent",
"vtodo", "vjournal calendar components to specify
participants, non-participants and the chair of a
group scheduled calendar entity. The property is
specified within the "VFREEBUSY" calendar component
to specify the calendar user associated with the
free or busy time. The property is specified within
an "EMAIL" category of the "VALARM" calendar
component to specify an email address that is to
receive the email type of iCalendar alarm.
Definition: <!ELEMENT attendees (#PCDATA) >
This property MUST be specified in an iCalendar
object that specifies a group scheduled calendar
entity. This property MUST be specified in an
iCalendar object that specifies the publication of
a calendar user's busy time. This property is not
specified in an iCalendar object that specifies
only a time zone definition or that defines
calendar entities that are not group scheduled
entities, but are entities only on a single user's
calendar.
Example: <attendees>MAILTO:johnp@host2.com</attendees>
Lippert/Reddy/Royer 22 Expires April 1999
Internet-Draft iCAL in XML November 18, 1998
6.4.busystatus Property
Name: busystatus
Purpose: Identify whether a chunk of free/busy time is free,
or busy, with possible detail if busy.
Description: If the busy time is associated with a time interval
that would be unavailable for scheduling in any
case the parameter MAY BE set to BUSY-UNAVAILABLE
or if the busy time that has been tentatively
scheduled the parameter MAY BE set to BUSY-
TENTATIVE. This element appears only in a
<freebusy> element.
Value: Default value is BUSY, providing no additional busy
status information.
6.5.categories
Name: categories
Purpose: This property defines the categories for a calendar
component.
Description: This property is used to specify categories or
subtypes of the calendar component. The categories
are useful in searching for a calendar component of
a particular type and category. Within the
"vevent", "vtodo" or "vjournal" calendar
components, more than one category MAY be specified
using the <li> element.
Definition: <!ELEMENT categories (#PCDATA) >
Example: <categories xml:lang=fr>mon projet</categories>
6.6.class
Name: class
Purpose: This property defines the access classification for
a calendar component.
Description: An access classification is only one component of
the general security system within a calendar
application. It provides a method of capturing the
scope of the access the calendar owner intends for
information within an individual calendar entry.
The content of the "class" element MAY be PUBLIC,
PRIVATE or CONFIDENTIAL.
Definition: <!ELEMENT class (#PCDATA)>
Lippert/Reddy/Royer 23 Expires April 1999
Internet-Draft iCAL in XML November 18, 1998
Example: <C:class>PUBLIC</C:class>
6.7.cn
Name: cn
Purpose: To display the "common name" of a contact,
organizer or delegate (in "sentby").
Definition: <!ELEMENT cn (#PCDATA)>
6.8.comment
Name: comment
Purpose: This property specifies non-processing information
intended to provide a comment to the calendar user.
Description: The property MAY contain a list of multiple
properties using the <li> element.
If there is an alternate representation of the
comment which can be found through a URI, use the
"alturi" attribute.
Datatype: The default datatype of this property is a string.
6.8.1. Simple comment example
<comment> We're looking forward to this event.</comment>
6.8.2. Example of multiple comments
<comment>
<li DCD:dt="uri">http://host.com/mystuff/comment.wav</li>
<li>We're looking forward to this event</li>
</comment>
6.8.3. Example comment with alternate location
<comment alturi="
http://host.com/mystuff/comment.wav
">
We're looking forward to this event.</comment>
6.9.completed
Name: completed
Purpose: This element defines the date and time that a to-do
was actually completed.
Datatype: Default datatype is ISO date/time ("dateTime.tz").
Examples: <completed DCD:dt="dateTime.tz"> 1997-03-
17T13:30:00</completed>
Lippert/Reddy/Royer 24 Expires April 1999
Internet-Draft iCAL in XML November 18, 1998
<completed>1997-03-17</completed>
6.10. contact
Name: contact
Purpose: The property is used to represent contact
information or alternately a reference to contact
information associated with the calendar component.
Description: The property value consists of textual contact
information. An alternative representation for the
property value MAY also be specified that refers to
a URI pointing to an alternate form, such as a
vCard, for the contact information. This element
may contain multiples using the <li> element.
Datatype: Default datatype is a string.
Definition: <!ELEMENT contact(cn, tel?)>
6.10.1. Simple contact example
<contact><cn>Lisa Lippert</cn></contact>
6.10.2. Contact list example
<contact>
<li>
<cn href="http://host.com/mystuff/LL.vcf>Lisa Lippert</cn>
<tel>882 8080</tel>
</li>
<li>
<cn>Frank Dawson</cn>
</li>
</contact>
6.11. created
Name: created
Purpose: This property specifies the date and time that the
calendar information was created in the calendar
user agent.
Datatype: Default datatype is ISO date/time ("dateTime.dt").
Description: The date and time the calendar information was
created.
Definition: <!ELEMENT created (#PCDATA)>
Example: <created>1997-03-17T13:30:00</created>
Lippert/Reddy/Royer 25 Expires April 1999
Internet-Draft iCAL in XML November 18, 1998
6.12. statusdata
Name: statusdata
Purpose: Provide extra string-formatted data to go in a
"requeststatus" element. May include multiple
strings separated with <li>.
Definition: <!ELEMENT statusdata (#PCDATA)>
6.13. description
Name: description
Purpose: This property provides a more complete description
of the calendar component than that provided by the
"summary" property.
Description: This property is used to capture lengthy textual
descriptions associated with the activity.
Datatype: Default datatype is DCD "string". Note that the
string data type implies no markup -- the WG should
consider whether to allow markup here.
An HREF attribute can be used along with or instead
of the string to point to the location of the
description.
Definition: <!ELEMENT comment(#PCDATA)>
Examples: <description xml:lang="en"> Status Meeting
</description>
<description href=http://host.com/stuff/desc.wav/>
6.14. direntry
Name: direntry
Purpose: Provide a pointer to an organizer's or delegate's
directory entry.
Datatype: Default datatype is a URI.
Definition: <!ELEMENT direntry (#PCDATA)>
Example: <direntry DCD:dt="uri">
ldap://host.com:6666/o=3DDC%20Associates,c=3DUS??
(cn=3DJohn%20Smith </direntry>
6.15. dtend
Name: dtend
Lippert/Reddy/Royer 26 Expires April 1999
Internet-Draft iCAL in XML November 18, 1998
Purpose: This property specifies the date and time that a
calendar component ends.
Datatype: DATE-TIME; The default datatype is DATE-TIME. The
datatype MAY BE reset to a DATE type.
Description: Within the "vevent" calendar component, this
property defines the date and time by which the
event ends. The value MUST be later in time than
the value of the "dtstart" property. Within the
"vfreebusy" calendar component, this property
defines the end date and time for the free or busy
time information. Within the "freebusy" element,
this property defines the end date and time for the
individual busy period.
Definition: <!ELEMENT dtend(#PCDATA)>
Example: <dtend DCD:dt="dateTime.dt">1997-03-T13:30</dtend>
<dtend>1997-03-T13:30</dtend>
6.16. dtstamp
Name: dtstamp
Purpose: The property indicates the date/time that the
instance of the iCalendar object was created.
Datatype: Default datatype is ISO date/time ("dateTime.tz").
Description: This property will assist in the proper sequencing
of messages containing iCalendar objects. This
property is different than the "created" and
"lastmodified" properties. These two properties are
used to specify when the calendar service
information was created and last modified. This is
different than when the iCalendar object
representation of the calendar service information
was created or last modified.
Example: <dtstamp>1997-03-17T13:30</dtstamp>
6.17. dtstart
Name: dtstart
Purpose: This property specifies when the calendar component
begins.
Datatype: Default datatype is ISO date/time ("dateTime.tz").
Description: In a "vevent" calendar component (MUST appear),
this defines the start date and time for the event.
Events MAY have a start date/time but no end
Lippert/Reddy/Royer 27 Expires April 1999
Internet-Draft iCAL in XML November 18, 1998
date/time. In that case, the event does not take up
any time.
In a "vfreebusy" calendar component, this property
defines the start date and time for the free or
busy time information.
In a "vtimezone" calendar component (MUST appear),
this property defines the effective start date and
time for a time zone specification.
In a "freebusy" element (MUST appear), this
property defines the end date and time for the
individual busy period.
Definition: <!ELEMENT dtstart(#PCDATA)>
Example: <dtstart>1997-03-17T13:30</dtstart>
6.18. due
Name: due
Purpose: This property defines the date and time that a to-
do is expected to be completed.
Datatype: Default datatype is ISO date/time ("dateTime.tz").
Description: The value MUST be a date/time equal to or after the
dtstart value, if specified.
Definition: <!ELEMENT due(#PCDATA)>
Example: <dtstamp DCD:dt="dateTime.dt">1997-03-17T13:30:00
</dtstamp>
6.19. duration
Name: duration
Purpose: The property specifies a duration of time.
Description: In a "vevent" calendar component, specifies a
duration of the event, instead of an explicit end
date/time.
In a "vtodo" calendar component, specifies a
duration for the to-do, instead of an explicit due
date/time.
In a "vfreebusy" calendar component, specifies the
interval of free time being requested.
In a "valarm" calendar component, specifies the
delay period prior to repeating an alarm.
Lippert/Reddy/Royer 28 Expires April 1999
Internet-Draft iCAL in XML November 18, 1998
In a "freebusy" element, the duration of the
individual busy (or free) period instead of an
explicit end date/time.
In a "rdate" element, the duration of the
recurrence period.
Datatype: The default syntax of the duration property is
defined in iCAL.
ISO8601 extended format can be used to define a
duration of data type "interval", as defined in
[DCD]. This format is recommended because existing
XML parsers understand the format.
Definition: <!ELEMENT duration(#PCDATA)>
Example: <duration>P15DT5H0M20S </duration>
<duration DCD:dt="interval">0000-00-
15T5:00:20</duration>
6.20. exdates
Name: exdates
Purpose: This property defines the list of date/time
exceptions for a recurring calendar component.
Datatype: Default datatype is ISO date/time ("dateTime.tz").
Description: The exception dates, if specified, are used in
computing the recurrence set. The recurrence set is
the complete set of recurrence instances for a
calendar component.
Example:
<exdates>
<li>1997-03-17</li>
<li>1997-03-24</li>
</exdates>
6.21. exrule
Name: exrule
Purpose: This property defines a rule or repeating pattern
for an exception to a recurrence set.
Description: The exception rule, if specified, is used in
computing the recurrence set. The recurrence set is
the complete set of recurrence instances for a
Lippert/Reddy/Royer 29 Expires April 1999
Internet-Draft iCAL in XML November 18, 1998
calendar component. The attributes "freq", "byday"
and "bysetpos" are used as defined in [iCAL].
Example: <exrule freq=MONTHLY byday=MO,TU,WE,TH,FR
bysetpos=-1 />
6.22. freebusy
Name: freebusy
Purpose: The element defines one or more free or busy time
intervals.
Description: These time periods MAY be specified as either a
start and end date-time or a start date-time and
duration. time format. The "freebusy" element MAY
include the "busystatus" property parameter to
specify whether the information defines a FREE or
BUSY time interval. The default "TYPE" property
parameter value is BUSY.
List elements within the "freebusy" elements SHOULD
be sorted in ascending order, based on start time
and then end time, with the earliest periods first.
Example:
<freebusy>
<li>
<busystatus>FREE</busystatus>
<dtstart>1997-03-08T16:00:00</dtstart>
<duration>PT3H</duration>
</li>
<li>
<busystatus>BUSY-UNAVAILABLE</busystatus>
<dtstart>1997-03-08T16:00:00</dtstart>
<dtend>1997-03-08T17:00:00</dtend>
</li>
</freebusy>
6.23. from
Name: from
Purpose: Identify where to trigger from (the start or end of
an event) in a "trigger" element
Datatype: string
Value: "start" or "end"
Example: <from>start</from>
Lippert/Reddy/Royer 30 Expires April 1999
Internet-Draft iCAL in XML November 18, 1998
6.24. lastmodified
Name: lastmodified
Purpose: The property specifies the date and time that the
information associated with the calendar component
was last revised.
Datatype: Default datatype is ISO date/time ("dateTime.tz").
6.25. location
Name: location
Purpose: The property defines the intended venue for the
activity defined by a calendar component.
Description: Specific venues such as conference or meeting rooms
may be explicitly specified using this property. An
alternate representation may be specified that is a
URI that points to directory information with more
structured specification of the location. This
element may include the xml:lang attribute.
When more than one location appears in a calendar
component, at least one location MUST be a string,
and others MAY be alternate formats (i.e. URI)
identified with a data type.
Datatype: Default datatype is a string.
6.25.1.
Example location with alternate languages
<location xml:lang="en">Germany</location
<location xml:lang="no">Tyskland</location>
6.25.2.
Example location with alternate representations
<location>Conference Room - F123, Bldg. 002</location>
<location DCD:dt="uri">
http://xyzcorp.com/conf
-
rooms/f123.vcf
</location>
6.26. organizer
Name: organizer
Purpose: The property defines the organizer for a calendar
component.
Datatype: Default datatype is a URI to be interpreted as a
calendaring address.
Lippert/Reddy/Royer 31 Expires April 1999
Internet-Draft iCAL in XML November 18, 1998
Description: The element is specified within the "vevent",
"vtodo", "vjournal calendar components to specify
the organizer of a group scheduled calendar entity.
The element is specified within the "vfreebusy"
calendar component to specify the calendar user
requesting the free or busy time.
Definition: <!ELEMENT organizer(cn?, url, direntry?, sentby?)>
This element MUST have a url which is a calendar
address.
Example:
<organizer>
<cn href=mailto:jsmith@host1.com>Jane Smith</cn>
<direntry DCD:dt="uri">
ldap://host.com:6666/o=3DDC%20Associates,c=3DUS??
(cn=3DJane%20Smith
</direntry>
<sentby>
<cn href="mailto:jdoe@host1.com">John Doe</cn>
</sentby>
</organizer>
6.27. percentcomplete
Name: percentcomplete
Purpose: This property is used by an assignee or delegatee
of a to-do to convey the percent completion of a
to-do to the Organizer.
Description: The property value is a postive integer between
zero and one hundred. A value of "0" indicates the
to-do has not yet been started. A value of "100"
indicates that the to-do has been completed.
Integer values in between indicate the percent
partially complete.
Example: <percentcomplete DCD:dt="int">50</percentcomplete>
6.28. priority
Name: priority
Purpose: The property defines the relative priority for a
calendar component.
Description: The priority is specified as an integer in the
range zero to nine. A value of zero (ASCII decimal
48) specifies an undefined priority. A value of one
(ASCII decimal 49) is the highest priority. A value
Lippert/Reddy/Royer 32 Expires April 1999
Internet-Draft iCAL in XML November 18, 1998
of two (ASCII decimal 50) is the second highest
priority. Subsequent numbers specify a decreasing
ordinal priority. A value of nine (ASCII decimal
58) is the lowest priority. Within a "vevent"
calendar component, this property specifies a
priority for the event. This property may be useful
when more than one event is scheduled for a
given time period. Within a "vtodo" calendar
component, this property specified a priority for
the to-do. This property is useful in prioritizing
multiple action items for a given time period.
6.29. rdate
Name: rdate
Purpose: This property defines the list of date/times for a
recurrence set.
Datatype: Default datatype is a list of ISO date/time
("dateTime.tz"). Alternately may contain "dtstart"
and "duration".
Issue: It is unclear what it means to have a
duration for a recurrence date, so it may be wrong
to allow dtstart and duration here.
Description: This property MAY appear along with the "rrule" to
define an aggregate set of repeating occurrences.
When they both appear in an iCalendar object, the
recurring events are defined by the union of
occurrences defined by both the "rdate" and
"rrule". The recurrence dates, if specified, is
used in computing the recurrence set. The
recurrence set is the complete set of recurrence
instances for a calendar component.
Definition: <!ELEMENT rdate(#PCDATA)>
Examples:
<rdate>
<li>1997-03-08</li>
<li>1997-03-15</li>
</rdate>
<rdate>
<dtstart>1997-03-08</dtstart>
<duration>00-00-14</duration>
</rdate>
6.30. recurid
Name: recurid
Lippert/Reddy/Royer 33 Expires April 1999
Internet-Draft iCAL in XML November 18, 1998
Purpose: This property is used in conjunction with the "uid"
and "sequence" property to identify a specific
instance of a recurring "vevent", "vtodo" or
"vjournal" calendar component. The property value
is the effective value of the "dtstart" property of
the recurrence instance.
Datatype: The default data type for this property is an ISO
extended date/time value without time zone
identifier ("dateTime"). The time format MAY be
any of valid date/time value. See [iCAL] for
specific interpretations of the various date/time
formats.
Description: The full range of calendar components specified by
a recurrence set is referenced by referring to just
the "uid" property value corresponding to the
calendar component. The "recurrence-id" property
allows the reference to an individual instance
within the recurrence set. If the value of the
"dtstart" property only has a date part, then the
value of recurid MUST be the calendar date for the
recurrence instance. The date/time value is set to
the time when the original recurrence instance
would occur -- meaning that if the intent is to
change a Friday meeting to Thursday, the date/time
is still set to the original Friday meeting.
The "recurid" property is used in conjunction with
the "uid" and "SEQUENCE" property to identify a
particular instance of a recurring event, to-do or
journal. For a given pair of "uid" and "SEQUENCE"
property values, the "recurid" value for a
recurrence instance is fixed.
Definition: <!ELEMENT recurid(#PCDATA)>
Example: <recurid>1997-09-09</recurid>
6.31. relatedto
Name: relatedto
Purpose: The property is used to represent a relationship or
reference between one calendar component and
another.
Description: The property value consists of the persistent,
globally unique identifier of another calendar
component. This value would be represented in a
calendar component by the "uid" property. By
default, the property value points to another
calendar component that has a PARENT relationship
to the referencing object. The "RELTYPE" property
parameter is used to either explicitly state the
Lippert/Reddy/Royer 34 Expires April 1999
Internet-Draft iCAL in XML November 18, 1998
default PARENT relationship type to the referenced
calendar component or to override the default
PARENT relationship type and specify either a CHILD
or SIBLING relationship.
Definition: <!ELEMENT relatedto(#PCDATA)>
<!ATTLIST relatedto
reltype (parent | child |sibling)>
Example: <relatedto "
reltype= child">[LL2] 19960401-080045-
4000F192713-0052@host1.com</relatedto>
6.32. requeststatus
Name: requeststatus
Purpose: This property defines the status code returned for
a scheduling request.
Description: This property is used to return status code
information related to the processing of an
associated iCalendar object. The data type for this
property is TEXT. The value consists of a short
return status, a longer return status
description, and optionally the offending data. The
components of the value are separated by the
SEMICOLON character (ASCII decimal 59). The short
return status is a PERIOD character (ASCII decimal
46) separated 3-tuple of integers. For example,
"3.1.1". The successive levels of integers provide
for a successive level of status code granularity.
Definition: <!ELEMENT requeststatus(statuscode, summary+,
statusdata)>
6.32.1. Example of simple requeststatus
<requeststatus>
<statuscode>2.0</statuscode>
<summary>Success</summary>
</requeststatus>
6.32.2. Example requeststatus with data
<requeststatus>
<statuscode>3.7</statuscode>
<summary>Invalid calendar user</summary>
<statusdata>attendee:jsmith@host.com</statusdata>
</requeststatus>
Lippert/Reddy/Royer 35 Expires April 1999
Internet-Draft iCAL in XML November 18, 1998
6.32.3.
Example requeststatus with multiple descriptions
<requeststatus>
<statuscode>4.1</statuscode>
<summary xml:lang="en">
Event conflict. Date/time is busy</summary>
<summary xml:lang="fr">
Evenement de conflit. La date ou l'heure est occupe.
</summary>
</requeststatus>
6.33. resources
Name: resources
Purpose: This property defines the equipment or resources
anticipated for an activity specified by a calendar
entity.
Description: The property value is an arbitrary text. More than
the resource MAY be specified as a list of
resources separated by the COMMA character (ASCII
decimal 44). This element may include the xml:lang
attribute.
Definition: <!ELEMENT comment(#PCDATA)>
Example:
<resources xml:lang="en">
<li>Easel</li>
<li>VCR</li>
</resources>
6.34. rrule
Name: rrule
Purpose: This property defines a rule or repeating pattern
for a recurring events, to-dos, or time zone
definitions.
Description: The recurring rule, if specified, is used in
computing the recurrence set. The recurrence set is
the complete set of recurrence instances for a
calendar component.
The attributes used to specify the recurrance are
defined by [iCAL].
Example: <rrule freq=YEARLY byday=-1SU bymonth=10/>
Lippert/Reddy/Royer 36 Expires April 1999
Internet-Draft iCAL in XML November 18, 1998
6.34.1. Alternative rrule format
The WG should consider an alternative format that uses XML
elements. This would be the most flexible for future enhancements
to the protocol, although it is most bulky. (similarly for
exrule).
<rrule>
<freq>YEARLY</freq>
<byday>-1SU</byday>
<bymonth>10</bymonth>
</rrule>
6.35. sequence
Name: sequence
Purpose: This property defines the revision sequence of the
calendar component used in a request.
Datatype: Default data type is an "int"
Description: This property is needed to properly handle the
receipt and processing of a sequence of calendar
components that have been delivered out of order.
Such is the case for store-and-forward based
transports. The first request is created with a
sequence number of "0" (ASCII decimal 48). It is
incremented each time the organizer or OWNER issues
a revision to the request.
6.36. sentby
Name: sentby
Purpose: This contains information on the delegate, the user
who sent an item on behalf of the organizer.
Definition: <!ELEMENT sentby (cn?, direntry?)
Example:
<sentby>
<cn href=jdoe@host1.com>John Doe</cn>
</sentby>
6.37. status
Name: status
Purpose: This property defines the overall status or
confirmation for the calendar component.
Description: In a group scheduled calendar
component, the property is used by the "Organizer"
Lippert/Reddy/Royer 37 Expires April 1999
Internet-Draft iCAL in XML November 18, 1998
to provide a confirmation of the event to the
"Attendees". For example in a "vevent" calendar
component, the "Organizer" can indicate that a
meeting is tentative, confirmed or cancelled. In a
"vtodo" calendar component, the "Organizer" can
indicate that an action item needs action, is
completed, is in process or being worked on, or has
been cancelled. In a "vjournal" calendar component,
the "Organizer" can indicate that a journal entry
is draft, final or has been cancelled or removed.
Datatype: String
Value: As defined by [iCAL]
Definition: <!ELEMENT status (#PCDATA)>
Example: <status>TENTATIVE</status>
6.38. statuscode
Name: statuscode
Purpose: Provide a status code for the "requeststatus"
element.
Definition: <!ELEMENT statuscode (#PCDATA)>
6.39. summary
Name: summary
Purpose: This property defines a short summary or subject
for the calendar component.
Description: This property is used to capture a short, one line
summary about the activity or journal entry.
This element may include the xml:lang or href
attributes.
Example:
<summary xml:lang="en"
href="http://host.com/mystuff/summary.html">
Status meeting
</summary>
6.40. telephoneNumber
Name: telephoneNumber
Purpose: Identify the telephone number of a contact or
organizer.
Lippert/Reddy/Royer 38 Expires April 1999
Internet-Draft iCAL in XML November 18, 1998
Value: Telephone number
6.41. trigger
Name: trigger
Purpose: This property specifies when an alarm will trigger.
Description: Within the "VALARM" calendar component, this
property defines when the alarm will trigger. The
trigger can contain a duration, specifying a
relative time for the trigger of the alarm. The
default duration is relative to the start of an
event or to-do that the alarm is associated with.
The duration can be explicitly set to trigger from
either the end or the start of the associated event
or to-do with the "from" element.
A value of START for the "from" element will set
the alarm to trigger off the start of the
associated event or to-do. A value of END will set
the alarm to trigger off the end of the associated
event or to-do.
Definition: <!ELEMENT trigger( (from?, duration) | (dtstart) )>
6.41.1.
Example trigger from start
<trigger>
<from>start</from>
<duration>PT5M</duration>
</trigger>
Equivalent format since "start" is assumed:
<trigger><duration>PT5M</duration></trigger>
6.41.2.
Example trigger at defined time
<trigger>
<dtstart DCD:dt="dateTime.tz">1998-09-09T18:30</dtstart>
</trigger>
6.42. tzurl
Name: tzurl
Purpose: Provide a URL to more information about a time zone
Datatype: URI
Definition: <!ELEMENT tzurl(#PCDATA)>
Lippert/Reddy/Royer 39 Expires April 1999
Internet-Draft iCAL in XML November 18, 1998
6.43. uid
Name: uid
Purpose: This property defines the persistent, globally
unique identifier for the calendar component.
The uid itself MUST be an internet-wide globally
unique identifier for the calendar component. The
generator of the identifier MUST guarantee that the
identifier is unique. There are several algorithms
that can be used to accomplish this. The identifier
MAY be the identical syntax to the [RFC 822] addr-
spec.
Definition: <!ELEMENT uid(#PCDATA)>
7. SECURITY CONSIDERATIONS
There are existing ways to encrypt XML bodies, so using XML as a
format for iCAL components should improve security.
8. REFERENCES
[2119] S. Bradner, "Key words for use in RFCs to indicate
requirement levels," RFC 2119, Internet Engineering Task Force,
Mar. 1997.
[DCD] T. Bray, "Document Content Description for XML", Submission
to the World Wide Web Consortium 31-July-1998,
http://www.w3.org/TR/NOTE-dcd
[XML] T. Bray, J Paoli and C. Sperberg-McQueen: "Extensible
Markup Language (XML) 1.0", W3C Recommendation 10-February-1998,
http://www.w3.org/TR/1998/REC-xml-19980210.
[iCAL] F. Dawson and D. Stenerson, "Internet Calendaring and
Scheduling Core Object Specification (iCalendar)", Internet-
Draft, http://www.imc.org/draft-ietf-calsch-ical-main.
[XMLDATA] A. Layman, E. Jung, E. Maler, H. Thompson, J. Paoli, J.
Tigue, N. Mikula and S. De Rose: "XML-DATA", W3C Note 05 Jan
1998, http://www.w3.org/TR/1998/NOTE-XML-data-0105/.
[XMLNS] T. Bray, D. Hollander, A. Layman, "Namespaces in XML",
WD-xml-names-19980916, http://www.w3.org/TR/WD-xml-names.
9. Authors' Addresses
Lisa Lippert
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Lippert/Reddy/Royer 40 Expires April 1999
Internet-Draft iCAL in XML November 18, 1998
Phone: +1(425) 935 2472
EMail: lisadu@microsoft.com
Surendra Reddy
Oracle Corporation
500 Oracle Parkway
M/S 6op3
Redwoodshores, CA 94065
Phone: +1(650) 506 5441
Fax: +1(650) 654 6205
Email: skreddy@us.oracle.com
Doug Royer
Sun Microsystems
901 San Antonio Road, MS MPK17-105
Palo Alto, CA
94303-4900
Phone: +1(650) 786 7599
Fax: +1(650) 786 7994
EMail: doug.royer@sun.com
10. Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights
Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared,
copied, published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to
the Internet Society or other Internet organizations, except as
needed for the purpose of developing Internet standards in which
case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate
it into languages other than English.
The limited permissions granted above are perpetual and will not
be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS 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
Lippert/Reddy/Royer 41 Expires April 1999
Internet-Draft iCAL in XML November 18, 1998
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.
Lippert/Reddy/Royer 42 Expires April 1999
Page: 13
[LL1]How do I show a new line in a string? - email sent
to charles frankston to find out
Page:
[LL2]Is there a better way to do this one_
35
| PAFTECH AB 2003-2026 | 2026-04-24 09:00:30 |