diff --git a/.cvsignore b/.cvsignore deleted file mode 100644 index 16fb01431..000000000 --- a/.cvsignore +++ /dev/null @@ -1,8 +0,0 @@ -bin -build -coverage -coverage.ec -target -build.properties -.settings -bin-groovy diff --git a/.hgignore b/.hgignore deleted file mode 100644 index 54dac5532..000000000 --- a/.hgignore +++ /dev/null @@ -1,11 +0,0 @@ - -syntax: regexp -^target$ -syntax: regexp -^\.classpath$ -syntax: regexp -^\.project$ -syntax: regexp -^\.settings$ -syntax: regexp -^\.pmd$ \ No newline at end of file diff --git a/CHANGELOG b/CHANGELOG index 89a914cc0..32ab9713c 100644 --- a/CHANGELOG +++ b/CHANGELOG @@ -4,7 +4,7 @@ See the changelog report for further details: - http://m2.modularity.net.au/projects/ical4j/changelog.html + http://ical4j.github.io/docs/ical4j/release-notes == diff --git a/README.md b/README.md index 7b5c16fbb..0fc76888b 100644 --- a/README.md +++ b/README.md @@ -3,24 +3,22 @@ # iCal4j - Release Notes - For a concise description of the goals and directions of iCal4j please - take a look at docs/index.html. + take a look at the [open issues](https://github.com/ical4j/ical4j/issues). - - You will find examples of how to use iCal4j at docs/introduction.html - and throughout the API documentation. + - You will find examples of how to use iCal4j in [the wiki](https://github.com/ical4j/ical4j/wiki) + and throughout the [API documentation](https://ical4j.github.io/docs/ical4j/api). - Detailed descriptions of changes included in each release may be found - in the CHANGELOG. + in the [CHANGELOG](https://ical4j.github.io/docs/ical4j/release-notes). - - iCal4j was created with the help of eclipse version 3.2 [http://eclipse.org]. - Note that the project metadata included in the source version of iCal4j may not - be compatible with prior versions of eclipse. + - iCal4j was created with the help of [Open Source](http://opensource.org) software. ## System Requirements - Java 6 or later -See [here](docs/Dependencies.md) for further details. +See [here](https://github.com/ical4j/ical4j/docs/Dependencies.md) for further details. ## Building with Gradle @@ -28,26 +26,28 @@ iCal4j includes the Gradle wrapper for a simpler and more consistent build. **Run unit tests** -`./gradlew clean test` + ./gradlew clean test **Build a new release** -`./gradlew clean test release -Prelease.forceVersion=2.0.0` + ./gradlew clean test release -Prelease.forceVersion=2.0.0 **Upload release binaries and packages** -`RELEASE_VERSION=2.0.0 ./gradlew uploadArchives uploadDist` + RELEASE_VERSION=2.0.0 ./gradlew uploadArchives uploadDist ## How to build - Maven2 - After installing Maven2 and adding to your path, you need to modify your local - profiles http://wiki.modularity.net.au/ical4j/index.php?title=Maven2. Then - open a command prompt to the location of the iCal4j source and execute the following: +After installing Maven2 and adding to your path, you need to [modify your local +profiles](https://github.com/ical4j/ical4j/wiki/Maven2). Then +open a command prompt to the location of the iCal4j source and execute the following: - [iCal4j-2.0-beta1-src] >mvn clean install - or - [iCal4j-2.0-beta1-src] >mvn clean install -P modularity-snapshots + $ mvn clean install + +or + + $ mvn clean install -P modularity-snapshots This will build and install iCal4j in your local repository. Build artifacts are generated in the 'target' directory. @@ -55,10 +55,10 @@ iCal4j includes the Gradle wrapper for a simpler and more consistent build. ## How to build - Ant - If you have downloaded the source distribution, you should be able to package a JAR - file simply by running ant in the root directory. e.g: +If you have downloaded the source distribution, you should be able to package a JAR +file simply by running ant in the root directory. e.g: - C:\Libs\iCal4j-2.0-beta1-src\>ant + C:\Libs\iCal4j-2.0-beta1-src\>ant If for some reason you would like to override the default build classpath, I would suggest creating a "build.properties" file (see the provided sample) in the root directory @@ -73,7 +73,7 @@ iCal4j includes the Gradle wrapper for a simpler and more consistent build. - You can relax iCal4j's unfolding rules by specifying the following system property: - ical4j.unfolding.relaxed=true + ical4j.unfolding.relaxed=true Note that I believe this problem is not restricted to Mozilla calendaring products, but rather may be caused by UNIX/Linux-based applications relying on the @@ -105,7 +105,7 @@ iCal4j includes the Gradle wrapper for a simpler and more consistent build. - You may also relax the parsing rules of iCal4j by setting the following system property: - ical4j.parsing.relaxed=true + ical4j.parsing.relaxed=true This property is intended as a general relaxation of parsing rules to allow for parsing otherwise invalid calendar files. Initially enabling this property will allow for the @@ -116,12 +116,12 @@ iCal4j includes the Gradle wrapper for a simpler and more consistent build. - Microsoft Outlook also appears to provide quoted TZID parameter values, as follows: - DTSTART;TZID="Pacific Time (US & Canada),Tijuana":20041011T223000 + DTSTART;TZID="Pacific Time (US & Canada),Tijuana":20041011T223000 To allow for compatibility with such iCalendar files you should specify the following system property: - ical4j.compatibility.outlook=true + ical4j.compatibility.outlook=true The full set of system properties may be found in net.fortuna.ical4j.util.CompatibilityHints. diff --git a/build.properties.sample b/build.properties.sample deleted file mode 100644 index 508b423ae..000000000 --- a/build.properties.sample +++ /dev/null @@ -1,9 +0,0 @@ -## To override properties in build.xml rename -## this file to "build.properties" and modify accordingly.. -project.classpath=C:/libs/commons-logging-1.0.4/commons-logging.jar;C:/libs/commons-codec-1.3/commons-codec-1.3.jar;${output.dir} - -## Override JAR filename.. -package.file=ical4j-${project.version}.jar - -## directory that contains emma.jar and emma_ant.jar -emma.dir=C:/Tools/emma-2.0.5312/lib diff --git a/build.xml b/build.xml deleted file mode 100644 index 512738c2e..000000000 --- a/build.xml +++ /dev/null @@ -1,244 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/docs/.cvsignore b/docs/.cvsignore deleted file mode 100644 index eedd89b45..000000000 --- a/docs/.cvsignore +++ /dev/null @@ -1 +0,0 @@ -api diff --git a/docs/apidocs/index.html b/docs/apidocs/index.html deleted file mode 100644 index 35bdbf2f7..000000000 --- a/docs/apidocs/index.html +++ /dev/null @@ -1,11 +0,0 @@ - - - - iCal4j - API Documentation - - - iCal4j - API Documentation has moved. Click - here - if you are not redirected automatically. - - diff --git a/docs/css/default.css b/docs/css/default.css deleted file mode 100644 index ac243f8dc..000000000 --- a/docs/css/default.css +++ /dev/null @@ -1,51 +0,0 @@ -body { - background-color: white; - font-family: tahoma, verdana, sans-serif; - font-size: 10pt; -} - -a { - text-decoration: none; - color: black; -} - -a:hover { - text-decoration: underline; -} - -h1 { - font-size: 36pt; -} - -img { - border: 0; -} - -table, h1 { - margin: 20px; - /* float: left; */ -} - -thead { - font-size: 18pt; - font-weight: bold; -} - -th { - text-align: left; - vertical-align: top; -} - -.title { - font-size: 36pt; -} - -.content { - margin: 20px; -} - -#footer { - text-align: center; - margin: 10px auto 10px auto; - font-size: xx-small; -} diff --git a/docs/index.html b/docs/index.html deleted file mode 100644 index 598574160..000000000 --- a/docs/index.html +++ /dev/null @@ -1,384 +0,0 @@ - - - - - iCal4j - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
iCal4j
Home|Introduction|Wiki|Documentation|News|Support|Download|License
- -
-

Overview »

-

- iCal4j is a Java library used to read and - write iCalendar data streams as defined in - RFC2445. - The iCalendar standard provides a common data format used to store information about - calendar-specific data such as events, appointments, to-do lists, etc. - All of the popular calendaring tools, such as Lotus Notes, Outlook and Apple's iCal - also support the iCalendar standard. -

-

- Providing both a parser and an object model, iCal4j allows - you to either modify existing iCalendar data or create new - data models. Validation is also provided to ensure the - data maintains a state consistent with the specification. -

-
- -
-

Popularity »

-

- - SourceForge.net Download Statistics - -

-
- -
-

Version Information »

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
0.9 -
    -
  • Initial release
  • -
  • Primary focus: parsing iCalendar data stream and building object model
  • -
  • Limited model manipulation
  • -
-
0.9.1 -
    -
  • Interim release
  • -
  • Validation of object model
  • -
  • Manipulation of object model
  • -
-
0.9.2 -
    -
  • Interim release
  • -
  • Added typed constructors to Property classes
  • -
  • Refactoring
  • -
-
0.9.3 -
    -
  • Interim release
  • -
  • Finished implementation of types (Recur, Period)
  • -
  • Bug fixes (see CHANGELOG for details)
  • -
-
0.9.4 -
    -
  • Interim release
  • -
  • Implemented proper string representations for all entities
  • -
  • Fixed folding and other changes (see CHANGELOG for details)
  • -
-
0.9.5 -
    -
  • Interim release
  • -
  • Configurable output format for some date-time-based properties (UTC or local time)
  • -
  • Added support for pre-defined VTimeZones
  • -
-
0.9.6 -
    -
  • Interim release
  • -
  • Fixed bug with parsing certain date-time properties
  • -
  • Added support for automatic validation
  • -
-
0.9.7 -
    -
  • Milestone (alpha) release
  • -
  • Added convenience constructors to object model
  • -
  • Initial design for suppporting RFC2446
  • -
-
0.9.8 -
    -
  • Second milestone (alpha) release
  • -
  • Added support for special character escaping
  • -
-
0.9.9 -
    -
  • Third milestone (alpha) release
  • -
  • All properties now mutable
  • -
  • Decoupled parser/builder to allow for alternate parser implementations
  • -
-
0.9.10 -
    -
  • Fourth milestone (alpha) release
  • -
  • Model classes now implement Serializable
  • -
  • Bug fixes related to nested VALARMs in VTODOs
  • -
-
0.9.11 -
    -
  • Fifth alpha release
  • -
  • Better support/usability for recurrence rules
  • -
  • Convenience constructors added to most components
  • -
  • Improved support for non-conformant folding of long lines
  • -
  • See the CHANGELOG for further details
  • -
-
0.9.12 -
    -
  • Sixth alpha release
  • -
  • Improved parsing of iCalendar files generated by KOrganizer
  • -
  • Reimplemented some constants as typed instances
  • -
  • Applied patch #1170060
  • -
  • Added Base64 encoding to ATTACH property
  • -
  • See the CHANGELOG for further details
  • -
-
0.9.13 -
    -
  • Seventh alpha release
  • -
  • "Normalised" DateRange/Period, DateRangeNormalizer/PeriodList and associated recurrance methods
  • -
  • Default charset is now UTF-8
  • -
  • Applied patches #1197119, #1191253, #1185766, #1203990
  • -
  • See the CHANGELOG for further details
  • -
-
0.9.14 -
    -
  • Interim release
  • -
  • Introduced Date, DateTime and Dur types
  • -
  • More support for timezones
  • -
  • Applied patches: #1234424, #1244945
  • -
  • Many more changes - see the CHANGELOG for further details
  • -
-
0.9.15 -
    -
  • Alpha release
  • -
  • Introduced custom TimeZone implementation and TimeZone Registry support
  • -
  • Added encoding/decoding of URIs
  • -
  • More bug fixes - see the CHANGELOG for further details
  • -
-
0.9.16 -
    -
  • Interim release
  • -
  • Includes a number of critical bug fixes (see CHANGELOG for further details)
  • -
-
0.9.17 -
    -
  • Interim release
  • -
  • Now includes default timezone definitions (based on Olson timezone database)
  • -
  • Support for experimental components
  • -
  • - Other bug fixes (see - CHANGELOG - for details) -
  • -
-
0.9.18 -
    -
  • Alpha release
  • -
  • Improved performance with regard to timezone lookups
  • -
  • - Date/Time instances now use the default Java timezone where no timezone - information is specified (i.e. floating time). -
  • -
  • Updated timezone definitions
  • -
  • - Other bug fixes (see - CHANGELOG - for details) -
  • -
-
0.9.19 -
    -
  • Alpha release
  • -
  • Added filtering capabilities (net.fortuna.ical4j.filter)
  • -
  • Added support for indexed components and properties (see IndexedComponentList and IndexedPropertyList
  • -
  • Improved compatibility with Mozilla Calendar's invalid "X" property (see relaxed parsing)
  • -
  • Additional convenience methods for Components and Properties
  • -
  • Even more performance improvements with timezones and dates
  • -
  • Updated timezone definitions
  • -
  • - Other bug fixes (see - CHANGELOG - for details) -
  • -
-
0.9.20 -
    -
  • Alpha release
  • -
  • Upgraded commons logging dependency to 1.1
  • -
  • Added commons codec support for encoding attachments
  • -
  • Updated timezone definitions
  • -
  • - Other bug fixes (see - CHANGELOG - for details) -
  • -
-
1.0 beta -
    -
  • Beta Release
  • -
  • Clean up and consistency check of code
  • -
-
1.0 -
    -
  • Stable Release
  • -
  • Complete implementation of RFC2445
  • -
-
1.1 -
    -
  • Stable Release
  • -
  • Complete implementation of RFC2446
  • -
-
1.2 -
    -
  • Stable Release
  • -
  • Complete implementation of RFC2447
  • -
-
-
- -
-

Dependencies »

- - Please see the - Project Documentation - for a list of dependencies. -
- - - - - \ No newline at end of file diff --git a/docs/index.php b/docs/index.php deleted file mode 100644 index cbef914e7..000000000 --- a/docs/index.php +++ /dev/null @@ -1 +0,0 @@ - diff --git a/docs/introduction.html b/docs/introduction.html deleted file mode 100644 index b0c2bc01e..000000000 --- a/docs/introduction.html +++ /dev/null @@ -1,295 +0,0 @@ - - - - - iCal4j - Introduction - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
iCal4j
Home|Introduction|Wiki|Documentation|News|Support|Download|License
- -
-

Introduction »

-

- iCal4j may be used for modifying existing iCalendar data or creating new iCalendar - data from scratch. Here you will find a few examples indicating the recommended usage - of this library. -

-
- -
-

Usage »

-

- Simply add the iCal4j jar file, - the Commons Logging jar file, and the Commons Language jar file to your classpath. -

-
- -
-

Examples »

- -

Parsing an iCalendar file

-

- Support for parsing and building an iCalendar object model is provided - by the CalendarParser and ContentHandler - interfaces. You can provide your own implementations of either - of these, or just use the default implementations as provided by - the CalendarBuilder class. Note that CalendarBuilder - is not thread-safe, and as such it is good practice to construct a new - instance for each data stream you wish to parse (see Working with TimeZones - for further reasons). -

- - - - -

-FileInputStream fin = new FileInputStream("mycalendar.ics");
-
-CalendarBuilder builder = new CalendarBuilder();
-
-Calendar calendar = builder.build(fin);
-            
- -

Iterating over a Calendar

-

- The iCal4j API is designed to conform with the standard Java collections - API as much as possible. As such, you will find that for searching and - manipulating a calendar object model you can make use of familiar concepts - such as Lists, Iterators, etc. -

- - - - -

-for (Iterator i = calendar.getComponents().iterator(); i.hasNext();) {
-    Component component = (Component) i.next();
-    System.out.println("Component [" + component.getName() + "]");
-
-    for (Iterator j = component.getProperties().iterator(); j.hasNext();) {
-        Property property = (Property) j.next();
-        System.out.println("Property [" + property.getName() + ", " + property.getValue() + "]");
-    }
-}
-            
- -

Creating a new calendar

-

- Creating a new calendar is quite straight-forward, in that all you need - to remember is that a Calendar contains a list of - Properties and Components. A calendar must - contain certain standard properties and at least one component to be - valid. You can verify that a calendar is valid via the method - Calendar.validate(). All iCal4j objects also override - Object.toString(), so you can verify the resulting calendar - data via this mechanism. -

- - - - - - - - -

-Calendar calendar = new Calendar();
-calendar.getProperties().add(new ProdId("-//Ben Fortuna//iCal4j 1.0//EN"));
-calendar.getProperties().add(Version.VERSION_2_0);
-calendar.getProperties().add(CalScale.GREGORIAN);
-
-// Add events, etc..
-	            
- Output: -

-BEGIN:VCALENDAR
-PRODID:-//Ben Fortuna//iCal4j 1.0//EN
-VERSION:2.0
-CALSCALE:GREGORIAN
-END:VCALENDAR
-            
- -

Creating an event

-

- One of the more commonly used components is a VEvent. To create - a VEvent you can either set the date value and properties manually or you can - make use of the convenience constructors to initialise standard values. -

- - - - - - - - -

-java.util.Calendar cal = java.util.Calendar.getInstance();
-cal.set(java.util.Calendar.MONTH, java.util.Calendar.DECEMBER);
-cal.set(java.util.Calendar.DAY_OF_MONTH, 25);
-
-VEvent christmas = new VEvent(new Date(cal.getTime()), "Christmas Day");
-// initialise as an all-day event..
-christmas.getProperties().getProperty(Property.DTSTART).getParameters().add(Value.DATE);
-            
- Output: -

-BEGIN:VEVENT
-DTSTAMP:20050222T044240Z
-DTSTART;VALUE=DATE:20051225
-SUMMARY:Christmas Day
-END:VEVENT
-            
- -

Working with TimeZones

-

- Complete timezone support is now provided by iCal4j, which follows these - basic principles: -

- - - - - - - - - - - - - -
-

-TimeZoneRegistry registry = TimeZoneRegistryFactory.getInstance().createRegistry();
-TimeZone timezone = registry.getTimeZone("Australia/Melbourne");
-
-java.util.Calendar cal = java.util.Calendar.getInstance(timezone);
-cal.set(java.util.Calendar.YEAR, 2005);
-cal.set(java.util.Calendar.MONTH, java.util.Calendar.NOVEMBER);
-cal.set(java.util.Calendar.DAY_OF_MONTH, 1);
-cal.set(java.util.Calendar.HOUR_OF_DAY, 15);
-cal.clear(java.util.Calendar.MINUTE);
-cal.clear(java.util.Calendar.SECOND);
-
-DateTime dt = new DateTime(cal.getTime());
-dt.setTimeZone(timezone);
-VEvent melbourneCup = new VEvent(dt, "Melbourne Cup");
-            
- Output: -

-BEGIN:VEVENT
-DTSTAMP:20051105T094739Z
-DTSTART;TZID=Australia/Melbourne:20051101T150000
-SUMMARY:Melbourne Cup
-END:VEVENT
-                    
-
- -

Saving an iCalendar file

-

- When saving an iCalendar file iCal4j will automatically validate your - calendar object model to ensure it complies with the - RFC2445 specification. - If you would prefer not to validate your calendar data you can disable the - validation by calling CalendarOutputter.setValidating(false). -

- - - - -

-FileOutputStream fout = new FileOutputStream("mycalendar.ics");
-
-CalendarOutputter outputter = new CalendarOutputter();
-outputter.output(calendar, fout);
-            
-

- More examples may be found in the API Documentation. -

-
- - - - \ No newline at end of file diff --git a/docs/license.html b/docs/license.html deleted file mode 100644 index 231e1cf89..000000000 --- a/docs/license.html +++ /dev/null @@ -1,11 +0,0 @@ - - - - iCal4j - License - - - iCal4j - License has moved. Click - here - if you are not redirected automatically. - - diff --git a/etc/.cvsignore b/etc/.cvsignore deleted file mode 100644 index b1db2237d..000000000 --- a/etc/.cvsignore +++ /dev/null @@ -1 +0,0 @@ -manifest.mf \ No newline at end of file diff --git a/etc/artwork/.cvsignore b/etc/artwork/.cvsignore deleted file mode 100644 index 085e8baf0..000000000 --- a/etc/artwork/.cvsignore +++ /dev/null @@ -1 +0,0 @@ -Thumbs.db diff --git a/etc/plugin.properties b/etc/plugin.properties deleted file mode 100644 index d971b31b6..000000000 --- a/etc/plugin.properties +++ /dev/null @@ -1,2 +0,0 @@ -pluginName=iCal4j -providerName=Ben Fortuna \ No newline at end of file diff --git a/etc/plugin.xml b/etc/plugin.xml deleted file mode 100644 index f86d0401d..000000000 --- a/etc/plugin.xml +++ /dev/null @@ -1,9 +0,0 @@ - - - - - - - - - \ No newline at end of file diff --git a/etc/pom.xml b/etc/pom.xml deleted file mode 100644 index 94ace3901..000000000 --- a/etc/pom.xml +++ /dev/null @@ -1,52 +0,0 @@ - - 4.0.0 - ical4j - ical4j - 0.9.7 - iCal4j - - - - commons-logging - commons-logging - 1.0.3 - - - - junit - junit - 3.8.1 - - - - - source - test - - - - **/*Test.java - - - **/*Abstract*Test.java - - - - test - - **/*.java - - - - - - - - source - - **/*.java - - - - - diff --git a/etc/project.xml b/etc/project.xml deleted file mode 100644 index 437c333d8..000000000 --- a/etc/project.xml +++ /dev/null @@ -1,65 +0,0 @@ - - ical4j - ical4j - iCal4j - 0.9.20 - - - Ben Fortuna - http://sourceforge.net/users/fortuna - - - - - - commons-logging - commons-logging - 1.1 - - - commons-codec - commons-codec - 1.3 - - - junit - junit - 3.8.1 - - test - - - - - - source - - - source - - **/*.java - - - - - test - - - **/*Test.java - - - net/fortuna/ical4j/model/ComponentTest.java - net/fortuna/ical4j/model/PropertyTest.java - **/*Abstract*Test.java - - - - test - - **/*.java - - - - - - diff --git a/etc/rfc2445.txt b/etc/rfc2445.txt deleted file mode 100644 index efcbc6f9e..000000000 --- a/etc/rfc2445.txt +++ /dev/null @@ -1,8290 +0,0 @@ - - - - - -Network Working Group F. Dawson -Request for Comments: 2445 Lotus -Category: Standards Track D. Stenerson - Microsoft - November 1998 - - - Internet Calendaring and Scheduling Core Object Specification - (iCalendar) - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1998). All Rights Reserved. - -Abstract - - There is a clear need to provide and deploy interoperable calendaring - and scheduling services for the Internet. Current group scheduling - and Personal Information Management (PIM) products are being extended - for use across the Internet, today, in proprietary ways. This memo - has been defined to provide the definition of a common format for - openly exchanging calendaring and scheduling information across the - Internet. - - This memo is formatted as a registration for a MIME media type per - [RFC 2048]. However, the format in this memo is equally applicable - for use outside of a MIME message content type. - - The proposed media type value is 'text/calendar'. This string would - label a media type containing calendaring and scheduling information - encoded as text characters formatted in a manner outlined below. - - This MIME media type provides a standard content type for capturing - calendar event, to-do and journal entry information. It also can be - used to convey free/busy time information. The content type is - suitable as a MIME message entity that can be transferred over MIME - based email systems, using HTTP or some other Internet transport. In - - - - - - -Dawson & Stenerson Standards Track [Page 1] - -RFC 2445 iCalendar November 1998 - - - addition, the content type is useful as an object for interactions - between desktop applications using the operating system clipboard, - drag/drop or file systems capabilities. - - This memo is based on the earlier work of the vCalendar specification - for the exchange of personal calendaring and scheduling information. - In order to avoid confusion with this referenced work, this memo is - to be known as the iCalendar specification. - - This memo defines the format for specifying iCalendar object methods. - An iCalendar object method is a set of usage constraints for the - iCalendar object. For example, these methods might define scheduling - messages that request an event be scheduled, reply to an event - request, send a cancellation notice for an event, modify or replace - the definition of an event, provide a counter proposal for an - original event request, delegate an event request to another - individual, request free or busy time, reply to a free or busy time - request, or provide similar scheduling messages for a to-do or - journal entry calendar component. The iCalendar Transport-indendent - Interoperability Protocol (iTIP) defined in [ITIP] is one such - scheduling protocol. - -Table of Contents - - 1 Introduction.....................................................5 - 2 Basic Grammar and Conventions....................................6 - 2.1 Formatting Conventions .......................................7 - 2.2 Related Memos ................................................8 - 2.3 International Considerations .................................8 - 3 Registration Information.........................................8 - 3.1 Content Type .................................................8 - 3.2 Parameters ...................................................9 - 3.3 Content Header Fields .......................................10 - 3.4 Encoding Considerations .....................................10 - 3.5 Security Considerations .....................................10 - 3.6 Interoperability Considerations .............................11 - 3.7 Applications Which Use This Media Type ......................11 - 3.8 Additional Information ......................................11 - 3.9 Magic Numbers ...............................................11 - 3.10 File Extensions ............................................11 - 3.11 Contact for Further Information: ...........................12 - 3.12 Intended Usage .............................................12 - 3.13 Authors/Change Controllers .................................12 - 4 iCalendar Object Specification..................................13 - 4.1 Content Lines ...............................................13 - 4.1.1 List and Field Separators ................................16 - 4.1.2 Multiple Values ..........................................16 - 4.1.3 Binary Content ...........................................16 - - - -Dawson & Stenerson Standards Track [Page 2] - -RFC 2445 iCalendar November 1998 - - - 4.1.4 Character Set ............................................17 - 4.2 Property Parameters .........................................17 - 4.2.1 Alternate Text Representation ............................18 - 4.2.2 Common Name ..............................................19 - 4.2.3 Calendar User Type .......................................20 - 4.2.4 Delegators ...............................................20 - 4.2.5 Delegatees ...............................................21 - 4.2.6 Directory Entry Reference ................................21 - 4.2.7 Inline Encoding ..........................................22 - 4.2.8 Format Type ..............................................23 - 4.2.9 Free/Busy Time Type ......................................23 - 4.2.10 Language ................................................24 - 4.2.11 Group or List Membership ................................25 - 4.2.12 Participation Status ....................................25 - 4.2.13 Recurrence Identifier Range .............................27 - 4.2.14 Alarm Trigger Relationship ..............................27 - 4.2.15 Relationship Type .......................................28 - 4.2.16 Participation Role ......................................29 - 4.2.17 RSVP Expectation ........................................29 - 4.2.18 Sent By .................................................30 - 4.2.19 Time Zone Identifier ....................................30 - 4.2.20 Value Data Types ........................................32 - 4.3 Property Value Data Types ...................................32 - 4.3.1 Binary ...................................................33 - 4.3.2 Boolean ..................................................33 - 4.3.3 Calendar User Address ....................................34 - 4.3.4 Date .....................................................34 - 4.3.5 Date-Time ................................................35 - 4.3.6 Duration .................................................37 - 4.3.7 Float ....................................................38 - 4.3.8 Integer ..................................................38 - 4.3.9 Period of Time ...........................................39 - 4.3.10 Recurrence Rule .........................................40 - 4.3.11 Text ....................................................45 - 4.3.12 Time ....................................................47 - 4.3.13 URI .....................................................49 - 4.3.14 UTC Offset ..............................................49 - 4.4 iCalendar Object ............................................50 - 4.5 Property ....................................................51 - 4.6 Calendar Components .........................................51 - 4.6.1 Event Component ..........................................52 - 4.6.2 To-do Component ..........................................55 - 4.6.3 Journal Component ........................................56 - 4.6.4 Free/Busy Component ......................................58 - 4.6.5 Time Zone Component ......................................60 - 4.6.6 Alarm Component ..........................................67 - 4.7 Calendar Properties .........................................73 - 4.7.1 Calendar Scale ...........................................73 - - - -Dawson & Stenerson Standards Track [Page 3] - -RFC 2445 iCalendar November 1998 - - - 4.7.2 Method ...................................................74 - 4.7.3 Product Identifier .......................................75 - 4.7.4 Version ..................................................76 - 4.8 Component Properties ........................................77 - 4.8.1 Descriptive Component Properties .........................77 - 4.8.1.1 Attachment ...........................................77 - 4.8.1.2 Categories ...........................................78 - 4.8.1.3 Classification .......................................79 - 4.8.1.4 Comment ..............................................80 - 4.8.1.5 Description ..........................................81 - 4.8.1.6 Geographic Position ..................................82 - 4.8.1.7 Location .............................................84 - 4.8.1.8 Percent Complete .....................................85 - 4.8.1.9 Priority .............................................85 - 4.8.1.10 Resources ...........................................87 - 4.8.1.11 Status ..............................................88 - 4.8.1.12 Summary .............................................89 - 4.8.2 Date and Time Component Properties .......................90 - 4.8.2.1 Date/Time Completed ..................................90 - 4.8.2.2 Date/Time End ........................................91 - 4.8.2.3 Date/Time Due ........................................92 - 4.8.2.4 Date/Time Start ......................................93 - 4.8.2.5 Duration .............................................94 - 4.8.2.6 Free/Busy Time .......................................95 - 4.8.2.7 Time Transparency ....................................96 - 4.8.3 Time Zone Component Properties ...........................97 - 4.8.3.1 Time Zone Identifier .................................97 - 4.8.3.2 Time Zone Name .......................................98 - 4.8.3.3 Time Zone Offset From ................................99 - 4.8.3.4 Time Zone Offset To .................................100 - 4.8.3.5 Time Zone URL .......................................101 - 4.8.4 Relationship Component Properties .......................102 - 4.8.4.1 Attendee ............................................102 - 4.8.4.2 Contact .............................................104 - 4.8.4.3 Organizer ...........................................106 - 4.8.4.4 Recurrence ID .......................................107 - 4.8.4.5 Related To ..........................................109 - 4.8.4.6 Uniform Resource Locator ............................110 - 4.8.4.7 Unique Identifier ...................................111 - 4.8.5 Recurrence Component Properties .........................112 - 4.8.5.1 Exception Date/Times ................................112 - 4.8.5.2 Exception Rule ......................................114 - 4.8.5.3 Recurrence Date/Times ...............................115 - 4.8.5.4 Recurrence Rule .....................................117 - 4.8.6 Alarm Component Properties ..............................126 - 4.8.6.1 Action ..............................................126 - 4.8.6.2 Repeat Count ........................................126 - 4.8.6.3 Trigger .............................................127 - - - -Dawson & Stenerson Standards Track [Page 4] - -RFC 2445 iCalendar November 1998 - - - 4.8.7 Change Management Component Properties ..................129 - 4.8.7.1 Date/Time Created ...................................129 - 4.8.7.2 Date/Time Stamp .....................................130 - 4.8.7.3 Last Modified .......................................131 - 4.8.7.4 Sequence Number .....................................131 - 4.8.8 Miscellaneous Component Properties ......................133 - 4.8.8.1 Non-standard Properties .............................133 - 4.8.8.2 Request Status ......................................134 - 5 iCalendar Object Examples......................................136 - 6 Recommended Practices..........................................140 - 7 Registration of Content Type Elements..........................141 - 7.1 Registration of New and Modified iCalendar Object Methods ..141 - 7.2 Registration of New Properties .............................141 - 7.2.1 Define the property .....................................142 - 7.2.2 Post the Property definition ............................143 - 7.2.3 Allow a comment period ..................................143 - 7.2.4 Submit the property for approval ........................143 - 7.3 Property Change Control ....................................143 - 8 References.....................................................144 - 9 Acknowledgments................................................145 - 10 Authors' and Chairs' Addresses................................146 - 11 Full Copyright Statement......................................148 - -1 Introduction - - The use of calendaring and scheduling has grown considerably in the - last decade. Enterprise and inter-enterprise business has become - dependent on rapid scheduling of events and actions using this - information technology. However, the longer term growth of - calendaring and scheduling, is currently limited by the lack of - Internet standards for the message content types that are central to - these knowledgeware applications. This memo is intended to progress - the level of interoperability possible between dissimilar calendaring - and scheduling applications. This memo defines a MIME content type - for exchanging electronic calendaring and scheduling information. The - Internet Calendaring and Scheduling Core Object Specification, or - iCalendar, allows for the capture and exchange of information - normally stored within a calendaring and scheduling application; such - as a Personal Information Manager (PIM) or a Group Scheduling - product. - - The iCalendar format is suitable as an exchange format between - applications or systems. The format is defined in terms of a MIME - content type. This will enable the object to be exchanged using - several transports, including but not limited to SMTP, HTTP, a file - system, desktop interactive protocols such as the use of a memory- - based clipboard or drag/drop interactions, point-to-point - asynchronous communication, wired-network transport, or some form of - - - -Dawson & Stenerson Standards Track [Page 5] - -RFC 2445 iCalendar November 1998 - - - unwired transport such as infrared might also be used. - - The memo also provides for the definition of iCalendar object methods - that will map this content type to a set of messages for supporting - calendaring and scheduling operations such as requesting, replying - to, modifying, and canceling meetings or appointments, to-dos and - journal entries. The iCalendar object methods can be used to define - other calendaring and scheduling operations such a requesting for and - replying with free/busy time data. Such a scheduling protocol is - defined in the iCalendar Transport-independent Interoperability - Protocol (iTIP) defined in [ITIP]. - - The memo also includes a formal grammar for the content type based on - the Internet ABNF defined in [RFC 2234]. This ABNF is required for - the implementation of parsers and to serve as the definitive - reference when ambiguities or questions arise in interpreting the - descriptive prose definition of the memo. - -2 Basic Grammar and Conventions - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" and - "OPTIONAL" in this document are to be interoperated as described in - [RFC 2119]. - - This memo makes use of both a descriptive prose and a more formal - notation for defining the calendaring and scheduling format. - - The notation used in this memo is the ABNF notation of [RFC 2234]. - Readers intending on implementing this format defined in this memo - should be familiar with this notation in order to properly interpret - the specifications of this memo. - - All numeric and hexadecimal values used in this memo are given in - decimal notation. - - All names of properties, property parameters, enumerated property - values and property parameter values are case-insensitive. However, - all other property values are case-sensitive, unless otherwise - stated. - - Note: All indented editorial notes, such as this one, are - intended to provide the reader with additional information. The - information is not essential to the building of an - implementation conformant with this memo. The information is - provided to highlight a particular feature or characteristic of - the memo. - - - - -Dawson & Stenerson Standards Track [Page 6] - -RFC 2445 iCalendar November 1998 - - - The format for the iCalendar object is based on the syntax of the - [RFC 2425] content type. While the iCalendar object is not a profile - of the [RFC 2425] content type, it does reuse a number of the - elements from the [RFC 2425] specification. - -2.1 Formatting Conventions - - The mechanisms defined in this memo are defined in prose. Many of the - terms used to describe these have common usage that is different than - the standards usage of this memo. In order to reference within this - memo elements of the calendaring and scheduling model, core object - (this memo) or interoperability protocol [ITIP] some formatting - conventions have been used. Calendaring and scheduling roles are - referred to in quoted-strings of text with the first character of - each word in upper case. For example, "Organizer" refers to a role of - a "Calendar User" within the scheduling protocol defined by [ITIP]. - Calendar components defined by this memo are referred to with - capitalized, quoted-strings of text. All calendar components start - with the letter "V". For example, "VEVENT" refers to the event - calendar component, "VTODO" refers to the to-do calendar component - and "VJOURNAL" refers to the daily journal calendar component. - Scheduling methods defined by [ITIP] are referred to with - capitalized, quoted-strings of text. For example, "REQUEST" refers to - the method for requesting a scheduling calendar component be created - or modified, "REPLY" refers to the method a recipient of a request - uses to update their status with the "Organizer" of the calendar - component. - - The properties defined by this memo are referred to with capitalized, - quoted-strings of text, followed by the word "property". For example, - "ATTENDEE" property refers to the iCalendar property used to convey - the calendar address of a calendar user. Property parameters defined - by this memo are referred to with lowercase, quoted-strings of text, - followed by the word "parameter". For example, "value" parameter - refers to the iCalendar property parameter used to override the - default data type for a property value. Enumerated values defined by - this memo are referred to with capitalized text, either alone or - followed by the word "value". For example, the "MINUTELY" value can - be used with the "FREQ" component of the "RECUR" data type to specify - repeating components based on an interval of one minute or more. - - - - - - - - - - - -Dawson & Stenerson Standards Track [Page 7] - -RFC 2445 iCalendar November 1998 - - -2.2 Related Memos - - Implementers will need to be familiar with several other memos that, - along with this memo, form a framework for Internet calendaring and - scheduling standards. This memo, [ICAL], specifies a core - specification of objects, data types, properties and property - parameters. - - [ITIP] - specifies an interoperability protocol for scheduling - between different implementations; - - [IMIP] specifies an Internet email binding for [ITIP]. - - This memo does not attempt to repeat the specification of concepts or - definitions from these other memos. Where possible, references are - made to the memo that provides for the specification of these - concepts or definitions. - -2.3 International Considerations - - In the rest of this document, descriptions of characters are of the - form "character name (codepoint)", where "codepoint" is from the US- - ASCII character set. The "character name" is the authoritative - description; (codepoint) is a reference to that character in US-ASCII - or US-ASCII compatible sets (for example the ISO-8859-x family, UTF- - 8, ISO-2022-xx, KOI8-R). If a non-US-ASCII compatible character set - is used, appropriate code-point from that character set MUST be - chosen instead. Use of non-US-ASCII-compatible character sets is NOT - recommended. - -3 Registration Information - - The Calendaring and Scheduling Core Object Specification is intended - for use as a MIME content type. However, the implementation of the - memo is in no way limited solely as a MIME content type. - -3.1 Content Type - - The following text is intended to register this memo as the MIME - content type "text/calendar". - - To: ietf-types@uninett.no - - Subject: Registration of MIME content type text/calendar. - - MIME media type name: text - - MIME subtype name: calendar - - - -Dawson & Stenerson Standards Track [Page 8] - -RFC 2445 iCalendar November 1998 - - -3.2 Parameters - - Required parameters: none - - Optional parameters: charset, method, component and optinfo - - The "charset" parameter is defined in [RFC 2046] for other body - parts. It is used to identify the default character set used within - the body part. - - The "method" parameter is used to convey the iCalendar object method - or transaction semantics for the calendaring and scheduling - information. It also is an identifier for the restricted set of - properties and values that the iCalendar object consists of. The - parameter is to be used as a guide for applications interpreting the - information contained within the body part. It SHOULD NOT be used to - exclude or require particular pieces of information unless the - identified method definition specifically calls for this behavior. - Unless specifically forbidden by a particular method definition, a - text/calendar content type can contain any set of properties - permitted by the Calendaring and Scheduling Core Object - Specification. The "method" parameter MUST be the same value as that - specified in the "METHOD" component property in the iCalendar object. - If one is present, the other MUST also be present. - - The value for the "method" parameter is defined as follows: - - method = 1*(ALPHA / DIGIT / "-") - ; IANA registered iCalendar object method - - The "component" parameter conveys the type of iCalendar calendar - component within the body part. If the iCalendar object contains more - than one calendar component type, then multiple component parameters - MUST be specified. - - The value for the "component" parameter is defined as follows: - - component = ("VEVENT" / "VTODO" / "VJOURNAL" / "VFREEBUSY" - / "VTIMEZONE" / x-name / iana-token) - - The "optinfo" parameter conveys optional information about the - iCalendar object within the body part. This parameter can only - specify semantics already specified by the iCalendar object and that - can be otherwise determined by parsing the body part. In addition, - the optional information specified by this parameter MUST be - consistent with that information specified by the iCalendar object. - For example, it can be used to convey the "Attendee" response status - to a meeting request. The parameter value consists of a string value. - - - -Dawson & Stenerson Standards Track [Page 9] - -RFC 2445 iCalendar November 1998 - - - The parameter can be specified multiple times. - - This parameter MAY only specify semantics already specified by the - iCalendar object and that can be otherwise determined by parsing the - body part. - - The value for the "optinfo" parameter is defined as follows: - - optinfo = infovalue / qinfovalue - - infovalue = iana-token / x-name - - qinfovalue = DQUOTE (infovalue) DQUOTE - -3.3 Content Header Fields - - Optional content header fields: Any header fields defined by [RFC - 2045]. - -3.4 Encoding Considerations - - This MIME content type can contain 8bit characters, so the use of - quoted-printable or BASE64 MIME content-transfer-encodings might be - necessary when iCalendar objects are transferred across protocols - restricted to the 7bit repertoire. Note that a text valued property - in the content entity can also have content encoding of special - characters using a BACKSLASH character (US-ASCII decimal 92) - escapement technique. This means that content values can end up - encoded twice. - -3.5 Security Considerations - - SPOOFING - - In this memo, the "Organizer" is the only person - authorized to make changes to an existing "VEVENT", "VTODO", - "VJOURNAL" calendar component and redistribute the updates to the - "Attendees". An iCalendar object that maliciously changes or cancels - an existing "VEVENT", "VTODO" or "VJOURNAL" or "VFREEBUSY" calendar - component might be constructed by someone other than the "Organizer" - and sent to the "Attendees". In addition in this memo, other than the - "Organizer", an "Attendee" of a "VEVENT", "VTODO", "VJOURNAL" - calendar component is the only other person authorized to update any - parameter associated with their "ATTENDEE" property and send it to - the "Organizer". An iCalendar object that maliciously changes the - "ATTENDEE" parameters can be constructed by someone other than the - real "Attendee" and sent to the "Organizer". - - - - - - -Dawson & Stenerson Standards Track [Page 10] - -RFC 2445 iCalendar November 1998 - - - PROCEDURAL ALARMS - - An iCalendar object can be created that - contains a "VEVENT" and "VTODO" calendar component with "VALARM" - calendar components. The "VALARM" calendar component can be of type - PROCEDURE and can have an attachment containing some sort of - executable program. Implementations that incorporate these types of - alarms are subject to any virus or malicious attack that might occur - as a result of executing the attachment. - - ATTACHMENTS - - An iCalendar object can include references to Uniform - Resource Locators that can be programmed resources. - - Implementers and users of this memo should be aware of the network - security implications of accepting and parsing such information. In - addition, the security considerations observed by implementations of - electronic mail systems should be followed for this memo. - -3.6 Interoperability Considerations - - This MIME content type is intended to define a common format for - conveying calendaring and scheduling information between different - systems. It is heavily based on the earlier [VCAL] industry - specification. - -3.7 Applications Which Use This Media Type - - This content-type is designed for widespread use by Internet - calendaring and scheduling applications. In addition, applications in - the workflow and document management area might find this content- - type applicable. The [ITIP] and [IMIP] Internet protocols directly - use this content-type also. Future work on an Internet calendar - access protocol will utilize this content-type too. - -3.8 Additional Information - - This memo defines this content-type. - -3.9 Magic Numbers - - None. - -3.10 File Extensions - - The file extension of "ics" is to be used to designate a file - containing (an arbitrary set of) calendaring and scheduling - information consistent with this MIME content type. - - - - - - -Dawson & Stenerson Standards Track [Page 11] - -RFC 2445 iCalendar November 1998 - - - The file extension of "ifb" is to be used to designate a file - containing free or busy time information consistent with this MIME - content type. - - Macintosh file type codes: The file type code of "iCal" is to be used - in Apple MacIntosh operating system environments to designate a file - containing calendaring and scheduling information consistent with - this MIME media type. - - The file type code of "iFBf" is to be used in Apple MacIntosh - operating system environments to designate a file containing free or - busy time information consistent with this MIME media type. - -3.11 Contact for Further Information: - - Frank Dawson - 6544 Battleford Drive - Raleigh, NC 27613-3502 - 919-676-9515 (Telephone) - 919-676-9564 (Data/Facsimile) - Frank_Dawson@Lotus.com (Internet Mail) - - Derik Stenerson - One Microsoft Way - Redmond, WA 98052-6399 - 425-936-5522 (Telephone) - 425-936-7329 (Facsimile) - deriks@microsoft.com (Internet Mail) - -3.12 Intended Usage - - COMMON - -3.13 Authors/Change Controllers - - Frank Dawson - 6544 Battleford Drive - Raleigh, NC 27613-3502 - 919-676-9515 (Telephone) - 919-676-9564 (Data/Facsimile) - Frank_Dawson@Lotus.com (Internet Mail) - - Derik Stenerson - One Microsoft Way - Redmond, WA 98052-6399 - 425-936-5522 (Telephone) - 425-936-7329 (Facsimile) - deriks@microsoft.com (Internet Mail) - - - -Dawson & Stenerson Standards Track [Page 12] - -RFC 2445 iCalendar November 1998 - - -4 iCalendar Object Specification - - The following sections define the details of a Calendaring and - Scheduling Core Object Specification. This information is intended to - be an integral part of the MIME content type registration. In - addition, this information can be used independent of such content - registration. In particular, this memo has direct applicability for - use as a calendaring and scheduling exchange format in file-, memory- - or network-based transport mechanisms. - -4.1 Content Lines - - The iCalendar object is organized into individual lines of text, - called content lines. Content lines are delimited by a line break, - which is a CRLF sequence (US-ASCII decimal 13, followed by US-ASCII - decimal 10). - - Lines of text SHOULD NOT be longer than 75 octets, excluding the line - break. Long content lines SHOULD be split into a multiple line - representations using a line "folding" technique. That is, a long - line can be split between any two characters by inserting a CRLF - immediately followed by a single linear white space character (i.e., - SPACE, US-ASCII decimal 32 or HTAB, US-ASCII decimal 9). Any sequence - of CRLF followed immediately by a single linear white space character - is ignored (i.e., removed) when processing the content type. - - For example the line: - - DESCRIPTION:This is a long description that exists on a long line. - - Can be represented as: - - DESCRIPTION:This is a lo - ng description - that exists on a long line. - - The process of moving from this folded multiple line representation - to its single line representation is called "unfolding". Unfolding is - accomplished by removing the CRLF character and the linear white - space character that immediately follows. - - When parsing a content line, folded lines MUST first be unfolded - according to the unfolding procedure described above. When generating - a content line, lines longer than 75 octets SHOULD be folded - according to the folding procedure described above. - - - - - - -Dawson & Stenerson Standards Track [Page 13] - -RFC 2445 iCalendar November 1998 - - - The content information associated with an iCalendar object is - formatted using a syntax similar to that defined by [RFC 2425]. That - is, the content information consists of CRLF-separated content lines. - - The following notation defines the lines of content in an iCalendar - object: - - contentline = name *(";" param ) ":" value CRLF - ; This ABNF is just a general definition for an initial parsing - ; of the content line into its property name, parameter list, - ; and value string - - ; When parsing a content line, folded lines MUST first - ; be unfolded according to the unfolding procedure - ; described above. When generating a content line, lines - ; longer than 75 octets SHOULD be folded according to - ; the folding procedure described above. - - name = x-name / iana-token - - iana-token = 1*(ALPHA / DIGIT / "-") - ; iCalendar identifier registered with IANA - - x-name = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-") - ; Reservered for experimental use. Not intended for use in - ; released products. - - vendorid = 3*(ALPHA / DIGIT) ;Vendor identification - - param = param-name "=" param-value - *("," param-value) - ; Each property defines the specific ABNF for the parameters - ; allowed on the property. Refer to specific properties for - ; precise parameter ABNF. - - param-name = iana-token / x-token - - param-value = paramtext / quoted-string - - paramtext = *SAFE-CHAR - - value = *VALUE-CHAR - - quoted-string = DQUOTE *QSAFE-CHAR DQUOTE - - NON-US-ASCII = %x80-F8 - ; Use restricted by charset parameter - ; on outer MIME object (UTF-8 preferred) - - - -Dawson & Stenerson Standards Track [Page 14] - -RFC 2445 iCalendar November 1998 - - - QSAFE-CHAR = WSP / %x21 / %x23-7E / NON-US-ASCII - ; Any character except CTLs and DQUOTE - - SAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E - / NON-US-ASCII - ; Any character except CTLs, DQUOTE, ";", ":", "," - - VALUE-CHAR = WSP / %x21-7E / NON-US-ASCII - ; Any textual character - - CR = %x0D - ; carriage return - - LF = %x0A - ; line feed - - CRLF = CR LF - ; Internet standard newline - - CTL = %x00-08 / %x0A-1F / %x7F - ; Controls - - ALPHA = %x41-5A / %x61-7A ; A-Z / a-z - - DIGIT = %x30-39 - ; 0-9 - - DQUOTE = %x22 - ; Quotation Mark - - WSP = SPACE / HTAB - - SPACE = %x20 - - HTAB = %x09 - - The property value component of a content line has a format that is - property specific. Refer to the section describing each property for - a definition of this format. - - All names of properties, property parameters, enumerated property - values and property parameter values are case-insensitive. However, - all other property values are case-sensitive, unless otherwise - stated. - - - - - - - -Dawson & Stenerson Standards Track [Page 15] - -RFC 2445 iCalendar November 1998 - - -4.1.1 List and Field Separators - - Some properties and parameters allow a list of values. Values in a - list of values MUST be separated by a COMMA character (US-ASCII - decimal 44). There is no significance to the order of values in a - list. For those parameter values (such as those that specify URI - values) that are specified in quoted-strings, the individual quoted- - strings are separated by a COMMA character (US-ASCII decimal 44). - - Some property values are defined in terms of multiple parts. These - structured property values MUST have their value parts separated by a - SEMICOLON character (US-ASCII decimal 59). - - Some properties allow a list of parameters. Each property parameter - in a list of property parameters MUST be separated by a SEMICOLON - character (US-ASCII decimal 59). - - Property parameters with values containing a COLON, a SEMICOLON or a - COMMA character MUST be placed in quoted text. - - For example, in the following properties a SEMICOLON is used to - separate property parameters from each other, and a COMMA is used to - separate property values in a value list. - - ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT:MAILTO: - jsmith@host.com - - RDATE;VALUE=DATE:19970304,19970504,19970704,19970904 - -4.1.2 Multiple Values - - Some properties defined in the iCalendar object can have multiple - values. The general rule for encoding multi-valued items is to simply - create a new content line for each value, including the property - name. However, it should be noted that some properties support - encoding multiple values in a single property by separating the - values with a COMMA character (US-ASCII decimal 44). Individual - property definitions should be consulted for determining whether a - specific property allows multiple values and in which of these two - forms. - -4.1.3 Binary Content - - Binary content information in an iCalendar object SHOULD be - referenced using a URI within a property value. That is the binary - content information SHOULD be placed in an external MIME entity that - can be referenced by a URI from within the iCalendar object. In - applications where this is not feasible, binary content information - - - -Dawson & Stenerson Standards Track [Page 16] - -RFC 2445 iCalendar November 1998 - - - can be included within an iCalendar object, but only after first - encoding it into text using the "BASE64" encoding method defined in - [RFC 2045]. Inline binary contact SHOULD only be used in applications - whose special circumstances demand that an iCalendar object be - expressed as a single entity. A property containing inline binary - content information MUST specify the "ENCODING" property parameter. - Binary content information placed external to the iCalendar object - MUST be referenced by a uniform resource identifier (URI). - - The following example specifies an "ATTACH" property that references - an attachment external to the iCalendar object with a URI reference: - - ATTACH:http://xyz.com/public/quarterly-report.doc - - The following example specifies an "ATTACH" property with inline - binary encoded content information: - - ATTACH;FMTTYPE=image/basic;ENCODING=BASE64;VALUE=BINARY: - MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1U - EBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIE - <...remainder of "BASE64" encoded binary data...> - -4.1.4 Character Set - - There is not a property parameter to declare the character set used - in a property value. The default character set for an iCalendar - object is UTF-8 as defined in [RFC 2279]. - - The "charset" Content-Type parameter can be used in MIME transports - to specify any other IANA registered character set. - -4.2 Property Parameters - - A property can have attributes associated with it. These "property - parameters" contain meta-information about the property or the - property value. Property parameters are provided to specify such - information as the location of an alternate text representation for a - property value, the language of a text property value, the data type - of the property value and other attributes. - - Property parameter values that contain the COLON (US-ASCII decimal - 58), SEMICOLON (US-ASCII decimal 59) or COMMA (US-ASCII decimal 44) - character separators MUST be specified as quoted-string text values. - Property parameter values MUST NOT contain the DOUBLE-QUOTE (US-ASCII - decimal 22) character. The DOUBLE-QUOTE (US-ASCII decimal 22) - character is used as a delimiter for parameter values that contain - restricted characters or URI text. For example: - - - - -Dawson & Stenerson Standards Track [Page 17] - -RFC 2445 iCalendar November 1998 - - - DESCRIPTION;ALTREP="http://www.wiz.org":The Fall'98 Wild Wizards - Conference - - Las Vegas, NV, USA - - Property parameter values that are not in quoted strings are case - insensitive. - - The general property parameters defined by this memo are defined by - the following notation: - - parameter = altrepparam ; Alternate text representation - / cnparam ; Common name - / cutypeparam ; Calendar user type - / delfromparam ; Delegator - / deltoparam ; Delegatee - / dirparam ; Directory entry - / encodingparam ; Inline encoding - / fmttypeparam ; Format type - / fbtypeparam ; Free/busy time type - / languageparam ; Language for text - / memberparam ; Group or list membership - / partstatparam ; Participation status - / rangeparam ; Recurrence identifier range - / trigrelparam ; Alarm trigger relationship - / reltypeparam ; Relationship type - / roleparam ; Participation role - / rsvpparam ; RSVP expectation - / sentbyparam ; Sent by - / tzidparam ; Reference to time zone object - / valuetypeparam ; Property value data type - / ianaparam - ; Some other IANA registered iCalendar parameter. - / xparam - ; A non-standard, experimental parameter. - - ianaparam = iana-token "=" param-value *("," param-value) - - xparam =x-name "=" param-value *("," param-value) - -4.2.1 Alternate Text Representation - - Parameter Name: ALTREP - - Purpose: To specify an alternate text representation for the property - value. - - Format Definition: The property parameter is defined by the following - notation: - - - - -Dawson & Stenerson Standards Track [Page 18] - -RFC 2445 iCalendar November 1998 - - - altrepparam = "ALTREP" "=" DQUOTE uri DQUOTE - - Description: The parameter specifies a URI that points to an - alternate representation for a textual property value. A property - specifying this parameter MUST also include a value that reflects the - default representation of the text value. The individual URI - parameter values MUST each be specified in a quoted-string. - - Example: - - DESCRIPTION;ALTREP="CID:":Project - XYZ Review Meeting will include the following agenda items: (a) - Market Overview, (b) Finances, (c) Project Management - - The "ALTREP" property parameter value might point to a "text/html" - content portion. - - Content-Type:text/html - Content-Id: - - -

Project XYZ Review Meeting will include the following - agenda items:

  1. Market - Overview
  2. Finances
  3. Project Management

- - -4.2.2 Common Name - - Parameter Name: CN - - Purpose: To specify the common name to be associated with the - calendar user specified by the property. - - Format Definition: The property parameter is defined by the following - notation: - - cnparam = "CN" "=" param-value - - Description: This parameter can be specified on properties with a - CAL-ADDRESS value type. The parameter specifies the common name to be - associated with the calendar user specified by the property. The - parameter value is text. The parameter value can be used for display - text to be associated with the calendar address specified by the - property. - - - - - - - -Dawson & Stenerson Standards Track [Page 19] - -RFC 2445 iCalendar November 1998 - - - Example: - - ORGANIZER;CN="John Smith":MAILTO:jsmith@host.com - -4.2.3 Calendar User Type - - Parameter Name: CUTYPE - - Purpose: To specify the type of calendar user specified by the - property. - - Format Definition: The property parameter is defined by the following - notation: - - cutypeparam = "CUTYPE" "=" - ("INDIVIDUAL" ; An individual - / "GROUP" ; A group of individuals - / "RESOURCE" ; A physical resource - / "ROOM" ; A room resource - / "UNKNOWN" ; Otherwise not known - / x-name ; Experimental type - / iana-token) ; Other IANA registered - ; type - ; Default is INDIVIDUAL - - Description: This parameter can be specified on properties with a - CAL-ADDRESS value type. The parameter identifies the type of calendar - user specified by the property. If not specified on a property that - allows this parameter, the default is INDIVIDUAL. - - Example: - - ATTENDEE;CUTYPE=GROUP:MAILTO:ietf-calsch@imc.org - -4.2.4 Delegators - - Parameter Name: DELEGATED-FROM - - Purpose: To specify the calendar users that have delegated their - participation to the calendar user specified by the property. - - Format Definition: The property parameter is defined by the following - notation: - - delfromparam = "DELEGATED-FROM" "=" DQUOTE cal-address DQUOTE - *("," DQUOTE cal-address DQUOTE) - - - - - -Dawson & Stenerson Standards Track [Page 20] - -RFC 2445 iCalendar November 1998 - - - Description: This parameter can be specified on properties with a - CAL-ADDRESS value type. This parameter can be specified on a property - that has a value type of calendar address. This parameter specifies - those calendar uses that have delegated their participation in a - group scheduled event or to-do to the calendar user specified by the - property. The value MUST be a MAILTO URI as defined in [RFC 1738]. - The individual calendar address parameter values MUST each be - specified in a quoted-string. - - Example: - - ATTENDEE;DELEGATED-FROM="MAILTO:jsmith@host.com":MAILTO: - jdoe@host.com - -4.2.5 Delegatees - - Parameter Name: DELEGATED-TO - - Purpose: To specify the calendar users to whom the calendar user - specified by the property has delegated participation. - - Format Definition: The property parameter is defined by the following - notation: - - deltoparam = "DELEGATED-TO" "=" DQUOTE cal-address DQUOTE - *("," DQUOTE cal-address DQUOTE) - - Description: This parameter can be specified on properties with a - CAL-ADDRESS value type. This parameter specifies those calendar users - whom have been delegated participation in a group scheduled event or - to-do by the calendar user specified by the property. The value MUST - be a MAILTO URI as defined in [RFC 1738]. The individual calendar - address parameter values MUST each be specified in a quoted-string. - - Example: - - ATTENDEE;DELEGATED-TO="MAILTO:jdoe@host.com","MAILTO:jqpublic@ - host.com":MAILTO:jsmith@host.com - -4.2.6 Directory Entry Reference - - Parameter Name: DIR - - Purpose: To specify reference to a directory entry associated with - the calendar user specified by the property. - - Format Definition: The property parameter is defined by the following - notation: - - - -Dawson & Stenerson Standards Track [Page 21] - -RFC 2445 iCalendar November 1998 - - - dirparam = "DIR" "=" DQUOTE uri DQUOTE - - Description: This parameter can be specified on properties with a - CAL-ADDRESS value type. The parameter specifies a reference to the - directory entry associated with the calendar user specified by the - property. The parameter value is a URI. The individual URI parameter - values MUST each be specified in a quoted-string. - - Example: - - ORGANIZER;DIR="ldap://host.com:6666/o=eDABC%20Industries,c=3DUS?? - (cn=3DBJim%20Dolittle)":MAILTO:jimdo@host1.com - -4.2.7 Inline Encoding - - Parameter Name: ENCODING - - Purpose: To specify an alternate inline encoding for the property - value. - - Format Definition: The property parameter is defined by the following - notation: - - encodingparam = "ENCODING" "=" - ("8BIT" - ; "8bit" text encoding is defined in [RFC 2045] - / "BASE64" - ; "BASE64" binary encoding format is defined in [RFC 2045] - / iana-token - ; Some other IANA registered iCalendar encoding type - / x-name) - ; A non-standard, experimental encoding type - - Description: The property parameter identifies the inline encoding - used in a property value. The default encoding is "8BIT", - corresponding to a property value consisting of text. The "BASE64" - encoding type corresponds to a property value encoded using the - "BASE64" encoding defined in [RFC 2045]. - - If the value type parameter is ";VALUE=BINARY", then the inline - encoding parameter MUST be specified with the value - ";ENCODING=BASE64". - - - - - - - - - -Dawson & Stenerson Standards Track [Page 22] - -RFC 2445 iCalendar November 1998 - - - Example: - - ATTACH;FMTYPE=IMAGE/JPEG;ENCODING=BASE64;VALUE=BINARY:MIICajC - CAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDA - qBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMRw - <...remainder of "BASE64" encoded binary data...> - -4.2.8 Format Type - - Parameter Name: FMTTYPE - - Purpose: To specify the content type of a referenced object. - - Format Definition: The property parameter is defined by the following - notation: - - fmttypeparam = "FMTTYPE" "=" iana-token - ; A IANA registered content type - / x-name - ; A non-standard content type - - Description: This parameter can be specified on properties that are - used to reference an object. The parameter specifies the content type - of the referenced object. For example, on the "ATTACH" property, a - FTP type URI value does not, by itself, necessarily convey the type - of content associated with the resource. The parameter value MUST be - the TEXT for either an IANA registered content type or a non-standard - content type. - - Example: - - ATTACH;FMTTYPE=application/binary:ftp://domain.com/pub/docs/ - agenda.doc - -4.2.9 Free/Busy Time Type - - Parameter Name: FBTYPE - - Purpose: To specify the free or busy time type. - - Format Definition: The property parameter is defined by the following - notation: - - fbtypeparam = "FBTYPE" "=" ("FREE" / "BUSY" - / "BUSY-UNAVAILABLE" / "BUSY-TENTATIVE" - / x-name - ; Some experimental iCalendar data type. - / iana-token) - - - -Dawson & Stenerson Standards Track [Page 23] - -RFC 2445 iCalendar November 1998 - - - ; Some other IANA registered iCalendar data type. - - Description: The parameter specifies the free or busy time type. The - value FREE indicates that the time interval is free for scheduling. - The value BUSY indicates that the time interval is busy because one - or more events have been scheduled for that interval. The value - BUSY-UNAVAILABLE indicates that the time interval is busy and that - the interval can not be scheduled. The value BUSY-TENTATIVE indicates - that the time interval is busy because one or more events have been - tentatively scheduled for that interval. If not specified on a - property that allows this parameter, the default is BUSY. - - Example: The following is an example of this parameter on a FREEBUSY - property. - - FREEBUSY;FBTYPE=BUSY:19980415T133000Z/19980415T170000Z - -4.2.10 Language - - Parameter Name: LANGUAGE - - Purpose: To specify the language for text values in a property or - property parameter. - - Format Definition: The property parameter is defined by the following - notation: - - languageparam = "LANGUAGE" "=" language - - language = - - Description: This parameter can be specified on properties with a - text value type. The parameter identifies the language of the text in - the property or property parameter value. The value of the "language" - property parameter is that defined in [RFC 1766]. - - For transport in a MIME entity, the Content-Language header field can - be used to set the default language for the entire body part. - Otherwise, no default language is assumed. - - Example: - - SUMMARY;LANGUAGE=us-EN:Company Holiday Party - - LOCATION;LANGUAGE=en:Germany - LOCATION;LANGUAGE=no:Tyskland - - - - - -Dawson & Stenerson Standards Track [Page 24] - -RFC 2445 iCalendar November 1998 - - - The following example makes use of the Quoted-Printable encoding in - order to represent non-ASCII characters. - - LOCATION;LANGUAGE=da:K=F8benhavn - LOCATION;LANGUAGE=en:Copenhagen - -4.2.11 Group or List Membership - - Parameter Name: MEMBER - - Purpose: To specify the group or list membership of the calendar user - specified by the property. - - Format Definition: The property parameter is defined by the following - notation: - - memberparam = "MEMBER" "=" DQUOTE cal-address DQUOTE - *("," DQUOTE cal-address DQUOTE) - - Description: This parameter can be specified on properties with a - CAL-ADDRESS value type. The parameter identifies the groups or list - membership for the calendar user specified by the property. The - parameter value either a single calendar address in a quoted-string - or a COMMA character (US-ASCII decimal 44) list of calendar - addresses, each in a quoted-string. The individual calendar address - parameter values MUST each be specified in a quoted-string. - - Example: - - ATTENDEE;MEMBER="MAILTO:ietf-calsch@imc.org":MAILTO:jsmith@host.com - - ATTENDEE;MEMBER="MAILTO:projectA@host.com","MAILTO:projectB@host. - com":MAILTO:janedoe@host.com - -4.2.12 Participation Status - - Parameter Name: PARTSTAT - - Purpose: To specify the participation status for the calendar user - specified by the property. - - Format Definition: The property parameter is defined by the following - notation: - - partstatparam = "PARTSTAT" "=" - ("NEEDS-ACTION" ; Event needs action - / "ACCEPTED" ; Event accepted - / "DECLINED" ; Event declined - - - -Dawson & Stenerson Standards Track [Page 25] - -RFC 2445 iCalendar November 1998 - - - / "TENTATIVE" ; Event tentatively - ; accepted - / "DELEGATED" ; Event delegated - / x-name ; Experimental status - / iana-token) ; Other IANA registered - ; status - ; These are the participation statuses for a "VEVENT". Default is - ; NEEDS-ACTION - partstatparam /= "PARTSTAT" "=" - ("NEEDS-ACTION" ; To-do needs action - / "ACCEPTED" ; To-do accepted - / "DECLINED" ; To-do declined - / "TENTATIVE" ; To-do tentatively - ; accepted - / "DELEGATED" ; To-do delegated - / "COMPLETED" ; To-do completed. - ; COMPLETED property has - ;date/time completed. - / "IN-PROCESS" ; To-do in process of - ; being completed - / x-name ; Experimental status - / iana-token) ; Other IANA registered - ; status - ; These are the participation statuses for a "VTODO". Default is - ; NEEDS-ACTION - - partstatparam /= "PARTSTAT" "=" - ("NEEDS-ACTION" ; Journal needs action - / "ACCEPTED" ; Journal accepted - / "DECLINED" ; Journal declined - / x-name ; Experimental status - / iana-token) ; Other IANA registered - ; status - ; These are the participation statuses for a "VJOURNAL". Default is - ; NEEDS-ACTION - - Description: This parameter can be specified on properties with a - CAL-ADDRESS value type. The parameter identifies the participation - status for the calendar user specified by the property value. The - parameter values differ depending on whether they are associated with - a group scheduled "VEVENT", "VTODO" or "VJOURNAL". The values MUST - match one of the values allowed for the given calendar component. If - not specified on a property that allows this parameter, the default - value is NEEDS-ACTION. - - Example: - - ATTENDEE;PARTSTAT=DECLINED:MAILTO:jsmith@host.com - - - -Dawson & Stenerson Standards Track [Page 26] - -RFC 2445 iCalendar November 1998 - - -4.2.13 Recurrence Identifier Range - - Parameter Name: RANGE - - Purpose: To specify the effective range of recurrence instances from - the instance specified by the recurrence identifier specified by the - property. - - Format Definition: The property parameter is defined by the following - notation: - - rangeparam = "RANGE" "=" ("THISANDPRIOR" - ; To specify all instances prior to the recurrence identifier - / "THISANDFUTURE") - ; To specify the instance specified by the recurrence identifier - ; and all subsequent recurrence instances - - Description: The parameter can be specified on a property that - specifies a recurrence identifier. The parameter specifies the - effective range of recurrence instances that is specified by the - property. The effective range is from the recurrence identified - specified by the property. If this parameter is not specified an - allowed property, then the default range is the single instance - specified by the recurrence identifier value of the property. The - parameter value can be "THISANDPRIOR" to indicate a range defined by - the recurrence identified value of the property and all prior - instances. The parameter value can also be "THISANDFUTURE" to - indicate a range defined by the recurrence identifier and all - subsequent instances. - - Example: - - RECURRENCE-ID;RANGE=THISANDPRIOR:19980401T133000Z - -4.2.14 Alarm Trigger Relationship - - Parameter Name: RELATED - - Purpose: To specify the relationship of the alarm trigger with - respect to the start or end of the calendar component. - - Format Definition: The property parameter is defined by the following - notation: - - trigrelparam = "RELATED" "=" - ("START" ; Trigger off of start - / "END") ; Trigger off of end - - - - -Dawson & Stenerson Standards Track [Page 27] - -RFC 2445 iCalendar November 1998 - - - Description: The parameter can be specified on properties that - specify an alarm trigger with a DURATION value type. The parameter - specifies whether the alarm will trigger relative to the start or end - of the calendar component. The parameter value START will set the - alarm to trigger off the start of the calendar component; the - parameter value END will set the alarm to trigger off the end of the - calendar component. If the parameter is not specified on an allowable - property, then the default is START. - - Example: - - TRIGGER;RELATED=END:PT5M - -4.2.15 Relationship Type - - Parameter Name: RELTYPE - - Purpose: To specify the type of hierarchical relationship associated - with the calendar component specified by the property. - - Format Definition: The property parameter is defined by the following - notation: - - reltypeparam = "RELTYPE" "=" - ("PARENT" ; Parent relationship. Default. - / "CHILD" ; Child relationship - / "SIBLING ; Sibling relationship - / iana-token ; Some other IANA registered - ; iCalendar relationship type - / x-name) ; A non-standard, experimental - ; relationship type - - Description: This parameter can be specified on a property that - references another related calendar. The parameter specifies the - hierarchical relationship type of the calendar component referenced - by the property. The parameter value can be PARENT, to indicate that - the referenced calendar component is a superior of calendar - component; CHILD to indicate that the referenced calendar component - is a subordinate of the calendar component; SIBLING to indicate that - the referenced calendar component is a peer of the calendar - component. If this parameter is not specified on an allowable - property, the default relationship type is PARENT. - - Example: - - RELATED-TO;RELTYPE=SIBLING:<19960401-080045-4000F192713@host.com> - - - - - -Dawson & Stenerson Standards Track [Page 28] - -RFC 2445 iCalendar November 1998 - - -4.2.16 Participation Role - - Parameter Name: ROLE - - Purpose: To specify the participation role for the calendar user - specified by the property. - - Format Definition: The property parameter is defined by the following - notation: - - roleparam = "ROLE" "=" - ("CHAIR" ; Indicates chair of the - ; calendar entity - / "REQ-PARTICIPANT" ; Indicates a participant whose - ; participation is required - / "OPT-PARTICIPANT" ; Indicates a participant whose - ; participation is optional - / "NON-PARTICIPANT" ; Indicates a participant who is - ; copied for information - ; purposes only - / x-name ; Experimental role - / iana-token) ; Other IANA role - ; Default is REQ-PARTICIPANT - - Description: This parameter can be specified on properties with a - CAL-ADDRESS value type. The parameter specifies the participation - role for the calendar user specified by the property in the group - schedule calendar component. If not specified on a property that - allows this parameter, the default value is REQ-PARTICIPANT. - - Example: - - ATTENDEE;ROLE=CHAIR:MAILTO:mrbig@host.com - -4.2.17 RSVP Expectation - - Parameter Name: RSVP - - Purpose: To specify whether there is an expectation of a favor of a - reply from the calendar user specified by the property value. - - Format Definition: The property parameter is defined by the following - notation: - - rsvpparam = "RSVP" "=" ("TRUE" / "FALSE") - ; Default is FALSE - - - - - -Dawson & Stenerson Standards Track [Page 29] - -RFC 2445 iCalendar November 1998 - - - Description: This parameter can be specified on properties with a - CAL-ADDRESS value type. The parameter identifies the expectation of a - reply from the calendar user specified by the property value. This - parameter is used by the "Organizer" to request a participation - status reply from an "Attendee" of a group scheduled event or to-do. - If not specified on a property that allows this parameter, the - default value is FALSE. - - Example: - - ATTENDEE;RSVP=TRUE:MAILTO:jsmith@host.com - -4.2.18 Sent By - - Parameter Name: SENT-BY - - Purpose: To specify the calendar user that is acting on behalf of the - calendar user specified by the property. - - Format Definition: The property parameter is defined by the following - notation: - - sentbyparam = "SENT-BY" "=" DQUOTE cal-address DQUOTE - - Description: This parameter can be specified on properties with a - CAL-ADDRESS value type. The parameter specifies the calendar user - that is acting on behalf of the calendar user specified by the - property. The parameter value MUST be a MAILTO URI as defined in [RFC - 1738]. The individual calendar address parameter values MUST each be - specified in a quoted-string. - - Example: - - ORGANIZER;SENT-BY:"MAILTO:sray@host.com":MAILTO:jsmith@host.com - -4.2.19 Time Zone Identifier - - Parameter Name: TZID - - Purpose: To specify the identifier for the time zone definition for a - time component in the property value. - - Format Definition: This property parameter is defined by the - following notation: - - tzidparam = "TZID" "=" [tzidprefix] paramtext CRLF - - tzidprefix = "/" - - - -Dawson & Stenerson Standards Track [Page 30] - -RFC 2445 iCalendar November 1998 - - - Description: The parameter MUST be specified on the "DTSTART", - "DTEND", "DUE", "EXDATE" and "RDATE" properties when either a DATE- - TIME or TIME value type is specified and when the value is not either - a UTC or a "floating" time. Refer to the DATE-TIME or TIME value type - definition for a description of UTC and "floating time" formats. This - property parameter specifies a text value which uniquely identifies - the "VTIMEZONE" calendar component to be used when evaluating the - time portion of the property. The value of the TZID property - parameter will be equal to the value of the TZID property for the - matching time zone definition. An individual "VTIMEZONE" calendar - component MUST be specified for each unique "TZID" parameter value - specified in the iCalendar object. - - The parameter MUST be specified on properties with a DATE-TIME value - if the DATE-TIME is not either a UTC or a "floating" time. - - The presence of the SOLIDUS character (US-ASCII decimal 47) as a - prefix, indicates that this TZID represents a unique ID in a globally - defined time zone registry (when such registry is defined). - - Note: This document does not define a naming convention for time - zone identifiers. Implementers may want to use the naming - conventions defined in existing time zone specifications such as - the public-domain Olson database [TZ]. The specification of - globally unique time zone identifiers is not addressed by this - document and is left for future study. - - The following are examples of this property parameter: - - DTSTART;TZID=US-Eastern:19980119T020000 - - DTEND;TZID=US-Eastern:19980119T030000 - - The TZID property parameter MUST NOT be applied to DATE-TIME or TIME - properties whose time values are specified in UTC. - - The use of local time in a DATE-TIME or TIME value without the TZID - property parameter is to be interpreted as a local time value, - regardless of the existence of "VTIMEZONE" calendar components in the - iCalendar object. - - For more information see the sections on the data types DATE-TIME and - TIME. - - - - - - - - -Dawson & Stenerson Standards Track [Page 31] - -RFC 2445 iCalendar November 1998 - - -4.2.20 Value Data Types - - Parameter Name: VALUE - - Purpose: To explicitly specify the data type format for a property - value. - - Format Definition: The "VALUE" property parameter is defined by the - following notation: - - valuetypeparam = "VALUE" "=" valuetype - - valuetype = ("BINARY" - / "BOOLEAN" - / "CAL-ADDRESS" - / "DATE" - / "DATE-TIME" - / "DURATION" - / "FLOAT" - / "INTEGER" - / "PERIOD" - / "RECUR" - / "TEXT" - / "TIME" - / "URI" - / "UTC-OFFSET" - / x-name - ; Some experimental iCalendar data type. - / iana-token) - ; Some other IANA registered iCalendar data type. - - Description: The parameter specifies the data type and format of the - property value. The property values MUST be of a single value type. - For example, a "RDATE" property cannot have a combination of DATE- - TIME and TIME value types. - - If the property's value is the default value type, then this - parameter need not be specified. However, if the property's default - value type is overridden by some other allowable value type, then - this parameter MUST be specified. - -4.3 Property Value Data Types - - The properties in an iCalendar object are strongly typed. The - definition of each property restricts the value to be one of the - value data types, or simply value types, defined in this section. The - value type for a property will either be specified implicitly as the - default value type or will be explicitly specified with the "VALUE" - - - -Dawson & Stenerson Standards Track [Page 32] - -RFC 2445 iCalendar November 1998 - - - parameter. If the value type of a property is one of the alternate - valid types, then it MUST be explicitly specified with the "VALUE" - parameter. - -4.3.1 Binary - - Value Name: BINARY - - Purpose: This value type is used to identify properties that contain - a character encoding of inline binary data. For example, an inline - attachment of an object code might be included in an iCalendar - object. - - Formal Definition: The value type is defined by the following - notation: - - binary = *(4b-char) [b-end] - ; A "BASE64" encoded character string, as defined by [RFC 2045]. - - b-end = (2b-char "==") / (3b-char "=") - - b-char = ALPHA / DIGIT / "+" / "/" - - Description: Property values with this value type MUST also include - the inline encoding parameter sequence of ";ENCODING=BASE64". That - is, all inline binary data MUST first be character encoded using the - "BASE64" encoding method defined in [RFC 2045]. No additional content - value encoding (i.e., BACKSLASH character encoding) is defined for - this value type. - - Example: The following is an abridged example of a "BASE64" encoded - binary value data. - - ATTACH;VALUE=BINARY;ENCODING=BASE64:MIICajCCAdOgAwIBAgICBEUwDQY - JKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlI - ENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZv - <...remainder of "BASE64" encoded binary data...> - -4.3.2 Boolean - - Value Name: BOOLEAN - - Purpose: This value type is used to identify properties that contain - either a "TRUE" or "FALSE" Boolean value. - - Formal Definition: The value type is defined by the following - notation: - - - - -Dawson & Stenerson Standards Track [Page 33] - -RFC 2445 iCalendar November 1998 - - - boolean = "TRUE" / "FALSE" - - Description: These values are case insensitive text. No additional - content value encoding (i.e., BACKSLASH character encoding) is - defined for this value type. - - Example: The following is an example of a hypothetical property that - has a BOOLEAN value type: - - GIBBERISH:TRUE - -4.3.3 Calendar User Address - - Value Name: CAL-ADDRESS - - Purpose: This value type is used to identify properties that contain - a calendar user address. - - Formal Definition: The value type is as defined by the following - notation: - - cal-address = uri - - Description: The value is a URI as defined by [RFC 1738] or any other - IANA registered form for a URI. When used to address an Internet - email transport address for a calendar user, the value MUST be a - MAILTO URI, as defined by [RFC 1738]. No additional content value - encoding (i.e., BACKSLASH character encoding) is defined for this - value type. - - Example: - - ATTENDEE:MAILTO:jane_doe@host.com - -4.3.4 Date - - Value Name: DATE - - Purpose: This value type is used to identify values that contain a - calendar date. - - Formal Definition: The value type is defined by the following - notation: - - date = date-value - - date-value = date-fullyear date-month date-mday - date-fullyear = 4DIGIT - - - -Dawson & Stenerson Standards Track [Page 34] - -RFC 2445 iCalendar November 1998 - - - date-month = 2DIGIT ;01-12 - date-mday = 2DIGIT ;01-28, 01-29, 01-30, 01-31 - ;based on month/year - - Description: If the property permits, multiple "date" values are - specified as a COMMA character (US-ASCII decimal 44) separated list - of values. The format for the value type is expressed as the [ISO - 8601] complete representation, basic format for a calendar date. The - textual format specifies a four-digit year, two-digit month, and - two-digit day of the month. There are no separator characters between - the year, month and day component text. - - No additional content value encoding (i.e., BACKSLASH character - encoding) is defined for this value type. - - Example: The following represents July 14, 1997: - - 19970714 - -4.3.5 Date-Time - - Value Name: DATE-TIME - - Purpose: This value type is used to identify values that specify a - precise calendar date and time of day. - - Formal Definition: The value type is defined by the following - notation: - - date-time = date "T" time ;As specified in the date and time - ;value definitions - - Description: If the property permits, multiple "date-time" values are - specified as a COMMA character (US-ASCII decimal 44) separated list - of values. No additional content value encoding (i.e., BACKSLASH - character encoding) is defined for this value type. - - The "DATE-TIME" data type is used to identify values that contain a - precise calendar date and time of day. The format is based on the - [ISO 8601] complete representation, basic format for a calendar date - and time of day. The text format is a concatenation of the "date", - followed by the LATIN CAPITAL LETTER T character (US-ASCII decimal - 84) time designator, followed by the "time" format. - - The "DATE-TIME" data type expresses time values in three forms: - - The form of date and time with UTC offset MUST NOT be used. For - example, the following is not valid for a date-time value: - - - -Dawson & Stenerson Standards Track [Page 35] - -RFC 2445 iCalendar November 1998 - - - DTSTART:19980119T230000-0800 ;Invalid time format - - FORM #1: DATE WITH LOCAL TIME - - The date with local time form is simply a date-time value that does - not contain the UTC designator nor does it reference a time zone. For - example, the following represents Janurary 18, 1998, at 11 PM: - - DTSTART:19980118T230000 - - Date-time values of this type are said to be "floating" and are not - bound to any time zone in particular. They are used to represent the - same hour, minute, and second value regardless of which time zone is - currently being observed. For example, an event can be defined that - indicates that an individual will be busy from 11:00 AM to 1:00 PM - every day, no matter which time zone the person is in. In these - cases, a local time can be specified. The recipient of an iCalendar - object with a property value consisting of a local time, without any - relative time zone information, SHOULD interpret the value as being - fixed to whatever time zone the ATTENDEE is in at any given moment. - This means that two ATTENDEEs, in different time zones, receiving the - same event definition as a floating time, may be participating in the - event at different actual times. Floating time SHOULD only be used - where that is the reasonable behavior. - - In most cases, a fixed time is desired. To properly communicate a - fixed time in a property value, either UTC time or local time with - time zone reference MUST be specified. - - The use of local time in a DATE-TIME value without the TZID property - parameter is to be interpreted as floating time, regardless of the - existence of "VTIMEZONE" calendar components in the iCalendar object. - - FORM #2: DATE WITH UTC TIME - - The date with UTC time, or absolute time, is identified by a LATIN - CAPITAL LETTER Z suffix character (US-ASCII decimal 90), the UTC - designator, appended to the time value. For example, the following - represents January 19, 1998, at 0700 UTC: - - DTSTART:19980119T070000Z - - The TZID property parameter MUST NOT be applied to DATE-TIME - properties whose time values are specified in UTC. - - FORM #3: DATE WITH LOCAL TIME AND TIME ZONE REFERENCE - - - - - -Dawson & Stenerson Standards Track [Page 36] - -RFC 2445 iCalendar November 1998 - - - The date and local time with reference to time zone information is - identified by the use the TZID property parameter to reference the - appropriate time zone definition. TZID is discussed in detail in the - section on Time Zone. For example, the following represents 2 AM in - New York on Janurary 19, 1998: - - DTSTART;TZID=US-Eastern:19980119T020000 - - Example: The following represents July 14, 1997, at 1:30 PM in New - York City in each of the three time formats, using the "DTSTART" - property. - - DTSTART:19970714T133000 ;Local time - DTSTART:19970714T173000Z ;UTC time - DTSTART;TZID=US-Eastern:19970714T133000 ;Local time and time - ; zone reference - - A time value MUST ONLY specify 60 seconds when specifying the - periodic "leap second" in the time value. For example: - - COMPLETED:19970630T235960Z - -4.3.6 Duration - - Value Name: DURATION - - Purpose: This value type is used to identify properties that contain - a duration of time. - - Formal Definition: The value type is defined by the following - notation: - - dur-value = (["+"] / "-") "P" (dur-date / dur-time / dur-week) - - dur-date = dur-day [dur-time] - dur-time = "T" (dur-hour / dur-minute / dur-second) - dur-week = 1*DIGIT "W" - dur-hour = 1*DIGIT "H" [dur-minute] - dur-minute = 1*DIGIT "M" [dur-second] - dur-second = 1*DIGIT "S" - dur-day = 1*DIGIT "D" - - Description: If the property permits, multiple "duration" values are - specified by a COMMA character (US-ASCII decimal 44) separated list - of values. The format is expressed as the [ISO 8601] basic format for - the duration of time. The format can represent durations in terms of - weeks, days, hours, minutes, and seconds. - - - - -Dawson & Stenerson Standards Track [Page 37] - -RFC 2445 iCalendar November 1998 - - - No additional content value encoding (i.e., BACKSLASH character - encoding) are defined for this value type. - - Example: A duration of 15 days, 5 hours and 20 seconds would be: - - P15DT5H0M20S - - A duration of 7 weeks would be: - - P7W - -4.3.7 Float - - Value Name: FLOAT - - Purpose: This value type is used to identify properties that contain - a real number value. - - Formal Definition: The value type is defined by the following - notation: - - float = (["+"] / "-") 1*DIGIT ["." 1*DIGIT] - - Description: If the property permits, multiple "float" values are - specified by a COMMA character (US-ASCII decimal 44) separated list - of values. - - No additional content value encoding (i.e., BACKSLASH character - encoding) is defined for this value type. - - Example: - - 1000000.0000001 - 1.333 - -3.14 - -4.3.8 Integer - - Value Name:INTEGER - - Purpose: This value type is used to identify properties that contain - a signed integer value. - - Formal Definition: The value type is defined by the following - notation: - - integer = (["+"] / "-") 1*DIGIT - - - - -Dawson & Stenerson Standards Track [Page 38] - -RFC 2445 iCalendar November 1998 - - - Description: If the property permits, multiple "integer" values are - specified by a COMMA character (US-ASCII decimal 44) separated list - of values. The valid range for "integer" is -2147483648 to - 2147483647. If the sign is not specified, then the value is assumed - to be positive. - - No additional content value encoding (i.e., BACKSLASH character - encoding) is defined for this value type. - - Example: - - 1234567890 - -1234567890 - +1234567890 - 432109876 - -4.3.9 Period of Time - - Value Name: PERIOD - - Purpose: This value type is used to identify values that contain a - precise period of time. - - Formal Definition: The data type is defined by the following - notation: - - period = period-explicit / period-start - - period-explicit = date-time "/" date-time - ; [ISO 8601] complete representation basic format for a period of - ; time consisting of a start and end. The start MUST be before the - ; end. - - period-start = date-time "/" dur-value - ; [ISO 8601] complete representation basic format for a period of - ; time consisting of a start and positive duration of time. - - Description: If the property permits, multiple "period" values are - specified by a COMMA character (US-ASCII decimal 44) separated list - of values. There are two forms of a period of time. First, a period - of time is identified by its start and its end. This format is - expressed as the [ISO 8601] complete representation, basic format for - "DATE-TIME" start of the period, followed by a SOLIDUS character - (US-ASCII decimal 47), followed by the "DATE-TIME" of the end of the - period. The start of the period MUST be before the end of the period. - Second, a period of time can also be defined by a start and a - positive duration of time. The format is expressed as the [ISO 8601] - complete representation, basic format for the "DATE-TIME" start of - - - -Dawson & Stenerson Standards Track [Page 39] - -RFC 2445 iCalendar November 1998 - - - the period, followed by a SOLIDUS character (US-ASCII decimal 47), - followed by the [ISO 8601] basic format for "DURATION" of the period. - - Example: The period starting at 18:00:00 UTC, on January 1, 1997 and - ending at 07:00:00 UTC on January 2, 1997 would be: - - 19970101T180000Z/19970102T070000Z - - The period start at 18:00:00 on January 1, 1997 and lasting 5 hours - and 30 minutes would be: - - 19970101T180000Z/PT5H30M - - No additional content value encoding (i.e., BACKSLASH character - encoding) is defined for this value type. - -4.3.10 Recurrence Rule - - Value Name: RECUR - - Purpose: This value type is used to identify properties that contain - a recurrence rule specification. - - Formal Definition: The value type is defined by the following - notation: - - recur = "FREQ"=freq *( - - ; either UNTIL or COUNT may appear in a 'recur', - ; but UNTIL and COUNT MUST NOT occur in the same 'recur' - - ( ";" "UNTIL" "=" enddate ) / - ( ";" "COUNT" "=" 1*DIGIT ) / - - ; the rest of these keywords are optional, - ; but MUST NOT occur more than once - - ( ";" "INTERVAL" "=" 1*DIGIT ) / - ( ";" "BYSECOND" "=" byseclist ) / - ( ";" "BYMINUTE" "=" byminlist ) / - ( ";" "BYHOUR" "=" byhrlist ) / - ( ";" "BYDAY" "=" bywdaylist ) / - ( ";" "BYMONTHDAY" "=" bymodaylist ) / - ( ";" "BYYEARDAY" "=" byyrdaylist ) / - ( ";" "BYWEEKNO" "=" bywknolist ) / - ( ";" "BYMONTH" "=" bymolist ) / - ( ";" "BYSETPOS" "=" bysplist ) / - ( ";" "WKST" "=" weekday ) / - - - -Dawson & Stenerson Standards Track [Page 40] - -RFC 2445 iCalendar November 1998 - - - ( ";" x-name "=" text ) - ) - - freq = "SECONDLY" / "MINUTELY" / "HOURLY" / "DAILY" - / "WEEKLY" / "MONTHLY" / "YEARLY" - - enddate = date - enddate =/ date-time ;An UTC value - - byseclist = seconds / ( seconds *("," seconds) ) - - seconds = 1DIGIT / 2DIGIT ;0 to 59 - - byminlist = minutes / ( minutes *("," minutes) ) - - minutes = 1DIGIT / 2DIGIT ;0 to 59 - - byhrlist = hour / ( hour *("," hour) ) - - hour = 1DIGIT / 2DIGIT ;0 to 23 - - bywdaylist = weekdaynum / ( weekdaynum *("," weekdaynum) ) - - weekdaynum = [([plus] ordwk / minus ordwk)] weekday - - plus = "+" - - minus = "-" - - ordwk = 1DIGIT / 2DIGIT ;1 to 53 - - weekday = "SU" / "MO" / "TU" / "WE" / "TH" / "FR" / "SA" - ;Corresponding to SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, - ;FRIDAY, SATURDAY and SUNDAY days of the week. - - bymodaylist = monthdaynum / ( monthdaynum *("," monthdaynum) ) - - monthdaynum = ([plus] ordmoday) / (minus ordmoday) - - ordmoday = 1DIGIT / 2DIGIT ;1 to 31 - - byyrdaylist = yeardaynum / ( yeardaynum *("," yeardaynum) ) - - yeardaynum = ([plus] ordyrday) / (minus ordyrday) - - ordyrday = 1DIGIT / 2DIGIT / 3DIGIT ;1 to 366 - - bywknolist = weeknum / ( weeknum *("," weeknum) ) - - - -Dawson & Stenerson Standards Track [Page 41] - -RFC 2445 iCalendar November 1998 - - - weeknum = ([plus] ordwk) / (minus ordwk) - - bymolist = monthnum / ( monthnum *("," monthnum) ) - - monthnum = 1DIGIT / 2DIGIT ;1 to 12 - - bysplist = setposday / ( setposday *("," setposday) ) - - setposday = yeardaynum - - Description: If the property permits, multiple "recur" values are - specified by a COMMA character (US-ASCII decimal 44) separated list - of values. The value type is a structured value consisting of a list - of one or more recurrence grammar parts. Each rule part is defined by - a NAME=VALUE pair. The rule parts are separated from each other by - the SEMICOLON character (US-ASCII decimal 59). The rule parts are not - ordered in any particular sequence. Individual rule parts MUST only - be specified once. - - The FREQ rule part identifies the type of recurrence rule. This rule - part MUST be specified in the recurrence rule. Valid values include - SECONDLY, to specify repeating events based on an interval of a - second or more; MINUTELY, to specify repeating events based on an - interval of a minute or more; HOURLY, to specify repeating events - based on an interval of an hour or more; DAILY, to specify repeating - events based on an interval of a day or more; WEEKLY, to specify - repeating events based on an interval of a week or more; MONTHLY, to - specify repeating events based on an interval of a month or more; and - YEARLY, to specify repeating events based on an interval of a year or - more. - - The INTERVAL rule part contains a positive integer representing how - often the recurrence rule repeats. The default value is "1", meaning - every second for a SECONDLY rule, or every minute for a MINUTELY - rule, every hour for an HOURLY rule, every day for a DAILY rule, - every week for a WEEKLY rule, every month for a MONTHLY rule and - every year for a YEARLY rule. - - The UNTIL rule part defines a date-time value which bounds the - recurrence rule in an inclusive manner. If the value specified by - UNTIL is synchronized with the specified recurrence, this date or - date-time becomes the last instance of the recurrence. If specified - as a date-time value, then it MUST be specified in an UTC time - format. If not present, and the COUNT rule part is also not present, - the RRULE is considered to repeat forever. - - The COUNT rule part defines the number of occurrences at which to - range-bound the recurrence. The "DTSTART" property value, if - - - -Dawson & Stenerson Standards Track [Page 42] - -RFC 2445 iCalendar November 1998 - - - specified, counts as the first occurrence. - - The BYSECOND rule part specifies a COMMA character (US-ASCII decimal - 44) separated list of seconds within a minute. Valid values are 0 to - 59. The BYMINUTE rule part specifies a COMMA character (US-ASCII - decimal 44) separated list of minutes within an hour. Valid values - are 0 to 59. The BYHOUR rule part specifies a COMMA character (US- - ASCII decimal 44) separated list of hours of the day. Valid values - are 0 to 23. - - The BYDAY rule part specifies a COMMA character (US-ASCII decimal 44) - separated list of days of the week; MO indicates Monday; TU indicates - Tuesday; WE indicates Wednesday; TH indicates Thursday; FR indicates - Friday; SA indicates Saturday; SU indicates Sunday. - - Each BYDAY value can also be preceded by a positive (+n) or negative - (-n) integer. If present, this indicates the nth occurrence of the - specific day within the MONTHLY or YEARLY RRULE. For example, within - a MONTHLY rule, +1MO (or simply 1MO) represents the first Monday - within the month, whereas -1MO represents the last Monday of the - month. If an integer modifier is not present, it means all days of - this type within the specified frequency. For example, within a - MONTHLY rule, MO represents all Mondays within the month. - - The BYMONTHDAY rule part specifies a COMMA character (ASCII decimal - 44) separated list of days of the month. Valid values are 1 to 31 or - -31 to -1. For example, -10 represents the tenth to the last day of - the month. - - The BYYEARDAY rule part specifies a COMMA character (US-ASCII decimal - 44) separated list of days of the year. Valid values are 1 to 366 or - -366 to -1. For example, -1 represents the last day of the year - (December 31st) and -306 represents the 306th to the last day of the - year (March 1st). - - The BYWEEKNO rule part specifies a COMMA character (US-ASCII decimal - 44) separated list of ordinals specifying weeks of the year. Valid - values are 1 to 53 or -53 to -1. This corresponds to weeks according - to week numbering as defined in [ISO 8601]. A week is defined as a - seven day period, starting on the day of the week defined to be the - week start (see WKST). Week number one of the calendar year is the - first week which contains at least four (4) days in that calendar - year. This rule part is only valid for YEARLY rules. For example, 3 - represents the third week of the year. - - Note: Assuming a Monday week start, week 53 can only occur when - Thursday is January 1 or if it is a leap year and Wednesday is - January 1. - - - -Dawson & Stenerson Standards Track [Page 43] - -RFC 2445 iCalendar November 1998 - - - The BYMONTH rule part specifies a COMMA character (US-ASCII decimal - 44) separated list of months of the year. Valid values are 1 to 12. - - The WKST rule part specifies the day on which the workweek starts. - Valid values are MO, TU, WE, TH, FR, SA and SU. This is significant - when a WEEKLY RRULE has an interval greater than 1, and a BYDAY rule - part is specified. This is also significant when in a YEARLY RRULE - when a BYWEEKNO rule part is specified. The default value is MO. - - The BYSETPOS rule part specifies a COMMA character (US-ASCII decimal - 44) separated list of values which corresponds to the nth occurrence - within the set of events specified by the rule. Valid values are 1 to - 366 or -366 to -1. It MUST only be used in conjunction with another - BYxxx rule part. For example "the last work day of the month" could - be represented as: - - RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1 - - Each BYSETPOS value can include a positive (+n) or negative (-n) - integer. If present, this indicates the nth occurrence of the - specific occurrence within the set of events specified by the rule. - - If BYxxx rule part values are found which are beyond the available - scope (ie, BYMONTHDAY=30 in February), they are simply ignored. - - Information, not contained in the rule, necessary to determine the - various recurrence instance start time and dates are derived from the - Start Time (DTSTART) entry attribute. For example, - "FREQ=YEARLY;BYMONTH=1" doesn't specify a specific day within the - month or a time. This information would be the same as what is - specified for DTSTART. - - BYxxx rule parts modify the recurrence in some manner. BYxxx rule - parts for a period of time which is the same or greater than the - frequency generally reduce or limit the number of occurrences of the - recurrence generated. For example, "FREQ=DAILY;BYMONTH=1" reduces the - number of recurrence instances from all days (if BYMONTH tag is not - present) to all days in January. BYxxx rule parts for a period of - time less than the frequency generally increase or expand the number - of occurrences of the recurrence. For example, - "FREQ=YEARLY;BYMONTH=1,2" increases the number of days within the - yearly recurrence set from 1 (if BYMONTH tag is not present) to 2. - - If multiple BYxxx rule parts are specified, then after evaluating the - specified FREQ and INTERVAL rule parts, the BYxxx rule parts are - applied to the current set of evaluated occurrences in the following - order: BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY, BYDAY, BYHOUR, - BYMINUTE, BYSECOND and BYSETPOS; then COUNT and UNTIL are evaluated. - - - -Dawson & Stenerson Standards Track [Page 44] - -RFC 2445 iCalendar November 1998 - - - Here is an example of evaluating multiple BYxxx rule parts. - - DTSTART;TZID=US-Eastern:19970105T083000 - RRULE:FREQ=YEARLY;INTERVAL=2;BYMONTH=1;BYDAY=SU;BYHOUR=8,9; - BYMINUTE=30 - - First, the "INTERVAL=2" would be applied to "FREQ=YEARLY" to arrive - at "every other year". Then, "BYMONTH=1" would be applied to arrive - at "every January, every other year". Then, "BYDAY=SU" would be - applied to arrive at "every Sunday in January, every other year". - Then, "BYHOUR=8,9" would be applied to arrive at "every Sunday in - January at 8 AM and 9 AM, every other year". Then, "BYMINUTE=30" - would be applied to arrive at "every Sunday in January at 8:30 AM and - 9:30 AM, every other year". Then, lacking information from RRULE, the - second is derived from DTSTART, to end up in "every Sunday in January - at 8:30:00 AM and 9:30:00 AM, every other year". Similarly, if the - BYMINUTE, BYHOUR, BYDAY, BYMONTHDAY or BYMONTH rule part were - missing, the appropriate minute, hour, day or month would have been - retrieved from the "DTSTART" property. - - No additional content value encoding (i.e., BACKSLASH character - encoding) is defined for this value type. - - Example: The following is a rule which specifies 10 meetings which - occur every other day: - - FREQ=DAILY;COUNT=10;INTERVAL=2 - - There are other examples specified in the "RRULE" specification. - -4.3.11 Text - - Value Name: TEXT - - Purpose This value type is used to identify values that contain human - readable text. - - Formal Definition: The character sets supported by this revision of - iCalendar are UTF-8 and US ASCII thereof. The applicability to other - character sets is for future work. The value type is defined by the - following notation. - - text = *(TSAFE-CHAR / ":" / DQUOTE / ESCAPED-CHAR) - ; Folded according to description above - - ESCAPED-CHAR = "\\" / "\;" / "\," / "\N" / "\n") - ; \\ encodes \, \N or \n encodes newline - ; \; encodes ;, \, encodes , - - - -Dawson & Stenerson Standards Track [Page 45] - -RFC 2445 iCalendar November 1998 - - - TSAFE-CHAR = %x20-21 / %x23-2B / %x2D-39 / %x3C-5B - %x5D-7E / NON-US-ASCII - ; Any character except CTLs not needed by the current - ; character set, DQUOTE, ";", ":", "\", "," - - Note: Certain other character sets may require modification of the - above definitions, but this is beyond the scope of this document. - - Description: If the property permits, multiple "text" values are - specified by a COMMA character (US-ASCII decimal 44) separated list - of values. - - The language in which the text is represented can be controlled by - the "LANGUAGE" property parameter. - - An intentional formatted text line break MUST only be included in a - "TEXT" property value by representing the line break with the - character sequence of BACKSLASH (US-ASCII decimal 92), followed by a - LATIN SMALL LETTER N (US-ASCII decimal 110) or a LATIN CAPITAL LETTER - N (US-ASCII decimal 78), that is "\n" or "\N". - - The "TEXT" property values may also contain special characters that - are used to signify delimiters, such as a COMMA character for lists - of values or a SEMICOLON character for structured values. In order to - support the inclusion of these special characters in "TEXT" property - values, they MUST be escaped with a BACKSLASH character. A BACKSLASH - character (US-ASCII decimal 92) in a "TEXT" property value MUST be - escaped with another BACKSLASH character. A COMMA character in a - "TEXT" property value MUST be escaped with a BACKSLASH character - (US-ASCII decimal 92). A SEMICOLON character in a "TEXT" property - value MUST be escaped with a BACKSLASH character (US-ASCII decimal - 92). However, a COLON character in a "TEXT" property value SHALL NOT - be escaped with a BACKSLASH character.Example: A multiple line value - of: - - Project XYZ Final Review - Conference Room - 3B - Come Prepared. - - would be represented as: - - Project XYZ Final Review\nConference Room - 3B\nCome Prepared. - - - - - - - - - -Dawson & Stenerson Standards Track [Page 46] - -RFC 2445 iCalendar November 1998 - - -4.3.12 Time - - Value Name: TIME - - Purpose: This value type is used to identify values that contain a - time of day. - - Formal Definition: The data type is defined by the following - notation: - - time = time-hour time-minute time-second [time-utc] - - time-hour = 2DIGIT ;00-23 - time-minute = 2DIGIT ;00-59 - time-second = 2DIGIT ;00-60 - ;The "60" value is used to account for "leap" seconds. - - time-utc = "Z" - - Description: If the property permits, multiple "time" values are - specified by a COMMA character (US-ASCII decimal 44) separated list - of values. No additional content value encoding (i.e., BACKSLASH - character encoding) is defined for this value type. - - The "TIME" data type is used to identify values that contain a time - of day. The format is based on the [ISO 8601] complete - representation, basic format for a time of day. The text format - consists of a two-digit 24-hour of the day (i.e., values 0-23), two- - digit minute in the hour (i.e., values 0-59), and two-digit seconds - in the minute (i.e., values 0-60). The seconds value of 60 MUST only - to be used to account for "leap" seconds. Fractions of a second are - not supported by this format. - - In parallel to the "DATE-TIME" definition above, the "TIME" data type - expresses time values in three forms: - - The form of time with UTC offset MUST NOT be used. For example, the - following is NOT VALID for a time value: - - 230000-0800 ;Invalid time format - - FORM #1 LOCAL TIME - - The local time form is simply a time value that does not contain the - UTC designator nor does it reference a time zone. For example, 11:00 - PM: - - 230000 - - - -Dawson & Stenerson Standards Track [Page 47] - -RFC 2445 iCalendar November 1998 - - - Time values of this type are said to be "floating" and are not bound - to any time zone in particular. They are used to represent the same - hour, minute, and second value regardless of which time zone is - currently being observed. For example, an event can be defined that - indicates that an individual will be busy from 11:00 AM to 1:00 PM - every day, no matter which time zone the person is in. In these - cases, a local time can be specified. The recipient of an iCalendar - object with a property value consisting of a local time, without any - relative time zone information, SHOULD interpret the value as being - fixed to whatever time zone the ATTENDEE is in at any given moment. - This means that two ATTENDEEs may participate in the same event at - different UTC times; floating time SHOULD only be used where that is - reasonable behavior. - - In most cases, a fixed time is desired. To properly communicate a - fixed time in a property value, either UTC time or local time with - time zone reference MUST be specified. - - The use of local time in a TIME value without the TZID property - parameter is to be interpreted as a local time value, regardless of - the existence of "VTIMEZONE" calendar components in the iCalendar - object. - - FORM #2: UTC TIME - - UTC time, or absolute time, is identified by a LATIN CAPITAL LETTER Z - suffix character (US-ASCII decimal 90), the UTC designator, appended - to the time value. For example, the following represents 07:00 AM - UTC: - - 070000Z - - The TZID property parameter MUST NOT be applied to TIME properties - whose time values are specified in UTC. - - FORM #3: LOCAL TIME AND TIME ZONE REFERENCE - - The local time with reference to time zone information form is - identified by the use the TZID property parameter to reference the - appropriate time zone definition. TZID is discussed in detail in the - section on Time Zone. - - Example: The following represents 8:30 AM in New York in Winter, five - hours behind UTC, in each of the three formats using the "X- - TIMEOFDAY" non-standard property: - - - - - - -Dawson & Stenerson Standards Track [Page 48] - -RFC 2445 iCalendar November 1998 - - - X-TIMEOFDAY:083000 - - X-TIMEOFDAY:133000Z - - X-TIMEOFDAY;TZID=US-Eastern:083000 - -4.3.13 URI - - Value Name: URI - - Purpose: This value type is used to identify values that contain a - uniform resource identifier (URI) type of reference to the property - value. - - Formal Definition: The data type is defined by the following - notation: - - uri = - - Description: This data type might be used to reference binary - information, for values that are large, or otherwise undesirable to - include directly in the iCalendar object. - - The URI value formats in RFC 1738, RFC 2111 and any other IETF - registered value format can be specified. - - Any IANA registered URI format can be used. These include, but are - not limited to, those defined in RFC 1738 and RFC 2111. - - When a property parameter value is a URI value type, the URI MUST be - specified as a quoted-string value. - - No additional content value encoding (i.e., BACKSLASH character - encoding) is defined for this value type. - - Example: The following is a URI for a network file: - - http://host1.com/my-report.txt - -4.3.14 UTC Offset - - Value Name: UTC-OFFSET - - Purpose: This value type is used to identify properties that contain - an offset from UTC to local time. - - Formal Definition: The data type is defined by the following - notation: - - - -Dawson & Stenerson Standards Track [Page 49] - -RFC 2445 iCalendar November 1998 - - - utc-offset = time-numzone ;As defined above in time data type - - time-numzone = ("+" / "-") time-hour time-minute [time- - second] - - Description: The PLUS SIGN character MUST be specified for positive - UTC offsets (i.e., ahead of UTC). The value of "-0000" and "-000000" - are not allowed. The time-second, if present, may not be 60; if - absent, it defaults to zero. - - No additional content value encoding (i.e., BACKSLASH character - encoding) is defined for this value type. - - Example: The following UTC offsets are given for standard time for - New York (five hours behind UTC) and Geneva (one hour ahead of UTC): - - -0500 - - +0100 - -4.4 iCalendar Object - - The Calendaring and Scheduling Core Object is a collection of - calendaring and scheduling information. Typically, this information - will consist of a single iCalendar object. However, multiple - iCalendar objects can be sequentially grouped together. The first - line and last line of the iCalendar object MUST contain a pair of - iCalendar object delimiter strings. The syntax for an iCalendar - object is as follows: - - icalobject = 1*("BEGIN" ":" "VCALENDAR" CRLF - icalbody - "END" ":" "VCALENDAR" CRLF) - - The following is a simple example of an iCalendar object: - - BEGIN:VCALENDAR - VERSION:2.0 - PRODID:-//hacksw/handcal//NONSGML v1.0//EN - BEGIN:VEVENT - DTSTART:19970714T170000Z - DTEND:19970715T035959Z - SUMMARY:Bastille Day Party - END:VEVENT - END:VCALENDAR - - - - - - -Dawson & Stenerson Standards Track [Page 50] - -RFC 2445 iCalendar November 1998 - - -4.5 Property - - A property is the definition of an individual attribute describing a - calendar or a calendar component. A property takes the form defined - by the "contentline" notation defined in section 4.1.1. - - The following is an example of a property: - - DTSTART:19960415T133000Z - - This memo imposes no ordering of properties within an iCalendar - object. - - Property names, parameter names and enumerated parameter values are - case insensitive. For example, the property name "DUE" is the same as - "due" and "Due", DTSTART;TZID=US-Eastern:19980714T120000 is the same - as DtStart;TzID=US-Eastern:19980714T120000. - -4.6 Calendar Components - - The body of the iCalendar object consists of a sequence of calendar - properties and one or more calendar components. The calendar - properties are attributes that apply to the calendar as a whole. The - calendar components are collections of properties that express a - particular calendar semantic. For example, the calendar component can - specify an event, a to-do, a journal entry, time zone information, or - free/busy time information, or an alarm. - - The body of the iCalendar object is defined by the following - notation: - - icalbody = calprops component - - calprops = 2*( - - ; 'prodid' and 'version' are both REQUIRED, - ; but MUST NOT occur more than once - - prodid /version / - - ; 'calscale' and 'method' are optional, - ; but MUST NOT occur more than once - - calscale / - method / - - x-prop - - - - -Dawson & Stenerson Standards Track [Page 51] - -RFC 2445 iCalendar November 1998 - - - ) - - component = 1*(eventc / todoc / journalc / freebusyc / - / timezonec / iana-comp / x-comp) - - iana-comp = "BEGIN" ":" iana-token CRLF - - 1*contentline - - "END" ":" iana-token CRLF - - x-comp = "BEGIN" ":" x-name CRLF - - 1*contentline - - "END" ":" x-name CRLF - - An iCalendar object MUST include the "PRODID" and "VERSION" calendar - properties. In addition, it MUST include at least one calendar - component. Special forms of iCalendar objects are possible to publish - just busy time (i.e., only a "VFREEBUSY" calendar component) or time - zone (i.e., only a "VTIMEZONE" calendar component) information. In - addition, a complex iCalendar object is possible that is used to - capture a complete snapshot of the contents of a calendar (e.g., - composite of many different calendar components). More commonly, an - iCalendar object will consist of just a single "VEVENT", "VTODO" or - "VJOURNAL" calendar component. - -4.6.1 Event Component - - Component Name: "VEVENT" - - Purpose: Provide a grouping of component properties that describe an - event. - - Format Definition: A "VEVENT" calendar component is defined by the - following notation: - - eventc = "BEGIN" ":" "VEVENT" CRLF - eventprop *alarmc - "END" ":" "VEVENT" CRLF - - eventprop = *( - - ; the following are optional, - ; but MUST NOT occur more than once - - class / created / description / dtstart / geo / - - - -Dawson & Stenerson Standards Track [Page 52] - -RFC 2445 iCalendar November 1998 - - - last-mod / location / organizer / priority / - dtstamp / seq / status / summary / transp / - uid / url / recurid / - - ; either 'dtend' or 'duration' may appear in - ; a 'eventprop', but 'dtend' and 'duration' - ; MUST NOT occur in the same 'eventprop' - - dtend / duration / - - ; the following are optional, - ; and MAY occur more than once - - attach / attendee / categories / comment / - contact / exdate / exrule / rstatus / related / - resources / rdate / rrule / x-prop - - ) - - Description: A "VEVENT" calendar component is a grouping of component - properties, and possibly including "VALARM" calendar components, that - represents a scheduled amount of time on a calendar. For example, it - can be an activity; such as a one-hour long, department meeting from - 8:00 AM to 9:00 AM, tomorrow. Generally, an event will take up time - on an individual calendar. Hence, the event will appear as an opaque - interval in a search for busy time. Alternately, the event can have - its Time Transparency set to "TRANSPARENT" in order to prevent - blocking of the event in searches for busy time. - - The "VEVENT" is also the calendar component used to specify an - anniversary or daily reminder within a calendar. These events have a - DATE value type for the "DTSTART" property instead of the default - data type of DATE-TIME. If such a "VEVENT" has a "DTEND" property, it - MUST be specified as a DATE value also. The anniversary type of - "VEVENT" can span more than one date (i.e, "DTEND" property value is - set to a calendar date after the "DTSTART" property value). - - The "DTSTART" property for a "VEVENT" specifies the inclusive start - of the event. For recurring events, it also specifies the very first - instance in the recurrence set. The "DTEND" property for a "VEVENT" - calendar component specifies the non-inclusive end of the event. For - cases where a "VEVENT" calendar component specifies a "DTSTART" - property with a DATE data type but no "DTEND" property, the events - non-inclusive end is the end of the calendar date specified by the - "DTSTART" property. For cases where a "VEVENT" calendar component - specifies a "DTSTART" property with a DATE-TIME data type but no - "DTEND" property, the event ends on the same calendar date and time - of day specified by the "DTSTART" property. - - - -Dawson & Stenerson Standards Track [Page 53] - -RFC 2445 iCalendar November 1998 - - - The "VEVENT" calendar component cannot be nested within another - calendar component. However, "VEVENT" calendar components can be - related to each other or to a "VTODO" or to a "VJOURNAL" calendar - component with the "RELATED-TO" property. - - Example: The following is an example of the "VEVENT" calendar - component used to represent a meeting that will also be opaque to - searches for busy time: - - BEGIN:VEVENT - UID:19970901T130000Z-123401@host.com - DTSTAMP:19970901T1300Z - DTSTART:19970903T163000Z - DTEND:19970903T190000Z - SUMMARY:Annual Employee Review - CLASS:PRIVATE - CATEGORIES:BUSINESS,HUMAN RESOURCES - END:VEVENT - - The following is an example of the "VEVENT" calendar component used - to represent a reminder that will not be opaque, but rather - transparent, to searches for busy time: - - BEGIN:VEVENT - UID:19970901T130000Z-123402@host.com - DTSTAMP:19970901T1300Z - DTSTART:19970401T163000Z - DTEND:19970402T010000Z - SUMMARY:Laurel is in sensitivity awareness class. - CLASS:PUBLIC - CATEGORIES:BUSINESS,HUMAN RESOURCES - TRANSP:TRANSPARENT - END:VEVENT - - The following is an example of the "VEVENT" calendar component used - to represent an anniversary that will occur annually. Since it takes - up no time, it will not appear as opaque in a search for busy time; - no matter what the value of the "TRANSP" property indicates: - - BEGIN:VEVENT - UID:19970901T130000Z-123403@host.com - DTSTAMP:19970901T1300Z - DTSTART:19971102 - SUMMARY:Our Blissful Anniversary - CLASS:CONFIDENTIAL - CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION - RRULE:FREQ=YEARLY - END:VEVENT - - - -Dawson & Stenerson Standards Track [Page 54] - -RFC 2445 iCalendar November 1998 - - -4.6.2 To-do Component - - Component Name: VTODO - - Purpose: Provide a grouping of calendar properties that describe a - to-do. - - Formal Definition: A "VTODO" calendar component is defined by the - following notation: - - todoc = "BEGIN" ":" "VTODO" CRLF - todoprop *alarmc - "END" ":" "VTODO" CRLF - - todoprop = *( - - ; the following are optional, - ; but MUST NOT occur more than once - - class / completed / created / description / dtstamp / - dtstart / geo / last-mod / location / organizer / - percent / priority / recurid / seq / status / - summary / uid / url / - - ; either 'due' or 'duration' may appear in - ; a 'todoprop', but 'due' and 'duration' - ; MUST NOT occur in the same 'todoprop' - - due / duration / - - ; the following are optional, - ; and MAY occur more than once - attach / attendee / categories / comment / contact / - exdate / exrule / rstatus / related / resources / - rdate / rrule / x-prop - - ) - - Description: A "VTODO" calendar component is a grouping of component - properties and possibly "VALARM" calendar components that represent - an action-item or assignment. For example, it can be used to - represent an item of work assigned to an individual; such as "turn in - travel expense today". - - The "VTODO" calendar component cannot be nested within another - calendar component. However, "VTODO" calendar components can be - related to each other or to a "VTODO" or to a "VJOURNAL" calendar - component with the "RELATED-TO" property. - - - -Dawson & Stenerson Standards Track [Page 55] - -RFC 2445 iCalendar November 1998 - - - A "VTODO" calendar component without the "DTSTART" and "DUE" (or - "DURATION") properties specifies a to-do that will be associated with - each successive calendar date, until it is completed. - - Example: The following is an example of a "VTODO" calendar component: - - BEGIN:VTODO - UID:19970901T130000Z-123404@host.com - DTSTAMP:19970901T1300Z - DTSTART:19970415T133000Z - DUE:19970416T045959Z - SUMMARY:1996 Income Tax Preparation - CLASS:CONFIDENTIAL - CATEGORIES:FAMILY,FINANCE - PRIORITY:1 - STATUS:NEEDS-ACTION - END:VTODO - -4.6.3 Journal Component - - Component Name: VJOURNAL - - Purpose: Provide a grouping of component properties that describe a - journal entry. - - Formal Definition: A "VJOURNAL" calendar component is defined by the - following notation: - - journalc = "BEGIN" ":" "VJOURNAL" CRLF - jourprop - "END" ":" "VJOURNAL" CRLF - - jourprop = *( - - ; the following are optional, - ; but MUST NOT occur more than once - - class / created / description / dtstart / dtstamp / - last-mod / organizer / recurid / seq / status / - summary / uid / url / - - ; the following are optional, - ; and MAY occur more than once - - attach / attendee / categories / comment / - contact / exdate / exrule / related / rdate / - rrule / rstatus / x-prop - - - - -Dawson & Stenerson Standards Track [Page 56] - -RFC 2445 iCalendar November 1998 - - - ) - - Description: A "VJOURNAL" calendar component is a grouping of - component properties that represent one or more descriptive text - notes associated with a particular calendar date. The "DTSTART" - property is used to specify the calendar date that the journal entry - is associated with. Generally, it will have a DATE value data type, - but it can also be used to specify a DATE-TIME value data type. - Examples of a journal entry include a daily record of a legislative - body or a journal entry of individual telephone contacts for the day - or an ordered list of accomplishments for the day. The "VJOURNAL" - calendar component can also be used to associate a document with a - calendar date. - - The "VJOURNAL" calendar component does not take up time on a - calendar. Hence, it does not play a role in free or busy time - searches - - it is as though it has a time transparency value of - TRANSPARENT. It is transparent to any such searches. - - The "VJOURNAL" calendar component cannot be nested within another - calendar component. However, "VJOURNAL" calendar components can be - related to each other or to a "VEVENT" or to a "VTODO" calendar - component, with the "RELATED-TO" property. - - Example: The following is an example of the "VJOURNAL" calendar - component: - - BEGIN:VJOURNAL - UID:19970901T130000Z-123405@host.com - DTSTAMP:19970901T1300Z - DTSTART;VALUE=DATE:19970317 - SUMMARY:Staff meeting minutes - DESCRIPTION:1. Staff meeting: Participants include Joe\, Lisa - and Bob. Aurora project plans were reviewed. There is currently - no budget reserves for this project. Lisa will escalate to - management. Next meeting on Tuesday.\n - 2. Telephone Conference: ABC Corp. sales representative called - to discuss new printer. Promised to get us a demo by Friday.\n - 3. Henry Miller (Handsoff Insurance): Car was totaled by tree. - Is looking into a loaner car. 654-2323 (tel). - END:VJOURNAL - - - - - - - - - - -Dawson & Stenerson Standards Track [Page 57] - -RFC 2445 iCalendar November 1998 - - -4.6.4 Free/Busy Component - - Component Name: VFREEBUSY - - Purpose: Provide a grouping of component properties that describe - either a request for free/busy time, describe a response to a request - for free/busy time or describe a published set of busy time. - - Formal Definition: A "VFREEBUSY" calendar component is defined by the - following notation: - - freebusyc = "BEGIN" ":" "VFREEBUSY" CRLF - fbprop - "END" ":" "VFREEBUSY" CRLF - - fbprop = *( - - ; the following are optional, - ; but MUST NOT occur more than once - - contact / dtstart / dtend / duration / dtstamp / - organizer / uid / url / - - ; the following are optional, - ; and MAY occur more than once - - attendee / comment / freebusy / rstatus / x-prop - - ) - - Description: A "VFREEBUSY" calendar component is a grouping of - component properties that represents either a request for, a reply to - a request for free or busy time information or a published set of - busy time information. - - When used to request free/busy time information, the "ATTENDEE" - property specifies the calendar users whose free/busy time is being - requested; the "ORGANIZER" property specifies the calendar user who - is requesting the free/busy time; the "DTSTART" and "DTEND" - properties specify the window of time for which the free/busy time is - being requested; the "UID" and "DTSTAMP" properties are specified to - assist in proper sequencing of multiple free/busy time requests. - - When used to reply to a request for free/busy time, the "ATTENDEE" - property specifies the calendar user responding to the free/busy time - request; the "ORGANIZER" property specifies the calendar user that - originally requested the free/busy time; the "FREEBUSY" property - specifies the free/busy time information (if it exists); and the - - - -Dawson & Stenerson Standards Track [Page 58] - -RFC 2445 iCalendar November 1998 - - - "UID" and "DTSTAMP" properties are specified to assist in proper - sequencing of multiple free/busy time replies. - - When used to publish busy time, the "ORGANIZER" property specifies - the calendar user associated with the published busy time; the - "DTSTART" and "DTEND" properties specify an inclusive time window - that surrounds the busy time information; the "FREEBUSY" property - specifies the published busy time information; and the "DTSTAMP" - property specifies the date/time that iCalendar object was created. - - The "VFREEBUSY" calendar component cannot be nested within another - calendar component. Multiple "VFREEBUSY" calendar components can be - specified within an iCalendar object. This permits the grouping of - Free/Busy information into logical collections, such as monthly - groups of busy time information. - - The "VFREEBUSY" calendar component is intended for use in iCalendar - object methods involving requests for free time, requests for busy - time, requests for both free and busy, and the associated replies. - - Free/Busy information is represented with the "FREEBUSY" property. - This property provides a terse representation of time periods. One or - more "FREEBUSY" properties can be specified in the "VFREEBUSY" - calendar component. - - When present in a "VFREEBUSY" calendar component, the "DTSTART" and - "DTEND" properties SHOULD be specified prior to any "FREEBUSY" - properties. In a free time request, these properties can be used in - combination with the "DURATION" property to represent a request for a - duration of free time within a specified window of time. - - The recurrence properties ("RRULE", "EXRULE", "RDATE", "EXDATE") are - not permitted within a "VFREEBUSY" calendar component. Any recurring - events are resolved into their individual busy time periods using the - "FREEBUSY" property. - - Example: The following is an example of a "VFREEBUSY" calendar - component used to request free or busy time information: - - BEGIN:VFREEBUSY - ORGANIZER:MAILTO:jane_doe@host1.com - ATTENDEE:MAILTO:john_public@host2.com - DTSTART:19971015T050000Z - DTEND:19971016T050000Z - DTSTAMP:19970901T083000Z - END:VFREEBUSY - - - - - -Dawson & Stenerson Standards Track [Page 59] - -RFC 2445 iCalendar November 1998 - - - The following is an example of a "VFREEBUSY" calendar component used - to reply to the request with busy time information: - - BEGIN:VFREEBUSY - ORGANIZER:MAILTO:jane_doe@host1.com - ATTENDEE:MAILTO:john_public@host2.com - DTSTAMP:19970901T100000Z - FREEBUSY;VALUE=PERIOD:19971015T050000Z/PT8H30M, - 19971015T160000Z/PT5H30M,19971015T223000Z/PT6H30M - URL:http://host2.com/pub/busy/jpublic-01.ifb - COMMENT:This iCalendar file contains busy time information for - the next three months. - END:VFREEBUSY - - The following is an example of a "VFREEBUSY" calendar component used - to publish busy time information. - - BEGIN:VFREEBUSY - ORGANIZER:jsmith@host.com - DTSTART:19980313T141711Z - DTEND:19980410T141711Z - FREEBUSY:19980314T233000Z/19980315T003000Z - FREEBUSY:19980316T153000Z/19980316T163000Z - FREEBUSY:19980318T030000Z/19980318T040000Z - URL:http://www.host.com/calendar/busytime/jsmith.ifb - END:VFREEBUSY - -4.6.5 Time Zone Component - - Component Name: VTIMEZONE - - Purpose: Provide a grouping of component properties that defines a - time zone. - - Formal Definition: A "VTIMEZONE" calendar component is defined by the - following notation: - - timezonec = "BEGIN" ":" "VTIMEZONE" CRLF - - 2*( - - ; 'tzid' is required, but MUST NOT occur more - ; than once - - tzid / - - ; 'last-mod' and 'tzurl' are optional, - but MUST NOT occur more than once - - - -Dawson & Stenerson Standards Track [Page 60] - -RFC 2445 iCalendar November 1998 - - - last-mod / tzurl / - - ; one of 'standardc' or 'daylightc' MUST occur - ..; and each MAY occur more than once. - - standardc / daylightc / - - ; the following is optional, - ; and MAY occur more than once - - x-prop - - ) - - "END" ":" "VTIMEZONE" CRLF - - standardc = "BEGIN" ":" "STANDARD" CRLF - - tzprop - - "END" ":" "STANDARD" CRLF - - daylightc = "BEGIN" ":" "DAYLIGHT" CRLF - - tzprop - - "END" ":" "DAYLIGHT" CRLF - - tzprop = 3*( - - ; the following are each REQUIRED, - ; but MUST NOT occur more than once - - dtstart / tzoffsetto / tzoffsetfrom / - - ; the following are optional, - ; and MAY occur more than once - - comment / rdate / rrule / tzname / x-prop - - ) - - Description: A time zone is unambiguously defined by the set of time - measurement rules determined by the governing body for a given - geographic area. These rules describe at a minimum the base offset - from UTC for the time zone, often referred to as the Standard Time - offset. Many locations adjust their Standard Time forward or backward - by one hour, in order to accommodate seasonal changes in number of - - - -Dawson & Stenerson Standards Track [Page 61] - -RFC 2445 iCalendar November 1998 - - - daylight hours, often referred to as Daylight Saving Time. Some - locations adjust their time by a fraction of an hour. Standard Time - is also known as Winter Time. Daylight Saving Time is also known as - Advanced Time, Summer Time, or Legal Time in certain countries. The - following table shows the changes in time zone rules in effect for - New York City starting from 1967. Each line represents a description - or rule for a particular observance. - - Effective Observance Rule - - Date (Date/Time) Offset Abbreviation - - 1967-* last Sun in Oct, 02:00 -0500 EST - - 1967-1973 last Sun in Apr, 02:00 -0400 EDT - - 1974-1974 Jan 6, 02:00 -0400 EDT - - 1975-1975 Feb 23, 02:00 -0400 EDT - - 1976-1986 last Sun in Apr, 02:00 -0400 EDT - - 1987-* first Sun in Apr, 02:00 -0400 EDT - - Note: The specification of a global time zone registry is not - addressed by this document and is left for future study. - However, implementers may find the Olson time zone database [TZ] - a useful reference. It is an informal, public-domain collection - of time zone information, which is currently being maintained by - volunteer Internet participants, and is used in several - operating systems. This database contains current and historical - time zone information for a wide variety of locations around the - globe; it provides a time zone identifier for every unique time - zone rule set in actual use since 1970, with historical data - going back to the introduction of standard time. - - Interoperability between two calendaring and scheduling applications, - especially for recurring events, to-dos or journal entries, is - dependent on the ability to capture and convey date and time - information in an unambiguous format. The specification of current - time zone information is integral to this behavior. - - If present, the "VTIMEZONE" calendar component defines the set of - Standard Time and Daylight Saving Time observances (or rules) for a - particular time zone for a given interval of time. The "VTIMEZONE" - calendar component cannot be nested within other calendar components. - Multiple "VTIMEZONE" calendar components can exist in an iCalendar - object. In this situation, each "VTIMEZONE" MUST represent a unique - - - -Dawson & Stenerson Standards Track [Page 62] - -RFC 2445 iCalendar November 1998 - - - time zone definition. This is necessary for some classes of events, - such as airline flights, that start in one time zone and end in - another. - - The "VTIMEZONE" calendar component MUST be present if the iCalendar - object contains an RRULE that generates dates on both sides of a time - zone shift (e.g. both in Standard Time and Daylight Saving Time) - unless the iCalendar object intends to convey a floating time (See - the section "4.1.10.11 Time" for proper interpretation of floating - time). It can be present if the iCalendar object does not contain - such a RRULE. In addition, if a RRULE is present, there MUST be valid - time zone information for all recurrence instances. - - The "VTIMEZONE" calendar component MUST include the "TZID" property - and at least one definition of a standard or daylight component. The - standard or daylight component MUST include the "DTSTART", - "TZOFFSETFROM" and "TZOFFSETTO" properties. - - An individual "VTIMEZONE" calendar component MUST be specified for - each unique "TZID" parameter value specified in the iCalendar object. - - Each "VTIMEZONE" calendar component consists of a collection of one - or more sub-components that describe the rule for a particular - observance (either a Standard Time or a Daylight Saving Time - observance). The "STANDARD" sub-component consists of a collection of - properties that describe Standard Time. The "DAYLIGHT" sub-component - consists of a collection of properties that describe Daylight Saving - Time. In general this collection of properties consists of: - - - the first onset date-time for the observance - - - the last onset date-time for the observance, if a last onset - is known. - - - the offset to be applied for the observance - - - a rule that describes the day and time when the observance - takes effect - - - an optional name for the observance - - For a given time zone, there may be multiple unique definitions of - the observances over a period of time. Each observance is described - using either a "STANDARD" or "DAYLIGHT" sub-component. The collection - of these sub-components is used to describe the time zone for a given - period of time. The offset to apply at any given time is found by - locating the observance that has the last onset date and time before - the time in question, and using the offset value from that - - - -Dawson & Stenerson Standards Track [Page 63] - -RFC 2445 iCalendar November 1998 - - - observance. - - The top-level properties in a "VTIMEZONE" calendar component are: - - The mandatory "TZID" property is a text value that uniquely - identifies the VTIMZONE calendar component within the scope of an - iCalendar object. - - The optional "LAST-MODIFIED" property is a UTC value that specifies - the date and time that this time zone definition was last updated. - - The optional "TZURL" property is url value that points to a published - VTIMEZONE definition. TZURL SHOULD refer to a resource that is - accessible by anyone who might need to interpret the object. This - SHOULD NOT normally be a file: URL or other URL that is not widely- - accessible. - - The collection of properties that are used to define the STANDARD and - DAYLIGHT sub-components include: - - The mandatory "DTSTART" property gives the effective onset date and - local time for the time zone sub-component definition. "DTSTART" in - this usage MUST be specified as a local DATE-TIME value. - - The mandatory "TZOFFSETFROM" property gives the UTC offset which is - in use when the onset of this time zone observance begins. - "TZOFFSETFROM" is combined with "DTSTART" to define the effective - onset for the time zone sub-component definition. For example, the - following represents the time at which the observance of Standard - Time took effect in Fall 1967 for New York City: - - DTSTART:19671029T020000 - - TZOFFSETFROM:-0400 - - The mandatory "TZOFFSETTO " property gives the UTC offset for the - time zone sub-component (Standard Time or Daylight Saving Time) when - this observance is in use. - - The optional "TZNAME" property is the customary name for the time - zone. It may be specified multiple times, to allow for specifying - multiple language variants of the time zone names. This could be used - for displaying dates. - - If specified, the onset for the observance defined by the time zone - sub-component is defined by either the "RRULE" or "RDATE" property. - If neither is specified, only one sub-component can be specified in - the "VTIMEZONE" calendar component and it is assumed that the single - - - -Dawson & Stenerson Standards Track [Page 64] - -RFC 2445 iCalendar November 1998 - - - observance specified is always in effect. - - The "RRULE" property defines the recurrence rule for the onset of the - observance defined by this time zone sub-component. Some specific - requirements for the usage of RRULE for this purpose include: - - - If observance is known to have an effective end date, the - "UNTIL" recurrence rule parameter MUST be used to specify the - last valid onset of this observance (i.e., the UNTIL date-time - will be equal to the last instance generated by the recurrence - pattern). It MUST be specified in UTC time. - - - The "DTSTART" and the "TZOFFSETTO" properties MUST be used - when generating the onset date-time values (instances) from the - RRULE. - - Alternatively, the "RDATE" property can be used to define the onset - of the observance by giving the individual onset date and times. - "RDATE" in this usage MUST be specified as a local DATE-TIME value in - UTC time. - - The optional "COMMENT" property is also allowed for descriptive - explanatory text. - - Example: The following are examples of the "VTIMEZONE" calendar - component: - - This is an example showing time zone information for the Eastern - United States using "RDATE" property. Note that this is only suitable - for a recurring event that starts on or later than April 6, 1997 at - 03:00:00 EDT (i.e., the earliest effective transition date and time) - and ends no later than April 7, 1998 02:00:00 EST (i.e., latest valid - date and time for EST in this scenario). For example, this can be - used for a recurring event that occurs every Friday, 8am-9:00 AM, - starting June 1, 1997, ending December 31, 1997. - - BEGIN:VTIMEZONE - TZID:US-Eastern - LAST-MODIFIED:19870101T000000Z - BEGIN:STANDARD - DTSTART:19971026T020000 - RDATE:19971026T020000 - TZOFFSETFROM:-0400 - TZOFFSETTO:-0500 - TZNAME:EST - END:STANDARD - BEGIN:DAYLIGHT - DTSTART:19971026T020000 - - - -Dawson & Stenerson Standards Track [Page 65] - -RFC 2445 iCalendar November 1998 - - - RDATE:19970406T020000 - TZOFFSETFROM:-0500 - TZOFFSETTO:-0400 - TZNAME:EDT - END:DAYLIGHT - END:VTIMEZONE - - This is a simple example showing the current time zone rules for the - Eastern United States using a RRULE recurrence pattern. Note that - there is no effective end date to either of the Standard Time or - Daylight Time rules. This information would be valid for a recurring - event starting today and continuing indefinitely. - - BEGIN:VTIMEZONE - TZID:US-Eastern - LAST-MODIFIED:19870101T000000Z - TZURL:http://zones.stds_r_us.net/tz/US-Eastern - BEGIN:STANDARD - DTSTART:19671029T020000 - RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 - TZOFFSETFROM:-0400 - TZOFFSETTO:-0500 - TZNAME:EST - END:STANDARD - BEGIN:DAYLIGHT - DTSTART:19870405T020000 - RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 - TZOFFSETFROM:-0500 - TZOFFSETTO:-0400 - TZNAME:EDT - END:DAYLIGHT - END:VTIMEZONE - - This is an example showing a fictitious set of rules for the Eastern - United States, where the Daylight Time rule has an effective end date - (i.e., after that date, Daylight Time is no longer observed). - - BEGIN:VTIMEZONE - TZID:US--Fictitious-Eastern - LAST-MODIFIED:19870101T000000Z - BEGIN:STANDARD - DTSTART:19671029T020000 - RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 - TZOFFSETFROM:-0400 - TZOFFSETTO:-0500 - TZNAME:EST - END:STANDARD - - - - -Dawson & Stenerson Standards Track [Page 66] - -RFC 2445 iCalendar November 1998 - - - BEGIN:DAYLIGHT - DTSTART:19870405T020000 - RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T070000Z - TZOFFSETFROM:-0500 - TZOFFSETTO:-0400 - TZNAME:EDT - END:DAYLIGHT - END:VTIMEZONE - - This is an example showing a fictitious set of rules for the Eastern - United States, where the first Daylight Time rule has an effective - end date. There is a second Daylight Time rule that picks up where - the other left off. - - BEGIN:VTIMEZONE - TZID:US--Fictitious-Eastern - LAST-MODIFIED:19870101T000000Z - BEGIN:STANDARD - DTSTART:19671029T020000 - RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 - TZOFFSETFROM:-0400 - TZOFFSETTO:-0500 - TZNAME:EST - END:STANDARD - BEGIN:DAYLIGHT - DTSTART:19870405T020000 - RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T070000Z - TZOFFSETFROM:-0500 - TZOFFSETTO:-0400 - TZNAME:EDT - END:DAYLIGHT - BEGIN:DAYLIGHT - DTSTART:19990424T020000 - RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=4 - TZOFFSETFROM:-0500 - TZOFFSETTO:-0400 - TZNAME:EDT - END:DAYLIGHT - END:VTIMEZONE - -4.6.6 Alarm Component - - Component Name: VALARM - - Purpose: Provide a grouping of component properties that define an - alarm. - - - - - -Dawson & Stenerson Standards Track [Page 67] - -RFC 2445 iCalendar November 1998 - - - Formal Definition: A "VALARM" calendar component is defined by the - following notation: - - alarmc = "BEGIN" ":" "VALARM" CRLF - (audioprop / dispprop / emailprop / procprop) - "END" ":" "VALARM" CRLF - - audioprop = 2*( - - ; 'action' and 'trigger' are both REQUIRED, - ; but MUST NOT occur more than once - - action / trigger / - - ; 'duration' and 'repeat' are both optional, - ; and MUST NOT occur more than once each, - ; but if one occurs, so MUST the other - - duration / repeat / - - ; the following is optional, - ; but MUST NOT occur more than once - - attach / - - ; the following is optional, - ; and MAY occur more than once - - x-prop - - ) - - - - dispprop = 3*( - - ; the following are all REQUIRED, - ; but MUST NOT occur more than once - - action / description / trigger / - - ; 'duration' and 'repeat' are both optional, - ; and MUST NOT occur more than once each, - ; but if one occurs, so MUST the other - - duration / repeat / - - ; the following is optional, - - - -Dawson & Stenerson Standards Track [Page 68] - -RFC 2445 iCalendar November 1998 - - - ; and MAY occur more than once - - *x-prop - - ) - - - - emailprop = 5*( - - ; the following are all REQUIRED, - ; but MUST NOT occur more than once - - action / description / trigger / summary - - ; the following is REQUIRED, - ; and MAY occur more than once - - attendee / - - ; 'duration' and 'repeat' are both optional, - ; and MUST NOT occur more than once each, - ; but if one occurs, so MUST the other - - duration / repeat / - - ; the following are optional, - ; and MAY occur more than once - - attach / x-prop - - ) - - - - procprop = 3*( - - ; the following are all REQUIRED, - ; but MUST NOT occur more than once - - action / attach / trigger / - - ; 'duration' and 'repeat' are both optional, - ; and MUST NOT occur more than once each, - ; but if one occurs, so MUST the other - - duration / repeat / - - - - -Dawson & Stenerson Standards Track [Page 69] - -RFC 2445 iCalendar November 1998 - - - ; 'description' is optional, - ; and MUST NOT occur more than once - - description / - - ; the following is optional, - ; and MAY occur more than once - - x-prop - - ) - - Description: A "VALARM" calendar component is a grouping of component - properties that is a reminder or alarm for an event or a to-do. For - example, it may be used to define a reminder for a pending event or - an overdue to-do. - - The "VALARM" calendar component MUST include the "ACTION" and - "TRIGGER" properties. The "ACTION" property further constrains the - "VALARM" calendar component in the following ways: - - When the action is "AUDIO", the alarm can also include one and only - one "ATTACH" property, which MUST point to a sound resource, which is - rendered when the alarm is triggered. - - When the action is "DISPLAY", the alarm MUST also include a - "DESCRIPTION" property, which contains the text to be displayed when - the alarm is triggered. - - When the action is "EMAIL", the alarm MUST include a "DESCRIPTION" - property, which contains the text to be used as the message body, a - "SUMMARY" property, which contains the text to be used as the message - subject, and one or more "ATTENDEE" properties, which contain the - email address of attendees to receive the message. It can also - include one or more "ATTACH" properties, which are intended to be - sent as message attachments. When the alarm is triggered, the email - message is sent. - - When the action is "PROCEDURE", the alarm MUST include one and only - one "ATTACH" property, which MUST point to a procedure resource, - which is invoked when the alarm is triggered. - - The "VALARM" calendar component MUST only appear within either a - "VEVENT" or "VTODO" calendar component. "VALARM" calendar components - cannot be nested. Multiple mutually independent "VALARM" calendar - components can be specified for a single "VEVENT" or "VTODO" calendar - component. - - - - -Dawson & Stenerson Standards Track [Page 70] - -RFC 2445 iCalendar November 1998 - - - The "TRIGGER" property specifies when the alarm will be triggered. - The "TRIGGER" property specifies a duration prior to the start of an - event or a to-do. The "TRIGGER" edge may be explicitly set to be - relative to the "START" or "END" of the event or to-do with the - "RELATED" parameter of the "TRIGGER" property. The "TRIGGER" property - value type can alternatively be set to an absolute calendar date and - time of day value. - - In an alarm set to trigger on the "START" of an event or to-do, the - "DTSTART" property MUST be present in the associated event or to-do. - In an alarm in a "VEVENT" calendar component set to trigger on the - "END" of the event, either the "DTEND" property MUST be present, or - the "DTSTART" and "DURATION" properties MUST both be present. In an - alarm in a "VTODO" calendar component set to trigger on the "END" of - the to-do, either the "DUE" property MUST be present, or the - "DTSTART" and "DURATION" properties MUST both be present. - - The alarm can be defined such that it triggers repeatedly. A - definition of an alarm with a repeating trigger MUST include both the - "DURATION" and "REPEAT" properties. The "DURATION" property specifies - the delay period, after which the alarm will repeat. The "REPEAT" - property specifies the number of additional repetitions that the - alarm will triggered. This repitition count is in addition to the - initial triggering of the alarm. Both of these properties MUST be - present in order to specify a repeating alarm. If one of these two - properties is absent, then the alarm will not repeat beyond the - initial trigger. - - The "ACTION" property is used within the "VALARM" calendar component - to specify the type of action invoked when the alarm is triggered. - The "VALARM" properties provide enough information for a specific - action to be invoked. It is typically the responsibility of a - "Calendar User Agent" (CUA) to deliver the alarm in the specified - fashion. An "ACTION" property value of AUDIO specifies an alarm that - causes a sound to be played to alert the user; DISPLAY specifies an - alarm that causes a text message to be displayed to the user; EMAIL - specifies an alarm that causes an electronic email message to be - delivered to one or more email addresses; and PROCEDURE specifies an - alarm that causes a procedure to be executed. The "ACTION" property - MUST specify one and only one of these values. - - In an AUDIO alarm, if the optional "ATTACH" property is included, it - MUST specify an audio sound resource. The intention is that the sound - will be played as the alarm effect. If an "ATTACH" property is - specified that does not refer to a sound resource, or if the - specified sound resource cannot be rendered (because its format is - unsupported, or because it cannot be retrieved), then the CUA or - other entity responsible for playing the sound may choose a fallback - - - -Dawson & Stenerson Standards Track [Page 71] - -RFC 2445 iCalendar November 1998 - - - action, such as playing a built-in default sound, or playing no sound - at all. - - In a DISPLAY alarm, the intended alarm effect is for the text value - of the "DESCRIPTION" property to be displayed to the user. - - In an EMAIL alarm, the intended alarm effect is for an email message - to be composed and delivered to all the addresses specified by the - "ATTENDEE" properties in the "VALARM" calendar component. The - "DESCRIPTION" property of the "VALARM" calendar component MUST be - used as the body text of the message, and the "SUMMARY" property MUST - be used as the subject text. Any "ATTACH" properties in the "VALARM" - calendar component SHOULD be sent as attachments to the message. - - In a PROCEDURE alarm, the "ATTACH" property in the "VALARM" calendar - component MUST specify a procedure or program that is intended to be - invoked as the alarm effect. If the procedure or program is in a - format that cannot be rendered, then no procedure alarm will be - invoked. If the "DESCRIPTION" property is present, its value - specifies the argument string to be passed to the procedure or - program. "Calendar User Agents" that receive an iCalendar object with - this category of alarm, can disable or allow the "Calendar User" to - disable, or otherwise ignore this type of alarm. While a very useful - alarm capability, the PROCEDURE type of alarm SHOULD be treated by - the "Calendar User Agent" as a potential security risk. - - Example: The following example is for a "VALARM" calendar component - that specifies an audio alarm that will sound at a precise time and - repeat 4 more times at 15 minute intervals: - - BEGIN:VALARM - TRIGGER;VALUE=DATE-TIME:19970317T133000Z - REPEAT:4 - DURATION:PT15M - ACTION:AUDIO - ATTACH;FMTTYPE=audio/basic:ftp://host.com/pub/sounds/bell-01.aud - END:VALARM - - The following example is for a "VALARM" calendar component that - specifies a display alarm that will trigger 30 minutes before the - scheduled start of the event or the due date/time of the to-do it is - associated with and will repeat 2 more times at 15 minute intervals: - - BEGIN:VALARM - TRIGGER:-PT30M - REPEAT:2 - DURATION:PT15M - ACTION:DISPLAY - - - -Dawson & Stenerson Standards Track [Page 72] - -RFC 2445 iCalendar November 1998 - - - DESCRIPTION:Breakfast meeting with executive\n - team at 8:30 AM EST. - END:VALARM - - The following example is for a "VALARM" calendar component that - specifies an email alarm that will trigger 2 days before the - scheduled due date/time of a to-do it is associated with. It does not - repeat. The email has a subject, body and attachment link. - - BEGIN:VALARM - TRIGGER:-P2D - ACTION:EMAIL - ATTENDEE:MAILTO:john_doe@host.com - SUMMARY:*** REMINDER: SEND AGENDA FOR WEEKLY STAFF MEETING *** - DESCRIPTION:A draft agenda needs to be sent out to the attendees - to the weekly managers meeting (MGR-LIST). Attached is a - pointer the document template for the agenda file. - ATTACH;FMTTYPE=application/binary:http://host.com/templates/agen - da.doc - END:VALARM - - The following example is for a "VALARM" calendar component that - specifies a procedural alarm that will trigger at a precise date/time - and will repeat 23 more times at one hour intervals. The alarm will - invoke a procedure file. - - BEGIN:VALARM - TRIGGER;VALUE=DATE-TIME:19980101T050000Z - REPEAT:23 - DURATION:PT1H - ACTION:PROCEDURE - ATTACH;FMTTYPE=application/binary:ftp://host.com/novo- - procs/felizano.exe - END:VALARM - -4.7 Calendar Properties - - The Calendar Properties are attributes that apply to the iCalendar - object, as a whole. These properties do not appear within a calendar - component. They SHOULD be specified after the "BEGIN:VCALENDAR" - property and prior to any calendar component. - -4.7.1 Calendar Scale - - Property Name: CALSCALE - - Purpose: This property defines the calendar scale used for the - calendar information specified in the iCalendar object. - - - -Dawson & Stenerson Standards Track [Page 73] - -RFC 2445 iCalendar November 1998 - - - Value Type: TEXT - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: Property can be specified in an iCalendar object. The - default value is "GREGORIAN". - - Description: This memo is based on the Gregorian calendar scale. The - Gregorian calendar scale is assumed if this property is not specified - in the iCalendar object. It is expected that other calendar scales - will be defined in other specifications or by future versions of this - memo. - - Format Definition: The property is defined by the following notation: - - calscale = "CALSCALE" calparam ":" calvalue CRLF - - calparam = *(";" xparam) - - calvalue = "GREGORIAN" / iana-token - - Example: The following is an example of this property: - - CALSCALE:GREGORIAN - -4.7.2 Method - - Property Name: METHOD - - Purpose: This property defines the iCalendar object method associated - with the calendar object. - - Value Type: TEXT - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: The property can be specified in an iCalendar object. - - Description: When used in a MIME message entity, the value of this - property MUST be the same as the Content-Type "method" parameter - value. This property can only appear once within the iCalendar - object. If either the "METHOD" property or the Content-Type "method" - parameter is specified, then the other MUST also be specified. - - No methods are defined by this specification. This is the subject of - other specifications, such as the iCalendar Transport-independent - - - -Dawson & Stenerson Standards Track [Page 74] - -RFC 2445 iCalendar November 1998 - - - Interoperability Protocol (iTIP) defined by [ITIP]. - - If this property is not present in the iCalendar object, then a - scheduling transaction MUST NOT be assumed. In such cases, the - iCalendar object is merely being used to transport a snapshot of some - calendar information; without the intention of conveying a scheduling - semantic. - - Format Definition: The property is defined by the following notation: - - method = "METHOD" metparam ":" metvalue CRLF - - metparam = *(";" xparam) - - metvalue = iana-token - - Example: The following is a hypothetical example of this property to - convey that the iCalendar object is a request for a meeting: - - METHOD:REQUEST - -4.7.3 Product Identifier - - Property Name: PRODID - - Purpose: This property specifies the identifier for the product that - created the iCalendar object. - - Value Type: TEXT - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: The property MUST be specified once in an iCalendar - object. - - Description: The vendor of the implementation SHOULD assure that this - is a globally unique identifier; using some technique such as an FPI - value, as defined in [ISO 9070]. - - This property SHOULD not be used to alter the interpretation of an - iCalendar object beyond the semantics specified in this memo. For - example, it is not to be used to further the understanding of non- - standard properties. - - Format Definition: The property is defined by the following notation: - - prodid = "PRODID" pidparam ":" pidvalue CRLF - - - -Dawson & Stenerson Standards Track [Page 75] - -RFC 2445 iCalendar November 1998 - - - pidparam = *(";" xparam) - - pidvalue = text - ;Any text that describes the product and version - ;and that is generally assured of being unique. - - Example: The following is an example of this property. It does not - imply that English is the default language. - - PRODID:-//ABC Corporation//NONSGML My Product//EN - -4.7.4 Version - - Property Name: VERSION - - Purpose: This property specifies the identifier corresponding to the - highest version number or the minimum and maximum range of the - iCalendar specification that is required in order to interpret the - iCalendar object. - - Value Type: TEXT - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property MUST be specified by an iCalendar object, - but MUST only be specified once. - - Description: A value of "2.0" corresponds to this memo. - - Format Definition: The property is defined by the following notation: - - version = "VERSION" verparam ":" vervalue CRLF - - verparam = *(";" xparam) - - vervalue = "2.0" ;This memo - / maxver - / (minver ";" maxver) - - minver = - ;Minimum iCalendar version needed to parse the iCalendar object - - maxver = - ;Maximum iCalendar version needed to parse the iCalendar object - - Example: The following is an example of this property: - - - - -Dawson & Stenerson Standards Track [Page 76] - -RFC 2445 iCalendar November 1998 - - - VERSION:2.0 - -4.8 Component Properties - - The following properties can appear within calendar components, as - specified by each component property definition. - -4.8.1 Descriptive Component Properties - - The following properties specify descriptive information about - calendar components. - -4.8.1.1 Attachment - - Property Name: ATTACH - - Purpose: The property provides the capability to associate a document - object with a calendar component. - - Value Type: The default value type for this property is URI. The - value type can also be set to BINARY to indicate inline binary - encoded content information. - - Property Parameters: Non-standard, inline encoding, format type and - value data type property parameters can be specified on this - property. - - Conformance: The property can be specified in a "VEVENT", "VTODO", - "VJOURNAL" or "VALARM" calendar components. - - Description: The property can be specified within "VEVENT", "VTODO", - "VJOURNAL", or "VALARM" calendar components. This property can be - specified multiple times within an iCalendar object. - - Format Definition: The property is defined by the following notation: - - attach = "ATTACH" attparam ":" uri CRLF - - attach =/ "ATTACH" attparam ";" "ENCODING" "=" "BASE64" - ";" "VALUE" "=" "BINARY" ":" binary - - attparam = *( - - ; the following is optional, - ; but MUST NOT occur more than once - - (";" fmttypeparam) / - - - - -Dawson & Stenerson Standards Track [Page 77] - -RFC 2445 iCalendar November 1998 - - - ; the following is optional, - ; and MAY occur more than once - - (";" xparam) - - ) - - Example: The following are examples of this property: - - ATTACH:CID:jsmith.part3.960817T083000.xyzMail@host1.com - - ATTACH;FMTTYPE=application/postscript:ftp://xyzCorp.com/pub/ - reports/r-960812.ps - -4.8.1.2 Categories - - Property Name: CATEGORIES - - Purpose: This property defines the categories for a calendar - component. - - Value Type: TEXT - - Property Parameters: Non-standard and language property parameters - can be specified on this property. - - Conformance: The property can be specified within "VEVENT", "VTODO" - or "VJOURNAL" calendar components. - - Description: This property is used to specify categories or subtypes - of the calendar component. The categories are useful in searching for - a calendar component of a particular type and category. Within the - "VEVENT", "VTODO" or "VJOURNAL" calendar components, more than one - category can be specified as a list of categories separated by the - COMMA character (US-ASCII decimal 44). - - Format Definition: The property is defined by the following notation: - - categories = "CATEGORIES" catparam ":" text *("," text) - CRLF - - catparam = *( - - ; the following is optional, - ; but MUST NOT occur more than once - - (";" languageparam ) / - - - - -Dawson & Stenerson Standards Track [Page 78] - -RFC 2445 iCalendar November 1998 - - - ; the following is optional, - ; and MAY occur more than once - - (";" xparam) - - ) - - Example: The following are examples of this property: - - CATEGORIES:APPOINTMENT,EDUCATION - - CATEGORIES:MEETING - -4.8.1.3 Classification - - Property Name: CLASS - - Purpose: This property defines the access classification for a - calendar component. - - Value Type: TEXT - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: The property can be specified once in a "VEVENT", - "VTODO" or "VJOURNAL" calendar components. - - Description: An access classification is only one component of the - general security system within a calendar application. It provides a - method of capturing the scope of the access the calendar owner - intends for information within an individual calendar entry. The - access classification of an individual iCalendar component is useful - when measured along with the other security components of a calendar - system (e.g., calendar user authentication, authorization, access - rights, access role, etc.). Hence, the semantics of the individual - access classifications cannot be completely defined by this memo - alone. Additionally, due to the "blind" nature of most exchange - processes using this memo, these access classifications cannot serve - as an enforcement statement for a system receiving an iCalendar - object. Rather, they provide a method for capturing the intention of - the calendar owner for the access to the calendar component. - - Format Definition: The property is defined by the following notation: - - class = "CLASS" classparam ":" classvalue CRLF - - classparam = *(";" xparam) - - - -Dawson & Stenerson Standards Track [Page 79] - -RFC 2445 iCalendar November 1998 - - - classvalue = "PUBLIC" / "PRIVATE" / "CONFIDENTIAL" / iana-token - / x-name - ;Default is PUBLIC - - Example: The following is an example of this property: - - CLASS:PUBLIC - -4.8.1.4 Comment - - Property Name: COMMENT - - Purpose: This property specifies non-processing information intended - to provide a comment to the calendar user. - - Value Type: TEXT - - Property Parameters: Non-standard, alternate text representation and - language property parameters can be specified on this property. - - Conformance: This property can be specified in "VEVENT", "VTODO", - "VJOURNAL", "VTIMEZONE" or "VFREEBUSY" calendar components. - - Description: The property can be specified multiple times. - - Format Definition: The property is defined by the following notation: - - comment = "COMMENT" commparam ":" text CRLF - - commparam = *( - - ; the following are optional, - ; but MUST NOT occur more than once - - (";" altrepparam) / (";" languageparam) / - - ; the following is optional, - ; and MAY occur more than once - - (";" xparam) - - ) - - Example: The following is an example of this property: - - COMMENT:The meeting really needs to include both ourselves - and the customer. We can't hold this meeting without them. - As a matter of fact\, the venue for the meeting ought to be at - - - -Dawson & Stenerson Standards Track [Page 80] - -RFC 2445 iCalendar November 1998 - - - their site. - - John - - The data type for this property is TEXT. - -4.8.1.5 Description - - Property Name: DESCRIPTION - - Purpose: This property provides a more complete description of the - calendar component, than that provided by the "SUMMARY" property. - - Value Type: TEXT - - Property Parameters: Non-standard, alternate text representation and - language property parameters can be specified on this property. - - Conformance: The property can be specified in the "VEVENT", "VTODO", - "VJOURNAL" or "VALARM" calendar components. The property can be - specified multiple times only within a "VJOURNAL" calendar component. - - Description: This property is used in the "VEVENT" and "VTODO" to - capture lengthy textual decriptions associated with the activity. - - This property is used in the "VJOURNAL" calendar component to capture - one more textual journal entries. - - This property is used in the "VALARM" calendar component to capture - the display text for a DISPLAY category of alarm, to capture the body - text for an EMAIL category of alarm and to capture the argument - string for a PROCEDURE category of alarm. - - Format Definition: The property is defined by the following notation: - - description = "DESCRIPTION" descparam ":" text CRLF - - descparam = *( - - ; the following are optional, - ; but MUST NOT occur more than once - - (";" altrepparam) / (";" languageparam) / - - ; the following is optional, - ; and MAY occur more than once - - (";" xparam) - - ) - - - -Dawson & Stenerson Standards Track [Page 81] - -RFC 2445 iCalendar November 1998 - - - Example: The following is an example of the property with formatted - line breaks in the property value: - - DESCRIPTION:Meeting to provide technical review for "Phoenix" - design.\n Happy Face Conference Room. Phoenix design team - MUST attend this meeting.\n RSVP to team leader. - - The following is an example of the property with folding of long - lines: - - DESCRIPTION:Last draft of the new novel is to be completed - for the editor's proof today. - -4.8.1.6 Geographic Position - - Property Name: GEO - - Purpose: This property specifies information related to the global - position for the activity specified by a calendar component. - - Value Type: FLOAT. The value MUST be two SEMICOLON separated FLOAT - values. - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property can be specified in "VEVENT" or "VTODO" - calendar components. - - Description: The property value specifies latitude and longitude, in - that order (i.e., "LAT LON" ordering). The longitude represents the - location east or west of the prime meridian as a positive or negative - real number, respectively. The longitude and latitude values MAY be - specified up to six decimal places, which will allow for accuracy to - within one meter of geographical position. Receiving applications - MUST accept values of this precision and MAY truncate values of - greater precision. - - Values for latitude and longitude shall be expressed as decimal - fractions of degrees. Whole degrees of latitude shall be represented - by a two-digit decimal number ranging from 0 through 90. Whole - degrees of longitude shall be represented by a decimal number ranging - from 0 through 180. When a decimal fraction of a degree is specified, - it shall be separated from the whole number of degrees by a decimal - point. - - - - - - -Dawson & Stenerson Standards Track [Page 82] - -RFC 2445 iCalendar November 1998 - - - Latitudes north of the equator shall be specified by a plus sign (+), - or by the absence of a minus sign (-), preceding the digits - designating degrees. Latitudes south of the Equator shall be - designated by a minus sign (-) preceding the digits designating - degrees. A point on the Equator shall be assigned to the Northern - Hemisphere. - - Longitudes east of the prime meridian shall be specified by a plus - sign (+), or by the absence of a minus sign (-), preceding the digits - designating degrees. Longitudes west of the meridian shall be - designated by minus sign (-) preceding the digits designating - degrees. A point on the prime meridian shall be assigned to the - Eastern Hemisphere. A point on the 180th meridian shall be assigned - to the Western Hemisphere. One exception to this last convention is - permitted. For the special condition of describing a band of latitude - around the earth, the East Bounding Coordinate data element shall be - assigned the value +180 (180) degrees. - - Any spatial address with a latitude of +90 (90) or -90 degrees will - specify the position at the North or South Pole, respectively. The - component for longitude may have any legal value. - - With the exception of the special condition described above, this - form is specified in Department of Commerce, 1986, Representation of - geographic point locations for information interchange (Federal - Information Processing Standard 70-1): Washington, Department of - Commerce, National Institute of Standards and Technology. - - The simple formula for converting degrees-minutes-seconds into - decimal degrees is: - - decimal = degrees + minutes/60 + seconds/3600. - - Format Definition: The property is defined by the following notation: - - geo = "GEO" geoparam ":" geovalue CRLF - - geoparam = *(";" xparam) - - geovalue = float ";" float - ;Latitude and Longitude components - - Example: The following is an example of this property: - - GEO:37.386013;-122.082932 - - - - - - -Dawson & Stenerson Standards Track [Page 83] - -RFC 2445 iCalendar November 1998 - - -4.8.1.7 Location - - Property Name: LOCATION - - Purpose: The property defines the intended venue for the activity - defined by a calendar component. - - Value Type: TEXT - - Property Parameters: Non-standard, alternate text representation and - language property parameters can be specified on this property. - - Conformance: This property can be specified in "VEVENT" or "VTODO" - calendar component. - - Description: Specific venues such as conference or meeting rooms may - be explicitly specified using this property. An alternate - representation may be specified that is a URI that points to - directory information with more structured specification of the - location. For example, the alternate representation may specify - either an LDAP URI pointing to an LDAP server entry or a CID URI - pointing to a MIME body part containing a vCard [RFC 2426] for the - location. - - Format Definition: The property is defined by the following notation: - - location = "LOCATION locparam ":" text CRLF - - locparam = *( - - ; the following are optional, - ; but MUST NOT occur more than once - - (";" altrepparam) / (";" languageparam) / - - ; the following is optional, - ; and MAY occur more than once - - (";" xparam) - - ) - - Example: The following are some examples of this property: - - LOCATION:Conference Room - F123, Bldg. 002 - - LOCATION;ALTREP="http://xyzcorp.com/conf-rooms/f123.vcf": - Conference Room - F123, Bldg. 002 - - - -Dawson & Stenerson Standards Track [Page 84] - -RFC 2445 iCalendar November 1998 - - -4.8.1.8 Percent Complete - - Property Name: PERCENT-COMPLETE - - Purpose: This property is used by an assignee or delegatee of a to-do - to convey the percent completion of a to-do to the Organizer. - - Value Type: INTEGER - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property can be specified in a "VTODO" calendar - component. - - Description: The property value is a positive integer between zero - and one hundred. A value of "0" indicates the to-do has not yet been - started. A value of "100" indicates that the to-do has been - completed. Integer values in between indicate the percent partially - complete. - - When a to-do is assigned to multiple individuals, the property value - indicates the percent complete for that portion of the to-do assigned - to the assignee or delegatee. For example, if a to-do is assigned to - both individuals "A" and "B". A reply from "A" with a percent - complete of "70" indicates that "A" has completed 70% of the to-do - assigned to them. A reply from "B" with a percent complete of "50" - indicates "B" has completed 50% of the to-do assigned to them. - - Format Definition: The property is defined by the following notation: - - percent = "PERCENT-COMPLETE" pctparam ":" integer CRLF - - pctparam = *(";" xparam) - - Example: The following is an example of this property to show 39% - completion: - - PERCENT-COMPLETE:39 - -4.8.1.9 Priority - - Property Name: PRIORITY - - Purpose: The property defines the relative priority for a calendar - component. - - Value Type: INTEGER - - - -Dawson & Stenerson Standards Track [Page 85] - -RFC 2445 iCalendar November 1998 - - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: The property can be specified in a "VEVENT" or "VTODO" - calendar component. - - Description: The priority is specified as an integer in the range - zero to nine. A value of zero (US-ASCII decimal 48) specifies an - undefined priority. A value of one (US-ASCII decimal 49) is the - highest priority. A value of two (US-ASCII decimal 50) is the second - highest priority. Subsequent numbers specify a decreasing ordinal - priority. A value of nine (US-ASCII decimal 58) is the lowest - priority. - - A CUA with a three-level priority scheme of "HIGH", "MEDIUM" and - "LOW" is mapped into this property such that a property value in the - range of one (US-ASCII decimal 49) to four (US-ASCII decimal 52) - specifies "HIGH" priority. A value of five (US-ASCII decimal 53) is - the normal or "MEDIUM" priority. A value in the range of six (US- - ASCII decimal 54) to nine (US-ASCII decimal 58) is "LOW" priority. - - A CUA with a priority schema of "A1", "A2", "A3", "B1", "B2", ..., - "C3" is mapped into this property such that a property value of one - (US-ASCII decimal 49) specifies "A1", a property value of two (US- - ASCII decimal 50) specifies "A2", a property value of three (US-ASCII - decimal 51) specifies "A3", and so forth up to a property value of 9 - (US-ASCII decimal 58) specifies "C3". - - Other integer values are reserved for future use. - - Within a "VEVENT" calendar component, this property specifies a - priority for the event. This property may be useful when more than - one event is scheduled for a given time period. - - Within a "VTODO" calendar component, this property specified a - priority for the to-do. This property is useful in prioritizing - multiple action items for a given time period. - - Format Definition: The property is specified by the following - notation: - - priority = "PRIORITY" prioparam ":" privalue CRLF - ;Default is zero - - prioparam = *(";" xparam) - - privalue = integer ;Must be in the range [0..9] - ; All other values are reserved for future use - - - -Dawson & Stenerson Standards Track [Page 86] - -RFC 2445 iCalendar November 1998 - - - The following is an example of a property with the highest priority: - - PRIORITY:1 - - The following is an example of a property with a next highest - priority: - - PRIORITY:2 - - Example: The following is an example of a property with no priority. - This is equivalent to not specifying the "PRIORITY" property: - - PRIORITY:0 - -4.8.1.10 Resources - - Property Name: RESOURCES - - Purpose: This property defines the equipment or resources anticipated - for an activity specified by a calendar entity.. - - Value Type: TEXT - - Property Parameters: Non-standard, alternate text representation and - language property parameters can be specified on this property. - - Conformance: This property can be specified in "VEVENT" or "VTODO" - calendar component. - - Description: The property value is an arbitrary text. More than one - resource can be specified as a list of resources separated by the - COMMA character (US-ASCII decimal 44). - - Format Definition: The property is defined by the following notation: - - resources = "RESOURCES" resrcparam ":" text *("," text) CRLF - - resrcparam = *( - - ; the following are optional, - ; but MUST NOT occur more than once - - (";" altrepparam) / (";" languageparam) / - - ; the following is optional, - ; and MAY occur more than once - - - - - -Dawson & Stenerson Standards Track [Page 87] - -RFC 2445 iCalendar November 1998 - - - (";" xparam) - - ) - - Example: The following is an example of this property: - - RESOURCES:EASEL,PROJECTOR,VCR - - RESOURCES;LANGUAGE=fr:1 raton-laveur - -4.8.1.11 Status - - Property Name: STATUS - - Purpose: This property defines the overall status or confirmation for - the calendar component. - - Value Type: TEXT - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property can be specified in "VEVENT", "VTODO" or - "VJOURNAL" calendar components. - - Description: In a group scheduled calendar component, the property is - used by the "Organizer" to provide a confirmation of the event to the - "Attendees". For example in a "VEVENT" calendar component, the - "Organizer" can indicate that a meeting is tentative, confirmed or - cancelled. In a "VTODO" calendar component, the "Organizer" can - indicate that an action item needs action, is completed, is in - process or being worked on, or has been cancelled. In a "VJOURNAL" - calendar component, the "Organizer" can indicate that a journal entry - is draft, final or has been cancelled or removed. - - Format Definition: The property is defined by the following notation: - - status = "STATUS" statparam] ":" statvalue CRLF - - statparam = *(";" xparam) - - statvalue = "TENTATIVE" ;Indicates event is - ;tentative. - / "CONFIRMED" ;Indicates event is - ;definite. - / "CANCELLED" ;Indicates event was - ;cancelled. - ;Status values for a "VEVENT" - - - -Dawson & Stenerson Standards Track [Page 88] - -RFC 2445 iCalendar November 1998 - - - statvalue =/ "NEEDS-ACTION" ;Indicates to-do needs action. - / "COMPLETED" ;Indicates to-do completed. - / "IN-PROCESS" ;Indicates to-do in process of - / "CANCELLED" ;Indicates to-do was cancelled. - ;Status values for "VTODO". - - statvalue =/ "DRAFT" ;Indicates journal is draft. - / "FINAL" ;Indicates journal is final. - / "CANCELLED" ;Indicates journal is removed. - ;Status values for "VJOURNAL". - - Example: The following is an example of this property for a "VEVENT" - calendar component: - - STATUS:TENTATIVE - - The following is an example of this property for a "VTODO" calendar - component: - - STATUS:NEEDS-ACTION - - The following is an example of this property for a "VJOURNAL" - calendar component: - - STATUS:DRAFT - -4.8.1.12 Summary - - Property Name: SUMMARY - - Purpose: This property defines a short summary or subject for the - calendar component. - - Value Type: TEXT - - Property Parameters: Non-standard, alternate text representation and - language property parameters can be specified on this property. - - Conformance: The property can be specified in "VEVENT", "VTODO", - "VJOURNAL" or "VALARM" calendar components. - - Description: This property is used in the "VEVENT", "VTODO" and - "VJOURNAL" calendar components to capture a short, one line summary - about the activity or journal entry. - - This property is used in the "VALARM" calendar component to capture - the subject of an EMAIL category of alarm. - - - - -Dawson & Stenerson Standards Track [Page 89] - -RFC 2445 iCalendar November 1998 - - - Format Definition: The property is defined by the following notation: - - summary = "SUMMARY" summparam ":" text CRLF - - summparam = *( - - ; the following are optional, - ; but MUST NOT occur more than once - - (";" altrepparam) / (";" languageparam) / - - ; the following is optional, - ; and MAY occur more than once - - (";" xparam) - - ) - - Example: The following is an example of this property: - - SUMMARY:Department Party - -4.8.2 Date and Time Component Properties - - The following properties specify date and time related information in - calendar components. - -4.8.2.1 Date/Time Completed - - Property Name: COMPLETED - - Purpose: This property defines the date and time that a to-do was - actually completed. - - Value Type: DATE-TIME - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: The property can be specified in a "VTODO" calendar - component. - - Description: The date and time MUST be in a UTC format. - - Format Definition: The property is defined by the following notation: - - completed = "COMPLETED" compparam ":" date-time CRLF - - - - -Dawson & Stenerson Standards Track [Page 90] - -RFC 2445 iCalendar November 1998 - - - compparam = *(";" xparam) - - Example: The following is an example of this property: - - COMPLETED:19960401T235959Z - -4.8.2.2 Date/Time End - - Property Name: DTEND - - Purpose: This property specifies the date and time that a calendar - component ends. - - Value Type: The default value type is DATE-TIME. The value type can - be set to a DATE value type. - - Property Parameters: Non-standard, value data type, time zone - identifier property parameters can be specified on this property. - - Conformance: This property can be specified in "VEVENT" or - "VFREEBUSY" calendar components. - - Description: Within the "VEVENT" calendar component, this property - defines the date and time by which the event ends. The value MUST be - later in time than the value of the "DTSTART" property. - - Within the "VFREEBUSY" calendar component, this property defines the - end date and time for the free or busy time information. The time - MUST be specified in the UTC time format. The value MUST be later in - time than the value of the "DTSTART" property. - - Format Definition: The property is defined by the following notation: - - dtend = "DTEND" dtendparam":" dtendval CRLF - - dtendparam = *( - - ; the following are optional, - ; but MUST NOT occur more than once - - (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / - (";" tzidparam) / - - ; the following is optional, - ; and MAY occur more than once - - - - - - -Dawson & Stenerson Standards Track [Page 91] - -RFC 2445 iCalendar November 1998 - - - (";" xparam) - - ) - - - - dtendval = date-time / date - ;Value MUST match value type - - Example: The following is an example of this property: - - DTEND:19960401T235959Z - - DTEND;VALUE=DATE:19980704 - -4.8.2.3 Date/Time Due - - Property Name: DUE - - Purpose: This property defines the date and time that a to-do is - expected to be completed. - - Value Type: The default value type is DATE-TIME. The value type can - be set to a DATE value type. - - Property Parameters: Non-standard, value data type, time zone - identifier property parameters can be specified on this property. - - Conformance: The property can be specified once in a "VTODO" calendar - component. - - Description: The value MUST be a date/time equal to or after the - DTSTART value, if specified. - - Format Definition: The property is defined by the following notation: - - due = "DUE" dueparam":" dueval CRLF - - dueparam = *( - ; the following are optional, - ; but MUST NOT occur more than once - - (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / - (";" tzidparam) / - - ; the following is optional, - ; and MAY occur more than once - - - - -Dawson & Stenerson Standards Track [Page 92] - -RFC 2445 iCalendar November 1998 - - - *(";" xparam) - - ) - - - - dueval = date-time / date - ;Value MUST match value type - - Example: The following is an example of this property: - - DUE:19980430T235959Z - -4.8.2.4 Date/Time Start - - Property Name: DTSTART - - Purpose: This property specifies when the calendar component begins. - - Value Type: The default value type is DATE-TIME. The time value MUST - be one of the forms defined for the DATE-TIME value type. The value - type can be set to a DATE value type. - - Property Parameters: Non-standard, value data type, time zone - identifier property parameters can be specified on this property. - - Conformance: This property can be specified in the "VEVENT", "VTODO", - "VFREEBUSY", or "VTIMEZONE" calendar components. - - Description: Within the "VEVENT" calendar component, this property - defines the start date and time for the event. The property is - REQUIRED in "VEVENT" calendar components. Events can have a start - date/time but no end date/time. In that case, the event does not take - up any time. - - Within the "VFREEBUSY" calendar component, this property defines the - start date and time for the free or busy time information. The time - MUST be specified in UTC time. - - Within the "VTIMEZONE" calendar component, this property defines the - effective start date and time for a time zone specification. This - property is REQUIRED within each STANDARD and DAYLIGHT part included - in "VTIMEZONE" calendar components and MUST be specified as a local - DATE-TIME without the "TZID" property parameter. - - Format Definition: The property is defined by the following notation: - - dtstart = "DTSTART" dtstparam ":" dtstval CRLF - - - -Dawson & Stenerson Standards Track [Page 93] - -RFC 2445 iCalendar November 1998 - - - dtstparam = *( - - ; the following are optional, - ; but MUST NOT occur more than once - - (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / - (";" tzidparam) / - - ; the following is optional, - ; and MAY occur more than once - - *(";" xparam) - - ) - - - - dtstval = date-time / date - ;Value MUST match value type - - Example: The following is an example of this property: - - DTSTART:19980118T073000Z - -4.8.2.5 Duration - - Property Name: DURATION - - Purpose: The property specifies a positive duration of time. - - Value Type: DURATION - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: The property can be specified in "VEVENT", "VTODO", - "VFREEBUSY" or "VALARM" calendar components. - - Description: In a "VEVENT" calendar component the property may be - used to specify a duration of the event, instead of an explicit end - date/time. In a "VTODO" calendar component the property may be used - to specify a duration for the to-do, instead of an explicit due - date/time. In a "VFREEBUSY" calendar component the property may be - used to specify the interval of free time being requested. In a - "VALARM" calendar component the property may be used to specify the - delay period prior to repeating an alarm. - - Format Definition: The property is defined by the following notation: - - - -Dawson & Stenerson Standards Track [Page 94] - -RFC 2445 iCalendar November 1998 - - - duration = "DURATION" durparam ":" dur-value CRLF - ;consisting of a positive duration of time. - - durparam = *(";" xparam) - - Example: The following is an example of this property that specifies - an interval of time of 1 hour and zero minutes and zero seconds: - - DURATION:PT1H0M0S - - The following is an example of this property that specifies an - interval of time of 15 minutes. - - DURATION:PT15M - -4.8.2.6 Free/Busy Time - - Property Name: FREEBUSY - - Purpose: The property defines one or more free or busy time - intervals. - - Value Type: PERIOD. The date and time values MUST be in an UTC time - format. - - Property Parameters: Non-standard or free/busy time type property - parameters can be specified on this property. - - Conformance: The property can be specified in a "VFREEBUSY" calendar - component. - - Property Parameter: "FBTYPE" and non-standard parameters can be - specified on this property. - - Description: These time periods can be specified as either a start - and end date-time or a start date-time and duration. The date and - time MUST be a UTC time format. - - "FREEBUSY" properties within the "VFREEBUSY" calendar component - SHOULD be sorted in ascending order, based on start time and then end - time, with the earliest periods first. - - The "FREEBUSY" property can specify more than one value, separated by - the COMMA character (US-ASCII decimal 44). In such cases, the - "FREEBUSY" property values SHOULD all be of the same "FBTYPE" - property parameter type (e.g., all values of a particular "FBTYPE" - listed together in a single property). - - - - -Dawson & Stenerson Standards Track [Page 95] - -RFC 2445 iCalendar November 1998 - - - Format Definition: The property is defined by the following notation: - - freebusy = "FREEBUSY" fbparam ":" fbvalue - CRLF - - fbparam = *( - ; the following is optional, - ; but MUST NOT occur more than once - - (";" fbtypeparam) / - - ; the following is optional, - ; and MAY occur more than once - - (";" xparam) - - ) - - fbvalue = period *["," period] - ;Time value MUST be in the UTC time format. - - Example: The following are some examples of this property: - - FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:19970308T160000Z/PT8H30M - - FREEBUSY;FBTYPE=FREE:19970308T160000Z/PT3H,19970308T200000Z/PT1H - - FREEBUSY;FBTYPE=FREE:19970308T160000Z/PT3H,19970308T200000Z/PT1H, - 19970308T230000Z/19970309T000000Z - -4.8.2.7 Time Transparency - - Property Name: TRANSP - - Purpose: This property defines whether an event is transparent or not - to busy time searches. - - Value Type: TEXT - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property can be specified once in a "VEVENT" - calendar component. - - Description: Time Transparency is the characteristic of an event that - determines whether it appears to consume time on a calendar. Events - that consume actual time for the individual or resource associated - - - -Dawson & Stenerson Standards Track [Page 96] - -RFC 2445 iCalendar November 1998 - - - with the calendar SHOULD be recorded as OPAQUE, allowing them to be - detected by free-busy time searches. Other events, which do not take - up the individual's (or resource's) time SHOULD be recorded as - TRANSPARENT, making them invisible to free-busy time searches. - - Format Definition: The property is specified by the following - notation: - - transp = "TRANSP" tranparam ":" transvalue CRLF - - tranparam = *(";" xparam) - - transvalue = "OPAQUE" ;Blocks or opaque on busy time searches. - / "TRANSPARENT" ;Transparent on busy time searches. - ;Default value is OPAQUE - - Example: The following is an example of this property for an event - that is transparent or does not block on free/busy time searches: - - TRANSP:TRANSPARENT - - The following is an example of this property for an event that is - opaque or blocks on free/busy time searches: - - TRANSP:OPAQUE - -4.8.3 Time Zone Component Properties - - The following properties specify time zone information in calendar - components. - -4.8.3.1 Time Zone Identifier - - Property Name: TZID - - Purpose: This property specifies the text value that uniquely - identifies the "VTIMEZONE" calendar component. - - Value Type: TEXT - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property MUST be specified in a "VTIMEZONE" - calendar component. - - - - - - -Dawson & Stenerson Standards Track [Page 97] - -RFC 2445 iCalendar November 1998 - - - Description: This is the label by which a time zone calendar - component is referenced by any iCalendar properties whose data type - is either DATE-TIME or TIME and not intended to specify a UTC or a - "floating" time. The presence of the SOLIDUS character (US-ASCII - decimal 47) as a prefix, indicates that this TZID represents an - unique ID in a globally defined time zone registry (when such - registry is defined). - - Note: This document does not define a naming convention for time - zone identifiers. Implementers may want to use the naming - conventions defined in existing time zone specifications such as - the public-domain Olson database [TZ]. The specification of - globally unique time zone identifiers is not addressed by this - document and is left for future study. - - Format Definition: This property is defined by the following - notation: - - tzid = "TZID" tzidpropparam ":" [tzidprefix] text CRLF - - tzidpropparam = *(";" xparam) - - ;tzidprefix = "/" - ; Defined previously. Just listed here for reader convenience. - - Example: The following are examples of non-globally unique time zone - identifiers: - - TZID:US-Eastern - - TZID:California-Los_Angeles - - The following is an example of a fictitious globally unique time zone - identifier: - - TZID:/US-New_York-New_York - -4.8.3.2 Time Zone Name - - Property Name: TZNAME - - Purpose: This property specifies the customary designation for a time - zone description. - - Value Type: TEXT - - Property Parameters: Non-standard and language property parameters - can be specified on this property. - - - -Dawson & Stenerson Standards Track [Page 98] - -RFC 2445 iCalendar November 1998 - - - Conformance: This property can be specified in a "VTIMEZONE" calendar - component. - - Description: This property may be specified in multiple languages; in - order to provide for different language requirements. - - Format Definition: This property is defined by the following - notation: - - tzname = "TZNAME" tznparam ":" text CRLF - - tznparam = *( - - ; the following is optional, - ; but MUST NOT occur more than once - - (";" languageparam) / - - ; the following is optional, - ; and MAY occur more than once - - (";" xparam) - - ) - - Example: The following are example of this property: - - TZNAME:EST - - The following is an example of this property when two different - languages for the time zone name are specified: - - TZNAME;LANGUAGE=en:EST - TZNAME;LANGUAGE=fr-CA:HNE - -4.8.3.3 Time Zone Offset From - - Property Name: TZOFFSETFROM - - Purpose: This property specifies the offset which is in use prior to - this time zone observance. - - Value Type: UTC-OFFSET - - Property Parameters: Non-standard property parameters can be - specified on this property. - - - - - -Dawson & Stenerson Standards Track [Page 99] - -RFC 2445 iCalendar November 1998 - - - Conformance: This property MUST be specified in a "VTIMEZONE" - calendar component. - - Description: This property specifies the offset which is in use prior - to this time observance. It is used to calculate the absolute time at - which the transition to a given observance takes place. This property - MUST only be specified in a "VTIMEZONE" calendar component. A - "VTIMEZONE" calendar component MUST include this property. The - property value is a signed numeric indicating the number of hours and - possibly minutes from UTC. Positive numbers represent time zones east - of the prime meridian, or ahead of UTC. Negative numbers represent - time zones west of the prime meridian, or behind UTC. - - Format Definition: The property is defined by the following notation: - - tzoffsetfrom = "TZOFFSETFROM" frmparam ":" utc-offset - CRLF - - frmparam = *(";" xparam) - - Example: The following are examples of this property: - - TZOFFSETFROM:-0500 - - TZOFFSETFROM:+1345 - -4.8.3.4 Time Zone Offset To - - Property Name: TZOFFSETTO - - Purpose: This property specifies the offset which is in use in this - time zone observance. - - Value Type: UTC-OFFSET - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property MUST be specified in a "VTIMEZONE" - calendar component. - - Description: This property specifies the offset which is in use in - this time zone observance. It is used to calculate the absolute time - for the new observance. The property value is a signed numeric - indicating the number of hours and possibly minutes from UTC. - Positive numbers represent time zones east of the prime meridian, or - ahead of UTC. Negative numbers represent time zones west of the prime - meridian, or behind UTC. - - - -Dawson & Stenerson Standards Track [Page 100] - -RFC 2445 iCalendar November 1998 - - - Format Definition: The property is defined by the following notation: - - tzoffsetto = "TZOFFSETTO" toparam ":" utc-offset CRLF - - toparam = *(";" xparam) - - Example: The following are examples of this property: - - TZOFFSETTO:-0400 - - TZOFFSETTO:+1245 - -4.8.3.5 Time Zone URL - - Property Name: TZURL - - Purpose: The TZURL provides a means for a VTIMEZONE component to - point to a network location that can be used to retrieve an up-to- - date version of itself. - - Value Type: URI - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property can be specified in a "VTIMEZONE" calendar - component. - - Description: The TZURL provides a means for a VTIMEZONE component to - point to a network location that can be used to retrieve an up-to- - date version of itself. This provides a hook to handle changes - government bodies impose upon time zone definitions. Retrieval of - this resource results in an iCalendar object containing a single - VTIMEZONE component and a METHOD property set to PUBLISH. - - Format Definition: The property is defined by the following notation: - - tzurl = "TZURL" tzurlparam ":" uri CRLF - - tzurlparam = *(";" xparam) - - Example: The following is an example of this property: - - TZURL:http://timezones.r.us.net/tz/US-California-Los_Angeles - - - - - - - -Dawson & Stenerson Standards Track [Page 101] - -RFC 2445 iCalendar November 1998 - - -4.8.4 Relationship Component Properties - - The following properties specify relationship information in calendar - components. - -4.8.4.1 Attendee - - Property Name: ATTENDEE - - Purpose: The property defines an "Attendee" within a calendar - component. - - Value Type: CAL-ADDRESS - - Property Parameters: Non-standard, language, calendar user type, - group or list membership, participation role, participation status, - RSVP expectation, delegatee, delegator, sent by, common name or - directory entry reference property parameters can be specified on - this property. - - Conformance: This property MUST be specified in an iCalendar object - that specifies a group scheduled calendar entity. This property MUST - NOT be specified in an iCalendar object when publishing the calendar - information (e.g., NOT in an iCalendar object that specifies the - publication of a calendar user's busy time, event, to-do or journal). - This property is not specified in an iCalendar object that specifies - only a time zone definition or that defines calendar entities that - are not group scheduled entities, but are entities only on a single - user's calendar. - - Description: The property MUST only be specified within calendar - components to specify participants, non-participants and the chair of - a group scheduled calendar entity. The property is specified within - an "EMAIL" category of the "VALARM" calendar component to specify an - email address that is to receive the email type of iCalendar alarm. - - The property parameter CN is for the common or displayable name - associated with the calendar address; ROLE, for the intended role - that the attendee will have in the calendar component; PARTSTAT, for - the status of the attendee's participation; RSVP, for indicating - whether the favor of a reply is requested; CUTYPE, to indicate the - type of calendar user; MEMBER, to indicate the groups that the - attendee belongs to; DELEGATED-TO, to indicate the calendar users - that the original request was delegated to; and DELEGATED-FROM, to - indicate whom the request was delegated from; SENT-BY, to indicate - whom is acting on behalf of the ATTENDEE; and DIR, to indicate the - URI that points to the directory information corresponding to the - attendee. These property parameters can be specified on an "ATTENDEE" - - - -Dawson & Stenerson Standards Track [Page 102] - -RFC 2445 iCalendar November 1998 - - - property in either a "VEVENT", "VTODO" or "VJOURNAL" calendar - component. They MUST not be specified in an "ATTENDEE" property in a - "VFREEBUSY" or "VALARM" calendar component. If the LANGUAGE property - parameter is specified, the identified language applies to the CN - parameter. - - A recipient delegated a request MUST inherit the RSVP and ROLE values - from the attendee that delegated the request to them. - - Multiple attendees can be specified by including multiple "ATTENDEE" - properties within the calendar component. - - Format Definition: The property is defined by the following notation: - - attendee = "ATTENDEE" attparam ":" cal-address CRLF - - attparam = *( - - ; the following are optional, - ; but MUST NOT occur more than once - - (";" cutypeparam) / (";"memberparam) / - (";" roleparam) / (";" partstatparam) / - (";" rsvpparam) / (";" deltoparam) / - (";" delfromparam) / (";" sentbyparam) / - (";"cnparam) / (";" dirparam) / - (";" languageparam) / - - ; the following is optional, - ; and MAY occur more than once - - (";" xparam) - - ) - - Example: The following are examples of this property's use for a to- - do: - - ORGANIZER:MAILTO:jsmith@host1.com - ATTENDEE;MEMBER="MAILTO:DEV-GROUP@host2.com": - MAILTO:joecool@host2.com - ATTENDEE;DELEGATED-FROM="MAILTO:immud@host3.com": - MAILTO:ildoit@host1.com - - The following is an example of this property used for specifying - multiple attendees to an event: - - - - - -Dawson & Stenerson Standards Track [Page 103] - -RFC 2445 iCalendar November 1998 - - - ORGANIZER:MAILTO:jsmith@host1.com - ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;CN=Henry Cabot - :MAILTO:hcabot@host2.com - ATTENDEE;ROLE=REQ-PARTICIPANT;DELEGATED-FROM="MAILTO:bob@host.com" - ;PARTSTAT=ACCEPTED;CN=Jane Doe:MAILTO:jdoe@host1.com - - The following is an example of this property with a URI to the - directory information associated with the attendee: - - ATTENDEE;CN=John Smith;DIR="ldap://host.com:6666/o=eDABC% - 20Industries,c=3DUS??(cn=3DBJim%20Dolittle)":MAILTO:jimdo@ - host1.com - - The following is an example of this property with "delegatee" and - "delegator" information for an event: - - ORGANIZER;CN=John Smith:MAILTO:jsmith@host.com - ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;DELEGATED-FROM= - "MAILTO:iamboss@host2.com";CN=Henry Cabot:MAILTO:hcabot@ - host2.com - ATTENDEE;ROLE=NON-PARTICIPANT;PARTSTAT=DELEGATED;DELEGATED-TO= - "MAILTO:hcabot@host2.com";CN=The Big Cheese:MAILTO:iamboss - @host2.com - ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;CN=Jane Doe - :MAILTO:jdoe@host1.com - - Example: The following is an example of this property's use when - another calendar user is acting on behalf of the "Attendee": - - ATTENDEE;SENT-BY=MAILTO:jan_doe@host1.com;CN=John Smith:MAILTO: - jsmith@host1.com - -4.8.4.2 Contact - - Property Name: CONTACT - - Purpose: The property is used to represent contact information or - alternately a reference to contact information associated with the - calendar component. - - Value Type: TEXT - - Property Parameters: Non-standard, alternate text representation and - language property parameters can be specified on this property. - - Conformance: The property can be specified in a "VEVENT", "VTODO", - "VJOURNAL" or "VFREEBUSY" calendar component. - - - - -Dawson & Stenerson Standards Track [Page 104] - -RFC 2445 iCalendar November 1998 - - - Description: The property value consists of textual contact - information. An alternative representation for the property value can - also be specified that refers to a URI pointing to an alternate form, - such as a vCard [RFC 2426], for the contact information. - - Format Definition: The property is defined by the following notation: - - contact = "CONTACT" contparam ":" text CRLF - - contparam = *( - ; the following are optional, - ; but MUST NOT occur more than once - - (";" altrepparam) / (";" languageparam) / - - ; the following is optional, - ; and MAY occur more than once - - (";" xparam) - - ) - - Example: The following is an example of this property referencing - textual contact information: - - CONTACT:Jim Dolittle\, ABC Industries\, +1-919-555-1234 - - The following is an example of this property with an alternate - representation of a LDAP URI to a directory entry containing the - contact information: - - CONTACT;ALTREP="ldap://host.com:6666/o=3DABC%20Industries\, - c=3DUS??(cn=3DBJim%20Dolittle)":Jim Dolittle\, ABC Industries\, - +1-919-555-1234 - - The following is an example of this property with an alternate - representation of a MIME body part containing the contact - information, such as a vCard [RFC 2426] embedded in a [MIME-DIR] - content-type: - - CONTACT;ALTREP="CID=":Jim - Dolittle\, ABC Industries\, +1-919-555-1234 - - The following is an example of this property referencing a network - resource, such as a vCard [RFC 2426] object containing the contact - information: - - - - - -Dawson & Stenerson Standards Track [Page 105] - -RFC 2445 iCalendar November 1998 - - - CONTACT;ALTREP="http://host.com/pdi/jdoe.vcf":Jim - Dolittle\, ABC Industries\, +1-919-555-1234 - -4.8.4.3 Organizer - - Property Name: ORGANIZER - - Purpose: The property defines the organizer for a calendar component. - - Value Type: CAL-ADDRESS - - Property Parameters: Non-standard, language, common name, directory - entry reference, sent by property parameters can be specified on this - property. - - Conformance: This property MUST be specified in an iCalendar object - that specifies a group scheduled calendar entity. This property MUST - be specified in an iCalendar object that specifies the publication of - a calendar user's busy time. This property MUST NOT be specified in - an iCalendar object that specifies only a time zone definition or - that defines calendar entities that are not group scheduled entities, - but are entities only on a single user's calendar. - - Description: The property is specified within the "VEVENT", "VTODO", - "VJOURNAL calendar components to specify the organizer of a group - scheduled calendar entity. The property is specified within the - "VFREEBUSY" calendar component to specify the calendar user - requesting the free or busy time. When publishing a "VFREEBUSY" - calendar component, the property is used to specify the calendar that - the published busy time came from. - - The property has the property parameters CN, for specifying the - common or display name associated with the "Organizer", DIR, for - specifying a pointer to the directory information associated with the - "Organizer", SENT-BY, for specifying another calendar user that is - acting on behalf of the "Organizer". The non-standard parameters may - also be specified on this property. If the LANGUAGE property - parameter is specified, the identified language applies to the CN - parameter value. - - Format Definition: The property is defined by the following notation: - - organizer = "ORGANIZER" orgparam ":" - cal-address CRLF - - orgparam = *( - - ; the following are optional, - - - -Dawson & Stenerson Standards Track [Page 106] - -RFC 2445 iCalendar November 1998 - - - ; but MUST NOT occur more than once - - (";" cnparam) / (";" dirparam) / (";" sentbyparam) / - (";" languageparam) / - - ; the following is optional, - ; and MAY occur more than once - - (";" xparam) - - ) - - Example: The following is an example of this property: - - ORGANIZER;CN=John Smith:MAILTO:jsmith@host1.com - - The following is an example of this property with a pointer to the - directory information associated with the organizer: - - ORGANIZER;CN=JohnSmith;DIR="ldap://host.com:6666/o=3DDC%20Associ - ates,c=3DUS??(cn=3DJohn%20Smith)":MAILTO:jsmith@host1.com - - The following is an example of this property used by another calendar - user who is acting on behalf of the organizer, with responses - intended to be sent back to the organizer, not the other calendar - user: - - ORGANIZER;SENT-BY="MAILTO:jane_doe@host.com": - MAILTO:jsmith@host1.com - -4.8.4.4 Recurrence ID - - Property Name: RECURRENCE-ID - - Purpose: This property is used in conjunction with the "UID" and - "SEQUENCE" property to identify a specific instance of a recurring - "VEVENT", "VTODO" or "VJOURNAL" calendar component. The property - value is the effective value of the "DTSTART" property of the - recurrence instance. - - Value Type: The default value type for this property is DATE-TIME. - The time format can be any of the valid forms defined for a DATE-TIME - value type. See DATE-TIME value type definition for specific - interpretations of the various forms. The value type can be set to - DATE. - - - - - - -Dawson & Stenerson Standards Track [Page 107] - -RFC 2445 iCalendar November 1998 - - - Property Parameters: Non-standard property, value data type, time - zone identifier and recurrence identifier range parameters can be - specified on this property. - - Conformance: This property can be specified in an iCalendar object - containing a recurring calendar component. - - Description: The full range of calendar components specified by a - recurrence set is referenced by referring to just the "UID" property - value corresponding to the calendar component. The "RECURRENCE-ID" - property allows the reference to an individual instance within the - recurrence set. - - If the value of the "DTSTART" property is a DATE type value, then the - value MUST be the calendar date for the recurrence instance. - - The date/time value is set to the time when the original recurrence - instance would occur; meaning that if the intent is to change a - Friday meeting to Thursday, the date/time is still set to the - original Friday meeting. - - The "RECURRENCE-ID" property is used in conjunction with the "UID" - and "SEQUENCE" property to identify a particular instance of a - recurring event, to-do or journal. For a given pair of "UID" and - "SEQUENCE" property values, the "RECURRENCE-ID" value for a - recurrence instance is fixed. When the definition of the recurrence - set for a calendar component changes, and hence the "SEQUENCE" - property value changes, the "RECURRENCE-ID" for a given recurrence - instance might also change.The "RANGE" parameter is used to specify - the effective range of recurrence instances from the instance - specified by the "RECURRENCE-ID" property value. The default value - for the range parameter is the single recurrence instance only. The - value can also be "THISANDPRIOR" to indicate a range defined by the - given recurrence instance and all prior instances or the value can be - "THISANDFUTURE" to indicate a range defined by the given recurrence - instance and all subsequent instances. - - Format Definition: The property is defined by the following notation: - - recurid = "RECURRENCE-ID" ridparam ":" ridval CRLF - - ridparam = *( - - ; the following are optional, - ; but MUST NOT occur more than once - - (";" "VALUE" "=" ("DATE-TIME" / "DATE)) / - (";" tzidparam) / (";" rangeparam) / - - - -Dawson & Stenerson Standards Track [Page 108] - -RFC 2445 iCalendar November 1998 - - - ; the following is optional, - ; and MAY occur more than once - - (";" xparam) - - ) - - ridval = date-time / date - ;Value MUST match value type - - Example: The following are examples of this property: - - RECURRENCE-ID;VALUE=DATE:19960401 - - RECURRENCE-ID;RANGE=THISANDFUTURE:19960120T120000Z - -4.8.4.5 Related To - - Property Name: RELATED-TO - - Purpose: The property is used to represent a relationship or - reference between one calendar component and another. - - Value Type: TEXT - - Property Parameters: Non-standard and relationship type property - parameters can be specified on this property. - - Conformance: The property can be specified one or more times in the - "VEVENT", "VTODO" or "VJOURNAL" calendar components. - - Description: The property value consists of the persistent, globally - unique identifier of another calendar component. This value would be - represented in a calendar component by the "UID" property. - - By default, the property value points to another calendar component - that has a PARENT relationship to the referencing object. The - "RELTYPE" property parameter is used to either explicitly state the - default PARENT relationship type to the referenced calendar component - or to override the default PARENT relationship type and specify - either a CHILD or SIBLING relationship. The PARENT relationship - indicates that the calendar component is a subordinate of the - referenced calendar component. The CHILD relationship indicates that - the calendar component is a superior of the referenced calendar - component. The SIBLING relationship indicates that the calendar - component is a peer of the referenced calendar component. - - - - - -Dawson & Stenerson Standards Track [Page 109] - -RFC 2445 iCalendar November 1998 - - - Changes to a calendar component referenced by this property can have - an implicit impact on the related calendar component. For example, if - a group event changes its start or end date or time, then the - related, dependent events will need to have their start and end dates - changed in a corresponding way. Similarly, if a PARENT calendar - component is canceled or deleted, then there is an implied impact to - the related CHILD calendar components. This property is intended only - to provide information on the relationship of calendar components. It - is up to the target calendar system to maintain any property - implications of this relationship. - - Format Definition: The property is defined by the following notation: - - related = "RELATED-TO" [relparam] ":" text CRLF - - relparam = *( - - ; the following is optional, - ; but MUST NOT occur more than once - - (";" reltypeparam) / - - ; the following is optional, - ; and MAY occur more than once - - (";" xparm) - - ) - - The following is an example of this property: - - RELATED-TO: - - RELATED-TO:<19960401-080045-4000F192713-0052@host1.com> - -4.8.4.6 Uniform Resource Locator - - Property Name: URL - - Purpose: This property defines a Uniform Resource Locator (URL) - associated with the iCalendar object. - - Value Type: URI - - Property Parameters: Non-standard property parameters can be - specified on this property. - - - - - -Dawson & Stenerson Standards Track [Page 110] - -RFC 2445 iCalendar November 1998 - - - Conformance: This property can be specified once in the "VEVENT", - "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components. - - Description: This property may be used in a calendar component to - convey a location where a more dynamic rendition of the calendar - information associated with the calendar component can be found. This - memo does not attempt to standardize the form of the URI, nor the - format of the resource pointed to by the property value. If the URL - property and Content-Location MIME header are both specified, they - MUST point to the same resource. - - Format Definition: The property is defined by the following notation: - - url = "URL" urlparam ":" uri CRLF - - urlparam = *(";" xparam) - - Example: The following is an example of this property: - - URL:http://abc.com/pub/calendars/jsmith/mytime.ics - -4.8.4.7 Unique Identifier - - Property Name: UID - - Purpose: This property defines the persistent, globally unique - identifier for the calendar component. - - Value Type: TEXT - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: The property MUST be specified in the "VEVENT", "VTODO", - "VJOURNAL" or "VFREEBUSY" calendar components. - - Description: The UID itself MUST be a globally unique identifier. The - generator of the identifier MUST guarantee that the identifier is - unique. There are several algorithms that can be used to accomplish - this. The identifier is RECOMMENDED to be the identical syntax to the - [RFC 822] addr-spec. A good method to assure uniqueness is to put the - domain name or a domain literal IP address of the host on which the - identifier was created on the right hand side of the "@", and on the - left hand side, put a combination of the current calendar date and - time of day (i.e., formatted in as a DATE-TIME value) along with some - other currently unique (perhaps sequential) identifier available on - the system (for example, a process id number). Using a date/time - value on the left hand side and a domain name or domain literal on - - - -Dawson & Stenerson Standards Track [Page 111] - -RFC 2445 iCalendar November 1998 - - - the right hand side makes it possible to guarantee uniqueness since - no two hosts should be using the same domain name or IP address at - the same time. Though other algorithms will work, it is RECOMMENDED - that the right hand side contain some domain identifier (either of - the host itself or otherwise) such that the generator of the message - identifier can guarantee the uniqueness of the left hand side within - the scope of that domain. - - This is the method for correlating scheduling messages with the - referenced "VEVENT", "VTODO", or "VJOURNAL" calendar component. - - The full range of calendar components specified by a recurrence set - is referenced by referring to just the "UID" property value - corresponding to the calendar component. The "RECURRENCE-ID" property - allows the reference to an individual instance within the recurrence - set. - - This property is an important method for group scheduling - applications to match requests with later replies, modifications or - deletion requests. Calendaring and scheduling applications MUST - generate this property in "VEVENT", "VTODO" and "VJOURNAL" calendar - components to assure interoperability with other group scheduling - applications. This identifier is created by the calendar system that - generates an iCalendar object. - - Implementations MUST be able to receive and persist values of at - least 255 characters for this property. - - Format Definition: The property is defined by the following notation: - - uid = "UID" uidparam ":" text CRLF - - uidparam = *(";" xparam) - - Example: The following is an example of this property: - - UID:19960401T080045Z-4000F192713-0052@host1.com - -4.8.5 Recurrence Component Properties - - The following properties specify recurrence information in calendar - components. - -4.8.5.1 Exception Date/Times - - Property Name: EXDATE - - - - - -Dawson & Stenerson Standards Track [Page 112] - -RFC 2445 iCalendar November 1998 - - - Purpose: This property defines the list of date/time exceptions for a - recurring calendar component. - - Value Type: The default value type for this property is DATE-TIME. - The value type can be set to DATE. - - Property Parameters: Non-standard, value data type and time zone - identifier property parameters can be specified on this property. - - Conformance: This property can be specified in an iCalendar object - that includes a recurring calendar component. - - Description: The exception dates, if specified, are used in computing - the recurrence set. The recurrence set is the complete set of - recurrence instances for a calendar component. The recurrence set is - generated by considering the initial "DTSTART" property along with - the "RRULE", "RDATE", "EXDATE" and "EXRULE" properties contained - within the iCalendar object. The "DTSTART" property defines the first - instance in the recurrence set. Multiple instances of the "RRULE" and - "EXRULE" properties can also be specified to define more - sophisticated recurrence sets. The final recurrence set is generated - by gathering all of the start date-times generated by any of the - specified "RRULE" and "RDATE" properties, and then excluding any - start date and times which fall within the union of start date and - times generated by any specified "EXRULE" and "EXDATE" properties. - This implies that start date and times within exclusion related - properties (i.e., "EXDATE" and "EXRULE") take precedence over those - specified by inclusion properties (i.e., "RDATE" and "RRULE"). Where - duplicate instances are generated by the "RRULE" and "RDATE" - properties, only one recurrence is considered. Duplicate instances - are ignored. - - The "EXDATE" property can be used to exclude the value specified in - "DTSTART". However, in such cases the original "DTSTART" date MUST - still be maintained by the calendaring and scheduling system because - the original "DTSTART" value has inherent usage dependencies by other - properties such as the "RECURRENCE-ID". - - Format Definition: The property is defined by the following notation: - - exdate = "EXDATE" exdtparam ":" exdtval *("," exdtval) CRLF - - exdtparam = *( - - ; the following are optional, - ; but MUST NOT occur more than once - - (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / - - - -Dawson & Stenerson Standards Track [Page 113] - -RFC 2445 iCalendar November 1998 - - - (";" tzidparam) / - - ; the following is optional, - ; and MAY occur more than once - - (";" xparam) - - ) - - exdtval = date-time / date - ;Value MUST match value type - - Example: The following is an example of this property: - - EXDATE:19960402T010000Z,19960403T010000Z,19960404T010000Z - -4.8.5.2 Exception Rule - - Property Name: EXRULE - - Purpose: This property defines a rule or repeating pattern for an - exception to a recurrence set. - - Value Type: RECUR - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property can be specified in "VEVENT", "VTODO" or - "VJOURNAL" calendar components. - - Description: The exception rule, if specified, is used in computing - the recurrence set. The recurrence set is the complete set of - recurrence instances for a calendar component. The recurrence set is - generated by considering the initial "DTSTART" property along with - the "RRULE", "RDATE", "EXDATE" and "EXRULE" properties contained - within the iCalendar object. The "DTSTART" defines the first instance - in the recurrence set. Multiple instances of the "RRULE" and "EXRULE" - properties can also be specified to define more sophisticated - recurrence sets. The final recurrence set is generated by gathering - all of the start date-times generated by any of the specified "RRULE" - and "RDATE" properties, and excluding any start date and times which - fall within the union of start date and times generated by any - specified "EXRULE" and "EXDATE" properties. This implies that start - date and times within exclusion related properties (i.e., "EXDATE" - and "EXRULE") take precedence over those specified by inclusion - - - - - -Dawson & Stenerson Standards Track [Page 114] - -RFC 2445 iCalendar November 1998 - - - properties (i.e., "RDATE" and "RRULE"). Where duplicate instances are - generated by the "RRULE" and "RDATE" properties, only one recurrence - is considered. Duplicate instances are ignored. - - The "EXRULE" property can be used to exclude the value specified in - "DTSTART". However, in such cases the original "DTSTART" date MUST - still be maintained by the calendaring and scheduling system because - the original "DTSTART" value has inherent usage dependencies by other - properties such as the "RECURRENCE-ID". - - Format Definition: The property is defined by the following notation: - - exrule = "EXRULE" exrparam ":" recur CRLF - - exrparam = *(";" xparam) - - Example: The following are examples of this property. Except every - other week, on Tuesday and Thursday for 4 occurrences: - - EXRULE:FREQ=WEEKLY;COUNT=4;INTERVAL=2;BYDAY=TU,TH - - Except daily for 10 occurrences: - - EXRULE:FREQ=DAILY;COUNT=10 - - Except yearly in June and July for 8 occurrences: - - EXRULE:FREQ=YEARLY;COUNT=8;BYMONTH=6,7 - -4.8.5.3 Recurrence Date/Times - - Property Name: RDATE - - Purpose: This property defines the list of date/times for a - recurrence set. - - Value Type: The default value type for this property is DATE-TIME. - The value type can be set to DATE or PERIOD. - - Property Parameters: Non-standard, value data type and time zone - identifier property parameters can be specified on this property. - - Conformance: The property can be specified in "VEVENT", "VTODO", - "VJOURNAL" or "VTIMEZONE" calendar components. - - - - - - - -Dawson & Stenerson Standards Track [Page 115] - -RFC 2445 iCalendar November 1998 - - - Description: This property can appear along with the "RRULE" property - to define an aggregate set of repeating occurrences. When they both - appear in an iCalendar object, the recurring events are defined by - the union of occurrences defined by both the "RDATE" and "RRULE". - - The recurrence dates, if specified, are used in computing the - recurrence set. The recurrence set is the complete set of recurrence - instances for a calendar component. The recurrence set is generated - by considering the initial "DTSTART" property along with the "RRULE", - "RDATE", "EXDATE" and "EXRULE" properties contained within the - iCalendar object. The "DTSTART" property defines the first instance - in the recurrence set. Multiple instances of the "RRULE" and "EXRULE" - properties can also be specified to define more sophisticated - recurrence sets. The final recurrence set is generated by gathering - all of the start date/times generated by any of the specified "RRULE" - and "RDATE" properties, and excluding any start date/times which fall - within the union of start date/times generated by any specified - "EXRULE" and "EXDATE" properties. This implies that start date/times - within exclusion related properties (i.e., "EXDATE" and "EXRULE") - take precedence over those specified by inclusion properties (i.e., - "RDATE" and "RRULE"). Where duplicate instances are generated by the - "RRULE" and "RDATE" properties, only one recurrence is considered. - Duplicate instances are ignored. - - Format Definition: The property is defined by the following notation: - - rdate = "RDATE" rdtparam ":" rdtval *("," rdtval) CRLF - - rdtparam = *( - - ; the following are optional, - ; but MUST NOT occur more than once - - (";" "VALUE" "=" ("DATE-TIME" / "DATE" / "PERIOD")) / - (";" tzidparam) / - - ; the following is optional, - ; and MAY occur more than once - - (";" xparam) - - ) - - rdtval = date-time / date / period - ;Value MUST match value type - - Example: The following are examples of this property: - - - - -Dawson & Stenerson Standards Track [Page 116] - -RFC 2445 iCalendar November 1998 - - - RDATE:19970714T123000Z - - RDATE;TZID=US-EASTERN:19970714T083000 - - RDATE;VALUE=PERIOD:19960403T020000Z/19960403T040000Z, - 19960404T010000Z/PT3H - - RDATE;VALUE=DATE:19970101,19970120,19970217,19970421 - 19970526,19970704,19970901,19971014,19971128,19971129,19971225 - -4.8.5.4 Recurrence Rule - - Property Name: RRULE - - Purpose: This property defines a rule or repeating pattern for - recurring events, to-dos, or time zone definitions. - - Value Type: RECUR - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property can be specified one or more times in - recurring "VEVENT", "VTODO" and "VJOURNAL" calendar components. It - can also be specified once in each STANDARD or DAYLIGHT sub-component - of the "VTIMEZONE" calendar component. - - Description: The recurrence rule, if specified, is used in computing - the recurrence set. The recurrence set is the complete set of - recurrence instances for a calendar component. The recurrence set is - generated by considering the initial "DTSTART" property along with - the "RRULE", "RDATE", "EXDATE" and "EXRULE" properties contained - within the iCalendar object. The "DTSTART" property defines the first - instance in the recurrence set. Multiple instances of the "RRULE" and - "EXRULE" properties can also be specified to define more - sophisticated recurrence sets. The final recurrence set is generated - by gathering all of the start date/times generated by any of the - specified "RRULE" and "RDATE" properties, and excluding any start - date/times which fall within the union of start date/times generated - by any specified "EXRULE" and "EXDATE" properties. This implies that - start date/times within exclusion related properties (i.e., "EXDATE" - and "EXRULE") take precedence over those specified by inclusion - properties (i.e., "RDATE" and "RRULE"). Where duplicate instances are - generated by the "RRULE" and "RDATE" properties, only one recurrence - is considered. Duplicate instances are ignored. - - - - - - -Dawson & Stenerson Standards Track [Page 117] - -RFC 2445 iCalendar November 1998 - - - The "DTSTART" and "DTEND" property pair or "DTSTART" and "DURATION" - property pair, specified within the iCalendar object defines the - first instance of the recurrence. When used with a recurrence rule, - the "DTSTART" and "DTEND" properties MUST be specified in local time - and the appropriate set of "VTIMEZONE" calendar components MUST be - included. For detail on the usage of the "VTIMEZONE" calendar - component, see the "VTIMEZONE" calendar component definition. - - Any duration associated with the iCalendar object applies to all - members of the generated recurrence set. Any modified duration for - specific recurrences MUST be explicitly specified using the "RDATE" - property. - - Format Definition: This property is defined by the following - notation: - - rrule = "RRULE" rrulparam ":" recur CRLF - - rrulparam = *(";" xparam) - - Example: All examples assume the Eastern United States time zone. - - Daily for 10 occurrences: - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=DAILY;COUNT=10 - - ==> (1997 9:00 AM EDT)September 2-11 - - Daily until December 24, 1997: - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=DAILY;UNTIL=19971224T000000Z - - ==> (1997 9:00 AM EDT)September 2-30;October 1-25 - (1997 9:00 AM EST)October 26-31;November 1-30;December 1-23 - - Every other day - forever: - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=DAILY;INTERVAL=2 - ==> (1997 9:00 AM EDT)September2,4,6,8...24,26,28,30; - October 2,4,6...20,22,24 - (1997 9:00 AM EST)October 26,28,30;November 1,3,5,7...25,27,29; - Dec 1,3,... - - Every 10 days, 5 occurrences: - - - - -Dawson & Stenerson Standards Track [Page 118] - -RFC 2445 iCalendar November 1998 - - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=DAILY;INTERVAL=10;COUNT=5 - - ==> (1997 9:00 AM EDT)September 2,12,22;October 2,12 - - Everyday in January, for 3 years: - - DTSTART;TZID=US-Eastern:19980101T090000 - RRULE:FREQ=YEARLY;UNTIL=20000131T090000Z; - BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA - or - RRULE:FREQ=DAILY;UNTIL=20000131T090000Z;BYMONTH=1 - - ==> (1998 9:00 AM EDT)January 1-31 - (1999 9:00 AM EDT)January 1-31 - (2000 9:00 AM EDT)January 1-31 - - Weekly for 10 occurrences - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=WEEKLY;COUNT=10 - - ==> (1997 9:00 AM EDT)September 2,9,16,23,30;October 7,14,21 - (1997 9:00 AM EST)October 28;November 4 - - Weekly until December 24, 1997 - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=WEEKLY;UNTIL=19971224T000000Z - - ==> (1997 9:00 AM EDT)September 2,9,16,23,30;October 7,14,21 - (1997 9:00 AM EST)October 28;November 4,11,18,25; - December 2,9,16,23 - Every other week - forever: - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=WEEKLY;INTERVAL=2;WKST=SU - - ==> (1997 9:00 AM EDT)September 2,16,30;October 14 - (1997 9:00 AM EST)October 28;November 11,25;December 9,23 - (1998 9:00 AM EST)January 6,20;February - ... - - Weekly on Tuesday and Thursday for 5 weeks: - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=WEEKLY;UNTIL=19971007T000000Z;WKST=SU;BYDAY=TU,TH - or - - - -Dawson & Stenerson Standards Track [Page 119] - -RFC 2445 iCalendar November 1998 - - - RRULE:FREQ=WEEKLY;COUNT=10;WKST=SU;BYDAY=TU,TH - - ==> (1997 9:00 AM EDT)September 2,4,9,11,16,18,23,25,30;October 2 - - Every other week on Monday, Wednesday and Friday until December 24, - 1997, but starting on Tuesday, September 2, 1997: - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=WEEKLY;INTERVAL=2;UNTIL=19971224T000000Z;WKST=SU; - BYDAY=MO,WE,FR - ==> (1997 9:00 AM EDT)September 2,3,5,15,17,19,29;October - 1,3,13,15,17 - (1997 9:00 AM EST)October 27,29,31;November 10,12,14,24,26,28; - December 8,10,12,22 - - Every other week on Tuesday and Thursday, for 8 occurrences: - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=8;WKST=SU;BYDAY=TU,TH - - ==> (1997 9:00 AM EDT)September 2,4,16,18,30;October 2,14,16 - - Monthly on the 1st Friday for ten occurrences: - - DTSTART;TZID=US-Eastern:19970905T090000 - RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR - - ==> (1997 9:00 AM EDT)September 5;October 3 - (1997 9:00 AM EST)November 7;Dec 5 - (1998 9:00 AM EST)January 2;February 6;March 6;April 3 - (1998 9:00 AM EDT)May 1;June 5 - - Monthly on the 1st Friday until December 24, 1997: - - DTSTART;TZID=US-Eastern:19970905T090000 - RRULE:FREQ=MONTHLY;UNTIL=19971224T000000Z;BYDAY=1FR - - ==> (1997 9:00 AM EDT)September 5;October 3 - (1997 9:00 AM EST)November 7;December 5 - - Every other month on the 1st and last Sunday of the month for 10 - occurrences: - - DTSTART;TZID=US-Eastern:19970907T090000 - RRULE:FREQ=MONTHLY;INTERVAL=2;COUNT=10;BYDAY=1SU,-1SU - - ==> (1997 9:00 AM EDT)September 7,28 - (1997 9:00 AM EST)November 2,30 - - - -Dawson & Stenerson Standards Track [Page 120] - -RFC 2445 iCalendar November 1998 - - - (1998 9:00 AM EST)January 4,25;March 1,29 - (1998 9:00 AM EDT)May 3,31 - - Monthly on the second to last Monday of the month for 6 months: - - DTSTART;TZID=US-Eastern:19970922T090000 - RRULE:FREQ=MONTHLY;COUNT=6;BYDAY=-2MO - - ==> (1997 9:00 AM EDT)September 22;October 20 - (1997 9:00 AM EST)November 17;December 22 - (1998 9:00 AM EST)January 19;February 16 - - Monthly on the third to the last day of the month, forever: - - DTSTART;TZID=US-Eastern:19970928T090000 - RRULE:FREQ=MONTHLY;BYMONTHDAY=-3 - - ==> (1997 9:00 AM EDT)September 28 - (1997 9:00 AM EST)October 29;November 28;December 29 - (1998 9:00 AM EST)January 29;February 26 - ... - - Monthly on the 2nd and 15th of the month for 10 occurrences: - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=2,15 - - ==> (1997 9:00 AM EDT)September 2,15;October 2,15 - (1997 9:00 AM EST)November 2,15;December 2,15 - (1998 9:00 AM EST)January 2,15 - - Monthly on the first and last day of the month for 10 occurrences: - - DTSTART;TZID=US-Eastern:19970930T090000 - RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=1,-1 - - ==> (1997 9:00 AM EDT)September 30;October 1 - (1997 9:00 AM EST)October 31;November 1,30;December 1,31 - (1998 9:00 AM EST)January 1,31;February 1 - - Every 18 months on the 10th thru 15th of the month for 10 - occurrences: - - DTSTART;TZID=US-Eastern:19970910T090000 - RRULE:FREQ=MONTHLY;INTERVAL=18;COUNT=10;BYMONTHDAY=10,11,12,13,14, - 15 - - ==> (1997 9:00 AM EDT)September 10,11,12,13,14,15 - - - -Dawson & Stenerson Standards Track [Page 121] - -RFC 2445 iCalendar November 1998 - - - (1999 9:00 AM EST)March 10,11,12,13 - - Every Tuesday, every other month: - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=MONTHLY;INTERVAL=2;BYDAY=TU - - ==> (1997 9:00 AM EDT)September 2,9,16,23,30 - (1997 9:00 AM EST)November 4,11,18,25 - (1998 9:00 AM EST)January 6,13,20,27;March 3,10,17,24,31 - ... - - Yearly in June and July for 10 occurrences: - - DTSTART;TZID=US-Eastern:19970610T090000 - RRULE:FREQ=YEARLY;COUNT=10;BYMONTH=6,7 - ==> (1997 9:00 AM EDT)June 10;July 10 - (1998 9:00 AM EDT)June 10;July 10 - (1999 9:00 AM EDT)June 10;July 10 - (2000 9:00 AM EDT)June 10;July 10 - (2001 9:00 AM EDT)June 10;July 10 - Note: Since none of the BYDAY, BYMONTHDAY or BYYEARDAY components - are specified, the day is gotten from DTSTART - - Every other year on January, February, and March for 10 occurrences: - - DTSTART;TZID=US-Eastern:19970310T090000 - RRULE:FREQ=YEARLY;INTERVAL=2;COUNT=10;BYMONTH=1,2,3 - - ==> (1997 9:00 AM EST)March 10 - (1999 9:00 AM EST)January 10;February 10;March 10 - (2001 9:00 AM EST)January 10;February 10;March 10 - (2003 9:00 AM EST)January 10;February 10;March 10 - - Every 3rd year on the 1st, 100th and 200th day for 10 occurrences: - - DTSTART;TZID=US-Eastern:19970101T090000 - RRULE:FREQ=YEARLY;INTERVAL=3;COUNT=10;BYYEARDAY=1,100,200 - - ==> (1997 9:00 AM EST)January 1 - (1997 9:00 AM EDT)April 10;July 19 - (2000 9:00 AM EST)January 1 - (2000 9:00 AM EDT)April 9;July 18 - (2003 9:00 AM EST)January 1 - (2003 9:00 AM EDT)April 10;July 19 - (2006 9:00 AM EST)January 1 - - Every 20th Monday of the year, forever: - - - -Dawson & Stenerson Standards Track [Page 122] - -RFC 2445 iCalendar November 1998 - - - DTSTART;TZID=US-Eastern:19970519T090000 - RRULE:FREQ=YEARLY;BYDAY=20MO - - ==> (1997 9:00 AM EDT)May 19 - (1998 9:00 AM EDT)May 18 - (1999 9:00 AM EDT)May 17 - ... - - Monday of week number 20 (where the default start of the week is - Monday), forever: - - DTSTART;TZID=US-Eastern:19970512T090000 - RRULE:FREQ=YEARLY;BYWEEKNO=20;BYDAY=MO - - ==> (1997 9:00 AM EDT)May 12 - (1998 9:00 AM EDT)May 11 - (1999 9:00 AM EDT)May 17 - ... - - Every Thursday in March, forever: - - DTSTART;TZID=US-Eastern:19970313T090000 - RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=TH - - ==> (1997 9:00 AM EST)March 13,20,27 - (1998 9:00 AM EST)March 5,12,19,26 - (1999 9:00 AM EST)March 4,11,18,25 - ... - - Every Thursday, but only during June, July, and August, forever: - - DTSTART;TZID=US-Eastern:19970605T090000 - RRULE:FREQ=YEARLY;BYDAY=TH;BYMONTH=6,7,8 - - ==> (1997 9:00 AM EDT)June 5,12,19,26;July 3,10,17,24,31; - August 7,14,21,28 - (1998 9:00 AM EDT)June 4,11,18,25;July 2,9,16,23,30; - August 6,13,20,27 - (1999 9:00 AM EDT)June 3,10,17,24;July 1,8,15,22,29; - August 5,12,19,26 - ... - - Every Friday the 13th, forever: - - DTSTART;TZID=US-Eastern:19970902T090000 - EXDATE;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=MONTHLY;BYDAY=FR;BYMONTHDAY=13 - - - - -Dawson & Stenerson Standards Track [Page 123] - -RFC 2445 iCalendar November 1998 - - - ==> (1998 9:00 AM EST)February 13;March 13;November 13 - (1999 9:00 AM EDT)August 13 - (2000 9:00 AM EDT)October 13 - ... - - The first Saturday that follows the first Sunday of the month, - forever: - - DTSTART;TZID=US-Eastern:19970913T090000 - RRULE:FREQ=MONTHLY;BYDAY=SA;BYMONTHDAY=7,8,9,10,11,12,13 - - ==> (1997 9:00 AM EDT)September 13;October 11 - (1997 9:00 AM EST)November 8;December 13 - (1998 9:00 AM EST)January 10;February 7;March 7 - (1998 9:00 AM EDT)April 11;May 9;June 13... - ... - - Every four years, the first Tuesday after a Monday in November, - forever (U.S. Presidential Election day): - - DTSTART;TZID=US-Eastern:19961105T090000 - RRULE:FREQ=YEARLY;INTERVAL=4;BYMONTH=11;BYDAY=TU;BYMONTHDAY=2,3,4, - 5,6,7,8 - - ==> (1996 9:00 AM EST)November 5 - (2000 9:00 AM EST)November 7 - (2004 9:00 AM EST)November 2 - ... - - The 3rd instance into the month of one of Tuesday, Wednesday or - Thursday, for the next 3 months: - - DTSTART;TZID=US-Eastern:19970904T090000 - RRULE:FREQ=MONTHLY;COUNT=3;BYDAY=TU,WE,TH;BYSETPOS=3 - - ==> (1997 9:00 AM EDT)September 4;October 7 - (1997 9:00 AM EST)November 6 - - The 2nd to last weekday of the month: - - DTSTART;TZID=US-Eastern:19970929T090000 - RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-2 - - ==> (1997 9:00 AM EDT)September 29 - (1997 9:00 AM EST)October 30;November 27;December 30 - (1998 9:00 AM EST)January 29;February 26;March 30 - ... - - - - -Dawson & Stenerson Standards Track [Page 124] - -RFC 2445 iCalendar November 1998 - - - Every 3 hours from 9:00 AM to 5:00 PM on a specific day: - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=HOURLY;INTERVAL=3;UNTIL=19970902T170000Z - - ==> (September 2, 1997 EDT)09:00,12:00,15:00 - - Every 15 minutes for 6 occurrences: - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=MINUTELY;INTERVAL=15;COUNT=6 - - ==> (September 2, 1997 EDT)09:00,09:15,09:30,09:45,10:00,10:15 - - Every hour and a half for 4 occurrences: - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=MINUTELY;INTERVAL=90;COUNT=4 - - ==> (September 2, 1997 EDT)09:00,10:30;12:00;13:30 - - Every 20 minutes from 9:00 AM to 4:40 PM every day: - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=DAILY;BYHOUR=9,10,11,12,13,14,15,16;BYMINUTE=0,20,40 - or - RRULE:FREQ=MINUTELY;INTERVAL=20;BYHOUR=9,10,11,12,13,14,15,16 - - ==> (September 2, 1997 EDT)9:00,9:20,9:40,10:00,10:20, - ... 16:00,16:20,16:40 - (September 3, 1997 EDT)9:00,9:20,9:40,10:00,10:20, - ...16:00,16:20,16:40 - ... - - An example where the days generated makes a difference because of - WKST: - - DTSTART;TZID=US-Eastern:19970805T090000 - RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=4;BYDAY=TU,SU;WKST=MO - - ==> (1997 EDT)Aug 5,10,19,24 - - changing only WKST from MO to SU, yields different results... - - DTSTART;TZID=US-Eastern:19970805T090000 - RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=4;BYDAY=TU,SU;WKST=SU - ==> (1997 EDT)August 5,17,19,31 - - - - -Dawson & Stenerson Standards Track [Page 125] - -RFC 2445 iCalendar November 1998 - - -4.8.6 Alarm Component Properties - - The following properties specify alarm information in calendar - components. - -4.8.6.1 Action - - Property Name: ACTION - - Purpose: This property defines the action to be invoked when an alarm - is triggered. - - Value Type: TEXT - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property MUST be specified once in a "VALARM" - calendar component. - - Description: Each "VALARM" calendar component has a particular type - of action associated with it. This property specifies the type of - action - - Format Definition: The property is defined by the following notation: - - action = "ACTION" actionparam ":" actionvalue CRLF - - actionparam = *(";" xparam) - - actionvalue = "AUDIO" / "DISPLAY" / "EMAIL" / "PROCEDURE" - / iana-token / x-name - - Example: The following are examples of this property in a "VALARM" - calendar component: - - ACTION:AUDIO - - ACTION:DISPLAY - - ACTION:PROCEDURE - -4.8.6.2 Repeat Count - - Property Name: REPEAT - - Purpose: This property defines the number of time the alarm should be - repeated, after the initial trigger. - - - -Dawson & Stenerson Standards Track [Page 126] - -RFC 2445 iCalendar November 1998 - - - Value Type: INTEGER - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property can be specified in a "VALARM" calendar - component. - - Description: If the alarm triggers more than once, then this property - MUST be specified along with the "DURATION" property. - - Format Definition: The property is defined by the following notation: - - repeatcnt = "REPEAT" repparam ":" integer CRLF - ;Default is "0", zero. - - repparam = *(";" xparam) - - Example: The following is an example of this property for an alarm - that repeats 4 additional times with a 5 minute delay after the - initial triggering of the alarm: - - REPEAT:4 - DURATION:PT5M - -4.8.6.3 Trigger - - Property Name: TRIGGER - - Purpose: This property specifies when an alarm will trigger. - - Value Type: The default value type is DURATION. The value type can be - set to a DATE-TIME value type, in which case the value MUST specify a - UTC formatted DATE-TIME value. - - Property Parameters: Non-standard, value data type, time zone - identifier or trigger relationship property parameters can be - specified on this property. The trigger relationship property - parameter MUST only be specified when the value type is DURATION. - - Conformance: This property MUST be specified in the "VALARM" calendar - component. - - Description: Within the "VALARM" calendar component, this property - defines when the alarm will trigger. The default value type is - DURATION, specifying a relative time for the trigger of the alarm. - The default duration is relative to the start of an event or to-do - that the alarm is associated with. The duration can be explicitly set - - - -Dawson & Stenerson Standards Track [Page 127] - -RFC 2445 iCalendar November 1998 - - - to trigger from either the end or the start of the associated event - or to-do with the "RELATED" parameter. A value of START will set the - alarm to trigger off the start of the associated event or to-do. A - value of END will set the alarm to trigger off the end of the - associated event or to-do. - - Either a positive or negative duration may be specified for the - "TRIGGER" property. An alarm with a positive duration is triggered - after the associated start or end of the event or to-do. An alarm - with a negative duration is triggered before the associated start or - end of the event or to-do. - - The "RELATED" property parameter is not valid if the value type of - the property is set to DATE-TIME (i.e., for an absolute date and time - alarm trigger). If a value type of DATE-TIME is specified, then the - property value MUST be specified in the UTC time format. If an - absolute trigger is specified on an alarm for a recurring event or - to-do, then the alarm will only trigger for the specified absolute - date/time, along with any specified repeating instances. - - If the trigger is set relative to START, then the "DTSTART" property - MUST be present in the associated "VEVENT" or "VTODO" calendar - component. If an alarm is specified for an event with the trigger set - relative to the END, then the "DTEND" property or the "DSTART" and - "DURATION' properties MUST be present in the associated "VEVENT" - calendar component. If the alarm is specified for a to-do with a - trigger set relative to the END, then either the "DUE" property or - the "DSTART" and "DURATION' properties MUST be present in the - associated "VTODO" calendar component. - - Alarms specified in an event or to-do which is defined in terms of a - DATE value type will be triggered relative to 00:00:00 UTC on the - specified date. For example, if "DTSTART:19980205, then the duration - trigger will be relative to19980205T000000Z. - - Format Definition: The property is defined by the following notation: - - trigger = "TRIGGER" (trigrel / trigabs) - - trigrel = *( - - ; the following are optional, - ; but MUST NOT occur more than once - - (";" "VALUE" "=" "DURATION") / - (";" trigrelparam) / - - ; the following is optional, - - - -Dawson & Stenerson Standards Track [Page 128] - -RFC 2445 iCalendar November 1998 - - - ; and MAY occur more than once - - (";" xparam) - ) ":" dur-value - - trigabs = 1*( - - ; the following is REQUIRED, - ; but MUST NOT occur more than once - - (";" "VALUE" "=" "DATE-TIME") / - - ; the following is optional, - ; and MAY occur more than once - - (";" xparam) - - ) ":" date-time - - Example: A trigger set 15 minutes prior to the start of the event or - to-do. - - TRIGGER:-P15M - - A trigger set 5 minutes after the end of the event or to-do. - - TRIGGER;RELATED=END:P5M - - A trigger set to an absolute date/time. - - TRIGGER;VALUE=DATE-TIME:19980101T050000Z - -4.8.7 Change Management Component Properties - - The following properties specify change management information in - calendar components. - -4.8.7.1 Date/Time Created - - Property Name: CREATED - - Purpose: This property specifies the date and time that the calendar - information was created by the calendar user agent in the calendar - store. - - Note: This is analogous to the creation date and time for a file - in the file system. - - - - -Dawson & Stenerson Standards Track [Page 129] - -RFC 2445 iCalendar November 1998 - - - Value Type: DATE-TIME - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: The property can be specified once in "VEVENT", "VTODO" - or "VJOURNAL" calendar components. - - Description: The date and time is a UTC value. - - Format Definition: The property is defined by the following notation: - - created = "CREATED" creaparam ":" date-time CRLF - - creaparam = *(";" xparam) - - Example: The following is an example of this property: - - CREATED:19960329T133000Z - -4.8.7.2 Date/Time Stamp - - Property Name: DTSTAMP - - Purpose: The property indicates the date/time that the instance of - the iCalendar object was created. - - Value Type: DATE-TIME - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property MUST be included in the "VEVENT", "VTODO", - "VJOURNAL" or "VFREEBUSY" calendar components. - - Description: The value MUST be specified in the UTC time format. - - This property is also useful to protocols such as [IMIP] that have - inherent latency issues with the delivery of content. This property - will assist in the proper sequencing of messages containing iCalendar - objects. - - This property is different than the "CREATED" and "LAST-MODIFIED" - properties. These two properties are used to specify when the - particular calendar data in the calendar store was created and last - modified. This is different than when the iCalendar object - representation of the calendar service information was created or - last modified. - - - -Dawson & Stenerson Standards Track [Page 130] - -RFC 2445 iCalendar November 1998 - - - Format Definition: The property is defined by the following notation: - - dtstamp = "DTSTAMP" stmparam ":" date-time CRLF - - stmparam = *(";" xparam) - - Example: - - DTSTAMP:19971210T080000Z - -4.8.7.3 Last Modified - - Property Name: LAST-MODIFIED - - Purpose: The property specifies the date and time that the - information associated with the calendar component was last revised - in the calendar store. - - Note: This is analogous to the modification date and time for a - file in the file system. - - Value Type: DATE-TIME - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property can be specified in the "EVENT", "VTODO", - "VJOURNAL" or "VTIMEZONE" calendar components. - - Description: The property value MUST be specified in the UTC time - format. - - Format Definition: The property is defined by the following notation: - - last-mod = "LAST-MODIFIED" lstparam ":" date-time CRLF - - lstparam = *(";" xparam) - - Example: The following is are examples of this property: - - LAST-MODIFIED:19960817T133000Z - -4.8.7.4 Sequence Number - - Property Name: SEQUENCE - - Purpose: This property defines the revision sequence number of the - calendar component within a sequence of revisions. - - - -Dawson & Stenerson Standards Track [Page 131] - -RFC 2445 iCalendar November 1998 - - - Value Type: integer - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: The property can be specified in "VEVENT", "VTODO" or - "VJOURNAL" calendar component. - - Description: When a calendar component is created, its sequence - number is zero (US-ASCII decimal 48). It is monotonically incremented - by the "Organizer's" CUA each time the "Organizer" makes a - significant revision to the calendar component. When the "Organizer" - makes changes to one of the following properties, the sequence number - MUST be incremented: - - . "DTSTART" - - . "DTEND" - - . "DUE" - - . "RDATE" - - . "RRULE" - - . "EXDATE" - - . "EXRULE" - - . "STATUS" - - In addition, changes made by the "Organizer" to other properties can - also force the sequence number to be incremented. The "Organizer" CUA - MUST increment the sequence number when ever it makes changes to - properties in the calendar component that the "Organizer" deems will - jeopardize the validity of the participation status of the - "Attendees". For example, changing the location of a meeting from one - locale to another distant locale could effectively impact the - participation status of the "Attendees". - - The "Organizer" includes this property in an iCalendar object that it - sends to an "Attendee" to specify the current version of the calendar - component. - - The "Attendee" includes this property in an iCalendar object that it - sends to the "Organizer" to specify the version of the calendar - component that the "Attendee" is referring to. - - - - -Dawson & Stenerson Standards Track [Page 132] - -RFC 2445 iCalendar November 1998 - - - A change to the sequence number is not the mechanism that an - "Organizer" uses to request a response from the "Attendees". The - "RSVP" parameter on the "ATTENDEE" property is used by the - "Organizer" to indicate that a response from the "Attendees" is - requested. - - Format Definition: This property is defined by the following - notation: - - seq = "SEQUENCE" seqparam ":" integer CRLF - ; Default is "0" - - seqparam = *(";" xparam) - - Example: The following is an example of this property for a calendar - component that was just created by the "Organizer". - - SEQUENCE:0 - - The following is an example of this property for a calendar component - that has been revised two different times by the "Organizer". - - SEQUENCE:2 - -4.8.8 Miscellaneous Component Properties - - The following properties specify information about a number of - miscellaneous features of calendar components. - -4.8.8.1 Non-standard Properties - - Property Name: Any property name with a "X-" prefix - - Purpose: This class of property provides a framework for defining - non-standard properties. - - Value Type: TEXT - - Property Parameters: Non-standard and language property parameters - can be specified on this property. - - Conformance: This property can be specified in any calendar - component. - - Description: The MIME Calendaring and Scheduling Content Type - provides a "standard mechanism for doing non-standard things". This - extension support is provided for implementers to "push the envelope" - on the existing version of the memo. Extension properties are - - - -Dawson & Stenerson Standards Track [Page 133] - -RFC 2445 iCalendar November 1998 - - - specified by property and/or property parameter names that have the - prefix text of "X-" (the two character sequence: LATIN CAPITAL LETTER - X character followed by the HYPEN-MINUS character). It is recommended - that vendors concatenate onto this sentinel another short prefix text - to identify the vendor. This will facilitate readability of the - extensions and minimize possible collision of names between different - vendors. User agents that support this content type are expected to - be able to parse the extension properties and property parameters but - can ignore them. - - At present, there is no registration authority for names of extension - properties and property parameters. The data type for this property - is TEXT. Optionally, the data type can be any of the other valid data - types. - - Format Definition: The property is defined by the following notation: - - x-prop = x-name *(";" xparam) [";" languageparam] ":" text CRLF - ; Lines longer than 75 octets should be folded - - Example: The following might be the ABC vendor's extension for an - audio-clip form of subject property: - - X-ABC-MMSUBJ;X-ABC-MMSUBJTYPE=wave:http://load.noise.org/mysubj.wav - -4.8.8.2 Request Status - - Property Name: REQUEST-STATUS - - Purpose: This property defines the status code returned for a - scheduling request. - - Value Type: TEXT - - Property Parameters: Non-standard and language property parameters - can be specified on this property. - - Conformance: The property can be specified in "VEVENT", "VTODO", - "VJOURNAL" or "VFREEBUSY" calendar component. - - Description: This property is used to return status code information - related to the processing of an associated iCalendar object. The data - type for this property is TEXT. - - The value consists of a short return status component, a longer - return status description component, and optionally a status-specific - data component. The components of the value are separated by the - SEMICOLON character (US-ASCII decimal 59). - - - -Dawson & Stenerson Standards Track [Page 134] - -RFC 2445 iCalendar November 1998 - - - The short return status is a PERIOD character (US-ASCII decimal 46) - separated 3-tuple of integers. For example, "3.1.1". The successive - levels of integers provide for a successive level of status code - granularity. - - The following are initial classes for the return status code. - Individual iCalendar object methods will define specific return - status codes for these classes. In addition, other classes for the - return status code may be defined using the registration process - defined later in this memo. - - |==============+===============================================| - | Short Return | Longer Return Status Description | - | Status Code | | - |==============+===============================================| - | 1.xx | Preliminary success. This class of status | - | | of status code indicates that the request has | - | | request has been initially processed but that | - | | completion is pending. | - |==============+===============================================| - | 2.xx | Successful. This class of status code | - | | indicates that the request was completed | - | | successfuly. However, the exact status code | - | | can indicate that a fallback has been taken. | - |==============+===============================================| - | 3.xx | Client Error. This class of status code | - | | indicates that the request was not successful.| - | | The error is the result of either a syntax or | - | | a semantic error in the client formatted | - | | request. Request should not be retried until | - | | the condition in the request is corrected. | - |==============+===============================================| - | 4.xx | Scheduling Error. This class of status code | - | | indicates that the request was not successful.| - | | Some sort of error occurred within the | - | | calendaring and scheduling service, not | - | | directly related to the request itself. | - |==============+===============================================| - - Format Definition: The property is defined by the following notation: - - rstatus = "REQUEST-STATUS" rstatparam ":" - statcode ";" statdesc [";" extdata] - - rstatparam = *( - - ; the following is optional, - ; but MUST NOT occur more than once - - - -Dawson & Stenerson Standards Track [Page 135] - -RFC 2445 iCalendar November 1998 - - - (";" languageparm) / - - ; the following is optional, - ; and MAY occur more than once - - (";" xparam) - - ) - - statcode = 1*DIGIT *("." 1*DIGIT) - ;Hierarchical, numeric return status code - - statdesc = text - ;Textual status description - - extdata = text - ;Textual exception data. For example, the offending property - ;name and value or complete property line. - - Example: The following are some possible examples of this property. - The COMMA and SEMICOLON separator characters in the property value - are BACKSLASH character escaped because they appear in a text value. - - REQUEST-STATUS:2.0;Success - - REQUEST-STATUS:3.1;Invalid property value;DTSTART:96-Apr-01 - - REQUEST-STATUS:2.8; Success\, repeating event ignored. Scheduled - as a single event.;RRULE:FREQ=WEEKLY\;INTERVAL=2 - - REQUEST-STATUS:4.1;Event conflict. Date/time is busy. - - REQUEST-STATUS:3.7;Invalid calendar user;ATTENDEE: - MAILTO:jsmith@host.com - -5 iCalendar Object Examples - - The following examples are provided as an informational source of - illustrative iCalendar objects consistent with this content type. - - The following example specifies a three-day conference that begins at - 8:00 AM EDT, September 18, 1996 and end at 6:00 PM EDT, September 20, - 1996. - - BEGIN:VCALENDAR PRODID:-//xyz Corp//NONSGML PDA Calendar Verson - 1.0//EN VERSION:2.0 BEGIN:VEVENT DTSTAMP:19960704T120000Z - UID:uid1@host.com ORGANIZER:MAILTO:jsmith@host.com - DTSTART:19960918T143000Z DTEND:19960920T220000Z STATUS:CONFIRMED - - - -Dawson & Stenerson Standards Track [Page 136] - -RFC 2445 iCalendar November 1998 - - - CATEGORIES:CONFERENCE SUMMARY:Networld+Interop Conference - DESCRIPTION:Networld+Interop Conference - and Exhibit\nAtlanta World Congress Center\n - Atlanta, Georgia END:VEVENT END:VCALENDAR - - The following example specifies a group scheduled meeting that begin - at 8:30 AM EST on March 12, 1998 and end at 9:30 AM EST on March 12, - 1998. The "Organizer" has scheduled the meeting with one or more - calendar users in a group. A time zone specification for Eastern - United States has been specified. - - BEGIN:VCALENDAR - PRODID:-//RDU Software//NONSGML HandCal//EN - VERSION:2.0 - BEGIN:VTIMEZONE - TZID:US-Eastern - BEGIN:STANDARD - DTSTART:19981025T020000 - RDATE:19981025T020000 - TZOFFSETFROM:-0400 - TZOFFSETTO:-0500 - TZNAME:EST - END:STANDARD - BEGIN:DAYLIGHT - DTSTART:19990404T020000 - RDATE:19990404T020000 - TZOFFSETFROM:-0500 - TZOFFSETTO:-0400 - TZNAME:EDT - END:DAYLIGHT - END:VTIMEZONE - BEGIN:VEVENT - DTSTAMP:19980309T231000Z - UID:guid-1.host1.com - ORGANIZER;ROLE=CHAIR:MAILTO:mrbig@host.com - ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;CUTYPE=GROUP: - MAILTO:employee-A@host.com - DESCRIPTION:Project XYZ Review Meeting - CATEGORIES:MEETING - CLASS:PUBLIC - CREATED:19980309T130000Z - SUMMARY:XYZ Project Review - DTSTART;TZID=US-Eastern:19980312T083000 - DTEND;TZID=US-Eastern:19980312T093000 - LOCATION:1CP Conference Room 4350 - END:VEVENT - END:VCALENDAR - - - - -Dawson & Stenerson Standards Track [Page 137] - -RFC 2445 iCalendar November 1998 - - - The following is an example of an iCalendar object passed in a MIME - message with a single body part consisting of a "text/calendar" - Content Type. - - TO:jsmith@host1.com - FROM:jdoe@host1.com - MIME-VERSION:1.0 - MESSAGE-ID: - CONTENT-TYPE:text/calendar - - BEGIN:VCALENDAR - METHOD:xyz - VERSION:2.0 - PRODID:-//ABC Corporation//NONSGML My Product//EN - BEGIN:VEVENT - DTSTAMP:19970324T1200Z - SEQUENCE:0 - UID:uid3@host1.com - ORGANIZER:MAILTO:jdoe@host1.com - ATTENDEE;RSVP=TRUE:MAILTO:jsmith@host1.com - DTSTART:19970324T123000Z - DTEND:19970324T210000Z - CATEGORIES:MEETING,PROJECT - CLASS:PUBLIC - SUMMARY:Calendaring Interoperability Planning Meeting - DESCRIPTION:Discuss how we can test c&s interoperability\n - using iCalendar and other IETF standards. - LOCATION:LDB Lobby - ATTACH;FMTTYPE=application/postscript:ftp://xyzCorp.com/pub/ - conf/bkgrnd.ps - END:VEVENT - END:VCALENDAR - - The following is an example of a to-do due on April 15, 1998. An - audio alarm has been specified to remind the calendar user at noon, - the day before the to-do is expected to be completed and repeat - hourly, four additional times. The to-do definition has been modified - twice since it was initially created. - - BEGIN:VCALENDAR - VERSION:2.0 - PRODID:-//ABC Corporation//NONSGML My Product//EN - BEGIN:VTODO - DTSTAMP:19980130T134500Z - SEQUENCE:2 - UID:uid4@host1.com - ORGANIZER:MAILTO:unclesam@us.gov - ATTENDEE;PARTSTAT=ACCEPTED:MAILTO:jqpublic@host.com - - - -Dawson & Stenerson Standards Track [Page 138] - -RFC 2445 iCalendar November 1998 - - - DUE:19980415T235959 - STATUS:NEEDS-ACTION - SUMMARY:Submit Income Taxes - BEGIN:VALARM - ACTION:AUDIO - TRIGGER:19980403T120000 - ATTACH;FMTTYPE=audio/basic:http://host.com/pub/audio- - files/ssbanner.aud - REPEAT:4 - DURATION:PT1H - END:VALARM - END:VTODO - END:VCALENDAR - - The following is an example of a journal entry. - - BEGIN:VCALENDAR - VERSION:2.0 - PRODID:-//ABC Corporation//NONSGML My Product//EN - BEGIN:VJOURNAL - DTSTAMP:19970324T120000Z - UID:uid5@host1.com - ORGANIZER:MAILTO:jsmith@host.com - STATUS:DRAFT - CLASS:PUBLIC - CATEGORY:Project Report, XYZ, Weekly Meeting - DESCRIPTION:Project xyz Review Meeting Minutes\n - Agenda\n1. Review of project version 1.0 requirements.\n2. - Definition - of project processes.\n3. Review of project schedule.\n - Participants: John Smith, Jane Doe, Jim Dandy\n-It was - decided that the requirements need to be signed off by - product marketing.\n-Project processes were accepted.\n - -Project schedule needs to account for scheduled holidays - and employee vacation time. Check with HR for specific - dates.\n-New schedule will be distributed by Friday.\n- - Next weeks meeting is cancelled. No meeting until 3/23. - END:VJOURNAL - END:VCALENDAR - - The following is an example of published busy time information. The - iCalendar object might be placed in the network resource - www.host.com/calendar/busytime/jsmith.ifb. - - BEGIN:VCALENDAR - VERSION:2.0 - PRODID:-//RDU Software//NONSGML HandCal//EN - BEGIN:VFREEBUSY - - - -Dawson & Stenerson Standards Track [Page 139] - -RFC 2445 iCalendar November 1998 - - - ORGANIZER:MAILTO:jsmith@host.com - DTSTART:19980313T141711Z - DTEND:19980410T141711Z - FREEBUSY:19980314T233000Z/19980315T003000Z - FREEBUSY:19980316T153000Z/19980316T163000Z - FREEBUSY:19980318T030000Z/19980318T040000Z - URL:http://www.host.com/calendar/busytime/jsmith.ifb - END:VFREEBUSY - END:VCALENDAR - -6 Recommended Practices - - These recommended practices should be followed in order to assure - consistent handling of the following cases for an iCalendar object. - - 1. Content lines longer than 75 octets SHOULD be folded. - - 2. A calendar entry with a "DTSTART" property but no "DTEND" - property does not take up any time. It is intended to represent - an event that is associated with a given calendar date and time - of day, such as an anniversary. Since the event does not take up - any time, it MUST NOT be used to record busy time no matter what - the value for the "TRANSP" property. - - 3. When the "DTSTART" and "DTEND", for "VEVENT", "VJOURNAL" and - "VFREEBUSY" calendar components, and "DTSTART" and "DUE", for - "VTODO" calendar components, have the same value data type (e.g., - DATE-TIME), they SHOULD specify values in the same time format - (e.g., UTC time format). - - 4. When the combination of the "RRULE" and "RDATE" properties on an - iCalendar object produces multiple instances having the same - start date/time, they should be collapsed to, and considered as, - a single instance. - - 5. When a calendar user receives multiple requests for the same - calendar component (e.g., REQUEST for a "VEVENT" calendar - component) as a result of being on multiple mailing lists - specified by "ATTENDEE" properties in the request, they SHOULD - respond to only one of the requests. The calendar user SHOULD - also specify (using the "MEMBER" parameter of the "ATTENDEE" - property) which mailing list they are a member of. - - 6. An implementation can truncate a "SUMMARY" property value to 255 - characters. - - - - - - -Dawson & Stenerson Standards Track [Page 140] - -RFC 2445 iCalendar November 1998 - - - 7. If seconds of the minute are not supported by an implementation, - then a value of "00" SHOULD be specified for the seconds - component in a time value. - - 8. If the value type parameter (VALUE=) contains an unknown value - type, it SHOULD be treated as TEXT. - - 9. TZURL values SHOULD NOT be specified as a FILE URI type. This URI - form can be useful within an organization, but is problematic in - the Internet. - - 10. Some possible English values for CATEGORIES property include - "ANNIVERSARY", "APPOINTMENT", "BUSINESS", "EDUCATION", - "HOLIDAY", "MEETING", "MISCELLANEOUS", "NON-WORKING HOURS", "NOT - IN OFFICE", "PERSONAL", "PHONE CALL", "SICK DAY", "SPECIAL - OCCASION", "TRAVEL", "VACATION". Categories can be specified in - any registered language. - - 11. Some possible English values for RESOURCES property include - "CATERING", "CHAIRS", "COMPUTER PROJECTOR", "EASEL", "OVERHEAD - PROJECTOR", "SPEAKER PHONE", "TABLE", "TV", "VCR", "VIDEO - PHONE", "VEHICLE". Resources can be specified in any registered - language. - -7 Registration of Content Type Elements - - This section provides the process for registration of MIME - Calendaring and Scheduling Content Type iCalendar object methods and - new or modified properties. - -7.1 Registration of New and Modified iCalendar Object Methods - - New MIME Calendaring and Scheduling Content Type iCalendar object - methods are registered by the publication of an IETF Request for - Comments (RFC). Changes to an iCalendar object method are registered - by the publication of a revision of the RFC defining the method. - -7.2 Registration of New Properties - - This section defines procedures by which new properties or enumerated - property values for the MIME Calendaring and Scheduling Content Type - can be registered with the IANA. Non-IANA properties can be used by - bilateral agreement, provided the associated properties names follow - the "X-" convention. - - The procedures defined here are designed to allow public comment and - review of new properties, while posing only a small impediment to the - definition of new properties. - - - -Dawson & Stenerson Standards Track [Page 141] - -RFC 2445 iCalendar November 1998 - - - Registration of a new property is accomplished by the following - steps. - -7.2.1 Define the property - - A property is defined by completing the following template. - - To: ietf-calendar@imc.org - - Subject: Registration of text/calendar MIME property XXX - - Property name: - - Property purpose: - - Property value type(s): - - Property parameter (s): - - Conformance: - - Description: - - Format definition: - - Examples: - - The meaning of each field in the template is as follows. - - Property name: The name of the property, as it will appear in the - body of an text/calendar MIME Content-Type "property: value" line to - the left of the colon ":". - - Property purpose: The purpose of the property (e.g., to indicate a - delegate for the event or to-do, etc.). Give a short but clear - description. - - Property value type (s): Any of the valid value types for the - property value needs to be specified. The default value type also - needs to be specified. If a new value type is specified, it needs to - be declared in this section. - - Property parameter (s): Any of the valid property parameters for the - property needs to be specified. - - Conformance: The calendar components that the property can appear in - needs to be specified. - - - - -Dawson & Stenerson Standards Track [Page 142] - -RFC 2445 iCalendar November 1998 - - - Description: Any special notes about the property, how it is to be - used, etc. - - Format definition: The ABNF for the property definition needs to be - specified. - - Examples: One or more examples of instances of the property needs to - be specified. - -7.2.2 Post the Property definition - - The property description MUST be posted to the new property - discussion list, ietf-calendar@imc.org. - -7.2.3 Allow a comment period - - Discussion on the new property MUST be allowed to take place on the - list for a minimum of two weeks. Consensus MUST be reached on the - property before proceeding to the next step. - -7.2.4 Submit the property for approval - - Once the two-week comment period has elapsed, and the proposer is - convinced consensus has been reached on the property, the - registration application should be submitted to the Method Reviewer - for approval. The Method Reviewer is appointed to the Application - Area Directors and can either accept or reject the property - registration. An accepted registration should be passed on by the - Method Reviewer to the IANA for inclusion in the official IANA method - registry. The registration can be rejected for any of the following - reasons. 1) Insufficient comment period; 2) Consensus not reached; 3) - Technical deficiencies raised on the list or elsewhere have not been - addressed. The Method Reviewer's decision to reject a property can be - appealed by the proposer to the IESG, or the objections raised can be - addressed by the proposer and the property resubmitted. - -7.3 Property Change Control - - Existing properties can be changed using the same process by which - they were registered. - - 1. Define the change - - 2. Post the change - - 3. Allow a comment period - - 4. Submit the property for approval - - - -Dawson & Stenerson Standards Track [Page 143] - -RFC 2445 iCalendar November 1998 - - - Note that the original author or any other interested party can - propose a change to an existing property, but that such changes - should only be proposed when there are serious omissions or errors in - the published memo. The Method Reviewer can object to a change if it - is not backward compatible, but is not required to do so. - - Property definitions can never be deleted from the IANA registry, but - properties which are no longer believed to be useful can be declared - OBSOLETE by a change to their "intended use" field. - -8 References - - [IMIP] Dawson, F., Mansour, S. and S. Silverberg, "iCalendar - Message-based Interoperability Protocol (IMIP)", RFC 2447, - November 1998. - - [ITIP] Silverberg, S., Mansour, S., Dawson, F. and R. Hopson, - "iCalendar Transport-Independent Interoperability Protocol - (iTIP) : Scheduling Events, Busy Time, To-dos and Journal - Entries", RFC 2446, November 1998. - - [ISO 8601] ISO 8601, "Data elements and interchange formats- - Information interchange--Representation of dates and - times", International Organization for Standardization, - June, 1988. - - [ISO 9070] ISO/IEC 9070, "Information Technology_SGML Support - Facilities--Registration Procedures for Public Text Owner - Identifiers", Second Edition, International Organization - for Standardization, April 1991. - - [RFC 822] Crocker, D., "Standard for the Format of ARPA Internet - Text Messages", STD 11, RFC 822, August 1982. - - [RFC 1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform - Resource Locators (URL)", RFC 1738, December 1994. - - [RFC 1766] Alvestrand, H., "Tags for the Identification of - Languages", RFC 1766, March 1995. - - [RFC 2045] Freed, N. and N. Borenstein, " Multipurpose Internet Mail - Extensions (MIME) - Part One: Format of Internet Message - Bodies", RFC 2045, November 1996. - - [RFC 2046] Freed, N. and N. Borenstein, " Multipurpose Internet Mail - Extensions (MIME) - Part Two: Media Types", RFC 2046, - November 1996. - - - - -Dawson & Stenerson Standards Track [Page 144] - -RFC 2445 iCalendar November 1998 - - - [RFC 2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose - Internet Mail Extensions (MIME) - Part Four: Registration - Procedures", RFC 2048, January 1997. - - [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC 2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", RFC 2234, November 1997. - - [RFC 2279] Yergeau, F., "UTF-8, a transformation format of ISO - 10646", RFC 2279, January 1998. - - [RFC 2425] Howes, T., Smith, M. and F. Dawson, "A MIME Content-Type - for Directory Information", RFC 2425, September 1998. - - [RFC 2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile", - RFC 2426, September 1998. - - [TZ] Olson, A.D., et al, Time zone code and data, - ftp://elsie.nci.nih.gov/pub/, updated periodically. - - [VCAL] Internet Mail Consortium, "vCalendar - The Electronic - Calendaring and Scheduling Exchange Format", - http://www.imc.org/pdi/vcal-10.txt, September 18, 1996. - -9 Acknowledgments - - A hearty thanks to the IETF Calendaring and Scheduling Working Group - and also the following individuals who have participated in the - drafting, review and discussion of this memo: - - Roland Alden, Harald T. Alvestrand, Eric Berman, Denis Bigorgne, John - Binici, Bill Bliss, Philippe Boucher, Steve Carter, Andre - Courtemanche, Dave Crocker, David Curley, Alec Dun, John Evans, Ross - Finlayson, Randell Flint, Ned Freed, Patrik Faltstrom, Chuck - Grandgent, Mark Handley, Steve Hanna, Paul B. Hill, Paul Hoffman, - Ross Hopson, Mark Horton, Daryl Huff, Bruce Kahn, C. Harald Koch, - Ryan Jansen, Don Lavange, Antoine Leca, Theodore Lorek, Steve - Mansour, Skip Montanaro, Keith Moore, Cecil Murray, Chris Newman, - John Noerenberg, Ralph Patterson, Pete Resnick, Keith Rhodes, Robert - Ripberger, John Rose, Doug Royer, Andras Salamar, Ted Schuh, Vinod - Seraphin, Derrick Shadel, Ken Shan, Andrew Shuman, Steve Silverberg, - William P. Spencer, John Sun, Mark Towfiq, Yvonne Tso, Robert Visnov, - James L. Weiner, Mike Weston, William Wyatt. - - - - - - -Dawson & Stenerson Standards Track [Page 145] - -RFC 2445 iCalendar November 1998 - - -10 Authors' and Chairs' Addresses - - The following address information is provided in a MIME-VCARD, - Electronic Business Card, format. - - The authors of this memo are: - - BEGIN:VCARD - VERSION:3.0 - N:Dawson;Frank - FN:Frank Dawson - ORG:Lotus Development Corporation - ADR;TYPE=WORK,POSTAL,PARCEL:;;6544 Battleford Drive; - Raleigh;NC;27613-3502;USA - TEL;TYPE=WORK,MSG:+1-919-676-9515 - TEL;TYPE=WORK,FAX:+1-919-676-9564 - EMAIL;TYPE=PREF,INTERNET:Frank_Dawson@Lotus.com - EMAIL;TYPE=INTERNET:fdawson@earthlink.net - URL:http://home.earthlink.net/~fdawson - END:VCARD - - BEGIN:VCARD - VERSION:3.0 - N:Stenerson;Derik - FN:Derik Stenerson - ORG:Microsoft Corporation - ADR;TYPE=WORK,POSTAL,PARCEL:;;One Microsoft Way; - Redmond;WA;98052-6399;USA - TEL;TYPE=WORK,MSG:+1-425-936-5522 - TEL;TYPE=WORK,FAX:+1-425-936-7329 - EMAIL;TYPE=INTERNET:deriks@Microsoft.com - END:VCARD - - The iCalendar object is a result of the work of the Internet - Engineering Task Force Calendaring and Scheduling Working Group. The - chairmen of that working group are: - - BEGIN:VCARD - VERSION:3.0 - N:Ganguly;Anik - FN:Anik Ganguly - ORG: Open Text Inc. - ADR;TYPE=WORK,POSTAL,PARCEL:;Suite 101;38777 West Six Mile Road; - Livonia;MI;48152;USA - TEL;TYPE=WORK,MSG:+1-734-542-5955 - EMAIL;TYPE=INTERNET:ganguly@acm.org - END:VCARD - - - - -Dawson & Stenerson Standards Track [Page 146] - -RFC 2445 iCalendar November 1998 - - - The co-chairman of that working group is: - - BEGIN:VCARD - VERSION:3.0 - N:Moskowitz;Robert - FN:Robert Moskowitz - EMAIL;TYPE=INTERNET:rgm-ietf@htt-consult.com - END:VCARD - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Dawson & Stenerson Standards Track [Page 147] - -RFC 2445 iCalendar November 1998 - - -11. Full Copyright Statement - - Copyright (C) The Internet Society (1998). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - -Dawson & Stenerson Standards Track [Page 148] - diff --git a/etc/rfc2446.txt b/etc/rfc2446.txt deleted file mode 100644 index 8e038a283..000000000 --- a/etc/rfc2446.txt +++ /dev/null @@ -1,6107 +0,0 @@ - - - - - - -Network Working Group S. Silverberg -Request for Comments: 2446 Microsoft -Category: Standards Track S. Mansour - Netscape - F. Dawson - Lotus - R. Hopson - ON Technologies - November 1998 - - - iCalendar Transport-Independent Interoperability Protocol - (iTIP) - Scheduling Events, BusyTime, To-dos and Journal Entries - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1998). All Rights Reserved. - -Abstract - - This document specifies how calendaring systems use iCalendar objects - to interoperate with other calendar systems. It does so in a general - way so as to allow multiple methods of communication between systems. - Subsequent documents specify interoperable methods of communications - between systems that use this protocol. - - The document outlines a model for calendar exchange that defines both - static and dynamic event, to-do, journal and free/busy objects. - Static objects are used to transmit information from one entity to - another without the expectation of continuity or referential - integrity with the original item. Dynamic objects are a superset of - static objects and will gracefully degrade to their static - counterparts for clients that only support static objects. - - This document specifies an Internet protocol based on the iCalendar - object specification that provides scheduling interoperability - between different calendar systems. The Internet protocol is called - the "iCalendar Transport-Independent Interoperability Protocol - (iTIP)". - - - -Silverberg, et. al. Standards Track [Page 1] - -RFC 2446 iTIP November 1998 - - - iTIP complements the iCalendar object specification by adding - semantics for group scheduling methods commonly available in current - calendar systems. These scheduling methods permit two or more - calendar systems to perform transactions such as publish, schedule, - reschedule, respond to scheduling requests, negotiation of changes or - cancel iCalendar-based calendar components. - - iTIP is defined independent of the particular transport used to - transmit the scheduling information. Companion memos to iTIP provide - bindings of the interoperability protocol to a number of Internet - protocols. - -Table of Contents - - 1 INTRODUCTION...................................................5 - 1.1 FORMATTING CONVENTIONS .....................................5 - 1.2 RELATED DOCUMENTS ..........................................6 - 1.3 ITIP ROLES AND TRANSACTIONS ................................6 - 2 INTEROPERABILITY MODELS........................................8 - 2.1 APPLICATION PROTOCOL .......................................9 - 2.1.1 Calendar Entry State ...................................9 - 2.1.2 Delegation .............................................9 - 2.1.3 Acting on Behalf of other Calendar Users ..............10 - 2.1.4 Component Revisions ...................................10 - 2.1.5 Message Sequencing ....................................11 - 3 APPLICATION PROTOCOL ELEMENTS.................................12 - 3.1 COMMON COMPONENT RESTRICTION TABLES .......................13 - 3.2 METHODS FOR VEVENT CALENDAR COMPONENTS ....................14 - 3.2.1 PUBLISH ...............................................15 - 3.2.2 REQUEST ...............................................17 - 3.2.2.1 Rescheduling an Event..............................19 - 3.2.2.2 Updating or Reconfirmation of an Event.............19 - 3.2.2.3 Delegating an Event to another CU..................19 - 3.2.2.4 Changing the Organizer.............................20 - 3.2.2.5 Sending on Behalf of the Organizer.................20 - 3.2.2.6 Forwarding to An Uninvited CU......................20 - 3.2.2.7 Updating Attendee Status...........................21 - 3.2.3 REPLY .................................................21 - 3.2.4 ADD ...................................................23 - 3.2.5 CANCEL ................................................25 - 3.2.6 REFRESH ...............................................26 - 3.2.7 COUNTER ...............................................28 - 3.2.8 DECLINECOUNTER ........................................29 - 3.3 METHODS FOR VFREEBUSY COMPONENTS ..........................31 - 3.3.1 PUBLISH ...............................................32 - 3.3.2 REQUEST ...............................................33 - 3.3.3 REPLY .................................................34 - 3.4 METHODS FOR VTODO COMPONENTS ..............................35 - - - -Silverberg, et. al. Standards Track [Page 2] - -RFC 2446 iTIP November 1998 - - - 3.4.1 PUBLISH ...............................................35 - 3.4.2 REQUEST ...............................................37 - 3.4.2.1 REQUEST for Rescheduling a VTODO...................39 - 3.4.2.2 REQUEST for Update or Reconfirmation of a VTODO....39 - 3.4.2.3 REQUEST for Delegating a VTODO.....................40 - 3.4.2.4 REQUEST Forwarded To An Uninvited Calendar User....40 - 3.4.2.5 REQUEST Updated Attendee Status....................41 - 3.4.3 REPLY .................................................41 - 3.4.4 ADD ...................................................43 - 3.4.5 CANCEL ................................................44 - 3.4.6 REFRESH ...............................................46 - 3.4.7 COUNTER ...............................................48 - 3.4.8 DECLINECOUNTER ........................................49 - 3.5 METHODS FOR VJOURNAL COMPONENTS ...........................50 - 3.5.1 PUBLISH ...............................................51 - 3.5.2 ADD ...................................................52 - 3.5.3 CANCEL ................................................53 - 3.6 STATUS REPLIES ............................................55 - 3.7 IMPLEMENTATION CONSIDERATIONS .............................57 - 3.7.1 Working With Recurrence Instances .....................57 - 3.7.2 Attendee Property Considerations ......................58 - 3.7.3 X-Tokens ..............................................59 - 4 EXAMPLES......................................................59 - 4.1 PUBLISHED EVENT EXAMPLES ..................................59 - 4.1.1 A Minimal Published Event .............................60 - 4.1.2 Changing A Published Event ............................60 - 4.1.3 Canceling A Published Event ...........................61 - 4.1.4 A Rich Published Event ................................62 - 4.1.5 Anniversaries or Events attached to entire days .......63 - 4.2 GROUP EVENT EXAMPLES ......................................63 - 4.2.1 A Group Event Request .................................64 - 4.2.2 Reply To A Group Event Request ........................65 - 4.2.3 Update An Event .......................................65 - 4.2.4 Countering an Event Proposal ..........................66 - 4.2.5 Delegating an Event ...................................68 - 4.2.6 Delegate Accepts the Meeting ..........................70 - 4.2.7 Delegate Declines the Meeting .........................71 - 4.2.8 Forwarding an Event Request ...........................72 - 4.2.9 Cancel A Group Event ..................................72 - 4.2.10 Removing Attendees ...................................74 - 4.2.11 Replacing the Organizer ..............................75 - 4.3 BUSY TIME EXAMPLES ........................................76 - 4.3.1 Request Busy Time .....................................77 - 4.3.2 Reply To A Busy Time Request ..........................77 - 4.4 RECURRING EVENT AND TIME ZONE EXAMPLES ....................78 - 4.4.1 A Recurring Event Spanning Time Zones .................78 - 4.4.2 Modify A Recurring Instance ...........................79 - 4.4.3 Cancel an Instance ....................................81 - - - -Silverberg, et. al. Standards Track [Page 3] - -RFC 2446 iTIP November 1998 - - - 4.4.4 Cancel Recurring Event ................................81 - 4.4.5 Change All Future Instances ...........................82 - 4.4.6 Add A New Instance To A Recurring Event ...............82 - 4.4.7 Add A New Series of Instances To A Recurring Event ....83 - 4.4.8 Counter An Instance Of A Recurring Event ..............87 - 4.4.9 Error Reply To A Request ..............................88 - 4.5 GROUP TO-DO EXAMPLES ......................................89 - 4.5.1 A VTODO Request .......................................90 - 4.5.2 A VTODO Reply .........................................90 - 4.5.3 A VTODO Request for Updated Status ....................91 - 4.5.4 A Reply: Percent-Complete .............................91 - 4.5.5 A Reply: Completed ....................................92 - 4.5.6 An Updated VTODO Request ..............................92 - 4.5.7 Recurring VTODOs ......................................92 - 4.5.7.1 Request for a Recurring VTODO......................93 - 4.5.7.2 Calculating due dates in recurring VTODOs..........93 - 4.5.7.3 Replying to an instance of a recurring VTODO.......93 - 4.6 JOURNAL EXAMPLES ..........................................94 - 4.7 OTHER EXAMPLES ............................................94 - 4.7.1 Event Refresh .........................................94 - 4.7.2 Bad RECURRENCE-ID .....................................95 - 5 APPLICATION PROTOCOL FALLBACKS................................97 - 5.1 PARTIAL IMPLEMENTATION ....................................97 - 5.1.1 Event-Related Fallbacks ...............................97 - 5.1.2 Free/Busy-Related Fallbacks ...........................99 - 5.1.3 To-Do-Related Fallbacks ...............................99 - 5.1.4 Journal-Related Fallbacks ............................101 - 5.2 LATENCY ISSUES ...........................................102 - 5.2.1 Cancellation of an Unknown Calendar Component. .......102 - 5.2.2 Unexpected Reply from an Unknown Delegate ............103 - 5.3 SEQUENCE NUMBER ..........................................103 - 6 SECURITY CONSIDERATIONS......................................103 - 6.1 SECURITY THREATS .........................................103 - 6.1.1 Spoofing the "Organizer" .............................103 - 6.1.2 Spoofing the "Attendee" ..............................103 - 6.1.3 Unauthorized Replacement of the Organizer ............104 - 6.1.4 Eavesdropping ........................................104 - 6.1.5 Flooding a Calendar ..................................104 - 6.1.6 Procedural Alarms ....................................104 - 6.1.7 Unauthorized REFRESH Requests ........................104 - 6.2 RECOMMENDATIONS ..........................................104 - 6.2.1 Use of [RFC-1847] to secure iTIP transactions ........105 - 6.2.2 Implementation Controls ..............................105 - 7 ACKNOWLEDGMENTS..............................................106 - 8 BIBLIOGRAPHY.................................................106 - 9 AUTHORS' ADDRESSES...........................................107 - 10 FULL COPYRIGHT STATEMENT....................................109 - - - - -Silverberg, et. al. Standards Track [Page 4] - -RFC 2446 iTIP November 1998 - - -1 Introduction - - This document specifies how calendaring systems use iCalendar objects - to interoperate with other calendar systems. In particular, it - specifies how to schedule events, to-dos, or daily journal entries. - It further specifies how to search for available busy time - information. It does so in a general way so as to allow multiple - methods of communication between systems. Subsequent documents - specify transport bindings between systems that use this protocol. - - This protocol is based on messages sent from an originator to one or - more recipients. For certain types of messages, a recipient may - reply, in order to update their status and may also return - transaction/request status information. The protocol supports the - ability for the message originator to modify or cancel the original - message. The protocol also supports the ability for recipients to - suggest changes to the originator of a message. The elements of the - protocol also define the user roles for its transactions. - -1.1 Formatting Conventions - - In order to refer to elements of the calendaring and scheduling - model, core object or interoperability protocol defined in [iCAL] and - [iTIP] several formatting conventions have been utilized. - - 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 [RFC-2119]. - - Calendaring and scheduling roles are referred to in quoted-strings of - text with the first character of each word in upper case. For - example, "Organizer" refers to a role of a "Calendar User" (CU) - within the scheduling protocol defined by [iTIP]. Calendar components - defined by [iCAL] are referred to with capitalized, quoted-strings of - text. All calendar components start with the letter "V". For example, - "VEVENT" refers to the event calendar component, "VTODO" refers to - the to-do calendar component and "VJOURNAL" refers to the daily - journal calendar component. Scheduling methods defined by [iTIP] are - referred to with capitalized, quoted-strings of text. For example, - "REQUEST" refers to the method for requesting a scheduling calendar - component be created or modified, "REPLY" refers to the method a - recipient of a request uses to update their status with the - "Organizer" of the calendar component. - - Properties defined by [iCAL] are referred to with capitalized, - quoted-strings of text, followed by the word "property". For example, - "ATTENDEE" property refers to the iCalendar property used to convey - the calendar address of a "Calendar User". Property parameters - - - -Silverberg, et. al. Standards Track [Page 5] - -RFC 2446 iTIP November 1998 - - - defined by this memo are referred to with lower case, quoted-strings - of text, followed by the word "parameter". For example, "value" - parameter refers to the iCalendar property parameter used to override - the default data type for a property value. Enumerated values defined - by this memo are referred to with capitalized text, either alone or - followed by the word "value". - - In tables, the quoted-string text is specified without quotes in - order to minimize the table length. - -1.2 Related Documents - - Implementers will need to be familiar with several other memos that, - along with this one, describe the Internet calendaring and scheduling - standards. This document, [iTIP], specifies an interoperability - protocol for scheduling between different implementations. The - related documents are: - - [iCAL] - specifies the objects, data types, properties and - property parameters used in the protocols, along with the - methods for representing and encoding them; - - [iMIP] specifies an Internet email binding for [iTIP]. - - This memo does not attempt to repeat the specification of concepts or - definitions from these other memos. Where possible, references are - made to the memo that provides for the specification of these - concepts or definitions. - -1.3 ITIP Roles and Transactions - - ITIP defines methods for exchanging [iCAL] objects for the purposes - of group calendaring and scheduling between "Calendar Users" (CUs). - CUs take on one of two roles in iTIP. The CU who initiates an - exchange takes on the role of "Organizer". For example, the CU who - proposes a group meeting is the "Organizer". The CUs asked to - participate in the group meeting by the "Organizer" take on the role - of "Attendee". Note that "role" is also a descriptive parameter to - the _ATTENDEE_ property. Its use is to convey descriptive context to - an "Attendee" such as "chair", "req-participant" or "non-participant" - and has nothing to do with the calendaring workflow. - - - - - - - - - - -Silverberg, et. al. Standards Track [Page 6] - -RFC 2446 iTIP November 1998 - - - The ITIP methods are listed below and their usage and semantics are - defined in section 3 of this document. - - +================+==================================================+ - | Method | Description | - |================+==================================================| - | PUBLISH | Used to publish a calendar entry to one or more | - | | Calendar Users. There is no interactivity | - | | between the publisher and any other calendar | - | | user. An example might include a baseball team | - | | publishing its schedule to the public. | - | | | - | REQUEST | Used to schedule a calendar entry with other | - | | Calendar Users. Requests are interactive in that | - | | they require the receiver to respond using | - | | the Reply methods. Meeting Requests, Busy | - | | Time requests and the assignment of VTODOs to | - | | other Calendar Users are all examples. | - | | Requests are also used by the "Organizer" to | - | | update the status of a calendar entry. | - | | | - | REPLY | A Reply is used in response to a Request to | - | | convey "Attendee" status to the "Organizer". | - | | Replies are commonly used to respond to meeting | - | | and task requests. | - | | | - | ADD | Add one or more instances to an existing | - | | VEVENT, VTODO, or VJOURNAL. | - | | | - | CANCEL | Cancel one or more instances of an existing | - | | VEVENT, VTODO, or VJOURNAL. | - | | | - | REFRESH | The Refresh method is used by an "Attendee" to | - | | request the latest version of a calendar entry. | - | | | - | COUNTER | The Counter method is used by an "Attendee" to | - | | negotiate a change in the calendar entry. | - | | Examples include the request to change a | - | | proposed Event time or change the due date for a | - | | VTODO. | - | | | - | DECLINE- | Used by the "Organizer" to decline the proposed | - | COUNTER | counter-proprosal. | - +================+==================================================+ - - - - - - - -Silverberg, et. al. Standards Track [Page 7] - -RFC 2446 iTIP November 1998 - - - Group scheduling in iTIP is accomplished using the set of "request" - and "response" methods described above. The following table shows the - methods broken down by who can send them. - - +================+==================================================+ - | Originator | Methods | - |================+==================================================| - | Organizer | PUBLISH, REQUEST, ADD, CANCEL, DECLINECOUNTER | - | | | - | Attendee | REPLY, REFRESH, COUNTER | - | | REQUEST only when delegating | - +================+==================================================+ - - Note that for some calendar component types, the allowable methods - are a subset of the above set. - -2 Interoperability Models - - There are two distinct protocols relevant to interoperability: an - "Application Protocol" and a "Transport Protocol". The Application - Protocol defines the content of the iCalendar objects sent between - sender and receiver to accomplish the scheduling transactions listed - above. The Transport Protocol defines how the iCalendar objects are - sent between the sender and receiver. This document focuses on the - Application Protocol. Binding documents such as [iMIP] focus on the - Transport Protocol. - - The connection between Sender and Receiver in the diagram below - refers to the Application Protocol. The iCalendar objects passed from - the Sender to the Receiver are presented in Section 3, Application - Protocol Elements. - - +----------+ +----------+ - | | iTIP | | - | Sender |<-------------------->| Receiver | - | | | | - +----------+ +----------+ - - There are several variations of this diagram in which the Sender and - Receiver take on various roles of a "Calendar User Agent" (CUA) or a - "Calendar Service" (CS). - - The architecture of iTIP is depicted in the diagram below. An - application written to this specification may work with bindings for - the store-and-forward transport, the real time transport, or both. - Also note that iTIP could be bound to other transports. - - - - - -Silverberg, et. al. Standards Track [Page 8] - -RFC 2446 iTIP November 1998 - - - +------------------------------------------+ - | iTIP | - +------------------------------------------+ - |Real-time | Store-and-Fwd | Other | - |Transport | Transport | Transports... | - +------------------------------------------+ - -2.1 Application Protocol - - In the iTIP model, a calendar entry is created and managed by an - "Organizer". The "Organizer" interacts with other CUs by sending one - or more of the iTIP messages listed above. "Attendees" use the - "REPLY" method to communicate their status. "Attendees" do not make - direct changes to the master calendar entry. They can, however, use - the "COUNTER" method to suggest changes to the "Organizer". In any - case, the "Organizer" has complete control over the master calendar - entry. - -2.1.1 Calendar Entry State - - There are two distinct states relevant to calendar entries: the - overall state of the entry and the state associated with an - "Attendee" to that entry. - - The state of an entry is defined by the "STATUS" property and is - controlled by the "Organizer." There is no default value for the - "STATUS" property. The "Organizer" sets the "STATUS" property to the - appropriate value for each calendar entry. - - The state of a particular "Attendee" relative to an entry is defined - by the "partstat" parameter in the "ATTENDEE" property for each - "Attendee". When an "Organizer" issues the initial entry, "Attendee" - status is unknown. The "Organizer" specifies this by setting the - "partstat" parameter to "NEEDS-ACTION". Each "Attendee" modifies - their "ATTENDEE" property "partstat" parameter to an appropriate - value as part of a "REPLY" message sent back to the "Organizer". - -2.1.2 Delegation - - Delegation is defined as the process by which an "Attendee" grants - another CU (or several CUs) the right to attend on their behalf. The - "Organizer" is made aware of this change because the delegating - "Attendee" informs the "Organizer". These steps are detailed in the - REQUEST method section. - - - - - - - -Silverberg, et. al. Standards Track [Page 9] - -RFC 2446 iTIP November 1998 - - -2.1.3 Acting on Behalf of other Calendar Users - - In many organizations one user will act on behalf of another to - organize and/or respond to meeting requests. ITIP provides two - mechanisms that support these activities. - - First, the "Organizer" is treated as a special entity, separate from - "Attendees". All responses from "Attendees" flow to the "Organizer", - making it easy to separate a calendar user organizing a meeting from - calendar users attending the meeting. Additionally, iCalendar - provides descriptive roles for each "Attendee". For instance, a role - of "chair" may be ascribed to one or more "Attendees". The "chair" - and the "Organizer" may or may not be the same calendar user. This - maps well to scenarios where an assistant may manage meeting - logistics for another individual who chairs a meeting. - - Second, a "sent-by" parameter may be specified in either the - "Organizer" or "Attendee" properties. When specified, the "sent-by" - parameter indicates that the responding CU acted on behalf of the - specified "Attendee" or "Organizer". - -2.1.4 Component Revisions - - The "SEQUENCE" property is used by the "Organizer" to indicate - revisions to the calendar component. The rules for incrementing the - "SEQUENCE" number are defined in [iCAL]. For clarity, these rules are - paraphrased here in terms of how they are applied in [iTIP]. For a - given "UID" in a calendar component: - - . For the "PUBLISH" and "REQUEST" methods, the "SEQUENCE" property - value is incremented according to the rules defined in [iCAL]. - - . The "SEQUENCE" property value MUST be incremented each time the - "Organizer" uses the "ADD" or "CANCEL" methods. - - . The "SEQUENCE" property value MUST NOT be incremented when using - "REPLY", "REFRESH", "COUNTER", "DECLINECOUNTER", or when sending a - delegation "REQUEST". - - In some circumstances the "Organizer" may not have received responses - to the final revision sent out. In this situation, the "Organizer" - may wish to send an update "REQUEST", and set "RSVP=TRUE" for all - "Attendees", so that current responses can be collected. - - - - - - - - -Silverberg, et. al. Standards Track [Page 10] - -RFC 2446 iTIP November 1998 - - - The value of the "SEQUENCE" property contained in a response from an - "Attendee" may not always match the "Organizer's" revision. - Implementations may choose to have the CUA indicate to the CU that - the response is to an entry that has been revised and allow the CU to - decide whether or not to accept the response. - -2.1.5 Message Sequencing - - CUAs that handle the [iTIP] application protocol must often correlate - a component in a calendar store with a component received in the - [iTIP] message. For example, an event may be updated with a later - revision of the same event. To accomplish this, a CUA must correlate - the version of the event already in its calendar store with the - version sent in the [iTIP] message. In addition to this correlation, - there are several factors that can cause [iTIP] messages to arrive in - an unexpected order. That is, an "Organizer" could receive a reply - to an earlier revision of a component AFTER receiving a reply to a - later revision. - - To maximize interoperability and to handle messages that arrive in an - unexpected order, use the following rules: - - 1. The primary key for referencing a particular iCalendar component - is the "UID" property value. To reference an instance of a - recurring component, the primary key is composed of the "UID" and - the "RECURRENCE-ID" properties. - - 2. The secondary key for referencing a component is the "SEQUENCE" - property value. For components where the "UID" is the same, the - component with the highest numeric value for the "SEQUENCE" - property obsoletes all other revisions of the component with - lower values. - - 3. "Attendees" send "REPLY" messages to the "Organizer". For - replies where the "UID" property value is the same, the value of - the "SEQUENCE" property indicates the revision of the component - to which the "Attendee" is replying. The reply with the highest - numeric value for the "SEQUENCE" property obsoletes all other - replies with lower values. - - 4. In situations where the "UID" and "SEQUENCE" properties match, - the "DTSTAMP" property is used as the tie-breaker. The component - with the latest "DTSTAMP" overrides all others. Similarly, for - "Attendee" responses where the "UID" property values match and - the "SEQUENCE" property values match, the response with the - latest "DTSTAMP" overrides all others. - - - - - -Silverberg, et. al. Standards Track [Page 11] - -RFC 2446 iTIP November 1998 - - - Hence, CUAs must persist the following component properties: "UID", - "RECURRENCE-ID", "SEQUENCE", and "DTSTAMP". Furthermore, for each - "ATTENDEE" property of a component CUAs must persist the "SEQUENCE" - and "DTSTAMP" property values associated with the "Attendee's" - response. - -3 Application Protocol Elements - - ITIP messages are "text/calendar" MIME entities that contain - calendaring and scheduling information. The particular type of [iCAL] - message is referred to as the "method type". Each method type is - identified by a "METHOD" property specified as part of the - "text/calendar" content type. The table below shows various - combinations of calendar components and the method types that this - memo supports. - - +=================================================+ - | | VEVENT | VTODO | VJOURNAL | VFREEBUSY | - |=================================================| - |Publish | Yes | Yes | Yes | Yes | - |Request | Yes | Yes | No | Yes | - |Refresh | Yes | Yes | No | No | - |Cancel | Yes | Yes | Yes | No | - |Add | Yes | Yes | Yes | No | - |Reply | Yes | Yes | No | Yes | - |Counter | Yes | Yes | No | No | - |Decline- | | | | | - |Counter | Yes | Yes | No | No | - +=================================================+ - - Each method type is defined in terms of its associated components and - properties. Some components and properties are required, some are - optional and others are excluded. The restrictions are expressed in - this document using a simple "restriction table". The first column - indicates the name of a component or property. Properties of the - iCalendar object are not indented. Properties of a component are - indented. The second column contains "MUST" if the component or - property must be present, "MAY" if the component or property is - optional, and "NOT" if the component or property must not be present. - Entries in the second column sometimes contain comments for further - clarification. - - - - - - - - - - -Silverberg, et. al. Standards Track [Page 12] - -RFC 2446 iTIP November 1998 - - -3.1 Common Component Restriction Tables - - The restriction table below applies to properties of the iCalendar - object. That is, the properties at the outermost scope. The presence - column uses the following values to assert whether a property is - required, is optional and the number of times it may appear in the - iCalendar object. - - Presence Value Description - -------------------------------------------------------------- - 1 One instance MUST be present - 1+ At least one instance MUST be present - 0 Instances of this property Must NOT be present - 0+ Multiple instances MAY be present - 0 or 1 Up to 1 instance of this property MAY be present - --------------------------------------------------------------- - - The tables also call out "X-PROPERTY" and "X-COMPONENT" to show - where vendor-specific properties and components can appear. The - tables do not lay out the restrictions of property parameters. Those - restrictions are defined in [iCAL]. - - Component/Property Presence - ------------------- ---------------------------------------------- - CALSCALE 0 or 1 - PRODID 1 - VERSION 1 Value MUST be "2.0" - X-PROPERTY 0+ - - - DateTime values MAY refer to a "VTIMEZONE" component. The property - restrictions in the table below apply to any "VTIMEZONE" component in - an ITIP message. - - Component/Property Presence - ------------------- ---------------------------------------------- - VTIMEZONE 0+ MUST be present if any date/time refers - to timezone - DAYLIGHT 0+ MUST be one or more of either STANDARD or - DAYLIGHT - COMMENT 0 or 1 - DTSTART 1 MUST be local time format - RDATE 0+ if present RRULE MUST NOT be present - RRULE 0+ if present RDATE MUST NOT be present - TZNAME 0 or 1 - TZOFFSET 1 - TZOFFSETFROM 1 - TZOFFSETTO 1 - - - -Silverberg, et. al. Standards Track [Page 13] - -RFC 2446 iTIP November 1998 - - - X-PROPERTY 0+ - LAST-MODIFIED 0 or 1 - STANDARD 0+ MUST be one or more of either STANDARD or - DAYLIGHT - COMMENT 0 or 1 - DTSTART 1 MUST be local time format - RDATE 0+ if present RRULE MUST NOT be present - RRULE 0+ if present RDATE MUST NOT be present - TZNAME 0 or 1 - TZOFFSETFROM 1 - TZOFFSETTO 1 - X-PROPERTY 0+ - TZID 1 - TZURL 0 or 1 - X-PROPERTY 0+ - - The property restrictions in the table below apply to any "VALARM" - component in an ITIP message. - - Component/Property Presence - ------------------- ---------------------------------------------- - VALARM 0+ - ACTION 1 - ATTACH 0+ - DESCRIPTION 0 or 1 - DURATION 0 or 1 if present REPEAT MUST be present - REPEAT 0 or 1 if present DURATION MUST be present - SUMMARY 0 or 1 - TRIGGER 1 - X-PROPERTY 0+ - -3.2 Methods for VEVENT Calendar Components - - This section defines the property set restrictions for the method - types that are applicable to the "VEVENT" calendar component. Each - method is defined using a table that clarifies the property - constraints that define the particular method. - - - - - - - - - - - - - - -Silverberg, et. al. Standards Track [Page 14] - -RFC 2446 iTIP November 1998 - - - The following summarizes the methods that are defined for the - "VEVENT" calendar component. - - +================+==================================================+ - | Method | Description | - |================+==================================================| - | PUBLISH | Post notification of an event. Used primarily as | - | | a method of advertising the existence of an | - | | event. | - | | | - | REQUEST | Make a request for an event. This is an explicit | - | | invitation to one or more "Attendees". Event | - | | Requests are also used to update or change an | - | | existing event. Clients that cannot handle | - | | REQUEST may degrade the event to view it as an | - | | PUBLISH. | - | | | - | REPLY | Reply to an event request. Clients may set their | - | | status ("partstat") to ACCEPTED, DECLINED, | - | | TENTATIVE, or DELEGATED. | - | | | - | ADD | Add one or more instances to an existing event. | - | | | - | CANCEL | Cancel one or more instances of an existing | - | | event. | - | | | - | REFRESH | A request is sent to an "Organizer" by an | - | | "Attendee" asking for the latest version of an | - | | event to be resent to the requester. | - | | | - | COUNTER | Counter a REQUEST with an alternative proposal, | - | | Sent by an "Attendee" to the "Organizer". | - | | | - | DECLINECOUNTER | Decline a counter proposal. Sent to an | - | | "Attendee" by the "Organizer". | - +================+==================================================+ - -3.2.1 PUBLISH - - The "PUBLISH" method in a "VEVENT" calendar component is an - unsolicited posting of an iCalendar object. Any CU may add published - components to their calendar. The "Organizer" MUST be present in a - published iCalendar component. "Attendees" MUST NOT be present. Its - expected usage is for encapsulating an arbitrary event as an - iCalendar object. The "Organizer" may subsequently update (with - another "PUBLISH" method), add instances to (with an "ADD" method), - or cancel (with a "CANCEL" method) a previously published "VEVENT" - calendar component. - - - -Silverberg, et. al. Standards Track [Page 15] - -RFC 2446 iTIP November 1998 - - - This method type is an iCalendar object that conforms to the - following property constraints: - -Component/Property Presence -------------------- ---------------------------------------------- -METHOD 1 MUST equal "PUBLISH" -VEVENT 1+ - DTSTAMP 1 - DTSTART 1 - ORGANIZER 1 - SUMMARY 1 Can be null. - UID 1 - RECURRENCE-ID 0 or 1 only if referring to an instance of a - recurring calendar component. Otherwise - it MUST NOT be present. - SEQUENCE 0 or 1 MUST be present if value is greater than - 0, MAY be present if 0 - ATTACH 0+ - CATEGORIES 0 or 1 This property may contain a list of - values - CLASS 0 or 1 - COMMENT 0 or 1 - CONTACT 0+ - CREATED 0 or 1 - DESCRIPTION 0 or 1 Can be null - DTEND 0 or 1 if present DURATION MUST NOT be present - DURATION 0 or 1 if present DTEND MUST NOT be present - EXDATE 0+ - EXRULE 0+ - GEO 0 or 1 - LAST-MODIFIED 0 or 1 - LOCATION 0 or 1 - PRIORITY 0 or 1 - RDATE 0+ - RELATED-TO 0+ - RESOURCES 0 or 1 This property MAY contain a list of values - RRULE 0+ - STATUS 0 or 1 MAY be one of TENTATIVE/CONFIRMED/CANCELLED - TRANSP 0 or 1 - URL 0 or 1 - X-PROPERTY 0+ - - ATTENDEE 0 - REQUEST-STATUS 0 - -VALARM 0+ -VFREEBUSY 0 -VJOURNAL 0 - - - -Silverberg, et. al. Standards Track [Page 16] - -RFC 2446 iTIP November 1998 - - -VTODO 0 -VTIMEZONE 0+ MUST be present if any date/time refers to - a timezone -X-COMPONENT 0+ - -3.2.2 REQUEST - - The "REQUEST" method in a "VEVENT" component provides the following - scheduling functions: - - . Invite "Attendees" to an event; - . Reschedule an existing event; - . Response to a REFRESH request; - . Update the details of an existing event, without rescheduling it; - . Update the status of "Attendees" of an existing event, without - rescheduling it; - . Reconfirm an existing event, without rescheduling it; - . Forward a "VEVENT" to another uninvited CU. - . For an existing "VEVENT" calendar component, delegate the role of - "Attendee" to another CU; - . For an existing "VEVENT" calendar component, changing the role of - "Organizer" to another CU. - - The "Organizer" originates the "REQUEST". The recipients of the - "REQUEST" method are the CUs invited to the event, the "Attendees". - "Attendees" use the "REPLY" method to convey attendance status to the - "Organizer". - - The "UID" and "SEQUENCE" properties are used to distinguish the - various uses of the "REQUEST" method. If the "UID" property value in - the "REQUEST" is not found on the recipient's calendar, then the - "REQUEST" is for a new "VEVENT" calendar component. If the "UID" - property value is found on the recipient's calendar, then the - "REQUEST" is for a rescheduling, an update, or a reconfirm of the - "VEVENT" calendar component. - - For the "REQUEST" method, multiple "VEVENT" components in a single - iCalendar object are only permitted when for components with the same - "UID" property. That is, a series of recurring events may have - instance-specific information. In this case, multiple "VEVENT" - components are needed to express the entire series. - - - - - - - - - - -Silverberg, et. al. Standards Track [Page 17] - -RFC 2446 iTIP November 1998 - - - This method type is an iCalendar object that conforms to the - following property constraints: - -Component/Property Presence ------------------------------------------------------------------ -METHOD 1 MUST be "REQUEST" -VEVENT 1+ All components MUST have the same UID - ATTENDEE 1+ - DTSTAMP 1 - DTSTART 1 - ORGANIZER 1 - SEQUENCE 0 or 1 MUST be present if value is greater than 0, - MAY be present if 0 - SUMMARY 1 Can be null - UID 1 - - ATTACH 0+ - CATEGORIES 0 or 1 This property may contain a list of values - CLASS 0 or 1 - COMMENT 0 or 1 - CONTACT 0+ - CREATED 0 or 1 - DESCRIPTION 0 or 1 Can be null - DTEND 0 or 1 if present DURATION MUST NOT be present - DURATION 0 or 1 if present DTEND MUST NOT be present - EXDATE 0+ - EXRULE 0+ - GEO 0 or 1 - LAST-MODIFIED 0 or 1 - LOCATION 0 or 1 - PRIORITY 0 or 1 - RDATE 0+ - RECURRENCE-ID 0 or 1 only if referring to an instance of a - recurring calendar component. Otherwise it - MUST NOT be present. - RELATED-TO 0+ - REQUEST-STATUS 0+ - RESOURCES 0 or 1 This property MAY contain a list of values - RRULE 0+ - STATUS 0 or 1 MAY be one of TENTATIVE/CONFIRMED - TRANSP 0 or 1 - URL 0 or 1 - X-PROPERTY 0+ - -VALARM 0+ -VTIMEZONE 0+ MUST be present if any date/time refers to - a timezone -X-COMPONENT 0+ - - - -Silverberg, et. al. Standards Track [Page 18] - -RFC 2446 iTIP November 1998 - - -VFREEBUSY 0 -VJOURNAL 0 -VTODO 0 - -3.2.2.1 Rescheduling an Event - - The "REQUEST" method may be used to reschedule an event. A - rescheduled event involves a change to the existing event in terms of - its time or recurrence intervals and possibly the location or - description. If the recipient CUA of a "REQUEST" method finds that - the "UID" property value already exists on the calendar, but that the - "SEQUENCE" (or "DTSTAMP") property value in the "REQUEST" method is - greater than the value for the existing event, then the "REQUEST" - method describes a rescheduling of the event. - -3.2.2.2 Updating or Reconfirmation of an Event - - The "REQUEST" method may be used to update or reconfirm an event. An - update to an existing event does not involve changes to the time or - recurrence intervals, and might not involve a change to the location - or description for the event. If the recipient CUA of a "REQUEST" - method finds that the "UID" property value already exists on the - calendar and that the "SEQUENCE" property value in the "REQUEST" is - the same as the value for the existing event, then the "REQUEST" - method describes an update of the event details, but no rescheduling - of the event. - - The update "REQUEST" method is the appropriate response to a - "REFRESH" method sent from an "Attendee" to the "Organizer" of an - event. - - The "Organizer" of an event may also send unsolicited "REQUEST" - methods. The unsolicited "REQUEST" methods may be used to update the - details of the event without rescheduling it, to update the - "partstat" parameter of "Attendees", or to reconfirm the event. - -3.2.2.3 Delegating an Event to another CU - - Some calendar and scheduling systems allow "Attendees" to delegate - their presence at an event to another calendar user. ITIP supports - this concept using the following workflow. Any "Attendee" may - delegate their right to participate in a calendar VEVENT to another - CU. The implication is that the delegate participates in lieu of the - original "Attendee"; NOT in addition to the "Attendee". The delegator - MUST notify the "Organizer" of this action using the steps outlined - below. Implementations may support or restrict delegation as they - see fit. For instance, some implementations may restrict a delegate - from delegating a "REQUEST" to another CU. - - - -Silverberg, et. al. Standards Track [Page 19] - -RFC 2446 iTIP November 1998 - - - The "Delegator" of an event forwards the existing "REQUEST" to the - "Delegate". The "REQUEST" method MUST include an "ATTENDEE" property - with the calendar address of the "Delegate". The "Delegator" MUST - also send a "REPLY" method to the "Organizer" with the "Delegator's" - "ATTENDEE" property "partstat" parameter value set to "delegated". In - addition, the "delegated-to" parameter MUST be included with the - calendar address of the "Delegate". - - In response to the request, the "Delegate" MUST send a "REPLY" method - to the "Organizer" and optionally, to the "Delegator". The "REPLY" - method " SHOULD include the "ATTENDEE" property with the "delegated- - from" parameter value of the "Delegator's" calendar address. - - The "Delegator" may continue to receive updates to the event even - though they will not be attending. This is accomplished by the - "Delegator" setting their "role" attribute to " NON-PARTICIPANT" in - the "REPLY" to the "Organizer" - -3.2.2.4 Changing the Organizer - - The situation may arise where the "Organizer" of a VEVENT is no - longer able to perform the "Organizer" role and abdicates without - passing on the "Organizer" role to someone else. When this occurs the - "Attendees" of the VEVENT may use out-of-band mechanisms to - communicate the situation and agree upon a new "Organizer". The new - "Organizer" should then send out a new "REQUEST" with a modified - version of the VEVENT in which the "SEQUENCE" number has been - incremented and value of the "ORGANIZER" property has been changed to - the calendar address of the new "Organizer". - -3.2.2.5 Sending on Behalf of the Organizer - - There are a number of scenarios that support the need for a calendar - user to act on behalf of the "Organizer" without explicit role - changing. This might be the case if the CU designated as "Organizer" - was sick or unable to perform duties associated with that function. - In these cases iTIP supports the notion of one CU acting on behalf of - another. Using the "sent-by" parameter, a calendar user could send an - updated "VEVENT" REQUEST. In the case where one CU sends on behalf of - another CU, the "Attendee" responses are still directed back towards - the CU designated as "Organizer". - -3.2.2.6 Forwarding to An Uninvited CU - - An "Attendee" invited to an event may invite another uninvited CU to - the event. The invited "Attendee" accomplishes this by forwarding the - original "REQUEST" method to the uninvited CU. The "Organizer" - decides whether or not the uninvited CU is added to the attendee - - - -Silverberg, et. al. Standards Track [Page 20] - -RFC 2446 iTIP November 1998 - - - list. If the "Organizer" decides not to add the uninvited CU no - further action is required, however the "Organizer" MAY send the - uninvited CU a "CANCEL" message. If the "Organizer" decides to add - an uninvited CU, a new "ATTENDEE" property is added for the uninvited - CU with its property parameters set as the "Organizer" deems - appropriate. When forwarding a "REQUEST" to another CU, the - forwarding "Attendee" MUST NOT make changes to the VEVENT property - set. - -3.2.2.7 Updating Attendee Status - - The "Organizer" of an event may also request updated status from one - or more "Attendees. The "Organizer" sends a "REQUEST" method to the - "Attendee" and sets the "ATTENDEE;RSVP=TRUE" property parameter. The - "SEQUENCE" property for the event is not changed from its previous - value. A recipient will determine that the only change in the - "REQUEST" is that their "RSVP" property parameter indicates a request - for updated status. The recipient SHOULD respond with a "REPLY" - method indicating their current status with respect to the "REQUEST". - -3.2.3 REPLY - - The "REPLY" method in a "VEVENT" calendar component is used to - respond (e.g., accept or decline) to a "REQUEST" or to reply to a - delegation "REQUEST". When used to provide a delegation response, the - "Delegator" SHOULD include the calendar address of the "Delegate" on - the "delegated-to" property parameter of the "Delegator's" "ATTENDEE" - property. The "Delegate" SHOULD include the calendar address of the - "Delegator" on the "delegated-from" property parameter of the - "Delegate's" "ATTENDEE" property. - - The "REPLY" method may also be used to respond to an unsuccessful - "REQUEST" method. Depending on the value of the "REQUEST-STATUS" - property no scheduling action may have been performed. - - The "Organizer" of an event may receive the "REPLY" method from a CU - not in the original "REQUEST". For example, a "REPLY" may be received - from a "Delegate" to an event. In addition, the "REPLY" method may be - received from an unknown CU (a "Party Crasher"). This uninvited - "Attendee" may be accepted, or the "Organizer" may cancel the event - for the uninvited "Attendee" by sending a "CANCEL" method to the - uninvited "Attendee". - - An "Attendee" can include a message to the "Organizer" using the - "COMMENT" property. For example, if the user indicates tentative - acceptance and wants to let the "Organizer" know why, the reason can - be expressed in the "COMMENT" property value. - - - - -Silverberg, et. al. Standards Track [Page 21] - -RFC 2446 iTIP November 1998 - - - The "Organizer" may also receive a "REPLY" from one CU on behalf of - another. Like the scenario enumerated above for the "Organizer", - "Attendees" may have another CU respond on their behalf. This is done - using the "sent-by" parameter. - - The optional properties listed in the table below (those listed as - "0+" or "0 or 1") MUST NOT be changed from those of the original - request. If property changes are desired the COUNTER message must be - used. - - This method type is an iCalendar object that conforms to the - following property constraints: - -Component/Property Presence -------------------- ---------------------------------------------- -METHOD 1 MUST be "REPLY" -VEVENT 1+ All components MUST have the same UID - ATTENDEE 1 MUST be the address of the Attendee - replying. - DTSTAMP 1 - ORGANIZER 1 - RECURRENCE-ID 0 or 1 only if referring to an instance of a - recurring calendar component. Otherwise - it must NOT be present. - UID 1 MUST be the UID of the original REQUEST - - SEQUENCE 0 or 1 MUST if non-zero, MUST be the sequence - number of the original REQUEST. MAY be - present if 0. - - ATTACH 0+ - CATEGORIES 0 or 1 This property may contain a list of values - CLASS 0 or 1 - COMMENT 0 or 1 - CONTACT 0+ - CREATED 0 or 1 - DESCRIPTION 0 or 1 - DTEND 0 or 1 if present DURATION MUST NOT be present - DTSTART 0 or 1 - DURATION 0 or 1 if present DTEND MUST NOT be present - EXDATE 0+ - EXRULE 0+ - GEO 0 or 1 - LAST-MODIFIED 0 or 1 - LOCATION 0 or 1 - PRIORITY 0 or 1 - RDATE 0+ - RELATED-TO 0+ - - - -Silverberg, et. al. Standards Track [Page 22] - -RFC 2446 iTIP November 1998 - - - RESOURCES 0 or 1 This property MAY contain a list of values - REQUEST-STATUS 0+ - RRULE 0+ - STATUS 0 or 1 - SUMMARY 0 or 1 - TRANSP 0 or 1 - URL 0 or 1 - X-PROPERTY 0+ - -VTIMEZONE 0 or 1 MUST be present if any date/time refers - to a timezone -X-COMPONENT 0+ - -VALARM 0 -VFREEBUSY 0 -VJOURNAL 0 -VTODO 0 - -3.2.4 ADD - - The "ADD" method in a "VEVENT" calendar component is used to add one - or more instances to an existing "VEVENT". Unlike the "REQUEST" - method, when using issuing an "ADD" method, the "Organizer" does not - send the full "VEVENT" description; only the new instance(s). The - "ADD" method is especially useful if there are instance-specific - properties to be preserved in a recurring "VEVENT". For instance, an - "Organizer" may have originally scheduled a weekly Thursday meeting. - At some point, several instances changed. Location or start time may - have changed, or some instances may have unique "DESCRIPTION" - properties. The "ADD" method allows the "Organizer" to add new - instances to an existing event using a single ITIP message without - redefining the entire recurring pattern. - - The "UID" must be that of the existing event. If the "UID" property - value in the "ADD" is not found on the recipient's calendar, then the - recipient SHOULD send a "REFRESH" to the "Organizer" in order to be - updated with the latest version of the "VEVENT". If an "Attendee" - implementation does not support the "ADD" method it should respond - with a "REQUEST-STATUS" value of 3.14 and ask for a "REFRESH". - - This method type is an iCalendar object that conforms to the - following property constraints: - - - - - - - - - -Silverberg, et. al. Standards Track [Page 23] - -RFC 2446 iTIP November 1998 - - -Component/Property Presence -------------------- ---------------------------------------------- -METHOD 1 MUST be "ADD" -VEVENT 1 - DTSTAMP 1 - DTSTART 1 - ORGANIZER 1 - SEQUENCE 1 MUST be greater than 0 - SUMMARY 1 Can be null - UID 1 MUST match that of the original event - - ATTACH 0+ - ATTENDEE 0+ - CATEGORIES 0 or 1 This property MAY contain a list of values - CLASS 0 or 1 - COMMENT 0 or 1 - CONTACT 0+ - CREATED 0 or 1 - DESCRIPTION 0 or 1 Can be null - DTEND 0 or 1 if present DURATION MUST NOT be present - DURATION 0 or 1 if present DTEND MUST NOT be present - EXDATE 0+ - EXRULE 0+ - GEO 0 or 1 - LAST-MODIFIED 0 or 1 - LOCATION 0 or 1 - PRIORITY 0 or 1 - RDATE 0+ - RELATED-TO 0+ - RESOURCES 0 or 1 This property MAY contain a list of values - RRULE 0+ - STATUS 0 or 1 MAY be one of TENTATIVE/CONFIRMED - TRANSP 0 or 1 - URL 0 or 1 - X-PROPERTY 0+ - - RECURRENCE-ID 0 - REQUEST-STATUS 0 - -VALARM 0+ -VTIMEZONE 0+ MUST be present if any date/time refers to - a timezone -X-COMPONENT 0+ - -VFREEBUSY 0 -VTODO 0 -VJOURNAL 0 - - - - -Silverberg, et. al. Standards Track [Page 24] - -RFC 2446 iTIP November 1998 - - -3.2.5 CANCEL - - The "CANCEL" method in a "VEVENT" calendar component is used to send - a cancellation notice of an existing event request to the - "Attendees". The message is sent by the "Organizer" of the event. For - a recurring event, either the whole event or instances of an event - may be cancelled. To cancel the complete range of recurring event, - the "UID" property value for the event MUST be specified and a - "RECURRENCE-ID" MUST NOT be specified in the "CANCEL" method. In - order to cancel an individual instance of the event, the - "RECURRENCE-ID" property value for the event MUST be specified in the - "CANCEL" method. - - There are two options for canceling a sequence of instances of a - recurring "VEVENT" calendar component: - - (a) the "RECURRENCE-ID" property for an instance in the sequence MUST - be specified with the "RANGE" property parameter value of - THISANDPRIOR (or THISANDFUTURE) to indicate cancellation of the - specified "VEVENT" calendar component and all instances before - (or after); or - - (b) individual recurrence instances may be cancelled by specifying - multiple "RECURRENCE-ID" properties corresponding to the - instances to be cancelled. - - When a "VEVENT" is cancelled, the "SEQUENCE" property value MUST be - incremented. - - This method type is an iCalendar object that conforms to the - following property constraints: - -Component/Property Presence -------------------- ---------------------------------------------- -METHOD 1 MUST be "CANCEL" - -VEVENT 1+ All must have the same UID - ATTENDEE 0+ MUST include all "Attendees" being removed - the event. MUST include all "Attendees" if - the entire event is cancelled. - DTSTAMP 1 - ORGANIZER 1 - SEQUENCE 1 - UID 1 MUST be the UID of the original REQUEST - - COMMENT 0 or 1 - ATTACH 0+ - CATEGORIES 0 or 1 This property may contain a list of values - - - -Silverberg, et. al. Standards Track [Page 25] - -RFC 2446 iTIP November 1998 - - - CLASS 0 or 1 - CONTACT 0+ - CREATED 0 or 1 - DESCRIPTION 0 or 1 - DTEND 0 or 1 if present DURATION MUST NOT be present - DTSTART 0 or 1 - DURATION 0 or 1 if present DTEND MUST NOT be present - EXDATE 0+ - EXRULE 0+ - GEO 0 or 1 - LAST-MODIFIED 0 or 1 - LOCATION 0 or 1 - PRIORITY 0 or 1 - RDATE 0+ - RECURRENCE-ID 0 or 1 MUST be present if referring to one or - more or more recurring instances. - Otherwise it MUST NOT be present - RELATED-TO 0+ - RESOURCES 0 or 1 - RRULE 0+ - STATUS 0 or 1 MUST be set to CANCELLED. If uninviting - specific "Attendees" then MUST NOT be - included. - SUMMARY 0 or 1 - TRANSP 0 or 1 - URL 0 or 1 - X-PROPERTY 0+ - REQUEST-STATUS 0 - -VTIMEZONE 0+ MUST be present if any date/time refers to - a timezone -X-COMPONENT 0+ - -VTODO 0 -VJOURNAL 0 -VFREEBUSY 0 -VALARM 0 - -3.2.6 REFRESH - - The "REFRESH" method in a "VEVENT" calendar component is used by - "Attendees" of an existing event to request an updated description - from the event "Organizer". The "REFRESH" method must specify the - "UID" property of the event to update. A recurrence instance of an - event may be requested by specifying the "RECURRENCE-ID" property - corresponding to the associated event. The "Organizer" responds with - the latest description and version of the event. - - - - -Silverberg, et. al. Standards Track [Page 26] - -RFC 2446 iTIP November 1998 - - - This method type is an iCalendar object that conforms to the - following property constraints: - -Component/Property Presence -------------------- ---------------------------------------------- -METHOD 1 MUST be "REFRESH" - -VEVENT 1 - ATTENDEE 1 MUST be the address of requestor - DTSTAMP 1 - ORGANIZER 1 - UID 1 MUST be the UID associated with original - REQUEST - COMMENT 0 or 1 - RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a - recurring calendar component. Otherwise - it must NOT be present. - X-PROPERTY 0+ - - ATTACH 0 - CATEGORIES 0 - CLASS 0 - CONTACT 0 - CREATED 0 - DESCRIPTION 0 - DTEND 0 - DTSTART 0 - DURATION 0 - EXDATE 0 - EXRULE 0 - GEO 0 - LAST-MODIFIED 0 - LOCATION 0 - PRIORITY 0 - RDATE 0 - RELATED-TO 0 - REQUEST-STATUS 0 - RESOURCES 0 - RRULE 0 - SEQUENCE 0 - STATUS 0 - SUMMARY 0 - TRANSP 0 - URL 0 - -X-COMPONENT 0+ - -VTODO 0 - - - -Silverberg, et. al. Standards Track [Page 27] - -RFC 2446 iTIP November 1998 - - -VJOURNAL 0 -VFREEBUSY 0 -VTIMEZONE 0 -VALARM 0 - -3.2.7 COUNTER - - The "COUNTER" method for a "VEVENT" calendar component is used by an - "Attendee" of an existing event to submit to the "Organizer" a - counter proposal to the event description. The "Attendee" sends this - message to the "Organizer" of the event. - - The counter proposal is an iCalendar object consisting of a VEVENT - calendar component describing the complete description of the - alternate event. - - The "Organizer" rejects the counter proposal by sending the - "Attendee" a VEVENT "DECLINECOUNTER" method. The "Organizer" accepts - the counter proposal by rescheduling the event as described in - section 3.2.2.1 Rescheduling an Event. - - This method type is an iCalendar object that conforms to the - following property constraints: - -Component/Property Presence -------------------- ---------------------------------------------- -METHOD 1 MUST be "COUNTER" - -VEVENT 1 - DTSTAMP 1 - DTSTART 1 - ORGANIZER 1 MUST be the "Organizer" of the original - event - SEQUENCE 1 MUST be present if value is greater than 0, - MAY be present if 0 - SUMMARY 1 Can be null - UID 1 MUST be the UID associated with the REQUEST - being countered - - ATTACH 0+ - ATTENDEE 0+ Can also be used to propose other - "Attendees" - CATEGORIES 0 or 1 This property may contain a list of values - CLASS 0 or 1 - COMMENT 0 or 1 - CONTACT 0+ - CREATED 0 or 1 - DESCRIPTION 0 or 1 - - - -Silverberg, et. al. Standards Track [Page 28] - -RFC 2446 iTIP November 1998 - - - DTEND 0 or 1 if present DURATION MUST NOT be present - DURATION 0 or 1 if present DTEND MUST NOT be present - EXDATE 0+ - EXRULE 0+ - GEO 0 or 1 - LAST-MODIFIED 0 or 1 - LOCATION 0 or 1 - PRIORITY 0 or 1 - RDATE 0+ - RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a - recurring calendar component. Otherwise it - MUST NOT be present. - RELATED-TO 0+ - REQUEST-STATUS 0+ - RESOURCES 0 or 1 This property may contain a list of values - RRULE 0+ - STATUS 0 or 1 Value must be one of CONFIRMED/TENATIVE/ - CANCELLED - TRANSP 0 or 1 - URL 0 or 1 - X-PROPERTY 0+ - -VALARM 0+ -VTIMEZONE 0+ MUST be present if any date/time refers to - a timezone -X-COMPONENT 0+ - -VTODO 0 -VJOURNAL 0 -VFREEBUSY 0 - -3.2.8 DECLINECOUNTER - - The "DECLINECOUNTER" method in a "VEVENT" calendar component is used - by the "Organizer" of an event to reject a counter proposal submitted - by an "Attendee". The "Organizer" must send the "DECLINECOUNTER" - message to the "Attendee" that sent the "COUNTER" method to the - "Organizer". - - This method type is an iCalendar object that conforms to the - following property constraints: - - - - - - - - - - -Silverberg, et. al. Standards Track [Page 29] - -RFC 2446 iTIP November 1998 - - -Component/Property Presence -------------------- ---------------------------------------------- -METHOD 1 MUST be "DECLINECOUNTER" - -VEVENT 1 - DTSTAMP 1 - ORGANIZER 1 - UID 1 MUST, same UID specified in original - REQUEST and subsequent COUNTER - COMMENT 0 or 1 - RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a - recurring calendar component. Otherwise it - MUST NOT be present. - REQUEST-STATUS 0+ - SEQUENCE 0 OR 1 MUST be present if value is greater than 0, - MAY be present if 0 - X-PROPERTY 0+ - ATTACH 0 - ATTENDEE 0 - CATEGORIES 0 - CLASS 0 - CONTACT 0 - CREATED 0 - DESCRIPTION 0 - DTEND 0 - DTSTART 0 - DURATION 0 - EXDATE 0 - EXRULE 0 - GEO 0 - LAST-MODIFIED 0 - LOCATION 0 - PRIORITY 0 - RDATE 0 - RELATED-TO 0 - RESOURCES 0 - RRULE 0 - STATUS 0 - SUMMARY 0 - TRANSP 0 - URL 0 - -X-COMPONENT 0+ -VTODO 0 -VJOURNAL 0 -VFREEBUSY 0 -VTIMEZONE 0 -VALARM 0 - - - -Silverberg, et. al. Standards Track [Page 30] - -RFC 2446 iTIP November 1998 - - -3.3 Methods For VFREEBUSY Components - - This section defines the property set for the methods that are - applicable to the "VFREEBUSY" calendar component. Each of the methods - is defined using a restriction table. - - This document only addresses the transfer of busy time information. - Applications desiring free time information MUST infer this from - available busy time information. - - The busy time information within the iCalendar object MAY be grouped - into more than one "VFREEBUSY" calendar component. This capability - allows busy time periods to be grouped according to some common - periodicity, such as a calendar week, month, or year. In this case, - each "VFREEBUSY" calendar component MUST include the "ATTENDEE", - "DTSTART" and "DTEND" properties in order to specify the source of - the busy time information and the date and time interval over which - the busy time information covers. - - The "FREEBUSY" property value MAY include a list of values, separated - by the COMMA character ([US-ASCII] decimal 44). Alternately, multiple - busy time periods MAY be specified with multiple instances of the - "FREEBUSY" property. Both forms MUST be supported by implementations - conforming to this document. Duplicate busy time periods SHOULD NOT - be specified in an iCalendar object. However, two different busy time - periods MAY overlap. - - "FREEBUSY" properties should be sorted such that their values are in - ascending order, based on the start time, and then the end time, with - the earliest periods first. For example, today's busy time - information should appear after yesterday's busy time information. - And the busy time for this half-hour should appear after the busy - time for earlier today. - - Since events may span a day boundary, free busy time period may also - span a day boundary. Individual "A" requests busy time from - individuals "B", "C" and "D". Individual "B" and "C" replies with - busy time data to individual "A". Individual "D" does not support - busy time requests and does not reply with any data. If the transport - binding supports exception messages, then individual "D" returns an - "unsupported capability" message to individual "A4.34.3". - - The following summarizes the methods that are defined for the - "VFREEBUSY" calendar component. - - - - - - - -Silverberg, et. al. Standards Track [Page 31] - -RFC 2446 iTIP November 1998 - - - |================|==================================================| - | Method | Description | - |================|==================================================| - | PUBLISH | Publish unsolicited busy time data. | - | REQUEST | Request busy time data. | - | REPLY | Reply to a busy time request. | - |================|==================================================| - -3.3.1 PUBLISH - - The "PUBLISH" method in a "VFREEBUSY" calendar component is used to - publish busy time data. The method may be sent from one CU to any - other. The purpose of the method is to provide a message for sending - unsolicited busy time data. That is, the busy time data is not being - sent as a "REPLY" to the receipt of a "REQUEST" method. - - The "ATTENDEE" property must be specified in the busy time - information. The value is the CU address of the originator of the - busy time information. - - This method type is an iCalendar object that conforms to the - following property constraints: - -Component/Property Presence -------------------- ---------------------------------------------- -METHOD 1 MUST be "PUBLISH" - -VFREEBUSY 1+ - DTSTAMP 1 - DTSTART 1 DateTime values must be in UTC - DTEND 1 DateTime values must be in UTC - FREEBUSY 1+ MUST be BUSYTIME. Multiple instances are - allowed. Multiple instances must be sorted - in ascending order - ORGANIZER 1 MUST contain the address of originator of - busy time data. - - COMMENT 0 or 1 - CONTACT 0+ - X-PROPERTY 0+ - URL 0 or 1 Specifies busy time URL - - ATTENDEE 0 - DURATION 0 - REQUEST-STATUS 0 - UID 0 - -X-COMPONENT 0+ - - - -Silverberg, et. al. Standards Track [Page 32] - -RFC 2446 iTIP November 1998 - - -VEVENT 0 -VTODO 0 -VJOURNAL 0 -VTIMEZONE 0 -VALARM 0 - -3.3.2 REQUEST - - The "REQUEST" method in a "VFREEBUSY" calendar component is used to - ask a "Calendar User" for their busy time information. The request - may be for a busy time information bounded by a specific date and - time interval. - - This message only permits requests for busy time information. The - message is sent from a "Calendar User" requesting the busy time - information to one or more intended recipients. - - If the originator of the "REQUEST" method is not authorized to make a - busy time request on the recipient's calendar system, then an - exception message SHOULD be returned in a "REPLY" method, but no busy - time data need be returned. - - This method type is an iCalendar object that conforms to the - following property constraints: - -Component/Property Presence -------------------- ---------------------------------------------- -METHOD 1 MUST be "REQUEST" - -VFREEBUSY 1 - ATTENDEE 1+ contain the address of the calendar store - DTEND 1 DateTime values must be in UTC - DTSTAMP 1 - DTSTART 1 DateTime values must be in UTC - ORGANIZER 1 MUST be the request originator's address - UID 1 - COMMENT 0 or 1 - CONTACT 0+ - X-PROPERTY 0+ - - FREEBUSY 0 - DURATION 0 - REQUEST-STATUS 0 - URL 0 - -X-COMPONENT 0+ -VALARM 0 -VEVENT 0 - - - -Silverberg, et. al. Standards Track [Page 33] - -RFC 2446 iTIP November 1998 - - -VTODO 0 -VJOURNAL 0 -VTIMEZONE 0 - -3.3.3 REPLY - - The "REPLY" method in a "VFREEBUSY" calendar component is used to - respond to a busy time request. The method is sent by the recipient - of a busy time request to the originator of the request. - - The "REPLY" method may also be used to respond to an unsuccessful - "REQUEST" method. Depending on the "REQUEST-STATUS" value, no busy - time information may be returned. - - This method type is an iCalendar object that conforms to the - following property constraints: - -Component/Property Presence -------------------- ---------------------------------------------- -METHOD 1 MUST be "REPLY" - -VFREEBUSY 1 - ATTENDEE 1 (address of recipient replying) - DTSTAMP 1 - DTEND 1 DateTime values must be in UTC - DTSTART 1 DateTime values must be in UTC - FREEBUSY 1+ (values MUST all be of the same data - type. Multiple instances are allowed. - Multiple instances MUST be sorted in - ascending order. Values MAY NOT overlap) - ORGANIZER 1 MUST be the request originator's address - UID 1 - - COMMENT 0 or 1 - CONTACT 0+ - REQUEST-STATUS 0+ - URL 0 or 1 (specifies busy time URL) - X-PROPERTY 0+ - DURATION 0 - SEQUENCE 0 - -X-COMPONENT 0+ -VALARM 0 -VEVENT 0 -VTODO 0 -VJOURNAL 0 -VTIMEZONE 0 - - - - -Silverberg, et. al. Standards Track [Page 34] - -RFC 2446 iTIP November 1998 - - -3.4 Methods For VTODO Components - - This section defines the property set for the methods that are - applicable to the "VTODO" calendar component. Each of the methods is - defined using a restriction table that specifies the property - constraints that define the particular method. - - The following summarizes the methods that are defined for the "VTODO" - calendar component. - - +================+==================================================+ - | Method | Description | - |================+==================================================| - | PUBLISH | Post notification of a VTODO. Used primarily as | - | | a method of advertising the existence of a VTODO.| - | | | - | REQUEST | Assign a VTODO. This is an explicit assignment to| - | | one or more Calendar Users. The REQUEST method | - | | is also used to update or change an existing | - | | VTODO. Clients that cannot handle REQUEST MAY | - | | degrade the method to treat it as a PUBLISH. | - | | | - | REPLY | Reply to a VTODO request. Attendees MAY set | - | | PARTSTAT to ACCEPTED, DECLINED, TENTATIVE, | - | | DELEGATED, PARTIAL, and COMPLETED. | - | | | - | ADD | Add one or more instances to an existing to-do. | - | | | - | CANCEL | Cancel one or more instances of an existing | - | | to-do. | - | | | - | REFRESH | A request sent to a VTODO Organizer asking for | - | | the latest version of a VTODO. | - | | | - | COUNTER | Counter a REQUEST with an alternative proposal. | - | | | - | DECLINECOUNTER | Decline a counter proposal by an Attendee. | - +================+==================================================+ - -3.4.1 PUBLISH - - The "PUBLISH" method in a "VTODO" calendar component has no - associated response. It is simply a posting of an iCalendar object - that maybe added to a calendar. It MUST have an "Organizer". It MUST - NOT have "Attendees". Its expected usage is for encapsulating an - arbitrary "VTODO" calendar component as an iCalendar object. The - "Organizer" MAY subsequently update (with another "PUBLISH" method), - add instances to (with an "ADD" method), or cancel (with a "CANCEL" - - - -Silverberg, et. al. Standards Track [Page 35] - -RFC 2446 iTIP November 1998 - - - method) a previously published "VTODO" calendar component. - - This method type is an iCalendar object that conforms to the - following property constraints: - -Component/Property Presence -------------------- ---------------------------------------------- -METHOD 1 MUST be "PUBLISH" -VTODO 1+ - DTSTAMP 1 - DTSTART 1 - ORGANIZER 1 - PRIORITY 1 - SEQUENCE 0 or 1 MUST be present if value is greater than - 0, MAY be present if 0 - SUMMARY 1 Can be null. - UID 1 - - ATTACH 0+ - CATEGORIES 0 or 1 This property may contain a list of values - CLASS 0 or 1 - COMMENT 0 or 1 - CONTACT 0+ - CREATED 0 or 1 - DESCRIPTION 0 or 1 Can be null - DUE 0 or 1 If present DURATION MUST NOT be present - DURATION 0 or 1 If present DUE MUST NOT be present - EXDATE 0+ - EXRULE 0+ - GEO 0 or 1 - LAST-MODIFIED 0 or 1 - LOCATION 0 or 1 - PERCENT-COMPLETE 0 or 1 - RDATE 0+ - RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a - recurring calendar component. Otherwise - it MUST NOT be present. - - RELATED-TO 0+ - RESOURCES 0 or 1 This property may contain a list of values - RRULE 0+ -STATUS 0 or 1 MAY be one of COMPLETED/NEEDS ACTION/IN- - PROCESS/CANCELLED - URL 0 or 1 - X-PROPERTY 0+ - - ATTENDEE 0 - REQUEST-STATUS 0 - - - -Silverberg, et. al. Standards Track [Page 36] - -RFC 2446 iTIP November 1998 - - -VTIMEZONE 0+ MUST be present if any date/time refers to - a timezone -VALARM 0+ -X-COMPONENT 0+ - -VFREEBUSY 0 -VEVENT 0 -VJOURNAL 0 - -3.4.2 REQUEST - - The "REQUEST" method in a "VTODO" calendar component provides the - following scheduling functions: - - . Assign a to-do to one or more "Calendar Users"; - . Reschedule an existing to-do; - . Update the details of an existing to-do, without rescheduling - it; - . Update the completion status of "Attendees" of an existing - to-do, without rescheduling it; - . Reconfirm an existing to-do, without rescheduling it; - . Delegate/reassign an existing to-do to another "Calendar User". - - The assigned "Calendar Users" are identified in the "VTODO" calendar - component by individual "ATTENDEE;ROLE=REQ-PARTICIPANT" property - value sequences. - - The originator of a "REQUEST" is the "Organizer" of the to-do. The - recipient of a "REQUEST" is the "Calendar User" assigned the to-do. - The "Attendee" uses the "REPLY" method to convey their acceptance and - completion status to the "Organizer" of the "REQUEST". - - The "UID", "SEQUENCE", and "DTSTAMP" properties are used to - distinguish the various uses of the "REQUEST" method. If the "UID" - property value in the "REQUEST" is not found on the recipient's - calendar, then the "REQUEST" is for a new to-do. If the "UID" - property value is found on the recipient's calendar, then the - "REQUEST" is a rescheduling, an update, or a reconfirm of the "VTODO" - calendar object. - - If the "Organizer" of the "REQUEST" method is not authorized to make - a to-do request on the "Attendee's" calendar system, then an - exception is returned in the "REQUEST-STATUS" property of a - subsequent "REPLY" method, but no scheduling action is performed. - - For the "REQUEST" method, multiple "VTODO" components in a single - iCalendar object are only permitted when for components with the same - "UID" property. That is, a series of recurring events may have - - - -Silverberg, et. al. Standards Track [Page 37] - -RFC 2446 iTIP November 1998 - - - instance-specific information. In this case, multiple "VTODO" - components are needed to express the entire series. - - This method type is an iCalendar object that conforms to the - following property constraints: - -Component/Property Presence -------------------- ---------------------------------------------- -METHOD 1 MUST be "REQUEST" -VTODO 1+ All components must have the same UID - ATTENDEE 1+ - DTSTAMP 1 - DTSTART 1 - ORGANIZER 1 - PRIORITY 1 - SEQUENCE 0 or 1 MUST be present if value is greater than - 0, MAY be present if 0 - SUMMARY 1 Can be null. - UID 1 - - ATTACH 0+ - CATEGORIES 0 or 1 This property may contain a list of - values - CLASS 0 or 1 - COMMENT 0 or 1 - CONTACT 0+ - CREATED 0 or 1 - DESCRIPTION 0 or 1 Can be null - DUE 0 or 1 If present DURATION MUST NOT be present - DURATION 0 or 1 If present DUE MUST NOT be present - EXDATE 0+ - EXRULE 0+ - GEO 0 or 1 - LAST-MODIFIED 0 or 1 - LOCATION 0 or 1 - PERCENT-COMPLETE 0 or 1 - RDATE 0+ - RECURRENCE-ID 0 or 1 present if referring to an instance of a - recurring calendar component. Otherwise - it MUST NOT be present. - RELATED-TO 0+ - RESOURCES 0 or 1 This property may contain a list of - values - RRULE 0+ - STATUS 0 or 1 MAY be one of COMPLETED/NEEDS ACTION/IN- - PROCESS - URL 0 or 1 - X-PROPERTY 0+ - - - -Silverberg, et. al. Standards Track [Page 38] - -RFC 2446 iTIP November 1998 - - - REQUEST-STATUS 0 - -VALARM 0+ - -VTIMEZONE 0+ MUST be present if any date/time refers - to a timezone -X-COMPONENT 0+ - -VEVENT 0 -VFREEBUSY 0 -VJOURNAL 0 - -3.4.2.1 REQUEST for Rescheduling a VTODO - - The "REQUEST" method may be used to reschedule a "VTODO" calendar - component. - - Rescheduling a "VTODO" calendar component involves a change to the - existing "VTODO" calendar component in terms of its start or due time - or recurrence intervals and possibly the description. If the - recipient CUA of a "REQUEST" method finds that the "UID" property - value already exists on the calendar, but that the "SEQUENCE" - property value in the "REQUEST" is greater than the value for the - existing VTODO, then the "REQUEST" method describes a rescheduling of - the "VTODO" calendar component. - -3.4.2.2 REQUEST for Update or Reconfirmation of a VTODO - - The "REQUEST" method may be used to update or reconfirm a "VTODO" - calendar component. Reconfirmation is merely an update of "Attendee" - completion status or overall "VTODO" calendar component status. - - An update to an existing "VTODO" calendar component does not involve - changes to the start or due time or recurrence intervals, nor - generally to the description for the "VTODO" calendar component. If - the recipient CUA of a "REQUEST" method finds that the "UID" property - value already exists on the calendar and that the "SEQUENCE" property - value in the "REQUEST" is the same as the value for the existing - event, then the "REQUEST" method describes an update of the "VTODO" - calendar component details, but not a rescheduling of the "VTODO" - calendar component. - - The update "REQUEST" is the appropriate response to a "REFRESH" - method sent from an "Attendee" to the "Organizer" of a "VTODO" - calendar component. - - Unsolicited "REQUEST" methods MAY be sent by the "Organizer" of a - "VTODO" calendar component. The unsolicited "REQUEST" methods are - - - -Silverberg, et. al. Standards Track [Page 39] - -RFC 2446 iTIP November 1998 - - - used to update the details of the "VTODO" (without rescheduling it or - updating the completion status of "Attendees") or the "VTODO" - calendar component itself (i.e., reconfirm the "VTODO"). - -3.4.2.3 REQUEST for Delegating a VTODO - - The "REQUEST" method is also used to delegate or reassign ownership - of a "VTODO" calendar component to another "Calendar User". For - example, it may be used to delegate an "Attendee's" role (i.e. - "chair", or "participant") for a "VTODO" calendar component. The - "REQUEST" method is sent by one of the "Attendees" of an existing - - "VTODO" calendar component to some other individual. An "Attendee" of - a "VTODO" calendar component MUST NOT delegate to the "Organizer" of - the event. - - For the purposes of this description, the "Attendee" delegating the - "VTODO" calendar component is referred to as the "Delegator". The - "Attendee" receiving the delegation request is referred to as the - "Delegate". - - The "Delegator" of a "VTODO" calendar component MUST forward the - existing "REQUEST" method for a "VTODO" calendar component to the - "Delegate". The "VTODO" calendar component description MUST include - the "Delegator's" up-to-date "VTODO" calendar component definition. - The "REQUEST" method MUST also include an "ATTENDEE" property with - the calendar address of the "Delegate". The "Delegator" MUST also - send a "REPLY" method back to the "Organizer" with the "Delegator's" - "Attendee" property "partstat" parameter value set to "DELEGATED". In - addition, the "delegated-to" parameter MUST be included with the - calendar address of the "Delegate". A response to the delegation - "REQUEST" is sent from the "Delegate" to the "Organizer" and - optionally, to the "Delegator". The "REPLY" method from the - "Delegate" SHOULD include the "ATTENDEE" property with their calendar - address and the "delegated-from" parameter with the value of the - "Delegator's" calendar address. - - The delegation "REQUEST" method MUST assign a value for the "RSVP" - property parameter associated with the "Delegator's" "Attendee" - property to that of the "Delegate's" "ATTENDEE" property. For example - if the "Delegator's" "ATTENDEE" property specifies "RSVP=TRUE", then - the "Delegate's" "ATTENDEE" property MUST specify "RSVP=TRUE". - -3.4.2.4 REQUEST Forwarded To An Uninvited Calendar User - - An "Attendee" assigned a "VTODO" calendar component may send the - "VTODO" calendar component to another new CU, not previously - associated with the "VTODO" calendar component. The current - - - -Silverberg, et. al. Standards Track [Page 40] - -RFC 2446 iTIP November 1998 - - - "Attendee" assigned the "VTODO" calendar component does this by - forwarding the original "REQUEST" method to the new CU. The new CU - can send a "REPLY" to the "Organizer" of the "VTODO" calendar - component. The reply contains an "ATTENDEE" property for the new CU. - - The "Organizer" ultimately decides whether or not the new CU becomes - part of the to-do and is not obligated to do anything with a "REPLY" - from a new (uninvited) CU. If the "Organizer" does not want the new - CU to be part of the to-do, the new "ATTENDEE" property is not added - to the "VTODO" calendar component. The "Organizer" MAY send the CU a - "CANCEL" message to indicate that they will not be added to the to- - do. If the "Organizer" decides to add the new CU, the new "ATTENDEE" - property is added to the "VTODO" calendar component. Furthermore, the - "Organizer" is free to change any "ATTENDEE" property parameter from - the values supplied by the new CU to something the "Organizer" - considers appropriate. - -3.4.2.5 REQUEST Updated Attendee Status - - An "Organizer" of a "VTODO" may request an updated status from one or - more "Attendees". The "Organizer" sends a "REQUEST" method to the - "Attendee" with the "ATTENDEE;RSVP=TRUE" property sequence. The - "SEQUENCE" property for the "VTODO" is not changed from its previous - value. A recipient determines that the only change in the "REQUEST" - is that their "RSVP" property parameter indicates a request for an - updated status. The recipient SHOULD respond with a "REPLY" method - indicating their current status with respect to the "REQUEST". - -3.4.3 REPLY - - The "REPLY" method in a "VTODO" calendar component is used to respond - (e.g., accept or decline) to a request or to reply to a delegation - request. It is also used by an "Attendee" to update their completion - status. When used to provide a delegation response, the "Delegator" - MUST include the calendar address of the "Delegate" in the - "delegated-to" parameter of the "Delegator's" "ATTENDEE" property. - The "Delegate" MUST include the calendar address of the "Delegator" - on the "delegated-from" parameter of the "Delegate's" "ATTENDEE" - property. - - The "REPLY" method MAY also be used to respond to an unsuccessful - "VTODO" calendar component "REQUEST" method. Depending on the - "REQUEST-STATUS" value, no scheduling action may have been performed. - - The "Organizer" of a "VTODO" calendar component MAY receive a "REPLY" - method from a "Calendar User" not in the original "REQUEST". For - example, a "REPLY" method MAY be received from a "Delegate" of a - "VTODO" calendar component. In addition, the "REPLY" method MAY be - - - -Silverberg, et. al. Standards Track [Page 41] - -RFC 2446 iTIP November 1998 - - - received from an unknown "Calendar User", having been forwarded the - "REQUEST" by an original "Attendee" of the "VTODO" calendar - component. This uninvited "Attendee" MAY be accepted, or the - "Organizer" MAY cancel the "VTODO" calendar component for the - uninvited "Attendee" by sending them a "CANCEL" method. - - This method type is an iCalendar object that conforms to the - following property constraints: - -Component/Property Presence -------------------- --------------------------------------------- -METHOD 1 MUST be "REPLY" -VTODO 1+ All component MUST have the same UID - ATTENDEE 1+ - DTSTAMP 1 - ORGANIZER 1 - REQUEST-STATUS 1+ - UID 1 MUST must be the address of the replying - attendee - - ATTACH 0+ - CATEGORIES 0 or 1 This property may contain a list of values - CLASS 0 or 1 - COMMENT 0 or 1 - CONTACT 0+ - CREATED 0 or 1 - DESCRIPTION 0 or 1 - DTSTART 0 or 1 - DUE 0 or 1 If present DURATION MUST NOT be present - DURATION 0 or 1 If present DUE MUST NOT be present - EXDATE 0+ - EXRULE 0+ - GEO 0 or 1 - LAST-MODIFIED 0 or 1 - LOCATION 0 or 1 - PERCENT-COMPLETE 0 or 1 - PRIORITY 0 or 1 - RDATE 0+ - RELATED-TO 0+ - RESOURCES 0 or 1 This property may contain a list of values - RRULE 0+ - RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a - Recurring calendar component. Otherwise it - MUST NOT be present - SEQUENCE 0 or 1 MUST be the sequence number of - the original REQUEST if greater than 0. - MAY be present if 0. - STATUS 0 or 1 - - - -Silverberg, et. al. Standards Track [Page 42] - -RFC 2446 iTIP November 1998 - - - SUMMARY 0 or 1 Can be null - URL 0 or 1 - X-PROPERTY 0+ - -VTIMEZONE 0 or 1 MUST be present if any date/time refers to - a timezone -X-COMPONENT 0+ - -VALARM 0 -VEVENT 0 -VFREEBUSY 0 - -3.4.4 ADD - - The "ADD" method in a "VTODO" calendar component is used to add one - or more instances to an existing to-do. - - If the "UID" property value in the "ADD" is not found on the - recipient's calendar, then the recipient SHOULD send a "REFRESH" to - the "Organizer" in order to be updated with the latest version of the - "VTODO". If an "Attendee" implementation does not support the "ADD" - method it should respond with a "REQUEST-STATUS" value of 5.3 and ask - for a "REFRESH". - - The "SEQUENCE" property value is incremented as the sequence of to- - dos has changed. - - This method type is an iCalendar object that conforms to the - following property constraints: - -Component/Property Presence -------------------- ---------------------------------------------- -METHOD 1 MUST be "ADD" -VTODO 1 - DTSTAMP 1 - ORGANIZER 1 - PRIORITY 1 - SEQUENCE 1 MUST be greater than 0 - SUMMARY 1 Can be null. - UID 1 MUST match that of the original to-do - - ATTACH 0+ - ATTENDEE 0+ - CATEGORIES 0 or 1 This property may contain a list of - values - CLASS 0 or 1 - COMMENT 0 or 1 - CONTACT 0+ - - - -Silverberg, et. al. Standards Track [Page 43] - -RFC 2446 iTIP November 1998 - - - CREATED 0 or 1 - DESCRIPTION 0 or 1 Can be null - DTSTART 0 or 1 - DUE 0 or 1 If present DURATION MUST NOT be present - DURATION 0 or 1 If present DUE MUST NOT be present - EXDATE 0+ - EXRULE 0+ - GEO 0 or 1 - LAST-MODIFIED 0 or 1 - LOCATION 0 or 1 - PERCENT-COMPLETE 0 or 1 - RDATE 0+ - RELATED-TO 0+ - RESOURCES 0 or 1 This property may contain a list of - values - RRULE 0+ - STATUS 0 or 1 MAY be one of COMPLETED/NEEDS ACTION/IN- - PROCESS - URL 0 or 1 - X-PROPERTY 0+ - - RECURRENCE-ID 0 - REQUEST-STATUS 0 - -VALARM 0+ -VTIMEZONE 0+ MUST be present if any date/time refers - to a timezone -X-COMPONENT 0+ - -VEVENT 0 -VJOURNAL 0 -VFREEBUSY 0 - -3.4.5 CANCEL - - The "CANCEL" method in a "VTODO" calendar component is used to send a - cancellation notice of an existing "VTODO" calendar request to the - "Attendees". The message is sent by the "Organizer" of a "VTODO" - calendar component to the "Attendees" of the "VTODO" calendar - component. For a recurring "VTODO" calendar component, either the - whole "VTODO" calendar component or instances of a "VTODO" calendar - component may be cancelled. To cancel the complete range of a - recurring "VTODO" calendar component, the "UID" property value for - the "VTODO" calendar component MUST be specified and a "RECURRENCE- - ID" MUST NOT be specified in the "CANCEL" method. In order to cancel - an individual instance of a recurring "VTODO" calendar component, the - "RECURRENCE-ID" property value for the "VTODO" calendar component - MUST be specified in the "CANCEL" method. - - - -Silverberg, et. al. Standards Track [Page 44] - -RFC 2446 iTIP November 1998 - - - There are two options for canceling a sequence of instances of a - recurring "VTODO" calendar component: - - (a) the "RECURRENCE-ID" property for an instance in the sequence MUST - be specified with the "RANGE" property parameter value of - THISANDPRIOR (or THISANDFUTURE) to indicate cancellation of the - specified "VTODO" calendar component and all instances before (or - after); or - - (b) individual recurrence instances may be cancelled by specifying - multiple "RECURRENCE-ID" properties corresponding to the - instances to be cancelled. - - When a "VTODO" is cancelled, the "SEQUENCE" property value MUST be - incremented. - - This method type is an iCalendar object that conforms to the - following property constraints: - -Component/Property Presence -------------------- --------------------------------------------- -METHOD 1 MUST be "CANCEL" -VTODO 1 - ATTENDEE 0+ include all "Attendees" being removed from - the todo. MUST include all "Attendees" if - the entire todo is cancelled. - UID 1 MUST echo original UID - DTSTAMP 1 - ORGANIZER 1 - SEQUENCE 1 - - ATTACH 0+ - CATEGORIES 0 or 1 This property MAY contain a list of values - CLASS 0 or 1 - COMMENT 0 or 1 - CONTACT 0+ - CREATED 0 or 1 - DESCRIPTION 0 or 1 - DTSTART 0 or 1 - DUE 0 or 1 If present DURATION MUST NOT be present - DURATION 0 or 1 If present DUE MUST NOT be present - EXDATE 0+ - EXRULE 0+ - GEO 0 or 1 - LAST-MODIFIED 0 or 1 - LOCATION 0 or 1 - PERCENT-COMPLETE 0 or 1 - RDATE 0+ - - - -Silverberg, et. al. Standards Track [Page 45] - -RFC 2446 iTIP November 1998 - - - RECURRENCE-ID 0 or 1 MUST only if referring to one or more - instances of a recurring calendar - component. Otherwise it MUST NOT be - present. - RELATED-TO 0+ - RESOURCES 0 or 1 This property MAY contain a list of values - RRULE 0+ - PRIORITY 0 or 1 - STATUS 0 or 1 If present it MUST be set to "CANCELLED". - MUST NOT be used if purpose is to remove - "ATTENDEES" rather than cancel the entire - VTODO. - URL 0 or 1 - X-PROPERTY 0+ - - REQUEST-STATUS 0 - -VTIMEZONE 0 or 1 MUST be present if any date/time refers to - a timezone -X-COMPONENT 0+ - -VALARM 0 -VEVENT 0 -VFREEBUSY 0 - -3.4.6 REFRESH - - The "REFRESH" method in a "VTODO" calendar component is used by - "Attendees" of an existing "VTODO" calendar component to request an - updated description from the "Organizer" of the "VTODO" calendar - component. The "Organizer" of the "VTODO" calendar component MAY use - this method to request an updated status from the "Attendees". The - "REFRESH" method MUST specify the "UID" property corresponding to the - "VTODO" calendar component needing update. - - A refresh of a recurrence instance of a "VTODO" calendar component - may be requested by specifying the "RECURRENCE-ID" property - corresponding to the associated "VTODO" calendar component. The - "Organizer" responds with the latest description and rendition of the - "VTODO" calendar component. In most cases this will be a REQUEST - unless the "VTODO" has been cancelled, in which case the ORGANIZER - MUST send a "CANCEL". This method is intended to facilitate machine - processing of requests for updates to a "VTODO" calendar component. - - This method type is an iCalendar object that conforms to the - following property constraints: - - - - - -Silverberg, et. al. Standards Track [Page 46] - -RFC 2446 iTIP November 1998 - - -Component/Property Presence -------------------- --------------------------------------------- -METHOD 1 MUST be "REFRESH" -VTODO 1 - ATTENDEE 1 - DTSTAMP 1 - UID 1 MUST echo original UID - - RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a - Recurring calendar component. Otherwise it - MUST NOT be present - X-PROPERTY 0+ - - ATTACH 0 - CATEGORIES 0 - CLASS 0 - COMMENT 0 - CONTACT 0 - CREATED 0 - DESCRIPTION 0 - DTSTART 0 - DUE 0 - DURATION 0 - EXDATE 0 - EXRULE 0 - GEO 0 - LAST-MODIFIED 0 - LOCATION 0 - ORGANIZER 0 - PERCENT-COMPLETE 0 - PRIORITY 0 - RDATE 0 - RELATED-TO 0 - REQUEST-STATUS 0 - RESOURCES 0 - RRULE 0 - SEQUENCE 0 - STATUS 0 - URL 0 - -X-COMPONENT 0+ - -VALARM 0 -VEVENT 0 -VFREEBUSY 0 -VTIMEZONE 0 - - - - - -Silverberg, et. al. Standards Track [Page 47] - -RFC 2446 iTIP November 1998 - - -3.4.7 COUNTER - - The "COUNTER" method in a "VTODO" calendar component is used by an - "Attendee" of an existing "VTODO" calendar component to submit to the - "Organizer" a counter proposal for the "VTODO" calendar component. - The "Attendee" sends the message to the "Organizer" of the "VTODO" - calendar component. - - The counter proposal is an iCalendar object consisting of a "VTODO" - calendar component describing the complete description of the - alternate "VTODO" calendar component. - - The "Organizer" rejects the counter proposal by sending the - "Attendee" a "DECLINECOUNTER" method. The "Organizer" accepts the - counter proposal by sending all of the "Attendees" of the "VTODO" - calendar component a "REQUEST" method rescheduling the "VTODO" - calendar component. In the latter case, the "Organizer" SHOULD reset - the individual "RSVP" property parameter values to TRUE on each - "ATTENDEE" property; in order to force a response by the "Attendees". - - This method type is an iCalendar object that conforms to the - following property constraints: - -Component/Property Presence -------------------- ---------------------------------------------- -METHOD 1 MUST be "COUNTER" -VTODO 1 - ATTENDEE 1+ - DTSTAMP 1 - ORGANIZER 1 - PRIORITY 1 - SUMMARY 1 Can be null - UID 1 - - ATTACH 0+ - CATEGORIES 0 or 1 This property MAY contain a list of values - CLASS 0 or 1 - COMMENT 0 or 1 - CONTACT 0+ - CREATED 0 or 1 - DESCRIPTION 0 or 1 Can be null - DTSTART 0 or 1 - DUE 0 or 1 If present DURATION MUST NOT be present - DURATION 0 or 1 If present DUE MUST NOT be present - EXDATE 0+ - EXRULE 0+ - GEO 0 or 1 - LAST-MODIFIED 0 or 1 - - - -Silverberg, et. al. Standards Track [Page 48] - -RFC 2446 iTIP November 1998 - - - LOCATION 0 or 1 - PERCENT-COMPLETE 0 or 1 - RDATE 0+ - RECURRENCE-ID 0 or 1 MUST only 3.5if referring to an instance of a - recurring calendar component. Otherwise it - MUST NOT be present. - RELATED-TO 0+ - REQUEST-STATUS 0+ - RESOURCES 0 or 1 This property MAY contain a list of values - RRULE 0 or 1 - SEQUENCE 0 or 1 MUST echo the original SEQUENCE number. - MUST be present if non-zero. MAY be present - if zero. - STATUS 0 or 1 MAY be one of COMPLETED/NEEDS ACTION/IN- - PROCESS/CANCELLED - URL 0 or 1 - X-PROPERTY 0+ - - -VALARM 0+ -VTIMEZONE 0 or 1 MUST be present if any date/time refers to - a timezone -X-COMPONENT 0+ - -VEVENT 0 -VFREEBUSY 0 - -3.4.8 DECLINECOUNTER - - The "DECLINECOUNTER" method in a "VTODO" calendar component is used - by an "Organizer" of "VTODO" calendar component to reject a counter - proposal offered by one of the "Attendees". The "Organizer" sends the - message to the "Attendee" that sent the "COUNTER" method to the - "Organizer". - - This method type is an iCalendar object that conforms to the - following property constraints: - -Component/Property Presence -------------------- --------------------------------------------- -METHOD 1 MUST be "DECLINECOUNTER" - -VTODO 1 - ATTENDEE 1+ MUST for all attendees - DTSTAMP 1 - ORGANIZER 1 - SEQUENCE 1 MUST echo the original SEQUENCE number - UID 1 MUST echo original UID - - - -Silverberg, et. al. Standards Track [Page 49] - -RFC 2446 iTIP November 1998 - - - ATTACH 0+ - CATEGORIES 0 or 1 This property may contain a list of values - CLASS 0 or 1 - COMMENT 0 or 1 - CONTACT 0+ - CREATED 0 or 1 - DESCRIPTION 0 or 1 - DTSTART 0 or 1 - DUE 0 or 1 If present DURATION MUST NOT be present - DURATION 0 or 1 If present DUE MUST NOT be present - EXDATE 0+ - EXRULE 0+ - GEO 0 or 1 - LAST-MODIFIED 0 or 1 - LOCATION 0 or 1 - PERCENT-COMPLETE 0 or 1 - PRIORITY 0 or 1 - RDATE 0+ - RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a - recurring calendar component. Otherwise - it MUST NOT be present. - RELATED-TO 0+ - REQUEST-STATUS 0+ - RESOURCES 0 or 1 This property MAY contain a list of values - RRULE 0+ - STATUS 0 or 1 MAY be one of COMPLETED/NEEDS ACTION/IN- - PROCESS - URL 0 or 1 - X-PROPERTY 0+ - -VTIMEZONE 0+ MUST be present if any date/time refers to - a timezone -X-COMPONENT 0+ - -VALARM 0 -VEVENT 0 -VFREEBUSY 0 - -3.5 Methods For VJOURNAL Components - - This section defines the property set for the methods that are - applicable to the "VJOURNAL" calendar component. - - The following summarizes the methods that are defined for the - "VJOURNAL" calendar component. - - - - - - -Silverberg, et. al. Standards Track [Page 50] - -RFC 2446 iTIP November 1998 - - - +================+==================================================+ - | Method | Description | - |================+==================================================| - | PUBLISH | Post a journal entry. Used primarily as a method | - | | of advertising the existence of a journal entry. | - | | | - | ADD | Add one or more instances to an existing journal | - | | entry. | - | | | - | CANCEL | Cancel one or more instances of an existing | - | | journal entry. | - +================+==================================================+ - -3.5.1 PUBLISH - - The "PUBLISH" method in a "VJOURNAL" calendar component has no - associated response. It is simply a posting of an iCalendar object - that may be added to a calendar. It MUST have an "Organizer". It MUST - NOT have "Attendees". The expected usage is for encapsulating an - - arbitrary journal entry as an iCalendar object. The "Organizer" MAY - subsequently update (with another "PUBLISH" method) or cancel (with a - "CANCEL" method) a previously published journal entry. - - This method type is an iCalendar object that conforms to the - following property constraints: - -Component/Property Presence -------------------- ---------------------------------------------- -METHOD 1 MUST be "PUBLISH" -VJOURNAL 1+ - DESCRIPTION 1 Can be null. - DTSTAMP 1 - DTSTART 1 - ORGANIZER 1 - UID 1 - - ATTACH 0+ - CATEGORIES 0 or 1 This property MAY contain a list of values - CLASS 0 or 1 - COMMENT 0 or 1 - CONTACT 0+ - CREATED 0 or 1 - EXDATE 0+ - EXRULE 0+ - LAST-MODIFIED 0 or 1 - RDATE 0+ - RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a - - - -Silverberg, et. al. Standards Track [Page 51] - -RFC 2446 iTIP November 1998 - - - recurring calendar component. Otherwise - it MUST NOT be present. - RELATED-TO 0+ - RRULE 0+ - SEQUENCE 0 or 1 MUST echo the original SEQUENCE number. - MUST be present if non-zero. MAY be - present if zero. - STATUS 0 or 1 MAY be one of DRAFT/FINAL/CANCELLED - SUMMARY 0 or 1 Can be null - URL 0 or 1 - X-PROPERTY 0+ - - ATTENDEE 0 - -VALARM 0+ -VTIMEZONE 0+ MUST be present if any date/time refers to - a timezone -X-COMPONENT 0+ - -VEVENT 0 -VFREEBUSY 0 -VTODO 0 - -3.5.2 ADD - - The "ADD" method in a "VJOURNAL" calendar component is used to add - one or more instances to an existing "VJOURNAL" entry. There is no - response to the "Organizer". - - If the "UID" property value in the "ADD" is not found on the - recipient's calendar, then the recipient MAY treat the "ADD" as a - "PUBLISH". - - This method type is an iCalendar object that conforms to the - following property constraints: - -Component/Property Presence -------------------- ---------------------------------------------- -METHOD 1 MUST be "ADD" -VJOURNAL 1 - DESCRIPTION 1 Can be null. - DTSTAMP 1 - DTSTART 1 - ORGANIZER 1 - SEQUENCE 1 MUST be greater than 0 - UID 1 MUST match that of the original journal - - ATTACH 0+ - - - -Silverberg, et. al. Standards Track [Page 52] - -RFC 2446 iTIP November 1998 - - - CATEGORIES 0 or 1 This property MAY contain a list of values - CLASS 0 or 1 - COMMENT 0 or 1 - CONTACT 0+ - CREATED 0 or 1 - EXDATE 0+ - EXRULE 0+ - LAST-MODIFIED 0 or 1 - RDATE 0+ - RELATED-TO 0+ - RRULE 0+ - STATUS 0 or 1 MAY be one of DRAFT/FINAL/CANCELLED - SUMMARY 0 or 1 Can be null - URL 0 or 1 - X-PROPERTY 0+ - - ATTENDEE 0 - RECURRENCE-ID 0 - -VALARM 0+ -VTIMEZONE 0 or 1 MUST be present if any date/time refers to - a timezone -X-COMPONENT 0+ - -VEVENT 0 -VFREEBUSY 0 -VTODO 0 - -3.5.3 CANCEL - - The "CANCEL" method in a "VJOURNAL" calendar component is used to - send a cancellation notice of an existing journal entry. The message - is sent by the "Organizer" of a journal entry. For a recurring - journal entry, either the whole journal entry or instances of a - journal entry may be cancelled. To cancel the complete range of a - recurring journal entry, the "UID" property value for the journal - entry MUST be specified and a "RECURRENCE-ID" property MUST NOT be - specified in the "CANCEL" method. In order to cancel an individual - instance of the journal entry, the "RECURRENCE-ID" property value for - the journal entry MUST be specified in the "CANCEL" method. - - There are two options for canceling a sequence of instances of a - recurring "VJOURNAL" calendar component: - - - - - - - - -Silverberg, et. al. Standards Track [Page 53] - -RFC 2446 iTIP November 1998 - - - (a) the "RECURRENCE-ID" property for an instance in the sequence MUST - be specified with the "RANGE" property parameter value of - THISANDPRIOR (or THISANDFUTURE) to indicate cancellation of the - specified "VTODO" calendar component and all instances before (or - after); or - - (b) individual recurrence instances may be cancelled by specifying - multiple "RECURRENCE-ID" properties corresponding to the - instances to be cancelled. - - When a "VJOURNAL" is cancelled, the "SEQUENCE" property value MUST be - incremented. - - This method type is an iCalendar object that conforms to the - following property constraints: - -Component/Property Presence -------------------- --------------------------------------------- -METHOD 1 MUST be "CANCEL" -VJOURNAL 1+ All MUST have the same UID - DTSTAMP 1 - ORGANIZER 1 - SEQUENCE 1 - UID 1 MUST be the UID of the original REQUEST - - ATTACH 0+ - ATTENDEE 0+ - CATEGORIES 0 or 1 This property MAY contain a list of values - CLASS 0 or 1 - COMMENT 0 or 1 - CONTACT 0+ - CREATED 0 or 1 - DESCRIPTION 0 or 1 - DTSTART 0 or 1 - EXDATE 0+ - EXRULE 0+ - LAST-MODIFIED 0 or 1 - RDATE 0+ - RECURRENCE-ID 0 or 1 only if referring to an instance of a - recurring calendar component. Otherwise - it MUST NOT be present. - RELATED-TO 0+ - RRULE 0+ - STATUS 0 or 1 MAY be present, must be "CANCELLED" if - present - SUMMARY 0 or 1 - URL 0 or 1 - X-PROPERTY 0+ - - - -Silverberg, et. al. Standards Track [Page 54] - -RFC 2446 iTIP November 1998 - - - REQUEST-STATUS 0 - -VTIMEZONE 0+ MUST be present if any date/time refers to - a timezone -X-COMPONENT 0+ -VALARM 0 -VEVENT 0 -VFREEBUSY 0 -VTODO 0 - -3.6 Status Replies - - The "REQUEST-STATUS" property may include the following values: - -|==============+============================+=========================| -| Short Return | Longer Return Status | Offending Data | -| Status Code | Description | | -|==============+============================+=========================| -| 2.0 | Success. | None. | -|==============+============================+=========================| -| 2.1 | Success but fallback taken | Property name and value | -| | on one or more property | MAY be specified. | -| | values. | | -|==============+============================+=========================| -| 2.2 | Success, invalid property | Property name MAY be | -| | ignored. | specified. | -|==============+============================+=========================| -| 2.3 | Success, invalid property | Property parameter name | -| | parameter ignored. | and value MAY be | -| | | specified. | -|==============+============================+=========================| -| 2.4 | Success, unknown non- | Non-standard property | -| | standard property ignored. | name MAY be specified. | -|==============+============================+=========================| -| 2.5 | Success, unknown non | Property and non- | -| | standard property value | standard value MAY be | -| | ignored. | specified. | -|==============+============================+=========================| -| 2.6 | Success, invalid calendar | Calendar component | -| | component ignored. | sentinel (e.g., BEGIN: | -| | | ALARM) MAY be | -| | | specified. | -|==============+============================+=========================| -| 2.7 | Success, request forwarded | Original and forwarded | -| | to Calendar User. | caluser addresses MAY | -| | | be specified. | -|==============+============================+=========================| -| 2.8 | Success, repeating event | RRULE or RDATE property | - - - -Silverberg, et. al. Standards Track [Page 55] - -RFC 2446 iTIP November 1998 - - -| | ignored. Scheduled as a | name and value MAY be | -| | single component. | specified. | -|==============+============================+=========================| -| 2.9 | Success, truncated end date| DTEND property value | -| | time to date boundary. | MAY be specified. | -|==============+============================+=========================| -| 2.10 | Success, repeating VTODO | RRULE or RDATE property | -| | ignored. Scheduled as a | name and value MAY be | -| | single VTODO. | specified. | -|==============+============================+=========================| -| 2.11 | Success, unbounded RRULE | RRULE property name and | -| | clipped at some finite | value MAY be specified. | -| | number of instances | Number of instances MAY | -| | | also be specified. | -|==============+============================+=========================| -| 3.0 | Invalid property name. | Property name MAY be | -| | | specified. | -|==============+============================+=========================| -| 3.1 | Invalid property value. | Property name and value | -| | | MAY be specified. | -|==============+============================+=========================| -| 3.2 | Invalid property parameter.| Property parameter name | -| | | and value MAY be | -| | | specified. | -|==============+============================+=========================| -| 3.3 | Invalid property parameter | Property parameter name | -| | value. | and value MAY be | -| | | specified. | -|==============+============================+=========================| -| 3.4 | Invalid calendar component | Calendar component | -| | sequence. | sentinel MAY be | -| | | specified (e.g., BEGIN: | -| | | VTIMEZONE). | -|==============+============================+=========================| -| 3.5 | Invalid date or time. | Date/time value(s) MAY | -| | | be specified. | -|==============+============================+=========================| -| 3.6 | Invalid rule. | Rule value MAY be | -| | | specified. | -|==============+============================+=========================| -| 3.7 | Invalid Calendar User. | Attendee property value | -| | |MAY be specified. | -|==============+============================+=========================| -| 3.8 | No authority. | METHOD and Attendee | -| | | property values MAY be | -| | | specified. | -|==============+============================+=========================| - - - - -Silverberg, et. al. Standards Track [Page 56] - -RFC 2446 iTIP November 1998 - - -| 3.9 | Unsupported version. | VERSION property name | -| | | and value MAY be | -| | | specified. | -|==============+============================+=========================| -| 3.10 | Request entity too large. | None. | -|==============+============================+=========================| -| 3.11 | Required component or | Component or property | -| | property missing. | name MAY be specified. | -|==============+============================+=========================| -| 3.12 | Unknown component or | Component or property | -| | property found | name MAY be specified | -|==============+============================+=========================| -| 3.13 | Unsupported component or | Component or property | -| | property found | name MAY be specified | -|==============+============================+=========================| -| 3.14 | Unsupported capability | Method or action MAY | -| | | be specified | -|==============+============================+=========================| -| 4.0 | Event conflict. Date/time | DTSTART and DTEND | -| | is busy. | property name and values| -| | | MAY be specified. | -|==============+============================+=========================| -| 5.0 | Request MAY supported. | Method property value | -| | | MAY be specified. | -|==============+============================+=========================| -| 5.1 | Service unavailable. | ATTENDEE property value | -| | | MAY be specified. | -|==============+============================+=========================| -| 5.2 | Invalid calendar service. | ATTENDEE property value | -| | | MAY be specified. | -|==============+============================+=========================| -| 5.3 | No scheduling support for | ATTENDEE property value | -| | user. | MAY be specified. | -|==============+============================+=========================| - -3.7 Implementation Considerations - -3.7.1 Working With Recurrence Instances - - iCalendar includes a recurrence grammar to represent recurring - events. The benefit of such a grammar is the ability to represent a - number of events in a single object. However, while this simplifies - creation of a recurring event, meeting instances still need to be - referenced. For instance, an "Attendee" may decline the third - instance of a recurring Friday event. Similarly, the "Organizer" may - change the time or location to a single instance of the recurring - event. - - - - -Silverberg, et. al. Standards Track [Page 57] - -RFC 2446 iTIP November 1998 - - - Since implementations may elect to store recurring events as either a - single event object or a collection of discreet, related event - objects, the protocol is designed so that each recurring instance may - be both referenced and versioned. Hence, implementations that choose - to maintain per-instance properties (such as "ATTENDEE" property - "partstat" parameter) may do so. However, the protocol does not - require per-instance recognition unless the instance itself must be - renegotiated. - - The scenarios for recurrence instance referencing are listed below. - For purposes of simplification a change to an event refers to a - "trigger property." That is, a property that has a substantive - effect on the meeting itself such as start time, location, due date - (for "VTODO" calendar component components) and possibly description. - - "Organizer" initiated actions: - - . "Organizer" deletes or changes a single instance of a recurring - event - . "Organizer" makes changes that affect all future instances - . "Organizer" makes changes that affect all previous instances - . "Organizer" deletes or modifies a previously changed instance - - "Attendee" initiated actions: - - . "Attendee" changes status for a particular recurrence instance - . "Attendee" sends Event-Counter for a particular recurrence - instance - - An instance of a recurring event is assigned a unique identification, - "RECURRENCE-ID" property, when that instance is renegotiated. - Negotiation may be necessary when a substantive change to the event - or to-do has be made (such as changing the start time, end time, due - date or location). The "Organizer" can identify a specific recurrence - instance using the "RECURRENCE-ID" property. The property value is - equal to the date/time of the instance. If the "Organizer" wishes to - change the "DTSTART", the original "DTSTART" value is used for - "RECURRENCE-ID" property and the new "DTSTART" and "DTEND" values - reflect the change. Note that after the change has occurred, the - "RECURRENCE-ID" has changed to the new "DTSTART" value. - -3.7.2 Attendee Property Considerations - - The "ORGANIZER" property is required on published events, to-dos, and - journal entries for two reasons. First, only the "Organizer" is - allowed to update and redistribute an event or to-do component. It - follows that the "ORGANIZER" property MUST be present in the event, - to-do, or journal entry component so that the CUA has a basis for - - - -Silverberg, et. al. Standards Track [Page 58] - -RFC 2446 iTIP November 1998 - - - authorizing an update. Second, it is prudent to provide a point of - contact for anyone who receives a published component in case of - problems. - - There are valid [RFC-822] addresses that represent groups. Sending - email to such an address results in mail being sent to multiple - recipients. Such an address may be used as the value of an - "ATTENDEE" property. Thus, it is possible that the recipient of a - "REQUEST" does not appear explicitly in the list. - - It is recommended that the general approach to finding a "Calendar - User" in an attendee list be as follows: - - 1. Search for the "Calendar User" in the attendee list where - "TYPE=INDIVIDUAL" - - 2. Failing (1) look for attendees where "TYPE=GROUP" or - 'TYPE=UNKNOWN". The CUA then determines if the "Calendar User" - is a member of one of these groups. If so, the "REPLY" method - sent to the "Organizer" MUST contain a new "ATTENDEE" property in - which: - . the "type" property parameter is set to INDIVIDUAL - . the "member" property parameter is set to the name of the - group - - 3. Failing (2) the CUA MAY ignore or accept the request as the - "Calendar User" wishes. - -3.7.3 X-Tokens - - To make iCalendar objects extensible, new property types MAY be - inserted into components. These properties are called X-Tokens as - they are prefixed with "X-". A client is not required to make sense - of X-Tokens. Clients are not required to save X-Tokens or use them - in replies. - -4 Examples - -4.1 Published Event Examples - - In the calendaring and scheduling context, publication refers to the - one way transfer of event information. Consumers of published events - simply incorporate the event into a calendar. No reply is expected. - Individual "A" publishes an event. Individual "B" reads the event and - incorporates it into their calendar. Events are published in several - ways including: embedding the event as an object in a web page, e- - mailing the event to a distribution list, and posting the event to a - newsgroup. - - - -Silverberg, et. al. Standards Track [Page 59] - -RFC 2446 iTIP November 1998 - - - The table below illustrates the sequence of events between the - publisher and the consumers of a published event. - - +-------------------------------------------------------------------+ - | Action | "Organizer" | - +---------------------------------+---------------------------------+ - | Publish an event | "A" sends or posts a PUBLISH | - | | message | - +---------------------------------+---------------------------------+ - | "B" reads a published event | | - +---------------------------------+---------------------------------+ - | Publish an updated event | "A" sends or posts a PUBLISH | - | | message | - +---------------------------------+---------------------------------+ - | "B" reads the updated event | | - +---------------------------------+---------------------------------+ - | Cancel a published event | "A" sends or posts a CANCEL | - | | message | - +---------------------------------+---------------------------------+ - | "B" reads the canceled event | | - | publication | | - +---------------------------------+---------------------------------+ - -4.1.1 A Minimal Published Event - - The iCalendar object below describes a single event that begins on - July 1, 1997 at 20:00 UTC. This event contains the minimum set of - properties for a "PUBLISH" for a "VEVENT" calendar component. - - BEGIN:VCALENDAR - METHOD:PUBLISH - PRODID:-//ACME/DesktopCalendar//EN - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:mailto:a@example.com - DTSTART:19970701T200000Z - DTSTAMP:19970611T190000Z - SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES - UID:0981234-1234234-23@example.com - END:VEVENT - END:VCALENDAR - -4.1.2 Changing A Published Event - - The iCalendar object below describes an update to the event described - in 4.1.1, the time has been changed, an end time has been added, and - the sequence number has been adjusted. - - - - -Silverberg, et. al. Standards Track [Page 60] - -RFC 2446 iTIP November 1998 - - - BEGIN:VCALENDAR - METHOD:PUBLISH - VERSION:2.0 - PRODID:-//ACME/DesktopCalendar//EN - BEGIN:VEVENT - ORGANIZER:mailto:a@example.com - DTSTAMP:19970612T190000Z - DTSTART:19970701T210000Z - DTEND:19970701T230000Z - SEQUENCE:1 - UID:0981234-1234234-23@example.com - SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES - END:VEVENT - END:VCALENDAR - - The "UID" property is used by the client to identify the event. The - "SEQUENCE" property indicates that this is a change to the event. The - event with a matching UID and sequence number 0 is superseded by this - event. - - The "SEQUENCE" property provides a reliable way to distinguish - different versions of the same event. Each time an event is - published, its sequence number is incremented. If a client receives - an event with a sequence number 5 and finds it has the same event - with sequence number 2, the event SHOULD be updated. However, if the - client received an event with sequence number 2 and finds it already - has sequence number 5 of the same event, the event MUST NOT be - updated. - -4.1.3 Canceling A Published Event - - The iCalendar object below cancels the event described in 4.1.1. This - cancels the event with "SEQUENCE" property of 0, 1, and 2. - - BEGIN:VCALENDAR - METHOD:CANCEL - VERSION:2.0 - PRODID:-//ACME/DesktopCalendar//EN - BEGIN:VEVENT - ORGANIZER:mailto:a@example.com - COMMENT:DUKES forfeit the game - SEQUENCE:2 - UID:0981234-1234234-23@example.com - DTSTAMP:19970613T190000Z - END:VEVENT - END:VCALENDAR - - - - - -Silverberg, et. al. Standards Track [Page 61] - -RFC 2446 iTIP November 1998 - - -4.1.4 A Rich Published Event - - This example describes the same event as in 4.1.1, but in much - greater detail. - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:PUBLISH - SCALE:GREGORIAN - VERSION:2.0 - BEGIN:VTIMEZONE - TZID:America-Chicago - TZURL:http://zones.stds_r_us.net/tz/America-Chicago - BEGIN:STANDARD - DTSTART:19671029T020000 - RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 - TZOFFSETFROM:-0500 - TZOFFSETTO:-0600 - TZNAME:CST - END:STANDARD - BEGIN:DAYLIGHT - DTSTART:19870405T020000 - RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 - TZOFFSETFROM:-0600 - TZOFFSETTO:-0500 - TZNAME:CDT - END:DAYLIGHT - END:VTIMEZONE - BEGIN:VEVENT - ORGANIZER:mailto:a@example.com - ATTACH:http://www.dukes.com/ - CATEGORIES:SPORTS EVENT,ENTERTAINMENT - CLASS:PRIVATE - DESCRIPTION:MIDWAY STADIUM\n - Big time game. MUST see.\n - Expected duration:2 hours\n - DTEND;TZID=America-Chicago:19970701T180000 - DTSTART;TZID=America-Chicago:19970702T160000 - DTSTAMP:19970614T190000Z - STATUS:CONFIRMED - LOCATION;VALUE=URI:http://www.midwaystadium.com/ - PRIORITY:2 - RESOURCES:SCOREBOARD - SEQUENCE:3 - SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES - UID:0981234-1234234-23@example.com - RELATED-TO:0981234-1234234-14@example.com - BEGIN:VALARM - - - -Silverberg, et. al. Standards Track [Page 62] - -RFC 2446 iTIP November 1998 - - - TRIGGER:-PT2H - ACTION:DISPLAY - DESCRIPTION:You should be leaving for the game now. - END:VALARM - BEGIN:VALARM - TRIGGER:-PT30M - ACTION:AUDIO - END:VALARM - END:VEVENT - END:VCALENDAR - - The "RELATED-TO" field contains the "UID" property of a related - calendar event. The "SEQUENCE" property 3 indicates that this event - supersedes versions 0, 1, and 2. - -4.1.5 Anniversaries or Events attached to entire days - - This example demonstrates the use of the "value" parameter to tie a - "VEVENT" to day rather than a specific time. - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:PUBLISH - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:mailto:a@example.com - DTSTAMP:19970614T190000Z - UID:0981234-1234234-23@example.com - DTSTART;VALUE=DATE:19970714 - RRULE:FREQ=YEARLY;INTERVAL=1 - SUMMARY: Bastille Day - END:VEVENT - END:VCALENDAR - -4.2 Group Event Examples - - Group events are distinguished from published events in that they - have "Attendees" and that there is interaction between the - "Attendees" and the "Organizer" with respect to the event. Individual - "A" requests a meeting between individuals "A", "B", "C" and "D". - Individual "B" confirms attendance to the meeting. Individual "C" - declines attendance. Individual "D" tentatively confirms attendance. - The following table illustrates the the message flow between these - individuals. A, the CU scheduling the meeting, is referenced as the - "Organizer". - - - - - - -Silverberg, et. al. Standards Track [Page 63] - -RFC 2446 iTIP November 1998 - - -+---------------------------------------------------------------------+ -| Action | "Organizer" | Attendee | -+---------------------------------------------------------------------+ -| Initiate a meeting | "A" sends a REQUEST | | -| request | message to "B", "C",| | -| | and "D" | | -+---------------------------------------------------------------------+ -| Accept the meeting | | "B" sends a REPLY | -| request | | message to "A" with its | -| | | ATTENDEE "partstat" para-| -| | | set to "accepted" | -+---------------------------------------------------------------------+ -| Decline the meeting| | "C" sends a REPLY | -| request | | message to "A" with its | -| | | ATTENDEE "partstat" para-| -| | | set to "declined" | -+---------------------------------------------------------------------+ -| Tentatively accept | | "D" sends a REPLY | -| the meeting request| | message to "A" with its | -| | | ATTENDEE "partstat" para-| -| | | set to "tentative" | -+---------------------------------------------------------------------+ -| Confirm meeting | "A" sends a REQUEST | | -| status with | message to "B" and | | -| attendees | "D" with updated | | -| | information. | | -+---------------------------------------------------------------------+ - -4.2.1 A Group Event Request - - A sample meeting request is sent from "A" to "B", "C", and "D". _E_ - is also sent a copy of the request but is not expected to attend and - need not reply. "E" illustrates how CUAs might implement an "FYI" - type feature. Note the use of the "role" parameter. The default value - for the "role" parameter is "req-participant" and it need not be - enumerated. In this case we are using the value "non-participant" to - indicate "E" is a non-attending CU. The parameter is not needed on - other "Attendees" since "participant" is the default value. - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;CN=BIG A:Mailto:A@example.com - ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=B:Mailto:B@example.com - ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=C:Mailto:C@example.com - - - -Silverberg, et. al. Standards Track [Page 64] - -RFC 2446 iTIP November 1998 - - - ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=Hal:Mailto:D@example.com - ATTENDEE;RSVP=FALSE;TYPE=ROOM:conf_Big@example.com - ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE:Mailto:E@example.com - DTSTAMP:19970611T190000Z - DTSTART:19970701T200000Z - DTEND:19970701T2000000Z - SUMMARY:Conference - UID:calsrv.example.com-873970198738777@example.com - SEQUENCE:0 - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - -4.2.2 Reply To A Group Event Request - - Attendee "B" accepts the meeting. - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REPLY - VERSION:2.0 - BEGIN:VEVENT - ATTENDEE;PARTSTAT=ACCEPTED:Mailto:B@example.com - ORGANIZER:MAILTO:A@example.com - UID:calsrv.example.com-873970198738777@example.com - SEQUENCE:0 - REQUEST-STATUS:2.0;Success - DTSTAMP:19970612T190000Z - END:VEVENT - END:VCALENDAR - - "B" could have declined the meeting or indicated tentative acceptance - by setting the "ATTENDEE" "partstat" parameter to "declined" or - "tentative", respectively. Also, "REQUEST-STATUS" is not required in - successful transactions. - -4.2.3 Update An Event - - The event is moved to a different time. The combination of the "UID" - property (unchanged) and the "SEQUENCE" (bumped to 1) properties - indicate the update. - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:Mailto:A@example.com - - - -Silverberg, et. al. Standards Track [Page 65] - -RFC 2446 iTIP November 1998 - - - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com - ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com - ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com - ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=Hal:Mailto:D@example.com - ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE; - CUTYPE=ROOM:Mailto:Conf@example.com - ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE:Mailto:E@example.com - DTSTART:19970701T180000Z - DTEND:19970701T190000Z - SUMMARY:Phone Conference - UID:calsrv.example.com-873970198738777@example.com - SEQUENCE:1 - DTSTAMP:19970613T190000Z - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - -4.2.4 Countering an Event Proposal - - "A" sends a "REQUEST" to "B" and "C". "B" makes a counter-proposal to - "A" to change the time and location. - - "A" sends the following "REQUEST": - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com - ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com - ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com - DTSTART:19970701T190000Z - DTEND:19970701T200000Z - SUMMARY:Discuss the Merits of the election results - LOCATION:Green Conference Room - UID:calsrv.example.com-873970198738777a@example.com - SEQUENCE:0 - DTSTAMP:19970611T190000Z - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - - "B" sends "COUNTER" to "A", requesting changes to time and place. "B" - uses the "COMMENT" property to communicate a rationale for the - change. Note that the "SEQUENCE" property is NOT incremented on a - "COUNTER". - - - -Silverberg, et. al. Standards Track [Page 66] - -RFC 2446 iTIP November 1998 - - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:COUNTER - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com - ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com - ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com - DTSTART:19970701T160000Z - DTEND:19970701T190000Z - DTSTAMP:19970612T190000Z - SUMMARY:Discuss the Merits of the election results - LOCATION:Green Conference Room - COMMENT:This time works much better and I think the big conference - room is too big - UID:calsrv.example.com-873970198738777a@example.com - SEQUENCE:0 - DTSTAMP:19970611T190000Z - END:VEVENT - END:VCALENDAR - - "A" accepts the changes from "B". To accept a counter-proposal, the - "Organizer" sends a new event "REQUEST" with an incremented sequence - number. - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com - ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com - ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com - DTSTAMP:19970613T190000Z - DTSTART:19970701T160000Z - DTEND:19970701T190000Z - SUMMARY:Discuss the Merits of the election results - changed to - meet B's schedule - LOCATION:Green Conference Room - UID:calsrv.example.com-873970198738777@example.com - SEQUENCE:1 - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - - Instead, "A" rejects "B's" counter proposal - - - -Silverberg, et. al. Standards Track [Page 67] - -RFC 2446 iTIP November 1998 - - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:DECLINECOUNTER - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:Mailto:A@example.com - ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com - COMMENT:Sorry, I cannot change this meeting time - UID:calsrv.example.com-873970198738777@example.com - SEQUENCE:0 - DTSTAMP:19970614T190000Z - END:VEVENT - END:VCALENDAR - -4.2.5 Delegating an Event - - When delegating an event request to another "Calendar User", the - "Delegator" must both update the "Organizer" with a "REPLY" and send - a request to the "Delegate". There is currently no protocol - limitation to delegation depth. It is possible for the original - - delegate to delegate the meeting to someone else, and so on. When a - request is delegated from one CUA to another there are a number of - responsibilities required of the "Delegator". The "Delegator" MUST: - - . Send a "REPLY" to the "Organizer" with the following updates: - . The "Delegator's" "ATTENDEE" property "partstat" parameter set - to "delegated" and the "delegated-to" parameter is set to the - address of the "Delegate" - . Add an additional "ATTENDEE" property for the "Delegate" with - the "delegated-from" property parameter set to the "Delegator" - . Indicate whether they want to continue to receive updates when - the "Organizer" sends out updated versions of the event. - Setting the "rsvp" property parameter to "TRUE" will cause the - updates to be sent, setting it to "FALSE" causes no further - updates to be sent. Note that in either case, if the "Delegate" - declines the invitation the "Delegator" will be notified. - . The "Delegator" MUST also send a copy of the original "REQUEST" - method to the "Delegate". - - It is not required that the "Delegate" include the "Delegator" in - their "REPLY" method. However, it is strongly advised since this will - inform the "Delegator" whether the "Delegate" plans to attend the - meeting. [Editors note: How so?] If the "Delegate" declines the - meeting, the "Delegator" may elect to delegate the "REQUEST" to - another CUA. The process is the same. - - - - - -Silverberg, et. al. Standards Track [Page 68] - -RFC 2446 iTIP November 1998 - - -+---------------------------------------------------------------------+ -| Action | "Organizer" | Attendee | -+---------------------------------------------------------------------+ -| Initiate a meeting | "A" sends a REQUEST | | -| request | message to "B" and | | -| | "C" | | -+---------------------------------------------------------------------+ -| Delegate: | | "C" sends a REPLY to "A" | -| "C" delegates to | | with the ATTENDEE. | -| "E" | | "partstat" parameter set | -| | | to "delegated" and with a| -| | | new "ATTENDEE" property | -| | | for "E". "E's" ATTENDEE | -| | | "delegated-from" param | -| | | is set to "C". "C's" | -| | | ATTENDEE "delegated-to" | -| | | param is set to "E". | -| | | "C" sends REQUEST message| -| | | to "E" with the original | -| | | meeting request | -| | | information. The | -| | | "partstat" property | -| | | parameter for "C" is set | -| | | to "delegated" and the | -| | | "delegated-to" | -| | | parameter is set to | -| | | the address of "E". An | -| | | "ATTENDEE" property is | -| | | added for "E" and the | -| | | "delegated-from" | -| | | parameter is set to | -| | | the address of "C". | -+---------------------------------------------------------------------+ -| Confirm meeting | | "E" sends REPLY message | -| attendance | | to "A" and optionally "C"| -| | | with its "partstat" | -| | | property parameter set | -| | | to "ACCEPTED" | -+---------------------------------------------------------------------+ -| Optional: | "A" sends REQUEST | | -| Redistribute | message to "B", "C" | | -| meeting to | and "E". | | -| attendees | | | -+---------------------------------------------------------------------+ - - - - - - - -Silverberg, et. al. Standards Track [Page 69] - -RFC 2446 iTIP November 1998 - - - "C" responds to the "Organizer". - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REPLY - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:MAILTO:A@Example.com - ATTENDEE;PARTSTAT=DELEGATED;DELEGATED- - TO="Mailto:E@example.com":Mailto:C@example.com - UID:calsrv.example.com-873970198738777@example.com - SEQUENCE:0 - REQUEST-STATUS:2.0;Success - DTSTAMP:19970611T190000Z - END:VEVENT - END:VCALENDAR - - Attendee "C" delegates presence at the meeting to "E". - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:Mailto:A@example.com - ATTENDEE;PARTSTAT=DELEGATED;DELEGATED- - TO="Mailto:E@example.com":Mailto:C@example.com - ATTENDEE;RSVP=TRUE; - DELEGATED-FROM="Mailto:C@example.com":Mailto:E@example.com - DTSTART:19970701T180000Z - DTEND:19970701T200000Z - SUMMARY:Phone Conference - UID:calsrv.example.com-873970198738777@example.com - SEQUENCE:0 - STATUS:CONFIRMED - DTSTAMP:19970611T190000Z - END:VEVENT - END:VCALENDAR - -4.2.6 Delegate Accepts the Meeting - - To accept a delegated meeting, the delegate, "E", sends the following - message to "A" and "C": - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REPLY - VERSION:2.0 - - - -Silverberg, et. al. Standards Track [Page 70] - -RFC 2446 iTIP November 1998 - - - BEGIN:VEVENT - ORGANIZER:MAILTO:A@Example.com - ATTENDEE;PARTSTAT=ACCEPTED;DELEGATED- - FROM="Mailto:C@example.com":Mailto:E@example.com - ATTENDEE;PARTSTAT=DELEGATED; - DELEGATED-TO="Mailto:E@example.com":Mailto:C@example.com - UID:calsrv.example.com-873970198738777@example.com - SEQUENCE:0 - REQUEST-STATUS:2.0;Success - DTSTAMP:19970614T190000Z - END:VEVENT - END:VCALENDAR - -4.2.7 Delegate Declines the Meeting - - In this example the "Delegate" declines the meeting request and sets - the "ATTENDEE" property "partstat" parameter to "DECLINED". The - "Organizer" SHOULD resend the "REQUEST" to "C" with the "partstat" - parameter of the "Delegate" set to "declined". This lets the - "Delegator" know that the "Delegate" has declined and provides an - opportunity to the "Delegator" to either accept the request or - delegate it to another CU. - - Response from "E" to "A" and "C". Note the use of the "COMMENT" - property "E" uses to indicate why the delegation was declined. - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REPLY - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:MAILTO:A@Example.com - ATTENDEE;PARTSTAT=DELEGATED; - DELEGATED-TO="Mailto:E@example.com":Mailto:C@example.com - ATTENDEE;PARTSTAT=DECLINED; - DELEGATED-FROM="Mailto:C@example.com":Mailto:E@example.com - COMMENT:Sorry, I will be out of town at that time. - UID:calsrv.example.com-873970198738777@example.com - SEQUENCE:0 - REQUEST-STATUS:2.0;Success - DTSTAMP:19970614T190000Z - END:VEVENT - END:VCALENDAR - - "A" resends the "REQUEST" method to "C". "A" may also wish to express - the fact that the item was delegated in the "COMMENT" property. - - - - - -Silverberg, et. al. Standards Track [Page 71] - -RFC 2446 iTIP November 1998 - - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:MAILTO:A@Example.com - ATTENDEE;PARTSTAT=DECLINED; - DELEGATED-FROM="Mailto:C@example.com":Mailto:E@example.com - ATTENDEE;RSVP=TRUE:Mailto:C@example.com - UID:calsrv.example.com-873970198738777@example.com - SEQUENCE:0 - SUMMARY:Phone Conference - DTSTART:19970701T180000Z - DTEND:19970701T200000Z - DTSTAMP:19970614T200000Z - COMMENT:DELEGATE (ATTENDEE Mailto:E@example.com) DECLINED YOUR - INVITATION - END:VEVENT - END:VCALENDAR - -4.2.8 Forwarding an Event Request - - The protocol does not prevent an "Attendee" from "forwarding" an - "VEVENT" calendar component to other "Calendar Users". Forwarding - differs from delegation in that the forwarded "Calendar User" (often - referred to as a "Party Crasher") does not replace the forwarding - "Calendar User". Implementations are not required to add the "Party - Crasher" to the "Attendee" list and hence there is no guarantee that - a "Party Crasher" will receive additional updates to the Event. The - forwarding "Calendar User" SHOULD NOT add the "Party Crasher" to the - attendee list. The "Organizer" MAY add the forwarded "Calendar User" - to the attendee list. - -4.2.9 Cancel A Group Event - - Individual "A" requests a meeting between individuals "A", "B", "C", - and "D". Individual "B" declines attendance to the meeting. - Individual "A" decides to cancel the meeting. The following table - illustrates the sequence of messages that would be exchanged between - these individuals. - - Messages related to a previously canceled event ("SEQUENCE" property - value is less than the "SEQUENCE" property value of the "CANCEL" - message) MUST be ignored. - - - - - - - -Silverberg, et. al. Standards Track [Page 72] - -RFC 2446 iTIP November 1998 - - - +--------------------------------------------------------------------+ - | Action | "Organizer" | "Attendee" | - +--------------------------------------------------------------------+ - | Initiate a meeting | "A" sends a REQUEST | | - | request | message to "B", "C",| | - | | and "D" | | - +--------------------------------------------------------------------+ - | Decline the meeting| | "B" sends a "REPLY" | - | request | | message to "A" with its | - | | | "partstat" para- | - | | | set to "declined". | - +--------------------------------------------------------------------+ - | Cancel the meeting | "A" sends a CANCEL | | - | | message to "B", "C" | | - | | and "D" | | - +--------------------------------------------------------------------+ - - The example shows how "A" cancels the event. - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:CANCEL - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:Mailto:A@example.com - ATTENDEE;TYPE=INDIVIDUAL;Mailto:A@example.com - ATTENDEE;TYPE=INDIVIDUAL:Mailto:B@example.com - ATTENDEE;TYPE=INDIVIDUAL:Mailto:C@example.com - ATTENDEE;TYPE=INDIVIDUAL:Mailto:D@example.com - COMMENT:Mr. B cannot attend. It's raining. Lets cancel. - UID:calsrv.example.com-873970198738777@example.com - SEQUENCE:1 - STATUS:CANCELLED - DTSTAMP:19970613T190000Z - END:VEVENT - END:VCALENDAR - - - - - - - - - - - - - - - -Silverberg, et. al. Standards Track [Page 73] - -RFC 2446 iTIP November 1998 - - -4.2.10 Removing Attendees - - "A" wants to remove "B" from a meeting. This is done by sending a - "CANCEL" to "B" and removing "B" from the attendee list in the master - copy of the event. - - +--------------------------------------------------------------------+ - | Action | "Organizer" | "Attendee" | - +--------------------------------------------------------------------+ - | Remove an "B" | "A" sends a CANCEL | | - | as an "Attendee" | message to "B" | | - +--------------------------------------------------------------------+ - | Update the master | "A" sends the | | - | copy of the event | updated event to | | - | | the remaining | | - | | "Attendees" | | - +--------------------------------------------------------------------+ - - The original meeting includes "A", "B", "C", and "D". The example - below shows the "CANCEL" that "A" sends to "B". Note that in the - example below the "STATUS" property is omitted. This is used when the - meeting itself is cancelled and not when the intent is to remove an - "Attendee" from the Event. - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:CANCEL - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:Mailto:A@example.com - ATTENDEE:mailto:B@example.com - COMMENT:You're off the hook for this meeting - UID:calsrv.example.com-873970198738777@example.com - DTSTAMP:19970613T193000Z - SEQUENCE:1 - END:VEVENT - END:VCALENDAR - - The updated master copy of the event is shown below. The "Organizer" - MAY resend the updated event to the remaining "Attendees". Note that - "B" has been removed. - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:Mailto:A@example.com - - - -Silverberg, et. al. Standards Track [Page 74] - -RFC 2446 iTIP November 1998 - - - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com - ATTENDEE;TYPE=INDIVIDUAL:Mailto:C@example.com - ATTENDEE;TYPE=INDIVIDUAL:Mailto:D@example.com - ATTENDEE;TYPE=ROOM:CR_Big@example.com - ATTENDEE;ROLE=NON-PARTICIPANT; - RSVP=FALSE:Mailto:E@example.com - DTSTAMP:19970611T190000Z - DTSTART:19970701T200000Z - DTEND:19970701T203000Z - SUMMARY:Phone Conference - UID:calsrv.example.com-873970198738777@example.com - SEQUENCE:2 - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - -4.2.11 Replacing the Organizer - - The scenario for this example begins with "A" as the "Organizer" for - a recurring meeting with "B", "C", and "D". "A" receives a new job - offer in another country and drops out of touch. "A" left no - forwarding address or way to be reached. Using out-of-band - communication, the other "Attendees" eventually learn what has - happened and reach an agreement that "B" should become the new - "Organizer" for the meeting. To do this, "B" sends out a new version - of the event and the other "Attendees" agree to accept "B" as the new - "Organizer". "B" also removes "A" from the event. - - When the "Organizer" is replaced, the "SEQUENCE" property value MUST - be incremented. - - This is the message "B" sends to "C" and "D" - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:Mailto:B@example.com - ATTENDEE;ROLE=CHAIR;STATUS=ACCEPTED:Mailto:B@example.com - ATTENDEE;TYPE=INDIVIDUAL:Mailto:C@example.com - ATTENDEE;TYPE=INDIVIDUAL:Mailto:D@example.com - DTSTAMP:19970611T190000Z - DTSTART:19970701T200000Z - DTEND:19970701T203000Z - RRULE:FREQ=WEEKLY - SUMMARY:Phone Conference - UID:123456@example.com - - - -Silverberg, et. al. Standards Track [Page 75] - -RFC 2446 iTIP November 1998 - - - SEQUENCE:1 - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - -4.3 Busy Time Examples - - Busy time objects can be used in several ways. First, a CU may - request busy time from another CU for a specific range of time. That - request can be answered with a busy time Reply. Additionally, a CU - may simply publish their busy time for a given interval and point - other CUs to the published location. The following examples outline - both scenarios. - - Individual "A" publishes busy time for one week. - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - VERSION:2.0 - METHOD:PUBLISH - BEGIN:VFREEBUSY - DTSTAMP:19980101T124100Z - ORGANIZER:MAILTO:A@Example.com - DTSTART:19980101T124200Z - DTEND:19980107T124200Z - FREEBUSY:19980101T180000Z/19980101T190000Z - FREEBUSY:19980103T020000Z/19980103T050000Z - FREEBUSY:19980107T020000Z/19980107T050000Z - FREEBUSY:19980113T000000Z/19980113T010000Z - FREEBUSY:19980115T190000Z/19980115T200000Z - FREEBUSY:19980115T220000Z/19980115T230000Z - FREEBUSY:19980116T013000Z/19980116T043000Z - END:VFREEBUSY - END:VCALENDAR - - Individual "A" requests busy time from individuals "B", "C". - Individual "B" and "C" replies with busy time data to individual "A". - The following table illustrates the sequence of messages that would - be exchanged between these individuals. - - - - - - - - - - - - -Silverberg, et. al. Standards Track [Page 76] - -RFC 2446 iTIP November 1998 - - -+--------------------------------------------------------------------+ -| Action | "Organizer" | Attendee | -+--------------------------------------------------------------------+ -| Initiate a busy | "A" sends "REQUEST" | | -| time request | message to "B" and | | -| | and "C" | | -+--------------------------------------------------------------------+ -| Reply to the "BUSY"| | "B" sends a "REPLY" | -| request with "BUSY"| | message to "A" with | -| time data | | busy time data | -+--------------------------------------------------------------------+ - -4.3.1 Request Busy Time - - "A" sends a "BUSY-REQUEST" to "B" and "C" for busy time - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VFREEBUSY - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR:Mailto:A@example.com - ATTENDEE:Mailto:B@example.com - ATTENDEE:Mailto:C@example.com - DTSTAMP:19970613T190000Z - DTSTART:19970701T080000Z - DTEND:19970701T200000 - UID:calsrv.example.com-873970198738777@example.com - END:VFREEBUSY - END:VCALENDAR - -4.3.2 Reply To A Busy Time Request - - "B" sends a "REPLY" method type of a "VFREEBUSY" calendar component - to "A" - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REPLY - VERSION:2.0 - BEGIN:VFREEBUSY - ORGANIZER:MAILTO:A@example.com - ATTENDEE:Mailto:B@example.com - DTSTART:19970701T080000Z - DTEND:19970701T200000Z - UID:calsrv.example.com-873970198738777@example.com - FREEBUSY:19970701T090000Z/PT1H,19970701T140000Z/PT30M - - - -Silverberg, et. al. Standards Track [Page 77] - -RFC 2446 iTIP November 1998 - - - DTSTAMP:19970613T190030Z - END:VFREEBUSY - END:VCALENDAR - - "B" is busy from 09:00 to 10:00 and from 14:00 to 14:30. - -4.4 Recurring Event and Time Zone Examples - -4.4.1 A Recurring Event Spanning Time Zones - - This event describes a weekly phone conference. The "Attendees" are - each in a different time zone. - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VTIMEZONE - TZID:America-SanJose - TZURL:http://zones.stds_r_us.net/tz/America-SanJose - BEGIN:STANDARD - DTSTART:19671029T020000 - RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 - TZOFFSETFROM:-0700 - TZOFFSETTO:-0800 - TZNAME:PST - END:STANDARD - BEGIN:DAYLIGHT - DTSTART:19870405T020000 - RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 - TZOFFSETFROM:-0800 - TZOFFSETTO:-0700 - TZNAME:PDT - END:DAYLIGHT - END:VTIMEZONE - BEGIN:VEVENT - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;TYPE=INDIVIDUAL:A@example.COM - ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:B@example.fr - ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:c@example.jp - DTSTAMP:19970613T190030Z - DTSTART;TZID=America-SanJose:19970701T140000 - DTEND;TZID=America-SanJose:19970701T150000 - RRULE:FREQ=WEEKLY;INTERVAL=20;WKST=SU;BYDAY=TU - RDATE;TZID=America-SanJose:19970910T140000 - EXDATE;TZID=America-SanJose:19970909T140000 - EXDATE;TZID=America-SanJose:19971028T140000 - SUMMARY:Weekly Phone Conference - - - -Silverberg, et. al. Standards Track [Page 78] - -RFC 2446 iTIP November 1998 - - - UID:calsrv.example.com-873970198738777@example.com - SEQUENCE:0 - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - - The first two components of this iCalendar object are the time zone - components. The "DTSTART" date coincides with the first instance of - the RRULE property. - - The recurring meeting is defined in a particular time zone, - presumably that of the originator. The client for each "Attendee" has - the responsibility of determining the recurrence time in the - "Attendee's" time zone. - - The repeating event starts on Tuesday, July 1, 1997 at 2:00pm PDT. - "Attendee" B@example.fr is in France where the local time on this - date is 9 hours ahead of PDT or 23:00. "Attendee" C@example.jp is in - Japan where local time is 8 hours ahead of UTC or Wednesday, July 2 - at 06:00. The event repeats weekly on Tuesdays (in PST/PDT). The - "RRULE" property results in 20 instances. The last instance falls on - Tuesday, November 11, 1997 2:00pm PDT. The "RDATE" property adds - another instance: WED, 10-SEP-1997 2:00 PM PST. - - There are two exceptions to this recurring appointment. The first one - is: - - TUE, 09-SEP-1997 23:00 GMT - TUE, 09-SEP-1997 14:00 PDT - WED, 10-SEP-1997 06:00 JST - - and the second is: - - TUE, 28-OCT-1997 23:00 GMT - TUE, 28-OCT-1997 14:00 PST - WED, 29-OCT-1997 06:00 JST - -4.4.2 Modify A Recurring Instance - - In this example the "Organizer" issues a recurring meeting. Later the - "Organizer" changes an instance of the event by changing the - "DTSTART" property. Note the use of "RECURRENCE-ID" property and - "SEQUENCE" property in the second request. - - Original Request: - - BEGIN:VCALENDAR - METHOD:REQUEST - - - -Silverberg, et. al. Standards Track [Page 79] - -RFC 2446 iTIP November 1998 - - - PRODID:-//RDU Software//NONSGML HandCal//EN - VERSION:2.0 - BEGIN:VEVENT - UID:guid-1@host1.com - SEQUENCE:0 - RRULE:FREQ=MONTHLY;BYMONTHDAY=1;UNTIL=19980901T210000Z - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com - ATTENDEE:Mailto:B@example.com - ATTENDEE:Mailto:C@example.com - ATTENDEE:Mailto:D@example.com - DESCRIPTION:IETF-C&S Conference Call - CLASS:PUBLIC - SUMMARY:IETF Calendaring Working Group Meeting - DTSTART:19970601T210000Z - DTEND:19970601T220000Z - LOCATION:Conference Call - DTSTAMP:19970526T083000Z - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - - The event request below is to change the time of a specific instance. - This changes the July 1st instance to July 3rd. - - BEGIN:VCALENDAR - METHOD:REQUEST - PRODID:-//RDU Software//NONSGML HandCal//EN - VERSION:2.0 - BEGIN:VEVENT - UID:guid-1@host1com - RECURRENCE-ID:19970701T210000Z - SEQUENCE:1 - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com - ATTENDEE:Mailto:B@example.com - ATTENDEE:Mailto:C@example.com - ATTENDEE:Mailto:D@example.com - DESCRIPTION:IETF-C&S Conference Call - CLASS:PUBLIC - SUMMARY:IETF Calendaring Working Group Meeting - DTSTART:19970703T210000Z - DTEND:19970703T220000Z - LOCATION:Conference Call - DTSTAMP:19970626T093000Z - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - - - -Silverberg, et. al. Standards Track [Page 80] - -RFC 2446 iTIP November 1998 - - -4.4.3 Cancel an Instance - - In this example the "Organizer" of a recurring event deletes the - August 1st instance. - - BEGIN:VCALENDAR - METHOD:CANCEL - PRODID:-//RDU Software//NONSGML HandCal//EN - VERSION:2.0 - BEGIN:VEVENT - UID:guid-1@host1.com - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com - ATTENDEE:Mailto:B@example.com - ATTENDEE:Mailto:C@example.com - ATTENDEE:Mailto:D@example.com - RECURRENCE-ID:19970801T210000Z - SEQUENCE:2 - STATUS:CANCELLED - DTSTAMP:19970721T093000Z - END:VEVENT - END:VCALENDAR - -4.4.4 Cancel Recurring Event - - In this example the "Organizer" wishes to cancel the entire recurring - event and any exceptions. - - BEGIN:VCALENDAR - METHOD:CANCEL - PRODID:-//RDU Software//NONSGML HandCal//EN - VERSION:2.0 - BEGIN:VEVENT - UID:guid-1@host1.com - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com - ATTENDEE:Mailto:B@example.com - ATTENDEE:Mailto:C@example.com - ATTENDEE:Mailto:D@example.com - DTSTAMP:19970721T103000Z - STATUS:CANCELLED - SEQUENCE:3 - END:VEVENT - END:VCALENDAR - - - - - - - -Silverberg, et. al. Standards Track [Page 81] - -RFC 2446 iTIP November 1998 - - -4.4.5 Change All Future Instances - - This example changes the meeting location from a conference call to - Seattle starting September 1 and extends to all future instances. - - BEGIN:VCALENDAR - METHOD:REQUEST - PRODID:-//RDU Software//NONSGML HandCal//EN - VERSION:2.0 - BEGIN:VEVENT - UID:guid-1@host1.com - RECURRENCE-ID;THISANDFUTURE:19970901T210000Z - SEQUENCE:3 - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com - ATTENDEE;RSVP=TRUE:Mailto:B@example.com - ATTENDEE;RSVP=TRUE:Mailto:C@example.com - ATTENDEE;RSVP=TRUE:Mailto:D@example.com - DESCRIPTION:IETF-C&S Discussion - CLASS:PUBLIC - SUMMARY:IETF Calendaring Working Group Meeting - DTSTART:19970901T210000Z - DTEND:19970901T220000Z - LOCATION:Building 32, Microsoft, Seattle, WA - DTSTAMP:19970526T083000Z - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - -4.4.6 Add A New Instance To A Recurring Event - - This example adds a one-time additional instance to the recurring - event. "Organizer" adds a second July meeting on the 15th. - - BEGIN:VCALENDAR - METHOD:ADD - PRODID:-//RDU Software//NONSGML HandCal//EN - VERSION:2.0 - BEGIN:VEVENT - UID:123456789@host1.com - SEQUENCE:4 - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com - ATTENDEE;RSVP=TRUE:Mailto:B@example.com - ATTENDEE;RSVP=TRUE:Mailto:C@example.com - ATTENDEE;RSVP=TRUE:Mailto:D@example.com - DESCRIPTION:IETF-C&S Conference Call - CLASS:PUBLIC - - - -Silverberg, et. al. Standards Track [Page 82] - -RFC 2446 iTIP November 1998 - - - SUMMARY:IETF Calendaring Working Group Meeting - DTSTART:19970715T210000Z - DTEND:19970715T220000Z - LOCATION:Conference Call - DTSTAMP:19970629T093000Z - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - -4.4.7 Add A New Series of Instances To A Recurring Event - - The scenario for this example involves an ongoing meeting, originally - set up to occur every Tuesday. The "Organizer" later decides that - the meetings need to be on Tuesdays and Thursdays, but does not want - to reschedule the entire meeting or lose any of the per-instance - information already collected. - - The original event: - - BEGIN:VCALENDAR - METHOD:REQUEST - PRODID:-//RDU Software//NONSGML HandCal//EN - VERSION:2.0 - BEGIN:VEVENT - UID:123456789@host1.com - SEQUENCE:0 - RRULE:WKST=SU;BYDAY=TU;FREQ=WEEKLY - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com - ATTENDEE;RSVP=TRUE:Mailto:B@example.com - SUMMARY:Review Accounts - DTSTART:19980303T210000Z - DTEND:19980303T220000Z - LOCATION:The White Room - DTSTAMP:19980301T093000Z - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - - Assume that many other updates happen to this event and that a lot of - instance-specific information exists in the recurring series. The - "SEQUENCE" property value is 7 for the next update. Now the - "Organizer" wants to add Thursdays to the event: - - BEGIN:VCALENDAR - METHOD:ADD - PRODID:-//RDU Software//NONSGML HandCal//EN - VERSION:2.0 - - - -Silverberg, et. al. Standards Track [Page 83] - -RFC 2446 iTIP November 1998 - - - BEGIN:VEVENT - UID:123456789@host1.com - SEQUENCE:7 - RRULE:WKST=SU;BYDAY=TH;FREQ=WEEKLY - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com - ATTENDEE;RSVP=TRUE:Mailto:B@example.com - SUMMARY:Review Accounts - DTSTART:19980303T210000Z - DTEND:19980303T220000Z - DTSTAMP:19980303T193000Z - LOCATION:The Usual conference room - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - - Alternatively, if the "Organizer" is not concerned with per-instance - updates, the entire event can be rescheduled using a "REQUEST". This - is done by using the "UID" of the event to reschedule and including - the modified "RRULE". Note, that since this is an entire rescheduling - of the event, any instance-specific information will be lost. - - BEGIN:VCALENDAR - METHOD:REQUEST - PRODID:-//RDU Software//NONSGML HandCal//EN - VERSION:2.0 - BEGIN:VEVENT - UID:123456789@host1.com - SEQUENCE:7 - RRULE:WKST=SU;BYDAY=TU,TH;FREQ=WEEKLY - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com - ATTENDEE;RSVP=TRUE:Mailto:B@example.com - SUMMARY:Review Accounts - DTSTART:19980303T210000Z - DTEND:19980303T220000Z - DTSTAMP:19980303T193000Z - LOCATION:The White Room - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - - The next series of examples illustrate how an "Organizer" would - respond to a "REFRESH" submitted by an "Attendee" after a series of - instance-specific modifications. To convey all instance-specific - changes, the "Organizer" must provide the latest event description - and the relevant instances. The first three examples show the history - including the initial "VEVENT" request and subsequent instance - - - -Silverberg, et. al. Standards Track [Page 84] - -RFC 2446 iTIP November 1998 - - - changes and finally the "REFRESH". - - Original Request: - - BEGIN:VCALENDAR - METHOD:REQUEST - PRODID:-//RDU Software//NONSGML HandCal//EN - VERSION:2.0 - BEGIN:VEVENT - UID:123456789@host1.com - SEQUENCE:0 - RDATE:19980304T180000Z - RDATE:19980311T180000Z - RDATE:19980318T180000Z - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com - ATTENDEE;RSVP=TRUE:Mailto:B@example.com - SUMMARY:Review Accounts - DTSTART:19980304T180000Z - DTEND:19980304T200000Z - DTSTAMP:19980303T193000Z - LOCATION:Conference Room A - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - - Organizer changes 2nd instance Location and Time: - - BEGIN:VCALENDAR - METHOD:REQUEST - PRODID:-//RDU Software//NONSGML HandCal//EN - VERSION:2.0 - BEGIN:VEVENT - UID:123456789@host1.com - SEQUENCE:1 - RECURRENCE-ID:19980311T180000Z - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com - ATTENDEE;RSVP=TRUE:Mailto:B@example.com - SUMMARY:Review Accounts - DTSTART:19980311T160000Z - DTEND:19980311T180000Z - DTSTAMP:19980306T193000Z - LOCATION:The Small conference room - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - - - - -Silverberg, et. al. Standards Track [Page 85] - -RFC 2446 iTIP November 1998 - - - Organizer adds a 4th instance of the meeting using the "ADD" method - - BEGIN:VCALENDAR - METHOD:ADD - PRODID:-//RDU Software//NONSGML HandCal//EN - VERSION:2.0 - BEGIN:VEVENT - UID:123456789@host1.com - SEQUENCE:2 - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com - ATTENDEE;RSVP=TRUE:Mailto:B@example.com - SUMMARY:Review Accounts - DTSTART:19980315T180000Z - DTEND:19980315T200000Z - DTSTAMP:19980307T193000Z - LOCATION:Conference Room A - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - - If "B" requests a "REFRESH", "A" responds with the following to - capture all instance-specific data. In this case both the initial - request and an additional "VEVENT" that specifies the instance- - specific data are included. Because these are both of the same type - (they are both "VEVENTS"), they can be conveyed in the same iCalendar - object. - - BEGIN:VCALENDAR - METHOD:REQUEST - PRODID:-//RDU Software//NONSGML HandCal//EN - VERSION:2.0 - BEGIN:VEVENT - UID:123456789@host1.com - SEQUENCE:2 - RDATE:19980304T180000Z - RDATE:19980311T160000Z - RDATE:19980315T180000Z - Error! Bookmark not defined. - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com - ATTENDEE;RSVP=TRUE:Mailto:B@example.com - SUMMARY:Review Accounts - DTSTART:19980304T180000Z - DTEND:19980304T200000Z - DTSTAMP:19980303T193000Z - LOCATION:Conference Room A - STATUS:CONFIRMED - - - -Silverberg, et. al. Standards Track [Page 86] - -RFC 2446 iTIP November 1998 - - - END:VEVENT - - BEGIN:VEVENT - Error! Bookmark not defined. - SEQUENCE:2 - RECURRENCE-ID:19980311T160000Z - Error! Bookmark not defined. - ATTENDEE;ROLE=CHAIR;Error! Bookmark not defined. - ATTENDEE;Error! Bookmark not defined. - SUMMARY:Review Accounts - DTSTART:19980311T160000Z - DTEND:19980304T180000Z - DTSTAMP:19980306T193000Z - LOCATION:The Small conference room - STATUS:CONFIRMED - END:VEVENT - - END:VCALENDAR - -4.4.8 Counter An Instance Of A Recurring Event - - In this example one of the "Attendees" counters the "DTSTART" - property of the proposed second July meeting. - - BEGIN:VCALENDAR - METHOD:COUNTER - PRODID:-//RDU Software//NONSGML HandCal//EN - VERSION:2.0 - BEGIN:VEVENT - UID:guid-1@host1.com - RECURRENCE-ID:19970715T210000Z - SEQUENCE:4 - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR;RSVP=TRUE:Mailto:A@example.com - ATTENDEE;RSVP=TRUE:Mailto:B@example.com - ATTENDEE;RSVP=TRUE:Mailto:C@example.com - ATTENDEE;RSVP=TRUE:Mailto:D@example.com - DESCRIPTION:IETF-C&S Conference Call - CLASS:PUBLIC - SUMMARY:IETF Calendaring Working Group Meeting - DTSTART:19970715T220000Z - DTEND:19970715T230000Z - LOCATION:Conference Call - COMMENT:May we bump this by an hour? I have a conflict - DTSTAMP:19970629T094000Z - END:VEVENT - END:VCALENDAR - - - - -Silverberg, et. al. Standards Track [Page 87] - -RFC 2446 iTIP November 1998 - - -4.4.9 Error Reply To A Request - - The following example illustrates a scenario where a meeting is - proposed containing an unsupported property and a bad property. - - Original Request - - BEGIN:VCALENDAR - METHOD:REQUEST - PRODID:-//RDU Software//NONSGML HandCal//EN - VERSION:2.0 - BEGIN:VEVENT - UID:guid-1@host1.com - SEQUENCE:0 - RRULE:FREQ=MONTHLY;BYMONTHDAY=1 - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR:Mailto:A@example.com - ATTENDEE;RSVP=TRUE:Mailto:B@example.com - ATTENDEE;RSVP=TRUE:Mailto:C@example.com - ATTENDEE;RSVP=TRUE:Mailto:D@example.com - DESCRIPTION:IETF-C&S Conference Call - CLASS:PUBLIC - SUMMARY:IETF Calendaring Working Group Meeting - DTSTART:19970601T210000Z - DTEND:19970601T220000Z - DTSTAMP:19970602T094000Z - LOCATION:Conference Call - STATUS:CONFIRMED - FOO:BAR - END:VEVENT - END:VCALENDAR - - Response from "B" to indicate that RRULE is not supported and an - unrecognized property was encountered - - BEGIN:VCALENDAR - PRODID:-//RDU Software//NONSGML HandCal//EN - METHOD:REPLY - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:Mailto:A@example.com - ATTENDEE:Mailto:B@example.com - REQUEST-STATUS:2.8;Repeating event ignored. Scheduled as a single - event;RRULE - REQUEST-STATUS:3.0;Invalid Property Name;FOO - UID:guid-1@host1.com - SEQUENCE:0 - DTSTAMP:19970603T094000Z - - - -Silverberg, et. al. Standards Track [Page 88] - -RFC 2446 iTIP November 1998 - - - END:VEVENT - END:VCALENDAR - -4.5 Group To-do Examples - - Individual "A" creates a group task in which individuals "A", "B", - "C" and "D" will participate. Individual "B" confirms acceptance of - the task. Individual "C" declines the task. Individual "D" - tentatively accepts the task. The following table illustrates the - sequence of messages that would be exchanged between these - individuals. Individual "A" then issues a "REQUEST" method to obtain - the status of the to-do from each participant. The response indicates - the individual "Attendee's" completion status. The table below - illustrates the message flow. - -+--------------------------------------------------------------------+ -| Action | "Organizer" | Attendee | -+--------------------------------------------------------------------+ -| Initiate a to-do | "A" sends a REQUEST | | -| request | message to "B", "C",| | -| | and "D" | | -+--------------------------------------------------------------------+ -| Accept the to-do | | "B" sends a "REPLY" | -| request | | message to "A" with its | -| | | "partstat" paramater | -| | | set to "accepted". | -+--------------------------------------------------------------------+ -| Decline the to-do | | "C" sends a REPLY | -| request | | message to "A" with its | -| | | "partstat" parameter | -| | | set to "declined". | -+--------------------------------------------------------------------+ -| Tentatively accept | | "D" sends a REPLY | -| the to-do request | | message to "A" with its | -| | | "partstat" parameter | -| | | set to "tentative". | -+--------------------------------------------------------------------+ -| Check attendee | "A" sends a REQUEST | | -| completion status | message to "B" and | | -| | "D" with current | | -| | information. | | -+--------------------------------------------------------------------+ -| Attendee indicates | | "B" sends a "REPLY" | -| percent complete | | message indicating | -| | | percent complete | - - - - - - -Silverberg, et. al. Standards Track [Page 89] - -RFC 2446 iTIP November 1998 - - -+--------------------------------------------------------------------+ -| Attendee indicates | | "D" sends a "REPLY" | -| completion | | message indicating | -| | | completion | -+--------------------------------------------------------------------+ - -4.5.1 A VTODO Request - - A sample "REQUEST" for a "VTODO" calendar component that "A" sends to - "B", "C", and "D". - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VTODO - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR:Mailto:A@example.com - ATTENDEE;RSVP=TRUE:Mailto:B@example.com - ATTENDEE;RSVP=TRUE:Mailto:C@example.com - ATTENDEE;RSVP=TRUE:Mailto:D@example.com - DTSTART:19970701T170000Z - DUE:19970722T170000Z - PRIORITY:1 - SUMMARY:Create the requirements document - UID:calsrv.example.com-873970198738777-00@example.com - SEQUENCE:0 - DTSTAMP:19970717T200000Z - STATUS:Needs Action - END:VTODO - END:VCALENDAR - -4.5.2 A VTODO Reply - - "B" accepts the to-do. - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REPLY - VERSION:2.0 - BEGIN:VTODO - ORGANIZER:Mailto:A@example.com - ATTENDEE;PARTSTAT=ACCEPTED:Mailto:B@example.com - UID:calsrv.example.com-873970198738777-00@example.com - COMMENT:I'll send you my input by e-mail - SEQUENCE:0 - DTSTAMP:19970717T203000Z - REQUEST-STATUS:2.0;Success - - - -Silverberg, et. al. Standards Track [Page 90] - -RFC 2446 iTIP November 1998 - - - END:VTODO - END:VCALENDAR - - "B" could have declined the TODO or indicated tentative acceptance by - setting the "partstat" property parameter sequence to "declined" or - "tentative", respectively. - -4.5.3 A VTODO Request for Updated Status - - "A" requests status from all "Attendees". - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VTODO - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR:Mailto:A@example.com - ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com - ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:D@example.com - UID:calsrv.example.com-873970198738777-00@example.com - SUMMARY:Create the requirements document - PRIORITY:1 - SEQUENCE:0 - STATUS:IN-PROCESS - DTSTART:19970701T170000Z - DTSTAMP:19970717T230000Z - END:VTODO - END:VCALENDAR - -4.5.4 A Reply: Percent-Complete - - A reply indicating the task being worked on and that "B" is 75% - complete with "B's" part of the assignment. - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REPLY - VERSION:2.0 - BEGIN:VTODO - ORGANIZER:MAILTO:A@example.com - ATTENDEE;PARTSTAT=IN-PROCESS:Mailto:B@example.com - PERCENT-COMPLETE:75 - UID:calsrv.example.com-873970198738777-00@example.com - DTSTAMP:19970717T233000Z - SEQUENCE:0 - END:VTODO - END:VCALENDAR - - - -Silverberg, et. al. Standards Track [Page 91] - -RFC 2446 iTIP November 1998 - - -4.5.5 A Reply: Completed - - A reply indicating that "D" completed "D's" part of the assignment. - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REPLY - VERSION:2.0 - BEGIN:VTODO - ORGANIZER:MAILTO:A@example.com - ATTENDEE;PARTSTAT=COMPLETED:Mailto:D@example.com - UID:calsrv.example.com-873970198738777-00@example.com - DTSTAMP:19970717T233000Z - SEQUENCE:0 - END:VTODO - END:VCALENDAR - -4.5.6 An Updated VTODO Request - - Organizer "A" resends the "VTODO" calendar component. "A" sets the - overall completion for the to-do at 40%. - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VTODO - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com - ATTENDEE;PARTSTAT=ACCEPTED;TYPE=INDIVIDUAL:Mailto:B@example.com - ATTENDEE;PARTSTAT=IN-PROCESS;TYPE=INDIVIDUAL:Mailto:D@example.com - DTSTART:19970701T170000Z - DUE:19970722T170000Z - PRIORITY:1 - SUMMARY:Create the requirements document - UID:calsrv.example.com-873970198738777-00@example.com - SEQUENCE:1 - DTSTAMP:19970718T100000Z - STATUS:IN-PROGRESS - PERCENT-COMPLETE:40 - END:VTODO - END:VCALENDAR - -4.5.7 Recurring VTODOs - - The following examples relate to recurring "VTODO" calendar - components. - - - - -Silverberg, et. al. Standards Track [Page 92] - -RFC 2446 iTIP November 1998 - - -4.5.7.1 Request for a Recurring VTODO - - In this example "A" sends a recurring "VTODO" calendar component to - "B" and "D". - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VTODO - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR:Mailto:A@example.com - ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com - ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:D@example.com - RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR - DTSTART:19980101T100000-0700 - DUE:19980103T100000-0700 - SUMMARY:Send Status Reports to Area Managers - UID:calsrv.example.com-873970198738777-00@example.com - SEQUENCE:0 - DTSTAMP:19970717T200000Z - STATUS:NEEDS ACTION - PRIORITY:1 - END:VTODO - END:VCALENDAR - -4.5.7.2 Calculating due dates in recurring VTODOs - - The due date in a recurring "VTODO" calendar component is either a - fixed interval specified in the "REQUEST" method or specified using - the "RECURRENCE-ID" property. The former is calculated by applying - the difference between "DTSTART" and "DUE" properties and applying it - to each of the start of each recurring instance. Hence, if the - initial "VTODO" calendar component specifies a "DTSTART" property - value of "19970701T190000Z" and a "DUE" property value of - "19970801T190000Z" the interval of one day which is applied to each - recurring instance of the "VTODO" calendar component to determine the - "DUE" date of the instance. - -4.5.7.3 Replying to an instance of a recurring VTODO - - In this example "B" updates "A" on a single instance of the "VTODO" - calendar component. - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REPLY - VERSION:2.0 - - - -Silverberg, et. al. Standards Track [Page 93] - -RFC 2446 iTIP November 1998 - - - BEGIN:VTODO - ATTENDEE;PARTSTAT=IN-PROCESS:Mailto:B@example.com - PERCENT-COMPLETE:75 - UID:calsrv.example.com-873970198738777-00@example.com - DTSTAMP:19970717T233000Z - RECURRENCE-ID:19980101T170000Z - SEQUENCE:1 - END:VTODO - END:VCALENDAR - -4.6 Journal Examples - - The iCalendar object below describes a single journal entry for - October 2, 1997. The "RELATED-TO" property references the phone - conference event for which minutes were taken. - - BEGIN:VCALENDAR - METHOD:PUBLISH - PRODID:-//ACME/DesktopCalendar//EN - VERSION:2.0 - BEGIN:VJOURNAL - DTSTART:19971002T200000Z - ORGANIZER:MAILTO:A@Example.com - SUMMARY:Phone conference minutes - DESCRIPTION:The editors meeting was held on October 1, 1997. - Details are in the attached document. - UID:0981234-1234234-2410@example.com - RELATED-TO:0981234-1234234-2402-35@example.com - ATTACH:ftp://ftp.example.com/pub/ed/minutes100197.txt - END:VJOURNAL - END:VCALENDAR - -4.7 Other Examples - -4.7.1 Event Refresh - - Refresh the event with "UID" property value of "guid-1- - 12345@host1.com": - - BEGIN:VCALENDAR - PRODID:-//RDU Software//NONSGML HandCal//EN - METHOD:REFRESH - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com - ATTENDEE:Mailto:B@example.com - ATTENDEE:Mailto:C@example.com - - - -Silverberg, et. al. Standards Track [Page 94] - -RFC 2446 iTIP November 1998 - - - ATTENDEE:Mailto:D@example.com - UID: guid-1-12345@host1.com - DTSTAMP:19970603T094000 - END:VEVENT - END:VCALENDAR - -4.7.2 Bad RECURRENCE-ID - - Component instances are identified by the combination of "UID", - "RECURRENCE-ID", and "SEQUENCE". When an "Organizer" sends a request - to an "Attendee", there are three cases in which an instance cannot - be found. They are: - - 1. The component with the referenced "UID" and "RECURRENCE-ID" has - been found but the "SEQUENCE" number in the calendar store does - not match that of the ITIP message. - - 2. The component with the referenced "UID" has been found, the - "SEQUENCE" numbers match, but the "RECURRENCE-ID" cannot be - found. - - 3. The "UID" and "SEQUENCE" numbers are found but the CUA does not - support recurrences. - - In case (1), two things can happen. If the "SEQUENCE" number of the - "Attendee's" instance is larger than that in the "Organizer's" - message then the "Attendee" is receiving an out-of-sequence message - and MUST ignore it. If the "SEQUENCE" number of the "Attendee's" - instance is smaller, then the "Organizer" is sending out a newer - version of the component and the "Attendee's" version needs to be - updated. Since one or more updates have been missed, the "Attendee" - SHOULD send a "REFRESH" message to the "Organizer" to get an updated - version of the event. - - In case (2), something has gone wrong. Both the "Organizer" and the - "Attendee" should have the same instances, but the "Attendee" does - not have the referenced instance. In this case the "Attendee" SHOULD - send a "REFRESH" to the "Organizer" to get an updated version of the - event. - - In case (3), the limitations of the "Attendee's" CUA makes it - impossible to match an instance other than the single instance - scheduled. In this case, the "Attendee" need not send a "REFRESH" to - the "Organizer". - - The example below shows a sequence in which an "Attendee" sends a - "REFRESH" to the "Organizer". - - - - -Silverberg, et. al. Standards Track [Page 95] - -RFC 2446 iTIP November 1998 - - -+--------------------------------------------------------------------+ -| Action | "Organizer" | Attendee | -+--------------------------------------------------------------------+ -| Update an instance | "A" sends "REQUEST"| | -| request | message to "B" | | -+--------------------------------------------------------------------+ -| Attendee requests | | "B" sends a "REFRESH" | -| refresh because | | message to "A" | -| "RECURRENCE-ID" was| | | -| not found | | | -+--------------------------------------------------------------------+ -| Refresh the entire | "A" sends the | | -| Event | latest copy of the | | -| | Event to "B" | | -+--------------------------------------------------------------------+ -| Attendee handles | | "B" updates to the | -| the request and | | latest copy of the | -| updates the | | meeting. | -| instance | | | -+--------------------------------------------------------------------+ - - Request from "A": - - BEGIN:VCALENDAR - METHOD:REQUEST - PRODID:-//RDU Software//NONSGML HandCal//EN - VERSION:2.0 - BEGIN:VEVENT - UID:acme-12345@host1.com - SEQUENCE:3 - RRULE:FREQ=WEEKLY - RDATE;VALUE=PERIOD:19970819T210000Z/199700819T220000Z - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com - ATTENDEE:Mailto:B@example.com - DESCRIPTION:IETF-C&S Conference Call - SUMMARY:IETF Calendaring Working Group Meeting - DTSTART:19970801T210000Z - DTEND:19970801T220000Z - RECURRENCE-ID:19970809T210000Z - DTSTAMP:19970726T083000 - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - - "B" has the event with "UID" property "acme-12345@host1.com" but - "B's" "SEQUENCE" property value is "1" and the event does not have an - instance at the specified recurrence time. This means that "B" has - - - -Silverberg, et. al. Standards Track [Page 96] - -RFC 2446 iTIP November 1998 - - - missed at least one update and needs a new copy of the event. "B" - requests the latest copy of the event with the following refresh - message: - - BEGIN:VCALENDAR - PRODID:-//RDU Software//NONSGML HandCal//EN - METHOD:REFRESH - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:Mailto:A@example.com - ATTENDEE:Mailto:B@example.com - UID:acme-12345@host1.com - DTSTAMP:19970603T094000 - END:VEVENT - END:VCALENDAR - -5 Application Protocol Fallbacks - -5.1 Partial Implementation - - Applications that support this memo are not required to support the - entire protocol. The following describes how methods and properties - SHOULD "fallback" in applications that do not support the complete - protocol. If a method or property is not addressed in this section, - it may be ignored. - -5.1.1 Event-Related Fallbacks - -Method Fallback --------------- ----------------------------------------------------- -PUBLISH Required -REQUEST PUBLISH -REPLY Required -ADD Required -CANCEL Required -REFRESH Required -COUNTER Reply with Not Supported -DECLINECOUNTER Required if EVENT-COUNTER is implemented; otherwise - reply with Not Supported - -iCalendar -Property Fallback --------------- ----------------------------------------------------- -CALSCALE Ignore; assume GREGORIAN -PRODID Ignore -METHOD Required as described in the Method list above -VERSION Ignore - - - - -Silverberg, et. al. Standards Track [Page 97] - -RFC 2446 iTIP November 1998 - - -Event-Related -Components Fallback --------------- ----------------------------------------------------- -VALARM Reply with Not Supported -VTIMEZONE Required if any DateTime value refers to a time zone. - -Component -Property Fallback --------------- ----------------------------------------------------- -ATTACH Ignore -ATTENDEE Required if EVENT-REQUEST is not implemented; - otherwise reply with Not Supported -CATEGORIES Ignore -CLASS Ignore -COMMENT Ignore -COMPLETED Ignore -nCONTACT Ignore -CREATED Ignore -DESCRIPTION Required -DURATION Reply with Not Supported -DTSTAMP Required -DTSTART Required -DTEND Required -EXDATE Ignore -EXRULE Ignore Reply with Not Supported. If implemented, - VTIMEZONE MUST also be implemented. -GEO Ignore -LAST-MODIFIED Ignore -LOCATION Required -ORGANIZER Ignore -PRIORITY Ignore -RELATED-TO Ignore -RDATE Ignore -RRULE Ignore. The first instance occurs on the DTStart - property. If implemented, VTIMEZONE MUST also be - implemented. -RECURRENCE-ID Required if RRULE is implemented; otherwise Ignore -REQUEST-STATUS Required -RESOURCES Ignore -SEQUENCE Required -STATUS Ignore -SUMMARY Ignore -TRANSP Required if FREEBUSY is implemented; otherwise Ignore -URL Ignore -UID Required -X- Ignore - - - - - -Silverberg, et. al. Standards Track [Page 98] - -RFC 2446 iTIP November 1998 - - -5.1.2 Free/Busy-Related Fallbacks - -Method Fallback --------------- ----------------------------------------------------- -PUBLISH Implementations MAY ignore the METHOD type. The - REQUEST-STATUS "3.14;Unsupported capability" MUST be - returned. -REQUEST Implementations MAY ignore the METHOD type. The - REQUEST-STATUS "3.14;Unsupported capability" MUST be - returned. -REPLY Implementations MAY ignore the METHOD type. The - REQUEST-STATUS "3.14;Unsupported capability" MUST be - returned. - - -iCalendar -Property Fallback --------------- ----------------------------------------------------- -CALSCALE Ignore; assume GREGORIAN. -PRODID Ignore -METHOD Required as described in the Method list above. -VERSION Ignore - - -Component -Property Fallback --------------- ----------------------------------------------------- -COMMENT Ignore -CONTACT Ignore -DTEND Required -DTSTAMP Required -DTSTART Required -DURATION Required -FREEBUSY Required -ORGANIZER Ignore -REQUEST-STATUS Ignore -UID Required -URL Ignore -X- Ignore - -5.1.3 To-Do-Related Fallbacks - -Method Fallback --------------- ----------------------------------------------------- -PUBLISH Required -REQUEST PUBLISH -REPLY Required -ADD Required - - - -Silverberg, et. al. Standards Track [Page 99] - -RFC 2446 iTIP November 1998 - - -CANCEL Required -REFRESH Required -COUNTER Reply with Not Supported -DECLINECOUNTER Required if VTODO - COUNTER is implemented; otherwise - reply with Not Supported - -iCalendar -Property Fallback --------------- ----------------------------------------------------- -CALSCALE Ignore; assume GREGORIAN. -PRODID Ignore -METHOD Required as described in the Method list above. -VERSION Ignore - - -To-Do-Related -Components Fallback --------------- ----------------------------------------------------- -VALARM Reply with Not Supported -VTIMEZONE Required if any DateTime value refers to a time zone. - - -Component -Property Fallback --------------- ----------------------------------------------------- -ATTACH Ignore -ATTENDEE Required if REQUEST is not implemented; otherwise - ignore -CATEGORIES Ignore -CLASS Ignore -COMMENT Ignore -COMPLETED Required -CONTACT Ignore -CREATED Ignore -DESCRIPTION Required -DUE Required -DURATION Ignore Reply with Not Supported -DTSTAMP Required -DTSTART Required -EXDATE Ignore Reply with Not Supported -EXRULE Ignore Reply with Not Supported. If implemented, - VTIMEZONE MUST also be implemented. -LAST-MODIFIED Ignore -LOCATION Ignore -ORGANIZER Ignore -PERCENT-COMPLETE Ignore -PRIORITY Required -RECURRENCE-ID Ignore - - - -Silverberg, et. al. Standards Track [Page 100] - -RFC 2446 iTIP November 1998 - - -RELATED-TO Ignore -REQUEST-STATUS Ignore -RDATE Ignore -RRULE Ignore. The first instance occurs on the DTSTART - property. If implemented, VTIMEZONE MUST also be - implemented. -RESOURCES Ignore -SEQUENCE Required -STATUS Required -SUMMARY Ignore -URL Ignore -UID Required -X- Ignore - -5.1.4 Journal-Related Fallbacks - - -Method Fallback --------------- ----------------------------------------------------- -PUBLISH Implementations MAY ignore the METHOD type. The - REQUEST-STATUS "3.14;Unsupported capability" MUST be - returned. -ADD Implementations MAY ignore the METHOD type. The - REQUEST-STATUS "3.14;Unsupported capability" MUST be - returned. -CANCEL Implementations MAY ignore the METHOD type. The - REQUEST-STATUS "3.14;Unsupported capability" MUST be - returned. - - -iCalendar -Property Fallback --------------- ----------------------------------------------------- -CALSCALE Ignore; assume GREGORIAN. -PRODID Ignore -METHOD Required as described in the Method list above. -VERSION Ignore - - -Journal-Related -Components Fallback --------------- ----------------------------------------------------- -VTIMEZONE Required if any DateTime value refers to a time zone. - - - - - - - - -Silverberg, et. al. Standards Track [Page 101] - -RFC 2446 iTIP November 1998 - - -Component -Property Fallback --------------- ----------------------------------------------------- -ATTACH Ignore -ATTENDEE Required if JOURNAL-REQUEST is implemented; otherwise - ignore -CATEGORIES Ignore -CLASS Ignore -COMMENT Ignore -CONTACT Ignore -CREATED Ignore -DESCRIPTION Required -DTSTAMP Required -DTSTART Required -EXDATE Ignore -EXRULE Ignore Reply with Not Supported. If implemented, - VTIMEZONE MUST also be implemented. -LAST-MODIFIED Ignore -ORGANIZER Ignore -RECURRENCE-ID Ignore -RELATED-TO Ignore -RDATE Ignore. -RRULE Ignore. The first instance occurs on the DTSTART - property. If implemented, VTIMEZONE MUST also be - implemented. -SEQUENCE Required -STATUS Ignore -SUMMARY Required -URL Ignore -UID Required -X- Ignore - -5.2 Latency Issues - - With a store-and-forward transport, it is possible for events to - arrive out of sequence. That is, a "CANCEL" method may be received - prior to receiving the associated "REQUEST" for the calendar - component. This section discusses a few of these scenarios. - -5.2.1 Cancellation of an Unknown Calendar Component. - - When a "CANCEL" method is received before the original "REQUEST" - method the calendar will be unable to correlate the "UID" property of - the cancellation with an existing calendar component. It is suggested - that messages that can not be correlated that also contain non-zero - sequence numbers be held and not discarded. Implementations MAY age - them out if no other messages arrive with the same "UID" property - value and a lower sequence number. - - - -Silverberg, et. al. Standards Track [Page 102] - -RFC 2446 iTIP November 1998 - - -5.2.2 Unexpected Reply from an Unknown Delegate - - When an "Attendee" delegates an item to another CU they MUST send a - "REPLY" method to the "Organizer" using the "ATTENDEE" properties to - indicate that the request was delegated and to whom. Hence, it is - possible for an "Organizer" to receive an "REPLY" from a CU not - listed as one of the original "Attendees". The resolution is left to - the implementation but it is expected that the calendaring software - will either accept the reply or hold it until the related "REPLY" - method is received from the "Delegator". If the version of the - "REPLY" method is out of date the "Organizer" SHOULD treat the - message as a "REFRESH" message and update the delegate with the - correct version. - -5.3 Sequence Number - - Under some conditions, a CUA may receive requests and replies with - the same "SEQUENCE" property value. The "DTSTAMP" property is - utilized as a tie-breaker when two items with the same "SEQUENCE" - property value are evaluated. - -6 Security Considerations - - ITIP is an abstract transport protocol which will be bound to a - real-time transport, a store-and-forward transport, and perhaps other - transports. The transport protocol will be responsible for providing - facilities for authentication and encryption using standard Internet - mechanisms that are mutually understood between the sender and - receiver. - -6.1 Security Threats - -6.1.1 Spoofing the "Organizer" - - In iTIP, the "Organizer" (or someone working on the "Organizer's" - behalf) is the only person authorized to make changes to an existing - "VEVENT", "VTODO", "VJOURNAL" calendar component and republish it or - redistribute updates to the "Attendees". An iCalendar object that - maliciously changes or cancels an existing "VEVENT", "VTODO" or - "VJOURNAL" calendar component may be constructed by someone other - than the "Organizer" and republished or sent to the "Attendees". - -6.1.2 Spoofing the "Attendee" - - In iTIP, an "Attendee" of a "VEVENT" or "VTODO" calendar component - (or someone working on the "Attendee's" behalf) is the only person - authorized to update any parameter associated with their "ATTENDEE" - property and send it to the "Organizer". An iCalendar object that - - - -Silverberg, et. al. Standards Track [Page 103] - -RFC 2446 iTIP November 1998 - - - maliciously changes the "ATTENDEE" parameters may be constructed by - someone other than the real "Attendee" and sent to the "Organizer". - -6.1.3 Unauthorized Replacement of the Organizer - - There will be circumstances when "Attendees" of an event or to-do - decide, using out-of-band mechanisms, that the "Organizer" must be - replaced. When the new "Organizer" sends out the updated "VEVENT" or - "VTODO" the "Attendee's" CUA will detect that the "Organizer" has - been changed, but it has no way of knowing whether or not the change - was mutually agreed upon. - -6.1.4 Eavesdropping - - The iCalendar object is constructed with human-readable clear text. - Any information contained in an iCalendar object may be read and/or - changed by unauthorized persons while the object is in transit. - -6.1.5 Flooding a Calendar - - Implementations MAY provide a means to automatically incorporate - "REQUEST" methods into a calendar. This presents the opportunity for - a calendar to be flooded with requests, which effectively block all - the calendar's free time. - -6.1.6 Procedural Alarms - - The "REQUEST" methods for "VEVENT" and "VTODO" calendar components - MAY contain "VALARM" calendar components. The "VALARM" calendar - component may be of type "PROCEDURE" and MAY have an attachment - containing an executable program. Implementations that incorporate - these types of alarms are subject to any virus or malicious attack - that may occur as a result of executing the attachment. - -6.1.7 Unauthorized REFRESH Requests - - It is possible for an "Organizer" to receive a "REFRESH" request from - someone who is not an "Attendee" of an event or to-do. Only - "Attendee's" of an event or to-do are authorized to receive replies - to "REFRESH" requests. Replying to such requests to anyone who is not - an "Attendee" may be a security problem. - -6.2 Recommendations - - For an application where the information is sensitive or critical and - the network is subject is subject to a high probability of attack, - iTIP transactions SHOULD be encrypted. This may be accomplished using - public key technology, specifically Security Multiparts for MIME - - - -Silverberg, et. al. Standards Track [Page 104] - -RFC 2446 iTIP November 1998 - - - [RFC-1847] in the iTIP transport binding. This helps mitigate the - threats of spoofing, eavesdropping and malicious changes in transit. - -6.2.1 Use of [RFC-1847] to secure iTIP transactions - - iTIP transport bindings MUST provide a mechanism based on Security - Multiparts for MIME [RFC-1847] to enable authentication of the - sender's identity, and privacy and integrity of the data being - transmitted. This allows the receiver of a signed iCalendar object to - verify the identity of the sender. This sender may then be correlated - to an "ATTENDEE" property in the iCalendar object. If the correlation - is made and the sender is authorized to make the requested change or - update then the operation may proceed. It also allows the message to - be encrypted to prevent unauthorized reading of the message contents - in transit. iTIP transport binding documents describe this process in - detail. - - Implementations MAY provide controls for users to disable this - capability. - -6.2.2 Implementation Controls - - The threat of unauthorized replacement of the "Organizer" SHOULD be - mitigated by a calendar system that uses this protocol by providing - controls or alerts that make "Calendar Users" aware of such - "Organizer" changes and allowing them to decide whether or not the - request should be honored. - - The threat of flooding a calendar SHOULD be mitigated by a calendar - system that uses this protocol by providing controls that may be used - to limit the acceptable sources for iTIP transactions, and perhaps - the size of messages and volume of traffic, by source. - - The threat of malicious procedural alarms SHOULD be mitigated by a - calendar system that uses this protocol by providing controls that - may be used to disallow procedural alarms in iTIP transactions and/or - remove all alarms from the object before delivery to the recipient. - - The threat of unauthorized "REFRESH" requests SHOULD be mitigated by - a calendar system that uses this protocol by providing controls or - alerts that allow "Calendar User" to decide whether or not the - request should be honored. An implementation MAY decide to maintain, - for audit or historical purposes, "Calendar Users" who were part of - an attendee list and who were subsequently uninvited. Similar - controls or alerts should be provided when a "REFRESH" request is - received from these "Calendar Users" as well. - - - - - -Silverberg, et. al. Standards Track [Page 105] - -RFC 2446 iTIP November 1998 - - -7 Acknowledgments - - A hearty thanks to the following individuals who have participated in - the drafting, review and discussion of this memo: - - Anik Ganguly, Dan Hickman, Paul Hill, Daryl Huff, Bruce Kahn, Antoine - Leca, Bob Mahoney, John Noerenberg, Leo Parker, John Rose, Doug - Royer, Vinod Seraphin, Richard Shusterman, Derik Stenerson, John Sun, - Alexander Taler, Kevin Tsurutome. - -8 Bibliography - - [iCAL] Dawson, F. and D. Stenerson, "Internet Calendaring and - Scheduling Core Object Specification - iCalendar", RFC - 2445, November 1998. - - [iMIP] Dawson, F., Mansour, S. and S. Silverberg, "iCalendar - Message-Based Interoperability Protocol - iMIP", RFC 2447, - November 1998. - - [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [US-ASCII] Coded Character Set--7-bit American Standard Code for - Information Interchange, ANSI X3.4-1986. - - - - - - - - - - - - - - - - - - - - - - - - - - -Silverberg, et. al. Standards Track [Page 106] - -RFC 2446 iTIP November 1998 - - -9 Authors' Addresses - - The following address information is provided in a vCard v3.0, - Electronic Business Card, format. - - The authors of this memo are: - - BEGIN:VCARD - VERSION:3.0 - N:Dawson;Frank - FN:Frank Dawson - ORG:Lotus Development Corporation - ADR;WORK;POSTAL;PARCEL:;;6544 Battleford Drive;Raleigh;NC;27613- - 3502;USA - TEL;TYPE=WORK,MSG:+1-919-676-9515 - TEL;TYPE=WORK,FAX:+1-919-676-9564 - EMAIL;TYPE=PREF,INTERNET:Frank_Dawson@Lotus.com - EMAIL;TYPE=INTERNET:fdawson@earthlink.net - URL:http://home.earthlink.net/~fdawson - END:VCARD - - BEGIN:VCARD - VERSION:3.0 - N:Hopson;Ross - FN:Ross Hopson - ORG:On Technology, Inc. - ADR;TYPE=WORK,POSTAL,PARCEL:;Suite 1600;434 Fayetteville St. - Mall\, Two Hannover Square;Raleigh;NC;27601 - TEL;TYPE=WORK,MSG:+1-919-890-4036 - TEL;TYPE=WORK,FAX:+1-919-890-4100 - EMAIL;TYPE=INTERNET:rhopson@on.com - END:VCARD - - BEGIN:VCARD - VERSION:3.0 - N:Mansour;Steve - FN:Steve Mansour - ORG:Netscape Communications Corporation - ADR;TYPE=WORK,POSTAL,PARCEL:;;501 East Middlefield Road;Mountain - View;CA;94043;USA - TEL;TYPE=WORK,MSG:+1-650-937-2378 - TEL;TYPE=WORK,FAX:+1-650-937-2103 - EMAIL;TYPE=INTERNET:sman@netscape.com - END:VCARD - - - - - - - -Silverberg, et. al. Standards Track [Page 107] - -RFC 2446 iTIP November 1998 - - - BEGIN:VCARD - VERSION:3.0 - N:Silverberg;Steve - FN:Steve Silverberg - ORG:Microsoft Corporation - ADR;TYPE=WORK,POSTAL,PARCEL:;;One Microsoft Way; - Redmond;WA;98052-6399;USA - TEL;TYPE=WORK,MSG:+1-425-936-9277 - TEL;TYPE=WORK,FAX:+1-425-936-8019 - EMAIL;INTERNET:stevesil@Microsoft.com - END:VCARD - - The iCalendar object is a result of the work of the Internet - Engineering Task Force Calendaring and scheduling Working Group. The - chairman of that working group is: - - BEGIN:VCARD - VERSION:3.0 - N:Ganguly;Anik - FN:Anik Ganguly - ORG:Open Text Inc. - ADR;TYPE=WORK,POSTAL,PARCEL:;Suite 101;38777 West Six Mile Road; - Livonia;MI;48152;USA - TEL;TYPE=WORK,MSG:+1-734-542-5955 - EMAIL;TYPE=INTERNET:ganguly@acm.org - END:VCARD - - The co-chairman of that working group is: - - BEGIN:VCARD - VERSION:3.0 - N:Moskowitz;Robert - FN:Robert Moskowitz - NICKNAME:Bob - EMAIL; TYPE=INTERNET:rgm-ietf@htt-consult.com - END:VCARD - - - - - - - - - - - - - - - -Silverberg, et. al. Standards Track [Page 108] - -RFC 2446 iTIP November 1998 - - -10. Full Copyright Statement - - Copyright (C) The Internet Society (1998). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - -Silverberg, et. al. Standards Track [Page 109] - diff --git a/etc/rfc5545.txt b/etc/rfc5545.txt deleted file mode 100644 index 47ea31d60..000000000 --- a/etc/rfc5545.txt +++ /dev/null @@ -1,9411 +0,0 @@ - - - - - - -Network Working Group B. Desruisseaux, Ed. -Request for Comments: 5545 Oracle -Obsoletes: 2445 September 2009 -Category: Standards Track - - - Internet Calendaring and Scheduling Core Object Specification - (iCalendar) - -Abstract - -This document defines the iCalendar data format for representing and -exchanging calendaring and scheduling information such as events, -to-dos, journal entries, and free/busy information, independent of any -particular calendar service or protocol. - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright and License Notice - - Copyright (c) 2009 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 BSD License. - - This document may contain material from IETF Documents or IETF - Contributions published or made publicly available before November - 10, 2008. The person(s) controlling the copyright in some of this - material may not have granted the IETF Trust the right to allow - modifications of such material outside the IETF Standards Process. - Without obtaining an adequate license from the person(s) controlling - the copyright in such materials, this document may not be modified - outside the IETF Standards Process, and derivative works of it may - not be created outside the IETF Standards Process, except to format - - - -Desruisseaux Standards Track [Page 1] - -RFC 5545 iCalendar September 2009 - - - it for publication as an RFC or to translate it into languages other - than English. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 - 2. Basic Grammar and Conventions . . . . . . . . . . . . . . . . 6 - 2.1. Formatting Conventions . . . . . . . . . . . . . . . . . 6 - 2.2. Related Memos . . . . . . . . . . . . . . . . . . . . . . 7 - 3. iCalendar Object Specification . . . . . . . . . . . . . . . 8 - 3.1. Content Lines . . . . . . . . . . . . . . . . . . . . . . 8 - 3.1.1. List and Field Separators . . . . . . . . . . . . . . 11 - 3.1.2. Multiple Values . . . . . . . . . . . . . . . . . . . 11 - 3.1.3. Binary Content . . . . . . . . . . . . . . . . . . . 11 - 3.1.4. Character Set . . . . . . . . . . . . . . . . . . . . 12 - 3.2. Property Parameters . . . . . . . . . . . . . . . . . . . 12 - 3.2.1. Alternate Text Representation . . . . . . . . . . . . 13 - 3.2.2. Common Name . . . . . . . . . . . . . . . . . . . . . 15 - 3.2.3. Calendar User Type . . . . . . . . . . . . . . . . . 15 - 3.2.4. Delegators . . . . . . . . . . . . . . . . . . . . . 16 - 3.2.5. Delegatees . . . . . . . . . . . . . . . . . . . . . 16 - 3.2.6. Directory Entry Reference . . . . . . . . . . . . . . 17 - 3.2.7. Inline Encoding . . . . . . . . . . . . . . . . . . . 17 - 3.2.8. Format Type . . . . . . . . . . . . . . . . . . . . . 18 - 3.2.9. Free/Busy Time Type . . . . . . . . . . . . . . . . . 19 - 3.2.10. Language . . . . . . . . . . . . . . . . . . . . . . 20 - 3.2.11. Group or List Membership . . . . . . . . . . . . . . 20 - 3.2.12. Participation Status . . . . . . . . . . . . . . . . 21 - 3.2.13. Recurrence Identifier Range . . . . . . . . . . . . . 22 - 3.2.14. Alarm Trigger Relationship . . . . . . . . . . . . . 23 - 3.2.15. Relationship Type . . . . . . . . . . . . . . . . . . 24 - 3.2.16. Participation Role . . . . . . . . . . . . . . . . . 25 - 3.2.17. RSVP Expectation . . . . . . . . . . . . . . . . . . 25 - 3.2.18. Sent By . . . . . . . . . . . . . . . . . . . . . . . 26 - 3.2.19. Time Zone Identifier . . . . . . . . . . . . . . . . 26 - 3.2.20. Value Data Types . . . . . . . . . . . . . . . . . . 28 - 3.3. Property Value Data Types . . . . . . . . . . . . . . . . 29 - 3.3.1. Binary . . . . . . . . . . . . . . . . . . . . . . . 29 - 3.3.2. Boolean . . . . . . . . . . . . . . . . . . . . . . . 30 - 3.3.3. Calendar User Address . . . . . . . . . . . . . . . . 30 - 3.3.4. Date . . . . . . . . . . . . . . . . . . . . . . . . 31 - 3.3.5. Date-Time . . . . . . . . . . . . . . . . . . . . . . 31 - 3.3.6. Duration . . . . . . . . . . . . . . . . . . . . . . 34 - 3.3.7. Float . . . . . . . . . . . . . . . . . . . . . . . . 35 - 3.3.8. Integer . . . . . . . . . . . . . . . . . . . . . . . 35 - 3.3.9. Period of Time . . . . . . . . . . . . . . . . . . . 36 - 3.3.10. Recurrence Rule . . . . . . . . . . . . . . . . . . . 37 - 3.3.11. Text . . . . . . . . . . . . . . . . . . . . . . . . 45 - - - -Desruisseaux Standards Track [Page 2] - -RFC 5545 iCalendar September 2009 - - - 3.3.12. Time . . . . . . . . . . . . . . . . . . . . . . . . 46 - 3.3.13. URI . . . . . . . . . . . . . . . . . . . . . . . . . 48 - 3.3.14. UTC Offset . . . . . . . . . . . . . . . . . . . . . 49 - 3.4. iCalendar Object . . . . . . . . . . . . . . . . . . . . 49 - 3.5. Property . . . . . . . . . . . . . . . . . . . . . . . . 50 - 3.6. Calendar Components . . . . . . . . . . . . . . . . . . . 50 - 3.6.1. Event Component . . . . . . . . . . . . . . . . . . . 52 - 3.6.2. To-Do Component . . . . . . . . . . . . . . . . . . . 56 - 3.6.3. Journal Component . . . . . . . . . . . . . . . . . . 58 - 3.6.4. Free/Busy Component . . . . . . . . . . . . . . . . . 60 - 3.6.5. Time Zone Component . . . . . . . . . . . . . . . . . 63 - 3.6.6. Alarm Component . . . . . . . . . . . . . . . . . . . 72 - 3.7. Calendar Properties . . . . . . . . . . . . . . . . . . . 77 - 3.7.1. Calendar Scale . . . . . . . . . . . . . . . . . . . 77 - 3.7.2. Method . . . . . . . . . . . . . . . . . . . . . . . 78 - 3.7.3. Product Identifier . . . . . . . . . . . . . . . . . 79 - 3.7.4. Version . . . . . . . . . . . . . . . . . . . . . . . 80 - 3.8. Component Properties . . . . . . . . . . . . . . . . . . 81 - 3.8.1. Descriptive Component Properties . . . . . . . . . . 81 - 3.8.1.1. Attachment . . . . . . . . . . . . . . . . . . . 81 - 3.8.1.2. Categories . . . . . . . . . . . . . . . . . . . 82 - 3.8.1.3. Classification . . . . . . . . . . . . . . . . . 83 - 3.8.1.4. Comment . . . . . . . . . . . . . . . . . . . . . 84 - 3.8.1.5. Description . . . . . . . . . . . . . . . . . . . 85 - 3.8.1.6. Geographic Position . . . . . . . . . . . . . . . 87 - 3.8.1.7. Location . . . . . . . . . . . . . . . . . . . . 88 - 3.8.1.8. Percent Complete . . . . . . . . . . . . . . . . 89 - 3.8.1.9. Priority . . . . . . . . . . . . . . . . . . . . 90 - 3.8.1.10. Resources . . . . . . . . . . . . . . . . . . . . 92 - 3.8.1.11. Status . . . . . . . . . . . . . . . . . . . . . 93 - 3.8.1.12. Summary . . . . . . . . . . . . . . . . . . . . . 94 - 3.8.2. Date and Time Component Properties . . . . . . . . . 95 - 3.8.2.1. Date-Time Completed . . . . . . . . . . . . . . . 95 - 3.8.2.2. Date-Time End . . . . . . . . . . . . . . . . . . 96 - 3.8.2.3. Date-Time Due . . . . . . . . . . . . . . . . . . 97 - 3.8.2.4. Date-Time Start . . . . . . . . . . . . . . . . . 99 - 3.8.2.5. Duration . . . . . . . . . . . . . . . . . . . . 100 - 3.8.2.6. Free/Busy Time . . . . . . . . . . . . . . . . . 101 - 3.8.2.7. Time Transparency . . . . . . . . . . . . . . . . 102 - 3.8.3. Time Zone Component Properties . . . . . . . . . . . 103 - 3.8.3.1. Time Zone Identifier . . . . . . . . . . . . . . 103 - 3.8.3.2. Time Zone Name . . . . . . . . . . . . . . . . . 105 - 3.8.3.3. Time Zone Offset From . . . . . . . . . . . . . . 106 - 3.8.3.4. Time Zone Offset To . . . . . . . . . . . . . . . 106 - 3.8.3.5. Time Zone URL . . . . . . . . . . . . . . . . . . 107 - 3.8.4. Relationship Component Properties . . . . . . . . . . 108 - 3.8.4.1. Attendee . . . . . . . . . . . . . . . . . . . . 108 - 3.8.4.2. Contact . . . . . . . . . . . . . . . . . . . . . 111 - - - -Desruisseaux Standards Track [Page 3] - -RFC 5545 iCalendar September 2009 - - - 3.8.4.3. Organizer . . . . . . . . . . . . . . . . . . . . 113 - 3.8.4.4. Recurrence ID . . . . . . . . . . . . . . . . . . 114 - 3.8.4.5. Related To . . . . . . . . . . . . . . . . . . . 117 - 3.8.4.6. Uniform Resource Locator . . . . . . . . . . . . 118 - 3.8.4.7. Unique Identifier . . . . . . . . . . . . . . . . 119 - 3.8.5. Recurrence Component Properties . . . . . . . . . . . 120 - 3.8.5.1. Exception Date-Times . . . . . . . . . . . . . . 120 - 3.8.5.2. Recurrence Date-Times . . . . . . . . . . . . . . 122 - 3.8.5.3. Recurrence Rule . . . . . . . . . . . . . . . . . 124 - 3.8.6. Alarm Component Properties . . . . . . . . . . . . . 134 - 3.8.6.1. Action . . . . . . . . . . . . . . . . . . . . . 134 - 3.8.6.2. Repeat Count . . . . . . . . . . . . . . . . . . 135 - 3.8.6.3. Trigger . . . . . . . . . . . . . . . . . . . . . 135 - 3.8.7. Change Management Component Properties . . . . . . . 138 - 3.8.7.1. Date-Time Created . . . . . . . . . . . . . . . . 138 - 3.8.7.2. Date-Time Stamp . . . . . . . . . . . . . . . . . 139 - 3.8.7.3. Last Modified . . . . . . . . . . . . . . . . . . 140 - 3.8.7.4. Sequence Number . . . . . . . . . . . . . . . . . 141 - 3.8.8. Miscellaneous Component Properties . . . . . . . . . 142 - 3.8.8.1. IANA Properties . . . . . . . . . . . . . . . . . 142 - 3.8.8.2. Non-Standard Properties . . . . . . . . . . . . . 142 - 3.8.8.3. Request Status . . . . . . . . . . . . . . . . . 144 - 4. iCalendar Object Examples . . . . . . . . . . . . . . . . . . 146 - 5. Recommended Practices . . . . . . . . . . . . . . . . . . . . 150 - 6. Internationalization Considerations . . . . . . . . . . . . . 151 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 151 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 151 - 8.1. iCalendar Media Type Registration . . . . . . . . . . . . 151 - 8.2. New iCalendar Elements Registration . . . . . . . . . . . 155 - 8.2.1. iCalendar Elements Registration Procedure . . . . . . 155 - 8.2.2. Registration Template for Components . . . . . . . . 155 - 8.2.3. Registration Template for Properties . . . . . . . . 156 - 8.2.4. Registration Template for Parameters . . . . . . . . 156 - 8.2.5. Registration Template for Value Data Types . . . . . 157 - 8.2.6. Registration Template for Values . . . . . . . . . . 157 - 8.3. Initial iCalendar Elements Registries . . . . . . . . . . 158 - 8.3.1. Components Registry . . . . . . . . . . . . . . . . . 158 - 8.3.2. Properties Registry . . . . . . . . . . . . . . . . . 158 - 8.3.3. Parameters Registry . . . . . . . . . . . . . . . . . 161 - 8.3.4. Value Data Types Registry . . . . . . . . . . . . . . 162 - 8.3.5. Calendar User Types Registry . . . . . . . . . . . . 162 - 8.3.6. Free/Busy Time Types Registry . . . . . . . . . . . . 163 - 8.3.7. Participation Statuses Registry . . . . . . . . . . . 163 - 8.3.8. Relationship Types Registry . . . . . . . . . . . . . 164 - 8.3.9. Participation Roles Registry . . . . . . . . . . . . 164 - 8.3.10. Actions Registry . . . . . . . . . . . . . . . . . . 165 - 8.3.11. Classifications Registry . . . . . . . . . . . . . . 165 - 8.3.12. Methods Registry . . . . . . . . . . . . . . . . . . 165 - - - -Desruisseaux Standards Track [Page 4] - -RFC 5545 iCalendar September 2009 - - - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 165 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 166 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 166 - 10.2. Informative References . . . . . . . . . . . . . . . . . 167 - Appendix A. Differences from RFC 2445 . . . . . . . . . . . . . 169 - A.1. New Restrictions . . . . . . . . . . . . . . . . . . . . 169 - A.2. Restrictions Removed . . . . . . . . . . . . . . . . . . 169 - A.3. Deprecated Features . . . . . . . . . . . . . . . . . . . 169 - -1. Introduction - - The use of calendaring and scheduling has grown considerably in the - last decade. Enterprise and inter-enterprise business has become - dependent on rapid scheduling of events and actions using this - information technology. This memo is intended to progress the level - of interoperability possible between dissimilar calendaring and - scheduling applications. This memo defines a MIME content type for - exchanging electronic calendaring and scheduling information. The - Internet Calendaring and Scheduling Core Object Specification, or - iCalendar, allows for the capture and exchange of information - normally stored within a calendaring and scheduling application; such - as a Personal Information Manager (PIM) or a Group-Scheduling - product. - - The iCalendar format is suitable as an exchange format between - applications or systems. The format is defined in terms of a MIME - content type. This will enable the object to be exchanged using - several transports, including but not limited to SMTP, HTTP, a file - system, desktop interactive protocols such as the use of a memory- - based clipboard or drag/drop interactions, point-to-point - asynchronous communication, wired-network transport, or some form of - unwired transport such as infrared. - - The memo also provides for the definition of iCalendar object methods - that will map this content type to a set of messages for supporting - calendaring and scheduling operations such as requesting, replying - to, modifying, and canceling meetings or appointments, to-dos, and - journal entries. The iCalendar object methods can be used to define - other calendaring and scheduling operations such as requesting for - and replying with free/busy time data. Such a scheduling protocol is - defined in the iCalendar Transport-independent Interoperability - Protocol (iTIP) defined in [2446bis]. - - The memo also includes a formal grammar for the content type based on - the Internet ABNF defined in [RFC5234]. This ABNF is required for - the implementation of parsers and to serve as the definitive - reference when ambiguities or questions arise in interpreting the - descriptive prose definition of the memo. Additional restrictions - - - -Desruisseaux Standards Track [Page 5] - -RFC 5545 iCalendar September 2009 - - - that could not easily be expressed with the ABNF syntax are specified - as comments in the ABNF. Comments with normative statements should - be treated as such. - -2. Basic Grammar and Conventions - - 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]. - - This memo makes use of both a descriptive prose and a more formal - notation for defining the calendaring and scheduling format. - - The notation used in this memo is the ABNF notation of [RFC5234]. - Readers intending on implementing the format defined in this memo - should be familiar with this notation in order to properly interpret - the specifications of this memo. - - All numeric values used in this memo are given in decimal notation. - - All names of properties, property parameters, enumerated property - values, and property parameter values are case-insensitive. However, - all other property values are case-sensitive, unless otherwise - stated. - - Note: All indented editorial notes, such as this one, are intended - to provide the reader with additional information. The - information is not essential to the building of an implementation - conformant with this memo. The information is provided to - highlight a particular feature or characteristic of the memo. - - The format for the iCalendar object is based on the syntax of the - text/directory media type [RFC2425]. While the iCalendar object is - not a profile of the text/directory media type [RFC2425], it does - reuse a number of the elements from the [RFC2425] specification. - -2.1. Formatting Conventions - - The elements defined in this memo are defined in prose. Many of the - terms used to describe these have common usage that is different than - the standards usage of this memo. In order to reference, within this - memo, elements of the calendaring and scheduling model, core object - (this memo), or interoperability protocol [2446bis] some formatting - conventions have been used. Calendaring and scheduling roles are - referred to in quoted-strings of text with the first character of - each word in uppercase. For example, "Organizer" refers to a role of - a "Calendar User" within the scheduling protocol defined by - [2446bis]. Calendar components defined by this memo are referred to - - - -Desruisseaux Standards Track [Page 6] - -RFC 5545 iCalendar September 2009 - - - with capitalized, quoted-strings of text. All calendar components - start with the letter "V". For example, "VEVENT" refers to the event - calendar component, "VTODO" refers to the to-do calendar component, - and "VJOURNAL" refers to the daily journal calendar component. - Scheduling methods defined by iTIP [2446bis] are referred to with - capitalized, quoted-strings of text. For example, "REQUEST" refers - to the method for requesting a scheduling calendar component be - created or modified, and "REPLY" refers to the method a recipient of - a request uses to update their status with the "Organizer" of the - calendar component. - - The properties defined by this memo are referred to with capitalized, - quoted-strings of text, followed by the word "property". For - example, "ATTENDEE" property refers to the iCalendar property used to - convey the calendar address of a calendar user. Property parameters - defined by this memo are referred to with lowercase, quoted-strings - of text, followed by the word "parameter". For example, "value" - parameter refers to the iCalendar property parameter used to override - the default value type for a property value. Enumerated values - defined by this memo are referred to with capitalized text, either - alone or followed by the word "value". For example, the "MINUTELY" - value can be used with the "FREQ" component of the "RECUR" value type - to specify repeating components based on an interval of one minute or - more. - - The following table lists the different characters from the - [US-ASCII] character set that is referenced in this document. For - each character, the table specifies the character name used - throughout this document, along with its US-ASCII decimal codepoint. - - - - - - - - - - - - - - - - - - - - - - -Desruisseaux Standards Track [Page 7] - -RFC 5545 iCalendar September 2009 - - - +------------------------+-------------------+ - | Character name | Decimal codepoint | - +------------------------+-------------------+ - | HTAB | 9 | - | LF | 10 | - | CR | 13 | - | DQUOTE | 22 | - | SPACE | 32 | - | PLUS SIGN | 43 | - | COMMA | 44 | - | HYPHEN-MINUS | 45 | - | PERIOD | 46 | - | SOLIDUS | 47 | - | COLON | 58 | - | SEMICOLON | 59 | - | LATIN CAPITAL LETTER N | 78 | - | LATIN CAPITAL LETTER T | 84 | - | LATIN CAPITAL LETTER X | 88 | - | LATIN CAPITAL LETTER Z | 90 | - | BACKSLASH | 92 | - | LATIN SMALL LETTER N | 110 | - +------------------------+-------------------+ - -2.2. Related Memos - - Implementers will need to be familiar with several other memos that, - along with this memo, form a framework for Internet calendaring and - scheduling standards. This memo specifies a core specification of - objects, value types, properties, and property parameters. - - o iTIP [2446bis] specifies an interoperability protocol for - scheduling between different implementations; - - o iCalendar Message-Based Interoperability Protocol (iMIP) [2447bis] - specifies an Internet email binding for [2446bis]. - - This memo does not attempt to repeat the specification of concepts or - definitions from these other memos. Where possible, references are - made to the memo that provides for the specification of these - concepts or definitions. - -3. iCalendar Object Specification - - The following sections define the details of a Calendaring and - Scheduling Core Object Specification. The Calendaring and Scheduling - Core Object is a collection of calendaring and scheduling - information. Typically, this information will consist of an - iCalendar stream with one or more iCalendar objects. The body of the - - - -Desruisseaux Standards Track [Page 8] - -RFC 5545 iCalendar September 2009 - - - iCalendar object consists of a sequence of calendar properties and - one or more calendar components. - - Section 3.1 defines the content line format; Section 3.2 defines the - property parameter format; Section 3.3 defines the data types for - property values; Section 3.4 defines the iCalendar object format; - Section 3.5 defines the iCalendar property format; Section 3.6 - defines the calendar component format; Section 3.7 defines calendar - properties; and Section 3.8 defines calendar component properties. - - This information is intended to be an integral part of the MIME - content type registration. In addition, this information can be used - independent of such content registration. In particular, this memo - has direct applicability for use as a calendaring and scheduling - exchange format in file-, memory-, or network-based transport - mechanisms. - -3.1. Content Lines - - The iCalendar object is organized into individual lines of text, - called content lines. Content lines are delimited by a line break, - which is a CRLF sequence (CR character followed by LF character). - - Lines of text SHOULD NOT be longer than 75 octets, excluding the line - break. Long content lines SHOULD be split into a multiple line - representations using a line "folding" technique. That is, a long - line can be split between any two characters by inserting a CRLF - immediately followed by a single linear white-space character (i.e., - SPACE or HTAB). Any sequence of CRLF followed immediately by a - single linear white-space character is ignored (i.e., removed) when - processing the content type. - - For example, the line: - - DESCRIPTION:This is a long description that exists on a long line. - - Can be represented as: - - DESCRIPTION:This is a lo - ng description - that exists on a long line. - - The process of moving from this folded multiple-line representation - to its single-line representation is called "unfolding". Unfolding - is accomplished by removing the CRLF and the linear white-space - character that immediately follows. - - - - - -Desruisseaux Standards Track [Page 9] - -RFC 5545 iCalendar September 2009 - - - When parsing a content line, folded lines MUST first be unfolded - according to the unfolding procedure described above. - - Note: It is possible for very simple implementations to generate - improperly folded lines in the middle of a UTF-8 multi-octet - sequence. For this reason, implementations need to unfold lines - in such a way to properly restore the original sequence. - - The content information associated with an iCalendar object is - formatted using a syntax similar to that defined by [RFC2425]. That - is, the content information consists of CRLF-separated content lines. - - The following notation defines the lines of content in an iCalendar - object: - - contentline = name *(";" param ) ":" value CRLF - ; This ABNF is just a general definition for an initial parsing - ; of the content line into its property name, parameter list, - ; and value string - - ; When parsing a content line, folded lines MUST first - ; be unfolded according to the unfolding procedure - ; described above. When generating a content line, lines - ; longer than 75 octets SHOULD be folded according to - ; the folding procedure described above. - - name = iana-token / x-name - - iana-token = 1*(ALPHA / DIGIT / "-") - ; iCalendar identifier registered with IANA - - x-name = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-") - ; Reserved for experimental use. - - vendorid = 3*(ALPHA / DIGIT) - ; Vendor identification - - param = param-name "=" param-value *("," param-value) - ; Each property defines the specific ABNF for the parameters - ; allowed on the property. Refer to specific properties for - ; precise parameter ABNF. - - param-name = iana-token / x-name - - param-value = paramtext / quoted-string - - paramtext = *SAFE-CHAR - - - - -Desruisseaux Standards Track [Page 10] - -RFC 5545 iCalendar September 2009 - - - value = *VALUE-CHAR - - quoted-string = DQUOTE *QSAFE-CHAR DQUOTE - - QSAFE-CHAR = WSP / %x21 / %x23-7E / NON-US-ASCII - ; Any character except CONTROL and DQUOTE - - SAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E - / NON-US-ASCII - ; Any character except CONTROL, DQUOTE, ";", ":", "," - - VALUE-CHAR = WSP / %x21-7E / NON-US-ASCII - ; Any textual character - - NON-US-ASCII = UTF8-2 / UTF8-3 / UTF8-4 - ; UTF8-2, UTF8-3, and UTF8-4 are defined in [RFC3629] - - CONTROL = %x00-08 / %x0A-1F / %x7F - ; All the controls except HTAB - - The property value component of a content line has a format that is - property specific. Refer to the section describing each property for - a definition of this format. - - All names of properties, property parameters, enumerated property - values and property parameter values are case-insensitive. However, - all other property values are case-sensitive, unless otherwise - stated. - -3.1.1. List and Field Separators - - Some properties and parameters allow a list of values. Values in a - list of values MUST be separated by a COMMA character. There is no - significance to the order of values in a list. For those parameter - values (such as those that specify URI values) that are specified in - quoted-strings, the individual quoted-strings are separated by a - COMMA character. - - Some property values are defined in terms of multiple parts. These - structured property values MUST have their value parts separated by a - SEMICOLON character. - - Some properties allow a list of parameters. Each property parameter - in a list of property parameters MUST be separated by a SEMICOLON - character. - - - - - - -Desruisseaux Standards Track [Page 11] - -RFC 5545 iCalendar September 2009 - - - Property parameters with values containing a COLON character, a - SEMICOLON character or a COMMA character MUST be placed in quoted - text. - - For example, in the following properties, a SEMICOLON is used to - separate property parameters from each other and a COMMA character is - used to separate property values in a value list. - - ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT:mailto: - jsmith@example.com - - RDATE;VALUE=DATE:19970304,19970504,19970704,19970904 - -3.1.2. Multiple Values - - Some properties defined in the iCalendar object can have multiple - values. The general rule for encoding multi-valued items is to - simply create a new content line for each value, including the - property name. However, it should be noted that some properties - support encoding multiple values in a single property by separating - the values with a COMMA character. Individual property definitions - should be consulted for determining whether a specific property - allows multiple values and in which of these two forms. Multi-valued - properties MUST NOT be used to specify multiple language variants of - the same value. Calendar applications SHOULD display all values. - -3.1.3. Binary Content - - Binary content information in an iCalendar object SHOULD be - referenced using a URI within a property value. That is, the binary - content information SHOULD be placed in an external MIME entity that - can be referenced by a URI from within the iCalendar object. In - applications where this is not feasible, binary content information - can be included within an iCalendar object, but only after first - encoding it into text using the "BASE64" encoding method defined in - [RFC4648]. Inline binary content SHOULD only be used in applications - whose special circumstances demand that an iCalendar object be - expressed as a single entity. A property containing inline binary - content information MUST specify the "ENCODING" property parameter. - Binary content information placed external to the iCalendar object - MUST be referenced by a uniform resource identifier (URI). - - The following example specifies an "ATTACH" property that references - an attachment external to the iCalendar object with a URI reference: - - ATTACH:http://example.com/public/quarterly-report.doc - - - - - -Desruisseaux Standards Track [Page 12] - -RFC 5545 iCalendar September 2009 - - - The following example specifies an "ATTACH" property with inline - binary encoded content information: - - ATTACH;FMTTYPE=text/plain;ENCODING=BASE64;VALUE=BINARY:VGhlIH - F1aWNrIGJyb3duIGZveCBqdW1wcyBvdmVyIHRoZSBsYXp5IGRvZy4 - -3.1.4. Character Set - - There is not a property parameter to declare the charset used in a - property value. The default charset for an iCalendar stream is UTF-8 - as defined in [RFC3629]. - - The "charset" Content-Type parameter MUST be used in MIME transports - to specify the charset being used. - -3.2. Property Parameters - - A property can have attributes with which it is associated. These - "property parameters" contain meta-information about the property or - the property value. Property parameters are provided to specify such - information as the location of an alternate text representation for a - property value, the language of a text property value, the value type - of the property value, and other attributes. - - Property parameter values that contain the COLON, SEMICOLON, or COMMA - character separators MUST be specified as quoted-string text values. - Property parameter values MUST NOT contain the DQUOTE character. The - DQUOTE character is used as a delimiter for parameter values that - contain restricted characters or URI text. For example: - - DESCRIPTION;ALTREP="cid:part1.0001@example.org":The Fall'98 Wild - Wizards Conference - - Las Vegas\, NV\, USA - - Property parameter values that are not in quoted-strings are case- - insensitive. - - The general property parameters defined by this memo are defined by - the following notation: - - - - - - - - - - - - - -Desruisseaux Standards Track [Page 13] - -RFC 5545 iCalendar September 2009 - - - icalparameter = altrepparam ; Alternate text representation - / cnparam ; Common name - / cutypeparam ; Calendar user type - / delfromparam ; Delegator - / deltoparam ; Delegatee - / dirparam ; Directory entry - / encodingparam ; Inline encoding - / fmttypeparam ; Format type - / fbtypeparam ; Free/busy time type - / languageparam ; Language for text - / memberparam ; Group or list membership - / partstatparam ; Participation status - / rangeparam ; Recurrence identifier range - / trigrelparam ; Alarm trigger relationship - / reltypeparam ; Relationship type - / roleparam ; Participation role - / rsvpparam ; RSVP expectation - / sentbyparam ; Sent by - / tzidparam ; Reference to time zone object - / valuetypeparam ; Property value data type - / other-param - - other-param = (iana-param / x-param) - - iana-param = iana-token "=" param-value *("," param-value) - ; Some other IANA-registered iCalendar parameter. - - x-param = x-name "=" param-value *("," param-value) - ; A non-standard, experimental parameter. - - Applications MUST ignore x-param and iana-param values they don't - recognize. - -3.2.1. Alternate Text Representation - - Parameter Name: ALTREP - - Purpose: To specify an alternate text representation for the - property value. - - Format Definition: This property parameter is defined by the - following notation: - - altrepparam = "ALTREP" "=" DQUOTE uri DQUOTE - - Description: This parameter specifies a URI that points to an - alternate representation for a textual property value. A property - specifying this parameter MUST also include a value that reflects - - - -Desruisseaux Standards Track [Page 14] - -RFC 5545 iCalendar September 2009 - - - the default representation of the text value. The URI parameter - value MUST be specified in a quoted-string. - - Note: While there is no restriction imposed on the URI schemes - allowed for this parameter, Content Identifier (CID) [RFC2392], - HTTP [RFC2616], and HTTPS [RFC2818] are the URI schemes most - commonly used by current implementations. - - Example: - - DESCRIPTION;ALTREP="CID:part3.msg.970415T083000@example.com": - Project XYZ Review Meeting will include the following agenda - items: (a) Market Overview\, (b) Finances\, (c) Project Man - agement - - The "ALTREP" property parameter value might point to a "text/html" - content portion. - - Content-Type:text/html - Content-Id: - - - - - - -

- Project XYZ Review Meeting will include - the following agenda items: -

    -
  1. Market Overview
  2. -
  3. Finances
  4. -
  5. Project Management
  6. -
-

- - - -3.2.2. Common Name - - Parameter Name: CN - - Purpose: To specify the common name to be associated with the - calendar user specified by the property. - - Format Definition: This property parameter is defined by the - following notation: - - - - -Desruisseaux Standards Track [Page 15] - -RFC 5545 iCalendar September 2009 - - - cnparam = "CN" "=" param-value - - Description: This parameter can be specified on properties with a - CAL-ADDRESS value type. The parameter specifies the common name - to be associated with the calendar user specified by the property. - The parameter value is text. The parameter value can be used for - display text to be associated with the calendar address specified - by the property. - - Example: - - ORGANIZER;CN="John Smith":mailto:jsmith@example.com - -3.2.3. Calendar User Type - - Parameter Name: CUTYPE - - Purpose: To identify the type of calendar user specified by the - property. - - Format Definition: This property parameter is defined by the - following notation: - - cutypeparam = "CUTYPE" "=" - ("INDIVIDUAL" ; An individual - / "GROUP" ; A group of individuals - / "RESOURCE" ; A physical resource - / "ROOM" ; A room resource - / "UNKNOWN" ; Otherwise not known - / x-name ; Experimental type - / iana-token) ; Other IANA-registered - ; type - ; Default is INDIVIDUAL - - Description: This parameter can be specified on properties with a - CAL-ADDRESS value type. The parameter identifies the type of - calendar user specified by the property. If not specified on a - property that allows this parameter, the default is INDIVIDUAL. - Applications MUST treat x-name and iana-token values they don't - recognize the same way as they would the UNKNOWN value. - - Example: - - ATTENDEE;CUTYPE=GROUP:mailto:ietf-calsch@example.org - - - - - - - -Desruisseaux Standards Track [Page 16] - -RFC 5545 iCalendar September 2009 - - -3.2.4. Delegators - - Parameter Name: DELEGATED-FROM - - Purpose: To specify the calendar users that have delegated their - participation to the calendar user specified by the property. - - Format Definition: This property parameter is defined by the - following notation: - - delfromparam = "DELEGATED-FROM" "=" DQUOTE cal-address - DQUOTE *("," DQUOTE cal-address DQUOTE) - - Description: This parameter can be specified on properties with a - CAL-ADDRESS value type. This parameter specifies those calendar - users that have delegated their participation in a group-scheduled - event or to-do to the calendar user specified by the property. - The individual calendar address parameter values MUST each be - specified in a quoted-string. - - Example: - - ATTENDEE;DELEGATED-FROM="mailto:jsmith@example.com":mailto: - jdoe@example.com - -3.2.5. Delegatees - - Parameter Name: DELEGATED-TO - - Purpose: To specify the calendar users to whom the calendar user - specified by the property has delegated participation. - - Format Definition: This property parameter is defined by the - following notation: - - deltoparam = "DELEGATED-TO" "=" DQUOTE cal-address DQUOTE - *("," DQUOTE cal-address DQUOTE) - - Description: This parameter can be specified on properties with a - CAL-ADDRESS value type. This parameter specifies those calendar - users whom have been delegated participation in a group-scheduled - event or to-do by the calendar user specified by the property. - The individual calendar address parameter values MUST each be - specified in a quoted-string. - - - - - - - -Desruisseaux Standards Track [Page 17] - -RFC 5545 iCalendar September 2009 - - - Example: - - ATTENDEE;DELEGATED-TO="mailto:jdoe@example.com","mailto:jqpublic - @example.com":mailto:jsmith@example.com - -3.2.6. Directory Entry Reference - - Parameter Name: DIR - - Purpose: To specify reference to a directory entry associated with - the calendar user specified by the property. - - Format Definition: This property parameter is defined by the - following notation: - - dirparam = "DIR" "=" DQUOTE uri DQUOTE - - Description: This parameter can be specified on properties with a - CAL-ADDRESS value type. The parameter specifies a reference to - the directory entry associated with the calendar user specified by - the property. The parameter value is a URI. The URI parameter - value MUST be specified in a quoted-string. - - Note: While there is no restriction imposed on the URI schemes - allowed for this parameter, CID [RFC2392], DATA [RFC2397], FILE - [RFC1738], FTP [RFC1738], HTTP [RFC2616], HTTPS [RFC2818], LDAP - [RFC4516], and MID [RFC2392] are the URI schemes most commonly - used by current implementations. - - Example: - - ORGANIZER;DIR="ldap://example.com:6666/o=ABC%20Industries, - c=US???(cn=Jim%20Dolittle)":mailto:jimdo@example.com - -3.2.7. Inline Encoding - - Parameter Name: ENCODING - - Purpose: To specify an alternate inline encoding for the property - value. - - Format Definition: This property parameter is defined by the - following notation: - - - - - - - - -Desruisseaux Standards Track [Page 18] - -RFC 5545 iCalendar September 2009 - - - encodingparam = "ENCODING" "=" - ( "8BIT" - ; "8bit" text encoding is defined in [RFC2045] - / "BASE64" - ; "BASE64" binary encoding format is defined in [RFC4648] - ) - - Description: This property parameter identifies the inline encoding - used in a property value. The default encoding is "8BIT", - corresponding to a property value consisting of text. The - "BASE64" encoding type corresponds to a property value encoded - using the "BASE64" encoding defined in [RFC2045]. - - If the value type parameter is ";VALUE=BINARY", then the inline - encoding parameter MUST be specified with the value - ";ENCODING=BASE64". - - Example: - - ATTACH;FMTTYPE=text/plain;ENCODING=BASE64;VALUE=BINARY:TG9yZW - 0gaXBzdW0gZG9sb3Igc2l0IGFtZXQsIGNvbnNlY3RldHVyIGFkaXBpc2ljaW - 5nIGVsaXQsIHNlZCBkbyBlaXVzbW9kIHRlbXBvciBpbmNpZGlkdW50IHV0IG - xhYm9yZSBldCBkb2xvcmUgbWFnbmEgYWxpcXVhLiBVdCBlbmltIGFkIG1pbm - ltIHZlbmlhbSwgcXVpcyBub3N0cnVkIGV4ZXJjaXRhdGlvbiB1bGxhbWNvIG - xhYm9yaXMgbmlzaSB1dCBhbGlxdWlwIGV4IGVhIGNvbW1vZG8gY29uc2VxdW - F0LiBEdWlzIGF1dGUgaXJ1cmUgZG9sb3IgaW4gcmVwcmVoZW5kZXJpdCBpbi - B2b2x1cHRhdGUgdmVsaXQgZXNzZSBjaWxsdW0gZG9sb3JlIGV1IGZ1Z2lhdC - BudWxsYSBwYXJpYXR1ci4gRXhjZXB0ZXVyIHNpbnQgb2NjYWVjYXQgY3VwaW - RhdGF0IG5vbiBwcm9pZGVudCwgc3VudCBpbiBjdWxwYSBxdWkgb2ZmaWNpYS - BkZXNlcnVudCBtb2xsaXQgYW5pbSBpZCBlc3QgbGFib3J1bS4= - -3.2.8. Format Type - - Parameter Name: FMTTYPE - - Purpose: To specify the content type of a referenced object. - - Format Definition: This property parameter is defined by the - following notation: - - fmttypeparam = "FMTTYPE" "=" type-name "/" subtype-name - ; Where "type-name" and "subtype-name" are - ; defined in Section 4.2 of [RFC4288]. - - Description: This parameter can be specified on properties that are - used to reference an object. The parameter specifies the media - type [RFC4288] of the referenced object. For example, on the - "ATTACH" property, an FTP type URI value does not, by itself, - - - -Desruisseaux Standards Track [Page 19] - -RFC 5545 iCalendar September 2009 - - - necessarily convey the type of content associated with the - resource. The parameter value MUST be the text for either an - IANA-registered media type or a non-standard media type. - - Example: - - ATTACH;FMTTYPE=application/msword:ftp://example.com/pub/docs/ - agenda.doc - -3.2.9. Free/Busy Time Type - - Parameter Name: FBTYPE - - Purpose: To specify the free or busy time type. - - Format Definition: This property parameter is defined by the - following notation: - - fbtypeparam = "FBTYPE" "=" ("FREE" / "BUSY" - / "BUSY-UNAVAILABLE" / "BUSY-TENTATIVE" - / x-name - ; Some experimental iCalendar free/busy type. - / iana-token) - ; Some other IANA-registered iCalendar free/busy type. - - Description: This parameter specifies the free or busy time type. - The value FREE indicates that the time interval is free for - scheduling. The value BUSY indicates that the time interval is - busy because one or more events have been scheduled for that - interval. The value BUSY-UNAVAILABLE indicates that the time - interval is busy and that the interval can not be scheduled. The - value BUSY-TENTATIVE indicates that the time interval is busy - because one or more events have been tentatively scheduled for - that interval. If not specified on a property that allows this - parameter, the default is BUSY. Applications MUST treat x-name - and iana-token values they don't recognize the same way as they - would the BUSY value. - - Example: The following is an example of this parameter on a - "FREEBUSY" property. - - FREEBUSY;FBTYPE=BUSY:19980415T133000Z/19980415T170000Z - - - - - - - - - -Desruisseaux Standards Track [Page 20] - -RFC 5545 iCalendar September 2009 - - -3.2.10. Language - - Parameter Name: LANGUAGE - - Purpose: To specify the language for text values in a property or - property parameter. - - Format Definition: This property parameter is defined by the - following notation: - - languageparam = "LANGUAGE" "=" language - - language = Language-Tag - ; As defined in [RFC5646]. - - Description: This parameter identifies the language of the text in - the property value and of all property parameter values of the - property. The value of the "LANGUAGE" property parameter is that - defined in [RFC5646]. - - For transport in a MIME entity, the Content-Language header field - can be used to set the default language for the entire body part. - Otherwise, no default language is assumed. - - Example: The following are examples of this parameter on the - "SUMMARY" and "LOCATION" properties: - - SUMMARY;LANGUAGE=en-US:Company Holiday Party - - LOCATION;LANGUAGE=en:Germany - - LOCATION;LANGUAGE=no:Tyskland - -3.2.11. Group or List Membership - - Parameter Name: MEMBER - - Purpose: To specify the group or list membership of the calendar - user specified by the property. - - Format Definition: This property parameter is defined by the - following notation: - - memberparam = "MEMBER" "=" DQUOTE cal-address DQUOTE - *("," DQUOTE cal-address DQUOTE) - - - - - - -Desruisseaux Standards Track [Page 21] - -RFC 5545 iCalendar September 2009 - - - Description: This parameter can be specified on properties with a - CAL-ADDRESS value type. The parameter identifies the groups or - list membership for the calendar user specified by the property. - The parameter value is either a single calendar address in a - quoted-string or a COMMA-separated list of calendar addresses, - each in a quoted-string. The individual calendar address - parameter values MUST each be specified in a quoted-string. - - Example: - - ATTENDEE;MEMBER="mailto:ietf-calsch@example.org":mailto: - jsmith@example.com - - ATTENDEE;MEMBER="mailto:projectA@example.com","mailto:pr - ojectB@example.com":mailto:janedoe@example.com - -3.2.12. Participation Status - - Parameter Name: PARTSTAT - - Purpose: To specify the participation status for the calendar user - specified by the property. - - Format Definition: This property parameter is defined by the - following notation: - - partstatparam = "PARTSTAT" "=" - (partstat-event - / partstat-todo - / partstat-jour) - - partstat-event = ("NEEDS-ACTION" ; Event needs action - / "ACCEPTED" ; Event accepted - / "DECLINED" ; Event declined - / "TENTATIVE" ; Event tentatively - ; accepted - / "DELEGATED" ; Event delegated - / x-name ; Experimental status - / iana-token) ; Other IANA-registered - ; status - ; These are the participation statuses for a "VEVENT". - ; Default is NEEDS-ACTION. - - partstat-todo = ("NEEDS-ACTION" ; To-do needs action - / "ACCEPTED" ; To-do accepted - / "DECLINED" ; To-do declined - / "TENTATIVE" ; To-do tentatively - ; accepted - - - -Desruisseaux Standards Track [Page 22] - -RFC 5545 iCalendar September 2009 - - - / "DELEGATED" ; To-do delegated - / "COMPLETED" ; To-do completed - ; COMPLETED property has - ; DATE-TIME completed - / "IN-PROCESS" ; To-do in process of - ; being completed - / x-name ; Experimental status - / iana-token) ; Other IANA-registered - ; status - ; These are the participation statuses for a "VTODO". - ; Default is NEEDS-ACTION. - - - - partstat-jour = ("NEEDS-ACTION" ; Journal needs action - / "ACCEPTED" ; Journal accepted - / "DECLINED" ; Journal declined - / x-name ; Experimental status - / iana-token) ; Other IANA-registered - ; status - ; These are the participation statuses for a "VJOURNAL". - ; Default is NEEDS-ACTION. - - Description: This parameter can be specified on properties with a - CAL-ADDRESS value type. The parameter identifies the - participation status for the calendar user specified by the - property value. The parameter values differ depending on whether - they are associated with a group-scheduled "VEVENT", "VTODO", or - "VJOURNAL". The values MUST match one of the values allowed for - the given calendar component. If not specified on a property that - allows this parameter, the default value is NEEDS-ACTION. - Applications MUST treat x-name and iana-token values they don't - recognize the same way as they would the NEEDS-ACTION value. - - Example: - - ATTENDEE;PARTSTAT=DECLINED:mailto:jsmith@example.com - -3.2.13. Recurrence Identifier Range - - Parameter Name: RANGE - - Purpose: To specify the effective range of recurrence instances from - the instance specified by the recurrence identifier specified by - the property. - - Format Definition: This property parameter is defined by the - following notation: - - - -Desruisseaux Standards Track [Page 23] - -RFC 5545 iCalendar September 2009 - - - rangeparam = "RANGE" "=" "THISANDFUTURE" - ; To specify the instance specified by the recurrence identifier - ; and all subsequent recurrence instances. - - Description: This parameter can be specified on a property that - specifies a recurrence identifier. The parameter specifies the - effective range of recurrence instances that is specified by the - property. The effective range is from the recurrence identifier - specified by the property. If this parameter is not specified on - an allowed property, then the default range is the single instance - specified by the recurrence identifier value of the property. The - parameter value can only be "THISANDFUTURE" to indicate a range - defined by the recurrence identifier and all subsequent instances. - The value "THISANDPRIOR" is deprecated by this revision of - iCalendar and MUST NOT be generated by applications. - - Example: - - RECURRENCE-ID;RANGE=THISANDFUTURE:19980401T133000Z - -3.2.14. Alarm Trigger Relationship - - Parameter Name: RELATED - - Purpose: To specify the relationship of the alarm trigger with - respect to the start or end of the calendar component. - - Format Definition: This property parameter is defined by the - following notation: - - trigrelparam = "RELATED" "=" - ("START" ; Trigger off of start - / "END") ; Trigger off of end - - Description: This parameter can be specified on properties that - specify an alarm trigger with a "DURATION" value type. The - parameter specifies whether the alarm will trigger relative to the - start or end of the calendar component. The parameter value START - will set the alarm to trigger off the start of the calendar - component; the parameter value END will set the alarm to trigger - off the end of the calendar component. If the parameter is not - specified on an allowable property, then the default is START. - - Example: - - TRIGGER;RELATED=END:PT5M - - - - - -Desruisseaux Standards Track [Page 24] - -RFC 5545 iCalendar September 2009 - - -3.2.15. Relationship Type - - Parameter Name: RELTYPE - - Purpose: To specify the type of hierarchical relationship associated - with the calendar component specified by the property. - - Format Definition: This property parameter is defined by the - following notation: - - reltypeparam = "RELTYPE" "=" - ("PARENT" ; Parent relationship - Default - / "CHILD" ; Child relationship - / "SIBLING" ; Sibling relationship - / iana-token ; Some other IANA-registered - ; iCalendar relationship type - / x-name) ; A non-standard, experimental - ; relationship type - - Description: This parameter can be specified on a property that - references another related calendar. The parameter specifies the - hierarchical relationship type of the calendar component - referenced by the property. The parameter value can be PARENT, to - indicate that the referenced calendar component is a superior of - calendar component; CHILD to indicate that the referenced calendar - component is a subordinate of the calendar component; or SIBLING - to indicate that the referenced calendar component is a peer of - the calendar component. If this parameter is not specified on an - allowable property, the default relationship type is PARENT. - Applications MUST treat x-name and iana-token values they don't - recognize the same way as they would the PARENT value. - - Example: - - RELATED-TO;RELTYPE=SIBLING:19960401-080045-4000F192713@ - example.com - -3.2.16. Participation Role - - Parameter Name: ROLE - - Purpose: To specify the participation role for the calendar user - specified by the property. - - Format Definition: This property parameter is defined by the - following notation: - - - - - -Desruisseaux Standards Track [Page 25] - -RFC 5545 iCalendar September 2009 - - - roleparam = "ROLE" "=" - ("CHAIR" ; Indicates chair of the - ; calendar entity - / "REQ-PARTICIPANT" ; Indicates a participant whose - ; participation is required - / "OPT-PARTICIPANT" ; Indicates a participant whose - ; participation is optional - / "NON-PARTICIPANT" ; Indicates a participant who - ; is copied for information - ; purposes only - / x-name ; Experimental role - / iana-token) ; Other IANA role - ; Default is REQ-PARTICIPANT - - Description: This parameter can be specified on properties with a - CAL-ADDRESS value type. The parameter specifies the participation - role for the calendar user specified by the property in the group - schedule calendar component. If not specified on a property that - allows this parameter, the default value is REQ-PARTICIPANT. - Applications MUST treat x-name and iana-token values they don't - recognize the same way as they would the REQ-PARTICIPANT value. - - Example: - - ATTENDEE;ROLE=CHAIR:mailto:mrbig@example.com - -3.2.17. RSVP Expectation - - Parameter Name: RSVP - - Purpose: To specify whether there is an expectation of a favor of a - reply from the calendar user specified by the property value. - - Format Definition: This property parameter is defined by the - following notation: - - rsvpparam = "RSVP" "=" ("TRUE" / "FALSE") - ; Default is FALSE - - Description: This parameter can be specified on properties with a - CAL-ADDRESS value type. The parameter identifies the expectation - of a reply from the calendar user specified by the property value. - This parameter is used by the "Organizer" to request a - participation status reply from an "Attendee" of a group-scheduled - event or to-do. If not specified on a property that allows this - parameter, the default value is FALSE. - - - - - -Desruisseaux Standards Track [Page 26] - -RFC 5545 iCalendar September 2009 - - - Example: - - ATTENDEE;RSVP=TRUE:mailto:jsmith@example.com - -3.2.18. Sent By - - Parameter Name: SENT-BY - - Purpose: To specify the calendar user that is acting on behalf of - the calendar user specified by the property. - - Format Definition: This property parameter is defined by the - following notation: - - sentbyparam = "SENT-BY" "=" DQUOTE cal-address DQUOTE - - Description: This parameter can be specified on properties with a - CAL-ADDRESS value type. The parameter specifies the calendar user - that is acting on behalf of the calendar user specified by the - property. The parameter value MUST be a mailto URI as defined in - [RFC2368]. The individual calendar address parameter values MUST - each be specified in a quoted-string. - - Example: - - ORGANIZER;SENT-BY="mailto:sray@example.com":mailto: - jsmith@example.com - -3.2.19. Time Zone Identifier - - Parameter Name: TZID - - Purpose: To specify the identifier for the time zone definition for - a time component in the property value. - - Format Definition: This property parameter is defined by the - following notation: - - tzidparam = "TZID" "=" [tzidprefix] paramtext - - tzidprefix = "/" - - Description: This parameter MUST be specified on the "DTSTART", - "DTEND", "DUE", "EXDATE", and "RDATE" properties when either a - DATE-TIME or TIME value type is specified and when the value is - neither a UTC or a "floating" time. Refer to the DATE-TIME or - TIME value type definition for a description of UTC and "floating - time" formats. This property parameter specifies a text value - - - -Desruisseaux Standards Track [Page 27] - -RFC 5545 iCalendar September 2009 - - - that uniquely identifies the "VTIMEZONE" calendar component to be - used when evaluating the time portion of the property. The value - of the "TZID" property parameter will be equal to the value of the - "TZID" property for the matching time zone definition. An - individual "VTIMEZONE" calendar component MUST be specified for - each unique "TZID" parameter value specified in the iCalendar - object. - - The parameter MUST be specified on properties with a DATE-TIME - value if the DATE-TIME is not either a UTC or a "floating" time. - Failure to include and follow VTIMEZONE definitions in iCalendar - objects may lead to inconsistent understanding of the local time - at any given location. - - The presence of the SOLIDUS character as a prefix, indicates that - this "TZID" represents a unique ID in a globally defined time zone - registry (when such registry is defined). - - Note: This document does not define a naming convention for - time zone identifiers. Implementers may want to use the naming - conventions defined in existing time zone specifications such - as the public-domain TZ database [TZDB]. The specification of - globally unique time zone identifiers is not addressed by this - document and is left for future study. - - The following are examples of this property parameter: - - DTSTART;TZID=America/New_York:19980119T020000 - - DTEND;TZID=America/New_York:19980119T030000 - - The "TZID" property parameter MUST NOT be applied to DATE - properties and DATE-TIME or TIME properties whose time values are - specified in UTC. - - The use of local time in a DATE-TIME or TIME value without the - "TZID" property parameter is to be interpreted as floating time, - regardless of the existence of "VTIMEZONE" calendar components in - the iCalendar object. - - For more information, see the sections on the value types DATE- - TIME and TIME. - - - - - - - - - -Desruisseaux Standards Track [Page 28] - -RFC 5545 iCalendar September 2009 - - -3.2.20. Value Data Types - - Parameter Name: VALUE - - Purpose: To explicitly specify the value type format for a property - value. - - Format Definition: This property parameter is defined by the - following notation: - - valuetypeparam = "VALUE" "=" valuetype - - valuetype = ("BINARY" - / "BOOLEAN" - / "CAL-ADDRESS" - / "DATE" - / "DATE-TIME" - / "DURATION" - / "FLOAT" - / "INTEGER" - / "PERIOD" - / "RECUR" - / "TEXT" - / "TIME" - / "URI" - / "UTC-OFFSET" - / x-name - ; Some experimental iCalendar value type. - / iana-token) - ; Some other IANA-registered iCalendar value type. - - Description: This parameter specifies the value type and format of - the property value. The property values MUST be of a single value - type. For example, a "RDATE" property cannot have a combination - of DATE-TIME and TIME value types. - - If the property's value is the default value type, then this - parameter need not be specified. However, if the property's - default value type is overridden by some other allowable value - type, then this parameter MUST be specified. - - Applications MUST preserve the value data for x-name and iana- - token values that they don't recognize without attempting to - interpret or parse the value data. - - - - - - - -Desruisseaux Standards Track [Page 29] - -RFC 5545 iCalendar September 2009 - - -3.3. Property Value Data Types - - The properties in an iCalendar object are strongly typed. The - definition of each property restricts the value to be one of the - value data types, or simply value types, defined in this section. - The value type for a property will either be specified implicitly as - the default value type or will be explicitly specified with the - "VALUE" parameter. If the value type of a property is one of the - alternate valid types, then it MUST be explicitly specified with the - "VALUE" parameter. - -3.3.1. Binary - - Value Name: BINARY - - Purpose: This value type is used to identify properties that contain - a character encoding of inline binary data. For example, an - inline attachment of a document might be included in an iCalendar - object. - - Format Definition: This value type is defined by the following - notation: - - binary = *(4b-char) [b-end] - ; A "BASE64" encoded character string, as defined by [RFC4648]. - - b-end = (2b-char "==") / (3b-char "=") - - b-char = ALPHA / DIGIT / "+" / "/" - - Description: Property values with this value type MUST also include - the inline encoding parameter sequence of ";ENCODING=BASE64". - That is, all inline binary data MUST first be character encoded - using the "BASE64" encoding method defined in [RFC2045]. No - additional content value encoding (i.e., BACKSLASH character - encoding, see Section 3.3.11) is defined for this value type. - - - - - - - - - - - - - - - -Desruisseaux Standards Track [Page 30] - -RFC 5545 iCalendar September 2009 - - - Example: The following is an example of a "BASE64" encoded binary - value data: - - ATTACH;FMTTYPE=image/vnd.microsoft.icon;ENCODING=BASE64;VALUE - =BINARY:AAABAAEAEBAQAAEABAAoAQAAFgAAACgAAAAQAAAAIAAAAAEABAAA - AAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAgIAAAICAgADAwMAA////AAAA - AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA - AAAAAAAAAAAAAAAAAAAAAAMwAAAAAAABNEMQAAAAAAAkQgAAAAAAJEREQgAA - ACECQ0QgEgAAQxQzM0E0AABERCRCREQAADRDJEJEQwAAAhA0QwEQAAAAAERE - AAAAAAAAREQAAAAAAAAkQgAAAAAAAAMgAAAAAAAAAAAAAAAAAAAAAAAAAAAA - AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA - AAAAAAAAAAAA - -3.3.2. Boolean - - Value Name: BOOLEAN - - Purpose: This value type is used to identify properties that contain - either a "TRUE" or "FALSE" Boolean value. - - Format Definition: This value type is defined by the following - notation: - - boolean = "TRUE" / "FALSE" - - Description: These values are case-insensitive text. No additional - content value encoding (i.e., BACKSLASH character encoding, see - Section 3.3.11) is defined for this value type. - - Example: The following is an example of a hypothetical property that - has a BOOLEAN value type: - - TRUE - -3.3.3. Calendar User Address - - Value Name: CAL-ADDRESS - - Purpose: This value type is used to identify properties that contain - a calendar user address. - - Format Definition: This value type is defined by the following - notation: - - cal-address = uri - - Description: The value is a URI as defined by [RFC3986] or any other - IANA-registered form for a URI. When used to address an Internet - - - -Desruisseaux Standards Track [Page 31] - -RFC 5545 iCalendar September 2009 - - - email transport address for a calendar user, the value MUST be a - mailto URI, as defined by [RFC2368]. No additional content value - encoding (i.e., BACKSLASH character encoding, see Section 3.3.11) - is defined for this value type. - - Example: - - mailto:jane_doe@example.com - -3.3.4. Date - - Value Name: DATE - - Purpose: This value type is used to identify values that contain a - calendar date. - - Format Definition: This value type is defined by the following - notation: - - date = date-value - - date-value = date-fullyear date-month date-mday - date-fullyear = 4DIGIT - date-month = 2DIGIT ;01-12 - date-mday = 2DIGIT ;01-28, 01-29, 01-30, 01-31 - ;based on month/year - - Description: If the property permits, multiple "date" values are - specified as a COMMA-separated list of values. The format for the - value type is based on the [ISO.8601.2004] complete - representation, basic format for a calendar date. The textual - format specifies a four-digit year, two-digit month, and two-digit - day of the month. There are no separator characters between the - year, month, and day component text. - - No additional content value encoding (i.e., BACKSLASH character - encoding, see Section 3.3.11) is defined for this value type. - - Example: The following represents July 14, 1997: - - 19970714 - -3.3.5. Date-Time - - Value Name: DATE-TIME - - Purpose: This value type is used to identify values that specify a - precise calendar date and time of day. - - - -Desruisseaux Standards Track [Page 32] - -RFC 5545 iCalendar September 2009 - - - Format Definition: This value type is defined by the following - notation: - - date-time = date "T" time ;As specified in the DATE and TIME - ;value definitions - - Description: If the property permits, multiple "DATE-TIME" values - are specified as a COMMA-separated list of values. No additional - content value encoding (i.e., BACKSLASH character encoding, see - Section 3.3.11) is defined for this value type. - - The "DATE-TIME" value type is used to identify values that contain - a precise calendar date and time of day. The format is based on - the [ISO.8601.2004] complete representation, basic format for a - calendar date and time of day. The text format is a concatenation - of the "date", followed by the LATIN CAPITAL LETTER T character, - the time designator, followed by the "time" format. - - The "DATE-TIME" value type expresses time values in three forms: - - The form of date and time with UTC offset MUST NOT be used. For - example, the following is not valid for a DATE-TIME value: - - 19980119T230000-0800 ;Invalid time format - - FORM #1: DATE WITH LOCAL TIME - - The date with local time form is simply a DATE-TIME value that - does not contain the UTC designator nor does it reference a time - zone. For example, the following represents January 18, 1998, at - 11 PM: - - 19980118T230000 - - DATE-TIME values of this type are said to be "floating" and are - not bound to any time zone in particular. They are used to - represent the same hour, minute, and second value regardless of - which time zone is currently being observed. For example, an - event can be defined that indicates that an individual will be - busy from 11:00 AM to 1:00 PM every day, no matter which time zone - the person is in. In these cases, a local time can be specified. - The recipient of an iCalendar object with a property value - consisting of a local time, without any relative time zone - information, SHOULD interpret the value as being fixed to whatever - time zone the "ATTENDEE" is in at any given moment. This means - that two "Attendees", in different time zones, receiving the same - event definition as a floating time, may be participating in the - - - - -Desruisseaux Standards Track [Page 33] - -RFC 5545 iCalendar September 2009 - - - event at different actual times. Floating time SHOULD only be - used where that is the reasonable behavior. - - In most cases, a fixed time is desired. To properly communicate a - fixed time in a property value, either UTC time or local time with - time zone reference MUST be specified. - - The use of local time in a DATE-TIME value without the "TZID" - property parameter is to be interpreted as floating time, - regardless of the existence of "VTIMEZONE" calendar components in - the iCalendar object. - - FORM #2: DATE WITH UTC TIME - - The date with UTC time, or absolute time, is identified by a LATIN - CAPITAL LETTER Z suffix character, the UTC designator, appended to - the time value. For example, the following represents January 19, - 1998, at 0700 UTC: - - 19980119T070000Z - - The "TZID" property parameter MUST NOT be applied to DATE-TIME - properties whose time values are specified in UTC. - - FORM #3: DATE WITH LOCAL TIME AND TIME ZONE REFERENCE - - The date and local time with reference to time zone information is - identified by the use the "TZID" property parameter to reference - the appropriate time zone definition. "TZID" is discussed in - detail in Section 3.2.19. For example, the following represents - 2:00 A.M. in New York on January 19, 1998: - - TZID=America/New_York:19980119T020000 - - If, based on the definition of the referenced time zone, the local - time described occurs more than once (when changing from daylight - to standard time), the DATE-TIME value refers to the first - occurrence of the referenced time. Thus, TZID=America/ - New_York:20071104T013000 indicates November 4, 2007 at 1:30 A.M. - EDT (UTC-04:00). If the local time described does not occur (when - changing from standard to daylight time), the DATE-TIME value is - interpreted using the UTC offset before the gap in local times. - Thus, TZID=America/New_York:20070311T023000 indicates March 11, - 2007 at 3:30 A.M. EDT (UTC-04:00), one hour after 1:30 A.M. EST - (UTC-05:00). - - - - - - -Desruisseaux Standards Track [Page 34] - -RFC 5545 iCalendar September 2009 - - - A time value MUST only specify the second 60 when specifying a - positive leap second. For example: - - 19970630T235960Z - - Implementations that do not support leap seconds SHOULD interpret - the second 60 as equivalent to the second 59. - - Example: The following represents July 14, 1997, at 1:30 PM in New - York City in each of the three time formats, using the "DTSTART" - property. - - DTSTART:19970714T133000 ; Local time - DTSTART:19970714T173000Z ; UTC time - DTSTART;TZID=America/New_York:19970714T133000 - ; Local time and time - ; zone reference - -3.3.6. Duration - - Value Name: DURATION - - Purpose: This value type is used to identify properties that contain - a duration of time. - - Format Definition: This value type is defined by the following - notation: - - dur-value = (["+"] / "-") "P" (dur-date / dur-time / dur-week) - - dur-date = dur-day [dur-time] - dur-time = "T" (dur-hour / dur-minute / dur-second) - dur-week = 1*DIGIT "W" - dur-hour = 1*DIGIT "H" [dur-minute] - dur-minute = 1*DIGIT "M" [dur-second] - dur-second = 1*DIGIT "S" - dur-day = 1*DIGIT "D" - - Description: If the property permits, multiple "duration" values are - specified by a COMMA-separated list of values. The format is - based on the [ISO.8601.2004] complete representation basic format - with designators for the duration of time. The format can - represent nominal durations (weeks and days) and accurate - durations (hours, minutes, and seconds). Note that unlike - [ISO.8601.2004], this value type doesn't support the "Y" and "M" - designators to specify durations in terms of years and months. - - - - - -Desruisseaux Standards Track [Page 35] - -RFC 5545 iCalendar September 2009 - - - The duration of a week or a day depends on its position in the - calendar. In the case of discontinuities in the time scale, such - as the change from standard time to daylight time and back, the - computation of the exact duration requires the subtraction or - addition of the change of duration of the discontinuity. Leap - seconds MUST NOT be considered when computing an exact duration. - When computing an exact duration, the greatest order time - components MUST be added first, that is, the number of days MUST - be added first, followed by the number of hours, number of - minutes, and number of seconds. - - Negative durations are typically used to schedule an alarm to - trigger before an associated time (see Section 3.8.6.3). - - No additional content value encoding (i.e., BACKSLASH character - encoding, see Section 3.3.11) are defined for this value type. - - Example: A duration of 15 days, 5 hours, and 20 seconds would be: - - P15DT5H0M20S - - A duration of 7 weeks would be: - - P7W - -3.3.7. Float - - Value Name: FLOAT - - Purpose: This value type is used to identify properties that contain - a real-number value. - - Format Definition: This value type is defined by the following - notation: - - float = (["+"] / "-") 1*DIGIT ["." 1*DIGIT] - - Description: If the property permits, multiple "float" values are - specified by a COMMA-separated list of values. - - No additional content value encoding (i.e., BACKSLASH character - encoding, see Section 3.3.11) is defined for this value type. - - Example: - - 1000000.0000001 - 1.333 - -3.14 - - - -Desruisseaux Standards Track [Page 36] - -RFC 5545 iCalendar September 2009 - - -3.3.8. Integer - - Value Name: INTEGER - - Purpose: This value type is used to identify properties that contain - a signed integer value. - - Format Definition: This value type is defined by the following - notation: - - integer = (["+"] / "-") 1*DIGIT - - Description: If the property permits, multiple "integer" values are - specified by a COMMA-separated list of values. The valid range - for "integer" is -2147483648 to 2147483647. If the sign is not - specified, then the value is assumed to be positive. - - No additional content value encoding (i.e., BACKSLASH character - encoding, see Section 3.3.11) is defined for this value type. - - Example: - - 1234567890 - -1234567890 - +1234567890 - 432109876 - -3.3.9. Period of Time - - Value Name: PERIOD - - Purpose: This value type is used to identify values that contain a - precise period of time. - - Format Definition: This value type is defined by the following - notation: - - period = period-explicit / period-start - - period-explicit = date-time "/" date-time - ; [ISO.8601.2004] complete representation basic format for a - ; period of time consisting of a start and end. The start MUST - ; be before the end. - - period-start = date-time "/" dur-value - ; [ISO.8601.2004] complete representation basic format for a - ; period of time consisting of a start and positive duration - ; of time. - - - -Desruisseaux Standards Track [Page 37] - -RFC 5545 iCalendar September 2009 - - - Description: If the property permits, multiple "period" values are - specified by a COMMA-separated list of values. There are two - forms of a period of time. First, a period of time is identified - by its start and its end. This format is based on the - [ISO.8601.2004] complete representation, basic format for "DATE- - TIME" start of the period, followed by a SOLIDUS character - followed by the "DATE-TIME" of the end of the period. The start - of the period MUST be before the end of the period. Second, a - period of time can also be defined by a start and a positive - duration of time. The format is based on the [ISO.8601.2004] - complete representation, basic format for the "DATE-TIME" start of - the period, followed by a SOLIDUS character, followed by the - [ISO.8601.2004] basic format for "DURATION" of the period. - - Example: The period starting at 18:00:00 UTC, on January 1, 1997 and - ending at 07:00:00 UTC on January 2, 1997 would be: - - 19970101T180000Z/19970102T070000Z - - The period start at 18:00:00 on January 1, 1997 and lasting 5 - hours and 30 minutes would be: - - 19970101T180000Z/PT5H30M - - No additional content value encoding (i.e., BACKSLASH character - encoding, see Section 3.3.11) is defined for this value type. - -3.3.10. Recurrence Rule - - Value Name: RECUR - - Purpose: This value type is used to identify properties that contain - a recurrence rule specification. - - Format Definition: This value type is defined by the following - notation: - - recur = recur-rule-part *( ";" recur-rule-part ) - ; - ; The rule parts are not ordered in any - ; particular sequence. - ; - ; The FREQ rule part is REQUIRED, - ; but MUST NOT occur more than once. - ; - ; The UNTIL or COUNT rule parts are OPTIONAL, - ; but they MUST NOT occur in the same 'recur'. - ; - - - -Desruisseaux Standards Track [Page 38] - -RFC 5545 iCalendar September 2009 - - - ; The other rule parts are OPTIONAL, - ; but MUST NOT occur more than once. - - recur-rule-part = ( "FREQ" "=" freq ) - / ( "UNTIL" "=" enddate ) - / ( "COUNT" "=" 1*DIGIT ) - / ( "INTERVAL" "=" 1*DIGIT ) - / ( "BYSECOND" "=" byseclist ) - / ( "BYMINUTE" "=" byminlist ) - / ( "BYHOUR" "=" byhrlist ) - / ( "BYDAY" "=" bywdaylist ) - / ( "BYMONTHDAY" "=" bymodaylist ) - / ( "BYYEARDAY" "=" byyrdaylist ) - / ( "BYWEEKNO" "=" bywknolist ) - / ( "BYMONTH" "=" bymolist ) - / ( "BYSETPOS" "=" bysplist ) - / ( "WKST" "=" weekday ) - - freq = "SECONDLY" / "MINUTELY" / "HOURLY" / "DAILY" - / "WEEKLY" / "MONTHLY" / "YEARLY" - - enddate = date / date-time - - byseclist = ( seconds *("," seconds) ) - - seconds = 1*2DIGIT ;0 to 60 - - byminlist = ( minutes *("," minutes) ) - - minutes = 1*2DIGIT ;0 to 59 - - byhrlist = ( hour *("," hour) ) - - hour = 1*2DIGIT ;0 to 23 - - bywdaylist = ( weekdaynum *("," weekdaynum) ) - - weekdaynum = [[plus / minus] ordwk] weekday - - plus = "+" - - minus = "-" - - ordwk = 1*2DIGIT ;1 to 53 - - weekday = "SU" / "MO" / "TU" / "WE" / "TH" / "FR" / "SA" - ;Corresponding to SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, - ;FRIDAY, and SATURDAY days of the week. - - - -Desruisseaux Standards Track [Page 39] - -RFC 5545 iCalendar September 2009 - - - bymodaylist = ( monthdaynum *("," monthdaynum) ) - - monthdaynum = [plus / minus] ordmoday - - ordmoday = 1*2DIGIT ;1 to 31 - - byyrdaylist = ( yeardaynum *("," yeardaynum) ) - - yeardaynum = [plus / minus] ordyrday - - ordyrday = 1*3DIGIT ;1 to 366 - - bywknolist = ( weeknum *("," weeknum) ) - - weeknum = [plus / minus] ordwk - - bymolist = ( monthnum *("," monthnum) ) - - monthnum = 1*2DIGIT ;1 to 12 - - bysplist = ( setposday *("," setposday) ) - - setposday = yeardaynum - - Description: This value type is a structured value consisting of a - list of one or more recurrence grammar parts. Each rule part is - defined by a NAME=VALUE pair. The rule parts are separated from - each other by the SEMICOLON character. The rule parts are not - ordered in any particular sequence. Individual rule parts MUST - only be specified once. Compliant applications MUST accept rule - parts ordered in any sequence, but to ensure backward - compatibility with applications that pre-date this revision of - iCalendar the FREQ rule part MUST be the first rule part specified - in a RECUR value. - - The FREQ rule part identifies the type of recurrence rule. This - rule part MUST be specified in the recurrence rule. Valid values - include SECONDLY, to specify repeating events based on an interval - of a second or more; MINUTELY, to specify repeating events based - on an interval of a minute or more; HOURLY, to specify repeating - events based on an interval of an hour or more; DAILY, to specify - repeating events based on an interval of a day or more; WEEKLY, to - specify repeating events based on an interval of a week or more; - MONTHLY, to specify repeating events based on an interval of a - month or more; and YEARLY, to specify repeating events based on an - interval of a year or more. - - - - - -Desruisseaux Standards Track [Page 40] - -RFC 5545 iCalendar September 2009 - - - The INTERVAL rule part contains a positive integer representing at - which intervals the recurrence rule repeats. The default value is - "1", meaning every second for a SECONDLY rule, every minute for a - MINUTELY rule, every hour for an HOURLY rule, every day for a - DAILY rule, every week for a WEEKLY rule, every month for a - MONTHLY rule, and every year for a YEARLY rule. For example, - within a DAILY rule, a value of "8" means every eight days. - - The UNTIL rule part defines a DATE or DATE-TIME value that bounds - the recurrence rule in an inclusive manner. If the value - specified by UNTIL is synchronized with the specified recurrence, - this DATE or DATE-TIME becomes the last instance of the - recurrence. The value of the UNTIL rule part MUST have the same - value type as the "DTSTART" property. Furthermore, if the - "DTSTART" property is specified as a date with local time, then - the UNTIL rule part MUST also be specified as a date with local - time. If the "DTSTART" property is specified as a date with UTC - time or a date with local time and time zone reference, then the - UNTIL rule part MUST be specified as a date with UTC time. In the - case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL - rule part MUST always be specified as a date with UTC time. If - specified as a DATE-TIME value, then it MUST be specified in a UTC - time format. If not present, and the COUNT rule part is also not - present, the "RRULE" is considered to repeat forever. - - The COUNT rule part defines the number of occurrences at which to - range-bound the recurrence. The "DTSTART" property value always - counts as the first occurrence. - - The BYSECOND rule part specifies a COMMA-separated list of seconds - within a minute. Valid values are 0 to 60. The BYMINUTE rule - part specifies a COMMA-separated list of minutes within an hour. - Valid values are 0 to 59. The BYHOUR rule part specifies a COMMA- - separated list of hours of the day. Valid values are 0 to 23. - The BYSECOND, BYMINUTE and BYHOUR rule parts MUST NOT be specified - when the associated "DTSTART" property has a DATE value type. - These rule parts MUST be ignored in RECUR value that violate the - above requirement (e.g., generated by applications that pre-date - this revision of iCalendar). - - The BYDAY rule part specifies a COMMA-separated list of days of - the week; SU indicates Sunday; MO indicates Monday; TU indicates - Tuesday; WE indicates Wednesday; TH indicates Thursday; FR - indicates Friday; and SA indicates Saturday. - - Each BYDAY value can also be preceded by a positive (+n) or - negative (-n) integer. If present, this indicates the nth - occurrence of a specific day within the MONTHLY or YEARLY "RRULE". - - - -Desruisseaux Standards Track [Page 41] - -RFC 5545 iCalendar September 2009 - - - For example, within a MONTHLY rule, +1MO (or simply 1MO) - represents the first Monday within the month, whereas -1MO - represents the last Monday of the month. The numeric value in a - BYDAY rule part with the FREQ rule part set to YEARLY corresponds - to an offset within the month when the BYMONTH rule part is - present, and corresponds to an offset within the year when the - BYWEEKNO or BYMONTH rule parts are present. If an integer - modifier is not present, it means all days of this type within the - specified frequency. For example, within a MONTHLY rule, MO - represents all Mondays within the month. The BYDAY rule part MUST - NOT be specified with a numeric value when the FREQ rule part is - not set to MONTHLY or YEARLY. Furthermore, the BYDAY rule part - MUST NOT be specified with a numeric value with the FREQ rule part - set to YEARLY when the BYWEEKNO rule part is specified. - - The BYMONTHDAY rule part specifies a COMMA-separated list of days - of the month. Valid values are 1 to 31 or -31 to -1. For - example, -10 represents the tenth to the last day of the month. - The BYMONTHDAY rule part MUST NOT be specified when the FREQ rule - part is set to WEEKLY. - - The BYYEARDAY rule part specifies a COMMA-separated list of days - of the year. Valid values are 1 to 366 or -366 to -1. For - example, -1 represents the last day of the year (December 31st) - and -306 represents the 306th to the last day of the year (March - 1st). The BYYEARDAY rule part MUST NOT be specified when the FREQ - rule part is set to DAILY, WEEKLY, or MONTHLY. - - The BYWEEKNO rule part specifies a COMMA-separated list of - ordinals specifying weeks of the year. Valid values are 1 to 53 - or -53 to -1. This corresponds to weeks according to week - numbering as defined in [ISO.8601.2004]. A week is defined as a - seven day period, starting on the day of the week defined to be - the week start (see WKST). Week number one of the calendar year - is the first week that contains at least four (4) days in that - calendar year. This rule part MUST NOT be used when the FREQ rule - part is set to anything other than YEARLY. For example, 3 - represents the third week of the year. - - Note: Assuming a Monday week start, week 53 can only occur when - Thursday is January 1 or if it is a leap year and Wednesday is - January 1. - - The BYMONTH rule part specifies a COMMA-separated list of months - of the year. Valid values are 1 to 12. - - The WKST rule part specifies the day on which the workweek starts. - Valid values are MO, TU, WE, TH, FR, SA, and SU. This is - - - -Desruisseaux Standards Track [Page 42] - -RFC 5545 iCalendar September 2009 - - - significant when a WEEKLY "RRULE" has an interval greater than 1, - and a BYDAY rule part is specified. This is also significant when - in a YEARLY "RRULE" when a BYWEEKNO rule part is specified. The - default value is MO. - - The BYSETPOS rule part specifies a COMMA-separated list of values - that corresponds to the nth occurrence within the set of - recurrence instances specified by the rule. BYSETPOS operates on - a set of recurrence instances in one interval of the recurrence - rule. For example, in a WEEKLY rule, the interval would be one - week A set of recurrence instances starts at the beginning of the - interval defined by the FREQ rule part. Valid values are 1 to 366 - or -366 to -1. It MUST only be used in conjunction with another - BYxxx rule part. For example "the last work day of the month" - could be represented as: - - FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1 - - Each BYSETPOS value can include a positive (+n) or negative (-n) - integer. If present, this indicates the nth occurrence of the - specific occurrence within the set of occurrences specified by the - rule. - - Recurrence rules may generate recurrence instances with an invalid - date (e.g., February 30) or nonexistent local time (e.g., 1:30 AM - on a day where the local time is moved forward by an hour at 1:00 - AM). Such recurrence instances MUST be ignored and MUST NOT be - counted as part of the recurrence set. - - Information, not contained in the rule, necessary to determine the - various recurrence instance start time and dates are derived from - the Start Time ("DTSTART") component attribute. For example, - "FREQ=YEARLY;BYMONTH=1" doesn't specify a specific day within the - month or a time. This information would be the same as what is - specified for "DTSTART". - - BYxxx rule parts modify the recurrence in some manner. BYxxx rule - parts for a period of time that is the same or greater than the - frequency generally reduce or limit the number of occurrences of - the recurrence generated. For example, "FREQ=DAILY;BYMONTH=1" - reduces the number of recurrence instances from all days (if - BYMONTH rule part is not present) to all days in January. BYxxx - rule parts for a period of time less than the frequency generally - increase or expand the number of occurrences of the recurrence. - For example, "FREQ=YEARLY;BYMONTH=1,2" increases the number of - days within the yearly recurrence set from 1 (if BYMONTH rule part - is not present) to 2. - - - - -Desruisseaux Standards Track [Page 43] - -RFC 5545 iCalendar September 2009 - - - If multiple BYxxx rule parts are specified, then after evaluating - the specified FREQ and INTERVAL rule parts, the BYxxx rule parts - are applied to the current set of evaluated occurrences in the - following order: BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY, BYDAY, - BYHOUR, BYMINUTE, BYSECOND and BYSETPOS; then COUNT and UNTIL are - evaluated. - - The table below summarizes the dependency of BYxxx rule part - expand or limit behavior on the FREQ rule part value. - - The term "N/A" means that the corresponding BYxxx rule part MUST - NOT be used with the corresponding FREQ value. - - BYDAY has some special behavior depending on the FREQ value and - this is described in separate notes below the table. - - +----------+--------+--------+-------+-------+------+-------+------+ - | |SECONDLY|MINUTELY|HOURLY |DAILY |WEEKLY|MONTHLY|YEARLY| - +----------+--------+--------+-------+-------+------+-------+------+ - |BYMONTH |Limit |Limit |Limit |Limit |Limit |Limit |Expand| - +----------+--------+--------+-------+-------+------+-------+------+ - |BYWEEKNO |N/A |N/A |N/A |N/A |N/A |N/A |Expand| - +----------+--------+--------+-------+-------+------+-------+------+ - |BYYEARDAY |Limit |Limit |Limit |N/A |N/A |N/A |Expand| - +----------+--------+--------+-------+-------+------+-------+------+ - |BYMONTHDAY|Limit |Limit |Limit |Limit |N/A |Expand |Expand| - +----------+--------+--------+-------+-------+------+-------+------+ - |BYDAY |Limit |Limit |Limit |Limit |Expand|Note 1 |Note 2| - +----------+--------+--------+-------+-------+------+-------+------+ - |BYHOUR |Limit |Limit |Limit |Expand |Expand|Expand |Expand| - +----------+--------+--------+-------+-------+------+-------+------+ - |BYMINUTE |Limit |Limit |Expand |Expand |Expand|Expand |Expand| - +----------+--------+--------+-------+-------+------+-------+------+ - |BYSECOND |Limit |Expand |Expand |Expand |Expand|Expand |Expand| - +----------+--------+--------+-------+-------+------+-------+------+ - |BYSETPOS |Limit |Limit |Limit |Limit |Limit |Limit |Limit | - +----------+--------+--------+-------+-------+------+-------+------+ - - Note 1: Limit if BYMONTHDAY is present; otherwise, special expand - for MONTHLY. - - Note 2: Limit if BYYEARDAY or BYMONTHDAY is present; otherwise, - special expand for WEEKLY if BYWEEKNO present; otherwise, - special expand for MONTHLY if BYMONTH present; otherwise, - special expand for YEARLY. - - - - - - -Desruisseaux Standards Track [Page 44] - -RFC 5545 iCalendar September 2009 - - - Here is an example of evaluating multiple BYxxx rule parts. - - DTSTART;TZID=America/New_York:19970105T083000 - RRULE:FREQ=YEARLY;INTERVAL=2;BYMONTH=1;BYDAY=SU;BYHOUR=8,9; - BYMINUTE=30 - - First, the "INTERVAL=2" would be applied to "FREQ=YEARLY" to - arrive at "every other year". Then, "BYMONTH=1" would be applied - to arrive at "every January, every other year". Then, "BYDAY=SU" - would be applied to arrive at "every Sunday in January, every - other year". Then, "BYHOUR=8,9" would be applied to arrive at - "every Sunday in January at 8 AM and 9 AM, every other year". - Then, "BYMINUTE=30" would be applied to arrive at "every Sunday in - January at 8:30 AM and 9:30 AM, every other year". Then, lacking - information from "RRULE", the second is derived from "DTSTART", to - end up in "every Sunday in January at 8:30:00 AM and 9:30:00 AM, - every other year". Similarly, if the BYMINUTE, BYHOUR, BYDAY, - BYMONTHDAY, or BYMONTH rule part were missing, the appropriate - minute, hour, day, or month would have been retrieved from the - "DTSTART" property. - - If the computed local start time of a recurrence instance does not - exist, or occurs more than once, for the specified time zone, the - time of the recurrence instance is interpreted in the same manner - as an explicit DATE-TIME value describing that date and time, as - specified in Section 3.3.5. - - No additional content value encoding (i.e., BACKSLASH character - encoding, see Section 3.3.11) is defined for this value type. - - Example: The following is a rule that specifies 10 occurrences that - occur every other day: - - FREQ=DAILY;COUNT=10;INTERVAL=2 - - There are other examples specified in Section 3.8.5.3. - -3.3.11. Text - - Value Name: TEXT - - Purpose: This value type is used to identify values that contain - human-readable text. - - Format Definition: This value type is defined by the following - notation: - - - - - -Desruisseaux Standards Track [Page 45] - -RFC 5545 iCalendar September 2009 - - - text = *(TSAFE-CHAR / ":" / DQUOTE / ESCAPED-CHAR) - ; Folded according to description above - - ESCAPED-CHAR = ("\\" / "\;" / "\," / "\N" / "\n") - ; \\ encodes \, \N or \n encodes newline - ; \; encodes ;, \, encodes , - - TSAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-5B / - %x5D-7E / NON-US-ASCII - ; Any character except CONTROLs not needed by the current - ; character set, DQUOTE, ";", ":", "\", "," - - Description: If the property permits, multiple TEXT values are - specified by a COMMA-separated list of values. - - The language in which the text is represented can be controlled by - the "LANGUAGE" property parameter. - - An intentional formatted text line break MUST only be included in - a "TEXT" property value by representing the line break with the - character sequence of BACKSLASH, followed by a LATIN SMALL LETTER - N or a LATIN CAPITAL LETTER N, that is "\n" or "\N". - - The "TEXT" property values may also contain special characters - that are used to signify delimiters, such as a COMMA character for - lists of values or a SEMICOLON character for structured values. - In order to support the inclusion of these special characters in - "TEXT" property values, they MUST be escaped with a BACKSLASH - character. A BACKSLASH character in a "TEXT" property value MUST - be escaped with another BACKSLASH character. A COMMA character in - a "TEXT" property value MUST be escaped with a BACKSLASH - character. A SEMICOLON character in a "TEXT" property value MUST - be escaped with a BACKSLASH character. However, a COLON character - in a "TEXT" property value SHALL NOT be escaped with a BACKSLASH - character. - - Example: A multiple line value of: - - Project XYZ Final Review - Conference Room - 3B - Come Prepared. - - would be represented as: - - Project XYZ Final Review\nConference Room - 3B\nCome Prepared. - - - - - - -Desruisseaux Standards Track [Page 46] - -RFC 5545 iCalendar September 2009 - - -3.3.12. Time - - Value Name: TIME - - Purpose: This value type is used to identify values that contain a - time of day. - - Format Definition: This value type is defined by the following - notation: - - time = time-hour time-minute time-second [time-utc] - - time-hour = 2DIGIT ;00-23 - time-minute = 2DIGIT ;00-59 - time-second = 2DIGIT ;00-60 - ;The "60" value is used to account for positive "leap" seconds. - - time-utc = "Z" - - Description: If the property permits, multiple "time" values are - specified by a COMMA-separated list of values. No additional - content value encoding (i.e., BACKSLASH character encoding, see - Section 3.3.11) is defined for this value type. - - The "TIME" value type is used to identify values that contain a - time of day. The format is based on the [ISO.8601.2004] complete - representation, basic format for a time of day. The text format - consists of a two-digit, 24-hour of the day (i.e., values 00-23), - two-digit minute in the hour (i.e., values 00-59), and two-digit - seconds in the minute (i.e., values 00-60). The seconds value of - 60 MUST only be used to account for positive "leap" seconds. - Fractions of a second are not supported by this format. - - In parallel to the "DATE-TIME" definition above, the "TIME" value - type expresses time values in three forms: - - The form of time with UTC offset MUST NOT be used. For example, - the following is not valid for a time value: - - 230000-0800 ;Invalid time format - - FORM #1 LOCAL TIME - - The local time form is simply a time value that does not contain - the UTC designator nor does it reference a time zone. For - example, 11:00 PM: - - 230000 - - - -Desruisseaux Standards Track [Page 47] - -RFC 5545 iCalendar September 2009 - - - Time values of this type are said to be "floating" and are not - bound to any time zone in particular. They are used to represent - the same hour, minute, and second value regardless of which time - zone is currently being observed. For example, an event can be - defined that indicates that an individual will be busy from 11:00 - AM to 1:00 PM every day, no matter which time zone the person is - in. In these cases, a local time can be specified. The recipient - of an iCalendar object with a property value consisting of a local - time, without any relative time zone information, SHOULD interpret - the value as being fixed to whatever time zone the "ATTENDEE" is - in at any given moment. This means that two "Attendees", may - participate in the same event at different UTC times; floating - time SHOULD only be used where that is reasonable behavior. - - In most cases, a fixed time is desired. To properly communicate a - fixed time in a property value, either UTC time or local time with - time zone reference MUST be specified. - - The use of local time in a TIME value without the "TZID" property - parameter is to be interpreted as floating time, regardless of the - existence of "VTIMEZONE" calendar components in the iCalendar - object. - - FORM #2: UTC TIME - - UTC time, or absolute time, is identified by a LATIN CAPITAL - LETTER Z suffix character, the UTC designator, appended to the - time value. For example, the following represents 07:00 AM UTC: - - 070000Z - - The "TZID" property parameter MUST NOT be applied to TIME - properties whose time values are specified in UTC. - - FORM #3: LOCAL TIME AND TIME ZONE REFERENCE - - The local time with reference to time zone information form is - identified by the use the "TZID" property parameter to reference - the appropriate time zone definition. "TZID" is discussed in - detail in Section 3.2.19. - - Example: The following represents 8:30 AM in New York in winter, - five hours behind UTC, in each of the three formats: - - 083000 - 133000Z - TZID=America/New_York:083000 - - - - -Desruisseaux Standards Track [Page 48] - -RFC 5545 iCalendar September 2009 - - -3.3.13. URI - - Value Name: URI - - Purpose: This value type is used to identify values that contain a - uniform resource identifier (URI) type of reference to the - property value. - - Format Definition: This value type is defined by the following - notation: - - uri = - - Description: This value type might be used to reference binary - information, for values that are large, or otherwise undesirable - to include directly in the iCalendar object. - - Property values with this value type MUST follow the generic URI - syntax defined in [RFC3986]. - - When a property parameter value is a URI value type, the URI MUST - be specified as a quoted-string value. - - No additional content value encoding (i.e., BACKSLASH character - encoding, see Section 3.3.11) is defined for this value type. - - Example: The following is a URI for a network file: - - http://example.com/my-report.txt - -3.3.14. UTC Offset - - Value Name: UTC-OFFSET - - Purpose: This value type is used to identify properties that contain - an offset from UTC to local time. - - Format Definition: This value type is defined by the following - notation: - - utc-offset = time-numzone - - time-numzone = ("+" / "-") time-hour time-minute [time-second] - - Description: The PLUS SIGN character MUST be specified for positive - UTC offsets (i.e., ahead of UTC). The HYPHEN-MINUS character MUST - be specified for negative UTC offsets (i.e., behind of UTC). The - - - - -Desruisseaux Standards Track [Page 49] - -RFC 5545 iCalendar September 2009 - - - value of "-0000" and "-000000" are not allowed. The time-second, - if present, MUST NOT be 60; if absent, it defaults to zero. - - No additional content value encoding (i.e., BACKSLASH character - encoding, see Section 3.3.11) is defined for this value type. - - Example: The following UTC offsets are given for standard time for - New York (five hours behind UTC) and Geneva (one hour ahead of - UTC): - - -0500 - - +0100 - -3.4. iCalendar Object - - The Calendaring and Scheduling Core Object is a collection of - calendaring and scheduling information. Typically, this information - will consist of an iCalendar stream with a single iCalendar object. - However, multiple iCalendar objects can be sequentially grouped - together in an iCalendar stream. The first line and last line of the - iCalendar object MUST contain a pair of iCalendar object delimiter - strings. The syntax for an iCalendar stream is as follows: - - icalstream = 1*icalobject - - icalobject = "BEGIN" ":" "VCALENDAR" CRLF - icalbody - "END" ":" "VCALENDAR" CRLF - - The following is a simple example of an iCalendar object: - - BEGIN:VCALENDAR - VERSION:2.0 - PRODID:-//hacksw/handcal//NONSGML v1.0//EN - BEGIN:VEVENT - UID:19970610T172345Z-AF23B2@example.com - DTSTAMP:19970610T172345Z - DTSTART:19970714T170000Z - DTEND:19970715T040000Z - SUMMARY:Bastille Day Party - END:VEVENT - END:VCALENDAR - - - - - - - - -Desruisseaux Standards Track [Page 50] - -RFC 5545 iCalendar September 2009 - - -3.5. Property - - A property is the definition of an individual attribute describing a - calendar object or a calendar component. A property takes the form - defined by the "contentline" notation defined in Section 3.1. - - The following is an example of a property: - - DTSTART:19960415T133000Z - - This memo imposes no ordering of properties within an iCalendar - object. - - Property names, parameter names, and enumerated parameter values are - case-insensitive. For example, the property name "DUE" is the same - as "due" and "Due", DTSTART;TZID=America/New_York:19980714T120000 is - the same as DtStart;TzID=America/New_York:19980714T120000. - -3.6. Calendar Components - - The body of the iCalendar object consists of a sequence of calendar - properties and one or more calendar components. The calendar - properties are attributes that apply to the calendar object as a - whole. The calendar components are collections of properties that - express a particular calendar semantic. For example, the calendar - component can specify an event, a to-do, a journal entry, time zone - information, free/busy time information, or an alarm. - - The body of the iCalendar object is defined by the following - notation: - - icalbody = calprops component - - calprops = *( - ; - ; The following are REQUIRED, - ; but MUST NOT occur more than once. - ; - prodid / version / - ; - ; The following are OPTIONAL, - ; but MUST NOT occur more than once. - ; - calscale / method / - ; - ; The following are OPTIONAL, - ; and MAY occur more than once. - ; - - - -Desruisseaux Standards Track [Page 51] - -RFC 5545 iCalendar September 2009 - - - x-prop / iana-prop - ; - ) - - component = 1*(eventc / todoc / journalc / freebusyc / - timezonec / iana-comp / x-comp) - - iana-comp = "BEGIN" ":" iana-token CRLF - 1*contentline - "END" ":" iana-token CRLF - - x-comp = "BEGIN" ":" x-name CRLF - 1*contentline - "END" ":" x-name CRLF - - An iCalendar object MUST include the "PRODID" and "VERSION" calendar - properties. In addition, it MUST include at least one calendar - component. Special forms of iCalendar objects are possible to - publish just busy time (i.e., only a "VFREEBUSY" calendar component) - or time zone (i.e., only a "VTIMEZONE" calendar component) - information. In addition, a complex iCalendar object that is used to - capture a complete snapshot of the contents of a calendar is possible - (e.g., composite of many different calendar components). More - commonly, an iCalendar object will consist of just a single "VEVENT", - "VTODO", or "VJOURNAL" calendar component. Applications MUST ignore - x-comp and iana-comp values they don't recognize. Applications that - support importing iCalendar objects SHOULD support all of the - component types defined in this document, and SHOULD NOT silently - drop any components as that can lead to user data loss. - -3.6.1. Event Component - - Component Name: VEVENT - - Purpose: Provide a grouping of component properties that describe an - event. - - Format Definition: A "VEVENT" calendar component is defined by the - following notation: - - eventc = "BEGIN" ":" "VEVENT" CRLF - eventprop *alarmc - "END" ":" "VEVENT" CRLF - - eventprop = *( - ; - ; The following are REQUIRED, - ; but MUST NOT occur more than once. - - - -Desruisseaux Standards Track [Page 52] - -RFC 5545 iCalendar September 2009 - - - ; - dtstamp / uid / - ; - ; The following is REQUIRED if the component - ; appears in an iCalendar object that doesn't - ; specify the "METHOD" property; otherwise, it - ; is OPTIONAL; in any case, it MUST NOT occur - ; more than once. - ; - dtstart / - ; - ; The following are OPTIONAL, - ; but MUST NOT occur more than once. - ; - class / created / description / geo / - last-mod / location / organizer / priority / - seq / status / summary / transp / - url / recurid / - ; - ; The following is OPTIONAL, - ; but SHOULD NOT occur more than once. - ; - rrule / - ; - ; Either 'dtend' or 'duration' MAY appear in - ; a 'eventprop', but 'dtend' and 'duration' - ; MUST NOT occur in the same 'eventprop'. - ; - dtend / duration / - ; - ; The following are OPTIONAL, - ; and MAY occur more than once. - ; - attach / attendee / categories / comment / - contact / exdate / rstatus / related / - resources / rdate / x-prop / iana-prop - ; - ) - - Description: A "VEVENT" calendar component is a grouping of - component properties, possibly including "VALARM" calendar - components, that represents a scheduled amount of time on a - calendar. For example, it can be an activity; such as a one-hour - long, department meeting from 8:00 AM to 9:00 AM, tomorrow. - Generally, an event will take up time on an individual calendar. - Hence, the event will appear as an opaque interval in a search for - busy time. Alternately, the event can have its Time Transparency - - - - -Desruisseaux Standards Track [Page 53] - -RFC 5545 iCalendar September 2009 - - - set to "TRANSPARENT" in order to prevent blocking of the event in - searches for busy time. - - The "VEVENT" is also the calendar component used to specify an - anniversary or daily reminder within a calendar. These events - have a DATE value type for the "DTSTART" property instead of the - default value type of DATE-TIME. If such a "VEVENT" has a "DTEND" - property, it MUST be specified as a DATE value also. The - anniversary type of "VEVENT" can span more than one date (i.e., - "DTEND" property value is set to a calendar date after the - "DTSTART" property value). If such a "VEVENT" has a "DURATION" - property, it MUST be specified as a "dur-day" or "dur-week" value. - - The "DTSTART" property for a "VEVENT" specifies the inclusive - start of the event. For recurring events, it also specifies the - very first instance in the recurrence set. The "DTEND" property - for a "VEVENT" calendar component specifies the non-inclusive end - of the event. For cases where a "VEVENT" calendar component - specifies a "DTSTART" property with a DATE value type but no - "DTEND" nor "DURATION" property, the event's duration is taken to - be one day. For cases where a "VEVENT" calendar component - specifies a "DTSTART" property with a DATE-TIME value type but no - "DTEND" property, the event ends on the same calendar date and - time of day specified by the "DTSTART" property. - - The "VEVENT" calendar component cannot be nested within another - calendar component. However, "VEVENT" calendar components can be - related to each other or to a "VTODO" or to a "VJOURNAL" calendar - component with the "RELATED-TO" property. - - Example: The following is an example of the "VEVENT" calendar - component used to represent a meeting that will also be opaque to - searches for busy time: - - BEGIN:VEVENT - UID:19970901T130000Z-123401@example.com - DTSTAMP:19970901T130000Z - DTSTART:19970903T163000Z - DTEND:19970903T190000Z - SUMMARY:Annual Employee Review - CLASS:PRIVATE - CATEGORIES:BUSINESS,HUMAN RESOURCES - END:VEVENT - - The following is an example of the "VEVENT" calendar component - used to represent a reminder that will not be opaque, but rather - transparent, to searches for busy time: - - - - -Desruisseaux Standards Track [Page 54] - -RFC 5545 iCalendar September 2009 - - - BEGIN:VEVENT - UID:19970901T130000Z-123402@example.com - DTSTAMP:19970901T130000Z - DTSTART:19970401T163000Z - DTEND:19970402T010000Z - SUMMARY:Laurel is in sensitivity awareness class. - CLASS:PUBLIC - CATEGORIES:BUSINESS,HUMAN RESOURCES - TRANSP:TRANSPARENT - END:VEVENT - - The following is an example of the "VEVENT" calendar component - used to represent an anniversary that will occur annually: - - BEGIN:VEVENT - UID:19970901T130000Z-123403@example.com - DTSTAMP:19970901T130000Z - DTSTART;VALUE=DATE:19971102 - SUMMARY:Our Blissful Anniversary - TRANSP:TRANSPARENT - CLASS:CONFIDENTIAL - CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION - RRULE:FREQ=YEARLY - END:VEVENT - - The following is an example of the "VEVENT" calendar component - used to represent a multi-day event scheduled from June 28th, 2007 - to July 8th, 2007 inclusively. Note that the "DTEND" property is - set to July 9th, 2007, since the "DTEND" property specifies the - non-inclusive end of the event. - - BEGIN:VEVENT - UID:20070423T123432Z-541111@example.com - DTSTAMP:20070423T123432Z - DTSTART;VALUE=DATE:20070628 - DTEND;VALUE=DATE:20070709 - SUMMARY:Festival International de Jazz de Montreal - TRANSP:TRANSPARENT - END:VEVENT - -3.6.2. To-Do Component - - Component Name: VTODO - - Purpose: Provide a grouping of calendar properties that describe a - to-do. - - - - - -Desruisseaux Standards Track [Page 55] - -RFC 5545 iCalendar September 2009 - - - Format Definition: A "VTODO" calendar component is defined by the - following notation: - - todoc = "BEGIN" ":" "VTODO" CRLF - todoprop *alarmc - "END" ":" "VTODO" CRLF - - todoprop = *( - ; - ; The following are REQUIRED, - ; but MUST NOT occur more than once. - ; - dtstamp / uid / - ; - ; The following are OPTIONAL, - ; but MUST NOT occur more than once. - ; - class / completed / created / description / - dtstart / geo / last-mod / location / organizer / - percent / priority / recurid / seq / status / - summary / url / - ; - ; The following is OPTIONAL, - ; but SHOULD NOT occur more than once. - ; - rrule / - ; - ; Either 'due' or 'duration' MAY appear in - ; a 'todoprop', but 'due' and 'duration' - ; MUST NOT occur in the same 'todoprop'. - ; If 'duration' appear in a 'todoprop', - ; then 'dtstart' MUST also appear in - ; the same 'todoprop'. - ; - due / duration / - ; - ; The following are OPTIONAL, - ; and MAY occur more than once. - ; - attach / attendee / categories / comment / contact / - exdate / rstatus / related / resources / - rdate / x-prop / iana-prop - ; - ) - - Description: A "VTODO" calendar component is a grouping of component - properties and possibly "VALARM" calendar components that - represent an action-item or assignment. For example, it can be - - - -Desruisseaux Standards Track [Page 56] - -RFC 5545 iCalendar September 2009 - - - used to represent an item of work assigned to an individual; such - as "turn in travel expense today". - - The "VTODO" calendar component cannot be nested within another - calendar component. However, "VTODO" calendar components can be - related to each other or to a "VEVENT" or to a "VJOURNAL" calendar - component with the "RELATED-TO" property. - - A "VTODO" calendar component without the "DTSTART" and "DUE" (or - "DURATION") properties specifies a to-do that will be associated - with each successive calendar date, until it is completed. - - Examples: The following is an example of a "VTODO" calendar - component that needs to be completed before May 1st, 2007. On - midnight May 1st, 2007 this to-do would be considered overdue. - - BEGIN:VTODO - UID:20070313T123432Z-456553@example.com - DTSTAMP:20070313T123432Z - DUE;VALUE=DATE:20070501 - SUMMARY:Submit Quebec Income Tax Return for 2006 - CLASS:CONFIDENTIAL - CATEGORIES:FAMILY,FINANCE - STATUS:NEEDS-ACTION - END:VTODO - - The following is an example of a "VTODO" calendar component that - was due before 1:00 P.M. UTC on July 9th, 2007 and was completed - on July 7th, 2007 at 10:00 A.M. UTC. - - BEGIN:VTODO - UID:20070514T103211Z-123404@example.com - DTSTAMP:20070514T103211Z - DTSTART:20070514T110000Z - DUE:20070709T130000Z - COMPLETED:20070707T100000Z - SUMMARY:Submit Revised Internet-Draft - PRIORITY:1 - STATUS:NEEDS-ACTION - END:VTODO - -3.6.3. Journal Component - - Component Name: VJOURNAL - - Purpose: Provide a grouping of component properties that describe a - journal entry. - - - - -Desruisseaux Standards Track [Page 57] - -RFC 5545 iCalendar September 2009 - - - Format Definition: A "VJOURNAL" calendar component is defined by the - following notation: - - journalc = "BEGIN" ":" "VJOURNAL" CRLF - jourprop - "END" ":" "VJOURNAL" CRLF - - jourprop = *( - ; - ; The following are REQUIRED, - ; but MUST NOT occur more than once. - ; - dtstamp / uid / - ; - ; The following are OPTIONAL, - ; but MUST NOT occur more than once. - ; - class / created / dtstart / - last-mod / organizer / recurid / seq / - status / summary / url / - ; - ; The following is OPTIONAL, - ; but SHOULD NOT occur more than once. - ; - rrule / - ; - ; The following are OPTIONAL, - ; and MAY occur more than once. - ; - attach / attendee / categories / comment / - contact / description / exdate / related / rdate / - rstatus / x-prop / iana-prop - ; - ) - - Description: A "VJOURNAL" calendar component is a grouping of - component properties that represent one or more descriptive text - notes associated with a particular calendar date. The "DTSTART" - property is used to specify the calendar date with which the - journal entry is associated. Generally, it will have a DATE value - data type, but it can also be used to specify a DATE-TIME value - data type. Examples of a journal entry include a daily record of - a legislative body or a journal entry of individual telephone - contacts for the day or an ordered list of accomplishments for the - day. The "VJOURNAL" calendar component can also be used to - associate a document with a calendar date. - - - - - -Desruisseaux Standards Track [Page 58] - -RFC 5545 iCalendar September 2009 - - - The "VJOURNAL" calendar component does not take up time on a - calendar. Hence, it does not play a role in free or busy time - searches -- it is as though it has a time transparency value of - TRANSPARENT. It is transparent to any such searches. - - The "VJOURNAL" calendar component cannot be nested within another - calendar component. However, "VJOURNAL" calendar components can - be related to each other or to a "VEVENT" or to a "VTODO" calendar - component, with the "RELATED-TO" property. - - Example: The following is an example of the "VJOURNAL" calendar - component: - - BEGIN:VJOURNAL - UID:19970901T130000Z-123405@example.com - DTSTAMP:19970901T130000Z - DTSTART;VALUE=DATE:19970317 - SUMMARY:Staff meeting minutes - DESCRIPTION:1. Staff meeting: Participants include Joe\, - Lisa\, and Bob. Aurora project plans were reviewed. - There is currently no budget reserves for this project. - Lisa will escalate to management. Next meeting on Tuesday.\n - 2. Telephone Conference: ABC Corp. sales representative - called to discuss new printer. Promised to get us a demo by - Friday.\n3. Henry Miller (Handsoff Insurance): Car was - totaled by tree. Is looking into a loaner car. 555-2323 - (tel). - END:VJOURNAL - -3.6.4. Free/Busy Component - - Component Name: VFREEBUSY - - Purpose: Provide a grouping of component properties that describe - either a request for free/busy time, describe a response to a - request for free/busy time, or describe a published set of busy - time. - - Format Definition: A "VFREEBUSY" calendar component is defined by - the following notation: - - freebusyc = "BEGIN" ":" "VFREEBUSY" CRLF - fbprop - "END" ":" "VFREEBUSY" CRLF - - fbprop = *( - ; - ; The following are REQUIRED, - - - -Desruisseaux Standards Track [Page 59] - -RFC 5545 iCalendar September 2009 - - - ; but MUST NOT occur more than once. - ; - dtstamp / uid / - ; - ; The following are OPTIONAL, - ; but MUST NOT occur more than once. - ; - contact / dtstart / dtend / - organizer / url / - ; - ; The following are OPTIONAL, - ; and MAY occur more than once. - ; - attendee / comment / freebusy / rstatus / x-prop / - iana-prop - ; - ) - - Description: A "VFREEBUSY" calendar component is a grouping of - component properties that represents either a request for free or - busy time information, a reply to a request for free or busy time - information, or a published set of busy time information. - - When used to request free/busy time information, the "ATTENDEE" - property specifies the calendar users whose free/busy time is - being requested; the "ORGANIZER" property specifies the calendar - user who is requesting the free/busy time; the "DTSTART" and - "DTEND" properties specify the window of time for which the free/ - busy time is being requested; the "UID" and "DTSTAMP" properties - are specified to assist in proper sequencing of multiple free/busy - time requests. - - When used to reply to a request for free/busy time, the "ATTENDEE" - property specifies the calendar user responding to the free/busy - time request; the "ORGANIZER" property specifies the calendar user - that originally requested the free/busy time; the "FREEBUSY" - property specifies the free/busy time information (if it exists); - and the "UID" and "DTSTAMP" properties are specified to assist in - proper sequencing of multiple free/busy time replies. - - When used to publish busy time, the "ORGANIZER" property specifies - the calendar user associated with the published busy time; the - "DTSTART" and "DTEND" properties specify an inclusive time window - that surrounds the busy time information; the "FREEBUSY" property - specifies the published busy time information; and the "DTSTAMP" - property specifies the DATE-TIME that iCalendar object was - created. - - - - -Desruisseaux Standards Track [Page 60] - -RFC 5545 iCalendar September 2009 - - - The "VFREEBUSY" calendar component cannot be nested within another - calendar component. Multiple "VFREEBUSY" calendar components can - be specified within an iCalendar object. This permits the - grouping of free/busy information into logical collections, such - as monthly groups of busy time information. - - The "VFREEBUSY" calendar component is intended for use in - iCalendar object methods involving requests for free time, - requests for busy time, requests for both free and busy, and the - associated replies. - - Free/Busy information is represented with the "FREEBUSY" property. - This property provides a terse representation of time periods. - One or more "FREEBUSY" properties can be specified in the - "VFREEBUSY" calendar component. - - When present in a "VFREEBUSY" calendar component, the "DTSTART" - and "DTEND" properties SHOULD be specified prior to any "FREEBUSY" - properties. - - The recurrence properties ("RRULE", "RDATE", "EXDATE") are not - permitted within a "VFREEBUSY" calendar component. Any recurring - events are resolved into their individual busy time periods using - the "FREEBUSY" property. - - Example: The following is an example of a "VFREEBUSY" calendar - component used to request free or busy time information: - - BEGIN:VFREEBUSY - UID:19970901T082949Z-FA43EF@example.com - ORGANIZER:mailto:jane_doe@example.com - ATTENDEE:mailto:john_public@example.com - DTSTART:19971015T050000Z - DTEND:19971016T050000Z - DTSTAMP:19970901T083000Z - END:VFREEBUSY - - - - - - - - - - - - - - - -Desruisseaux Standards Track [Page 61] - -RFC 5545 iCalendar September 2009 - - - The following is an example of a "VFREEBUSY" calendar component - used to reply to the request with busy time information: - - BEGIN:VFREEBUSY - UID:19970901T095957Z-76A912@example.com - ORGANIZER:mailto:jane_doe@example.com - ATTENDEE:mailto:john_public@example.com - DTSTAMP:19970901T100000Z - FREEBUSY:19971015T050000Z/PT8H30M, - 19971015T160000Z/PT5H30M,19971015T223000Z/PT6H30M - URL:http://example.com/pub/busy/jpublic-01.ifb - COMMENT:This iCalendar file contains busy time information for - the next three months. - END:VFREEBUSY - - The following is an example of a "VFREEBUSY" calendar component - used to publish busy time information: - - BEGIN:VFREEBUSY - UID:19970901T115957Z-76A912@example.com - DTSTAMP:19970901T120000Z - ORGANIZER:jsmith@example.com - DTSTART:19980313T141711Z - DTEND:19980410T141711Z - FREEBUSY:19980314T233000Z/19980315T003000Z - FREEBUSY:19980316T153000Z/19980316T163000Z - FREEBUSY:19980318T030000Z/19980318T040000Z - URL:http://www.example.com/calendar/busytime/jsmith.ifb - END:VFREEBUSY - -3.6.5. Time Zone Component - - Component Name: VTIMEZONE - - Purpose: Provide a grouping of component properties that defines a - time zone. - - Format Definition: A "VTIMEZONE" calendar component is defined by - the following notation: - - timezonec = "BEGIN" ":" "VTIMEZONE" CRLF - *( - ; - ; 'tzid' is REQUIRED, but MUST NOT occur more - ; than once. - ; - tzid / - ; - - - -Desruisseaux Standards Track [Page 62] - -RFC 5545 iCalendar September 2009 - - - ; 'last-mod' and 'tzurl' are OPTIONAL, - ; but MUST NOT occur more than once. - ; - last-mod / tzurl / - ; - ; One of 'standardc' or 'daylightc' MUST occur - ; and each MAY occur more than once. - ; - standardc / daylightc / - ; - ; The following are OPTIONAL, - ; and MAY occur more than once. - ; - x-prop / iana-prop - ; - ) - "END" ":" "VTIMEZONE" CRLF - - standardc = "BEGIN" ":" "STANDARD" CRLF - tzprop - "END" ":" "STANDARD" CRLF - - daylightc = "BEGIN" ":" "DAYLIGHT" CRLF - tzprop - "END" ":" "DAYLIGHT" CRLF - - tzprop = *( - ; - ; The following are REQUIRED, - ; but MUST NOT occur more than once. - ; - dtstart / tzoffsetto / tzoffsetfrom / - ; - ; The following is OPTIONAL, - ; but SHOULD NOT occur more than once. - ; - rrule / - ; - ; The following are OPTIONAL, - ; and MAY occur more than once. - ; - comment / rdate / tzname / x-prop / iana-prop - ; - ) - - Description: A time zone is unambiguously defined by the set of time - measurement rules determined by the governing body for a given - geographic area. These rules describe, at a minimum, the base - - - -Desruisseaux Standards Track [Page 63] - -RFC 5545 iCalendar September 2009 - - - offset from UTC for the time zone, often referred to as the - Standard Time offset. Many locations adjust their Standard Time - forward or backward by one hour, in order to accommodate seasonal - changes in number of daylight hours, often referred to as Daylight - Saving Time. Some locations adjust their time by a fraction of an - hour. Standard Time is also known as Winter Time. Daylight - Saving Time is also known as Advanced Time, Summer Time, or Legal - Time in certain countries. The following table shows the changes - in time zone rules in effect for New York City starting from 1967. - Each line represents a description or rule for a particular - observance. - - Effective Observance Rule - - +-----------+--------------------------+--------+--------------+ - | Date | (Date-Time) | Offset | Abbreviation | - +-----------+--------------------------+--------+--------------+ - | 1967-1973 | last Sun in Apr, 02:00 | -0400 | EDT | - | | | | | - | 1967-2006 | last Sun in Oct, 02:00 | -0500 | EST | - | | | | | - | 1974-1974 | Jan 6, 02:00 | -0400 | EDT | - | | | | | - | 1975-1975 | Feb 23, 02:00 | -0400 | EDT | - | | | | | - | 1976-1986 | last Sun in Apr, 02:00 | -0400 | EDT | - | | | | | - | 1987-2006 | first Sun in Apr, 02:00 | -0400 | EDT | - | | | | | - | 2007-* | second Sun in Mar, 02:00 | -0400 | EDT | - | | | | | - | 2007-* | first Sun in Nov, 02:00 | -0500 | EST | - +-----------+--------------------------+--------+--------------+ - - Note: The specification of a global time zone registry is not - addressed by this document and is left for future study. - However, implementers may find the TZ database [TZDB] a useful - reference. It is an informal, public-domain collection of time - zone information, which is currently being maintained by - volunteer Internet participants, and is used in several - operating systems. This database contains current and - historical time zone information for a wide variety of - locations around the globe; it provides a time zone identifier - for every unique time zone rule set in actual use since 1970, - with historical data going back to the introduction of standard - time. - - - - - -Desruisseaux Standards Track [Page 64] - -RFC 5545 iCalendar September 2009 - - - Interoperability between two calendaring and scheduling - applications, especially for recurring events, to-dos or journal - entries, is dependent on the ability to capture and convey date - and time information in an unambiguous format. The specification - of current time zone information is integral to this behavior. - - If present, the "VTIMEZONE" calendar component defines the set of - Standard Time and Daylight Saving Time observances (or rules) for - a particular time zone for a given interval of time. The - "VTIMEZONE" calendar component cannot be nested within other - calendar components. Multiple "VTIMEZONE" calendar components can - exist in an iCalendar object. In this situation, each "VTIMEZONE" - MUST represent a unique time zone definition. This is necessary - for some classes of events, such as airline flights, that start in - one time zone and end in another. - - The "VTIMEZONE" calendar component MUST include the "TZID" - property and at least one definition of a "STANDARD" or "DAYLIGHT" - sub-component. The "STANDARD" or "DAYLIGHT" sub-component MUST - include the "DTSTART", "TZOFFSETFROM", and "TZOFFSETTO" - properties. - - An individual "VTIMEZONE" calendar component MUST be specified for - each unique "TZID" parameter value specified in the iCalendar - object. In addition, a "VTIMEZONE" calendar component, referred - to by a recurring calendar component, MUST provide valid time zone - information for all recurrence instances. - - Each "VTIMEZONE" calendar component consists of a collection of - one or more sub-components that describe the rule for a particular - observance (either a Standard Time or a Daylight Saving Time - observance). The "STANDARD" sub-component consists of a - collection of properties that describe Standard Time. The - "DAYLIGHT" sub-component consists of a collection of properties - that describe Daylight Saving Time. In general, this collection - of properties consists of: - - * the first onset DATE-TIME for the observance; - - * the last onset DATE-TIME for the observance, if a last onset is - known; - - * the offset to be applied for the observance; - - * a rule that describes the day and time when the observance - takes effect; - - * an optional name for the observance. - - - -Desruisseaux Standards Track [Page 65] - -RFC 5545 iCalendar September 2009 - - - For a given time zone, there may be multiple unique definitions of - the observances over a period of time. Each observance is - described using either a "STANDARD" or "DAYLIGHT" sub-component. - The collection of these sub-components is used to describe the - time zone for a given period of time. The offset to apply at any - given time is found by locating the observance that has the last - onset date and time before the time in question, and using the - offset value from that observance. - - The top-level properties in a "VTIMEZONE" calendar component are: - - The mandatory "TZID" property is a text value that uniquely - identifies the "VTIMEZONE" calendar component within the scope of - an iCalendar object. - - The optional "LAST-MODIFIED" property is a UTC value that - specifies the date and time that this time zone definition was - last updated. - - The optional "TZURL" property is a url value that points to a - published "VTIMEZONE" definition. "TZURL" SHOULD refer to a - resource that is accessible by anyone who might need to interpret - the object. This SHOULD NOT normally be a "file" URL or other URL - that is not widely accessible. - - The collection of properties that are used to define the - "STANDARD" and "DAYLIGHT" sub-components include: - - The mandatory "DTSTART" property gives the effective onset date - and local time for the time zone sub-component definition. - "DTSTART" in this usage MUST be specified as a date with a local - time value. - - The mandatory "TZOFFSETFROM" property gives the UTC offset that is - in use when the onset of this time zone observance begins. - "TZOFFSETFROM" is combined with "DTSTART" to define the effective - onset for the time zone sub-component definition. For example, - the following represents the time at which the observance of - Standard Time took effect in Fall 1967 for New York City: - - DTSTART:19671029T020000 - - TZOFFSETFROM:-0400 - - The mandatory "TZOFFSETTO" property gives the UTC offset for the - time zone sub-component (Standard Time or Daylight Saving Time) - when this observance is in use. - - - - -Desruisseaux Standards Track [Page 66] - -RFC 5545 iCalendar September 2009 - - - The optional "TZNAME" property is the customary name for the time - zone. This could be used for displaying dates. - - The onset DATE-TIME values for the observance defined by the time - zone sub-component is defined by the "DTSTART", "RRULE", and - "RDATE" properties. - - The "RRULE" property defines the recurrence rule for the onset of - the observance defined by this time zone sub-component. Some - specific requirements for the usage of "RRULE" for this purpose - include: - - * If observance is known to have an effective end date, the - "UNTIL" recurrence rule parameter MUST be used to specify the - last valid onset of this observance (i.e., the UNTIL DATE-TIME - will be equal to the last instance generated by the recurrence - pattern). It MUST be specified in UTC time. - - * The "DTSTART" and the "TZOFFSETFROM" properties MUST be used - when generating the onset DATE-TIME values (instances) from the - "RRULE". - - The "RDATE" property can also be used to define the onset of the - observance by giving the individual onset date and times. "RDATE" - in this usage MUST be specified as a date with local time value, - relative to the UTC offset specified in the "TZOFFSETFROM" - property. - - The optional "COMMENT" property is also allowed for descriptive - explanatory text. - - Example: The following are examples of the "VTIMEZONE" calendar - component: - - This is an example showing all the time zone rules for New York - City since April 30, 1967 at 03:00:00 EDT. - - BEGIN:VTIMEZONE - TZID:America/New_York - LAST-MODIFIED:20050809T050000Z - BEGIN:DAYLIGHT - DTSTART:19670430T020000 - RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=-1SU;UNTIL=19730429T070000Z - TZOFFSETFROM:-0500 - TZOFFSETTO:-0400 - TZNAME:EDT - END:DAYLIGHT - BEGIN:STANDARD - - - -Desruisseaux Standards Track [Page 67] - -RFC 5545 iCalendar September 2009 - - - DTSTART:19671029T020000 - RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU;UNTIL=20061029T060000Z - TZOFFSETFROM:-0400 - TZOFFSETTO:-0500 - TZNAME:EST - END:STANDARD - BEGIN:DAYLIGHT - DTSTART:19740106T020000 - RDATE:19750223T020000 - TZOFFSETFROM:-0500 - TZOFFSETTO:-0400 - TZNAME:EDT - END:DAYLIGHT - BEGIN:DAYLIGHT - DTSTART:19760425T020000 - RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=-1SU;UNTIL=19860427T070000Z - TZOFFSETFROM:-0500 - TZOFFSETTO:-0400 - TZNAME:EDT - END:DAYLIGHT - BEGIN:DAYLIGHT - DTSTART:19870405T020000 - RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=1SU;UNTIL=20060402T070000Z - TZOFFSETFROM:-0500 - TZOFFSETTO:-0400 - TZNAME:EDT - END:DAYLIGHT - BEGIN:DAYLIGHT - DTSTART:20070311T020000 - RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU - TZOFFSETFROM:-0500 - TZOFFSETTO:-0400 - TZNAME:EDT - END:DAYLIGHT - BEGIN:STANDARD - DTSTART:20071104T020000 - RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU - TZOFFSETFROM:-0400 - TZOFFSETTO:-0500 - TZNAME:EST - END:STANDARD - END:VTIMEZONE - - This is an example showing time zone information for New York City - using only the "DTSTART" property. Note that this is only - suitable for a recurring event that starts on or later than March - 11, 2007 at 03:00:00 EDT (i.e., the earliest effective transition - date and time) and ends no later than March 9, 2008 at 01:59:59 - - - -Desruisseaux Standards Track [Page 68] - -RFC 5545 iCalendar September 2009 - - - EST (i.e., latest valid date and time for EST in this scenario). - For example, this can be used for a recurring event that occurs - every Friday, 8:00 A.M.-9:00 A.M., starting June 1, 2007, ending - December 31, 2007, - - BEGIN:VTIMEZONE - TZID:America/New_York - LAST-MODIFIED:20050809T050000Z - BEGIN:STANDARD - DTSTART:20071104T020000 - TZOFFSETFROM:-0400 - TZOFFSETTO:-0500 - TZNAME:EST - END:STANDARD - BEGIN:DAYLIGHT - DTSTART:20070311T020000 - TZOFFSETFROM:-0500 - TZOFFSETTO:-0400 - TZNAME:EDT - END:DAYLIGHT - END:VTIMEZONE - - This is a simple example showing the current time zone rules for - New York City using a "RRULE" recurrence pattern. Note that there - is no effective end date to either of the Standard Time or - Daylight Time rules. This information would be valid for a - recurring event starting today and continuing indefinitely. - - BEGIN:VTIMEZONE - TZID:America/New_York - LAST-MODIFIED:20050809T050000Z - TZURL:http://zones.example.com/tz/America-New_York.ics - BEGIN:STANDARD - DTSTART:20071104T020000 - RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU - TZOFFSETFROM:-0400 - TZOFFSETTO:-0500 - TZNAME:EST - END:STANDARD - BEGIN:DAYLIGHT - DTSTART:20070311T020000 - RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU - TZOFFSETFROM:-0500 - TZOFFSETTO:-0400 - TZNAME:EDT - END:DAYLIGHT - END:VTIMEZONE - - - - -Desruisseaux Standards Track [Page 69] - -RFC 5545 iCalendar September 2009 - - - This is an example showing a set of rules for a fictitious time - zone where the Daylight Time rule has an effective end date (i.e., - after that date, Daylight Time is no longer observed). - - BEGIN:VTIMEZONE - TZID:Fictitious - LAST-MODIFIED:19870101T000000Z - BEGIN:STANDARD - DTSTART:19671029T020000 - RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 - TZOFFSETFROM:-0400 - TZOFFSETTO:-0500 - TZNAME:EST - END:STANDARD - BEGIN:DAYLIGHT - DTSTART:19870405T020000 - RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T070000Z - TZOFFSETFROM:-0500 - TZOFFSETTO:-0400 - TZNAME:EDT - END:DAYLIGHT - END:VTIMEZONE - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Desruisseaux Standards Track [Page 70] - -RFC 5545 iCalendar September 2009 - - - This is an example showing a set of rules for a fictitious time - zone where the first Daylight Time rule has an effective end date. - There is a second Daylight Time rule that picks up where the other - left off. - - BEGIN:VTIMEZONE - TZID:Fictitious - LAST-MODIFIED:19870101T000000Z - BEGIN:STANDARD - DTSTART:19671029T020000 - RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 - TZOFFSETFROM:-0400 - TZOFFSETTO:-0500 - TZNAME:EST - END:STANDARD - BEGIN:DAYLIGHT - DTSTART:19870405T020000 - RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T070000Z - TZOFFSETFROM:-0500 - TZOFFSETTO:-0400 - TZNAME:EDT - END:DAYLIGHT - BEGIN:DAYLIGHT - DTSTART:19990424T020000 - RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=4 - TZOFFSETFROM:-0500 - TZOFFSETTO:-0400 - TZNAME:EDT - END:DAYLIGHT - END:VTIMEZONE - -3.6.6. Alarm Component - - Component Name: VALARM - - Purpose: Provide a grouping of component properties that define an - alarm. - - Format Definition: A "VALARM" calendar component is defined by the - following notation: - - alarmc = "BEGIN" ":" "VALARM" CRLF - (audioprop / dispprop / emailprop) - "END" ":" "VALARM" CRLF - - audioprop = *( - ; - ; 'action' and 'trigger' are both REQUIRED, - - - -Desruisseaux Standards Track [Page 71] - -RFC 5545 iCalendar September 2009 - - - ; but MUST NOT occur more than once. - ; - action / trigger / - ; - ; 'duration' and 'repeat' are both OPTIONAL, - ; and MUST NOT occur more than once each; - ; but if one occurs, so MUST the other. - ; - duration / repeat / - ; - ; The following is OPTIONAL, - ; but MUST NOT occur more than once. - ; - attach / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - x-prop / iana-prop - ; - ) - - dispprop = *( - ; - ; The following are REQUIRED, - ; but MUST NOT occur more than once. - ; - action / description / trigger / - ; - ; 'duration' and 'repeat' are both OPTIONAL, - ; and MUST NOT occur more than once each; - ; but if one occurs, so MUST the other. - ; - duration / repeat / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - x-prop / iana-prop - ; - ) - - emailprop = *( - ; - ; The following are all REQUIRED, - ; but MUST NOT occur more than once. - ; - action / description / trigger / summary / - - - -Desruisseaux Standards Track [Page 72] - -RFC 5545 iCalendar September 2009 - - - ; - ; The following is REQUIRED, - ; and MAY occur more than once. - ; - attendee / - ; - ; 'duration' and 'repeat' are both OPTIONAL, - ; and MUST NOT occur more than once each; - ; but if one occurs, so MUST the other. - ; - duration / repeat / - ; - ; The following are OPTIONAL, - ; and MAY occur more than once. - ; - attach / x-prop / iana-prop - ; - ) - - Description: A "VALARM" calendar component is a grouping of - component properties that is a reminder or alarm for an event or a - to-do. For example, it may be used to define a reminder for a - pending event or an overdue to-do. - - The "VALARM" calendar component MUST include the "ACTION" and - "TRIGGER" properties. The "ACTION" property further constrains - the "VALARM" calendar component in the following ways: - - When the action is "AUDIO", the alarm can also include one and - only one "ATTACH" property, which MUST point to a sound resource, - which is rendered when the alarm is triggered. - - When the action is "DISPLAY", the alarm MUST also include a - "DESCRIPTION" property, which contains the text to be displayed - when the alarm is triggered. - - When the action is "EMAIL", the alarm MUST include a "DESCRIPTION" - property, which contains the text to be used as the message body, - a "SUMMARY" property, which contains the text to be used as the - message subject, and one or more "ATTENDEE" properties, which - contain the email address of attendees to receive the message. It - can also include one or more "ATTACH" properties, which are - intended to be sent as message attachments. When the alarm is - triggered, the email message is sent. - - The "VALARM" calendar component MUST only appear within either a - "VEVENT" or "VTODO" calendar component. "VALARM" calendar - components cannot be nested. Multiple mutually independent - - - -Desruisseaux Standards Track [Page 73] - -RFC 5545 iCalendar September 2009 - - - "VALARM" calendar components can be specified for a single - "VEVENT" or "VTODO" calendar component. - - The "TRIGGER" property specifies when the alarm will be triggered. - The "TRIGGER" property specifies a duration prior to the start of - an event or a to-do. The "TRIGGER" edge may be explicitly set to - be relative to the "START" or "END" of the event or to-do with the - "RELATED" parameter of the "TRIGGER" property. The "TRIGGER" - property value type can alternatively be set to an absolute - calendar date with UTC time. - - In an alarm set to trigger on the "START" of an event or to-do, - the "DTSTART" property MUST be present in the associated event or - to-do. In an alarm in a "VEVENT" calendar component set to - trigger on the "END" of the event, either the "DTEND" property - MUST be present, or the "DTSTART" and "DURATION" properties MUST - both be present. In an alarm in a "VTODO" calendar component set - to trigger on the "END" of the to-do, either the "DUE" property - MUST be present, or the "DTSTART" and "DURATION" properties MUST - both be present. - - The alarm can be defined such that it triggers repeatedly. A - definition of an alarm with a repeating trigger MUST include both - the "DURATION" and "REPEAT" properties. The "DURATION" property - specifies the delay period, after which the alarm will repeat. - The "REPEAT" property specifies the number of additional - repetitions that the alarm will be triggered. This repetition - count is in addition to the initial triggering of the alarm. Both - of these properties MUST be present in order to specify a - repeating alarm. If one of these two properties is absent, then - the alarm will not repeat beyond the initial trigger. - - The "ACTION" property is used within the "VALARM" calendar - component to specify the type of action invoked when the alarm is - triggered. The "VALARM" properties provide enough information for - a specific action to be invoked. It is typically the - responsibility of a "Calendar User Agent" (CUA) to deliver the - alarm in the specified fashion. An "ACTION" property value of - AUDIO specifies an alarm that causes a sound to be played to alert - the user; DISPLAY specifies an alarm that causes a text message to - be displayed to the user; and EMAIL specifies an alarm that causes - an electronic email message to be delivered to one or more email - addresses. - - In an AUDIO alarm, if the optional "ATTACH" property is included, - it MUST specify an audio sound resource. The intention is that - the sound will be played as the alarm effect. If an "ATTACH" - property is specified that does not refer to a sound resource, or - - - -Desruisseaux Standards Track [Page 74] - -RFC 5545 iCalendar September 2009 - - - if the specified sound resource cannot be rendered (because its - format is unsupported, or because it cannot be retrieved), then - the CUA or other entity responsible for playing the sound may - choose a fallback action, such as playing a built-in default - sound, or playing no sound at all. - - In a DISPLAY alarm, the intended alarm effect is for the text - value of the "DESCRIPTION" property to be displayed to the user. - - In an EMAIL alarm, the intended alarm effect is for an email - message to be composed and delivered to all the addresses - specified by the "ATTENDEE" properties in the "VALARM" calendar - component. The "DESCRIPTION" property of the "VALARM" calendar - component MUST be used as the body text of the message, and the - "SUMMARY" property MUST be used as the subject text. Any "ATTACH" - properties in the "VALARM" calendar component SHOULD be sent as - attachments to the message. - - Note: Implementations should carefully consider whether they - accept alarm components from untrusted sources, e.g., when - importing calendar objects from external sources. One - reasonable policy is to always ignore alarm components that the - calendar user has not set herself, or at least ask for - confirmation in such a case. - - Example: The following example is for a "VALARM" calendar component - that specifies an audio alarm that will sound at a precise time - and repeat 4 more times at 15-minute intervals: - - BEGIN:VALARM - TRIGGER;VALUE=DATE-TIME:19970317T133000Z - REPEAT:4 - DURATION:PT15M - ACTION:AUDIO - ATTACH;FMTTYPE=audio/basic:ftp://example.com/pub/ - sounds/bell-01.aud - END:VALARM - - The following example is for a "VALARM" calendar component that - specifies a display alarm that will trigger 30 minutes before the - scheduled start of the event or of the to-do it is associated with - and will repeat 2 more times at 15-minute intervals: - - - - - - - - - -Desruisseaux Standards Track [Page 75] - -RFC 5545 iCalendar September 2009 - - - BEGIN:VALARM - TRIGGER:-PT30M - REPEAT:2 - DURATION:PT15M - ACTION:DISPLAY - DESCRIPTION:Breakfast meeting with executive\n - team at 8:30 AM EST. - END:VALARM - - The following example is for a "VALARM" calendar component that - specifies an email alarm that will trigger 2 days before the - scheduled due DATE-TIME of a to-do with which it is associated. - It does not repeat. The email has a subject, body, and attachment - link. - - BEGIN:VALARM - TRIGGER;RELATED=END:-P2D - ACTION:EMAIL - ATTENDEE:mailto:john_doe@example.com - SUMMARY:*** REMINDER: SEND AGENDA FOR WEEKLY STAFF MEETING *** - DESCRIPTION:A draft agenda needs to be sent out to the attendees - to the weekly managers meeting (MGR-LIST). Attached is a - pointer the document template for the agenda file. - ATTACH;FMTTYPE=application/msword:http://example.com/ - templates/agenda.doc - END:VALARM - -3.7. Calendar Properties - - The Calendar Properties are attributes that apply to the iCalendar - object, as a whole. These properties do not appear within a calendar - component. They SHOULD be specified after the "BEGIN:VCALENDAR" - delimiter string and prior to any calendar component. - -3.7.1. Calendar Scale - - Property Name: CALSCALE - - Purpose: This property defines the calendar scale used for the - calendar information specified in the iCalendar object. - - Value Type: TEXT - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: This property can be specified once in an iCalendar - object. The default value is "GREGORIAN". - - - -Desruisseaux Standards Track [Page 76] - -RFC 5545 iCalendar September 2009 - - - Description: This memo is based on the Gregorian calendar scale. - The Gregorian calendar scale is assumed if this property is not - specified in the iCalendar object. It is expected that other - calendar scales will be defined in other specifications or by - future versions of this memo. - - Format Definition: This property is defined by the following - notation: - - calscale = "CALSCALE" calparam ":" calvalue CRLF - - calparam = *(";" other-param) - - calvalue = "GREGORIAN" - - Example: The following is an example of this property: - - CALSCALE:GREGORIAN - -3.7.2. Method - - Property Name: METHOD - - Purpose: This property defines the iCalendar object method - associated with the calendar object. - - Value Type: TEXT - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: This property can be specified once in an iCalendar - object. - - Description: When used in a MIME message entity, the value of this - property MUST be the same as the Content-Type "method" parameter - value. If either the "METHOD" property or the Content-Type - "method" parameter is specified, then the other MUST also be - specified. - - No methods are defined by this specification. This is the subject - of other specifications, such as the iCalendar Transport- - independent Interoperability Protocol (iTIP) defined by [2446bis]. - - If this property is not present in the iCalendar object, then a - scheduling transaction MUST NOT be assumed. In such cases, the - iCalendar object is merely being used to transport a snapshot of - - - - -Desruisseaux Standards Track [Page 77] - -RFC 5545 iCalendar September 2009 - - - some calendar information; without the intention of conveying a - scheduling semantic. - - Format Definition: This property is defined by the following - notation: - - method = "METHOD" metparam ":" metvalue CRLF - - metparam = *(";" other-param) - - metvalue = iana-token - - Example: The following is a hypothetical example of this property to - convey that the iCalendar object is a scheduling request: - - METHOD:REQUEST - -3.7.3. Product Identifier - - Property Name: PRODID - - Purpose: This property specifies the identifier for the product that - created the iCalendar object. - - Value Type: TEXT - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: The property MUST be specified once in an iCalendar - object. - - Description: The vendor of the implementation SHOULD assure that - this is a globally unique identifier; using some technique such as - an FPI value, as defined in [ISO.9070.1991]. - - This property SHOULD NOT be used to alter the interpretation of an - iCalendar object beyond the semantics specified in this memo. For - example, it is not to be used to further the understanding of non- - standard properties. - - Format Definition: This property is defined by the following - notation: - - prodid = "PRODID" pidparam ":" pidvalue CRLF - - pidparam = *(";" other-param) - - - - -Desruisseaux Standards Track [Page 78] - -RFC 5545 iCalendar September 2009 - - - pidvalue = text - ;Any text that describes the product and version - ;and that is generally assured of being unique. - - Example: The following is an example of this property. It does not - imply that English is the default language. - - PRODID:-//ABC Corporation//NONSGML My Product//EN - -3.7.4. Version - - Property Name: VERSION - - Purpose: This property specifies the identifier corresponding to the - highest version number or the minimum and maximum range of the - iCalendar specification that is required in order to interpret the - iCalendar object. - - Value Type: TEXT - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: This property MUST be specified once in an iCalendar - object. - - Description: A value of "2.0" corresponds to this memo. - - Format Definition: This property is defined by the following - notation: - - version = "VERSION" verparam ":" vervalue CRLF - - verparam = *(";" other-param) - - vervalue = "2.0" ;This memo - / maxver - / (minver ";" maxver) - - minver =
- ;Minimum iCalendar version needed to parse the iCalendar object. - - maxver = - ;Maximum iCalendar version needed to parse the iCalendar object. - - - - - - - -Desruisseaux Standards Track [Page 79] - -RFC 5545 iCalendar September 2009 - - - Example: The following is an example of this property: - - VERSION:2.0 - -3.8. Component Properties - - The following properties can appear within calendar components, as - specified by each component property definition. - -3.8.1. Descriptive Component Properties - - The following properties specify descriptive information about - calendar components. - -3.8.1.1. Attachment - - Property Name: ATTACH - - Purpose: This property provides the capability to associate a - document object with a calendar component. - - Value Type: The default value type for this property is URI. The - value type can also be set to BINARY to indicate inline binary - encoded content information. - - Property Parameters: IANA, non-standard, inline encoding, and value - data type property parameters can be specified on this property. - The format type parameter can be specified on this property and is - RECOMMENDED for inline binary encoded content information. - - Conformance: This property can be specified multiple times in a - "VEVENT", "VTODO", "VJOURNAL", or "VALARM" calendar component with - the exception of AUDIO alarm that only allows this property to - occur once. - - Description: This property is used in "VEVENT", "VTODO", and - "VJOURNAL" calendar components to associate a resource (e.g., - document) with the calendar component. This property is used in - "VALARM" calendar components to specify an audio sound resource or - an email message attachment. This property can be specified as a - URI pointing to a resource or as inline binary encoded content. - - When this property is specified as inline binary encoded content, - calendar applications MAY attempt to guess the media type of the - resource via inspection of its content if and only if the media - type of the resource is not given by the "FMTTYPE" parameter. If - the media type remains unknown, calendar applications SHOULD treat - it as type "application/octet-stream". - - - -Desruisseaux Standards Track [Page 80] - -RFC 5545 iCalendar September 2009 - - - Format Definition: This property is defined by the following - notation: - - attach = "ATTACH" attachparam ( ":" uri ) / - ( - ";" "ENCODING" "=" "BASE64" - ";" "VALUE" "=" "BINARY" - ":" binary - ) - CRLF - - attachparam = *( - ; - ; The following is OPTIONAL for a URI value, - ; RECOMMENDED for a BINARY value, - ; and MUST NOT occur more than once. - ; - (";" fmttypeparam) / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - (";" other-param) - ; - ) - - Example: The following are examples of this property: - - ATTACH:CID:jsmith.part3.960817T083000.xyzMail@example.com - - ATTACH;FMTTYPE=application/postscript:ftp://example.com/pub/ - reports/r-960812.ps - -3.8.1.2. Categories - - Property Name: CATEGORIES - - Purpose: This property defines the categories for a calendar - component. - - Value Type: TEXT - - Property Parameters: IANA, non-standard, and language property - parameters can be specified on this property. - - Conformance: The property can be specified within "VEVENT", "VTODO", - or "VJOURNAL" calendar components. - - - - -Desruisseaux Standards Track [Page 81] - -RFC 5545 iCalendar September 2009 - - - Description: This property is used to specify categories or subtypes - of the calendar component. The categories are useful in searching - for a calendar component of a particular type and category. - Within the "VEVENT", "VTODO", or "VJOURNAL" calendar components, - more than one category can be specified as a COMMA-separated list - of categories. - - Format Definition: This property is defined by the following - notation: - - categories = "CATEGORIES" catparam ":" text *("," text) - CRLF - - catparam = *( - ; - ; The following is OPTIONAL, - ; but MUST NOT occur more than once. - ; - (";" languageparam ) / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - (";" other-param) - ; - ) - - Example: The following are examples of this property: - - CATEGORIES:APPOINTMENT,EDUCATION - - CATEGORIES:MEETING - -3.8.1.3. Classification - - Property Name: CLASS - - Purpose: This property defines the access classification for a - calendar component. - - Value Type: TEXT - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: The property can be specified once in a "VEVENT", - "VTODO", or "VJOURNAL" calendar components. - - - - -Desruisseaux Standards Track [Page 82] - -RFC 5545 iCalendar September 2009 - - - Description: An access classification is only one component of the - general security system within a calendar application. It - provides a method of capturing the scope of the access the - calendar owner intends for information within an individual - calendar entry. The access classification of an individual - iCalendar component is useful when measured along with the other - security components of a calendar system (e.g., calendar user - authentication, authorization, access rights, access role, etc.). - Hence, the semantics of the individual access classifications - cannot be completely defined by this memo alone. Additionally, - due to the "blind" nature of most exchange processes using this - memo, these access classifications cannot serve as an enforcement - statement for a system receiving an iCalendar object. Rather, - they provide a method for capturing the intention of the calendar - owner for the access to the calendar component. If not specified - in a component that allows this property, the default value is - PUBLIC. Applications MUST treat x-name and iana-token values they - don't recognize the same way as they would the PRIVATE value. - - Format Definition: This property is defined by the following - notation: - - class = "CLASS" classparam ":" classvalue CRLF - - classparam = *(";" other-param) - - classvalue = "PUBLIC" / "PRIVATE" / "CONFIDENTIAL" / iana-token - / x-name - ;Default is PUBLIC - - Example: The following is an example of this property: - - CLASS:PUBLIC - -3.8.1.4. Comment - - Property Name: COMMENT - - Purpose: This property specifies non-processing information intended - to provide a comment to the calendar user. - - Value Type: TEXT - - Property Parameters: IANA, non-standard, alternate text - representation, and language property parameters can be specified - on this property. - - - - - -Desruisseaux Standards Track [Page 83] - -RFC 5545 iCalendar September 2009 - - - Conformance: This property can be specified multiple times in - "VEVENT", "VTODO", "VJOURNAL", and "VFREEBUSY" calendar components - as well as in the "STANDARD" and "DAYLIGHT" sub-components. - - Description: This property is used to specify a comment to the - calendar user. - - Format Definition: This property is defined by the following - notation: - - comment = "COMMENT" commparam ":" text CRLF - - commparam = *( - ; - ; The following are OPTIONAL, - ; but MUST NOT occur more than once. - ; - (";" altrepparam) / (";" languageparam) / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - (";" other-param) - ; - ) - - Example: The following is an example of this property: - - COMMENT:The meeting really needs to include both ourselves - and the customer. We can't hold this meeting without them. - As a matter of fact\, the venue for the meeting ought to be at - their site. - - John - -3.8.1.5. Description - - Property Name: DESCRIPTION - - Purpose: This property provides a more complete description of the - calendar component than that provided by the "SUMMARY" property. - - Value Type: TEXT - - Property Parameters: IANA, non-standard, alternate text - representation, and language property parameters can be specified - on this property. - - - - - - -Desruisseaux Standards Track [Page 84] - -RFC 5545 iCalendar September 2009 - - - Conformance: The property can be specified in the "VEVENT", "VTODO", - "VJOURNAL", or "VALARM" calendar components. The property can be - specified multiple times only within a "VJOURNAL" calendar - component. - - Description: This property is used in the "VEVENT" and "VTODO" to - capture lengthy textual descriptions associated with the activity. - - This property is used in the "VJOURNAL" calendar component to - capture one or more textual journal entries. - - This property is used in the "VALARM" calendar component to - capture the display text for a DISPLAY category of alarm, and to - capture the body text for an EMAIL category of alarm. - - Format Definition: This property is defined by the following - notation: - - description = "DESCRIPTION" descparam ":" text CRLF - - descparam = *( - ; - ; The following are OPTIONAL, - ; but MUST NOT occur more than once. - ; - (";" altrepparam) / (";" languageparam) / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - (";" other-param) - ; - ) - - Example: The following is an example of this property with formatted - line breaks in the property value: - - DESCRIPTION:Meeting to provide technical review for "Phoenix" - design.\nHappy Face Conference Room. Phoenix design team - MUST attend this meeting.\nRSVP to team leader. - -3.8.1.6. Geographic Position - - Property Name: GEO - - Purpose: This property specifies information related to the global - position for the activity specified by a calendar component. - - - - -Desruisseaux Standards Track [Page 85] - -RFC 5545 iCalendar September 2009 - - - Value Type: FLOAT. The value MUST be two SEMICOLON-separated FLOAT - values. - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: This property can be specified in "VEVENT" or "VTODO" - calendar components. - - Description: This property value specifies latitude and longitude, - in that order (i.e., "LAT LON" ordering). The longitude - represents the location east or west of the prime meridian as a - positive or negative real number, respectively. The longitude and - latitude values MAY be specified up to six decimal places, which - will allow for accuracy to within one meter of geographical - position. Receiving applications MUST accept values of this - precision and MAY truncate values of greater precision. - - Values for latitude and longitude shall be expressed as decimal - fractions of degrees. Whole degrees of latitude shall be - represented by a two-digit decimal number ranging from 0 through - 90. Whole degrees of longitude shall be represented by a decimal - number ranging from 0 through 180. When a decimal fraction of a - degree is specified, it shall be separated from the whole number - of degrees by a decimal point. - - Latitudes north of the equator shall be specified by a plus sign - (+), or by the absence of a minus sign (-), preceding the digits - designating degrees. Latitudes south of the Equator shall be - designated by a minus sign (-) preceding the digits designating - degrees. A point on the Equator shall be assigned to the Northern - Hemisphere. - - Longitudes east of the prime meridian shall be specified by a plus - sign (+), or by the absence of a minus sign (-), preceding the - digits designating degrees. Longitudes west of the meridian shall - be designated by minus sign (-) preceding the digits designating - degrees. A point on the prime meridian shall be assigned to the - Eastern Hemisphere. A point on the 180th meridian shall be - assigned to the Western Hemisphere. One exception to this last - convention is permitted. For the special condition of describing - a band of latitude around the earth, the East Bounding Coordinate - data element shall be assigned the value +180 (180) degrees. - - Any spatial address with a latitude of +90 (90) or -90 degrees - will specify the position at the North or South Pole, - respectively. The component for longitude may have any legal - value. - - - -Desruisseaux Standards Track [Page 86] - -RFC 5545 iCalendar September 2009 - - - With the exception of the special condition described above, this - form is specified in [ANSI INCITS 61-1986]. - - The simple formula for converting degrees-minutes-seconds into - decimal degrees is: - - decimal = degrees + minutes/60 + seconds/3600. - - Format Definition: This property is defined by the following - notation: - - geo = "GEO" geoparam ":" geovalue CRLF - - geoparam = *(";" other-param) - - geovalue = float ";" float - ;Latitude and Longitude components - - Example: The following is an example of this property: - - GEO:37.386013;-122.082932 - -3.8.1.7. Location - - Property Name: LOCATION - - Purpose: This property defines the intended venue for the activity - defined by a calendar component. - - Value Type: TEXT - - Property Parameters: IANA, non-standard, alternate text - representation, and language property parameters can be specified - on this property. - - Conformance: This property can be specified in "VEVENT" or "VTODO" - calendar component. - - Description: Specific venues such as conference or meeting rooms may - be explicitly specified using this property. An alternate - representation may be specified that is a URI that points to - directory information with more structured specification of the - location. For example, the alternate representation may specify - either an LDAP URL [RFC4516] pointing to an LDAP server entry or a - CID URL [RFC2392] pointing to a MIME body part containing a - Virtual-Information Card (vCard) [RFC2426] for the location. - - - - - -Desruisseaux Standards Track [Page 87] - -RFC 5545 iCalendar September 2009 - - - Format Definition: This property is defined by the following - notation: - - location = "LOCATION" locparam ":" text CRLF - - locparam = *( - ; - ; The following are OPTIONAL, - ; but MUST NOT occur more than once. - ; - (";" altrepparam) / (";" languageparam) / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - (";" other-param) - ; - ) - - Example: The following are some examples of this property: - - LOCATION:Conference Room - F123\, Bldg. 002 - - LOCATION;ALTREP="http://xyzcorp.com/conf-rooms/f123.vcf": - Conference Room - F123\, Bldg. 002 - -3.8.1.8. Percent Complete - - Property Name: PERCENT-COMPLETE - - Purpose: This property is used by an assignee or delegatee of a - to-do to convey the percent completion of a to-do to the - "Organizer". - - Value Type: INTEGER - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: This property can be specified once in a "VTODO" - calendar component. - - Description: The property value is a positive integer between 0 and - 100. A value of "0" indicates the to-do has not yet been started. - A value of "100" indicates that the to-do has been completed. - Integer values in between indicate the percent partially complete. - - - - - -Desruisseaux Standards Track [Page 88] - -RFC 5545 iCalendar September 2009 - - - When a to-do is assigned to multiple individuals, the property - value indicates the percent complete for that portion of the to-do - assigned to the assignee or delegatee. For example, if a to-do is - assigned to both individuals "A" and "B". A reply from "A" with a - percent complete of "70" indicates that "A" has completed 70% of - the to-do assigned to them. A reply from "B" with a percent - complete of "50" indicates "B" has completed 50% of the to-do - assigned to them. - - Format Definition: This property is defined by the following - notation: - - percent = "PERCENT-COMPLETE" pctparam ":" integer CRLF - - pctparam = *(";" other-param) - - Example: The following is an example of this property to show 39% - completion: - - PERCENT-COMPLETE:39 - -3.8.1.9. Priority - - Property Name: PRIORITY - - Purpose: This property defines the relative priority for a calendar - component. - - Value Type: INTEGER - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: This property can be specified in "VEVENT" and "VTODO" - calendar components. - - Description: This priority is specified as an integer in the range 0 - to 9. A value of 0 specifies an undefined priority. A value of 1 - is the highest priority. A value of 2 is the second highest - priority. Subsequent numbers specify a decreasing ordinal - priority. A value of 9 is the lowest priority. - - A CUA with a three-level priority scheme of "HIGH", "MEDIUM", and - "LOW" is mapped into this property such that a property value in - the range of 1 to 4 specifies "HIGH" priority. A value of 5 is - the normal or "MEDIUM" priority. A value in the range of 6 to 9 - is "LOW" priority. - - - - -Desruisseaux Standards Track [Page 89] - -RFC 5545 iCalendar September 2009 - - - A CUA with a priority schema of "A1", "A2", "A3", "B1", "B2", ..., - "C3" is mapped into this property such that a property value of 1 - specifies "A1", a property value of 2 specifies "A2", a property - value of 3 specifies "A3", and so forth up to a property value of - 9 specifies "C3". - - Other integer values are reserved for future use. - - Within a "VEVENT" calendar component, this property specifies a - priority for the event. This property may be useful when more - than one event is scheduled for a given time period. - - Within a "VTODO" calendar component, this property specified a - priority for the to-do. This property is useful in prioritizing - multiple action items for a given time period. - - Format Definition: This property is defined by the following - notation: - - priority = "PRIORITY" prioparam ":" priovalue CRLF - ;Default is zero (i.e., undefined). - - prioparam = *(";" other-param) - - priovalue = integer ;Must be in the range [0..9] - ; All other values are reserved for future use. - - Example: The following is an example of a property with the highest - priority: - - PRIORITY:1 - - The following is an example of a property with a next highest - priority: - - PRIORITY:2 - - The following is an example of a property with no priority. This - is equivalent to not specifying the "PRIORITY" property: - - PRIORITY:0 - - - - - - - - - - -Desruisseaux Standards Track [Page 90] - -RFC 5545 iCalendar September 2009 - - -3.8.1.10. Resources - - Property Name: RESOURCES - - Purpose: This property defines the equipment or resources - anticipated for an activity specified by a calendar component. - - Value Type: TEXT - - Property Parameters: IANA, non-standard, alternate text - representation, and language property parameters can be specified - on this property. - - Conformance: This property can be specified once in "VEVENT" or - "VTODO" calendar component. - - Description: The property value is an arbitrary text. More than one - resource can be specified as a COMMA-separated list of resources. - - Format Definition: This property is defined by the following - notation: - - resources = "RESOURCES" resrcparam ":" text *("," text) CRLF - - resrcparam = *( - ; - ; The following are OPTIONAL, - ; but MUST NOT occur more than once. - ; - (";" altrepparam) / (";" languageparam) / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - (";" other-param) - ; - ) - - Example: The following is an example of this property: - - RESOURCES:EASEL,PROJECTOR,VCR - - RESOURCES;LANGUAGE=fr:Nettoyeur haute pression - - - - - - - - -Desruisseaux Standards Track [Page 91] - -RFC 5545 iCalendar September 2009 - - -3.8.1.11. Status - - Property Name: STATUS - - Purpose: This property defines the overall status or confirmation - for the calendar component. - - Value Type: TEXT - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: This property can be specified once in "VEVENT", - "VTODO", or "VJOURNAL" calendar components. - - Description: In a group-scheduled calendar component, the property - is used by the "Organizer" to provide a confirmation of the event - to the "Attendees". For example in a "VEVENT" calendar component, - the "Organizer" can indicate that a meeting is tentative, - confirmed, or cancelled. In a "VTODO" calendar component, the - "Organizer" can indicate that an action item needs action, is - completed, is in process or being worked on, or has been - cancelled. In a "VJOURNAL" calendar component, the "Organizer" - can indicate that a journal entry is draft, final, or has been - cancelled or removed. - - Format Definition: This property is defined by the following - notation: - - status = "STATUS" statparam ":" statvalue CRLF - - statparam = *(";" other-param) - - statvalue = (statvalue-event - / statvalue-todo - / statvalue-jour) - - statvalue-event = "TENTATIVE" ;Indicates event is tentative. - / "CONFIRMED" ;Indicates event is definite. - / "CANCELLED" ;Indicates event was cancelled. - ;Status values for a "VEVENT" - - statvalue-todo = "NEEDS-ACTION" ;Indicates to-do needs action. - / "COMPLETED" ;Indicates to-do completed. - / "IN-PROCESS" ;Indicates to-do in process of. - / "CANCELLED" ;Indicates to-do was cancelled. - ;Status values for "VTODO". - - - - -Desruisseaux Standards Track [Page 92] - -RFC 5545 iCalendar September 2009 - - - statvalue-jour = "DRAFT" ;Indicates journal is draft. - / "FINAL" ;Indicates journal is final. - / "CANCELLED" ;Indicates journal is removed. - ;Status values for "VJOURNAL". - - Example: The following is an example of this property for a "VEVENT" - calendar component: - - STATUS:TENTATIVE - - The following is an example of this property for a "VTODO" - calendar component: - - STATUS:NEEDS-ACTION - - The following is an example of this property for a "VJOURNAL" - calendar component: - - STATUS:DRAFT - -3.8.1.12. Summary - - Property Name: SUMMARY - - Purpose: This property defines a short summary or subject for the - calendar component. - - Value Type: TEXT - - Property Parameters: IANA, non-standard, alternate text - representation, and language property parameters can be specified - on this property. - - Conformance: The property can be specified in "VEVENT", "VTODO", - "VJOURNAL", or "VALARM" calendar components. - - Description: This property is used in the "VEVENT", "VTODO", and - "VJOURNAL" calendar components to capture a short, one-line - summary about the activity or journal entry. - - This property is used in the "VALARM" calendar component to - capture the subject of an EMAIL category of alarm. - - Format Definition: This property is defined by the following - notation: - - - - - - -Desruisseaux Standards Track [Page 93] - -RFC 5545 iCalendar September 2009 - - - summary = "SUMMARY" summparam ":" text CRLF - - summparam = *( - ; - ; The following are OPTIONAL, - ; but MUST NOT occur more than once. - ; - (";" altrepparam) / (";" languageparam) / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - (";" other-param) - ; - ) - - Example: The following is an example of this property: - - SUMMARY:Department Party - -3.8.2. Date and Time Component Properties - - The following properties specify date and time related information in - calendar components. - -3.8.2.1. Date-Time Completed - - Property Name: COMPLETED - - Purpose: This property defines the date and time that a to-do was - actually completed. - - Value Type: DATE-TIME - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: The property can be specified in a "VTODO" calendar - component. The value MUST be specified as a date with UTC time. - - Description: This property defines the date and time that a to-do - was actually completed. - - Format Definition: This property is defined by the following - notation: - - - - - - -Desruisseaux Standards Track [Page 94] - -RFC 5545 iCalendar September 2009 - - - completed = "COMPLETED" compparam ":" date-time CRLF - - compparam = *(";" other-param) - - Example: The following is an example of this property: - - COMPLETED:19960401T150000Z - -3.8.2.2. Date-Time End - - Property Name: DTEND - - Purpose: This property specifies the date and time that a calendar - component ends. - - Value Type: The default value type is DATE-TIME. The value type can - be set to a DATE value type. - - Property Parameters: IANA, non-standard, value data type, and time - zone identifier property parameters can be specified on this - property. - - Conformance: This property can be specified in "VEVENT" or - "VFREEBUSY" calendar components. - - Description: Within the "VEVENT" calendar component, this property - defines the date and time by which the event ends. The value type - of this property MUST be the same as the "DTSTART" property, and - its value MUST be later in time than the value of the "DTSTART" - property. Furthermore, this property MUST be specified as a date - with local time if and only if the "DTSTART" property is also - specified as a date with local time. - - Within the "VFREEBUSY" calendar component, this property defines - the end date and time for the free or busy time information. The - time MUST be specified in the UTC time format. The value MUST be - later in time than the value of the "DTSTART" property. - - Format Definition: This property is defined by the following - notation: - - - - - - - - - - - -Desruisseaux Standards Track [Page 95] - -RFC 5545 iCalendar September 2009 - - - dtend = "DTEND" dtendparam ":" dtendval CRLF - - dtendparam = *( - ; - ; The following are OPTIONAL, - ; but MUST NOT occur more than once. - ; - (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / - (";" tzidparam) / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - (";" other-param) - ; - ) - - dtendval = date-time / date - ;Value MUST match value type - - Example: The following is an example of this property: - - DTEND:19960401T150000Z - - DTEND;VALUE=DATE:19980704 - -3.8.2.3. Date-Time Due - - Property Name: DUE - - Purpose: This property defines the date and time that a to-do is - expected to be completed. - - Value Type: The default value type is DATE-TIME. The value type can - be set to a DATE value type. - - Property Parameters: IANA, non-standard, value data type, and time - zone identifier property parameters can be specified on this - property. - - Conformance: The property can be specified once in a "VTODO" - calendar component. - - Description: This property defines the date and time before which a - to-do is expected to be completed. For cases where this property - is specified in a "VTODO" calendar component that also specifies a - "DTSTART" property, the value type of this property MUST be the - same as the "DTSTART" property, and the value of this property - - - -Desruisseaux Standards Track [Page 96] - -RFC 5545 iCalendar September 2009 - - - MUST be later in time than the value of the "DTSTART" property. - Furthermore, this property MUST be specified as a date with local - time if and only if the "DTSTART" property is also specified as a - date with local time. - - Format Definition: This property is defined by the following - notation: - - due = "DUE" dueparam ":" dueval CRLF - - dueparam = *( - ; - ; The following are OPTIONAL, - ; but MUST NOT occur more than once. - ; - (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / - (";" tzidparam) / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - (";" other-param) - ; - ) - - dueval = date-time / date - ;Value MUST match value type - - Example: The following is an example of this property: - - DUE:19980430T000000Z - -3.8.2.4. Date-Time Start - - Property Name: DTSTART - - Purpose: This property specifies when the calendar component begins. - - Value Type: The default value type is DATE-TIME. The time value - MUST be one of the forms defined for the DATE-TIME value type. - The value type can be set to a DATE value type. - - Property Parameters: IANA, non-standard, value data type, and time - zone identifier property parameters can be specified on this - property. - - Conformance: This property can be specified once in the "VEVENT", - "VTODO", or "VFREEBUSY" calendar components as well as in the - - - -Desruisseaux Standards Track [Page 97] - -RFC 5545 iCalendar September 2009 - - - "STANDARD" and "DAYLIGHT" sub-components. This property is - REQUIRED in all types of recurring calendar components that - specify the "RRULE" property. This property is also REQUIRED in - "VEVENT" calendar components contained in iCalendar objects that - don't specify the "METHOD" property. - - Description: Within the "VEVENT" calendar component, this property - defines the start date and time for the event. - - Within the "VFREEBUSY" calendar component, this property defines - the start date and time for the free or busy time information. - The time MUST be specified in UTC time. - - Within the "STANDARD" and "DAYLIGHT" sub-components, this property - defines the effective start date and time for a time zone - specification. This property is REQUIRED within each "STANDARD" - and "DAYLIGHT" sub-components included in "VTIMEZONE" calendar - components and MUST be specified as a date with local time without - the "TZID" property parameter. - - Format Definition: This property is defined by the following - notation: - - dtstart = "DTSTART" dtstparam ":" dtstval CRLF - - dtstparam = *( - ; - ; The following are OPTIONAL, - ; but MUST NOT occur more than once. - ; - (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / - (";" tzidparam) / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - (";" other-param) - ; - ) - - dtstval = date-time / date - ;Value MUST match value type - - Example: The following is an example of this property: - - DTSTART:19980118T073000Z - - - - - -Desruisseaux Standards Track [Page 98] - -RFC 5545 iCalendar September 2009 - - -3.8.2.5. Duration - - Property Name: DURATION - - Purpose: This property specifies a positive duration of time. - - Value Type: DURATION - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: This property can be specified in "VEVENT", "VTODO", or - "VALARM" calendar components. - - Description: In a "VEVENT" calendar component the property may be - used to specify a duration of the event, instead of an explicit - end DATE-TIME. In a "VTODO" calendar component the property may - be used to specify a duration for the to-do, instead of an - explicit due DATE-TIME. In a "VALARM" calendar component the - property may be used to specify the delay period prior to - repeating an alarm. When the "DURATION" property relates to a - "DTSTART" property that is specified as a DATE value, then the - "DURATION" property MUST be specified as a "dur-day" or "dur-week" - value. - - Format Definition: This property is defined by the following - notation: - - duration = "DURATION" durparam ":" dur-value CRLF - ;consisting of a positive duration of time. - - durparam = *(";" other-param) - - Example: The following is an example of this property that specifies - an interval of time of one hour and zero minutes and zero seconds: - - DURATION:PT1H0M0S - - The following is an example of this property that specifies an - interval of time of 15 minutes. - - DURATION:PT15M - - - - - - - - - -Desruisseaux Standards Track [Page 99] - -RFC 5545 iCalendar September 2009 - - -3.8.2.6. Free/Busy Time - - Property Name: FREEBUSY - - Purpose: This property defines one or more free or busy time - intervals. - - Value Type: PERIOD - - Property Parameters: IANA, non-standard, and free/busy time type - property parameters can be specified on this property. - - Conformance: The property can be specified in a "VFREEBUSY" calendar - component. - - Description: These time periods can be specified as either a start - and end DATE-TIME or a start DATE-TIME and DURATION. The date and - time MUST be a UTC time format. - - "FREEBUSY" properties within the "VFREEBUSY" calendar component - SHOULD be sorted in ascending order, based on start time and then - end time, with the earliest periods first. - - The "FREEBUSY" property can specify more than one value, separated - by the COMMA character. In such cases, the "FREEBUSY" property - values MUST all be of the same "FBTYPE" property parameter type - (e.g., all values of a particular "FBTYPE" listed together in a - single property). - - Format Definition: This property is defined by the following - notation: - - freebusy = "FREEBUSY" fbparam ":" fbvalue CRLF - - fbparam = *( - ; - ; The following is OPTIONAL, - ; but MUST NOT occur more than once. - ; - (";" fbtypeparam) / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - (";" other-param) - ; - ) - - - - -Desruisseaux Standards Track [Page 100] - -RFC 5545 iCalendar September 2009 - - - fbvalue = period *("," period) - ;Time value MUST be in the UTC time format. - - Example: The following are some examples of this property: - - FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:19970308T160000Z/PT8H30M - - FREEBUSY;FBTYPE=FREE:19970308T160000Z/PT3H,19970308T200000Z/PT1H - - FREEBUSY;FBTYPE=FREE:19970308T160000Z/PT3H,19970308T200000Z/PT1H - ,19970308T230000Z/19970309T000000Z - -3.8.2.7. Time Transparency - - Property Name: TRANSP - - Purpose: This property defines whether or not an event is - transparent to busy time searches. - - Value Type: TEXT - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: This property can be specified once in a "VEVENT" - calendar component. - - Description: Time Transparency is the characteristic of an event - that determines whether it appears to consume time on a calendar. - Events that consume actual time for the individual or resource - associated with the calendar SHOULD be recorded as OPAQUE, - allowing them to be detected by free/busy time searches. Other - events, which do not take up the individual's (or resource's) time - SHOULD be recorded as TRANSPARENT, making them invisible to free/ - busy time searches. - - Format Definition: This property is defined by the following - notation: - - transp = "TRANSP" transparam ":" transvalue CRLF - - transparam = *(";" other-param) - - transvalue = "OPAQUE" - ;Blocks or opaque on busy time searches. - / "TRANSPARENT" - ;Transparent on busy time searches. - ;Default value is OPAQUE - - - -Desruisseaux Standards Track [Page 101] - -RFC 5545 iCalendar September 2009 - - - Example: The following is an example of this property for an event - that is transparent or does not block on free/busy time searches: - - TRANSP:TRANSPARENT - - The following is an example of this property for an event that is - opaque or blocks on free/busy time searches: - - TRANSP:OPAQUE - -3.8.3. Time Zone Component Properties - - The following properties specify time zone information in calendar - components. - -3.8.3.1. Time Zone Identifier - - Property Name: TZID - - Purpose: This property specifies the text value that uniquely - identifies the "VTIMEZONE" calendar component in the scope of an - iCalendar object. - - Value Type: TEXT - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: This property MUST be specified in a "VTIMEZONE" - calendar component. - - Description: This is the label by which a time zone calendar - component is referenced by any iCalendar properties whose value - type is either DATE-TIME or TIME and not intended to specify a UTC - or a "floating" time. The presence of the SOLIDUS character as a - prefix, indicates that this "TZID" represents an unique ID in a - globally defined time zone registry (when such registry is - defined). - - Note: This document does not define a naming convention for - time zone identifiers. Implementers may want to use the naming - conventions defined in existing time zone specifications such - as the public-domain TZ database [TZDB]. The specification of - globally unique time zone identifiers is not addressed by this - document and is left for future study. - - - - - - -Desruisseaux Standards Track [Page 102] - -RFC 5545 iCalendar September 2009 - - - Format Definition: This property is defined by the following - notation: - - tzid = "TZID" tzidpropparam ":" [tzidprefix] text CRLF - - tzidpropparam = *(";" other-param) - - ;tzidprefix = "/" - ; Defined previously. Just listed here for reader convenience. - - Example: The following are examples of non-globally unique time zone - identifiers: - - TZID:America/New_York - - TZID:America/Los_Angeles - - The following is an example of a fictitious globally unique time - zone identifier: - - TZID:/example.org/America/New_York - -3.8.3.2. Time Zone Name - - Property Name: TZNAME - - Purpose: This property specifies the customary designation for a - time zone description. - - Value Type: TEXT - - Property Parameters: IANA, non-standard, and language property - parameters can be specified on this property. - - Conformance: This property can be specified in "STANDARD" and - "DAYLIGHT" sub-components. - - Description: This property specifies a customary name that can be - used when displaying dates that occur during the observance - defined by the time zone sub-component. - - Format Definition: This property is defined by the following - notation: - - - - - - - - -Desruisseaux Standards Track [Page 103] - -RFC 5545 iCalendar September 2009 - - - tzname = "TZNAME" tznparam ":" text CRLF - - tznparam = *( - ; - ; The following is OPTIONAL, - ; but MUST NOT occur more than once. - ; - (";" languageparam) / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - (";" other-param) - ; - ) - - Example: The following are examples of this property: - - TZNAME:EST - - TZNAME;LANGUAGE=fr-CA:HNE - -3.8.3.3. Time Zone Offset From - - Property Name: TZOFFSETFROM - - Purpose: This property specifies the offset that is in use prior to - this time zone observance. - - Value Type: UTC-OFFSET - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: This property MUST be specified in "STANDARD" and - "DAYLIGHT" sub-components. - - Description: This property specifies the offset that is in use prior - to this time observance. It is used to calculate the absolute - time at which the transition to a given observance takes place. - This property MUST only be specified in a "VTIMEZONE" calendar - component. A "VTIMEZONE" calendar component MUST include this - property. The property value is a signed numeric indicating the - number of hours and possibly minutes from UTC. Positive numbers - represent time zones east of the prime meridian, or ahead of UTC. - Negative numbers represent time zones west of the prime meridian, - or behind UTC. - - - - -Desruisseaux Standards Track [Page 104] - -RFC 5545 iCalendar September 2009 - - - Format Definition: This property is defined by the following - notation: - - tzoffsetfrom = "TZOFFSETFROM" frmparam ":" utc-offset - CRLF - - frmparam = *(";" other-param) - - Example: The following are examples of this property: - - TZOFFSETFROM:-0500 - - TZOFFSETFROM:+1345 - -3.8.3.4. Time Zone Offset To - - Property Name: TZOFFSETTO - - Purpose: This property specifies the offset that is in use in this - time zone observance. - - Value Type: UTC-OFFSET - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: This property MUST be specified in "STANDARD" and - "DAYLIGHT" sub-components. - - Description: This property specifies the offset that is in use in - this time zone observance. It is used to calculate the absolute - time for the new observance. The property value is a signed - numeric indicating the number of hours and possibly minutes from - UTC. Positive numbers represent time zones east of the prime - meridian, or ahead of UTC. Negative numbers represent time zones - west of the prime meridian, or behind UTC. - - Format Definition: This property is defined by the following - notation: - - tzoffsetto = "TZOFFSETTO" toparam ":" utc-offset CRLF - - toparam = *(";" other-param) - - - - - - - - -Desruisseaux Standards Track [Page 105] - -RFC 5545 iCalendar September 2009 - - - Example: The following are examples of this property: - - TZOFFSETTO:-0400 - - TZOFFSETTO:+1245 - -3.8.3.5. Time Zone URL - - Property Name: TZURL - - Purpose: This property provides a means for a "VTIMEZONE" component - to point to a network location that can be used to retrieve an up- - to-date version of itself. - - Value Type: URI - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: This property can be specified in a "VTIMEZONE" - calendar component. - - Description: This property provides a means for a "VTIMEZONE" - component to point to a network location that can be used to - retrieve an up-to-date version of itself. This provides a hook to - handle changes government bodies impose upon time zone - definitions. Retrieval of this resource results in an iCalendar - object containing a single "VTIMEZONE" component and a "METHOD" - property set to PUBLISH. - - Format Definition: This property is defined by the following - notation: - - tzurl = "TZURL" tzurlparam ":" uri CRLF - - tzurlparam = *(";" other-param) - - Example: The following is an example of this property: - - TZURL:http://timezones.example.org/tz/America-Los_Angeles.ics - -3.8.4. Relationship Component Properties - - The following properties specify relationship information in calendar - components. - - - - - - -Desruisseaux Standards Track [Page 106] - -RFC 5545 iCalendar September 2009 - - -3.8.4.1. Attendee - - Property Name: ATTENDEE - - Purpose: This property defines an "Attendee" within a calendar - component. - - Value Type: CAL-ADDRESS - - Property Parameters: IANA, non-standard, language, calendar user - type, group or list membership, participation role, participation - status, RSVP expectation, delegatee, delegator, sent by, common - name, or directory entry reference property parameters can be - specified on this property. - - Conformance: This property MUST be specified in an iCalendar object - that specifies a group-scheduled calendar entity. This property - MUST NOT be specified in an iCalendar object when publishing the - calendar information (e.g., NOT in an iCalendar object that - specifies the publication of a calendar user's busy time, event, - to-do, or journal). This property is not specified in an - iCalendar object that specifies only a time zone definition or - that defines calendar components that are not group-scheduled - components, but are components only on a single user's calendar. - - Description: This property MUST only be specified within calendar - components to specify participants, non-participants, and the - chair of a group-scheduled calendar entity. The property is - specified within an "EMAIL" category of the "VALARM" calendar - component to specify an email address that is to receive the email - type of iCalendar alarm. - - The property parameter "CN" is for the common or displayable name - associated with the calendar address; "ROLE", for the intended - role that the attendee will have in the calendar component; - "PARTSTAT", for the status of the attendee's participation; - "RSVP", for indicating whether the favor of a reply is requested; - "CUTYPE", to indicate the type of calendar user; "MEMBER", to - indicate the groups that the attendee belongs to; "DELEGATED-TO", - to indicate the calendar users that the original request was - delegated to; and "DELEGATED-FROM", to indicate whom the request - was delegated from; "SENT-BY", to indicate whom is acting on - behalf of the "ATTENDEE"; and "DIR", to indicate the URI that - points to the directory information corresponding to the attendee. - These property parameters can be specified on an "ATTENDEE" - property in either a "VEVENT", "VTODO", or "VJOURNAL" calendar - component. They MUST NOT be specified in an "ATTENDEE" property - in a "VFREEBUSY" or "VALARM" calendar component. If the - - - -Desruisseaux Standards Track [Page 107] - -RFC 5545 iCalendar September 2009 - - - "LANGUAGE" property parameter is specified, the identified - language applies to the "CN" parameter. - - A recipient delegated a request MUST inherit the "RSVP" and "ROLE" - values from the attendee that delegated the request to them. - - Multiple attendees can be specified by including multiple - "ATTENDEE" properties within the calendar component. - - Format Definition: This property is defined by the following - notation: - - attendee = "ATTENDEE" attparam ":" cal-address CRLF - - attparam = *( - ; - ; The following are OPTIONAL, - ; but MUST NOT occur more than once. - ; - (";" cutypeparam) / (";" memberparam) / - (";" roleparam) / (";" partstatparam) / - (";" rsvpparam) / (";" deltoparam) / - (";" delfromparam) / (";" sentbyparam) / - (";" cnparam) / (";" dirparam) / - (";" languageparam) / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - (";" other-param) - ; - ) - - Example: The following are examples of this property's use for a - to-do: - - ATTENDEE;MEMBER="mailto:DEV-GROUP@example.com": - mailto:joecool@example.com - ATTENDEE;DELEGATED-FROM="mailto:immud@example.com": - mailto:ildoit@example.com - - - - - - - - - - - -Desruisseaux Standards Track [Page 108] - -RFC 5545 iCalendar September 2009 - - - The following is an example of this property used for specifying - multiple attendees to an event: - - ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;CN=Henry - Cabot:mailto:hcabot@example.com - ATTENDEE;ROLE=REQ-PARTICIPANT;DELEGATED-FROM="mailto:bob@ - example.com";PARTSTAT=ACCEPTED;CN=Jane Doe:mailto:jdoe@ - example.com - - The following is an example of this property with a URI to the - directory information associated with the attendee: - - ATTENDEE;CN=John Smith;DIR="ldap://example.com:6666/o=ABC% - 20Industries,c=US???(cn=Jim%20Dolittle)":mailto:jimdo@ - example.com - - The following is an example of this property with "delegatee" and - "delegator" information for an event: - - ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;DELEGATED-FROM= - "mailto:iamboss@example.com";CN=Henry Cabot:mailto:hcabot@ - example.com - ATTENDEE;ROLE=NON-PARTICIPANT;PARTSTAT=DELEGATED;DELEGATED-TO= - "mailto:hcabot@example.com";CN=The Big Cheese:mailto:iamboss - @example.com - ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;CN=Jane Doe - :mailto:jdoe@example.com - - Example: The following is an example of this property's use when - another calendar user is acting on behalf of the "Attendee": - - ATTENDEE;SENT-BY=mailto:jan_doe@example.com;CN=John Smith: - mailto:jsmith@example.com - -3.8.4.2. Contact - - Property Name: CONTACT - - Purpose: This property is used to represent contact information or - alternately a reference to contact information associated with the - calendar component. - - Value Type: TEXT - - Property Parameters: IANA, non-standard, alternate text - representation, and language property parameters can be specified - on this property. - - - - -Desruisseaux Standards Track [Page 109] - -RFC 5545 iCalendar September 2009 - - - Conformance: This property can be specified in a "VEVENT", "VTODO", - "VJOURNAL", or "VFREEBUSY" calendar component. - - Description: The property value consists of textual contact - information. An alternative representation for the property value - can also be specified that refers to a URI pointing to an - alternate form, such as a vCard [RFC2426], for the contact - information. - - Format Definition: This property is defined by the following - notation: - - contact = "CONTACT" contparam ":" text CRLF - - contparam = *( - ; - ; The following are OPTIONAL, - ; but MUST NOT occur more than once. - ; - (";" altrepparam) / (";" languageparam) / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - (";" other-param) - ; - ) - - Example: The following is an example of this property referencing - textual contact information: - - CONTACT:Jim Dolittle\, ABC Industries\, +1-919-555-1234 - - The following is an example of this property with an alternate - representation of an LDAP URI to a directory entry containing the - contact information: - - CONTACT;ALTREP="ldap://example.com:6666/o=ABC%20Industries\, - c=US???(cn=Jim%20Dolittle)":Jim Dolittle\, ABC Industries\, - +1-919-555-1234 - - The following is an example of this property with an alternate - representation of a MIME body part containing the contact - information, such as a vCard [RFC2426] embedded in a text/ - directory media type [RFC2425]: - - CONTACT;ALTREP="CID:part3.msg970930T083000SILVER@example.com": - Jim Dolittle\, ABC Industries\, +1-919-555-1234 - - - -Desruisseaux Standards Track [Page 110] - -RFC 5545 iCalendar September 2009 - - - The following is an example of this property referencing a network - resource, such as a vCard [RFC2426] object containing the contact - information: - - CONTACT;ALTREP="http://example.com/pdi/jdoe.vcf":Jim - Dolittle\, ABC Industries\, +1-919-555-1234 - -3.8.4.3. Organizer - - Property Name: ORGANIZER - - Purpose: This property defines the organizer for a calendar - component. - - Value Type: CAL-ADDRESS - - Property Parameters: IANA, non-standard, language, common name, - directory entry reference, and sent-by property parameters can be - specified on this property. - - Conformance: This property MUST be specified in an iCalendar object - that specifies a group-scheduled calendar entity. This property - MUST be specified in an iCalendar object that specifies the - publication of a calendar user's busy time. This property MUST - NOT be specified in an iCalendar object that specifies only a time - zone definition or that defines calendar components that are not - group-scheduled components, but are components only on a single - user's calendar. - - Description: This property is specified within the "VEVENT", - "VTODO", and "VJOURNAL" calendar components to specify the - organizer of a group-scheduled calendar entity. The property is - specified within the "VFREEBUSY" calendar component to specify the - calendar user requesting the free or busy time. When publishing a - "VFREEBUSY" calendar component, the property is used to specify - the calendar that the published busy time came from. - - The property has the property parameters "CN", for specifying the - common or display name associated with the "Organizer", "DIR", for - specifying a pointer to the directory information associated with - the "Organizer", "SENT-BY", for specifying another calendar user - that is acting on behalf of the "Organizer". The non-standard - parameters may also be specified on this property. If the - "LANGUAGE" property parameter is specified, the identified - language applies to the "CN" parameter value. - - - - - - -Desruisseaux Standards Track [Page 111] - -RFC 5545 iCalendar September 2009 - - - Format Definition: This property is defined by the following - notation: - - organizer = "ORGANIZER" orgparam ":" - cal-address CRLF - - orgparam = *( - ; - ; The following are OPTIONAL, - ; but MUST NOT occur more than once. - ; - (";" cnparam) / (";" dirparam) / (";" sentbyparam) / - (";" languageparam) / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - (";" other-param) - ; - ) - - Example: The following is an example of this property: - - ORGANIZER;CN=John Smith:mailto:jsmith@example.com - - The following is an example of this property with a pointer to the - directory information associated with the organizer: - - ORGANIZER;CN=JohnSmith;DIR="ldap://example.com:6666/o=DC%20Ass - ociates,c=US???(cn=John%20Smith)":mailto:jsmith@example.com - - The following is an example of this property used by another - calendar user who is acting on behalf of the organizer, with - responses intended to be sent back to the organizer, not the other - calendar user: - - ORGANIZER;SENT-BY="mailto:jane_doe@example.com": - mailto:jsmith@example.com - -3.8.4.4. Recurrence ID - - Property Name: RECURRENCE-ID - - Purpose: This property is used in conjunction with the "UID" and - "SEQUENCE" properties to identify a specific instance of a - recurring "VEVENT", "VTODO", or "VJOURNAL" calendar component. - The property value is the original value of the "DTSTART" property - of the recurrence instance. - - - -Desruisseaux Standards Track [Page 112] - -RFC 5545 iCalendar September 2009 - - - Value Type: The default value type is DATE-TIME. The value type can - be set to a DATE value type. This property MUST have the same - value type as the "DTSTART" property contained within the - recurring component. Furthermore, this property MUST be specified - as a date with local time if and only if the "DTSTART" property - contained within the recurring component is specified as a date - with local time. - - Property Parameters: IANA, non-standard, value data type, time zone - identifier, and recurrence identifier range parameters can be - specified on this property. - - Conformance: This property can be specified in an iCalendar object - containing a recurring calendar component. - - Description: The full range of calendar components specified by a - recurrence set is referenced by referring to just the "UID" - property value corresponding to the calendar component. The - "RECURRENCE-ID" property allows the reference to an individual - instance within the recurrence set. - - If the value of the "DTSTART" property is a DATE type value, then - the value MUST be the calendar date for the recurrence instance. - - The DATE-TIME value is set to the time when the original - recurrence instance would occur; meaning that if the intent is to - change a Friday meeting to Thursday, the DATE-TIME is still set to - the original Friday meeting. - - The "RECURRENCE-ID" property is used in conjunction with the "UID" - and "SEQUENCE" properties to identify a particular instance of a - recurring event, to-do, or journal. For a given pair of "UID" and - "SEQUENCE" property values, the "RECURRENCE-ID" value for a - recurrence instance is fixed. - - The "RANGE" parameter is used to specify the effective range of - recurrence instances from the instance specified by the - "RECURRENCE-ID" property value. The value for the range parameter - can only be "THISANDFUTURE" to indicate a range defined by the - given recurrence instance and all subsequent instances. - Subsequent instances are determined by their "RECURRENCE-ID" value - and not their current scheduled start time. Subsequent instances - defined in separate components are not impacted by the given - recurrence instance. When the given recurrence instance is - rescheduled, all subsequent instances are also rescheduled by the - same time difference. For instance, if the given recurrence - instance is rescheduled to start 2 hours later, then all - subsequent instances are also rescheduled 2 hours later. - - - -Desruisseaux Standards Track [Page 113] - -RFC 5545 iCalendar September 2009 - - - Similarly, if the duration of the given recurrence instance is - modified, then all subsequence instances are also modified to have - this same duration. - - Note: The "RANGE" parameter may not be appropriate to - reschedule specific subsequent instances of complex recurring - calendar component. Assuming an unbounded recurring calendar - component scheduled to occur on Mondays and Wednesdays, the - "RANGE" parameter could not be used to reschedule only the - future Monday instances to occur on Tuesday instead. In such - cases, the calendar application could simply truncate the - unbounded recurring calendar component (i.e., with the "COUNT" - or "UNTIL" rule parts), and create two new unbounded recurring - calendar components for the future instances. - - Format Definition: This property is defined by the following - notation: - - recurid = "RECURRENCE-ID" ridparam ":" ridval CRLF - - ridparam = *( - ; - ; The following are OPTIONAL, - ; but MUST NOT occur more than once. - ; - (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / - (";" tzidparam) / (";" rangeparam) / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - (";" other-param) - ; - ) - - ridval = date-time / date - ;Value MUST match value type - - Example: The following are examples of this property: - - RECURRENCE-ID;VALUE=DATE:19960401 - - RECURRENCE-ID;RANGE=THISANDFUTURE:19960120T120000Z - - - - - - - - -Desruisseaux Standards Track [Page 114] - -RFC 5545 iCalendar September 2009 - - -3.8.4.5. Related To - - Property Name: RELATED-TO - - Purpose: This property is used to represent a relationship or - reference between one calendar component and another. - - Value Type: TEXT - - Property Parameters: IANA, non-standard, and relationship type - property parameters can be specified on this property. - - Conformance: This property can be specified in the "VEVENT", - "VTODO", and "VJOURNAL" calendar components. - - Description: The property value consists of the persistent, globally - unique identifier of another calendar component. This value would - be represented in a calendar component by the "UID" property. - - By default, the property value points to another calendar - component that has a PARENT relationship to the referencing - object. The "RELTYPE" property parameter is used to either - explicitly state the default PARENT relationship type to the - referenced calendar component or to override the default PARENT - relationship type and specify either a CHILD or SIBLING - relationship. The PARENT relationship indicates that the calendar - component is a subordinate of the referenced calendar component. - The CHILD relationship indicates that the calendar component is a - superior of the referenced calendar component. The SIBLING - relationship indicates that the calendar component is a peer of - the referenced calendar component. - - Changes to a calendar component referenced by this property can - have an implicit impact on the related calendar component. For - example, if a group event changes its start or end date or time, - then the related, dependent events will need to have their start - and end dates changed in a corresponding way. Similarly, if a - PARENT calendar component is cancelled or deleted, then there is - an implied impact to the related CHILD calendar components. This - property is intended only to provide information on the - relationship of calendar components. It is up to the target - calendar system to maintain any property implications of this - relationship. - - - - - - - - -Desruisseaux Standards Track [Page 115] - -RFC 5545 iCalendar September 2009 - - - Format Definition: This property is defined by the following - notation: - - related = "RELATED-TO" relparam ":" text CRLF - - relparam = *( - ; - ; The following is OPTIONAL, - ; but MUST NOT occur more than once. - ; - (";" reltypeparam) / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - (";" other-param) - ; - ) - - The following is an example of this property: - - RELATED-TO:jsmith.part7.19960817T083000.xyzMail@example.com - - RELATED-TO:19960401-080045-4000F192713-0052@example.com - -3.8.4.6. Uniform Resource Locator - - Property Name: URL - - Purpose: This property defines a Uniform Resource Locator (URL) - associated with the iCalendar object. - - Value Type: URI - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: This property can be specified once in the "VEVENT", - "VTODO", "VJOURNAL", or "VFREEBUSY" calendar components. - - Description: This property may be used in a calendar component to - convey a location where a more dynamic rendition of the calendar - information associated with the calendar component can be found. - This memo does not attempt to standardize the form of the URI, nor - the format of the resource pointed to by the property value. If - the URL property and Content-Location MIME header are both - specified, they MUST point to the same resource. - - - - -Desruisseaux Standards Track [Page 116] - -RFC 5545 iCalendar September 2009 - - - Format Definition: This property is defined by the following - notation: - - url = "URL" urlparam ":" uri CRLF - - urlparam = *(";" other-param) - - Example: The following is an example of this property: - - URL:http://example.com/pub/calendars/jsmith/mytime.ics - -3.8.4.7. Unique Identifier - - Property Name: UID - - Purpose: This property defines the persistent, globally unique - identifier for the calendar component. - - Value Type: TEXT - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: The property MUST be specified in the "VEVENT", - "VTODO", "VJOURNAL", or "VFREEBUSY" calendar components. - - Description: The "UID" itself MUST be a globally unique identifier. - The generator of the identifier MUST guarantee that the identifier - is unique. There are several algorithms that can be used to - accomplish this. A good method to assure uniqueness is to put the - domain name or a domain literal IP address of the host on which - the identifier was created on the right-hand side of an "@", and - on the left-hand side, put a combination of the current calendar - date and time of day (i.e., formatted in as a DATE-TIME value) - along with some other currently unique (perhaps sequential) - identifier available on the system (for example, a process id - number). Using a DATE-TIME value on the left-hand side and a - domain name or domain literal on the right-hand side makes it - possible to guarantee uniqueness since no two hosts should be - using the same domain name or IP address at the same time. Though - other algorithms will work, it is RECOMMENDED that the right-hand - side contain some domain identifier (either of the host itself or - otherwise) such that the generator of the message identifier can - guarantee the uniqueness of the left-hand side within the scope of - that domain. - - This is the method for correlating scheduling messages with the - referenced "VEVENT", "VTODO", or "VJOURNAL" calendar component. - - - -Desruisseaux Standards Track [Page 117] - -RFC 5545 iCalendar September 2009 - - - The full range of calendar components specified by a recurrence - set is referenced by referring to just the "UID" property value - corresponding to the calendar component. The "RECURRENCE-ID" - property allows the reference to an individual instance within the - recurrence set. - - This property is an important method for group-scheduling - applications to match requests with later replies, modifications, - or deletion requests. Calendaring and scheduling applications - MUST generate this property in "VEVENT", "VTODO", and "VJOURNAL" - calendar components to assure interoperability with other group- - scheduling applications. This identifier is created by the - calendar system that generates an iCalendar object. - - Implementations MUST be able to receive and persist values of at - least 255 octets for this property, but they MUST NOT truncate - values in the middle of a UTF-8 multi-octet sequence. - - Format Definition: This property is defined by the following - notation: - - uid = "UID" uidparam ":" text CRLF - - uidparam = *(";" other-param) - - Example: The following is an example of this property: - - UID:19960401T080045Z-4000F192713-0052@example.com - -3.8.5. Recurrence Component Properties - - The following properties specify recurrence information in calendar - components. - -3.8.5.1. Exception Date-Times - - Property Name: EXDATE - - Purpose: This property defines the list of DATE-TIME exceptions for - recurring events, to-dos, journal entries, or time zone - definitions. - - Value Type: The default value type for this property is DATE-TIME. - The value type can be set to DATE. - - Property Parameters: IANA, non-standard, value data type, and time - zone identifier property parameters can be specified on this - property. - - - -Desruisseaux Standards Track [Page 118] - -RFC 5545 iCalendar September 2009 - - - Conformance: This property can be specified in recurring "VEVENT", - "VTODO", and "VJOURNAL" calendar components as well as in the - "STANDARD" and "DAYLIGHT" sub-components of the "VTIMEZONE" - calendar component. - - Description: The exception dates, if specified, are used in - computing the recurrence set. The recurrence set is the complete - set of recurrence instances for a calendar component. The - recurrence set is generated by considering the initial "DTSTART" - property along with the "RRULE", "RDATE", and "EXDATE" properties - contained within the recurring component. The "DTSTART" property - defines the first instance in the recurrence set. The "DTSTART" - property value SHOULD match the pattern of the recurrence rule, if - specified. The recurrence set generated with a "DTSTART" property - value that doesn't match the pattern of the rule is undefined. - The final recurrence set is generated by gathering all of the - start DATE-TIME values generated by any of the specified "RRULE" - and "RDATE" properties, and then excluding any start DATE-TIME - values specified by "EXDATE" properties. This implies that start - DATE-TIME values specified by "EXDATE" properties take precedence - over those specified by inclusion properties (i.e., "RDATE" and - "RRULE"). When duplicate instances are generated by the "RRULE" - and "RDATE" properties, only one recurrence is considered. - Duplicate instances are ignored. - - The "EXDATE" property can be used to exclude the value specified - in "DTSTART". However, in such cases, the original "DTSTART" date - MUST still be maintained by the calendaring and scheduling system - because the original "DTSTART" value has inherent usage - dependencies by other properties such as the "RECURRENCE-ID". - - Format Definition: This property is defined by the following - notation: - - - - - - - - - - - - - - - - - - -Desruisseaux Standards Track [Page 119] - -RFC 5545 iCalendar September 2009 - - - exdate = "EXDATE" exdtparam ":" exdtval *("," exdtval) CRLF - - exdtparam = *( - ; - ; The following are OPTIONAL, - ; but MUST NOT occur more than once. - ; - (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / - ; - (";" tzidparam) / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - (";" other-param) - ; - ) - - exdtval = date-time / date - ;Value MUST match value type - - Example: The following is an example of this property: - - EXDATE:19960402T010000Z,19960403T010000Z,19960404T010000Z - -3.8.5.2. Recurrence Date-Times - - Property Name: RDATE - - Purpose: This property defines the list of DATE-TIME values for - recurring events, to-dos, journal entries, or time zone - definitions. - - Value Type: The default value type for this property is DATE-TIME. - The value type can be set to DATE or PERIOD. - - Property Parameters: IANA, non-standard, value data type, and time - zone identifier property parameters can be specified on this - property. - - Conformance: This property can be specified in recurring "VEVENT", - "VTODO", and "VJOURNAL" calendar components as well as in the - "STANDARD" and "DAYLIGHT" sub-components of the "VTIMEZONE" - calendar component. - - Description: This property can appear along with the "RRULE" - property to define an aggregate set of repeating occurrences. - When they both appear in a recurring component, the recurrence - - - -Desruisseaux Standards Track [Page 120] - -RFC 5545 iCalendar September 2009 - - - instances are defined by the union of occurrences defined by both - the "RDATE" and "RRULE". - - The recurrence dates, if specified, are used in computing the - recurrence set. The recurrence set is the complete set of - recurrence instances for a calendar component. The recurrence set - is generated by considering the initial "DTSTART" property along - with the "RRULE", "RDATE", and "EXDATE" properties contained - within the recurring component. The "DTSTART" property defines - the first instance in the recurrence set. The "DTSTART" property - value SHOULD match the pattern of the recurrence rule, if - specified. The recurrence set generated with a "DTSTART" property - value that doesn't match the pattern of the rule is undefined. - The final recurrence set is generated by gathering all of the - start DATE-TIME values generated by any of the specified "RRULE" - and "RDATE" properties, and then excluding any start DATE-TIME - values specified by "EXDATE" properties. This implies that start - DATE-TIME values specified by "EXDATE" properties take precedence - over those specified by inclusion properties (i.e., "RDATE" and - "RRULE"). Where duplicate instances are generated by the "RRULE" - and "RDATE" properties, only one recurrence is considered. - Duplicate instances are ignored. - - Format Definition: This property is defined by the following - notation: - - rdate = "RDATE" rdtparam ":" rdtval *("," rdtval) CRLF - - rdtparam = *( - ; - ; The following are OPTIONAL, - ; but MUST NOT occur more than once. - ; - (";" "VALUE" "=" ("DATE-TIME" / "DATE" / "PERIOD")) / - (";" tzidparam) / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - (";" other-param) - ; - ) - - rdtval = date-time / date / period - ;Value MUST match value type - - - - - - -Desruisseaux Standards Track [Page 121] - -RFC 5545 iCalendar September 2009 - - - Example: The following are examples of this property: - - RDATE:19970714T123000Z - RDATE;TZID=America/New_York:19970714T083000 - - RDATE;VALUE=PERIOD:19960403T020000Z/19960403T040000Z, - 19960404T010000Z/PT3H - - RDATE;VALUE=DATE:19970101,19970120,19970217,19970421 - 19970526,19970704,19970901,19971014,19971128,19971129,19971225 - -3.8.5.3. Recurrence Rule - - Property Name: RRULE - - Purpose: This property defines a rule or repeating pattern for - recurring events, to-dos, journal entries, or time zone - definitions. - - Value Type: RECUR - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: This property can be specified in recurring "VEVENT", - "VTODO", and "VJOURNAL" calendar components as well as in the - "STANDARD" and "DAYLIGHT" sub-components of the "VTIMEZONE" - calendar component, but it SHOULD NOT be specified more than once. - The recurrence set generated with multiple "RRULE" properties is - undefined. - - Description: The recurrence rule, if specified, is used in computing - the recurrence set. The recurrence set is the complete set of - recurrence instances for a calendar component. The recurrence set - is generated by considering the initial "DTSTART" property along - with the "RRULE", "RDATE", and "EXDATE" properties contained - within the recurring component. The "DTSTART" property defines - the first instance in the recurrence set. The "DTSTART" property - value SHOULD be synchronized with the recurrence rule, if - specified. The recurrence set generated with a "DTSTART" property - value not synchronized with the recurrence rule is undefined. The - final recurrence set is generated by gathering all of the start - DATE-TIME values generated by any of the specified "RRULE" and - "RDATE" properties, and then excluding any start DATE-TIME values - specified by "EXDATE" properties. This implies that start DATE- - TIME values specified by "EXDATE" properties take precedence over - those specified by inclusion properties (i.e., "RDATE" and - "RRULE"). Where duplicate instances are generated by the "RRULE" - - - -Desruisseaux Standards Track [Page 122] - -RFC 5545 iCalendar September 2009 - - - and "RDATE" properties, only one recurrence is considered. - Duplicate instances are ignored. - - The "DTSTART" property specified within the iCalendar object - defines the first instance of the recurrence. In most cases, a - "DTSTART" property of DATE-TIME value type used with a recurrence - rule, should be specified as a date with local time and time zone - reference to make sure all the recurrence instances start at the - same local time regardless of time zone changes. - - If the duration of the recurring component is specified with the - "DTEND" or "DUE" property, then the same exact duration will apply - to all the members of the generated recurrence set. Else, if the - duration of the recurring component is specified with the - "DURATION" property, then the same nominal duration will apply to - all the members of the generated recurrence set and the exact - duration of each recurrence instance will depend on its specific - start time. For example, recurrence instances of a nominal - duration of one day will have an exact duration of more or less - than 24 hours on a day where a time zone shift occurs. The - duration of a specific recurrence may be modified in an exception - component or simply by using an "RDATE" property of PERIOD value - type. - - Format Definition: This property is defined by the following - notation: - - rrule = "RRULE" rrulparam ":" recur CRLF - - rrulparam = *(";" other-param) - - Example: All examples assume the Eastern United States time zone. - - Daily for 10 occurrences: - - DTSTART;TZID=America/New_York:19970902T090000 - RRULE:FREQ=DAILY;COUNT=10 - - ==> (1997 9:00 AM EDT) September 2-11 - - Daily until December 24, 1997: - - DTSTART;TZID=America/New_York:19970902T090000 - RRULE:FREQ=DAILY;UNTIL=19971224T000000Z - - ==> (1997 9:00 AM EDT) September 2-30;October 1-25 - (1997 9:00 AM EST) October 26-31;November 1-30;December 1-23 - - - - -Desruisseaux Standards Track [Page 123] - -RFC 5545 iCalendar September 2009 - - - Every other day - forever: - - DTSTART;TZID=America/New_York:19970902T090000 - RRULE:FREQ=DAILY;INTERVAL=2 - - ==> (1997 9:00 AM EDT) September 2,4,6,8...24,26,28,30; - October 2,4,6...20,22,24 - (1997 9:00 AM EST) October 26,28,30; - November 1,3,5,7...25,27,29; - December 1,3,... - - Every 10 days, 5 occurrences: - - DTSTART;TZID=America/New_York:19970902T090000 - RRULE:FREQ=DAILY;INTERVAL=10;COUNT=5 - - ==> (1997 9:00 AM EDT) September 2,12,22; - October 2,12 - - Every day in January, for 3 years: - - DTSTART;TZID=America/New_York:19980101T090000 - - RRULE:FREQ=YEARLY;UNTIL=20000131T140000Z; - BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA - or - RRULE:FREQ=DAILY;UNTIL=20000131T140000Z;BYMONTH=1 - - ==> (1998 9:00 AM EST)January 1-31 - (1999 9:00 AM EST)January 1-31 - (2000 9:00 AM EST)January 1-31 - - Weekly for 10 occurrences: - - DTSTART;TZID=America/New_York:19970902T090000 - RRULE:FREQ=WEEKLY;COUNT=10 - - ==> (1997 9:00 AM EDT) September 2,9,16,23,30;October 7,14,21 - (1997 9:00 AM EST) October 28;November 4 - - - - - - - - - - - - -Desruisseaux Standards Track [Page 124] - -RFC 5545 iCalendar September 2009 - - - Weekly until December 24, 1997: - - DTSTART;TZID=America/New_York:19970902T090000 - RRULE:FREQ=WEEKLY;UNTIL=19971224T000000Z - - ==> (1997 9:00 AM EDT) September 2,9,16,23,30; - October 7,14,21 - (1997 9:00 AM EST) October 28; - November 4,11,18,25; - December 2,9,16,23 - - Every other week - forever: - - DTSTART;TZID=America/New_York:19970902T090000 - RRULE:FREQ=WEEKLY;INTERVAL=2;WKST=SU - - ==> (1997 9:00 AM EDT) September 2,16,30; - October 14 - (1997 9:00 AM EST) October 28; - November 11,25; - December 9,23 - (1998 9:00 AM EST) January 6,20; - February 3, 17 - ... - - Weekly on Tuesday and Thursday for five weeks: - - DTSTART;TZID=America/New_York:19970902T090000 - RRULE:FREQ=WEEKLY;UNTIL=19971007T000000Z;WKST=SU;BYDAY=TU,TH - - or - - RRULE:FREQ=WEEKLY;COUNT=10;WKST=SU;BYDAY=TU,TH - - ==> (1997 9:00 AM EDT) September 2,4,9,11,16,18,23,25,30; - October 2 - - Every other week on Monday, Wednesday, and Friday until December - 24, 1997, starting on Monday, September 1, 1997: - - DTSTART;TZID=America/New_York:19970901T090000 - RRULE:FREQ=WEEKLY;INTERVAL=2;UNTIL=19971224T000000Z;WKST=SU; - BYDAY=MO,WE,FR - - ==> (1997 9:00 AM EDT) September 1,3,5,15,17,19,29; - October 1,3,13,15,17 - (1997 9:00 AM EST) October 27,29,31; - November 10,12,14,24,26,28; - - - -Desruisseaux Standards Track [Page 125] - -RFC 5545 iCalendar September 2009 - - - December 8,10,12,22 - - Every other week on Tuesday and Thursday, for 8 occurrences: - - DTSTART;TZID=America/New_York:19970902T090000 - RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=8;WKST=SU;BYDAY=TU,TH - - ==> (1997 9:00 AM EDT) September 2,4,16,18,30; - October 2,14,16 - - Monthly on the first Friday for 10 occurrences: - - DTSTART;TZID=America/New_York:19970905T090000 - RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR - - ==> (1997 9:00 AM EDT) September 5;October 3 - (1997 9:00 AM EST) November 7;December 5 - (1998 9:00 AM EST) January 2;February 6;March 6;April 3 - (1998 9:00 AM EDT) May 1;June 5 - - Monthly on the first Friday until December 24, 1997: - - DTSTART;TZID=America/New_York:19970905T090000 - RRULE:FREQ=MONTHLY;UNTIL=19971224T000000Z;BYDAY=1FR - - ==> (1997 9:00 AM EDT) September 5; October 3 - (1997 9:00 AM EST) November 7; December 5 - - Every other month on the first and last Sunday of the month for 10 - occurrences: - - DTSTART;TZID=America/New_York:19970907T090000 - RRULE:FREQ=MONTHLY;INTERVAL=2;COUNT=10;BYDAY=1SU,-1SU - - ==> (1997 9:00 AM EDT) September 7,28 - (1997 9:00 AM EST) November 2,30 - (1998 9:00 AM EST) January 4,25;March 1,29 - (1998 9:00 AM EDT) May 3,31 - - Monthly on the second-to-last Monday of the month for 6 months: - - DTSTART;TZID=America/New_York:19970922T090000 - RRULE:FREQ=MONTHLY;COUNT=6;BYDAY=-2MO - - ==> (1997 9:00 AM EDT) September 22;October 20 - (1997 9:00 AM EST) November 17;December 22 - (1998 9:00 AM EST) January 19;February 16 - - - - -Desruisseaux Standards Track [Page 126] - -RFC 5545 iCalendar September 2009 - - - Monthly on the third-to-the-last day of the month, forever: - - DTSTART;TZID=America/New_York:19970928T090000 - RRULE:FREQ=MONTHLY;BYMONTHDAY=-3 - - ==> (1997 9:00 AM EDT) September 28 - (1997 9:00 AM EST) October 29;November 28;December 29 - (1998 9:00 AM EST) January 29;February 26 - ... - - Monthly on the 2nd and 15th of the month for 10 occurrences: - - DTSTART;TZID=America/New_York:19970902T090000 - RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=2,15 - - ==> (1997 9:00 AM EDT) September 2,15;October 2,15 - (1997 9:00 AM EST) November 2,15;December 2,15 - (1998 9:00 AM EST) January 2,15 - - Monthly on the first and last day of the month for 10 occurrences: - - DTSTART;TZID=America/New_York:19970930T090000 - RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=1,-1 - - ==> (1997 9:00 AM EDT) September 30;October 1 - (1997 9:00 AM EST) October 31;November 1,30;December 1,31 - (1998 9:00 AM EST) January 1,31;February 1 - - Every 18 months on the 10th thru 15th of the month for 10 - occurrences: - - DTSTART;TZID=America/New_York:19970910T090000 - RRULE:FREQ=MONTHLY;INTERVAL=18;COUNT=10;BYMONTHDAY=10,11,12, - 13,14,15 - - ==> (1997 9:00 AM EDT) September 10,11,12,13,14,15 - (1999 9:00 AM EST) March 10,11,12,13 - - Every Tuesday, every other month: - - DTSTART;TZID=America/New_York:19970902T090000 - RRULE:FREQ=MONTHLY;INTERVAL=2;BYDAY=TU - - ==> (1997 9:00 AM EDT) September 2,9,16,23,30 - (1997 9:00 AM EST) November 4,11,18,25 - (1998 9:00 AM EST) January 6,13,20,27;March 3,10,17,24,31 - ... - - - - -Desruisseaux Standards Track [Page 127] - -RFC 5545 iCalendar September 2009 - - - Yearly in June and July for 10 occurrences: - - DTSTART;TZID=America/New_York:19970610T090000 - RRULE:FREQ=YEARLY;COUNT=10;BYMONTH=6,7 - - ==> (1997 9:00 AM EDT) June 10;July 10 - (1998 9:00 AM EDT) June 10;July 10 - (1999 9:00 AM EDT) June 10;July 10 - (2000 9:00 AM EDT) June 10;July 10 - (2001 9:00 AM EDT) June 10;July 10 - - Note: Since none of the BYDAY, BYMONTHDAY, or BYYEARDAY - components are specified, the day is gotten from "DTSTART". - - Every other year on January, February, and March for 10 - occurrences: - - DTSTART;TZID=America/New_York:19970310T090000 - RRULE:FREQ=YEARLY;INTERVAL=2;COUNT=10;BYMONTH=1,2,3 - - ==> (1997 9:00 AM EST) March 10 - (1999 9:00 AM EST) January 10;February 10;March 10 - (2001 9:00 AM EST) January 10;February 10;March 10 - (2003 9:00 AM EST) January 10;February 10;March 10 - - Every third year on the 1st, 100th, and 200th day for 10 - occurrences: - - DTSTART;TZID=America/New_York:19970101T090000 - RRULE:FREQ=YEARLY;INTERVAL=3;COUNT=10;BYYEARDAY=1,100,200 - - ==> (1997 9:00 AM EST) January 1 - (1997 9:00 AM EDT) April 10;July 19 - (2000 9:00 AM EST) January 1 - (2000 9:00 AM EDT) April 9;July 18 - (2003 9:00 AM EST) January 1 - (2003 9:00 AM EDT) April 10;July 19 - (2006 9:00 AM EST) January 1 - - Every 20th Monday of the year, forever: - - DTSTART;TZID=America/New_York:19970519T090000 - RRULE:FREQ=YEARLY;BYDAY=20MO - - ==> (1997 9:00 AM EDT) May 19 - (1998 9:00 AM EDT) May 18 - (1999 9:00 AM EDT) May 17 - ... - - - -Desruisseaux Standards Track [Page 128] - -RFC 5545 iCalendar September 2009 - - - Monday of week number 20 (where the default start of the week is - Monday), forever: - - DTSTART;TZID=America/New_York:19970512T090000 - RRULE:FREQ=YEARLY;BYWEEKNO=20;BYDAY=MO - - ==> (1997 9:00 AM EDT) May 12 - (1998 9:00 AM EDT) May 11 - (1999 9:00 AM EDT) May 17 - ... - - Every Thursday in March, forever: - - DTSTART;TZID=America/New_York:19970313T090000 - RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=TH - - ==> (1997 9:00 AM EST) March 13,20,27 - (1998 9:00 AM EST) March 5,12,19,26 - (1999 9:00 AM EST) March 4,11,18,25 - ... - - Every Thursday, but only during June, July, and August, forever: - - DTSTART;TZID=America/New_York:19970605T090000 - RRULE:FREQ=YEARLY;BYDAY=TH;BYMONTH=6,7,8 - - ==> (1997 9:00 AM EDT) June 5,12,19,26;July 3,10,17,24,31; - August 7,14,21,28 - (1998 9:00 AM EDT) June 4,11,18,25;July 2,9,16,23,30; - August 6,13,20,27 - (1999 9:00 AM EDT) June 3,10,17,24;July 1,8,15,22,29; - August 5,12,19,26 - ... - - Every Friday the 13th, forever: - - DTSTART;TZID=America/New_York:19970902T090000 - EXDATE;TZID=America/New_York:19970902T090000 - RRULE:FREQ=MONTHLY;BYDAY=FR;BYMONTHDAY=13 - - ==> (1998 9:00 AM EST) February 13;March 13;November 13 - (1999 9:00 AM EDT) August 13 - (2000 9:00 AM EDT) October 13 - ... - - - - - - - -Desruisseaux Standards Track [Page 129] - -RFC 5545 iCalendar September 2009 - - - The first Saturday that follows the first Sunday of the month, - forever: - - DTSTART;TZID=America/New_York:19970913T090000 - RRULE:FREQ=MONTHLY;BYDAY=SA;BYMONTHDAY=7,8,9,10,11,12,13 - - ==> (1997 9:00 AM EDT) September 13;October 11 - (1997 9:00 AM EST) November 8;December 13 - (1998 9:00 AM EST) January 10;February 7;March 7 - (1998 9:00 AM EDT) April 11;May 9;June 13... - ... - - Every 4 years, the first Tuesday after a Monday in November, - forever (U.S. Presidential Election day): - - DTSTART;TZID=America/New_York:19961105T090000 - RRULE:FREQ=YEARLY;INTERVAL=4;BYMONTH=11;BYDAY=TU; - BYMONTHDAY=2,3,4,5,6,7,8 - - ==> (1996 9:00 AM EST) November 5 - (2000 9:00 AM EST) November 7 - (2004 9:00 AM EST) November 2 - ... - - The third instance into the month of one of Tuesday, Wednesday, or - Thursday, for the next 3 months: - - DTSTART;TZID=America/New_York:19970904T090000 - RRULE:FREQ=MONTHLY;COUNT=3;BYDAY=TU,WE,TH;BYSETPOS=3 - - ==> (1997 9:00 AM EDT) September 4;October 7 - (1997 9:00 AM EST) November 6 - - The second-to-last weekday of the month: - - DTSTART;TZID=America/New_York:19970929T090000 - RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-2 - - ==> (1997 9:00 AM EDT) September 29 - (1997 9:00 AM EST) October 30;November 27;December 30 - (1998 9:00 AM EST) January 29;February 26;March 30 - ... - - - - - - - - - -Desruisseaux Standards Track [Page 130] - -RFC 5545 iCalendar September 2009 - - - Every 3 hours from 9:00 AM to 5:00 PM on a specific day: - - DTSTART;TZID=America/New_York:19970902T090000 - RRULE:FREQ=HOURLY;INTERVAL=3;UNTIL=19970902T170000Z - - ==> (September 2, 1997 EDT) 09:00,12:00,15:00 - - Every 15 minutes for 6 occurrences: - - DTSTART;TZID=America/New_York:19970902T090000 - RRULE:FREQ=MINUTELY;INTERVAL=15;COUNT=6 - - ==> (September 2, 1997 EDT) 09:00,09:15,09:30,09:45,10:00,10:15 - - Every hour and a half for 4 occurrences: - - DTSTART;TZID=America/New_York:19970902T090000 - RRULE:FREQ=MINUTELY;INTERVAL=90;COUNT=4 - - ==> (September 2, 1997 EDT) 09:00,10:30;12:00;13:30 - - Every 20 minutes from 9:00 AM to 4:40 PM every day: - - DTSTART;TZID=America/New_York:19970902T090000 - RRULE:FREQ=DAILY;BYHOUR=9,10,11,12,13,14,15,16;BYMINUTE=0,20,40 - or - RRULE:FREQ=MINUTELY;INTERVAL=20;BYHOUR=9,10,11,12,13,14,15,16 - - ==> (September 2, 1997 EDT) 9:00,9:20,9:40,10:00,10:20, - ... 16:00,16:20,16:40 - (September 3, 1997 EDT) 9:00,9:20,9:40,10:00,10:20, - ...16:00,16:20,16:40 - ... - - An example where the days generated makes a difference because of - WKST: - - DTSTART;TZID=America/New_York:19970805T090000 - RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=4;BYDAY=TU,SU;WKST=MO - - ==> (1997 EDT) August 5,10,19,24 - - changing only WKST from MO to SU, yields different results... - - DTSTART;TZID=America/New_York:19970805T090000 - RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=4;BYDAY=TU,SU;WKST=SU - - ==> (1997 EDT) August 5,17,19,31 - - - -Desruisseaux Standards Track [Page 131] - -RFC 5545 iCalendar September 2009 - - - An example where an invalid date (i.e., February 30) is ignored. - - DTSTART;TZID=America/New_York:20070115T090000 - RRULE:FREQ=MONTHLY;BYMONTHDAY=15,30;COUNT=5 - - ==> (2007 EST) January 15,30 - (2007 EST) February 15 - (2007 EDT) March 15,30 - -3.8.6. Alarm Component Properties - - The following properties specify alarm information in calendar - components. - -3.8.6.1. Action - - Property Name: ACTION - - Purpose: This property defines the action to be invoked when an - alarm is triggered. - - Value Type: TEXT - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: This property MUST be specified once in a "VALARM" - calendar component. - - Description: Each "VALARM" calendar component has a particular type - of action with which it is associated. This property specifies - the type of action. Applications MUST ignore alarms with x-name - and iana-token values they don't recognize. - - Format Definition: This property is defined by the following - notation: - - action = "ACTION" actionparam ":" actionvalue CRLF - - actionparam = *(";" other-param) - - - actionvalue = "AUDIO" / "DISPLAY" / "EMAIL" - / iana-token / x-name - - Example: The following are examples of this property in a "VALARM" - calendar component: - - - - -Desruisseaux Standards Track [Page 132] - -RFC 5545 iCalendar September 2009 - - - ACTION:AUDIO - - ACTION:DISPLAY - -3.8.6.2. Repeat Count - - Property Name: REPEAT - - Purpose: This property defines the number of times the alarm should - be repeated, after the initial trigger. - - Value Type: INTEGER - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: This property can be specified in a "VALARM" calendar - component. - - Description: This property defines the number of times an alarm - should be repeated after its initial trigger. If the alarm - triggers more than once, then this property MUST be specified - along with the "DURATION" property. - - Format Definition: This property is defined by the following - notation: - - repeat = "REPEAT" repparam ":" integer CRLF - ;Default is "0", zero. - - repparam = *(";" other-param) - - Example: The following is an example of this property for an alarm - that repeats 4 additional times with a 5-minute delay after the - initial triggering of the alarm: - - REPEAT:4 - DURATION:PT5M - -3.8.6.3. Trigger - - Property Name: TRIGGER - - Purpose: This property specifies when an alarm will trigger. - - Value Type: The default value type is DURATION. The value type can - be set to a DATE-TIME value type, in which case the value MUST - specify a UTC-formatted DATE-TIME value. - - - -Desruisseaux Standards Track [Page 133] - -RFC 5545 iCalendar September 2009 - - - Property Parameters: IANA, non-standard, value data type, time zone - identifier, or trigger relationship property parameters can be - specified on this property. The trigger relationship property - parameter MUST only be specified when the value type is - "DURATION". - - Conformance: This property MUST be specified in the "VALARM" - calendar component. - - Description: This property defines when an alarm will trigger. The - default value type is DURATION, specifying a relative time for the - trigger of the alarm. The default duration is relative to the - start of an event or to-do with which the alarm is associated. - The duration can be explicitly set to trigger from either the end - or the start of the associated event or to-do with the "RELATED" - parameter. A value of START will set the alarm to trigger off the - start of the associated event or to-do. A value of END will set - the alarm to trigger off the end of the associated event or to-do. - - Either a positive or negative duration may be specified for the - "TRIGGER" property. An alarm with a positive duration is - triggered after the associated start or end of the event or to-do. - An alarm with a negative duration is triggered before the - associated start or end of the event or to-do. - - The "RELATED" property parameter is not valid if the value type of - the property is set to DATE-TIME (i.e., for an absolute date and - time alarm trigger). If a value type of DATE-TIME is specified, - then the property value MUST be specified in the UTC time format. - If an absolute trigger is specified on an alarm for a recurring - event or to-do, then the alarm will only trigger for the specified - absolute DATE-TIME, along with any specified repeating instances. - - If the trigger is set relative to START, then the "DTSTART" - property MUST be present in the associated "VEVENT" or "VTODO" - calendar component. If an alarm is specified for an event with - the trigger set relative to the END, then the "DTEND" property or - the "DTSTART" and "DURATION " properties MUST be present in the - associated "VEVENT" calendar component. If the alarm is specified - for a to-do with a trigger set relative to the END, then either - the "DUE" property or the "DTSTART" and "DURATION " properties - MUST be present in the associated "VTODO" calendar component. - - Alarms specified in an event or to-do that is defined in terms of - a DATE value type will be triggered relative to 00:00:00 of the - user's configured time zone on the specified date, or relative to - 00:00:00 UTC on the specified date if no configured time zone can - be found for the user. For example, if "DTSTART" is a DATE value - - - -Desruisseaux Standards Track [Page 134] - -RFC 5545 iCalendar September 2009 - - - set to 19980205 then the duration trigger will be relative to - 19980205T000000 America/New_York for a user configured with the - America/New_York time zone. - - Format Definition: This property is defined by the following - notation: - - trigger = "TRIGGER" (trigrel / trigabs) CRLF - - trigrel = *( - ; - ; The following are OPTIONAL, - ; but MUST NOT occur more than once. - ; - (";" "VALUE" "=" "DURATION") / - (";" trigrelparam) / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - (";" other-param) - ; - ) ":" dur-value - - trigabs = *( - ; - ; The following is REQUIRED, - ; but MUST NOT occur more than once. - ; - (";" "VALUE" "=" "DATE-TIME") / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - (";" other-param) - ; - ) ":" date-time - - Example: A trigger set 15 minutes prior to the start of the event or - to-do. - - TRIGGER:-PT15M - - A trigger set five minutes after the end of an event or the due - date of a to-do. - - TRIGGER;RELATED=END:PT5M - - - - -Desruisseaux Standards Track [Page 135] - -RFC 5545 iCalendar September 2009 - - - A trigger set to an absolute DATE-TIME. - - TRIGGER;VALUE=DATE-TIME:19980101T050000Z - -3.8.7. Change Management Component Properties - - The following properties specify change management information in - calendar components. - -3.8.7.1. Date-Time Created - - Property Name: CREATED - - Purpose: This property specifies the date and time that the calendar - information was created by the calendar user agent in the calendar - store. - - Note: This is analogous to the creation date and time for a - file in the file system. - - Value Type: DATE-TIME - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: The property can be specified once in "VEVENT", - "VTODO", or "VJOURNAL" calendar components. The value MUST be - specified as a date with UTC time. - - Description: This property specifies the date and time that the - calendar information was created by the calendar user agent in the - calendar store. - - Format Definition: This property is defined by the following - notation: - - created = "CREATED" creaparam ":" date-time CRLF - - creaparam = *(";" other-param) - - Example: The following is an example of this property: - - CREATED:19960329T133000Z - - - - - - - - -Desruisseaux Standards Track [Page 136] - -RFC 5545 iCalendar September 2009 - - -3.8.7.2. Date-Time Stamp - - Property Name: DTSTAMP - - Purpose: In the case of an iCalendar object that specifies a - "METHOD" property, this property specifies the date and time that - the instance of the iCalendar object was created. In the case of - an iCalendar object that doesn't specify a "METHOD" property, this - property specifies the date and time that the information - associated with the calendar component was last revised in the - calendar store. - - Value Type: DATE-TIME - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: This property MUST be included in the "VEVENT", - "VTODO", "VJOURNAL", or "VFREEBUSY" calendar components. - - Description: The value MUST be specified in the UTC time format. - - This property is also useful to protocols such as [2447bis] that - have inherent latency issues with the delivery of content. This - property will assist in the proper sequencing of messages - containing iCalendar objects. - - In the case of an iCalendar object that specifies a "METHOD" - property, this property differs from the "CREATED" and "LAST- - MODIFIED" properties. These two properties are used to specify - when the particular calendar data in the calendar store was - created and last modified. This is different than when the - iCalendar object representation of the calendar service - information was created or last modified. - - In the case of an iCalendar object that doesn't specify a "METHOD" - property, this property is equivalent to the "LAST-MODIFIED" - property. - - Format Definition: This property is defined by the following - notation: - - dtstamp = "DTSTAMP" stmparam ":" date-time CRLF - - stmparam = *(";" other-param) - - - - - - -Desruisseaux Standards Track [Page 137] - -RFC 5545 iCalendar September 2009 - - - Example: - - DTSTAMP:19971210T080000Z - -3.8.7.3. Last Modified - - Property Name: LAST-MODIFIED - - Purpose: This property specifies the date and time that the - information associated with the calendar component was last - revised in the calendar store. - - Note: This is analogous to the modification date and time for a - file in the file system. - - Value Type: DATE-TIME - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: This property can be specified in the "VEVENT", - "VTODO", "VJOURNAL", or "VTIMEZONE" calendar components. - - Description: The property value MUST be specified in the UTC time - format. - - Format Definition: This property is defined by the following - notation: - - last-mod = "LAST-MODIFIED" lstparam ":" date-time CRLF - - lstparam = *(";" other-param) - - Example: The following is an example of this property: - - LAST-MODIFIED:19960817T133000Z - -3.8.7.4. Sequence Number - - Property Name: SEQUENCE - - Purpose: This property defines the revision sequence number of the - calendar component within a sequence of revisions. - - Value Type: INTEGER - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - - -Desruisseaux Standards Track [Page 138] - -RFC 5545 iCalendar September 2009 - - - Conformance: The property can be specified in "VEVENT", "VTODO", or - "VJOURNAL" calendar component. - - Description: When a calendar component is created, its sequence - number is 0. It is monotonically incremented by the "Organizer's" - CUA each time the "Organizer" makes a significant revision to the - calendar component. - - The "Organizer" includes this property in an iCalendar object that - it sends to an "Attendee" to specify the current version of the - calendar component. - - The "Attendee" includes this property in an iCalendar object that - it sends to the "Organizer" to specify the version of the calendar - component to which the "Attendee" is referring. - - A change to the sequence number is not the mechanism that an - "Organizer" uses to request a response from the "Attendees". The - "RSVP" parameter on the "ATTENDEE" property is used by the - "Organizer" to indicate that a response from the "Attendees" is - requested. - - Recurrence instances of a recurring component MAY have different - sequence numbers. - - Format Definition: This property is defined by the following - notation: - - seq = "SEQUENCE" seqparam ":" integer CRLF - ; Default is "0" - - seqparam = *(";" other-param) - - Example: The following is an example of this property for a calendar - component that was just created by the "Organizer": - - SEQUENCE:0 - - The following is an example of this property for a calendar - component that has been revised two different times by the - "Organizer": - - SEQUENCE:2 - -3.8.8. Miscellaneous Component Properties - - The following properties specify information about a number of - miscellaneous features of calendar components. - - - -Desruisseaux Standards Track [Page 139] - -RFC 5545 iCalendar September 2009 - - -3.8.8.1. IANA Properties - - Property Name: An IANA-registered property name - - Value Type: The default value type is TEXT. The value type can be - set to any value type. - - Property Parameters: Any parameter can be specified on this - property. - - Description: This specification allows other properties registered - with IANA to be specified in any calendar components. Compliant - applications are expected to be able to parse these other IANA- - registered properties but can ignore them. - - Format Definition: This property is defined by the following - notation: - - iana-prop = iana-token *(";" icalparameter) ":" value CRLF - - Example: The following are examples of properties that might be - registered to IANA: - - DRESSCODE:CASUAL - - NON-SMOKING;VALUE=BOOLEAN:TRUE - -3.8.8.2. Non-Standard Properties - - Property Name: Any property name with a "X-" prefix - - Purpose: This class of property provides a framework for defining - non-standard properties. - - Value Type: The default value type is TEXT. The value type can be - set to any value type. - - Property Parameters: IANA, non-standard, and language property - parameters can be specified on this property. - - Conformance: This property can be specified in any calendar - component. - - Description: The MIME Calendaring and Scheduling Content Type - provides a "standard mechanism for doing non-standard things". - This extension support is provided for implementers to "push the - envelope" on the existing version of the memo. Extension - properties are specified by property and/or property parameter - - - -Desruisseaux Standards Track [Page 140] - -RFC 5545 iCalendar September 2009 - - - names that have the prefix text of "X-" (the two-character - sequence: LATIN CAPITAL LETTER X character followed by the HYPHEN- - MINUS character). It is recommended that vendors concatenate onto - this sentinel another short prefix text to identify the vendor. - This will facilitate readability of the extensions and minimize - possible collision of names between different vendors. User - agents that support this content type are expected to be able to - parse the extension properties and property parameters but can - ignore them. - - At present, there is no registration authority for names of - extension properties and property parameters. The value type for - this property is TEXT. Optionally, the value type can be any of - the other valid value types. - - Format Definition: This property is defined by the following - notation: - - x-prop = x-name *(";" icalparameter) ":" value CRLF - - Example: The following might be the ABC vendor's extension for an - audio-clip form of subject property: - - X-ABC-MMSUBJ;VALUE=URI;FMTTYPE=audio/basic:http://www.example. - org/mysubj.au - -3.8.8.3. Request Status - - Property Name: REQUEST-STATUS - - Purpose: This property defines the status code returned for a - scheduling request. - - Value Type: TEXT - - Property Parameters: IANA, non-standard, and language property - parameters can be specified on this property. - - Conformance: The property can be specified in the "VEVENT", "VTODO", - "VJOURNAL", or "VFREEBUSY" calendar component. - - Description: This property is used to return status code information - related to the processing of an associated iCalendar object. The - value type for this property is TEXT. - - - - - - - -Desruisseaux Standards Track [Page 141] - -RFC 5545 iCalendar September 2009 - - - The value consists of a short return status component, a longer - return status description component, and optionally a status- - specific data component. The components of the value are - separated by the SEMICOLON character. - - The short return status is a PERIOD character separated pair or - 3-tuple of integers. For example, "3.1" or "3.1.1". The - successive levels of integers provide for a successive level of - status code granularity. - - The following are initial classes for the return status code. - Individual iCalendar object methods will define specific return - status codes for these classes. In addition, other classes for - the return status code may be defined using the registration - process defined later in this memo. - - +--------+----------------------------------------------------------+ - | Short | Longer Return Status Description | - | Return | | - | Status | | - | Code | | - +--------+----------------------------------------------------------+ - | 1.xx | Preliminary success. This class of status code | - | | indicates that the request has been initially processed | - | | but that completion is pending. | - | | | - | 2.xx | Successful. This class of status code indicates that | - | | the request was completed successfully. However, the | - | | exact status code can indicate that a fallback has been | - | | taken. | - | | | - | 3.xx | Client Error. This class of status code indicates that | - | | the request was not successful. The error is the result | - | | of either a syntax or a semantic error in the client- | - | | formatted request. Request should not be retried until | - | | the condition in the request is corrected. | - | | | - | 4.xx | Scheduling Error. This class of status code indicates | - | | that the request was not successful. Some sort of error | - | | occurred within the calendaring and scheduling service, | - | | not directly related to the request itself. | - +--------+----------------------------------------------------------+ - - - - - - - - - -Desruisseaux Standards Track [Page 142] - -RFC 5545 iCalendar September 2009 - - - Format Definition: This property is defined by the following - notation: - - rstatus = "REQUEST-STATUS" rstatparam ":" - statcode ";" statdesc [";" extdata] - - rstatparam = *( - ; - ; The following is OPTIONAL, - ; but MUST NOT occur more than once. - ; - (";" languageparam) / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - (";" other-param) - ; - ) - - statcode = 1*DIGIT 1*2("." 1*DIGIT) - ;Hierarchical, numeric return status code - - statdesc = text - ;Textual status description - - extdata = text - ;Textual exception data. For example, the offending property - ;name and value or complete property line. - - Example: The following are some possible examples of this property. - - The COMMA and SEMICOLON separator characters in the property value - are BACKSLASH character escaped because they appear in a text - value. - - REQUEST-STATUS:2.0;Success - - REQUEST-STATUS:3.1;Invalid property value;DTSTART:96-Apr-01 - - REQUEST-STATUS:2.8; Success\, repeating event ignored. Scheduled - as a single event.;RRULE:FREQ=WEEKLY\;INTERVAL=2 - - REQUEST-STATUS:4.1;Event conflict. Date-time is busy. - - REQUEST-STATUS:3.7;Invalid calendar user;ATTENDEE: - mailto:jsmith@example.com - - - - -Desruisseaux Standards Track [Page 143] - -RFC 5545 iCalendar September 2009 - - -4. iCalendar Object Examples - - The following examples are provided as an informational source of - illustrative iCalendar objects consistent with this content type. - - The following example specifies a three-day conference that begins at - 2:30 P.M. UTC, September 18, 1996 and ends at 10:00 P.M. UTC, - September 20, 1996. - - BEGIN:VCALENDAR - PRODID:-//xyz Corp//NONSGML PDA Calendar Version 1.0//EN - VERSION:2.0 - BEGIN:VEVENT - DTSTAMP:19960704T120000Z - UID:uid1@example.com - ORGANIZER:mailto:jsmith@example.com - DTSTART:19960918T143000Z - DTEND:19960920T220000Z - STATUS:CONFIRMED - CATEGORIES:CONFERENCE - SUMMARY:Networld+Interop Conference - DESCRIPTION:Networld+Interop Conference - and Exhibit\nAtlanta World Congress Center\n - Atlanta\, Georgia - END:VEVENT - END:VCALENDAR - - The following example specifies a group-scheduled meeting that begins - at 8:30 AM EST on March 12, 1998 and ends at 9:30 AM EST on March 12, - 1998. The "Organizer" has scheduled the meeting with one or more - calendar users in a group. A time zone specification for Eastern - United States has been specified. - - BEGIN:VCALENDAR - PRODID:-//RDU Software//NONSGML HandCal//EN - VERSION:2.0 - BEGIN:VTIMEZONE - TZID:America/New_York - BEGIN:STANDARD - DTSTART:19981025T020000 - TZOFFSETFROM:-0400 - TZOFFSETTO:-0500 - TZNAME:EST - END:STANDARD - BEGIN:DAYLIGHT - DTSTART:19990404T020000 - TZOFFSETFROM:-0500 - TZOFFSETTO:-0400 - - - -Desruisseaux Standards Track [Page 144] - -RFC 5545 iCalendar September 2009 - - - TZNAME:EDT - END:DAYLIGHT - END:VTIMEZONE - BEGIN:VEVENT - DTSTAMP:19980309T231000Z - UID:guid-1.example.com - ORGANIZER:mailto:mrbig@example.com - ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;CUTYPE=GROUP: - mailto:employee-A@example.com - DESCRIPTION:Project XYZ Review Meeting - CATEGORIES:MEETING - CLASS:PUBLIC - CREATED:19980309T130000Z - SUMMARY:XYZ Project Review - DTSTART;TZID=America/New_York:19980312T083000 - DTEND;TZID=America/New_York:19980312T093000 - LOCATION:1CP Conference Room 4350 - END:VEVENT - END:VCALENDAR - - The following is an example of an iCalendar object passed in a MIME - message with a single body part consisting of a "text/calendar" - Content Type. - - TO:jsmith@example.com - FROM:jdoe@example.com - MIME-VERSION:1.0 - MESSAGE-ID: - CONTENT-TYPE:text/calendar; method="xyz"; component="VEVENT" - - BEGIN:VCALENDAR - METHOD:xyz - VERSION:2.0 - PRODID:-//ABC Corporation//NONSGML My Product//EN - BEGIN:VEVENT - DTSTAMP:19970324T120000Z - SEQUENCE:0 - UID:uid3@example.com - ORGANIZER:mailto:jdoe@example.com - ATTENDEE;RSVP=TRUE:mailto:jsmith@example.com - DTSTART:19970324T123000Z - DTEND:19970324T210000Z - CATEGORIES:MEETING,PROJECT - CLASS:PUBLIC - SUMMARY:Calendaring Interoperability Planning Meeting - DESCRIPTION:Discuss how we can test c&s interoperability\n - using iCalendar and other IETF standards. - LOCATION:LDB Lobby - - - -Desruisseaux Standards Track [Page 145] - -RFC 5545 iCalendar September 2009 - - - ATTACH;FMTTYPE=application/postscript:ftp://example.com/pub/ - conf/bkgrnd.ps - END:VEVENT - END:VCALENDAR - - The following is an example of a to-do due on April 15, 1998. An - audio alarm has been specified to remind the calendar user at noon, - the day before the to-do is expected to be completed and repeat - hourly, four additional times. The to-do definition has been - modified twice since it was initially created. - - BEGIN:VCALENDAR - VERSION:2.0 - PRODID:-//ABC Corporation//NONSGML My Product//EN - BEGIN:VTODO - DTSTAMP:19980130T134500Z - SEQUENCE:2 - UID:uid4@example.com - ORGANIZER:mailto:unclesam@example.com - ATTENDEE;PARTSTAT=ACCEPTED:mailto:jqpublic@example.com - DUE:19980415T000000 - STATUS:NEEDS-ACTION - SUMMARY:Submit Income Taxes - BEGIN:VALARM - ACTION:AUDIO - TRIGGER:19980403T120000Z - ATTACH;FMTTYPE=audio/basic:http://example.com/pub/audio- - files/ssbanner.aud - REPEAT:4 - DURATION:PT1H - END:VALARM - END:VTODO - END:VCALENDAR - - The following is an example of a journal entry: - - BEGIN:VCALENDAR - VERSION:2.0 - PRODID:-//ABC Corporation//NONSGML My Product//EN - BEGIN:VJOURNAL - DTSTAMP:19970324T120000Z - UID:uid5@example.com - ORGANIZER:mailto:jsmith@example.com - STATUS:DRAFT - CLASS:PUBLIC - CATEGORIES:Project Report,XYZ,Weekly Meeting - DESCRIPTION:Project xyz Review Meeting Minutes\n - Agenda\n1. Review of project version 1.0 requirements.\n2. - - - -Desruisseaux Standards Track [Page 146] - -RFC 5545 iCalendar September 2009 - - - Definition - of project processes.\n3. Review of project schedule.\n - Participants: John Smith\, Jane Doe\, Jim Dandy\n-It was - decided that the requirements need to be signed off by - product marketing.\n-Project processes were accepted.\n - -Project schedule needs to account for scheduled holidays - and employee vacation time. Check with HR for specific - dates.\n-New schedule will be distributed by Friday.\n- - Next weeks meeting is cancelled. No meeting until 3/23. - END:VJOURNAL - END:VCALENDAR - - The following is an example of published busy time information. The - iCalendar object might be placed in the network resource - http://www.example.com/calendar/busytime/jsmith.ifb. - - BEGIN:VCALENDAR - VERSION:2.0 - PRODID:-//RDU Software//NONSGML HandCal//EN - BEGIN:VFREEBUSY - ORGANIZER:mailto:jsmith@example.com - DTSTART:19980313T141711Z - DTEND:19980410T141711Z - FREEBUSY:19980314T233000Z/19980315T003000Z - FREEBUSY:19980316T153000Z/19980316T163000Z - FREEBUSY:19980318T030000Z/19980318T040000Z - URL:http://www.example.com/calendar/busytime/jsmith.ifb - END:VFREEBUSY - END:VCALENDAR - -5. Recommended Practices - - These recommended practices should be followed in order to assure - consistent handling of the following cases for an iCalendar object. - - 1. Content lines longer than 75 octets SHOULD be folded. - - 2. When the combination of the "RRULE" and "RDATE" properties in a - recurring component produces multiple instances having the same - start DATE-TIME value, they should be collapsed to, and - considered as, a single instance. If the "RDATE" property is - specified as a PERIOD value the duration of the recurrence - instance will be the one specified by the "RDATE" property, and - not the duration of the recurrence instance defined by the - "DTSTART" property. - - 3. When a calendar user receives multiple requests for the same - calendar component (e.g., REQUEST for a "VEVENT" calendar - - - -Desruisseaux Standards Track [Page 147] - -RFC 5545 iCalendar September 2009 - - - component) as a result of being on multiple mailing lists - specified by "ATTENDEE" properties in the request, they SHOULD - respond to only one of the requests. The calendar user SHOULD - also specify (using the "MEMBER" parameter of the "ATTENDEE" - property) of which mailing list they are a member. - - 4. An implementation can truncate a "SUMMARY" property value to 255 - octets, but it MUST NOT truncate the value in the middle of a - UTF-8 multi-octet sequence. - - 5. If seconds of the minute are not supported by an implementation, - then a value of "00" SHOULD be specified for the seconds - component in a time value. - - 6. "TZURL" values SHOULD NOT be specified as a file URI type. This - URI form can be useful within an organization, but is problematic - in the Internet. - - 7. Some possible English values for "CATEGORIES" property include: - "ANNIVERSARY", "APPOINTMENT", "BUSINESS", "EDUCATION", "HOLIDAY", - "MEETING", "MISCELLANEOUS", "NON-WORKING HOURS", "NOT IN OFFICE", - "PERSONAL", "PHONE CALL", "SICK DAY", "SPECIAL OCCASION", - "TRAVEL", "VACATION". Categories can be specified in any - registered language. - - 8. Some possible English values for the "RESOURCES" property - include: "CATERING", "CHAIRS", "COMPUTER PROJECTOR", "EASEL", - "OVERHEAD PROJECTOR", "SPEAKER PHONE", "TABLE", "TV", "VCR", - "VIDEO PHONE", "VEHICLE". Resources can be specified in any - registered language. - -6. Internationalization Considerations - - Applications MUST generate iCalendar streams in the UTF-8 charset and - MUST accept an iCalendar stream in the UTF-8 or US-ASCII charset. - -7. Security Considerations - - Because calendaring and scheduling information is very privacy- - sensitive, the protocol used for the transmission of calendaring and - scheduling information should have capabilities to protect the - information from possible threats, such as eavesdropping, replay, - message insertion, deletion, modification, and man-in-the-middle - attacks. - - As this document only defines the data format and media type of text/ - calendar that is independent of any calendar service or protocol, it - is up to the actual protocol specifications such as iTIP [2446bis], - - - -Desruisseaux Standards Track [Page 148] - -RFC 5545 iCalendar September 2009 - - - iMIP [2447bis], and "Calendaring Extensions to WebDAV (CalDAV)" - [RFC4791] to describe the threats that the above attacks present, as - well as ways in which to mitigate them. - -8. IANA Considerations - -8.1. iCalendar Media Type Registration - - The Calendaring and Scheduling Core Object Specification is intended - for use as a MIME content type. - - To: ietf-types@iana.org - - Subject: Registration of media type text/calendar - - Type name: text - - Subtype name: calendar - - Required parameters: none - - Optional parameters: charset, method, component, and optinfo - - The "charset" parameter is defined in [RFC2046] for subtypes of - the "text" media type. It is used to indicate the charset used in - the body part. The charset supported by this revision of - iCalendar is UTF-8. The use of any other charset is deprecated by - this revision of iCalendar; however, note that this revision - requires that compliant applications MUST accept iCalendar streams - using either the UTF-8 or US-ASCII charset. - - The "method" parameter is used to convey the iCalendar object - method or transaction semantics for the calendaring and scheduling - information. It also is an identifier for the restricted set of - properties and values of which the iCalendar object consists. The - parameter is to be used as a guide for applications interpreting - the information contained within the body part. It SHOULD NOT be - used to exclude or require particular pieces of information unless - the identified method definition specifically calls for this - behavior. Unless specifically forbidden by a particular method - definition, a text/calendar content type can contain any set of - properties permitted by the Calendaring and Scheduling Core Object - Specification. The "method" parameter MUST be specified and MUST - be set to the same value as the "METHOD" component property of the - iCalendar objects of the iCalendar stream if and only if the - iCalendar objects in the iCalendar stream all have a "METHOD" - component property set to the same value. - - - - -Desruisseaux Standards Track [Page 149] - -RFC 5545 iCalendar September 2009 - - - The value for the "method" parameter is defined as follows: - - method = 1*(ALPHA / DIGIT / "-") - ; IANA-registered iCalendar object method - - The "component" parameter conveys the type of iCalendar calendar - component within the body part. If the iCalendar object contains - more than one calendar component type, then multiple component - parameters MUST be specified. - - The value for the "component" parameter is defined as follows: - - component = "VEVENT" - / "VTODO" - / "VJOURNAL" - / "VFREEBUSY" - / "VTIMEZONE" - / iana-token - / x-name - - The "optinfo" parameter conveys optional information about the - iCalendar object within the body part. This parameter can only - specify semantics already specified by the iCalendar object and - that can be otherwise determined by parsing the body part. In - addition, the optional information specified by this parameter - MUST be consistent with that information specified by the - iCalendar object. For example, it can be used to convey the - "Attendee" response status to a meeting request. The parameter - value consists of a string value. - - The parameter can be specified multiple times. - - The value for the "optinfo" parameter is defined as follows: - - optinfo = infovalue / qinfovalue - - infovalue = iana-token / x-name - - qinfovalue = DQUOTE (infovalue) DQUOTE - - Encoding considerations: This media type can contain 8bit - characters, so the use of quoted-printable or base64 MIME Content- - Transfer-Encodings might be necessary when iCalendar objects are - transferred across protocols restricted to the 7bit repertoire. - Note that a text valued property in the content entity can also - have content encoding of special characters using a BACKSLASH - character escapement technique. This means that content values - can end up being encoded twice. - - - -Desruisseaux Standards Track [Page 150] - -RFC 5545 iCalendar September 2009 - - - Security considerations: See Section 7. - - Interoperability considerations: This media type is intended to - define a common format for conveying calendaring and scheduling - information between different systems. It is heavily based on the - earlier [VCAL] industry specification. - - Published specification: This specification. - - Applications that use this media type: This media type is designed - for widespread use by Internet calendaring and scheduling - applications. In addition, applications in the workflow and - document management area might find this content-type applicable. - The iTIP [2446bis], iMIP [2447bis], and CalDAV [RFC4791] Internet - protocols directly use this media type also. - - Additional information: - - Magic number(s): None. - - File extension(s): The file extension of "ics" is to be used to - designate a file containing (an arbitrary set of) calendaring - and scheduling information consistent with this MIME content - type. - - The file extension of "ifb" is to be used to designate a file - containing free or busy time information consistent with this - MIME content type. - - Macintosh file type code(s): The file type code of "iCal" is to - be used in Apple MacIntosh operating system environments to - designate a file containing calendaring and scheduling - information consistent with this MIME media type. - - The file type code of "iFBf" is to be used in Apple MacIntosh - operating system environments to designate a file containing - free or busy time information consistent with this MIME media - type. - - Person & email address to contact for further information: See the - "Author's Address" section of this document. - - Intended usage: COMMON - - Restrictions on usage: There are no restrictions on where this media - type can be used. - - Author: See the "Author's Address" section of this document. - - - -Desruisseaux Standards Track [Page 151] - -RFC 5545 iCalendar September 2009 - - - Change controller: IETF - -8.2. New iCalendar Elements Registration - - This section defines the process to register new or modified - iCalendar elements, that is, components, properties, parameters, - value data types, and values, with IANA. - -8.2.1. iCalendar Elements Registration Procedure - - The IETF will create a mailing list, icalendar@ietf.org, which can be - used for public discussion of iCalendar elements proposals prior to - registration. Use of the mailing list is strongly encouraged. The - IESG will appoint a designated expert who will monitor the - icalendar@ietf.org mailing list and review registrations. - - Registration of new iCalendar elements MUST be reviewed by the - designated expert and published in an RFC. A Standards Track RFC is - REQUIRED for the registration of new value data types that modify - existing properties, as well as for the registration of participation - status values to be used in "VEVENT" calendar components. A - Standards Track RFC is also REQUIRED for registration of iCalendar - elements that modify iCalendar elements previously documented in a - Standards Track RFC. - - The registration procedure begins when a completed registration - template, defined in the sections below, is sent to - icalendar@ietf.org and iana@iana.org. The designated expert is - expected to tell IANA and the submitter of the registration within - two weeks whether the registration is approved, approved with minor - changes, or rejected with cause. When a registration is rejected - with cause, it can be re-submitted if the concerns listed in the - cause are addressed. Decisions made by the designated expert can be - appealed to the IESG Applications Area Director, then to the IESG. - They follow the normal appeals procedure for IESG decisions. - -8.2.2. Registration Template for Components - - A component is defined by completing the following template. - - Component name: The name of the component. - - Purpose: The purpose of the component. Give a short but clear - description. - - Format definition: The ABNF for the component definition needs to be - specified. - - - - -Desruisseaux Standards Track [Page 152] - -RFC 5545 iCalendar September 2009 - - - Description: Any special notes about the component, how it is to be - used, etc. - - Example(s): One or more examples of instances of the component need - to be specified. - -8.2.3. Registration Template for Properties - - A property is defined by completing the following template. - - Property name: The name of the property. - - Purpose: The purpose of the property. Give a short but clear - description. - - Value type: Any of the valid value types for the property value need - to be specified. The default value type also needs to be - specified. - - Property parameters: Any of the valid property parameters for the - property MUST be specified. - - Conformance: The calendar components in which the property can - appear MUST be specified. - - Description: Any special notes about the property, how it is to be - used, etc. - - Format definition: The ABNF for the property definition needs to be - specified. - - Example(s): One or more examples of instances of the property need - to be specified. - -8.2.4. Registration Template for Parameters - - A parameter is defined by completing the following template. - - Parameter name: The name of the parameter. - - Purpose: The purpose of the parameter. Give a short but clear - description. - - Format definition: The ABNF for the parameter definition needs to be - specified. - - Description: Any special notes about the parameter, how it is to be - used, etc. - - - -Desruisseaux Standards Track [Page 153] - -RFC 5545 iCalendar September 2009 - - - Example(s): One or more examples of instances of the parameter need - to be specified. - -8.2.5. Registration Template for Value Data Types - - A value data type is defined by completing the following template. - - Value name: The name of the value type. - - Purpose: The purpose of the value type. Give a short but clear - description. - - Format definition: The ABNF for the value type definition needs to - be specified. - - Description: Any special notes about the value type, how it is to be - used, etc. - - Example(s): One or more examples of instances of the value type need - to be specified. - -8.2.6. Registration Template for Values - - A value is defined by completing the following template. - - Value: The value literal. - - Purpose: The purpose of the value. Give a short but clear - description. - - Conformance: The calendar properties and/or parameters that can take - this value need to be specified. - - Example(s): One or more examples of instances of the value need to - be specified. - - The following is a fictitious example of a registration of an - iCalendar value: - - Value: TOP-SECRET - - Purpose: This value is used to specify the access classification of - top-secret calendar components. - - Conformance: This value can be used with the "CLASS" property. - - - - - - -Desruisseaux Standards Track [Page 154] - -RFC 5545 iCalendar September 2009 - - - Example(s): The following is an example of this value used with the - "CLASS" property: - - CLASS:TOP-SECRET - -8.3. Initial iCalendar Elements Registries - - The IANA created and maintains the following registries for iCalendar - elements with pointers to appropriate reference documents. - -8.3.1. Components Registry - - The following table has been used to initialize the components - registry. - - +-----------+---------+-------------------------+ - | Component | Status | Reference | - +-----------+---------+-------------------------+ - | VCALENDAR | Current | RFC 5545, Section 3.4 | - | | | | - | VEVENT | Current | RFC 5545, Section 3.6.1 | - | | | | - | VTODO | Current | RFC 5545, Section 3.6.2 | - | | | | - | VJOURNAL | Current | RFC 5545, Section 3.6.3 | - | | | | - | VFREEBUSY | Current | RFC 5545, Section 3.6.4 | - | | | | - | VTIMEZONE | Current | RFC 5545, Section 3.6.5 | - | | | | - | VALARM | Current | RFC 5545, Section 3.6.6 | - | | | | - | STANDARD | Current | RFC 5545, Section 3.6.5 | - | | | | - | DAYLIGHT | Current | RFC 5545, Section 3.6.5 | - +-----------+---------+-------------------------+ - - - - - - - - - - - - - - - -Desruisseaux Standards Track [Page 155] - -RFC 5545 iCalendar September 2009 - - -8.3.2. Properties Registry - - The following table is has been used to initialize the properties - registry. - - +------------------+------------+----------------------------+ - | Property | Status | Reference | - +------------------+------------+----------------------------+ - | CALSCALE | Current | RFC 5545, Section 3.7.1 | - | METHOD | Current | RFC 5545, Section 3.7.2 | - | | | | - | PRODID | Current | RFC 5545, Section 3.7.3 | - | | | | - | VERSION | Current | RFC 5545, Section 3.7.4 | - | | | | - | ATTACH | Current | RFC 5545, Section 3.8.1.1 | - | | | | - | CATEGORIES | Current | RFC 5545, Section 3.8.1.2 | - | | | | - | CLASS | Current | RFC 5545, Section 3.8.1.3 | - | | | | - | COMMENT | Current | RFC 5545, Section 3.8.1.4 | - | | | | - | DESCRIPTION | Current | RFC 5545, Section 3.8.1.5 | - | | | | - | GEO | Current | RFC 5545, Section 3.8.1.6 | - | | | | - | LOCATION | Current | RFC 5545, Section 3.8.1.7 | - | | | | - | PERCENT-COMPLETE | Current | RFC 5545, Section 3.8.1.8 | - | | | | - | PRIORITY | Current | RFC 5545, Section 3.8.1.9 | - | | | | - | RESOURCES | Current | RFC 5545, Section 3.8.1.10 | - | | | | - | STATUS | Current | RFC 5545, Section 3.8.1.11 | - | | | | - | SUMMARY | Current | RFC 5545, Section 3.8.1.12 | - | | | | - | COMPLETED | Current | RFC 5545, Section 3.8.2.1 | - | | | | - | DTEND | Current | RFC 5545, Section 3.8.2.2 | - | | | | - | DUE | Current | RFC 5545, Section 3.8.2.3 | - | | | | - | DTSTART | Current | RFC 5545, Section 3.8.2.4 | - | | | | - | DURATION | Current | RFC 5545, Section 3.8.2.5 | - - - -Desruisseaux Standards Track [Page 156] - -RFC 5545 iCalendar September 2009 - - - | | | | - | FREEBUSY | Current | RFC 5545, Section 3.8.2.6 | - | | | | - | TRANSP | Current | RFC 5545, Section 3.8.2.7 | - | | | | - | TZID | Current | RFC 5545, Section 3.8.3.1 | - | | | | - | TZNAME | Current | RFC 5545, Section 3.8.3.2 | - | | | | - | TZOFFSETFROM | Current | RFC 5545, Section 3.8.3.3 | - | | | | - | TZOFFSETTO | Current | RFC 5545, Section 3.8.3.4 | - | | | | - | TZURL | Current | RFC 5545, Section 3.8.3.5 | - | | | | - | ATTENDEE | Current | RFC 5545, Section 3.8.4.1 | - | | | | - | CONTACT | Current | RFC 5545, Section 3.8.4.2 | - | | | | - | ORGANIZER | Current | RFC 5545, Section 3.8.4.3 | - | | | | - | RECURRENCE-ID | Current | RFC 5545, Section 3.8.4.4 | - | | | | - | RELATED-TO | Current | RFC 5545, Section 3.8.4.5 | - | | | | - | URL | Current | RFC 5545, Section 3.8.4.6 | - | | | | - | UID | Current | RFC 5545, Section 3.8.4.7 | - | | | | - | EXDATE | Current | RFC 5545, Section 3.8.5.1 | - | | | | - | EXRULE | Deprecated | [RFC2445], Section 4.8.5.2 | - | | | | - | RDATE | Current | RFC 5545, Section 3.8.5.2 | - | | | | - | RRULE | Current | RFC 5545, Section 3.8.5.3 | - | | | | - | ACTION | Current | RFC 5545, Section 3.8.6.1 | - | | | | - | REPEAT | Current | RFC 5545, Section 3.8.6.2 | - | | | | - | TRIGGER | Current | RFC 5545, Section 3.8.6.3 | - | | | | - | CREATED | Current | RFC 5545, Section 3.8.7.1 | - | | | | - | DTSTAMP | Current | RFC 5545, Section 3.8.7.2 | - | | | | - | LAST-MODIFIED | Current | RFC 5545, Section 3.8.7.3 | - - - -Desruisseaux Standards Track [Page 157] - -RFC 5545 iCalendar September 2009 - - - | | | | - | SEQUENCE | Current | RFC 5545, Section 3.8.7.4 | - | | | | - | REQUEST-STATUS | Current | RFC 5545, Section 3.8.8.3 | - +------------------+------------+----------------------------+ - -8.3.3. Parameters Registry - - The following table has been used to initialize the parameters - registry. - - +----------------+---------+--------------------------+ - | Parameter | Status | Reference | - +----------------+---------+--------------------------+ - | ALTREP | Current | RFC 5545, Section 3.2.1 | - | | | | - | CN | Current | RFC 5545, Section 3.2.2 | - | | | | - | CUTYPE | Current | RFC 5545, Section 3.2.3 | - | | | | - | DELEGATED-FROM | Current | RFC 5545, Section 3.2.4 | - | | | | - | DELEGATED-TO | Current | RFC 5545, Section 3.2.5 | - | | | | - | DIR | Current | RFC 5545, Section 3.2.6 | - | | | | - | ENCODING | Current | RFC 5545, Section 3.2.7 | - | | | | - | FMTTYPE | Current | RFC 5545, Section 3.2.8 | - | | | | - | FBTYPE | Current | RFC 5545, Section 3.2.9 | - | | | | - | LANGUAGE | Current | RFC 5545, Section 3.2.10 | - | | | | - | MEMBER | Current | RFC 5545, Section 3.2.11 | - | | | | - | PARTSTAT | Current | RFC 5545, Section 3.2.12 | - | | | | - | RANGE | Current | RFC 5545, Section 3.2.13 | - | | | | - | RELATED | Current | RFC 5545, Section 3.2.14 | - | | | | - | RELTYPE | Current | RFC 5545, Section 3.2.15 | - | | | | - | ROLE | Current | RFC 5545, Section 3.2.16 | - | | | | - | RSVP | Current | RFC 5545, Section 3.2.17 | - | | | | - - - -Desruisseaux Standards Track [Page 158] - -RFC 5545 iCalendar September 2009 - - - | SENT-BY | Current | RFC 5545, Section 3.2.18 | - | | | | - | TZID | Current | RFC 5545, Section 3.2.19 | - | | | | - | VALUE | Current | RFC 5545, Section 3.2.20 | - +----------------+---------+--------------------------+ - -8.3.4. Value Data Types Registry - - The following table has been used to initialize the value data types - registry. - - +-----------------+---------+--------------------------+ - | Value Data Type | Status | Reference | - +-----------------+---------+--------------------------+ - | BINARY | Current | RFC 5545, Section 3.3.1 | - | | | | - | BOOLEAN | Current | RFC 5545, Section 3.3.2 | - | | | | - | CAL-ADDRESS | Current | RFC 5545, Section 3.3.3 | - | | | | - | DATE | Current | RFC 5545, Section 3.3.4 | - | | | | - | DATE-TIME | Current | RFC 5545, Section 3.3.5 | - | | | | - | DURATION | Current | RFC 5545, Section 3.3.6 | - | | | | - | FLOAT | Current | RFC 5545, Section 3.3.7 | - | | | | - | INTEGER | Current | RFC 5545, Section 3.3.8 | - | | | | - | PERIOD | Current | RFC 5545, Section 3.3.9 | - | | | | - | RECUR | Current | RFC 5545, Section 3.3.10 | - | | | | - | TEXT | Current | RFC 5545, Section 3.3.11 | - | | | | - | TIME | Current | RFC 5545, Section 3.3.12 | - | | | | - | URI | Current | RFC 5545, Section 3.3.13 | - | | | | - | UTC-OFFSET | Current | RFC 5545, Section 3.3.14 | - +-----------------+---------+--------------------------+ - - - - - - - - -Desruisseaux Standards Track [Page 159] - -RFC 5545 iCalendar September 2009 - - -8.3.5. Calendar User Types Registry - - The following table has been used to initialize the calendar user - types registry. - - +--------------------+---------+-------------------------+ - | Calendar User Type | Status | Reference | - +--------------------+---------+-------------------------+ - | INDIVIDUAL | Current | RFC 5545, Section 3.2.3 | - | | | | - | GROUP | Current | RFC 5545, Section 3.2.3 | - | | | | - | RESOURCE | Current | RFC 5545, Section 3.2.3 | - | | | | - | ROOM | Current | RFC 5545, Section 3.2.3 | - | | | | - | UNKNOWN | Current | RFC 5545, Section 3.2.3 | - +--------------------+---------+-------------------------+ - -8.3.6. Free/Busy Time Types Registry - - The following table has been used to initialize the free/busy time - types registry. - - +---------------------+---------+-------------------------+ - | Free/Busy Time Type | Status | Reference | - +---------------------+---------+-------------------------+ - | FREE | Current | RFC 5545, Section 3.2.9 | - | | | | - | BUSY | Current | RFC 5545, Section 3.2.9 | - | | | | - | BUSY-UNAVAILABLE | Current | RFC 5545, Section 3.2.9 | - | | | | - | BUSY-TENTATIVE | Current | RFC 5545, Section 3.2.9 | - +---------------------+---------+-------------------------+ - - - - - - - - - - - - - - - - -Desruisseaux Standards Track [Page 160] - -RFC 5545 iCalendar September 2009 - - -8.3.7. Participation Statuses Registry - - The following table has been used to initialize the participation - statuses registry. - - +--------------------+---------+--------------------------+ - | Participant Status | Status | Reference | - +--------------------+---------+--------------------------+ - | NEEDS-ACTION | Current | RFC 5545, Section 3.2.12 | - | | | | - | ACCEPTED | Current | RFC 5545, Section 3.2.12 | - | | | | - | DECLINED | Current | RFC 5545, Section 3.2.12 | - | | | | - | TENTATIVE | Current | RFC 5545, Section 3.2.12 | - | | | | - | DELEGATED | Current | RFC 5545, Section 3.2.12 | - | | | | - | COMPLETED | Current | RFC 5545, Section 3.2.12 | - | | | | - | IN-PROCESS | Current | RFC 5545, Section 3.2.12 | - +--------------------+---------+--------------------------+ - -8.3.8. Relationship Types Registry - - The following table has been used to initialize the relationship - types registry. - - +-------------------+---------+--------------------------+ - | Relationship Type | Status | Reference | - +-------------------+---------+--------------------------+ - | CHILD | Current | RFC 5545, Section 3.2.15 | - | | | | - | PARENT | Current | RFC 5545, Section 3.2.15 | - | | | | - | SIBLING | Current | RFC 5545, Section 3.2.15 | - +-------------------+---------+--------------------------+ - - - - - - - - - - - - - - -Desruisseaux Standards Track [Page 161] - -RFC 5545 iCalendar September 2009 - - -8.3.9. Participation Roles Registry - - The following table has been used to initialize the participation - roles registry. - - +-----------------+---------+--------------------------+ - | Role Type | Status | Reference | - +-----------------+---------+--------------------------+ - | CHAIR | Current | RFC 5545, Section 3.2.16 | - | | | | - | REQ-PARTICIPANT | Current | RFC 5545, Section 3.2.16 | - | | | | - | OPT-PARTICIPANT | Current | RFC 5545, Section 3.2.16 | - | | | | - | NON-PARTICIPANT | Current | RFC 5545, Section 3.2.16 | - +-----------------+---------+--------------------------+ - -8.3.10. Actions Registry - - The following table has been used to initialize the actions registry. - - +-----------+------------+----------------------------+ - | Action | Status | Reference | - +-----------+------------+----------------------------+ - | AUDIO | Current | RFC 5545, Section 3.8.6.1 | - | | | | - | DISPLAY | Current | RFC 5545, Section 3.8.6.1 | - | | | | - | EMAIL | Current | RFC 5545, Section 3.8.6.1 | - | | | | - | PROCEDURE | Deprecated | [RFC2445], Section 4.8.6.1 | - +-----------+------------+----------------------------+ - -8.3.11. Classifications Registry - - The following table has been used to initialize the classifications - registry. - - +----------------+---------+---------------------------+ - | Classification | Status | Reference | - +----------------+---------+---------------------------+ - | PUBLIC | Current | RFC 5545, Section 3.8.1.3 | - | | | | - | PRIVATE | Current | RFC 5545, Section 3.8.1.3 | - | | | | - | CONFIDENTIAL | Current | RFC 5545, Section 3.8.1.3 | - +----------------+---------+---------------------------+ - - - - -Desruisseaux Standards Track [Page 162] - -RFC 5545 iCalendar September 2009 - - -8.3.12. Methods Registry - - No values are defined in this document for the "METHOD" property. - -9. Acknowledgments - - The editor of this document wishes to thank Frank Dawson and Derik - Stenerson, the original authors of RFC 2445, as well as the following - individuals who have participated in the drafting, review, and - discussion of this memo: - - Joe Abley, Hervey Allen, Steve Allen, Jay Batson, Oliver Block, - Stephane Bortzmeyer, Chris Bryant, Tantek Celik, Mark Crispin, Cyrus - Daboo, Mike Douglass, Andrew N. Dowden, Lisa Dusseault, Lars Eggert, - Gren Eliot, Pasi Eronen, Ben Fortuna, Ned Freed, Neal Gafter, Ted - Hardie, Tim Hare, Jeffrey Harris, Helge Hess, Paul B. Hill, Thomas - Hnetila, Russ Housley, Leif Johansson, Ciny Joy, Bruce Kahn, Reinhold - Kainhofer, Martin Kiff, Patrice Lapierre, Michiel van Leeuwen, - Jonathan Lennox, Jeff McCullough, Bill McQuillan, Alexey Melnikov, - John W. Noerenberg II, Chuck Norris, Mark Paterson, Simon Pilette, - Arnaud Quillaud, Robert Ransdell, Julian F. Reschke, Caleb - Richardson, Sam Roberts, Dan Romascanu, Mike Samuel, George Sexton, - Nigel Swinson, Clint Talbert, Simon Vaillancourt, Magnus Westerlund, - and Sandy Wills. - - A special thanks to the working group chairs Aki Niemi and Eliot Lear - for their support and guidance. - - The editor would also like to thank the Calendaring and Scheduling - Consortium for advice with this specification, and for organizing - interoperability testing events to help refine it. - - - - - - - - - - - - - - - - - - - - -Desruisseaux Standards Track [Page 163] - -RFC 5545 iCalendar September 2009 - - -10. References - -10.1. Normative References - - [ISO.8601.2004] International Organization for - Standardization, "Data elements and - interchange formats -- Information interchange - -- Representation of dates and times", 2004. - - [ISO.9070.1991] International Organization for - Standardization, "Information Technology_SGML - Support Facilities -- Registration Procedures - for Public Text Owner Identifiers, Second - Edition", April 1991. - - [RFC2045] Freed, N. and N. Borenstein, "Multipurpose - Internet Mail Extensions (MIME) Part One: - Format of Internet Message Bodies", RFC 2045, - November 1996. - - [RFC2046] Freed, N. and N. Borenstein, "Multipurpose - Internet Mail Extensions (MIME) Part Two: - Media Types", RFC 2046, November 1996. - - [RFC2119] Bradner, S., "Key words for use in RFCs to - Indicate Requirement Levels", BCP 14, - RFC 2119, March 1997. - - [RFC2368] Hoffman, P., Masinter, L., and J. Zawinski, - "The mailto URL scheme", RFC 2368, July 1998. - - [RFC3629] Yergeau, F., "UTF-8, a transformation format - of ISO 10646", STD 63, RFC 3629, - November 2003. - - [RFC3986] Berners-Lee, T., Fielding, R., and L. - Masinter, "Uniform Resource Identifier (URI): - Generic Syntax", STD 66, RFC 3986, - January 2005. - - [RFC4288] Freed, N. and J. Klensin, "Media Type - Specifications and Registration Procedures", - BCP 13, RFC 4288, December 2005. - - [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 - Data Encodings", RFC 4648, October 2006. - - - - - -Desruisseaux Standards Track [Page 164] - -RFC 5545 iCalendar September 2009 - - - [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for - Syntax Specifications: ABNF", STD 68, - RFC 5234, January 2008. - - [RFC5646] Phillips, A., Ed., and M. Davis, Ed., "Tags - for Identifying Languages", BCP 47, RFC 5646, - September 2009. - - [US-ASCII] American National Standards Institute, "Coded - Character Set - 7-bit American Standard Code - for Information Interchange", ANSI X3.4, 1986. - -10.2. Informative References - - [2446bis] Daboo, C., "iCalendar Transport-Independent - Interoperability Protocol (iTIP)", Work - in Progress, April 2009. - - [2447bis] Melnikov, A., "iCalendar Message-Based - Interoperability Protocol (iMIP)", Work - in Progress, June 2008. - - [ANSI INCITS 61-1986] International Committee for Information - Technology, "Representation of Geographic - Point Locations for Information Interchange - (formerly ANSI X3.61-1986 (R1997))", ANSI - INCITS 61-1986 (R2007), 2007. - - [RFC1738] Berners-Lee, T., Masinter, L., and M. - McCahill, "Uniform Resource Locators (URL)", - RFC 1738, December 1994. - - [RFC2392] Levinson, E., "Content-ID and Message-ID - Uniform Resource Locators", RFC 2392, - August 1998. - - [RFC2397] Masinter, L., "The "data" URL scheme", - RFC 2397, August 1998. - - [RFC2425] Howes, T., Smith, M., and F. Dawson, "A MIME - Content-Type for Directory Information", - RFC 2425, September 1998. - - [RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory - Profile", RFC 2426, September 1998. - - - - - - -Desruisseaux Standards Track [Page 165] - -RFC 5545 iCalendar September 2009 - - - [RFC2445] Dawson, F. and Stenerson, D., "Internet - Calendaring and Scheduling Core Object - Specification (iCalendar)", RFC 2445, - November 1998. - - [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, - H., Masinter, L., Leach, P., and T. Berners- - Lee, "Hypertext Transfer Protocol -- - HTTP/1.1", RFC 2616, June 1999. - - [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, - May 2000. - - [RFC4516] Smith, M. and T. Howes, "Lightweight Directory - Access Protocol (LDAP): Uniform Resource - Locator", RFC 4516, June 2006. - - [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, - "Calendaring Extensions to WebDAV (CalDAV)", - RFC 4791, March 2007. - - [TZDB] Eggert, P. and A.D. Olson, "Sources for Time - Zone and Daylight Saving Time Data", - July 2009, - . - - [VCAL] Internet Mail Consortium, "vCalendar: The - Electronic Calendaring and Scheduling Exchange - Format", September 1996, - . - - - - - - - - - - - - - - - - - - - - - -Desruisseaux Standards Track [Page 166] - -RFC 5545 iCalendar September 2009 - - -Appendix A. Differences from RFC 2445 - - This appendix contains a list of changes that have been made in the - Internet Calendaring and Scheduling Core Object Specification from - RFC 2445. - -A.1. New Restrictions - - 1. The "DTSTART" property SHOULD be synchronized with the recurrence - rule, if specified. - - 2. The "RRULE" property SHOULD NOT occur more than once in a - component. - - 3. The BYHOUR, BYMINUTE, and BYSECOND rule parts MUST NOT be - specified in the "RRULE" property when the "DTSTART" property is - specified as a DATE value. - - 4. The value type of the "DTEND" or "DUE" properties MUST match the - value type of "DTSTART" property. - - 5. The "DURATION" property can no longer appear in "VFREEBUSY" - components. - -A.2. Restrictions Removed - - 1. The "DTSTART" and "DTEND" properties are no longer required to be - specified as date with local time and time zone reference when - used with a recurrence rule. - -A.3. Deprecated Features - - 1. The "EXRULE" property can no longer be specified in a component. - - 2. The "THISANDPRIOR" value can no longer be used with the "RANGE" - parameter. - - 3. The "PROCEDURE" value can no longer be used with the "ACTION" - property. - - 4. The value type RECUR no longer allows multiple values to be - specified by a COMMA-separated list of values. - - 5. x-name rule parts can no longer be specified in properties of - RECUR value type (e.g., "RRULE"). x-param can be used on RECUR - value type properties instead. - - - - - -Desruisseaux Standards Track [Page 167] - -RFC 5545 iCalendar September 2009 - - -Author's Address - - Bernard Desruisseaux (editor) - Oracle Corporation - 600 blvd. de Maisonneuve West - Suite 1900 - Montreal, QC H3A 3J2 - CANADA - - EMail: bernard.desruisseaux@oracle.com - URI: http://www.oracle.com/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Desruisseaux Standards Track [Page 168] - diff --git a/etc/zoneinfo-outlook-global/.cvsignore b/etc/zoneinfo-outlook-global/.cvsignore deleted file mode 100644 index cd077421a..000000000 --- a/etc/zoneinfo-outlook-global/.cvsignore +++ /dev/null @@ -1,2 +0,0 @@ -zones.h -zones.tab diff --git a/etc/zoneinfo-outlook-global/readme.txt b/etc/zoneinfo-outlook-global/readme.txt deleted file mode 100644 index 7a15d15b4..000000000 --- a/etc/zoneinfo-outlook-global/readme.txt +++ /dev/null @@ -1,2 +0,0 @@ - -Please see the ical4j-zoneinfo-outlook sub-project for Outlook-compatible timezone definitions. \ No newline at end of file diff --git a/etc/zoneinfo-outlook/.cvsignore b/etc/zoneinfo-outlook/.cvsignore deleted file mode 100644 index cd077421a..000000000 --- a/etc/zoneinfo-outlook/.cvsignore +++ /dev/null @@ -1,2 +0,0 @@ -zones.h -zones.tab diff --git a/etc/zoneinfo-outlook/readme.txt b/etc/zoneinfo-outlook/readme.txt deleted file mode 100644 index 7a15d15b4..000000000 --- a/etc/zoneinfo-outlook/readme.txt +++ /dev/null @@ -1,2 +0,0 @@ - -Please see the ical4j-zoneinfo-outlook sub-project for Outlook-compatible timezone definitions. \ No newline at end of file diff --git a/lib/commons-codec.jar b/lib/commons-codec.jar deleted file mode 100644 index ee1bc49ac..000000000 Binary files a/lib/commons-codec.jar and /dev/null differ diff --git a/lib/commons-lang3.jar b/lib/commons-lang3.jar deleted file mode 100644 index a85e539b1..000000000 Binary files a/lib/commons-lang3.jar and /dev/null differ diff --git a/lib/jcl-over-slf4j.jar b/lib/jcl-over-slf4j.jar deleted file mode 100644 index ab898c041..000000000 Binary files a/lib/jcl-over-slf4j.jar and /dev/null differ diff --git a/lib/junit.jar b/lib/junit.jar deleted file mode 100644 index 954851e67..000000000 Binary files a/lib/junit.jar and /dev/null differ diff --git a/lib/slf4j-api.jar b/lib/slf4j-api.jar deleted file mode 100644 index 4c03fa6bb..000000000 Binary files a/lib/slf4j-api.jar and /dev/null differ diff --git a/pom.xml b/pom.xml deleted file mode 100644 index feeec22ef..000000000 --- a/pom.xml +++ /dev/null @@ -1,422 +0,0 @@ - - - - mnode-parent - org.mnode - 1.22 - - 4.0.0 - org.mnode.ical4j - ical4j - iCal4j - 2.0-alpha2-SNAPSHOT - - A Java library for reading and writing iCalendar (*.ics) files - - http://ical4j.sourceforge.net - - - 2.2.1 - - - - SourceForge.net - https://sourceforge.net/tracker/?group_id=107024 - - 2004 - - - ${project.name} - License - ${project.scm.url}/raw-file/tip/LICENSE - - - - - scm:git:https://github.com/ical4j/ical4j.git - scm:git:ssh://git@github.com:ical4j/ical4j.git - https://github.com/ical4j/ical4j - - - - - Mike Douglass - - Rensselaer Polytechnic Institute - - http://www.rpi.edu - - - Randy Letness - - Open Source Applications Foundation - - - http://www.osafoundation.org - - - - Arnaud Quillaud - Oracle Inc. - - http://www.oracle.com - - - - - - - - src/main/resources - - zoneinfo/** - - - zoneinfo/zones.h - zoneinfo/zones.tab - - - - src/main/resources - - overview.html - net/** - META-INF/services/org.codehaus.groovy.runtime.ExtensionModule - - true - - - - - - maven-surefire-plugin - - - **/*Test.java - **/*Spec.java - - - **/CalendarOutputterTest.java - - - - - - com.mycila.maven-license-plugin - maven-license-plugin - - - **/*.ics - **/*.alias - - - - - - maven-jar-plugin - - - ${project.build.outputDirectory}/META-INF/MANIFEST.MF - - - - - - org.apache.felix - maven-bundle-plugin - - - bundle-manifest - process-classes - - manifest - - - - - - net.fortuna.ical4j.* - net.fortuna.ical4j.*,org.apache.commons.lang3.*,org.apache.commons.logging,*;resolution:=optional - - - - - - org.apache.maven.plugins - maven-dependency-plugin - - - unpack-shared-resources - - unpack-dependencies - - generate-resources - - ${project.build.directory}/mnode-tools - mnode-tools - ${project.parent.groupId} - true - - - - - - - maven-assembly-plugin - - - src/main/assembly/bin-assembly.xml - src/main/assembly/src-assembly.xml - - - - - make-assembly - site-deploy - - attached - - - - - - - - maven-enforcer-plugin - 1.2 - - - enforce-sane-versions - - enforce - - - - - - - - - - - - - - - - maven-dependency-plugin - 2.1 - - - maven-assembly-plugin - 2.4 - - - maven-install-plugin - 2.4 - - - maven-resources-plugin - 2.6 - - - maven-clean-plugin - 2.5 - - - maven-deploy-plugin - 2.7 - - - maven-jar-plugin - 2.4 - - - com.mycila.maven-license-plugin - maven-license-plugin - 1.10.b1 - - - - - - - - org.slf4j - jcl-over-slf4j - - - ch.qos.logback - logback-classic - test - - - - commons-codec - commons-codec - 1.6 - - - org.apache.commons - commons-lang3 - 3.1 - - - junit - junit - test - - - commons-io - commons-io - 2.3 - test - - - org.codehaus.groovy - groovy-all - true - - - org.spockframework - spock-core - test - - - org.quartz-scheduler - quartz - 2.1.5 - true - - - org.ccil.cowan.tagsoup - tagsoup - 1.2.1 - test - - - - - ${project.parent.groupId} - mnode-tools - ${project.parent.version} - resources - zip - provided - - - - biz.aQute.bnd - bndlib - 2.2.0 - provided - - - - - - - org.apache.maven.plugins - maven-javadoc-plugin - - - ${project.build.outputDirectory}/overview.html - - - - - - org.apache.maven.plugins - maven-surefire-report-plugin - ${surefire.version} - - - - org.apache.maven.plugins - maven-checkstyle-plugin - ${checkstyle.version} - - - - org.apache.maven.plugins - maven-pmd-plugin - ${pmd.version} - - true - 1.5 - - ${project.build.directory}/mnode-tools/pmd/mnode_ruleset.xml - - - - - - org.apache.maven.plugins - maven-jxr-plugin - - - org.codehaus.mojo - jdepend-maven-plugin - - - org.codehaus.mojo - taglist-maven-plugin - - - org.codehaus.mojo - findbugs-maven-plugin - - - - - - - - - - - - org.hamcrest - hamcrest-core - 1.3 - - - - diff --git a/src/test/groovy/net/fortuna/ical4j/data/CalendarParserImplSpec.groovy b/src/test/groovy/net/fortuna/ical4j/data/CalendarParserImplSpec.groovy index b5b8d708a..6bb20839b 100644 --- a/src/test/groovy/net/fortuna/ical4j/data/CalendarParserImplSpec.groovy +++ b/src/test/groovy/net/fortuna/ical4j/data/CalendarParserImplSpec.groovy @@ -76,7 +76,7 @@ class CalendarParserImplSpec extends Specification { } expect: - Calendar calendar = Calendars.load(filename) + Calendar calendar = Calendars.load(CalendarParserImplSpec.getResource(resource)) cleanup: compatibilityHints.each { @@ -84,8 +84,8 @@ class CalendarParserImplSpec extends Specification { } where: - filename | compatibilityHints - 'etc/samples/valid/bhav23-1.ics' | [] - 'etc/samples/invalid/bhav23-2.ics' | [KEY_RELAXED_UNFOLDING, KEY_RELAXED_PARSING] + resource | compatibilityHints + '/samples/valid/bhav23-1.ics' | [] + '/samples/invalid/bhav23-2.ics' | [KEY_RELAXED_UNFOLDING, KEY_RELAXED_PARSING] } } diff --git a/src/test/java/net/fortuna/ical4j/data/CalendarBuilderTest.java b/src/test/java/net/fortuna/ical4j/data/CalendarBuilderTest.java index f402674a1..03b8c41af 100644 --- a/src/test/java/net/fortuna/ical4j/data/CalendarBuilderTest.java +++ b/src/test/java/net/fortuna/ical4j/data/CalendarBuilderTest.java @@ -148,19 +148,15 @@ public static Test suite() throws FileNotFoundException { File[] testFiles = null; - // single test.. -// suite.addTest(new CalendarBuilderTest("testBuildValid", -// new File("etc/samples/valid/oracle.ics").getPath())); - // valid tests.. - testFiles = new File("etc/samples/valid").listFiles((FileFilter) new NotFileFilter(DirectoryFileFilter.INSTANCE)); + testFiles = new File("src/test/resources/samples/valid").listFiles((FileFilter) new NotFileFilter(DirectoryFileFilter.INSTANCE)); for (int i = 0; i < testFiles.length; i++) { log.info("Sample [" + testFiles[i] + "]"); suite.addTest(new CalendarBuilderTest("testBuildValid", testFiles[i].getPath())); } // invalid tests.. - testFiles = new File("etc/samples/invalid").listFiles((FileFilter) new NotFileFilter(DirectoryFileFilter.INSTANCE)); + testFiles = new File("src/test/resources/samples/invalid").listFiles((FileFilter) new NotFileFilter(DirectoryFileFilter.INSTANCE)); for (int i = 0; i < testFiles.length; i++) { log.info("Sample [" + testFiles[i] + "]"); suite.addTest(new CalendarBuilderTest("testBuildInvalid", testFiles[i].getPath())); diff --git a/src/test/java/net/fortuna/ical4j/data/CalendarBuilderTimezoneTest.java b/src/test/java/net/fortuna/ical4j/data/CalendarBuilderTimezoneTest.java index bf18199d8..0a902fa85 100755 --- a/src/test/java/net/fortuna/ical4j/data/CalendarBuilderTimezoneTest.java +++ b/src/test/java/net/fortuna/ical4j/data/CalendarBuilderTimezoneTest.java @@ -31,7 +31,7 @@ */ package net.fortuna.ical4j.data; -import java.io.FileInputStream; +import java.io.InputStream; import junit.framework.TestCase; import net.fortuna.ical4j.model.Calendar; @@ -84,12 +84,12 @@ public void testVTimeZoneAfterVEvent() throws Exception { // Evolution includes VTIMEZONE defs after VEVENT defs, // which is allowed by RFC-2445 - FileInputStream fin = new FileInputStream( - "etc/samples/valid/evolution.ics"); + InputStream in = getClass().getResourceAsStream( + "/samples/valid/evolution.ics"); CalendarBuilder builder = new CalendarBuilder(); Calendar calendar = null; - calendar = builder.build(fin); + calendar = builder.build(in); assertNotNull("Calendar is null", calendar); ComponentList comps = calendar.getComponents(Component.VEVENT); assertTrue("VEVENT not found", comps.size() == 1); diff --git a/src/test/java/net/fortuna/ical4j/data/CalendarEqualsTest.java b/src/test/java/net/fortuna/ical4j/data/CalendarEqualsTest.java index b70932b0f..015fb01ba 100644 --- a/src/test/java/net/fortuna/ical4j/data/CalendarEqualsTest.java +++ b/src/test/java/net/fortuna/ical4j/data/CalendarEqualsTest.java @@ -170,7 +170,7 @@ public final String getName() { public static TestSuite suite() { TestSuite suite = new TestSuite(); - File[] testFiles = new File("etc/samples/valid").listFiles((FileFilter) new NotFileFilter(DirectoryFileFilter.INSTANCE)); + File[] testFiles = new File("src/test/resources/samples/valid").listFiles((FileFilter) new NotFileFilter(DirectoryFileFilter.INSTANCE)); for (int i = 0; i < testFiles.length; i++) { suite.addTest(new CalendarEqualsTest((File) testFiles[i], true)); } diff --git a/src/test/java/net/fortuna/ical4j/data/CalendarOutputterTest.java b/src/test/java/net/fortuna/ical4j/data/CalendarOutputterTest.java index 98933d0f3..c5157e36c 100644 --- a/src/test/java/net/fortuna/ical4j/data/CalendarOutputterTest.java +++ b/src/test/java/net/fortuna/ical4j/data/CalendarOutputterTest.java @@ -156,14 +156,14 @@ public static Test suite() { File[] testFiles = null; // valid tests.. - testFiles = new File("etc/samples/valid").listFiles((FileFilter) new NotFileFilter(DirectoryFileFilter.INSTANCE)); + testFiles = new File("src/test/resources/samples/valid").listFiles((FileFilter) new NotFileFilter(DirectoryFileFilter.INSTANCE)); for (int i = 0; i < testFiles.length; i++) { log.info("Sample [" + testFiles[i] + "]"); suite.addTest(new CalendarOutputterTest(testFiles[i].getPath())); } // invalid tests.. - testFiles = new File("etc/samples/invalid").listFiles((FileFilter) new NotFileFilter(DirectoryFileFilter.INSTANCE)); + testFiles = new File("src/test/resources/samples/invalid").listFiles((FileFilter) new NotFileFilter(DirectoryFileFilter.INSTANCE)); for (int i = 0; i < testFiles.length; i++) { log.info("Sample [" + testFiles[i] + "]"); suite.addTest(new CalendarOutputterTest(testFiles[i].getPath())); diff --git a/src/test/java/net/fortuna/ical4j/data/CalendarParserImplTest.java b/src/test/java/net/fortuna/ical4j/data/CalendarParserImplTest.java index 9ae3f28a1..3eeef6273 100644 --- a/src/test/java/net/fortuna/ical4j/data/CalendarParserImplTest.java +++ b/src/test/java/net/fortuna/ical4j/data/CalendarParserImplTest.java @@ -39,6 +39,7 @@ import org.slf4j.LoggerFactory; import java.io.IOException; +import java.net.URL; /** * $Id$ @@ -53,17 +54,17 @@ public class CalendarParserImplTest extends TestCase { private static final Logger LOG = LoggerFactory.getLogger(CalendarParserImplTest.class); - private String filename; + private URL resource; private int expectedErrorLineNo; /** - * @param filename + * @param resouces a calendar resource * @param expectedErrorLineNo */ - public CalendarParserImplTest(String filename, int expectedErrorLineNo) { + public CalendarParserImplTest(String resourceString, int expectedErrorLineNo) { super("testParseException"); - this.filename = filename; + this.resource = getClass().getResource(resourceString); this.expectedErrorLineNo = expectedErrorLineNo; } @@ -90,8 +91,8 @@ protected void tearDown() throws Exception { */ public void testParseException() throws IOException { try { - Calendars.load(filename); - fail("Should throw ParserException: [" + filename + "]"); + Calendars.load(resource); + fail("Should throw ParserException: [" + resource + "]"); } catch (ParserException pe) { LOG.info(pe.getMessage()); assertEquals(expectedErrorLineNo, pe.getLineNo()); @@ -106,7 +107,7 @@ public void testParseException() throws IOException { * Overridden to return the current iCalendar file under test. */ public final String getName() { - return super.getName() + " [" + filename + "]"; + return super.getName() + " [" + resource + "]"; } /** @@ -114,20 +115,20 @@ public final String getName() { */ public static TestSuite suite() { TestSuite suite = new TestSuite(); - suite.addTest(new CalendarParserImplTest("etc/samples/invalid/google_aus_holidays.ics", 11)); - suite.addTest(new CalendarParserImplTest("etc/samples/invalid/13-MoonPhase.ics", 215)); + suite.addTest(new CalendarParserImplTest("/samples/invalid/google_aus_holidays.ics", 11)); + suite.addTest(new CalendarParserImplTest("/samples/invalid/13-MoonPhase.ics", 215)); // CalendarParserImpl thinks this error happened on line 24, but you can // see that invalid property "X" starts on line 23, and ends there. -// suite.addTest(new CalendarParserImplTest("etc/samples/invalid/CalendarDataFile.ics", 23)); - suite.addTest(new CalendarParserImplTest("etc/samples/invalid/CalendarDataFile.ics", 24)); +// suite.addTest(new CalendarParserImplTest("samples/invalid/CalendarDataFile.ics", 23)); + suite.addTest(new CalendarParserImplTest("/samples/invalid/CalendarDataFile.ics", 24)); - suite.addTest(new CalendarParserImplTest("etc/samples/invalid/overlaps.ics", 1)); - suite.addTest(new CalendarParserImplTest("etc/samples/invalid/phpicalendar_sample.ics", 93)); - suite.addTest(new CalendarParserImplTest("etc/samples/invalid/schedule-unstable.ics", 196)); - suite.addTest(new CalendarParserImplTest("etc/samples/invalid/smallcluster.ics", 2)); - suite.addTest(new CalendarParserImplTest("etc/samples/invalid/twinkle.ics", 67)); - suite.addTest(new CalendarParserImplTest("etc/samples/invalid/zidestoreical4jbomb.ics", 10)); + suite.addTest(new CalendarParserImplTest("/samples/invalid/overlaps.ics", 1)); + suite.addTest(new CalendarParserImplTest("/samples/invalid/phpicalendar_sample.ics", 93)); + suite.addTest(new CalendarParserImplTest("/samples/invalid/schedule-unstable.ics", 196)); + suite.addTest(new CalendarParserImplTest("/samples/invalid/smallcluster.ics", 2)); + suite.addTest(new CalendarParserImplTest("/samples/invalid/twinkle.ics", 67)); + suite.addTest(new CalendarParserImplTest("/samples/invalid/zidestoreical4jbomb.ics", 10)); return suite; } } diff --git a/src/test/java/net/fortuna/ical4j/data/HCalendarParserTest.java b/src/test/java/net/fortuna/ical4j/data/HCalendarParserTest.java index 9726bf27a..457315454 100755 --- a/src/test/java/net/fortuna/ical4j/data/HCalendarParserTest.java +++ b/src/test/java/net/fortuna/ical4j/data/HCalendarParserTest.java @@ -60,12 +60,12 @@ protected void setUp() throws Exception { * Test method for {@link net.fortuna.ical4j.data.HCalendarParser#parse(java.io.Reader, net.fortuna.ical4j.data.ContentHandler)}. */ public void testParseReaderContentHandler() throws IOException, ParserException { - Calendar icsCalendar = Calendars.load("etc/samples/hcalendar/example1.ics"); + Calendar icsCalendar = Calendars.load(getClass().getResource("/samples/hcalendar/example1.ics")); // remove prod-id which seems to be not handled by hcalendar.. icsCalendar.getProperties().remove(icsCalendar.getProperty(Property.PRODID)); CalendarBuilder builder = new CalendarBuilder(new HCalendarParser()); - Calendar hcalCalendar = builder.build(new FileReader("etc/samples/hcalendar/example1.html")); + Calendar hcalCalendar = builder.build(getClass().getResourceAsStream("/samples/hcalendar/example1.html")); // assertEquals(icsCalendar, hcalCalendar); assertEquals(icsCalendar.getProperties().size(), hcalCalendar.getProperties().size()); diff --git a/src/test/java/net/fortuna/ical4j/filter/FilterTest.java b/src/test/java/net/fortuna/ical4j/filter/FilterTest.java index 1d1344aec..28e4b4e94 100644 --- a/src/test/java/net/fortuna/ical4j/filter/FilterTest.java +++ b/src/test/java/net/fortuna/ical4j/filter/FilterTest.java @@ -115,9 +115,6 @@ public void testFilteredSize() { */ @SuppressWarnings("unchecked") public static TestSuite suite() throws FileNotFoundException, IOException, ParserException, URISyntaxException { -// CalendarBuilder builder = new CalendarBuilder(); -// Calendar calendar = builder.build(new FileReader("etc/samples/valid/incoming.ics")); - Organizer organizer = new Organizer(new URI("Mailto:B@example.com")); Attendee a1 = new Attendee(new URI("Mailto:A@example.com")); Attendee a2 = new Attendee(new URI("Mailto:C@example.com")); diff --git a/src/test/java/net/fortuna/ical4j/filter/PeriodRuleTest.java b/src/test/java/net/fortuna/ical4j/filter/PeriodRuleTest.java index d39ec6541..0dac22bd7 100644 --- a/src/test/java/net/fortuna/ical4j/filter/PeriodRuleTest.java +++ b/src/test/java/net/fortuna/ical4j/filter/PeriodRuleTest.java @@ -120,7 +120,7 @@ public void testRecurrenceRules() throws ParserException, IOException, ParseExce */ public static TestSuite suite() throws FileNotFoundException, IOException, ParserException { CalendarBuilder builder = new CalendarBuilder(); - Calendar calendar = builder.build(new FileReader("etc/samples/valid/Australian_TV_Melbourne.ics")); + Calendar calendar = builder.build(PeriodRuleTest.class.getResourceAsStream("/samples/valid/Australian_TV_Melbourne.ics")); TestSuite suite = new TestSuite(); @@ -170,7 +170,7 @@ public static TestSuite suite() throws FileNotFoundException, IOException, Parse } // Test exclusion of particular dates.. - Calendar exCal = Calendars.load("etc/samples/valid/friday13.ics"); + Calendar exCal = Calendars.load(PeriodRuleTest.class.getResource("/samples/valid/friday13.ics")); cal = java.util.Calendar.getInstance(); cal.set(1997, 8, 2, 9, 0, 0); DateTime startDt = new DateTime(cal.getTime()); @@ -179,7 +179,7 @@ public static TestSuite suite() throws FileNotFoundException, IOException, Parse suite.addTest(new PeriodRuleTest("testFilteredIsEmpty", filter, exCal.getComponents())); // Test exclusion of particular date patterns.. - exCal = Calendars.load("etc/samples/valid/friday13-NOT.ics"); + exCal = Calendars.load(PeriodRuleTest.class.getResource("/samples/valid/friday13-NOT.ics")); cal = java.util.Calendar.getInstance(); cal.set(1997, 8, 2, 9, 0, 0); startDt = new DateTime(cal.getTime()); @@ -189,7 +189,7 @@ public static TestSuite suite() throws FileNotFoundException, IOException, Parse // Asia/Singapore test.. CompatibilityHints.setHintEnabled(CompatibilityHints.KEY_RELAXED_UNFOLDING, true); - calendar = Calendars.load("etc/samples/valid/2207678.ics"); + calendar = Calendars.load(PeriodRuleTest.class.getResource("/samples/valid/2207678.ics")); CompatibilityHints.clearHintEnabled(CompatibilityHints.KEY_RELAXED_UNFOLDING); TimeZone timeZone = TimeZone.getTimeZone("Asia/Singapore"); diff --git a/src/test/java/net/fortuna/ical4j/model/IndexedComponentListTest.java b/src/test/java/net/fortuna/ical4j/model/IndexedComponentListTest.java index 9f780c73b..e02d9240d 100644 --- a/src/test/java/net/fortuna/ical4j/model/IndexedComponentListTest.java +++ b/src/test/java/net/fortuna/ical4j/model/IndexedComponentListTest.java @@ -61,7 +61,7 @@ public class IndexedComponentListTest extends TestCase { */ protected void setUp() throws Exception { CalendarBuilder builder = new CalendarBuilder(); - calendar = builder.build(new FileReader("etc/samples/valid/Australian_TV_Melbourne.ics")); + calendar = builder.build(getClass().getResourceAsStream("/samples/valid/Australian_TV_Melbourne.ics")); } /** diff --git a/src/test/java/net/fortuna/ical4j/model/IndexedPropertyListTest.java b/src/test/java/net/fortuna/ical4j/model/IndexedPropertyListTest.java index b49121fec..637329d32 100644 --- a/src/test/java/net/fortuna/ical4j/model/IndexedPropertyListTest.java +++ b/src/test/java/net/fortuna/ical4j/model/IndexedPropertyListTest.java @@ -59,7 +59,7 @@ public class IndexedPropertyListTest extends TestCase { */ protected void setUp() throws Exception { CalendarBuilder builder = new CalendarBuilder(); - calendar = builder.build(new FileReader("etc/samples/valid/incoming.ics")); + calendar = builder.build(getClass().getResourceAsStream("/samples/valid/incoming.ics")); } /** diff --git a/src/test/java/net/fortuna/ical4j/model/component/VEventTest.java b/src/test/java/net/fortuna/ical4j/model/component/VEventTest.java index 720b5aa65..4e69b90db 100644 --- a/src/test/java/net/fortuna/ical4j/model/component/VEventTest.java +++ b/src/test/java/net/fortuna/ical4j/model/component/VEventTest.java @@ -47,9 +47,10 @@ import org.slf4j.LoggerFactory; import java.io.File; -import java.io.FileInputStream; +import java.io.InputStream; import java.io.IOException; import java.net.URISyntaxException; +import java.net.URL; import java.text.ParseException; import java.util.Calendar; import java.util.Iterator; @@ -144,14 +145,14 @@ private static Calendar getCalendarInstance() { * @param filename * @return */ - private net.fortuna.ical4j.model.Calendar loadCalendar(String filename) + private net.fortuna.ical4j.model.Calendar loadCalendar(String resourceString) throws IOException, ParserException, ValidationException { net.fortuna.ical4j.model.Calendar calendar = Calendars.load( - filename); + getClass().getResource(resourceString)); calendar.validate(); - log.info("File: " + filename); + log.info("Resource: " + resourceString); if (log.isDebugEnabled()) { log.debug("Calendar:\n=========\n" + calendar.toString()); @@ -396,9 +397,9 @@ public final void testGetConsumedTimeMonthly() throws Exception { public final void testGetConsumedTime2() throws Exception { - String filename = "etc/samples/valid/derryn.ics"; + String resource = "/samples/valid/derryn.ics"; - net.fortuna.ical4j.model.Calendar calendar = loadCalendar(filename); + net.fortuna.ical4j.model.Calendar calendar = loadCalendar(resource); Date start = new Date(); Calendar endCal = getCalendarInstance(); @@ -418,9 +419,9 @@ public final void testGetConsumedTime2() throws Exception { } public final void testGetConsumedTime3() throws Exception { - String filename = "etc/samples/valid/calconnect10.ics"; + String resource = "/samples/valid/calconnect10.ics"; - net.fortuna.ical4j.model.Calendar calendar = loadCalendar(filename); + net.fortuna.ical4j.model.Calendar calendar = loadCalendar(resource); VEvent vev = (VEvent) calendar.getComponent(Component.VEVENT); @@ -510,8 +511,8 @@ public void testGetConsumedTimeWithExDate() throws ParseException { * @throws ParseException */ public void testGetConsumedTimeWithExDate2() throws IOException, ParserException { - FileInputStream fin = new FileInputStream("etc/samples/valid/friday13.ics"); - net.fortuna.ical4j.model.Calendar calendar = new CalendarBuilder().build(fin); + InputStream in = getClass().getResourceAsStream("/samples/valid/friday13.ics"); + net.fortuna.ical4j.model.Calendar calendar = new CalendarBuilder().build(in); VEvent event = (VEvent) calendar.getComponent(Component.VEVENT); @@ -756,10 +757,10 @@ public static TestSuite suite() throws ValidationException, ParseException, IOEx // test iTIP validation.. // File[] testFiles = new File("etc/samples/valid").listFiles((FileFilter) new NotFileFilter(DirectoryFileFilter.INSTANCE)); - File[] testFiles = new File[]{new File("etc/samples/valid/calconnect.ics"), new File("etc/samples/valid/calconnect10.ics")}; + URL[] testFiles = new URL[]{VEventTest.class.getResource("/samples/valid/calconnect.ics"), VEventTest.class.getResource("/samples/valid/calconnect10.ics")}; for (int i = 0; i < testFiles.length; i++) { log.info("Sample [" + testFiles[i] + "]"); - net.fortuna.ical4j.model.Calendar calendar = Calendars.load(testFiles[i].getPath()); + net.fortuna.ical4j.model.Calendar calendar = Calendars.load(testFiles[i]); if (Method.PUBLISH.equals(calendar.getProperty(Property.METHOD))) { for (Iterator it = calendar.getComponents(Component.VEVENT).iterator(); it.hasNext(); ) { VEvent event1 = (VEvent) it.next(); diff --git a/src/test/java/net/fortuna/ical4j/model/component/VFreeBusyTest.java b/src/test/java/net/fortuna/ical4j/model/component/VFreeBusyTest.java index a549b15f7..3da41bf50 100644 --- a/src/test/java/net/fortuna/ical4j/model/component/VFreeBusyTest.java +++ b/src/test/java/net/fortuna/ical4j/model/component/VFreeBusyTest.java @@ -41,7 +41,7 @@ import org.slf4j.Logger; import org.slf4j.LoggerFactory; -import java.io.FileInputStream; +import java.io.InputStream; import java.io.IOException; import java.net.URISyntaxException; import java.text.ParseException; @@ -184,10 +184,10 @@ public final void testVFreeBusyComponentList() throws Exception { * Class under test for void VFreeBusy(ComponentList) */ public final void testVFreeBusyComponentList2() throws Exception { - FileInputStream fin = new FileInputStream("etc/samples/invalid/core.ics"); + InputStream in = getClass().getResourceAsStream("/samples/invalid/core.ics"); CalendarBuilder builder = new CalendarBuilder(); - Calendar calendar = builder.build(fin); + Calendar calendar = builder.build(in); DateTime startDate = new DateTime(0); DateTime endDate = new DateTime(); diff --git a/src/test/java/net/fortuna/ical4j/model/parameter/TzIdTest.java b/src/test/java/net/fortuna/ical4j/model/parameter/TzIdTest.java index b058eb8d5..3657617e7 100644 --- a/src/test/java/net/fortuna/ical4j/model/parameter/TzIdTest.java +++ b/src/test/java/net/fortuna/ical4j/model/parameter/TzIdTest.java @@ -58,7 +58,7 @@ public class TzIdTest extends TestCase { public void testTzIdCompatibility() throws IOException, ParserException { CalendarBuilder builder = new CalendarBuilder(); - Calendar calendar = builder.build(new FileInputStream("etc/samples/valid/tmeher.ics")); + Calendar calendar = builder.build(getClass().getResourceAsStream("/samples/valid/tmeher.ics")); // ensure the calendar is loaded properly.. assertNotNull(calendar); diff --git a/src/test/java/net/fortuna/ical4j/model/property/AttendeeTest.java b/src/test/java/net/fortuna/ical4j/model/property/AttendeeTest.java index b02fb8c15..23f018257 100644 --- a/src/test/java/net/fortuna/ical4j/model/property/AttendeeTest.java +++ b/src/test/java/net/fortuna/ical4j/model/property/AttendeeTest.java @@ -93,7 +93,7 @@ public void testAttendeeString() throws URISyntaxException { public void testRelaxedParsing() throws IOException, ParserException { try { - Calendars.load("etc/samples/invalid/groupwise.ics"); + Calendars.load(getClass().getResource("/samples/invalid/groupwise.ics")); fail("Should throw URISyntaxException"); } catch (ParserException pe) { @@ -101,7 +101,7 @@ public void testRelaxedParsing() throws IOException, ParserException { } CompatibilityHints.setHintEnabled(CompatibilityHints.KEY_RELAXED_PARSING, true); - Calendar calendar = Calendars.load("etc/samples/invalid/groupwise.ics"); + Calendar calendar = Calendars.load(getClass().getResource("/samples/invalid/groupwise.ics")); Attendee attendee = (Attendee) calendar.getComponent(Component.VEVENT).getProperty(Property.ATTENDEE); assertNotNull(attendee.getCalAddress()); diff --git a/src/test/java/net/fortuna/ical4j/model/property/CategoriesTest.java b/src/test/java/net/fortuna/ical4j/model/property/CategoriesTest.java index 86261d0e4..ad792f048 100644 --- a/src/test/java/net/fortuna/ical4j/model/property/CategoriesTest.java +++ b/src/test/java/net/fortuna/ical4j/model/property/CategoriesTest.java @@ -141,7 +141,7 @@ public static TestSuite suite() throws IOException, ValidationException, suite.addTest(new CategoriesTest(categories, list)); // Test escaping of categories string representation.. - Calendar calendar = Calendars.load("etc/samples/valid/categories.ics"); + Calendar calendar = Calendars.load(CategoriesTest.class.getResource("/samples/valid/categories.ics")); Categories orig = (Categories) calendar.getComponent(Component.VEVENT) .getProperty(Property.CATEGORIES); diff --git a/src/test/java/net/fortuna/ical4j/model/property/DescriptionTest.java b/src/test/java/net/fortuna/ical4j/model/property/DescriptionTest.java index c202e9999..d4e266b40 100755 --- a/src/test/java/net/fortuna/ical4j/model/property/DescriptionTest.java +++ b/src/test/java/net/fortuna/ical4j/model/property/DescriptionTest.java @@ -64,7 +64,7 @@ public DescriptionTest(Property property, String expectedValue) { public static TestSuite suite() throws IOException, ParserException { TestSuite suite = new TestSuite(); // Test correct parsing of text with tabs. - Calendar calendar = Calendars.load("etc/samples/valid/mansour.ics"); + Calendar calendar = Calendars.load(DescriptionTest.class.getResource("/samples/valid/mansour.ics")); Component event = calendar.getComponent(Component.VEVENT); suite.addTest(new DescriptionTest(event .getProperty(Property.DESCRIPTION), "Test\t\ttabs")); diff --git a/src/test/java/net/fortuna/ical4j/model/property/ExDateTest.java b/src/test/java/net/fortuna/ical4j/model/property/ExDateTest.java index 5d1341cb4..232159a48 100644 --- a/src/test/java/net/fortuna/ical4j/model/property/ExDateTest.java +++ b/src/test/java/net/fortuna/ical4j/model/property/ExDateTest.java @@ -76,7 +76,7 @@ protected void tearDown() throws Exception { */ public void testTimeZones() throws Exception { CalendarBuilder builder = new CalendarBuilder(); - Calendar calendar = builder.build(new FileInputStream("etc/samples/valid/EXDATE.ics")); + Calendar calendar = builder.build(getClass().getResourceAsStream("/samples/valid/EXDATE.ics")); Component event = calendar.getComponent(Component.VEVENT); PropertyList exdates = event.getProperties(Property.EXDATE); diff --git a/src/test/java/net/fortuna/ical4j/model/property/LocationTest.java b/src/test/java/net/fortuna/ical4j/model/property/LocationTest.java index f5ffea1c9..e369fc51e 100644 --- a/src/test/java/net/fortuna/ical4j/model/property/LocationTest.java +++ b/src/test/java/net/fortuna/ical4j/model/property/LocationTest.java @@ -73,7 +73,7 @@ public LocationTest(String testMethod, Location property) { * @throws ParserException */ public void testQuotedText() throws IOException, ParserException { - Calendar calendar = Calendars.load("etc/samples/valid/mansour.ics"); + Calendar calendar = Calendars.load(getClass().getResource("/samples/valid/mansour.ics")); Component event = calendar.getComponent(Component.VEVENT); assertEquals("At \"The Terrace\" Complex > Melbourne \"\\,", event.getProperty(Property.LOCATION).getValue()); } @@ -86,7 +86,7 @@ public void testQuotedText() throws IOException, ParserException { public static TestSuite suite() throws IOException, ParserException { TestSuite suite = new TestSuite(); //testQuotedText.. - Calendar calendar = Calendars.load("etc/samples/valid/mansour.ics"); + Calendar calendar = Calendars.load(LocationTest.class.getResource("/samples/valid/mansour.ics")); Component event = calendar.getComponent(Component.VEVENT); Location location = (Location) event.getProperty(Property.LOCATION); suite.addTest(new LocationTest(location, "At \"The Terrace\" Complex > Melbourne \"\\,")); diff --git a/src/test/java/net/fortuna/ical4j/model/property/SummaryTest.java b/src/test/java/net/fortuna/ical4j/model/property/SummaryTest.java index 01a8fab2a..f9b9b76fd 100644 --- a/src/test/java/net/fortuna/ical4j/model/property/SummaryTest.java +++ b/src/test/java/net/fortuna/ical4j/model/property/SummaryTest.java @@ -75,7 +75,7 @@ public SummaryTest(String testMethod, Summary property) { public static TestSuite suite() throws IOException, ParserException { TestSuite suite = new TestSuite(); // Test correct parsing of quoted text.. - Calendar calendar = Calendars.load("etc/samples/valid/mansour.ics"); + Calendar calendar = Calendars.load(SummaryTest.class.getResource("/samples/valid/mansour.ics")); Component event = calendar.getComponent(Component.VEVENT); Summary summary = (Summary) event.getProperty(Property.SUMMARY); suite.addTest(new SummaryTest(summary, "A colon with spaces on either side : like that")); diff --git a/src/test/java/net/fortuna/ical4j/util/CalendarsTest.java b/src/test/java/net/fortuna/ical4j/util/CalendarsTest.java index 442e12eed..02ec7b190 100644 --- a/src/test/java/net/fortuna/ical4j/util/CalendarsTest.java +++ b/src/test/java/net/fortuna/ical4j/util/CalendarsTest.java @@ -42,6 +42,7 @@ import java.io.FileNotFoundException; import java.io.IOException; +import java.net.URL; import java.nio.charset.Charset; import java.util.ArrayList; import java.util.List; @@ -60,6 +61,8 @@ public class CalendarsTest extends TestCase { private static Logger LOG = LoggerFactory.getLogger(CalendarsTest.class); private String path; + + private URL resource; private Calendar[] calendars; @@ -78,6 +81,7 @@ public class CalendarsTest extends TestCase { public CalendarsTest(String testMethod, String path) { super(testMethod); this.path = path; + this.resource = getClass().getResource(path); } /** @@ -114,7 +118,7 @@ public CalendarsTest(String testMethod, Calendar calendar, Charset charset, Stri * @throws ParserException */ public void testLoad() throws IOException, ParserException { - assertNotNull(Calendars.load(path)); + assertNotNull(Calendars.load(resource)); } /** @@ -139,7 +143,7 @@ public void testLoadFileNotFoundException() throws IOException, ParserException */ public void testLoadParserException() throws IOException { try { - Calendars.load(path); + Calendars.load(resource); fail("Should throw ParserException"); } catch (ParserException pe) { LOG.info("Caught exception: " + pe.getMessage()); @@ -190,21 +194,21 @@ public void testGetContentType() { public static TestSuite suite() throws IOException, ParserException { TestSuite suite = new TestSuite(); - suite.addTest(new CalendarsTest("testLoad", "etc/samples/valid/Australian32Holidays.ics")); - suite.addTest(new CalendarsTest("testLoadFileNotFoundException", "etc/samples/valid/doesnt-exist.ics")); - suite.addTest(new CalendarsTest("testLoadParserException", "etc/samples/invalid/google_aus_holidays.ics")); + suite.addTest(new CalendarsTest("testLoad", "/samples/valid/Australian32Holidays.ics")); + suite.addTest(new CalendarsTest("testLoadFileNotFoundException", "/samples/valid/doesnt-exist.ics")); + suite.addTest(new CalendarsTest("testLoadParserException", "/samples/invalid/google_aus_holidays.ics")); List calendars = new ArrayList(); - calendars.add(Calendars.load("etc/samples/valid/Australian32Holidays.ics")); - calendars.add(Calendars.load("etc/samples/valid/OZMovies.ics")); + calendars.add(Calendars.load(CalendarsTest.class.getResource("/samples/valid/Australian32Holidays.ics"))); + calendars.add(Calendars.load(CalendarsTest.class.getResource("/samples/valid/OZMovies.ics"))); suite.addTest(new CalendarsTest("testMerge", (Calendar[]) calendars.toArray(new Calendar[calendars.size()]))); - Calendar calendar = Calendars.load("etc/samples/valid/Australian32Holidays.ics"); + Calendar calendar = Calendars.load(CalendarsTest.class.getResource("/samples/valid/Australian32Holidays.ics")); suite.addTest(new CalendarsTest("testSplit", calendar, 10)); suite.addTest(new CalendarsTest("testGetContentType", calendar, null, "text/calendar")); - calendar = Calendars.load("etc/samples/valid/OZMovies.ics"); + calendar = Calendars.load(CalendarsTest.class.getResource("/samples/valid/OZMovies.ics")); suite.addTest(new CalendarsTest("testGetContentType", calendar, null, "text/calendar; method=PUBLISH")); suite.addTest(new CalendarsTest("testGetContentType", calendar, Charset.forName("US-ASCII"), "text/calendar; method=PUBLISH; charset=US-ASCII")); diff --git a/etc/samples/hcalendar/example1.html b/src/test/resources/samples/hcalendar/example1.html similarity index 100% rename from etc/samples/hcalendar/example1.html rename to src/test/resources/samples/hcalendar/example1.html diff --git a/etc/samples/hcalendar/example1.ics b/src/test/resources/samples/hcalendar/example1.ics similarity index 100% rename from etc/samples/hcalendar/example1.ics rename to src/test/resources/samples/hcalendar/example1.ics diff --git a/etc/samples/invalid/0.ics b/src/test/resources/samples/invalid/0.ics similarity index 100% rename from etc/samples/invalid/0.ics rename to src/test/resources/samples/invalid/0.ics diff --git a/etc/samples/invalid/13-MoonPhase.ics b/src/test/resources/samples/invalid/13-MoonPhase.ics similarity index 100% rename from etc/samples/invalid/13-MoonPhase.ics rename to src/test/resources/samples/invalid/13-MoonPhase.ics diff --git a/etc/samples/invalid/CalendarDataFile.ics b/src/test/resources/samples/invalid/CalendarDataFile.ics similarity index 100% rename from etc/samples/invalid/CalendarDataFile.ics rename to src/test/resources/samples/invalid/CalendarDataFile.ics diff --git a/etc/samples/invalid/bhav23-2.ics b/src/test/resources/samples/invalid/bhav23-2.ics similarity index 100% rename from etc/samples/invalid/bhav23-2.ics rename to src/test/resources/samples/invalid/bhav23-2.ics diff --git a/etc/samples/invalid/boeing.ics b/src/test/resources/samples/invalid/boeing.ics similarity index 100% rename from etc/samples/invalid/boeing.ics rename to src/test/resources/samples/invalid/boeing.ics diff --git a/etc/samples/invalid/calconnect.ics b/src/test/resources/samples/invalid/calconnect.ics similarity index 100% rename from etc/samples/invalid/calconnect.ics rename to src/test/resources/samples/invalid/calconnect.ics diff --git a/etc/samples/invalid/core.ics b/src/test/resources/samples/invalid/core.ics similarity index 100% rename from etc/samples/invalid/core.ics rename to src/test/resources/samples/invalid/core.ics diff --git a/etc/samples/invalid/eli_courtwright.ics b/src/test/resources/samples/invalid/eli_courtwright.ics similarity index 100% rename from etc/samples/invalid/eli_courtwright.ics rename to src/test/resources/samples/invalid/eli_courtwright.ics diff --git a/etc/samples/invalid/eli_test.ics b/src/test/resources/samples/invalid/eli_test.ics similarity index 100% rename from etc/samples/invalid/eli_test.ics rename to src/test/resources/samples/invalid/eli_test.ics diff --git a/etc/samples/invalid/google_aus_holidays.ics b/src/test/resources/samples/invalid/google_aus_holidays.ics similarity index 100% rename from etc/samples/invalid/google_aus_holidays.ics rename to src/test/resources/samples/invalid/google_aus_holidays.ics diff --git a/etc/samples/invalid/groupwise.ics b/src/test/resources/samples/invalid/groupwise.ics similarity index 100% rename from etc/samples/invalid/groupwise.ics rename to src/test/resources/samples/invalid/groupwise.ics diff --git a/etc/samples/invalid/lastfm.ics b/src/test/resources/samples/invalid/lastfm.ics similarity index 100% rename from etc/samples/invalid/lastfm.ics rename to src/test/resources/samples/invalid/lastfm.ics diff --git a/etc/samples/invalid/multiple_calendars.ics b/src/test/resources/samples/invalid/multiple_calendars.ics similarity index 100% rename from etc/samples/invalid/multiple_calendars.ics rename to src/test/resources/samples/invalid/multiple_calendars.ics diff --git a/etc/samples/invalid/overlaps.ics b/src/test/resources/samples/invalid/overlaps.ics similarity index 100% rename from etc/samples/invalid/overlaps.ics rename to src/test/resources/samples/invalid/overlaps.ics diff --git a/etc/samples/invalid/phpicalendar_sample.ics b/src/test/resources/samples/invalid/phpicalendar_sample.ics similarity index 100% rename from etc/samples/invalid/phpicalendar_sample.ics rename to src/test/resources/samples/invalid/phpicalendar_sample.ics diff --git a/etc/samples/invalid/schedule-unstable.ics b/src/test/resources/samples/invalid/schedule-unstable.ics similarity index 100% rename from etc/samples/invalid/schedule-unstable.ics rename to src/test/resources/samples/invalid/schedule-unstable.ics diff --git a/etc/samples/invalid/smallcluster.ics b/src/test/resources/samples/invalid/smallcluster.ics similarity index 100% rename from etc/samples/invalid/smallcluster.ics rename to src/test/resources/samples/invalid/smallcluster.ics diff --git a/etc/samples/invalid/twinkle.ics b/src/test/resources/samples/invalid/twinkle.ics similarity index 100% rename from etc/samples/invalid/twinkle.ics rename to src/test/resources/samples/invalid/twinkle.ics diff --git a/etc/samples/invalid/twinkle_orig.ics b/src/test/resources/samples/invalid/twinkle_orig.ics similarity index 100% rename from etc/samples/invalid/twinkle_orig.ics rename to src/test/resources/samples/invalid/twinkle_orig.ics diff --git a/etc/samples/invalid/zidestoreical4jbomb.ics b/src/test/resources/samples/invalid/zidestoreical4jbomb.ics similarity index 100% rename from etc/samples/invalid/zidestoreical4jbomb.ics rename to src/test/resources/samples/invalid/zidestoreical4jbomb.ics diff --git a/etc/samples/valid/1106817412.ics b/src/test/resources/samples/valid/1106817412.ics similarity index 100% rename from etc/samples/valid/1106817412.ics rename to src/test/resources/samples/valid/1106817412.ics diff --git a/etc/samples/valid/2207678.ics b/src/test/resources/samples/valid/2207678.ics similarity index 100% rename from etc/samples/valid/2207678.ics rename to src/test/resources/samples/valid/2207678.ics diff --git a/etc/samples/valid/3.ics b/src/test/resources/samples/valid/3.ics similarity index 100% rename from etc/samples/valid/3.ics rename to src/test/resources/samples/valid/3.ics diff --git a/etc/samples/valid/4.ics b/src/test/resources/samples/valid/4.ics similarity index 100% rename from etc/samples/valid/4.ics rename to src/test/resources/samples/valid/4.ics diff --git a/etc/samples/valid/6.ics b/src/test/resources/samples/valid/6.ics similarity index 100% rename from etc/samples/valid/6.ics rename to src/test/resources/samples/valid/6.ics diff --git a/etc/samples/valid/7.ics b/src/test/resources/samples/valid/7.ics similarity index 100% rename from etc/samples/valid/7.ics rename to src/test/resources/samples/valid/7.ics diff --git a/etc/samples/valid/ArgentinaHolidays.ics b/src/test/resources/samples/valid/ArgentinaHolidays.ics similarity index 100% rename from etc/samples/valid/ArgentinaHolidays.ics rename to src/test/resources/samples/valid/ArgentinaHolidays.ics diff --git a/etc/samples/valid/Australian32Holidays.ics b/src/test/resources/samples/valid/Australian32Holidays.ics similarity index 100% rename from etc/samples/valid/Australian32Holidays.ics rename to src/test/resources/samples/valid/Australian32Holidays.ics diff --git a/etc/samples/valid/Australian_TV_Melbourne.ics b/src/test/resources/samples/valid/Australian_TV_Melbourne.ics similarity index 100% rename from etc/samples/valid/Australian_TV_Melbourne.ics rename to src/test/resources/samples/valid/Australian_TV_Melbourne.ics diff --git a/etc/samples/valid/BCP321928.ics b/src/test/resources/samples/valid/BCP321928.ics similarity index 100% rename from etc/samples/valid/BCP321928.ics rename to src/test/resources/samples/valid/BCP321928.ics diff --git a/etc/samples/valid/Belgische32feestdagen.ics b/src/test/resources/samples/valid/Belgische32feestdagen.ics similarity index 100% rename from etc/samples/valid/Belgische32feestdagen.ics rename to src/test/resources/samples/valid/Belgische32feestdagen.ics diff --git a/etc/samples/valid/Buddhist.ics b/src/test/resources/samples/valid/Buddhist.ics similarity index 100% rename from etc/samples/valid/Buddhist.ics rename to src/test/resources/samples/valid/Buddhist.ics diff --git a/etc/samples/valid/Christian32Holidays.ics b/src/test/resources/samples/valid/Christian32Holidays.ics similarity index 100% rename from etc/samples/valid/Christian32Holidays.ics rename to src/test/resources/samples/valid/Christian32Holidays.ics diff --git a/etc/samples/valid/Dryway.ics b/src/test/resources/samples/valid/Dryway.ics similarity index 100% rename from etc/samples/valid/Dryway.ics rename to src/test/resources/samples/valid/Dryway.ics diff --git a/etc/samples/valid/EXDATE.ics b/src/test/resources/samples/valid/EXDATE.ics similarity index 100% rename from etc/samples/valid/EXDATE.ics rename to src/test/resources/samples/valid/EXDATE.ics diff --git a/etc/samples/valid/Earth32Seasons.ics b/src/test/resources/samples/valid/Earth32Seasons.ics similarity index 100% rename from etc/samples/valid/Earth32Seasons.ics rename to src/test/resources/samples/valid/Earth32Seasons.ics diff --git a/etc/samples/valid/EstoniaHolidays.ics b/src/test/resources/samples/valid/EstoniaHolidays.ics similarity index 100% rename from etc/samples/valid/EstoniaHolidays.ics rename to src/test/resources/samples/valid/EstoniaHolidays.ics diff --git a/etc/samples/valid/Misc.History.ics b/src/test/resources/samples/valid/Misc.History.ics similarity index 100% rename from etc/samples/valid/Misc.History.ics rename to src/test/resources/samples/valid/Misc.History.ics diff --git a/etc/samples/valid/New Years Day.ics b/src/test/resources/samples/valid/New Years Day.ics similarity index 100% rename from etc/samples/valid/New Years Day.ics rename to src/test/resources/samples/valid/New Years Day.ics diff --git a/etc/samples/valid/OZMovies.ics b/src/test/resources/samples/valid/OZMovies.ics similarity index 100% rename from etc/samples/valid/OZMovies.ics rename to src/test/resources/samples/valid/OZMovies.ics diff --git a/etc/samples/valid/Packers.ics b/src/test/resources/samples/valid/Packers.ics similarity index 100% rename from etc/samples/valid/Packers.ics rename to src/test/resources/samples/valid/Packers.ics diff --git a/etc/samples/valid/Session6.ics b/src/test/resources/samples/valid/Session6.ics similarity index 100% rename from etc/samples/valid/Session6.ics rename to src/test/resources/samples/valid/Session6.ics diff --git a/etc/samples/valid/Standup.ics b/src/test/resources/samples/valid/Standup.ics similarity index 100% rename from etc/samples/valid/Standup.ics rename to src/test/resources/samples/valid/Standup.ics diff --git a/etc/samples/valid/SwedishHolidays2003-2006.ics b/src/test/resources/samples/valid/SwedishHolidays2003-2006.ics similarity index 100% rename from etc/samples/valid/SwedishHolidays2003-2006.ics rename to src/test/resources/samples/valid/SwedishHolidays2003-2006.ics diff --git a/etc/samples/valid/THFC.ics b/src/test/resources/samples/valid/THFC.ics similarity index 100% rename from etc/samples/valid/THFC.ics rename to src/test/resources/samples/valid/THFC.ics diff --git a/etc/samples/valid/afl2004.ics b/src/test/resources/samples/valid/afl2004.ics similarity index 100% rename from etc/samples/valid/afl2004.ics rename to src/test/resources/samples/valid/afl2004.ics diff --git a/etc/samples/valid/bears.ics b/src/test/resources/samples/valid/bears.ics similarity index 100% rename from etc/samples/valid/bears.ics rename to src/test/resources/samples/valid/bears.ics diff --git a/etc/samples/valid/bhav23-1.ics b/src/test/resources/samples/valid/bhav23-1.ics similarity index 100% rename from etc/samples/valid/bhav23-1.ics rename to src/test/resources/samples/valid/bhav23-1.ics diff --git a/etc/samples/valid/blalor.ics b/src/test/resources/samples/valid/blalor.ics similarity index 100% rename from etc/samples/valid/blalor.ics rename to src/test/resources/samples/valid/blalor.ics diff --git a/etc/samples/valid/calconnect.ics b/src/test/resources/samples/valid/calconnect.ics similarity index 100% rename from etc/samples/valid/calconnect.ics rename to src/test/resources/samples/valid/calconnect.ics diff --git a/etc/samples/valid/calconnect10.ics b/src/test/resources/samples/valid/calconnect10.ics similarity index 100% rename from etc/samples/valid/calconnect10.ics rename to src/test/resources/samples/valid/calconnect10.ics diff --git a/etc/samples/valid/calconnect2.ics b/src/test/resources/samples/valid/calconnect2.ics similarity index 100% rename from etc/samples/valid/calconnect2.ics rename to src/test/resources/samples/valid/calconnect2.ics diff --git a/etc/samples/valid/calconnect3.ics b/src/test/resources/samples/valid/calconnect3.ics similarity index 100% rename from etc/samples/valid/calconnect3.ics rename to src/test/resources/samples/valid/calconnect3.ics diff --git a/etc/samples/valid/calconnect4.ics b/src/test/resources/samples/valid/calconnect4.ics similarity index 100% rename from etc/samples/valid/calconnect4.ics rename to src/test/resources/samples/valid/calconnect4.ics diff --git a/etc/samples/valid/calconnect5.ics b/src/test/resources/samples/valid/calconnect5.ics similarity index 100% rename from etc/samples/valid/calconnect5.ics rename to src/test/resources/samples/valid/calconnect5.ics diff --git a/etc/samples/valid/calconnect6.ics b/src/test/resources/samples/valid/calconnect6.ics similarity index 100% rename from etc/samples/valid/calconnect6.ics rename to src/test/resources/samples/valid/calconnect6.ics diff --git a/etc/samples/valid/calconnect7.ics b/src/test/resources/samples/valid/calconnect7.ics similarity index 100% rename from etc/samples/valid/calconnect7.ics rename to src/test/resources/samples/valid/calconnect7.ics diff --git a/etc/samples/valid/calconnect8.ics b/src/test/resources/samples/valid/calconnect8.ics similarity index 100% rename from etc/samples/valid/calconnect8.ics rename to src/test/resources/samples/valid/calconnect8.ics diff --git a/etc/samples/valid/calconnect9.ics b/src/test/resources/samples/valid/calconnect9.ics similarity index 100% rename from etc/samples/valid/calconnect9.ics rename to src/test/resources/samples/valid/calconnect9.ics diff --git a/etc/samples/valid/canada.ics b/src/test/resources/samples/valid/canada.ics similarity index 100% rename from etc/samples/valid/canada.ics rename to src/test/resources/samples/valid/canada.ics diff --git a/etc/samples/valid/categories.ics b/src/test/resources/samples/valid/categories.ics similarity index 100% rename from etc/samples/valid/categories.ics rename to src/test/resources/samples/valid/categories.ics diff --git a/etc/samples/valid/classify.ics b/src/test/resources/samples/valid/classify.ics similarity index 100% rename from etc/samples/valid/classify.ics rename to src/test/resources/samples/valid/classify.ics diff --git a/etc/samples/valid/custom_component.ics b/src/test/resources/samples/valid/custom_component.ics similarity index 100% rename from etc/samples/valid/custom_component.ics rename to src/test/resources/samples/valid/custom_component.ics diff --git a/etc/samples/valid/derryn.ics b/src/test/resources/samples/valid/derryn.ics similarity index 100% rename from etc/samples/valid/derryn.ics rename to src/test/resources/samples/valid/derryn.ics diff --git a/etc/samples/valid/evolution.ics b/src/test/resources/samples/valid/evolution.ics similarity index 100% rename from etc/samples/valid/evolution.ics rename to src/test/resources/samples/valid/evolution.ics diff --git a/etc/samples/valid/friday13-NOT.ics b/src/test/resources/samples/valid/friday13-NOT.ics similarity index 100% rename from etc/samples/valid/friday13-NOT.ics rename to src/test/resources/samples/valid/friday13-NOT.ics diff --git a/etc/samples/valid/friday13.ics b/src/test/resources/samples/valid/friday13.ics similarity index 100% rename from etc/samples/valid/friday13.ics rename to src/test/resources/samples/valid/friday13.ics diff --git a/etc/samples/valid/incoming.ics b/src/test/resources/samples/valid/incoming.ics similarity index 100% rename from etc/samples/valid/incoming.ics rename to src/test/resources/samples/valid/incoming.ics diff --git a/etc/samples/valid/japan_west.ics b/src/test/resources/samples/valid/japan_west.ics similarity index 100% rename from etc/samples/valid/japan_west.ics rename to src/test/resources/samples/valid/japan_west.ics diff --git a/etc/samples/valid/korganizer-lowercase.ics b/src/test/resources/samples/valid/korganizer-lowercase.ics similarity index 100% rename from etc/samples/valid/korganizer-lowercase.ics rename to src/test/resources/samples/valid/korganizer-lowercase.ics diff --git a/etc/samples/valid/korganizer.ics b/src/test/resources/samples/valid/korganizer.ics similarity index 100% rename from etc/samples/valid/korganizer.ics rename to src/test/resources/samples/valid/korganizer.ics diff --git a/etc/samples/valid/korganizer_sample.ics b/src/test/resources/samples/valid/korganizer_sample.ics similarity index 100% rename from etc/samples/valid/korganizer_sample.ics rename to src/test/resources/samples/valid/korganizer_sample.ics diff --git a/etc/samples/valid/lotr-updated.ics b/src/test/resources/samples/valid/lotr-updated.ics similarity index 100% rename from etc/samples/valid/lotr-updated.ics rename to src/test/resources/samples/valid/lotr-updated.ics diff --git a/etc/samples/valid/lotr.ics b/src/test/resources/samples/valid/lotr.ics similarity index 100% rename from etc/samples/valid/lotr.ics rename to src/test/resources/samples/valid/lotr.ics diff --git a/etc/samples/valid/mansour.ics b/src/test/resources/samples/valid/mansour.ics similarity index 100% rename from etc/samples/valid/mansour.ics rename to src/test/resources/samples/valid/mansour.ics diff --git a/etc/samples/valid/mathBirthdays.ics b/src/test/resources/samples/valid/mathBirthdays.ics similarity index 100% rename from etc/samples/valid/mathBirthdays.ics rename to src/test/resources/samples/valid/mathBirthdays.ics diff --git a/etc/samples/valid/miked.ics b/src/test/resources/samples/valid/miked.ics similarity index 100% rename from etc/samples/valid/miked.ics rename to src/test/resources/samples/valid/miked.ics diff --git a/etc/samples/valid/multiple_calendars.ics b/src/test/resources/samples/valid/multiple_calendars.ics similarity index 100% rename from etc/samples/valid/multiple_calendars.ics rename to src/test/resources/samples/valid/multiple_calendars.ics diff --git a/etc/samples/valid/oracle-personal-notes-test-empty.ics b/src/test/resources/samples/valid/oracle-personal-notes-test-empty.ics similarity index 100% rename from etc/samples/valid/oracle-personal-notes-test-empty.ics rename to src/test/resources/samples/valid/oracle-personal-notes-test-empty.ics diff --git a/etc/samples/valid/oracle-personal-notes-test.ics b/src/test/resources/samples/valid/oracle-personal-notes-test.ics similarity index 100% rename from etc/samples/valid/oracle-personal-notes-test.ics rename to src/test/resources/samples/valid/oracle-personal-notes-test.ics diff --git a/etc/samples/valid/php-flp.ics b/src/test/resources/samples/valid/php-flp.ics similarity index 100% rename from etc/samples/valid/php-flp.ics rename to src/test/resources/samples/valid/php-flp.ics diff --git a/etc/samples/valid/rfc5545-sec3.4.ics b/src/test/resources/samples/valid/rfc5545-sec3.4.ics similarity index 100% rename from etc/samples/valid/rfc5545-sec3.4.ics rename to src/test/resources/samples/valid/rfc5545-sec3.4.ics diff --git a/etc/samples/valid/rfc5545-sec3.6.1.ics b/src/test/resources/samples/valid/rfc5545-sec3.6.1.ics similarity index 100% rename from etc/samples/valid/rfc5545-sec3.6.1.ics rename to src/test/resources/samples/valid/rfc5545-sec3.6.1.ics diff --git a/etc/samples/valid/rfc5545-sec3.6.2.ics b/src/test/resources/samples/valid/rfc5545-sec3.6.2.ics similarity index 100% rename from etc/samples/valid/rfc5545-sec3.6.2.ics rename to src/test/resources/samples/valid/rfc5545-sec3.6.2.ics diff --git a/etc/samples/valid/rfc5545-sec3.6.3.ics b/src/test/resources/samples/valid/rfc5545-sec3.6.3.ics similarity index 100% rename from etc/samples/valid/rfc5545-sec3.6.3.ics rename to src/test/resources/samples/valid/rfc5545-sec3.6.3.ics diff --git a/etc/samples/valid/rfc5545-sec3.6.4.ics b/src/test/resources/samples/valid/rfc5545-sec3.6.4.ics similarity index 100% rename from etc/samples/valid/rfc5545-sec3.6.4.ics rename to src/test/resources/samples/valid/rfc5545-sec3.6.4.ics diff --git a/etc/samples/valid/rfc5545-sec3.6.5.ics b/src/test/resources/samples/valid/rfc5545-sec3.6.5.ics similarity index 100% rename from etc/samples/valid/rfc5545-sec3.6.5.ics rename to src/test/resources/samples/valid/rfc5545-sec3.6.5.ics diff --git a/etc/samples/valid/rfc5545-sec3.6.6.ics b/src/test/resources/samples/valid/rfc5545-sec3.6.6.ics similarity index 100% rename from etc/samples/valid/rfc5545-sec3.6.6.ics rename to src/test/resources/samples/valid/rfc5545-sec3.6.6.ics diff --git a/etc/samples/valid/rfc5545-sec4.1.ics b/src/test/resources/samples/valid/rfc5545-sec4.1.ics similarity index 100% rename from etc/samples/valid/rfc5545-sec4.1.ics rename to src/test/resources/samples/valid/rfc5545-sec4.1.ics diff --git a/etc/samples/valid/rfc5545-sec4.2.ics b/src/test/resources/samples/valid/rfc5545-sec4.2.ics similarity index 100% rename from etc/samples/valid/rfc5545-sec4.2.ics rename to src/test/resources/samples/valid/rfc5545-sec4.2.ics diff --git a/etc/samples/valid/rfc5545-sec4.3.ics b/src/test/resources/samples/valid/rfc5545-sec4.3.ics similarity index 100% rename from etc/samples/valid/rfc5545-sec4.3.ics rename to src/test/resources/samples/valid/rfc5545-sec4.3.ics diff --git a/etc/samples/valid/rfc5545-sec4.4.ics b/src/test/resources/samples/valid/rfc5545-sec4.4.ics similarity index 100% rename from etc/samples/valid/rfc5545-sec4.4.ics rename to src/test/resources/samples/valid/rfc5545-sec4.4.ics diff --git a/etc/samples/valid/rfc5545-sec4.5.ics b/src/test/resources/samples/valid/rfc5545-sec4.5.ics similarity index 100% rename from etc/samples/valid/rfc5545-sec4.5.ics rename to src/test/resources/samples/valid/rfc5545-sec4.5.ics diff --git a/etc/samples/valid/sunbird_sample.ics b/src/test/resources/samples/valid/sunbird_sample.ics similarity index 100% rename from etc/samples/valid/sunbird_sample.ics rename to src/test/resources/samples/valid/sunbird_sample.ics diff --git a/etc/samples/valid/talios.ics b/src/test/resources/samples/valid/talios.ics similarity index 100% rename from etc/samples/valid/talios.ics rename to src/test/resources/samples/valid/talios.ics diff --git a/etc/samples/valid/tmeher.ics b/src/test/resources/samples/valid/tmeher.ics similarity index 100% rename from etc/samples/valid/tmeher.ics rename to src/test/resources/samples/valid/tmeher.ics