]> Apple Inc.

1 Infinite Loop Cupertino CA 95014 USA cyrus@daboo.name http://www.apple.com/

Rensselaer Polytechnic Institute

110 8th Street Troy NY 12180 USA douglm@rpi.edu http://www.rpi.edu/

Microsoft Corporation

One Microsoft Way Redmond WA 98052 USA steven.lees@microsoft.com http://www.microsoft.com/

Applications This specification defines "xCal", an XML format for iCalendar data.

The iCalendar data format is a widely deployed interchange format for calendaring and scheduling data. While many applications and services consume and generate calendar data, iCalendar is a specialized format that requires its own parser/generator. In contrast, XML-based formats are widely used for interoperability between applications, and the many tools that generate, parse, and manipulate XML make it easier to work with than iCalendar. The purpose of this specification is to define "xCal", an XML format for iCalendar data. xCal is defined as a straightforward mapping into XML from iCalendar, so that iCalendar data can be converted to XML, and then back to iCalendar, without losing any semantic meaning in the data. Anyone creating xCal calendar data according to this specification will know that their data can be converted to a valid iCalendar representation as well. Key design considerations are: Round-tripping (converting an iCalendar instance to xCal and back) will give the same semantic result as the starting point. i.e., all components, properties and property parameters are guaranteed to be preserved, with the exception of those which have default values. Preserve the semantics of the iCalendar data. While a simple consumer can easily browse the calendar data in xCal, a full understanding of iCalendar is still required in order to modify and/or fully comprehend the calendar data. Ability to handle many extensions to the underlying iCalendar specification without requiring an update to this document.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in . When XML element types in the namespace "urn:ietf:params:xml:ns:icalendar-2.0" are referenced in this document outside of the context of an XML fragment, the string "IC:" will be prefixed to the element types. Some examples in this document contain "partial" XML documents used for illustrative purposes. In these examples, three periods "..." are used to indicate a portion of the document that has been removed for compactness.

This section describes how iCalendar data is converted to xCal using a simple mapping between the iCalendar data model and XML elements.

iCalendar uses a line folding mechanism to limit lines of data to a maximum line length (typically 72 characters) to ensure maximum likelihood of preserving data integrity as it is transported via various means (e.g., email) - see Section 3.1 of . Prior to converting iCalendar data into xCal all folded lines MUST be unfolded. iCalendar data uses an "escape" character sequence for text values and property parameter values. When such text elements are converted into xCal the escaping MUST be removed. iCalendar uses a base64 encoding for binary data. However, it does not restrict the encoding from being applied to non-binary value types. So the following rules MUST be applied when processing a property with the "ENCODING" property parameter set to "BASE64": If the property value type is "BINARY", the base64 encoding MUST be preserved. If the value type is not "BINARY", the "ENCODING" property parameter MUST be removed, and the value MUST be base64 decoded. When base64 encoding and decoding is used, it MUST conform to Section 4 of , which is the base64 method used in . One key difference in the formatting of values used in iCalendar and xCal is that in xCal the specification uses date/time and utc-offset values aligned with the syntax of to aid with XML processing.

At the top level of the iCalendar object model is an "iCalendar stream". This object encompasses multiple "iCalendar objects". In xCal, the entire stream is contained in the root IC:icalendar XML element. An iCalendar stream can contain one or more iCalendar objects. Each iCalendar object, delimited by "BEGIN:VCALENDAR" and "END:VCALENDAR", is enclosed by the IC:vcalendar XML element. Example:

... ]]>

iCalendar objects are comprised of a set of "components", "properties", "parameters" and "values". A "component" can contain other "components" or "properties". A "property" has a value and a set of zero or more "parameters". In xCal, component elements, for example IC:vevent, IC:vtodo, are contained within an IC:components XML element. Within the component element, another IC:components element could appear (representing components nested within components) or the IC:properties XML element could appear. IC:properties is used to encapsulate iCalendar properties. Each iCalendar property will be mapped to its own XML element as described below. Within each of these elements there is zero or one IC:parameters XML element used to encapsulate any iCalendar property parameters. Additionally there will be one or more XML elements representing the value of the iCalendar property. Example:

... ... ]]>

Item XML element XML Definition iCalendar Stream IC:icalendar # 3.4 VCALENDAR IC:vcalendar # 3.6

