diff options
Diffstat (limited to 'vendor/sabre/dav/docs/rfc5545.txt')
| -rw-r--r-- | vendor/sabre/dav/docs/rfc5545.txt | 9411 |
1 files changed, 9411 insertions, 0 deletions
diff --git a/vendor/sabre/dav/docs/rfc5545.txt b/vendor/sabre/dav/docs/rfc5545.txt new file mode 100644 index 000000000..47ea31d60 --- /dev/null +++ b/vendor/sabre/dav/docs/rfc5545.txt @@ -0,0 +1,9411 @@ + + + + + + +Network Working Group B. Desruisseaux, Ed. +Request for Comments: 5545 Oracle +Obsoletes: 2445 September 2009 +Category: Standards Track + + + Internet Calendaring and Scheduling Core Object Specification + (iCalendar) + +Abstract + +This document defines the iCalendar data format for representing and +exchanging calendaring and scheduling information such as events, +to-dos, journal entries, and free/busy information, independent of any +particular calendar service or protocol. + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright and License Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + + + +Desruisseaux Standards Track [Page 1] + +RFC 5545 iCalendar September 2009 + + + it for publication as an RFC or to translate it into languages other + than English. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2. Basic Grammar and Conventions . . . . . . . . . . . . . . . . 6 + 2.1. Formatting Conventions . . . . . . . . . . . . . . . . . 6 + 2.2. Related Memos . . . . . . . . . . . . . . . . . . . . . . 7 + 3. iCalendar Object Specification . . . . . . . . . . . . . . . 8 + 3.1. Content Lines . . . . . . . . . . . . . . . . . . . . . . 8 + 3.1.1. List and Field Separators . . . . . . . . . . . . . . 11 + 3.1.2. Multiple Values . . . . . . . . . . . . . . . . . . . 11 + 3.1.3. Binary Content . . . . . . . . . . . . . . . . . . . 11 + 3.1.4. Character Set . . . . . . . . . . . . . . . . . . . . 12 + 3.2. Property Parameters . . . . . . . . . . . . . . . . . . . 12 + 3.2.1. Alternate Text Representation . . . . . . . . . . . . 13 + 3.2.2. Common Name . . . . . . . . . . . . . . . . . . . . . 15 + 3.2.3. Calendar User Type . . . . . . . . . . . . . . . . . 15 + 3.2.4. Delegators . . . . . . . . . . . . . . . . . . . . . 16 + 3.2.5. Delegatees . . . . . . . . . . . . . . . . . . . . . 16 + 3.2.6. Directory Entry Reference . . . . . . . . . . . . . . 17 + 3.2.7. Inline Encoding . . . . . . . . . . . . . . . . . . . 17 + 3.2.8. Format Type . . . . . . . . . . . . . . . . . . . . . 18 + 3.2.9. Free/Busy Time Type . . . . . . . . . . . . . . . . . 19 + 3.2.10. Language . . . . . . . . . . . . . . . . . . . . . . 20 + 3.2.11. Group or List Membership . . . . . . . . . . . . . . 20 + 3.2.12. Participation Status . . . . . . . . . . . . . . . . 21 + 3.2.13. Recurrence Identifier Range . . . . . . . . . . . . . 22 + 3.2.14. Alarm Trigger Relationship . . . . . . . . . . . . . 23 + 3.2.15. Relationship Type . . . . . . . . . . . . . . . . . . 24 + 3.2.16. Participation Role . . . . . . . . . . . . . . . . . 25 + 3.2.17. RSVP Expectation . . . . . . . . . . . . . . . . . . 25 + 3.2.18. Sent By . . . . . . . . . . . . . . . . . . . . . . . 26 + 3.2.19. Time Zone Identifier . . . . . . . . . . . . . . . . 26 + 3.2.20. Value Data Types . . . . . . . . . . . . . . . . . . 28 + 3.3. Property Value Data Types . . . . . . . . . . . . . . . . 29 + 3.3.1. Binary . . . . . . . . . . . . . . . . . . . . . . . 29 + 3.3.2. Boolean . . . . . . . . . . . . . . . . . . . . . . . 30 + 3.3.3. Calendar User Address . . . . . . . . . . . . . . . . 30 + 3.3.4. Date . . . . . . . . . . . . . . . . . . . . . . . . 31 + 3.3.5. Date-Time . . . . . . . . . . . . . . . . . . . . . . 31 + 3.3.6. Duration . . . . . . . . . . . . . . . . . . . . . . 34 + 3.3.7. Float . . . . . . . . . . . . . . . . . . . . . . . . 35 + 3.3.8. Integer . . . . . . . . . . . . . . . . . . . . . . . 35 + 3.3.9. Period of Time . . . . . . . . . . . . . . . . . . . 36 + 3.3.10. Recurrence Rule . . . . . . . . . . . . . . . . . . . 37 + 3.3.11. Text . . . . . . . . . . . . . . . . . . . . . . . . 45 + + + +Desruisseaux Standards Track [Page 2] + +RFC 5545 iCalendar September 2009 + + + 3.3.12. Time . . . . . . . . . . . . . . . . . . . . . . . . 46 + 3.3.13. URI . . . . . . . . . . . . . . . . . . . . . . . . . 48 + 3.3.14. UTC Offset . . . . . . . . . . . . . . . . . . . . . 49 + 3.4. iCalendar Object . . . . . . . . . . . . . . . . . . . . 49 + 3.5. Property . . . . . . . . . . . . . . . . . . . . . . . . 50 + 3.6. Calendar Components . . . . . . . . . . . . . . . . . . . 50 + 3.6.1. Event Component . . . . . . . . . . . . . . . . . . . 52 + 3.6.2. To-Do Component . . . . . . . . . . . . . . . . . . . 56 + 3.6.3. Journal Component . . . . . . . . . . . . . . . . . . 58 + 3.6.4. Free/Busy Component . . . . . . . . . . . . . . . . . 60 + 3.6.5. Time Zone Component . . . . . . . . . . . . . . . . . 63 + 3.6.6. Alarm Component . . . . . . . . . . . . . . . . . . . 72 + 3.7. Calendar Properties . . . . . . . . . . . . . . . . . . . 77 + 3.7.1. Calendar Scale . . . . . . . . . . . . . . . . . . . 77 + 3.7.2. Method . . . . . . . . . . . . . . . . . . . . . . . 78 + 3.7.3. Product Identifier . . . . . . . . . . . . . . . . . 79 + 3.7.4. Version . . . . . . . . . . . . . . . . . . . . . . . 80 + 3.8. Component Properties . . . . . . . . . . . . . . . . . . 81 + 3.8.1. Descriptive Component Properties . . . . . . . . . . 81 + 3.8.1.1. Attachment . . . . . . . . . . . . . . . . . . . 81 + 3.8.1.2. Categories . . . . . . . . . . . . . . . . . . . 82 + 3.8.1.3. Classification . . . . . . . . . . . . . . . . . 83 + 3.8.1.4. Comment . . . . . . . . . . . . . . . . . . . . . 84 + 3.8.1.5. Description . . . . . . . . . . . . . . . . . . . 85 + 3.8.1.6. Geographic Position . . . . . . . . . . . . . . . 87 + 3.8.1.7. Location . . . . . . . . . . . . . . . . . . . . 88 + 3.8.1.8. Percent Complete . . . . . . . . . . . . . . . . 89 + 3.8.1.9. Priority . . . . . . . . . . . . . . . . . . . . 90 + 3.8.1.10. Resources . . . . . . . . . . . . . . . . . . . . 92 + 3.8.1.11. Status . . . . . . . . . . . . . . . . . . . . . 93 + 3.8.1.12. Summary . . . . . . . . . . . . . . . . . . . . . 94 + 3.8.2. Date and Time Component Properties . . . . . . . . . 95 + 3.8.2.1. Date-Time Completed . . . . . . . . . . . . . . . 95 + 3.8.2.2. Date-Time End . . . . . . . . . . . . . . . . . . 96 + 3.8.2.3. Date-Time Due . . . . . . . . . . . . . . . . . . 97 + 3.8.2.4. Date-Time Start . . . . . . . . . . . . . . . . . 99 + 3.8.2.5. Duration . . . . . . . . . . . . . . . . . . . . 100 + 3.8.2.6. Free/Busy Time . . . . . . . . . . . . . . . . . 101 + 3.8.2.7. Time Transparency . . . . . . . . . . . . . . . . 102 + 3.8.3. Time Zone Component Properties . . . . . . . . . . . 103 + 3.8.3.1. Time Zone Identifier . . . . . . . . . . . . . . 103 + 3.8.3.2. Time Zone Name . . . . . . . . . . . . . . . . . 105 + 3.8.3.3. Time Zone Offset From . . . . . . . . . . . . . . 106 + 3.8.3.4. Time Zone Offset To . . . . . . . . . . . . . . . 106 + 3.8.3.5. Time Zone URL . . . . . . . . . . . . . . . . . . 107 + 3.8.4. Relationship Component Properties . . . . . . . . . . 108 + 3.8.4.1. Attendee . . . . . . . . . . . . . . . . . . . . 108 + 3.8.4.2. Contact . . . . . . . . . . . . . . . . . . . . . 111 + + + +Desruisseaux Standards Track [Page 3] + +RFC 5545 iCalendar September 2009 + + + 3.8.4.3. Organizer . . . . . . . . . . . . . . . . . . . . 113 + 3.8.4.4. Recurrence ID . . . . . . . . . . . . . . . . . . 114 + 3.8.4.5. Related To . . . . . . . . . . . . . . . . . . . 117 + 3.8.4.6. Uniform Resource Locator . . . . . . . . . . . . 118 + 3.8.4.7. Unique Identifier . . . . . . . . . . . . . . . . 119 + 3.8.5. Recurrence Component Properties . . . . . . . . . . . 120 + 3.8.5.1. Exception Date-Times . . . . . . . . . . . . . . 120 + 3.8.5.2. Recurrence Date-Times . . . . . . . . . . . . . . 122 + 3.8.5.3. Recurrence Rule . . . . . . . . . . . . . . . . . 124 + 3.8.6. Alarm Component Properties . . . . . . . . . . . . . 134 + 3.8.6.1. Action . . . . . . . . . . . . . . . . . . . . . 134 + 3.8.6.2. Repeat Count . . . . . . . . . . . . . . . . . . 135 + 3.8.6.3. Trigger . . . . . . . . . . . . . . . . . . . . . 135 + 3.8.7. Change Management Component Properties . . . . . . . 138 + 3.8.7.1. Date-Time Created . . . . . . . . . . . . . . . . 138 + 3.8.7.2. Date-Time Stamp . . . . . . . . . . . . . . . . . 139 + 3.8.7.3. Last Modified . . . . . . . . . . . . . . . . . . 140 + 3.8.7.4. Sequence Number . . . . . . . . . . . . . . . . . 141 + 3.8.8. Miscellaneous Component Properties . . . . . . . . . 142 + 3.8.8.1. IANA Properties . . . . . . . . . . . . . . . . . 142 + 3.8.8.2. Non-Standard Properties . . . . . . . . . . . . . 142 + 3.8.8.3. Request Status . . . . . . . . . . . . . . . . . 144 + 4. iCalendar Object Examples . . . . . . . . . . . . . . . . . . 146 + 5. Recommended Practices . . . . . . . . . . . . . . . . . . . . 150 + 6. Internationalization Considerations . . . . . . . . . . . . . 151 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 151 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 151 + 8.1. iCalendar Media Type Registration . . . . . . . . . . . . 151 + 8.2. New iCalendar Elements Registration . . . . . . . . . . . 155 + 8.2.1. iCalendar Elements Registration Procedure . . . . . . 155 + 8.2.2. Registration Template for Components . . . . . . . . 155 + 8.2.3. Registration Template for Properties . . . . . . . . 156 + 8.2.4. Registration Template for Parameters . . . . . . . . 156 + 8.2.5. Registration Template for Value Data Types . . . . . 157 + 8.2.6. Registration Template for Values . . . . . . . . . . 157 + 8.3. Initial iCalendar Elements Registries . . . . . . . . . . 158 + 8.3.1. Components Registry . . . . . . . . . . . . . . . . . 158 + 8.3.2. Properties Registry . . . . . . . . . . . . . . . . . 158 + 8.3.3. Parameters Registry . . . . . . . . . . . . . . . . . 161 + 8.3.4. Value Data Types Registry . . . . . . . . . . . . . . 162 + 8.3.5. Calendar User Types Registry . . . . . . . . . . . . 162 + 8.3.6. Free/Busy Time Types Registry . . . . . . . . . . . . 163 + 8.3.7. Participation Statuses Registry . . . . . . . . . . . 163 + 8.3.8. Relationship Types Registry . . . . . . . . . . . . . 164 + 8.3.9. Participation Roles Registry . . . . . . . . . . . . 164 + 8.3.10. Actions Registry . . . . . . . . . . . . . . . . . . 165 + 8.3.11. Classifications Registry . . . . . . . . . . . . . . 165 + 8.3.12. Methods Registry . . . . . . . . . . . . . . . . . . 165 + + + +Desruisseaux Standards Track [Page 4] + +RFC 5545 iCalendar September 2009 + + + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 165 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 166 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 166 + 10.2. Informative References . . . . . . . . . . . . . . . . . 167 + Appendix A. Differences from RFC 2445 . . . . . . . . . . . . . 169 + A.1. New Restrictions . . . . . . . . . . . . . . . . . . . . 169 + A.2. Restrictions Removed . . . . . . . . . . . . . . . . . . 169 + A.3. Deprecated Features . . . . . . . . . . . . . . . . . . . 169 + +1. Introduction + + The use of calendaring and scheduling has grown considerably in the + last decade. Enterprise and inter-enterprise business has become + dependent on rapid scheduling of events and actions using this + information technology. This memo is intended to progress the level + of interoperability possible between dissimilar calendaring and + scheduling applications. This memo defines a MIME content type for + exchanging electronic calendaring and scheduling information. The + Internet Calendaring and Scheduling Core Object Specification, or + iCalendar, allows for the capture and exchange of information + normally stored within a calendaring and scheduling application; such + as a Personal Information Manager (PIM) or a Group-Scheduling + product. + + The iCalendar format is suitable as an exchange format between + applications or systems. The format is defined in terms of a MIME + content type. This will enable the object to be exchanged using + several transports, including but not limited to SMTP, HTTP, a file + system, desktop interactive protocols such as the use of a memory- + based clipboard or drag/drop interactions, point-to-point + asynchronous communication, wired-network transport, or some form of + unwired transport such as infrared. + + The memo also provides for the definition of iCalendar object methods + that will map this content type to a set of messages for supporting + calendaring and scheduling operations such as requesting, replying + to, modifying, and canceling meetings or appointments, to-dos, and + journal entries. The iCalendar object methods can be used to define + other calendaring and scheduling operations such as requesting for + and replying with free/busy time data. Such a scheduling protocol is + defined in the iCalendar Transport-independent Interoperability + Protocol (iTIP) defined in [2446bis]. + + The memo also includes a formal grammar for the content type based on + the Internet ABNF defined in [RFC5234]. This ABNF is required for + the implementation of parsers and to serve as the definitive + reference when ambiguities or questions arise in interpreting the + descriptive prose definition of the memo. Additional restrictions + + + +Desruisseaux Standards Track [Page 5] + +RFC 5545 iCalendar September 2009 + + + that could not easily be expressed with the ABNF syntax are specified + as comments in the ABNF. Comments with normative statements should + be treated as such. + +2. Basic Grammar and Conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + This memo makes use of both a descriptive prose and a more formal + notation for defining the calendaring and scheduling format. + + The notation used in this memo is the ABNF notation of [RFC5234]. + Readers intending on implementing the format defined in this memo + should be familiar with this notation in order to properly interpret + the specifications of this memo. + + All numeric values used in this memo are given in decimal notation. + + All names of properties, property parameters, enumerated property + values, and property parameter values are case-insensitive. However, + all other property values are case-sensitive, unless otherwise + stated. + + Note: All indented editorial notes, such as this one, are intended + to provide the reader with additional information. The + information is not essential to the building of an implementation + conformant with this memo. The information is provided to + highlight a particular feature or characteristic of the memo. + + The format for the iCalendar object is based on the syntax of the + text/directory media type [RFC2425]. While the iCalendar object is + not a profile of the text/directory media type [RFC2425], it does + reuse a number of the elements from the [RFC2425] specification. + +2.1. Formatting Conventions + + The elements defined in this memo are defined in prose. Many of the + terms used to describe these have common usage that is different than + the standards usage of this memo. In order to reference, within this + memo, elements of the calendaring and scheduling model, core object + (this memo), or interoperability protocol [2446bis] some formatting + conventions have been used. Calendaring and scheduling roles are + referred to in quoted-strings of text with the first character of + each word in uppercase. For example, "Organizer" refers to a role of + a "Calendar User" within the scheduling protocol defined by + [2446bis]. Calendar components defined by this memo are referred to + + + +Desruisseaux Standards Track [Page 6] + +RFC 5545 iCalendar September 2009 + + + with capitalized, quoted-strings of text. All calendar components + start with the letter "V". For example, "VEVENT" refers to the event + calendar component, "VTODO" refers to the to-do calendar component, + and "VJOURNAL" refers to the daily journal calendar component. + Scheduling methods defined by iTIP [2446bis] are referred to with + capitalized, quoted-strings of text. For example, "REQUEST" refers + to the method for requesting a scheduling calendar component be + created or modified, and "REPLY" refers to the method a recipient of + a request uses to update their status with the "Organizer" of the + calendar component. + + The properties defined by this memo are referred to with capitalized, + quoted-strings of text, followed by the word "property". For + example, "ATTENDEE" property refers to the iCalendar property used to + convey the calendar address of a calendar user. Property parameters + defined by this memo are referred to with lowercase, quoted-strings + of text, followed by the word "parameter". For example, "value" + parameter refers to the iCalendar property parameter used to override + the default value type for a property value. Enumerated values + defined by this memo are referred to with capitalized text, either + alone or followed by the word "value". For example, the "MINUTELY" + value can be used with the "FREQ" component of the "RECUR" value type + to specify repeating components based on an interval of one minute or + more. + + The following table lists the different characters from the + [US-ASCII] character set that is referenced in this document. For + each character, the table specifies the character name used + throughout this document, along with its US-ASCII decimal codepoint. + + + + + + + + + + + + + + + + + + + + + + +Desruisseaux Standards Track [Page 7] + +RFC 5545 iCalendar September 2009 + + + +------------------------+-------------------+ + | Character name | Decimal codepoint | + +------------------------+-------------------+ + | HTAB | 9 | + | LF | 10 | + | CR | 13 | + | DQUOTE | 22 | + | SPACE | 32 | + | PLUS SIGN | 43 | + | COMMA | 44 | + | HYPHEN-MINUS | 45 | + | PERIOD | 46 | + | SOLIDUS | 47 | + | COLON | 58 | + | SEMICOLON | 59 | + | LATIN CAPITAL LETTER N | 78 | + | LATIN CAPITAL LETTER T | 84 | + | LATIN CAPITAL LETTER X | 88 | + | LATIN CAPITAL LETTER Z | 90 | + | BACKSLASH | 92 | + | LATIN SMALL LETTER N | 110 | + +------------------------+-------------------+ + +2.2. Related Memos + + Implementers will need to be familiar with several other memos that, + along with this memo, form a framework for Internet calendaring and + scheduling standards. This memo specifies a core specification of + objects, value types, properties, and property parameters. + + o iTIP [2446bis] specifies an interoperability protocol for + scheduling between different implementations; + + o iCalendar Message-Based Interoperability Protocol (iMIP) [2447bis] + specifies an Internet email binding for [2446bis]. + + This memo does not attempt to repeat the specification of concepts or + definitions from these other memos. Where possible, references are + made to the memo that provides for the specification of these + concepts or definitions. + +3. iCalendar Object Specification + + The following sections define the details of a Calendaring and + Scheduling Core Object Specification. The Calendaring and Scheduling + Core Object is a collection of calendaring and scheduling + information. Typically, this information will consist of an + iCalendar stream with one or more iCalendar objects. The body of the + + + +Desruisseaux Standards Track [Page 8] + +RFC 5545 iCalendar September 2009 + + + iCalendar object consists of a sequence of calendar properties and + one or more calendar components. + + Section 3.1 defines the content line format; Section 3.2 defines the + property parameter format; Section 3.3 defines the data types for + property values; Section 3.4 defines the iCalendar object format; + Section 3.5 defines the iCalendar property format; Section 3.6 + defines the calendar component format; Section 3.7 defines calendar + properties; and Section 3.8 defines calendar component properties. + + This information is intended to be an integral part of the MIME + content type registration. In addition, this information can be used + independent of such content registration. In particular, this memo + has direct applicability for use as a calendaring and scheduling + exchange format in file-, memory-, or network-based transport + mechanisms. + +3.1. Content Lines + + The iCalendar object is organized into individual lines of text, + called content lines. Content lines are delimited by a line break, + which is a CRLF sequence (CR character followed by LF character). + + Lines of text SHOULD NOT be longer than 75 octets, excluding the line + break. Long content lines SHOULD be split into a multiple line + representations using a line "folding" technique. That is, a long + line can be split between any two characters by inserting a CRLF + immediately followed by a single linear white-space character (i.e., + SPACE or HTAB). Any sequence of CRLF followed immediately by a + single linear white-space character is ignored (i.e., removed) when + processing the content type. + + For example, the line: + + DESCRIPTION:This is a long description that exists on a long line. + + Can be represented as: + + DESCRIPTION:This is a lo + ng description + that exists on a long line. + + The process of moving from this folded multiple-line representation + to its single-line representation is called "unfolding". Unfolding + is accomplished by removing the CRLF and the linear white-space + character that immediately follows. + + + + + +Desruisseaux Standards Track [Page 9] + +RFC 5545 iCalendar September 2009 + + + When parsing a content line, folded lines MUST first be unfolded + according to the unfolding procedure described above. + + Note: It is possible for very simple implementations to generate + improperly folded lines in the middle of a UTF-8 multi-octet + sequence. For this reason, implementations need to unfold lines + in such a way to properly restore the original sequence. + + The content information associated with an iCalendar object is + formatted using a syntax similar to that defined by [RFC2425]. That + is, the content information consists of CRLF-separated content lines. + + The following notation defines the lines of content in an iCalendar + object: + + contentline = name *(";" param ) ":" value CRLF + ; This ABNF is just a general definition for an initial parsing + ; of the content line into its property name, parameter list, + ; and value string + + ; When parsing a content line, folded lines MUST first + ; be unfolded according to the unfolding procedure + ; described above. When generating a content line, lines + ; longer than 75 octets SHOULD be folded according to + ; the folding procedure described above. + + name = iana-token / x-name + + iana-token = 1*(ALPHA / DIGIT / "-") + ; iCalendar identifier registered with IANA + + x-name = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-") + ; Reserved for experimental use. + + vendorid = 3*(ALPHA / DIGIT) + ; Vendor identification + + param = param-name "=" param-value *("," param-value) + ; Each property defines the specific ABNF for the parameters + ; allowed on the property. Refer to specific properties for + ; precise parameter ABNF. + + param-name = iana-token / x-name + + param-value = paramtext / quoted-string + + paramtext = *SAFE-CHAR + + + + +Desruisseaux Standards Track [Page 10] + +RFC 5545 iCalendar September 2009 + + + value = *VALUE-CHAR + + quoted-string = DQUOTE *QSAFE-CHAR DQUOTE + + QSAFE-CHAR = WSP / %x21 / %x23-7E / NON-US-ASCII + ; Any character except CONTROL and DQUOTE + + SAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E + / NON-US-ASCII + ; Any character except CONTROL, DQUOTE, ";", ":", "," + + VALUE-CHAR = WSP / %x21-7E / NON-US-ASCII + ; Any textual character + + NON-US-ASCII = UTF8-2 / UTF8-3 / UTF8-4 + ; UTF8-2, UTF8-3, and UTF8-4 are defined in [RFC3629] + + CONTROL = %x00-08 / %x0A-1F / %x7F + ; All the controls except HTAB + + The property value component of a content line has a format that is + property specific. Refer to the section describing each property for + a definition of this format. + + All names of properties, property parameters, enumerated property + values and property parameter values are case-insensitive. However, + all other property values are case-sensitive, unless otherwise + stated. + +3.1.1. List and Field Separators + + Some properties and parameters allow a list of values. Values in a + list of values MUST be separated by a COMMA character. There is no + significance to the order of values in a list. For those parameter + values (such as those that specify URI values) that are specified in + quoted-strings, the individual quoted-strings are separated by a + COMMA character. + + Some property values are defined in terms of multiple parts. These + structured property values MUST have their value parts separated by a + SEMICOLON character. + + Some properties allow a list of parameters. Each property parameter + in a list of property parameters MUST be separated by a SEMICOLON + character. + + + + + + +Desruisseaux Standards Track [Page 11] + +RFC 5545 iCalendar September 2009 + + + Property parameters with values containing a COLON character, a + SEMICOLON character or a COMMA character MUST be placed in quoted + text. + + For example, in the following properties, a SEMICOLON is used to + separate property parameters from each other and a COMMA character is + used to separate property values in a value list. + + ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT:mailto: + jsmith@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] + |