idnits 2.17.1 draft-ietf-calsify-rfc2445bis-07.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 7881. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 7892. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 7899. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 7905. 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 (July 8, 2007) is 6136 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 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 4646 (Obsoleted by RFC 5646) == Outdated reference: A later version (-10) exists of draft-ietf-calsify-2446bis-03 == 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: 6 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) July 8, 2007 5 Intended status: Standards Track 6 Expires: January 9, 2008 8 Internet Calendaring and Scheduling Core Object Specification 9 (iCalendar) 10 draft-ietf-calsify-rfc2445bis-07 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 January 9, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 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 . . . . . . . . . . . . . . . . 22 81 3.2.13. Alarm Trigger Relationship . . . . . . . . . . . . . 24 82 3.2.14. Relationship Type . . . . . . . . . . . . . . . . . . 24 83 3.2.15. Participation Role . . . . . . . . . . . . . . . . . 25 84 3.2.16. RSVP Expectation . . . . . . . . . . . . . . . . . . 26 85 3.2.17. Sent By . . . . . . . . . . . . . . . . . . . . . . . 27 86 3.2.18. Time Zone Identifier . . . . . . . . . . . . . . . . 27 87 3.2.19. Value Data Types . . . . . . . . . . . . . . . . . . 28 88 3.3. Property Value Data Types . . . . . . . . . . . . . . . . 29 89 3.3.1. Binary . . . . . . . . . . . . . . . . . . . . . . . 30 90 3.3.2. Boolean . . . . . . . . . . . . . . . . . . . . . . . 30 91 3.3.3. Calendar User Address . . . . . . . . . . . . . . . . 31 92 3.3.4. Date . . . . . . . . . . . . . . . . . . . . . . . . 31 93 3.3.5. Date-Time . . . . . . . . . . . . . . . . . . . . . . 32 94 3.3.6. Duration . . . . . . . . . . . . . . . . . . . . . . 34 95 3.3.7. Float . . . . . . . . . . . . . . . . . . . . . . . . 36 96 3.3.8. Integer . . . . . . . . . . . . . . . . . . . . . . . 36 97 3.3.9. Period of Time . . . . . . . . . . . . . . . . . . . 37 98 3.3.10. Recurrence Rule . . . . . . . . . . . . . . . . . . . 38 99 3.3.11. Text . . . . . . . . . . . . . . . . . . . . . . . . 45 100 3.3.12. Time . . . . . . . . . . . . . . . . . . . . . . . . 47 101 3.3.13. URI . . . . . . . . . . . . . . . . . . . . . . . . . 49 102 3.3.14. UTC Offset . . . . . . . . . . . . . . . . . . . . . 49 103 3.4. iCalendar Object . . . . . . . . . . . . . . . . . . . . 50 104 3.5. Property . . . . . . . . . . . . . . . . . . . . . . . . 51 105 3.6. Calendar Components . . . . . . . . . . . . . . . . . . . 51 106 3.6.1. Event Component . . . . . . . . . . . . . . . . . . . 52 107 3.6.2. To-do Component . . . . . . . . . . . . . . . . . . . 56 108 3.6.3. Journal Component . . . . . . . . . . . . . . . . . . 58 109 3.6.4. Free/Busy Component . . . . . . . . . . . . . . . . . 60 110 3.6.5. Time Zone Component . . . . . . . . . . . . . . . . . 63 111 3.6.6. Alarm Component . . . . . . . . . . . . . . . . . . . 72 112 3.7. Calendar Properties . . . . . . . . . . . . . . . . . . . 77 113 3.7.1. Calendar Scale . . . . . . . . . . . . . . . . . . . 77 114 3.7.2. Method . . . . . . . . . . . . . . . . . . . . . . . 78 115 3.7.3. Product Identifier . . . . . . . . . . . . . . . . . 79 116 3.7.4. Version . . . . . . . . . . . . . . . . . . . . . . . 80 117 3.8. Component Properties . . . . . . . . . . . . . . . . . . 81 118 3.8.1. Descriptive Component Properties . . . . . . . . . . 81 119 3.8.1.1. Attachment . . . . . . . . . . . . . . . . . . . 81 120 3.8.1.2. Categories . . . . . . . . . . . . . . . . . . . 82 121 3.8.1.3. Classification . . . . . . . . . . . . . . . . . 83 122 3.8.1.4. Comment . . . . . . . . . . . . . . . . . . . . . 84 123 3.8.1.5. Description . . . . . . . . . . . . . . . . . . . 85 124 3.8.1.6. Geographic Position . . . . . . . . . . . . . . . 86 125 3.8.1.7. Location . . . . . . . . . . . . . . . . . . . . 88 126 3.8.1.8. Percent Complete . . . . . . . . . . . . . . . . 89 127 3.8.1.9. Priority . . . . . . . . . . . . . . . . . . . . 90 128 3.8.1.10. Resources . . . . . . . . . . . . . . . . . . . . 92 129 3.8.1.11. Status . . . . . . . . . . . . . . . . . . . . . 93 130 3.8.1.12. Summary . . . . . . . . . . . . . . . . . . . . . 94 131 3.8.2. Date and Time Component Properties . . . . . . . . . 95 132 3.8.2.1. Date/Time Completed . . . . . . . . . . . . . . . 95 133 3.8.2.2. Date/Time End . . . . . . . . . . . . . . . . . . 96 134 3.8.2.3. Date/Time Due . . . . . . . . . . . . . . . . . . 97 135 3.8.2.4. Date/Time Start . . . . . . . . . . . . . . . . . 99 136 3.8.2.5. Duration . . . . . . . . . . . . . . . . . . . . 100 137 3.8.2.6. Free/Busy Time . . . . . . . . . . . . . . . . . 101 138 3.8.2.7. Time Transparency . . . . . . . . . . . . . . . . 102 139 3.8.3. Time Zone Component Properties . . . . . . . . . . . 103 140 3.8.3.1. Time Zone Identifier . . . . . . . . . . . . . . 103 141 3.8.3.2. Time Zone Name . . . . . . . . . . . . . . . . . 105 142 3.8.3.3. Time Zone Offset From . . . . . . . . . . . . . . 106 143 3.8.3.4. Time Zone Offset To . . . . . . . . . . . . . . . 106 144 3.8.3.5. Time Zone URL . . . . . . . . . . . . . . . . . . 107 145 3.8.4. Relationship Component Properties . . . . . . . . . . 108 146 3.8.4.1. Attendee . . . . . . . . . . . . . . . . . . . . 108 147 3.8.4.2. Contact . . . . . . . . . . . . . . . . . . . . . 111 148 3.8.4.3. Organizer . . . . . . . . . . . . . . . . . . . . 112 149 3.8.4.4. Recurrence ID . . . . . . . . . . . . . . . . . . 114 150 3.8.4.5. Related To . . . . . . . . . . . . . . . . . . . 116 151 3.8.4.6. Uniform Resource Locator . . . . . . . . . . . . 118 152 3.8.4.7. Unique Identifier . . . . . . . . . . . . . . . . 118 153 3.8.5. Recurrence Component Properties . . . . . . . . . . . 120 154 3.8.5.1. Exception Date/Times . . . . . . . . . . . . . . 120 155 3.8.5.2. Recurrence Date/Times . . . . . . . . . . . . . . 122 156 3.8.5.3. Recurrence Rule . . . . . . . . . . . . . . . . . 123 157 3.8.6. Alarm Component Properties . . . . . . . . . . . . . 134 158 3.8.6.1. Action . . . . . . . . . . . . . . . . . . . . . 134 159 3.8.6.2. Repeat Count . . . . . . . . . . . . . . . . . . 134 160 3.8.6.3. Trigger . . . . . . . . . . . . . . . . . . . . . 135 161 3.8.7. Change Management Component Properties . . . . . . . 138 162 3.8.7.1. Date/Time Created . . . . . . . . . . . . . . . . 138 163 3.8.7.2. Date/Time Stamp . . . . . . . . . . . . . . . . . 138 164 3.8.7.3. Last Modified . . . . . . . . . . . . . . . . . . 139 165 3.8.7.4. Sequence Number . . . . . . . . . . . . . . . . . 140 166 3.8.8. Miscellaneous Component Properties . . . . . . . . . 142 167 3.8.8.1. IANA Properties . . . . . . . . . . . . . . . . . 142 168 3.8.8.2. Non-standard Properties . . . . . . . . . . . . . 143 169 3.8.8.3. Request Status . . . . . . . . . . . . . . . . . 144 170 4. iCalendar Object Examples . . . . . . . . . . . . . . . . . . 147 171 5. Recommended Practices . . . . . . . . . . . . . . . . . . . . 151 172 6. Internationalization Considerations . . . . . . . . . . . . . 152 173 7. Security Considerations . . . . . . . . . . . . . . . . . . . 152 174 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 152 175 8.1. iCalendar Media Type Registration . . . . . . . . . . . . 153 176 8.2. New iCalendar Elements Registration . . . . . . . . . . . 156 177 8.2.1. iCalendar Elements Registration Procedure . . . . . . 156 178 8.2.2. Registration Template for Components . . . . . . . . 156 179 8.2.3. Registration Template for Properties . . . . . . . . 157 180 8.2.4. Registration Template for Parameters . . . . . . . . 158 181 8.2.5. Registration Template for Value Data Types . . . . . 158 182 8.2.6. Registration Template for Values . . . . . . . . . . 158 183 8.3. Initial iCalendar Elements Registries . . . . . . . . . . 159 184 8.3.1. Components Registry . . . . . . . . . . . . . . . . . 159 185 8.3.2. Properties Registry . . . . . . . . . . . . . . . . . 160 186 8.3.3. Parameters Registry . . . . . . . . . . . . . . . . . 161 187 8.3.4. Value Data Types Registry . . . . . . . . . . . . . . 162 188 8.3.5. Calendar User Types Registry . . . . . . . . . . . . 163 189 8.3.6. Free/Busy Time Types Registry . . . . . . . . . . . . 163 190 8.3.7. Participation Statuses Registry . . . . . . . . . . . 163 191 8.3.8. Relationship Types Registry . . . . . . . . . . . . . 164 192 8.3.9. Participation Roles Registry . . . . . . . . . . . . 164 193 8.3.10. Actions Registry . . . . . . . . . . . . . . . . . . 164 194 8.3.11. Classifications Registry . . . . . . . . . . . . . . 164 195 8.3.12. Methods Registry . . . . . . . . . . . . . . . . . . 165 196 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 165 197 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 165 198 10.1. Normative References . . . . . . . . . . . . . . . . . . 165 199 10.2. Informative References . . . . . . . . . . . . . . . . . 167 200 Appendix A. Differences from RFC 2445 . . . . . . . . . . . . . 168 201 A.1. New restrictions . . . . . . . . . . . . . . . . . . . . 168 202 A.2. Restrictions removed . . . . . . . . . . . . . . . . . . 168 203 A.3. Deprecated features . . . . . . . . . . . . . . . . . . . 168 204 Appendix B. Change Log (to be removed by RFC Editor prior to 205 publication) . . . . . . . . . . . . . . . . . . . . 169 206 B.1. Changes in -07 . . . . . . . . . . . . . . . . . . . . . 169 207 B.2. Changes in -06 . . . . . . . . . . . . . . . . . . . . . 170 208 B.3. Changes in -05 . . . . . . . . . . . . . . . . . . . . . 172 209 B.4. Changes in -04 . . . . . . . . . . . . . . . . . . . . . 172 210 B.5. Changes in -03 . . . . . . . . . . . . . . . . . . . . . 174 211 B.6. Changes in -02 . . . . . . . . . . . . . . . . . . . . . 174 212 B.7. Changes in -01 . . . . . . . . . . . . . . . . . . . . . 175 213 Appendix C. Open issues (to be removed by RFC Editor prior to 214 publication) . . . . . . . . . . . . . . . . . . . . 175 215 C.1. introduction . . . . . . . . . . . . . . . . . . . . . . 175 216 C.2. #issue11+4.3.10_byxxx_rule_part_examples . . . . . . . . 175 217 C.3. #issue63+4.8.5.3_rdate_and_dtstart . . . . . . . . . . . 176 219 1. Introduction 221 The use of calendaring and scheduling has grown considerably in the 222 last decade. Enterprise and inter-enterprise business has become 223 dependent on rapid scheduling of events and actions using this 224 information technology. However, the longer term growth of 225 calendaring and scheduling is currently limited by the lack of 226 Internet standards for the message content types that are central to 227 these knowledgeware applications. This memo is intended to progress 228 the level of interoperability possible between dissimilar calendaring 229 and scheduling applications. This memo defines a MIME content type 230 for exchanging electronic calendaring and scheduling information. 231 The Internet Calendaring and Scheduling Core Object Specification, or 232 iCalendar, allows for the capture and exchange of information 233 normally stored within a calendaring and scheduling application; such 234 as a Personal Information Manager (PIM) or a Group Scheduling 235 product. 237 The iCalendar format is suitable as an exchange format between 238 applications or systems. The format is defined in terms of a MIME 239 content type. This will enable the object to be exchanged using 240 several transports, including but not limited to SMTP, HTTP, a file 241 system, desktop interactive protocols such as the use of a memory- 242 based clipboard or drag/drop interactions, point-to-point 243 asynchronous communication, wired-network transport, or some form of 244 unwired transport such as infrared might also be used. 246 The memo also provides for the definition of iCalendar object methods 247 that will map this content type to a set of messages for supporting 248 calendaring and scheduling operations such as requesting, replying 249 to, modifying, and canceling meetings or appointments, to-dos and 250 journal entries. The iCalendar object methods can be used to define 251 other calendaring and scheduling operations such a requesting for and 252 replying with free/busy time data. Such a scheduling protocol is 253 defined in the iCalendar Transport-independent Interoperability 254 Protocol (iTIP) defined in [I-D.ietf-calsify-2446bis]. 256 The memo also includes a formal grammar for the content type based on 257 the Internet ABNF defined in [RFC4234]. This ABNF is required for 258 the implementation of parsers and to serve as the definitive 259 reference when ambiguities or questions arise in interpreting the 260 descriptive prose definition of the memo. Additional restrictions 261 that could not easily be expressed with the ABNF syntax are specified 262 as comments in the ABNF. Comments with normative statements should 263 be treated as such. 265 2. Basic Grammar and Conventions 267 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 268 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" and 269 "OPTIONAL" in this document are to be interpreted as described in 270 [RFC2119]. 272 This memo makes use of both a descriptive prose and a more formal 273 notation for defining the calendaring and scheduling format. 275 The notation used in this memo is the ABNF notation of [RFC4234]. 276 Readers intending on implementing the format defined in this memo 277 should be familiar with this notation in order to properly interpret 278 the specifications of this memo. 280 All numeric values used in this memo are given in decimal notation. 282 All names of properties, property parameters, enumerated property 283 values and property parameter values are case-insensitive. However, 284 all other property values are case-sensitive, unless otherwise 285 stated. 287 Note: All indented editorial notes, such as this one, are intended 288 to provide the reader with additional information. The 289 information is not essential to the building of an implementation 290 conformant with this memo. The information is provided to 291 highlight a particular feature or characteristic of the memo. 293 The format for the iCalendar object is based on the syntax of the 294 text/directory media type [RFC2425]. While the iCalendar object is 295 not a profile of the text/directory media type [RFC2425], it does 296 reuse a number of the elements from the [RFC2425] specification. 298 2.1. Formatting Conventions 300 The elements defined in this memo are defined in prose. Many of the 301 terms used to describe these have common usage that is different than 302 the standards usage of this memo. In order to reference within this 303 memo elements of the calendaring and scheduling model, core object 304 (this memo) or interoperability protocol [I-D.ietf-calsify-2446bis] 305 some formatting conventions have been used. Calendaring and 306 scheduling roles are referred to in quoted-strings of text with the 307 first character of each word in upper case. For example, "Organizer" 308 refers to a role of a "Calendar User" within the scheduling protocol 309 defined by [I-D.ietf-calsify-2446bis]. Calendar components defined 310 by this memo are referred to with capitalized, quoted-strings of 311 text. All calendar components start with the letter "V". For 312 example, "VEVENT" refers to the event calendar component, "VTODO" 313 refers to the to-do calendar component and "VJOURNAL" refers to the 314 daily journal calendar component. Scheduling methods defined by iTIP 315 [I-D.ietf-calsify-2446bis] are referred to with capitalized, quoted- 316 strings of text. For example, "REQUEST" refers to the method for 317 requesting a scheduling calendar component be created or modified, 318 "REPLY" refers to the method a recipient of a request uses to update 319 their status with the "Organizer" of the calendar component. 321 The properties defined by this memo are referred to with capitalized, 322 quoted-strings of text, followed by the word "property". For 323 example, "ATTENDEE" property refers to the iCalendar property used to 324 convey the calendar address of a calendar user. Property parameters 325 defined by this memo are referred to with lowercase, quoted-strings 326 of text, followed by the word "parameter". For example, "value" 327 parameter refers to the iCalendar property parameter used to override 328 the default value type for a property value. Enumerated values 329 defined by this memo are referred to with capitalized text, either 330 alone or followed by the word "value". For example, the "MINUTELY" 331 value can be used with the "FREQ" component of the "RECUR" value type 332 to specify repeating components based on an interval of one minute or 333 more. 335 In this document, descriptions of characters are of the form 336 "character name (codepoint)", where "codepoint" is from the US-ASCII 337 character set. The "character name" is the authoritative 338 description; (codepoint) is a reference to that character in US- 339 ASCII. 341 2.2. Related Memos 343 Implementers will need to be familiar with several other memos that, 344 along with this memo, form a framework for Internet calendaring and 345 scheduling standards. This memo specifies a core specification of 346 objects, value types, properties and property parameters. 348 o iTIP [I-D.ietf-calsify-2446bis] specifies an interoperability 349 protocol for scheduling between different implementations; 351 o iMIP [I-D.ietf-calsify-rfc2447bis] specifies an Internet email 352 binding for [I-D.ietf-calsify-2446bis]. 354 This memo does not attempt to repeat the specification of concepts or 355 definitions from these other memos. Where possible, references are 356 made to the memo that provides for the specification of these 357 concepts or definitions. 359 3. iCalendar Object Specification 361 The following sections define the details of a Calendaring and 362 Scheduling Core Object Specification. This information is intended 363 to be an integral part of the MIME content type registration. In 364 addition, this information can be used independent of such content 365 registration. In particular, this memo has direct applicability for 366 use as a calendaring and scheduling exchange format in file-, memory- 367 or network-based transport mechanisms. 369 3.1. Content Lines 371 The iCalendar object is organized into individual lines of text, 372 called content lines. Content lines are delimited by a line break, 373 which is a CRLF sequence (US-ASCII decimal 13, followed by US-ASCII 374 decimal 10). 376 Lines of text SHOULD NOT be longer than 75 octets, excluding the line 377 break. Long content lines SHOULD be split into a multiple line 378 representations using a line "folding" technique. That is, a long 379 line can be split between any two characters by inserting a CRLF 380 immediately followed by a single linear white space character (i.e., 381 SPACE, US-ASCII decimal 32 or HTAB, US-ASCII decimal 9). Any 382 sequence of CRLF followed immediately by a single linear white space 383 character is ignored (i.e., removed) when processing the content 384 type. 386 For example the line: 388 DESCRIPTION:This is a long description that exists on a long line. 390 Can be represented as: 392 DESCRIPTION:This is a lo 393 ng description 394 that exists on a long line. 396 The process of moving from this folded multiple line representation 397 to its single line representation is called "unfolding". Unfolding 398 is accomplished by removing the CRLF character and the linear white 399 space character that immediately follows. 401 When parsing a content line, folded lines MUST first be unfolded 402 according to the unfolding procedure described above. 404 Note: It is possible for very simple implementations to generate 405 improperly folded lines in the middle of a UTF-8 multi-octet 406 sequence. For this reason, implementations need to unfold lines 407 in such a way to properly restore the original sequence. 409 The content information associated with an iCalendar object is 410 formatted using a syntax similar to that defined by [RFC2425]. That 411 is, the content information consists of CRLF-separated content lines. 413 The following notation defines the lines of content in an iCalendar 414 object: 416 contentline = name *(";" param ) ":" value CRLF 417 ; This ABNF is just a general definition for an initial parsing 418 ; of the content line into its property name, parameter list, 419 ; and value string 421 ; When parsing a content line, folded lines MUST first 422 ; be unfolded according to the unfolding procedure 423 ; described above. When generating a content line, lines 424 ; longer than 75 octets SHOULD be folded according to 425 ; the folding procedure described above. 427 name = iana-token / x-name 429 iana-token = 1*(ALPHA / DIGIT / "-") 430 ; iCalendar identifier registered with IANA 432 x-name = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-") 433 ; Reserved for experimental use. 435 vendorid = 3*(ALPHA / DIGIT) 436 ; Vendor identification 438 param = param-name "=" param-value *("," param-value) 439 ; Each property defines the specific ABNF for the parameters 440 ; allowed on the property. Refer to specific properties for 441 ; precise parameter ABNF. 443 param-name = iana-token / x-name 445 param-value = paramtext / quoted-string 447 paramtext = *SAFE-CHAR 449 value = *VALUE-CHAR 451 quoted-string = DQUOTE *QSAFE-CHAR DQUOTE 453 QSAFE-CHAR = WSP / %x21 / %x23-7E / NON-US-ASCII 454 ; Any character except CONTROL and DQUOTE 455 SAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E 456 / NON-US-ASCII 457 ; Any character except CONTROL, DQUOTE, ";", ":", "," 459 VALUE-CHAR = WSP / %x21-7E / NON-US-ASCII 460 ; Any textual character 462 NON-US-ASCII = UTF8-2 / UTF8-3 / UTF8-4 463 ; UTF8-2, UTF8-3, and UTF8-4 are defined in [RFC3629] 465 CONTROL = %x00-08 / %x0A-1F / %x7F 466 ; All the controls except HTAB 468 The property value component of a content line has a format that is 469 property specific. Refer to the section describing each property for 470 a definition of this format. 472 All names of properties, property parameters, enumerated property 473 values and property parameter values are case-insensitive. However, 474 all other property values are case-sensitive, unless otherwise 475 stated. 477 3.1.1. List and Field Separators 479 Some properties and parameters allow a list of values. Values in a 480 list of values MUST be separated by a COMMA character (US-ASCII 481 decimal 44). There is no significance to the order of values in a 482 list. For those parameter values (such as those that specify URI 483 values) that are specified in quoted-strings, the individual quoted- 484 strings are separated by a COMMA character (US-ASCII decimal 44). 486 Some property values are defined in terms of multiple parts. These 487 structured property values MUST have their value parts separated by a 488 SEMICOLON character (US-ASCII decimal 59). 490 Some properties allow a list of parameters. Each property parameter 491 in a list of property parameters MUST be separated by a SEMICOLON 492 character (US-ASCII decimal 59). 494 Property parameters with values containing a COLON character (US- 495 ASCII decimal 58), a SEMICOLON character (US-ASCII decimal 59) or a 496 COMMA character (US-ASCII decimal 44) MUST be placed in quoted text. 498 For example, in the following properties a SEMICOLON is used to 499 separate property parameters from each other, and a COMMA is used to 500 separate property values in a value list. 502 ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT:mailto: 503 jsmith@example.com 505 RDATE;VALUE=DATE:19970304,19970504,19970704,19970904 507 3.1.2. Multiple Values 509 Some properties defined in the iCalendar object can have multiple 510 values. The general rule for encoding multi-valued items is to 511 simply create a new content line for each value, including the 512 property name. However, it should be noted that some properties 513 support encoding multiple values in a single property by separating 514 the values with a COMMA character (US-ASCII decimal 44). Individual 515 property definitions should be consulted for determining whether a 516 specific property allows multiple values and in which of these two 517 forms. 519 3.1.3. Binary Content 521 Binary content information in an iCalendar object SHOULD be 522 referenced using a URI within a property value. That is the binary 523 content information SHOULD be placed in an external MIME entity that 524 can be referenced by a URI from within the iCalendar object. In 525 applications where this is not feasible, binary content information 526 can be included within an iCalendar object, but only after first 527 encoding it into text using the "BASE64" encoding method defined in 528 [RFC4648]. Inline binary content SHOULD only be used in applications 529 whose special circumstances demand that an iCalendar object be 530 expressed as a single entity. A property containing inline binary 531 content information MUST specify the "ENCODING" property parameter. 532 Binary content information placed external to the iCalendar object 533 MUST be referenced by a uniform resource identifier (URI). 535 The following example specifies an "ATTACH" property that references 536 an attachment external to the iCalendar object with a URI reference: 538 ATTACH:http://example.com/public/quarterly-report.doc 540 The following example specifies an "ATTACH" property with inline 541 binary encoded content information: 543 ATTACH;FMTTYPE=image/basic;ENCODING=BASE64;VALUE=BINARY: 544 MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1U 545 EBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIE 546 <...remainder of "BASE64" encoded binary data...> 548 3.1.4. Character Set 550 There is not a property parameter to declare the charset used in a 551 property value. The default charset for an iCalendar stream is UTF-8 552 as defined in [RFC3629]. 554 The "charset" Content-Type parameter MUST be used in MIME transports 555 to specify the charset being used. 557 3.2. Property Parameters 559 A property can have attributes associated with it. These "property 560 parameters" contain meta-information about the property or the 561 property value. Property parameters are provided to specify such 562 information as the location of an alternate text representation for a 563 property value, the language of a text property value, the value type 564 of the property value and other attributes. 566 Property parameter values that contain the COLON (US-ASCII decimal 567 58), SEMICOLON (US-ASCII decimal 59) or COMMA (US-ASCII decimal 44) 568 character separators MUST be specified as quoted-string text values. 569 Property parameter values MUST NOT contain the DQUOTE (US-ASCII 570 decimal 22) character. The DQUOTE (US-ASCII decimal 22) character is 571 used as a delimiter for parameter values that contain restricted 572 characters or URI text. For example: 574 DESCRIPTION;ALTREP="http://www.example.org":The Fall'98 Wild 575 Wizards Conference - - Las Vegas\, NV\, USA 577 Property parameter values that are not in quoted strings are case 578 insensitive. 580 The general property parameters defined by this memo are defined by 581 the following notation: 583 icalparameter = altrepparam ; Alternate text representation 584 / cnparam ; Common name 585 / cutypeparam ; Calendar user type 586 / delfromparam ; Delegator 587 / deltoparam ; Delegatee 588 / dirparam ; Directory entry 589 / encodingparam ; Inline encoding 590 / fmttypeparam ; Format type 591 / fbtypeparam ; Free/busy time type 592 / languageparam ; Language for text 593 / memberparam ; Group or list membership 594 / partstatparam ; Participation status 595 / trigrelparam ; Alarm trigger relationship 596 / reltypeparam ; Relationship type 597 / roleparam ; Participation role 598 / rsvpparam ; RSVP expectation 599 / sentbyparam ; Sent by 600 / tzidparam ; Reference to time zone object 601 / valuetypeparam ; Property value data type 602 / other-param 604 other-param = (iana-param / x-param) 606 iana-param = iana-token "=" param-value *("," param-value) 607 ; Some other IANA registered iCalendar parameter. 609 x-param = x-name "=" param-value *("," param-value) 610 ; A non-standard, experimental parameter. 612 Applications MUST ignore x-param and iana-param value they don't 613 recognized. 615 3.2.1. Alternate Text Representation 617 Parameter Name: ALTREP 619 Purpose: To specify an alternate text representation for the 620 property value. 622 Format Definition: This property parameter is defined by the 623 following notation: 625 altrepparam = "ALTREP" "=" DQUOTE uri DQUOTE 627 Description: This parameter specifies a URI that points to an 628 alternate representation for a textual property value. A property 629 specifying this parameter MUST also include a value that reflects 630 the default representation of the text value. The individual URI 631 parameter values MUST each be specified in a quoted-string. 633 Example: 635 DESCRIPTION;ALTREP="CID:part3.msg.970415T083000@example.com": 636 Project XYZ Review Meeting will include the following agenda 637 items: (a) Market Overview\, (b) Finances\, (c) Project Man 638 agement 640 The "ALTREP" property parameter value might point to a "text/html" 641 content portion. 643 Content-Type:text/html 644 Content-Id: 646 647 648 649 650 651

652 Project XYZ Review Meeting will include 653 the following agenda items: 654

    655
  1. Market Overview
    2. 656
  2. Finances
    3. 657
  3. Project Management
    4. 658
659

