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