Each calendar component in the "VCALENDAR" object, delimited by "BEGIN" and "END", will be converted to an enclosing XML element with the same name, but in lowercase. As an example, the table below shows iCalendar to xCal mappings for current iCalendar components. Any new iCalendar components added in the future will be converted in the same way. Component XML element XML Definition VEVENT IC:vevent # 3.6.1 VTODO IC:vtodo # 3.6.2 VJOURNAL IC:vjournal # 3.6.3 VFREEBUSY IC:vfreebusy # 3.6.4 VTIMEZONE IC:vtimezone # 3.6.5 STANDARD IC:standard # 3.6.5 DAYLIGHT IC:daylight # 3.6.5 VALARM IC:valarm # 3.6.6

iCalendar properties , whether they apply to the "VCALENDAR" object or to a component, are handled in a consistent way in the xCal format. iCalendar properties are enclosed in the XML element IC:properties. Each individual iCalendar property is represented in xCal by an element of the same name as the iCalendar property, but in lowercase. For example, the "CALSCALE" property is represented in xCal by the IC:calscale element. Example:

... ... ... ... ]]>

Each property can contain an IC:parameters XML element encapsulating any iCalendar property parameters associated with the iCalendar property. Each property will contain one or more "value" XML elements as described below representing the value of the iCalendar property. As an example, the table below shows iCalendar to xCal mappings for current iCalendar properties. Any new iCalendar properties added in the future will be converted in the same way. Property XML element XML Definition CALSCALE IC:calscale # 3.7.1 METHOD IC:method # 3.7.2 PRODID IC:prodid # 3.7.3 VERSION IC:version # 3.7.4 ATTACH IC:attach # 3.8.1.1 CATEGORIES IC:categories # 3.8.1.2 CLASS IC:class # 3.8.1.3 COMMENT IC:comment # 3.8.1.4 DESCRIPTION IC:description # 3.8.1.5 GEO IC:geo # 3.8.1.6 LOCATION IC:location # 3.8.1.7 PERCENT-COMPLETE IC:percent-complete # 3.8.1.8 PRIORITY IC:priority # 3.8.1.9 RESOURCES IC:resources # 3.8.1.10 STATUS IC:status # 3.8.1.11 SUMMARY IC:summary # 3.8.1.12 COMPLETED IC:completed # 3.8.2.1 DTEND IC:dtend # 3.8.2.2 DUE IC:due # 3.8.2.3 DTSTART IC:dtstart # 3.8.2.4 DURATION IC:duration # 3.8.2.5 FREEBUSY IC:freebusy # 3.8.2.6 TRANSP IC:transp # 3.8.2.7 TZID IC:tzid # 3.8.3.1 TZNAME IC:tzname # 3.8.3.2 TZOFFSETFROM IC:tzoffsetfrom # 3.8.3.3 TZOFFSETTO IC:tzoffsetto # 3.8.3.4 TZURL IC:tzurl # 3.8.3.5 ATTENDEE IC:attendee # 3.8.4.1 CONTACT IC:contact # 3.8.4.2 ORGANIZER IC:organizer # 3.8.4.3 RECURRENCE-ID IC:recurrence-id # 3.8.4.4 RELATED-TO IC:related-to # 3.8.4.5 URL IC:url # 3.8.4.6 UID IC:uid # 3.8.4.7 EXDATE IC:exdate # 3.8.5.1 RDATE IC:rdate # 3.8.5.2 RRULE IC:rrule # 3.8.5.3 ACTION IC:action # 3.8.6.1 REPEAT IC:repeat # 3.8.6.2 TRIGGER IC:trigger # 3.8.6.3 CREATED IC:created # 3.8.7.1 DTSTAMP IC:dtstamp # 3.8.7.2 LAST-MODIFIED IC:last-modified # 3.8.7.3 SEQUENCE IC:sequence # 3.8.7.4 REQUEST-STATUS IC:request-status # 3.8.8.3

This section describes some properties that have special handling when converting to xCal.

The following iCalendar properties can have values that consist of a list of "standard" iCalendar values separated by a specific delimiter. In xCal these properties are represented by an XML element that contains multiple "value" elements (). Property XML element XML Definition CATEGORIES IC:categories # 3.8.1.2 RESOURCES IC:resources # 3.8.1.10 FREEBUSY IC:freebusy # 3.8.2.6 EXDATE IC:exdate # 3.8.5.1 RDATE IC:rdate # 3.8.5.2

