3027 lines
78 KiB
Text
3027 lines
78 KiB
Text
|
||
|
||
|
||
|
||
|
||
|
||
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.
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]
|
||
|