idnits 2.17.1 draft-ietf-calsify-rfc2445bis-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 7932. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 7943. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 7950. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 7956. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document obsoletes RFC2445, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 6, 2008) is 5924 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2368 (Obsoleted by RFC 6068) ** Obsolete normative reference: RFC 4646 (Obsoleted by RFC 5646) == Outdated reference: A later version (-10) exists of draft-ietf-calsify-2446bis-04 == Outdated reference: A later version (-11) exists of draft-ietf-calsify-rfc2447bis-03 -- Obsolete informational reference (is this intentional?): RFC 2425 (Obsoleted by RFC 6350) -- Obsolete informational reference (is this intentional?): RFC 2426 (Obsoleted by RFC 6350) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Desruisseaux, Ed. 3 Internet-Draft Oracle 4 Obsoletes: 2445 (if approved) February 6, 2008 5 Intended status: Standards Track 6 Expires: August 9, 2008 8 Internet Calendaring and Scheduling Core Object Specification 9 (iCalendar) 10 draft-ietf-calsify-rfc2445bis-08 12 Status of This Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 9, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 This document defines the iCalendar data format for representing and 44 exchanging calendaring and scheduling information such as events, to- 45 dos, journal entries and free/busy information, independent of any 46 particular calendar service or protocol. 48 Editorial Note (To be removed by RFC Editor prior to publication) 50 This document is a product of the Calendaring and Scheduling 51 Standards Simplification (Calsify) working group of the Internet 52 Engineering Task Force. Comments on this draft are welcomed, and 53 should be addressed to the ietf-calsify@osafoundation.org [1] mailing 54 list. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 59 2. Basic Grammar and Conventions . . . . . . . . . . . . . . . . 7 60 2.1. Formatting Conventions . . . . . . . . . . . . . . . . . 7 61 2.2. Related Memos . . . . . . . . . . . . . . . . . . . . . . 8 62 3. iCalendar Object Specification . . . . . . . . . . . . . . . 9 63 3.1. Content Lines . . . . . . . . . . . . . . . . . . . . . . 9 64 3.1.1. List and Field Separators . . . . . . . . . . . . . . 11 65 3.1.2. Multiple Values . . . . . . . . . . . . . . . . . . . 12 66 3.1.3. Binary Content . . . . . . . . . . . . . . . . . . . 12 67 3.1.4. Character Set . . . . . . . . . . . . . . . . . . . . 13 68 3.2. Property Parameters . . . . . . . . . . . . . . . . . . . 13 69 3.2.1. Alternate Text Representation . . . . . . . . . . . . 14 70 3.2.2. Common Name . . . . . . . . . . . . . . . . . . . . . 15 71 3.2.3. Calendar User Type . . . . . . . . . . . . . . . . . 16 72 3.2.4. Delegators . . . . . . . . . . . . . . . . . . . . . 16 73 3.2.5. Delegatees . . . . . . . . . . . . . . . . . . . . . 17 74 3.2.6. Directory Entry Reference . . . . . . . . . . . . . . 18 75 3.2.7. Inline Encoding . . . . . . . . . . . . . . . . . . . 18 76 3.2.8. Format Type . . . . . . . . . . . . . . . . . . . . . 19 77 3.2.9. Free/Busy Time Type . . . . . . . . . . . . . . . . . 19 78 3.2.10. Language . . . . . . . . . . . . . . . . . . . . . . 20 79 3.2.11. Group or List Membership . . . . . . . . . . . . . . 21 80 3.2.12. Participation Status . . . . . . . . . . . . . . . . 21 81 3.2.13. Recurrence Identifier Range . . . . . . . . . . . . . 24 82 3.2.14. Alarm Trigger Relationship . . . . . . . . . . . . . 24 83 3.2.15. Relationship Type . . . . . . . . . . . . . . . . . . 25 84 3.2.16. Participation Role . . . . . . . . . . . . . . . . . 26 85 3.2.17. RSVP Expectation . . . . . . . . . . . . . . . . . . 27 86 3.2.18. Sent By . . . . . . . . . . . . . . . . . . . . . . . 27 87 3.2.19. Time Zone Identifier . . . . . . . . . . . . . . . . 28 88 3.2.20. Value Data Types . . . . . . . . . . . . . . . . . . 29 89 3.3. Property Value Data Types . . . . . . . . . . . . . . . . 30 90 3.3.1. Binary . . . . . . . . . . . . . . . . . . . . . . . 31 91 3.3.2. Boolean . . . . . . . . . . . . . . . . . . . . . . . 31 92 3.3.3. Calendar User Address . . . . . . . . . . . . . . . . 32 93 3.3.4. Date . . . . . . . . . . . . . . . . . . . . . . . . 32 94 3.3.5. Date-Time . . . . . . . . . . . . . . . . . . . . . . 33 95 3.3.6. Duration . . . . . . . . . . . . . . . . . . . . . . 36 96 3.3.7. Float . . . . . . . . . . . . . . . . . . . . . . . . 37 97 3.3.8. Integer . . . . . . . . . . . . . . . . . . . . . . . 37 98 3.3.9. Period of Time . . . . . . . . . . . . . . . . . . . 38 99 3.3.10. Recurrence Rule . . . . . . . . . . . . . . . . . . . 39 100 3.3.11. Text . . . . . . . . . . . . . . . . . . . . . . . . 46 101 3.3.12. Time . . . . . . . . . . . . . . . . . . . . . . . . 48 102 3.3.13. URI . . . . . . . . . . . . . . . . . . . . . . . . . 50 103 3.3.14. UTC Offset . . . . . . . . . . . . . . . . . . . . . 50 104 3.4. iCalendar Object . . . . . . . . . . . . . . . . . . . . 51 105 3.5. Property . . . . . . . . . . . . . . . . . . . . . . . . 52 106 3.6. Calendar Components . . . . . . . . . . . . . . . . . . . 52 107 3.6.1. Event Component . . . . . . . . . . . . . . . . . . . 53 108 3.6.2. To-do Component . . . . . . . . . . . . . . . . . . . 57 109 3.6.3. Journal Component . . . . . . . . . . . . . . . . . . 59 110 3.6.4. Free/Busy Component . . . . . . . . . . . . . . . . . 61 111 3.6.5. Time Zone Component . . . . . . . . . . . . . . . . . 64 112 3.6.6. Alarm Component . . . . . . . . . . . . . . . . . . . 73 113 3.7. Calendar Properties . . . . . . . . . . . . . . . . . . . 78 114 3.7.1. Calendar Scale . . . . . . . . . . . . . . . . . . . 78 115 3.7.2. Method . . . . . . . . . . . . . . . . . . . . . . . 79 116 3.7.3. Product Identifier . . . . . . . . . . . . . . . . . 80 117 3.7.4. Version . . . . . . . . . . . . . . . . . . . . . . . 81 118 3.8. Component Properties . . . . . . . . . . . . . . . . . . 82 119 3.8.1. Descriptive Component Properties . . . . . . . . . . 82 120 3.8.1.1. Attachment . . . . . . . . . . . . . . . . . . . 82 121 3.8.1.2. Categories . . . . . . . . . . . . . . . . . . . 83 122 3.8.1.3. Classification . . . . . . . . . . . . . . . . . 84 123 3.8.1.4. Comment . . . . . . . . . . . . . . . . . . . . . 85 124 3.8.1.5. Description . . . . . . . . . . . . . . . . . . . 87 125 3.8.1.6. Geographic Position . . . . . . . . . . . . . . . 88 126 3.8.1.7. Location . . . . . . . . . . . . . . . . . . . . 89 127 3.8.1.8. Percent Complete . . . . . . . . . . . . . . . . 91 128 3.8.1.9. Priority . . . . . . . . . . . . . . . . . . . . 91 129 3.8.1.10. Resources . . . . . . . . . . . . . . . . . . . . 93 130 3.8.1.11. Status . . . . . . . . . . . . . . . . . . . . . 94 131 3.8.1.12. Summary . . . . . . . . . . . . . . . . . . . . . 96 132 3.8.2. Date and Time Component Properties . . . . . . . . . 97 133 3.8.2.1. Date/Time Completed . . . . . . . . . . . . . . . 97 134 3.8.2.2. Date/Time End . . . . . . . . . . . . . . . . . . 97 135 3.8.2.3. Date/Time Due . . . . . . . . . . . . . . . . . . 99 136 3.8.2.4. Date/Time Start . . . . . . . . . . . . . . . . . 100 137 3.8.2.5. Duration . . . . . . . . . . . . . . . . . . . . 101 138 3.8.2.6. Free/Busy Time . . . . . . . . . . . . . . . . . 102 139 3.8.2.7. Time Transparency . . . . . . . . . . . . . . . . 103 140 3.8.3. Time Zone Component Properties . . . . . . . . . . . 104 141 3.8.3.1. Time Zone Identifier . . . . . . . . . . . . . . 104 142 3.8.3.2. Time Zone Name . . . . . . . . . . . . . . . . . 106 143 3.8.3.3. Time Zone Offset From . . . . . . . . . . . . . . 107 144 3.8.3.4. Time Zone Offset To . . . . . . . . . . . . . . . 107 145 3.8.3.5. Time Zone URL . . . . . . . . . . . . . . . . . . 108 146 3.8.4. Relationship Component Properties . . . . . . . . . . 109 147 3.8.4.1. Attendee . . . . . . . . . . . . . . . . . . . . 109 148 3.8.4.2. Contact . . . . . . . . . . . . . . . . . . . . . 112 149 3.8.4.3. Organizer . . . . . . . . . . . . . . . . . . . . 113 150 3.8.4.4. Recurrence ID . . . . . . . . . . . . . . . . . . 115 151 3.8.4.5. Related To . . . . . . . . . . . . . . . . . . . 117 152 3.8.4.6. Uniform Resource Locator . . . . . . . . . . . . 119 153 3.8.4.7. Unique Identifier . . . . . . . . . . . . . . . . 120 154 3.8.5. Recurrence Component Properties . . . . . . . . . . . 121 155 3.8.5.1. Exception Date/Times . . . . . . . . . . . . . . 121 156 3.8.5.2. Recurrence Date/Times . . . . . . . . . . . . . . 123 157 3.8.5.3. Recurrence Rule . . . . . . . . . . . . . . . . . 125 158 3.8.6. Alarm Component Properties . . . . . . . . . . . . . 135 159 3.8.6.1. Action . . . . . . . . . . . . . . . . . . . . . 135 160 3.8.6.2. Repeat Count . . . . . . . . . . . . . . . . . . 136 161 3.8.6.3. Trigger . . . . . . . . . . . . . . . . . . . . . 136 162 3.8.7. Change Management Component Properties . . . . . . . 139 163 3.8.7.1. Date/Time Created . . . . . . . . . . . . . . . . 139 164 3.8.7.2. Date/Time Stamp . . . . . . . . . . . . . . . . . 140 165 3.8.7.3. Last Modified . . . . . . . . . . . . . . . . . . 141 166 3.8.7.4. Sequence Number . . . . . . . . . . . . . . . . . 142 167 3.8.8. Miscellaneous Component Properties . . . . . . . . . 143 168 3.8.8.1. IANA Properties . . . . . . . . . . . . . . . . . 143 169 3.8.8.2. Non-standard Properties . . . . . . . . . . . . . 143 170 3.8.8.3. Request Status . . . . . . . . . . . . . . . . . 144 171 4. iCalendar Object Examples . . . . . . . . . . . . . . . . . . 148 172 5. Recommended Practices . . . . . . . . . . . . . . . . . . . . 152 173 6. Internationalization Considerations . . . . . . . . . . . . . 153 174 7. Security Considerations . . . . . . . . . . . . . . . . . . . 153 175 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 153 176 8.1. iCalendar Media Type Registration . . . . . . . . . . . . 154 177 8.2. New iCalendar Elements Registration . . . . . . . . . . . 157 178 8.2.1. iCalendar Elements Registration Procedure . . . . . . 157 179 8.2.2. Registration Template for Components . . . . . . . . 157 180 8.2.3. Registration Template for Properties . . . . . . . . 158 181 8.2.4. Registration Template for Parameters . . . . . . . . 158 182 8.2.5. Registration Template for Value Data Types . . . . . 159 183 8.2.6. Registration Template for Values . . . . . . . . . . 159 184 8.3. Initial iCalendar Elements Registries . . . . . . . . . . 160 185 8.3.1. Components Registry . . . . . . . . . . . . . . . . . 160 186 8.3.2. Properties Registry . . . . . . . . . . . . . . . . . 161 187 8.3.3. Parameters Registry . . . . . . . . . . . . . . . . . 162 188 8.3.4. Value Data Types Registry . . . . . . . . . . . . . . 162 189 8.3.5. Calendar User Types Registry . . . . . . . . . . . . 163 190 8.3.6. Free/Busy Time Types Registry . . . . . . . . . . . . 163 191 8.3.7. Participation Statuses Registry . . . . . . . . . . . 164 192 8.3.8. Relationship Types Registry . . . . . . . . . . . . . 164 193 8.3.9. Participation Roles Registry . . . . . . . . . . . . 164 194 8.3.10. Actions Registry . . . . . . . . . . . . . . . . . . 165 195 8.3.11. Classifications Registry . . . . . . . . . . . . . . 165 196 8.3.12. Methods Registry . . . . . . . . . . . . . . . . . . 165 197 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 165 198 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 166 199 10.1. Normative References . . . . . . . . . . . . . . . . . . 166 200 10.2. Informative References . . . . . . . . . . . . . . . . . 167 201 Appendix A. Differences from RFC 2445 . . . . . . . . . . . . . 168 202 A.1. New restrictions . . . . . . . . . . . . . . . . . . . . 168 203 A.2. Restrictions removed . . . . . . . . . . . . . . . . . . 168 204 A.3. Deprecated features . . . . . . . . . . . . . . . . . . . 169 205 Appendix B. Change Log (to be removed by RFC Editor prior to 206 publication) . . . . . . . . . . . . . . . . . . . . 169 207 B.1. Changes in -08 . . . . . . . . . . . . . . . . . . . . . 169 208 B.2. Changes in -07 . . . . . . . . . . . . . . . . . . . . . 170 209 B.3. Changes in -06 . . . . . . . . . . . . . . . . . . . . . 171 210 B.4. Changes in -05 . . . . . . . . . . . . . . . . . . . . . 173 211 B.5. Changes in -04 . . . . . . . . . . . . . . . . . . . . . 173 212 B.6. Changes in -03 . . . . . . . . . . . . . . . . . . . . . 175 213 B.7. Changes in -02 . . . . . . . . . . . . . . . . . . . . . 175 214 B.8. Changes in -01 . . . . . . . . . . . . . . . . . . . . . 176 216 1. Introduction 218 The use of calendaring and scheduling has grown considerably in the 219 last decade. Enterprise and inter-enterprise business has become 220 dependent on rapid scheduling of events and actions using this 221 information technology. However, the longer term growth of 222 calendaring and scheduling is currently limited by the lack of 223 Internet standards for the message content types that are central to 224 these knowledgeware applications. This memo is intended to progress 225 the level of interoperability possible between dissimilar calendaring 226 and scheduling applications. This memo defines a MIME content type 227 for exchanging electronic calendaring and scheduling information. 228 The Internet Calendaring and Scheduling Core Object Specification, or 229 iCalendar, allows for the capture and exchange of information 230 normally stored within a calendaring and scheduling application; such 231 as a Personal Information Manager (PIM) or a Group Scheduling 232 product. 234 The iCalendar format is suitable as an exchange format between 235 applications or systems. The format is defined in terms of a MIME 236 content type. This will enable the object to be exchanged using 237 several transports, including but not limited to SMTP, HTTP, a file 238 system, desktop interactive protocols such as the use of a memory- 239 based clipboard or drag/drop interactions, point-to-point 240 asynchronous communication, wired-network transport, or some form of 241 unwired transport such as infrared might also be used. 243 The memo also provides for the definition of iCalendar object methods 244 that will map this content type to a set of messages for supporting 245 calendaring and scheduling operations such as requesting, replying 246 to, modifying, and canceling meetings or appointments, to-dos and 247 journal entries. The iCalendar object methods can be used to define 248 other calendaring and scheduling operations such a requesting for and 249 replying with free/busy time data. Such a scheduling protocol is 250 defined in the iCalendar Transport-independent Interoperability 251 Protocol (iTIP) defined in [I-D.ietf-calsify-2446bis]. 253 The memo also includes a formal grammar for the content type based on 254 the Internet ABNF defined in [RFC5234]. This ABNF is required for 255 the implementation of parsers and to serve as the definitive 256 reference when ambiguities or questions arise in interpreting the 257 descriptive prose definition of the memo. Additional restrictions 258 that could not easily be expressed with the ABNF syntax are specified 259 as comments in the ABNF. Comments with normative statements should 260 be treated as such. 262 2. Basic Grammar and Conventions 264 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 265 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" and 266 "OPTIONAL" in this document are to be interpreted as described in 267 [RFC2119]. 269 This memo makes use of both a descriptive prose and a more formal 270 notation for defining the calendaring and scheduling format. 272 The notation used in this memo is the ABNF notation of [RFC5234]. 273 Readers intending on implementing the format defined in this memo 274 should be familiar with this notation in order to properly interpret 275 the specifications of this memo. 277 All numeric values used in this memo are given in decimal notation. 279 All names of properties, property parameters, enumerated property 280 values and property parameter values are case-insensitive. However, 281 all other property values are case-sensitive, unless otherwise 282 stated. 284 Note: All indented editorial notes, such as this one, are intended 285 to provide the reader with additional information. The 286 information is not essential to the building of an implementation 287 conformant with this memo. The information is provided to 288 highlight a particular feature or characteristic of the memo. 290 The format for the iCalendar object is based on the syntax of the 291 text/directory media type [RFC2425]. While the iCalendar object is 292 not a profile of the text/directory media type [RFC2425], it does 293 reuse a number of the elements from the [RFC2425] specification. 295 2.1. Formatting Conventions 297 The elements defined in this memo are defined in prose. Many of the 298 terms used to describe these have common usage that is different than 299 the standards usage of this memo. In order to reference within this 300 memo elements of the calendaring and scheduling model, core object 301 (this memo) or interoperability protocol [I-D.ietf-calsify-2446bis] 302 some formatting conventions have been used. Calendaring and 303 scheduling roles are referred to in quoted-strings of text with the 304 first character of each word in upper case. For example, "Organizer" 305 refers to a role of a "Calendar User" within the scheduling protocol 306 defined by [I-D.ietf-calsify-2446bis]. Calendar components defined 307 by this memo are referred to with capitalized, quoted-strings of 308 text. All calendar components start with the letter "V". For 309 example, "VEVENT" refers to the event calendar component, "VTODO" 310 refers to the to-do calendar component and "VJOURNAL" refers to the 311 daily journal calendar component. Scheduling methods defined by iTIP 312 [I-D.ietf-calsify-2446bis] are referred to with capitalized, quoted- 313 strings of text. For example, "REQUEST" refers to the method for 314 requesting a scheduling calendar component be created or modified, 315 "REPLY" refers to the method a recipient of a request uses to update 316 their status with the "Organizer" of the calendar component. 318 The properties defined by this memo are referred to with capitalized, 319 quoted-strings of text, followed by the word "property". For 320 example, "ATTENDEE" property refers to the iCalendar property used to 321 convey the calendar address of a calendar user. Property parameters 322 defined by this memo are referred to with lowercase, quoted-strings 323 of text, followed by the word "parameter". For example, "value" 324 parameter refers to the iCalendar property parameter used to override 325 the default value type for a property value. Enumerated values 326 defined by this memo are referred to with capitalized text, either 327 alone or followed by the word "value". For example, the "MINUTELY" 328 value can be used with the "FREQ" component of the "RECUR" value type 329 to specify repeating components based on an interval of one minute or 330 more. 332 In this document, descriptions of characters are of the form 333 "character name (codepoint)", where "codepoint" is from the US-ASCII 334 character set. The "character name" is the authoritative 335 description; (codepoint) is a reference to that character in US- 336 ASCII. 338 2.2. Related Memos 340 Implementers will need to be familiar with several other memos that, 341 along with this memo, form a framework for Internet calendaring and 342 scheduling standards. This memo specifies a core specification of 343 objects, value types, properties and property parameters. 345 o iTIP [I-D.ietf-calsify-2446bis] specifies an interoperability 346 protocol for scheduling between different implementations; 348 o iMIP [I-D.ietf-calsify-rfc2447bis] specifies an Internet email 349 binding for [I-D.ietf-calsify-2446bis]. 351 This memo does not attempt to repeat the specification of concepts or 352 definitions from these other memos. Where possible, references are 353 made to the memo that provides for the specification of these 354 concepts or definitions. 356 3. iCalendar Object Specification 358 The following sections define the details of a Calendaring and 359 Scheduling Core Object Specification. The Calendaring and Scheduling 360 Core Object is a collection of calendaring and scheduling 361 information. Typically, this information will consist of an 362 iCalendar stream with one or more iCalendar objects. The body of the 363 iCalendar object consists of a sequence of calendar properties and 364 one or more calendar components. 366 Section 3.1. defines the content line format; Section 3.2. defines 367 the property parameter format; Section 3.3. defines the data types 368 for property values; Section 3.4. defines the iCalendar object 369 format; Section 3.5. defines the iCalendar property format; Section 370 3.6. defines the calendar component format; Section 3.7. defines 371 calendar properties; and Sectiopn 3.8. defines calendar component 372 properties. 374 This information is intended to be an integral part of the MIME 375 content type registration. In addition, this information can be used 376 independent of such content registration. In particular, this memo 377 has direct applicability for use as a calendaring and scheduling 378 exchange format in file-, memory- or network-based transport 379 mechanisms. 381 3.1. Content Lines 383 The iCalendar object is organized into individual lines of text, 384 called content lines. Content lines are delimited by a line break, 385 which is a CRLF sequence (US-ASCII decimal 13, followed by US-ASCII 386 decimal 10). 388 Lines of text SHOULD NOT be longer than 75 octets, excluding the line 389 break. Long content lines SHOULD be split into a multiple line 390 representations using a line "folding" technique. That is, a long 391 line can be split between any two characters by inserting a CRLF 392 immediately followed by a single linear white space character (i.e., 393 SPACE, US-ASCII decimal 32 or HTAB, US-ASCII decimal 9). Any 394 sequence of CRLF followed immediately by a single linear white space 395 character is ignored (i.e., removed) when processing the content 396 type. 398 For example the line: 400 DESCRIPTION:This is a long description that exists on a long line. 402 Can be represented as: 404 DESCRIPTION:This is a lo 405 ng description 406 that exists on a long line. 408 The process of moving from this folded multiple line representation 409 to its single line representation is called "unfolding". Unfolding 410 is accomplished by removing the CRLF character and the linear white 411 space character that immediately follows. 413 When parsing a content line, folded lines MUST first be unfolded 414 according to the unfolding procedure described above. 416 Note: It is possible for very simple implementations to generate 417 improperly folded lines in the middle of a UTF-8 multi-octet 418 sequence. For this reason, implementations need to unfold lines 419 in such a way to properly restore the original sequence. 421 The content information associated with an iCalendar object is 422 formatted using a syntax similar to that defined by [RFC2425]. That 423 is, the content information consists of CRLF-separated content lines. 425 The following notation defines the lines of content in an iCalendar 426 object: 428 contentline = name *(";" param ) ":" value CRLF 429 ; This ABNF is just a general definition for an initial parsing 430 ; of the content line into its property name, parameter list, 431 ; and value string 433 ; When parsing a content line, folded lines MUST first 434 ; be unfolded according to the unfolding procedure 435 ; described above. When generating a content line, lines 436 ; longer than 75 octets SHOULD be folded according to 437 ; the folding procedure described above. 439 name = iana-token / x-name 441 iana-token = 1*(ALPHA / DIGIT / "-") 442 ; iCalendar identifier registered with IANA 444 x-name = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-") 445 ; Reserved for experimental use. 447 vendorid = 3*(ALPHA / DIGIT) 448 ; Vendor identification 450 param = param-name "=" param-value *("," param-value) 451 ; Each property defines the specific ABNF for the parameters 452 ; allowed on the property. Refer to specific properties for 453 ; precise parameter ABNF. 455 param-name = iana-token / x-name 457 param-value = paramtext / quoted-string 459 paramtext = *SAFE-CHAR 461 value = *VALUE-CHAR 463 quoted-string = DQUOTE *QSAFE-CHAR DQUOTE 465 QSAFE-CHAR = WSP / %x21 / %x23-7E / NON-US-ASCII 466 ; Any character except CONTROL and DQUOTE 468 SAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E 469 / NON-US-ASCII 470 ; Any character except CONTROL, DQUOTE, ";", ":", "," 472 VALUE-CHAR = WSP / %x21-7E / NON-US-ASCII 473 ; Any textual character 475 NON-US-ASCII = UTF8-2 / UTF8-3 / UTF8-4 476 ; UTF8-2, UTF8-3, and UTF8-4 are defined in [RFC3629] 478 CONTROL = %x00-08 / %x0A-1F / %x7F 479 ; All the controls except HTAB 481 The property value component of a content line has a format that is 482 property specific. Refer to the section describing each property for 483 a definition of this format. 485 All names of properties, property parameters, enumerated property 486 values and property parameter values are case-insensitive. However, 487 all other property values are case-sensitive, unless otherwise 488 stated. 490 3.1.1. List and Field Separators 492 Some properties and parameters allow a list of values. Values in a 493 list of values MUST be separated by a COMMA character (US-ASCII 494 decimal 44). There is no significance to the order of values in a 495 list. For those parameter values (such as those that specify URI 496 values) that are specified in quoted-strings, the individual quoted- 497 strings are separated by a COMMA character (US-ASCII decimal 44). 499 Some property values are defined in terms of multiple parts. These 500 structured property values MUST have their value parts separated by a 501 SEMICOLON character (US-ASCII decimal 59). 503 Some properties allow a list of parameters. Each property parameter 504 in a list of property parameters MUST be separated by a SEMICOLON 505 character (US-ASCII decimal 59). 507 Property parameters with values containing a COLON character (US- 508 ASCII decimal 58), a SEMICOLON character (US-ASCII decimal 59) or a 509 COMMA character (US-ASCII decimal 44) MUST be placed in quoted text. 511 For example, in the following properties a SEMICOLON is used to 512 separate property parameters from each other, and a COMMA is used to 513 separate property values in a value list. 515 ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT:mailto: 516 jsmith@example.com 518 RDATE;VALUE=DATE:19970304,19970504,19970704,19970904 520 3.1.2. Multiple Values 522 Some properties defined in the iCalendar object can have multiple 523 values. The general rule for encoding multi-valued items is to 524 simply create a new content line for each value, including the 525 property name. However, it should be noted that some properties 526 support encoding multiple values in a single property by separating 527 the values with a COMMA character (US-ASCII decimal 44). Individual 528 property definitions should be consulted for determining whether a 529 specific property allows multiple values and in which of these two 530 forms. 532 3.1.3. Binary Content 534 Binary content information in an iCalendar object SHOULD be 535 referenced using a URI within a property value. That is the binary 536 content information SHOULD be placed in an external MIME entity that 537 can be referenced by a URI from within the iCalendar object. In 538 applications where this is not feasible, binary content information 539 can be included within an iCalendar object, but only after first 540 encoding it into text using the "BASE64" encoding method defined in 541 [RFC4648]. Inline binary content SHOULD only be used in applications 542 whose special circumstances demand that an iCalendar object be 543 expressed as a single entity. A property containing inline binary 544 content information MUST specify the "ENCODING" property parameter. 545 Binary content information placed external to the iCalendar object 546 MUST be referenced by a uniform resource identifier (URI). 548 The following example specifies an "ATTACH" property that references 549 an attachment external to the iCalendar object with a URI reference: 551 ATTACH:http://example.com/public/quarterly-report.doc 553 The following example specifies an "ATTACH" property with inline 554 binary encoded content information: 556 ATTACH;FMTTYPE=image/basic;ENCODING=BASE64;VALUE=BINARY: 557 MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1U 558 EBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIE 559 <...remainder of "BASE64" encoded binary data...> 561 3.1.4. Character Set 563 There is not a property parameter to declare the charset used in a 564 property value. The default charset for an iCalendar stream is UTF-8 565 as defined in [RFC3629]. 567 The "charset" Content-Type parameter MUST be used in MIME transports 568 to specify the charset being used. 570 3.2. Property Parameters 572 A property can have attributes associated with it. These "property 573 parameters" contain meta-information about the property or the 574 property value. Property parameters are provided to specify such 575 information as the location of an alternate text representation for a 576 property value, the language of a text property value, the value type 577 of the property value and other attributes. 579 Property parameter values that contain the COLON (US-ASCII decimal 580 58), SEMICOLON (US-ASCII decimal 59) or COMMA (US-ASCII decimal 44) 581 character separators MUST be specified as quoted-string text values. 582 Property parameter values MUST NOT contain the DQUOTE (US-ASCII 583 decimal 22) character. The DQUOTE (US-ASCII decimal 22) character is 584 used as a delimiter for parameter values that contain restricted 585 characters or URI text. For example: 587 DESCRIPTION;ALTREP="http://www.example.org":The Fall'98 Wild 588 Wizards Conference - - Las Vegas\, NV\, USA 590 Property parameter values that are not in quoted strings are case 591 insensitive. 593 The general property parameters defined by this memo are defined by 594 the following notation: 596 icalparameter = altrepparam ; Alternate text representation 597 / cnparam ; Common name 598 / cutypeparam ; Calendar user type 599 / delfromparam ; Delegator 600 / deltoparam ; Delegatee 601 / dirparam ; Directory entry 602 / encodingparam ; Inline encoding 603 / fmttypeparam ; Format type 604 / fbtypeparam ; Free/busy time type 605 / languageparam ; Language for text 606 / memberparam ; Group or list membership 607 / partstatparam ; Participation status 608 / rangeparam ; Recurrence identifier range 609 / trigrelparam ; Alarm trigger relationship 610 / reltypeparam ; Relationship type 611 / roleparam ; Participation role 612 / rsvpparam ; RSVP expectation 613 / sentbyparam ; Sent by 614 / tzidparam ; Reference to time zone object 615 / valuetypeparam ; Property value data type 616 / other-param 618 other-param = (iana-param / x-param) 620 iana-param = iana-token "=" param-value *("," param-value) 621 ; Some other IANA registered iCalendar parameter. 623 x-param = x-name "=" param-value *("," param-value) 624 ; A non-standard, experimental parameter. 626 Applications MUST ignore x-param and iana-param value they don't 627 recognized. 629 3.2.1. Alternate Text Representation 631 Parameter Name: ALTREP 633 Purpose: To specify an alternate text representation for the 634 property value. 636 Format Definition: This property parameter is defined by the 637 following notation: 639 altrepparam = "ALTREP" "=" DQUOTE uri DQUOTE 641 Description: This parameter specifies a URI that points to an 642 alternate representation for a textual property value. A property 643 specifying this parameter MUST also include a value that reflects 644 the default representation of the text value. The individual URI 645 parameter values MUST each be specified in a quoted-string. 647 Example: 649 DESCRIPTION;ALTREP="CID:part3.msg.970415T083000@example.com": 650 Project XYZ Review Meeting will include the following agenda 651 items: (a) Market Overview\, (b) Finances\, (c) Project Man 652 agement 654 The "ALTREP" property parameter value might point to a "text/html" 655 content portion. 657 Content-Type:text/html 658 Content-Id: 660 661 662 663 664 665

666 Project XYZ Review Meeting will include 667 the following agenda items: 668

    669
  1. Market Overview
    2. 670
  2. Finances
    3. 671
  3. Project Management
    4. 672
673