In iCalendar, the "GEO" property value is defined as a semi-colon separated list of two "FLOAT" values, the first representing latitude and the second longitude. In xCal, the value for the IC:geo element is represented by two XML elements. These are an IC:latitude element and an IC:longitude element, each of which contain float values. See # 3.8.1.6. Example:

... 37.386013 -122.082932 ... ]]>

In iCalendar, the "REQUEST-STATUS" property value is defined as a semi-colon separated list of two or three "TEXT" values. The first represents a code, the second a description, and the third any additional data. In xCal, the value for the IC:request-status element is represented by two or three XML elements. These are an IC:code element, an IC:description element, and an IC:data element, each of which contain the corresponding "TEXT" values. If there is no additional data in the iCalendar value, the IC:data element (which would be empty) SHOULD NOT be present. See # 3.8.8.3. Example:

... 2.0 Success ... ]]>

iCalendar property parameters are enclosed in the XML element IC:parameters which occurs in each property XML element. If there are no iCalendar property parameters, the IC:parameters element (which would be empty) SHOULD NOT be present. Each individual iCalendar property parameter is represented in xCal by an element of the same name as the iCalendar property parameter, but in lowercase. For example, the "PARTSTAT" property parameter is represented in xCal by the IC:partstat element. Example:

... ... NEEDS-ACTION ... ... ]]>

Each XML parameter element contains one or more child XML elements representing iCalendar value types. As an example, the table below shows iCalendar to xCal mappings for current iCalendar parameters. Any new iCalendar parameters added in the future will be converted in the same way. Parameter XML element XML Definition ALTREP IC:altrep # 3.2.1 CN IC:cn # 3.2.2 CUTYPE IC:cutype # 3.2.3 DELEGATED-FROM IC:delegated-from # 3.2.4 DELEGATED-TO IC:delegated-to # 3.2.5 DIR IC:dir # 3.2.6 ENCODING IC:encoding # 3.2.7 FMTTYPE IC:fmttype # 3.2.8 FBTYPE IC:fbtype # 3.2.9 LANGUAGE IC:language # 3.2.10 MEMBER IC:member # 3.2.11 PARTSTAT IC:partstat # 3.2.12 RANGE IC:range # 3.2.13 RELATED IC:related # 3.2.14 RELTYPE IC:reltype # 3.2.15 ROLE IC:role # 3.2.16 RSVP IC:rsvp # 3.2.17 SENT-BY IC:sent-by # 3.2.18 TZID IC:tzid # 3.2.19

iCalendar defines a "VALUE" property parameter (Section 3.2.20 of ). This property parameter is not mapped to an xCal XML element. Instead, the value type is handled by having different XML elements for each value, and these appear inside of IC:property elements. Thus, when converting from iCalendar to xCal, any "VALUE" property parameters are skipped. When converting from xCal into iCalendar, the appropriate "VALUE" property parameter MUST be included in the iCalendar property if the value type is not the default value type for that property.

In the typical case, iCalendar value types are mapped into XML elements with a matching name in all lowercase. In the case of the value for a recurrence rule (see below), iCalendar defines "structured" values and these are mapped into separate child elements for each value element.

iCalendar "BINARY" property values are represented by the IC:binary XML element. The content of the element is base64 encoded data, conforming to Section 4 of , which is the base64 method used in . Whitespace MAY be inserted into the data at any point to "wrap" the data to reasonable line lengths. When converting back to iCalendar the whitespace MUST first be removed. # 3.3.1

SGVsbG8gV29ybGQh ]]>

iCalendar "BOOLEAN" property values are represented by the IC:boolean XML element. The content of the element is a boolean value. # 3.3.2

true ]]>

iCalendar "CAL-ADDRESS" property values are represented by the IC:cal-address XML element. The content of the element is a URI. # 3.3.3

mailto:cyrus@example.com ]]>

iCalendar "DATE" property values are represented by the IC:date XML element. The content of the element is the same date value specified by , with the exception that the date components are separated by "-" characters, for consistency with . # 3.3.4

2011-05-17 ]]>