660 661 663 3.2.2. Common Name 665 Parameter Name: CN 667 Purpose: To specify the common name to be associated with the 668 calendar user specified by the property. 670 Format Definition: This property parameter is defined by the 671 following notation: 673 cnparam = "CN" "=" param-value 675 Description: This parameter can be specified on properties with a 676 CAL-ADDRESS value type. The parameter specifies the common name 677 to be associated with the calendar user specified by the property. 678 The parameter value is text. The parameter value can be used for 679 display text to be associated with the calendar address specified 680 by the property. 682 Example: 684 ORGANIZER;CN="John Smith":mailto:jsmith@example.com 686 3.2.3. Calendar User Type 688 Parameter Name: CUTYPE 690 Purpose: To specify the type of calendar user specified by the 691 property. 693 Format Definition: This property parameter is defined by the 694 following notation: 696 cutypeparam = "CUTYPE" "=" 697 ("INDIVIDUAL" ; An individual 698 / "GROUP" ; A group of individuals 699 / "RESOURCE" ; A physical resource 700 / "ROOM" ; A room resource 701 / "UNKNOWN" ; Otherwise not known 702 / x-name ; Experimental type 703 / iana-token) ; Other IANA registered 704 ; type 705 ; Default is INDIVIDUAL 707 Description: This parameter can be specified on properties with a 708 CAL-ADDRESS value type. The parameter identifies the type of 709 calendar user specified by the property. If not specified on a 710 property that allows this parameter, the default is INDIVIDUAL. 711 Applications MUST treat x-name and iana-token value they don't 712 recognized the same way as the INDIVIDUAL value. 714 Example: 716 ATTENDEE;CUTYPE=GROUP:mailto:ietf-calsch@example.org 718 3.2.4. Delegators 719 Parameter Name: DELEGATED-FROM 721 Purpose: To specify the calendar users that have delegated their 722 participation to the calendar user specified by the property. 724 Format Definition: This property parameter is defined by the 725 following notation: 727 delfromparam = "DELEGATED-FROM" "=" DQUOTE cal-address 728 DQUOTE *("," DQUOTE cal-address DQUOTE) 730 Description: This parameter can be specified on properties with a 731 CAL-ADDRESS value type. This parameter specifies those calendar 732 users that have delegated their participation in a group scheduled 733 event or to-do to the calendar user specified by the property. 734 The value MUST be a mailto URI as defined in [RFC2368]. The 735 individual calendar address parameter values MUST each be 736 specified in a quoted-string. 738 Example: 740 ATTENDEE;DELEGATED-FROM="mailto:jsmith@example.com":mailto: 741 jdoe@example.com 743 3.2.5. Delegatees 745 Parameter Name: DELEGATED-TO 747 Purpose: To specify the calendar users to whom the calendar user 748 specified by the property has delegated participation. 750 Format Definition: This property parameter is defined by the 751 following notation: 753 deltoparam = "DELEGATED-TO" "=" DQUOTE cal-address DQUOTE 754 *("," DQUOTE cal-address DQUOTE) 756 Description: This parameter can be specified on properties with a 757 CAL-ADDRESS value type. This parameter specifies those calendar 758 users whom have been delegated participation in a group scheduled 759 event or to-do by the calendar user specified by the property. 760 The value MUST be a mailto URI as defined in [RFC2368]. The 761 individual calendar address parameter values MUST each be 762 specified in a quoted-string. 764 Example: 766 ATTENDEE;DELEGATED-TO="mailto:jdoe@example.com","mailto:jqpublic 767 @example.com":mailto:jsmith@example.com 769 3.2.6. Directory Entry Reference 771 Parameter Name: DIR 773 Purpose: To specify reference to a directory entry associated with 774 the calendar user specified by the property. 776 Format Definition: This property parameter is defined by the 777 following notation: 779 dirparam = "DIR" "=" DQUOTE uri DQUOTE 781 Description: This parameter can be specified on properties with a 782 CAL-ADDRESS value type. The parameter specifies a reference to 783 the directory entry associated with the calendar user specified by 784 the property. The parameter value is a URI. The URI parameter 785 value MUST be specified in a quoted-string. 787 Example: 789 ORGANIZER;DIR="ldap://example.com:6666/o=ABC%20Industries, 790 c=US???(cn=Jim%20Dolittle)":mailto:jimdo@example.com 792 3.2.7. Inline Encoding 794 Parameter Name: ENCODING 796 Purpose: To specify an alternate inline encoding for the property 797 value. 799 Format Definition: This property parameter is defined by the 800 following notation: 802 encodingparam = "ENCODING" "=" 803 ( "8BIT" 804 ; "8bit" text encoding is defined in [RFC2045] 805 / "BASE64" 806 ; "BASE64" binary encoding format is defined in [RFC4648] 807 ) 809 Description: This property parameter identifies the inline encoding 810 used in a property value. The default encoding is "8BIT", 811 corresponding to a property value consisting of text. The 812 "BASE64" encoding type corresponds to a property value encoded 813 using the "BASE64" encoding defined in [RFC2045]. 815 If the value type parameter is ";VALUE=BINARY", then the inline 816 encoding parameter MUST be specified with the value 817 ";ENCODING=BASE64". 819 Example: 821 ATTACH;FMTYPE=IMAGE/JPEG;ENCODING=BASE64;VALUE=BINARY:MIICajC 822 CAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDA 823 qBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMRw 824 <...remainder of "BASE64" encoded binary data...> 826 3.2.8. Format Type 828 Parameter Name: FMTTYPE 830 Purpose: To specify the content type of a referenced object. 832 Format Definition: This property parameter is defined by the 833 following notation: 835 fmttypeparam = "FMTTYPE" "=" type "/" subtype *(";" parameter) 836 ; Where "type", "subtype", and "parameter" 837 ; are defined in section 5.1 of [RFC2045] 839 Description: This parameter can be specified on properties that are 840 used to reference an object. The parameter specifies the content 841 type of the referenced object. For example, on the "ATTACH" 842 property, a FTP type URI value does not, by itself, necessarily 843 convey the type of content associated with the resource. The 844 parameter value MUST be the text for either an IANA registered 845 media type or a non-standard media type. 847 Example: 849 ATTACH;FMTTYPE=application/msword:ftp://example.com/pub/docs/ 850 agenda.doc 852 3.2.9. Free/Busy Time Type 853 Parameter Name: FBTYPE 855 Purpose: To specify the free or busy time type. 857 Format Definition: This property parameter is defined by the 858 following notation: 860 fbtypeparam = "FBTYPE" "=" ("FREE" / "BUSY" 861 / "BUSY-UNAVAILABLE" / "BUSY-TENTATIVE" 862 / x-name 863 ; Some experimental iCalendar free busy type. 864 / iana-token) 865 ; Some other IANA registered iCalendar free busy type. 867 Description: This parameter specifies the free or busy time type. 868 The value FREE indicates that the time interval is free for 869 scheduling. The value BUSY indicates that the time interval is 870 busy because one or more events have been scheduled for that 871 interval. The value BUSY-UNAVAILABLE indicates that the time 872 interval is busy and that the interval can not be scheduled. The 873 value BUSY-TENTATIVE indicates that the time interval is busy 874 because one or more events have been tentatively scheduled for 875 that interval. If not specified on a property that allows this 876 parameter, the default is BUSY. Applications MUST treat x-name 877 and iana-token value they don't recognized the same way as the 878 BUSY value. 880 Example: The following is an example of this parameter on a 881 "FREEBUSY" property. 883 FREEBUSY;FBTYPE=BUSY:19980415T133000Z/19980415T170000Z 885 3.2.10. Language 887 Parameter Name: LANGUAGE 889 Purpose: To specify the language for text values in a property or 890 property parameter. 892 Format Definition: This property parameter is defined by the 893 following notation: 895 languageparam = "LANGUAGE" "=" language 897 language = Language-Tag 898 ; As defined in [RFC4646] 900 Description: This parameter identifies the language of the text in 901 the property value and of all property parameter values of the 902 property. The value of the "LANGUAGE" property parameter is that 903 defined in [RFC4646]. 905 For transport in a MIME entity, the Content-Language header field 906 can be used to set the default language for the entire body part. 907 Otherwise, no default language is assumed. 909 Example: The following are examples of this parameter on the 910 "SUMMARY" and "LOCATION" properties: 912 SUMMARY;LANGUAGE=us-EN:Company Holiday Party 914 LOCATION;LANGUAGE=en:Germany 916 LOCATION;LANGUAGE=no:Tyskland 918 3.2.11. Group or List Membership 920 Parameter Name: MEMBER 922 Purpose: To specify the group or list membership of the calendar 923 user specified by the property. 925 Format Definition: This property parameter is defined by the 926 following notation: 928 memberparam = "MEMBER" "=" DQUOTE cal-address DQUOTE 929 *("," DQUOTE cal-address DQUOTE) 931 Description: This parameter can be specified on properties with a 932 CAL-ADDRESS value type. The parameter identifies the groups or 933 list membership for the calendar user specified by the property. 934 The parameter value is either a single calendar address in a 935 quoted-string or a COMMA character (US-ASCII decimal 44) separated 936 list of calendar addresses, each in a quoted-string. The 937 individual calendar address parameter values MUST each be 938 specified in a quoted-string. 940 Example: 942 ATTENDEE;MEMBER="mailto:ietf-calsch@example.org":mailto: 943 jsmith@example.com 945 ATTENDEE;MEMBER="mailto:projectA@example.com","mailto:pr 946 ojectB@example.com":mailto:janedoe@example.com 948 3.2.12. Participation Status 950 Parameter Name: PARTSTAT 952 Purpose: To specify the participation status for the calendar user 953 specified by the property. 955 Format Definition: This property parameter is defined by the 956 following notation: 958 partstatparam = "PARTSTAT" "=" 959 (partstat-event 960 / partstat-todo 961 / partstat-jour) 963 partstat-event = ("NEEDS-ACTION" ; Event needs action 964 / "ACCEPTED" ; Event accepted 965 / "DECLINED" ; Event declined 966 / "TENTATIVE" ; Event tentatively 967 ; accepted 968 / "DELEGATED" ; Event delegated 969 / x-name ; Experimental status 970 / iana-token) ; Other IANA registered 971 ; status 972 ; These are the participation statuses for a "VEVENT". 973 ; Default is NEEDS-ACTION. 975 partstat-todo = ("NEEDS-ACTION" ; To-do needs action 976 / "ACCEPTED" ; To-do accepted 977 / "DECLINED" ; To-do declined 978 / "TENTATIVE" ; To-do tentatively 979 ; accepted 980 / "DELEGATED" ; To-do delegated 981 / "COMPLETED" ; To-do completed. 982 ; COMPLETED property has 983 ; date/time completed. 984 / "IN-PROCESS" ; To-do in process of 985 ; being completed 986 / x-name ; Experimental status 987 / iana-token) ; Other IANA registered 988 ; status 989 ; These are the participation statuses for a "VTODO". 990 ; Default is NEEDS-ACTION. 992 partstat-jour = ("NEEDS-ACTION" ; Journal needs action 993 / "ACCEPTED" ; Journal accepted 994 / "DECLINED" ; Journal declined 995 / x-name ; Experimental status 996 / iana-token) ; Other IANA registered 997 ; status 998 ; These are the participation statuses for a "VJOURNAL". 999 ; Default is NEEDS-ACTION. 1001 Description: This parameter can be specified on properties with a 1002 CAL-ADDRESS value type. The parameter identifies the 1003 participation status for the calendar user specified by the 1004 property value. The parameter values differ depending on whether 1005 they are associated with a group scheduled "VEVENT", "VTODO" or 1006 "VJOURNAL". The values MUST match one of the values allowed for 1007 the given calendar component. If not specified on a property that 1008 allows this parameter, the default value is NEEDS-ACTION. 1009 Applications MUST treat x-name and iana-token value they don't 1010 recognized the same way as the NEEDS-ACTION value. 1012 Example: 1014 ATTENDEE;PARTSTAT=DECLINED:mailto:jsmith@example.com 1016 3.2.13. Alarm Trigger Relationship 1018 Parameter Name: RELATED 1020 Purpose: To specify the relationship of the alarm trigger with 1021 respect to the start or end of the calendar component. 1023 Format Definition: This property parameter is defined by the 1024 following notation: 1026 trigrelparam = "RELATED" "=" 1027 ("START" ; Trigger off of start 1028 / "END") ; Trigger off of end 1030 Description: This parameter can be specified on properties that 1031 specify an alarm trigger with a "DURATION" value type. The 1032 parameter specifies whether the alarm will trigger relative to the 1033 start or end of the calendar component. The parameter value START 1034 will set the alarm to trigger off the start of the calendar 1035 component; the parameter value END will set the alarm to trigger 1036 off the end of the calendar component. If the parameter is not 1037 specified on an allowable property, then the default is START. 1039 Example: 1041 TRIGGER;RELATED=END:PT5M 1043 3.2.14. Relationship Type 1045 Parameter Name: RELTYPE 1047 Purpose: To specify the type of hierarchical relationship associated 1048 with the calendar component specified by the property. 1050 Format Definition: This property parameter is defined by the 1051 following notation: 1053 reltypeparam = "RELTYPE" "=" 1054 ("PARENT" ; Parent relationship. Default. 1055 / "CHILD" ; Child relationship 1056 / "SIBLING" ; Sibling relationship 1057 / iana-token ; Some other IANA registered 1058 ; iCalendar relationship type 1059 / x-name) ; A non-standard, experimental 1060 ; relationship type 1062 Description: This parameter can be specified on a property that 1063 references another related calendar. The parameter specifies the 1064 hierarchical relationship type of the calendar component 1065 referenced by the property. The parameter value can be PARENT, to 1066 indicate that the referenced calendar component is a superior of 1067 calendar component; CHILD to indicate that the referenced calendar 1068 component is a subordinate of the calendar component; SIBLING to 1069 indicate that the referenced calendar component is a peer of the 1070 calendar component. If this parameter is not specified on an 1071 allowable property, the default relationship type is PARENT. 1072 Applications MUST treat x-name and iana-token value they don't 1073 recognized the same way as the PARENT value. 1075 Example: 1077 RELATED-TO;RELTYPE=SIBLING:19960401-080045-4000F192713@ 1078 example.com 1080 3.2.15. Participation Role 1082 Parameter Name: ROLE 1084 Purpose: To specify the participation role for the calendar user 1085 specified by the property. 1087 Format Definition: This property parameter is defined by the 1088 following notation: 1090 roleparam = "ROLE" "=" 1091 ("CHAIR" ; Indicates chair of the 1092 ; calendar entity 1093 / "REQ-PARTICIPANT" ; Indicates a participant whose 1094 ; participation is required 1095 / "OPT-PARTICIPANT" ; Indicates a participant whose 1096 ; participation is optional 1097 / "NON-PARTICIPANT" ; Indicates a participant who 1098 ; is copied for information 1099 ; purposes only 1100 / x-name ; Experimental role 1101 / iana-token) ; Other IANA role 1102 ; Default is REQ-PARTICIPANT 1104 Description: This parameter can be specified on properties with a 1105 CAL-ADDRESS value type. The parameter specifies the participation 1106 role for the calendar user specified by the property in the group 1107 schedule calendar component. If not specified on a property that 1108 allows this parameter, the default value is REQ-PARTICIPANT. 1109 Applications MUST treat x-name and iana-token value they don't 1110 recognized the same way as the REQ-PARTICIPANT value. 1112 Example: 1114 ATTENDEE;ROLE=CHAIR:mailto:mrbig@example.com 1116 3.2.16. RSVP Expectation 1118 Parameter Name: RSVP 1120 Purpose: To specify whether there is an expectation of a favor of a 1121 reply from the calendar user specified by the property value. 1123 Format Definition: This property parameter is defined by the 1124 following notation: 1126 rsvpparam = "RSVP" "=" ("TRUE" / "FALSE") 1127 ; Default is FALSE 1129 Description: This parameter can be specified on properties with a 1130 CAL-ADDRESS value type. The parameter identifies the expectation 1131 of a reply from the calendar user specified by the property value. 1132 This parameter is used by the "Organizer" to request a 1133 participation status reply from an "Attendee" of a group scheduled 1134 event or to-do. If not specified on a property that allows this 1135 parameter, the default value is FALSE. 1137 Example: 1139 ATTENDEE;RSVP=TRUE:mailto:jsmith@example.com 1141 3.2.17. Sent By 1143 Parameter Name: SENT-BY 1145 Purpose: To specify the calendar user that is acting on behalf of 1146 the calendar user specified by the property. 1148 Format Definition: This property parameter is defined by the 1149 following notation: 1151 sentbyparam = "SENT-BY" "=" DQUOTE cal-address DQUOTE 1153 Description: This parameter can be specified on properties with a 1154 CAL-ADDRESS value type. The parameter specifies the calendar user 1155 that is acting on behalf of the calendar user specified by the 1156 property. The parameter value MUST be a mailto URI as defined in 1157 [RFC2368]. The individual calendar address parameter values MUST 1158 each be specified in a quoted-string. 1160 Example: 1162 ORGANIZER;SENT-BY="mailto:sray@example.com":mailto: 1163 jsmith@example.com 1165 3.2.18. Time Zone Identifier 1167 Parameter Name: TZID 1169 Purpose: To specify the identifier for the time zone definition for 1170 a time component in the property value. 1172 Format Definition: This property parameter is defined by the 1173 following notation: 1175 tzidparam = "TZID" "=" [tzidprefix] paramtext 1177 tzidprefix = "/" 1179 Description: This parameter MUST be specified on the "DTSTART", 1180 "DTEND", "DUE", "EXDATE" and "RDATE" properties when either a 1181 DATE-TIME or TIME value type is specified and when the value is 1182 not either a UTC or a "floating" time. Refer to the DATE-TIME or 1183 TIME value type definition for a description of UTC and "floating 1184 time" formats. This property parameter specifies a text value 1185 which uniquely identifies the "VTIMEZONE" calendar component to be 1186 used when evaluating the time portion of the property. The value 1187 of the "TZID" property parameter will be equal to the value of the 1188 "TZID" property for the matching time zone definition. An 1189 individual "VTIMEZONE" calendar component MUST be specified for 1190 each unique "TZID" parameter value specified in the iCalendar 1191 object. 1193 The parameter MUST be specified on properties with a DATE-TIME 1194 value if the DATE-TIME is not either a UTC or a "floating" time. 1196 The presence of the SOLIDUS character (US-ASCII decimal 47) as a 1197 prefix, indicates that this "TZID" represents a unique ID in a 1198 globally defined time zone registry (when such registry is 1199 defined). 1201 Note: This document does not define a naming convention for 1202 time zone identifiers. Implementers may want to use the naming 1203 conventions defined in existing time zone specifications such 1204 as the public-domain TZ database [TZDB]. The specification of 1205 globally unique time zone identifiers is not addressed by this 1206 document and is left for future study. 1208 The following are examples of this property parameter: 1210 DTSTART;TZID=America/New_York:19980119T020000 1212 DTEND;TZID=America/New_York:19980119T030000 1214 The "TZID" property parameter MUST NOT be applied to DATE 1215 properties, and DATE-TIME or TIME properties whose time values are 1216 specified in UTC. 1218 The use of local time in a DATE-TIME or TIME value without the 1219 "TZID" property parameter is to be interpreted as a local time 1220 value, regardless of the existence of "VTIMEZONE" calendar 1221 components in the iCalendar object. 1223 For more information see the sections on the value types DATE-TIME 1224 and TIME. 1226 3.2.19. Value Data Types 1228 Parameter Name: VALUE 1229 Purpose: To explicitly specify the value type format for a property 1230 value. 1232 Format Definition: This property parameter is defined by the 1233 following notation: 1235 valuetypeparam = "VALUE" "=" valuetype 1237 valuetype = ("BINARY" 1238 / "BOOLEAN" 1239 / "CAL-ADDRESS" 1240 / "DATE" 1241 / "DATE-TIME" 1242 / "DURATION" 1243 / "FLOAT" 1244 / "INTEGER" 1245 / "PERIOD" 1246 / "RECUR" 1247 / "TEXT" 1248 / "TIME" 1249 / "URI" 1250 / "UTC-OFFSET" 1251 / x-name 1252 ; Some experimental iCalendar value type. 1253 / iana-token) 1254 ; Some other IANA registered iCalendar value type. 1256 Description: This parameter specifies the value type and format of 1257 the property value. The property values MUST be of a single value 1258 type. For example, a "RDATE" property cannot have a combination 1259 of DATE-TIME and TIME value types. 1261 If the property's value is the default value type, then this 1262 parameter need not be specified. However, if the property's 1263 default value type is overridden by some other allowable value 1264 type, then this parameter MUST be specified. 1266 Applications MUST treat x-name and iana-token value they don't 1267 recognized the same way as the TEXT value. 1269 3.3. Property Value Data Types 1271 The properties in an iCalendar object are strongly typed. The 1272 definition of each property restricts the value to be one of the 1273 value data types, or simply value types, defined in this section. 1274 The value type for a property will either be specified implicitly as 1275 the default value type or will be explicitly specified with the 1276 "VALUE" parameter. If the value type of a property is one of the 1277 alternate valid types, then it MUST be explicitly specified with the 1278 "VALUE" parameter. 1280 3.3.1. Binary 1282 Value Name: BINARY 1284 Purpose: This value type is used to identify properties that contain 1285 a character encoding of inline binary data. For example, an 1286 inline attachment of a document might be included in an iCalendar 1287 object. 1289 Format Definition: This value type is defined by the following 1290 notation: 1292 binary = *(4b-char) [b-end] 1293 ; A "BASE64" encoded character string, as defined by [RFC4648]. 1295 b-end = (2b-char "==") / (3b-char "=") 1297 b-char = ALPHA / DIGIT / "+" / "/" 1299 Description: Property values with this value type MUST also include 1300 the inline encoding parameter sequence of ";ENCODING=BASE64". 1301 That is, all inline binary data MUST first be character encoded 1302 using the "BASE64" encoding method defined in [RFC2045]. No 1303 additional content value encoding (i.e., BACKSLASH character 1304 encoding) is defined for this value type. 1306 Example: The following is an abridged example of a "BASE64" encoded 1307 binary value data. 1309 JKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlI 1310 ENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZv 1311 <...remainder of "BASE64" encoded binary data...> 1313 3.3.2. Boolean 1315 Value Name: BOOLEAN 1317 Purpose: This value type is used to identify properties that contain 1318 either a "TRUE" or "FALSE" Boolean value. 1320 Format Definition: This value type is defined by the following 1321 notation: 1323 boolean = "TRUE" / "FALSE" 1325 Description: These values are case insensitive text. No additional 1326 content value encoding (i.e., BACKSLASH character encoding) is 1327 defined for this value type. 1329 Example: The following is an example of a hypothetical property that 1330 has a BOOLEAN value type: 1332 TRUE 1334 3.3.3. Calendar User Address 1336 Value Name: CAL-ADDRESS 1338 Purpose: This value type is used to identify properties that contain 1339 a calendar user address. 1341 Format Definition: This value type is defined by the following 1342 notation: 1344 cal-address = uri 1346 Description: The value is a URI as defined by [RFC3986] or any other 1347 IANA registered form for a URI. When used to address an Internet 1348 email transport address for a calendar user, the value MUST be a 1349 mailto URI, as defined by [RFC2368]. No additional content value 1350 encoding (i.e., BACKSLASH character encoding) is defined for this 1351 value type. 1353 Example: 1355 mailto:jane_doe@example.com 1357 3.3.4. Date 1359 Value Name: DATE 1361 Purpose: This value type is used to identify values that contain a 1362 calendar date. 1364 Format Definition: This value type is defined by the following 1365 notation: 1367 date = date-value 1369 date-value = date-fullyear date-month date-mday 1370 date-fullyear = 4DIGIT 1371 date-month = 2DIGIT ;01-12 1372 date-mday = 2DIGIT ;01-28, 01-29, 01-30, 01-31 1373 ;based on month/year 1375 Description: If the property permits, multiple "date" values are 1376 specified as a COMMA character (US-ASCII decimal 44) separated 1377 list of values. The format for the value type is based on the 1378 [ISO.8601.2004] complete representation, basic format for a 1379 calendar date. The textual format specifies a four-digit year, 1380 two-digit month, and two-digit day of the month. There are no 1381 separator characters between the year, month and day component 1382 text. 1384 No additional content value encoding (i.e., BACKSLASH character 1385 encoding) is defined for this value type. 1387 Example: The following represents July 14, 1997: 1389 19970714 1391 3.3.5. Date-Time 1393 Value Name: DATE-TIME 1395 Purpose: This value type is used to identify values that specify a 1396 precise calendar date and time of day. 1398 Format Definition: This value type is defined by the following 1399 notation: 1401 date-time = date "T" time ;As specified in the date and time 1402 ;value definitions 1404 Description: If the property permits, multiple "date-time" values 1405 are specified as a COMMA character (US-ASCII decimal 44) separated 1406 list of values. No additional content value encoding (i.e., 1407 BACKSLASH character encoding) is defined for this value type. 1409 The "DATE-TIME" value type is used to identify values that contain 1410 a precise calendar date and time of day. The format is based on 1411 the [ISO.8601.2004] complete representation, basic format for a 1412 calendar date and time of day. The text format is a concatenation 1413 of the "date", followed by the LATIN CAPITAL LETTER T character 1414 (US-ASCII decimal 84) time designator, followed by the "time" 1415 format. 1417 The "DATE-TIME" value type expresses time values in three forms: 1419 The form of date and time with UTC offset MUST NOT be used. For 1420 example, the following is not valid for a date-time value: 1422 19980119T230000-0800 ;Invalid time format 1424 FORM #1: DATE WITH LOCAL TIME 1426 The date with local time form is simply a date-time value that 1427 does not contain the UTC designator nor does it reference a time 1428 zone. For example, the following represents January 18, 1998, at 1429 11 PM: 1431 19980118T230000 1433 Date-time values of this type are said to be "floating" and are 1434 not bound to any time zone in particular. They are used to 1435 represent the same hour, minute, and second value regardless of 1436 which time zone is currently being observed. For example, an 1437 event can be defined that indicates that an individual will be 1438 busy from 11:00 AM to 1:00 PM every day, no matter which time zone 1439 the person is in. In these cases, a local time can be specified. 1440 The recipient of an iCalendar object with a property value 1441 consisting of a local time, without any relative time zone 1442 information, SHOULD interpret the value as being fixed to whatever 1443 time zone the "ATTENDEE" is in at any given moment. This means 1444 that two "Attendees", in different time zones, receiving the same 1445 event definition as a floating time, may be participating in the 1446 event at different actual times. Floating time SHOULD only be 1447 used where that is the reasonable behavior. 1449 In most cases, a fixed time is desired. To properly communicate a 1450 fixed time in a property value, either UTC time or local time with 1451 time zone reference MUST be specified. 1453 The use of local time in a DATE-TIME value without the "TZID" 1454 property parameter is to be interpreted as floating time, 1455 regardless of the existence of "VTIMEZONE" calendar components in 1456 the iCalendar object. 1458 FORM #2: DATE WITH UTC TIME 1460 The date with UTC time, or absolute time, is identified by a LATIN 1461 CAPITAL LETTER Z suffix character (US-ASCII decimal 90), the UTC 1462 designator, appended to the time value. For example, the 1463 following represents January 19, 1998, at 0700 UTC: 1465 19980119T070000Z 1467 The "TZID" property parameter MUST NOT be applied to DATE-TIME 1468 properties whose time values are specified in UTC. 1470 FORM #3: DATE WITH LOCAL TIME AND TIME ZONE REFERENCE 1472 The date and local time with reference to time zone information is 1473 identified by the use the "TZID" property parameter to reference 1474 the appropriate time zone definition. "TZID" is discussed in 1475 detail in Section 3.2.18. For example, the following represents 1476 2:00 A.M. in New York on Janurary 19, 1998: 1478 TZID=America/New_York:19980119T020000 1480 If, based on the definition of the referenced time zone, the local 1481 time described occurs more than once (when changing from daylight 1482 to standard time), the DATE-TIME value refers to the first 1483 occurence of the referenced time. Thus, TZID=America/ 1484 New_York:20071104T013000 indicates November 4, 2007 at 1:30 A.M. 1485 EDT (UTC-04:00). If the local time described does not occur (when 1486 changing from standard to daylight time), the DATE-TIME value is 1487 interpreted using the UTC offset before the gap in local times. 1488 Thus, TZID=America/New_York:20070311T023000 indicates March 11, 1489 2007 at 3:30 A.M. EDT (UTC-04:00), one hour after 1:30 A.M. EST 1490 (UTC-05:00). 1492 A time value MUST only specify the second 60 when specifying a 1493 positive leap second. For example: 1495 19970630T235960Z 1497 Implementations which do not support leap seconds SHOULD interpret 1498 the second 60 as equivalent to the second 59. 1500 Example: The following represents July 14, 1997, at 1:30 PM in New 1501 York City in each of the three time formats, using the "DTSTART" 1502 property. 1504 DTSTART:19970714T133000 ; Local time 1505 DTSTART:19970714T173000Z ; UTC time 1506 DTSTART;TZID=America/New_York:19970714T133000 1507 ; Local time and time 1508 ; zone reference 1510 3.3.6. Duration 1511 Value Name: DURATION 1513 Purpose: This value type is used to identify properties that contain 1514 a duration of time. 1516 Format Definition: This value type is defined by the following 1517 notation: 1519 dur-value = (["+"] / "-") "P" (dur-date / dur-time / dur-week) 1521 dur-date = dur-day [dur-time] 1522 dur-time = "T" (dur-hour / dur-minute / dur-second) 1523 dur-week = 1*DIGIT "W" 1524 dur-hour = 1*DIGIT "H" [dur-minute] 1525 dur-minute = 1*DIGIT "M" [dur-second] 1526 dur-second = 1*DIGIT "S" 1527 dur-day = 1*DIGIT "D" 1529 Description: If the property permits, multiple "duration" values are 1530 specified by a COMMA character (US-ASCII decimal 44) separated 1531 list of values. The format is based on the [ISO.8601.2004] 1532 complete representation basic format with designators for the 1533 duration of time. The format can represent nominal durations 1534 (weeks and days) and accurate durations (hours, minutes, and 1535 seconds). Note that unlike [ISO.8601.2004] this value type 1536 doesn't support the "Y" and "M" designators to specify durations 1537 in terms of years and months. 1539 The duration of a week or a day depends on its position in the 1540 calendar. In the case of discontinuities in the time scale, such 1541 as the change from standard time to daylight time and back, the 1542 computation of the exact duration requires the substraction or 1543 addition of the change of duration of the discontinuity. Leap 1544 seconds MUST NOT be considered when computing an exact duration. 1545 When computing an exact duration, the greatest order time 1546 components MUST be added first, that is, the number of weeks MUST 1547 be added first, followed by the number of days, number of hours, 1548 number of minutes, and number of seconds. 1550 Negative durations are typically used to schedule an alarm to 1551 trigger before an associated time (see Section 3.8.6.3). 1553 No additional content value encoding (i.e., BACKSLASH character 1554 encoding) are defined for this value type. 1556 Example: A duration of 15 days, 5 hours and 20 seconds would be: 1558 P15DT5H0M20S 1560 A duration of 7 weeks would be: 1562 P7W 1564 3.3.7. Float 1566 Value Name: FLOAT 1568 Purpose: This value type is used to identify properties that contain 1569 a real number value. 1571 Format Definition: This value type is defined by the following 1572 notation: 1574 float = (["+"] / "-") 1*DIGIT ["." 1*DIGIT] 1576 Description: If the property permits, multiple "float" values are 1577 specified by a COMMA character (US-ASCII decimal 44) separated 1578 list of values. 1580 No additional content value encoding (i.e., BACKSLASH character 1581 encoding) is defined for this value type. 1583 Example: 1585 1000000.0000001 1586 1.333 1587 -3.14 1589 3.3.8. Integer 1591 Value Name: INTEGER 1593 Purpose: This value type is used to identify properties that contain 1594 a signed integer value. 1596 Format Definition: This value type is defined by the following 1597 notation: 1599 integer = (["+"] / "-") 1*DIGIT 1601 Description: If the property permits, multiple "integer" values are 1602 specified by a COMMA character (US-ASCII decimal 44) separated 1603 list of values. The valid range for "integer" is -2147483648 to 1604 2147483647. If the sign is not specified, then the value is 1605 assumed to be positive. 1607 No additional content value encoding (i.e., BACKSLASH character 1608 encoding) is defined for this value type. 1610 Example: 1612 1234567890 1613 -1234567890 1614 +1234567890 1615 432109876 1617 3.3.9. Period of Time 1619 Value Name: PERIOD 1621 Purpose: This value type is used to identify values that contain a 1622 precise period of time. 1624 Format Definition: This value type is defined by the following 1625 notation: 1627 period = period-explicit / period-start 1629 period-explicit = date-time "/" date-time 1630 ; [ISO.8601.2004] complete representation basic format for a 1631 ; period of time consisting of a start and end. The start MUST 1632 ; be before the end. 1634 period-start = date-time "/" dur-value 1635 ; [ISO.8601.2004] complete representation basic format for a 1636 ; period of time consisting of a start and positive duration 1637 ; of time. 1639 Description: If the property permits, multiple "period" values are 1640 specified by a COMMA character (US-ASCII decimal 44) separated 1641 list of values. There are two forms of a period of time. First, 1642 a period of time is identified by its start and its end. This 1643 format is based on the [ISO.8601.2004] complete representation, 1644 basic format for "DATE-TIME" start of the period, followed by a 1645 SOLIDUS character (US-ASCII decimal 47), followed by the "DATE- 1646 TIME" of the end of the period. The start of the period MUST be 1647 before the end of the period. Second, a period of time can also 1648 be defined by a start and a positive duration of time. The format 1649 is based on the [ISO.8601.2004] complete representation, basic 1650 format for the "DATE-TIME" start of the period, followed by a 1651 SOLIDUS character (US-ASCII decimal 47), followed by the 1652 [ISO.8601.2004] basic format for "DURATION" of the period. 1654 Example: The period starting at 18:00:00 UTC, on January 1, 1997 and 1655 ending at 07:00:00 UTC on January 2, 1997 would be: 1657 19970101T180000Z/19970102T070000Z 1659 The period start at 18:00:00 on January 1, 1997 and lasting 5 1660 hours and 30 minutes would be: 1662 19970101T180000Z/PT5H30M 1664 No additional content value encoding (i.e., BACKSLASH character 1665 encoding) is defined for this value type. 1667 3.3.10. Recurrence Rule 1669 Value Name: RECUR 1671 Purpose: This value type is used to identify properties that contain 1672 a recurrence rule specification. 1674 Format Definition: This value type is defined by the following 1675 notation: 1677 recur = recur-rule-part *( ";" recur-rule-part ) 1678 ; 1679 ; The rule parts are not ordered in any 1680 ; particular sequence 1681 ; 1682 ; The FREQ rule part is REQUIRED, 1683 ; but MUST NOT occur more than once 1684 ; 1685 ; The UNTIL or COUNT rule parts are OPTIONAL, 1686 ; but they MUST NOT occur in the same 'recur' 1687 ; 1688 ; The other rule parts are OPTIONAL, 1689 ; but MUST NOT occur more than once 1691 recur-rule-part = ( "FREQ" "=" freq ) 1692 / ( "UNTIL" "=" enddate ) 1693 / ( "COUNT" "=" 1*DIGIT ) 1694 / ( "INTERVAL" "=" 1*DIGIT ) 1695 / ( "BYSECOND" "=" byseclist ) 1696 / ( "BYMINUTE" "=" byminlist ) 1697 / ( "BYHOUR" "=" byhrlist ) 1698 / ( "BYDAY" "=" bywdaylist ) 1699 / ( "BYMONTHDAY" "=" bymodaylist ) 1700 / ( "BYYEARDAY" "=" byyrdaylist ) 1701 / ( "BYWEEKNO" "=" bywknolist ) 1702 / ( "BYMONTH" "=" bymolist ) 1703 / ( "BYSETPOS" "=" bysplist ) 1704 / ( "WKST" "=" weekday ) 1706 freq = "SECONDLY" / "MINUTELY" / "HOURLY" / "DAILY" 1707 / "WEEKLY" / "MONTHLY" / "YEARLY" 1709 enddate = date / date-time ;A UTC value 1711 byseclist = ( seconds *("," seconds) ) 1713 seconds = 1*2DIGIT ;0 to 60 1715 byminlist = ( minutes *("," minutes) ) 1717 minutes = 1*2DIGIT ;0 to 59 1719 byhrlist = ( hour *("," hour) ) 1721 hour = 1*2DIGIT ;0 to 23 1723 bywdaylist = ( weekdaynum *("," weekdaynum) ) 1725 weekdaynum = [[plus / minus] ordwk] weekday 1727 plus = "+" 1729 minus = "-" 1731 ordwk = 1*2DIGIT ;1 to 53 1733 weekday = "SU" / "MO" / "TU" / "WE" / "TH" / "FR" / "SA" 1734 ;Corresponding to SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, 1735 ;FRIDAY, and SATURDAY days of the week. 1737 bymodaylist = ( monthdaynum *("," monthdaynum) ) 1739 monthdaynum = [plus / minus] ordmoday 1741 ordmoday = 1*2DIGIT ;1 to 31 1743 byyrdaylist = ( yeardaynum *("," yeardaynum) ) 1744 yeardaynum = [plus / minus] ordyrday 1746 ordyrday = 1*3DIGIT ;1 to 366 1748 bywknolist = ( weeknum *("," weeknum) ) 1750 weeknum = [plus / minus] ordwk 1752 bymolist = ( monthnum *("," monthnum) ) 1754 monthnum = 1*2DIGIT ;1 to 12 1756 bysplist = ( setposday *("," setposday) ) 1758 setposday = yeardaynum 1760 Description: This value type is a structured value consisting of a 1761 list of one or more recurrence grammar parts. Each rule part is 1762 defined by a NAME=VALUE pair. The rule parts are separated from 1763 each other by the SEMICOLON character (US-ASCII decimal 59). The 1764 rule parts are not ordered in any particular sequence. Individual 1765 rule parts MUST only be specified once. 1767 Note: Compliant applications MUST accept rule parts ordered in 1768 any sequence, but to ensure backward compatibility with 1769 applications that pre-date this revision of iCalendar the FREQ 1770 rule part MUST be the first rule part specified in a RECUR 1771 value. 1773 The FREQ rule part identifies the type of recurrence rule. This 1774 rule part MUST be specified in the recurrence rule. Valid values 1775 include SECONDLY, to specify repeating events based on an interval 1776 of a second or more; MINUTELY, to specify repeating events based 1777 on an interval of a minute or more; HOURLY, to specify repeating 1778 events based on an interval of an hour or more; DAILY, to specify 1779 repeating events based on an interval of a day or more; WEEKLY, to 1780 specify repeating events based on an interval of a week or more; 1781 MONTHLY, to specify repeating events based on an interval of a 1782 month or more; and YEARLY, to specify repeating events based on an 1783 interval of a year or more. 1785 The INTERVAL rule part contains a positive integer representing 1786 how often the recurrence rule repeats. The default value is "1", 1787 meaning every second for a SECONDLY rule, or every minute for a 1788 MINUTELY rule, every hour for an HOURLY rule, every day for a 1789 DAILY rule, every week for a WEEKLY rule, every month for a 1790 MONTHLY rule and every year for a YEARLY rule. 1792 The UNTIL rule part defines a DATE or DATE-TIME value which bounds 1793 the recurrence rule in an inclusive manner. If the value 1794 specified by UNTIL is synchronized with the specified recurrence, 1795 this DATE or DATE-TIME becomes the last instance of the 1796 recurrence. The value of the UNTIL rule part MUST have the same 1797 value type as the "DTSTART" property. Furthermore, if the 1798 "DTSTART" property is specified as a date with local time, then 1799 the UNTIL rule part MUST also be specified as a date with local 1800 time. Else, if the "DTSTART" property is specified as a date with 1801 UTC time or a date with local time and time zone reference, then 1802 the UNTIL rule part MUST be specified as a date with UTC time. In 1803 the case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL 1804 rule part MUST always be specified as a date with UTC time. If 1805 specified as a DATE-TIME value, then it MUST be specified in a UTC 1806 time format. If not present, and the COUNT rule part is also not 1807 present, the "RRULE" is considered to repeat forever. 1809 The COUNT rule part defines the number of occurrences at which to 1810 range-bound the recurrence. The "DTSTART" property value always 1811 counts as the first occurrence. 1813 The BYSECOND rule part specifies a COMMA character (US-ASCII 1814 decimal 44) separated list of seconds within a minute. Valid 1815 values are 0 to 60. The BYMINUTE rule part specifies a COMMA 1816 character (US-ASCII decimal 44) separated list of minutes within 1817 an hour. Valid values are 0 to 59. The BYHOUR rule part 1818 specifies a COMMA character (US-ASCII decimal 44) separated list 1819 of hours of the day. Valid values are 0 to 23. The BYSECOND, 1820 BYMINUTE and BYHOUR rule parts MUST NOT be specified when the 1821 associated "DTSTART" property has a DATE value type. These rule 1822 parts MUST be ignored in RECUR value that violate the above 1823 requirement (e.g., generated by applications that pre-date this 1824 revision of iCalendar). 1826 The BYDAY rule part specifies a COMMA character (US-ASCII decimal 1827 44) separated list of days of the week; SU indicates Sunday; MO 1828 indicates Monday; TU indicates Tuesday; WE indicates Wednesday; TH 1829 indicates Thursday; FR indicates Friday; SA indicates Saturday. 1831 Each BYDAY value can also be preceded by a positive (+n) or 1832 negative (-n) integer. If present, this indicates the nth 1833 occurrence of the specific day within the MONTHLY or YEARLY 1834 "RRULE". For example, within a MONTHLY rule, +1MO (or simply 1MO) 1835 represents the first Monday within the month, whereas -1MO 1836 represents the last Monday of the month. If an integer modifier 1837 is not present, it means all days of this type within the 1838 specified frequency. For example, within a MONTHLY rule, MO 1839 represents all Mondays within the month. The BYDAY rule part MUST 1840 NOT be specified with a numeric value when the FREQ rule part is 1841 not set to MONTHLY or YEARLY. Furthermore, the BYDAY rule part 1842 MUST NOT be specified with a numeric value with the FREQ rule part 1843 set to YEARLY when the BYWEEKNO rule part is specified. The 1844 numeric value in a BYDAY rule part with the FREQ rule part set to 1845 YEARLY corresponds to an offset within the month when the BYMONTH 1846 rule part is present, and corresponds to an offset within the year 1847 when the BYWEEKNO or BYMONTH rule parts are present. 1849 The BYMONTHDAY rule part specifies a COMMA character (US-ASCII 1850 decimal 44) separated list of days of the month. Valid values are 1851 1 to 31 or -31 to -1. For example, -10 represents the tenth to 1852 the last day of the month. The BYMONTHDAY rule part MUST NOT be 1853 specified when the FREQ rule part is set to WEEKLY. 1855 The BYYEARDAY rule part specifies a COMMA character (US-ASCII 1856 decimal 44) separated list of days of the year. Valid values are 1857 1 to 366 or -366 to -1. For example, -1 represents the last day 1858 of the year (December 31st) and -306 represents the 306th to the 1859 last day of the year (March 1st). The BYYEARDAY rule part MUST 1860 NOT be specified when the FREQ rule part is set to DAILY, WEEKLY, 1861 and MONTHLY. 1863 The BYWEEKNO rule part specifies a COMMA character (US-ASCII 1864 decimal 44) separated list of ordinals specifying weeks of the 1865 year. Valid values are 1 to 53 or -53 to -1. This corresponds to 1866 weeks according to week numbering as defined in [ISO.8601.2004]. 1867 A week is defined as a seven day period, starting on the day of 1868 the week defined to be the week start (see WKST). Week number one 1869 of the calendar year is the first week which contains at least 1870 four (4) days in that calendar year. This rule part MUST NOT be 1871 used when the FREQ rule part is not set to YEARLY. For example, 3 1872 represents the third week of the year. 1874 Note: Assuming a Monday week start, week 53 can only occur when 1875 Thursday is January 1 or if it is a leap year and Wednesday is 1876 January 1. 1878 The BYMONTH rule part specifies a COMMA character (US-ASCII 1879 decimal 44) separated list of months of the year. Valid values 1880 are 1 to 12. 1882 The WKST rule part specifies the day on which the workweek starts. 1883 Valid values are MO, TU, WE, TH, FR, SA and SU. This is 1884 significant when a WEEKLY "RRULE" has an interval greater than 1, 1885 and a BYDAY rule part is specified. This is also significant when 1886 in a YEARLY "RRULE" when a BYWEEKNO rule part is specified. The 1887 default value is MO. 1889 The BYSETPOS rule part specifies a COMMA character (US-ASCII 1890 decimal 44) separated list of values which corresponds to the nth 1891 occurrence within the set of recurrence instances specified by the 1892 rule. BYSETPOS operates on a set of recurrence instances in one 1893 interval of the recurrence rule. For a WEEKLY rule, the interval 1894 is one week, for a MONTHLY rule, one month, and for a YEARLY rule, 1895 one year. Valid values are 1 to 366 or -366 to -1. It MUST only 1896 be used in conjunction with another BYxxx rule part. For example 1897 "the last work day of the month" could be represented as: 1899 FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1 1901 Each BYSETPOS value can include a positive (+n) or negative (-n) 1902 integer. If present, this indicates the nth occurrence of the 1903 specific occurrence within the set of occurences specified by the 1904 rule. 1906 Recurrence rules may generate recurrence instances with invalid 1907 date (e.g., February 30) or nonexistent local time (e.g., 1:30 AM 1908 on a day where the local time is moved forward by an hour at 1:00 1909 AM). Such recurrence instances MUST be ignored and MUST NOT be 1910 counted as part of the recurrence set. 1912 Information, not contained in the rule, necessary to determine the 1913 various recurrence instance start time and dates are derived from 1914 the Start Time ("DTSTART") component attribute. For example, 1915 "FREQ=YEARLY;BYMONTH=1" doesn't specify a specific day within the 1916 month or a time. This information would be the same as what is 1917 specified for "DTSTART". 1919 BYxxx rule parts modify the recurrence in some manner. BYxxx rule 1920 parts for a period of time which is the same or greater than the 1921 frequency generally reduce or limit the number of occurrences of 1922 the recurrence generated. For example, "FREQ=DAILY;BYMONTH=1" 1923 reduces the number of recurrence instances from all days (if 1924 BYMONTH rule part is not present) to all days in January. BYxxx 1925 rule parts for a period of time less than the frequency generally 1926 increase or expand the number of occurrences of the recurrence. 1927 For example, "FREQ=YEARLY;BYMONTH=1,2" increases the number of 1928 days within the yearly recurrence set from 1 (if BYMONTH rule part 1929 is not present) to 2. 1931 If multiple BYxxx rule parts are specified, then after evaluating 1932 the specified FREQ and INTERVAL rule parts, the BYxxx rule parts 1933 are applied to the current set of evaluated occurrences in the 1934 following order: BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY, BYDAY, 1935 BYHOUR, BYMINUTE, BYSECOND and BYSETPOS; then COUNT and UNTIL are 1936 evaluated. 1938 The table below summarizes the dependency of BYxxx rule part 1939 expand or limit behaviour on the FREQ rule part value. 1941 The term "N/A" means that the corresponding BYxxx rule part MUST 1942 NOT be used with the corresponding FREQ value. 1944 BYDAY has some special behaviour depending on the FREQ value and 1945 this is described in separate notes below the table. 1947 +----------+--------+--------+-------+-------+------+-------+------+ 1948 | |SECONDLY|MINUTELY|HOURLY |DAILY |WEEKLY|MONTHLY|YEARLY| 1949 +----------+--------+--------+-------+-------+------+-------+------+ 1950 |BYMONTH |Limit |Limit |Limit |Limit |Limit |Limit |Expand| 1951 +----------+--------+--------+-------+-------+------+-------+------+ 1952 |BYWEEKNO |N/A |N/A |N/A |N/A |N/A |N/A |Expand| 1953 +----------+--------+--------+-------+-------+------+-------+------+ 1954 |BYYEARDAY |Limit |Limit |Limit |N/A |N/A |N/A |Expand| 1955 +----------+--------+--------+-------+-------+------+-------+------+ 1956 |BYMONTHDAY|Limit |Limit |Limit |Limit |N/A |Expand |Expand| 1957 +----------+--------+--------+-------+-------+------+-------+------+ 1958 |BYDAY |Limit |Limit |Limit |Limit |Expand|Note 1 |Note 2| 1959 +----------+--------+--------+-------+-------+------+-------+------+ 1960 |BYHOUR |Limit |Limit |Limit |Expand |Expand|Expand |Expand| 1961 +----------+--------+--------+-------+-------+------+-------+------+ 1962 |BYMINUTE |Limit |Limit |Expand |Expand |Expand|Expand |Expand| 1963 +----------+--------+--------+-------+-------+------+-------+------+ 1964 |BYSECOND |Limit |Expand |Expand |Expand |Expand|Expand |Expand| 1965 +----------+--------+--------+-------+-------+------+-------+------+ 1966 |BYSETPOS |Limit |Limit |Limit |Limit |Limit |Limit |Limit | 1967 +----------+--------+--------+-------+-------+------+-------+------+ 1969 Note 1: Limit if BYMONTHDAY is present, otherwise special expand 1970 for MONTHLY. 1972 Note 2: Limit if BYYEARDAY or BYMONTHDAY is present, otherwise 1973 special expand for WEEKLY if BYWEEKNO present, otherwise 1974 special expand for MONTHLY if BYMONTH present, otherwise 1975 special expand for YEARLY. 1977 Here is an example of evaluating multiple BYxxx rule parts. 1979 DTSTART;TZID=America/New_York:19970105T083000 1980 RRULE:FREQ=YEARLY;INTERVAL=2;BYMONTH=1;BYDAY=SU;BYHOUR=8,9; 1981 BYMINUTE=30 1983 First, the "INTERVAL=2" would be applied to "FREQ=YEARLY" to 1984 arrive at "every other year". Then, "BYMONTH=1" would be applied 1985 to arrive at "every January, every other year". Then, "BYDAY=SU" 1986 would be applied to arrive at "every Sunday in January, every 1987 other year". Then, "BYHOUR=8,9" would be applied to arrive at 1988 "every Sunday in January at 8 AM and 9 AM, every other year". 1989 Then, "BYMINUTE=30" would be applied to arrive at "every Sunday in 1990 January at 8:30 AM and 9:30 AM, every other year". Then, lacking 1991 information from "RRULE", the second is derived from "DTSTART", to 1992 end up in "every Sunday in January at 8:30:00 AM and 9:30:00 AM, 1993 every other year". Similarly, if the BYMINUTE, BYHOUR, BYDAY, 1994 BYMONTHDAY or BYMONTH rule part were missing, the appropriate 1995 minute, hour, day or month would have been retrieved from the 1996 "DTSTART" property. 1998 If the computed local start time of a recurrence instance does not 1999 exist, or occurs more than once, for the specified time zone, the 2000 time of the recurrence instance is interpreted in the same manner 2001 as an explicit DATE-TIME value describing that date and time, as 2002 specified in Section 3.3.5. 2004 No additional content value encoding (i.e., BACKSLASH character 2005 encoding) is defined for this value type. 2007 Example: The following is a rule which specifies 10 occurences which 2008 occur every other day: 2010 FREQ=DAILY;COUNT=10;INTERVAL=2 2012 There are other examples specified in Section 3.8.5.3. 2014 3.3.11. Text 2016 Value Name: TEXT 2018 Purpose: This value type is used to identify values that contain 2019 human readable text. 2021 Format Definition: This value type is defined by the following 2022 notation. 2024 text = *(TSAFE-CHAR / ":" / DQUOTE / ESCAPED-CHAR) 2025 ; Folded according to description above 2027 ESCAPED-CHAR = ("\\" / "\;" / "\," / "\N" / "\n") 2028 ; \\ encodes \, \N or \n encodes newline 2029 ; \; encodes ;, \, encodes , 2031 TSAFE-CHAR = %x20-21 / %x23-2B / %x2D-39 / %x3C-5B / 2032 %x5D-7E / NON-US-ASCII 2033 ; Any character except CTLs not needed by the current 2034 ; character set, DQUOTE, ";", ":", "\", "," 2036 Description: If the property permits, multiple TEXT values are 2037 specified by a COMMA character (US-ASCII decimal 44) separated 2038 list of values. 2040 The language in which the text is represented can be controlled by 2041 the "LANGUAGE" property parameter. 2043 An intentional formatted text line break MUST only be included in 2044 a "TEXT" property value by representing the line break with the 2045 character sequence of BACKSLASH (US-ASCII decimal 92), followed by 2046 a LATIN SMALL LETTER N (US-ASCII decimal 110) or a LATIN CAPITAL 2047 LETTER N (US-ASCII decimal 78), that is "\n" or "\N". 2049 The "TEXT" property values may also contain special characters 2050 that are used to signify delimiters, such as a COMMA character for 2051 lists of values or a SEMICOLON character for structured values. 2052 In order to support the inclusion of these special characters in 2053 "TEXT" property values, they MUST be escaped with a BACKSLASH 2054 character. A BACKSLASH character (US-ASCII decimal 92) in a 2055 "TEXT" property value MUST be escaped with another BACKSLASH 2056 character. A COMMA character in a "TEXT" property value MUST be 2057 escaped with a BACKSLASH character (US-ASCII decimal 92). A 2058 SEMICOLON character in a "TEXT" property value MUST be escaped 2059 with a BACKSLASH character (US-ASCII decimal 92). However, a 2060 COLON character in a "TEXT" property value SHALL NOT be escaped 2061 with a BACKSLASH character. 2063 Example: A multiple line value of: 2065 Project XYZ Final Review 2066 Conference Room - 3B 2067 Come Prepared. 2069 would be represented as: 2071 Project XYZ Final Review\nConference Room - 3B\nCome Prepared. 2073 3.3.12. Time 2075 Value Name: TIME 2077 Purpose: This value type is used to identify values that contain a 2078 time of day. 2080 Format Definition: This value type is defined by the following 2081 notation: 2083 time = time-hour time-minute time-second [time-utc] 2085 time-hour = 2DIGIT ;00-23 2086 time-minute = 2DIGIT ;00-59 2087 time-second = 2DIGIT ;00-60 2088 ;The "60" value is used to account for positive "leap" seconds. 2090 time-utc = "Z" 2092 Description: If the property permits, multiple "time" values are 2093 specified by a COMMA character (US-ASCII decimal 44) separated 2094 list of values. No additional content value encoding (i.e., 2095 BACKSLASH character encoding) is defined for this value type. 2097 The "TIME" value type is used to identify values that contain a 2098 time of day. The format is based on the [ISO.8601.2004] complete 2099 representation, basic format for a time of day. The text format 2100 consists of a two-digit 24-hour of the day (i.e., values 00-23), 2101 two-digit minute in the hour (i.e., values 00-59), and two-digit 2102 seconds in the minute (i.e., values 00-60). The seconds value of 2103 60 MUST only be used to account for positive "leap" seconds. 2104 Fractions of a second are not supported by this format. 2106 In parallel to the "DATE-TIME" definition above, the "TIME" value 2107 type expresses time values in three forms: 2109 The form of time with UTC offset MUST NOT be used. For example, 2110 the following is not valid for a time value: 2112 230000-0800 ;Invalid time format 2114 FORM #1 LOCAL TIME 2116 The local time form is simply a time value that does not contain 2117 the UTC designator nor does it reference a time zone. For 2118 example, 11:00 PM: 2120 230000 2122 Time values of this type are said to be "floating" and are not 2123 bound to any time zone in particular. They are used to represent 2124 the same hour, minute, and second value regardless of which time 2125 zone is currently being observed. For example, an event can be 2126 defined that indicates that an individual will be busy from 11:00 2127 AM to 1:00 PM every day, no matter which time zone the person is 2128 in. In these cases, a local time can be specified. The recipient 2129 of an iCalendar object with a property value consisting of a local 2130 time, without any relative time zone information, SHOULD interpret 2131 the value as being fixed to whatever time zone the "ATTENDEE" is 2132 in at any given moment. This means that two "Attendees", may 2133 participate in the same event at different UTC times; floating 2134 time SHOULD only be used where that is reasonable behavior. 2136 In most cases, a fixed time is desired. To properly communicate a 2137 fixed time in a property value, either UTC time or local time with 2138 time zone reference MUST be specified. 2140 The use of local time in a TIME value without the "TZID" property 2141 parameter is to be interpreted as a local time value, regardless 2142 of the existence of "VTIMEZONE" calendar components in the 2143 iCalendar object. 2145 FORM #2: UTC TIME 2147 UTC time, or absolute time, is identified by a LATIN CAPITAL 2148 LETTER Z suffix character (US-ASCII decimal 90), the UTC 2149 designator, appended to the time value. For example, the 2150 following represents 07:00 AM UTC: 2152 070000Z 2154 The "TZID" property parameter MUST NOT be applied to TIME 2155 properties whose time values are specified in UTC. 2157 FORM #3: LOCAL TIME AND TIME ZONE REFERENCE 2159 The local time with reference to time zone information form is 2160 identified by the use the "TZID" property parameter to reference 2161 the appropriate time zone definition. "TZID" is discussed in 2162 detail in Section 3.2.18. 2164 Example: The following represents 8:30 AM in New York in Winter, 2165 five hours behind UTC, in each of the three formats: 2167 083000 2168 133000Z 2169 TZID=America/New_York:083000 2171 3.3.13. URI 2173 Value Name: URI 2175 Purpose: This value type is used to identify values that contain a 2176 uniform resource identifier (URI) type of reference to the 2177 property value. 2179 Format Definition: This value type is defined by the following 2180 notation: 2182 uri = 2184 Description: This value type might be used to reference binary 2185 information, for values that are large, or otherwise undesirable 2186 to include directly in the iCalendar object. 2188 Property values with this value type MUST follow the generic URI 2189 syntax defined in [RFC3986]. 2191 When a property parameter value is a URI value type, the URI MUST 2192 be specified as a quoted-string value. 2194 No additional content value encoding (i.e., BACKSLASH character 2195 encoding) is defined for this value type. 2197 Example: The following is a URI for a network file: 2199 http://example.com/my-report.txt 2201 3.3.14. UTC Offset 2203 Value Name: UTC-OFFSET 2205 Purpose: This value type is used to identify properties that contain 2206 an offset from UTC to local time. 2208 Format Definition: This value type is defined by the following 2209 notation: 2211 utc-offset = time-numzone 2213 time-numzone = ("+" / "-") time-hour time-minute [time-second] 2215 Description: The PLUS SIGN (US-ASCII decimal 43) character MUST be 2216 specified for positive UTC offsets (i.e., ahead of UTC). The 2217 HYPHEN-MINUS character (US-ASCII decimal 45) MUST be specified for 2218 negative UTC offsets (i.e., behind of UTC). The value of "-0000" 2219 and "-000000" are not allowed. The time-second, if present, MUST 2220 NOT be 60; if absent, it defaults to zero. 2222 No additional content value encoding (i.e., BACKSLASH character 2223 encoding) is defined for this value type. 2225 Example: The following UTC offsets are given for standard time for 2226 New York (five hours behind UTC) and Geneva (one hour ahead of 2227 UTC): 2229 -0500 2231 +0100 2233 3.4. iCalendar Object 2235 The Calendaring and Scheduling Core Object is a collection of 2236 calendaring and scheduling information. Typically, this information 2237 will consist of an iCalendar stream with a single iCalendar object. 2238 However, multiple iCalendar objects can be sequentially grouped 2239 together in an iCalendar stream. The first line and last line of the 2240 iCalendar object MUST contain a pair of iCalendar object delimiter 2241 strings. The syntax for an iCalendar stream is as follows: 2243 icalstream = 1*icalobject 2245 icalobject = "BEGIN" ":" "VCALENDAR" CRLF 2246 icalbody 2247 "END" ":" "VCALENDAR" CRLF 2249 The following is a simple example of an iCalendar object: 2251 BEGIN:VCALENDAR 2252 VERSION:2.0 2253 PRODID:-//hacksw/handcal//NONSGML v1.0//EN 2254 BEGIN:VEVENT 2255 UID:19970610T172345Z-AF23B2@example.com 2256 DTSTAMP:19970610T172345Z 2257 DTSTART:19970714T170000Z 2258 DTEND:19970715T040000Z 2259 SUMMARY:Bastille Day Party 2260 END:VEVENT 2261 END:VCALENDAR 2263 3.5. Property 2265 A property is the definition of an individual attribute describing a 2266 calendar object or a calendar component. A property takes the form 2267 defined by the "contentline" notation defined in Section 3.1. 2269 The following is an example of a property: 2271 DTSTART:19960415T133000Z 2273 This memo imposes no ordering of properties within an iCalendar 2274 object. 2276 Property names, parameter names and enumerated parameter values are 2277 case insensitive. For example, the property name "DUE" is the same 2278 as "due" and "Due", DTSTART;TZID=America/New_York:19980714T120000 is 2279 the same as DtStart;TzID=America/New_York:19980714T120000. 2281 3.6. Calendar Components 2283 The body of the iCalendar object consists of a sequence of calendar 2284 properties and one or more calendar components. The calendar 2285 properties are attributes that apply to the calendar object as a 2286 whole. The calendar components are collections of properties that 2287 express a particular calendar semantic. For example, the calendar 2288 component can specify an event, a to-do, a journal entry, time zone 2289 information, free/busy time information, or an alarm. 2291 The body of the iCalendar object is defined by the following 2292 notation: 2294 icalbody = calprops component 2296 calprops = *( 2298 ; the following are REQUIRED, 2299 ; but MUST NOT occur more than once 2301 prodid / version / 2303 ; the following are OPTIONAL, 2304 ; but MUST NOT occur more than once 2306 calscale / method / 2308 ; the following are OPTIONAL, 2309 ; and MAY occur more than once 2311 x-prop / iana-prop 2312 ) 2314 component = 1*(eventc / todoc / journalc / freebusyc / 2315 timezonec / iana-comp / x-comp) 2317 iana-comp = "BEGIN" ":" iana-token CRLF 2318 1*contentline 2319 "END" ":" iana-token CRLF 2321 x-comp = "BEGIN" ":" x-name CRLF 2322 1*contentline 2323 "END" ":" x-name CRLF 2325 An iCalendar object MUST include the "PRODID" and "VERSION" calendar 2326 properties. In addition, it MUST include at least one calendar 2327 component. Special forms of iCalendar objects are possible to 2328 publish just busy time (i.e., only a "VFREEBUSY" calendar component) 2329 or time zone (i.e., only a "VTIMEZONE" calendar component) 2330 information. In addition, a complex iCalendar object that is used to 2331 capture a complete snapshot of the contents of a calendar is possible 2332 (e.g., composite of many different calendar components). More 2333 commonly, an iCalendar object will consist of just a single "VEVENT", 2334 "VTODO" or "VJOURNAL" calendar component. Applications MUST ignore 2335 x-comp and iana-comp they don't recognized. 2337 3.6.1. Event Component 2338 Component Name: VEVENT 2340 Purpose: Provide a grouping of component properties that describe an 2341 event. 2343 Format Definition: A "VEVENT" calendar component is defined by the 2344 following notation: 2346 eventc = "BEGIN" ":" "VEVENT" CRLF 2347 eventprop *alarmc 2348 "END" ":" "VEVENT" CRLF 2350 eventprop = *( 2352 ; the following are REQUIRED, 2353 ; but MUST NOT occur more than once 2355 dtstamp / dtstart / uid / 2357 ; the following are OPTIONAL, 2358 ; but MUST NOT occur more than once 2360 class / created / description / geo / 2361 last-mod / location / organizer / priority / 2362 seq / status / summary / transp / 2363 url / recurid / 2365 ; the following is OPTIONAL, 2366 ; but SHOULD NOT occur more than once 2368 rrule / 2370 ; either 'dtend' or 'duration' MAY appear in 2371 ; a 'eventprop', but 'dtend' and 'duration' 2372 ; MUST NOT occur in the same 'eventprop' 2374 dtend / duration / 2376 ; the following are OPTIONAL, 2377 ; and MAY occur more than once 2379 attach / attendee / categories / comment / 2380 contact / exdate / rstatus / related / 2381 resources / rdate / x-prop / iana-prop 2383 ) 2385 Description: A "VEVENT" calendar component is a grouping of 2386 component properties, and possibly including "VALARM" calendar 2387 components, that represents a scheduled amount of time on a 2388 calendar. For example, it can be an activity; such as a one-hour 2389 long, department meeting from 8:00 AM to 9:00 AM, tomorrow. 2390 Generally, an event will take up time on an individual calendar. 2391 Hence, the event will appear as an opaque interval in a search for 2392 busy time. Alternately, the event can have its Time Transparency 2393 set to "TRANSPARENT" in order to prevent blocking of the event in 2394 searches for busy time. 2396 The "VEVENT" is also the calendar component used to specify an 2397 anniversary or daily reminder within a calendar. These events 2398 have a DATE value type for the "DTSTART" property instead of the 2399 default value type of DATE-TIME. If such a "VEVENT" has a "DTEND" 2400 property, it MUST be specified as a DATE value also. The 2401 anniversary type of "VEVENT" can span more than one date (i.e., 2402 "DTEND" property value is set to a calendar date after the 2403 "DTSTART" property value). If such a "VEVENT" has a "DURATION" 2404 property, it MUST be specified as a "dur-day" or "dur-week" value. 2406 The "DTSTART" property for a "VEVENT" specifies the inclusive 2407 start of the event. For recurring events, it also specifies the 2408 very first instance in the recurrence set. The "DTEND" property 2409 for a "VEVENT" calendar component specifies the non-inclusive end 2410 of the event. For cases where a "VEVENT" calendar component 2411 specifies a "DTSTART" property with a DATE value type but no 2412 "DTEND" nor DURATION property, the event's duration is taken to be 2413 one day. For cases where a "VEVENT" calendar component specifies 2414 a "DTSTART" property with a DATE-TIME value type but no "DTEND" 2415 property, the event ends on the same calendar date and time of day 2416 specified by the "DTSTART" property. 2418 The "VEVENT" calendar component cannot be nested within another 2419 calendar component. However, "VEVENT" calendar components can be 2420 related to each other or to a "VTODO" or to a "VJOURNAL" calendar 2421 component with the "RELATED-TO" property. 2423 Example: The following is an example of the "VEVENT" calendar 2424 component used to represent a meeting that will also be opaque to 2425 searches for busy time: 2427 BEGIN:VEVENT 2428 UID:19970901T130000Z-123401@example.com 2429 DTSTAMP:19970901T130000Z 2430 DTSTART:19970903T163000Z 2431 DTEND:19970903T190000Z 2432 SUMMARY:Annual Employee Review 2433 CLASS:PRIVATE 2434 CATEGORIES:BUSINESS,HUMAN RESOURCES 2435 END:VEVENT 2437 The following is an example of the "VEVENT" calendar component 2438 used to represent a reminder that will not be opaque, but rather 2439 transparent, to searches for busy time: 2441 BEGIN:VEVENT 2442 UID:19970901T130000Z-123402@example.com 2443 DTSTAMP:19970901T130000Z 2444 DTSTART:19970401T163000Z 2445 DTEND:19970402T010000Z 2446 SUMMARY:Laurel is in sensitivity awareness class. 2447 CLASS:PUBLIC 2448 CATEGORIES:BUSINESS,HUMAN RESOURCES 2449 TRANSP:TRANSPARENT 2450 END:VEVENT 2452 The following is an example of the "VEVENT" calendar component 2453 used to represent an anniversary that will occur annually. 2455 BEGIN:VEVENT 2456 UID:19970901T130000Z-123403@example.com 2457 DTSTAMP:19970901T130000Z 2458 DTSTART;VALUE=DATE:19971102 2459 SUMMARY:Our Blissful Anniversary 2460 TRANSP:TRANSPARENT 2461 CLASS:CONFIDENTIAL 2462 CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION 2463 RRULE:FREQ=YEARLY 2464 END:VEVENT 2466 The following is an example of the "VEVENT" calendar component 2467 used to represent a multi-day event scheduled from June 28th, 2007 2468 to July 8th, 2007 inclusively. Note that the "DTEND" property is 2469 set to July 9th, 2007, since the "DTEND" property specifies the 2470 non-inclusive end of the event. 2472 BEGIN:VEVENT 2473 UID:20070423T123432Z-541111@example.com 2474 DTSTAMP:20070423T123432Z 2475 DTSTART;VALUE=DATE:20070628 2476 DTEND;VALUE=DATE:20070709 2477 SUMMARY:Festival International de Jazz de Montreal 2478 TRANSP:TRANSPARENT 2479 END:VEVENT 2481 3.6.2. To-do Component 2483 Component Name: VTODO 2485 Purpose: Provide a grouping of calendar properties that describe a 2486 to-do. 2488 Format Definition: A "VTODO" calendar component is defined by the 2489 following notation: 2491 todoc = "BEGIN" ":" "VTODO" CRLF 2492 todoprop *alarmc 2493 "END" ":" "VTODO" CRLF 2495 todoprop = *( 2497 ; the following are REQUIRED, 2498 ; but MUST NOT occur more than once 2500 dtstamp / uid / 2502 ; the following are OPTIONAL, 2503 ; but MUST NOT occur more than once 2505 class / completed / created / description / 2506 dtstart / geo / last-mod / location / organizer / 2507 percent / priority / recurid / seq / status / 2508 summary / url / 2510 ; the following is OPTIONAL, 2511 ; but SHOULD NOT occur more than once 2513 rrule / 2515 ; either 'due' or 'duration' MAY appear in 2516 ; a 'todoprop', but 'due' and 'duration' 2517 ; MUST NOT occur in the same 'todoprop'. 2518 ; If 'duration' appear in a 'todoprop', 2519 ; then 'dtstart' MUST also appear in 2520 ' the same 'todoprop'. 2522 due / duration / 2524 ; the following are OPTIONAL, 2525 ; and MAY occur more than once 2527 attach / attendee / categories / comment / contact / 2528 exdate / rstatus / related / resources / 2529 rdate / x-prop / iana-prop 2531 ) 2533 Description: A "VTODO" calendar component is a grouping of component 2534 properties and possibly "VALARM" calendar components that 2535 represent an action-item or assignment. For example, it can be 2536 used to represent an item of work assigned to an individual; such 2537 as "turn in travel expense today". 2539 The "VTODO" calendar component cannot be nested within another 2540 calendar component. However, "VTODO" calendar components can be 2541 related to each other or to a "VEVENT" or to a "VJOURNAL" calendar 2542 component with the "RELATED-TO" property. 2544 A "VTODO" calendar component without the "DTSTART" and "DUE" (or 2545 "DURATION") properties specifies a to-do that will be associated 2546 with each successive calendar date, until it is completed. 2548 Examples: The following is an example of a "VTODO" calendar 2549 component that needs to be completed before May 1st, 2007. On 2550 midnight May 1st, 2007 this to-do would be considered overdue. 2552 BEGIN:VTODO 2553 UID:20070313T123432Z-456553@example.com 2554 DTSTAMP:20070313T123432Z 2555 DUE;VALUE=DATE:20070501 2556 SUMMARY:Submit Quebec Income Tax Return for 2006 2557 CLASS:CONFIDENTIAL 2558 CATEGORIES:FAMILY,FINANCE 2559 STATUS:NEEDS-ACTION 2560 END:VTODO 2562 The following is an example of a "VTODO" calendar component that 2563 was due before 1:00 P.M. UTC on July 9th, 2007 and was completed 2564 on July 7th, 2007 at 10:00 A.M. UTC. 2566 BEGIN:VTODO 2567 UID:20070514T103211Z-123404@example.com 2568 DTSTAMP:20070514T103211Z 2569 DTSTART:20070514T110000Z 2570 DUE:20070709T130000Z 2571 COMPLETED:20070707T100000Z 2572 SUMMARY:Submit Revised Internet-Draft 2573 PRIORITY:1 2574 STATUS:NEEDS-ACTION 2575 END:VTODO 2577 3.6.3. Journal Component 2579 Component Name: VJOURNAL 2581 Purpose: Provide a grouping of component properties that describe a 2582 journal entry. 2584 Format Definition: A "VJOURNAL" calendar component is defined by the 2585 following notation: 2587 journalc = "BEGIN" ":" "VJOURNAL" CRLF 2588 jourprop 2589 "END" ":" "VJOURNAL" CRLF 2591 jourprop = *( 2593 ; the following are REQUIRED, 2594 ; but MUST NOT occur more than once 2596 dtstamp / uid / 2598 ; the following are OPTIONAL, 2599 ; but MUST NOT occur more than once 2601 class / created / dtstart / 2602 last-mod / organizer / recurid / seq / 2603 status / summary / url / 2605 ; the following is OPTIONAL, 2606 ; but SHOULD NOT occur more than once 2608 rrule / 2610 ; the following are OPTIONAL, 2611 ; and MAY occur more than once 2613 attach / attendee / categories / comment / 2614 contact / description / exdate / related / rdate / 2615 rstatus / x-prop / iana-prop 2616 ) 2618 Description: A "VJOURNAL" calendar component is a grouping of 2619 component properties that represent one or more descriptive text 2620 notes associated with a particular calendar date. The "DTSTART" 2621 property is used to specify the calendar date that the journal 2622 entry is associated with. Generally, it will have a DATE value 2623 data type, but it can also be used to specify a DATE-TIME value 2624 data type. Examples of a journal entry include a daily record of 2625 a legislative body or a journal entry of individual telephone 2626 contacts for the day or an ordered list of accomplishments for the 2627 day. The "VJOURNAL" calendar component can also be used to 2628 associate a document with a calendar date. 2630 The "VJOURNAL" calendar component does not take up time on a 2631 calendar. Hence, it does not play a role in free or busy time 2632 searches -- it is as though it has a time transparency value of 2633 TRANSPARENT. It is transparent to any such searches. 2635 The "VJOURNAL" calendar component cannot be nested within another 2636 calendar component. However, "VJOURNAL" calendar components can 2637 be related to each other or to a "VEVENT" or to a "VTODO" calendar 2638 component, with the "RELATED-TO" property. 2640 Example: The following is an example of the "VJOURNAL" calendar 2641 component: 2643 BEGIN:VJOURNAL 2644 UID:19970901T130000Z-123405@example.com 2645 DTSTAMP:19970901T130000Z 2646 DTSTART;VALUE=DATE:19970317 2647 SUMMARY:Staff meeting minutes 2648 DESCRIPTION:1. Staff meeting: Participants include Joe\, Lisa 2649 and Bob. Aurora project plans were reviewed. There is currentl 2650 y no budget reserves for this project. Lisa will escalate to 2651 management. Next meeting on Tuesday.\n 2652 2. Telephone Conference: ABC Corp. sales representative called 2653 to discuss new printer. Promised to get us a demo by Friday.\n 2654 3. Henry Miller (Handsoff Insurance): Car was totaled by tree. 2655 Is looking into a loaner car. 555-2323 (tel). 2656 END:VJOURNAL 2658 3.6.4. Free/Busy Component 2660 Component Name: VFREEBUSY 2662 Purpose: Provide a grouping of component properties that describe 2663 either a request for free/busy time, describe a response to a 2664 request for free/busy time or describe a published set of busy 2665 time. 2667 Format Definition: A "VFREEBUSY" calendar component is defined by 2668 the following notation: 2670 freebusyc = "BEGIN" ":" "VFREEBUSY" CRLF 2671 fbprop 2672 "END" ":" "VFREEBUSY" CRLF 2674 fbprop = *( 2676 ; the following are REQUIRED, 2677 ; but MUST NOT occur more than once 2679 dtstamp / uid / 2681 ; the following are OPTIONAL, 2682 ; but MUST NOT occur more than once 2684 contact / dtstart / dtend / duration / dtstamp / 2685 organizer / uid / url / 2687 ; the following are OPTIONAL, 2688 ; and MAY occur more than once 2690 attendee / comment / freebusy / rstatus / x-prop / 2691 iana-prop 2692 ) 2694 Description: A "VFREEBUSY" calendar component is a grouping of 2695 component properties that represents either a request for, a reply 2696 to a request for free or busy time information or a published set 2697 of busy time information. 2699 When used to request free/busy time information, the "ATTENDEE" 2700 property specifies the calendar users whose free/busy time is 2701 being requested; the "ORGANIZER" property specifies the calendar 2702 user who is requesting the free/busy time; the "DTSTART" and 2703 "DTEND" properties specify the window of time for which the free/ 2704 busy time is being requested; the "UID" and "DTSTAMP" properties 2705 are specified to assist in proper sequencing of multiple free/busy 2706 time requests. 2708 When used to reply to a request for free/busy time, the "ATTENDEE" 2709 property specifies the calendar user responding to the free/busy 2710 time request; the "ORGANIZER" property specifies the calendar user 2711 that originally requested the free/busy time; the "FREEBUSY" 2712 property specifies the free/busy time information (if it exists); 2713 and the "UID" and "DTSTAMP" properties are specified to assist in 2714 proper sequencing of multiple free/busy time replies. 2716 When used to publish busy time, the "ORGANIZER" property specifies 2717 the calendar user associated with the published busy time; the 2718 "DTSTART" and "DTEND" properties specify an inclusive time window 2719 that surrounds the busy time information; the "FREEBUSY" property 2720 specifies the published busy time information; and the "DTSTAMP" 2721 property specifies the date/time that iCalendar object was 2722 created. 2724 The "VFREEBUSY" calendar component cannot be nested within another 2725 calendar component. Multiple "VFREEBUSY" calendar components can 2726 be specified within an iCalendar object. This permits the 2727 grouping of Free/Busy information into logical collections, such 2728 as monthly groups of busy time information. 2730 The "VFREEBUSY" calendar component is intended for use in 2731 iCalendar object methods involving requests for free time, 2732 requests for busy time, requests for both free and busy, and the 2733 associated replies. 2735 Free/Busy information is represented with the "FREEBUSY" property. 2736 This property provides a terse representation of time periods. 2737 One or more "FREEBUSY" properties can be specified in the 2738 "VFREEBUSY" calendar component. 2740 When present in a "VFREEBUSY" calendar component, the "DTSTART" 2741 and "DTEND" properties SHOULD be specified prior to any "FREEBUSY" 2742 properties. In a free time request, these properties can be used 2743 in combination with the "DURATION" property to represent a request 2744 for a duration of free time within a specified window of time. 2746 The recurrence properties ("RRULE", "RDATE", "EXDATE") are not 2747 permitted within a "VFREEBUSY" calendar component. Any recurring 2748 events are resolved into their individual busy time periods using 2749 the "FREEBUSY" property. 2751 Example: The following is an example of a "VFREEBUSY" calendar 2752 component used to request free or busy time information: 2754 BEGIN:VFREEBUSY 2755 UID:19970901T082949Z-FA43EF@example.com 2756 ORGANIZER:mailto:jane_doe@example.com 2757 ATTENDEE:mailto:john_public@example.com 2758 DTSTART:19971015T050000Z 2759 DTEND:19971016T050000Z 2760 DTSTAMP:19970901T083000Z 2761 END:VFREEBUSY 2763 The following is an example of a "VFREEBUSY" calendar component 2764 used to reply to the request with busy time information: 2766 BEGIN:VFREEBUSY 2767 UID:19970901T095957Z-76A912@example.com 2768 ORGANIZER:mailto:jane_doe@example.com 2769 ATTENDEE:mailto:john_public@example.com 2770 DTSTAMP:19970901T100000Z 2771 FREEBUSY:19971015T050000Z/PT8H30M, 2772 19971015T160000Z/PT5H30M,19971015T223000Z/PT6H30M 2773 URL:http://example.com/pub/busy/jpublic-01.ifb 2774 COMMENT:This iCalendar file contains busy time information for 2775 the next three months. 2776 END:VFREEBUSY 2778 The following is an example of a "VFREEBUSY" calendar component 2779 used to publish busy time information. 2781 BEGIN:VFREEBUSY 2782 UID:19970901T115957Z-76A912@example.com 2783 DTSTAMP:19970901T120000Z 2784 ORGANIZER:jsmith@example.com 2785 DTSTART:19980313T141711Z 2786 DTEND:19980410T141711Z 2787 FREEBUSY:19980314T233000Z/19980315T003000Z 2788 FREEBUSY:19980316T153000Z/19980316T163000Z 2789 FREEBUSY:19980318T030000Z/19980318T040000Z 2790 URL:http://www.example.com/calendar/busytime/jsmith.ifb 2791 END:VFREEBUSY 2793 3.6.5. Time Zone Component 2795 Component Name: VTIMEZONE 2797 Purpose: Provide a grouping of component properties that defines a 2798 time zone. 2800 Format Definition: A "VTIMEZONE" calendar component is defined by 2801 the following notation: 2803 timezonec = "BEGIN" ":" "VTIMEZONE" CRLF 2804 *( 2806 ; 'tzid' is REQUIRED, but MUST NOT occur more 2807 ; than once 2809 tzid / 2810 ; 'last-mod' and 'tzurl' are OPTIONAL, 2811 ; but MUST NOT occur more than once 2813 last-mod / tzurl / 2815 ; one of 'standardc' or 'daylightc' MUST occur 2816 ; and each MAY occur more than once. 2818 standardc / daylightc / 2820 ; the following are OPTIONAL, 2821 ; and MAY occur more than once 2823 x-prop / iana-prop 2825 ) 2827 "END" ":" "VTIMEZONE" CRLF 2829 standardc = "BEGIN" ":" "STANDARD" CRLF 2830 tzprop 2831 "END" ":" "STANDARD" CRLF 2833 daylightc = "BEGIN" ":" "DAYLIGHT" CRLF 2834 tzprop 2835 "END" ":" "DAYLIGHT" CRLF 2837 tzprop = *( 2839 ; the following are REQUIRED, 2840 ; but MUST NOT occur more than once 2842 dtstart / tzoffsetto / tzoffsetfrom / 2844 ; the following is OPTIONAL, 2845 ; but SHOULD NOT occur more than once 2847 rrule / 2849 ; the following are OPTIONAL, 2850 ; and MAY occur more than once 2852 comment / rdate / tzname / x-prop / iana-prop 2854 ) 2856 Description: A time zone is unambiguously defined by the set of time 2857 measurement rules determined by the governing body for a given 2858 geographic area. These rules describe at a minimum the base 2859 offset from UTC for the time zone, often referred to as the 2860 Standard Time offset. Many locations adjust their Standard Time 2861 forward or backward by one hour, in order to accommodate seasonal 2862 changes in number of daylight hours, often referred to as Daylight 2863 Saving Time. Some locations adjust their time by a fraction of an 2864 hour. Standard Time is also known as Winter Time. Daylight 2865 Saving Time is also known as Advanced Time, Summer Time, or Legal 2866 Time in certain countries. The following table shows the changes 2867 in time zone rules in effect for New York City starting from 1967. 2868 Each line represents a description or rule for a particular 2869 observance. 2871 Effective Observance Rule 2873 +-----------+--------------------------+--------+--------------+ 2874 | Date | (Date/Time) | Offset | Abbreviation | 2875 +-----------+--------------------------+--------+--------------+ 2876 | 1967-1973 | last Sun in Apr, 02:00 | -0400 | EDT | 2877 | 1967-2006 | last Sun in Oct, 02:00 | -0500 | EST | 2878 | 1974-1974 | Jan 6, 02:00 | -0400 | EDT | 2879 | 1975-1975 | Feb 23, 02:00 | -0400 | EDT | 2880 | 1976-1986 | last Sun in Apr, 02:00 | -0400 | EDT | 2881 | 1987-2006 | first Sun in Apr, 02:00 | -0400 | EDT | 2882 | 2007-* | second Sun in Mar, 02:00 | -0400 | EDT | 2883 | 2007-* | first Sun in Nov, 02:00 | -0500 | EST | 2884 +-----------+--------------------------+--------+--------------+ 2886 Note: The specification of a global time zone registry is not 2887 addressed by this document and is left for future study. 2888 However, implementers may find the TZ database [TZDB] a useful 2889 reference. It is an informal, public-domain collection of time 2890 zone information, which is currently being maintained by 2891 volunteer Internet participants, and is used in several 2892 operating systems. This database contains current and 2893 historical time zone information for a wide variety of 2894 locations around the globe; it provides a time zone identifier 2895 for every unique time zone rule set in actual use since 1970, 2896 with historical data going back to the introduction of standard 2897 time. 2899 Interoperability between two calendaring and scheduling 2900 applications, especially for recurring events, to-dos or journal 2901 entries, is dependent on the ability to capture and convey date 2902 and time information in an unambiguous format. The specification 2903 of current time zone information is integral to this behavior. 2905 If present, the "VTIMEZONE" calendar component defines the set of 2906 Standard Time and Daylight Saving Time observances (or rules) for 2907 a particular time zone for a given interval of time. The 2908 "VTIMEZONE" calendar component cannot be nested within other 2909 calendar components. Multiple "VTIMEZONE" calendar components can 2910 exist in an iCalendar object. In this situation, each "VTIMEZONE" 2911 MUST represent a unique time zone definition. This is necessary 2912 for some classes of events, such as airline flights, that start in 2913 one time zone and end in another. 2915 The "VTIMEZONE" calendar component MUST include the "TZID" 2916 property and at least one definition of a "STANDARD" or "DAYLIGHT" 2917 sub-component. The "STANDARD" or "DAYLIGHT" subcomponent MUST 2918 include the "DTSTART", "TZOFFSETFROM" and "TZOFFSETTO" properties. 2920 An individual "VTIMEZONE" calendar component MUST be specified for 2921 each unique "TZID" parameter value specified in the iCalendar 2922 object. In addition, a "VTIMEZONE" calendar component, referred 2923 to by a recurring calendar component, MUST provide valid time zone 2924 information for all recurrence instances. 2926 Each "VTIMEZONE" calendar component consists of a collection of 2927 one or more sub-components that describe the rule for a particular 2928 observance (either a Standard Time or a Daylight Saving Time 2929 observance). The "STANDARD" sub-component consists of a 2930 collection of properties that describe Standard Time. The 2931 "DAYLIGHT" sub-component consists of a collection of properties 2932 that describe Daylight Saving Time. In general this collection of 2933 properties consists of: 2935 * the first onset date-time for the observance; 2937 * the last onset date-time for the observance, if a last onset is 2938 known; 2940 * the offset to be applied for the observance; 2942 * a rule that describes the day and time when the observance 2943 takes effect; 2945 * an optional name for the observance. 2947 For a given time zone, there may be multiple unique definitions of 2948 the observances over a period of time. Each observance is 2949 described using either a "STANDARD" or "DAYLIGHT" sub-component. 2950 The collection of these sub-components is used to describe the 2951 time zone for a given period of time. The offset to apply at any 2952 given time is found by locating the observance that has the last 2953 onset date and time before the time in question, and using the 2954 offset value from that observance. 2956 The top-level properties in a "VTIMEZONE" calendar component are: 2958 The mandatory "TZID" property is a text value that uniquely 2959 identifies the "VTIMEZONE" calendar component within the scope of 2960 an iCalendar object. 2962 The optional "LAST-MODIFIED" property is a UTC value that 2963 specifies the date and time that this time zone definition was 2964 last updated. 2966 The optional "TZURL" property is a url value that points to a 2967 published "VTIMEZONE" definition. "TZURL" SHOULD refer to a 2968 resource that is accessible by anyone who might need to interpret 2969 the object. This SHOULD NOT normally be a "file" URL or other URL 2970 that is not widely-accessible. 2972 The collection of properties that are used to define the 2973 "STANDARD" and "DAYLIGHT" sub-components include: 2975 The mandatory "DTSTART" property gives the effective onset date 2976 and local time for the time zone sub-component definition. 2977 "DTSTART" in this usage MUST be specified as a local DATE-TIME 2978 value. 2980 The mandatory "TZOFFSETFROM" property gives the UTC offset which 2981 is in use when the onset of this time zone observance begins. 2982 "TZOFFSETFROM" is combined with "DTSTART" to define the effective 2983 onset for the time zone sub-component definition. For example, 2984 the following represents the time at which the observance of 2985 Standard Time took effect in Fall 1967 for New York City: 2987 DTSTART:19671029T020000 2989 TZOFFSETFROM:-0400 2991 The mandatory "TZOFFSETTO" property gives the UTC offset for the 2992 time zone sub-component (Standard Time or Daylight Saving Time) 2993 when this observance is in use. 2995 The optional "TZNAME" property is the customary name for the time 2996 zone. It may be specified multiple times, to allow for specifying 2997 multiple language variants of the time zone names. This could be 2998 used for displaying dates. 3000 The onset date-times for the observance defined by the time zone 3001 sub-component is defined by the "DTSTART", "RRULE", and "RDATE" 3002 properties. 3004 The "RRULE" property defines the recurrence rule for the onset of 3005 the observance defined by this time zone sub-component. Some 3006 specific requirements for the usage of "RRULE" for this purpose 3007 include: 3009 * If observance is known to have an effective end date, the 3010 "UNTIL" recurrence rule parameter MUST be used to specify the 3011 last valid onset of this observance (i.e., the UNTIL date-time 3012 will be equal to the last instance generated by the recurrence 3013 pattern). It MUST be specified in UTC time. 3015 * The "DTSTART" and the "TZOFFSETFROM" properties MUST be used 3016 when generating the onset date-time values (instances) from the 3017 "RRULE". 3019 Alternatively, the "RDATE" property can be used to define the 3020 onset of the observance by giving the individual onset date and 3021 times. "RDATE" in this usage MUST be specified as a local DATE- 3022 TIME value, relative to the UTC offset specified in the 3023 "TZOFFSETFROM" property. 3025 The optional "COMMENT" property is also allowed for descriptive 3026 explanatory text. 3028 Example: The following are examples of the "VTIMEZONE" calendar 3029 component: 3031 This is an example showing all the time zone rules for New York 3032 City since April 30, 1967 at 03:00:00 EDT. 3034 BEGIN:VTIMEZONE 3035 TZID:America/New_York 3036 LAST-MODIFIED:20050809T050000Z 3037 BEGIN:DAYLIGHT 3038 DTSTART:19670430T020000 3039 RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=-1SU;UNTIL=19730429T070000Z 3040 TZOFFSETFROM:-0500 3041 TZOFFSETTO:-0400 3042 TZNAME:EDT 3043 END:DAYLIGHT 3044 BEGIN:STANDARD 3045 DTSTART:19671029T020000 3046 RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU;UNTIL=20061029T060000Z 3047 TZOFFSETFROM:-0400 3048 TZOFFSETTO:-0500 3049 TZNAME:EST 3050 END:STANDARD 3051 BEGIN:DAYLIGHT 3052 DTSTART:19740106T020000 3053 RDATE:19750223T020000 3054 TZOFFSETFROM:-0500 3055 TZOFFSETTO:-0400 3056 TZNAME:EDT 3057 END:DAYLIGHT 3058 BEGIN:DAYLIGHT 3059 DTSTART:19760425T020000 3060 RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=-1SU;UNTIL=19860427T070000Z 3061 TZOFFSETFROM:-0500 3062 TZOFFSETTO:-0400 3063 TZNAME:EDT 3064 END:DAYLIGHT 3065 BEGIN:DAYLIGHT 3066 DTSTART:19870405T020000 3067 RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=1SU;UNTIL=20060402T070000Z 3068 TZOFFSETFROM:-0500 3069 TZOFFSETTO:-0400 3070 TZNAME:EDT 3071 END:DAYLIGHT 3072 BEGIN:DAYLIGHT 3073 DTSTART:20070311T020000 3074 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU 3075 TZOFFSETFROM:-0500 3076 TZOFFSETTO:-0400 3077 TZNAME:EDT 3078 END:DAYLIGHT 3079 BEGIN:STANDARD 3080 DTSTART:20071104T020000 3081 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU 3082 TZOFFSETFROM:-0400 3083 TZOFFSETTO:-0500 3084 TZNAME:EST 3085 END:STANDARD 3086 END:VTIMEZONE 3088 This is an example showing time zone information for New York City 3089 using "RDATE" property. Note that this is only suitable for a 3090 recurring event that starts on or later than March 11, 2007 at 03: 3091 00:00 EDT (i.e., the earliest effective transition date and time) 3092 and ends no later than March 9, 2008 at 01:59:59 EST (i.e., latest 3093 valid date and time for EST in this scenario). For example, this 3094 can be used for a recurring event that occurs every Friday, 8:00 3095 A.M.-9:00 A.M., starting June 1, 2007, ending December 31, 2007, 3097 BEGIN:VTIMEZONE 3098 TZID:America/New_York 3099 LAST-MODIFIED:20050809T050000Z 3100 BEGIN:STANDARD 3101 DTSTART:20071104T020000 3102 TZOFFSETFROM:-0400 3103 TZOFFSETTO:-0500 3104 TZNAME:EST 3105 END:STANDARD 3106 BEGIN:DAYLIGHT 3107 DTSTART:20070311T020000 3108 TZOFFSETFROM:-0500 3109 TZOFFSETTO:-0400 3110 TZNAME:EDT 3111 END:DAYLIGHT 3112 END:VTIMEZONE 3114 This is a simple example showing the current time zone rules for 3115 New York City using a "RRULE" recurrence pattern. Note that there 3116 is no effective end date to either of the Standard Time or 3117 Daylight Time rules. This information would be valid for a 3118 recurring event starting today and continuing indefinitely. 3120 BEGIN:VTIMEZONE 3121 TZID:America/New_York 3122 LAST-MODIFIED:20050809T050000Z 3124 TZURL:http://zones.example.com/tz/America-New_York.ics 3125 BEGIN:STANDARD 3126 DTSTART:20071104T020000 3127 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU 3128 TZOFFSETFROM:-0400 3129 TZOFFSETTO:-0500 3130 TZNAME:EST 3131 END:STANDARD 3132 BEGIN:DAYLIGHT 3133 DTSTART:20070311T020000 3134 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU 3135 TZOFFSETFROM:-0500 3136 TZOFFSETTO:-0400 3137 TZNAME:EDT 3138 END:DAYLIGHT 3139 END:VTIMEZONE 3141 This is an example showing a set of rules for a fictitious time 3142 zone where the Daylight Time rule has an effective end date (i.e., 3143 after that date, Daylight Time is no longer observed). 3145 BEGIN:VTIMEZONE 3146 TZID:Fictitious 3147 LAST-MODIFIED:19870101T000000Z 3148 BEGIN:STANDARD 3149 DTSTART:19671029T020000 3150 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 3151 TZOFFSETFROM:-0400 3152 TZOFFSETTO:-0500 3153 TZNAME:EST 3154 END:STANDARD 3155 BEGIN:DAYLIGHT 3156 DTSTART:19870405T020000 3157 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T070000Z 3158 TZOFFSETFROM:-0500 3159 TZOFFSETTO:-0400 3160 TZNAME:EDT 3161 END:DAYLIGHT 3162 END:VTIMEZONE 3164 This is an example showing a set of rules for a fictitious time 3165 zone where the first Daylight Time rule has an effective end date. 3166 There is a second Daylight Time rule that picks up where the other 3167 left off. 3169 BEGIN:VTIMEZONE 3170 TZID:Fictitious 3171 LAST-MODIFIED:19870101T000000Z 3172 BEGIN:STANDARD 3173 DTSTART:19671029T020000 3174 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 3175 TZOFFSETFROM:-0400 3176 TZOFFSETTO:-0500 3177 TZNAME:EST 3178 END:STANDARD 3179 BEGIN:DAYLIGHT 3180 DTSTART:19870405T020000 3181 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T070000Z 3182 TZOFFSETFROM:-0500 3183 TZOFFSETTO:-0400 3184 TZNAME:EDT 3185 END:DAYLIGHT 3186 BEGIN:DAYLIGHT 3187 DTSTART:19990424T020000 3188 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=4 3189 TZOFFSETFROM:-0500 3190 TZOFFSETTO:-0400 3191 TZNAME:EDT 3192 END:DAYLIGHT 3193 END:VTIMEZONE 3195 3.6.6. Alarm Component 3197 Component Name: VALARM 3199 Purpose: Provide a grouping of component properties that define an 3200 alarm. 3202 Format Definition: A "VALARM" calendar component is defined by the 3203 following notation: 3205 alarmc = "BEGIN" ":" "VALARM" CRLF 3206 (audioprop / dispprop / emailprop) 3207 "END" ":" "VALARM" CRLF 3209 audioprop = *( 3211 ; 'action' and 'trigger' are both REQUIRED, 3212 ; but MUST NOT occur more than once 3214 action / trigger / 3216 ; 'duration' and 'repeat' are both OPTIONAL, 3217 ; and MUST NOT occur more than once each, 3218 ; but if one occurs, so MUST the other 3220 duration / repeat / 3222 ; the following is OPTIONAL, 3223 ; but MUST NOT occur more than once 3225 attach / 3227 ; the following is OPTIONAL, 3228 ; and MAY occur more than once 3230 x-prop / iana-prop 3232 ) 3234 dispprop = *( 3236 ; the following are REQUIRED, 3237 ; but MUST NOT occur more than once 3239 action / description / trigger / 3241 ; 'duration' and 'repeat' are both OPTIONAL, 3242 ; and MUST NOT occur more than once each, 3243 ; but if one occurs, so MUST the other 3245 duration / repeat / 3247 ; the following is OPTIONAL, 3248 ; and MAY occur more than once 3250 x-prop / iana-prop 3252 ) 3254 emailprop = *( 3256 ; the following are all REQUIRED, 3257 ; but MUST NOT occur more than once 3259 action / description / trigger / summary / 3260 ; the following is REQUIRED, 3261 ; and MAY occur more than once 3263 attendee / 3265 ; 'duration' and 'repeat' are both OPTIONAL, 3266 ; and MUST NOT occur more than once each, 3267 ; but if one occurs, so MUST the other 3269 duration / repeat / 3271 ; the following are OPTIONAL, 3272 ; and MAY occur more than once 3274 attach / x-prop / iana-prop 3276 ) 3278 Description: A "VALARM" calendar component is a grouping of 3279 component properties that is a reminder or alarm for an event or a 3280 to-do. For example, it may be used to define a reminder for a 3281 pending event or an overdue to-do. 3283 The "VALARM" calendar component MUST include the "ACTION" and 3284 "TRIGGER" properties. The "ACTION" property further constrains 3285 the "VALARM" calendar component in the following ways: 3287 When the action is "AUDIO", the alarm can also include one and 3288 only one "ATTACH" property, which MUST point to a sound resource, 3289 which is rendered when the alarm is triggered. 3291 When the action is "DISPLAY", the alarm MUST also include a 3292 "DESCRIPTION" property, which contains the text to be displayed 3293 when the alarm is triggered. 3295 When the action is "EMAIL", the alarm MUST include a "DESCRIPTION" 3296 property, which contains the text to be used as the message body, 3297 a "SUMMARY" property, which contains the text to be used as the 3298 message subject, and one or more "ATTENDEE" properties, which 3299 contain the email address of attendees to receive the message. It 3300 can also include one or more "ATTACH" properties, which are 3301 intended to be sent as message attachments. When the alarm is 3302 triggered, the email message is sent. 3304 The "VALARM" calendar component MUST only appear within either a 3305 "VEVENT" or "VTODO" calendar component. "VALARM" calendar 3306 components cannot be nested. Multiple mutually independent 3307 "VALARM" calendar components can be specified for a single 3308 "VEVENT" or "VTODO" calendar component. 3310 The "TRIGGER" property specifies when the alarm will be triggered. 3311 The "TRIGGER" property specifies a duration prior to the start of 3312 an event or a to-do. The "TRIGGER" edge may be explicitly set to 3313 be relative to the "START" or "END" of the event or to-do with the 3314 "RELATED" parameter of the "TRIGGER" property. The "TRIGGER" 3315 property value type can alternatively be set to an absolute 3316 calendar date with UTC time. 3318 In an alarm set to trigger on the "START" of an event or to-do, 3319 the "DTSTART" property MUST be present in the associated event or 3320 to-do. In an alarm in a "VEVENT" calendar component set to 3321 trigger on the "END" of the event, either the "DTEND" property 3322 MUST be present, or the "DTSTART" and "DURATION" properties MUST 3323 both be present. In an alarm in a "VTODO" calendar component set 3324 to trigger on the "END" of the to-do, either the "DUE" property 3325 MUST be present, or the "DTSTART" and "DURATION" properties MUST 3326 both be present. 3328 The alarm can be defined such that it triggers repeatedly. A 3329 definition of an alarm with a repeating trigger MUST include both 3330 the "DURATION" and "REPEAT" properties. The "DURATION" property 3331 specifies the delay period, after which the alarm will repeat. 3332 The "REPEAT" property specifies the number of additional 3333 repetitions that the alarm will be triggered. This repetition 3334 count is in addition to the initial triggering of the alarm. Both 3335 of these properties MUST be present in order to specify a 3336 repeating alarm. If one of these two properties is absent, then 3337 the alarm will not repeat beyond the initial trigger. 3339 The "ACTION" property is used within the "VALARM" calendar 3340 component to specify the type of action invoked when the alarm is 3341 triggered. The "VALARM" properties provide enough information for 3342 a specific action to be invoked. It is typically the 3343 responsibility of a "Calendar User Agent" (CUA) to deliver the 3344 alarm in the specified fashion. An "ACTION" property value of 3345 AUDIO specifies an alarm that causes a sound to be played to alert 3346 the user; DISPLAY specifies an alarm that causes a text message to 3347 be displayed to the user; and EMAIL specifies an alarm that causes 3348 an electronic email message to be delivered to one or more email 3349 addresses. 3351 In an AUDIO alarm, if the optional "ATTACH" property is included, 3352 it MUST specify an audio sound resource. The intention is that 3353 the sound will be played as the alarm effect. If an "ATTACH" 3354 property is specified that does not refer to a sound resource, or 3355 if the specified sound resource cannot be rendered (because its 3356 format is unsupported, or because it cannot be retrieved), then 3357 the CUA or other entity responsible for playing the sound may 3358 choose a fallback action, such as playing a built-in default 3359 sound, or playing no sound at all. 3361 In a DISPLAY alarm, the intended alarm effect is for the text 3362 value of the "DESCRIPTION" property to be displayed to the user. 3364 In an EMAIL alarm, the intended alarm effect is for an email 3365 message to be composed and delivered to all the addresses 3366 specified by the "ATTENDEE" properties in the "VALARM" calendar 3367 component. The "DESCRIPTION" property of the "VALARM" calendar 3368 component MUST be used as the body text of the message, and the 3369 "SUMMARY" property MUST be used as the subject text. Any "ATTACH" 3370 properties in the "VALARM" calendar component SHOULD be sent as 3371 attachments to the message. 3373 Example: The following example is for a "VALARM" calendar component 3374 that specifies an audio alarm that will sound at a precise time 3375 and repeat 4 more times at 15 minute intervals: 3377 BEGIN:VALARM 3378 TRIGGER;VALUE=DATE-TIME:19970317T133000Z 3379 REPEAT:4 3380 DURATION:PT15M 3381 ACTION:AUDIO 3382 ATTACH;FMTTYPE=audio/basic:ftp://example.com/pub/ 3383 sounds/bell-01.aud 3384 END:VALARM 3386 The following example is for a "VALARM" calendar component that 3387 specifies a display alarm that will trigger 30 minutes before the 3388 scheduled start of the event or of the to-do it is associated with 3389 and will repeat 2 more times at 15 minute intervals: 3391 BEGIN:VALARM 3392 TRIGGER:-PT30M 3393 REPEAT:2 3394 DURATION:PT15M 3395 ACTION:DISPLAY 3396 DESCRIPTION:Breakfast meeting with executive\n 3397 team at 8:30 AM EST. 3398 END:VALARM 3400 The following example is for a "VALARM" calendar component that 3401 specifies an email alarm that will trigger 2 days before the 3402 scheduled due date/time of a to-do it is associated with. It does 3403 not repeat. The email has a subject, body and attachment link. 3405 BEGIN:VALARM 3406 TRIGGER;RELATED=END:-P2D 3407 ACTION:EMAIL 3408 ATTENDEE:mailto:john_doe@example.com 3409 SUMMARY:*** REMINDER: SEND AGENDA FOR WEEKLY STAFF MEETING *** 3410 DESCRIPTION:A draft agenda needs to be sent out to the attendees 3411 to the weekly managers meeting (MGR-LIST). Attached is a 3412 pointer the document template for the agenda file. 3413 ATTACH;FMTTYPE=application/msword:http://example.com/ 3414 templates/agenda.doc 3415 END:VALARM 3417 3.7. Calendar Properties 3419 The Calendar Properties are attributes that apply to the iCalendar 3420 object, as a whole. These properties do not appear within a calendar 3421 component. They SHOULD be specified after the "BEGIN:VCALENDAR" 3422 delimiter string and prior to any calendar component. 3424 3.7.1. Calendar Scale 3426 Property Name: CALSCALE 3428 Purpose: This property defines the calendar scale used for the 3429 calendar information specified in the iCalendar object. 3431 Value Type: TEXT 3433 Property Parameters: IANA and non-standard property parameters can 3434 be specified on this property. 3436 Conformance: This property can be specified once in an iCalendar 3437 object. The default value is "GREGORIAN". 3439 Description: This memo is based on the Gregorian calendar scale. 3440 The Gregorian calendar scale is assumed if this property is not 3441 specified in the iCalendar object. It is expected that other 3442 calendar scales will be defined in other specifications or by 3443 future versions of this memo. 3445 Format Definition: This property is defined by the following 3446 notation: 3448 calscale = "CALSCALE" calparam ":" calvalue CRLF 3450 calparam = *(";" other-param) 3452 calvalue = "GREGORIAN" 3454 Example: The following is an example of this property: 3456 CALSCALE:GREGORIAN 3458 3.7.2. Method 3460 Property Name: METHOD 3462 Purpose: This property defines the iCalendar object method 3463 associated with the calendar object. 3465 Value Type: TEXT 3467 Property Parameters: IANA and non-standard property parameters can 3468 be specified on this property. 3470 Conformance: This property can be specified once in an iCalendar 3471 object. 3473 Description: When used in a MIME message entity, the value of this 3474 property MUST be the same as the Content-Type "method" parameter 3475 value. If either the "METHOD" property or the Content-Type 3476 "method" parameter is specified, then the other MUST also be 3477 specified. 3479 No methods are defined by this specification. This is the subject 3480 of other specifications, such as the iCalendar Transport- 3481 independent Interoperability Protocol (iTIP) defined by 3482 [I-D.ietf-calsify-2446bis]. 3484 If this property is not present in the iCalendar object, then a 3485 scheduling transaction MUST NOT be assumed. In such cases, the 3486 iCalendar object is merely being used to transport a snapshot of 3487 some calendar information; without the intention of conveying a 3488 scheduling semantic. 3490 Format Definition: This property is defined by the following 3491 notation: 3493 method = "METHOD" metparam ":" metvalue CRLF 3495 metparam = *(";" other-param) 3497 metvalue = iana-token 3499 Example: The following is a hypothetical example of this property to 3500 convey that the iCalendar object is a scheduling request: 3502 METHOD:REQUEST 3504 3.7.3. Product Identifier 3506 Property Name: PRODID 3508 Purpose: This property specifies the identifier for the product that 3509 created the iCalendar object. 3511 Value Type: TEXT 3513 Property Parameters: IANA and non-standard property parameters can 3514 be specified on this property. 3516 Conformance: The property MUST be specified once in an iCalendar 3517 object. 3519 Description: The vendor of the implementation SHOULD assure that 3520 this is a globally unique identifier; using some technique such as 3521 an FPI value, as defined in [ISO.9070.1991]. 3523 This property SHOULD not be used to alter the interpretation of an 3524 iCalendar object beyond the semantics specified in this memo. For 3525 example, it is not to be used to further the understanding of non- 3526 standard properties. 3528 Format Definition: This property is defined by the following 3529 notation: 3531 prodid = "PRODID" pidparam ":" pidvalue CRLF 3533 pidparam = *(";" other-param) 3535 pidvalue = text 3536 ;Any text that describes the product and version 3537 ;and that is generally assured of being unique. 3539 Example: The following is an example of this property. It does not 3540 imply that English is the default language. 3542 PRODID:-//ABC Corporation//NONSGML My Product//EN 3544 3.7.4. Version 3546 Property Name: VERSION 3548 Purpose: This property specifies the identifier corresponding to the 3549 highest version number or the minimum and maximum range of the 3550 iCalendar specification that is required in order to interpret the 3551 iCalendar object. 3553 Value Type: TEXT 3555 Property Parameters: IANA and non-standard property parameters can 3556 be specified on this property. 3558 Conformance: This property MUST be specified once in an iCalendar 3559 object. 3561 Description: A value of "2.0" corresponds to this memo. 3563 Format Definition: This property is defined by the following 3564 notation: 3566 version = "VERSION" verparam ":" vervalue CRLF 3568 verparam = *(";" other-param) 3570 vervalue = "2.0" ;This memo 3571 / maxver 3572 / (minver ";" maxver) 3574 minver = 3575 ;Minimum iCalendar version needed to parse the iCalendar object 3577 maxver = 3578 ;Maximum iCalendar version needed to parse the iCalendar object 3580 Example: The following is an example of this property: 3582 VERSION:2.0 3584 3.8. Component Properties 3586 The following properties can appear within calendar components, as 3587 specified by each component property definition. 3589 3.8.1. Descriptive Component Properties 3591 The following properties specify descriptive information about 3592 calendar components. 3594 3.8.1.1. Attachment 3596 Property Name: ATTACH 3598 Purpose: This property provides the capability to associate a 3599 document object with a calendar component. 3601 Value Type: The default value type for this property is URI. The 3602 value type can also be set to BINARY to indicate inline binary 3603 encoded content information. 3605 Property Parameters: IANA, non-standard, inline encoding, format 3606 type and value data type property parameters can be specified on 3607 this property. 3609 Conformance: This property can be specified multiple times in a 3610 "VEVENT", "VTODO", "VJOURNAL" or "VALARM" calendar component with 3611 the exception of AUDIO alarm which only allow this property to 3612 occur once. 3614 Description: This property is used in "VEVENT", "VTODO", and 3615 "VJOURNAL" calendar components to associate a resource (e.g., 3616 document) with the calendar component. This property is used in 3617 "VALARM" calendar components to specify an audio sound resource or 3618 an email message attachment. This property can be specified as a 3619 URI pointing to a resource or as inline binary encoded content. 3621 Format Definition: This property is defined by the following 3622 notation: 3624 attach = "ATTACH" attachparam ":" uri CRLF 3626 / "ATTACH" attachparam ";" "ENCODING" "=" "BASE64" 3627 ";" "VALUE" "=" "BINARY" ":" binary 3629 attachparam = *( 3631 ; the following is OPTIONAL, 3632 ; but MUST NOT occur more than once 3634 (";" fmttypeparam) / 3636 ; the following is OPTIONAL, 3637 ; and MAY occur more than once 3639 (";" other-param) 3641 ) 3643 Example: The following are examples of this property: 3645 ATTACH:CID:jsmith.part3.960817T083000.xyzMail@example.com 3647 ATTACH;FMTTYPE=application/postscript:ftp://example.com/pub/ 3648 reports/r-960812.ps 3650 3.8.1.2. Categories 3652 Property Name: CATEGORIES 3654 Purpose: This property defines the categories for a calendar 3655 component. 3657 Value Type: TEXT 3659 Property Parameters: IANA, non-standard, and language property 3660 parameters can be specified on this property. 3662 Conformance: The property can be specified within "VEVENT", "VTODO" 3663 or "VJOURNAL" calendar components. 3665 Description: This property is used to specify categories or subtypes 3666 of the calendar component. The categories are useful in searching 3667 for a calendar component of a particular type and category. 3668 Within the "VEVENT", "VTODO" or "VJOURNAL" calendar components, 3669 more than one category can be specified as a list of categories 3670 separated by the COMMA character (US-ASCII decimal 44). 3672 Format Definition: This property is defined by the following 3673 notation: 3675 categories = "CATEGORIES" catparam ":" text *("," text) 3676 CRLF 3678 catparam = *( 3680 ; the following is OPTIONAL, 3681 ; but MUST NOT occur more than once 3683 (";" languageparam ) / 3685 ; the following is OPTIONAL, 3686 ; and MAY occur more than once 3688 (";" other-param) 3690 ) 3692 Example: The following are examples of this property: 3694 CATEGORIES:APPOINTMENT,EDUCATION 3696 CATEGORIES:MEETING 3698 3.8.1.3. Classification 3700 Property Name: CLASS 3702 Purpose: This property defines the access classification for a 3703 calendar component. 3705 Value Type: TEXT 3707 Property Parameters: IANA and non-standard property parameters can 3708 be specified on this property. 3710 Conformance: The property can be specified once in a "VEVENT", 3711 "VTODO" or "VJOURNAL" calendar components. 3713 Description: An access classification is only one component of the 3714 general security system within a calendar application. It 3715 provides a method of capturing the scope of the access the 3716 calendar owner intends for information within an individual 3717 calendar entry. The access classification of an individual 3718 iCalendar component is useful when measured along with the other 3719 security components of a calendar system (e.g., calendar user 3720 authentication, authorization, access rights, access role, etc.). 3721 Hence, the semantics of the individual access classifications 3722 cannot be completely defined by this memo alone. Additionally, 3723 due to the "blind" nature of most exchange processes using this 3724 memo, these access classifications cannot serve as an enforcement 3725 statement for a system receiving an iCalendar object. Rather, 3726 they provide a method for capturing the intention of the calendar 3727 owner for the access to the calendar component. If not specified 3728 in a component that allows this property, the default value is 3729 PUBLIC. Applications MUST treat x-name and iana-token value they 3730 don't recognized the same way as the PRIVATE value. 3732 Format Definition: This property is defined by the following 3733 notation: 3735 class = "CLASS" classparam ":" classvalue CRLF 3737 classparam = *(";" other-param) 3739 classvalue = "PUBLIC" / "PRIVATE" / "CONFIDENTIAL" / iana-token 3740 / x-name 3741 ;Default is PUBLIC 3743 Example: The following is an example of this property: 3745 CLASS:PUBLIC 3747 3.8.1.4. Comment 3749 Property Name: COMMENT 3751 Purpose: This property specifies non-processing information intended 3752 to provide a comment to the calendar user. 3754 Value Type: TEXT 3756 Property Parameters: IANA, non-standard, alternate text 3757 representation and language property parameters can be specified 3758 on this property. 3760 Conformance: This property can be specified multiple times in 3761 "VEVENT", "VTODO", "VJOURNAL", and "VFREEBUSY" calendar components 3762 as well as in the "STANDARD" and "DAYLIGHT" sub-components. 3764 Description: This property is used to specify a comment to the 3765 calendar user. 3767 Format Definition: This property is defined by the following 3768 notation: 3770 comment = "COMMENT" commparam ":" text CRLF 3772 commparam = *( 3774 ; the following are OPTIONAL, 3775 ; but MUST NOT occur more than once 3777 (";" altrepparam) / (";" languageparam) / 3779 ; the following is OPTIONAL, 3780 ; and MAY occur more than once 3782 (";" other-param) 3784 ) 3786 Example: The following is an example of this property: 3788 COMMENT:The meeting really needs to include both ourselves 3789 and the customer. We can't hold this meeting without them. 3790 As a matter of fact\, the venue for the meeting ought to be at 3791 their site. - - John 3793 3.8.1.5. Description 3795 Property Name: DESCRIPTION 3797 Purpose: This property provides a more complete description of the 3798 calendar component, than that provided by the "SUMMARY" property. 3800 Value Type: TEXT 3802 Property Parameters: IANA, non-standard, alternate text 3803 representation and language property parameters can be specified 3804 on this property. 3806 Conformance: The property can be specified in the "VEVENT", "VTODO", 3807 "VJOURNAL" or "VALARM" calendar components. The property can be 3808 specified multiple times only within a "VJOURNAL" calendar 3809 component. 3811 Description: This property is used in the "VEVENT" and "VTODO" to 3812 capture lengthy textual decriptions associated with the activity. 3814 This property is used in the "VJOURNAL" calendar component to 3815 capture one or more textual journal entries. 3817 This property is used in the "VALARM" calendar component to 3818 capture the display text for a DISPLAY category of alarm, and to 3819 capture the body text for an EMAIL category of alarm. 3821 Format Definition: This property is defined by the following 3822 notation: 3824 description = "DESCRIPTION" descparam ":" text CRLF 3826 descparam = *( 3828 ; the following are OPTIONAL, 3829 ; but MUST NOT occur more than once 3831 (";" altrepparam) / (";" languageparam) / 3833 ; the following is OPTIONAL, 3834 ; and MAY occur more than once 3836 (";" other-param) 3838 ) 3840 Example: The following is an example of this property with formatted 3841 line breaks in the property value: 3843 DESCRIPTION:Meeting to provide technical review for "Phoenix" 3844 design.\nHappy Face Conference Room. Phoenix design team 3845 MUST attend this meeting.\nRSVP to team leader. 3847 3.8.1.6. Geographic Position 3849 Property Name: GEO 3851 Purpose: This property specifies information related to the global 3852 position for the activity specified by a calendar component. 3854 Value Type: FLOAT. The value MUST be two SEMICOLON separated FLOAT 3855 values. 3857 Property Parameters: IANA and non-standard property parameters can 3858 be specified on this property. 3860 Conformance: This property can be specified in "VEVENT" or "VTODO" 3861 calendar components. 3863 Description: This property value specifies latitude and longitude, 3864 in that order (i.e., "LAT LON" ordering). The longitude 3865 represents the location East or West of the prime meridian as a 3866 positive or negative real number, respectively. The longitude and 3867 latitude values MAY be specified up to six decimal places, which 3868 will allow for accuracy to within one meter of geographical 3869 position. Receiving applications MUST accept values of this 3870 precision and MAY truncate values of greater precision. 3872 Values for latitude and longitude shall be expressed as decimal 3873 fractions of degrees. Whole degrees of latitude shall be 3874 represented by a two-digit decimal number ranging from 0 through 3875 90. Whole degrees of longitude shall be represented by a decimal 3876 number ranging from 0 through 180. When a decimal fraction of a 3877 degree is specified, it shall be separated from the whole number 3878 of degrees by a decimal point. 3880 Latitudes North of the equator shall be specified by a plus sign 3881 (+), or by the absence of a minus sign (-), preceding the digits 3882 designating degrees. Latitudes South of the Equator shall be 3883 designated by a minus sign (-) preceding the digits designating 3884 degrees. A point on the Equator shall be assigned to the Northern 3885 Hemisphere. 3887 Longitudes east of the prime meridian shall be specified by a plus 3888 sign (+), or by the absence of a minus sign (-), preceding the 3889 digits designating degrees. Longitudes west of the meridian shall 3890 be designated by minus sign (-) preceding the digits designating 3891 degrees. A point on the prime meridian shall be assigned to the 3892 Eastern Hemisphere. A point on the 180th meridian shall be 3893 assigned to the Western Hemisphere. One exception to this last 3894 convention is permitted. For the special condition of describing 3895 a band of latitude around the earth, the East Bounding Coordinate 3896 data element shall be assigned the value +180 (180) degrees. 3898 Any spatial address with a latitude of +90 (90) or -90 degrees 3899 will specify the position at the North or South Pole, 3900 respectively. The component for longitude may have any legal 3901 value. 3903 With the exception of the special condition described above, this 3904 form is specified in Department of Commerce, 1986, Representation 3905 of geographic point locations for information interchange (Federal 3906 Information Processing Standard 70-1): Washington, Department of 3907 Commerce, National Institute of Standards and Technology. 3909 The simple formula for converting degrees-minutes-seconds into 3910 decimal degrees is: 3912 decimal = degrees + minutes/60 + seconds/3600. 3914 Format Definition: This property is defined by the following 3915 notation: 3917 geo = "GEO" geoparam ":" geovalue CRLF 3919 geoparam = *(";" other-param) 3921 geovalue = float ";" float 3922 ;Latitude and Longitude components 3924 Example: The following is an example of this property: 3926 GEO:37.386013;-122.082932 3928 3.8.1.7. Location 3930 Property Name: LOCATION 3932 Purpose: This property defines the intended venue for the activity 3933 defined by a calendar component. 3935 Value Type: TEXT 3937 Property Parameters: IANA, non-standard, alternate text 3938 representation and language property parameters can be specified 3939 on this property. 3941 Conformance: This property can be specified in "VEVENT" or "VTODO" 3942 calendar component. 3944 Description: Specific venues such as conference or meeting rooms may 3945 be explicitly specified using this property. An alternate 3946 representation may be specified that is a URI that points to 3947 directory information with more structured specification of the 3948 location. For example, the alternate representation may specify 3949 either an LDAP URL [RFC4516] pointing to an LDAP server entry or a 3950 CID URL [RFC2392] pointing to a MIME body part containing a vCard 3951 [RFC2426] for the location. 3953 Format Definition: This property is defined by the following 3954 notation: 3956 location = "LOCATION" locparam ":" text CRLF 3958 locparam = *( 3960 ; the following are OPTIONAL, 3961 ; but MUST NOT occur more than once 3963 (";" altrepparam) / (";" languageparam) / 3965 ; the following is OPTIONAL, 3966 ; and MAY occur more than once 3968 (";" other-param) 3970 ) 3972 Example: The following are some examples of this property: 3974 LOCATION:Conference Room - F123\, Bldg. 002 3976 LOCATION;ALTREP="http://xyzcorp.com/conf-rooms/f123.vcf": 3977 Conference Room - F123\, Bldg. 002 3979 3.8.1.8. Percent Complete 3981 Property Name: PERCENT-COMPLETE 3983 Purpose: This property is used by an assignee or delegatee of a 3984 to-do to convey the percent completion of a to-do to the 3985 "Organizer". 3987 Value Type: INTEGER 3989 Property Parameters: IANA and non-standard property parameters can 3990 be specified on this property. 3992 Conformance: This property can be specified once in a "VTODO" 3993 calendar component. 3995 Description: The property value is a positive integer between zero 3996 and one hundred. A value of "0" indicates the to-do has not yet 3997 been started. A value of "100" indicates that the to-do has been 3998 completed. Integer values in between indicate the percent 3999 partially complete. 4001 When a to-do is assigned to multiple individuals, the property 4002 value indicates the percent complete for that portion of the to-do 4003 assigned to the assignee or delegatee. For example, if a to-do is 4004 assigned to both individuals "A" and "B". A reply from "A" with a 4005 percent complete of "70" indicates that "A" has completed 70% of 4006 the to-do assigned to them. A reply from "B" with a percent 4007 complete of "50" indicates "B" has completed 50% of the to-do 4008 assigned to them. 4010 Format Definition: This property is defined by the following 4011 notation: 4013 percent = "PERCENT-COMPLETE" pctparam ":" integer CRLF 4015 pctparam = *(";" other-param) 4017 Example: The following is an example of this property to show 39% 4018 completion: 4020 PERCENT-COMPLETE:39 4022 3.8.1.9. Priority 4024 Property Name: PRIORITY 4026 Purpose: This property defines the relative priority for a calendar 4027 component. 4029 Value Type: INTEGER 4031 Property Parameters: IANA and non-standard property parameters can 4032 be specified on this property. 4034 Conformance: This property can be specified in "VEVENT" and "VTODO" 4035 calendar components. 4037 Description: This priority is specified as an integer in the range 4038 zero to nine. A value of zero (US-ASCII decimal 48) specifies an 4039 undefined priority. A value of one (US-ASCII decimal 49) is the 4040 highest priority. A value of two (US-ASCII decimal 50) is the 4041 second highest priority. Subsequent numbers specify a decreasing 4042 ordinal priority. A value of nine (US-ASCII decimal 57 ) is the 4043 lowest priority. 4045 A CUA with a three-level priority scheme of "HIGH", "MEDIUM" and 4046 "LOW" is mapped into this property such that a property value in 4047 the range of one (US-ASCII decimal 49) to four (US-ASCII decimal 4048 52) specifies "HIGH" priority. A value of five (US-ASCII decimal 4049 53) is the normal or "MEDIUM" priority. A value in the range of 4050 six (US-ASCII decimal 54) to nine (US-ASCII decimal 57 ) is "LOW" 4051 priority. 4053 A CUA with a priority schema of "A1", "A2", "A3", "B1", "B2", ..., 4054 "C3" is mapped into this property such that a property value of 4055 one (US-ASCII decimal 49) specifies "A1", a property value of two 4056 (US-ASCII decimal 50) specifies "A2", a property value of three 4057 (US-ASCII decimal 51) specifies "A3", and so forth up to a 4058 property value of 9 (US-ASCII decimal 57 ) specifies "C3". 4060 Other integer values are reserved for future use. 4062 Within a "VEVENT" calendar component, this property specifies a 4063 priority for the event. This property may be useful when more 4064 than one event is scheduled for a given time period. 4066 Within a "VTODO" calendar component, this property specified a 4067 priority for the to-do. This property is useful in prioritizing 4068 multiple action items for a given time period. 4070 Format Definition: This property is defined by the following 4071 notation: 4073 priority = "PRIORITY" prioparam ":" priovalue CRLF 4074 ;Default is zero (i.e., undefined) 4076 prioparam = *(";" other-param) 4078 priovalue = integer ;Must be in the range [0..9] 4079 ; All other values are reserved for future use 4081 Example: The following is an example of a property with the highest 4082 priority: 4084 PRIORITY:1 4086 The following is an example of a property with a next highest 4087 priority: 4089 PRIORITY:2 4091 The following is an example of a property with no priority. This 4092 is equivalent to not specifying the "PRIORITY" property: 4094 PRIORITY:0 4096 3.8.1.10. Resources 4098 Property Name: RESOURCES 4100 Purpose: This property defines the equipment or resources 4101 anticipated for an activity specified by a calendar component. 4103 Value Type: TEXT 4105 Property Parameters: IANA, non-standard, alternate text 4106 representation and language property parameters can be specified 4107 on this property. 4109 Conformance: This property can be specified once in "VEVENT" or 4110 "VTODO" calendar component. 4112 Description: The property value is an arbitrary text. More than one 4113 resource can be specified as a list of resources separated by the 4114 COMMA character (US-ASCII decimal 44). 4116 Format Definition: This property is defined by the following 4117 notation: 4119 resources = "RESOURCES" resrcparam ":" text *("," text) CRLF 4121 resrcparam = *( 4123 ; the following are OPTIONAL, 4124 ; but MUST NOT occur more than once 4126 (";" altrepparam) / (";" languageparam) / 4128 ; the following is OPTIONAL, 4129 ; and MAY occur more than once 4131 (";" other-param) 4133 ) 4135 Example: The following is an example of this property: 4137 RESOURCES:EASEL,PROJECTOR,VCR 4139 RESOURCES;LANGUAGE=fr:1 raton-laveur 4141 3.8.1.11. Status 4143 Property Name: STATUS 4145 Purpose: This property defines the overall status or confirmation 4146 for the calendar component. 4148 Value Type: TEXT 4150 Property Parameters: IANA and non-standard property parameters can 4151 be specified on this property. 4153 Conformance: This property can be specified once in "VEVENT", 4154 "VTODO" or "VJOURNAL" calendar components. 4156 Description: In a group scheduled calendar component, the property 4157 is used by the "Organizer" to provide a confirmation of the event 4158 to the "Attendees". For example in a "VEVENT" calendar component, 4159 the "Organizer" can indicate that a meeting is tentative, 4160 confirmed or cancelled. In a "VTODO" calendar component, the 4161 "Organizer" can indicate that an action item needs action, is 4162 completed, is in process or being worked on, or has been 4163 cancelled. In a "VJOURNAL" calendar component, the "Organizer" 4164 can indicate that a journal entry is draft, final or has been 4165 cancelled or removed. 4167 Format Definition: This property is defined by the following 4168 notation: 4170 status = "STATUS" statparam ":" statvalue CRLF 4172 statparam = *(";" other-param) 4174 statvalue = (statvalue-event 4175 / statvalue-todo 4176 / statvalue-jour) 4178 statvalue-event = "TENTATIVE" ;Indicates event is tentative. 4179 / "CONFIRMED" ;Indicates event is definite. 4180 / "CANCELLED" ;Indicates event was cancelled. 4181 ;Status values for a "VEVENT" 4183 statvalue-todo = "NEEDS-ACTION" ;Indicates to-do needs action. 4184 / "COMPLETED" ;Indicates to-do completed. 4185 / "IN-PROCESS" ;Indicates to-do in process of. 4186 / "CANCELLED" ;Indicates to-do was cancelled. 4187 ;Status values for "VTODO". 4189 statvalue-jour = "DRAFT" ;Indicates journal is draft. 4190 / "FINAL" ;Indicates journal is final. 4191 / "CANCELLED" ;Indicates journal is removed. 4192 ;Status values for "VJOURNAL". 4194 Example: The following is an example of this property for a "VEVENT" 4195 calendar component: 4197 STATUS:TENTATIVE 4199 The following is an example of this property for a "VTODO" 4200 calendar component: 4202 STATUS:NEEDS-ACTION 4204 The following is an example of this property for a "VJOURNAL" 4205 calendar component: 4207 STATUS:DRAFT 4209 3.8.1.12. Summary 4211 Property Name: SUMMARY 4213 Purpose: This property defines a short summary or subject for the 4214 calendar component. 4216 Value Type: TEXT 4218 Property Parameters: IANA, non-standard, alternate text 4219 representation and language property parameters can be specified 4220 on this property. 4222 Conformance: The property can be specified in "VEVENT", "VTODO", 4223 "VJOURNAL" or "VALARM" calendar components. 4225 Description: This property is used in the "VEVENT", "VTODO" and 4226 "VJOURNAL" calendar components to capture a short, one line 4227 summary about the activity or journal entry. 4229 This property is used in the "VALARM" calendar component to 4230 capture the subject of an EMAIL category of alarm. 4232 Format Definition: This property is defined by the following 4233 notation: 4235 summary = "SUMMARY" summparam ":" text CRLF 4237 summparam = *( 4239 ; the following are OPTIONAL, 4240 ; but MUST NOT occur more than once 4242 (";" altrepparam) / (";" languageparam) / 4244 ; the following is OPTIONAL, 4245 ; and MAY occur more than once 4247 (";" other-param) 4249 ) 4251 Example: The following is an example of this property: 4253 SUMMARY:Department Party 4255 3.8.2. Date and Time Component Properties 4257 The following properties specify date and time related information in 4258 calendar components. 4260 3.8.2.1. Date/Time Completed 4261 Property Name: COMPLETED 4263 Purpose: This property defines the date and time that a to-do was 4264 actually completed. 4266 Value Type: DATE-TIME 4268 Property Parameters: IANA and non-standard property parameters can 4269 be specified on this property. 4271 Conformance: The property can be specified in a "VTODO" calendar 4272 component. The value MUST be specified as a date with UTC time. 4274 Description: This property defines the date and time that a to-do 4275 was actually completed. 4277 Format Definition: This property is defined by the following 4278 notation: 4280 completed = "COMPLETED" compparam ":" date-time CRLF 4282 compparam = *(";" other-param) 4284 Example: The following is an example of this property: 4286 COMPLETED:19960401T150000Z 4288 3.8.2.2. Date/Time End 4290 Property Name: DTEND 4292 Purpose: This property specifies the date and time that a calendar 4293 component ends. 4295 Value Type: The default value type is DATE-TIME. The value type can 4296 be set to a DATE value type. 4298 Property Parameters: IANA, non-standard, value data type, and time 4299 zone identifier property parameters can be specified on this 4300 property. 4302 Conformance: This property can be specified in "VEVENT" or 4303 "VFREEBUSY" calendar components. 4305 Description: Within the "VEVENT" calendar component, this property 4306 defines the date and time by which the event ends. The value type 4307 of this property MUST be the same as the "DTSTART" property, and 4308 its value MUST be later in time than the value of the "DTSTART" 4309 property. Furthermore, this property MUST be specified as a date 4310 with local time if and only if the "DTSTART" property is also 4311 specified as a date with local time. 4313 Within the "VFREEBUSY" calendar component, this property defines 4314 the end date and time for the free or busy time information. The 4315 time MUST be specified in the UTC time format. The value MUST be 4316 later in time than the value of the "DTSTART" property. 4318 Format Definition: This property is defined by the following 4319 notation: 4321 dtend = "DTEND" dtendparam ":" dtendval CRLF 4323 dtendparam = *( 4325 ; the following are OPTIONAL, 4326 ; but MUST NOT occur more than once 4328 (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / 4329 (";" tzidparam) / 4331 ; the following is OPTIONAL, 4332 ; and MAY occur more than once 4334 (";" other-param) 4336 ) 4338 dtendval = date-time / date 4339 ;Value MUST match value type 4341 Example: The following is an example of this property: 4343 DTEND:19960401T150000Z 4345 DTEND;VALUE=DATE:19980704 4347 3.8.2.3. Date/Time Due 4349 Property Name: DUE 4351 Purpose: This property defines the date and time that a to-do is 4352 expected to be completed. 4354 Value Type: The default value type is DATE-TIME. The value type can 4355 be set to a DATE value type. 4357 Property Parameters: IANA, non-standard, value data type, and time 4358 zone identifier property parameters can be specified on this 4359 property. 4361 Conformance: The property can be specified once in a "VTODO" 4362 calendar component. 4364 Description: This property defines the date and time that a to-do is 4365 expected to be completed. For cases where this property is 4366 specified in a "VTODO" calendar component that also specifies a 4367 "DTSTART" property, the value type of this property MUST be the 4368 same as the "DTSTART" property, and the value of this property 4369 MUST be later in time than the value of the "DTSTART" property. 4370 Furthermore, this property MUST be specified as a date with local 4371 time if and only if the "DTSTART" property is also specified as a 4372 date with local time. 4374 Format Definition: This property is defined by the following 4375 notation: 4377 due = "DUE" dueparam ":" dueval CRLF 4379 dueparam = *( 4381 ; the following are OPTIONAL, 4382 ; but MUST NOT occur more than once 4384 (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / 4385 (";" tzidparam) / 4387 ; the following is OPTIONAL, 4388 ; and MAY occur more than once 4390 (";" other-param) 4392 ) 4394 dueval = date-time / date 4395 ;Value MUST match value type 4397 Example: The following is an example of this property: 4399 DUE:19980430T000000Z 4401 3.8.2.4. Date/Time Start 4403 Property Name: DTSTART 4405 Purpose: This property specifies when the calendar component begins. 4407 Value Type: The default value type is DATE-TIME. The time value 4408 MUST be one of the forms defined for the DATE-TIME value type. 4409 The value type can 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: This property can be specified once in the "VEVENT", 4416 "VTODO", or "VFREEBUSY" calendar components as well as in the 4417 "STANDARD" and "DAYLIGHT" sub-components. This property is 4418 REQUIRED in "VEVENT" calendar components and in all types of 4419 recurring calendar components. 4421 Description: Within the "VEVENT" calendar component, this property 4422 defines the start date and time for the event. 4424 Within the "VFREEBUSY" calendar component, this property defines 4425 the start date and time for the free or busy time information. 4426 The time MUST be specified in UTC time. 4428 Within the "STANDARD" and "DAYLIGHT" sub-components, this property 4429 defines the effective start date and time for a time zone 4430 specification. This property is REQUIRED within each "STANDARD" 4431 and "DAYLIGHT" sub-components included in "VTIMEZONE" calendar 4432 components and MUST be specified as a local DATE-TIME without the 4433 "TZID" property parameter. 4435 Format Definition: This property is defined by the following 4436 notation: 4438 dtstart = "DTSTART" dtstparam ":" dtstval CRLF 4440 dtstparam = *( 4442 ; the following are OPTIONAL, 4443 ; but MUST NOT occur more than once 4445 (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / 4446 (";" tzidparam) / 4448 ; the following is OPTIONAL, 4449 ; and MAY occur more than once 4451 (";" other-param) 4453 ) 4455 dtstval = date-time / date 4456 ;Value MUST match value type 4458 Example: The following is an example of this property: 4460 DTSTART:19980118T073000Z 4462 3.8.2.5. Duration 4464 Property Name: DURATION 4466 Purpose: This property specifies a positive duration of time. 4468 Value Type: DURATION 4470 Property Parameters: IANA and non-standard property parameters can 4471 be specified on this property. 4473 Conformance: This property can be specified in "VEVENT", "VTODO", 4474 "VFREEBUSY" or "VALARM" calendar components. 4476 Description: In a "VEVENT" calendar component the property may be 4477 used to specify a duration of the event, instead of an explicit 4478 end date/time. In a "VTODO" calendar component the property may 4479 be used to specify a duration for the to-do, instead of an 4480 explicit due date/time. In a "VFREEBUSY" calendar component the 4481 property may be used to specify the interval of free time being 4482 requested. In a "VALARM" calendar component the property may be 4483 used to specify the delay period prior to repeating an alarm. 4484 When the "DURATION" property relates to a "DTSTART" property that 4485 is specified as a DATE value, then the "DURATION" property MUST be 4486 specified as a "dur-day" or "dur-week" value. 4488 Format Definition: This property is defined by the following 4489 notation: 4491 duration = "DURATION" durparam ":" dur-value CRLF 4492 ;consisting of a positive duration of time. 4494 durparam = *(";" other-param) 4496 Example: The following is an example of this property that specifies 4497 an interval of time of 1 hour and zero minutes and zero seconds: 4499 DURATION:PT1H0M0S 4501 The following is an example of this property that specifies an 4502 interval of time of 15 minutes. 4504 DURATION:PT15M 4506 3.8.2.6. Free/Busy Time 4508 Property Name: FREEBUSY 4510 Purpose: This property defines one or more free or busy time 4511 intervals. 4513 Value Type: PERIOD 4515 Property Parameters: IANA, non-standard, and free/busy time type 4516 property parameters can be specified on this property. 4518 Conformance: The property can be specified in a "VFREEBUSY" calendar 4519 component. 4521 Description: These time periods can be specified as either a start 4522 and end date-time or a start date-time and duration. The date and 4523 time MUST be a UTC time format. 4525 "FREEBUSY" properties within the "VFREEBUSY" calendar component 4526 SHOULD be sorted in ascending order, based on start time and then 4527 end time, with the earliest periods first. 4529 The "FREEBUSY" property can specify more than one value, separated 4530 by the COMMA character (US-ASCII decimal 44). In such cases, the 4531 "FREEBUSY" property values MUST all be of the same "FBTYPE" 4532 property parameter type (e.g., all values of a particular "FBTYPE" 4533 listed together in a single property). 4535 Format Definition: This property is defined by the following 4536 notation: 4538 freebusy = "FREEBUSY" fbparam ":" fbvalue CRLF 4540 fbparam = *( 4541 ; the following is OPTIONAL, 4542 ; but MUST NOT occur more than once 4544 (";" fbtypeparam) / 4546 ; the following is OPTIONAL, 4547 ; and MAY occur more than once 4549 (";" other-param) 4551 ) 4553 fbvalue = period *("," period) 4554 ;Time value MUST be in the UTC time format. 4556 Example: The following are some examples of this property: 4558 FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:19970308T160000Z/PT8H30M 4560 FREEBUSY;FBTYPE=FREE:19970308T160000Z/PT3H,19970308T200000Z/PT1H 4562 FREEBUSY;FBTYPE=FREE:19970308T160000Z/PT3H,19970308T200000Z/PT1H 4563 ,19970308T230000Z/19970309T000000Z 4565 3.8.2.7. Time Transparency 4567 Property Name: TRANSP 4569 Purpose: This property defines whether an event is transparent or 4570 not to busy time searches. 4572 Value Type: TEXT 4574 Property Parameters: IANA and non-standard property parameters can 4575 be specified on this property. 4577 Conformance: This property can be specified once in a "VEVENT" 4578 calendar component. 4580 Description: Time Transparency is the characteristic of an event 4581 that determines whether it appears to consume time on a calendar. 4582 Events that consume actual time for the individual or resource 4583 associated with the calendar SHOULD be recorded as OPAQUE, 4584 allowing them to be detected by free-busy time searches. Other 4585 events, which do not take up the individual's (or resource's) time 4586 SHOULD be recorded as TRANSPARENT, making them invisible to free- 4587 busy time searches. 4589 Format Definition: This property is defined by the following 4590 notation: 4592 transp = "TRANSP" transparam ":" transvalue CRLF 4594 transparam = *(";" other-param) 4596 transvalue = "OPAQUE" 4597 ;Blocks or opaque on busy time searches. 4598 / "TRANSPARENT" 4599 ;Transparent on busy time searches. 4600 ;Default value is OPAQUE 4602 Example: The following is an example of this property for an event 4603 that is transparent or does not block on free/busy time searches: 4605 TRANSP:TRANSPARENT 4607 The following is an example of this property for an event that is 4608 opaque or blocks on free/busy time searches: 4610 TRANSP:OPAQUE 4612 3.8.3. Time Zone Component Properties 4614 The following properties specify time zone information in calendar 4615 components. 4617 3.8.3.1. Time Zone Identifier 4619 Property Name: TZID 4621 Purpose: This property specifies the text value that uniquely 4622 identifies the "VTIMEZONE" calendar component in the scope of an 4623 iCalendar object. 4625 Value Type: TEXT 4627 Property Parameters: IANA and non-standard property parameters can 4628 be specified on this property. 4630 Conformance: This property MUST be specified in a "VTIMEZONE" 4631 calendar component. 4633 Description: This is the label by which a time zone calendar 4634 component is referenced by any iCalendar properties whose value 4635 type is either DATE-TIME or TIME and not intended to specify a UTC 4636 or a "floating" time. The presence of the SOLIDUS character (US- 4637 ASCII decimal 47) as a prefix, indicates that this "TZID" 4638 represents an unique ID in a globally defined time zone registry 4639 (when such registry is defined). 4641 Note: This document does not define a naming convention for 4642 time zone identifiers. Implementers may want to use the naming 4643 conventions defined in existing time zone specifications such 4644 as the public-domain TZ database [TZDB]. The specification of 4645 globally unique time zone identifiers is not addressed by this 4646 document and is left for future study. 4648 Format Definition: This property is defined by the following 4649 notation: 4651 tzid = "TZID" tzidpropparam ":" [tzidprefix] text CRLF 4653 tzidpropparam = *(";" other-param) 4655 ;tzidprefix = "/" 4656 ; Defined previously. Just listed here for reader convenience. 4658 Example: The following are examples of non-globally unique time zone 4659 identifiers: 4661 TZID:America/New_York 4663 TZID:America/Los_Angeles 4665 The following is an example of a fictitious globally unique time 4666 zone identifier: 4668 TZID:/example.org/America/New_York 4670 3.8.3.2. Time Zone Name 4672 Property Name: TZNAME 4674 Purpose: This property specifies the customary designation for a 4675 time zone description. 4677 Value Type: TEXT 4679 Property Parameters: IANA, non-standard, and language property 4680 parameters can be specified on this property. 4682 Conformance: This property can be specified in "STANDARD" and 4683 "DAYLIGHT" sub-components. 4685 Description: This property may be specified in multiple languages; 4686 in order to provide for different language requirements. 4688 Format Definition: This property is defined by the following 4689 notation: 4691 tzname = "TZNAME" tznparam ":" text CRLF 4693 tznparam = *( 4695 ; the following is OPTIONAL, 4696 ; but MUST NOT occur more than once 4698 (";" languageparam) / 4700 ; the following is OPTIONAL, 4701 ; and MAY occur more than once 4703 (";" other-param) 4705 ) 4707 Example: The following are example of this property: 4709 TZNAME:EST 4711 The following is an example of this property when two different 4712 languages for the time zone name are specified: 4714 TZNAME;LANGUAGE=en:EST 4715 TZNAME;LANGUAGE=fr-CA:HNE 4717 3.8.3.3. Time Zone Offset From 4719 Property Name: TZOFFSETFROM 4721 Purpose: This property specifies the offset which is in use prior to 4722 this time zone observance. 4724 Value Type: UTC-OFFSET 4726 Property Parameters: IANA and non-standard property parameters can 4727 be specified on this property. 4729 Conformance: This property MUST be specified in "STANDARD" and 4730 "DAYLIGHT" sub-components. 4732 Description: This property specifies the offset which is in use 4733 prior to this time observance. It is used to calculate the 4734 absolute time at which the transition to a given observance takes 4735 place. This property MUST only be specified in a "VTIMEZONE" 4736 calendar component. A "VTIMEZONE" calendar component MUST include 4737 this property. The property value is a signed numeric indicating 4738 the number of hours and possibly minutes from UTC. Positive 4739 numbers represent time zones east of the prime meridian, or ahead 4740 of UTC. Negative numbers represent time zones west of the prime 4741 meridian, or behind UTC. 4743 Format Definition: This property is defined by the following 4744 notation: 4746 tzoffsetfrom = "TZOFFSETFROM" frmparam ":" utc-offset 4747 CRLF 4749 frmparam = *(";" other-param) 4751 Example: The following are examples of this property: 4753 TZOFFSETFROM:-0500 4755 TZOFFSETFROM:+1345 4757 3.8.3.4. Time Zone Offset To 4759 Property Name: TZOFFSETTO 4761 Purpose: This property specifies the offset which is in use in this 4762 time zone observance. 4764 Value Type: UTC-OFFSET 4766 Property Parameters: IANA and non-standard property parameters can 4767 be specified on this property. 4769 Conformance: This property MUST be specified in "STANDARD" and 4770 "DAYLIGHT" sub-components. 4772 Description: This property specifies the offset which is in use in 4773 this time zone observance. It is used to calculate the absolute 4774 time for the new observance. The property value is a signed 4775 numeric indicating the number of hours and possibly minutes from 4776 UTC. Positive numbers represent time zones east of the prime 4777 meridian, or ahead of UTC. Negative numbers represent time zones 4778 west of the prime meridian, or behind UTC. 4780 Format Definition: This property is defined by the following 4781 notation: 4783 tzoffsetto = "TZOFFSETTO" toparam ":" utc-offset CRLF 4785 toparam = *(";" other-param) 4787 Example: The following are examples of this property: 4789 TZOFFSETTO:-0400 4791 TZOFFSETTO:+1245 4793 3.8.3.5. Time Zone URL 4795 Property Name: TZURL 4797 Purpose: This property provides a means for a "VTIMEZONE" component 4798 to point to a network location that can be used to retrieve an up- 4799 to-date version of itself. 4801 Value Type: URI 4803 Property Parameters: IANA and non-standard property parameters can 4804 be specified on this property. 4806 Conformance: This property can be specified in a "VTIMEZONE" 4807 calendar component. 4809 Description: This property provides a means for a "VTIMEZONE" 4810 component to point to a network location that can be used to 4811 retrieve an up-to-date version of itself. This provides a hook to 4812 handle changes government bodies impose upon time zone 4813 definitions. Retrieval of this resource results in an iCalendar 4814 object containing a single "VTIMEZONE" component and a "METHOD" 4815 property set to PUBLISH. 4817 Format Definition: This property is defined by the following 4818 notation: 4820 tzurl = "TZURL" tzurlparam ":" uri CRLF 4822 tzurlparam = *(";" other-param) 4824 Example: The following is an example of this property: 4826 TZURL:http://timezones.example.org/tz/America-Los_Angeles.ics 4828 3.8.4. Relationship Component Properties 4830 The following properties specify relationship information in calendar 4831 components. 4833 3.8.4.1. Attendee 4835 Property Name: ATTENDEE 4837 Purpose: This property defines an "Attendee" within a calendar 4838 component. 4840 Value Type: CAL-ADDRESS 4842 Property Parameters: IANA, non-standard, language, calendar user 4843 type, group or list membership, participation role, participation 4844 status, RSVP expectation, delegatee, delegator, sent by, common 4845 name or directory entry reference property parameters can be 4846 specified on this property. 4848 Conformance: This property MUST be specified in an iCalendar object 4849 that specifies a group scheduled calendar entity. This property 4850 MUST NOT be specified in an iCalendar object when publishing the 4851 calendar information (e.g., NOT in an iCalendar object that 4852 specifies the publication of a calendar user's busy time, event, 4853 to-do or journal). This property is not specified in an iCalendar 4854 object that specifies only a time zone definition or that defines 4855 calendar components that are not group scheduled components, but 4856 are components only on a single user's calendar. 4858 Description: This property MUST only be specified within calendar 4859 components to specify participants, non-participants and the chair 4860 of a group scheduled calendar entity. The property is specified 4861 within an "EMAIL" category of the "VALARM" calendar component to 4862 specify an email address that is to receive the email type of 4863 iCalendar alarm. 4865 The property parameter "CN" is for the common or displayable name 4866 associated with the calendar address; "ROLE", for the intended 4867 role that the attendee will have in the calendar component; 4868 "PARTSTAT", for the status of the attendee's participation; 4869 "RSVP", for indicating whether the favor of a reply is requested; 4870 "CUTYPE", to indicate the type of calendar user; "MEMBER", to 4871 indicate the groups that the attendee belongs to; "DELEGATED-TO", 4872 to indicate the calendar users that the original request was 4873 delegated to; and "DELEGATED-FROM", to indicate whom the request 4874 was delegated from; "SENT-BY", to indicate whom is acting on 4875 behalf of the "ATTENDEE"; and "DIR", to indicate the URI that 4876 points to the directory information corresponding to the attendee. 4877 These property parameters can be specified on an "ATTENDEE" 4878 property in either a "VEVENT", "VTODO" or "VJOURNAL" calendar 4879 component. They MUST NOT be specified in an "ATTENDEE" property 4880 in a "VFREEBUSY" or "VALARM" calendar component. If the 4881 "LANGUAGE" property parameter is specified, the identified 4882 language applies to the "CN" parameter. 4884 A recipient delegated a request MUST inherit the "RSVP" and "ROLE" 4885 values from the attendee that delegated the request to them. 4887 Multiple attendees can be specified by including multiple 4888 "ATTENDEE" properties within the calendar component. 4890 Format Definition: This property is defined by the following 4891 notation: 4893 attendee = "ATTENDEE" attparam ":" cal-address CRLF 4895 attparam = *( 4897 ; the following are OPTIONAL, 4898 ; but MUST NOT occur more than once 4900 (";" cutypeparam) / (";" memberparam) / 4901 (";" roleparam) / (";" partstatparam) / 4902 (";" rsvpparam) / (";" deltoparam) / 4903 (";" delfromparam) / (";" sentbyparam) / 4904 (";" cnparam) / (";" dirparam) / 4905 (";" languageparam) / 4907 ; the following is OPTIONAL, 4908 ; and MAY occur more than once 4910 (";" other-param) 4912 ) 4914 Example: The following are examples of this property's use for a 4915 to-do: 4917 ATTENDEE;MEMBER="mailto:DEV-GROUP@example.com": 4918 mailto:joecool@example.com 4919 ATTENDEE;DELEGATED-FROM="mailto:immud@example.com": 4920 mailto:ildoit@example.com 4922 The following is an example of this property used for specifying 4923 multiple attendees to an event: 4925 ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;CN=Henry 4926 Cabot:mailto:hcabot@example.com 4927 ATTENDEE;ROLE=REQ-PARTICIPANT;DELEGATED-FROM="mailto:bob@ 4928 example.com";PARTSTAT=ACCEPTED;CN=Jane Doe:mailto:jdoe@ 4929 example.com 4931 The following is an example of this property with a URI to the 4932 directory information associated with the attendee: 4934 ATTENDEE;CN=John Smith;DIR="ldap://example.com:6666/o=ABC% 4935 20Industries,c=US???(cn=Jim%20Dolittle)":mailto:jimdo@ 4936 example.com 4938 The following is an example of this property with "delegatee" and 4939 "delegator" information for an event: 4941 ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;DELEGATED-FROM= 4942 "mailto:iamboss@example.com";CN=Henry Cabot:mailto:hcabot@ 4943 example.com 4944 ATTENDEE;ROLE=NON-PARTICIPANT;PARTSTAT=DELEGATED;DELEGATED-TO= 4945 "mailto:hcabot@example.com";CN=The Big Cheese:mailto:iamboss 4946 @example.com 4947 ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;CN=Jane Doe 4948 :mailto:jdoe@example.com 4950 Example: The following is an example of this property's use when 4951 another calendar user is acting on behalf of the "Attendee": 4953 ATTENDEE;SENT-BY=mailto:jan_doe@example.com;CN=John Smith: 4954 mailto:jsmith@example.com 4956 3.8.4.2. Contact 4958 Property Name: CONTACT 4960 Purpose: This property is used to represent contact information or 4961 alternately a reference to contact information associated with the 4962 calendar component. 4964 Value Type: TEXT 4966 Property Parameters: IANA, non-standard, alternate text 4967 representation and language property parameters can be specified 4968 on this property. 4970 Conformance: This property can be specified in a "VEVENT", "VTODO", 4971 "VJOURNAL" or "VFREEBUSY" calendar component. 4973 Description: The property value consists of textual contact 4974 information. An alternative representation for the property value 4975 can also be specified that refers to a URI pointing to an 4976 alternate form, such as a vCard [RFC2426], for the contact 4977 information. 4979 Format Definition: This property is defined by the following 4980 notation: 4982 contact = "CONTACT" contparam ":" text CRLF 4984 contparam = *( 4985 ; the following are OPTIONAL, 4986 ; but MUST NOT occur more than once 4988 (";" altrepparam) / (";" languageparam) / 4990 ; the following is OPTIONAL, 4991 ; and MAY occur more than once 4993 (";" other-param) 4995 ) 4997 Example: The following is an example of this property referencing 4998 textual contact information: 5000 CONTACT:Jim Dolittle\, ABC Industries\, +1-919-555-1234 5002 The following is an example of this property with an alternate 5003 representation of a LDAP URI to a directory entry containing the 5004 contact information: 5006 CONTACT;ALTREP="ldap://example.com:6666/o=ABC%20Industries\, 5007 c=US???(cn=Jim%20Dolittle)":Jim Dolittle\, ABC Industries\, 5008 +1-919-555-1234 5010 The following is an example of this property with an alternate 5011 representation of a MIME body part containing the contact 5012 information, such as a vCard [RFC2426] embedded in a text/ 5013 directory media type [RFC2425]: 5015 CONTACT;ALTREP="CID:part3.msg970930T083000SILVER@example.com": 5016 Jim Dolittle\, ABC Industries\, +1-919-555-1234 5018 The following is an example of this property referencing a network 5019 resource, such as a vCard [RFC2426] object containing the contact 5020 information: 5022 CONTACT;ALTREP="http://example.com/pdi/jdoe.vcf":Jim 5023 Dolittle\, ABC Industries\, +1-919-555-1234 5025 3.8.4.3. Organizer 5026 Property Name: ORGANIZER 5028 Purpose: This property defines the organizer for a calendar 5029 component. 5031 Value Type: CAL-ADDRESS 5033 Property Parameters: IANA, non-standard, language, common name, 5034 directory entry reference, sent by property parameters can be 5035 specified on this property. 5037 Conformance: This property MUST be specified in an iCalendar object 5038 that specifies a group scheduled calendar entity. This property 5039 MUST be specified in an iCalendar object that specifies the 5040 publication of a calendar user's busy time. This property MUST 5041 NOT be specified in an iCalendar object that specifies only a time 5042 zone definition or that defines calendar components that are not 5043 group scheduled components, but are components only on a single 5044 user's calendar. 5046 Description: This property is specified within the "VEVENT", 5047 "VTODO", "VJOURNAL" calendar components to specify the organizer 5048 of a group scheduled calendar entity. The property is specified 5049 within the "VFREEBUSY" calendar component to specify the calendar 5050 user requesting the free or busy time. When publishing a 5051 "VFREEBUSY" calendar component, the property is used to specify 5052 the calendar that the published busy time came from. 5054 The property has the property parameters "CN", for specifying the 5055 common or display name associated with the "Organizer", "DIR", for 5056 specifying a pointer to the directory information associated with 5057 the "Organizer", "SENT-BY", for specifying another calendar user 5058 that is acting on behalf of the "Organizer". The non-standard 5059 parameters may also be specified on this property. If the 5060 "LANGUAGE" property parameter is specified, the identified 5061 language applies to the "CN" parameter value. 5063 Format Definition: This property is defined by the following 5064 notation: 5066 organizer = "ORGANIZER" orgparam ":" 5067 cal-address CRLF 5069 orgparam = *( 5071 ; the following are OPTIONAL, 5072 ; but MUST NOT occur more than once 5074 (";" cnparam) / (";" dirparam) / (";" sentbyparam) / 5075 (";" languageparam) / 5077 ; the following is OPTIONAL, 5078 ; and MAY occur more than once 5080 (";" other-param) 5082 ) 5084 Example: The following is an example of this property: 5086 ORGANIZER;CN=John Smith:mailto:jsmith@example.com 5088 The following is an example of this property with a pointer to the 5089 directory information associated with the organizer: 5091 ORGANIZER;CN=JohnSmith;DIR="ldap://example.com:6666/o=DC%20Ass 5092 ociates,c=US???(cn=John%20Smith)":mailto:jsmith@example.com 5094 The following is an example of this property used by another 5095 calendar user who is acting on behalf of the organizer, with 5096 responses intended to be sent back to the organizer, not the other 5097 calendar user: 5099 ORGANIZER;SENT-BY="mailto:jane_doe@example.com": 5100 mailto:jsmith@example.com 5102 3.8.4.4. Recurrence ID 5104 Property Name: RECURRENCE-ID 5106 Purpose: This property is used in conjunction with the "UID" and 5107 "SEQUENCE" property to identify a specific instance of a recurring 5108 "VEVENT", "VTODO" or "VJOURNAL" calendar component. The property 5109 value is the original value of the "DTSTART" property of the 5110 recurrence instance. 5112 Value Type: The default value type for this property is DATE-TIME. 5113 The time format can be any of the valid forms defined for a DATE- 5114 TIME value type. See DATE-TIME value type definition for specific 5115 interpretations of the various forms. The value type can be set 5116 to DATE. 5118 Property Parameters: IANA, non-standard, value data type, and time 5119 zone identifier parameters can be specified on this property. 5121 Conformance: This property can be specified in an iCalendar object 5122 containing a recurring calendar component. 5124 Description: The full range of calendar components specified by a 5125 recurrence set is referenced by referring to just the "UID" 5126 property value corresponding to the calendar component. The 5127 "RECURRENCE-ID" property allows the reference to an individual 5128 instance within the recurrence set. 5130 If the value of the "DTSTART" property is a DATE type value, then 5131 the value MUST be the calendar date for the recurrence instance. 5133 The date/time value is set to the time when the original 5134 recurrence instance would occur; meaning that if the intent is to 5135 change a Friday meeting to Thursday, the date/time is still set to 5136 the original Friday meeting. 5138 The "RECURRENCE-ID" property is used in conjunction with the "UID" 5139 and "SEQUENCE" property to identify a particular instance of a 5140 recurring event, to-do or journal. For a given pair of "UID" and 5141 "SEQUENCE" property values, the "RECURRENCE-ID" value for a 5142 recurrence instance is fixed. 5144 Format Definition: This property is defined by the following 5145 notation: 5147 recurid = "RECURRENCE-ID" ridparam ":" ridval CRLF 5149 ridparam = *( 5151 ; the following are OPTIONAL, 5152 ; but MUST NOT occur more than once 5154 (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / 5155 (";" tzidparam) / 5157 ; the following is OPTIONAL, 5158 ; and MAY occur more than once 5160 (";" other-param) 5162 ) 5164 ridval = date-time / date 5165 ;Value MUST match value type 5167 Example: The following are examples of this property: 5169 RECURRENCE-ID;VALUE=DATE:19960401 5171 RECURRENCE-ID:19960120T120000Z 5173 3.8.4.5. Related To 5175 Property Name: RELATED-TO 5177 Purpose: This property is used to represent a relationship or 5178 reference between one calendar component and another. 5180 Value Type: TEXT 5182 Property Parameters: IANA, non-standard, and relationship type 5183 property parameters can be specified on this property. 5185 Conformance: This property can be specified in the "VEVENT", "VTODO" 5186 and "VJOURNAL" calendar components. 5188 Description: The property value consists of the persistent, globally 5189 unique identifier of another calendar component. This value would 5190 be represented in a calendar component by the "UID" property. 5192 By default, the property value points to another calendar 5193 component that has a PARENT relationship to the referencing 5194 object. The "RELTYPE" property parameter is used to either 5195 explicitly state the default PARENT relationship type to the 5196 referenced calendar component or to override the default PARENT 5197 relationship type and specify either a CHILD or SIBLING 5198 relationship. The PARENT relationship indicates that the calendar 5199 component is a subordinate of the referenced calendar component. 5200 The CHILD relationship indicates that the calendar component is a 5201 superior of the referenced calendar component. The SIBLING 5202 relationship indicates that the calendar component is a peer of 5203 the referenced calendar component. 5205 Changes to a calendar component referenced by this property can 5206 have an implicit impact on the related calendar component. For 5207 example, if a group event changes its start or end date or time, 5208 then the related, dependent events will need to have their start 5209 and end dates changed in a corresponding way. Similarly, if a 5210 PARENT calendar component is cancelled or deleted, then there is 5211 an implied impact to the related CHILD calendar components. This 5212 property is intended only to provide information on the 5213 relationship of calendar components. It is up to the target 5214 calendar system to maintain any property implications of this 5215 relationship. 5217 Format Definition: This property is defined by the following 5218 notation: 5220 related = "RELATED-TO" relparam ":" text CRLF 5222 relparam = *( 5224 ; the following is OPTIONAL, 5225 ; but MUST NOT occur more than once 5227 (";" reltypeparam) / 5229 ; the following is OPTIONAL, 5230 ; and MAY occur more than once 5232 (";" other-param) 5234 ) 5236 The following is an example of this property: 5238 RELATED-TO:jsmith.part7.19960817T083000.xyzMail@example.com 5240 RELATED-TO:19960401-080045-4000F192713-0052@example.com 5242 3.8.4.6. Uniform Resource Locator 5244 Property Name: URL 5246 Purpose: This property defines a Uniform Resource Locator (URL) 5247 associated with the iCalendar object. 5249 Value Type: URI 5251 Property Parameters: IANA and non-standard property parameters can 5252 be specified on this property. 5254 Conformance: This property can be specified once in the "VEVENT", 5255 "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components. 5257 Description: This property may be used in a calendar component to 5258 convey a location where a more dynamic rendition of the calendar 5259 information associated with the calendar component can be found. 5260 This memo does not attempt to standardize the form of the URI, nor 5261 the format of the resource pointed to by the property value. If 5262 the URL property and Content-Location MIME header are both 5263 specified, they MUST point to the same resource. 5265 Format Definition: This property is defined by the following 5266 notation: 5268 url = "URL" urlparam ":" uri CRLF 5270 urlparam = *(";" other-param) 5272 Example: The following is an example of this property: 5274 URL:http://example.com/pub/calendars/jsmith/mytime.ics 5276 3.8.4.7. Unique Identifier 5278 Property Name: UID 5280 Purpose: This property defines the persistent, globally unique 5281 identifier for the calendar component. 5283 Value Type: TEXT 5285 Property Parameters: IANA and non-standard property parameters can 5286 be specified on this property. 5288 Conformance: The property MUST be specified in the "VEVENT", 5289 "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components. 5291 Description: The "UID" itself MUST be a globally unique identifier. 5292 The generator of the identifier MUST guarantee that the identifier 5293 is unique. There are several algorithms that can be used to 5294 accomplish this. The identifier is RECOMMENDED to be the 5295 identical syntax to the [RFC2822] addr-spec. A good method to 5296 assure uniqueness is to put the domain name or a domain literal IP 5297 address of the host on which the identifier was created on the 5298 right hand side of the "@", and on the left hand side, put a 5299 combination of the current calendar date and time of day (i.e., 5300 formatted in as a DATE-TIME value) along with some other currently 5301 unique (perhaps sequential) identifier available on the system 5302 (for example, a process id number). Using a date/time value on 5303 the left hand side and a domain name or domain literal on the 5304 right hand side makes it possible to guarantee uniqueness since no 5305 two hosts should be using the same domain name or IP address at 5306 the same time. Though other algorithms will work, it is 5307 RECOMMENDED that the right hand side contain some domain 5308 identifier (either of the host itself or otherwise) such that the 5309 generator of the message identifier can guarantee the uniqueness 5310 of the left hand side within the scope of that domain. 5312 This is the method for correlating scheduling messages with the 5313 referenced "VEVENT", "VTODO", or "VJOURNAL" calendar component. 5315 The full range of calendar components specified by a recurrence 5316 set is referenced by referring to just the "UID" property value 5317 corresponding to the calendar component. The "RECURRENCE-ID" 5318 property allows the reference to an individual instance within the 5319 recurrence set. 5321 This property is an important method for group scheduling 5322 applications to match requests with later replies, modifications 5323 or deletion requests. Calendaring and scheduling applications 5324 MUST generate this property in "VEVENT", "VTODO" and "VJOURNAL" 5325 calendar components to assure interoperability with other group 5326 scheduling applications. This identifier is created by the 5327 calendar system that generates an iCalendar object. 5329 Implementations MUST be able to receive and persist values of at 5330 least 255 octets for this property but MUST NOT truncate values in 5331 the middle of a UTF-8 multi-octet sequence. 5333 Format Definition: This property is defined by the following 5334 notation: 5336 uid = "UID" uidparam ":" text CRLF 5338 uidparam = *(";" other-param) 5340 Example: The following is an example of this property: 5342 UID:19960401T080045Z-4000F192713-0052@example.com 5344 3.8.5. Recurrence Component Properties 5346 The following properties specify recurrence information in calendar 5347 components. 5349 3.8.5.1. Exception Date/Times 5351 Property Name: EXDATE 5353 Purpose: This property defines the list of date/time exceptions for 5354 recurring events, to-dos, journal entries or time zone 5355 definitions. 5357 Value Type: The default value type for this property is DATE-TIME. 5358 The value type can be set to DATE. 5360 Property Parameters: IANA, non-standard, value data type and time 5361 zone identifier property parameters can be specified on this 5362 property. 5364 Conformance: This property can be specified in recurring "VEVENT", 5365 "VTODO", and "VJOURNAL" calendar components as well as in the 5366 "STANDARD" and "DAYLIGHT" sub-components of the "VTIMEZONE" 5367 calendar component. 5369 Description: The exception dates, if specified, are used in 5370 computing the recurrence set. The recurrence set is the complete 5371 set of recurrence instances for a calendar component. The 5372 recurrence set is generated by considering the initial "DTSTART" 5373 property along with the "RRULE", "RDATE", and "EXDATE" properties 5374 contained within the recurring component. The "DTSTART" property 5375 defines the first instance in the recurrence set. The "DTSTART" 5376 property value SHOULD match the pattern of the recurrence rule, if 5377 specified. The recurrence set generated with a "DTSTART" property 5378 value that doesn't match the pattern of the rule is undefined. 5379 The final recurrence set is generated by gathering all of the 5380 start date-times generated by any of the specified "RRULE" and 5381 "RDATE" properties, and then excluding any start date and times 5382 specified by "EXDATE" properties. This implies that start date 5383 and times specified by "EXDATE" properties take precedence over 5384 those specified by inclusion properties (i.e., "RDATE" and 5385 "RRULE"). When duplicate instances are generated by the "RRULE" 5386 and "RDATE" properties, only one recurrence is considered. 5387 Duplicate instances are ignored. 5389 The "EXDATE" property can be used to exclude the value specified 5390 in "DTSTART". However, in such cases the original "DTSTART" date 5391 MUST still be maintained by the calendaring and scheduling system 5392 because the original "DTSTART" value has inherent usage 5393 dependencies by other properties such as the "RECURRENCE-ID". 5395 Format Definition: This property is defined by the following 5396 notation: 5398 exdate = "EXDATE" exdtparam ":" exdtval *("," exdtval) CRLF 5400 exdtparam = *( 5402 ; the following are OPTIONAL, 5403 ; but MUST NOT occur more than once 5405 (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / 5407 (";" tzidparam) / 5409 ; the following is OPTIONAL, 5410 ; and MAY occur more than once 5412 (";" other-param) 5414 ) 5416 exdtval = date-time / date 5417 ;Value MUST match value type 5419 Example: The following is an example of this property: 5421 EXDATE:19960402T010000Z,19960403T010000Z,19960404T010000Z 5423 3.8.5.2. Recurrence Date/Times 5425 Property Name: RDATE 5427 Purpose: This property defines the list of date/times for recurring 5428 events, to-dos, journal entries or time zone definitions. 5430 Value Type: The default value type for this property is DATE-TIME. 5431 The value type can be set to DATE or PERIOD. 5433 Property Parameters: IANA, non-standard, value data type and time 5434 zone identifier property parameters can be specified on this 5435 property. 5437 Conformance: This property can be specified in recurring "VEVENT", 5438 "VTODO", and "VJOURNAL" calendar components as well as in the 5439 "STANDARD" and "DAYLIGHT" sub-components of the "VTIMEZONE" 5440 calendar component. 5442 Description: This property can appear along with the "RRULE" 5443 property to define an aggregate set of repeating occurrences. 5444 When they both appear in a recurring component, the recurrence 5445 instances are defined by the union of occurrences defined by both 5446 the "RDATE" and "RRULE". 5448 The recurrence dates, if specified, are used in computing the 5449 recurrence set. The recurrence set is the complete set of 5450 recurrence instances for a calendar component. The recurrence set 5451 is generated by considering the initial "DTSTART" property along 5452 with the "RRULE", "RDATE", and "EXDATE" properties contained 5453 within the recurring component. The "DTSTART" property defines 5454 the first instance in the recurrence set. The "DTSTART" property 5455 value SHOULD match the pattern of the recurrence rule, if 5456 specified. The recurrence set generated with a "DTSTART" property 5457 value that doesn't match the pattern of the rule is undefined. 5458 The final recurrence set is generated by gathering all of the 5459 start date-times generated by any of the specified "RRULE" and 5460 "RDATE" properties, and then excluding any start date and times 5461 specified by "EXDATE" properties. This implies that start date/ 5462 times specified by "EXDATE" properties take precedence over those 5463 specified by inclusion properties (i.e., "RDATE" and "RRULE"). 5464 Where duplicate instances are generated by the "RRULE" and "RDATE" 5465 properties, only one recurrence is considered. Duplicate 5466 instances are ignored. 5468 Format Definition: This property is defined by the following 5469 notation: 5471 rdate = "RDATE" rdtparam ":" rdtval *("," rdtval) CRLF 5473 rdtparam = *( 5475 ; the following are OPTIONAL, 5476 ; but MUST NOT occur more than once 5478 (";" "VALUE" "=" ("DATE-TIME" / "DATE" / "PERIOD")) / 5479 (";" tzidparam) / 5481 ; the following is OPTIONAL, 5482 ; and MAY occur more than once 5484 (";" other-param) 5486 ) 5488 rdtval = date-time / date / period 5489 ;Value MUST match value type 5491 Example: The following are examples of this property: 5493 RDATE:19970714T123000Z 5494 RDATE;TZID=America/New_York:19970714T083000 5496 RDATE;VALUE=PERIOD:19960403T020000Z/19960403T040000Z, 5497 19960404T010000Z/PT3H 5499 RDATE;VALUE=DATE:19970101,19970120,19970217,19970421 5500 19970526,19970704,19970901,19971014,19971128,19971129,19971225 5502 3.8.5.3. Recurrence Rule 5504 Property Name: RRULE 5506 Purpose: This property defines a rule or repeating pattern for 5507 recurring events, to-dos, journal entries or time zone 5508 definitions. 5510 Value Type: RECUR 5512 Property Parameters: IANA and non-standard property parameters can 5513 be specified on this property. 5515 Conformance: This property can be specified in recurring "VEVENT", 5516 "VTODO" and "VJOURNAL" calendar components as well as in the 5517 "STANDARD" and "DAYLIGHT" sub-components of the "VTIMEZONE" 5518 calendar component, but it SHOULD NOT be specified more than once. 5519 The recurrence set generated with multiple "RRULE" properties is 5520 undefined. 5522 Description: The recurrence rule, if specified, is used in computing 5523 the recurrence set. The recurrence set is the complete set of 5524 recurrence instances for a calendar component. The recurrence set 5525 is generated by considering the initial "DTSTART" property along 5526 with the "RRULE", "RDATE", and "EXDATE" properties contained 5527 within the recurring component. The "DTSTART" property defines 5528 the first instance in the recurrence set. The "DTSTART" property 5529 value SHOULD be synchronized with the recurrence rule, if 5530 specified. The recurrence set generated with a "DTSTART" property 5531 value not synchronized with the recurrence rule is undefined. The 5532 final recurrence set is generated by gathering all of the start 5533 date/times generated by any of the specified "RRULE" and "RDATE" 5534 properties, and then excluding any start date/times specified by 5535 "EXDATE" properties. This implies that start date/times specified 5536 by "EXDATE" properties take precedence over those specified by 5537 inclusion properties (i.e., "RDATE" and "RRULE"). Where duplicate 5538 instances are generated by the "RRULE" and "RDATE" properties, 5539 only one recurrence is considered. Duplicate instances are 5540 ignored. 5542 The "DTSTART" property specified within the iCalendar object 5543 defines the first instance of the recurrence. In most cases, a 5544 "DTSTART" property of DATE-TIME value type used with a recurrence 5545 rule, should be specified as a date with local time and time zone 5546 reference to make sure all the recurrence instances start at the 5547 same local time regardless of time zone changes. 5549 If the duration of the recurring component is specified with the 5550 "DTEND" or "DUE" property, then the same exact duration will apply 5551 to all the members of the generated recurrence set. Else, if the 5552 duration of the recurring component is specified with the 5553 "DURATION" property, then the same nominal duration will apply to 5554 all the members of the generated recurrence set and the exact 5555 duration of each recurrence instance will depend on its specific 5556 start time. For example, recurrence instances of a nominal 5557 duration of one day will have an exact duration of more or less 5558 than 24 hours on a day where a time zone shift occurs. The 5559 duration of a specific recurrence may be modified in an exception 5560 component or simply by using an "RDATE" property of PERIOD value 5561 type. 5563 Format Definition: This property is defined by the following 5564 notation: 5566 rrule = "RRULE" rrulparam ":" recur CRLF 5568 rrulparam = *(";" other-param) 5570 Example: All examples assume the Eastern United States time zone. 5572 Daily for 10 occurrences: 5574 DTSTART;TZID=America/New_York:19970902T090000 5575 RRULE:FREQ=DAILY;COUNT=10 5577 ==> (1997 9:00 AM EDT) September 2-11 5579 Daily until December 24, 1997: 5581 DTSTART;TZID=America/New_York:19970902T090000 5582 RRULE:FREQ=DAILY;UNTIL=19971224T000000Z 5584 ==> (1997 9:00 AM EDT) September 2-30;October 1-25 5585 (1997 9:00 AM EST) October 26-31;November 1-30;December 1-23 5587 Every other day - forever: 5589 DTSTART;TZID=America/New_York:19970902T090000 5590 RRULE:FREQ=DAILY;INTERVAL=2 5592 ==> (1997 9:00 AM EDT) September 2,4,6,8...24,26,28,30; 5593 October 2,4,6...20,22,24 5594 (1997 9:00 AM EST) October 26,28,30; 5595 November 1,3,5,7...25,27,29; 5596 December 1,3,... 5598 Every 10 days, 5 occurrences: 5600 DTSTART;TZID=America/New_York:19970902T090000 5601 RRULE:FREQ=DAILY;INTERVAL=10;COUNT=5 5603 ==> (1997 9:00 AM EDT) September 2,12,22; 5604 October 2,12 5606 Everyday in January, for 3 years: 5608 DTSTART;TZID=America/New_York:19980101T090000 5610 RRULE:FREQ=YEARLY;UNTIL=20000131T140000Z; 5611 BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA 5612 or 5613 RRULE:FREQ=DAILY;UNTIL=20000131T140000Z;BYMONTH=1 5615 ==> (1998 9:00 AM EST)January 1-31 5616 (1999 9:00 AM EST)January 1-31 5617 (2000 9:00 AM EST)January 1-31 5619 Weekly for 10 occurrences 5621 DTSTART;TZID=America/New_York:19970902T090000 5622 RRULE:FREQ=WEEKLY;COUNT=10 5624 ==> (1997 9:00 AM EDT) September 2,9,16,23,30;October 7,14,21 5625 (1997 9:00 AM EST) October 28;November 4 5627 Weekly until December 24, 1997 5629 DTSTART;TZID=America/New_York:19970902T090000 5630 RRULE:FREQ=WEEKLY;UNTIL=19971224T000000Z 5632 ==> (1997 9:00 AM EDT) September 2,9,16,23,30; 5633 October 7,14,21 5634 (1997 9:00 AM EST) October 28; 5635 November 4,11,18,25; 5636 December 2,9,16,23 5638 Every other week - forever: 5640 DTSTART;TZID=America/New_York:19970902T090000 5641 RRULE:FREQ=WEEKLY;INTERVAL=2;WKST=SU 5643 ==> (1997 9:00 AM EDT) September 2,16,30; 5644 October 14 5645 (1997 9:00 AM EST) October 28; 5646 November 11,25; 5647 December 9,23 5648 (1998 9:00 AM EST) January 6,20; 5649 February 3, 17 5650 ... 5652 Weekly on Tuesday and Thursday for 5 weeks: 5654 DTSTART;TZID=America/New_York:19970902T090000 5655 RRULE:FREQ=WEEKLY;UNTIL=19971007T000000Z;WKST=SU;BYDAY=TU,TH 5657 or 5659 RRULE:FREQ=WEEKLY;COUNT=10;WKST=SU;BYDAY=TU,TH 5661 ==> (1997 9:00 AM EDT) September 2,4,9,11,16,18,23,25,30; 5662 October 2 5664 Every other week on Monday, Wednesday and Friday until December 5665 24, 1997, starting on Monday, September 1, 1997: 5667 DTSTART;TZID=America/New_York:19970901T090000 5668 RRULE:FREQ=WEEKLY;INTERVAL=2;UNTIL=19971224T000000Z;WKST=SU; 5669 BYDAY=MO,WE,FR 5671 ==> (1997 9:00 AM EDT) September 1,3,5,15,17,19,29; 5672 October 1,3,13,15,17 5673 (1997 9:00 AM EST) October 27,29,31; 5674 November 10,12,14,24,26,28; 5675 December 8,10,12,22 5677 Every other week on Tuesday and Thursday, for 8 occurrences: 5679 DTSTART;TZID=America/New_York:19970902T090000 5680 RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=8;WKST=SU;BYDAY=TU,TH 5682 ==> (1997 9:00 AM EDT) September 2,4,16,18,30; 5683 October 2,14,16 5685 Monthly on the 1st Friday for ten occurrences: 5687 DTSTART;TZID=America/New_York:19970905T090000 5688 RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR 5690 ==> (1997 9:00 AM EDT) September 5;October 3 5691 (1997 9:00 AM EST) November 7;December 5 5692 (1998 9:00 AM EST) January 2;February 6;March 6;April 3 5693 (1998 9:00 AM EDT) May 1;June 5 5695 Monthly on the 1st Friday until December 24, 1997: 5697 DTSTART;TZID=America/New_York:19970905T090000 5698 RRULE:FREQ=MONTHLY;UNTIL=19971224T000000Z;BYDAY=1FR 5700 ==> (1997 9:00 AM EDT) September 5; October 3 5701 (1997 9:00 AM EST) November 7; December 5 5703 Every other month on the 1st and last Sunday of the month for 10 5704 occurrences: 5706 DTSTART;TZID=America/New_York:19970907T090000 5707 RRULE:FREQ=MONTHLY;INTERVAL=2;COUNT=10;BYDAY=1SU,-1SU 5709 ==> (1997 9:00 AM EDT) September 7,28 5710 (1997 9:00 AM EST) November 2,30 5711 (1998 9:00 AM EST) January 4,25;March 1,29 5712 (1998 9:00 AM EDT) May 3,31 5714 Monthly on the second to last Monday of the month for 6 months: 5716 DTSTART;TZID=America/New_York:19970922T090000 5717 RRULE:FREQ=MONTHLY;COUNT=6;BYDAY=-2MO 5719 ==> (1997 9:00 AM EDT) September 22;October 20 5720 (1997 9:00 AM EST) November 17;December 22 5721 (1998 9:00 AM EST) January 19;February 16 5723 Monthly on the third to the last day of the month, forever: 5725 DTSTART;TZID=America/New_York:19970928T090000 5726 RRULE:FREQ=MONTHLY;BYMONTHDAY=-3 5728 ==> (1997 9:00 AM EDT) September 28 5729 (1997 9:00 AM EST) October 29;November 28;December 29 5730 (1998 9:00 AM EST) January 29;February 26 5731 ... 5733 Monthly on the 2nd and 15th of the month for 10 occurrences: 5735 DTSTART;TZID=America/New_York:19970902T090000 5736 RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=2,15 5738 ==> (1997 9:00 AM EDT) September 2,15;October 2,15 5739 (1997 9:00 AM EST) November 2,15;December 2,15 5740 (1998 9:00 AM EST) January 2,15 5742 Monthly on the first and last day of the month for 10 occurrences: 5744 DTSTART;TZID=America/New_York:19970930T090000 5745 RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=1,-1 5747 ==> (1997 9:00 AM EDT) September 30;October 1 5748 (1997 9:00 AM EST) October 31;November 1,30;December 1,31 5749 (1998 9:00 AM EST) January 1,31;February 1 5751 Every 18 months on the 10th thru 15th of the month for 10 5752 occurrences: 5754 DTSTART;TZID=America/New_York:19970910T090000 5755 RRULE:FREQ=MONTHLY;INTERVAL=18;COUNT=10;BYMONTHDAY=10,11,12, 5756 13,14,15 5758 ==> (1997 9:00 AM EDT) September 10,11,12,13,14,15 5759 (1999 9:00 AM EST) March 10,11,12,13 5761 Every Tuesday, every other month: 5763 DTSTART;TZID=America/New_York:19970902T090000 5764 RRULE:FREQ=MONTHLY;INTERVAL=2;BYDAY=TU 5766 ==> (1997 9:00 AM EDT) September 2,9,16,23,30 5767 (1997 9:00 AM EST) November 4,11,18,25 5768 (1998 9:00 AM EST) January 6,13,20,27;March 3,10,17,24,31 5769 ... 5771 Yearly in June and July for 10 occurrences: 5773 DTSTART;TZID=America/New_York:19970610T090000 5774 RRULE:FREQ=YEARLY;COUNT=10;BYMONTH=6,7 5776 ==> (1997 9:00 AM EDT) June 10;July 10 5777 (1998 9:00 AM EDT) June 10;July 10 5778 (1999 9:00 AM EDT) June 10;July 10 5779 (2000 9:00 AM EDT) June 10;July 10 5780 (2001 9:00 AM EDT) June 10;July 10 5782 Note: Since none of the BYDAY, BYMONTHDAY or BYYEARDAY 5783 components are specified, the day is gotten from "DTSTART" 5785 Every other year on January, February, and March for 10 5786 occurrences: 5788 DTSTART;TZID=America/New_York:19970310T090000 5789 RRULE:FREQ=YEARLY;INTERVAL=2;COUNT=10;BYMONTH=1,2,3 5791 ==> (1997 9:00 AM EST) March 10 5792 (1999 9:00 AM EST) January 10;February 10;March 10 5793 (2001 9:00 AM EST) January 10;February 10;March 10 5794 (2003 9:00 AM EST) January 10;February 10;March 10 5796 Every 3rd year on the 1st, 100th and 200th day for 10 occurrences: 5798 DTSTART;TZID=America/New_York:19970101T090000 5799 RRULE:FREQ=YEARLY;INTERVAL=3;COUNT=10;BYYEARDAY=1,100,200 5801 ==> (1997 9:00 AM EST) January 1 5802 (1997 9:00 AM EDT) April 10;July 19 5803 (2000 9:00 AM EST) January 1 5804 (2000 9:00 AM EDT) April 9;July 18 5805 (2003 9:00 AM EST) January 1 5806 (2003 9:00 AM EDT) April 10;July 19 5807 (2006 9:00 AM EST) January 1 5809 Every 20th Monday of the year, forever: 5811 DTSTART;TZID=America/New_York:19970519T090000 5812 RRULE:FREQ=YEARLY;BYDAY=20MO 5814 ==> (1997 9:00 AM EDT) May 19 5815 (1998 9:00 AM EDT) May 18 5816 (1999 9:00 AM EDT) May 17 5817 ... 5819 Monday of week number 20 (where the default start of the week is 5820 Monday), forever: 5822 DTSTART;TZID=America/New_York:19970512T090000 5823 RRULE:FREQ=YEARLY;BYWEEKNO=20;BYDAY=MO 5825 ==> (1997 9:00 AM EDT) May 12 5826 (1998 9:00 AM EDT) May 11 5827 (1999 9:00 AM EDT) May 17 5828 ... 5830 Every Thursday in March, forever: 5832 DTSTART;TZID=America/New_York:19970313T090000 5833 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=TH 5835 ==> (1997 9:00 AM EST) March 13,20,27 5836 (1998 9:00 AM EST) March 5,12,19,26 5837 (1999 9:00 AM EST) March 4,11,18,25 5838 ... 5840 Every Thursday, but only during June, July, and August, forever: 5842 DTSTART;TZID=America/New_York:19970605T090000 5843 RRULE:FREQ=YEARLY;BYDAY=TH;BYMONTH=6,7,8 5845 ==> (1997 9:00 AM EDT) June 5,12,19,26;July 3,10,17,24,31; 5846 August 7,14,21,28 5847 (1998 9:00 AM EDT) June 4,11,18,25;July 2,9,16,23,30; 5848 August 6,13,20,27 5849 (1999 9:00 AM EDT) June 3,10,17,24;July 1,8,15,22,29; 5850 August 5,12,19,26 5851 ... 5853 Every Friday the 13th, forever: 5855 DTSTART;TZID=America/New_York:19970902T090000 5856 EXDATE;TZID=America/New_York:19970902T090000 5857 RRULE:FREQ=MONTHLY;BYDAY=FR;BYMONTHDAY=13 5859 ==> (1998 9:00 AM EST) February 13;March 13;November 13 5860 (1999 9:00 AM EDT) August 13 5861 (2000 9:00 AM EDT) October 13 5862 ... 5864 The first Saturday that follows the first Sunday of the month, 5865 forever: 5867 DTSTART;TZID=America/New_York:19970913T090000 5868 RRULE:FREQ=MONTHLY;BYDAY=SA;BYMONTHDAY=7,8,9,10,11,12,13 5870 ==> (1997 9:00 AM EDT) September 13;October 11 5871 (1997 9:00 AM EST) November 8;December 13 5872 (1998 9:00 AM EST) January 10;February 7;March 7 5873 (1998 9:00 AM EDT) April 11;May 9;June 13... 5874 ... 5876 Every four years, the first Tuesday after a Monday in November, 5877 forever (U.S. Presidential Election day): 5879 DTSTART;TZID=America/New_York:19961105T090000 5880 RRULE:FREQ=YEARLY;INTERVAL=4;BYMONTH=11;BYDAY=TU; 5881 BYMONTHDAY=2,3,4,5,6,7,8 5883 ==> (1996 9:00 AM EST) November 5 5884 (2000 9:00 AM EST) November 7 5885 (2004 9:00 AM EST) November 2 5886 ... 5888 The 3rd instance into the month of one of Tuesday, Wednesday or 5889 Thursday, for the next 3 months: 5891 DTSTART;TZID=America/New_York:19970904T090000 5892 RRULE:FREQ=MONTHLY;COUNT=3;BYDAY=TU,WE,TH;BYSETPOS=3 5894 ==> (1997 9:00 AM EDT) September 4;October 7 5895 (1997 9:00 AM EST) November 6 5897 The 2nd to last weekday of the month: 5899 DTSTART;TZID=America/New_York:19970929T090000 5900 RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-2 5902 ==> (1997 9:00 AM EDT) September 29 5903 (1997 9:00 AM EST) October 30;November 27;December 30 5904 (1998 9:00 AM EST) January 29;February 26;March 30 5905 ... 5907 Every 3 hours from 9:00 AM to 5:00 PM on a specific day: 5909 DTSTART;TZID=America/New_York:19970902T090000 5910 RRULE:FREQ=HOURLY;INTERVAL=3;UNTIL=19970902T170000Z 5912 ==> (September 2, 1997 EDT) 09:00,12:00,15:00 5914 Every 15 minutes for 6 occurrences: 5916 DTSTART;TZID=America/New_York:19970902T090000 5917 RRULE:FREQ=MINUTELY;INTERVAL=15;COUNT=6 5919 ==> (September 2, 1997 EDT) 09:00,09:15,09:30,09:45,10:00,10:15 5921 Every hour and a half for 4 occurrences: 5923 DTSTART;TZID=America/New_York:19970902T090000 5924 RRULE:FREQ=MINUTELY;INTERVAL=90;COUNT=4 5926 ==> (September 2, 1997 EDT) 09:00,10:30;12:00;13:30 5928 Every 20 minutes from 9:00 AM to 4:40 PM every day: 5930 DTSTART;TZID=America/New_York:19970902T090000 5931 RRULE:FREQ=DAILY;BYHOUR=9,10,11,12,13,14,15,16;BYMINUTE=0,20,40 5932 or 5933 RRULE:FREQ=MINUTELY;INTERVAL=20;BYHOUR=9,10,11,12,13,14,15,16 5935 ==> (September 2, 1997 EDT) 9:00,9:20,9:40,10:00,10:20, 5936 ... 16:00,16:20,16:40 5937 (September 3, 1997 EDT) 9:00,9:20,9:40,10:00,10:20, 5938 ...16:00,16:20,16:40 5939 ... 5941 An example where the days generated makes a difference because of 5942 WKST: 5944 DTSTART;TZID=America/New_York:19970805T090000 5945 RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=4;BYDAY=TU,SU;WKST=MO 5947 ==> (1997 EDT) August 5,10,19,24 5949 changing only WKST from MO to SU, yields different results... 5951 DTSTART;TZID=America/New_York:19970805T090000 5952 RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=4;BYDAY=TU,SU;WKST=SU 5954 ==> (1997 EDT) August 5,17,19,31 5956 An example where an invalid date (i.e., February 30) is ignored. 5958 DTSTART;TZID=America/New_York:20070115T090000 5959 RRULE:FREQ=MONTHLY;BYMONTHDAY=15,30;COUNT=5 5961 ==> (2007 EST) January 15,30 5962 (2007 EST) February 15 5963 (2007 EDT) March 15,30 5965 3.8.6. Alarm Component Properties 5967 The following properties specify alarm information in calendar 5968 components. 5970 3.8.6.1. Action 5972 Property Name: ACTION 5974 Purpose: This property defines the action to be invoked when an 5975 alarm is triggered. 5977 Value Type: TEXT 5979 Property Parameters: IANA and non-standard property parameters can 5980 be specified on this property. 5982 Conformance: This property MUST be specified once in a "VALARM" 5983 calendar component. 5985 Description: Each "VALARM" calendar component has a particular type 5986 of action associated with it. This property specifies the type of 5987 action. Applications MUST ignore alarms with x-name and iana- 5988 token value they don't recognized. 5990 Format Definition: This property is defined by the following 5991 notation: 5993 action = "ACTION" actionparam ":" actionvalue CRLF 5995 actionparam = *(";" other-param) 5997 actionvalue = "AUDIO" / "DISPLAY" / "EMAIL" 5998 / iana-token / x-name 6000 Example: The following are examples of this property in a "VALARM" 6001 calendar component: 6003 ACTION:AUDIO 6005 ACTION:DISPLAY 6007 3.8.6.2. Repeat Count 6008 Property Name: REPEAT 6010 Purpose: This property defines the number of time the alarm should 6011 be repeated, after the initial trigger. 6013 Value Type: INTEGER 6015 Property Parameters: IANA and non-standard property parameters can 6016 be specified on this property. 6018 Conformance: This property can be specified in a "VALARM" calendar 6019 component. 6021 Description: This property defines the number of time an alarm 6022 should be repeated after its initial trigger. If the alarm 6023 triggers more than once, then this property MUST be specified 6024 along with the "DURATION" property. 6026 Format Definition: This property is defined by the following 6027 notation: 6029 repeat = "REPEAT" repparam ":" integer CRLF 6030 ;Default is "0", zero. 6032 repparam = *(";" other-param) 6034 Example: The following is an example of this property for an alarm 6035 that repeats 4 additional times with a 5 minute delay after the 6036 initial triggering of the alarm: 6038 REPEAT:4 6039 DURATION:PT5M 6041 3.8.6.3. Trigger 6043 Property Name: TRIGGER 6045 Purpose: This property specifies when an alarm will trigger. 6047 Value Type: The default value type is DURATION. The value type can 6048 be set to a DATE-TIME value type, in which case the value MUST 6049 specify a UTC formatted DATE-TIME value. 6051 Property Parameters: IANA, non-standard, value data type, time zone 6052 identifier or trigger relationship property parameters can be 6053 specified on this property. The trigger relationship property 6054 parameter MUST only be specified when the value type is 6055 "DURATION". 6057 Conformance: This property MUST be specified in the "VALARM" 6058 calendar component. 6060 Description: This property defines when an alarm will trigger. The 6061 default value type is DURATION, specifying a relative time for the 6062 trigger of the alarm. The default duration is relative to the 6063 start of an event or to-do that the alarm is associated with. The 6064 duration can be explicitly set to trigger from either the end or 6065 the start of the associated event or to-do with the "RELATED" 6066 parameter. A value of START will set the alarm to trigger off the 6067 start of the associated event or to-do. A value of END will set 6068 the alarm to trigger off the end of the associated event or to-do. 6070 Either a positive or negative duration may be specified for the 6071 "TRIGGER" property. An alarm with a positive duration is 6072 triggered after the associated start or end of the event or to-do. 6073 An alarm with a negative duration is triggered before the 6074 associated start or end of the event or to-do. 6076 The "RELATED" property parameter is not valid if the value type of 6077 the property is set to DATE-TIME (i.e., for an absolute date and 6078 time alarm trigger). If a value type of DATE-TIME is specified, 6079 then the property value MUST be specified in the UTC time format. 6080 If an absolute trigger is specified on an alarm for a recurring 6081 event or to-do, then the alarm will only trigger for the specified 6082 absolute date/time, along with any specified repeating instances. 6084 If the trigger is set relative to START, then the "DTSTART" 6085 property MUST be present in the associated "VEVENT" or "VTODO" 6086 calendar component. If an alarm is specified for an event with 6087 the trigger set relative to the END, then the "DTEND" property or 6088 the "DTSTART" and "DURATION " properties MUST be present in the 6089 associated "VEVENT" calendar component. If the alarm is specified 6090 for a to-do with a trigger set relative to the END, then either 6091 the "DUE" property or the "DTSTART" and "DURATION " properties 6092 MUST be present in the associated "VTODO" calendar component. 6094 Alarms specified in an event or to-do which is defined in terms of 6095 a DATE value type will be triggered relative to 00:00:00 of the 6096 user's configured time zone on the specified date, or relative to 6097 00:00:00 UTC on the specified date if no configured time zone can 6098 be found for the user. For example, if "DTSTART" is a DATE value 6099 set to 19980205 then the duration trigger will be relative to 6100 19980205T000000 America/New_York for a user configured with the 6101 America/New_York time zone. 6103 Format Definition: This property is defined by the following 6104 notation: 6106 trigger = "TRIGGER" (trigrel / trigabs) CRLF 6108 trigrel = *( 6110 ; the following are OPTIONAL, 6111 ; but MUST NOT occur more than once 6113 (";" "VALUE" "=" "DURATION") / 6114 (";" trigrelparam) / 6116 ; the following is OPTIONAL, 6117 ; and MAY occur more than once 6119 (";" other-param) 6120 ) ":" dur-value 6122 trigabs = *( 6124 ; the following is REQUIRED, 6125 ; but MUST NOT occur more than once 6127 (";" "VALUE" "=" "DATE-TIME") / 6129 ; the following is OPTIONAL, 6130 ; and MAY occur more than once 6132 (";" other-param) 6134 ) ":" date-time 6136 Example: A trigger set 15 minutes prior to the start of the event or 6137 to-do. 6139 TRIGGER:-PT15M 6141 A trigger set 5 minutes after the end of an event or the due date 6142 of a to-do. 6144 TRIGGER;RELATED=END:PT5M 6146 A trigger set to an absolute date/time. 6148 TRIGGER;VALUE=DATE-TIME:19980101T050000Z 6150 3.8.7. Change Management Component Properties 6152 The following properties specify change management information in 6153 calendar components. 6155 3.8.7.1. Date/Time Created 6157 Property Name: CREATED 6159 Purpose: This property specifies the date and time that the calendar 6160 information was created by the calendar user agent in the calendar 6161 store. 6163 Note: This is analogous to the creation date and time for a 6164 file in the file system. 6166 Value Type: DATE-TIME 6168 Property Parameters: IANA and non-standard property parameters can 6169 be specified on this property. 6171 Conformance: The property can be specified once in "VEVENT", "VTODO" 6172 or "VJOURNAL" calendar components. The value MUST be specified as 6173 a date with UTC time. 6175 Description: This property specifies the date and time that the 6176 calendar information was created by the calendar user agent in the 6177 calendar store. 6179 Format Definition: This property is defined by the following 6180 notation: 6182 created = "CREATED" creaparam ":" date-time CRLF 6184 creaparam = *(";" other-param) 6186 Example: The following is an example of this property: 6188 CREATED:19960329T133000Z 6190 3.8.7.2. Date/Time Stamp 6192 Property Name: DTSTAMP 6194 Purpose: In the case of an iCalendar object that specifies a 6195 "METHOD" property, this property specifies the date and time that 6196 the instance of the iCalendar object was created. In the case of 6197 an iCalendar object that doesn't specify a "METHOD" property, this 6198 property specifies the date and time that the information 6199 associated with the calendar component was last revised in the 6200 calendar store. 6202 Value Type: DATE-TIME 6204 Property Parameters: IANA and non-standard property parameters can 6205 be specified on this property. 6207 Conformance: This property MUST be included in the "VEVENT", 6208 "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components. 6210 Description: The value MUST be specified in the UTC time format. 6212 This property is also useful to protocols such as 6213 [I-D.ietf-calsify-rfc2447bis] that have inherent latency issues 6214 with the delivery of content. This property will assist in the 6215 proper sequencing of messages containing iCalendar objects. 6217 In the case of an iCalendar object that specifies a "METHOD" 6218 property, this property is different than the "CREATED" and "LAST- 6219 MODIFIED" properties. These two properties are used to specify 6220 when the particular calendar data in the calendar store was 6221 created and last modified. This is different than when the 6222 iCalendar object representation of the calendar service 6223 information was created or last modified. 6225 In the case of an iCalendar object that doesn't specify a "METHOD" 6226 property, this property is equivalent to the "LAST-MODIFIED" 6227 property. 6229 Format Definition: This property is defined by the following 6230 notation: 6232 dtstamp = "DTSTAMP" stmparam ":" date-time CRLF 6234 stmparam = *(";" other-param) 6236 Example: 6238 DTSTAMP:19971210T080000Z 6240 3.8.7.3. Last Modified 6241 Property Name: LAST-MODIFIED 6243 Purpose: This property specifies the date and time that the 6244 information associated with the calendar component was last 6245 revised in the calendar store. 6247 Note: This is analogous to the modification date and time for a 6248 file in the file system. 6250 Value Type: DATE-TIME 6252 Property Parameters: IANA and non-standard property parameters can 6253 be specified on this property. 6255 Conformance: This property can be specified in the "VEVENT", 6256 "VTODO", "VJOURNAL" or "VTIMEZONE" calendar components. 6258 Description: The property value MUST be specified in the UTC time 6259 format. 6261 Format Definition: This property is defined by the following 6262 notation: 6264 last-mod = "LAST-MODIFIED" lstparam ":" date-time CRLF 6266 lstparam = *(";" other-param) 6268 Example: The following is an example of this property: 6270 LAST-MODIFIED:19960817T133000Z 6272 3.8.7.4. Sequence Number 6274 Property Name: SEQUENCE 6276 Purpose: This property defines the revision sequence number of the 6277 calendar component within a sequence of revisions. 6279 Value Type: INTEGER 6281 Property Parameters: IANA and non-standard property parameters can 6282 be specified on this property. 6284 Conformance: The property can be specified in "VEVENT", "VTODO" or 6285 "VJOURNAL" calendar component. 6287 Description: When a calendar component is created, its sequence 6288 number is zero (US-ASCII decimal 48). It is monotonically 6289 incremented by the "Organizer's" CUA each time the "Organizer" 6290 makes a significant revision to the calendar component. When the 6291 "Organizer" makes changes to one of the following properties, the 6292 sequence number MUST be incremented: 6294 * "DTSTART" 6296 * "DTEND" 6298 * "DURATION" 6300 * "DUE" 6302 * "RDATE" 6304 * "RRULE" 6306 * "EXDATE" 6308 * "STATUS" 6310 In addition, changes made by the "Organizer" to other properties 6311 can also force the sequence number to be incremented. The 6312 "Organizer" CUA MUST increment the sequence number whenever it 6313 makes changes to properties in the calendar component that the 6314 "Organizer" deems will jeopardize the validity of the 6315 participation status of the "Attendees". For example, changing 6316 the location of a meeting from one locale to another distant 6317 locale could effectively impact the participation status of the 6318 "Attendees". 6320 The "Organizer" includes this property in an iCalendar object that 6321 it sends to an "Attendee" to specify the current version of the 6322 calendar component. 6324 The "Attendee" includes this property in an iCalendar object that 6325 it sends to the "Organizer" to specify the version of the calendar 6326 component that the "Attendee" is referring to. 6328 A change to the sequence number is not the mechanism that an 6329 "Organizer" uses to request a response from the "Attendees". The 6330 "RSVP" parameter on the "ATTENDEE" property is used by the 6331 "Organizer" to indicate that a response from the "Attendees" is 6332 requested. 6334 Format Definition: This property is defined by the following 6335 notation: 6337 seq = "SEQUENCE" seqparam ":" integer CRLF 6338 ; Default is "0" 6340 seqparam = *(";" other-param) 6342 Example: The following is an example of this property for a calendar 6343 component that was just created by the "Organizer": 6345 SEQUENCE:0 6347 The following is an example of this property for a calendar 6348 component that has been revised two different times by the 6349 "Organizer": 6351 SEQUENCE:2 6353 3.8.8. Miscellaneous Component Properties 6355 The following properties specify information about a number of 6356 miscellaneous features of calendar components. 6358 3.8.8.1. IANA Properties 6360 Property Name: An IANA registered property name 6362 Value Type: The default value type is TEXT. The value type can be 6363 set to any value type. 6365 Property Parameters: Any parameter can be specified on this 6366 property. 6368 Description: This specification allows other properties registered 6369 with IANA to be specified in any calendar components. Compliant 6370 applications are expected to be able to parse these other IANA 6371 registered properties but can ignore them. 6373 Format Definition: This property is defined by the following 6374 notation: 6376 iana-prop = iana-token *(";" icalparameter) ":" value CRLF 6378 Example: The following are examples of properties that might be 6379 registered to IANA: 6381 DRESSCODE:CASUAL 6383 NON-SMOKING;VALUE=BOOLEAN:TRUE 6385 3.8.8.2. Non-standard Properties 6387 Property Name: Any property name with a "X-" prefix 6389 Purpose: This class of property provides a framework for defining 6390 non-standard properties. 6392 Value Type: The default value type is TEXT. The value type can be 6393 set to any value type. 6395 Property Parameters: IANA, non-standard and language property 6396 parameters can be specified on this property. 6398 Conformance: This property can be specified in any calendar 6399 component. 6401 Description: The MIME Calendaring and Scheduling Content Type 6402 provides a "standard mechanism for doing non-standard things". 6403 This extension support is provided for implementers to "push the 6404 envelope" on the existing version of the memo. Extension 6405 properties are specified by property and/or property parameter 6406 names that have the prefix text of "X-" (the two character 6407 sequence: LATIN CAPITAL LETTER X character followed by the HYPHEN- 6408 MINUS character). It is recommended that vendors concatenate onto 6409 this sentinel another short prefix text to identify the vendor. 6410 This will facilitate readability of the extensions and minimize 6411 possible collision of names between different vendors. User 6412 agents that support this content type are expected to be able to 6413 parse the extension properties and property parameters but can 6414 ignore them. 6416 At present, there is no registration authority for names of 6417 extension properties and property parameters. The value type for 6418 this property is TEXT. Optionally, the value type can be any of 6419 the other valid value types. 6421 Format Definition: This property is defined by the following 6422 notation: 6424 x-prop = x-name *(";" icalparameter) ":" value CRLF 6426 Example: The following might be the ABC vendor's extension for an 6427 audio-clip form of subject property: 6429 X-ABC-MMSUBJ;VALUE=URI;FMTTYPE=audio/basic:http://www.example. 6430 org/mysubj.au 6432 3.8.8.3. Request Status 6434 Property Name: REQUEST-STATUS 6436 Purpose: This property defines the status code returned for a 6437 scheduling request. 6439 Value Type: TEXT 6441 Property Parameters: IANA, non-standard and language property 6442 parameters can be specified on this property. 6444 Conformance: The property can be specified in "VEVENT", "VTODO", 6445 "VJOURNAL" or "VFREEBUSY" calendar component. 6447 Description: This property is used to return status code information 6448 related to the processing of an associated iCalendar object. The 6449 value type for this property is TEXT. 6451 The value consists of a short return status component, a longer 6452 return status description component, and optionally a status- 6453 specific data component. The components of the value are 6454 separated by the SEMICOLON character (US-ASCII decimal 59). 6456 The short return status is a PERIOD character (US-ASCII decimal 6457 46) separated pair or 3-tuple of integers. For example, "3.1" or 6458 "3.1.1". The successive levels of integers provide for a 6459 successive level of status code granularity. 6461 The following are initial classes for the return status code. 6462 Individual iCalendar object methods will define specific return 6463 status codes for these classes. In addition, other classes for 6464 the return status code may be defined using the registration 6465 process defined later in this memo. 6467 |==============+===============================================| 6468 | Short Return | Longer Return Status Description | 6469 | Status Code | | 6470 |==============+===============================================| 6471 | 1.xx | Preliminary success. This class of status | 6472 | | of status code indicates that the request has | 6473 | | request has been initially processed but that | 6474 | | completion is pending. | 6475 |==============+===============================================| 6476 | 2.xx | Successful. This class of status code | 6477 | | indicates that the request was completed | 6478 | | successfuly. However, the exact status code | 6479 | | can indicate that a fallback has been taken. | 6480 |==============+===============================================| 6481 | 3.xx | Client Error. This class of status code | 6482 | | indicates that the request was not successful.| 6483 | | The error is the result of either a syntax or | 6484 | | a semantic error in the client formatted | 6485 | | request. Request should not be retried until | 6486 | | the condition in the request is corrected. | 6487 |==============+===============================================| 6488 | 4.xx | Scheduling Error. This class of status code | 6489 | | indicates that the request was not successful.| 6490 | | Some sort of error occurred within the | 6491 | | calendaring and scheduling service, not | 6492 | | directly related to the request itself. | 6493 |==============+===============================================| 6495 Format Definition: This property is defined by the following 6496 notation: 6498 rstatus = "REQUEST-STATUS" rstatparam ":" 6499 statcode ";" statdesc [";" extdata] 6501 rstatparam = *( 6503 ; the following is OPTIONAL, 6504 ; but MUST NOT occur more than once 6506 (";" languageparam) / 6508 ; the following is OPTIONAL, 6509 ; and MAY occur more than once 6511 (";" other-param) 6513 ) 6515 statcode = 1*DIGIT 1*2("." 1*DIGIT) 6516 ;Hierarchical, numeric return status code 6518 statdesc = text 6519 ;Textual status description 6521 extdata = text 6522 ;Textual exception data. For example, the offending property 6523 ;name and value or complete property line. 6525 Example: The following are some possible examples of this property. 6527 The COMMA and SEMICOLON separator characters in the property value 6528 are BACKSLASH character escaped because they appear in a text 6529 value. 6531 REQUEST-STATUS:2.0;Success 6533 REQUEST-STATUS:3.1;Invalid property value;DTSTART:96-Apr-01 6535 REQUEST-STATUS:2.8; Success\, repeating event ignored. Scheduled 6536 as a single event.;RRULE:FREQ=WEEKLY\;INTERVAL=2 6538 REQUEST-STATUS:4.1;Event conflict. Date/time is busy. 6540 REQUEST-STATUS:3.7;Invalid calendar user;ATTENDEE: 6541 mailto:jsmith@example.com 6543 4. iCalendar Object Examples 6545 The following examples are provided as an informational source of 6546 illustrative iCalendar objects consistent with this content type. 6548 The following example specifies a three-day conference that begins at 6549 2:30 P.M. UTC, September 18, 1996 and end at 10:00 P.M. UTC, 6550 September 20, 1996. 6552 BEGIN:VCALENDAR 6553 PRODID:-//xyz Corp//NONSGML PDA Calendar Version 1.0//EN 6554 VERSION:2.0 6555 BEGIN:VEVENT 6556 DTSTAMP:19960704T120000Z 6557 UID:uid1@example.com 6558 ORGANIZER:mailto:jsmith@example.com 6559 DTSTART:19960918T143000Z 6560 DTEND:19960920T220000Z 6561 STATUS:CONFIRMED 6562 CATEGORIES:CONFERENCE 6563 SUMMARY:Networld+Interop Conference 6564 DESCRIPTION:Networld+Interop Conference 6565 and Exhibit\nAtlanta World Congress Center\n 6566 Atlanta\, Georgia 6567 END:VEVENT 6568 END:VCALENDAR 6570 The following example specifies a group scheduled meeting that begin 6571 at 8:30 AM EST on March 12, 1998 and end at 9:30 AM EST on March 12, 6572 1998. The "Organizer" has scheduled the meeting with one or more 6573 calendar users in a group. A time zone specification for Eastern 6574 United States has been specified. 6576 BEGIN:VCALENDAR 6577 PRODID:-//RDU Software//NONSGML HandCal//EN 6578 VERSION:2.0 6579 BEGIN:VTIMEZONE 6580 TZID:America/New_York 6581 BEGIN:STANDARD 6582 DTSTART:19981025T020000 6583 TZOFFSETFROM:-0400 6584 TZOFFSETTO:-0500 6585 TZNAME:EST 6586 END:STANDARD 6587 BEGIN:DAYLIGHT 6588 DTSTART:19990404T020000 6589 TZOFFSETFROM:-0500 6590 TZOFFSETTO:-0400 6591 TZNAME:EDT 6592 END:DAYLIGHT 6593 END:VTIMEZONE 6594 BEGIN:VEVENT 6595 DTSTAMP:19980309T231000Z 6596 UID:guid-1.example.com 6597 ORGANIZER;ROLE=CHAIR:mailto:mrbig@example.com 6598 ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;CUTYPE=GROUP: 6599 mailto:employee-A@example.com 6600 DESCRIPTION:Project XYZ Review Meeting 6601 CATEGORIES:MEETING 6602 CLASS:PUBLIC 6603 CREATED:19980309T130000Z 6604 SUMMARY:XYZ Project Review 6605 DTSTART;TZID=America/New_York:19980312T083000 6606 DTEND;TZID=America/New_York:19980312T093000 6607 LOCATION:1CP Conference Room 4350 6608 END:VEVENT 6609 END:VCALENDAR 6611 The following is an example of an iCalendar object passed in a MIME 6612 message with a single body part consisting of a "text/calendar" 6613 Content Type. 6615 TO:jsmith@example.com 6616 FROM:jdoe@example.com 6617 MIME-VERSION:1.0 6618 MESSAGE-ID: 6619 CONTENT-TYPE:text/calendar; method="xyz"; component="VEVENT" 6621 BEGIN:VCALENDAR 6622 METHOD:xyz 6623 VERSION:2.0 6624 PRODID:-//ABC Corporation//NONSGML My Product//EN 6625 BEGIN:VEVENT 6626 DTSTAMP:19970324T120000Z 6627 SEQUENCE:0 6628 UID:uid3@example.com 6629 ORGANIZER:mailto:jdoe@example.com 6630 ATTENDEE;RSVP=TRUE:mailto:jsmith@example.com 6631 DTSTART:19970324T123000Z 6632 DTEND:19970324T210000Z 6633 CATEGORIES:MEETING,PROJECT 6634 CLASS:PUBLIC 6635 SUMMARY:Calendaring Interoperability Planning Meeting 6636 DESCRIPTION:Discuss how we can test c&s interoperability\n 6637 using iCalendar and other IETF standards. 6638 LOCATION:LDB Lobby 6639 ATTACH;FMTTYPE=application/postscript:ftp://example.com/pub/ 6640 conf/bkgrnd.ps 6641 END:VEVENT 6642 END:VCALENDAR 6644 The following is an example of a to-do due on April 15, 1998. An 6645 audio alarm has been specified to remind the calendar user at noon, 6646 the day before the to-do is expected to be completed and repeat 6647 hourly, four additional times. The to-do definition has been 6648 modified twice since it was initially created. 6650 BEGIN:VCALENDAR 6651 VERSION:2.0 6652 PRODID:-//ABC Corporation//NONSGML My Product//EN 6653 BEGIN:VTODO 6654 DTSTAMP:19980130T134500Z 6655 SEQUENCE:2 6656 UID:uid4@example.com 6657 ORGANIZER:mailto:unclesam@example.com 6658 ATTENDEE;PARTSTAT=ACCEPTED:mailto:jqpublic@example.com 6659 DUE:19980415T000000 6660 STATUS:NEEDS-ACTION 6661 SUMMARY:Submit Income Taxes 6662 BEGIN:VALARM 6663 ACTION:AUDIO 6664 TRIGGER:19980403T120000Z 6665 ATTACH;FMTTYPE=audio/basic:http://example.com/pub/audio- 6666 files/ssbanner.aud 6667 REPEAT:4 6668 DURATION:PT1H 6669 END:VALARM 6670 END:VTODO 6671 END:VCALENDAR 6673 The following is an example of a journal entry. 6675 BEGIN:VCALENDAR 6676 VERSION:2.0 6677 PRODID:-//ABC Corporation//NONSGML My Product//EN 6678 BEGIN:VJOURNAL 6679 DTSTAMP:19970324T120000Z 6680 UID:uid5@example.com 6681 ORGANIZER:mailto:jsmith@example.com 6682 STATUS:DRAFT 6683 CLASS:PUBLIC 6684 CATEGORIES:Project Report,XYZ,Weekly Meeting 6685 DESCRIPTION:Project xyz Review Meeting Minutes\n 6686 Agenda\n1. Review of project version 1.0 requirements.\n2. 6687 Definition 6688 of project processes.\n3. Review of project schedule.\n 6689 Participants: John Smith\, Jane Doe\, Jim Dandy\n-It was 6690 decided that the requirements need to be signed off by 6691 product marketing.\n-Project processes were accepted.\n 6692 -Project schedule needs to account for scheduled holidays 6693 and employee vacation time. Check with HR for specific 6694 dates.\n-New schedule will be distributed by Friday.\n- 6695 Next weeks meeting is cancelled. No meeting until 3/23. 6696 END:VJOURNAL 6697 END:VCALENDAR 6699 The following is an example of published busy time information. The 6700 iCalendar object might be placed in the network resource 6701 http://www.example.com/calendar/busytime/jsmith.ifb. 6703 BEGIN:VCALENDAR 6704 VERSION:2.0 6705 PRODID:-//RDU Software//NONSGML HandCal//EN 6706 BEGIN:VFREEBUSY 6707 ORGANIZER:mailto:jsmith@example.com 6708 DTSTART:19980313T141711Z 6709 DTEND:19980410T141711Z 6710 FREEBUSY:19980314T233000Z/19980315T003000Z 6711 FREEBUSY:19980316T153000Z/19980316T163000Z 6712 FREEBUSY:19980318T030000Z/19980318T040000Z 6713 URL:http://www.example.com/calendar/busytime/jsmith.ifb 6714 END:VFREEBUSY 6715 END:VCALENDAR 6717 5. Recommended Practices 6719 These recommended practices should be followed in order to assure 6720 consistent handling of the following cases for an iCalendar object. 6722 1. Content lines longer than 75 octets SHOULD be folded. 6724 2. 6726 3. When the combination of the "RRULE" and "RDATE" properties in a 6727 recurring component produces multiple instances having the same 6728 start DATE-TIME value, they should be collapsed to, and 6729 considered as, a single instance. If the "RDATE" property is 6730 specified as a PERIOD value the duration of the recurrence 6731 instance will be the one specified by the "RDATE" property, and 6732 not the duration of the recurrence instance defined by the 6733 "DTSTART" property. 6735 4. When a calendar user receives multiple requests for the same 6736 calendar component (e.g., REQUEST for a "VEVENT" calendar 6737 component) as a result of being on multiple mailing lists 6738 specified by "ATTENDEE" properties in the request, they SHOULD 6739 respond to only one of the requests. The calendar user SHOULD 6740 also specify (using the "MEMBER" parameter of the "ATTENDEE" 6741 property) which mailing list they are a member of. 6743 5. An implementation can truncate a "SUMMARY" property value to 255 6744 octets, but MUST NOT truncate the value in the middle of a UTF-8 6745 multi-octet sequence. 6747 6. If seconds of the minute are not supported by an implementation, 6748 then a value of "00" SHOULD be specified for the seconds 6749 component in a time value. 6751 7. 6753 8. "TZURL" values SHOULD NOT be specified as a file URI type. This 6754 URI form can be useful within an organization, but is 6755 problematic in the Internet. 6757 9. Some possible English values for "CATEGORIES" property include 6758 "ANNIVERSARY", "APPOINTMENT", "BUSINESS", "EDUCATION", 6759 "HOLIDAY", "MEETING", "MISCELLANEOUS", "NON-WORKING HOURS", "NOT 6760 IN OFFICE", "PERSONAL", "PHONE CALL", "SICK DAY", "SPECIAL 6761 OCCASION", "TRAVEL", "VACATION". Categories can be specified in 6762 any registered language. 6764 10. Some possible English values for "RESOURCES" property include 6765 "CATERING", "CHAIRS", "COMPUTER PROJECTOR", "EASEL", "OVERHEAD 6766 PROJECTOR", "SPEAKER PHONE", "TABLE", "TV", "VCR", "VIDEO 6767 PHONE", "VEHICLE". Resources can be specified in any registered 6768 language. 6770 6. Internationalization Considerations 6772 Applications MUST generate iCalendar stream in the UTF-8 charset and 6773 MUST accept iCalendar stream in the UTF-8 or US-ASCII charset. 6775 7. Security Considerations 6777 Because calendaring and scheduling information is very privacy- 6778 sensitive, the protocol used for the transmission of calendaring and 6779 scheduling information should have capabilities to protect the 6780 information from possible threats, such as eavesdropping, replay, 6781 message insertion, deletion, modification and man-in-the-middle 6782 attacks. 6784 As this document only defines the data format and media type of text/ 6785 calendar that is independent of any calendar service or protocol, it 6786 is up to the actual protocol specifications such as iTIP 6787 [I-D.ietf-calsify-2446bis], iMIP [I-D.ietf-calsify-rfc2447bis], and 6788 CalDAV [RFC4791] to describe the threats that the above attacks 6789 present, as well as ways in which to mitigate them. 6791 8. IANA Considerations 6792 8.1. iCalendar Media Type Registration 6794 The Calendaring and Scheduling Core Object Specification is intended 6795 for use as a MIME content type. However, the implementation of the 6796 memo is in no way limited solely as a MIME content type. 6798 To: ietf-types@iana.org 6799 Subject: Registration of media type text/calendar 6801 Type name: text 6803 Subtype name: calendar 6805 Required parameters: none 6807 Optional parameters: charset, method, component and optinfo 6809 The "charset" parameter is defined in [RFC2046] for subtypes of 6810 the "text" media type. It is used to indicate the charset used in 6811 the body part. The charset supported by this revision of 6812 iCalendar is UTF-8. The use of any other charset is deprecated by 6813 this revision of iCalendar; however note that this revision 6814 requires that compliant applications MUST accept iCalendar streams 6815 using either the UTF-8 or US-ASCII charset. 6817 The "method" parameter is used to convey the iCalendar object 6818 method or transaction semantics for the calendaring and scheduling 6819 information. It also is an identifier for the restricted set of 6820 properties and values that the iCalendar object consists of. The 6821 parameter is to be used as a guide for applications interpreting 6822 the information contained within the body part. It SHOULD NOT be 6823 used to exclude or require particular pieces of information unless 6824 the identified method definition specifically calls for this 6825 behavior. Unless specifically forbidden by a particular method 6826 definition, a text/calendar content type can contain any set of 6827 properties permitted by the Calendaring and Scheduling Core Object 6828 Specification. The "method" parameter MUST be specified and MUST 6829 be set to the same value as the "METHOD" component property of the 6830 iCalendar objects of the iCalendar stream if and only if the 6831 iCalendar objects in the iCalendar stream all have a "METHOD" 6832 component property set to the same value. 6834 The value for the "method" parameter is defined as follows: 6836 method = 1*(ALPHA / DIGIT / "-") 6837 ; IANA registered iCalendar object method 6839 The "component" parameter conveys the type of iCalendar calendar 6840 component within the body part. If the iCalendar object contains 6841 more than one calendar component type, then multiple component 6842 parameters MUST be specified. 6844 The value for the "component" parameter is defined as follows: 6846 component = "VEVENT" 6847 / "VTODO" 6848 / "VJOURNAL" 6849 / "VFREEBUSY" 6850 / "VTIMEZONE" 6851 / iana-token 6852 / x-name 6854 The "optinfo" parameter conveys optional information about the 6855 iCalendar object within the body part. This parameter can only 6856 specify semantics already specified by the iCalendar object and 6857 that can be otherwise determined by parsing the body part. In 6858 addition, the optional information specified by this parameter 6859 MUST be consistent with that information specified by the 6860 iCalendar object. For example, it can be used to convey the 6861 "Attendee" response status to a meeting request. The parameter 6862 value consists of a string value. 6864 The parameter can be specified multiple times. 6866 The value for the "optinfo" parameter is defined as follows: 6868 optinfo = infovalue / qinfovalue 6870 infovalue = iana-token / x-name 6872 qinfovalue = DQUOTE (infovalue) DQUOTE 6874 Encoding considerations: This media type can contain 8bit 6875 characters, so the use of quoted-printable or base64 MIME Content- 6876 Transfer-Encodings might be necessary when iCalendar objects are 6877 transferred across protocols restricted to the 7bit repertoire. 6878 Note that a text valued property in the content entity can also 6879 have content encoding of special characters using a BACKSLASH 6880 character (US-ASCII decimal 92) escapement technique. This means 6881 that content values can end up encoded twice. 6883 Security considerations: See Section 7. 6885 Interoperability considerations: This media type is intended to 6886 define a common format for conveying calendaring and scheduling 6887 information between different systems. It is heavily based on the 6888 earlier [VCAL] industry specification. 6890 Published specification: This specification. 6892 Applications which use this media type: This media type is designed 6893 for widespread use by Internet calendaring and scheduling 6894 applications. In addition, applications in the workflow and 6895 document management area might find this content-type applicable. 6896 The iTIP [I-D.ietf-calsify-2446bis], iMIP 6897 [I-D.ietf-calsify-rfc2447bis] and CalDAV [RFC4791] Internet 6898 protocols directly use this media type also. 6900 Additional information: 6902 Magic number(s): None. 6904 File extension(s): The file extension of "ics" is to be used to 6905 designate a file containing (an arbitrary set of) calendaring 6906 and scheduling information consistent with this MIME content 6907 type. 6909 The file extension of "ifb" is to be used to designate a file 6910 containing free or busy time information consistent with this 6911 MIME content type. 6913 Macintosh file type code(s): The file type code of "iCal" is to 6914 be used in Apple MacIntosh operating system environments to 6915 designate a file containing calendaring and scheduling 6916 information consistent with this MIME media type. 6918 The file type code of "iFBf" is to be used in Apple MacIntosh 6919 operating system environments to designate a file containing 6920 free or busy time information consistent with this MIME media 6921 type. 6923 Person & email address to contact for further information: See the 6924 "Author's Address" section of this document. 6926 Intended usage: COMMON 6928 Restrictions on usage: There are no restrictions on where this media 6929 type can be used. 6931 Author: See the "Author's Address" section of this document. 6933 Change controller: IETF 6935 8.2. New iCalendar Elements Registration 6937 This section defines the process to register new or modified 6938 iCalendar elements, that is, components, properties, parameters, 6939 value data types, and values, with IANA. 6941 8.2.1. iCalendar Elements Registration Procedure 6943 The IETF will create a mailing list, icalendar@ietf.org [2], which 6944 can be used for public discussion of iCalendar elements proposals 6945 prior to registration. Use of the mailing list is strongly 6946 encouraged. The IESG will appoint a designated expert who will 6947 monitor the icalendar@ietf.org [2] mailing list and review 6948 registrations. 6950 Registration of new iCalendar elements MUST be reviewed by the 6951 designated expert and published in an RFC. A Standard Tracks RFC is 6952 REQUIRED for the regisration of new value data types that modify 6953 existing properties, as well as for the registration of participation 6954 statuses values to be used in "VEVENT" calendar components. A 6955 Standard Tracks RFC is also REQUIRED for registration of iCalendar 6956 elements that modify iCalendar elements previously documented in a 6957 Standard Tracks RFC. 6959 The registration procedure begins when a completed registration 6960 template, defined in the sections below, is sent to 6961 icalendar@ietf.org [2] and iana@iana.org [3]. The designated expert 6962 is expected to tell IANA and the submitter of the registration within 6963 two weeks whether the registration is approved, approved with minor 6964 changes, or rejected with cause. When a registration is rejected 6965 with cause, it can be re-submitted if the concerns listed in the 6966 cause are addressed. Decisions made by the designated expert can be 6967 appealed to the IESG Applications Area Director, then to the IESG. 6968 They follow the normal appeals procedure for IESG decisions. 6970 8.2.2. Registration Template for Components 6972 A component is defined by completing the following template. 6974 Component name: The name of the component. 6976 Purpose: The purpose of the component. Give a short but clear 6977 description. 6979 Format definition: The ABNF for the component definition needs to 6980 be specified. 6982 Description: Any special notes about the component, how it is to 6983 be used, etc. 6985 Example(s): One or more examples of instances of the component 6986 needs to be specified. 6988 8.2.3. Registration Template for Properties 6990 A property is defined by completing the following template. 6992 Property name: The name of the property. 6994 Purpose: The purpose of the property. Give a short but clear 6995 description. 6997 Value type: Any of the valid value types for the property value 6998 needs to be specified. The default value type also needs to be 6999 specified. 7001 Property parameters: Any of the valid property parameters for the 7002 property MUST be specified. 7004 Conformance: The calendar components that the property can appear 7005 in MUST be specified. 7007 Description: Any special notes about the property, how it is to 7008 be used, etc. 7010 Format definition: The ABNF for the property definition needs to 7011 be specified. 7013 Example(s): One or more examples of instances of the property 7014 needs to be specified. 7016 8.2.4. Registration Template for Parameters 7018 A parameter is defined by completing the following template. 7020 Parameter name: The name of the parameter. 7022 Purpose: The purpose of the parameter. Give a short but clear 7023 description. 7025 Format definition: The ABNF for the parameter definition needs to 7026 be specified. 7028 Description: Any special notes about the parameter, how it is to 7029 be used, etc. 7031 Example(s): One or more examples of instances of the parameter 7032 needs to be specified. 7034 8.2.5. Registration Template for Value Data Types 7036 A value data type is defined by completing the following template. 7038 Value name: The name of the value type. 7040 Purpose: The purpose of the value type. Give a short but clear 7041 description. 7043 Format definition: The ABNF for the value type definition needs 7044 to be specified. 7046 Description: Any special notes about the value type, how it is to 7047 be used, etc. 7049 Example(s): One or more examples of instances of the value type 7050 needs to be specified. 7052 8.2.6. Registration Template for Values 7054 A value is defined by completing the following template. 7056 Value: The value literal. 7058 Purpose: The purpose of the value. Give a short but clear 7059 description. 7061 Conformance: The calendar properties and/or parameters that can 7062 take this value needs to be specified. 7064 Example(s): One or more examples of instances of the value needs 7065 to be specified. 7067 The following is a fictitious example of a registration of an 7068 iCalendar value: 7070 Value: TOP-SECRET 7072 Purpose: This value is used to specify the access classification 7073 of top-secret calendar components. 7075 Conformance: This value can be used with the "CLASS" property. 7077 Example(s): The following is an example of this value used with 7078 the "CLASS" property: 7080 CLASS:TOP-SECRET 7082 8.3. Initial iCalendar Elements Registries 7084 The IANA is requested to create and maintain the following registries 7085 for iCalendar elements with pointers to appropriate reference 7086 documents. 7088 8.3.1. Components Registry 7090 The following table is to be used to initialize the components 7091 registry. 7093 +-----------+---------+------------------------+ 7094 | Component | Status | Reference | 7095 +-----------+---------+------------------------+ 7096 | VCALENDAR | Current | RFCXXXX, Section 3.4 | 7097 | VEVENT | Current | RFCXXXX, Section 3.6.1 | 7098 | VTODO | Current | RFCXXXX, Section 3.6.2 | 7099 | VJOURNAL | Current | RFCXXXX, Section 3.6.3 | 7100 | VFREEBUSY | Current | RFCXXXX, Section 3.6.4 | 7101 | VTIMEZONE | Current | RFCXXXX, Section 3.6.5 | 7102 | VALARM | Current | RFCXXXX, Section 3.6.6 | 7103 | STANDARD | Current | RFCXXXX, Section 3.6.5 | 7104 | DAYLIGHT | Current | RFCXXXX, Section 3.6.5 | 7105 +-----------+---------+------------------------+ 7107 8.3.2. Properties Registry 7109 The following table is to be used to initialize the properties 7110 registry. 7112 +------------------+------------+---------------------------+ 7113 | Property | Status | Reference | 7114 +------------------+------------+---------------------------+ 7115 | CALSCALE | Current | RFCXXXX, Section 3.7.1 | 7116 | METHOD | Current | RFCXXXX, Section 3.7.2 | 7117 | PRODID | Current | RFCXXXX, Section 3.7.3 | 7118 | VERSION | Current | RFCXXXX, Section 3.7.4 | 7119 | ATTACH | Current | RFCXXXX, Section 3.8.1.1 | 7120 | CATEGORIES | Current | RFCXXXX, Section 3.8.1.2 | 7121 | CLASS | Current | RFCXXXX, Section 3.8.1.3 | 7122 | COMMENT | Current | RFCXXXX, Section 3.8.1.4 | 7123 | DESCRIPTION | Current | RFCXXXX, Section 3.8.1.5 | 7124 | GEO | Current | RFCXXXX, Section 3.8.1.6 | 7125 | LOCATION | Current | RFCXXXX, Section 3.8.1.7 | 7126 | PERCENT-COMPLETE | Current | RFCXXXX, Section 3.8.1.8 | 7127 | PRIORITY | Current | RFCXXXX, Section 3.8.1.9 | 7128 | RESOURCES | Current | RFCXXXX, Section 3.8.1.10 | 7129 | STATUS | Current | RFCXXXX, Section 3.8.1.11 | 7130 | SUMMARY | Current | RFCXXXX, Section 3.8.1.12 | 7131 | COMPLETED | Current | RFCXXXX, Section 3.8.2.1 | 7132 | DTEND | Current | RFCXXXX, Section 3.8.2.2 | 7133 | DUE | Current | RFCXXXX, Section 3.8.2.3 | 7134 | DTSTART | Current | RFCXXXX, Section 3.8.2.4 | 7135 | DURATION | Current | RFCXXXX, Section 3.8.2.5 | 7136 | FREEBUSY | Current | RFCXXXX, Section 3.8.2.6 | 7137 | TRANSP | Current | RFCXXXX, Section 3.8.2.7 | 7138 | TZID | Current | RFCXXXX, Section 3.8.3.1 | 7139 | TZNAME | Current | RFCXXXX, Section 3.8.3.2 | 7140 | TZOFFSETFROM | Current | RFCXXXX, Section 3.8.3.3 | 7141 | TZOFFSETTO | Current | RFCXXXX, Section 3.8.3.4 | 7142 | TZURL | Current | RFCXXXX, Section 3.8.3.5 | 7143 | ATTENDEE | Current | RFCXXXX, Section 3.8.4.1 | 7144 | CONTACT | Current | RFCXXXX, Section 3.8.4.2 | 7145 | ORGANIZER | Current | RFCXXXX, Section 3.8.4.3 | 7146 | RECURRENCE-ID | Current | RFCXXXX, Section 3.8.4.4 | 7147 | RELATED-TO | Current | RFCXXXX, Section 3.8.4.5 | 7148 | URL | Current | RFCXXXX, Section 3.8.4.6 | 7149 | UID | Current | RFCXXXX, Section 3.8.4.7 | 7150 | EXDATE | Current | RFCXXXX, Section 3.8.5.1 | 7151 | EXRULE | Deprecated | RFC2445, Section 4.8.5.2 | 7152 | RDATE | Current | RFCXXXX, Section 3.8.5.2 | 7153 | RRULE | Current | RFCXXXX, Section 3.8.5.3 | 7154 | ACTION | Current | RFCXXXX, Section 3.8.6.1 | 7155 | REPEAT | Current | RFCXXXX, Section 3.8.6.2 | 7156 | TRIGGER | Current | RFCXXXX, Section 3.8.6.3 | 7157 | CREATED | Current | RFCXXXX, Section 3.8.7.1 | 7158 | DTSTAMP | Current | RFCXXXX, Section 3.8.7.2 | 7159 | LAST-MODIFIED | Current | RFCXXXX, Section 3.8.7.3 | 7160 | SEQUENCE | Current | RFCXXXX, Section 3.8.7.4 | 7161 | REQUEST-STATUS | Current | RFCXXXX, Section 3.8.8.3 | 7162 +------------------+------------+---------------------------+ 7164 8.3.3. Parameters Registry 7166 The following table is to be used to initialize the parameters 7167 registry. 7169 +----------------+------------+-------------------------+ 7170 | Parameter | Status | Reference | 7171 +----------------+------------+-------------------------+ 7172 | ALTREP | Current | RFCXXXX, Section 3.2.1 | 7173 | CN | Current | RFCXXXX, Section 3.2.2 | 7174 | CUTYPE | Current | RFCXXXX, Section 3.2.3 | 7175 | DELEGATED-FROM | Current | RFCXXXX, Section 3.2.4 | 7176 | DELEGATED-TO | Current | RFCXXXX, Section 3.2.5 | 7177 | DIR | Current | RFCXXXX, Section 3.2.6 | 7178 | ENCODING | Current | RFCXXXX, Section 3.2.7 | 7179 | FMTTYPE | Current | RFCXXXX, Section 3.2.8 | 7180 | FBTYPE | Current | RFCXXXX, Section 3.2.9 | 7181 | LANGUAGE | Current | RFCXXXX, Section 3.2.10 | 7182 | MEMBER | Current | RFCXXXX, Section 3.2.11 | 7183 | PARTSTAT | Current | RFCXXXX, Section 3.2.12 | 7184 | RANGE | Deprecated | RFC2445, Section 4.2.13 | 7185 | RELATED | Current | RFCXXXX, Section 3.2.13 | 7186 | RELTYPE | Current | RFCXXXX, Section 3.2.14 | 7187 | ROLE | Current | RFCXXXX, Section 3.2.15 | 7188 | RSVP | Current | RFCXXXX, Section 3.2.16 | 7189 | SENT-BY | Current | RFCXXXX, Section 3.2.17 | 7190 | TZID | Current | RFCXXXX, Section 3.2.18 | 7191 | VALUE | Current | RFCXXXX, Section 3.2.19 | 7192 +----------------+------------+-------------------------+ 7194 8.3.4. Value Data Types Registry 7196 The following table is to be used to initialize the value data types 7197 registry. 7199 +-----------------+---------+-------------------------+ 7200 | Value Data Type | Status | Reference | 7201 +-----------------+---------+-------------------------+ 7202 | BINARY | Current | RFCXXXX, Section 3.3.1 | 7203 | BOOLEAN | Current | RFCXXXX, Section 3.3.2 | 7204 | CAL-ADDRESS | Current | RFCXXXX, Section 3.3.3 | 7205 | DATE | Current | RFCXXXX, Section 3.3.4 | 7206 | DATE-TIME | Current | RFCXXXX, Section 3.3.5 | 7207 | DURATION | Current | RFCXXXX, Section 3.3.6 | 7208 | FLOAT | Current | RFCXXXX, Section 3.3.7 | 7209 | INTEGER | Current | RFCXXXX, Section 3.3.8 | 7210 | PERIOD | Current | RFCXXXX, Section 3.3.9 | 7211 | RECUR | Current | RFCXXXX, Section 3.3.10 | 7212 | TEXT | Current | RFCXXXX, Section 3.3.11 | 7213 | TIME | Current | RFCXXXX, Section 3.3.12 | 7214 | URI | Current | RFCXXXX, Section 3.3.13 | 7215 | UTC-OFFSET | Current | RFCXXXX, Section 3.3.14 | 7216 +-----------------+---------+-------------------------+ 7218 8.3.5. Calendar User Types Registry 7220 The following table is to be used to initialize the calendar user 7221 types registry. 7223 +--------------------+---------+------------------------+ 7224 | Calendar User Type | Status | Reference | 7225 +--------------------+---------+------------------------+ 7226 | INDIVIDUAL | Current | RFCXXXX, Section 3.2.3 | 7227 | GROUP | Current | RFCXXXX, Section 3.2.3 | 7228 | RESOURCE | Current | RFCXXXX, Section 3.2.3 | 7229 | ROOM | Current | RFCXXXX, Section 3.2.3 | 7230 | UNKNOWN | Current | RFCXXXX, Section 3.2.3 | 7231 +--------------------+---------+------------------------+ 7233 8.3.6. Free/Busy Time Types Registry 7235 The following table is to be used to initialize the free/busy time 7236 types registry. 7238 +---------------------+---------+------------------------+ 7239 | Free/Busy Time Type | Status | Reference | 7240 +---------------------+---------+------------------------+ 7241 | FREE | Current | RFCXXXX, Section 3.2.9 | 7242 | BUSY | Current | RFCXXXX, Section 3.2.9 | 7243 | BUSY-UNAVAILABLE | Current | RFCXXXX, Section 3.2.9 | 7244 | BUSY-TENTATIVE | Current | RFCXXXX, Section 3.2.9 | 7245 +---------------------+---------+------------------------+ 7247 8.3.7. Participation Statuses Registry 7249 The following table is to be used to initialize the participation 7250 statuses registry. 7252 +--------------------+---------+-------------------------+ 7253 | Participant Status | Status | Reference | 7254 +--------------------+---------+-------------------------+ 7255 | NEEDS-ACTION | Current | RFCXXXX, Section 3.2.12 | 7256 | ACCEPTED | Current | RFCXXXX, Section 3.2.12 | 7257 | DECLINED | Current | RFCXXXX, Section 3.2.12 | 7258 | TENTATIVE | Current | RFCXXXX, Section 3.2.12 | 7259 | DELEGATED | Current | RFCXXXX, Section 3.2.12 | 7260 | COMPLETED | Current | RFCXXXX, Section 3.2.12 | 7261 | IN-PROCESS | Current | RFCXXXX, Section 3.2.12 | 7262 +--------------------+---------+-------------------------+ 7264 8.3.8. Relationship Types Registry 7266 The following table is to be used to initialize the property 7267 parameters registry. 7269 +-------------------+---------+-------------------------+ 7270 | Relationship Type | Status | Reference | 7271 +-------------------+---------+-------------------------+ 7272 | CHILD | Current | RFCXXXX, Section 3.2.14 | 7273 | PARENT | Current | RFCXXXX, Section 3.2.14 | 7274 | SIBLING | Current | RFCXXXX, Section 3.2.14 | 7275 +-------------------+---------+-------------------------+ 7277 8.3.9. Participation Roles Registry 7279 The following table is to be used to initialize the participation 7280 roles registry. 7282 +-----------------+---------+-------------------------+ 7283 | Role Type | Status | Reference | 7284 +-----------------+---------+-------------------------+ 7285 | CHAIR | Current | RFCXXXX, Section 3.2.15 | 7286 | REQ-PARTICIPANT | Current | RFCXXXX, Section 3.2.15 | 7287 | OPT-PARTICIPANT | Current | RFCXXXX, Section 3.2.15 | 7288 | NON-PARTICIPANT | Current | RFCXXXX, Section 3.2.15 | 7289 +-----------------+---------+-------------------------+ 7291 8.3.10. Actions Registry 7293 The following table is to be used to initialize the actions registry. 7295 +-----------+------------+--------------------------+ 7296 | Action | Status | Reference | 7297 +-----------+------------+--------------------------+ 7298 | AUDIO | Current | RFCXXXX, Section 3.8.6.1 | 7299 | DISPLAY | Current | RFCXXXX, Section 3.8.6.1 | 7300 | EMAIL | Current | RFCXXXX, Section 3.8.6.1 | 7301 | PROCEDURE | Deprecated | RFC2445, Section 4.8.6.1 | 7302 +-----------+------------+--------------------------+ 7304 8.3.11. Classifications Registry 7306 The following table is to be used to initialize the classifications 7307 registry. 7309 +----------------+---------+--------------------------+ 7310 | Classification | Status | Reference | 7311 +----------------+---------+--------------------------+ 7312 | PUBLIC | Current | RFCXXXX, Section 3.8.1.3 | 7313 | PRIVATE | Current | RFCXXXX, Section 3.8.1.3 | 7314 | CONFIDENTIAL | Current | RFCXXXX, Section 3.8.1.3 | 7315 +----------------+---------+--------------------------+ 7317 8.3.12. Methods Registry 7319 No values are defined in this document for the "METHOD" property. 7321 9. Acknowledgements 7323 The editor of this document wish to thank Frank Dawson and Derik 7324 Stenerson, the original authors of RFC2445, as well as the following 7325 individuals who have participated in the drafting, review and 7326 discussion of this memo: 7328 Joe Abley, Hervey Allen, Jay Batson, Oliver Block, Stephane 7329 Bortzmeyer, Chris Bryant, Tantek Celik, Mark Crispin, Cyrus Daboo, 7330 Mike Douglass, Andrew N. Dowden, Lisa Dusseault, Ned Freed, Ted 7331 Hardie, Tim Hare, Jeffrey Harris, Helge Hess, Leif Johansson, 7332 Reinhold Kainhofer, Eliot Lear, Michiel van Leeuwen, Jonathan Lennox, 7333 Jeff McCullough, Bill McQuillan, Alexey Melnikov, Aki Niemi, John W. 7334 Noerenberg II, Chuck Norris, Mark Paterson, Simon Pilette, Arnaud 7335 Quillaud, Robert Ransdell, Julian F. Reschke, Caleb Richardson, Sam 7336 Roberts, George Sexton, Nigel Swinson, Simon Vaillancourt, and Sandy 7337 Wills. 7339 The editor would also like to thank the Calendaring and Scheduling 7340 Consortium for advice with this specification, and for organizing 7341 interoperability testing events to help refine it. 7343 10. References 7345 10.1. Normative References 7347 [ISO.8601.2004] International Organization for 7348 Standardization, "Data elements and 7349 interchange formats -- Information 7350 interchange -- Representation of dates 7351 and times", 2004. 7353 [ISO.9070.1991] International Organization for 7354 Standardization, "Information 7355 Technology_SGML Support Facilities -- 7356 Registration Procedures for Public 7357 Text Owner Identifiers, Second 7358 Edition", April 1991. 7360 [RFC2045] Freed, N. and N. Borenstein, 7361 "Multipurpose Internet Mail Extensions 7362 (MIME) Part One: Format of Internet 7363 Message Bodies", RFC 2045, 7364 November 1996. 7366 [RFC2046] Freed, N. and N. Borenstein, 7367 "Multipurpose Internet Mail Extensions 7368 (MIME) Part Two: Media Types", 7369 RFC 2046, November 1996. 7371 [RFC2119] Bradner, S., "Key words for use in 7372 RFCs to Indicate Requirement Levels", 7373 BCP 14, RFC 2119, March 1997. 7375 [RFC2368] Hoffman, P., Masinter, L., and J. 7376 Zawinski, "The mailto URL scheme", 7377 RFC 2368, July 1998. 7379 [RFC2822] Resnick, P., "Internet Message 7380 Format", RFC 2822, April 2001. 7382 [RFC3629] Yergeau, F., "UTF-8, a transformation 7383 format of ISO 10646", STD 63, 7384 RFC 3629, November 2003. 7386 [RFC3986] Berners-Lee, T., Fielding, R., and L. 7387 Masinter, "Uniform Resource Identifier 7388 (URI): Generic Syntax", STD 66, 7389 RFC 3986, January 2005. 7391 [RFC4234] Crocker, D., Ed. and P. Overell, 7392 "Augmented BNF for Syntax 7393 Specifications: ABNF", RFC 4234, 7394 October 2005. 7396 [RFC4646] Phillips, A. and M. Davis, "Tags for 7397 Identifying Languages", BCP 47, 7398 RFC 4646, September 2006. 7400 [RFC4648] Josefsson, S., "The Base16, Base32, 7401 and Base64 Data Encodings", RFC 4648, 7402 October 2006. 7404 10.2. Informative References 7406 [I-D.ietf-calsify-2446bis] Daboo, C., "iCalendar Transport- 7407 Independent Interoperability Protocol 7408 (iTIP)", draft-ietf-calsify-2446bis-03 7409 (work in progress), March 2007. 7411 [I-D.ietf-calsify-rfc2447bis] Melnikov, A., "iCalendar Message-Based 7412 Interoperability Protocol(iMIP)", 7413 draft-ietf-calsify-rfc2447bis-03 (work 7414 in progress), February 2007. 7416 [RFC2392] Levinson, E., "Content-ID and 7417 Message-ID Uniform Resource Locators", 7418 RFC 2392, August 1998. 7420 [RFC2425] Howes, T., Smith, M., and F. Dawson, 7421 "A MIME Content-Type for Directory 7422 Information", RFC 2425, 7423 September 1998. 7425 [RFC2426] Dawson, F. and T. Howes, "vCard MIME 7426 Directory Profile", RFC 2426, 7427 September 1998. 7429 [RFC4516] Smith, M. and T. Howes, "Lightweight 7430 Directory Access Protocol (LDAP): 7431 Uniform Resource Locator", RFC 4516, 7432 June 2006. 7434 [RFC4791] Daboo, C., Desruisseaux, B., and L. 7435 Dusseault, "Calendaring Extensions to 7436 WebDAV (CalDAV)", RFC 4791, 7437 March 2007. 7439 [TZDB] Eggert, P. and A. Olson, "Sources for 7440 Time Zone and Daylight Saving Time 7441 Data", January 2007, . 7444 [Note to RFC Editor: Change "A. Olson" 7445 to "A.D. Olson".] 7447 [VCAL] Internet Mail Consortium, "vCalendar: 7448 The Electronic Calendaring and 7449 Scheduling Exchange Format", 7450 September 1996, 7451 . 7453 URIs 7455 [1] 7457 [2] 7459 [3] 7461 Appendix A. Differences from RFC 2445 7463 This appendix contains a list of changes that have been made in the 7464 Internet Calendaring and Scheduling Core Object Specification from 7465 RFC 2445. 7467 A.1. New restrictions 7469 1. The "DTSTART" property SHOULD be synchronized with the recurrence 7470 rule, if specified. 7472 2. The "RRULE" property SHOULD NOT occur more than once in a 7473 component. 7475 3. The BYHOUR, BYMINUTE and BYSECOND rule parts MUST NOT be 7476 specified in the "RRULE" property when the "DTSTART" property is 7477 specified as a DATE value. 7479 4. The value type of the "DTEND" or "DUE" properties MUST match the 7480 value type of "DTSTART" property. 7482 A.2. Restrictions removed 7484 1. The "DTSTART" and "DTEND" properties are no longer required to be 7485 specified as date with local time and time zone reference when 7486 used with a recurrence rule. 7488 A.3. Deprecated features 7490 1. The "EXRULE" property can no longer be specified in a component. 7492 2. The "RANGE" parameter can no longer be specified on the 7493 "RECURRENCE-ID" property. 7495 3. The "PROCEDURE" value can no longer be used with the "ACTION" 7496 property. 7498 4. x-name rule parts can no longer be specified in properties of 7499 RECUR value type (e.g., RRULE). x-param can be used on RECUR 7500 value type properties instead. 7502 Appendix B. Change Log (to be removed by RFC Editor prior to 7503 publication) 7505 B.1. Changes in -07 7507 A detailed list of changes is available at the following page: 7508 http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/ 7509 draft-ietf-calsify-rfc2445bis-07.changes.html. 7511 a. Issue 8: Clarified how to compute the exact duration of a nominal 7512 duration. 7514 b. Issue 10: Added new examples for "VEVENT" and "VTODO" to 7515 demonstrate that end times are always non-inclusive, that is, 7516 even end times specified as DATE values. 7518 c. Issue 11: Added a table that shows the dependency of BYxxx rule 7519 part expand or limit behaviour on the FREQ value in the rule. 7521 d. Issue 19: Removed section "Registration of Content Type 7522 Elements". Added registration templates in IANA Considerations 7523 section. Specified how applications should treat x-name and 7524 x-token they don't recognize. 7526 e. Issue 65: Removed 3rd recommended practice. Added new 7527 requirements to require "DTEND" and "DUE" to be a local date time 7528 if and only if "DTSTART" is a local date time. 7530 f. Issue 68: Clarified handling of date-times that fall in time 7531 discontinutities. 7533 g. Issue 69: Clarified handling of recurrence instances that fall in 7534 time discontinutities 7536 h. Issue 71: Clarified handling of leap seconds. 7538 i. Issue 75: Clarified that the "RDATE" property MUST be specified 7539 as a local DATE-TIME value in "VTIMEZONE" sub-components. 7541 j. Issue 76: Clarified that the value type of the "DTEND" property 7542 MUST be the same as the "DTSTART" property. 7544 k. Issue 77: Clarified that the value type of the "DUE" property 7545 MUST be the same as the "DTSTART" property. 7547 l. Issue 79: Clarified that "DTSTART" always specify an onset date- 7548 time of an observance and that its value does not need to be 7549 repeated in an "RDATE" property. 7551 m. Issue 80: Rewrote Security Considerations section. 7553 n. Issue 81: Clarified the meaning of "the set of events specified 7554 by the rule" in the description of the BYSETPOS rule part. 7556 o. Modified Abstract section. 7558 p. Moved text of section 2.3 International Considerations at the end 7559 of sectino 2.1 Formatting Conventions. 7561 q. Added Internationalization Considerations section. 7563 r. Modified the description of the following properties: "ATTACH", 7564 "COMMENT", "COMPLETED", "CREATED" "DTSTAMP" "DUE", and "REPEAT". 7566 s. Clarified some differences with ISO 8601. 7568 t. Updated reference to CalDAV and ISO 8601. 7570 u. Updated section "Differences from RFC 2445": added new 7571 restrictions and added list of removed restrictions. 7573 v. Numerous editorial changes. 7575 B.2. Changes in -06 7577 A detailed list of changes is available at the following page: 7578 http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/ 7579 draft-ietf-calsify-rfc2445bis-06.changes.html. 7581 a. Issue 19: Defined new IANA registries. [Work in progress]; 7583 b. Issue 23: Clarified that the UNTIL rule part MUST specify a value 7584 of the same type as the value specified by "DTSTART"; 7586 c. Issue 27: Clarified how the duration of generated recurrence 7587 instances is determined; 7589 d. Issue 35: Further clarified the description of the "LANGUAGE" 7590 property; 7592 e. Issue 42: Removed the restriction on the values allowed for the 7593 "ACTION" property in the the "VALARM" component; 7595 f. Issue 47: Clarified that alarm triggers relative to a DATE value 7596 type needs to be triggered to 00:00:00 of the user's configured 7597 time zone; 7599 g. Issue 56: Added a note to specify that FREQ MUST be specified as 7600 the first rule part in generated iCalendar applications, but MUST 7601 be accepted in any order to ensure backward compatibility. The 7602 rest of the RECUR value type ABNF has been further simplified; 7604 h. Issue 59: Clarified the default duration of "VEVENT" components 7605 specified with a "DTSTART" property of DATE value type; 7607 i. Issue 61: Modified all the property ABNFs to allow iana-param in 7608 addition to x-param. Also modified the component ABNFs to allow 7609 iana-prop in addition to x-prop. [Work in progress]; 7611 j. Issue 62: Removed the text that lead to believe that the 7612 "RECURRENCE-ID" of a specific recurrence instance might change; 7614 k. Issue 64: Clarified that REQUEST-STATUS only allows pairs (1.1) 7615 and 3-tuples (1.1.1). 7617 l. Issue 65: Clarified that a different time zone may be used by 7618 "DTSTART" and "DTEND", and "DTSTART" and "DUE" when specified as 7619 date with local time and time zone reference. [Work in 7620 progress]; 7622 m. Issue 66: Clarified that if the "RDATE" property is specified as 7623 a PERIOD, its duration has precedence over the duration of the 7624 recurrence instance defined by the "DTSTART" property; 7626 n. Issue 72: Removed the requirement that a "VTIMEZONE" calendar 7627 component MUST be present if the iCalendar object contains an 7628 RRULE that generates dates on both sides of a time zone shift; 7630 o. Issue 73: Clarified that the "TZID" must be unique in the scope 7631 of an iCalendar object only; 7633 p. Issue 74: Deprecated the "PROCEDURE" value for the "ACTION" 7634 property; 7636 q. Issue 78: Fixed the text to specify that "TZOFFSETFROM" and not 7637 "TZOFFSETTO" must be used with "DTSTART" when generating the 7638 onset date-time values from the "RRULE" in a "VTIMEZONE" 7639 component; 7641 r. Clarified that the "DTSTART" property MUST be specified in a 7642 "VTODO" component when the "DURATION" property is specified; 7644 s. Started to update the time zone information / examples; 7645 t. Numerous editorial changes. 7647 B.3. Changes in -05 7649 A detailed list of changes is available at the following page: 7650 http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/ 7651 draft-ietf-calsify-rfc2445bis-05.changes.html. 7653 a. Fixed ABNF with references in .txt version of the draft; 7655 b. Numerous editorial changes; 7657 c. Clarified that normative statements in ABNF comments should be 7658 considered as normative; 7660 d. Removed notes talking of character sets other than US-ASCII and 7661 UTF-8; 7663 e. Renamed CTL to CONTROL to avoid conflict with the CTL rule 7664 defined in RFC4234; 7666 f. Removed ABNF rules defined in RFC4234; 7668 g. Changed the partstatparam ABNF rule for clarity; 7670 h. Clarified the purpose of negative durations; 7672 i. Added informational references to RFC 2392 (CID URL) and RFC 4516 7673 (LDAP URL). 7675 j. Updated TZDB reference. 7677 B.4. Changes in -04 7679 A detailed list of changes is available at the following page: 7680 http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/ 7681 draft-ietf-calsify-rfc2445bis-04.changes.html. 7683 a. Issue 16: Clarified that recurrence instances, generated by a 7684 recurrence rule, with an invalid date or nonexistent local time 7685 must be ignored and not counted as part of the recurrence set. 7687 b. Issue 26: Clarified how to handle the BYHOUR, BYMINUTE and 7688 BYSECOND rule parts when "DTSTART" is a DATE value. 7690 c. Issue 28: Removed the MUST requirement to specify the "RDATE" 7691 property whenever the duration of a recurrence instance is 7692 modified. 7694 d. Issue 29: Clarified that the "DTSTART" property is REQUIRED in 7695 all types of recurring components. 7697 e. Issue 32: Introduced the notion of an "iCalendar stream" to make 7698 it explicit when we are refering to a "single iCalendar object" 7699 or a "sequence of iCalendar objects". 7701 f. Issue 34: Clarified what should be done with the "method" 7702 parameter when the iCalendar stream is a sequence of iCalendar 7703 objects. 7705 g. Issue 40: Changed to fbprop ABNF rule to specify that the 7706 "DTSTAMP" and the "UID" properties are REQUIRED in "VFREEBUSY" 7707 components. 7709 h. Issue 43: Removed the MUST requirement to specify the "DTSTART" 7710 and the "DTEND" properties as local time in recurring components, 7711 but added a note that in most cases this is the right thing to 7712 do. 7714 i. Issue 44: Changed the x-prop ABNF to allow any parameters on non- 7715 standard properties. 7717 j. Issue 46: Simplified the tzprop, audioprop, dispprop, emailprop, 7718 and procprop ABNF rules by removing the number of required 7719 properties in front of the "*". 7721 k. Issue 48: Deprecated the "RANGE" parameter. 7723 l. Issue 51: Clarified implicit duration of day events with no 7724 "DTEND" nor "DURATION" property. 7726 m. Issue 52: Removed x-name from the "recur" rule part definition. 7727 It should be sufficient to allow xparam on properties of RECUR 7728 value type. 7730 n. Issue 53: Updated the NON-US-ASCII ABNF rule for UTF-8. 7732 o. Issue 56: Changed the "recur" ABNF rule to allow rule parts to be 7733 specified in any order. 7735 p. Issue 57: Specified that the "DURATION" property MUST be 7736 specified as a "dur-day" or "dur-week" value when the "DTSTART" 7737 is a DATE. 7739 q. Issue 58: Changed the jourprop ABNF rule to allow the 7740 "DESCRIPTION" property to occur more than once. 7742 r. Numerous editorial changes. 7744 s. Changed reference to RFC 4646 for Language-Tag. 7746 B.5. Changes in -03 7748 A detailed list of changes is available at the following page: 7749 http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/ 7750 draft-ietf-calsify-rfc2445bis-03.changes.html. 7752 a. Numerous editorial changes. 7754 b. Specified that "DTSTART" should match the pattern of "RRULE" and 7755 is always part of the "COUNT". 7757 c. Specified "RRULE" should not occur more than once in recurring 7758 components. 7760 d. Deprecated "EXRULE". 7762 e. Fixed all ABNF errors reported by Bill Fenner's ABNF parsing web 7763 service available at: 7764 http://rtg.ietf.org/~fenner/abnf.cgi. 7766 f. Changed reference to RFC 4648 for Base64 encoding. 7768 B.6. Changes in -02 7770 A detailed list of changes is available at the following page: 7771 http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/ 7772 draft-ietf-calsify-rfc2445bis-02.changes.html. 7774 a. Numerous editorial changes including the typos listed in the 7775 "RFC2445 Errata": 7776 http://www.rfc-editor.org/cgi-bin/errataSearch.pl?rfc=2445& 7777 and in the "RFC2445 Issues List": 7778 http://www.softwarestudio.org/iCal/2445Issues.html. 7780 b. Clarified line folding requirements. 7782 c. Clarified charset requirements. 7784 d. Clarified line limits requirements. 7786 e. Clarified on the use of the "LANGUAGE" parameter. 7788 f. Fixed the eventprop, todoprop and jourprop ABNF rules with 7789 respect to required properties. 7791 g. Fixed all the examples to use RFC2606-compliant FQDNs. 7793 h. Fixed the Content-ID URLs in the examples. 7795 i. Fixed the LDAP URLs in the examples. 7797 j. Moved multiple references in the Informative References section. 7799 k. Updated the Acknowledgments section. 7801 B.7. Changes in -01 7803 A detailed list of changes is available at the following page: 7804 http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/ 7805 draft-ietf-calsify-rfc2445bis-01.changes.html. 7807 a. Numerous editorial changes (typos, errors in examples, etc.). 7809 b. Fixed invalid media types in examples. 7811 c. Fixed the "DTSTAMP" values in the examples. 7813 d. Moved media type registration in a separate IANA Consideration 7814 section. 7816 e. Added Internationalization Considerations section. 7818 f. Added Security Considerations section. 7820 g. Updated the Acknowledgments section. 7822 Appendix C. Open issues (to be removed by RFC Editor prior to 7823 publication) 7825 C.1. introduction 7827 Type: edit 7829 bernard.desruisseaux@oracle.com (2007-02-20): The Introduction 7830 section should be updated. 7832 C.2. #issue11+4.3.10_byxxx_rule_part_examples 7834 Type: change 7836 7838 reinhold@kainhofer.com (2006-06-03): We should add more BYXXX rule 7839 parts examples. 7841 Resolution: 7843 C.3. #issue63+4.8.5.3_rdate_and_dtstart 7845 Type: change 7847 7850 bernard.desruisseaux@oracle.com (2006-11-05): We need to clarify 7851 whether RDATE can specify a value earlier in time than DTSTART. 7853 Resolution: 7855 Author's Address 7857 Bernard Desruisseaux (editor) 7858 Oracle Corporation 7859 600 blvd. de Maisonneuve West 7860 Suite 1900 7861 Montreal, QC H3A 3J2 7862 CANADA 7864 EMail: bernard.desruisseaux@oracle.com 7865 URI: http://www.oracle.com/ 7867 Full Copyright Statement 7869 Copyright (C) The IETF Trust (2007). 7871 This document is subject to the rights, licenses and restrictions 7872 contained in BCP 78, and except as set forth therein, the authors 7873 retain all their rights. 7875 This document and the information contained herein are provided on an 7876 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 7877 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 7878 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 7879 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 7880 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 7881 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 7883 Intellectual Property 7885 The IETF takes no position regarding the validity or scope of any 7886 Intellectual Property Rights or other rights that might be claimed to 7887 pertain to the implementation or use of the technology described in 7888 this document or the extent to which any license under such rights 7889 might or might not be available; nor does it represent that it has 7890 made any independent effort to identify any such rights. Information 7891 on the procedures with respect to rights in RFC documents can be 7892 found in BCP 78 and BCP 79. 7894 Copies of IPR disclosures made to the IETF Secretariat and any 7895 assurances of licenses to be made available, or the result of an 7896 attempt made to obtain a general license or permission for the use of 7897 such proprietary rights by implementers or users of this 7898 specification can be obtained from the IETF on-line IPR repository at 7899 http://www.ietf.org/ipr. 7901 The IETF invites any interested party to bring to its attention any 7902 copyrights, patents or patent applications, or other proprietary 7903 rights that may cover technology that may be required to implement 7904 this standard. Please address the information to the IETF at 7905 ietf-ipr@ietf.org. 7907 Acknowledgement 7909 Funding for the RFC Editor function is provided by the IETF 7910 Administrative Support Activity (IASA).