[CalendarServer-changes] [4556] CalendarServer/trunk/doc/RFC
source_changes at macosforge.org
source_changes at macosforge.org
Sun Sep 27 09:55:48 PDT 2009
Revision: 4556
http://trac.macosforge.org/projects/calendarserver/changeset/4556
Author: wsanchez at apple.com
Date: 2009-09-27 09:55:44 -0700 (Sun, 27 Sep 2009)
Log Message:
-----------
RFC 2445 has been superseced by RFC 5545.
Added Paths:
-----------
CalendarServer/trunk/doc/RFC/rfc5545-iCalendar.txt
Removed Paths:
-------------
CalendarServer/trunk/doc/RFC/rfc2445-iCalendar.txt
Deleted: CalendarServer/trunk/doc/RFC/rfc2445-iCalendar.txt
===================================================================
--- CalendarServer/trunk/doc/RFC/rfc2445-iCalendar.txt 2009-09-24 21:01:05 UTC (rev 4555)
+++ CalendarServer/trunk/doc/RFC/rfc2445-iCalendar.txt 2009-09-27 16:55:44 UTC (rev 4556)
@@ -1,8291 +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 at 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 at Lotus.com (Internet Mail)
-
- Derik Stenerson
- One Microsoft Way
- Redmond, WA 98052-6399
- 425-936-5522 (Telephone)
- 425-936-7329 (Facsimile)
- deriks at 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 at Lotus.com (Internet Mail)
-
- Derik Stenerson
- One Microsoft Way
- Redmond, WA 98052-6399
- 425-936-5522 (Telephone)
- 425-936-7329 (Facsimile)
- deriks at 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 at 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:<part3.msg.970415T083000 at host.com>":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:<part3.msg.970415T083000 at host.com>
-
- <html><body>
- <p><b>Project XYZ Review Meeting</b> will include the following
- agenda items:<ol><li>Market
- Overview</li><li>Finances</li><li>Project Management</li></ol></p>
- </body></html>
-
-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 at 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 at 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 at host.com":MAILTO:
- jdoe at 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 at host.com","MAILTO:jqpublic@
- host.com":MAILTO:jsmith at 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 at 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 = <Text identifying a language, as defined in [RFC 1766]>
-
- 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 at imc.org":MAILTO:jsmith at host.com
-
- ATTENDEE;MEMBER="MAILTO:projectA at host.com","MAILTO:projectB at host.
- com":MAILTO:janedoe at 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 at 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 at 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 at 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 at 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 at host.com":MAILTO:jsmith at 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 at 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 = <As defined by any IETF RFC>
-
- 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 at 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 at 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 at 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 at 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 at 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 at host1.com
- ATTENDEE:MAILTO:john_public at 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 at host1.com
- ATTENDEE:MAILTO:john_public at 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 at 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 at 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 = <A IANA registered iCalendar version identifier>
- ;Minimum iCalendar version needed to parse the iCalendar object
-
- maxver = <A IANA registered iCalendar version identifier>
- ;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 at 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 at host1.com
- ATTENDEE;MEMBER="MAILTO:DEV-GROUP at host2.com":
- MAILTO:joecool at host2.com
- ATTENDEE;DELEGATED-FROM="MAILTO:immud at host3.com":
- MAILTO:ildoit at 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 at host1.com
- ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;CN=Henry Cabot
- :MAILTO:hcabot at host2.com
- ATTENDEE;ROLE=REQ-PARTICIPANT;DELEGATED-FROM="MAILTO:bob at host.com"
- ;PARTSTAT=ACCEPTED;CN=Jane Doe:MAILTO:jdoe at 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 at host.com
- ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;DELEGATED-FROM=
- "MAILTO:iamboss at host2.com";CN=Henry Cabot:MAILTO:hcabot@
- host2.com
- ATTENDEE;ROLE=NON-PARTICIPANT;PARTSTAT=DELEGATED;DELEGATED-TO=
- "MAILTO:hcabot at host2.com";CN=The Big Cheese:MAILTO:iamboss
- @host2.com
- ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;CN=Jane Doe
- :MAILTO:jdoe at 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 at host1.com;CN=John Smith:MAILTO:
- jsmith at 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=<part3.msg970930T083000SILVER at host.com>":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 at 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 at 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 at host.com":
- MAILTO:jsmith at 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:<jsmith.part7.19960817T083000.xyzMail at host3.com>
-
- RELATED-TO:<19960401-080045-4000F192713-0052 at 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 at 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 at 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 at host.com ORGANIZER:MAILTO:jsmith at 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 at host.com
- ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;CUTYPE=GROUP:
- MAILTO:employee-A at 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 at host1.com
- FROM:jdoe at host1.com
- MIME-VERSION:1.0
- MESSAGE-ID:<id3 at host1.com>
- 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 at host1.com
- ORGANIZER:MAILTO:jdoe at host1.com
- ATTENDEE;RSVP=TRUE:MAILTO:jsmith at 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 at host1.com
- ORGANIZER:MAILTO:unclesam at us.gov
- ATTENDEE;PARTSTAT=ACCEPTED:MAILTO:jqpublic at 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 at host1.com
- ORGANIZER:MAILTO:jsmith at 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 at 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 at 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 at 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 at Lotus.com
- EMAIL;TYPE=INTERNET:fdawson at 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 at 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 at 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 at 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]
-
Added: CalendarServer/trunk/doc/RFC/rfc5545-iCalendar.txt
===================================================================
--- CalendarServer/trunk/doc/RFC/rfc5545-iCalendar.txt (rev 0)
+++ CalendarServer/trunk/doc/RFC/rfc5545-iCalendar.txt 2009-09-27 16:55:44 UTC (rev 4556)
@@ -0,0 +1,9411 @@
+
+
+
+
+
+
+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 at 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 at 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 at 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:<part3.msg.970415T083000 at example.com>
+
+ <html>
+ <head>
+ <title></title>
+ </head>
+ <body>
+ <p>
+ <b>Project XYZ Review Meeting</b> will include
+ the following agenda items:
+ <ol>
+ <li>Market Overview</li>
+ <li>Finances</li>
+ <li>Project Management</li>
+ </ol>
+ </p>
+ </body>
+ </html>
+
+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 at 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 at 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 at example.com":mailto:
+ jdoe at 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 at example.com","mailto:jqpublic
+ @example.com":mailto:jsmith at 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 at 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 at example.org":mailto:
+ jsmith at example.com
+
+ ATTENDEE;MEMBER="mailto:projectA at example.com","mailto:pr
+ ojectB at example.com":mailto:janedoe at 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 at 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 at 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 at 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 at example.com":mailto:
+ jsmith at 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 at 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 = <As defined in Section 3 of [RFC3986]>
+
+ 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at example.com
+ ORGANIZER:mailto:jane_doe at example.com
+ ATTENDEE:mailto:john_public at 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 at example.com
+ ORGANIZER:mailto:jane_doe at example.com
+ ATTENDEE:mailto:john_public at 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 at example.com
+ DTSTAMP:19970901T120000Z
+ ORGANIZER:jsmith at 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 at 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 = <A IANA-registered iCalendar version identifier>
+ ;Minimum iCalendar version needed to parse the iCalendar object.
+
+ maxver = <A IANA-registered iCalendar version identifier>
+ ;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 at 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 at example.com":
+ mailto:joecool at example.com
+ ATTENDEE;DELEGATED-FROM="mailto:immud at example.com":
+ mailto:ildoit at 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 at 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 at example.com";CN=Henry Cabot:mailto:hcabot@
+ example.com
+ ATTENDEE;ROLE=NON-PARTICIPANT;PARTSTAT=DELEGATED;DELEGATED-TO=
+ "mailto:hcabot at example.com";CN=The Big Cheese:mailto:iamboss
+ @example.com
+ ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;CN=Jane Doe
+ :mailto:jdoe at 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 at example.com;CN=John Smith:
+ mailto:jsmith at 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 at 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 at 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 at 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 at example.com":
+ mailto:jsmith at 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 at example.com
+
+ RELATED-TO:19960401-080045-4000F192713-0052 at 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 at 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 at 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 at example.com
+ ORGANIZER:mailto:jsmith at 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 at example.com
+ ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;CUTYPE=GROUP:
+ mailto:employee-A at 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 at example.com
+ FROM:jdoe at example.com
+ MIME-VERSION:1.0
+ MESSAGE-ID:<id3 at example.com>
+ 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 at example.com
+ ORGANIZER:mailto:jdoe at example.com
+ ATTENDEE;RSVP=TRUE:mailto:jsmith at 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 at example.com
+ ORGANIZER:mailto:unclesam at example.com
+ ATTENDEE;PARTSTAT=ACCEPTED:mailto:jqpublic at 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 at example.com
+ ORGANIZER:mailto:jsmith at 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 at 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 at 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 at 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 at 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 at ietf.org and iana at 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,
+ <http://www.twinsun.com/tz/tz-link.htm>.
+
+ [VCAL] Internet Mail Consortium, "vCalendar: The
+ Electronic Calendaring and Scheduling Exchange
+ Format", September 1996,
+ <http://www.imc.org/pdi/vcal-10.txt>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 at oracle.com
+ URI: http://www.oracle.com/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Desruisseaux Standards Track [Page 168]
+
Property changes on: CalendarServer/trunk/doc/RFC/rfc5545-iCalendar.txt
___________________________________________________________________
Added: svn:mime-type
+ text/plain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/calendarserver-changes/attachments/20090927/b8f347f5/attachment-0001.html>
More information about the calendarserver-changes
mailing list