iCalendar "DATE-TIME" property values are represented by the IC:date-time XML element. The content of the element is the same date-time value specified by , with the exception that the date components are separated by "-" characters, and the time components are separated by ":" characters, for consistency with . Note that while [W3C.REC-xmlschema-2-20041028] allows for a UTC offset to be included in date/time values, xCal does not use that, and instead follows the iCalendar behavior of using timezone definitions via the "TZID" property parameter. # 3.3.5

2011-05-17T12:00:00 ]]>

iCalendar "DURATION" property values are represented by the IC:duration XML element. The content of the element is the same duration value specified by . # 3.3.6

P1D ]]>

iCalendar "FLOAT" property values are represented by the IC:float XML element. The content of the element is a text representation of a floating point number. # 3.3.7

0.5 ]]>

iCalendar "INTEGER" property values are represented by the IC:integer XML element. The content of the element is a text representation of an integer number. # 3.3.8

50 -100 ]]>

iCalendar "PERIOD" property values are represented by the IC:period XML element. The content of the element is child elements representing the start, end or duration components of the period. # 3.3.9

2011-05-17T12:00:00 P1H ]]>

iCalendar "RECUR" property values are represented by the IC:recur XML element. The content of the element is child elements representing the various components of a recurrence rule. # 3.3.10

YEARLY 5 -1SU 10 ]]>

iCalendar "TEXT" property values are represented by the IC:text XML element. The content of the element is simple text. # 3.3.11

Hello World! ]]>

iCalendar "TIME" property values are represented by the IC:time XML element. The content of the element is the same time value specified by , with the exception that the time components are separated by ":" characters, for consistency with . Note that while [W3C.REC-xmlschema-2-20041028] allows for a UTC offset to be included in date/time values, xCal does not use that, and instead follows the iCalendar behavior of using timezone definitions via the "TZID" property parameter. # 3.3.12

12:00:00 ]]>

iCalendar "URI" property values are represented by the IC:uri XML element. The content of the element is a URI. # 3.3.13

http://calendar.example.com ]]>

iCalendar "UTC-OFFSET" property values are represented by the IC:utc-offset XML element. The content of the element is the same UTC offset value specified by , with the exception that the hour and minute components are separated by a ":" character, for consistency with . # 3.3.14

-05:00 ]]>

iCalendar extension properties and property parameters (those with an "X-" prefix in their name) are handled in the same way as other properties and property parameters: the property or property parameter is represented by an XML element with the same name, but in lowercase. e.g., the "X-FOO" property in iCalendar turns into the IC:x-foo element in xCal. But see for how to deal with default values for unrecognized extension properties or property parameters.

When converting component, property and property parameter values, the names SHOULD be converted to uppercase. Although iCalendar names are case insensitive, common practice is to keep them all uppercase following the actual definitions in . Backslash escaping and line folding MUST be applied to the resulting iCalendar data as required by . Non-binary value types MUST NOT be base64 encoded.

XML extensions are converted back to iCalendar in one of two ways, depending on whether the extensions are in the iCalendar XML namespace, or in an external namespace. Extensions that are part of the iCalendar XML namespace MUST have element names that begin with "x-", and will be converted back to the equivalent extension property in iCalendar. For example, the "x-foo" element will convert to the "X-FOO" iCalendar property. Extensions that are in a namespace other than the iCalendar XML namespace SHOULD be preserved in the iCalendar representation using the "XML" iCalendar property described in .

This section describes an extension property for iCalendar, as covered in section 8.2.3 of . Property name: XML Purpose: To embed XML-encoded calendar data in the iCalendar format. Value type: The default value type is "TEXT". The value type can also be set to "BINARY" to indicate base64 encoded content. Property parameters: IANA, non-standard, inline encoding, and value data type property parameters can be specified on this property. Conformance: The property can appear on any iCalendar component. Description: The value of this property is an XML element. The "XML" property MUST NOT be used to contain properties that are already defined in iCalendar, or properties that use the "X-" iCalendar extension property syntax. Since all elements in the urn:ietf:params:xml:ns:icalendar-2.0 namespace convert to a well-defined iCalendar object, the elements in this property MUST NOT be in the urn:ietf:params:xml:ns:icalendar-2.0 namespace. The XML element which is the value of this property MUST have an XML namespace declaration. Note that the source XML may contain characters not allowed in iCalendar such as control characters. If this is the case, then the XML data MUST be base64 encoded. As required by , the "ENCODING" property parameter MUST be present and set to "BASE64", and the "VALUE" property parameter MUST be present and set to "BINARY". There can be more than one "XML" property present for a given iCalendar object. The ordering of "XML" properties is not preserved in the conversion between xCal and iCalendar. Format definition: This property is defined by the following notation:

