add sabre (1.8.x) via composer in the !@#$ place it wants to be

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]
+