aboutsummaryrefslogtreecommitdiffstats
path: root/vendor/sabre/dav/docs/rfc6321.txt
diff options
context:
space:
mode:
Diffstat (limited to 'vendor/sabre/dav/docs/rfc6321.txt')
-rw-r--r--vendor/sabre/dav/docs/rfc6321.txt3027
1 files changed, 3027 insertions, 0 deletions
diff --git a/vendor/sabre/dav/docs/rfc6321.txt b/vendor/sabre/dav/docs/rfc6321.txt
new file mode 100644
index 000000000..c038c64cf
--- /dev/null
+++ b/vendor/sabre/dav/docs/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:
+
+ <?xml version="1.0" encoding="utf-8"?>
+ <icalendar xmlns="urn:ietf:params:xml:ns:icalendar-2.0">
+ <vcalendar>
+ ...
+ </vcalendar>
+ </icalendar>
+
+ 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:
+
+ <?xml version="1.0" encoding="utf-8"?>
+ <icalendar xmlns="urn:ietf:params:xml:ns:icalendar-2.0">
+ <vcalendar>
+ <properties>
+ ...
+ </properties>
+ <components>
+ ...
+ </components>
+ </vcalendar>
+ </icalendar>
+
+ +------------------+--------------+------------------+
+ | 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:
+
+ <?xml version="1.0" encoding="utf-8"?>
+ <icalendar xmlns="urn:ietf:params:xml:ns:icalendar-2.0">
+ <vcalendar>
+ <properties>
+ <calscale>...</calscale>
+ <version>...</version>
+ <prodid>...</prodid>
+ </properties>
+ <components>
+ ...
+ </components>
+ </vcalendar>
+ </icalendar>
+
+ 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:
+
+ <?xml version="1.0" encoding="utf-8"?>
+ <icalendar xmlns="urn:ietf:params:xml:ns:icalendar-2.0">
+ ...
+ <geo>
+ <latitude>37.386013</latitude>
+ <longitude>-122.082932</longitude>
+ </geo>
+ ...
+ </icalendar>
+
+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:
+
+ <?xml version="1.0" encoding="utf-8"?>
+ <icalendar xmlns="urn:ietf:params:xml:ns:icalendar-2.0">
+ ...
+ <request-status>
+ <code>2.0</code>
+ <description>Success</description>
+ </request-status>
+ ...
+ </icalendar>
+
+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:
+
+ <?xml version="1.0" encoding="utf-8"?>
+ <icalendar xmlns="urn:ietf:params:xml:ns:icalendar-2.0">
+ <vcalendar>
+ ...
+ <components>
+ ...
+ <attendee>
+ <parameters>
+ <partstat><text>NEEDS-ACTION</text></partstat>
+ </parameters>
+ ...
+ </attendee>
+ ...
+ </components>
+ </vcalendar>
+ </icalendar>
+
+ 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:
+
+ <binary>SGVsbG8gV29ybGQh</binary>
+
+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:
+
+ <boolean>true</boolean>
+
+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:
+
+ <cal-address>mailto:cyrus@example.com</cal-address>
+
+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:
+
+ <date>2011-05-17</date>
+
+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:
+
+ <date-time>2011-05-17T12:00:00</date-time>
+
+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:
+
+ <duration>P1D</duration>
+
+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:
+
+ <float>0.5</float>
+
+
+
+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:
+
+ <integer>50</integer>
+ <integer>-100</integer>
+
+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:
+
+ <period>
+ <start>2011-05-17T12:00:00</start>
+ <duration>P1H</duration>
+ </period>
+
+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:
+
+ <recur>
+ <freq>YEARLY</freq>
+ <count>5</count>
+ <byday>-1SU</byday>
+ <bymonth>10</bymonth>
+ </recur>
+
+
+
+
+
+
+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:
+
+ <text>Hello World!</text>
+
+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:
+
+ <time>12:00:00</time>
+
+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:
+
+ <uri>http://calendar.example.com</uri>
+
+
+
+
+
+
+
+
+
+
+
+
+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:
+
+ <utc-offset>-05:00</utc-offset>
+
+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:<kml xmlns="http://www.opengis.net/kml/2.2">\n
+ <Document>\n
+ <name>KML Sample</name>\n
+ <open>1</open>\n
+ <description>An incomplete example of a KML docum
+ ent - used as an example!</description>\n
+ </Document>\n
+ </kml>
+
+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:
+
+ <x-property>
+ <unknown>20110512T120000Z</unknown>
+ </x-property>
+
+ 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:
+
+ <dtstart>
+ <parameters>
+ <x-param><unknown>PT30M</unknown></x-param>
+ </parameters>
+ <date-time>2011-05-12T13:00:00Z</date-time>
+ </dtstart>
+
+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,
+ <http://www.w3.org/TR/2008/REC-xml-20081126>.
+
+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,
+ <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
+
+
+
+
+
+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
+
+ <?xml version="1.0" encoding="utf-8"?>
+ <icalendar xmlns="urn:ietf:params:xml:ns:icalendar-2.0">
+ <vcalendar>
+ <properties>
+ <calscale>
+ <text>GREGORIAN</text>
+ </calscale>
+ <prodid>
+ <text>-//Example Inc.//Example Calendar//EN</text>
+ </prodid>
+ <version>
+ <text>2.0</text>
+ </version>
+ </properties>
+ <components>
+ <vevent>
+ <properties>
+ <dtstamp>
+ <date-time>2008-02-05T19:12:24Z</date-time>
+ </dtstamp>
+ <dtstart>
+ <date>2008-10-06</date>
+ </dtstart>
+ <summary>
+ <text>Planning meeting</text>
+
+
+
+Daboo, et al. Standards Track [Page 49]
+
+RFC 6321 xCal August 2011
+
+
+ </summary>
+ <uid>
+ <text>4088E990AD89CB3DBB484909</text>
+ </uid>
+ </properties>
+ </vevent>
+ </components>
+ </vcalendar>
+ </icalendar>
+
+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
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <icalendar xmlns="urn:ietf:params:xml:ns:icalendar-2.0">
+ <vcalendar>
+ <properties>
+ <prodid>
+ <text>-//Example Inc.//Example Client//EN</text>
+ </prodid>
+ <version>
+ <text>2.0</text>
+ </version>
+ </properties>
+ <components>
+ <vtimezone>
+ <properties>
+ <last-modified>
+ <date-time>2004-01-10T03:28:45Z</date-time>
+ </last-modified>
+ <tzid>US/Eastern</tzid>
+ </properties>
+ <components>
+ <daylight>
+ <properties>
+ <dtstart>
+ <date-time>2000-04-04T02:00:00</date-time>
+ </dtstart>
+ <rrule>
+ <recur>
+ <freq>YEARLY</freq>
+ <byday>1SU</byday>
+ <bymonth>4</bymonth>
+ </recur>
+ </rrule>
+ <tzname>
+ <text>EDT</text>
+ </tzname>
+ <tzoffsetfrom>
+ <utc-offset>-05:00</utc-offset>
+
+
+
+Daboo, et al. Standards Track [Page 51]
+
+RFC 6321 xCal August 2011
+
+
+ </tzoffsetfrom>
+ <tzoffsetto>
+ <utc-offset>-04:00</utc-offset>
+ </tzoffsetto>
+ </properties>
+ </daylight>
+ <standard>
+ <properties>
+ <dtstart>
+ <date-time>2000-10-26T02:00:00</date-time>
+ </dtstart>
+ <rrule>
+ <recur>
+ <freq>YEARLY</freq>
+ <byday>-1SU</byday>
+ <bymonth>10</bymonth>
+ </recur>
+ </rrule>
+ <tzname>
+ <text>EST</text>
+ </tzname>
+ <tzoffsetfrom>
+ <utc-offset>-04:00</utc-offset>
+ </tzoffsetfrom>
+ <tzoffsetto>
+ <utc-offset>-05:00</utc-offset>
+ </tzoffsetto>
+ </properties>
+ </standard>
+ </components>
+ </vtimezone>
+ <vevent>
+ <properties>
+ <dtstamp>
+ <date-time>2006-02-06T00:11:21Z</date-time>
+ </dtstamp>
+ <dtstart>
+ <parameters>
+ <tzid><text>US/Eastern</text></tzid>
+ </parameters>
+ <date-time>2006-01-02T12:00:00</date-time>
+ </dtstart>
+ <duration>
+ <duration>PT1H</duration>
+ </duration>
+ <rrule>
+ <recur>
+ <freq>DAILY</freq>
+
+
+
+Daboo, et al. Standards Track [Page 52]
+
+RFC 6321 xCal August 2011
+
+
+ <count>5</count>
+ </recur>
+ </rrule>
+ <rdate>
+ <parameters>
+ <tzid><text>US/Eastern</text></tzid>
+ </parameters>
+ <period>
+ <start>2006-01-02T15:00:00</start>
+ <duration>PT2H</duration>
+ </period>
+ </rdate>
+ <summary>
+ <text>Event #2</text>
+ </summary>
+ <description>
+ <text>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.&#x0a;Please bring your own lunch for the 12 pm
+ meetings.</text>
+ </description>
+ <uid>
+ <text>00959BC664CA650E933C892C@example.com</text>
+ </uid>
+ </properties>
+ </vevent>
+ <vevent>
+ <properties>
+ <dtstamp>
+ <date-time>2006-02-06T00:11:21Z</date-time>
+ </dtstamp>
+ <dtstart>
+ <parameters>
+ <tzid><text>US/Eastern</text></tzid>
+ </parameters>
+ <date-time>2006-01-04T14:00:00</date-time>
+ </dtstart>
+ <duration>
+ <duration>PT1H</duration>
+ </duration>
+ <recurrence-id>
+ <parameters>
+ <tzid><text>US/Eastern</text></tzid>
+ </parameters>
+ <date-time>2006-01-04T12:00:00</date-time>
+ </recurrence-id>
+ <summary>
+ <text>Event #2 bis</text>
+
+
+
+Daboo, et al. Standards Track [Page 53]
+
+RFC 6321 xCal August 2011
+
+
+ </summary>
+ <uid>
+ <text>00959BC664CA650E933C892C@example.com</text>
+ </uid>
+ </properties>
+ </vevent>
+ </components>
+ </vcalendar>
+ </icalendar>
+
+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]
+
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-24 16:29:22 +0000