xCal: The XML Format for iCalendar
updated by
Extracted elements (30)
xCal deliberately does not use W3C XML Schema UTC offset syntax within date-time values, even though that syntax supports it. Instead it follows iCalendar's model of using time zone definitions via the TZID property parameter, preserving semantic equivalence with iCalendar's timezone handling model.
xCal is defined as a straightforward mapping from iCalendar to XML such that round-tripping (iCalendar → xCal → iCalendar) preserves all semantic meaning. All components, properties, and property parameters are guaranteed to be preserved, with the exception of those that have default values. This design allows xCal data to always be converted back to valid iCalendar.
iCalendar X- extension properties and parameters are handled identically to standard properties: they are lowercased and represented as XML elements. However, unrecognized extension properties with unknown default value types must use IC:unknown, which may result in loss of type information that cannot be restored on round-trip.
For the XML iCalendar property, if the XML source contains characters not allowed in TEXT values, the data MUST be base64 encoded, with ENCODING=BASE64 and VALUE=BINARY parameters both present and set accordingly.
If there are no iCalendar property parameters, the IC:parameters element SHOULD NOT be present (i.e., an empty IC:parameters element should be omitted). Each parameter is represented by a lowercase XML element containing value type child elements.
Prior to converting iCalendar data into xCal, all folded lines MUST be unfolded. iCalendar escape character sequences for text and parameter values MUST be removed when converting to xCal.
The iCalendar VALUE property parameter is not mapped to an xCal XML element; instead, value type is indicated by the XML element name used inside property elements. When converting xCal back to iCalendar, the appropriate VALUE property parameter MUST be included if the value type is not the default for that property.
When converting iCalendar to xCal, any property whose default value type is not known MUST be converted using the IC:unknown value element containing the unprocessed value text. Unrecognized property parameters also MUST use IC:unknown with the parameter value text.
When converting xCal to iCalendar, component/property/parameter names SHOULD be converted to uppercase to follow common iCalendar practice. BACKSLASH character encoding and line folding MUST be applied as required by RFC 5545. Non-binary value types MUST NOT be base64 encoded.
When converting xCal to iCalendar, IC:unknown property value elements are converted directly to iCalendar values and the containing property MUST NOT have a VALUE parameter. IC:unknown parameter value elements are treated as IC:text.
When processing a property with ENCODING=BASE64: if the value type is BINARY, the base64 encoding MUST be preserved; if the value type is not BINARY, the ENCODING parameter MUST be removed and the value MUST be base64 decoded. Base64 encoding and decoding MUST conform to Section 4 of RFC 4648.
XML extensions in the iCalendar namespace MUST have element names beginning with 'x-' and convert back to equivalent X- extension properties in iCalendar. Extensions in foreign namespaces SHOULD be preserved using the new XML iCalendar property; only immediate child elements of IC:properties are converted, others are ignored.
Each iCalendar component (VEVENT, VTODO, VJOURNAL, VFREEBUSY, VTIMEZONE, STANDARD, DAYLIGHT, VALARM) is mapped to an XML element with the same name in lowercase. Future iCalendar components are converted in the same way.
Each iCalendar property is represented by an XML element with the same name in lowercase, enclosed within IC:properties. Each property may contain an IC:parameters element and one or more value XML elements. All standard iCalendar properties (CALSCALE, DTSTART, RRULE, etc.) are mapped this way.
In xCal, component elements (e.g., IC:vevent, IC:vtodo) are contained within an IC:components XML element. Within a component, IC:components may appear for nested components, or IC:properties encapsulates iCalendar properties. Each property element contains zero or one IC:parameters element and one or more value elements.
Multi-valued iCalendar properties (CATEGORIES, RESOURCES, FREEBUSY, EXDATE, RDATE) are represented in xCal by an XML element containing multiple value child elements rather than a single delimited string.
The GEO property, which in iCalendar is a semicolon-separated pair of FLOAT values, is represented in xCal as an IC:geo element containing an IC:latitude and an IC:longitude child element, each holding a float value.
The IC:recur element maps the iCalendar RECUR value type using child elements for each rule part: IC:freq, IC:until or IC:count, IC:interval, IC:byday, IC:bymonth, IC:wkst, etc. Each rule part becomes its own typed XML element rather than a semicolon-delimited key=value string.
The new XML iCalendar property (value type TEXT or BINARY) embeds a single XML 1.0 element from a foreign namespace into iCalendar. The XML property MUST NOT contain elements already defined in iCalendar or in the urn:ietf:params:xml:ns:icalendar-2.0 namespace. The embedded XML element MUST have an XML namespace declaration.
The REQUEST-STATUS property, which in iCalendar is a semicolon-separated list of two or three TEXT values, is represented in xCal as IC:request-status containing IC:code, IC:description, and optionally IC:data child elements. The IC:data element SHOULD NOT be present if there is no additional data.
The XML namespace for xCal is 'urn:ietf:params:xml:ns:icalendar-2.0'. An iCalendar stream is represented by the root IC:icalendar element, and each iCalendar object (VCALENDAR) is enclosed by the IC:vcalendar element.
This document adds the 'XML' property to the iCalendar property registry defined in RFC 5545 Section 8.2.3, with status 'Current' and reference RFC 6321 Section 4.2.
This document registers the MIME media type 'application/calendar+xml' for iCalendar data in XML format. Optional parameters include method, component, optinfo (from text/calendar), and charset (strongly RECOMMENDED to be 'utf-8'). File extension is .xcs.
This document registers the XML namespace URI 'urn:ietf:params:xml:ns:icalendar-2.0' in the IETF XML registry per RFC 3688.
For calendar data security, RFC 5545 Section 7 applies and no new concerns are introduced by the xCal mapping. Using XML as a format introduces additional security risks discussed in RFC 3470 Section 7 (guidelines for XML in IETF protocols) and the application/xml security discussion in RFC 3023.
The IC:binary element contains base64-encoded binary data conforming to RFC 4648 Section 4. Whitespace MAY be inserted to wrap data to reasonable line lengths; whitespace MUST be removed before converting back to iCalendar.
The IC:date element encodes iCalendar DATE values with date components separated by '-' characters (e.g., '2011-05-17'), aligned with W3C XML Schema datatypes for consistency with XML processing tools.
The IC:date-time element encodes iCalendar DATE-TIME values with '-' separating date components and ':' separating time components (e.g., '2011-05-17T12:00:00'). Unlike W3C XML Schema, xCal does not use embedded UTC offsets; timezone information is conveyed via the TZID parameter.
The IC:period element contains a child IC:start element (date-time pattern) plus either an IC:end element (date-time) or an IC:duration element (duration pattern), representing the two forms of iCalendar PERIOD values.
The IC:utc-offset element encodes iCalendar UTC-OFFSET values with hour, minute, and second components separated by ':' (e.g., '-05:00'), aligning with W3C XML Schema syntax.