Internet-draft Lisa Lippert, Microsoft 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: 1997-11-02T18:00 Interview with Robert Dusseault PG-13 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: 1997-11-02T18:00 1997-11-02T18:02 ... 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: 1997-11-02T18:00 Interview with Robert Dusseault PG-13 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: 2088-04-07T18:39:09-08:00 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: 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: Choose colours for packaging Choose colors for packaging 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: 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: 1998-09-09T18:30-08:00 1998-09-09 1998-09-09 1998-09-09 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
  • or "list" element (standard to HTML) is used as a list delimiter. The value of the data within the
  • element depends on the container outside the
  • element. For example, for the "categories" element the contents of each list element is a string.
  • XML project
  • Calendaring
  • The
  • 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. GermanyTyskland 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: 5.1.1. Example vcalendar -//hacksw/handcal//NONSGML v1.0//EN Une entrevue avec Robert Dusseault ... 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: 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 :-//hacksw/handcal//NONSGML 1.0//EN 19970901T130000Z-123401@host.com 1997-09-01T13:00 1997-09-03T16:30 1997-09-03T19:00 Annual Employee Review PRIVATE
  • BUSINESS
  • HUMAN RESOURCES
    • (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: 19970901T130000Z-123402@host.com 1997-09-01T13:00 1997-04-01T16:30 1997-04-02T010:00 Laurel is in sensitivity awareness class. PUBLIC
  • BUSINESS
  • HUMAN RESOURCES
    •  transparent     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: 19970901T130000Z-123403@host.com 1997-09-01T13:00 Lippert/Reddy/Royer 11 Expires April 1999 Internet-Draft iCAL in XML November 18, 1998 1997-11-02 Our Blissful Anniversary CONFIDENTIAL
  • ANNIVERSARY
  • PERSONAL
  • SPECIAL OCCASION
    •      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: 5.3.1. Example: vtodo The following is an example of a "vtodo" calendar component: 19970901T130000Z-123404@host.com 1997-09-01T13:00-8:00 1997-04-15T13:30:00-8:00 1997-04-16T04:59:59-8:00 1996 Income Tax Preparation CONFIDENTIAL
  • BUSINESS
  • FAMILY
  • FINANCE
    •  1 NEEDS-ACTION     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: 5.4.1. Example: vjournal The following is an example of the "vjournal" calendar component: 19970901T130000Z-123405@host.com 1997-09-01T13:00 1997-03-17 Staff meeting minutes 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). 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: 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: MAILTO:jane_doe@host1.com MAILTO:john_public@host2.com 1997-10-15T05:00 1997-10-16T05:00 1997-09-01T08:30 0 19970901T0830000-uid1@host1.com 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 MAILTO:john_public@host2.com 1997:09:01T10:00 0 19970901T0830000-uid1@host1.com
  • 1997-10-15T05:00:00 PT8H30M
  • 1997-10-15T16:00:00 PT5H30M
  • 1997-10-15T22:0:00 PT6H30M
    •      MAILTO:jsmith@host.com 1998-03-13T14:17:11 1998-04-10T14:17:11
  • 1998-03-14T23:30:00 1998-03-15T00:30:00
  • 1998-03-16T15:30:00 1998-03-16T16:30:00
  • 1998-03-18T03:00:00 1998-03-18T04:00:00
    •      5.6.freebusyreq element Name: freebusyreq Purpose: Within a vfreebusy element, provide a request for free/busy time. Definition: 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: 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: 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: 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. America-New_York 1987-01-01T00:00:00 1997-10-26T02:00:00 1997-10-26T02:00:00 -04:00 -05:00 EST 1997-10-26T02:00:00 1997-04-06T02:00:00 -05:00 -04:00 EDT 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. America-New_York 1987-01-01T00:00:00 http://zones.stdsrus.net/tz/America-New_York 1967-10-29T02:00:00 -04:00 -05:00 EST 1987-04-05T02:00:00 -05:00 -04:00 EDT 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). America-New_York 1987-01-01T00:00:00Z 1967-10-29T02:00:00 -04:00 -05:00 EST 1987-04-05T02:00:00 -05:00 -04:00 EDT 5.10. standard Name: standard Purpose: To contain information for the standard (not daylight-savings) timezone offset rules. Definition: 5.11. daylight Name: daylight Purpose: To contain information about the daylight-savings timezone offset rules. Definition: 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: 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: AUDIO 1997-03-17T13:30:00 4 PT15M ftp://host.com/sounds/bell-01.wav 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: DISPLAY Breakfast meeting with executive team PT30M 2 PT15M 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. EMAIL mailto:john_doe@host.com P2D *** REMINDER: SEND AGENDA FOR WEEKLY STAFF MEETING *** Lippert/Reddy/Royer 20 Expires April 1999 Internet-Draft iCAL in XML November 18, 1998 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. http://host.com/templates/agenda.doc 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. PROCEDURE 1998-01-01T05:00:00 23 PT1H ftp://host.com/procs/felizano.exe 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: ftp://host.com/pub/sounds/bell-01.wav ftp://host.com/pub/foo.doc 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: A193CB8872F9882 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: 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: MAILTO:johnp@host2.com 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 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
  • element. Definition: Example: mon projet 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: Lippert/Reddy/Royer 23 Expires April 1999 Internet-Draft iCAL in XML November 18, 1998 Example: PUBLIC 6.7.cn Name: cn Purpose: To display the "common name" of a contact, organizer or delegate (in "sentby"). Definition: 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
  • 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 We're looking forward to this event. 6.8.2. Example of multiple comments
  • http://host.com/mystuff/comment.wav
  • We're looking forward to this event
    • 6.8.3. Example comment with alternate location We're looking forward to this event. 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: 1997-03- 17T13:30:00 Lippert/Reddy/Royer 24 Expires April 1999 Internet-Draft iCAL in XML November 18, 1998 1997-03-17 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
  • element. Datatype: Default datatype is a string. Definition: 6.10.1. Simple contact example Lisa Lippert 6.10.2. Contact list example
  • Example: 1997-03-17T13:30:00 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
  • . Definition: 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: Examples: Status Meeting 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: Example: ldap://host.com:6666/o=3DDC%20Associates,c=3DUS?? (cn=3DJohn%20Smith 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: Example: 1997-03-T13:30 1997-03-T13:30 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: 1997-03-17T13:30 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: Example: 1997-03-17T13:30 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: Example: 1997-03-17T13:30:00 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: Example: P15DT5H0M20S 0000-00- 15T5:00:20 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:
  • 1997-03-17
  • 1997-03-24
    • 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: 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:
  • FREE 1997-03-08T16:00:00 PT3H
  • BUSY-UNAVAILABLE 1997-03-08T16:00:00 1997-03-08T17:00:00
    • 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: start 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 GermanyTyskland 6.25.2. Example location with alternate representations Conference Room - F123, Bldg. 002 http://xyzcorp.com/conf - rooms/f123.vcf 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: This element MUST have a url which is a calendar address. Example: Jane Smith ldap://host.com:6666/o=3DDC%20Associates,c=3DUS?? (cn=3DJane%20Smith John Doe 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: 50 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: Examples:
  • 1997-03-08
  • 1997-03-15
    •  1997-03-08 00-00-14 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: Example: 1997-09-09 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: Example: [LL2] 19960401-080045- 4000F192713-0052@host1.com 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: 6.32.1. Example of simple requeststatus 2.0 Success 6.32.2. Example requeststatus with data 3.7 Invalid calendar user attendee:jsmith@host.com Lippert/Reddy/Royer 35 Expires April 1999 Internet-Draft iCAL in XML November 18, 1998 6.32.3. Example requeststatus with multiple descriptions 4.1 Event conflict. Date/time is busy Evenement de conflit. La date ou l'heure est occupe. 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: Example:
  • Easel
  • VCR
    •  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: 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). YEARLY -1SU 10 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: John Doe 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: Example: TENTATIVE 6.38. statuscode Name: statuscode Purpose: Provide a status code for the "requeststatus" element. Definition: 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: Status meeting 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: 6.41.1. Example trigger from start start PT5M Equivalent format since "start" is assumed: PT5M 6.41.2. Example trigger at defined time 1998-09-09T18:30 6.42. tzurl Name: tzurl Purpose: Provide a URL to more information about a time zone Datatype: URI Definition: 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: 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