Example: The following is an example of an iCalendar event with a location embedded in KML markup inside the "XML" property.

... END:VEVENT END:VCALENDAR ]]>

In iCalendar, properties have a default value type specified by their definition, e.g. "SUMMARY"'s value type is "TEXT" and "DURATION"'s is "DURATION". When a property uses its default value type, the "VALUE" property parameter does not need to be specified on the property. When new properties are defined or "X-" properties used, an iCalendar<->xCal converter might not recognize them, and know what the appropriate default value types are, yet they need to be able to preserve the values. A similar issue arises for unrecognized property parameters. As a result, the following rules are applied when dealing with unrecognized properties and property parameters: When converting iCalendar into xCal: Any property that does not include a "VALUE" property parameter and whose default value type is not known, MUST be converted using the value type XML element IC:unknown. The content of that element is the unprocessed value text. Any unrecognized property parameter MUST be converted using the value type XML element IC:unknown, with its content set to the property parameter value text, treated as if it were a "TEXT" value, or list of "TEXT" values. When converting xCal into iCalendar: Any IC:unknown property value XML elements are converted directly into iCalendar values. The containing property MUST NOT have a "VALUE" property parameter. Any IC:unknown parameter value XML elements are converted as if they were IC:text value type XML elements. Example: The following is an example of an unrecognized iCalendar property (that uses a "DATE-TIME" value as its default), and the equivalent xCal representation of that property.

iCalendar:

xCal: 20110512T120000Z ]]>

Example: The following is an example of an unrecognized iCalendar property parameter (that uses a "DURATION" value as its default) specified on a recognized iCalendar property, and the equivalent xCal representation of that property and property parameter.

iCalendar:

xCal: PT30M 2011-05-12T13:00:00Z ]]>

For security considerations specific to calendar data, see Section 7 of . Since this specification is a mapping from iCalendar, no new security concerns are introduced related to calendar data. The use of XML as a format does have security risks. Section 7 of discusses these risks. See also the security discussion for the application/xml type in .

This document defines a new URN to identify a new XML namespace for iCalendar data. The URN conforms to a registry mechanism described in . This document defines a new media type. The registration is in . This document defines a new property for iCalendar. The registration is in .

Registration request for the iCalendar namespace: URI: urn:ietf:params:xml:ns:icalendar-2.0 Registrant Contact: See the "Authors' Addresses" section of this document. XML: None. Namespace URIs do not represent an XML specification.

This section defines the MIME media type for use with iCalendar in XML data. application calendar+xml none method, component and optinfo as defined for the text/calendar media type in ; charset as defined for application/xml in ; per , use of the charset property parameter with the value "utf-8" is "STRONGLY RECOMMENDED" Same as encoding considerations of application/xml as specified in See . This media type provides an alternative format for iCalendar data based on XML. This specification. Applications that currently make use of the text/calendar media type can use this as an alternative. None xcs None specified. calsify@ietf.org COMMON There are no restrictions on where this media type can be used. See the "Author's Address" section of this document. IETF

This document defines the following new iCalendar property to be added to the registry defined in Section 8.2.3 of : Property Status Reference XML Current RFCXXXX,

The authors would like to thank the following for their valuable contributions: Toby Considine, Bernard Desruisseaux, Keith Moore, Filip Navara, Simon Perreault, Arnaud Quillaud, Peter Saint-Andre, and Dave Thewlis. This specification originated from the work of the XML technical committee of the Calendaring and Scheduling Consortium.

&rfc2119; &rfc3023; &rfc3470; &rfc3688; &rfc4648; &rfc5545; &W3C.REC-xmlschema-2-20041028;

Below is a Relax NG schema for iCalendar in XML. The schema is non-normative and given for reference only. This schema uses the compact notation of Relax NG. The numeric section numbers given in the comments refer to section in . The ordering of elements follows the section ordering of . The Relax NG compact notation "?" operator is used to indicate an unordered list of items. However, that operator, as defined, allows "mixing" each element that it operates on at any depth within the other elements, rather than just allowing "mixing" of siblings only. As a result, the schema provided allows certain constructs that are not allowed in iCalendar. Given that there is no sibling-only unordered list operator in RelaxNG, this is the best representation that can be given. Patterns for date/time, duration and utc-offset values are given because those differ from the values used in iCalendar. More restrictive schema with patterns and numerical limits could be derived from the example schema here if more comprehensive schema validation is required.

