From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6321.txt | 3027 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 3027 insertions(+) create mode 100644 doc/rfc/rfc6321.txt (limited to 'doc/rfc/rfc6321.txt') diff --git a/doc/rfc/rfc6321.txt b/doc/rfc/rfc6321.txt new file mode 100644 index 0000000..c038c64 --- /dev/null +++ b/doc/rfc/rfc6321.txt @@ -0,0 +1,3027 @@ + + + + + + +Internet Engineering Task Force (IETF) C. Daboo +Request for Comments: 6321 Apple, Inc. +Category: Standards Track M. Douglass +ISSN: 2070-1721 RPI + S. Lees + Microsoft + August 2011 + + + xCal: The XML Format for iCalendar + +Abstract + + This specification defines "xCal", an XML format for iCalendar data. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6321. + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + + + + +Daboo, et al. Standards Track [Page 1] + +RFC 6321 xCal August 2011 + + +Table of Contents + + 1. Introduction ....................................................3 + 2. Conventions Used in This Document ...............................4 + 3. Converting from iCalendar to xCal ...............................4 + 3.1. Pre-Processing .............................................4 + 3.2. iCalendar Stream (RFC 5545, Section 3.4) ...................5 + 3.3. Components (RFC 5545, Section 3.6) .........................6 + 3.4. Properties (RFC 5545, Sections 3.7 and 3.8) ................6 + 3.4.1. Special Cases for Properties ........................8 + 3.4.1.1. Multi-Valued Properties ....................8 + 3.4.1.2. GEO Property ...............................9 + 3.4.1.3. REQUEST-STATUS Property ....................9 + 3.5. Parameters (RFC 5545, Section 3.2) ........................10 + 3.5.1. VALUE Parameter ....................................11 + 3.6. Values (RFC 5545, Section 3.3) ............................11 + 3.6.1. Binary (RFC 5545, Section 3.3.1) ...................12 + 3.6.2. Boolean (RFC 5545, Section 3.3.2) .................12 + 3.6.3. Calendar User Address (RFC 5545, Section 3.3.3) ....12 + 3.6.4. Date (RFC 5545, Section 3.3.4) .....................12 + 3.6.5. Date-Time (RFC 5545, Section 3.3.5) ................13 + 3.6.6. Duration (RFC 5545, Section 3.3.6) .................13 + 3.6.7. Float (RFC 5545, Section 3.3.7) ....................13 + 3.6.8. Integer (RFC 5545, Section 3.3.8) ..................14 + 3.6.9. Period of Time (RFC 5545, Section 3.3.9) ...........14 + 3.6.10. Recurrence Rule (RFC 5545, Section 3.3.10) ........14 + 3.6.11. Text (RFC 5545, Section 3.3.11) ...................15 + 3.6.12. Time (RFC 5545, Section 3.3.12) ...................15 + 3.6.13. URI (RFC 5545, Section 3.3.13) ....................15 + 3.6.14. UTC Offset (RFC 5545, Section 3.3.14) .............16 + 3.7. Extensions ................................................16 + 4. Converting from xCal into iCalendar ............................16 + 4.1. Converting XML Extensions into iCalendar ..................16 + 4.2. The XML Property for iCalendar ............................17 + 5. Handling Unrecognized Properties or Parameters .................18 + 6. Security Considerations ........................................19 + 7. IANA Considerations ............................................20 + 7.1. Namespace Registration ....................................20 + 7.2. Media Type ................................................20 + 7.3. iCalendar Property Registrations ..........................21 + 8. Acknowledgments ................................................22 + 9. References .....................................................22 + 9.1. Normative References ......................................22 + 9.2. Informative References ....................................22 + + + + + + + +Daboo, et al. Standards Track [Page 2] + +RFC 6321 xCal August 2011 + + + Appendix A. RELAX NG Schema .......................................23 + Appendix B. Examples ..............................................49 + B.1. Example 1 ..................................................49 + B.1.1. iCalendar Data .........................................49 + B.1.2. XML Data ...............................................49 + B.2. Example 2 ..................................................50 + B.2.1. iCalendar Data .........................................50 + B.2.2. XML Data ...............................................51 + +1. Introduction + + The iCalendar data format [RFC5545] 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. That + is, all components, properties, and property parameters are + guaranteed to be preserved, with the exception of those that have + default values. + + xCal preserves 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. + + xCal has the ability to handle many extensions to the underlying + iCalendar specification without requiring an update to this + document. + + + + + + + + +Daboo, et al. Standards Track [Page 3] + +RFC 6321 xCal August 2011 + + +2. Conventions Used in 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 [RFC2119]. + + 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. + +3. Converting from iCalendar to xCal + + This section describes how iCalendar data is converted to xCal using + a simple mapping between the iCalendar data model and XML elements. + +3.1. Pre-Processing + + 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 [RFC5545]. 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": + + o If the property value type is "BINARY", the base64 encoding MUST + be preserved. + + o 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 are used, they MUST conform to + Section 4 of [RFC4648], which is the base64 method used in [RFC5545]. + + + + +Daboo, et al. Standards Track [Page 4] + +RFC 6321 xCal August 2011 + + + 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 + [W3C.REC-xmlschema-2-20041028] to aid with XML processing. + +3.2. iCalendar Stream (RFC 5545, Section 3.4) + + 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 and 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. + + + + + + + + + +Daboo, et al. Standards Track [Page 5] + +RFC 6321 xCal August 2011 + + + Example: + + + + + + ... + + + ... + + + + + +------------------+--------------+------------------+ + | Item | XML element | XML Definition | + +------------------+--------------+------------------+ + | iCalendar Stream | IC:icalendar | Appendix A # 3.4 | + | VCALENDAR | IC:vcalendar | Appendix A # 3.6 | + +------------------+--------------+------------------+ + +3.3. Components (RFC 5545, Section 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 | Appendix A # 3.6.1 | + | VTODO | IC:vtodo | Appendix A # 3.6.2 | + | VJOURNAL | IC:vjournal | Appendix A # 3.6.3 | + | VFREEBUSY | IC:vfreebusy | Appendix A # 3.6.4 | + | VTIMEZONE | IC:vtimezone | Appendix A # 3.6.5 | + | STANDARD | IC:standard | Appendix A # 3.6.5 | + | DAYLIGHT | IC:daylight | Appendix A # 3.6.5 | + | VALARM | IC:valarm | Appendix A # 3.6.6 | + +-----------+--------------+--------------------+ + +3.4. Properties (RFC 5545, Sections 3.7 and 3.8) + + iCalendar properties, whether they apply to the "VCALENDAR" object or + to a component, are handled in a consistent way in the xCal format. + + + + +Daboo, et al. Standards Track [Page 6] + +RFC 6321 xCal August 2011 + + + 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 | Appendix A # 3.7.1 | + | METHOD | IC:method | Appendix A # 3.7.2 | + | PRODID | IC:prodid | Appendix A # 3.7.3 | + | VERSION | IC:version | Appendix A # 3.7.4 | + | ATTACH | IC:attach | Appendix A # 3.8.1.1 | + | CATEGORIES | IC:categories | Appendix A # 3.8.1.2 | + | CLASS | IC:class | Appendix A # 3.8.1.3 | + | COMMENT | IC:comment | Appendix A # 3.8.1.4 | + | DESCRIPTION | IC:description | Appendix A # 3.8.1.5 | + | GEO | IC:geo | Appendix A # 3.8.1.6 | + | LOCATION | IC:location | Appendix A # 3.8.1.7 | + + + +Daboo, et al. Standards Track [Page 7] + +RFC 6321 xCal August 2011 + + + | PERCENT-COMPLETE | IC:percent-complete | Appendix A # 3.8.1.8 | + | PRIORITY | IC:priority | Appendix A # 3.8.1.9 | + | RESOURCES | IC:resources | Appendix A # 3.8.1.10 | + | STATUS | IC:status | Appendix A # 3.8.1.11 | + | SUMMARY | IC:summary | Appendix A # 3.8.1.12 | + | COMPLETED | IC:completed | Appendix A # 3.8.2.1 | + | DTEND | IC:dtend | Appendix A # 3.8.2.2 | + | DUE | IC:due | Appendix A # 3.8.2.3 | + | DTSTART | IC:dtstart | Appendix A # 3.8.2.4 | + | DURATION | IC:duration | Appendix A # 3.8.2.5 | + | FREEBUSY | IC:freebusy | Appendix A # 3.8.2.6 | + | TRANSP | IC:transp | Appendix A # 3.8.2.7 | + | TZID | IC:tzid | Appendix A # 3.8.3.1 | + | TZNAME | IC:tzname | Appendix A # 3.8.3.2 | + | TZOFFSETFROM | IC:tzoffsetfrom | Appendix A # 3.8.3.3 | + | TZOFFSETTO | IC:tzoffsetto | Appendix A # 3.8.3.4 | + | TZURL | IC:tzurl | Appendix A # 3.8.3.5 | + | ATTENDEE | IC:attendee | Appendix A # 3.8.4.1 | + | CONTACT | IC:contact | Appendix A # 3.8.4.2 | + | ORGANIZER | IC:organizer | Appendix A # 3.8.4.3 | + | RECURRENCE-ID | IC:recurrence-id | Appendix A # 3.8.4.4 | + | RELATED-TO | IC:related-to | Appendix A # 3.8.4.5 | + | URL | IC:url | Appendix A # 3.8.4.6 | + | UID | IC:uid | Appendix A # 3.8.4.7 | + | EXDATE | IC:exdate | Appendix A # 3.8.5.1 | + | RDATE | IC:rdate | Appendix A # 3.8.5.2 | + | RRULE | IC:rrule | Appendix A # 3.8.5.3 | + | ACTION | IC:action | Appendix A # 3.8.6.1 | + | REPEAT | IC:repeat | Appendix A # 3.8.6.2 | + | TRIGGER | IC:trigger | Appendix A # 3.8.6.3 | + | CREATED | IC:created | Appendix A # 3.8.7.1 | + | DTSTAMP | IC:dtstamp | Appendix A # 3.8.7.2 | + | LAST-MODIFIED | IC:last-modified | Appendix A # 3.8.7.3 | + | SEQUENCE | IC:sequence | Appendix A # 3.8.7.4 | + | REQUEST-STATUS | IC:request-status | Appendix A # 3.8.8.3 | + +------------------+---------------------+-----------------------+ + +3.4.1. Special Cases for Properties + + This section describes some properties that have special handling + when converting to xCal. + +3.4.1.1. Multi-Valued Properties + + 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 (Section 3.6). + + + +Daboo, et al. Standards Track [Page 8] + +RFC 6321 xCal August 2011 + + + +------------+---------------+-----------------------+ + | Property | XML element | XML Definition | + +------------+---------------+-----------------------+ + | CATEGORIES | IC:categories | Appendix A # 3.8.1.2 | + | RESOURCES | IC:resources | Appendix A # 3.8.1.10 | + | FREEBUSY | IC:freebusy | Appendix A # 3.8.2.6 | + | EXDATE | IC:exdate | Appendix A # 3.8.5.1 | + | RDATE | IC:rdate | Appendix A # 3.8.5.2 | + +------------+---------------+-----------------------+ + +3.4.1.2. GEO Property + + In iCalendar, the "GEO" property value is defined as a semicolon- + 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 contains float values. See Appendix A # + 3.8.1.6. + + Example: + + + + ... + + 37.386013 + -122.082932 + + ... + + +3.4.1.3. REQUEST-STATUS Property + + In iCalendar, the "REQUEST-STATUS" property value is defined as a + semicolon-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 contains + 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 Appendix A # 3.8.8.3. + + + + + +Daboo, et al. Standards Track [Page 9] + +RFC 6321 xCal August 2011 + + + Example: + + + + ... + + 2.0 + Success + + ... + + +3.5. Parameters (RFC 5545, Section 3.2) + + 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. + + + + + + +Daboo, et al. Standards Track [Page 10] + +RFC 6321 xCal August 2011 + + + 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 | Appendix A # 3.2.1 | + | CN | IC:cn | Appendix A # 3.2.2 | + | CUTYPE | IC:cutype | Appendix A # 3.2.3 | + | DELEGATED-FROM | IC:delegated-from | Appendix A # 3.2.4 | + | DELEGATED-TO | IC:delegated-to | Appendix A # 3.2.5 | + | DIR | IC:dir | Appendix A # 3.2.6 | + | ENCODING | IC:encoding | Appendix A # 3.2.7 | + | FMTTYPE | IC:fmttype | Appendix A # 3.2.8 | + | FBTYPE | IC:fbtype | Appendix A # 3.2.9 | + | LANGUAGE | IC:language | Appendix A # 3.2.10 | + | MEMBER | IC:member | Appendix A # 3.2.11 | + | PARTSTAT | IC:partstat | Appendix A # 3.2.12 | + | RANGE | IC:range | Appendix A # 3.2.13 | + | RELATED | IC:related | Appendix A # 3.2.14 | + | RELTYPE | IC:reltype | Appendix A # 3.2.15 | + | ROLE | IC:role | Appendix A # 3.2.16 | + | RSVP | IC:rsvp | Appendix A # 3.2.17 | + | SENT-BY | IC:sent-by | Appendix A # 3.2.18 | + | TZID | IC:tzid | Appendix A # 3.2.19 | + +----------------+-------------------+---------------------+ + +3.5.1. VALUE Parameter + + iCalendar defines a "VALUE" property parameter (Section 3.2.20 of + [RFC5545]). 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 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. + +3.6. Values (RFC 5545, Section 3.3) + + 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. + + + + +Daboo, et al. Standards Track [Page 11] + +RFC 6321 xCal August 2011 + + +3.6.1. Binary (RFC 5545, Section 3.3.1) + + Description: 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 [RFC4648], which is the + base64 method used in [RFC5545]. 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. + + XML Definition: Appendix A # 3.3.1 + + Example: + + SGVsbG8gV29ybGQh + +3.6.2. Boolean (RFC 5545, Section 3.3.2) + + Description: iCalendar "BOOLEAN" property values are represented by + the IC:boolean XML element. The content of the element is a + boolean value. + + XML Definition: Appendix A # 3.3.2 + + Example: + + true + +3.6.3. Calendar User Address (RFC 5545, Section 3.3.3) + + Description: iCalendar "CAL-ADDRESS" property values are represented + by the IC:cal-address XML element. The content of the element is + a URI. + + XML Definition: Appendix A # 3.3.3 + + Example: + + mailto:cyrus@example.com + +3.6.4. Date (RFC 5545, Section 3.3.4) + + Description: iCalendar "DATE" property values are represented by the + IC:date XML element. The content of the element is the same date + value specified by [RFC5545], with the exception that the date + components are separated by "-" characters, for consistency with + [W3C.REC-xmlschema-2-20041028]. + + + + +Daboo, et al. Standards Track [Page 12] + +RFC 6321 xCal August 2011 + + + XML Definition: Appendix A # 3.3.4 + + Example: + + 2011-05-17 + +3.6.5. Date-Time (RFC 5545, Section 3.3.5) + + Description: 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 [RFC5545], with the + exception that the date components are separated by "-" + characters, and the time components are separated by ":" + characters, for consistency with [W3C.REC-xmlschema-2-20041028]. + 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 time zone + definitions via the "TZID" property parameter. + + XML Definition: Appendix A # 3.3.5 + + Example: + + 2011-05-17T12:00:00 + +3.6.6. Duration (RFC 5545, Section 3.3.6) + + Description: iCalendar "DURATION" property values are represented by + the IC:duration XML element. The content of the element is the + same duration value specified by [RFC5545]. + + XML Definition: Appendix A # 3.3.6 + + Example: + + P1D + +3.6.7. Float (RFC 5545, Section 3.3.7) + + Description: 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. + + XML Definition: Appendix A # 3.3.7 + + Example: + + 0.5 + + + +Daboo, et al. Standards Track [Page 13] + +RFC 6321 xCal August 2011 + + +3.6.8. Integer (RFC 5545, Section 3.3.8) + + Description: 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. + + XML Definition: Appendix A # 3.3.8 + + Examples: + + 50 + -100 + +3.6.9. Period of Time (RFC 5545, Section 3.3.9) + + Description: 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. + + XML Definition: Appendix A # 3.3.9 + + Example: + + + 2011-05-17T12:00:00 + P1H + + +3.6.10. Recurrence Rule (RFC 5545, Section 3.3.10) + + Description: 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. + + XML Definition: Appendix A # 3.3.10 + + Example: + + + YEARLY + 5 + -1SU + 10 + + + + + + + +Daboo, et al. Standards Track [Page 14] + +RFC 6321 xCal August 2011 + + +3.6.11. Text (RFC 5545, Section 3.3.11) + + Description: iCalendar "TEXT" property values are represented by the + IC:text XML element. The content of the element is simple text. + + XML Definition: Appendix A # 3.3.11 + + Example: + + Hello World! + +3.6.12. Time (RFC 5545, Section 3.3.12) + + Description: iCalendar "TIME" property values are represented by the + IC:time XML element. The content of the element is the same time + value specified by [RFC5545], with the exception that the time + components are separated by ":" characters, for consistency with + [W3C.REC-xmlschema-2-20041028]. 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 time zone definitions via + the "TZID" property parameter. + + XML Definition: Appendix A # 3.3.12 + + Example: + + + +3.6.13. URI (RFC 5545, Section 3.3.13) + + Description: iCalendar "URI" property values are represented by the + IC:uri XML element. The content of the element is a URI. + + XML Definition: Appendix A # 3.3.13 + + Example: + + http://calendar.example.com + + + + + + + + + + + + +Daboo, et al. Standards Track [Page 15] + +RFC 6321 xCal August 2011 + + +3.6.14. UTC Offset (RFC 5545, Section 3.3.14) + + Description: 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 [RFC5545], with the + exception that the hour, minute, and second components are + separated by a ":" character, for consistency with + [W3C.REC-xmlschema-2-20041028]. + + XML Definition: Appendix A # 3.3.14 + + Example: + + -05:00 + +3.7. Extensions + + 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. However, see Section 5 for how to deal with + default values for unrecognized extension properties or property + parameters. + +4. Converting from xCal into iCalendar + + 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 [RFC5545]. + + BACKSLASH character encoding and line folding MUST be applied to the + resulting iCalendar data as required by [RFC5545]. + + Non-binary value types MUST NOT be base64 encoded. + +4.1. Converting XML Extensions into iCalendar + + 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. + + + +Daboo, et al. Standards Track [Page 16] + +RFC 6321 xCal August 2011 + + + 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 Section 4.2. Only those + extension elements that are immediate child elements of the IC: + properties element are converted, any others are ignored. + +4.2. The XML Property for iCalendar + + This section describes an extension property for iCalendar, as + covered in Section 8.2.3 of [RFC5545]. + + Property name: XML + + Purpose: To embed extended XML-encoded iCalendar 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 be specified multiple times in any + calendar component. + + Description: The value of this property is a single XML 1.0 + [W3C.REC-xml-20081126] element. The "XML" property MUST NOT be used + to contain properties that are already defined in iCalendar. 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 that is the value of this property MUST + have an XML namespace declaration. + + The default value type for this property is "TEXT", and normal + BACKSLASH character encoding rules for that value MUST be applied. + Note that the source XML can contain characters not allowed in "TEXT" + property values. If this is the case, then the XML data MUST be + base64 encoded. As required by [RFC5545], the "ENCODING" property + parameter MUST be present and set to "BASE64", and the "VALUE" + property parameter MUST be present and set to "BINARY". + + 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: + + + + +Daboo, et al. Standards Track [Page 17] + +RFC 6321 xCal August 2011 + + + xml = "XML" xmlparam ( ":" text ) / + ( + ";" "ENCODING" "=" "BASE64" + ";" "VALUE" "=" "BINARY" + ":" binary + ) + CRLF + + xmlparam = *(";" other-param) + + Example: The following is an example of a location embedded in KML + markup inside the "XML" property. + + XML:\n + \n + KML Sample\n + 1\n + An incomplete example of a KML docum + ent - used as an example!\n + \n + + +5. Handling Unrecognized Properties or Parameters + + 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 are 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: + + o 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. + + + +Daboo, et al. Standards Track [Page 18] + +RFC 6321 xCal August 2011 + + + o 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: + + X-PROPERTY:20110512T120000Z + + 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: + + DTSTART;X-PARAM=PT30M:20110512T130000Z + + xCal: + + + + PT30M + + 2011-05-12T13:00:00Z + + +6. Security Considerations + + For security considerations specific to calendar data, see Section 7 + of [RFC5545]. Since this specification is a mapping from iCalendar, + no new security concerns are introduced related to calendar data. + + + + + +Daboo, et al. Standards Track [Page 19] + +RFC 6321 xCal August 2011 + + + The use of XML as a format does have security risks. Section 7 of + [RFC3470] discusses these risks. See also the security discussion + for the application/xml type in [RFC3023]. + +7. IANA Considerations + + This document defines a new URN to identify a new XML namespace for + iCalendar data. The URN conforms to a registry mechanism described + in [RFC3688]. + + This document defines a new media type. The registration is in + Section 7.2. + + This document defines a new property for iCalendar. The registration + is in Section 7.3. + +7.1. Namespace Registration + + 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. + +7.2. Media Type + + This section defines the MIME media type for use with iCalendar in + XML data. + + Type name: application + + Subtype name: calendar+xml + + Required parameters: None + + Optional parameters: method, component, and optinfo as defined for + the text/calendar media type in [RFC5545]; charset as defined for + application/xml in [RFC3023]; per [RFC3023], use of the charset + property parameter with the value "utf-8" is STRONGLY RECOMMENDED. + + Encoding considerations: Same as encoding considerations of + application/xml as specified in [RFC3023]. + + + + + + +Daboo, et al. Standards Track [Page 20] + +RFC 6321 xCal August 2011 + + + Security considerations: See Section 6. + + Interoperability considerations: This media type provides an + alternative format for iCalendar data based on XML. + + Published specification: This specification. + + Applications that use this media type: Applications that currently + make use of the text/calendar media type can use this as an + alternative. + + Additional information: + + Magic number(s): None + + File extension(s): xcs + + Macintosh file type code(s): None specified. + + Person & email address to contact for further information: + calsify@ietf.org + + Intended usage: COMMON + + Restrictions on usage: There are no restrictions on where this media + type can be used. + + Author: See the "Authors' Addresses" section of this document. + + Change controller: IETF + +7.3. iCalendar Property Registrations + + This document defines the following new iCalendar property to be + added to the registry defined in Section 8.2.3 of [RFC5545]: + + +----------+---------+-----------------------+ + | Property | Status | Reference | + +----------+---------+-----------------------+ + | XML | Current | RFC 6321, Section 4.2 | + +----------+---------+-----------------------+ + + + + + + + + + + +Daboo, et al. Standards Track [Page 21] + +RFC 6321 xCal August 2011 + + +8. Acknowledgments + + 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. + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media + Types", RFC 3023, January 2001. + + [RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for + the Use of Extensible Markup Language (XML) + within IETF Protocols", BCP 70, RFC 3470, January 2003. + + [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, + January 2004. + + [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data + Encodings", RFC 4648, October 2006. + + [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling + Core Object Specification (iCalendar)", RFC 5545, + September 2009. + + [W3C.REC-xml-20081126] + Sperberg-McQueen, C., Yergeau, F., Bray, T., Paoli, J., + and E. Maler, "Extensible Markup Language (XML) 1.0 (Fifth + Edition)", World Wide Web Consortium Recommendation REC- + xml-20081126, November 2008, + . + +9.2. Informative References + + [W3C.REC-xmlschema-2-20041028] + Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes + Second Edition", World Wide Web Consortium + Recommendation REC-xmlschema-2-20041028, October 2004, + . + + + + + +Daboo, et al. Standards Track [Page 22] + +RFC 6321 xCal August 2011 + + +Appendix A. RELAX NG Schema + + 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 sections in [RFC5545]. + The ordering of elements follows the section ordering of [RFC5545]. + + 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 RELAX NG, 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. + + # RELAX NG Schema for iCalendar in XML + + default namespace = "urn:ietf:params:xml:ns:icalendar-2.0" + + # 3.2 Property Parameters + + # 3.2.1 Alternate Text Representation + + altrepparam = element altrep { + value-uri + } + + # 3.2.2 Common Name + + cnparam = element cn { + value-text + } + + + + + + + + + + +Daboo, et al. Standards Track [Page 23] + +RFC 6321 xCal August 2011 + + + # 3.2.3 Calendar User Type + + cutypeparam = element cutype { + element text { + "INDIVIDUAL" | + "GROUP" | + "RESOURCE" | + "ROOM" | + "UNKNOWN" + } + } + + # 3.2.4 Delegators + + delfromparam = element delegated-from { + value-cal-address+ + } + + # 3.2.5 Delegatees + + deltoparam = element delegated-to { + value-cal-address+ + } + + # 3.2.6 Directory Entry Reference + + dirparam = element dir { + value-uri + } + + # 3.2.7 Inline Encoding + + encodingparam = element encoding { + element text { + "8BIT" | + "BASE64" + } + } + + # 3.2.8 Format Type + + fmttypeparam = element fmttype { + value-text + } + + + + + + + +Daboo, et al. Standards Track [Page 24] + +RFC 6321 xCal August 2011 + + + # 3.2.9 Free/Busy Time Type + + fbtypeparam = element fbtype { + element text { + "FREE" | + "BUSY" | + "BUSY-UNAVAILABLE" | + "BUSY-TENTATIVE" + } + } + + # 3.2.10 Language + + languageparam = element language { + value-text + } + + # 3.2.11 Group or List Membership + + memberparam = element member { + value-cal-address+ + } + + # 3.2.12 Participation Status + + partstatparam = element partstat { + type-partstat-event | + type-partstat-todo | + type-partstat-jour + } + + type-partstat-event = ( + element text { + "NEEDS-ACTION" | + "ACCEPTED" | + "DECLINED" | + "TENTATIVE" | + "DELEGATED" + } + ) + + + + + + + + + + + +Daboo, et al. Standards Track [Page 25] + +RFC 6321 xCal August 2011 + + + type-partstat-todo = ( + element text { + "NEEDS-ACTION" | + "ACCEPTED" | + "DECLINED" | + "TENTATIVE" | + "DELEGATED" | + "COMPLETED" | + "IN-PROCESS" + } + ) + + type-partstat-jour = ( + element text { + "NEEDS-ACTION" | + "ACCEPTED" | + "DECLINED" + } + ) + + # 3.2.13 Recurrence Identifier Range + + rangeparam = element range { + element text { + "THISANDFUTURE" + } + } + + # 3.2.14 Alarm Trigger Relationship + + trigrelparam = element related { + element text { + "START" | + "END" + } + } + + # 3.2.15 Relationship Type + + reltypeparam = element reltype { + element text { + "PARENT" | + "CHILD" | + "SIBLING" + } + } + + + + + +Daboo, et al. Standards Track [Page 26] + +RFC 6321 xCal August 2011 + + + # 3.2.16 Participation Role + + roleparam = element role { + element text { + "CHAIR" | + "REQ-PARTICIPANT" | + "OPT-PARTICIPANT" | + "NON-PARTICIPANT" + } + } + + # 3.2.17 RSVP Expectation + + rsvpparam = element rsvp { + value-boolean + } + + # 3.2.18 Sent By + + sentbyparam = element sent-by { + value-cal-address + } + + # 3.2.19 Time Zone Identifier + + tzidparam = element tzid { + value-text + } + + # 3.3 Property Value Data Types + + # 3.3.1 BINARY + + value-binary = element binary { + xsd:string + } + + # 3.3.2 BOOLEAN + + value-boolean = element boolean { + xsd:boolean + } + + # 3.3.3 CAL-ADDRESS + + value-cal-address = element cal-address { + xsd:anyURI + } + + + +Daboo, et al. Standards Track [Page 27] + +RFC 6321 xCal August 2011 + + + # 3.3.4 DATE + + pattern-date = xsd:string { + pattern = "\d\d\d\d-\d\d-\d\d" + } + + value-date = element date { + pattern-date + } + + # 3.3.5 DATE-TIME + + pattern-date-time = xsd:string { + pattern = "\d\d\d\d-\d\d-\d\dT\d\d:\d\d:\d\dZ?" + } + + value-date-time = element date-time { + pattern-date-time + } + + # 3.3.6 DURATION + + pattern-duration = xsd:string { + pattern = "(+|-)?P(\d+W)|(\d+D)?" + ~ "(T(\d+H(\d+M)?(\d+S)?)|" + ~ "(\d+M(\d+S)?)|" + ~ "(\d+S))?" + } + + value-duration = element duration { + pattern-duration + } + + # 3.3.7 FLOAT + + value-float = element float { + xsd:float + } + + # 3.3.8 INTEGER + + value-integer = element integer { + xsd:integer + } + + + + + + + +Daboo, et al. Standards Track [Page 28] + +RFC 6321 xCal August 2011 + + + # 3.3.9 PERIOD + + value-period = element period { + element start { + pattern-date-time + }, + ( + element end { + pattern-date-time + } | + element duration { + pattern-duration + } + ) + } + + # 3.3.10 RECUR + + value-recur = element recur { + type-freq, + (type-until | type-count)?, + element interval { + xsd:positiveInteger + }?, + type-bysecond*, + type-byminute*, + type-byhour*, + type-byday*, + type-bymonthday*, + type-byyearday*, + type-byweekno*, + type-bymonth*, + type-bysetpos*, + element wkst { type-weekday }? + } + + type-freq = element freq { + "SECONDLY" | + "MINUTELY" | + "HOURLY" | + "DAILY" | + "WEEKLY" | + "MONTHLY" | + "YEARLY" + } + + + + + + +Daboo, et al. Standards Track [Page 29] + +RFC 6321 xCal August 2011 + + + type-until = element until { + type-date | + type-date-time + } + + type-count = element count { + xsd:positiveInteger + } + + type-bysecond = element bysecond { + xsd:positiveInteger + } + + type-byminute = element byminute { + xsd:positiveInteger + } + + type-byhour = element byhour { + xsd:positiveInteger + } + + type-weekday = ( + "SU" | + "MO" | + "TU" | + "WE" | + "TH" | + "FR" | + "SA" + ) + + type-byday = element byday { + xsd:integer?, + type-weekday + } + + type-bymonthday = element bymonthday { + xsd:integer + } + + type-byyearday = element byyearday { + xsd:integer + } + + type-byweekno = element byweekno { + xsd:integer + } + + + + +Daboo, et al. Standards Track [Page 30] + +RFC 6321 xCal August 2011 + + + type-bymonth = element bymonth { + xsd:positiveInteger + } + + type-bysetpos = element bysetpos { + xsd:integer + } + + # 3.3.11 TEXT + + value-text = element text { + xsd:string + } + + # 3.3.12 TIME + + pattern-time = xsd:string { + pattern = "\d\d:\d\d:\d\dZ?" + } + + value-time = element time { + pattern-time + } + + # 3.3.13 URI + + value-uri = element uri { + xsd:anyURI + } + + # 3.3.14 UTC-OFFSET + + value-utc-offset = element utc-offset { + xsd:string { pattern = "(+|-)\d\d:\d\d(:\d\d)?" } + } + + # UNKNOWN + + value-unknown = element unknown { + xsd:string + } + + # 3.4 iCalendar Stream + + start = element icalendar { + vcalendar+ + } + + + + +Daboo, et al. Standards Track [Page 31] + +RFC 6321 xCal August 2011 + + + # 3.6 Calendar Components + + vcalendar = element vcalendar { + type-calprops, + type-component + } + + type-calprops = element properties { + property-prodid & + property-version & + property-calscale? & + property-method? + } + + type-component = element components { + ( + component-vevent | + component-vtodo | + component-vjournal | + component-vfreebusy | + component-vtimezone + )* + } + + # 3.6.1 Event Component + + component-vevent = element vevent { + type-eventprop, + element components { + component-valarm+ + }? + } + + type-eventprop = element properties { + property-dtstamp & + property-dtstart & + property-uid & + + property-class? & + property-created? & + property-description? & + property-geo? & + property-last-mod? & + property-location? & + property-organizer? & + property-priority? & + property-seq? & + property-status-event? & + + + +Daboo, et al. Standards Track [Page 32] + +RFC 6321 xCal August 2011 + + + property-summary? & + property-transp? & + property-url? & + property-recurid? & + + property-rrule? & + + (property-dtend | property-duration)? & + + property-attach* & + property-attendee* & + property-categories* & + property-comment* & + property-contact* & + property-exdate* & + property-rstatus* & + property-related* & + property-resources* & + property-rdate* + } + + # 3.6.2 To-do Component + + component-vtodo = element vtodo { + type-todoprop, + element components { + component-valarm+ + }? + } + + type-todoprop = element properties { + property-dtstamp & + property-uid & + + property-class? & + property-completed? & + property-created? & + property-description? & + property-geo? & + property-last-mod? & + property-location? & + property-organizer? & + property-percent? & + property-priority? & + property-recurid? & + property-seq? & + property-status-todo? & + property-summary? & + + + +Daboo, et al. Standards Track [Page 33] + +RFC 6321 xCal August 2011 + + + property-url? & + + property-rrule? & + + ( + (property-dtstart?, property-dtend? ) | + (property-dtstart, property-duration)? + ) & + + property-attach* & + property-attendee* & + property-categories* & + property-comment* & + property-contact* & + property-exdate* & + property-rstatus* & + property-related* & + property-resources* & + property-rdate* + } + + # 3.6.3 Journal Component + + component-vjournal = element vjournal { + type-jourprop + } + + type-jourprop = element properties { + property-dtstamp & + property-uid & + + property-class? & + property-created? & + property-dtstart? & + property-last-mod? & + property-organizer? & + property-recurid? & + property-seq? & + property-status-jour? & + property-summary? & + property-url? & + + property-rrule? & + + property-attach* & + property-attendee* & + property-categories* & + property-comment* & + + + +Daboo, et al. Standards Track [Page 34] + +RFC 6321 xCal August 2011 + + + property-contact* & + property-description? & + property-exdate* & + property-related* & + property-rdate* & + property-rstatus* + } + + # 3.6.4 Free/Busy Component + + component-vfreebusy = element vfreebusy { + type-fbprop + } + + type-fbprop = element properties { + property-dtstamp & + property-uid & + + property-contact? & + property-dtstart? & + property-dtend? & + property-duration? & + property-organizer? & + property-url? & + + property-attendee* & + property-comment* & + property-freebusy* & + property-rstatus* + } + + # 3.6.5 Time Zone Component + + component-vtimezone = element vtimezone { + element properties { + property-tzid & + + property-last-mod? & + property-tzuurl? + }, + element components { + (component-standard | component-daylight) & + component-standard* & + component-daylight* + } + } + + + + + +Daboo, et al. Standards Track [Page 35] + +RFC 6321 xCal August 2011 + + + component-standard = element standard { + type-tzprop + } + + component-daylight = element daylight { + type-tzprop + } + + type-tzprop = element properties { + property-dtstart & + property-tzoffsetto & + property-tzoffsetfrom & + + property-rrule? & + + property-comment* & + property-rdate* & + property-tzname* + } + + # 3.6.6 Alarm Component + + component-valarm = element valarm { + audioprop | dispprop | emailprop + } + + type-audioprop = element properties { + property-action & + + property-trigger & + + (property-duration, property-repeat)? & + + property-attach? + } + + type-dispprop = element properties { + property-action & + property-description & + property-trigger & + property-summary & + + property-attendee+ & + + (property-duration, property-repeat)? & + + property-attach* + } + + + +Daboo, et al. Standards Track [Page 36] + +RFC 6321 xCal August 2011 + + + type-emailprop = element properties { + property-action & + property-description & + property-trigger & + + (property-duration, property-repeat)? + } + + # 3.7 Calendar Properties + + # 3.7.1 Calendar Scale + + property-calscale = element calscale { + + element parameters { empty }?, + + element text { "GREGORIAN" } + } + + # 3.7.2 Method + + property-method = element method { + + element parameters { empty }?, + + value-text + } + + # 3.7.3 Product Identifier + + property-prodid = element prodid { + + element parameters { empty }?, + + value-text + } + + # 3.7.4 Version + + property-version = element version { + + element parameters { empty }?, + + element text { "2.0" } + } + + + + + + +Daboo, et al. Standards Track [Page 37] + +RFC 6321 xCal August 2011 + + + # 3.8 Component Properties + + # 3.8.1 Descriptive Component Properties + + # 3.8.1.1 Attachment + + property-attach = element attach { + + element parameters { + fmttypeparam? & + encodingparam? + }?, + + value-uri | value-binary + } + + # 3.8.1.2 Categories + + property-categories = element categories { + + element parameters { + languageparam? & + }?, + + value-text+ + } + + # 3.8.1.3 Classification + + property-class = element class { + + element parameters { empty }?, + + element text { + "PUBLIC" | + "PRIVATE" | + "CONFIDENTIAL" + } + } + + # 3.8.1.4 Comment + + property-comment = element comment { + + element parameters { + altrepparam? & + languageparam? + }?, + + + +Daboo, et al. Standards Track [Page 38] + +RFC 6321 xCal August 2011 + + + value-text + } + + # 3.8.1.5 Description + + property-description = element description { + + element parameters { + altrepparam? & + languageparam? + }?, + + value-text + } + + # 3.8.1.6 Geographic Position + + property-geo = element geo { + + element parameters { empty }?, + + element latitude { xsd:float }, + element longitude { xsd:float } + } + + # 3.8.1.7 Location + + property-location = element location { + + element parameters { + + altrepparam? & + languageparam? + }?, + + value-text + } + + # 3.8.1.8 Percent Complete + + property-percent = element percent-complete { + + element parameters { empty }?, + + value-integer + } + + + + + +Daboo, et al. Standards Track [Page 39] + +RFC 6321 xCal August 2011 + + + # 3.8.1.9 Priority + + property-priority = element priority { + + element parameters { empty }?, + + value-integer + } + + # 3.8.1.10 Resources + + property-resources = element resources { + + element parameters { + altrepparam? & + languageparam? + }?, + + value-text+ + } + + # 3.8.1.11 Status + + property-status-event = element status { + + element parameters { empty }?, + + element text { + "TENTATIVE" | + "CONFIRMED" | + "CANCELLED" + } + } + + property-status-todo = element status { + + element parameters { empty }?, + + element text { + "NEEDS-ACTION" | + "COMPLETED" | + "IN-PROCESS" | + "CANCELLED" + } + } + + + + + + +Daboo, et al. Standards Track [Page 40] + +RFC 6321 xCal August 2011 + + + property-status-jour = element status { + + element parameters { empty }?, + + element text { + "DRAFT" | + "FINAL" | + "CANCELLED" + } + } + + # 3.8.1.12 Summary + + property-summary = element summary { + + element parameters { + altrepparam? & + languageparam? + }?, + + value-text + } + + # 3.8.2 Date and Time Component Properties + + # 3.8.2.1 Date/Time Completed + + property-completed = element completed { + + element parameters { empty }?, + + value-date-time + } + + # 3.8.2.2 Date/Time End + + property-dtend = element dtend { + + element parameters { + tzidparam? + }?, + + value-date-time | + value-date + } + + + + + + +Daboo, et al. Standards Track [Page 41] + +RFC 6321 xCal August 2011 + + + # 3.8.2.3 Date/Time Due + + property-due = element due { + + element parameters { + tzidparam? + }?, + + value-date-time | + value-date + } + + # 3.8.2.4 Date/Time Start + + property-dtstart = element dtstart { + + element parameters { + tzidparam? + }?, + + value-date-time | + value-date + } + + # 3.8.2.5 Duration + + property-duration = element duration { + + element parameters { empty }?, + + value-duration + } + + # 3.8.2.6 Free/Busy Time + + property-freebusy = element freebusy { + + element parameters { + fbtypeparam? + }?, + + + value-period+ + } + + # 3.8.2.7 Time Transparency + + property-transp = element transp { + + + +Daboo, et al. Standards Track [Page 42] + +RFC 6321 xCal August 2011 + + + element parameters { empty }?, + + element text { + "OPAQUE" | + "TRANSPARENT" + } + } + + # 3.8.3 Time Zone Component Properties + + # 3.8.3.1 Time Zone Identifier + + property-tzid = element tzid { + + element parameters { empty }?, + + value-text + } + + # 3.8.3.2 Time Zone Name + + property-tzname = element tzname { + + element parameters { + languageparam? + }?, + + value-text + } + + # 3.8.3.3 Time Zone Offset From + + property-tzoffsetfrom = element tzoffsetfrom { + + element parameters { empty }?, + + value-utc-offset + } + + # 3.8.3.4 Time Zone Offset To + + property-tzoffsetto = element tzoffsetto { + + element parameters { empty }?, + + value-utc-offset + } + + + + +Daboo, et al. Standards Track [Page 43] + +RFC 6321 xCal August 2011 + + + # 3.8.3.5 Time Zone URL + + property-tzurl = element tzurl { + + element parameters { empty }?, + + value-uri + } + + # 3.8.4 Relationship Component Properties + + # 3.8.4.1 Attendee + + property-attendee = element attendee { + + element parameters { + cutypeparam? & + memberparam? & + roleparam? & + partstatparam? & + rsvpparam? & + deltoparam? & + delfromparam? & + sentbyparam? & + cnparam? & + dirparam? & + languageparam? + }?, + + value-cal-address + } + + # 3.8.4.2 Contact + + property-contact = element contact { + + element parameters { + altrepparam? & + languageparam? + }?, + + value-text + } + + # 3.8.4.3 Organizer + + property-organizer = element organizer { + + + + +Daboo, et al. Standards Track [Page 44] + +RFC 6321 xCal August 2011 + + + element parameters { + cnparam? & + dirparam? & + sentbyparam? & + languageparam? + }?, + + value-cal-address + } + + # 3.8.4.4 Recurrence ID + + property-recurid = element recurrence-id { + + element parameters { + tzidparam? & + rangeparam? + }?, + + value-date-time | + value-date + } + + # 3.8.4.5 Related-To + + property-related = element related-to { + + element parameters { + reltypeparam? + }?, + + value-text + } + + # 3.8.4.6 Uniform Resource Locator + + property-url = element url { + + element parameters { empty }?, + + value-uri + } + + # 3.8.4.7 Unique Identifier + + property-uid = element uid { + + element parameters { empty }?, + + + +Daboo, et al. Standards Track [Page 45] + +RFC 6321 xCal August 2011 + + + value-text + } + + # 3.8.5 Recurrence Component Properties + + # 3.8.5.1 Exception Date/Times + + property-exdate = element exdate { + + element parameters { + tzidparam? + }?, + + value-date-time+ | + value-date+ + } + + # 3.8.5.2 Recurrence Date/Times + + property-rdate = element rdate { + + element parameters { + tzidparam? + }?, + + value-date-time+ | + value-date+ | + value-period+ + } + + # 3.8.5.3 Recurrence Rule + + property-rrule = element rrule { + + element parameters { empty }?, + + value-recur + } + + # 3.8.6 Alarm Component Properties + + # 3.8.6.1 Action + + property-action = element action { + + element parameters { empty }?, + + + + + +Daboo, et al. Standards Track [Page 46] + +RFC 6321 xCal August 2011 + + + element text { + "AUDIO" | + "DISPLAY" | + "EMAIL" + } + } + + # 3.8.6.2 Repeat Count + + property-repeat = element repeat { + + element parameters { empty }?, + + value-integer + } + + # 3.8.6.3 Trigger + + property-trigger = element trigger { + + ( + element parameters { + trigrelparam? + }?, + + value-duration + ) | + ( + element parameters { empty }?, + + value-date-time + ) + } + + # 3.8.7 Change Management Component Properties + + # 3.8.7.1 Date/Time Created + + property-created = element created { + + element parameters { empty }?, + + value-date-time + } + + # 3.8.7.2 Date/Time Stamp + + property-dtstamp = element dtstamp { + + + +Daboo, et al. Standards Track [Page 47] + +RFC 6321 xCal August 2011 + + + element parameters { empty }?, + + value-date-time + } + + # 3.8.7.3 Last Modified + + property-last-mod = element last-modified { + + element parameters { empty }?, + + value-date-time + } + + # 3.8.7.4 Sequence Number + + property-seq = element sequence { + + element parameters { empty }?, + + value-integer + } + + # 3.8.8 Miscellaneous Component Properties + + # 3.8.8.3 Request Status + + property-rstatus = element request-status { + + element parameters { + languageparam? + }?, + + element code { xsd:string }, + element description { xsd:string }, + element data { xsd:string }? + } + + + + + + + + + + + + + + +Daboo, et al. Standards Track [Page 48] + +RFC 6321 xCal August 2011 + + +Appendix B. Examples + + This section contains two examples of iCalendar objects with their + xCal representation. + +B.1. Example 1 + +B.1.1. iCalendar Data + + BEGIN:VCALENDAR + CALSCALE:GREGORIAN + PRODID:-//Example Inc.//Example Calendar//EN + VERSION:2.0 + BEGIN:VEVENT + DTSTAMP:20080205T191224Z + DTSTART:20081006 + SUMMARY:Planning meeting + UID:4088E990AD89CB3DBB484909 + END:VEVENT + END:VCALENDAR + +B.1.2. XML Data + + + + + + + GREGORIAN + + + -//Example Inc.//Example Calendar//EN + + + 2.0 + + + + + + + 2008-02-05T19:12:24Z + + + 2008-10-06 + + + Planning meeting + + + +Daboo, et al. Standards Track [Page 49] + +RFC 6321 xCal August 2011 + + + + + 4088E990AD89CB3DBB484909 + + + + + + + +B.2. Example 2 + +B.2.1. iCalendar Data + + VERSION:2.0 + PRODID:-//Example Corp.//Example Client//EN + BEGIN:VTIMEZONE + LAST-MODIFIED:20040110T032845Z + TZID:US/Eastern + BEGIN:DAYLIGHT + DTSTART:20000404T020000 + RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 + TZNAME:EDT + TZOFFSETFROM:-0500 + TZOFFSETTO:-0400 + END:DAYLIGHT + BEGIN:STANDARD + DTSTART:20001026T020000 + RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 + TZNAME:EST + TZOFFSETFROM:-0400 + TZOFFSETTO:-0500 + END:STANDARD + END:VTIMEZONE + BEGIN:VEVENT + DTSTAMP:20060206T001121Z + DTSTART;TZID=US/Eastern:20060102T120000 + DURATION:PT1H + RRULE:FREQ=DAILY;COUNT=5 + RDATE;TZID=US/Eastern;VALUE=PERIOD:20060102T150000/PT2H + SUMMARY:Event #2 + DESCRIPTION:We are having a meeting all this week at 12 pm fo + r one hour\, with an additional meeting on the first day 2 h + ours long.\nPlease bring your own lunch for the 12 pm meetin + gs. + UID:00959BC664CA650E933C892C@example.com + END:VEVENT + BEGIN:VEVENT + + + +Daboo, et al. Standards Track [Page 50] + +RFC 6321 xCal August 2011 + + + DTSTAMP:20060206T001121Z + DTSTART;TZID=US/Eastern:20060104T140000 + DURATION:PT1H + RECURRENCE-ID;TZID=US/Eastern:20060104T120000 + SUMMARY:Event #2 bis + UID:00959BC664CA650E933C892C@example.com + END:VEVENT + END:VCALENDAR + +B.2.2. XML Data + + + + + + + -//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 + + + +Daboo, et al. Standards Track [Page 51] + +RFC 6321 xCal August 2011 + + + + + -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 + + + +Daboo, et al. Standards Track [Page 52] + +RFC 6321 xCal August 2011 + + + 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 + + + +Daboo, et al. Standards Track [Page 53] + +RFC 6321 xCal August 2011 + + + + + 00959BC664CA650E933C892C@example.com + + + + + + + +Authors' Addresses + + Cyrus Daboo + Apple Inc. + 1 Infinite Loop + Cupertino, CA 95014 + USA + + EMail: cyrus@daboo.name + URI: http://www.apple.com/ + + + Mike Douglass + Rensselaer Polytechnic Institute + 110 8th Street + Troy, NY 12180 + USA + + EMail: douglm@rpi.edu + URI: http://www.rpi.edu/ + + + Steven Lees + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + USA + + EMail: steven.lees@microsoft.com + URI: http://www.microsoft.com/ + + + + + + + + + + + +Daboo, et al. Standards Track [Page 54] + -- cgit v1.2.3