674 675 677 3.2.2. Common Name 679 Parameter Name: CN 681 Purpose: To specify the common name to be associated with the 682 calendar user specified by the property. 684 Format Definition: This property parameter is defined by the 685 following notation: 687 cnparam = "CN" "=" param-value 689 Description: This parameter can be specified on properties with a 690 CAL-ADDRESS value type. The parameter specifies the common name 691 to be associated with the calendar user specified by the property. 692 The parameter value is text. The parameter value can be used for 693 display text to be associated with the calendar address specified 694 by the property. 696 Example: 698 ORGANIZER;CN="John Smith":mailto:jsmith@example.com 700 3.2.3. Calendar User Type 702 Parameter Name: CUTYPE 704 Purpose: To specify the type of calendar user specified by the 705 property. 707 Format Definition: This property parameter is defined by the 708 following notation: 710 cutypeparam = "CUTYPE" "=" 711 ("INDIVIDUAL" ; An individual 712 / "GROUP" ; A group of individuals 713 / "RESOURCE" ; A physical resource 714 / "ROOM" ; A room resource 715 / "UNKNOWN" ; Otherwise not known 716 / x-name ; Experimental type 717 / iana-token) ; Other IANA registered 718 ; type 719 ; Default is INDIVIDUAL 721 Description: This parameter can be specified on properties with a 722 CAL-ADDRESS value type. The parameter identifies the type of 723 calendar user specified by the property. If not specified on a 724 property that allows this parameter, the default is INDIVIDUAL. 725 Applications MUST treat x-name and iana-token value they don't 726 recognized the same way as they would the UNKNOWN value. 728 Example: 730 ATTENDEE;CUTYPE=GROUP:mailto:ietf-calsch@example.org 732 3.2.4. Delegators 733 Parameter Name: DELEGATED-FROM 735 Purpose: To specify the calendar users that have delegated their 736 participation to the calendar user specified by the property. 738 Format Definition: This property parameter is defined by the 739 following notation: 741 delfromparam = "DELEGATED-FROM" "=" DQUOTE cal-address 742 DQUOTE *("," DQUOTE cal-address DQUOTE) 744 Description: This parameter can be specified on properties with a 745 CAL-ADDRESS value type. This parameter specifies those calendar 746 users that have delegated their participation in a group scheduled 747 event or to-do to the calendar user specified by the property. 748 The individual calendar address parameter values MUST each be 749 specified in a quoted-string. 751 Example: 753 ATTENDEE;DELEGATED-FROM="mailto:jsmith@example.com":mailto: 754 jdoe@example.com 756 3.2.5. Delegatees 758 Parameter Name: DELEGATED-TO 760 Purpose: To specify the calendar users to whom the calendar user 761 specified by the property has delegated participation. 763 Format Definition: This property parameter is defined by the 764 following notation: 766 deltoparam = "DELEGATED-TO" "=" DQUOTE cal-address DQUOTE 767 *("," DQUOTE cal-address DQUOTE) 769 Description: This parameter can be specified on properties with a 770 CAL-ADDRESS value type. This parameter specifies those calendar 771 users whom have been delegated participation in a group scheduled 772 event or to-do by the calendar user specified by the property. 773 The individual calendar address parameter values MUST each be 774 specified in a quoted-string. 776 Example: 778 ATTENDEE;DELEGATED-TO="mailto:jdoe@example.com","mailto:jqpublic 779 @example.com":mailto:jsmith@example.com 781 3.2.6. Directory Entry Reference 783 Parameter Name: DIR 785 Purpose: To specify reference to a directory entry associated with 786 the calendar user specified by the property. 788 Format Definition: This property parameter is defined by the 789 following notation: 791 dirparam = "DIR" "=" DQUOTE uri DQUOTE 793 Description: This parameter can be specified on properties with a 794 CAL-ADDRESS value type. The parameter specifies a reference to 795 the directory entry associated with the calendar user specified by 796 the property. The parameter value is a URI. The URI parameter 797 value MUST be specified in a quoted-string. 799 Example: 801 ORGANIZER;DIR="ldap://example.com:6666/o=ABC%20Industries, 802 c=US???(cn=Jim%20Dolittle)":mailto:jimdo@example.com 804 3.2.7. Inline Encoding 806 Parameter Name: ENCODING 808 Purpose: To specify an alternate inline encoding for the property 809 value. 811 Format Definition: This property parameter is defined by the 812 following notation: 814 encodingparam = "ENCODING" "=" 815 ( "8BIT" 816 ; "8bit" text encoding is defined in [RFC2045] 817 / "BASE64" 818 ; "BASE64" binary encoding format is defined in [RFC4648] 819 ) 821 Description: This property parameter identifies the inline encoding 822 used in a property value. The default encoding is "8BIT", 823 corresponding to a property value consisting of text. The 824 "BASE64" encoding type corresponds to a property value encoded 825 using the "BASE64" encoding defined in [RFC2045]. 827 If the value type parameter is ";VALUE=BINARY", then the inline 828 encoding parameter MUST be specified with the value 829 ";ENCODING=BASE64". 831 Example: 833 ATTACH;FMTYPE=IMAGE/JPEG;ENCODING=BASE64;VALUE=BINARY:MIICajC 834 CAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDA 835 qBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMRw 836 <...remainder of "BASE64" encoded binary data...> 838 3.2.8. Format Type 840 Parameter Name: FMTTYPE 842 Purpose: To specify the content type of a referenced object. 844 Format Definition: This property parameter is defined by the 845 following notation: 847 fmttypeparam = "FMTTYPE" "=" type "/" subtype *(";" parameter) 848 ; Where "type", "subtype", and "parameter" 849 ; are defined in section 5.1 of [RFC2045] 851 Description: This parameter can be specified on properties that are 852 used to reference an object. The parameter specifies the content 853 type of the referenced object. For example, on the "ATTACH" 854 property, a FTP type URI value does not, by itself, necessarily 855 convey the type of content associated with the resource. The 856 parameter value MUST be the text for either an IANA registered 857 media type or a non-standard media type. 859 Example: 861 ATTACH;FMTTYPE=application/msword:ftp://example.com/pub/docs/ 862 agenda.doc 864 3.2.9. Free/Busy Time Type 866 Parameter Name: FBTYPE 868 Purpose: To specify the free or busy time type. 870 Format Definition: This property parameter is defined by the 871 following notation: 873 fbtypeparam = "FBTYPE" "=" ("FREE" / "BUSY" 874 / "BUSY-UNAVAILABLE" / "BUSY-TENTATIVE" 875 / x-name 876 ; Some experimental iCalendar free busy type. 877 / iana-token) 878 ; Some other IANA registered iCalendar free busy type. 880 Description: This parameter specifies the free or busy time type. 881 The value FREE indicates that the time interval is free for 882 scheduling. The value BUSY indicates that the time interval is 883 busy because one or more events have been scheduled for that 884 interval. The value BUSY-UNAVAILABLE indicates that the time 885 interval is busy and that the interval can not be scheduled. The 886 value BUSY-TENTATIVE indicates that the time interval is busy 887 because one or more events have been tentatively scheduled for 888 that interval. If not specified on a property that allows this 889 parameter, the default is BUSY. Applications MUST treat x-name 890 and iana-token value they don't recognized the same way as they 891 would the BUSY value. 893 Example: The following is an example of this parameter on a 894 "FREEBUSY" property. 896 FREEBUSY;FBTYPE=BUSY:19980415T133000Z/19980415T170000Z 898 3.2.10. Language 900 Parameter Name: LANGUAGE 902 Purpose: To specify the language for text values in a property or 903 property parameter. 905 Format Definition: This property parameter is defined by the 906 following notation: 908 languageparam = "LANGUAGE" "=" language 910 language = Language-Tag 911 ; As defined in [RFC4646] 913 Description: This parameter identifies the language of the text in 914 the property value and of all property parameter values of the 915 property. The value of the "LANGUAGE" property parameter is that 916 defined in [RFC4646]. 918 For transport in a MIME entity, the Content-Language header field 919 can be used to set the default language for the entire body part. 920 Otherwise, no default language is assumed. 922 Example: The following are examples of this parameter on the 923 "SUMMARY" and "LOCATION" properties: 925 SUMMARY;LANGUAGE=us-EN:Company Holiday Party 927 LOCATION;LANGUAGE=en:Germany 929 LOCATION;LANGUAGE=no:Tyskland 931 3.2.11. Group or List Membership 933 Parameter Name: MEMBER 935 Purpose: To specify the group or list membership of the calendar 936 user specified by the property. 938 Format Definition: This property parameter is defined by the 939 following notation: 941 memberparam = "MEMBER" "=" DQUOTE cal-address DQUOTE 942 *("," DQUOTE cal-address DQUOTE) 944 Description: This parameter can be specified on properties with a 945 CAL-ADDRESS value type. The parameter identifies the groups or 946 list membership for the calendar user specified by the property. 947 The parameter value is either a single calendar address in a 948 quoted-string or a COMMA character (US-ASCII decimal 44) separated 949 list of calendar addresses, each in a quoted-string. The 950 individual calendar address parameter values MUST each be 951 specified in a quoted-string. 953 Example: 955 ATTENDEE;MEMBER="mailto:ietf-calsch@example.org":mailto: 956 jsmith@example.com 958 ATTENDEE;MEMBER="mailto:projectA@example.com","mailto:pr 959 ojectB@example.com":mailto:janedoe@example.com 961 3.2.12. Participation Status 962 Parameter Name: PARTSTAT 964 Purpose: To specify the participation status for the calendar user 965 specified by the property. 967 Format Definition: This property parameter is defined by the 968 following notation: 970 partstatparam = "PARTSTAT" "=" 971 (partstat-event 972 / partstat-todo 973 / partstat-jour) 975 partstat-event = ("NEEDS-ACTION" ; Event needs action 976 / "ACCEPTED" ; Event accepted 977 / "DECLINED" ; Event declined 978 / "TENTATIVE" ; Event tentatively 979 ; accepted 980 / "DELEGATED" ; Event delegated 981 / x-name ; Experimental status 982 / iana-token) ; Other IANA registered 983 ; status 984 ; These are the participation statuses for a "VEVENT". 985 ; Default is NEEDS-ACTION. 987 partstat-todo = ("NEEDS-ACTION" ; To-do needs action 988 / "ACCEPTED" ; To-do accepted 989 / "DECLINED" ; To-do declined 990 / "TENTATIVE" ; To-do tentatively 991 ; accepted 992 / "DELEGATED" ; To-do delegated 993 / "COMPLETED" ; To-do completed. 994 ; COMPLETED property has 995 ; date/time completed. 996 / "IN-PROCESS" ; To-do in process of 997 ; being completed 998 / x-name ; Experimental status 999 / iana-token) ; Other IANA registered 1000 ; status 1001 ; These are the participation statuses for a "VTODO". 1002 ; Default is NEEDS-ACTION. 1004 partstat-jour = ("NEEDS-ACTION" ; Journal needs action 1005 / "ACCEPTED" ; Journal accepted 1006 / "DECLINED" ; Journal declined 1007 / x-name ; Experimental status 1008 / iana-token) ; Other IANA registered 1009 ; status 1010 ; These are the participation statuses for a "VJOURNAL". 1011 ; Default is NEEDS-ACTION. 1013 Description: This parameter can be specified on properties with a 1014 CAL-ADDRESS value type. The parameter identifies the 1015 participation status for the calendar user specified by the 1016 property value. The parameter values differ depending on whether 1017 they are associated with a group scheduled "VEVENT", "VTODO" or 1018 "VJOURNAL". The values MUST match one of the values allowed for 1019 the given calendar component. If not specified on a property that 1020 allows this parameter, the default value is NEEDS-ACTION. 1021 Applications MUST treat x-name and iana-token value they don't 1022 recognized the same way as they would the NEEDS-ACTION value. 1024 Example: 1026 ATTENDEE;PARTSTAT=DECLINED:mailto:jsmith@example.com 1028 3.2.13. Recurrence Identifier Range 1030 Parameter Name: RANGE 1032 Purpose: To specify the effective range of recurrence instances from 1033 the instance specified by the recurrence identifier specified by 1034 the property. 1036 Format Definition: This property parameter is defined by the 1037 following notation: 1039 rangeparam = "RANGE" "=" "THISANDFUTURE" 1040 ; To specify the instance specified by the recurrence identifier 1041 ; and all subsequent recurrence instances 1043 Description: This parameter can be specified on a property that 1044 specifies a recurrence identifier. The parameter specifies the 1045 effective range of recurrence instances that is specified by the 1046 property. The effective range is from the recurrence identifier 1047 specified by the property. If this parameter is not specified on 1048 an allowed property, then the default range is the single instance 1049 specified by the recurrence identifier value of the property. The 1050 parameter value can only be "THISANDFUTURE" to indicate a range 1051 defined by the recurrence identifier and all subsequent instances. 1053 Note: The value "THISANDPRIOR" is deprecated by this revision 1054 of iCalendar and MUST NOT be generated by applications. 1056 Example: 1058 RECURRENCE-ID;RANGE=THISANDFUTURE:19980401T133000Z 1060 3.2.14. Alarm Trigger Relationship 1061 Parameter Name: RELATED 1063 Purpose: To specify the relationship of the alarm trigger with 1064 respect to the start or end of the calendar component. 1066 Format Definition: This property parameter is defined by the 1067 following notation: 1069 trigrelparam = "RELATED" "=" 1070 ("START" ; Trigger off of start 1071 / "END") ; Trigger off of end 1073 Description: This parameter can be specified on properties that 1074 specify an alarm trigger with a "DURATION" value type. The 1075 parameter specifies whether the alarm will trigger relative to the 1076 start or end of the calendar component. The parameter value START 1077 will set the alarm to trigger off the start of the calendar 1078 component; the parameter value END will set the alarm to trigger 1079 off the end of the calendar component. If the parameter is not 1080 specified on an allowable property, then the default is START. 1082 Example: 1084 TRIGGER;RELATED=END:PT5M 1086 3.2.15. Relationship Type 1088 Parameter Name: RELTYPE 1090 Purpose: To specify the type of hierarchical relationship associated 1091 with the calendar component specified by the property. 1093 Format Definition: This property parameter is defined by the 1094 following notation: 1096 reltypeparam = "RELTYPE" "=" 1097 ("PARENT" ; Parent relationship. Default. 1098 / "CHILD" ; Child relationship 1099 / "SIBLING" ; Sibling relationship 1100 / iana-token ; Some other IANA registered 1101 ; iCalendar relationship type 1102 / x-name) ; A non-standard, experimental 1103 ; relationship type 1105 Description: This parameter can be specified on a property that 1106 references another related calendar. The parameter specifies the 1107 hierarchical relationship type of the calendar component 1108 referenced by the property. The parameter value can be PARENT, to 1109 indicate that the referenced calendar component is a superior of 1110 calendar component; CHILD to indicate that the referenced calendar 1111 component is a subordinate of the calendar component; SIBLING to 1112 indicate that the referenced calendar component is a peer of the 1113 calendar component. If this parameter is not specified on an 1114 allowable property, the default relationship type is PARENT. 1115 Applications MUST treat x-name and iana-token value they don't 1116 recognized the same way as they would the PARENT value. 1118 Example: 1120 RELATED-TO;RELTYPE=SIBLING:19960401-080045-4000F192713@ 1121 example.com 1123 3.2.16. Participation Role 1125 Parameter Name: ROLE 1127 Purpose: To specify the participation role for the calendar user 1128 specified by the property. 1130 Format Definition: This property parameter is defined by the 1131 following notation: 1133 roleparam = "ROLE" "=" 1134 ("CHAIR" ; Indicates chair of the 1135 ; calendar entity 1136 / "REQ-PARTICIPANT" ; Indicates a participant whose 1137 ; participation is required 1138 / "OPT-PARTICIPANT" ; Indicates a participant whose 1139 ; participation is optional 1140 / "NON-PARTICIPANT" ; Indicates a participant who 1141 ; is copied for information 1142 ; purposes only 1143 / x-name ; Experimental role 1144 / iana-token) ; Other IANA role 1145 ; Default is REQ-PARTICIPANT 1147 Description: This parameter can be specified on properties with a 1148 CAL-ADDRESS value type. The parameter specifies the participation 1149 role for the calendar user specified by the property in the group 1150 schedule calendar component. If not specified on a property that 1151 allows this parameter, the default value is REQ-PARTICIPANT. 1152 Applications MUST treat x-name and iana-token value they don't 1153 recognized the same way as they would the REQ-PARTICIPANT value. 1155 Example: 1157 ATTENDEE;ROLE=CHAIR:mailto:mrbig@example.com 1159 3.2.17. RSVP Expectation 1161 Parameter Name: RSVP 1163 Purpose: To specify whether there is an expectation of a favor of a 1164 reply from the calendar user specified by the property value. 1166 Format Definition: This property parameter is defined by the 1167 following notation: 1169 rsvpparam = "RSVP" "=" ("TRUE" / "FALSE") 1170 ; Default is FALSE 1172 Description: This parameter can be specified on properties with a 1173 CAL-ADDRESS value type. The parameter identifies the expectation 1174 of a reply from the calendar user specified by the property value. 1175 This parameter is used by the "Organizer" to request a 1176 participation status reply from an "Attendee" of a group scheduled 1177 event or to-do. If not specified on a property that allows this 1178 parameter, the default value is FALSE. 1180 Example: 1182 ATTENDEE;RSVP=TRUE:mailto:jsmith@example.com 1184 3.2.18. Sent By 1186 Parameter Name: SENT-BY 1188 Purpose: To specify the calendar user that is acting on behalf of 1189 the calendar user specified by the property. 1191 Format Definition: This property parameter is defined by the 1192 following notation: 1194 sentbyparam = "SENT-BY" "=" DQUOTE cal-address DQUOTE 1196 Description: This parameter can be specified on properties with a 1197 CAL-ADDRESS value type. The parameter specifies the calendar user 1198 that is acting on behalf of the calendar user specified by the 1199 property. The parameter value MUST be a mailto URI as defined in 1200 [RFC2368]. The individual calendar address parameter values MUST 1201 each be specified in a quoted-string. 1203 Example: 1205 ORGANIZER;SENT-BY="mailto:sray@example.com":mailto: 1206 jsmith@example.com 1208 3.2.19. Time Zone Identifier 1210 Parameter Name: TZID 1212 Purpose: To specify the identifier for the time zone definition for 1213 a time component in the property value. 1215 Format Definition: This property parameter is defined by the 1216 following notation: 1218 tzidparam = "TZID" "=" [tzidprefix] paramtext 1220 tzidprefix = "/" 1222 Description: This parameter MUST be specified on the "DTSTART", 1223 "DTEND", "DUE", "EXDATE" and "RDATE" properties when either a 1224 DATE-TIME or TIME value type is specified and when the value is 1225 not either a UTC or a "floating" time. Refer to the DATE-TIME or 1226 TIME value type definition for a description of UTC and "floating 1227 time" formats. This property parameter specifies a text value 1228 which uniquely identifies the "VTIMEZONE" calendar component to be 1229 used when evaluating the time portion of the property. The value 1230 of the "TZID" property parameter will be equal to the value of the 1231 "TZID" property for the matching time zone definition. An 1232 individual "VTIMEZONE" calendar component MUST be specified for 1233 each unique "TZID" parameter value specified in the iCalendar 1234 object. 1236 The parameter MUST be specified on properties with a DATE-TIME 1237 value if the DATE-TIME is not either a UTC or a "floating" time. 1239 The presence of the SOLIDUS character (US-ASCII decimal 47) as a 1240 prefix, indicates that this "TZID" represents a unique ID in a 1241 globally defined time zone registry (when such registry is 1242 defined). 1244 Note: This document does not define a naming convention for 1245 time zone identifiers. Implementers may want to use the naming 1246 conventions defined in existing time zone specifications such 1247 as the public-domain TZ database [TZDB]. The specification of 1248 globally unique time zone identifiers is not addressed by this 1249 document and is left for future study. 1251 The following are examples of this property parameter: 1253 DTSTART;TZID=America/New_York:19980119T020000 1255 DTEND;TZID=America/New_York:19980119T030000 1257 The "TZID" property parameter MUST NOT be applied to DATE 1258 properties, and DATE-TIME or TIME properties whose time values are 1259 specified in UTC. 1261 The use of local time in a DATE-TIME or TIME value without the 1262 "TZID" property parameter is to be interpreted as a local time 1263 value, regardless of the existence of "VTIMEZONE" calendar 1264 components in the iCalendar object. 1266 For more information see the sections on the value types DATE-TIME 1267 and TIME. 1269 3.2.20. Value Data Types 1271 Parameter Name: VALUE 1273 Purpose: To explicitly specify the value type format for a property 1274 value. 1276 Format Definition: This property parameter is defined by the 1277 following notation: 1279 valuetypeparam = "VALUE" "=" valuetype 1281 valuetype = ("BINARY" 1282 / "BOOLEAN" 1283 / "CAL-ADDRESS" 1284 / "DATE" 1285 / "DATE-TIME" 1286 / "DURATION" 1287 / "FLOAT" 1288 / "INTEGER" 1289 / "PERIOD" 1290 / "RECUR" 1291 / "TEXT" 1292 / "TIME" 1293 / "URI" 1294 / "UTC-OFFSET" 1295 / x-name 1296 ; Some experimental iCalendar value type. 1297 / iana-token) 1298 ; Some other IANA registered iCalendar value type. 1300 Description: This parameter specifies the value type and format of 1301 the property value. The property values MUST be of a single value 1302 type. For example, a "RDATE" property cannot have a combination 1303 of DATE-TIME and TIME value types. 1305 If the property's value is the default value type, then this 1306 parameter need not be specified. However, if the property's 1307 default value type is overridden by some other allowable value 1308 type, then this parameter MUST be specified. 1310 Applications MUST preserve the value data for x-name and iana- 1311 token values that they don't recognize without attempting to 1312 interpret or parse the value data. 1314 3.3. Property Value Data Types 1316 The properties in an iCalendar object are strongly typed. The 1317 definition of each property restricts the value to be one of the 1318 value data types, or simply value types, defined in this section. 1319 The value type for a property will either be specified implicitly as 1320 the default value type or will be explicitly specified with the 1321 "VALUE" parameter. If the value type of a property is one of the 1322 alternate valid types, then it MUST be explicitly specified with the 1323 "VALUE" parameter. 1325 3.3.1. Binary 1327 Value Name: BINARY 1329 Purpose: This value type is used to identify properties that contain 1330 a character encoding of inline binary data. For example, an 1331 inline attachment of a document might be included in an iCalendar 1332 object. 1334 Format Definition: This value type is defined by the following 1335 notation: 1337 binary = *(4b-char) [b-end] 1338 ; A "BASE64" encoded character string, as defined by [RFC4648]. 1340 b-end = (2b-char "==") / (3b-char "=") 1342 b-char = ALPHA / DIGIT / "+" / "/" 1344 Description: Property values with this value type MUST also include 1345 the inline encoding parameter sequence of ";ENCODING=BASE64". 1346 That is, all inline binary data MUST first be character encoded 1347 using the "BASE64" encoding method defined in [RFC2045]. No 1348 additional content value encoding (i.e., BACKSLASH character 1349 encoding, see Section 3.3.11) is defined for this value type. 1351 Example: The following is an abridged example of a "BASE64" encoded 1352 binary value data. 1354 JKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlI 1355 ENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZv 1356 <...remainder of "BASE64" encoded binary data...> 1358 3.3.2. Boolean 1360 Value Name: BOOLEAN 1362 Purpose: This value type is used to identify properties that contain 1363 either a "TRUE" or "FALSE" Boolean value. 1365 Format Definition: This value type is defined by the following 1366 notation: 1368 boolean = "TRUE" / "FALSE" 1370 Description: These values are case insensitive text. No additional 1371 content value encoding (i.e., BACKSLASH character encoding, see 1372 Section 3.3.11) is defined for this value type. 1374 Example: The following is an example of a hypothetical property that 1375 has a BOOLEAN value type: 1377 TRUE 1379 3.3.3. Calendar User Address 1381 Value Name: CAL-ADDRESS 1383 Purpose: This value type is used to identify properties that contain 1384 a calendar user address. 1386 Format Definition: This value type is defined by the following 1387 notation: 1389 cal-address = uri 1391 Description: The value is a URI as defined by [RFC3986] or any other 1392 IANA registered form for a URI. When used to address an Internet 1393 email transport address for a calendar user, the value MUST be a 1394 mailto URI, as defined by [RFC2368]. No additional content value 1395 encoding (i.e., BACKSLASH character encoding, see Section 3.3.11) 1396 is defined for this value type. 1398 Example: 1400 mailto:jane_doe@example.com 1402 3.3.4. Date 1404 Value Name: DATE 1406 Purpose: This value type is used to identify values that contain a 1407 calendar date. 1409 Format Definition: This value type is defined by the following 1410 notation: 1412 date = date-value 1414 date-value = date-fullyear date-month date-mday 1415 date-fullyear = 4DIGIT 1416 date-month = 2DIGIT ;01-12 1417 date-mday = 2DIGIT ;01-28, 01-29, 01-30, 01-31 1418 ;based on month/year 1420 Description: If the property permits, multiple "date" values are 1421 specified as a COMMA character (US-ASCII decimal 44) separated 1422 list of values. The format for the value type is based on the 1423 [ISO.8601.2004] complete representation, basic format for a 1424 calendar date. The textual format specifies a four-digit year, 1425 two-digit month, and two-digit day of the month. There are no 1426 separator characters between the year, month and day component 1427 text. 1429 No additional content value encoding (i.e., BACKSLASH character 1430 encoding, see Section 3.3.11) is defined for this value type. 1432 Example: The following represents July 14, 1997: 1434 19970714 1436 3.3.5. Date-Time 1438 Value Name: DATE-TIME 1440 Purpose: This value type is used to identify values that specify a 1441 precise calendar date and time of day. 1443 Format Definition: This value type is defined by the following 1444 notation: 1446 date-time = date "T" time ;As specified in the date and time 1447 ;value definitions 1449 Description: If the property permits, multiple "date-time" values 1450 are specified as a COMMA character (US-ASCII decimal 44) separated 1451 list of values. No additional content value encoding (i.e., 1452 BACKSLASH character encoding, see Section 3.3.11) is defined for 1453 this value type. 1455 The "DATE-TIME" value type is used to identify values that contain 1456 a precise calendar date and time of day. The format is based on 1457 the [ISO.8601.2004] complete representation, basic format for a 1458 calendar date and time of day. The text format is a concatenation 1459 of the "date", followed by the LATIN CAPITAL LETTER T character 1460 (US-ASCII decimal 84) time designator, followed by the "time" 1461 format. 1463 The "DATE-TIME" value type expresses time values in three forms: 1465 The form of date and time with UTC offset MUST NOT be used. For 1466 example, the following is not valid for a date-time value: 1468 19980119T230000-0800 ;Invalid time format 1470 FORM #1: DATE WITH LOCAL TIME 1472 The date with local time form is simply a date-time value that 1473 does not contain the UTC designator nor does it reference a time 1474 zone. For example, the following represents January 18, 1998, at 1475 11 PM: 1477 19980118T230000 1479 Date-time values of this type are said to be "floating" and are 1480 not bound to any time zone in particular. They are used to 1481 represent the same hour, minute, and second value regardless of 1482 which time zone is currently being observed. For example, an 1483 event can be defined that indicates that an individual will be 1484 busy from 11:00 AM to 1:00 PM every day, no matter which time zone 1485 the person is in. In these cases, a local time can be specified. 1486 The recipient of an iCalendar object with a property value 1487 consisting of a local time, without any relative time zone 1488 information, SHOULD interpret the value as being fixed to whatever 1489 time zone the "ATTENDEE" is in at any given moment. This means 1490 that two "Attendees", in different time zones, receiving the same 1491 event definition as a floating time, may be participating in the 1492 event at different actual times. Floating time SHOULD only be 1493 used where that is the reasonable behavior. 1495 In most cases, a fixed time is desired. To properly communicate a 1496 fixed time in a property value, either UTC time or local time with 1497 time zone reference MUST be specified. 1499 The use of local time in a DATE-TIME value without the "TZID" 1500 property parameter is to be interpreted as floating time, 1501 regardless of the existence of "VTIMEZONE" calendar components in 1502 the iCalendar object. 1504 FORM #2: DATE WITH UTC TIME 1506 The date with UTC time, or absolute time, is identified by a LATIN 1507 CAPITAL LETTER Z suffix character (US-ASCII decimal 90), the UTC 1508 designator, appended to the time value. For example, the 1509 following represents January 19, 1998, at 0700 UTC: 1511 19980119T070000Z 1513 The "TZID" property parameter MUST NOT be applied to DATE-TIME 1514 properties whose time values are specified in UTC. 1516 FORM #3: DATE WITH LOCAL TIME AND TIME ZONE REFERENCE 1518 The date and local time with reference to time zone information is 1519 identified by the use the "TZID" property parameter to reference 1520 the appropriate time zone definition. "TZID" is discussed in 1521 detail in Section 3.2.19. For example, the following represents 1522 2:00 A.M. in New York on Janurary 19, 1998: 1524 TZID=America/New_York:19980119T020000 1526 If, based on the definition of the referenced time zone, the local 1527 time described occurs more than once (when changing from daylight 1528 to standard time), the DATE-TIME value refers to the first 1529 occurence of the referenced time. Thus, TZID=America/ 1530 New_York:20071104T013000 indicates November 4, 2007 at 1:30 A.M. 1531 EDT (UTC-04:00). If the local time described does not occur (when 1532 changing from standard to daylight time), the DATE-TIME value is 1533 interpreted using the UTC offset before the gap in local times. 1534 Thus, TZID=America/New_York:20070311T023000 indicates March 11, 1535 2007 at 3:30 A.M. EDT (UTC-04:00), one hour after 1:30 A.M. EST 1536 (UTC-05:00). 1538 A time value MUST only specify the second 60 when specifying a 1539 positive leap second. For example: 1541 19970630T235960Z 1543 Implementations which do not support leap seconds SHOULD interpret 1544 the second 60 as equivalent to the second 59. 1546 Example: The following represents July 14, 1997, at 1:30 PM in New 1547 York City in each of the three time formats, using the "DTSTART" 1548 property. 1550 DTSTART:19970714T133000 ; Local time 1551 DTSTART:19970714T173000Z ; UTC time 1552 DTSTART;TZID=America/New_York:19970714T133000 1553 ; Local time and time 1554 ; zone reference 1556 3.3.6. Duration 1558 Value Name: DURATION 1560 Purpose: This value type is used to identify properties that contain 1561 a duration of time. 1563 Format Definition: This value type is defined by the following 1564 notation: 1566 dur-value = (["+"] / "-") "P" (dur-date / dur-time / dur-week) 1568 dur-date = dur-day [dur-time] 1569 dur-time = "T" (dur-hour / dur-minute / dur-second) 1570 dur-week = 1*DIGIT "W" 1571 dur-hour = 1*DIGIT "H" [dur-minute] 1572 dur-minute = 1*DIGIT "M" [dur-second] 1573 dur-second = 1*DIGIT "S" 1574 dur-day = 1*DIGIT "D" 1576 Description: If the property permits, multiple "duration" values are 1577 specified by a COMMA character (US-ASCII decimal 44) separated 1578 list of values. The format is based on the [ISO.8601.2004] 1579 complete representation basic format with designators for the 1580 duration of time. The format can represent nominal durations 1581 (weeks and days) and accurate durations (hours, minutes, and 1582 seconds). Note that unlike [ISO.8601.2004] this value type 1583 doesn't support the "Y" and "M" designators to specify durations 1584 in terms of years and months. 1586 The duration of a week or a day depends on its position in the 1587 calendar. In the case of discontinuities in the time scale, such 1588 as the change from standard time to daylight time and back, the 1589 computation of the exact duration requires the substraction or 1590 addition of the change of duration of the discontinuity. Leap 1591 seconds MUST NOT be considered when computing an exact duration. 1592 When computing an exact duration, the greatest order time 1593 components MUST be added first, that is, the number of weeks MUST 1594 be added first, followed by the number of days, number of hours, 1595 number of minutes, and number of seconds. 1597 Negative durations are typically used to schedule an alarm to 1598 trigger before an associated time (see Section 3.8.6.3). 1600 No additional content value encoding (i.e., BACKSLASH character 1601 encoding, see Section 3.3.11) are defined for this value type. 1603 Example: A duration of 15 days, 5 hours and 20 seconds would be: 1605 P15DT5H0M20S 1607 A duration of 7 weeks would be: 1609 P7W 1611 3.3.7. Float 1613 Value Name: FLOAT 1615 Purpose: This value type is used to identify properties that contain 1616 a real number value. 1618 Format Definition: This value type is defined by the following 1619 notation: 1621 float = (["+"] / "-") 1*DIGIT ["." 1*DIGIT] 1623 Description: If the property permits, multiple "float" values are 1624 specified by a COMMA character (US-ASCII decimal 44) separated 1625 list of values. 1627 No additional content value encoding (i.e., BACKSLASH character 1628 encoding, see Section 3.3.11) is defined for this value type. 1630 Example: 1632 1000000.0000001 1633 1.333 1634 -3.14 1636 3.3.8. Integer 1638 Value Name: INTEGER 1640 Purpose: This value type is used to identify properties that contain 1641 a signed integer value. 1643 Format Definition: This value type is defined by the following 1644 notation: 1646 integer = (["+"] / "-") 1*DIGIT 1648 Description: If the property permits, multiple "integer" values are 1649 specified by a COMMA character (US-ASCII decimal 44) separated 1650 list of values. The valid range for "integer" is -2147483648 to 1651 2147483647. If the sign is not specified, then the value is 1652 assumed to be positive. 1654 No additional content value encoding (i.e., BACKSLASH character 1655 encoding, see Section 3.3.11) is defined for this value type. 1657 Example: 1659 1234567890 1660 -1234567890 1661 +1234567890 1662 432109876 1664 3.3.9. Period of Time 1666 Value Name: PERIOD 1668 Purpose: This value type is used to identify values that contain a 1669 precise period of time. 1671 Format Definition: This value type is defined by the following 1672 notation: 1674 period = period-explicit / period-start 1676 period-explicit = date-time "/" date-time 1677 ; [ISO.8601.2004] complete representation basic format for a 1678 ; period of time consisting of a start and end. The start MUST 1679 ; be before the end. 1681 period-start = date-time "/" dur-value 1682 ; [ISO.8601.2004] complete representation basic format for a 1683 ; period of time consisting of a start and positive duration 1684 ; of time. 1686 Description: If the property permits, multiple "period" values are 1687 specified by a COMMA character (US-ASCII decimal 44) separated 1688 list of values. There are two forms of a period of time. First, 1689 a period of time is identified by its start and its end. This 1690 format is based on the [ISO.8601.2004] complete representation, 1691 basic format for "DATE-TIME" start of the period, followed by a 1692 SOLIDUS character (US-ASCII decimal 47), followed by the "DATE- 1693 TIME" of the end of the period. The start of the period MUST be 1694 before the end of the period. Second, a period of time can also 1695 be defined by a start and a positive duration of time. The format 1696 is based on the [ISO.8601.2004] complete representation, basic 1697 format for the "DATE-TIME" start of the period, followed by a 1698 SOLIDUS character (US-ASCII decimal 47), followed by the 1699 [ISO.8601.2004] basic format for "DURATION" of the period. 1701 Example: The period starting at 18:00:00 UTC, on January 1, 1997 and 1702 ending at 07:00:00 UTC on January 2, 1997 would be: 1704 19970101T180000Z/19970102T070000Z 1706 The period start at 18:00:00 on January 1, 1997 and lasting 5 1707 hours and 30 minutes would be: 1709 19970101T180000Z/PT5H30M 1711 No additional content value encoding (i.e., BACKSLASH character 1712 encoding, see Section 3.3.11) is defined for this value type. 1714 3.3.10. Recurrence Rule 1716 Value Name: RECUR 1718 Purpose: This value type is used to identify properties that contain 1719 a recurrence rule specification. 1721 Format Definition: This value type is defined by the following 1722 notation: 1724 recur = recur-rule-part *( ";" recur-rule-part ) 1725 ; 1726 ; The rule parts are not ordered in any 1727 ; particular sequence 1728 ; 1729 ; The FREQ rule part is REQUIRED, 1730 ; but MUST NOT occur more than once 1731 ; 1732 ; The UNTIL or COUNT rule parts are OPTIONAL, 1733 ; but they MUST NOT occur in the same 'recur' 1734 ; 1735 ; The other rule parts are OPTIONAL, 1736 ; but MUST NOT occur more than once 1738 recur-rule-part = ( "FREQ" "=" freq ) 1739 / ( "UNTIL" "=" enddate ) 1740 / ( "COUNT" "=" 1*DIGIT ) 1741 / ( "INTERVAL" "=" 1*DIGIT ) 1742 / ( "BYSECOND" "=" byseclist ) 1743 / ( "BYMINUTE" "=" byminlist ) 1744 / ( "BYHOUR" "=" byhrlist ) 1745 / ( "BYDAY" "=" bywdaylist ) 1746 / ( "BYMONTHDAY" "=" bymodaylist ) 1747 / ( "BYYEARDAY" "=" byyrdaylist ) 1748 / ( "BYWEEKNO" "=" bywknolist ) 1749 / ( "BYMONTH" "=" bymolist ) 1750 / ( "BYSETPOS" "=" bysplist ) 1751 / ( "WKST" "=" weekday ) 1753 freq = "SECONDLY" / "MINUTELY" / "HOURLY" / "DAILY" 1754 / "WEEKLY" / "MONTHLY" / "YEARLY" 1756 enddate = date / date-time ;A UTC value 1758 byseclist = ( seconds *("," seconds) ) 1760 seconds = 1*2DIGIT ;0 to 60 1762 byminlist = ( minutes *("," minutes) ) 1764 minutes = 1*2DIGIT ;0 to 59 1766 byhrlist = ( hour *("," hour) ) 1768 hour = 1*2DIGIT ;0 to 23 1770 bywdaylist = ( weekdaynum *("," weekdaynum) ) 1772 weekdaynum = [[plus / minus] ordwk] weekday 1774 plus = "+" 1776 minus = "-" 1778 ordwk = 1*2DIGIT ;1 to 53 1780 weekday = "SU" / "MO" / "TU" / "WE" / "TH" / "FR" / "SA" 1781 ;Corresponding to SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, 1782 ;FRIDAY, and SATURDAY days of the week. 1784 bymodaylist = ( monthdaynum *("," monthdaynum) ) 1786 monthdaynum = [plus / minus] ordmoday 1788 ordmoday = 1*2DIGIT ;1 to 31 1790 byyrdaylist = ( yeardaynum *("," yeardaynum) ) 1791 yeardaynum = [plus / minus] ordyrday 1793 ordyrday = 1*3DIGIT ;1 to 366 1795 bywknolist = ( weeknum *("," weeknum) ) 1797 weeknum = [plus / minus] ordwk 1799 bymolist = ( monthnum *("," monthnum) ) 1801 monthnum = 1*2DIGIT ;1 to 12 1803 bysplist = ( setposday *("," setposday) ) 1805 setposday = yeardaynum 1807 Description: This value type is a structured value consisting of a 1808 list of one or more recurrence grammar parts. Each rule part is 1809 defined by a NAME=VALUE pair. The rule parts are separated from 1810 each other by the SEMICOLON character (US-ASCII decimal 59). The 1811 rule parts are not ordered in any particular sequence. Individual 1812 rule parts MUST only be specified once. 1814 Note: Compliant applications MUST accept rule parts ordered in 1815 any sequence, but to ensure backward compatibility with 1816 applications that pre-date this revision of iCalendar the FREQ 1817 rule part MUST be the first rule part specified in a RECUR 1818 value. 1820 The FREQ rule part identifies the type of recurrence rule. This 1821 rule part MUST be specified in the recurrence rule. Valid values 1822 include SECONDLY, to specify repeating events based on an interval 1823 of a second or more; MINUTELY, to specify repeating events based 1824 on an interval of a minute or more; HOURLY, to specify repeating 1825 events based on an interval of an hour or more; DAILY, to specify 1826 repeating events based on an interval of a day or more; WEEKLY, to 1827 specify repeating events based on an interval of a week or more; 1828 MONTHLY, to specify repeating events based on an interval of a 1829 month or more; and YEARLY, to specify repeating events based on an 1830 interval of a year or more. 1832 The INTERVAL rule part contains a positive integer representing 1833 how often the recurrence rule repeats. The default value is "1", 1834 meaning every second for a SECONDLY rule, or every minute for a 1835 MINUTELY rule, every hour for an HOURLY rule, every day for a 1836 DAILY rule, every week for a WEEKLY rule, every month for a 1837 MONTHLY rule and every year for a YEARLY rule. 1839 The UNTIL rule part defines a DATE or DATE-TIME value which bounds 1840 the recurrence rule in an inclusive manner. If the value 1841 specified by UNTIL is synchronized with the specified recurrence, 1842 this DATE or DATE-TIME becomes the last instance of the 1843 recurrence. The value of the UNTIL rule part MUST have the same 1844 value type as the "DTSTART" property. Furthermore, if the 1845 "DTSTART" property is specified as a date with local time, then 1846 the UNTIL rule part MUST also be specified as a date with local 1847 time. If the "DTSTART" property is specified as a date with UTC 1848 time or a date with local time and time zone reference, then the 1849 UNTIL rule part MUST be specified as a date with UTC time. In the 1850 case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL 1851 rule part MUST always be specified as a date with UTC time. If 1852 specified as a DATE-TIME value, then it MUST be specified in a UTC 1853 time format. If not present, and the COUNT rule part is also not 1854 present, the "RRULE" is considered to repeat forever. 1856 The COUNT rule part defines the number of occurrences at which to 1857 range-bound the recurrence. The "DTSTART" property value always 1858 counts as the first occurrence. 1860 The BYSECOND rule part specifies a COMMA character (US-ASCII 1861 decimal 44) separated list of seconds within a minute. Valid 1862 values are 0 to 60. The BYMINUTE rule part specifies a COMMA 1863 character (US-ASCII decimal 44) separated list of minutes within 1864 an hour. Valid values are 0 to 59. The BYHOUR rule part 1865 specifies a COMMA character (US-ASCII decimal 44) separated list 1866 of hours of the day. Valid values are 0 to 23. The BYSECOND, 1867 BYMINUTE and BYHOUR rule parts MUST NOT be specified when the 1868 associated "DTSTART" property has a DATE value type. These rule 1869 parts MUST be ignored in RECUR value that violate the above 1870 requirement (e.g., generated by applications that pre-date this 1871 revision of iCalendar). 1873 The BYDAY rule part specifies a COMMA character (US-ASCII decimal 1874 44) separated list of days of the week; SU indicates Sunday; MO 1875 indicates Monday; TU indicates Tuesday; WE indicates Wednesday; TH 1876 indicates Thursday; FR indicates Friday; SA indicates Saturday. 1878 Each BYDAY value can also be preceded by a positive (+n) or 1879 negative (-n) integer. If present, this indicates the nth 1880 occurrence of a specific day within the MONTHLY or YEARLY "RRULE". 1881 For example, within a MONTHLY rule, +1MO (or simply 1MO) 1882 represents the first Monday within the month, whereas -1MO 1883 represents the last Monday of the month. The numeric value in a 1884 BYDAY rule part with the FREQ rule part set to YEARLY corresponds 1885 to an offset within the month when the BYMONTH rule part is 1886 present, and corresponds to an offset within the year when the 1887 BYWEEKNO or BYMONTH rule parts are present. If an integer 1888 modifier is not present, it means all days of this type within the 1889 specified frequency. For example, within a MONTHLY rule, MO 1890 represents all Mondays within the month. The BYDAY rule part MUST 1891 NOT be specified with a numeric value when the FREQ rule part is 1892 not set to MONTHLY or YEARLY. Furthermore, the BYDAY rule part 1893 MUST NOT be specified with a numeric value with the FREQ rule part 1894 set to YEARLY when the BYWEEKNO rule part is specified. 1896 The BYMONTHDAY rule part specifies a COMMA character (US-ASCII 1897 decimal 44) separated list of days of the month. Valid values are 1898 1 to 31 or -31 to -1. For example, -10 represents the tenth to 1899 the last day of the month. The BYMONTHDAY rule part MUST NOT be 1900 specified when the FREQ rule part is set to WEEKLY. 1902 The BYYEARDAY rule part specifies a COMMA character (US-ASCII 1903 decimal 44) separated list of days of the year. Valid values are 1904 1 to 366 or -366 to -1. For example, -1 represents the last day 1905 of the year (December 31st) and -306 represents the 306th to the 1906 last day of the year (March 1st). The BYYEARDAY rule part MUST 1907 NOT be specified when the FREQ rule part is set to DAILY, WEEKLY, 1908 or MONTHLY. 1910 The BYWEEKNO rule part specifies a COMMA character (US-ASCII 1911 decimal 44) separated list of ordinals specifying weeks of the 1912 year. Valid values are 1 to 53 or -53 to -1. This corresponds to 1913 weeks according to week numbering as defined in [ISO.8601.2004]. 1914 A week is defined as a seven day period, starting on the day of 1915 the week defined to be the week start (see WKST). Week number one 1916 of the calendar year is the first week which contains at least 1917 four (4) days in that calendar year. This rule part MUST NOT be 1918 used when the FREQ rule part is set to anything other than YEARLY. 1919 For example, 3 represents the third week of the year. 1921 Note: Assuming a Monday week start, week 53 can only occur when 1922 Thursday is January 1 or if it is a leap year and Wednesday is 1923 January 1. 1925 The BYMONTH rule part specifies a COMMA character (US-ASCII 1926 decimal 44) separated list of months of the year. Valid values 1927 are 1 to 12. 1929 The WKST rule part specifies the day on which the workweek starts. 1930 Valid values are MO, TU, WE, TH, FR, SA and SU. This is 1931 significant when a WEEKLY "RRULE" has an interval greater than 1, 1932 and a BYDAY rule part is specified. This is also significant when 1933 in a YEARLY "RRULE" when a BYWEEKNO rule part is specified. The 1934 default value is MO. 1936 The BYSETPOS rule part specifies a COMMA character (US-ASCII 1937 decimal 44) separated list of values which corresponds to the nth 1938 occurrence within the set of recurrence instances specified by the 1939 rule. BYSETPOS operates on a set of recurrence instances in one 1940 interval of the recurrence rule. For example, in a WEEKLY rule, 1941 the interval would be one week A set of recurrence instances 1942 starts at the beginning of the interval defined by the FREQ rule 1943 part. Valid values are 1 to 366 or -366 to -1. It MUST only be 1944 used in conjunction with another BYxxx rule part. For example 1945 "the last work day of the month" could be represented as: 1947 FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1 1949 Each BYSETPOS value can include a positive (+n) or negative (-n) 1950 integer. If present, this indicates the nth occurrence of the 1951 specific occurrence within the set of occurences specified by the 1952 rule. 1954 Recurrence rules may generate recurrence instances with invalid 1955 date (e.g., February 30) or nonexistent local time (e.g., 1:30 AM 1956 on a day where the local time is moved forward by an hour at 1:00 1957 AM). Such recurrence instances MUST be ignored and MUST NOT be 1958 counted as part of the recurrence set. 1960 Information, not contained in the rule, necessary to determine the 1961 various recurrence instance start time and dates are derived from 1962 the Start Time ("DTSTART") component attribute. For example, 1963 "FREQ=YEARLY;BYMONTH=1" doesn't specify a specific day within the 1964 month or a time. This information would be the same as what is 1965 specified for "DTSTART". 1967 BYxxx rule parts modify the recurrence in some manner. BYxxx rule 1968 parts for a period of time which is the same or greater than the 1969 frequency generally reduce or limit the number of occurrences of 1970 the recurrence generated. For example, "FREQ=DAILY;BYMONTH=1" 1971 reduces the number of recurrence instances from all days (if 1972 BYMONTH rule part is not present) to all days in January. BYxxx 1973 rule parts for a period of time less than the frequency generally 1974 increase or expand the number of occurrences of the recurrence. 1975 For example, "FREQ=YEARLY;BYMONTH=1,2" increases the number of 1976 days within the yearly recurrence set from 1 (if BYMONTH rule part 1977 is not present) to 2. 1979 If multiple BYxxx rule parts are specified, then after evaluating 1980 the specified FREQ and INTERVAL rule parts, the BYxxx rule parts 1981 are applied to the current set of evaluated occurrences in the 1982 following order: BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY, BYDAY, 1983 BYHOUR, BYMINUTE, BYSECOND and BYSETPOS; then COUNT and UNTIL are 1984 evaluated. 1986 The table below summarizes the dependency of BYxxx rule part 1987 expand or limit behaviour on the FREQ rule part value. 1989 The term "N/A" means that the corresponding BYxxx rule part MUST 1990 NOT be used with the corresponding FREQ value. 1992 BYDAY has some special behaviour depending on the FREQ value and 1993 this is described in separate notes below the table. 1995 +----------+--------+--------+-------+-------+------+-------+------+ 1996 | |SECONDLY|MINUTELY|HOURLY |DAILY |WEEKLY|MONTHLY|YEARLY| 1997 +----------+--------+--------+-------+-------+------+-------+------+ 1998 |BYMONTH |Limit |Limit |Limit |Limit |Limit |Limit |Expand| 1999 +----------+--------+--------+-------+-------+------+-------+------+ 2000 |BYWEEKNO |N/A |N/A |N/A |N/A |N/A |N/A |Expand| 2001 +----------+--------+--------+-------+-------+------+-------+------+ 2002 |BYYEARDAY |Limit |Limit |Limit |N/A |N/A |N/A |Expand| 2003 +----------+--------+--------+-------+-------+------+-------+------+ 2004 |BYMONTHDAY|Limit |Limit |Limit |Limit |N/A |Expand |Expand| 2005 +----------+--------+--------+-------+-------+------+-------+------+ 2006 |BYDAY |Limit |Limit |Limit |Limit |Expand|Note 1 |Note 2| 2007 +----------+--------+--------+-------+-------+------+-------+------+ 2008 |BYHOUR |Limit |Limit |Limit |Expand |Expand|Expand |Expand| 2009 +----------+--------+--------+-------+-------+------+-------+------+ 2010 |BYMINUTE |Limit |Limit |Expand |Expand |Expand|Expand |Expand| 2011 +----------+--------+--------+-------+-------+------+-------+------+ 2012 |BYSECOND |Limit |Expand |Expand |Expand |Expand|Expand |Expand| 2013 +----------+--------+--------+-------+-------+------+-------+------+ 2014 |BYSETPOS |Limit |Limit |Limit |Limit |Limit |Limit |Limit | 2015 +----------+--------+--------+-------+-------+------+-------+------+ 2017 Note 1: Limit if BYMONTHDAY is present, otherwise special expand 2018 for MONTHLY. 2020 Note 2: Limit if BYYEARDAY or BYMONTHDAY is present, otherwise 2021 special expand for WEEKLY if BYWEEKNO present, otherwise 2022 special expand for MONTHLY if BYMONTH present, otherwise 2023 special expand for YEARLY. 2025 Here is an example of evaluating multiple BYxxx rule parts. 2027 DTSTART;TZID=America/New_York:19970105T083000 2028 RRULE:FREQ=YEARLY;INTERVAL=2;BYMONTH=1;BYDAY=SU;BYHOUR=8,9; 2029 BYMINUTE=30 2031 First, the "INTERVAL=2" would be applied to "FREQ=YEARLY" to 2032 arrive at "every other year". Then, "BYMONTH=1" would be applied 2033 to arrive at "every January, every other year". Then, "BYDAY=SU" 2034 would be applied to arrive at "every Sunday in January, every 2035 other year". Then, "BYHOUR=8,9" would be applied to arrive at 2036 "every Sunday in January at 8 AM and 9 AM, every other year". 2037 Then, "BYMINUTE=30" would be applied to arrive at "every Sunday in 2038 January at 8:30 AM and 9:30 AM, every other year". Then, lacking 2039 information from "RRULE", the second is derived from "DTSTART", to 2040 end up in "every Sunday in January at 8:30:00 AM and 9:30:00 AM, 2041 every other year". Similarly, if the BYMINUTE, BYHOUR, BYDAY, 2042 BYMONTHDAY or BYMONTH rule part were missing, the appropriate 2043 minute, hour, day or month would have been retrieved from the 2044 "DTSTART" property. 2046 If the computed local start time of a recurrence instance does not 2047 exist, or occurs more than once, for the specified time zone, the 2048 time of the recurrence instance is interpreted in the same manner 2049 as an explicit DATE-TIME value describing that date and time, as 2050 specified in Section 3.3.5. 2052 No additional content value encoding (i.e., BACKSLASH character 2053 encoding, see Section 3.3.11) is defined for this value type. 2055 Example: The following is a rule which specifies 10 occurences which 2056 occur every other day: 2058 FREQ=DAILY;COUNT=10;INTERVAL=2 2060 There are other examples specified in Section 3.8.5.3. 2062 3.3.11. Text 2064 Value Name: TEXT 2066 Purpose: This value type is used to identify values that contain 2067 human readable text. 2069 Format Definition: This value type is defined by the following 2070 notation. 2072 text = *(TSAFE-CHAR / ":" / DQUOTE / ESCAPED-CHAR) 2073 ; Folded according to description above 2075 ESCAPED-CHAR = ("\\" / "\;" / "\," / "\N" / "\n") 2076 ; \\ encodes \, \N or \n encodes newline 2077 ; \; encodes ;, \, encodes , 2079 TSAFE-CHAR = %x20-21 / %x23-2B / %x2D-39 / %x3C-5B / 2080 %x5D-7E / NON-US-ASCII 2081 ; Any character except CTLs not needed by the current 2082 ; character set, DQUOTE, ";", ":", "\", "," 2084 Description: If the property permits, multiple TEXT values are 2085 specified by a COMMA character (US-ASCII decimal 44) separated 2086 list of values. 2088 The language in which the text is represented can be controlled by 2089 the "LANGUAGE" property parameter. 2091 An intentional formatted text line break MUST only be included in 2092 a "TEXT" property value by representing the line break with the 2093 character sequence of BACKSLASH (US-ASCII decimal 92), followed by 2094 a LATIN SMALL LETTER N (US-ASCII decimal 110) or a LATIN CAPITAL 2095 LETTER N (US-ASCII decimal 78), that is "\n" or "\N". 2097 The "TEXT" property values may also contain special characters 2098 that are used to signify delimiters, such as a COMMA character for 2099 lists of values or a SEMICOLON character for structured values. 2100 In order to support the inclusion of these special characters in 2101 "TEXT" property values, they MUST be escaped with a BACKSLASH 2102 character. A BACKSLASH character (US-ASCII decimal 92) in a 2103 "TEXT" property value MUST be escaped with another BACKSLASH 2104 character. A COMMA character in a "TEXT" property value MUST be 2105 escaped with a BACKSLASH character (US-ASCII decimal 92). A 2106 SEMICOLON character in a "TEXT" property value MUST be escaped 2107 with a BACKSLASH character (US-ASCII decimal 92). However, a 2108 COLON character in a "TEXT" property value SHALL NOT be escaped 2109 with a BACKSLASH character. 2111 Example: A multiple line value of: 2113 Project XYZ Final Review 2114 Conference Room - 3B 2115 Come Prepared. 2117 would be represented as: 2119 Project XYZ Final Review\nConference Room - 3B\nCome Prepared. 2121 3.3.12. Time 2123 Value Name: TIME 2125 Purpose: This value type is used to identify values that contain a 2126 time of day. 2128 Format Definition: This value type is defined by the following 2129 notation: 2131 time = time-hour time-minute time-second [time-utc] 2133 time-hour = 2DIGIT ;00-23 2134 time-minute = 2DIGIT ;00-59 2135 time-second = 2DIGIT ;00-60 2136 ;The "60" value is used to account for positive "leap" seconds. 2138 time-utc = "Z" 2140 Description: If the property permits, multiple "time" values are 2141 specified by a COMMA character (US-ASCII decimal 44) separated 2142 list of values. No additional content value encoding (i.e., 2143 BACKSLASH character encoding, see Section 3.3.11) is defined for 2144 this value type. 2146 The "TIME" value type is used to identify values that contain a 2147 time of day. The format is based on the [ISO.8601.2004] complete 2148 representation, basic format for a time of day. The text format 2149 consists of a two-digit 24-hour of the day (i.e., values 00-23), 2150 two-digit minute in the hour (i.e., values 00-59), and two-digit 2151 seconds in the minute (i.e., values 00-60). The seconds value of 2152 60 MUST only be used to account for positive "leap" seconds. 2153 Fractions of a second are not supported by this format. 2155 In parallel to the "DATE-TIME" definition above, the "TIME" value 2156 type expresses time values in three forms: 2158 The form of time with UTC offset MUST NOT be used. For example, 2159 the following is not valid for a time value: 2161 230000-0800 ;Invalid time format 2163 FORM #1 LOCAL TIME 2165 The local time form is simply a time value that does not contain 2166 the UTC designator nor does it reference a time zone. For 2167 example, 11:00 PM: 2169 230000 2171 Time values of this type are said to be "floating" and are not 2172 bound to any time zone in particular. They are used to represent 2173 the same hour, minute, and second value regardless of which time 2174 zone is currently being observed. For example, an event can be 2175 defined that indicates that an individual will be busy from 11:00 2176 AM to 1:00 PM every day, no matter which time zone the person is 2177 in. In these cases, a local time can be specified. The recipient 2178 of an iCalendar object with a property value consisting of a local 2179 time, without any relative time zone information, SHOULD interpret 2180 the value as being fixed to whatever time zone the "ATTENDEE" is 2181 in at any given moment. This means that two "Attendees", may 2182 participate in the same event at different UTC times; floating 2183 time SHOULD only be used where that is reasonable behavior. 2185 In most cases, a fixed time is desired. To properly communicate a 2186 fixed time in a property value, either UTC time or local time with 2187 time zone reference MUST be specified. 2189 The use of local time in a TIME value without the "TZID" property 2190 parameter is to be interpreted as a local time value, regardless 2191 of the existence of "VTIMEZONE" calendar components in the 2192 iCalendar object. 2194 FORM #2: UTC TIME 2196 UTC time, or absolute time, is identified by a LATIN CAPITAL 2197 LETTER Z suffix character (US-ASCII decimal 90), the UTC 2198 designator, appended to the time value. For example, the 2199 following represents 07:00 AM UTC: 2201 070000Z 2203 The "TZID" property parameter MUST NOT be applied to TIME 2204 properties whose time values are specified in UTC. 2206 FORM #3: LOCAL TIME AND TIME ZONE REFERENCE 2208 The local time with reference to time zone information form is 2209 identified by the use the "TZID" property parameter to reference 2210 the appropriate time zone definition. "TZID" is discussed in 2211 detail in Section 3.2.19. 2213 Example: The following represents 8:30 AM in New York in Winter, 2214 five hours behind UTC, in each of the three formats: 2216 083000 2217 133000Z 2219 TZID=America/New_York:083000 2221 3.3.13. URI 2223 Value Name: URI 2225 Purpose: This value type is used to identify values that contain a 2226 uniform resource identifier (URI) type of reference to the 2227 property value. 2229 Format Definition: This value type is defined by the following 2230 notation: 2232 uri = 2234 Description: This value type might be used to reference binary 2235 information, for values that are large, or otherwise undesirable 2236 to include directly in the iCalendar object. 2238 Property values with this value type MUST follow the generic URI 2239 syntax defined in [RFC3986]. 2241 When a property parameter value is a URI value type, the URI MUST 2242 be specified as a quoted-string value. 2244 No additional content value encoding (i.e., BACKSLASH character 2245 encoding, see Section 3.3.11) is defined for this value type. 2247 Example: The following is a URI for a network file: 2249 http://example.com/my-report.txt 2251 3.3.14. UTC Offset 2253 Value Name: UTC-OFFSET 2255 Purpose: This value type is used to identify properties that contain 2256 an offset from UTC to local time. 2258 Format Definition: This value type is defined by the following 2259 notation: 2261 utc-offset = time-numzone 2263 time-numzone = ("+" / "-") time-hour time-minute [time-second] 2265 Description: The PLUS SIGN (US-ASCII decimal 43) character MUST be 2266 specified for positive UTC offsets (i.e., ahead of UTC). The 2267 HYPHEN-MINUS character (US-ASCII decimal 45) MUST be specified for 2268 negative UTC offsets (i.e., behind of UTC). The value of "-0000" 2269 and "-000000" are not allowed. The time-second, if present, MUST 2270 NOT be 60; if absent, it defaults to zero. 2272 No additional content value encoding (i.e., BACKSLASH character 2273 encoding, see Section 3.3.11) is defined for this value type. 2275 Example: The following UTC offsets are given for standard time for 2276 New York (five hours behind UTC) and Geneva (one hour ahead of 2277 UTC): 2279 -0500 2281 +0100 2283 3.4. iCalendar Object 2285 The Calendaring and Scheduling Core Object is a collection of 2286 calendaring and scheduling information. Typically, this information 2287 will consist of an iCalendar stream with a single iCalendar object. 2288 However, multiple iCalendar objects can be sequentially grouped 2289 together in an iCalendar stream. The first line and last line of the 2290 iCalendar object MUST contain a pair of iCalendar object delimiter 2291 strings. The syntax for an iCalendar stream is as follows: 2293 icalstream = 1*icalobject 2295 icalobject = "BEGIN" ":" "VCALENDAR" CRLF 2296 icalbody 2297 "END" ":" "VCALENDAR" CRLF 2299 The following is a simple example of an iCalendar object: 2301 BEGIN:VCALENDAR 2302 VERSION:2.0 2303 PRODID:-//hacksw/handcal//NONSGML v1.0//EN 2304 BEGIN:VEVENT 2305 UID:19970610T172345Z-AF23B2@example.com 2306 DTSTAMP:19970610T172345Z 2307 DTSTART:19970714T170000Z 2308 DTEND:19970715T040000Z 2309 SUMMARY:Bastille Day Party 2310 END:VEVENT 2311 END:VCALENDAR 2313 3.5. Property 2315 A property is the definition of an individual attribute describing a 2316 calendar object or a calendar component. A property takes the form 2317 defined by the "contentline" notation defined in Section 3.1. 2319 The following is an example of a property: 2321 DTSTART:19960415T133000Z 2323 This memo imposes no ordering of properties within an iCalendar 2324 object. 2326 Property names, parameter names and enumerated parameter values are 2327 case insensitive. For example, the property name "DUE" is the same 2328 as "due" and "Due", DTSTART;TZID=America/New_York:19980714T120000 is 2329 the same as DtStart;TzID=America/New_York:19980714T120000. 2331 3.6. Calendar Components 2333 The body of the iCalendar object consists of a sequence of calendar 2334 properties and one or more calendar components. The calendar 2335 properties are attributes that apply to the calendar object as a 2336 whole. The calendar components are collections of properties that 2337 express a particular calendar semantic. For example, the calendar 2338 component can specify an event, a to-do, a journal entry, time zone 2339 information, free/busy time information, or an alarm. 2341 The body of the iCalendar object is defined by the following 2342 notation: 2344 icalbody = calprops component 2346 calprops = *( 2348 ; the following are REQUIRED, 2349 ; but MUST NOT occur more than once 2351 prodid / version / 2353 ; the following are OPTIONAL, 2354 ; but MUST NOT occur more than once 2356 calscale / method / 2358 ; the following are OPTIONAL, 2359 ; and MAY occur more than once 2361 x-prop / iana-prop 2362 ) 2364 component = 1*(eventc / todoc / journalc / freebusyc / 2365 timezonec / iana-comp / x-comp) 2367 iana-comp = "BEGIN" ":" iana-token CRLF 2368 1*contentline 2369 "END" ":" iana-token CRLF 2371 x-comp = "BEGIN" ":" x-name CRLF 2372 1*contentline 2373 "END" ":" x-name CRLF 2375 An iCalendar object MUST include the "PRODID" and "VERSION" calendar 2376 properties. In addition, it MUST include at least one calendar 2377 component. Special forms of iCalendar objects are possible to 2378 publish just busy time (i.e., only a "VFREEBUSY" calendar component) 2379 or time zone (i.e., only a "VTIMEZONE" calendar component) 2380 information. In addition, a complex iCalendar object that is used to 2381 capture a complete snapshot of the contents of a calendar is possible 2382 (e.g., composite of many different calendar components). More 2383 commonly, an iCalendar object will consist of just a single "VEVENT", 2384 "VTODO" or "VJOURNAL" calendar component. Applications MUST ignore 2385 x-comp and iana-comp they don't recognized. 2387 3.6.1. Event Component 2388 Component Name: VEVENT 2390 Purpose: Provide a grouping of component properties that describe an 2391 event. 2393 Format Definition: A "VEVENT" calendar component is defined by the 2394 following notation: 2396 eventc = "BEGIN" ":" "VEVENT" CRLF 2397 eventprop *alarmc 2398 "END" ":" "VEVENT" CRLF 2400 eventprop = *( 2402 ; the following are REQUIRED, 2403 ; but MUST NOT occur more than once 2405 dtstamp / dtstart / uid / 2407 ; the following are OPTIONAL, 2408 ; but MUST NOT occur more than once 2410 class / created / description / geo / 2411 last-mod / location / organizer / priority / 2412 seq / status / summary / transp / 2413 url / recurid / 2415 ; the following is OPTIONAL, 2416 ; but SHOULD NOT occur more than once 2418 rrule / 2420 ; either 'dtend' or 'duration' MAY appear in 2421 ; a 'eventprop', but 'dtend' and 'duration' 2422 ; MUST NOT occur in the same 'eventprop' 2424 dtend / duration / 2426 ; the following are OPTIONAL, 2427 ; and MAY occur more than once 2429 attach / attendee / categories / comment / 2430 contact / exdate / rstatus / related / 2431 resources / rdate / x-prop / iana-prop 2433 ) 2435 Description: A "VEVENT" calendar component is a grouping of 2436 component properties, and possibly including "VALARM" calendar 2437 components, that represents a scheduled amount of time on a 2438 calendar. For example, it can be an activity; such as a one-hour 2439 long, department meeting from 8:00 AM to 9:00 AM, tomorrow. 2440 Generally, an event will take up time on an individual calendar. 2441 Hence, the event will appear as an opaque interval in a search for 2442 busy time. Alternately, the event can have its Time Transparency 2443 set to "TRANSPARENT" in order to prevent blocking of the event in 2444 searches for busy time. 2446 The "VEVENT" is also the calendar component used to specify an 2447 anniversary or daily reminder within a calendar. These events 2448 have a DATE value type for the "DTSTART" property instead of the 2449 default value type of DATE-TIME. If such a "VEVENT" has a "DTEND" 2450 property, it MUST be specified as a DATE value also. The 2451 anniversary type of "VEVENT" can span more than one date (i.e., 2452 "DTEND" property value is set to a calendar date after the 2453 "DTSTART" property value). If such a "VEVENT" has a "DURATION" 2454 property, it MUST be specified as a "dur-day" or "dur-week" value. 2456 The "DTSTART" property for a "VEVENT" specifies the inclusive 2457 start of the event. For recurring events, it also specifies the 2458 very first instance in the recurrence set. The "DTEND" property 2459 for a "VEVENT" calendar component specifies the non-inclusive end 2460 of the event. For cases where a "VEVENT" calendar component 2461 specifies a "DTSTART" property with a DATE value type but no 2462 "DTEND" nor DURATION property, the event's duration is taken to be 2463 one day. For cases where a "VEVENT" calendar component specifies 2464 a "DTSTART" property with a DATE-TIME value type but no "DTEND" 2465 property, the event ends on the same calendar date and time of day 2466 specified by the "DTSTART" property. 2468 The "VEVENT" calendar component cannot be nested within another 2469 calendar component. However, "VEVENT" calendar components can be 2470 related to each other or to a "VTODO" or to a "VJOURNAL" calendar 2471 component with the "RELATED-TO" property. 2473 Example: The following is an example of the "VEVENT" calendar 2474 component used to represent a meeting that will also be opaque to 2475 searches for busy time: 2477 BEGIN:VEVENT 2478 UID:19970901T130000Z-123401@example.com 2479 DTSTAMP:19970901T130000Z 2480 DTSTART:19970903T163000Z 2481 DTEND:19970903T190000Z 2482 SUMMARY:Annual Employee Review 2483 CLASS:PRIVATE 2484 CATEGORIES:BUSINESS,HUMAN RESOURCES 2485 END:VEVENT 2487 The following is an example of the "VEVENT" calendar component 2488 used to represent a reminder that will not be opaque, but rather 2489 transparent, to searches for busy time: 2491 BEGIN:VEVENT 2492 UID:19970901T130000Z-123402@example.com 2493 DTSTAMP:19970901T130000Z 2494 DTSTART:19970401T163000Z 2495 DTEND:19970402T010000Z 2496 SUMMARY:Laurel is in sensitivity awareness class. 2497 CLASS:PUBLIC 2498 CATEGORIES:BUSINESS,HUMAN RESOURCES 2499 TRANSP:TRANSPARENT 2500 END:VEVENT 2502 The following is an example of the "VEVENT" calendar component 2503 used to represent an anniversary that will occur annually. 2505 BEGIN:VEVENT 2506 UID:19970901T130000Z-123403@example.com 2507 DTSTAMP:19970901T130000Z 2508 DTSTART;VALUE=DATE:19971102 2509 SUMMARY:Our Blissful Anniversary 2510 TRANSP:TRANSPARENT 2511 CLASS:CONFIDENTIAL 2512 CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION 2513 RRULE:FREQ=YEARLY 2514 END:VEVENT 2516 The following is an example of the "VEVENT" calendar component 2517 used to represent a multi-day event scheduled from June 28th, 2007 2518 to July 8th, 2007 inclusively. Note that the "DTEND" property is 2519 set to July 9th, 2007, since the "DTEND" property specifies the 2520 non-inclusive end of the event. 2522 BEGIN:VEVENT 2523 UID:20070423T123432Z-541111@example.com 2524 DTSTAMP:20070423T123432Z 2525 DTSTART;VALUE=DATE:20070628 2526 DTEND;VALUE=DATE:20070709 2527 SUMMARY:Festival International de Jazz de Montreal 2528 TRANSP:TRANSPARENT 2529 END:VEVENT 2531 3.6.2. To-do Component 2533 Component Name: VTODO 2535 Purpose: Provide a grouping of calendar properties that describe a 2536 to-do. 2538 Format Definition: A "VTODO" calendar component is defined by the 2539 following notation: 2541 todoc = "BEGIN" ":" "VTODO" CRLF 2542 todoprop *alarmc 2543 "END" ":" "VTODO" CRLF 2545 todoprop = *( 2547 ; the following are REQUIRED, 2548 ; but MUST NOT occur more than once 2550 dtstamp / uid / 2552 ; the following are OPTIONAL, 2553 ; but MUST NOT occur more than once 2555 class / completed / created / description / 2556 dtstart / geo / last-mod / location / organizer / 2557 percent / priority / recurid / seq / status / 2558 summary / url / 2560 ; the following is OPTIONAL, 2561 ; but SHOULD NOT occur more than once 2563 rrule / 2565 ; either 'due' or 'duration' MAY appear in 2566 ; a 'todoprop', but 'due' and 'duration' 2567 ; MUST NOT occur in the same 'todoprop'. 2568 ; If 'duration' appear in a 'todoprop', 2569 ; then 'dtstart' MUST also appear in 2570 ; the same 'todoprop'. 2572 due / duration / 2574 ; the following are OPTIONAL, 2575 ; and MAY occur more than once 2577 attach / attendee / categories / comment / contact / 2578 exdate / rstatus / related / resources / 2579 rdate / x-prop / iana-prop 2581 ) 2583 Description: A "VTODO" calendar component is a grouping of component 2584 properties and possibly "VALARM" calendar components that 2585 represent an action-item or assignment. For example, it can be 2586 used to represent an item of work assigned to an individual; such 2587 as "turn in travel expense today". 2589 The "VTODO" calendar component cannot be nested within another 2590 calendar component. However, "VTODO" calendar components can be 2591 related to each other or to a "VEVENT" or to a "VJOURNAL" calendar 2592 component with the "RELATED-TO" property. 2594 A "VTODO" calendar component without the "DTSTART" and "DUE" (or 2595 "DURATION") properties specifies a to-do that will be associated 2596 with each successive calendar date, until it is completed. 2598 Examples: The following is an example of a "VTODO" calendar 2599 component that needs to be completed before May 1st, 2007. On 2600 midnight May 1st, 2007 this to-do would be considered overdue. 2602 BEGIN:VTODO 2603 UID:20070313T123432Z-456553@example.com 2604 DTSTAMP:20070313T123432Z 2605 DUE;VALUE=DATE:20070501 2606 SUMMARY:Submit Quebec Income Tax Return for 2006 2607 CLASS:CONFIDENTIAL 2608 CATEGORIES:FAMILY,FINANCE 2609 STATUS:NEEDS-ACTION 2610 END:VTODO 2612 The following is an example of a "VTODO" calendar component that 2613 was due before 1:00 P.M. UTC on July 9th, 2007 and was completed 2614 on July 7th, 2007 at 10:00 A.M. UTC. 2616 BEGIN:VTODO 2617 UID:20070514T103211Z-123404@example.com 2618 DTSTAMP:20070514T103211Z 2619 DTSTART:20070514T110000Z 2620 DUE:20070709T130000Z 2621 COMPLETED:20070707T100000Z 2622 SUMMARY:Submit Revised Internet-Draft 2623 PRIORITY:1 2624 STATUS:NEEDS-ACTION 2625 END:VTODO 2627 3.6.3. Journal Component 2629 Component Name: VJOURNAL 2631 Purpose: Provide a grouping of component properties that describe a 2632 journal entry. 2634 Format Definition: A "VJOURNAL" calendar component is defined by the 2635 following notation: 2637 journalc = "BEGIN" ":" "VJOURNAL" CRLF 2638 jourprop 2639 "END" ":" "VJOURNAL" CRLF 2641 jourprop = *( 2643 ; the following are REQUIRED, 2644 ; but MUST NOT occur more than once 2646 dtstamp / uid / 2648 ; the following are OPTIONAL, 2649 ; but MUST NOT occur more than once 2651 class / created / dtstart / 2652 last-mod / organizer / recurid / seq / 2653 status / summary / url / 2655 ; the following is OPTIONAL, 2656 ; but SHOULD NOT occur more than once 2658 rrule / 2660 ; the following are OPTIONAL, 2661 ; and MAY occur more than once 2663 attach / attendee / categories / comment / 2664 contact / description / exdate / related / rdate / 2665 rstatus / x-prop / iana-prop 2666 ) 2668 Description: A "VJOURNAL" calendar component is a grouping of 2669 component properties that represent one or more descriptive text 2670 notes associated with a particular calendar date. The "DTSTART" 2671 property is used to specify the calendar date that the journal 2672 entry is associated with. Generally, it will have a DATE value 2673 data type, but it can also be used to specify a DATE-TIME value 2674 data type. Examples of a journal entry include a daily record of 2675 a legislative body or a journal entry of individual telephone 2676 contacts for the day or an ordered list of accomplishments for the 2677 day. The "VJOURNAL" calendar component can also be used to 2678 associate a document with a calendar date. 2680 The "VJOURNAL" calendar component does not take up time on a 2681 calendar. Hence, it does not play a role in free or busy time 2682 searches -- it is as though it has a time transparency value of 2683 TRANSPARENT. It is transparent to any such searches. 2685 The "VJOURNAL" calendar component cannot be nested within another 2686 calendar component. However, "VJOURNAL" calendar components can 2687 be related to each other or to a "VEVENT" or to a "VTODO" calendar 2688 component, with the "RELATED-TO" property. 2690 Example: The following is an example of the "VJOURNAL" calendar 2691 component: 2693 BEGIN:VJOURNAL 2694 UID:19970901T130000Z-123405@example.com 2695 DTSTAMP:19970901T130000Z 2696 DTSTART;VALUE=DATE:19970317 2697 SUMMARY:Staff meeting minutes 2698 DESCRIPTION:1. Staff meeting: Participants include Joe\, Lisa 2699 and Bob. Aurora project plans were reviewed. There is currentl 2700 y no budget reserves for this project. Lisa will escalate to 2701 management. Next meeting on Tuesday.\n 2702 2. Telephone Conference: ABC Corp. sales representative called 2703 to discuss new printer. Promised to get us a demo by Friday.\n 2704 3. Henry Miller (Handsoff Insurance): Car was totaled by tree. 2705 Is looking into a loaner car. 555-2323 (tel). 2706 END:VJOURNAL 2708 3.6.4. Free/Busy Component 2710 Component Name: VFREEBUSY 2712 Purpose: Provide a grouping of component properties that describe 2713 either a request for free/busy time, describe a response to a 2714 request for free/busy time or describe a published set of busy 2715 time. 2717 Format Definition: A "VFREEBUSY" calendar component is defined by 2718 the following notation: 2720 freebusyc = "BEGIN" ":" "VFREEBUSY" CRLF 2721 fbprop 2722 "END" ":" "VFREEBUSY" CRLF 2724 fbprop = *( 2726 ; the following are REQUIRED, 2727 ; but MUST NOT occur more than once 2729 dtstamp / uid / 2731 ; the following are OPTIONAL, 2732 ; but MUST NOT occur more than once 2734 contact / dtstart / dtend / duration / 2735 organizer / url / 2737 ; the following are OPTIONAL, 2738 ; and MAY occur more than once 2740 attendee / comment / freebusy / rstatus / x-prop / 2741 iana-prop 2742 ) 2744 Description: A "VFREEBUSY" calendar component is a grouping of 2745 component properties that represents either a request for, a reply 2746 to a request for free or busy time information or a published set 2747 of busy time information. 2749 When used to request free/busy time information, the "ATTENDEE" 2750 property specifies the calendar users whose free/busy time is 2751 being requested; the "ORGANIZER" property specifies the calendar 2752 user who is requesting the free/busy time; the "DTSTART" and 2753 "DTEND" properties specify the window of time for which the free/ 2754 busy time is being requested; the "UID" and "DTSTAMP" properties 2755 are specified to assist in proper sequencing of multiple free/busy 2756 time requests. 2758 When used to reply to a request for free/busy time, the "ATTENDEE" 2759 property specifies the calendar user responding to the free/busy 2760 time request; the "ORGANIZER" property specifies the calendar user 2761 that originally requested the free/busy time; the "FREEBUSY" 2762 property specifies the free/busy time information (if it exists); 2763 and the "UID" and "DTSTAMP" properties are specified to assist in 2764 proper sequencing of multiple free/busy time replies. 2766 When used to publish busy time, the "ORGANIZER" property specifies 2767 the calendar user associated with the published busy time; the 2768 "DTSTART" and "DTEND" properties specify an inclusive time window 2769 that surrounds the busy time information; the "FREEBUSY" property 2770 specifies the published busy time information; and the "DTSTAMP" 2771 property specifies the date/time that iCalendar object was 2772 created. 2774 The "VFREEBUSY" calendar component cannot be nested within another 2775 calendar component. Multiple "VFREEBUSY" calendar components can 2776 be specified within an iCalendar object. This permits the 2777 grouping of Free/Busy information into logical collections, such 2778 as monthly groups of busy time information. 2780 The "VFREEBUSY" calendar component is intended for use in 2781 iCalendar object methods involving requests for free time, 2782 requests for busy time, requests for both free and busy, and the 2783 associated replies. 2785 Free/Busy information is represented with the "FREEBUSY" property. 2786 This property provides a terse representation of time periods. 2787 One or more "FREEBUSY" properties can be specified in the 2788 "VFREEBUSY" calendar component. 2790 When present in a "VFREEBUSY" calendar component, the "DTSTART" 2791 and "DTEND" properties SHOULD be specified prior to any "FREEBUSY" 2792 properties. In a free time request, these properties can be used 2793 in combination with the "DURATION" property to represent a request 2794 for a duration of free time within a specified window of time. 2796 The recurrence properties ("RRULE", "RDATE", "EXDATE") are not 2797 permitted within a "VFREEBUSY" calendar component. Any recurring 2798 events are resolved into their individual busy time periods using 2799 the "FREEBUSY" property. 2801 Example: The following is an example of a "VFREEBUSY" calendar 2802 component used to request free or busy time information: 2804 BEGIN:VFREEBUSY 2805 UID:19970901T082949Z-FA43EF@example.com 2806 ORGANIZER:mailto:jane_doe@example.com 2807 ATTENDEE:mailto:john_public@example.com 2808 DTSTART:19971015T050000Z 2809 DTEND:19971016T050000Z 2810 DTSTAMP:19970901T083000Z 2811 END:VFREEBUSY 2813 The following is an example of a "VFREEBUSY" calendar component 2814 used to reply to the request with busy time information: 2816 BEGIN:VFREEBUSY 2817 UID:19970901T095957Z-76A912@example.com 2818 ORGANIZER:mailto:jane_doe@example.com 2819 ATTENDEE:mailto:john_public@example.com 2820 DTSTAMP:19970901T100000Z 2821 FREEBUSY:19971015T050000Z/PT8H30M, 2822 19971015T160000Z/PT5H30M,19971015T223000Z/PT6H30M 2823 URL:http://example.com/pub/busy/jpublic-01.ifb 2824 COMMENT:This iCalendar file contains busy time information for 2825 the next three months. 2826 END:VFREEBUSY 2828 The following is an example of a "VFREEBUSY" calendar component 2829 used to publish busy time information. 2831 BEGIN:VFREEBUSY 2832 UID:19970901T115957Z-76A912@example.com 2833 DTSTAMP:19970901T120000Z 2834 ORGANIZER:jsmith@example.com 2835 DTSTART:19980313T141711Z 2836 DTEND:19980410T141711Z 2837 FREEBUSY:19980314T233000Z/19980315T003000Z 2838 FREEBUSY:19980316T153000Z/19980316T163000Z 2839 FREEBUSY:19980318T030000Z/19980318T040000Z 2840 URL:http://www.example.com/calendar/busytime/jsmith.ifb 2841 END:VFREEBUSY 2843 3.6.5. Time Zone Component 2845 Component Name: VTIMEZONE 2847 Purpose: Provide a grouping of component properties that defines a 2848 time zone. 2850 Format Definition: A "VTIMEZONE" calendar component is defined by 2851 the following notation: 2853 timezonec = "BEGIN" ":" "VTIMEZONE" CRLF 2854 *( 2856 ; 'tzid' is REQUIRED, but MUST NOT occur more 2857 ; than once 2859 tzid / 2860 ; 'last-mod' and 'tzurl' are OPTIONAL, 2861 ; but MUST NOT occur more than once 2863 last-mod / tzurl / 2865 ; one of 'standardc' or 'daylightc' MUST occur 2866 ; and each MAY occur more than once. 2868 standardc / daylightc / 2870 ; the following are OPTIONAL, 2871 ; and MAY occur more than once 2873 x-prop / iana-prop 2875 ) 2877 "END" ":" "VTIMEZONE" CRLF 2879 standardc = "BEGIN" ":" "STANDARD" CRLF 2880 tzprop 2881 "END" ":" "STANDARD" CRLF 2883 daylightc = "BEGIN" ":" "DAYLIGHT" CRLF 2884 tzprop 2885 "END" ":" "DAYLIGHT" CRLF 2887 tzprop = *( 2889 ; the following are REQUIRED, 2890 ; but MUST NOT occur more than once 2892 dtstart / tzoffsetto / tzoffsetfrom / 2894 ; the following is OPTIONAL, 2895 ; but SHOULD NOT occur more than once 2897 rrule / 2899 ; the following are OPTIONAL, 2900 ; and MAY occur more than once 2902 comment / rdate / tzname / x-prop / iana-prop 2904 ) 2906 Description: A time zone is unambiguously defined by the set of time 2907 measurement rules determined by the governing body for a given 2908 geographic area. These rules describe at a minimum the base 2909 offset from UTC for the time zone, often referred to as the 2910 Standard Time offset. Many locations adjust their Standard Time 2911 forward or backward by one hour, in order to accommodate seasonal 2912 changes in number of daylight hours, often referred to as Daylight 2913 Saving Time. Some locations adjust their time by a fraction of an 2914 hour. Standard Time is also known as Winter Time. Daylight 2915 Saving Time is also known as Advanced Time, Summer Time, or Legal 2916 Time in certain countries. The following table shows the changes 2917 in time zone rules in effect for New York City starting from 1967. 2918 Each line represents a description or rule for a particular 2919 observance. 2921 Effective Observance Rule 2923 +-----------+--------------------------+--------+--------------+ 2924 | Date | (Date/Time) | Offset | Abbreviation | 2925 +-----------+--------------------------+--------+--------------+ 2926 | 1967-1973 | last Sun in Apr, 02:00 | -0400 | EDT | 2927 | 1967-2006 | last Sun in Oct, 02:00 | -0500 | EST | 2928 | 1974-1974 | Jan 6, 02:00 | -0400 | EDT | 2929 | 1975-1975 | Feb 23, 02:00 | -0400 | EDT | 2930 | 1976-1986 | last Sun in Apr, 02:00 | -0400 | EDT | 2931 | 1987-2006 | first Sun in Apr, 02:00 | -0400 | EDT | 2932 | 2007-* | second Sun in Mar, 02:00 | -0400 | EDT | 2933 | 2007-* | first Sun in Nov, 02:00 | -0500 | EST | 2934 +-----------+--------------------------+--------+--------------+ 2936 Note: The specification of a global time zone registry is not 2937 addressed by this document and is left for future study. 2938 However, implementers may find the TZ database [TZDB] a useful 2939 reference. It is an informal, public-domain collection of time 2940 zone information, which is currently being maintained by 2941 volunteer Internet participants, and is used in several 2942 operating systems. This database contains current and 2943 historical time zone information for a wide variety of 2944 locations around the globe; it provides a time zone identifier 2945 for every unique time zone rule set in actual use since 1970, 2946 with historical data going back to the introduction of standard 2947 time. 2949 Interoperability between two calendaring and scheduling 2950 applications, especially for recurring events, to-dos or journal 2951 entries, is dependent on the ability to capture and convey date 2952 and time information in an unambiguous format. The specification 2953 of current time zone information is integral to this behavior. 2955 If present, the "VTIMEZONE" calendar component defines the set of 2956 Standard Time and Daylight Saving Time observances (or rules) for 2957 a particular time zone for a given interval of time. The 2958 "VTIMEZONE" calendar component cannot be nested within other 2959 calendar components. Multiple "VTIMEZONE" calendar components can 2960 exist in an iCalendar object. In this situation, each "VTIMEZONE" 2961 MUST represent a unique time zone definition. This is necessary 2962 for some classes of events, such as airline flights, that start in 2963 one time zone and end in another. 2965 The "VTIMEZONE" calendar component MUST include the "TZID" 2966 property and at least one definition of a "STANDARD" or "DAYLIGHT" 2967 sub-component. The "STANDARD" or "DAYLIGHT" subcomponent MUST 2968 include the "DTSTART", "TZOFFSETFROM" and "TZOFFSETTO" properties. 2970 An individual "VTIMEZONE" calendar component MUST be specified for 2971 each unique "TZID" parameter value specified in the iCalendar 2972 object. In addition, a "VTIMEZONE" calendar component, referred 2973 to by a recurring calendar component, MUST provide valid time zone 2974 information for all recurrence instances. 2976 Each "VTIMEZONE" calendar component consists of a collection of 2977 one or more sub-components that describe the rule for a particular 2978 observance (either a Standard Time or a Daylight Saving Time 2979 observance). The "STANDARD" sub-component consists of a 2980 collection of properties that describe Standard Time. The 2981 "DAYLIGHT" sub-component consists of a collection of properties 2982 that describe Daylight Saving Time. In general this collection of 2983 properties consists of: 2985 * the first onset date-time for the observance; 2987 * the last onset date-time for the observance, if a last onset is 2988 known; 2990 * the offset to be applied for the observance; 2992 * a rule that describes the day and time when the observance 2993 takes effect; 2995 * an optional name for the observance. 2997 For a given time zone, there may be multiple unique definitions of 2998 the observances over a period of time. Each observance is 2999 described using either a "STANDARD" or "DAYLIGHT" sub-component. 3000 The collection of these sub-components is used to describe the 3001 time zone for a given period of time. The offset to apply at any 3002 given time is found by locating the observance that has the last 3003 onset date and time before the time in question, and using the 3004 offset value from that observance. 3006 The top-level properties in a "VTIMEZONE" calendar component are: 3008 The mandatory "TZID" property is a text value that uniquely 3009 identifies the "VTIMEZONE" calendar component within the scope of 3010 an iCalendar object. 3012 The optional "LAST-MODIFIED" property is a UTC value that 3013 specifies the date and time that this time zone definition was 3014 last updated. 3016 The optional "TZURL" property is a url value that points to a 3017 published "VTIMEZONE" definition. "TZURL" SHOULD refer to a 3018 resource that is accessible by anyone who might need to interpret 3019 the object. This SHOULD NOT normally be a "file" URL or other URL 3020 that is not widely-accessible. 3022 The collection of properties that are used to define the 3023 "STANDARD" and "DAYLIGHT" sub-components include: 3025 The mandatory "DTSTART" property gives the effective onset date 3026 and local time for the time zone sub-component definition. 3027 "DTSTART" in this usage MUST be specified as a local DATE-TIME 3028 value. 3030 The mandatory "TZOFFSETFROM" property gives the UTC offset which 3031 is in use when the onset of this time zone observance begins. 3032 "TZOFFSETFROM" is combined with "DTSTART" to define the effective 3033 onset for the time zone sub-component definition. For example, 3034 the following represents the time at which the observance of 3035 Standard Time took effect in Fall 1967 for New York City: 3037 DTSTART:19671029T020000 3039 TZOFFSETFROM:-0400 3041 The mandatory "TZOFFSETTO" property gives the UTC offset for the 3042 time zone sub-component (Standard Time or Daylight Saving Time) 3043 when this observance is in use. 3045 The optional "TZNAME" property is the customary name for the time 3046 zone. It may be specified multiple times, to allow for specifying 3047 multiple language variants of the time zone names. This could be 3048 used for displaying dates. 3050 The onset date-times for the observance defined by the time zone 3051 sub-component is defined by the "DTSTART", "RRULE", and "RDATE" 3052 properties. 3054 The "RRULE" property defines the recurrence rule for the onset of 3055 the observance defined by this time zone sub-component. Some 3056 specific requirements for the usage of "RRULE" for this purpose 3057 include: 3059 * If observance is known to have an effective end date, the 3060 "UNTIL" recurrence rule parameter MUST be used to specify the 3061 last valid onset of this observance (i.e., the UNTIL date-time 3062 will be equal to the last instance generated by the recurrence 3063 pattern). It MUST be specified in UTC time. 3065 * The "DTSTART" and the "TZOFFSETFROM" properties MUST be used 3066 when generating the onset date-time values (instances) from the 3067 "RRULE". 3069 Alternatively, the "RDATE" property can be used to define the 3070 onset of the observance by giving the individual onset date and 3071 times. "RDATE" in this usage MUST be specified as a local DATE- 3072 TIME value, relative to the UTC offset specified in the 3073 "TZOFFSETFROM" property. 3075 The optional "COMMENT" property is also allowed for descriptive 3076 explanatory text. 3078 Example: The following are examples of the "VTIMEZONE" calendar 3079 component: 3081 This is an example showing all the time zone rules for New York 3082 City since April 30, 1967 at 03:00:00 EDT. 3084 BEGIN:VTIMEZONE 3085 TZID:America/New_York 3086 LAST-MODIFIED:20050809T050000Z 3087 BEGIN:DAYLIGHT 3088 DTSTART:19670430T020000 3089 RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=-1SU;UNTIL=19730429T070000Z 3090 TZOFFSETFROM:-0500 3091 TZOFFSETTO:-0400 3092 TZNAME:EDT 3093 END:DAYLIGHT 3094 BEGIN:STANDARD 3095 DTSTART:19671029T020000 3096 RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU;UNTIL=20061029T060000Z 3097 TZOFFSETFROM:-0400 3098 TZOFFSETTO:-0500 3099 TZNAME:EST 3100 END:STANDARD 3101 BEGIN:DAYLIGHT 3102 DTSTART:19740106T020000 3103 RDATE:19750223T020000 3104 TZOFFSETFROM:-0500 3105 TZOFFSETTO:-0400 3106 TZNAME:EDT 3107 END:DAYLIGHT 3108 BEGIN:DAYLIGHT 3109 DTSTART:19760425T020000 3110 RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=-1SU;UNTIL=19860427T070000Z 3111 TZOFFSETFROM:-0500 3112 TZOFFSETTO:-0400 3113 TZNAME:EDT 3114 END:DAYLIGHT 3115 BEGIN:DAYLIGHT 3116 DTSTART:19870405T020000 3117 RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=1SU;UNTIL=20060402T070000Z 3118 TZOFFSETFROM:-0500 3119 TZOFFSETTO:-0400 3120 TZNAME:EDT 3121 END:DAYLIGHT 3122 BEGIN:DAYLIGHT 3123 DTSTART:20070311T020000 3124 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU 3125 TZOFFSETFROM:-0500 3126 TZOFFSETTO:-0400 3127 TZNAME:EDT 3128 END:DAYLIGHT 3129 BEGIN:STANDARD 3130 DTSTART:20071104T020000 3131 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU 3132 TZOFFSETFROM:-0400 3133 TZOFFSETTO:-0500 3134 TZNAME:EST 3135 END:STANDARD 3136 END:VTIMEZONE 3138 This is an example showing time zone information for New York City 3139 using "RDATE" property. Note that this is only suitable for a 3140 recurring event that starts on or later than March 11, 2007 at 03: 3141 00:00 EDT (i.e., the earliest effective transition date and time) 3142 and ends no later than March 9, 2008 at 01:59:59 EST (i.e., latest 3143 valid date and time for EST in this scenario). For example, this 3144 can be used for a recurring event that occurs every Friday, 8:00 3145 A.M.-9:00 A.M., starting June 1, 2007, ending December 31, 2007, 3147 BEGIN:VTIMEZONE 3148 TZID:America/New_York 3149 LAST-MODIFIED:20050809T050000Z 3150 BEGIN:STANDARD 3151 DTSTART:20071104T020000 3152 TZOFFSETFROM:-0400 3153 TZOFFSETTO:-0500 3154 TZNAME:EST 3155 END:STANDARD 3156 BEGIN:DAYLIGHT 3157 DTSTART:20070311T020000 3158 TZOFFSETFROM:-0500 3159 TZOFFSETTO:-0400 3160 TZNAME:EDT 3161 END:DAYLIGHT 3162 END:VTIMEZONE 3164 This is a simple example showing the current time zone rules for 3165 New York City using a "RRULE" recurrence pattern. Note that there 3166 is no effective end date to either of the Standard Time or 3167 Daylight Time rules. This information would be valid for a 3168 recurring event starting today and continuing indefinitely. 3170 BEGIN:VTIMEZONE 3171 TZID:America/New_York 3172 LAST-MODIFIED:20050809T050000Z 3174 TZURL:http://zones.example.com/tz/America-New_York.ics 3175 BEGIN:STANDARD 3176 DTSTART:20071104T020000 3177 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU 3178 TZOFFSETFROM:-0400 3179 TZOFFSETTO:-0500 3180 TZNAME:EST 3181 END:STANDARD 3182 BEGIN:DAYLIGHT 3183 DTSTART:20070311T020000 3184 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU 3185 TZOFFSETFROM:-0500 3186 TZOFFSETTO:-0400 3187 TZNAME:EDT 3188 END:DAYLIGHT 3189 END:VTIMEZONE 3191 This is an example showing a set of rules for a fictitious time 3192 zone where the Daylight Time rule has an effective end date (i.e., 3193 after that date, Daylight Time is no longer observed). 3195 BEGIN:VTIMEZONE 3196 TZID:Fictitious 3197 LAST-MODIFIED:19870101T000000Z 3198 BEGIN:STANDARD 3199 DTSTART:19671029T020000 3200 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 3201 TZOFFSETFROM:-0400 3202 TZOFFSETTO:-0500 3203 TZNAME:EST 3204 END:STANDARD 3205 BEGIN:DAYLIGHT 3206 DTSTART:19870405T020000 3207 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T070000Z 3208 TZOFFSETFROM:-0500 3209 TZOFFSETTO:-0400 3210 TZNAME:EDT 3211 END:DAYLIGHT 3212 END:VTIMEZONE 3214 This is an example showing a set of rules for a fictitious time 3215 zone where the first Daylight Time rule has an effective end date. 3216 There is a second Daylight Time rule that picks up where the other 3217 left off. 3219 BEGIN:VTIMEZONE 3220 TZID:Fictitious 3221 LAST-MODIFIED:19870101T000000Z 3222 BEGIN:STANDARD 3223 DTSTART:19671029T020000 3224 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 3225 TZOFFSETFROM:-0400 3226 TZOFFSETTO:-0500 3227 TZNAME:EST 3228 END:STANDARD 3229 BEGIN:DAYLIGHT 3230 DTSTART:19870405T020000 3231 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T070000Z 3232 TZOFFSETFROM:-0500 3233 TZOFFSETTO:-0400 3234 TZNAME:EDT 3235 END:DAYLIGHT 3236 BEGIN:DAYLIGHT 3237 DTSTART:19990424T020000 3238 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=4 3239 TZOFFSETFROM:-0500 3240 TZOFFSETTO:-0400 3241 TZNAME:EDT 3242 END:DAYLIGHT 3243 END:VTIMEZONE 3245 3.6.6. Alarm Component 3247 Component Name: VALARM 3249 Purpose: Provide a grouping of component properties that define an 3250 alarm. 3252 Format Definition: A "VALARM" calendar component is defined by the 3253 following notation: 3255 alarmc = "BEGIN" ":" "VALARM" CRLF 3256 (audioprop / dispprop / emailprop) 3257 "END" ":" "VALARM" CRLF 3259 audioprop = *( 3261 ; 'action' and 'trigger' are both REQUIRED, 3262 ; but MUST NOT occur more than once 3264 action / trigger / 3266 ; 'duration' and 'repeat' are both OPTIONAL, 3267 ; and MUST NOT occur more than once each, 3268 ; but if one occurs, so MUST the other 3270 duration / repeat / 3272 ; the following is OPTIONAL, 3273 ; but MUST NOT occur more than once 3275 attach / 3277 ; the following is OPTIONAL, 3278 ; and MAY occur more than once 3280 x-prop / iana-prop 3282 ) 3284 dispprop = *( 3286 ; the following are REQUIRED, 3287 ; but MUST NOT occur more than once 3289 action / description / trigger / 3291 ; 'duration' and 'repeat' are both OPTIONAL, 3292 ; and MUST NOT occur more than once each, 3293 ; but if one occurs, so MUST the other 3295 duration / repeat / 3297 ; the following is OPTIONAL, 3298 ; and MAY occur more than once 3300 x-prop / iana-prop 3302 ) 3304 emailprop = *( 3306 ; the following are all REQUIRED, 3307 ; but MUST NOT occur more than once 3309 action / description / trigger / summary / 3310 ; the following is REQUIRED, 3311 ; and MAY occur more than once 3313 attendee / 3315 ; 'duration' and 'repeat' are both OPTIONAL, 3316 ; and MUST NOT occur more than once each, 3317 ; but if one occurs, so MUST the other 3319 duration / repeat / 3321 ; the following are OPTIONAL, 3322 ; and MAY occur more than once 3324 attach / x-prop / iana-prop 3326 ) 3328 Description: A "VALARM" calendar component is a grouping of 3329 component properties that is a reminder or alarm for an event or a 3330 to-do. For example, it may be used to define a reminder for a 3331 pending event or an overdue to-do. 3333 The "VALARM" calendar component MUST include the "ACTION" and 3334 "TRIGGER" properties. The "ACTION" property further constrains 3335 the "VALARM" calendar component in the following ways: 3337 When the action is "AUDIO", the alarm can also include one and 3338 only one "ATTACH" property, which MUST point to a sound resource, 3339 which is rendered when the alarm is triggered. 3341 When the action is "DISPLAY", the alarm MUST also include a 3342 "DESCRIPTION" property, which contains the text to be displayed 3343 when the alarm is triggered. 3345 When the action is "EMAIL", the alarm MUST include a "DESCRIPTION" 3346 property, which contains the text to be used as the message body, 3347 a "SUMMARY" property, which contains the text to be used as the 3348 message subject, and one or more "ATTENDEE" properties, which 3349 contain the email address of attendees to receive the message. It 3350 can also include one or more "ATTACH" properties, which are 3351 intended to be sent as message attachments. When the alarm is 3352 triggered, the email message is sent. 3354 The "VALARM" calendar component MUST only appear within either a 3355 "VEVENT" or "VTODO" calendar component. "VALARM" calendar 3356 components cannot be nested. Multiple mutually independent 3357 "VALARM" calendar components can be specified for a single 3358 "VEVENT" or "VTODO" calendar component. 3360 The "TRIGGER" property specifies when the alarm will be triggered. 3361 The "TRIGGER" property specifies a duration prior to the start of 3362 an event or a to-do. The "TRIGGER" edge may be explicitly set to 3363 be relative to the "START" or "END" of the event or to-do with the 3364 "RELATED" parameter of the "TRIGGER" property. The "TRIGGER" 3365 property value type can alternatively be set to an absolute 3366 calendar date with UTC time. 3368 In an alarm set to trigger on the "START" of an event or to-do, 3369 the "DTSTART" property MUST be present in the associated event or 3370 to-do. In an alarm in a "VEVENT" calendar component set to 3371 trigger on the "END" of the event, either the "DTEND" property 3372 MUST be present, or the "DTSTART" and "DURATION" properties MUST 3373 both be present. In an alarm in a "VTODO" calendar component set 3374 to trigger on the "END" of the to-do, either the "DUE" property 3375 MUST be present, or the "DTSTART" and "DURATION" properties MUST 3376 both be present. 3378 The alarm can be defined such that it triggers repeatedly. A 3379 definition of an alarm with a repeating trigger MUST include both 3380 the "DURATION" and "REPEAT" properties. The "DURATION" property 3381 specifies the delay period, after which the alarm will repeat. 3382 The "REPEAT" property specifies the number of additional 3383 repetitions that the alarm will be triggered. This repetition 3384 count is in addition to the initial triggering of the alarm. Both 3385 of these properties MUST be present in order to specify a 3386 repeating alarm. If one of these two properties is absent, then 3387 the alarm will not repeat beyond the initial trigger. 3389 The "ACTION" property is used within the "VALARM" calendar 3390 component to specify the type of action invoked when the alarm is 3391 triggered. The "VALARM" properties provide enough information for 3392 a specific action to be invoked. It is typically the 3393 responsibility of a "Calendar User Agent" (CUA) to deliver the 3394 alarm in the specified fashion. An "ACTION" property value of 3395 AUDIO specifies an alarm that causes a sound to be played to alert 3396 the user; DISPLAY specifies an alarm that causes a text message to 3397 be displayed to the user; and EMAIL specifies an alarm that causes 3398 an electronic email message to be delivered to one or more email 3399 addresses. 3401 In an AUDIO alarm, if the optional "ATTACH" property is included, 3402 it MUST specify an audio sound resource. The intention is that 3403 the sound will be played as the alarm effect. If an "ATTACH" 3404 property is specified that does not refer to a sound resource, or 3405 if the specified sound resource cannot be rendered (because its 3406 format is unsupported, or because it cannot be retrieved), then 3407 the CUA or other entity responsible for playing the sound may 3408 choose a fallback action, such as playing a built-in default 3409 sound, or playing no sound at all. 3411 In a DISPLAY alarm, the intended alarm effect is for the text 3412 value of the "DESCRIPTION" property to be displayed to the user. 3414 In an EMAIL alarm, the intended alarm effect is for an email 3415 message to be composed and delivered to all the addresses 3416 specified by the "ATTENDEE" properties in the "VALARM" calendar 3417 component. The "DESCRIPTION" property of the "VALARM" calendar 3418 component MUST be used as the body text of the message, and the 3419 "SUMMARY" property MUST be used as the subject text. Any "ATTACH" 3420 properties in the "VALARM" calendar component SHOULD be sent as 3421 attachments to the message. 3423 Note: Implementations should carefully consider whether they 3424 accept alarm components from untrusted sources, e.g., when 3425 importing calendar objects from external sources. One 3426 reasonable policy is to always ignore alarm components that the 3427 calendar user has not set herself, or at least ask for 3428 confirmation in such a case. 3430 Example: The following example is for a "VALARM" calendar component 3431 that specifies an audio alarm that will sound at a precise time 3432 and repeat 4 more times at 15 minute intervals: 3434 BEGIN:VALARM 3435 TRIGGER;VALUE=DATE-TIME:19970317T133000Z 3436 REPEAT:4 3437 DURATION:PT15M 3438 ACTION:AUDIO 3439 ATTACH;FMTTYPE=audio/basic:ftp://example.com/pub/ 3440 sounds/bell-01.aud 3441 END:VALARM 3443 The following example is for a "VALARM" calendar component that 3444 specifies a display alarm that will trigger 30 minutes before the 3445 scheduled start of the event or of the to-do it is associated with 3446 and will repeat 2 more times at 15 minute intervals: 3448 BEGIN:VALARM 3449 TRIGGER:-PT30M 3450 REPEAT:2 3451 DURATION:PT15M 3452 ACTION:DISPLAY 3453 DESCRIPTION:Breakfast meeting with executive\n 3454 team at 8:30 AM EST. 3455 END:VALARM 3457 The following example is for a "VALARM" calendar component that 3458 specifies an email alarm that will trigger 2 days before the 3459 scheduled due date/time of a to-do it is associated with. It does 3460 not repeat. The email has a subject, body and attachment link. 3462 BEGIN:VALARM 3463 TRIGGER;RELATED=END:-P2D 3464 ACTION:EMAIL 3465 ATTENDEE:mailto:john_doe@example.com 3466 SUMMARY:*** REMINDER: SEND AGENDA FOR WEEKLY STAFF MEETING *** 3467 DESCRIPTION:A draft agenda needs to be sent out to the attendees 3468 to the weekly managers meeting (MGR-LIST). Attached is a 3469 pointer the document template for the agenda file. 3470 ATTACH;FMTTYPE=application/msword:http://example.com/ 3471 templates/agenda.doc 3472 END:VALARM 3474 3.7. Calendar Properties 3476 The Calendar Properties are attributes that apply to the iCalendar 3477 object, as a whole. These properties do not appear within a calendar 3478 component. They SHOULD be specified after the "BEGIN:VCALENDAR" 3479 delimiter string and prior to any calendar component. 3481 3.7.1. Calendar Scale 3483 Property Name: CALSCALE 3485 Purpose: This property defines the calendar scale used for the 3486 calendar information specified in the iCalendar object. 3488 Value Type: TEXT 3490 Property Parameters: IANA and non-standard property parameters can 3491 be specified on this property. 3493 Conformance: This property can be specified once in an iCalendar 3494 object. The default value is "GREGORIAN". 3496 Description: This memo is based on the Gregorian calendar scale. 3497 The Gregorian calendar scale is assumed if this property is not 3498 specified in the iCalendar object. It is expected that other 3499 calendar scales will be defined in other specifications or by 3500 future versions of this memo. 3502 Format Definition: This property is defined by the following 3503 notation: 3505 calscale = "CALSCALE" calparam ":" calvalue CRLF 3507 calparam = *(";" other-param) 3509 calvalue = "GREGORIAN" 3511 Example: The following is an example of this property: 3513 CALSCALE:GREGORIAN 3515 3.7.2. Method 3517 Property Name: METHOD 3519 Purpose: This property defines the iCalendar object method 3520 associated with the calendar object. 3522 Value Type: TEXT 3524 Property Parameters: IANA and non-standard property parameters can 3525 be specified on this property. 3527 Conformance: This property can be specified once in an iCalendar 3528 object. 3530 Description: When used in a MIME message entity, the value of this 3531 property MUST be the same as the Content-Type "method" parameter 3532 value. If either the "METHOD" property or the Content-Type 3533 "method" parameter is specified, then the other MUST also be 3534 specified. 3536 No methods are defined by this specification. This is the subject 3537 of other specifications, such as the iCalendar Transport- 3538 independent Interoperability Protocol (iTIP) defined by 3539 [I-D.ietf-calsify-2446bis]. 3541 If this property is not present in the iCalendar object, then a 3542 scheduling transaction MUST NOT be assumed. In such cases, the 3543 iCalendar object is merely being used to transport a snapshot of 3544 some calendar information; without the intention of conveying a 3545 scheduling semantic. 3547 Format Definition: This property is defined by the following 3548 notation: 3550 method = "METHOD" metparam ":" metvalue CRLF 3552 metparam = *(";" other-param) 3554 metvalue = iana-token 3556 Example: The following is a hypothetical example of this property to 3557 convey that the iCalendar object is a scheduling request: 3559 METHOD:REQUEST 3561 3.7.3. Product Identifier 3563 Property Name: PRODID 3565 Purpose: This property specifies the identifier for the product that 3566 created the iCalendar object. 3568 Value Type: TEXT 3570 Property Parameters: IANA and non-standard property parameters can 3571 be specified on this property. 3573 Conformance: The property MUST be specified once in an iCalendar 3574 object. 3576 Description: The vendor of the implementation SHOULD assure that 3577 this is a globally unique identifier; using some technique such as 3578 an FPI value, as defined in [ISO.9070.1991]. 3580 This property SHOULD not be used to alter the interpretation of an 3581 iCalendar object beyond the semantics specified in this memo. For 3582 example, it is not to be used to further the understanding of non- 3583 standard properties. 3585 Format Definition: This property is defined by the following 3586 notation: 3588 prodid = "PRODID" pidparam ":" pidvalue CRLF 3590 pidparam = *(";" other-param) 3592 pidvalue = text 3593 ;Any text that describes the product and version 3594 ;and that is generally assured of being unique. 3596 Example: The following is an example of this property. It does not 3597 imply that English is the default language. 3599 PRODID:-//ABC Corporation//NONSGML My Product//EN 3601 3.7.4. Version 3603 Property Name: VERSION 3605 Purpose: This property specifies the identifier corresponding to the 3606 highest version number or the minimum and maximum range of the 3607 iCalendar specification that is required in order to interpret the 3608 iCalendar object. 3610 Value Type: TEXT 3612 Property Parameters: IANA and non-standard property parameters can 3613 be specified on this property. 3615 Conformance: This property MUST be specified once in an iCalendar 3616 object. 3618 Description: A value of "2.0" corresponds to this memo. 3620 Format Definition: This property is defined by the following 3621 notation: 3623 version = "VERSION" verparam ":" vervalue CRLF 3625 verparam = *(";" other-param) 3627 vervalue = "2.0" ;This memo 3628 / maxver 3629 / (minver ";" maxver) 3631 minver = 3632 ;Minimum iCalendar version needed to parse the iCalendar object 3634 maxver = 3635 ;Maximum iCalendar version needed to parse the iCalendar object 3637 Example: The following is an example of this property: 3639 VERSION:2.0 3641 3.8. Component Properties 3643 The following properties can appear within calendar components, as 3644 specified by each component property definition. 3646 3.8.1. Descriptive Component Properties 3648 The following properties specify descriptive information about 3649 calendar components. 3651 3.8.1.1. Attachment 3653 Property Name: ATTACH 3655 Purpose: This property provides the capability to associate a 3656 document object with a calendar component. 3658 Value Type: The default value type for this property is URI. The 3659 value type can also be set to BINARY to indicate inline binary 3660 encoded content information. 3662 Property Parameters: IANA, non-standard, inline encoding, format 3663 type and value data type property parameters can be specified on 3664 this property. 3666 Conformance: This property can be specified multiple times in a 3667 "VEVENT", "VTODO", "VJOURNAL" or "VALARM" calendar component with 3668 the exception of AUDIO alarm which only allows this property to 3669 occur once. 3671 Description: This property is used in "VEVENT", "VTODO", and 3672 "VJOURNAL" calendar components to associate a resource (e.g., 3673 document) with the calendar component. This property is used in 3674 "VALARM" calendar components to specify an audio sound resource or 3675 an email message attachment. This property can be specified as a 3676 URI pointing to a resource or as inline binary encoded content. 3678 Format Definition: This property is defined by the following 3679 notation: 3681 attach = "ATTACH" attachparam ":" uri CRLF 3683 / "ATTACH" attachparam ";" "ENCODING" "=" "BASE64" 3684 ";" "VALUE" "=" "BINARY" ":" binary 3686 attachparam = *( 3688 ; the following is OPTIONAL, 3689 ; but MUST NOT occur more than once 3691 (";" fmttypeparam) / 3693 ; the following is OPTIONAL, 3694 ; and MAY occur more than once 3696 (";" other-param) 3698 ) 3700 Example: The following are examples of this property: 3702 ATTACH:CID:jsmith.part3.960817T083000.xyzMail@example.com 3704 ATTACH;FMTTYPE=application/postscript:ftp://example.com/pub/ 3705 reports/r-960812.ps 3707 3.8.1.2. Categories 3709 Property Name: CATEGORIES 3711 Purpose: This property defines the categories for a calendar 3712 component. 3714 Value Type: TEXT 3715 Property Parameters: IANA, non-standard, and language property 3716 parameters can be specified on this property. 3718 Conformance: The property can be specified within "VEVENT", "VTODO" 3719 or "VJOURNAL" calendar components. 3721 Description: This property is used to specify categories or subtypes 3722 of the calendar component. The categories are useful in searching 3723 for a calendar component of a particular type and category. 3724 Within the "VEVENT", "VTODO" or "VJOURNAL" calendar components, 3725 more than one category can be specified as a list of categories 3726 separated by the COMMA character (US-ASCII decimal 44). 3728 Format Definition: This property is defined by the following 3729 notation: 3731 categories = "CATEGORIES" catparam ":" text *("," text) 3732 CRLF 3734 catparam = *( 3736 ; the following is OPTIONAL, 3737 ; but MUST NOT occur more than once 3739 (";" languageparam ) / 3741 ; the following is OPTIONAL, 3742 ; and MAY occur more than once 3744 (";" other-param) 3746 ) 3748 Example: The following are examples of this property: 3750 CATEGORIES:APPOINTMENT,EDUCATION 3752 CATEGORIES:MEETING 3754 3.8.1.3. Classification 3756 Property Name: CLASS 3758 Purpose: This property defines the access classification for a 3759 calendar component. 3761 Value Type: TEXT 3763 Property Parameters: IANA and non-standard property parameters can 3764 be specified on this property. 3766 Conformance: The property can be specified once in a "VEVENT", 3767 "VTODO" or "VJOURNAL" calendar components. 3769 Description: An access classification is only one component of the 3770 general security system within a calendar application. It 3771 provides a method of capturing the scope of the access the 3772 calendar owner intends for information within an individual 3773 calendar entry. The access classification of an individual 3774 iCalendar component is useful when measured along with the other 3775 security components of a calendar system (e.g., calendar user 3776 authentication, authorization, access rights, access role, etc.). 3777 Hence, the semantics of the individual access classifications 3778 cannot be completely defined by this memo alone. Additionally, 3779 due to the "blind" nature of most exchange processes using this 3780 memo, these access classifications cannot serve as an enforcement 3781 statement for a system receiving an iCalendar object. Rather, 3782 they provide a method for capturing the intention of the calendar 3783 owner for the access to the calendar component. If not specified 3784 in a component that allows this property, the default value is 3785 PUBLIC. Applications MUST treat x-name and iana-token value they 3786 don't recognized the same way as they would the PRIVATE value. 3788 Format Definition: This property is defined by the following 3789 notation: 3791 class = "CLASS" classparam ":" classvalue CRLF 3793 classparam = *(";" other-param) 3795 classvalue = "PUBLIC" / "PRIVATE" / "CONFIDENTIAL" / iana-token 3796 / x-name 3797 ;Default is PUBLIC 3799 Example: The following is an example of this property: 3801 CLASS:PUBLIC 3803 3.8.1.4. Comment 3804 Property Name: COMMENT 3806 Purpose: This property specifies non-processing information intended 3807 to provide a comment to the calendar user. 3809 Value Type: TEXT 3811 Property Parameters: IANA, non-standard, alternate text 3812 representation and language property parameters can be specified 3813 on this property. 3815 Conformance: This property can be specified multiple times in 3816 "VEVENT", "VTODO", "VJOURNAL", and "VFREEBUSY" calendar components 3817 as well as in the "STANDARD" and "DAYLIGHT" sub-components. 3819 Description: This property is used to specify a comment to the 3820 calendar user. 3822 Format Definition: This property is defined by the following 3823 notation: 3825 comment = "COMMENT" commparam ":" text CRLF 3827 commparam = *( 3829 ; the following are OPTIONAL, 3830 ; but MUST NOT occur more than once 3832 (";" altrepparam) / (";" languageparam) / 3834 ; the following is OPTIONAL, 3835 ; and MAY occur more than once 3837 (";" other-param) 3839 ) 3841 Example: The following is an example of this property: 3843 COMMENT:The meeting really needs to include both ourselves 3844 and the customer. We can't hold this meeting without them. 3845 As a matter of fact\, the venue for the meeting ought to be at 3846 their site. - - John 3848 3.8.1.5. Description 3850 Property Name: DESCRIPTION 3852 Purpose: This property provides a more complete description of the 3853 calendar component, than that provided by the "SUMMARY" property. 3855 Value Type: TEXT 3857 Property Parameters: IANA, non-standard, alternate text 3858 representation and language property parameters can be specified 3859 on this property. 3861 Conformance: The property can be specified in the "VEVENT", "VTODO", 3862 "VJOURNAL" or "VALARM" calendar components. The property can be 3863 specified multiple times only within a "VJOURNAL" calendar 3864 component. 3866 Description: This property is used in the "VEVENT" and "VTODO" to 3867 capture lengthy textual decriptions associated with the activity. 3869 This property is used in the "VJOURNAL" calendar component to 3870 capture one or more textual journal entries. 3872 This property is used in the "VALARM" calendar component to 3873 capture the display text for a DISPLAY category of alarm, and to 3874 capture the body text for an EMAIL category of alarm. 3876 Format Definition: This property is defined by the following 3877 notation: 3879 description = "DESCRIPTION" descparam ":" text CRLF 3881 descparam = *( 3883 ; the following are OPTIONAL, 3884 ; but MUST NOT occur more than once 3886 (";" altrepparam) / (";" languageparam) / 3888 ; the following is OPTIONAL, 3889 ; and MAY occur more than once 3891 (";" other-param) 3893 ) 3895 Example: The following is an example of this property with formatted 3896 line breaks in the property value: 3898 DESCRIPTION:Meeting to provide technical review for "Phoenix" 3899 design.\nHappy Face Conference Room. Phoenix design team 3900 MUST attend this meeting.\nRSVP to team leader. 3902 3.8.1.6. Geographic Position 3904 Property Name: GEO 3906 Purpose: This property specifies information related to the global 3907 position for the activity specified by a calendar component. 3909 Value Type: FLOAT. The value MUST be two SEMICOLON separated FLOAT 3910 values. 3912 Property Parameters: IANA and non-standard property parameters can 3913 be specified on this property. 3915 Conformance: This property can be specified in "VEVENT" or "VTODO" 3916 calendar components. 3918 Description: This property value specifies latitude and longitude, 3919 in that order (i.e., "LAT LON" ordering). The longitude 3920 represents the location East or West of the prime meridian as a 3921 positive or negative real number, respectively. The longitude and 3922 latitude values MAY be specified up to six decimal places, which 3923 will allow for accuracy to within one meter of geographical 3924 position. Receiving applications MUST accept values of this 3925 precision and MAY truncate values of greater precision. 3927 Values for latitude and longitude shall be expressed as decimal 3928 fractions of degrees. Whole degrees of latitude shall be 3929 represented by a two-digit decimal number ranging from 0 through 3930 90. Whole degrees of longitude shall be represented by a decimal 3931 number ranging from 0 through 180. When a decimal fraction of a 3932 degree is specified, it shall be separated from the whole number 3933 of degrees by a decimal point. 3935 Latitudes North of the equator shall be specified by a plus sign 3936 (+), or by the absence of a minus sign (-), preceding the digits 3937 designating degrees. Latitudes South of the Equator shall be 3938 designated by a minus sign (-) preceding the digits designating 3939 degrees. A point on the Equator shall be assigned to the Northern 3940 Hemisphere. 3942 Longitudes east of the prime meridian shall be specified by a plus 3943 sign (+), or by the absence of a minus sign (-), preceding the 3944 digits designating degrees. Longitudes west of the meridian shall 3945 be designated by minus sign (-) preceding the digits designating 3946 degrees. A point on the prime meridian shall be assigned to the 3947 Eastern Hemisphere. A point on the 180th meridian shall be 3948 assigned to the Western Hemisphere. One exception to this last 3949 convention is permitted. For the special condition of describing 3950 a band of latitude around the earth, the East Bounding Coordinate 3951 data element shall be assigned the value +180 (180) degrees. 3953 Any spatial address with a latitude of +90 (90) or -90 degrees 3954 will specify the position at the North or South Pole, 3955 respectively. The component for longitude may have any legal 3956 value. 3958 With the exception of the special condition described above, this 3959 form is specified in Department of Commerce, 1986, Representation 3960 of geographic point locations for information interchange (Federal 3961 Information Processing Standard 70-1): Washington, Department of 3962 Commerce, National Institute of Standards and Technology. 3964 The simple formula for converting degrees-minutes-seconds into 3965 decimal degrees is: 3967 decimal = degrees + minutes/60 + seconds/3600. 3969 Format Definition: This property is defined by the following 3970 notation: 3972 geo = "GEO" geoparam ":" geovalue CRLF 3974 geoparam = *(";" other-param) 3976 geovalue = float ";" float 3977 ;Latitude and Longitude components 3979 Example: The following is an example of this property: 3981 GEO:37.386013;-122.082932 3983 3.8.1.7. Location 3985 Property Name: LOCATION 3986 Purpose: This property defines the intended venue for the activity 3987 defined by a calendar component. 3989 Value Type: TEXT 3991 Property Parameters: IANA, non-standard, alternate text 3992 representation and language property parameters can be specified 3993 on this property. 3995 Conformance: This property can be specified in "VEVENT" or "VTODO" 3996 calendar component. 3998 Description: Specific venues such as conference or meeting rooms may 3999 be explicitly specified using this property. An alternate 4000 representation may be specified that is a URI that points to 4001 directory information with more structured specification of the 4002 location. For example, the alternate representation may specify 4003 either an LDAP URL [RFC4516] pointing to an LDAP server entry or a 4004 CID URL [RFC2392] pointing to a MIME body part containing a vCard 4005 [RFC2426] for the location. 4007 Format Definition: This property is defined by the following 4008 notation: 4010 location = "LOCATION" locparam ":" text CRLF 4012 locparam = *( 4014 ; the following are OPTIONAL, 4015 ; but MUST NOT occur more than once 4017 (";" altrepparam) / (";" languageparam) / 4019 ; the following is OPTIONAL, 4020 ; and MAY occur more than once 4022 (";" other-param) 4024 ) 4026 Example: The following are some examples of this property: 4028 LOCATION:Conference Room - F123\, Bldg. 002 4030 LOCATION;ALTREP="http://xyzcorp.com/conf-rooms/f123.vcf": 4031 Conference Room - F123\, Bldg. 002 4033 3.8.1.8. Percent Complete 4035 Property Name: PERCENT-COMPLETE 4037 Purpose: This property is used by an assignee or delegatee of a 4038 to-do to convey the percent completion of a to-do to the 4039 "Organizer". 4041 Value Type: INTEGER 4043 Property Parameters: IANA and non-standard property parameters can 4044 be specified on this property. 4046 Conformance: This property can be specified once in a "VTODO" 4047 calendar component. 4049 Description: The property value is a positive integer between zero 4050 and one hundred. A value of "0" indicates the to-do has not yet 4051 been started. A value of "100" indicates that the to-do has been 4052 completed. Integer values in between indicate the percent 4053 partially complete. 4055 When a to-do is assigned to multiple individuals, the property 4056 value indicates the percent complete for that portion of the to-do 4057 assigned to the assignee or delegatee. For example, if a to-do is 4058 assigned to both individuals "A" and "B". A reply from "A" with a 4059 percent complete of "70" indicates that "A" has completed 70% of 4060 the to-do assigned to them. A reply from "B" with a percent 4061 complete of "50" indicates "B" has completed 50% of the to-do 4062 assigned to them. 4064 Format Definition: This property is defined by the following 4065 notation: 4067 percent = "PERCENT-COMPLETE" pctparam ":" integer CRLF 4069 pctparam = *(";" other-param) 4071 Example: The following is an example of this property to show 39% 4072 completion: 4074 PERCENT-COMPLETE:39 4076 3.8.1.9. Priority 4077 Property Name: PRIORITY 4079 Purpose: This property defines the relative priority for a calendar 4080 component. 4082 Value Type: INTEGER 4084 Property Parameters: IANA and non-standard property parameters can 4085 be specified on this property. 4087 Conformance: This property can be specified in "VEVENT" and "VTODO" 4088 calendar components. 4090 Description: This priority is specified as an integer in the range 4091 zero to nine. A value of zero (US-ASCII decimal 48) specifies an 4092 undefined priority. A value of one (US-ASCII decimal 49) is the 4093 highest priority. A value of two (US-ASCII decimal 50) is the 4094 second highest priority. Subsequent numbers specify a decreasing 4095 ordinal priority. A value of nine (US-ASCII decimal 57 ) is the 4096 lowest priority. 4098 A CUA with a three-level priority scheme of "HIGH", "MEDIUM" and 4099 "LOW" is mapped into this property such that a property value in 4100 the range of one (US-ASCII decimal 49) to four (US-ASCII decimal 4101 52) specifies "HIGH" priority. A value of five (US-ASCII decimal 4102 53) is the normal or "MEDIUM" priority. A value in the range of 4103 six (US-ASCII decimal 54) to nine (US-ASCII decimal 57 ) is "LOW" 4104 priority. 4106 A CUA with a priority schema of "A1", "A2", "A3", "B1", "B2", ..., 4107 "C3" is mapped into this property such that a property value of 4108 one (US-ASCII decimal 49) specifies "A1", a property value of two 4109 (US-ASCII decimal 50) specifies "A2", a property value of three 4110 (US-ASCII decimal 51) specifies "A3", and so forth up to a 4111 property value of 9 (US-ASCII decimal 57 ) specifies "C3". 4113 Other integer values are reserved for future use. 4115 Within a "VEVENT" calendar component, this property specifies a 4116 priority for the event. This property may be useful when more 4117 than one event is scheduled for a given time period. 4119 Within a "VTODO" calendar component, this property specified a 4120 priority for the to-do. This property is useful in prioritizing 4121 multiple action items for a given time period. 4123 Format Definition: This property is defined by the following 4124 notation: 4126 priority = "PRIORITY" prioparam ":" priovalue CRLF 4127 ;Default is zero (i.e., undefined) 4129 prioparam = *(";" other-param) 4131 priovalue = integer ;Must be in the range [0..9] 4132 ; All other values are reserved for future use 4134 Example: The following is an example of a property with the highest 4135 priority: 4137 PRIORITY:1 4139 The following is an example of a property with a next highest 4140 priority: 4142 PRIORITY:2 4144 The following is an example of a property with no priority. This 4145 is equivalent to not specifying the "PRIORITY" property: 4147 PRIORITY:0 4149 3.8.1.10. Resources 4151 Property Name: RESOURCES 4153 Purpose: This property defines the equipment or resources 4154 anticipated for an activity specified by a calendar component. 4156 Value Type: TEXT 4158 Property Parameters: IANA, non-standard, alternate text 4159 representation and language property parameters can be specified 4160 on this property. 4162 Conformance: This property can be specified once in "VEVENT" or 4163 "VTODO" calendar component. 4165 Description: The property value is an arbitrary text. More than one 4166 resource can be specified as a list of resources separated by the 4167 COMMA character (US-ASCII decimal 44). 4169 Format Definition: This property is defined by the following 4170 notation: 4172 resources = "RESOURCES" resrcparam ":" text *("," text) CRLF 4174 resrcparam = *( 4176 ; the following are OPTIONAL, 4177 ; but MUST NOT occur more than once 4179 (";" altrepparam) / (";" languageparam) / 4181 ; the following is OPTIONAL, 4182 ; and MAY occur more than once 4184 (";" other-param) 4186 ) 4188 Example: The following is an example of this property: 4190 RESOURCES:EASEL,PROJECTOR,VCR 4192 RESOURCES;LANGUAGE=fr:1 raton-laveur 4194 3.8.1.11. Status 4196 Property Name: STATUS 4198 Purpose: This property defines the overall status or confirmation 4199 for the calendar component. 4201 Value Type: TEXT 4203 Property Parameters: IANA and non-standard property parameters can 4204 be specified on this property. 4206 Conformance: This property can be specified once in "VEVENT", 4207 "VTODO" or "VJOURNAL" calendar components. 4209 Description: In a group scheduled calendar component, the property 4210 is used by the "Organizer" to provide a confirmation of the event 4211 to the "Attendees". For example in a "VEVENT" calendar component, 4212 the "Organizer" can indicate that a meeting is tentative, 4213 confirmed or cancelled. In a "VTODO" calendar component, the 4214 "Organizer" can indicate that an action item needs action, is 4215 completed, is in process or being worked on, or has been 4216 cancelled. In a "VJOURNAL" calendar component, the "Organizer" 4217 can indicate that a journal entry is draft, final or has been 4218 cancelled or removed. 4220 Format Definition: This property is defined by the following 4221 notation: 4223 status = "STATUS" statparam ":" statvalue CRLF 4225 statparam = *(";" other-param) 4227 statvalue = (statvalue-event 4228 / statvalue-todo 4229 / statvalue-jour) 4231 statvalue-event = "TENTATIVE" ;Indicates event is tentative. 4232 / "CONFIRMED" ;Indicates event is definite. 4233 / "CANCELLED" ;Indicates event was cancelled. 4234 ;Status values for a "VEVENT" 4236 statvalue-todo = "NEEDS-ACTION" ;Indicates to-do needs action. 4237 / "COMPLETED" ;Indicates to-do completed. 4238 / "IN-PROCESS" ;Indicates to-do in process of. 4239 / "CANCELLED" ;Indicates to-do was cancelled. 4240 ;Status values for "VTODO". 4242 statvalue-jour = "DRAFT" ;Indicates journal is draft. 4243 / "FINAL" ;Indicates journal is final. 4244 / "CANCELLED" ;Indicates journal is removed. 4245 ;Status values for "VJOURNAL". 4247 Example: The following is an example of this property for a "VEVENT" 4248 calendar component: 4250 STATUS:TENTATIVE 4252 The following is an example of this property for a "VTODO" 4253 calendar component: 4255 STATUS:NEEDS-ACTION 4257 The following is an example of this property for a "VJOURNAL" 4258 calendar component: 4260 STATUS:DRAFT 4262 3.8.1.12. Summary 4264 Property Name: SUMMARY 4266 Purpose: This property defines a short summary or subject for the 4267 calendar component. 4269 Value Type: TEXT 4271 Property Parameters: IANA, non-standard, alternate text 4272 representation and language property parameters can be specified 4273 on this property. 4275 Conformance: The property can be specified in "VEVENT", "VTODO", 4276 "VJOURNAL" or "VALARM" calendar components. 4278 Description: This property is used in the "VEVENT", "VTODO" and 4279 "VJOURNAL" calendar components to capture a short, one line 4280 summary about the activity or journal entry. 4282 This property is used in the "VALARM" calendar component to 4283 capture the subject of an EMAIL category of alarm. 4285 Format Definition: This property is defined by the following 4286 notation: 4288 summary = "SUMMARY" summparam ":" text CRLF 4290 summparam = *( 4292 ; the following are OPTIONAL, 4293 ; but MUST NOT occur more than once 4295 (";" altrepparam) / (";" languageparam) / 4297 ; the following is OPTIONAL, 4298 ; and MAY occur more than once 4300 (";" other-param) 4302 ) 4304 Example: The following is an example of this property: 4306 SUMMARY:Department Party 4308 3.8.2. Date and Time Component Properties 4310 The following properties specify date and time related information in 4311 calendar components. 4313 3.8.2.1. Date/Time Completed 4315 Property Name: COMPLETED 4317 Purpose: This property defines the date and time that a to-do was 4318 actually completed. 4320 Value Type: DATE-TIME 4322 Property Parameters: IANA and non-standard property parameters can 4323 be specified on this property. 4325 Conformance: The property can be specified in a "VTODO" calendar 4326 component. The value MUST be specified as a date with UTC time. 4328 Description: This property defines the date and time that a to-do 4329 was actually completed. 4331 Format Definition: This property is defined by the following 4332 notation: 4334 completed = "COMPLETED" compparam ":" date-time CRLF 4336 compparam = *(";" other-param) 4338 Example: The following is an example of this property: 4340 COMPLETED:19960401T150000Z 4342 3.8.2.2. Date/Time End 4344 Property Name: DTEND 4346 Purpose: This property specifies the date and time that a calendar 4347 component ends. 4349 Value Type: The default value type is DATE-TIME. The value type can 4350 be set to a DATE value type. 4352 Property Parameters: IANA, non-standard, value data type, and time 4353 zone identifier property parameters can be specified on this 4354 property. 4356 Conformance: This property can be specified in "VEVENT" or 4357 "VFREEBUSY" calendar components. 4359 Description: Within the "VEVENT" calendar component, this property 4360 defines the date and time by which the event ends. The value type 4361 of this property MUST be the same as the "DTSTART" property, and 4362 its value MUST be later in time than the value of the "DTSTART" 4363 property. Furthermore, this property MUST be specified as a date 4364 with local time if and only if the "DTSTART" property is also 4365 specified as a date with local time. 4367 Within the "VFREEBUSY" calendar component, this property defines 4368 the end date and time for the free or busy time information. The 4369 time MUST be specified in the UTC time format. The value MUST be 4370 later in time than the value of the "DTSTART" property. 4372 Format Definition: This property is defined by the following 4373 notation: 4375 dtend = "DTEND" dtendparam ":" dtendval CRLF 4377 dtendparam = *( 4379 ; the following are OPTIONAL, 4380 ; but MUST NOT occur more than once 4382 (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / 4383 (";" tzidparam) / 4385 ; the following is OPTIONAL, 4386 ; and MAY occur more than once 4388 (";" other-param) 4390 ) 4392 dtendval = date-time / date 4393 ;Value MUST match value type 4395 Example: The following is an example of this property: 4397 DTEND:19960401T150000Z 4399 DTEND;VALUE=DATE:19980704 4401 3.8.2.3. Date/Time Due 4403 Property Name: DUE 4405 Purpose: This property defines the date and time that a to-do is 4406 expected to be completed. 4408 Value Type: The default value type is DATE-TIME. The value type can 4409 be set to a DATE value type. 4411 Property Parameters: IANA, non-standard, value data type, and time 4412 zone identifier property parameters can be specified on this 4413 property. 4415 Conformance: The property can be specified once in a "VTODO" 4416 calendar component. 4418 Description: This property defines the date and time before which a 4419 to-do is expected to be completed. For cases where this property 4420 is specified in a "VTODO" calendar component that also specifies a 4421 "DTSTART" property, the value type of this property MUST be the 4422 same as the "DTSTART" property, and the value of this property 4423 MUST be later in time than the value of the "DTSTART" property. 4424 Furthermore, this property MUST be specified as a date with local 4425 time if and only if the "DTSTART" property is also specified as a 4426 date with local time. 4428 Format Definition: This property is defined by the following 4429 notation: 4431 due = "DUE" dueparam ":" dueval CRLF 4433 dueparam = *( 4435 ; the following are OPTIONAL, 4436 ; but MUST NOT occur more than once 4438 (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / 4439 (";" tzidparam) / 4441 ; the following is OPTIONAL, 4442 ; and MAY occur more than once 4444 (";" other-param) 4446 ) 4448 dueval = date-time / date 4449 ;Value MUST match value type 4451 Example: The following is an example of this property: 4453 DUE:19980430T000000Z 4455 3.8.2.4. Date/Time Start 4457 Property Name: DTSTART 4459 Purpose: This property specifies when the calendar component begins. 4461 Value Type: The default value type is DATE-TIME. The time value 4462 MUST be one of the forms defined for the DATE-TIME value type. 4463 The value type can be set to a DATE value type. 4465 Property Parameters: IANA, non-standard, value data type, and time 4466 zone identifier property parameters can be specified on this 4467 property. 4469 Conformance: This property can be specified once in the "VEVENT", 4470 "VTODO", or "VFREEBUSY" calendar components as well as in the 4471 "STANDARD" and "DAYLIGHT" sub-components. This property is 4472 REQUIRED in "VEVENT" calendar components and in all types of 4473 recurring calendar components. 4475 Description: Within the "VEVENT" calendar component, this property 4476 defines the start date and time for the event. 4478 Within the "VFREEBUSY" calendar component, this property defines 4479 the start date and time for the free or busy time information. 4480 The time MUST be specified in UTC time. 4482 Within the "STANDARD" and "DAYLIGHT" sub-components, this property 4483 defines the effective start date and time for a time zone 4484 specification. This property is REQUIRED within each "STANDARD" 4485 and "DAYLIGHT" sub-components included in "VTIMEZONE" calendar 4486 components and MUST be specified as a local DATE-TIME without the 4487 "TZID" property parameter. 4489 Format Definition: This property is defined by the following 4490 notation: 4492 dtstart = "DTSTART" dtstparam ":" dtstval CRLF 4494 dtstparam = *( 4496 ; the following are OPTIONAL, 4497 ; but MUST NOT occur more than once 4499 (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / 4500 (";" tzidparam) / 4502 ; the following is OPTIONAL, 4503 ; and MAY occur more than once 4505 (";" other-param) 4507 ) 4509 dtstval = date-time / date 4510 ;Value MUST match value type 4512 Example: The following is an example of this property: 4514 DTSTART:19980118T073000Z 4516 3.8.2.5. Duration 4518 Property Name: DURATION 4520 Purpose: This property specifies a positive duration of time. 4522 Value Type: DURATION 4524 Property Parameters: IANA and non-standard property parameters can 4525 be specified on this property. 4527 Conformance: This property can be specified in "VEVENT", "VTODO", 4528 "VFREEBUSY" or "VALARM" calendar components. 4530 Description: In a "VEVENT" calendar component the property may be 4531 used to specify a duration of the event, instead of an explicit 4532 end date/time. In a "VTODO" calendar component the property may 4533 be used to specify a duration for the to-do, instead of an 4534 explicit due date/time. In a "VFREEBUSY" calendar component the 4535 property may be used to specify the interval of free time being 4536 requested. In a "VALARM" calendar component the property may be 4537 used to specify the delay period prior to repeating an alarm. 4538 When the "DURATION" property relates to a "DTSTART" property that 4539 is specified as a DATE value, then the "DURATION" property MUST be 4540 specified as a "dur-day" or "dur-week" value. 4542 Format Definition: This property is defined by the following 4543 notation: 4545 duration = "DURATION" durparam ":" dur-value CRLF 4546 ;consisting of a positive duration of time. 4548 durparam = *(";" other-param) 4550 Example: The following is an example of this property that specifies 4551 an interval of time of 1 hour and zero minutes and zero seconds: 4553 DURATION:PT1H0M0S 4555 The following is an example of this property that specifies an 4556 interval of time of 15 minutes. 4558 DURATION:PT15M 4560 3.8.2.6. Free/Busy Time 4562 Property Name: FREEBUSY 4564 Purpose: This property defines one or more free or busy time 4565 intervals. 4567 Value Type: PERIOD 4569 Property Parameters: IANA, non-standard, and free/busy time type 4570 property parameters can be specified on this property. 4572 Conformance: The property can be specified in a "VFREEBUSY" calendar 4573 component. 4575 Description: These time periods can be specified as either a start 4576 and end date-time or a start date-time and duration. The date and 4577 time MUST be a UTC time format. 4579 "FREEBUSY" properties within the "VFREEBUSY" calendar component 4580 SHOULD be sorted in ascending order, based on start time and then 4581 end time, with the earliest periods first. 4583 The "FREEBUSY" property can specify more than one value, separated 4584 by the COMMA character (US-ASCII decimal 44). In such cases, the 4585 "FREEBUSY" property values MUST all be of the same "FBTYPE" 4586 property parameter type (e.g., all values of a particular "FBTYPE" 4587 listed together in a single property). 4589 Format Definition: This property is defined by the following 4590 notation: 4592 freebusy = "FREEBUSY" fbparam ":" fbvalue CRLF 4594 fbparam = *( 4595 ; the following is OPTIONAL, 4596 ; but MUST NOT occur more than once 4598 (";" fbtypeparam) / 4600 ; the following is OPTIONAL, 4601 ; and MAY occur more than once 4603 (";" other-param) 4605 ) 4607 fbvalue = period *("," period) 4608 ;Time value MUST be in the UTC time format. 4610 Example: The following are some examples of this property: 4612 FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:19970308T160000Z/PT8H30M 4614 FREEBUSY;FBTYPE=FREE:19970308T160000Z/PT3H,19970308T200000Z/PT1H 4616 FREEBUSY;FBTYPE=FREE:19970308T160000Z/PT3H,19970308T200000Z/PT1H 4617 ,19970308T230000Z/19970309T000000Z 4619 3.8.2.7. Time Transparency 4621 Property Name: TRANSP 4623 Purpose: This property defines whether an event is transparent or 4624 not to busy time searches. 4626 Value Type: TEXT 4628 Property Parameters: IANA and non-standard property parameters can 4629 be specified on this property. 4631 Conformance: This property can be specified once in a "VEVENT" 4632 calendar component. 4634 Description: Time Transparency is the characteristic of an event 4635 that determines whether it appears to consume time on a calendar. 4636 Events that consume actual time for the individual or resource 4637 associated with the calendar SHOULD be recorded as OPAQUE, 4638 allowing them to be detected by free-busy time searches. Other 4639 events, which do not take up the individual's (or resource's) time 4640 SHOULD be recorded as TRANSPARENT, making them invisible to free- 4641 busy time searches. 4643 Format Definition: This property is defined by the following 4644 notation: 4646 transp = "TRANSP" transparam ":" transvalue CRLF 4648 transparam = *(";" other-param) 4650 transvalue = "OPAQUE" 4651 ;Blocks or opaque on busy time searches. 4652 / "TRANSPARENT" 4653 ;Transparent on busy time searches. 4654 ;Default value is OPAQUE 4656 Example: The following is an example of this property for an event 4657 that is transparent or does not block on free/busy time searches: 4659 TRANSP:TRANSPARENT 4661 The following is an example of this property for an event that is 4662 opaque or blocks on free/busy time searches: 4664 TRANSP:OPAQUE 4666 3.8.3. Time Zone Component Properties 4668 The following properties specify time zone information in calendar 4669 components. 4671 3.8.3.1. Time Zone Identifier 4673 Property Name: TZID 4675 Purpose: This property specifies the text value that uniquely 4676 identifies the "VTIMEZONE" calendar component in the scope of an 4677 iCalendar object. 4679 Value Type: TEXT 4681 Property Parameters: IANA and non-standard property parameters can 4682 be specified on this property. 4684 Conformance: This property MUST be specified in a "VTIMEZONE" 4685 calendar component. 4687 Description: This is the label by which a time zone calendar 4688 component is referenced by any iCalendar properties whose value 4689 type is either DATE-TIME or TIME and not intended to specify a UTC 4690 or a "floating" time. The presence of the SOLIDUS character (US- 4691 ASCII decimal 47) as a prefix, indicates that this "TZID" 4692 represents an unique ID in a globally defined time zone registry 4693 (when such registry is defined). 4695 Note: This document does not define a naming convention for 4696 time zone identifiers. Implementers may want to use the naming 4697 conventions defined in existing time zone specifications such 4698 as the public-domain TZ database [TZDB]. The specification of 4699 globally unique time zone identifiers is not addressed by this 4700 document and is left for future study. 4702 Format Definition: This property is defined by the following 4703 notation: 4705 tzid = "TZID" tzidpropparam ":" [tzidprefix] text CRLF 4707 tzidpropparam = *(";" other-param) 4709 ;tzidprefix = "/" 4710 ; Defined previously. Just listed here for reader convenience. 4712 Example: The following are examples of non-globally unique time zone 4713 identifiers: 4715 TZID:America/New_York 4717 TZID:America/Los_Angeles 4719 The following is an example of a fictitious globally unique time 4720 zone identifier: 4722 TZID:/example.org/America/New_York 4724 3.8.3.2. Time Zone Name 4726 Property Name: TZNAME 4728 Purpose: This property specifies the customary designation for a 4729 time zone description. 4731 Value Type: TEXT 4733 Property Parameters: IANA, non-standard, and language property 4734 parameters can be specified on this property. 4736 Conformance: This property can be specified in "STANDARD" and 4737 "DAYLIGHT" sub-components. 4739 Description: This property may be specified in multiple languages; 4740 in order to provide for different language requirements. 4742 Format Definition: This property is defined by the following 4743 notation: 4745 tzname = "TZNAME" tznparam ":" text CRLF 4747 tznparam = *( 4749 ; the following is OPTIONAL, 4750 ; but MUST NOT occur more than once 4752 (";" languageparam) / 4754 ; the following is OPTIONAL, 4755 ; and MAY occur more than once 4757 (";" other-param) 4759 ) 4761 Example: The following are example of this property: 4763 TZNAME:EST 4765 The following is an example of this property when two different 4766 languages for the time zone name are specified: 4768 TZNAME;LANGUAGE=en:EST 4769 TZNAME;LANGUAGE=fr-CA:HNE 4771 3.8.3.3. Time Zone Offset From 4773 Property Name: TZOFFSETFROM 4775 Purpose: This property specifies the offset which is in use prior to 4776 this time zone observance. 4778 Value Type: UTC-OFFSET 4780 Property Parameters: IANA and non-standard property parameters can 4781 be specified on this property. 4783 Conformance: This property MUST be specified in "STANDARD" and 4784 "DAYLIGHT" sub-components. 4786 Description: This property specifies the offset which is in use 4787 prior to this time observance. It is used to calculate the 4788 absolute time at which the transition to a given observance takes 4789 place. This property MUST only be specified in a "VTIMEZONE" 4790 calendar component. A "VTIMEZONE" calendar component MUST include 4791 this property. The property value is a signed numeric indicating 4792 the number of hours and possibly minutes from UTC. Positive 4793 numbers represent time zones east of the prime meridian, or ahead 4794 of UTC. Negative numbers represent time zones west of the prime 4795 meridian, or behind UTC. 4797 Format Definition: This property is defined by the following 4798 notation: 4800 tzoffsetfrom = "TZOFFSETFROM" frmparam ":" utc-offset 4801 CRLF 4803 frmparam = *(";" other-param) 4805 Example: The following are examples of this property: 4807 TZOFFSETFROM:-0500 4809 TZOFFSETFROM:+1345 4811 3.8.3.4. Time Zone Offset To 4813 Property Name: TZOFFSETTO 4815 Purpose: This property specifies the offset which is in use in this 4816 time zone observance. 4818 Value Type: UTC-OFFSET 4820 Property Parameters: IANA and non-standard property parameters can 4821 be specified on this property. 4823 Conformance: This property MUST be specified in "STANDARD" and 4824 "DAYLIGHT" sub-components. 4826 Description: This property specifies the offset which is in use in 4827 this time zone observance. It is used to calculate the absolute 4828 time for the new observance. The property value is a signed 4829 numeric indicating the number of hours and possibly minutes from 4830 UTC. Positive numbers represent time zones east of the prime 4831 meridian, or ahead of UTC. Negative numbers represent time zones 4832 west of the prime meridian, or behind UTC. 4834 Format Definition: This property is defined by the following 4835 notation: 4837 tzoffsetto = "TZOFFSETTO" toparam ":" utc-offset CRLF 4839 toparam = *(";" other-param) 4841 Example: The following are examples of this property: 4843 TZOFFSETTO:-0400 4845 TZOFFSETTO:+1245 4847 3.8.3.5. Time Zone URL 4849 Property Name: TZURL 4851 Purpose: This property provides a means for a "VTIMEZONE" component 4852 to point to a network location that can be used to retrieve an up- 4853 to-date version of itself. 4855 Value Type: URI 4857 Property Parameters: IANA and non-standard property parameters can 4858 be specified on this property. 4860 Conformance: This property can be specified in a "VTIMEZONE" 4861 calendar component. 4863 Description: This property provides a means for a "VTIMEZONE" 4864 component to point to a network location that can be used to 4865 retrieve an up-to-date version of itself. This provides a hook to 4866 handle changes government bodies impose upon time zone 4867 definitions. Retrieval of this resource results in an iCalendar 4868 object containing a single "VTIMEZONE" component and a "METHOD" 4869 property set to PUBLISH. 4871 Format Definition: This property is defined by the following 4872 notation: 4874 tzurl = "TZURL" tzurlparam ":" uri CRLF 4876 tzurlparam = *(";" other-param) 4878 Example: The following is an example of this property: 4880 TZURL:http://timezones.example.org/tz/America-Los_Angeles.ics 4882 3.8.4. Relationship Component Properties 4884 The following properties specify relationship information in calendar 4885 components. 4887 3.8.4.1. Attendee 4889 Property Name: ATTENDEE 4891 Purpose: This property defines an "Attendee" within a calendar 4892 component. 4894 Value Type: CAL-ADDRESS 4896 Property Parameters: IANA, non-standard, language, calendar user 4897 type, group or list membership, participation role, participation 4898 status, RSVP expectation, delegatee, delegator, sent by, common 4899 name or directory entry reference property parameters can be 4900 specified on this property. 4902 Conformance: This property MUST be specified in an iCalendar object 4903 that specifies a group scheduled calendar entity. This property 4904 MUST NOT be specified in an iCalendar object when publishing the 4905 calendar information (e.g., NOT in an iCalendar object that 4906 specifies the publication of a calendar user's busy time, event, 4907 to-do or journal). This property is not specified in an iCalendar 4908 object that specifies only a time zone definition or that defines 4909 calendar components that are not group scheduled components, but 4910 are components only on a single user's calendar. 4912 Description: This property MUST only be specified within calendar 4913 components to specify participants, non-participants and the chair 4914 of a group scheduled calendar entity. The property is specified 4915 within an "EMAIL" category of the "VALARM" calendar component to 4916 specify an email address that is to receive the email type of 4917 iCalendar alarm. 4919 The property parameter "CN" is for the common or displayable name 4920 associated with the calendar address; "ROLE", for the intended 4921 role that the attendee will have in the calendar component; 4922 "PARTSTAT", for the status of the attendee's participation; 4923 "RSVP", for indicating whether the favor of a reply is requested; 4924 "CUTYPE", to indicate the type of calendar user; "MEMBER", to 4925 indicate the groups that the attendee belongs to; "DELEGATED-TO", 4926 to indicate the calendar users that the original request was 4927 delegated to; and "DELEGATED-FROM", to indicate whom the request 4928 was delegated from; "SENT-BY", to indicate whom is acting on 4929 behalf of the "ATTENDEE"; and "DIR", to indicate the URI that 4930 points to the directory information corresponding to the attendee. 4931 These property parameters can be specified on an "ATTENDEE" 4932 property in either a "VEVENT", "VTODO" or "VJOURNAL" calendar 4933 component. They MUST NOT be specified in an "ATTENDEE" property 4934 in a "VFREEBUSY" or "VALARM" calendar component. If the 4935 "LANGUAGE" property parameter is specified, the identified 4936 language applies to the "CN" parameter. 4938 A recipient delegated a request MUST inherit the "RSVP" and "ROLE" 4939 values from the attendee that delegated the request to them. 4941 Multiple attendees can be specified by including multiple 4942 "ATTENDEE" properties within the calendar component. 4944 Format Definition: This property is defined by the following 4945 notation: 4947 attendee = "ATTENDEE" attparam ":" cal-address CRLF 4949 attparam = *( 4951 ; the following are OPTIONAL, 4952 ; but MUST NOT occur more than once 4954 (";" cutypeparam) / (";" memberparam) / 4955 (";" roleparam) / (";" partstatparam) / 4956 (";" rsvpparam) / (";" deltoparam) / 4957 (";" delfromparam) / (";" sentbyparam) / 4958 (";" cnparam) / (";" dirparam) / 4959 (";" languageparam) / 4961 ; the following is OPTIONAL, 4962 ; and MAY occur more than once 4964 (";" other-param) 4966 ) 4968 Example: The following are examples of this property's use for a 4969 to-do: 4971 ATTENDEE;MEMBER="mailto:DEV-GROUP@example.com": 4972 mailto:joecool@example.com 4973 ATTENDEE;DELEGATED-FROM="mailto:immud@example.com": 4974 mailto:ildoit@example.com 4976 The following is an example of this property used for specifying 4977 multiple attendees to an event: 4979 ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;CN=Henry 4980 Cabot:mailto:hcabot@example.com 4981 ATTENDEE;ROLE=REQ-PARTICIPANT;DELEGATED-FROM="mailto:bob@ 4982 example.com";PARTSTAT=ACCEPTED;CN=Jane Doe:mailto:jdoe@ 4983 example.com 4985 The following is an example of this property with a URI to the 4986 directory information associated with the attendee: 4988 ATTENDEE;CN=John Smith;DIR="ldap://example.com:6666/o=ABC% 4989 20Industries,c=US???(cn=Jim%20Dolittle)":mailto:jimdo@ 4990 example.com 4992 The following is an example of this property with "delegatee" and 4993 "delegator" information for an event: 4995 ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;DELEGATED-FROM= 4996 "mailto:iamboss@example.com";CN=Henry Cabot:mailto:hcabot@ 4997 example.com 4998 ATTENDEE;ROLE=NON-PARTICIPANT;PARTSTAT=DELEGATED;DELEGATED-TO= 4999 "mailto:hcabot@example.com";CN=The Big Cheese:mailto:iamboss 5000 @example.com 5001 ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;CN=Jane Doe 5002 :mailto:jdoe@example.com 5004 Example: The following is an example of this property's use when 5005 another calendar user is acting on behalf of the "Attendee": 5007 ATTENDEE;SENT-BY=mailto:jan_doe@example.com;CN=John Smith: 5008 mailto:jsmith@example.com 5010 3.8.4.2. Contact 5012 Property Name: CONTACT 5014 Purpose: This property is used to represent contact information or 5015 alternately a reference to contact information associated with the 5016 calendar component. 5018 Value Type: TEXT 5020 Property Parameters: IANA, non-standard, alternate text 5021 representation and language property parameters can be specified 5022 on this property. 5024 Conformance: This property can be specified in a "VEVENT", "VTODO", 5025 "VJOURNAL" or "VFREEBUSY" calendar component. 5027 Description: The property value consists of textual contact 5028 information. An alternative representation for the property value 5029 can also be specified that refers to a URI pointing to an 5030 alternate form, such as a vCard [RFC2426], for the contact 5031 information. 5033 Format Definition: This property is defined by the following 5034 notation: 5036 contact = "CONTACT" contparam ":" text CRLF 5038 contparam = *( 5039 ; the following are OPTIONAL, 5040 ; but MUST NOT occur more than once 5042 (";" altrepparam) / (";" languageparam) / 5044 ; the following is OPTIONAL, 5045 ; and MAY occur more than once 5047 (";" other-param) 5049 ) 5051 Example: The following is an example of this property referencing 5052 textual contact information: 5054 CONTACT:Jim Dolittle\, ABC Industries\, +1-919-555-1234 5056 The following is an example of this property with an alternate 5057 representation of a LDAP URI to a directory entry containing the 5058 contact information: 5060 CONTACT;ALTREP="ldap://example.com:6666/o=ABC%20Industries\, 5061 c=US???(cn=Jim%20Dolittle)":Jim Dolittle\, ABC Industries\, 5062 +1-919-555-1234 5064 The following is an example of this property with an alternate 5065 representation of a MIME body part containing the contact 5066 information, such as a vCard [RFC2426] embedded in a text/ 5067 directory media type [RFC2425]: 5069 CONTACT;ALTREP="CID:part3.msg970930T083000SILVER@example.com": 5070 Jim Dolittle\, ABC Industries\, +1-919-555-1234 5072 The following is an example of this property referencing a network 5073 resource, such as a vCard [RFC2426] object containing the contact 5074 information: 5076 CONTACT;ALTREP="http://example.com/pdi/jdoe.vcf":Jim 5077 Dolittle\, ABC Industries\, +1-919-555-1234 5079 3.8.4.3. Organizer 5080 Property Name: ORGANIZER 5082 Purpose: This property defines the organizer for a calendar 5083 component. 5085 Value Type: CAL-ADDRESS 5087 Property Parameters: IANA, non-standard, language, common name, 5088 directory entry reference, sent by property parameters can be 5089 specified on this property. 5091 Conformance: This property MUST be specified in an iCalendar object 5092 that specifies a group scheduled calendar entity. This property 5093 MUST be specified in an iCalendar object that specifies the 5094 publication of a calendar user's busy time. This property MUST 5095 NOT be specified in an iCalendar object that specifies only a time 5096 zone definition or that defines calendar components that are not 5097 group scheduled components, but are components only on a single 5098 user's calendar. 5100 Description: This property is specified within the "VEVENT", 5101 "VTODO", "VJOURNAL" calendar components to specify the organizer 5102 of a group scheduled calendar entity. The property is specified 5103 within the "VFREEBUSY" calendar component to specify the calendar 5104 user requesting the free or busy time. When publishing a 5105 "VFREEBUSY" calendar component, the property is used to specify 5106 the calendar that the published busy time came from. 5108 The property has the property parameters "CN", for specifying the 5109 common or display name associated with the "Organizer", "DIR", for 5110 specifying a pointer to the directory information associated with 5111 the "Organizer", "SENT-BY", for specifying another calendar user 5112 that is acting on behalf of the "Organizer". The non-standard 5113 parameters may also be specified on this property. If the 5114 "LANGUAGE" property parameter is specified, the identified 5115 language applies to the "CN" parameter value. 5117 Format Definition: This property is defined by the following 5118 notation: 5120 organizer = "ORGANIZER" orgparam ":" 5121 cal-address CRLF 5123 orgparam = *( 5125 ; the following are OPTIONAL, 5126 ; but MUST NOT occur more than once 5128 (";" cnparam) / (";" dirparam) / (";" sentbyparam) / 5129 (";" languageparam) / 5131 ; the following is OPTIONAL, 5132 ; and MAY occur more than once 5134 (";" other-param) 5136 ) 5138 Example: The following is an example of this property: 5140 ORGANIZER;CN=John Smith:mailto:jsmith@example.com 5142 The following is an example of this property with a pointer to the 5143 directory information associated with the organizer: 5145 ORGANIZER;CN=JohnSmith;DIR="ldap://example.com:6666/o=DC%20Ass 5146 ociates,c=US???(cn=John%20Smith)":mailto:jsmith@example.com 5148 The following is an example of this property used by another 5149 calendar user who is acting on behalf of the organizer, with 5150 responses intended to be sent back to the organizer, not the other 5151 calendar user: 5153 ORGANIZER;SENT-BY="mailto:jane_doe@example.com": 5154 mailto:jsmith@example.com 5156 3.8.4.4. Recurrence ID 5158 Property Name: RECURRENCE-ID 5160 Purpose: This property is used in conjunction with the "UID" and 5161 "SEQUENCE" property to identify a specific instance of a recurring 5162 "VEVENT", "VTODO" or "VJOURNAL" calendar component. The property 5163 value is the original value of the "DTSTART" property of the 5164 recurrence instance. 5166 Value Type: The default value type for this property is DATE-TIME. 5167 The time format can be any of the valid forms defined for a DATE- 5168 TIME value type. See DATE-TIME value type definition for specific 5169 interpretations of the various forms. The value type can be set 5170 to DATE. 5172 Property Parameters: IANA, non-standard, value data type, time zone 5173 identifier and recurrence identifier range parameters can be 5174 specified on this property. 5176 Conformance: This property can be specified in an iCalendar object 5177 containing a recurring calendar component. 5179 Description: The full range of calendar components specified by a 5180 recurrence set is referenced by referring to just the "UID" 5181 property value corresponding to the calendar component. The 5182 "RECURRENCE-ID" property allows the reference to an individual 5183 instance within the recurrence set. 5185 If the value of the "DTSTART" property is a DATE type value, then 5186 the value MUST be the calendar date for the recurrence instance. 5188 The date/time value is set to the time when the original 5189 recurrence instance would occur; meaning that if the intent is to 5190 change a Friday meeting to Thursday, the date/time is still set to 5191 the original Friday meeting. 5193 The "RECURRENCE-ID" property is used in conjunction with the "UID" 5194 and "SEQUENCE" property to identify a particular instance of a 5195 recurring event, to-do or journal. For a given pair of "UID" and 5196 "SEQUENCE" property values, the "RECURRENCE-ID" value for a 5197 recurrence instance is fixed. 5199 The "RANGE" parameter is used to specify the effective range of 5200 recurrence instances from the instance specified by the 5201 "RECURRENCE-ID" property value. The value for the range parameter 5202 can only be "THISANDFUTURE" to indicate a range defined by the 5203 given recurrence instance and all subsequent instances. 5204 Subsequent instances are determined by their "RECURRENCE-ID" value 5205 and not their current scheduled start time. Subsequent instances 5206 defined in separate components are not impacted by the given 5207 recurrence instance. When the given recurrence instance is 5208 rescheduled, all subsequent instances are also rescheduled by the 5209 same time difference. For instance, if the given recurrence 5210 instance is rescheduled to start 2 hours later, then all 5211 subsequent instances are also rescheduled 2 hours later. 5212 Similarly, if the duration of the given recurrence instance is 5213 modified, then all subsequence instances are also modified to have 5214 this same duration. 5216 Note: The "RANGE" parameter may not be appropriate to 5217 reschedule specific subsequent instances of complex recurring 5218 calendar component. Assuming an unbounded recurring calendar 5219 component scheduled to occur on Mondays and Wednesdays, the 5220 "RANGE" parameter could not be used to reschedule only the 5221 future Monday instances to occur on Tuesday instead. In such 5222 cases, the calendar application could simply truncate the 5223 unbounded recurring calendar component (i.e., with the "COUNT" 5224 or "UNTIL" rule parts), and create two new unbounded recurring 5225 calendar components for the future instances. 5227 Format Definition: This property is defined by the following 5228 notation: 5230 recurid = "RECURRENCE-ID" ridparam ":" ridval CRLF 5232 ridparam = *( 5234 ; the following are OPTIONAL, 5235 ; but MUST NOT occur more than once 5237 (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / 5238 (";" tzidparam) / (";" rangeparam) / 5240 ; the following is OPTIONAL, 5241 ; and MAY occur more than once 5243 (";" other-param) 5245 ) 5247 ridval = date-time / date 5248 ;Value MUST match value type 5250 Example: The following are examples of this property: 5252 RECURRENCE-ID;VALUE=DATE:19960401 5254 RECURRENCE-ID;RANGE=THISANDFUTURE:19960120T120000Z 5256 3.8.4.5. Related To 5257 Property Name: RELATED-TO 5259 Purpose: This property is used to represent a relationship or 5260 reference between one calendar component and another. 5262 Value Type: TEXT 5264 Property Parameters: IANA, non-standard, and relationship type 5265 property parameters can be specified on this property. 5267 Conformance: This property can be specified in the "VEVENT", "VTODO" 5268 and "VJOURNAL" calendar components. 5270 Description: The property value consists of the persistent, globally 5271 unique identifier of another calendar component. This value would 5272 be represented in a calendar component by the "UID" property. 5274 By default, the property value points to another calendar 5275 component that has a PARENT relationship to the referencing 5276 object. The "RELTYPE" property parameter is used to either 5277 explicitly state the default PARENT relationship type to the 5278 referenced calendar component or to override the default PARENT 5279 relationship type and specify either a CHILD or SIBLING 5280 relationship. The PARENT relationship indicates that the calendar 5281 component is a subordinate of the referenced calendar component. 5282 The CHILD relationship indicates that the calendar component is a 5283 superior of the referenced calendar component. The SIBLING 5284 relationship indicates that the calendar component is a peer of 5285 the referenced calendar component. 5287 Changes to a calendar component referenced by this property can 5288 have an implicit impact on the related calendar component. For 5289 example, if a group event changes its start or end date or time, 5290 then the related, dependent events will need to have their start 5291 and end dates changed in a corresponding way. Similarly, if a 5292 PARENT calendar component is cancelled or deleted, then there is 5293 an implied impact to the related CHILD calendar components. This 5294 property is intended only to provide information on the 5295 relationship of calendar components. It is up to the target 5296 calendar system to maintain any property implications of this 5297 relationship. 5299 Format Definition: This property is defined by the following 5300 notation: 5302 related = "RELATED-TO" relparam ":" text CRLF 5304 relparam = *( 5306 ; the following is OPTIONAL, 5307 ; but MUST NOT occur more than once 5309 (";" reltypeparam) / 5311 ; the following is OPTIONAL, 5312 ; and MAY occur more than once 5314 (";" other-param) 5316 ) 5318 The following is an example of this property: 5320 RELATED-TO:jsmith.part7.19960817T083000.xyzMail@example.com 5322 RELATED-TO:19960401-080045-4000F192713-0052@example.com 5324 3.8.4.6. Uniform Resource Locator 5326 Property Name: URL 5328 Purpose: This property defines a Uniform Resource Locator (URL) 5329 associated with the iCalendar object. 5331 Value Type: URI 5333 Property Parameters: IANA and non-standard property parameters can 5334 be specified on this property. 5336 Conformance: This property can be specified once in the "VEVENT", 5337 "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components. 5339 Description: This property may be used in a calendar component to 5340 convey a location where a more dynamic rendition of the calendar 5341 information associated with the calendar component can be found. 5342 This memo does not attempt to standardize the form of the URI, nor 5343 the format of the resource pointed to by the property value. If 5344 the URL property and Content-Location MIME header are both 5345 specified, they MUST point to the same resource. 5347 Format Definition: This property is defined by the following 5348 notation: 5350 url = "URL" urlparam ":" uri CRLF 5352 urlparam = *(";" other-param) 5354 Example: The following is an example of this property: 5356 URL:http://example.com/pub/calendars/jsmith/mytime.ics 5358 3.8.4.7. Unique Identifier 5360 Property Name: UID 5362 Purpose: This property defines the persistent, globally unique 5363 identifier for the calendar component. 5365 Value Type: TEXT 5367 Property Parameters: IANA and non-standard property parameters can 5368 be specified on this property. 5370 Conformance: The property MUST be specified in the "VEVENT", 5371 "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components. 5373 Description: The "UID" itself MUST be a globally unique identifier. 5374 The generator of the identifier MUST guarantee that the identifier 5375 is unique. There are several algorithms that can be used to 5376 accomplish this. A good method to assure uniqueness is to put the 5377 domain name or a domain literal IP address of the host on which 5378 the identifier was created on the right hand side of an "@", and 5379 on the left hand side, put a combination of the current calendar 5380 date and time of day (i.e., formatted in as a DATE-TIME value) 5381 along with some other currently unique (perhaps sequential) 5382 identifier available on the system (for example, a process id 5383 number). Using a date/time value on the left hand side and a 5384 domain name or domain literal on the right hand side makes it 5385 possible to guarantee uniqueness since no two hosts should be 5386 using the same domain name or IP address at the same time. Though 5387 other algorithms will work, it is RECOMMENDED that the right hand 5388 side contain some domain identifier (either of the host itself or 5389 otherwise) such that the generator of the message identifier can 5390 guarantee the uniqueness of the left hand side within the scope of 5391 that domain. 5393 This is the method for correlating scheduling messages with the 5394 referenced "VEVENT", "VTODO", or "VJOURNAL" calendar component. 5396 The full range of calendar components specified by a recurrence 5397 set is referenced by referring to just the "UID" property value 5398 corresponding to the calendar component. The "RECURRENCE-ID" 5399 property allows the reference to an individual instance within the 5400 recurrence set. 5402 This property is an important method for group scheduling 5403 applications to match requests with later replies, modifications 5404 or deletion requests. Calendaring and scheduling applications 5405 MUST generate this property in "VEVENT", "VTODO" and "VJOURNAL" 5406 calendar components to assure interoperability with other group 5407 scheduling applications. This identifier is created by the 5408 calendar system that generates an iCalendar object. 5410 Implementations MUST be able to receive and persist values of at 5411 least 255 octets for this property but MUST NOT truncate values in 5412 the middle of a UTF-8 multi-octet sequence. 5414 Format Definition: This property is defined by the following 5415 notation: 5417 uid = "UID" uidparam ":" text CRLF 5419 uidparam = *(";" other-param) 5421 Example: The following is an example of this property: 5423 UID:19960401T080045Z-4000F192713-0052@example.com 5425 3.8.5. Recurrence Component Properties 5427 The following properties specify recurrence information in calendar 5428 components. 5430 3.8.5.1. Exception Date/Times 5432 Property Name: EXDATE 5434 Purpose: This property defines the list of date/time exceptions for 5435 recurring events, to-dos, journal entries or time zone 5436 definitions. 5438 Value Type: The default value type for this property is DATE-TIME. 5439 The value type can be set to DATE. 5441 Property Parameters: IANA, non-standard, value data type and time 5442 zone identifier property parameters can be specified on this 5443 property. 5445 Conformance: This property can be specified in recurring "VEVENT", 5446 "VTODO", and "VJOURNAL" calendar components as well as in the 5447 "STANDARD" and "DAYLIGHT" sub-components of the "VTIMEZONE" 5448 calendar component. 5450 Description: The exception dates, if specified, are used in 5451 computing the recurrence set. The recurrence set is the complete 5452 set of recurrence instances for a calendar component. The 5453 recurrence set is generated by considering the initial "DTSTART" 5454 property along with the "RRULE", "RDATE", and "EXDATE" properties 5455 contained within the recurring component. The "DTSTART" property 5456 defines the first instance in the recurrence set. The "DTSTART" 5457 property value SHOULD match the pattern of the recurrence rule, if 5458 specified. The recurrence set generated with a "DTSTART" property 5459 value that doesn't match the pattern of the rule is undefined. 5460 The final recurrence set is generated by gathering all of the 5461 start date-times generated by any of the specified "RRULE" and 5462 "RDATE" properties, and then excluding any start date and times 5463 specified by "EXDATE" properties. This implies that start date 5464 and times specified by "EXDATE" properties take precedence over 5465 those specified by inclusion properties (i.e., "RDATE" and 5466 "RRULE"). When duplicate instances are generated by the "RRULE" 5467 and "RDATE" properties, only one recurrence is considered. 5468 Duplicate instances are ignored. 5470 The "EXDATE" property can be used to exclude the value specified 5471 in "DTSTART". However, in such cases the original "DTSTART" date 5472 MUST still be maintained by the calendaring and scheduling system 5473 because the original "DTSTART" value has inherent usage 5474 dependencies by other properties such as the "RECURRENCE-ID". 5476 Format Definition: This property is defined by the following 5477 notation: 5479 exdate = "EXDATE" exdtparam ":" exdtval *("," exdtval) CRLF 5481 exdtparam = *( 5483 ; the following are OPTIONAL, 5484 ; but MUST NOT occur more than once 5486 (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / 5488 (";" tzidparam) / 5490 ; the following is OPTIONAL, 5491 ; and MAY occur more than once 5493 (";" other-param) 5495 ) 5497 exdtval = date-time / date 5498 ;Value MUST match value type 5500 Example: The following is an example of this property: 5502 EXDATE:19960402T010000Z,19960403T010000Z,19960404T010000Z 5504 3.8.5.2. Recurrence Date/Times 5506 Property Name: RDATE 5508 Purpose: This property defines the list of date/times for recurring 5509 events, to-dos, journal entries or time zone definitions. 5511 Value Type: The default value type for this property is DATE-TIME. 5512 The value type can be set to DATE or PERIOD. 5514 Property Parameters: IANA, non-standard, value data type and time 5515 zone identifier property parameters can be specified on this 5516 property. 5518 Conformance: This property can be specified in recurring "VEVENT", 5519 "VTODO", and "VJOURNAL" calendar components as well as in the 5520 "STANDARD" and "DAYLIGHT" sub-components of the "VTIMEZONE" 5521 calendar component. 5523 Description: This property can appear along with the "RRULE" 5524 property to define an aggregate set of repeating occurrences. 5525 When they both appear in a recurring component, the recurrence 5526 instances are defined by the union of occurrences defined by both 5527 the "RDATE" and "RRULE". 5529 The recurrence dates, if specified, are used in computing the 5530 recurrence set. The recurrence set is the complete set of 5531 recurrence instances for a calendar component. The recurrence set 5532 is generated by considering the initial "DTSTART" property along 5533 with the "RRULE", "RDATE", and "EXDATE" properties contained 5534 within the recurring component. The "DTSTART" property defines 5535 the first instance in the recurrence set. The "DTSTART" property 5536 value SHOULD match the pattern of the recurrence rule, if 5537 specified. The recurrence set generated with a "DTSTART" property 5538 value that doesn't match the pattern of the rule is undefined. 5539 The final recurrence set is generated by gathering all of the 5540 start date-times generated by any of the specified "RRULE" and 5541 "RDATE" properties, and then excluding any start date and times 5542 specified by "EXDATE" properties. This implies that start date/ 5543 times specified by "EXDATE" properties take precedence over those 5544 specified by inclusion properties (i.e., "RDATE" and "RRULE"). 5545 Where duplicate instances are generated by the "RRULE" and "RDATE" 5546 properties, only one recurrence is considered. Duplicate 5547 instances are ignored. 5549 Format Definition: This property is defined by the following 5550 notation: 5552 rdate = "RDATE" rdtparam ":" rdtval *("," rdtval) CRLF 5554 rdtparam = *( 5556 ; the following are OPTIONAL, 5557 ; but MUST NOT occur more than once 5559 (";" "VALUE" "=" ("DATE-TIME" / "DATE" / "PERIOD")) / 5560 (";" tzidparam) / 5562 ; the following is OPTIONAL, 5563 ; and MAY occur more than once 5565 (";" other-param) 5567 ) 5569 rdtval = date-time / date / period 5570 ;Value MUST match value type 5572 Example: The following are examples of this property: 5574 RDATE:19970714T123000Z 5575 RDATE;TZID=America/New_York:19970714T083000 5577 RDATE;VALUE=PERIOD:19960403T020000Z/19960403T040000Z, 5578 19960404T010000Z/PT3H 5580 RDATE;VALUE=DATE:19970101,19970120,19970217,19970421 5581 19970526,19970704,19970901,19971014,19971128,19971129,19971225 5583 3.8.5.3. Recurrence Rule 5585 Property Name: RRULE 5587 Purpose: This property defines a rule or repeating pattern for 5588 recurring events, to-dos, journal entries or time zone 5589 definitions. 5591 Value Type: RECUR 5593 Property Parameters: IANA and non-standard property parameters can 5594 be specified on this property. 5596 Conformance: This property can be specified in recurring "VEVENT", 5597 "VTODO" and "VJOURNAL" calendar components as well as in the 5598 "STANDARD" and "DAYLIGHT" sub-components of the "VTIMEZONE" 5599 calendar component, but it SHOULD NOT be specified more than once. 5600 The recurrence set generated with multiple "RRULE" properties is 5601 undefined. 5603 Description: The recurrence rule, if specified, is used in computing 5604 the recurrence set. The recurrence set is the complete set of 5605 recurrence instances for a calendar component. The recurrence set 5606 is generated by considering the initial "DTSTART" property along 5607 with the "RRULE", "RDATE", and "EXDATE" properties contained 5608 within the recurring component. The "DTSTART" property defines 5609 the first instance in the recurrence set. The "DTSTART" property 5610 value SHOULD be synchronized with the recurrence rule, if 5611 specified. The recurrence set generated with a "DTSTART" property 5612 value not synchronized with the recurrence rule is undefined. The 5613 final recurrence set is generated by gathering all of the start 5614 date/times generated by any of the specified "RRULE" and "RDATE" 5615 properties, and then excluding any start date/times specified by 5616 "EXDATE" properties. This implies that start date/times specified 5617 by "EXDATE" properties take precedence over those specified by 5618 inclusion properties (i.e., "RDATE" and "RRULE"). Where duplicate 5619 instances are generated by the "RRULE" and "RDATE" properties, 5620 only one recurrence is considered. Duplicate instances are 5621 ignored. 5623 The "DTSTART" property specified within the iCalendar object 5624 defines the first instance of the recurrence. In most cases, a 5625 "DTSTART" property of DATE-TIME value type used with a recurrence 5626 rule, should be specified as a date with local time and time zone 5627 reference to make sure all the recurrence instances start at the 5628 same local time regardless of time zone changes. 5630 If the duration of the recurring component is specified with the 5631 "DTEND" or "DUE" property, then the same exact duration will apply 5632 to all the members of the generated recurrence set. Else, if the 5633 duration of the recurring component is specified with the 5634 "DURATION" property, then the same nominal duration will apply to 5635 all the members of the generated recurrence set and the exact 5636 duration of each recurrence instance will depend on its specific 5637 start time. For example, recurrence instances of a nominal 5638 duration of one day will have an exact duration of more or less 5639 than 24 hours on a day where a time zone shift occurs. The 5640 duration of a specific recurrence may be modified in an exception 5641 component or simply by using an "RDATE" property of PERIOD value 5642 type. 5644 Format Definition: This property is defined by the following 5645 notation: 5647 rrule = "RRULE" rrulparam ":" recur CRLF 5649 rrulparam = *(";" other-param) 5651 Example: All examples assume the Eastern United States time zone. 5653 Daily for 10 occurrences: 5655 DTSTART;TZID=America/New_York:19970902T090000 5656 RRULE:FREQ=DAILY;COUNT=10 5658 ==> (1997 9:00 AM EDT) September 2-11 5660 Daily until December 24, 1997: 5662 DTSTART;TZID=America/New_York:19970902T090000 5663 RRULE:FREQ=DAILY;UNTIL=19971224T000000Z 5665 ==> (1997 9:00 AM EDT) September 2-30;October 1-25 5666 (1997 9:00 AM EST) October 26-31;November 1-30;December 1-23 5668 Every other day - forever: 5670 DTSTART;TZID=America/New_York:19970902T090000 5671 RRULE:FREQ=DAILY;INTERVAL=2 5673 ==> (1997 9:00 AM EDT) September 2,4,6,8...24,26,28,30; 5674 October 2,4,6...20,22,24 5675 (1997 9:00 AM EST) October 26,28,30; 5676 November 1,3,5,7...25,27,29; 5677 December 1,3,... 5679 Every 10 days, 5 occurrences: 5681 DTSTART;TZID=America/New_York:19970902T090000 5682 RRULE:FREQ=DAILY;INTERVAL=10;COUNT=5 5684 ==> (1997 9:00 AM EDT) September 2,12,22; 5685 October 2,12 5687 Everyday in January, for 3 years: 5689 DTSTART;TZID=America/New_York:19980101T090000 5691 RRULE:FREQ=YEARLY;UNTIL=20000131T140000Z; 5692 BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA 5693 or 5694 RRULE:FREQ=DAILY;UNTIL=20000131T140000Z;BYMONTH=1 5696 ==> (1998 9:00 AM EST)January 1-31 5697 (1999 9:00 AM EST)January 1-31 5698 (2000 9:00 AM EST)January 1-31 5700 Weekly for 10 occurrences 5702 DTSTART;TZID=America/New_York:19970902T090000 5703 RRULE:FREQ=WEEKLY;COUNT=10 5705 ==> (1997 9:00 AM EDT) September 2,9,16,23,30;October 7,14,21 5706 (1997 9:00 AM EST) October 28;November 4 5708 Weekly until December 24, 1997 5709 DTSTART;TZID=America/New_York:19970902T090000 5710 RRULE:FREQ=WEEKLY;UNTIL=19971224T000000Z 5712 ==> (1997 9:00 AM EDT) September 2,9,16,23,30; 5713 October 7,14,21 5714 (1997 9:00 AM EST) October 28; 5715 November 4,11,18,25; 5716 December 2,9,16,23 5718 Every other week - forever: 5720 DTSTART;TZID=America/New_York:19970902T090000 5721 RRULE:FREQ=WEEKLY;INTERVAL=2;WKST=SU 5723 ==> (1997 9:00 AM EDT) September 2,16,30; 5724 October 14 5725 (1997 9:00 AM EST) October 28; 5726 November 11,25; 5727 December 9,23 5728 (1998 9:00 AM EST) January 6,20; 5729 February 3, 17 5730 ... 5732 Weekly on Tuesday and Thursday for 5 weeks: 5734 DTSTART;TZID=America/New_York:19970902T090000 5735 RRULE:FREQ=WEEKLY;UNTIL=19971007T000000Z;WKST=SU;BYDAY=TU,TH 5737 or 5739 RRULE:FREQ=WEEKLY;COUNT=10;WKST=SU;BYDAY=TU,TH 5741 ==> (1997 9:00 AM EDT) September 2,4,9,11,16,18,23,25,30; 5742 October 2 5744 Every other week on Monday, Wednesday and Friday until December 5745 24, 1997, starting on Monday, September 1, 1997: 5747 DTSTART;TZID=America/New_York:19970901T090000 5748 RRULE:FREQ=WEEKLY;INTERVAL=2;UNTIL=19971224T000000Z;WKST=SU; 5749 BYDAY=MO,WE,FR 5751 ==> (1997 9:00 AM EDT) September 1,3,5,15,17,19,29; 5752 October 1,3,13,15,17 5753 (1997 9:00 AM EST) October 27,29,31; 5754 November 10,12,14,24,26,28; 5755 December 8,10,12,22 5757 Every other week on Tuesday and Thursday, for 8 occurrences: 5759 DTSTART;TZID=America/New_York:19970902T090000 5760 RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=8;WKST=SU;BYDAY=TU,TH 5762 ==> (1997 9:00 AM EDT) September 2,4,16,18,30; 5763 October 2,14,16 5765 Monthly on the 1st Friday for ten occurrences: 5767 DTSTART;TZID=America/New_York:19970905T090000 5768 RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR 5770 ==> (1997 9:00 AM EDT) September 5;October 3 5771 (1997 9:00 AM EST) November 7;December 5 5772 (1998 9:00 AM EST) January 2;February 6;March 6;April 3 5773 (1998 9:00 AM EDT) May 1;June 5 5775 Monthly on the 1st Friday until December 24, 1997: 5777 DTSTART;TZID=America/New_York:19970905T090000 5778 RRULE:FREQ=MONTHLY;UNTIL=19971224T000000Z;BYDAY=1FR 5780 ==> (1997 9:00 AM EDT) September 5; October 3 5781 (1997 9:00 AM EST) November 7; December 5 5783 Every other month on the 1st and last Sunday of the month for 10 5784 occurrences: 5786 DTSTART;TZID=America/New_York:19970907T090000 5787 RRULE:FREQ=MONTHLY;INTERVAL=2;COUNT=10;BYDAY=1SU,-1SU 5789 ==> (1997 9:00 AM EDT) September 7,28 5790 (1997 9:00 AM EST) November 2,30 5791 (1998 9:00 AM EST) January 4,25;March 1,29 5792 (1998 9:00 AM EDT) May 3,31 5794 Monthly on the second to last Monday of the month for 6 months: 5796 DTSTART;TZID=America/New_York:19970922T090000 5797 RRULE:FREQ=MONTHLY;COUNT=6;BYDAY=-2MO 5799 ==> (1997 9:00 AM EDT) September 22;October 20 5800 (1997 9:00 AM EST) November 17;December 22 5801 (1998 9:00 AM EST) January 19;February 16 5803 Monthly on the third to the last day of the month, forever: 5805 DTSTART;TZID=America/New_York:19970928T090000 5806 RRULE:FREQ=MONTHLY;BYMONTHDAY=-3 5808 ==> (1997 9:00 AM EDT) September 28 5809 (1997 9:00 AM EST) October 29;November 28;December 29 5810 (1998 9:00 AM EST) January 29;February 26 5811 ... 5813 Monthly on the 2nd and 15th of the month for 10 occurrences: 5815 DTSTART;TZID=America/New_York:19970902T090000 5816 RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=2,15 5818 ==> (1997 9:00 AM EDT) September 2,15;October 2,15 5819 (1997 9:00 AM EST) November 2,15;December 2,15 5820 (1998 9:00 AM EST) January 2,15 5822 Monthly on the first and last day of the month for 10 occurrences: 5824 DTSTART;TZID=America/New_York:19970930T090000 5825 RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=1,-1 5827 ==> (1997 9:00 AM EDT) September 30;October 1 5828 (1997 9:00 AM EST) October 31;November 1,30;December 1,31 5829 (1998 9:00 AM EST) January 1,31;February 1 5831 Every 18 months on the 10th thru 15th of the month for 10 5832 occurrences: 5834 DTSTART;TZID=America/New_York:19970910T090000 5835 RRULE:FREQ=MONTHLY;INTERVAL=18;COUNT=10;BYMONTHDAY=10,11,12, 5836 13,14,15 5838 ==> (1997 9:00 AM EDT) September 10,11,12,13,14,15 5839 (1999 9:00 AM EST) March 10,11,12,13 5841 Every Tuesday, every other month: 5843 DTSTART;TZID=America/New_York:19970902T090000 5844 RRULE:FREQ=MONTHLY;INTERVAL=2;BYDAY=TU 5846 ==> (1997 9:00 AM EDT) September 2,9,16,23,30 5847 (1997 9:00 AM EST) November 4,11,18,25 5848 (1998 9:00 AM EST) January 6,13,20,27;March 3,10,17,24,31 5849 ... 5851 Yearly in June and July for 10 occurrences: 5853 DTSTART;TZID=America/New_York:19970610T090000 5854 RRULE:FREQ=YEARLY;COUNT=10;BYMONTH=6,7 5856 ==> (1997 9:00 AM EDT) June 10;July 10 5857 (1998 9:00 AM EDT) June 10;July 10 5858 (1999 9:00 AM EDT) June 10;July 10 5859 (2000 9:00 AM EDT) June 10;July 10 5860 (2001 9:00 AM EDT) June 10;July 10 5862 Note: Since none of the BYDAY, BYMONTHDAY or BYYEARDAY 5863 components are specified, the day is gotten from "DTSTART" 5865 Every other year on January, February, and March for 10 5866 occurrences: 5868 DTSTART;TZID=America/New_York:19970310T090000 5869 RRULE:FREQ=YEARLY;INTERVAL=2;COUNT=10;BYMONTH=1,2,3 5871 ==> (1997 9:00 AM EST) March 10 5872 (1999 9:00 AM EST) January 10;February 10;March 10 5873 (2001 9:00 AM EST) January 10;February 10;March 10 5874 (2003 9:00 AM EST) January 10;February 10;March 10 5876 Every 3rd year on the 1st, 100th and 200th day for 10 occurrences: 5878 DTSTART;TZID=America/New_York:19970101T090000 5879 RRULE:FREQ=YEARLY;INTERVAL=3;COUNT=10;BYYEARDAY=1,100,200 5881 ==> (1997 9:00 AM EST) January 1 5882 (1997 9:00 AM EDT) April 10;July 19 5883 (2000 9:00 AM EST) January 1 5884 (2000 9:00 AM EDT) April 9;July 18 5885 (2003 9:00 AM EST) January 1 5886 (2003 9:00 AM EDT) April 10;July 19 5887 (2006 9:00 AM EST) January 1 5889 Every 20th Monday of the year, forever: 5891 DTSTART;TZID=America/New_York:19970519T090000 5892 RRULE:FREQ=YEARLY;BYDAY=20MO 5894 ==> (1997 9:00 AM EDT) May 19 5895 (1998 9:00 AM EDT) May 18 5896 (1999 9:00 AM EDT) May 17 5897 ... 5899 Monday of week number 20 (where the default start of the week is 5900 Monday), forever: 5902 DTSTART;TZID=America/New_York:19970512T090000 5903 RRULE:FREQ=YEARLY;BYWEEKNO=20;BYDAY=MO 5905 ==> (1997 9:00 AM EDT) May 12 5906 (1998 9:00 AM EDT) May 11 5907 (1999 9:00 AM EDT) May 17 5908 ... 5910 Every Thursday in March, forever: 5912 DTSTART;TZID=America/New_York:19970313T090000 5913 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=TH 5915 ==> (1997 9:00 AM EST) March 13,20,27 5916 (1998 9:00 AM EST) March 5,12,19,26 5917 (1999 9:00 AM EST) March 4,11,18,25 5918 ... 5920 Every Thursday, but only during June, July, and August, forever: 5922 DTSTART;TZID=America/New_York:19970605T090000 5923 RRULE:FREQ=YEARLY;BYDAY=TH;BYMONTH=6,7,8 5925 ==> (1997 9:00 AM EDT) June 5,12,19,26;July 3,10,17,24,31; 5926 August 7,14,21,28 5927 (1998 9:00 AM EDT) June 4,11,18,25;July 2,9,16,23,30; 5928 August 6,13,20,27 5929 (1999 9:00 AM EDT) June 3,10,17,24;July 1,8,15,22,29; 5930 August 5,12,19,26 5931 ... 5933 Every Friday the 13th, forever: 5935 DTSTART;TZID=America/New_York:19970902T090000 5936 EXDATE;TZID=America/New_York:19970902T090000 5937 RRULE:FREQ=MONTHLY;BYDAY=FR;BYMONTHDAY=13 5939 ==> (1998 9:00 AM EST) February 13;March 13;November 13 5940 (1999 9:00 AM EDT) August 13 5941 (2000 9:00 AM EDT) October 13 5942 ... 5944 The first Saturday that follows the first Sunday of the month, 5945 forever: 5947 DTSTART;TZID=America/New_York:19970913T090000 5948 RRULE:FREQ=MONTHLY;BYDAY=SA;BYMONTHDAY=7,8,9,10,11,12,13 5950 ==> (1997 9:00 AM EDT) September 13;October 11 5951 (1997 9:00 AM EST) November 8;December 13 5952 (1998 9:00 AM EST) January 10;February 7;March 7 5953 (1998 9:00 AM EDT) April 11;May 9;June 13... 5954 ... 5956 Every four years, the first Tuesday after a Monday in November, 5957 forever (U.S. Presidential Election day): 5959 DTSTART;TZID=America/New_York:19961105T090000 5960 RRULE:FREQ=YEARLY;INTERVAL=4;BYMONTH=11;BYDAY=TU; 5961 BYMONTHDAY=2,3,4,5,6,7,8 5963 ==> (1996 9:00 AM EST) November 5 5964 (2000 9:00 AM EST) November 7 5965 (2004 9:00 AM EST) November 2 5966 ... 5968 The 3rd instance into the month of one of Tuesday, Wednesday or 5969 Thursday, for the next 3 months: 5971 DTSTART;TZID=America/New_York:19970904T090000 5972 RRULE:FREQ=MONTHLY;COUNT=3;BYDAY=TU,WE,TH;BYSETPOS=3 5974 ==> (1997 9:00 AM EDT) September 4;October 7 5975 (1997 9:00 AM EST) November 6 5977 The 2nd to last weekday of the month: 5979 DTSTART;TZID=America/New_York:19970929T090000 5980 RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-2 5982 ==> (1997 9:00 AM EDT) September 29 5983 (1997 9:00 AM EST) October 30;November 27;December 30 5984 (1998 9:00 AM EST) January 29;February 26;March 30 5985 ... 5987 Every 3 hours from 9:00 AM to 5:00 PM on a specific day: 5989 DTSTART;TZID=America/New_York:19970902T090000 5990 RRULE:FREQ=HOURLY;INTERVAL=3;UNTIL=19970902T170000Z 5991 ==> (September 2, 1997 EDT) 09:00,12:00,15:00 5993 Every 15 minutes for 6 occurrences: 5995 DTSTART;TZID=America/New_York:19970902T090000 5996 RRULE:FREQ=MINUTELY;INTERVAL=15;COUNT=6 5998 ==> (September 2, 1997 EDT) 09:00,09:15,09:30,09:45,10:00,10:15 6000 Every hour and a half for 4 occurrences: 6002 DTSTART;TZID=America/New_York:19970902T090000 6003 RRULE:FREQ=MINUTELY;INTERVAL=90;COUNT=4 6005 ==> (September 2, 1997 EDT) 09:00,10:30;12:00;13:30 6007 Every 20 minutes from 9:00 AM to 4:40 PM every day: 6009 DTSTART;TZID=America/New_York:19970902T090000 6010 RRULE:FREQ=DAILY;BYHOUR=9,10,11,12,13,14,15,16;BYMINUTE=0,20,40 6011 or 6012 RRULE:FREQ=MINUTELY;INTERVAL=20;BYHOUR=9,10,11,12,13,14,15,16 6014 ==> (September 2, 1997 EDT) 9:00,9:20,9:40,10:00,10:20, 6015 ... 16:00,16:20,16:40 6016 (September 3, 1997 EDT) 9:00,9:20,9:40,10:00,10:20, 6017 ...16:00,16:20,16:40 6018 ... 6020 An example where the days generated makes a difference because of 6021 WKST: 6023 DTSTART;TZID=America/New_York:19970805T090000 6024 RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=4;BYDAY=TU,SU;WKST=MO 6026 ==> (1997 EDT) August 5,10,19,24 6028 changing only WKST from MO to SU, yields different results... 6030 DTSTART;TZID=America/New_York:19970805T090000 6031 RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=4;BYDAY=TU,SU;WKST=SU 6033 ==> (1997 EDT) August 5,17,19,31 6035 An example where an invalid date (i.e., February 30) is ignored. 6037 DTSTART;TZID=America/New_York:20070115T090000 6038 RRULE:FREQ=MONTHLY;BYMONTHDAY=15,30;COUNT=5 6040 ==> (2007 EST) January 15,30 6041 (2007 EST) February 15 6042 (2007 EDT) March 15,30 6044 3.8.6. Alarm Component Properties 6046 The following properties specify alarm information in calendar 6047 components. 6049 3.8.6.1. Action 6051 Property Name: ACTION 6053 Purpose: This property defines the action to be invoked when an 6054 alarm is triggered. 6056 Value Type: TEXT 6058 Property Parameters: IANA and non-standard property parameters can 6059 be specified on this property. 6061 Conformance: This property MUST be specified once in a "VALARM" 6062 calendar component. 6064 Description: Each "VALARM" calendar component has a particular type 6065 of action associated with it. This property specifies the type of 6066 action. Applications MUST ignore alarms with x-name and iana- 6067 token value they don't recognize. 6069 Format Definition: This property is defined by the following 6070 notation: 6072 action = "ACTION" actionparam ":" actionvalue CRLF 6074 actionparam = *(";" other-param) 6076 actionvalue = "AUDIO" / "DISPLAY" / "EMAIL" 6077 / iana-token / x-name 6079 Example: The following are examples of this property in a "VALARM" 6080 calendar component: 6082 ACTION:AUDIO 6084 ACTION:DISPLAY 6086 3.8.6.2. Repeat Count 6088 Property Name: REPEAT 6090 Purpose: This property defines the number of times the alarm should 6091 be repeated, after the initial trigger. 6093 Value Type: INTEGER 6095 Property Parameters: IANA and non-standard property parameters can 6096 be specified on this property. 6098 Conformance: This property can be specified in a "VALARM" calendar 6099 component. 6101 Description: This property defines the number of time an alarm 6102 should be repeated after its initial trigger. If the alarm 6103 triggers more than once, then this property MUST be specified 6104 along with the "DURATION" property. 6106 Format Definition: This property is defined by the following 6107 notation: 6109 repeat = "REPEAT" repparam ":" integer CRLF 6110 ;Default is "0", zero. 6112 repparam = *(";" other-param) 6114 Example: The following is an example of this property for an alarm 6115 that repeats 4 additional times with a 5 minute delay after the 6116 initial triggering of the alarm: 6118 REPEAT:4 6119 DURATION:PT5M 6121 3.8.6.3. Trigger 6122 Property Name: TRIGGER 6124 Purpose: This property specifies when an alarm will trigger. 6126 Value Type: The default value type is DURATION. The value type can 6127 be set to a DATE-TIME value type, in which case the value MUST 6128 specify a UTC formatted DATE-TIME value. 6130 Property Parameters: IANA, non-standard, value data type, time zone 6131 identifier or trigger relationship property parameters can be 6132 specified on this property. The trigger relationship property 6133 parameter MUST only be specified when the value type is 6134 "DURATION". 6136 Conformance: This property MUST be specified in the "VALARM" 6137 calendar component. 6139 Description: This property defines when an alarm will trigger. The 6140 default value type is DURATION, specifying a relative time for the 6141 trigger of the alarm. The default duration is relative to the 6142 start of an event or to-do that the alarm is associated with. The 6143 duration can be explicitly set to trigger from either the end or 6144 the start of the associated event or to-do with the "RELATED" 6145 parameter. A value of START will set the alarm to trigger off the 6146 start of the associated event or to-do. A value of END will set 6147 the alarm to trigger off the end of the associated event or to-do. 6149 Either a positive or negative duration may be specified for the 6150 "TRIGGER" property. An alarm with a positive duration is 6151 triggered after the associated start or end of the event or to-do. 6152 An alarm with a negative duration is triggered before the 6153 associated start or end of the event or to-do. 6155 The "RELATED" property parameter is not valid if the value type of 6156 the property is set to DATE-TIME (i.e., for an absolute date and 6157 time alarm trigger). If a value type of DATE-TIME is specified, 6158 then the property value MUST be specified in the UTC time format. 6159 If an absolute trigger is specified on an alarm for a recurring 6160 event or to-do, then the alarm will only trigger for the specified 6161 absolute date/time, along with any specified repeating instances. 6163 If the trigger is set relative to START, then the "DTSTART" 6164 property MUST be present in the associated "VEVENT" or "VTODO" 6165 calendar component. If an alarm is specified for an event with 6166 the trigger set relative to the END, then the "DTEND" property or 6167 the "DTSTART" and "DURATION " properties MUST be present in the 6168 associated "VEVENT" calendar component. If the alarm is specified 6169 for a to-do with a trigger set relative to the END, then either 6170 the "DUE" property or the "DTSTART" and "DURATION " properties 6171 MUST be present in the associated "VTODO" calendar component. 6173 Alarms specified in an event or to-do which is defined in terms of 6174 a DATE value type will be triggered relative to 00:00:00 of the 6175 user's configured time zone on the specified date, or relative to 6176 00:00:00 UTC on the specified date if no configured time zone can 6177 be found for the user. For example, if "DTSTART" is a DATE value 6178 set to 19980205 then the duration trigger will be relative to 6179 19980205T000000 America/New_York for a user configured with the 6180 America/New_York time zone. 6182 Format Definition: This property is defined by the following 6183 notation: 6185 trigger = "TRIGGER" (trigrel / trigabs) CRLF 6187 trigrel = *( 6189 ; the following are OPTIONAL, 6190 ; but MUST NOT occur more than once 6192 (";" "VALUE" "=" "DURATION") / 6193 (";" trigrelparam) / 6195 ; the following is OPTIONAL, 6196 ; and MAY occur more than once 6198 (";" other-param) 6199 ) ":" dur-value 6201 trigabs = *( 6203 ; the following is REQUIRED, 6204 ; but MUST NOT occur more than once 6206 (";" "VALUE" "=" "DATE-TIME") / 6208 ; the following is OPTIONAL, 6209 ; and MAY occur more than once 6211 (";" other-param) 6213 ) ":" date-time 6215 Example: A trigger set 15 minutes prior to the start of the event or 6216 to-do. 6218 TRIGGER:-PT15M 6220 A trigger set 5 minutes after the end of an event or the due date 6221 of a to-do. 6223 TRIGGER;RELATED=END:PT5M 6225 A trigger set to an absolute date/time. 6227 TRIGGER;VALUE=DATE-TIME:19980101T050000Z 6229 3.8.7. Change Management Component Properties 6231 The following properties specify change management information in 6232 calendar components. 6234 3.8.7.1. Date/Time Created 6236 Property Name: CREATED 6238 Purpose: This property specifies the date and time that the calendar 6239 information was created by the calendar user agent in the calendar 6240 store. 6242 Note: This is analogous to the creation date and time for a 6243 file in the file system. 6245 Value Type: DATE-TIME 6247 Property Parameters: IANA and non-standard property parameters can 6248 be specified on this property. 6250 Conformance: The property can be specified once in "VEVENT", "VTODO" 6251 or "VJOURNAL" calendar components. The value MUST be specified as 6252 a date with UTC time. 6254 Description: This property specifies the date and time that the 6255 calendar information was created by the calendar user agent in the 6256 calendar store. 6258 Format Definition: This property is defined by the following 6259 notation: 6261 created = "CREATED" creaparam ":" date-time CRLF 6262 creaparam = *(";" other-param) 6264 Example: The following is an example of this property: 6266 CREATED:19960329T133000Z 6268 3.8.7.2. Date/Time Stamp 6270 Property Name: DTSTAMP 6272 Purpose: In the case of an iCalendar object that specifies a 6273 "METHOD" property, this property specifies the date and time that 6274 the instance of the iCalendar object was created. In the case of 6275 an iCalendar object that doesn't specify a "METHOD" property, this 6276 property specifies the date and time that the information 6277 associated with the calendar component was last revised in the 6278 calendar store. 6280 Value Type: DATE-TIME 6282 Property Parameters: IANA and non-standard property parameters can 6283 be specified on this property. 6285 Conformance: This property MUST be included in the "VEVENT", 6286 "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components. 6288 Description: The value MUST be specified in the UTC time format. 6290 This property is also useful to protocols such as 6291 [I-D.ietf-calsify-rfc2447bis] that have inherent latency issues 6292 with the delivery of content. This property will assist in the 6293 proper sequencing of messages containing iCalendar objects. 6295 In the case of an iCalendar object that specifies a "METHOD" 6296 property, this property differs from the "CREATED" and "LAST- 6297 MODIFIED" properties. These two properties are used to specify 6298 when the particular calendar data in the calendar store was 6299 created and last modified. This is different than when the 6300 iCalendar object representation of the calendar service 6301 information was created or last modified. 6303 In the case of an iCalendar object that doesn't specify a "METHOD" 6304 property, this property is equivalent to the "LAST-MODIFIED" 6305 property. 6307 Format Definition: This property is defined by the following 6308 notation: 6310 dtstamp = "DTSTAMP" stmparam ":" date-time CRLF 6312 stmparam = *(";" other-param) 6314 Example: 6316 DTSTAMP:19971210T080000Z 6318 3.8.7.3. Last Modified 6320 Property Name: LAST-MODIFIED 6322 Purpose: This property specifies the date and time that the 6323 information associated with the calendar component was last 6324 revised in the calendar store. 6326 Note: This is analogous to the modification date and time for a 6327 file in the file system. 6329 Value Type: DATE-TIME 6331 Property Parameters: IANA and non-standard property parameters can 6332 be specified on this property. 6334 Conformance: This property can be specified in the "VEVENT", 6335 "VTODO", "VJOURNAL" or "VTIMEZONE" calendar components. 6337 Description: The property value MUST be specified in the UTC time 6338 format. 6340 Format Definition: This property is defined by the following 6341 notation: 6343 last-mod = "LAST-MODIFIED" lstparam ":" date-time CRLF 6345 lstparam = *(";" other-param) 6347 Example: The following is an example of this property: 6349 LAST-MODIFIED:19960817T133000Z 6351 3.8.7.4. Sequence Number 6353 Property Name: SEQUENCE 6355 Purpose: This property defines the revision sequence number of the 6356 calendar component within a sequence of revisions. 6358 Value Type: INTEGER 6360 Property Parameters: IANA and non-standard property parameters can 6361 be specified on this property. 6363 Conformance: The property can be specified in "VEVENT", "VTODO" or 6364 "VJOURNAL" calendar component. 6366 Description: When a calendar component is created, its sequence 6367 number is zero (US-ASCII decimal 48). It is monotonically 6368 incremented by the "Organizer's" CUA each time the "Organizer" 6369 makes a significant revision to the calendar component. 6371 The "Organizer" includes this property in an iCalendar object that 6372 it sends to an "Attendee" to specify the current version of the 6373 calendar component. 6375 The "Attendee" includes this property in an iCalendar object that 6376 it sends to the "Organizer" to specify the version of the calendar 6377 component that the "Attendee" is referring to. 6379 A change to the sequence number is not the mechanism that an 6380 "Organizer" uses to request a response from the "Attendees". The 6381 "RSVP" parameter on the "ATTENDEE" property is used by the 6382 "Organizer" to indicate that a response from the "Attendees" is 6383 requested. 6385 Format Definition: This property is defined by the following 6386 notation: 6388 seq = "SEQUENCE" seqparam ":" integer CRLF 6389 ; Default is "0" 6391 seqparam = *(";" other-param) 6393 Example: The following is an example of this property for a calendar 6394 component that was just created by the "Organizer": 6396 SEQUENCE:0 6398 The following is an example of this property for a calendar 6399 component that has been revised two different times by the 6400 "Organizer": 6402 SEQUENCE:2 6404 3.8.8. Miscellaneous Component Properties 6406 The following properties specify information about a number of 6407 miscellaneous features of calendar components. 6409 3.8.8.1. IANA Properties 6411 Property Name: An IANA registered property name 6413 Value Type: The default value type is TEXT. The value type can be 6414 set to any value type. 6416 Property Parameters: Any parameter can be specified on this 6417 property. 6419 Description: This specification allows other properties registered 6420 with IANA to be specified in any calendar components. Compliant 6421 applications are expected to be able to parse these other IANA 6422 registered properties but can ignore them. 6424 Format Definition: This property is defined by the following 6425 notation: 6427 iana-prop = iana-token *(";" icalparameter) ":" value CRLF 6429 Example: The following are examples of properties that might be 6430 registered to IANA: 6432 DRESSCODE:CASUAL 6434 NON-SMOKING;VALUE=BOOLEAN:TRUE 6436 3.8.8.2. Non-standard Properties 6438 Property Name: Any property name with a "X-" prefix 6440 Purpose: This class of property provides a framework for defining 6441 non-standard properties. 6443 Value Type: The default value type is TEXT. The value type can be 6444 set to any value type. 6446 Property Parameters: IANA, non-standard and language property 6447 parameters can be specified on this property. 6449 Conformance: This property can be specified in any calendar 6450 component. 6452 Description: The MIME Calendaring and Scheduling Content Type 6453 provides a "standard mechanism for doing non-standard things". 6454 This extension support is provided for implementers to "push the 6455 envelope" on the existing version of the memo. Extension 6456 properties are specified by property and/or property parameter 6457 names that have the prefix text of "X-" (the two character 6458 sequence: LATIN CAPITAL LETTER X character followed by the HYPHEN- 6459 MINUS character). It is recommended that vendors concatenate onto 6460 this sentinel another short prefix text to identify the vendor. 6461 This will facilitate readability of the extensions and minimize 6462 possible collision of names between different vendors. User 6463 agents that support this content type are expected to be able to 6464 parse the extension properties and property parameters but can 6465 ignore them. 6467 At present, there is no registration authority for names of 6468 extension properties and property parameters. The value type for 6469 this property is TEXT. Optionally, the value type can be any of 6470 the other valid value types. 6472 Format Definition: This property is defined by the following 6473 notation: 6475 x-prop = x-name *(";" icalparameter) ":" value CRLF 6477 Example: The following might be the ABC vendor's extension for an 6478 audio-clip form of subject property: 6480 X-ABC-MMSUBJ;VALUE=URI;FMTTYPE=audio/basic:http://www.example. 6481 org/mysubj.au 6483 3.8.8.3. Request Status 6485 Property Name: REQUEST-STATUS 6487 Purpose: This property defines the status code returned for a 6488 scheduling request. 6490 Value Type: TEXT 6491 Property Parameters: IANA, non-standard and language property 6492 parameters can be specified on this property. 6494 Conformance: The property can be specified in "VEVENT", "VTODO", 6495 "VJOURNAL" or "VFREEBUSY" calendar component. 6497 Description: This property is used to return status code information 6498 related to the processing of an associated iCalendar object. The 6499 value type for this property is TEXT. 6501 The value consists of a short return status component, a longer 6502 return status description component, and optionally a status- 6503 specific data component. The components of the value are 6504 separated by the SEMICOLON character (US-ASCII decimal 59). 6506 The short return status is a PERIOD character (US-ASCII decimal 6507 46) separated pair or 3-tuple of integers. For example, "3.1" or 6508 "3.1.1". The successive levels of integers provide for a 6509 successive level of status code granularity. 6511 The following are initial classes for the return status code. 6512 Individual iCalendar object methods will define specific return 6513 status codes for these classes. In addition, other classes for 6514 the return status code may be defined using the registration 6515 process defined later in this memo. 6517 |==============+===============================================| 6518 | Short Return | Longer Return Status Description | 6519 | Status Code | | 6520 |==============+===============================================| 6521 | 1.xx | Preliminary success. This class of status | 6522 | | of status code indicates that the request has | 6523 | | request has been initially processed but that | 6524 | | completion is pending. | 6525 |==============+===============================================| 6526 | 2.xx | Successful. This class of status code | 6527 | | indicates that the request was completed | 6528 | | successfuly. However, the exact status code | 6529 | | can indicate that a fallback has been taken. | 6530 |==============+===============================================| 6531 | 3.xx | Client Error. This class of status code | 6532 | | indicates that the request was not successful.| 6533 | | The error is the result of either a syntax or | 6534 | | a semantic error in the client formatted | 6535 | | request. Request should not be retried until | 6536 | | the condition in the request is corrected. | 6537 |==============+===============================================| 6538 | 4.xx | Scheduling Error. This class of status code | 6539 | | indicates that the request was not successful.| 6540 | | Some sort of error occurred within the | 6541 | | calendaring and scheduling service, not | 6542 | | directly related to the request itself. | 6543 |==============+===============================================| 6545 Format Definition: This property is defined by the following 6546 notation: 6548 rstatus = "REQUEST-STATUS" rstatparam ":" 6549 statcode ";" statdesc [";" extdata] 6551 rstatparam = *( 6553 ; the following is OPTIONAL, 6554 ; but MUST NOT occur more than once 6556 (";" languageparam) / 6558 ; the following is OPTIONAL, 6559 ; and MAY occur more than once 6561 (";" other-param) 6563 ) 6565 statcode = 1*DIGIT 1*2("." 1*DIGIT) 6566 ;Hierarchical, numeric return status code 6568 statdesc = text 6569 ;Textual status description 6571 extdata = text 6572 ;Textual exception data. For example, the offending property 6573 ;name and value or complete property line. 6575 Example: The following are some possible examples of this property. 6577 The COMMA and SEMICOLON separator characters in the property value 6578 are BACKSLASH character escaped because they appear in a text 6579 value. 6581 REQUEST-STATUS:2.0;Success 6583 REQUEST-STATUS:3.1;Invalid property value;DTSTART:96-Apr-01 6585 REQUEST-STATUS:2.8; Success\, repeating event ignored. Scheduled 6586 as a single event.;RRULE:FREQ=WEEKLY\;INTERVAL=2 6588 REQUEST-STATUS:4.1;Event conflict. Date/time is busy. 6590 REQUEST-STATUS:3.7;Invalid calendar user;ATTENDEE: 6591 mailto:jsmith@example.com 6593 4. iCalendar Object Examples 6595 The following examples are provided as an informational source of 6596 illustrative iCalendar objects consistent with this content type. 6598 The following example specifies a three-day conference that begins at 6599 2:30 P.M. UTC, September 18, 1996 and end at 10:00 P.M. UTC, 6600 September 20, 1996. 6602 BEGIN:VCALENDAR 6603 PRODID:-//xyz Corp//NONSGML PDA Calendar Version 1.0//EN 6604 VERSION:2.0 6605 BEGIN:VEVENT 6606 DTSTAMP:19960704T120000Z 6607 UID:uid1@example.com 6608 ORGANIZER:mailto:jsmith@example.com 6609 DTSTART:19960918T143000Z 6610 DTEND:19960920T220000Z 6611 STATUS:CONFIRMED 6612 CATEGORIES:CONFERENCE 6613 SUMMARY:Networld+Interop Conference 6614 DESCRIPTION:Networld+Interop Conference 6615 and Exhibit\nAtlanta World Congress Center\n 6616 Atlanta\, Georgia 6617 END:VEVENT 6618 END:VCALENDAR 6620 The following example specifies a group scheduled meeting that begin 6621 at 8:30 AM EST on March 12, 1998 and end at 9:30 AM EST on March 12, 6622 1998. The "Organizer" has scheduled the meeting with one or more 6623 calendar users in a group. A time zone specification for Eastern 6624 United States has been specified. 6626 BEGIN:VCALENDAR 6627 PRODID:-//RDU Software//NONSGML HandCal//EN 6628 VERSION:2.0 6629 BEGIN:VTIMEZONE 6630 TZID:America/New_York 6631 BEGIN:STANDARD 6632 DTSTART:19981025T020000 6633 TZOFFSETFROM:-0400 6634 TZOFFSETTO:-0500 6635 TZNAME:EST 6636 END:STANDARD 6637 BEGIN:DAYLIGHT 6638 DTSTART:19990404T020000 6639 TZOFFSETFROM:-0500 6640 TZOFFSETTO:-0400 6641 TZNAME:EDT 6642 END:DAYLIGHT 6643 END:VTIMEZONE 6644 BEGIN:VEVENT 6645 DTSTAMP:19980309T231000Z 6646 UID:guid-1.example.com 6647 ORGANIZER;ROLE=CHAIR:mailto:mrbig@example.com 6648 ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;CUTYPE=GROUP: 6649 mailto:employee-A@example.com 6650 DESCRIPTION:Project XYZ Review Meeting 6651 CATEGORIES:MEETING 6652 CLASS:PUBLIC 6653 CREATED:19980309T130000Z 6654 SUMMARY:XYZ Project Review 6655 DTSTART;TZID=America/New_York:19980312T083000 6656 DTEND;TZID=America/New_York:19980312T093000 6657 LOCATION:1CP Conference Room 4350 6658 END:VEVENT 6659 END:VCALENDAR 6661 The following is an example of an iCalendar object passed in a MIME 6662 message with a single body part consisting of a "text/calendar" 6663 Content Type. 6665 TO:jsmith@example.com 6666 FROM:jdoe@example.com 6667 MIME-VERSION:1.0 6668 MESSAGE-ID: 6669 CONTENT-TYPE:text/calendar; method="xyz"; component="VEVENT" 6671 BEGIN:VCALENDAR 6672 METHOD:xyz 6673 VERSION:2.0 6674 PRODID:-//ABC Corporation//NONSGML My Product//EN 6675 BEGIN:VEVENT 6676 DTSTAMP:19970324T120000Z 6677 SEQUENCE:0 6678 UID:uid3@example.com 6679 ORGANIZER:mailto:jdoe@example.com 6680 ATTENDEE;RSVP=TRUE:mailto:jsmith@example.com 6681 DTSTART:19970324T123000Z 6682 DTEND:19970324T210000Z 6683 CATEGORIES:MEETING,PROJECT 6684 CLASS:PUBLIC 6685 SUMMARY:Calendaring Interoperability Planning Meeting 6686 DESCRIPTION:Discuss how we can test c&s interoperability\n 6687 using iCalendar and other IETF standards. 6688 LOCATION:LDB Lobby 6689 ATTACH;FMTTYPE=application/postscript:ftp://example.com/pub/ 6690 conf/bkgrnd.ps 6691 END:VEVENT 6692 END:VCALENDAR 6694 The following is an example of a to-do due on April 15, 1998. An 6695 audio alarm has been specified to remind the calendar user at noon, 6696 the day before the to-do is expected to be completed and repeat 6697 hourly, four additional times. The to-do definition has been 6698 modified twice since it was initially created. 6700 BEGIN:VCALENDAR 6701 VERSION:2.0 6702 PRODID:-//ABC Corporation//NONSGML My Product//EN 6703 BEGIN:VTODO 6704 DTSTAMP:19980130T134500Z 6705 SEQUENCE:2 6706 UID:uid4@example.com 6707 ORGANIZER:mailto:unclesam@example.com 6708 ATTENDEE;PARTSTAT=ACCEPTED:mailto:jqpublic@example.com 6709 DUE:19980415T000000 6710 STATUS:NEEDS-ACTION 6711 SUMMARY:Submit Income Taxes 6712 BEGIN:VALARM 6713 ACTION:AUDIO 6714 TRIGGER:19980403T120000Z 6715 ATTACH;FMTTYPE=audio/basic:http://example.com/pub/audio- 6716 files/ssbanner.aud 6717 REPEAT:4 6718 DURATION:PT1H 6719 END:VALARM 6720 END:VTODO 6721 END:VCALENDAR 6723 The following is an example of a journal entry. 6725 BEGIN:VCALENDAR 6726 VERSION:2.0 6727 PRODID:-//ABC Corporation//NONSGML My Product//EN 6728 BEGIN:VJOURNAL 6729 DTSTAMP:19970324T120000Z 6730 UID:uid5@example.com 6731 ORGANIZER:mailto:jsmith@example.com 6732 STATUS:DRAFT 6733 CLASS:PUBLIC 6734 CATEGORIES:Project Report,XYZ,Weekly Meeting 6735 DESCRIPTION:Project xyz Review Meeting Minutes\n 6736 Agenda\n1. Review of project version 1.0 requirements.\n2. 6737 Definition 6738 of project processes.\n3. Review of project schedule.\n 6739 Participants: John Smith\, Jane Doe\, Jim Dandy\n-It was 6740 decided that the requirements need to be signed off by 6741 product marketing.\n-Project processes were accepted.\n 6742 -Project schedule needs to account for scheduled holidays 6743 and employee vacation time. Check with HR for specific 6744 dates.\n-New schedule will be distributed by Friday.\n- 6745 Next weeks meeting is cancelled. No meeting until 3/23. 6746 END:VJOURNAL 6747 END:VCALENDAR 6749 The following is an example of published busy time information. The 6750 iCalendar object might be placed in the network resource 6751 http://www.example.com/calendar/busytime/jsmith.ifb. 6753 BEGIN:VCALENDAR 6754 VERSION:2.0 6755 PRODID:-//RDU Software//NONSGML HandCal//EN 6756 BEGIN:VFREEBUSY 6757 ORGANIZER:mailto:jsmith@example.com 6758 DTSTART:19980313T141711Z 6759 DTEND:19980410T141711Z 6760 FREEBUSY:19980314T233000Z/19980315T003000Z 6761 FREEBUSY:19980316T153000Z/19980316T163000Z 6762 FREEBUSY:19980318T030000Z/19980318T040000Z 6763 URL:http://www.example.com/calendar/busytime/jsmith.ifb 6764 END:VFREEBUSY 6765 END:VCALENDAR 6767 5. Recommended Practices 6769 These recommended practices should be followed in order to assure 6770 consistent handling of the following cases for an iCalendar object. 6772 1. Content lines longer than 75 octets SHOULD be folded. 6774 2. 6776 3. When the combination of the "RRULE" and "RDATE" properties in a 6777 recurring component produces multiple instances having the same 6778 start DATE-TIME value, they should be collapsed to, and 6779 considered as, a single instance. If the "RDATE" property is 6780 specified as a PERIOD value the duration of the recurrence 6781 instance will be the one specified by the "RDATE" property, and 6782 not the duration of the recurrence instance defined by the 6783 "DTSTART" property. 6785 4. When a calendar user receives multiple requests for the same 6786 calendar component (e.g., REQUEST for a "VEVENT" calendar 6787 component) as a result of being on multiple mailing lists 6788 specified by "ATTENDEE" properties in the request, they SHOULD 6789 respond to only one of the requests. The calendar user SHOULD 6790 also specify (using the "MEMBER" parameter of the "ATTENDEE" 6791 property) which mailing list they are a member of. 6793 5. An implementation can truncate a "SUMMARY" property value to 255 6794 octets, but MUST NOT truncate the value in the middle of a UTF-8 6795 multi-octet sequence. 6797 6. If seconds of the minute are not supported by an implementation, 6798 then a value of "00" SHOULD be specified for the seconds 6799 component in a time value. 6801 7. 6803 8. "TZURL" values SHOULD NOT be specified as a file URI type. This 6804 URI form can be useful within an organization, but is 6805 problematic in the Internet. 6807 9. Some possible English values for "CATEGORIES" property include 6808 "ANNIVERSARY", "APPOINTMENT", "BUSINESS", "EDUCATION", 6809 "HOLIDAY", "MEETING", "MISCELLANEOUS", "NON-WORKING HOURS", "NOT 6810 IN OFFICE", "PERSONAL", "PHONE CALL", "SICK DAY", "SPECIAL 6811 OCCASION", "TRAVEL", "VACATION". Categories can be specified in 6812 any registered language. 6814 10. Some possible English values for "RESOURCES" property include 6815 "CATERING", "CHAIRS", "COMPUTER PROJECTOR", "EASEL", "OVERHEAD 6816 PROJECTOR", "SPEAKER PHONE", "TABLE", "TV", "VCR", "VIDEO 6817 PHONE", "VEHICLE". Resources can be specified in any registered 6818 language. 6820 6. Internationalization Considerations 6822 Applications MUST generate iCalendar stream in the UTF-8 charset and 6823 MUST accept iCalendar stream in the UTF-8 or US-ASCII charset. 6825 7. Security Considerations 6827 Because calendaring and scheduling information is very privacy- 6828 sensitive, the protocol used for the transmission of calendaring and 6829 scheduling information should have capabilities to protect the 6830 information from possible threats, such as eavesdropping, replay, 6831 message insertion, deletion, modification and man-in-the-middle 6832 attacks. 6834 As this document only defines the data format and media type of text/ 6835 calendar that is independent of any calendar service or protocol, it 6836 is up to the actual protocol specifications such as iTIP 6837 [I-D.ietf-calsify-2446bis], iMIP [I-D.ietf-calsify-rfc2447bis], and 6838 CalDAV [RFC4791] to describe the threats that the above attacks 6839 present, as well as ways in which to mitigate them. 6841 8. IANA Considerations 6842 8.1. iCalendar Media Type Registration 6844 The Calendaring and Scheduling Core Object Specification is intended 6845 for use as a MIME content type. 6847 To: ietf-types@iana.org 6848 Subject: Registration of media type text/calendar 6850 Type name: text 6852 Subtype name: calendar 6854 Required parameters: none 6856 Optional parameters: charset, method, component and optinfo 6858 The "charset" parameter is defined in [RFC2046] for subtypes of 6859 the "text" media type. It is used to indicate the charset used in 6860 the body part. The charset supported by this revision of 6861 iCalendar is UTF-8. The use of any other charset is deprecated by 6862 this revision of iCalendar; however note that this revision 6863 requires that compliant applications MUST accept iCalendar streams 6864 using either the UTF-8 or US-ASCII charset. 6866 The "method" parameter is used to convey the iCalendar object 6867 method or transaction semantics for the calendaring and scheduling 6868 information. It also is an identifier for the restricted set of 6869 properties and values that the iCalendar object consists of. The 6870 parameter is to be used as a guide for applications interpreting 6871 the information contained within the body part. It SHOULD NOT be 6872 used to exclude or require particular pieces of information unless 6873 the identified method definition specifically calls for this 6874 behavior. Unless specifically forbidden by a particular method 6875 definition, a text/calendar content type can contain any set of 6876 properties permitted by the Calendaring and Scheduling Core Object 6877 Specification. The "method" parameter MUST be specified and MUST 6878 be set to the same value as the "METHOD" component property of the 6879 iCalendar objects of the iCalendar stream if and only if the 6880 iCalendar objects in the iCalendar stream all have a "METHOD" 6881 component property set to the same value. 6883 The value for the "method" parameter is defined as follows: 6885 method = 1*(ALPHA / DIGIT / "-") 6886 ; IANA registered iCalendar object method 6888 The "component" parameter conveys the type of iCalendar calendar 6889 component within the body part. If the iCalendar object contains 6890 more than one calendar component type, then multiple component 6891 parameters MUST be specified. 6893 The value for the "component" parameter is defined as follows: 6895 component = "VEVENT" 6896 / "VTODO" 6897 / "VJOURNAL" 6898 / "VFREEBUSY" 6899 / "VTIMEZONE" 6900 / iana-token 6901 / x-name 6903 The "optinfo" parameter conveys optional information about the 6904 iCalendar object within the body part. This parameter can only 6905 specify semantics already specified by the iCalendar object and 6906 that can be otherwise determined by parsing the body part. In 6907 addition, the optional information specified by this parameter 6908 MUST be consistent with that information specified by the 6909 iCalendar object. For example, it can be used to convey the 6910 "Attendee" response status to a meeting request. The parameter 6911 value consists of a string value. 6913 The parameter can be specified multiple times. 6915 The value for the "optinfo" parameter is defined as follows: 6917 optinfo = infovalue / qinfovalue 6919 infovalue = iana-token / x-name 6921 qinfovalue = DQUOTE (infovalue) DQUOTE 6923 Encoding considerations: This media type can contain 8bit 6924 characters, so the use of quoted-printable or base64 MIME Content- 6925 Transfer-Encodings might be necessary when iCalendar objects are 6926 transferred across protocols restricted to the 7bit repertoire. 6927 Note that a text valued property in the content entity can also 6928 have content encoding of special characters using a BACKSLASH 6929 character (US-ASCII decimal 92) escapement technique. This means 6930 that content values can end up encoded twice. 6932 Security considerations: See Section 7. 6934 Interoperability considerations: This media type is intended to 6935 define a common format for conveying calendaring and scheduling 6936 information between different systems. It is heavily based on the 6937 earlier [VCAL] industry specification. 6939 Published specification: This specification. 6941 Applications which use this media type: This media type is designed 6942 for widespread use by Internet calendaring and scheduling 6943 applications. In addition, applications in the workflow and 6944 document management area might find this content-type applicable. 6945 The iTIP [I-D.ietf-calsify-2446bis], iMIP 6946 [I-D.ietf-calsify-rfc2447bis] and CalDAV [RFC4791] Internet 6947 protocols directly use this media type also. 6949 Additional information: 6951 Magic number(s): None. 6953 File extension(s): The file extension of "ics" is to be used to 6954 designate a file containing (an arbitrary set of) calendaring 6955 and scheduling information consistent with this MIME content 6956 type. 6958 The file extension of "ifb" is to be used to designate a file 6959 containing free or busy time information consistent with this 6960 MIME content type. 6962 Macintosh file type code(s): The file type code of "iCal" is to 6963 be used in Apple MacIntosh operating system environments to 6964 designate a file containing calendaring and scheduling 6965 information consistent with this MIME media type. 6967 The file type code of "iFBf" is to be used in Apple MacIntosh 6968 operating system environments to designate a file containing 6969 free or busy time information consistent with this MIME media 6970 type. 6972 Person & email address to contact for further information: See the 6973 "Author's Address" section of this document. 6975 Intended usage: COMMON 6977 Restrictions on usage: There are no restrictions on where this media 6978 type can be used. 6980 Author: See the "Author's Address" section of this document. 6982 Change controller: IETF 6984 8.2. New iCalendar Elements Registration 6986 This section defines the process to register new or modified 6987 iCalendar elements, that is, components, properties, parameters, 6988 value data types, and values, with IANA. 6990 8.2.1. iCalendar Elements Registration Procedure 6992 The IETF will create a mailing list, icalendar@ietf.org [2], which 6993 can be used for public discussion of iCalendar elements proposals 6994 prior to registration. Use of the mailing list is strongly 6995 encouraged. The IESG will appoint a designated expert who will 6996 monitor the icalendar@ietf.org [2] mailing list and review 6997 registrations. 6999 Registration of new iCalendar elements MUST be reviewed by the 7000 designated expert and published in an RFC. A Standard Tracks RFC is 7001 REQUIRED for the regisration of new value data types that modify 7002 existing properties, as well as for the registration of participation 7003 statuses values to be used in "VEVENT" calendar components. A 7004 Standard Tracks RFC is also REQUIRED for registration of iCalendar 7005 elements that modify iCalendar elements previously documented in a 7006 Standard Tracks RFC. 7008 The registration procedure begins when a completed registration 7009 template, defined in the sections below, is sent to 7010 icalendar@ietf.org [2] and iana@iana.org [3]. The designated expert 7011 is expected to tell IANA and the submitter of the registration within 7012 two weeks whether the registration is approved, approved with minor 7013 changes, or rejected with cause. When a registration is rejected 7014 with cause, it can be re-submitted if the concerns listed in the 7015 cause are addressed. Decisions made by the designated expert can be 7016 appealed to the IESG Applications Area Director, then to the IESG. 7017 They follow the normal appeals procedure for IESG decisions. 7019 8.2.2. Registration Template for Components 7021 A component is defined by completing the following template. 7023 Component name: The name of the component. 7025 Purpose: The purpose of the component. Give a short but clear 7026 description. 7028 Format definition: The ABNF for the component definition needs to 7029 be specified. 7031 Description: Any special notes about the component, how it is to 7032 be used, etc. 7034 Example(s): One or more examples of instances of the component 7035 needs to be specified. 7037 8.2.3. Registration Template for Properties 7039 A property is defined by completing the following template. 7041 Property name: The name of the property. 7043 Purpose: The purpose of the property. Give a short but clear 7044 description. 7046 Value type: Any of the valid value types for the property value 7047 needs to be specified. The default value type also needs to be 7048 specified. 7050 Property parameters: Any of the valid property parameters for the 7051 property MUST be specified. 7053 Conformance: The calendar components that the property can appear 7054 in MUST be specified. 7056 Description: Any special notes about the property, how it is to 7057 be used, etc. 7059 Format definition: The ABNF for the property definition needs to 7060 be specified. 7062 Example(s): One or more examples of instances of the property 7063 needs to be specified. 7065 8.2.4. Registration Template for Parameters 7067 A parameter is defined by completing the following template. 7069 Parameter name: The name of the parameter. 7071 Purpose: The purpose of the parameter. Give a short but clear 7072 description. 7074 Format definition: The ABNF for the parameter definition needs to 7075 be specified. 7077 Description: Any special notes about the parameter, how it is to 7078 be used, etc. 7080 Example(s): One or more examples of instances of the parameter 7081 needs to be specified. 7083 8.2.5. Registration Template for Value Data Types 7085 A value data type is defined by completing the following template. 7087 Value name: The name of the value type. 7089 Purpose: The purpose of the value type. Give a short but clear 7090 description. 7092 Format definition: The ABNF for the value type definition needs 7093 to be specified. 7095 Description: Any special notes about the value type, how it is to 7096 be used, etc. 7098 Example(s): One or more examples of instances of the value type 7099 needs to be specified. 7101 8.2.6. Registration Template for Values 7103 A value is defined by completing the following template. 7105 Value: The value literal. 7107 Purpose: The purpose of the value. Give a short but clear 7108 description. 7110 Conformance: The calendar properties and/or parameters that can 7111 take this value needs to be specified. 7113 Example(s): One or more examples of instances of the value needs 7114 to be specified. 7116 The following is a fictitious example of a registration of an 7117 iCalendar value: 7119 Value: TOP-SECRET 7121 Purpose: This value is used to specify the access classification 7122 of top-secret calendar components. 7124 Conformance: This value can be used with the "CLASS" property. 7126 Example(s): The following is an example of this value used with 7127 the "CLASS" property: 7129 CLASS:TOP-SECRET 7131 8.3. Initial iCalendar Elements Registries 7133 The IANA is requested to create and maintain the following registries 7134 for iCalendar elements with pointers to appropriate reference 7135 documents. 7137 8.3.1. Components Registry 7139 The following table is to be used to initialize the components 7140 registry. 7142 +-----------+---------+------------------------+ 7143 | Component | Status | Reference | 7144 +-----------+---------+------------------------+ 7145 | VCALENDAR | Current | RFCXXXX, Section 3.4 | 7146 | VEVENT | Current | RFCXXXX, Section 3.6.1 | 7147 | VTODO | Current | RFCXXXX, Section 3.6.2 | 7148 | VJOURNAL | Current | RFCXXXX, Section 3.6.3 | 7149 | VFREEBUSY | Current | RFCXXXX, Section 3.6.4 | 7150 | VTIMEZONE | Current | RFCXXXX, Section 3.6.5 | 7151 | VALARM | Current | RFCXXXX, Section 3.6.6 | 7152 | STANDARD | Current | RFCXXXX, Section 3.6.5 | 7153 | DAYLIGHT | Current | RFCXXXX, Section 3.6.5 | 7154 +-----------+---------+------------------------+ 7156 8.3.2. Properties Registry 7158 The following table is to be used to initialize the properties 7159 registry. 7161 +------------------+------------+---------------------------+ 7162 | Property | Status | Reference | 7163 +------------------+------------+---------------------------+ 7164 | CALSCALE | Current | RFCXXXX, Section 3.7.1 | 7165 | METHOD | Current | RFCXXXX, Section 3.7.2 | 7166 | PRODID | Current | RFCXXXX, Section 3.7.3 | 7167 | VERSION | Current | RFCXXXX, Section 3.7.4 | 7168 | ATTACH | Current | RFCXXXX, Section 3.8.1.1 | 7169 | CATEGORIES | Current | RFCXXXX, Section 3.8.1.2 | 7170 | CLASS | Current | RFCXXXX, Section 3.8.1.3 | 7171 | COMMENT | Current | RFCXXXX, Section 3.8.1.4 | 7172 | DESCRIPTION | Current | RFCXXXX, Section 3.8.1.5 | 7173 | GEO | Current | RFCXXXX, Section 3.8.1.6 | 7174 | LOCATION | Current | RFCXXXX, Section 3.8.1.7 | 7175 | PERCENT-COMPLETE | Current | RFCXXXX, Section 3.8.1.8 | 7176 | PRIORITY | Current | RFCXXXX, Section 3.8.1.9 | 7177 | RESOURCES | Current | RFCXXXX, Section 3.8.1.10 | 7178 | STATUS | Current | RFCXXXX, Section 3.8.1.11 | 7179 | SUMMARY | Current | RFCXXXX, Section 3.8.1.12 | 7180 | COMPLETED | Current | RFCXXXX, Section 3.8.2.1 | 7181 | DTEND | Current | RFCXXXX, Section 3.8.2.2 | 7182 | DUE | Current | RFCXXXX, Section 3.8.2.3 | 7183 | DTSTART | Current | RFCXXXX, Section 3.8.2.4 | 7184 | DURATION | Current | RFCXXXX, Section 3.8.2.5 | 7185 | FREEBUSY | Current | RFCXXXX, Section 3.8.2.6 | 7186 | TRANSP | Current | RFCXXXX, Section 3.8.2.7 | 7187 | TZID | Current | RFCXXXX, Section 3.8.3.1 | 7188 | TZNAME | Current | RFCXXXX, Section 3.8.3.2 | 7189 | TZOFFSETFROM | Current | RFCXXXX, Section 3.8.3.3 | 7190 | TZOFFSETTO | Current | RFCXXXX, Section 3.8.3.4 | 7191 | TZURL | Current | RFCXXXX, Section 3.8.3.5 | 7192 | ATTENDEE | Current | RFCXXXX, Section 3.8.4.1 | 7193 | CONTACT | Current | RFCXXXX, Section 3.8.4.2 | 7194 | ORGANIZER | Current | RFCXXXX, Section 3.8.4.3 | 7195 | RECURRENCE-ID | Current | RFCXXXX, Section 3.8.4.4 | 7196 | RELATED-TO | Current | RFCXXXX, Section 3.8.4.5 | 7197 | URL | Current | RFCXXXX, Section 3.8.4.6 | 7198 | UID | Current | RFCXXXX, Section 3.8.4.7 | 7199 | EXDATE | Current | RFCXXXX, Section 3.8.5.1 | 7200 | EXRULE | Deprecated | RFC2445, Section 4.8.5.2 | 7201 | RDATE | Current | RFCXXXX, Section 3.8.5.2 | 7202 | RRULE | Current | RFCXXXX, Section 3.8.5.3 | 7203 | ACTION | Current | RFCXXXX, Section 3.8.6.1 | 7204 | REPEAT | Current | RFCXXXX, Section 3.8.6.2 | 7205 | TRIGGER | Current | RFCXXXX, Section 3.8.6.3 | 7206 | CREATED | Current | RFCXXXX, Section 3.8.7.1 | 7207 | DTSTAMP | Current | RFCXXXX, Section 3.8.7.2 | 7208 | LAST-MODIFIED | Current | RFCXXXX, Section 3.8.7.3 | 7209 | SEQUENCE | Current | RFCXXXX, Section 3.8.7.4 | 7210 | REQUEST-STATUS | Current | RFCXXXX, Section 3.8.8.3 | 7211 +------------------+------------+---------------------------+ 7213 8.3.3. Parameters Registry 7215 The following table is to be used to initialize the parameters 7216 registry. 7218 +----------------+---------+-------------------------+ 7219 | Parameter | Status | Reference | 7220 +----------------+---------+-------------------------+ 7221 | ALTREP | Current | RFCXXXX, Section 3.2.1 | 7222 | CN | Current | RFCXXXX, Section 3.2.2 | 7223 | CUTYPE | Current | RFCXXXX, Section 3.2.3 | 7224 | DELEGATED-FROM | Current | RFCXXXX, Section 3.2.4 | 7225 | DELEGATED-TO | Current | RFCXXXX, Section 3.2.5 | 7226 | DIR | Current | RFCXXXX, Section 3.2.6 | 7227 | ENCODING | Current | RFCXXXX, Section 3.2.7 | 7228 | FMTTYPE | Current | RFCXXXX, Section 3.2.8 | 7229 | FBTYPE | Current | RFCXXXX, Section 3.2.9 | 7230 | LANGUAGE | Current | RFCXXXX, Section 3.2.10 | 7231 | MEMBER | Current | RFCXXXX, Section 3.2.11 | 7232 | PARTSTAT | Current | RFCXXXX, Section 3.2.12 | 7233 | RANGE | Current | RFCXXXX, Section 3.2.13 | 7234 | RELATED | Current | RFCXXXX, Section 3.2.14 | 7235 | RELTYPE | Current | RFCXXXX, Section 3.2.15 | 7236 | ROLE | Current | RFCXXXX, Section 3.2.16 | 7237 | RSVP | Current | RFCXXXX, Section 3.2.17 | 7238 | SENT-BY | Current | RFCXXXX, Section 3.2.18 | 7239 | TZID | Current | RFCXXXX, Section 3.2.19 | 7240 | VALUE | Current | RFCXXXX, Section 3.2.20 | 7241 +----------------+---------+-------------------------+ 7243 8.3.4. Value Data Types Registry 7245 The following table is to be used to initialize the value data types 7246 registry. 7248 +-----------------+---------+-------------------------+ 7249 | Value Data Type | Status | Reference | 7250 +-----------------+---------+-------------------------+ 7251 | BINARY | Current | RFCXXXX, Section 3.3.1 | 7252 | BOOLEAN | Current | RFCXXXX, Section 3.3.2 | 7253 | CAL-ADDRESS | Current | RFCXXXX, Section 3.3.3 | 7254 | DATE | Current | RFCXXXX, Section 3.3.4 | 7255 | DATE-TIME | Current | RFCXXXX, Section 3.3.5 | 7256 | DURATION | Current | RFCXXXX, Section 3.3.6 | 7257 | FLOAT | Current | RFCXXXX, Section 3.3.7 | 7258 | INTEGER | Current | RFCXXXX, Section 3.3.8 | 7259 | PERIOD | Current | RFCXXXX, Section 3.3.9 | 7260 | RECUR | Current | RFCXXXX, Section 3.3.10 | 7261 | TEXT | Current | RFCXXXX, Section 3.3.11 | 7262 | TIME | Current | RFCXXXX, Section 3.3.12 | 7263 | URI | Current | RFCXXXX, Section 3.3.13 | 7264 | UTC-OFFSET | Current | RFCXXXX, Section 3.3.14 | 7265 +-----------------+---------+-------------------------+ 7267 8.3.5. Calendar User Types Registry 7269 The following table is to be used to initialize the calendar user 7270 types registry. 7272 +--------------------+---------+------------------------+ 7273 | Calendar User Type | Status | Reference | 7274 +--------------------+---------+------------------------+ 7275 | INDIVIDUAL | Current | RFCXXXX, Section 3.2.3 | 7276 | GROUP | Current | RFCXXXX, Section 3.2.3 | 7277 | RESOURCE | Current | RFCXXXX, Section 3.2.3 | 7278 | ROOM | Current | RFCXXXX, Section 3.2.3 | 7279 | UNKNOWN | Current | RFCXXXX, Section 3.2.3 | 7280 +--------------------+---------+------------------------+ 7282 8.3.6. Free/Busy Time Types Registry 7284 The following table is to be used to initialize the free/busy time 7285 types registry. 7287 +---------------------+---------+------------------------+ 7288 | Free/Busy Time Type | Status | Reference | 7289 +---------------------+---------+------------------------+ 7290 | FREE | Current | RFCXXXX, Section 3.2.9 | 7291 | BUSY | Current | RFCXXXX, Section 3.2.9 | 7292 | BUSY-UNAVAILABLE | Current | RFCXXXX, Section 3.2.9 | 7293 | BUSY-TENTATIVE | Current | RFCXXXX, Section 3.2.9 | 7294 +---------------------+---------+------------------------+ 7296 8.3.7. Participation Statuses Registry 7298 The following table is to be used to initialize the participation 7299 statuses registry. 7301 +--------------------+---------+-------------------------+ 7302 | Participant Status | Status | Reference | 7303 +--------------------+---------+-------------------------+ 7304 | NEEDS-ACTION | Current | RFCXXXX, Section 3.2.12 | 7305 | ACCEPTED | Current | RFCXXXX, Section 3.2.12 | 7306 | DECLINED | Current | RFCXXXX, Section 3.2.12 | 7307 | TENTATIVE | Current | RFCXXXX, Section 3.2.12 | 7308 | DELEGATED | Current | RFCXXXX, Section 3.2.12 | 7309 | COMPLETED | Current | RFCXXXX, Section 3.2.12 | 7310 | IN-PROCESS | Current | RFCXXXX, Section 3.2.12 | 7311 +--------------------+---------+-------------------------+ 7313 8.3.8. Relationship Types Registry 7315 The following table is to be used to initialize the property 7316 parameters registry. 7318 +-------------------+---------+-------------------------+ 7319 | Relationship Type | Status | Reference | 7320 +-------------------+---------+-------------------------+ 7321 | CHILD | Current | RFCXXXX, Section 3.2.15 | 7322 | PARENT | Current | RFCXXXX, Section 3.2.15 | 7323 | SIBLING | Current | RFCXXXX, Section 3.2.15 | 7324 +-------------------+---------+-------------------------+ 7326 8.3.9. Participation Roles Registry 7328 The following table is to be used to initialize the participation 7329 roles registry. 7331 +-----------------+---------+-------------------------+ 7332 | Role Type | Status | Reference | 7333 +-----------------+---------+-------------------------+ 7334 | CHAIR | Current | RFCXXXX, Section 3.2.16 | 7335 | REQ-PARTICIPANT | Current | RFCXXXX, Section 3.2.16 | 7336 | OPT-PARTICIPANT | Current | RFCXXXX, Section 3.2.16 | 7337 | NON-PARTICIPANT | Current | RFCXXXX, Section 3.2.16 | 7338 +-----------------+---------+-------------------------+ 7340 8.3.10. Actions Registry 7342 The following table is to be used to initialize the actions registry. 7344 +-----------+------------+--------------------------+ 7345 | Action | Status | Reference | 7346 +-----------+------------+--------------------------+ 7347 | AUDIO | Current | RFCXXXX, Section 3.8.6.1 | 7348 | DISPLAY | Current | RFCXXXX, Section 3.8.6.1 | 7349 | EMAIL | Current | RFCXXXX, Section 3.8.6.1 | 7350 | PROCEDURE | Deprecated | RFC2445, Section 4.8.6.1 | 7351 +-----------+------------+--------------------------+ 7353 8.3.11. Classifications Registry 7355 The following table is to be used to initialize the classifications 7356 registry. 7358 +----------------+---------+--------------------------+ 7359 | Classification | Status | Reference | 7360 +----------------+---------+--------------------------+ 7361 | PUBLIC | Current | RFCXXXX, Section 3.8.1.3 | 7362 | PRIVATE | Current | RFCXXXX, Section 3.8.1.3 | 7363 | CONFIDENTIAL | Current | RFCXXXX, Section 3.8.1.3 | 7364 +----------------+---------+--------------------------+ 7366 8.3.12. Methods Registry 7368 No values are defined in this document for the "METHOD" property. 7370 9. Acknowledgements 7372 The editor of this document wish to thank Frank Dawson and Derik 7373 Stenerson, the original authors of RFC2445, as well as the following 7374 individuals who have participated in the drafting, review and 7375 discussion of this memo: 7377 Joe Abley, Hervey Allen, Jay Batson, Oliver Block, Stephane 7378 Bortzmeyer, Chris Bryant, Tantek Celik, Mark Crispin, Cyrus Daboo, 7379 Mike Douglass, Andrew N. Dowden, Lisa Dusseault, Ned Freed, Ted 7380 Hardie, Tim Hare, Jeffrey Harris, Helge Hess, Leif Johansson, 7381 Reinhold Kainhofer, Eliot Lear, Michiel van Leeuwen, Jonathan Lennox, 7382 Jeff McCullough, Bill McQuillan, Alexey Melnikov, Aki Niemi, John W. 7383 Noerenberg II, Chuck Norris, Mark Paterson, Simon Pilette, Arnaud 7384 Quillaud, Robert Ransdell, Julian F. Reschke, Caleb Richardson, Sam 7385 Roberts, George Sexton, Nigel Swinson, Simon Vaillancourt, and Sandy 7386 Wills. 7388 The editor would also like to thank the Calendaring and Scheduling 7389 Consortium for advice with this specification, and for organizing 7390 interoperability testing events to help refine it. 7392 10. References 7394 10.1. Normative References 7396 [ISO.8601.2004] International Organization for 7397 Standardization, "Data elements and 7398 interchange formats -- Information 7399 interchange -- Representation of dates 7400 and times", 2004. 7402 [ISO.9070.1991] International Organization for 7403 Standardization, "Information 7404 Technology_SGML Support Facilities -- 7405 Registration Procedures for Public 7406 Text Owner Identifiers, Second 7407 Edition", April 1991. 7409 [RFC2045] Freed, N. and N. Borenstein, 7410 "Multipurpose Internet Mail Extensions 7411 (MIME) Part One: Format of Internet 7412 Message Bodies", RFC 2045, 7413 November 1996. 7415 [RFC2046] Freed, N. and N. Borenstein, 7416 "Multipurpose Internet Mail Extensions 7417 (MIME) Part Two: Media Types", 7418 RFC 2046, November 1996. 7420 [RFC2119] Bradner, S., "Key words for use in 7421 RFCs to Indicate Requirement Levels", 7422 BCP 14, RFC 2119, March 1997. 7424 [RFC2368] Hoffman, P., Masinter, L., and J. 7425 Zawinski, "The mailto URL scheme", 7426 RFC 2368, July 1998. 7428 [RFC3629] Yergeau, F., "UTF-8, a transformation 7429 format of ISO 10646", STD 63, 7430 RFC 3629, November 2003. 7432 [RFC3986] Berners-Lee, T., Fielding, R., and L. 7433 Masinter, "Uniform Resource Identifier 7434 (URI): Generic Syntax", STD 66, 7435 RFC 3986, January 2005. 7437 [RFC4646] Phillips, A. and M. Davis, "Tags for 7438 Identifying Languages", BCP 47, 7439 RFC 4646, September 2006. 7441 [RFC4648] Josefsson, S., "The Base16, Base32, 7442 and Base64 Data Encodings", RFC 4648, 7443 October 2006. 7445 [RFC5234] Crocker, D. and P. Overell, "Augmented 7446 BNF for Syntax Specifications: ABNF", 7447 STD 68, RFC 5234, January 2008. 7449 10.2. Informative References 7451 [I-D.ietf-calsify-2446bis] Daboo, C., "iCalendar Transport- 7452 Independent Interoperability Protocol 7453 (iTIP)", draft-ietf-calsify-2446bis-04 7454 (work in progress), November 2007. 7456 [I-D.ietf-calsify-rfc2447bis] Melnikov, A., "iCalendar Message-Based 7457 Interoperability Protocol(iMIP)", 7458 draft-ietf-calsify-rfc2447bis-03 (work 7459 in progress), February 2007. 7461 [RFC2392] Levinson, E., "Content-ID and 7462 Message-ID Uniform Resource Locators", 7463 RFC 2392, August 1998. 7465 [RFC2425] Howes, T., Smith, M., and F. Dawson, 7466 "A MIME Content-Type for Directory 7467 Information", RFC 2425, 7468 September 1998. 7470 [RFC2426] Dawson, F. and T. Howes, "vCard MIME 7471 Directory Profile", RFC 2426, 7472 September 1998. 7474 [RFC4516] Smith, M. and T. Howes, "Lightweight 7475 Directory Access Protocol (LDAP): 7476 Uniform Resource Locator", RFC 4516, 7477 June 2006. 7479 [RFC4791] Daboo, C., Desruisseaux, B., and L. 7480 Dusseault, "Calendaring Extensions to 7481 WebDAV (CalDAV)", RFC 4791, 7482 March 2007. 7484 [TZDB] Eggert, P. and A. Olson, "Sources for 7485 Time Zone and Daylight Saving Time 7486 Data", January 2007, . 7489 [Note to RFC Editor: Change "A. Olson" 7490 to "A.D. Olson".] 7492 [VCAL] Internet Mail Consortium, "vCalendar: 7493 The Electronic Calendaring and 7494 Scheduling Exchange Format", 7495 September 1996, 7496 . 7498 URIs 7500 [1] 7502 [2] 7504 [3] 7506 Appendix A. Differences from RFC 2445 7508 This appendix contains a list of changes that have been made in the 7509 Internet Calendaring and Scheduling Core Object Specification from 7510 RFC 2445. 7512 A.1. New restrictions 7514 1. The "DTSTART" property SHOULD be synchronized with the recurrence 7515 rule, if specified. 7517 2. The "RRULE" property SHOULD NOT occur more than once in a 7518 component. 7520 3. The BYHOUR, BYMINUTE and BYSECOND rule parts MUST NOT be 7521 specified in the "RRULE" property when the "DTSTART" property is 7522 specified as a DATE value. 7524 4. The value type of the "DTEND" or "DUE" properties MUST match the 7525 value type of "DTSTART" property. 7527 A.2. Restrictions removed 7529 1. The "DTSTART" and "DTEND" properties are no longer required to be 7530 specified as date with local time and time zone reference when 7531 used with a recurrence rule. 7533 A.3. Deprecated features 7535 1. The "EXRULE" property can no longer be specified in a component. 7537 2. The "THISANDPRIOR" value can no longer be used with the "RANGE" 7538 parameter. 7540 3. The "PROCEDURE" value can no longer be used with the "ACTION" 7541 property. 7543 4. x-name rule parts can no longer be specified in properties of 7544 RECUR value type (e.g., RRULE). x-param can be used on RECUR 7545 value type properties instead. 7547 Appendix B. Change Log (to be removed by RFC Editor prior to 7548 publication) 7550 B.1. Changes in -08 7552 A detailed list of changes is available at the following page: 7553 http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/ 7554 draft-ietf-calsify-rfc2445bis-08.changes.html. 7556 a. Issue 48: Revert the change to deprecate the "RANGE" parameter. 7557 Only the value "THISANDPRIOR" is deprecated. 7559 b. Issue 81: BYSETPOS: Clarify that "a set" starts at the beginning 7560 of the interval defined by the FREQ rule part. 7562 c. Chair Review: Changed requirement to handle unrecognized CUTYPE 7563 values. 7565 d. Chair Review: Changed requirement to handle unrecognized VALUE 7566 data types. 7568 e. Chair Review: Removed requirements for "DELEGATED-TO" and 7569 "DELEGATED-FROM" to be specified as mailto URI. 7571 f. Chair Review: Added note about alarms from untrusted sources. 7573 g. Chair Review: Added text to clarify the structure of the 7574 document. 7576 h. Chair Review: Added forward reference to the section covering 7577 BACKSLASH character encoding. 7579 i. Removed the text that specifies when the sequence number MUST be 7580 incremented. Text will be added to rfc2446bis. 7582 j. Removed normative reference to RFC2822. 7584 k. Changed reference of RFC4234 to RFC5234. 7586 l. Few editorial changes. 7588 B.2. Changes in -07 7590 A detailed list of changes is available at the following page: 7591 http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/ 7592 draft-ietf-calsify-rfc2445bis-07.changes.html. 7594 a. Issue 8: Clarified how to compute the exact duration of a nominal 7595 duration. 7597 b. Issue 10: Added new examples for "VEVENT" and "VTODO" to 7598 demonstrate that end times are always non-inclusive, that is, 7599 even end times specified as DATE values. 7601 c. Issue 11: Added a table that shows the dependency of BYxxx rule 7602 part expand or limit behaviour on the FREQ value in the rule. 7604 d. Issue 19: Removed section "Registration of Content Type 7605 Elements". Added registration templates in IANA Considerations 7606 section. Specified how applications should treat x-name and 7607 x-token they don't recognize. 7609 e. Issue 65: Removed 3rd recommended practice. Added new 7610 requirements to require "DTEND" and "DUE" to be a local date time 7611 if and only if "DTSTART" is a local date time. 7613 f. Issue 68: Clarified handling of date-times that fall in time 7614 discontinutities. 7616 g. Issue 69: Clarified handling of recurrence instances that fall in 7617 time discontinutities 7619 h. Issue 71: Clarified handling of leap seconds. 7621 i. Issue 75: Clarified that the "RDATE" property MUST be specified 7622 as a local DATE-TIME value in "VTIMEZONE" sub-components. 7624 j. Issue 76: Clarified that the value type of the "DTEND" property 7625 MUST be the same as the "DTSTART" property. 7627 k. Issue 77: Clarified that the value type of the "DUE" property 7628 MUST be the same as the "DTSTART" property. 7630 l. Issue 79: Clarified that "DTSTART" always specify an onset date- 7631 time of an observance and that its value does not need to be 7632 repeated in an "RDATE" property. 7634 m. Issue 80: Rewrote Security Considerations section. 7636 n. Issue 81: Clarified the meaning of "the set of events specified 7637 by the rule" in the description of the BYSETPOS rule part. 7639 o. Modified Abstract section. 7641 p. Moved text of section 2.3 International Considerations at the end 7642 of sectino 2.1 Formatting Conventions. 7644 q. Added Internationalization Considerations section. 7646 r. Modified the description of the following properties: "ATTACH", 7647 "COMMENT", "COMPLETED", "CREATED" "DTSTAMP" "DUE", and "REPEAT". 7649 s. Clarified some differences with ISO 8601. 7651 t. Updated reference to CalDAV and ISO 8601. 7653 u. Updated section "Differences from RFC 2445": added new 7654 restrictions and added list of removed restrictions. 7656 v. Numerous editorial changes. 7658 B.3. Changes in -06 7660 A detailed list of changes is available at the following page: 7661 http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/ 7662 draft-ietf-calsify-rfc2445bis-06.changes.html. 7664 a. Issue 19: Defined new IANA registries. [Work in progress]; 7666 b. Issue 23: Clarified that the UNTIL rule part MUST specify a value 7667 of the same type as the value specified by "DTSTART"; 7669 c. Issue 27: Clarified how the duration of generated recurrence 7670 instances is determined; 7672 d. Issue 35: Further clarified the description of the "LANGUAGE" 7673 property; 7675 e. Issue 42: Removed the restriction on the values allowed for the 7676 "ACTION" property in the the "VALARM" component; 7678 f. Issue 47: Clarified that alarm triggers relative to a DATE value 7679 type needs to be triggered to 00:00:00 of the user's configured 7680 time zone; 7682 g. Issue 56: Added a note to specify that FREQ MUST be specified as 7683 the first rule part in generated iCalendar applications, but MUST 7684 be accepted in any order to ensure backward compatibility. The 7685 rest of the RECUR value type ABNF has been further simplified; 7687 h. Issue 59: Clarified the default duration of "VEVENT" components 7688 specified with a "DTSTART" property of DATE value type; 7690 i. Issue 61: Modified all the property ABNFs to allow iana-param in 7691 addition to x-param. Also modified the component ABNFs to allow 7692 iana-prop in addition to x-prop. [Work in progress]; 7694 j. Issue 62: Removed the text that lead to believe that the 7695 "RECURRENCE-ID" of a specific recurrence instance might change; 7697 k. Issue 64: Clarified that REQUEST-STATUS only allows pairs (1.1) 7698 and 3-tuples (1.1.1). 7700 l. Issue 65: Clarified that a different time zone may be used by 7701 "DTSTART" and "DTEND", and "DTSTART" and "DUE" when specified as 7702 date with local time and time zone reference. [Work in 7703 progress]; 7705 m. Issue 66: Clarified that if the "RDATE" property is specified as 7706 a PERIOD, its duration has precedence over the duration of the 7707 recurrence instance defined by the "DTSTART" property; 7709 n. Issue 72: Removed the requirement that a "VTIMEZONE" calendar 7710 component MUST be present if the iCalendar object contains an 7711 RRULE that generates dates on both sides of a time zone shift; 7713 o. Issue 73: Clarified that the "TZID" must be unique in the scope 7714 of an iCalendar object only; 7716 p. Issue 74: Deprecated the "PROCEDURE" value for the "ACTION" 7717 property; 7719 q. Issue 78: Fixed the text to specify that "TZOFFSETFROM" and not 7720 "TZOFFSETTO" must be used with "DTSTART" when generating the 7721 onset date-time values from the "RRULE" in a "VTIMEZONE" 7722 component; 7724 r. Clarified that the "DTSTART" property MUST be specified in a 7725 "VTODO" component when the "DURATION" property is specified; 7727 s. Started to update the time zone information / examples; 7729 t. Numerous editorial changes. 7731 B.4. Changes in -05 7733 A detailed list of changes is available at the following page: 7734 http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/ 7735 draft-ietf-calsify-rfc2445bis-05.changes.html. 7737 a. Fixed ABNF with references in .txt version of the draft; 7739 b. Numerous editorial changes; 7741 c. Clarified that normative statements in ABNF comments should be 7742 considered as normative; 7744 d. Removed notes talking of character sets other than US-ASCII and 7745 UTF-8; 7747 e. Renamed CTL to CONTROL to avoid conflict with the CTL rule 7748 defined in RFC4234; 7750 f. Removed ABNF rules defined in RFC4234; 7752 g. Changed the partstatparam ABNF rule for clarity; 7754 h. Clarified the purpose of negative durations; 7756 i. Added informational references to RFC 2392 (CID URL) and RFC 4516 7757 (LDAP URL). 7759 j. Updated TZDB reference. 7761 B.5. Changes in -04 7763 A detailed list of changes is available at the following page: 7764 http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/ 7765 draft-ietf-calsify-rfc2445bis-04.changes.html. 7767 a. Issue 16: Clarified that recurrence instances, generated by a 7768 recurrence rule, with an invalid date or nonexistent local time 7769 must be ignored and not counted as part of the recurrence set. 7771 b. Issue 26: Clarified how to handle the BYHOUR, BYMINUTE and 7772 BYSECOND rule parts when "DTSTART" is a DATE value. 7774 c. Issue 28: Removed the MUST requirement to specify the "RDATE" 7775 property whenever the duration of a recurrence instance is 7776 modified. 7778 d. Issue 29: Clarified that the "DTSTART" property is REQUIRED in 7779 all types of recurring components. 7781 e. Issue 32: Introduced the notion of an "iCalendar stream" to make 7782 it explicit when we are refering to a "single iCalendar object" 7783 or a "sequence of iCalendar objects". 7785 f. Issue 34: Clarified what should be done with the "method" 7786 parameter when the iCalendar stream is a sequence of iCalendar 7787 objects. 7789 g. Issue 40: Changed to fbprop ABNF rule to specify that the 7790 "DTSTAMP" and the "UID" properties are REQUIRED in "VFREEBUSY" 7791 components. 7793 h. Issue 43: Removed the MUST requirement to specify the "DTSTART" 7794 and the "DTEND" properties as local time in recurring components, 7795 but added a note that in most cases this is the right thing to 7796 do. 7798 i. Issue 44: Changed the x-prop ABNF to allow any parameters on non- 7799 standard properties. 7801 j. Issue 46: Simplified the tzprop, audioprop, dispprop, emailprop, 7802 and procprop ABNF rules by removing the number of required 7803 properties in front of the "*". 7805 k. Issue 48: Deprecated the "RANGE" parameter. 7807 l. Issue 51: Clarified implicit duration of day events with no 7808 "DTEND" nor "DURATION" property. 7810 m. Issue 52: Removed x-name from the "recur" rule part definition. 7811 It should be sufficient to allow xparam on properties of RECUR 7812 value type. 7814 n. Issue 53: Updated the NON-US-ASCII ABNF rule for UTF-8. 7816 o. Issue 56: Changed the "recur" ABNF rule to allow rule parts to be 7817 specified in any order. 7819 p. Issue 57: Specified that the "DURATION" property MUST be 7820 specified as a "dur-day" or "dur-week" value when the "DTSTART" 7821 is a DATE. 7823 q. Issue 58: Changed the jourprop ABNF rule to allow the 7824 "DESCRIPTION" property to occur more than once. 7826 r. Numerous editorial changes. 7828 s. Changed reference to RFC 4646 for Language-Tag. 7830 B.6. Changes in -03 7832 A detailed list of changes is available at the following page: 7833 http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/ 7834 draft-ietf-calsify-rfc2445bis-03.changes.html. 7836 a. Numerous editorial changes. 7838 b. Specified that "DTSTART" should match the pattern of "RRULE" and 7839 is always part of the "COUNT". 7841 c. Specified "RRULE" should not occur more than once in recurring 7842 components. 7844 d. Deprecated "EXRULE". 7846 e. Fixed all ABNF errors reported by Bill Fenner's ABNF parsing web 7847 service available at: 7848 http://rtg.ietf.org/~fenner/abnf.cgi. 7850 f. Changed reference to RFC 4648 for Base64 encoding. 7852 B.7. Changes in -02 7854 A detailed list of changes is available at the following page: 7855 http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/ 7856 draft-ietf-calsify-rfc2445bis-02.changes.html. 7858 a. Numerous editorial changes including the typos listed in the 7859 "RFC2445 Errata": 7860 http://www.rfc-editor.org/cgi-bin/errataSearch.pl?rfc=2445& 7861 and in the "RFC2445 Issues List": 7862 http://www.softwarestudio.org/iCal/2445Issues.html. 7864 b. Clarified line folding requirements. 7866 c. Clarified charset requirements. 7868 d. Clarified line limits requirements. 7870 e. Clarified on the use of the "LANGUAGE" parameter. 7872 f. Fixed the eventprop, todoprop and jourprop ABNF rules with 7873 respect to required properties. 7875 g. Fixed all the examples to use RFC2606-compliant FQDNs. 7877 h. Fixed the Content-ID URLs in the examples. 7879 i. Fixed the LDAP URLs in the examples. 7881 j. Moved multiple references in the Informative References section. 7883 k. Updated the Acknowledgments section. 7885 B.8. Changes in -01 7887 A detailed list of changes is available at the following page: 7888 http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/ 7889 draft-ietf-calsify-rfc2445bis-01.changes.html. 7891 a. Numerous editorial changes (typos, errors in examples, etc.). 7893 b. Fixed invalid media types in examples. 7895 c. Fixed the "DTSTAMP" values in the examples. 7897 d. Moved media type registration in a separate IANA Consideration 7898 section. 7900 e. Added Internationalization Considerations section. 7902 f. Added Security Considerations section. 7904 g. Updated the Acknowledgments section. 7906 Author's Address 7908 Bernard Desruisseaux (editor) 7909 Oracle Corporation 7910 600 blvd. de Maisonneuve West 7911 Suite 1900 7912 Montreal, QC H3A 3J2 7913 CANADA 7915 EMail: bernard.desruisseaux@oracle.com 7916 URI: http://www.oracle.com/ 7918 Full Copyright Statement 7920 Copyright (C) The IETF Trust (2008). 7922 This document is subject to the rights, licenses and restrictions 7923 contained in BCP 78, and except as set forth therein, the authors 7924 retain all their rights. 7926 This document and the information contained herein are provided on an 7927 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 7928 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 7929 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 7930 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 7931 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 7932 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 7934 Intellectual Property 7936 The IETF takes no position regarding the validity or scope of any 7937 Intellectual Property Rights or other rights that might be claimed to 7938 pertain to the implementation or use of the technology described in 7939 this document or the extent to which any license under such rights 7940 might or might not be available; nor does it represent that it has 7941 made any independent effort to identify any such rights. Information 7942 on the procedures with respect to rights in RFC documents can be 7943 found in BCP 78 and BCP 79. 7945 Copies of IPR disclosures made to the IETF Secretariat and any 7946 assurances of licenses to be made available, or the result of an 7947 attempt made to obtain a general license or permission for the use of 7948 such proprietary rights by implementers or users of this 7949 specification can be obtained from the IETF on-line IPR repository at 7950 http://www.ietf.org/ipr. 7952 The IETF invites any interested party to bring to its attention any 7953 copyrights, patents or patent applications, or other proprietary 7954 rights that may cover technology that may be required to implement 7955 this standard. Please address the information to the IETF at 7956 ietf-ipr@ietf.org. 7958 Acknowledgement 7960 Funding for the RFC Editor function is provided by the IETF 7961 Administrative Support Activity (IASA).