This section contains two examples of iCalendar objects with their xCal representation.

GREGORIAN -//Example Inc.//Example Calendar//EN 2.0 2008-02-05T19:12:24Z 2008-10-06

Planning meeting

4088E990AD89CB3DBB484909 ]]>

-//Example Inc.//Example Client//EN 2.0 2004-01-10T03:28:45Z US/Eastern 2000-04-04T02:00:00 YEARLY 1SU 4 EDT -05:00 -04:00 2000-10-26T02:00:00 YEARLY -1SU 10 EST -04:00 -05:00 2006-02-06T00:11:21Z US/Eastern 2006-01-02T12:00:00 PT1H DAILY 5 US/Eastern 2006-01-02T15:00:00 PT2H

Event #2

We are having a meeting all this week at 12 pm for one hour, with an additional meeting on the first day 2 hours long. Please bring your own lunch for the 12 pm meetings. 00959BC664CA650E933C892C@example.com 2006-02-06T00:11:21Z US/Eastern 2006-01-04T14:00:00 PT1H US/Eastern 2006-01-04T12:00:00

Event #2 bis

00959BC664CA650E933C892C@example.com ]]>

Changes in -10: IESG: Added more XML schema references in value descriptions. IESG: Added reference to RFC4648 for base64 definition. IESG: Rephrased various uses of "optional". IESG: Clarified round-tripping design consideration. IESG: Use "As an example" rather than "non-normative" for tables. IESG: Added a few more examples. IESG: Added a note that UTC-offset is not used with time values. Changes in -09: LC: Changed namespace prefix to IC:. LC: Clarified what needs to happen with base64 encoding. LC: Changed "XML" to "xCal" in various places. LC: Schema now uses xsd types where appropriate. LC: GEO value fixed to be two floats. LC: Fix use of <text> within parameters. LC: Add IC:unknown value element to deal with unrecognized properties or parameters. LC: Added escaped/folded text example property. Removed <value> wrapper element for GEO and REQUEST-STATUS. Date/time, duration and utc-offset values defined in terms of patterns. Some now align with xsd patterns rather than iCalendar ones. Period schema value defined in terms of child elements. Added more examples. Changes in -08: Updated optional parameters section of media type registration (feedback from ietf-types) Corrected the schema for the trigger element Updated to ietf.org mailing list Updated definition of iCalendar XML property Changes in -07: Updated XML reference to latest version. Corrected dtstamp elements in samples. Removed empty informative references section. Changed media type registration file extension to "xcs" (feedback from ietf-types) Changed media type registration follow up email to ietf-calsify (feedback from ietf-types) Updated several parts of the specification to show how future extensions to iCalendar can be handled without changing this specification (feedback from ietf-types) Updated security concerns in section 5 (feedback from ietf-types) Updated encoding considerations in section 5 (feedback from ietf-types) Changes in -06: Removed the ordwk and weekday elements from the byday element in a recurrence rule. The byday element now takes a text value which is the same as the value used in . Added another example of an iCalendar object converted to xCal. Fixed the MIME type registration (another instance of xml+calendar corrected to calendar+xml). Changes in -05: Added description to XML extension discussing how to handle binary data in XML. Removed empty Appendix B. Changes in -04: Changed the proposed MIME type from xml+calendar to calendar+xml. Fixed several references to sections of RFC5545. Updated example in Appendix C. Corrected the definition and grammar for TIME and UTC-OFFSET properties. Changes in -03: Removed the LINK extension and related sections. The concept will be addressed in a separate specification. Various minor edits for clarity and consistency. Changes in -02: Added LINK extension to iCalendar and section discussing links in XML format. Adopted "xCal" as the short name for the specification. Changes in -01: Changed 2445bis references to RFC5545. Added a version number to the XML namespace for iCalendar. Changed the values for the date, date-time, period, and duration elements to exactly match the values specified in RFC5545. Previously these were broken out into separate elements for day, month, year, etc. Added specification for XML property in iCalendar.