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

683 Project XYZ Review Meeting will include 684 the following agenda items: 685

    686
  1. Market Overview
    2. 687
  2. Finances
    3. 688
  3. Project Management
    4. 689
690

691 692 694 3.2.2. Common Name 696 Parameter Name: CN 697 Purpose: To specify the common name to be associated with the 698 calendar user specified by the property. 700 Format Definition: This property parameter is defined by the 701 following notation: 703 cnparam = "CN" "=" param-value 705 Description: This parameter can be specified on properties with a 706 CAL-ADDRESS value type. The parameter specifies the common name 707 to be associated with the calendar user specified by the property. 708 The parameter value is text. The parameter value can be used for 709 display text to be associated with the calendar address specified 710 by the property. 712 Example: 714 ORGANIZER;CN="John Smith":mailto:jsmith@example.com 716 3.2.3. Calendar User Type 718 Parameter Name: CUTYPE 720 Purpose: To specify the type of calendar user specified by the 721 property. 723 Format Definition: This property parameter is defined by the 724 following notation: 726 cutypeparam = "CUTYPE" "=" 727 ("INDIVIDUAL" ; An individual 728 / "GROUP" ; A group of individuals 729 / "RESOURCE" ; A physical resource 730 / "ROOM" ; A room resource 731 / "UNKNOWN" ; Otherwise not known 732 / x-name ; Experimental type 733 / iana-token) ; Other IANA registered 734 ; type 735 ; Default is INDIVIDUAL 737 Description: This parameter can be specified on properties with a 738 CAL-ADDRESS value type. The parameter identifies the type of 739 calendar user specified by the property. If not specified on a 740 property that allows this parameter, the default is INDIVIDUAL. 741 Applications MUST treat x-name and iana-token value they don't 742 recognized the same way as they would the UNKNOWN value. 744 Example: 746 ATTENDEE;CUTYPE=GROUP:mailto:ietf-calsch@example.org 748 3.2.4. Delegators 750 Parameter Name: DELEGATED-FROM 752 Purpose: To specify the calendar users that have delegated their 753 participation to the calendar user specified by the property. 755 Format Definition: This property parameter is defined by the 756 following notation: 758 delfromparam = "DELEGATED-FROM" "=" DQUOTE cal-address 759 DQUOTE *("," DQUOTE cal-address DQUOTE) 761 Description: This parameter can be specified on properties with a 762 CAL-ADDRESS value type. This parameter specifies those calendar 763 users that have delegated their participation in a group scheduled 764 event or to-do to the calendar user specified by the property. 765 The individual calendar address parameter values MUST each be 766 specified in a quoted-string. 768 Example: 770 ATTENDEE;DELEGATED-FROM="mailto:jsmith@example.com":mailto: 771 jdoe@example.com 773 3.2.5. Delegatees 775 Parameter Name: DELEGATED-TO 777 Purpose: To specify the calendar users to whom the calendar user 778 specified by the property has delegated participation. 780 Format Definition: This property parameter is defined by the 781 following notation: 783 deltoparam = "DELEGATED-TO" "=" DQUOTE cal-address DQUOTE 784 *("," DQUOTE cal-address DQUOTE) 786 Description: This parameter can be specified on properties with a 787 CAL-ADDRESS value type. This parameter specifies those calendar 788 users whom have been delegated participation in a group scheduled 789 event or to-do by the calendar user specified by the property. 790 The individual calendar address parameter values MUST each be 791 specified in a quoted-string. 793 Example: 795 ATTENDEE;DELEGATED-TO="mailto:jdoe@example.com","mailto:jqpublic 796 @example.com":mailto:jsmith@example.com 798 3.2.6. Directory Entry Reference 800 Parameter Name: DIR 802 Purpose: To specify reference to a directory entry associated with 803 the calendar user specified by the property. 805 Format Definition: This property parameter is defined by the 806 following notation: 808 dirparam = "DIR" "=" DQUOTE uri DQUOTE 810 Description: This parameter can be specified on properties with a 811 CAL-ADDRESS value type. The parameter specifies a reference to 812 the directory entry associated with the calendar user specified by 813 the property. The parameter value is a URI. The URI parameter 814 value MUST be specified in a quoted-string. 816 Note: While there is no restriction imposed on the URI schemes 817 allowed for this parameter, CID [RFC2392], DATA [RFC2397], FILE 818 [RFC1738], FTP [RFC1738], HTTP [RFC2616], HTTPS [RFC2818], LDAP 819 [RFC4516], and MID [RFC2392] are the URI schemes most commonly 820 used by current implementations. 822 Example: 824 ORGANIZER;DIR="ldap://example.com:6666/o=ABC%20Industries, 825 c=US???(cn=Jim%20Dolittle)":mailto:jimdo@example.com 827 3.2.7. Inline Encoding 829 Parameter Name: ENCODING 831 Purpose: To specify an alternate inline encoding for the property 832 value. 834 Format Definition: This property parameter is defined by the 835 following notation: 837 encodingparam = "ENCODING" "=" 838 ( "8BIT" 839 ; "8bit" text encoding is defined in [RFC2045] 840 / "BASE64" 841 ; "BASE64" binary encoding format is defined in [RFC4648] 842 ) 844 Description: This property parameter identifies the inline encoding 845 used in a property value. The default encoding is "8BIT", 846 corresponding to a property value consisting of text. The 847 "BASE64" encoding type corresponds to a property value encoded 848 using the "BASE64" encoding defined in [RFC2045]. 850 If the value type parameter is ";VALUE=BINARY", then the inline 851 encoding parameter MUST be specified with the value 852 ";ENCODING=BASE64". 854 Example: 856 ATTACH;FMTTYPE=text/plain;ENCODING=BASE64;VALUE=BINARY:TG9yZW 857 0gaXBzdW0gZG9sb3Igc2l0IGFtZXQsIGNvbnNlY3RldHVyIGFkaXBpc2ljaW 858 5nIGVsaXQsIHNlZCBkbyBlaXVzbW9kIHRlbXBvciBpbmNpZGlkdW50IHV0IG 859 xhYm9yZSBldCBkb2xvcmUgbWFnbmEgYWxpcXVhLiBVdCBlbmltIGFkIG1pbm 860 ltIHZlbmlhbSwgcXVpcyBub3N0cnVkIGV4ZXJjaXRhdGlvbiB1bGxhbWNvIG 861 xhYm9yaXMgbmlzaSB1dCBhbGlxdWlwIGV4IGVhIGNvbW1vZG8gY29uc2VxdW 862 F0LiBEdWlzIGF1dGUgaXJ1cmUgZG9sb3IgaW4gcmVwcmVoZW5kZXJpdCBpbi 863 B2b2x1cHRhdGUgdmVsaXQgZXNzZSBjaWxsdW0gZG9sb3JlIGV1IGZ1Z2lhdC 864 BudWxsYSBwYXJpYXR1ci4gRXhjZXB0ZXVyIHNpbnQgb2NjYWVjYXQgY3VwaW 865 RhdGF0IG5vbiBwcm9pZGVudCwgc3VudCBpbiBjdWxwYSBxdWkgb2ZmaWNpYS 866 BkZXNlcnVudCBtb2xsaXQgYW5pbSBpZCBlc3QgbGFib3J1bS4= 868 3.2.8. Format Type 870 Parameter Name: FMTTYPE 872 Purpose: To specify the content type of a referenced object. 874 Format Definition: This property parameter is defined by the 875 following notation: 877 fmttypeparam = "FMTTYPE" "=" type-name "/" subtype-name 878 ; Where "type-name" and "subtype-name" are 879 ; defined in section 4.2 of [RFC4288] 881 Description: This parameter can be specified on properties that are 882 used to reference an object. The parameter specifies the media 883 type [RFC4288] of the referenced object. For example, on the 884 "ATTACH" property, a FTP type URI value does not, by itself, 885 necessarily convey the type of content associated with the 886 resource. The parameter value MUST be the text for either an IANA 887 registered media type or a non-standard media type. 889 Example: 891 ATTACH;FMTTYPE=application/msword:ftp://example.com/pub/docs/ 892 agenda.doc 894 3.2.9. Free/Busy Time Type 896 Parameter Name: FBTYPE 898 Purpose: To specify the free or busy time type. 900 Format Definition: This property parameter is defined by the 901 following notation: 903 fbtypeparam = "FBTYPE" "=" ("FREE" / "BUSY" 904 / "BUSY-UNAVAILABLE" / "BUSY-TENTATIVE" 905 / x-name 906 ; Some experimental iCalendar free busy type. 907 / iana-token) 908 ; Some other IANA registered iCalendar free busy type. 910 Description: This parameter specifies the free or busy time type. 911 The value FREE indicates that the time interval is free for 912 scheduling. The value BUSY indicates that the time interval is 913 busy because one or more events have been scheduled for that 914 interval. The value BUSY-UNAVAILABLE indicates that the time 915 interval is busy and that the interval can not be scheduled. The 916 value BUSY-TENTATIVE indicates that the time interval is busy 917 because one or more events have been tentatively scheduled for 918 that interval. If not specified on a property that allows this 919 parameter, the default is BUSY. Applications MUST treat x-name 920 and iana-token value they don't recognized the same way as they 921 would the BUSY value. 923 Example: The following is an example of this parameter on a 924 "FREEBUSY" property. 926 FREEBUSY;FBTYPE=BUSY:19980415T133000Z/19980415T170000Z 928 3.2.10. Language 930 Parameter Name: LANGUAGE 932 Purpose: To specify the language for text values in a property or 933 property parameter. 935 Format Definition: This property parameter is defined by the 936 following notation: 938 languageparam = "LANGUAGE" "=" language 940 language = Language-Tag 941 ; As defined in [RFC4646] 943 Description: This parameter identifies the language of the text in 944 the property value and of all property parameter values of the 945 property. The value of the "LANGUAGE" property parameter is that 946 defined in [RFC4646]. 948 For transport in a MIME entity, the Content-Language header field 949 can be used to set the default language for the entire body part. 950 Otherwise, no default language is assumed. 952 Example: The following are examples of this parameter on the 953 "SUMMARY" and "LOCATION" properties: 955 SUMMARY;LANGUAGE=en-US:Company Holiday Party 957 LOCATION;LANGUAGE=en:Germany 959 LOCATION;LANGUAGE=no:Tyskland 961 3.2.11. Group or List Membership 963 Parameter Name: MEMBER 965 Purpose: To specify the group or list membership of the calendar 966 user specified by the property. 968 Format Definition: This property parameter is defined by the 969 following notation: 971 memberparam = "MEMBER" "=" DQUOTE cal-address DQUOTE 972 *("," DQUOTE cal-address DQUOTE) 974 Description: This parameter can be specified on properties with a 975 CAL-ADDRESS value type. The parameter identifies the groups or 976 list membership for the calendar user specified by the property. 977 The parameter value is either a single calendar address in a 978 quoted-string or a COMMA character (US-ASCII decimal 44) separated 979 list of calendar addresses, each in a quoted-string. The 980 individual calendar address parameter values MUST each be 981 specified in a quoted-string. 983 Example: 985 ATTENDEE;MEMBER="mailto:ietf-calsch@example.org":mailto: 986 jsmith@example.com 988 ATTENDEE;MEMBER="mailto:projectA@example.com","mailto:pr 989 ojectB@example.com":mailto:janedoe@example.com 991 3.2.12. Participation Status 993 Parameter Name: PARTSTAT 995 Purpose: To specify the participation status for the calendar user 996 specified by the property. 998 Format Definition: This property parameter is defined by the 999 following notation: 1001 partstatparam = "PARTSTAT" "=" 1002 (partstat-event 1003 / partstat-todo 1004 / partstat-jour) 1006 partstat-event = ("NEEDS-ACTION" ; Event needs action 1007 / "ACCEPTED" ; Event accepted 1008 / "DECLINED" ; Event declined 1009 / "TENTATIVE" ; Event tentatively 1010 ; accepted 1011 / "DELEGATED" ; Event delegated 1012 / x-name ; Experimental status 1013 / iana-token) ; Other IANA registered 1014 ; status 1015 ; These are the participation statuses for a "VEVENT". 1016 ; Default is NEEDS-ACTION. 1018 partstat-todo = ("NEEDS-ACTION" ; To-do needs action 1019 / "ACCEPTED" ; To-do accepted 1020 / "DECLINED" ; To-do declined 1021 / "TENTATIVE" ; To-do tentatively 1022 ; accepted 1023 / "DELEGATED" ; To-do delegated 1024 / "COMPLETED" ; To-do completed. 1025 ; COMPLETED property has 1026 ; date/time completed. 1027 / "IN-PROCESS" ; To-do in process of 1028 ; being completed 1029 / x-name ; Experimental status 1030 / iana-token) ; Other IANA registered 1031 ; status 1032 ; These are the participation statuses for a "VTODO". 1033 ; Default is NEEDS-ACTION. 1035 partstat-jour = ("NEEDS-ACTION" ; Journal needs action 1036 / "ACCEPTED" ; Journal accepted 1037 / "DECLINED" ; Journal declined 1038 / x-name ; Experimental status 1039 / iana-token) ; Other IANA registered 1040 ; status 1041 ; These are the participation statuses for a "VJOURNAL". 1042 ; Default is NEEDS-ACTION. 1044 Description: This parameter can be specified on properties with a 1045 CAL-ADDRESS value type. The parameter identifies the 1046 participation status for the calendar user specified by the 1047 property value. The parameter values differ depending on whether 1048 they are associated with a group scheduled "VEVENT", "VTODO" or 1049 "VJOURNAL". The values MUST match one of the values allowed for 1050 the given calendar component. If not specified on a property that 1051 allows this parameter, the default value is NEEDS-ACTION. 1052 Applications MUST treat x-name and iana-token value they don't 1053 recognized the same way as they would the NEEDS-ACTION value. 1055 Example: 1057 ATTENDEE;PARTSTAT=DECLINED:mailto:jsmith@example.com 1059 3.2.13. Recurrence Identifier Range 1060 Parameter Name: RANGE 1062 Purpose: To specify the effective range of recurrence instances from 1063 the instance specified by the recurrence identifier specified by 1064 the property. 1066 Format Definition: This property parameter is defined by the 1067 following notation: 1069 rangeparam = "RANGE" "=" "THISANDFUTURE" 1070 ; To specify the instance specified by the recurrence identifier 1071 ; and all subsequent recurrence instances 1073 Description: This parameter can be specified on a property that 1074 specifies a recurrence identifier. The parameter specifies the 1075 effective range of recurrence instances that is specified by the 1076 property. The effective range is from the recurrence identifier 1077 specified by the property. If this parameter is not specified on 1078 an allowed property, then the default range is the single instance 1079 specified by the recurrence identifier value of the property. The 1080 parameter value can only be "THISANDFUTURE" to indicate a range 1081 defined by the recurrence identifier and all subsequent instances. 1082 The value "THISANDPRIOR" is deprecated by this revision of 1083 iCalendar and MUST NOT be generated by applications. 1085 Example: 1087 RECURRENCE-ID;RANGE=THISANDFUTURE:19980401T133000Z 1089 3.2.14. Alarm Trigger Relationship 1091 Parameter Name: RELATED 1093 Purpose: To specify the relationship of the alarm trigger with 1094 respect to the start or end of the calendar component. 1096 Format Definition: This property parameter is defined by the 1097 following notation: 1099 trigrelparam = "RELATED" "=" 1100 ("START" ; Trigger off of start 1101 / "END") ; Trigger off of end 1103 Description: This parameter can be specified on properties that 1104 specify an alarm trigger with a "DURATION" value type. The 1105 parameter specifies whether the alarm will trigger relative to the 1106 start or end of the calendar component. The parameter value START 1107 will set the alarm to trigger off the start of the calendar 1108 component; the parameter value END will set the alarm to trigger 1109 off the end of the calendar component. If the parameter is not 1110 specified on an allowable property, then the default is START. 1112 Example: 1114 TRIGGER;RELATED=END:PT5M 1116 3.2.15. Relationship Type 1118 Parameter Name: RELTYPE 1120 Purpose: To specify the type of hierarchical relationship associated 1121 with the calendar component specified by the property. 1123 Format Definition: This property parameter is defined by the 1124 following notation: 1126 reltypeparam = "RELTYPE" "=" 1127 ("PARENT" ; Parent relationship. Default. 1128 / "CHILD" ; Child relationship 1129 / "SIBLING" ; Sibling relationship 1130 / iana-token ; Some other IANA registered 1131 ; iCalendar relationship type 1132 / x-name) ; A non-standard, experimental 1133 ; relationship type 1135 Description: This parameter can be specified on a property that 1136 references another related calendar. The parameter specifies the 1137 hierarchical relationship type of the calendar component 1138 referenced by the property. The parameter value can be PARENT, to 1139 indicate that the referenced calendar component is a superior of 1140 calendar component; CHILD to indicate that the referenced calendar 1141 component is a subordinate of the calendar component; SIBLING to 1142 indicate that the referenced calendar component is a peer of the 1143 calendar component. If this parameter is not specified on an 1144 allowable property, the default relationship type is PARENT. 1145 Applications MUST treat x-name and iana-token value they don't 1146 recognized the same way as they would the PARENT value. 1148 Example: 1150 RELATED-TO;RELTYPE=SIBLING:19960401-080045-4000F192713@ 1151 example.com 1153 3.2.16. Participation Role 1155 Parameter Name: ROLE 1157 Purpose: To specify the participation role for the calendar user 1158 specified by the property. 1160 Format Definition: This property parameter is defined by the 1161 following notation: 1163 roleparam = "ROLE" "=" 1164 ("CHAIR" ; Indicates chair of the 1165 ; calendar entity 1166 / "REQ-PARTICIPANT" ; Indicates a participant whose 1167 ; participation is required 1168 / "OPT-PARTICIPANT" ; Indicates a participant whose 1169 ; participation is optional 1170 / "NON-PARTICIPANT" ; Indicates a participant who 1171 ; is copied for information 1172 ; purposes only 1173 / x-name ; Experimental role 1174 / iana-token) ; Other IANA role 1175 ; Default is REQ-PARTICIPANT 1177 Description: This parameter can be specified on properties with a 1178 CAL-ADDRESS value type. The parameter specifies the participation 1179 role for the calendar user specified by the property in the group 1180 schedule calendar component. If not specified on a property that 1181 allows this parameter, the default value is REQ-PARTICIPANT. 1182 Applications MUST treat x-name and iana-token value they don't 1183 recognized the same way as they would the REQ-PARTICIPANT value. 1185 Example: 1187 ATTENDEE;ROLE=CHAIR:mailto:mrbig@example.com 1189 3.2.17. RSVP Expectation 1191 Parameter Name: RSVP 1193 Purpose: To specify whether there is an expectation of a favor of a 1194 reply from the calendar user specified by the property value. 1196 Format Definition: This property parameter is defined by the 1197 following notation: 1199 rsvpparam = "RSVP" "=" ("TRUE" / "FALSE") 1200 ; Default is FALSE 1202 Description: This parameter can be specified on properties with a 1203 CAL-ADDRESS value type. The parameter identifies the expectation 1204 of a reply from the calendar user specified by the property value. 1205 This parameter is used by the "Organizer" to request a 1206 participation status reply from an "Attendee" of a group scheduled 1207 event or to-do. If not specified on a property that allows this 1208 parameter, the default value is FALSE. 1210 Example: 1212 ATTENDEE;RSVP=TRUE:mailto:jsmith@example.com 1214 3.2.18. Sent By 1216 Parameter Name: SENT-BY 1218 Purpose: To specify the calendar user that is acting on behalf of 1219 the calendar user specified by the property. 1221 Format Definition: This property parameter is defined by the 1222 following notation: 1224 sentbyparam = "SENT-BY" "=" DQUOTE cal-address DQUOTE 1226 Description: This parameter can be specified on properties with a 1227 CAL-ADDRESS value type. The parameter specifies the calendar user 1228 that is acting on behalf of the calendar user specified by the 1229 property. The parameter value MUST be a mailto URI as defined in 1230 [RFC2368]. The individual calendar address parameter values MUST 1231 each be specified in a quoted-string. 1233 Example: 1235 ORGANIZER;SENT-BY="mailto:sray@example.com":mailto: 1236 jsmith@example.com 1238 3.2.19. Time Zone Identifier 1240 Parameter Name: TZID 1242 Purpose: To specify the identifier for the time zone definition for 1243 a time component in the property value. 1245 Format Definition: This property parameter is defined by the 1246 following notation: 1248 tzidparam = "TZID" "=" [tzidprefix] paramtext 1249 tzidprefix = "/" 1251 Description: This parameter MUST be specified on the "DTSTART", 1252 "DTEND", "DUE", "EXDATE" and "RDATE" properties when either a 1253 DATE-TIME or TIME value type is specified and when the value is 1254 not either a UTC or a "floating" time. Refer to the DATE-TIME or 1255 TIME value type definition for a description of UTC and "floating 1256 time" formats. This property parameter specifies a text value 1257 which uniquely identifies the "VTIMEZONE" calendar component to be 1258 used when evaluating the time portion of the property. The value 1259 of the "TZID" property parameter will be equal to the value of the 1260 "TZID" property for the matching time zone definition. An 1261 individual "VTIMEZONE" calendar component MUST be specified for 1262 each unique "TZID" parameter value specified in the iCalendar 1263 object. 1265 The parameter MUST be specified on properties with a DATE-TIME 1266 value if the DATE-TIME is not either a UTC or a "floating" time. 1268 The presence of the SOLIDUS character (US-ASCII decimal 47) as a 1269 prefix, indicates that this "TZID" represents a unique ID in a 1270 globally defined time zone registry (when such registry is 1271 defined). 1273 Note: This document does not define a naming convention for 1274 time zone identifiers. Implementers may want to use the naming 1275 conventions defined in existing time zone specifications such 1276 as the public-domain TZ database [TZDB]. The specification of 1277 globally unique time zone identifiers is not addressed by this 1278 document and is left for future study. 1280 The following are examples of this property parameter: 1282 DTSTART;TZID=America/New_York:19980119T020000 1284 DTEND;TZID=America/New_York:19980119T030000 1286 The "TZID" property parameter MUST NOT be applied to DATE 1287 properties, and DATE-TIME or TIME properties whose time values are 1288 specified in UTC. 1290 The use of local time in a DATE-TIME or TIME value without the 1291 "TZID" property parameter is to be interpreted as floating time, 1292 regardless of the existence of "VTIMEZONE" calendar components in 1293 the iCalendar object. 1295 For more information see the sections on the value types DATE-TIME 1296 and TIME. 1298 3.2.20. Value Data Types 1300 Parameter Name: VALUE 1302 Purpose: To explicitly specify the value type format for a property 1303 value. 1305 Format Definition: This property parameter is defined by the 1306 following notation: 1308 valuetypeparam = "VALUE" "=" valuetype 1310 valuetype = ("BINARY" 1311 / "BOOLEAN" 1312 / "CAL-ADDRESS" 1313 / "DATE" 1314 / "DATE-TIME" 1315 / "DURATION" 1316 / "FLOAT" 1317 / "INTEGER" 1318 / "PERIOD" 1319 / "RECUR" 1320 / "TEXT" 1321 / "TIME" 1322 / "URI" 1323 / "UTC-OFFSET" 1324 / x-name 1325 ; Some experimental iCalendar value type. 1326 / iana-token) 1327 ; Some other IANA registered iCalendar value type. 1329 Description: This parameter specifies the value type and format of 1330 the property value. The property values MUST be of a single value 1331 type. For example, a "RDATE" property cannot have a combination 1332 of DATE-TIME and TIME value types. 1334 If the property's value is the default value type, then this 1335 parameter need not be specified. However, if the property's 1336 default value type is overridden by some other allowable value 1337 type, then this parameter MUST be specified. 1339 Applications MUST preserve the value data for x-name and iana- 1340 token values that they don't recognize without attempting to 1341 interpret or parse the value data. 1343 3.3. Property Value Data Types 1345 The properties in an iCalendar object are strongly typed. The 1346 definition of each property restricts the value to be one of the 1347 value data types, or simply value types, defined in this section. 1348 The value type for a property will either be specified implicitly as 1349 the default value type or will be explicitly specified with the 1350 "VALUE" parameter. If the value type of a property is one of the 1351 alternate valid types, then it MUST be explicitly specified with the 1352 "VALUE" parameter. 1354 3.3.1. Binary 1356 Value Name: BINARY 1358 Purpose: This value type is used to identify properties that contain 1359 a character encoding of inline binary data. For example, an 1360 inline attachment of a document might be included in an iCalendar 1361 object. 1363 Format Definition: This value type is defined by the following 1364 notation: 1366 binary = *(4b-char) [b-end] 1367 ; A "BASE64" encoded character string, as defined by [RFC4648]. 1369 b-end = (2b-char "==") / (3b-char "=") 1371 b-char = ALPHA / DIGIT / "+" / "/" 1373 Description: Property values with this value type MUST also include 1374 the inline encoding parameter sequence of ";ENCODING=BASE64". 1375 That is, all inline binary data MUST first be character encoded 1376 using the "BASE64" encoding method defined in [RFC2045]. No 1377 additional content value encoding (i.e., BACKSLASH character 1378 encoding, see Section 3.3.11) is defined for this value type. 1380 Example: The following is an example of a "BASE64" encoded binary 1381 value data. 1383 ATTACH;FMTTYPE=image/vnd.microsoft.icon;ENCODING=BASE64;VALUE 1384 =BINARY:AAABAAEAEBAQAAEABAAoAQAAFgAAACgAAAAQAAAAIAAAAAEABAAA 1385 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAgIAAAICAgADAwMAA////AAAA 1386 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 1387 AAAAAAAAAAAAAAAAAAAAAAMwAAAAAAABNEMQAAAAAAAkQgAAAAAAJEREQgAA 1388 ACECQ0QgEgAAQxQzM0E0AABERCRCREQAADRDJEJEQwAAAhA0QwEQAAAAAERE 1389 AAAAAAAAREQAAAAAAAAkQgAAAAAAAAMgAAAAAAAAAAAAAAAAAAAAAAAAAAAA 1390 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 1391 AAAAAAAAAAAA 1393 3.3.2. Boolean 1395 Value Name: BOOLEAN 1397 Purpose: This value type is used to identify properties that contain 1398 either a "TRUE" or "FALSE" Boolean value. 1400 Format Definition: This value type is defined by the following 1401 notation: 1403 boolean = "TRUE" / "FALSE" 1405 Description: These values are case insensitive text. No additional 1406 content value encoding (i.e., BACKSLASH character encoding, see 1407 Section 3.3.11) is defined for this value type. 1409 Example: The following is an example of a hypothetical property that 1410 has a BOOLEAN value type: 1412 TRUE 1414 3.3.3. Calendar User Address 1416 Value Name: CAL-ADDRESS 1418 Purpose: This value type is used to identify properties that contain 1419 a calendar user address. 1421 Format Definition: This value type is defined by the following 1422 notation: 1424 cal-address = uri 1426 Description: The value is a URI as defined by [RFC3986] or any other 1427 IANA registered form for a URI. When used to address an Internet 1428 email transport address for a calendar user, the value MUST be a 1429 mailto URI, as defined by [RFC2368]. No additional content value 1430 encoding (i.e., BACKSLASH character encoding, see Section 3.3.11) 1431 is defined for this value type. 1433 Example: 1435 mailto:jane_doe@example.com 1437 3.3.4. Date 1439 Value Name: DATE 1441 Purpose: This value type is used to identify values that contain a 1442 calendar date. 1444 Format Definition: This value type is defined by the following 1445 notation: 1447 date = date-value 1449 date-value = date-fullyear date-month date-mday 1450 date-fullyear = 4DIGIT 1451 date-month = 2DIGIT ;01-12 1452 date-mday = 2DIGIT ;01-28, 01-29, 01-30, 01-31 1453 ;based on month/year 1455 Description: If the property permits, multiple "date" values are 1456 specified as a COMMA character (US-ASCII decimal 44) separated 1457 list of values. The format for the value type is based on the 1458 [ISO.8601.2004] complete representation, basic format for a 1459 calendar date. The textual format specifies a four-digit year, 1460 two-digit month, and two-digit day of the month. There are no 1461 separator characters between the year, month and day component 1462 text. 1464 No additional content value encoding (i.e., BACKSLASH character 1465 encoding, see Section 3.3.11) is defined for this value type. 1467 Example: The following represents July 14, 1997: 1469 19970714 1471 3.3.5. Date-Time 1473 Value Name: DATE-TIME 1475 Purpose: This value type is used to identify values that specify a 1476 precise calendar date and time of day. 1478 Format Definition: This value type is defined by the following 1479 notation: 1481 date-time = date "T" time ;As specified in the date and time 1482 ;value definitions 1484 Description: If the property permits, multiple "date-time" values 1485 are specified as a COMMA character (US-ASCII decimal 44) separated 1486 list of values. No additional content value encoding (i.e., 1487 BACKSLASH character encoding, see Section 3.3.11) is defined for 1488 this value type. 1490 The "DATE-TIME" value type is used to identify values that contain 1491 a precise calendar date and time of day. The format is based on 1492 the [ISO.8601.2004] complete representation, basic format for a 1493 calendar date and time of day. The text format is a concatenation 1494 of the "date", followed by the LATIN CAPITAL LETTER T character 1495 (US-ASCII decimal 84) time designator, followed by the "time" 1496 format. 1498 The "DATE-TIME" value type expresses time values in three forms: 1500 The form of date and time with UTC offset MUST NOT be used. For 1501 example, the following is not valid for a date-time value: 1503 19980119T230000-0800 ;Invalid time format 1505 FORM #1: DATE WITH LOCAL TIME 1507 The date with local time form is simply a DATE-TIME value that 1508 does not contain the UTC designator nor does it reference a time 1509 zone. For example, the following represents January 18, 1998, at 1510 11 PM: 1512 19980118T230000 1514 DATE-TIME values of this type are said to be "floating" and are 1515 not bound to any time zone in particular. They are used to 1516 represent the same hour, minute, and second value regardless of 1517 which time zone is currently being observed. For example, an 1518 event can be defined that indicates that an individual will be 1519 busy from 11:00 AM to 1:00 PM every day, no matter which time zone 1520 the person is in. In these cases, a local time can be specified. 1521 The recipient of an iCalendar object with a property value 1522 consisting of a local time, without any relative time zone 1523 information, SHOULD interpret the value as being fixed to whatever 1524 time zone the "ATTENDEE" is in at any given moment. This means 1525 that two "Attendees", in different time zones, receiving the same 1526 event definition as a floating time, may be participating in the 1527 event at different actual times. Floating time SHOULD only be 1528 used where that is the reasonable behavior. 1530 In most cases, a fixed time is desired. To properly communicate a 1531 fixed time in a property value, either UTC time or local time with 1532 time zone reference MUST be specified. 1534 The use of local time in a DATE-TIME value without the "TZID" 1535 property parameter is to be interpreted as floating time, 1536 regardless of the existence of "VTIMEZONE" calendar components in 1537 the iCalendar object. 1539 FORM #2: DATE WITH UTC TIME 1541 The date with UTC time, or absolute time, is identified by a LATIN 1542 CAPITAL LETTER Z suffix character (US-ASCII decimal 90), the UTC 1543 designator, appended to the time value. For example, the 1544 following represents January 19, 1998, at 0700 UTC: 1546 19980119T070000Z 1548 The "TZID" property parameter MUST NOT be applied to DATE-TIME 1549 properties whose time values are specified in UTC. 1551 FORM #3: DATE WITH LOCAL TIME AND TIME ZONE REFERENCE 1553 The date and local time with reference to time zone information is 1554 identified by the use the "TZID" property parameter to reference 1555 the appropriate time zone definition. "TZID" is discussed in 1556 detail in Section 3.2.19. For example, the following represents 1557 2:00 A.M. in New York on Janurary 19, 1998: 1559 TZID=America/New_York:19980119T020000 1561 If, based on the definition of the referenced time zone, the local 1562 time described occurs more than once (when changing from daylight 1563 to standard time), the DATE-TIME value refers to the first 1564 occurence of the referenced time. Thus, TZID=America/ 1565 New_York:20071104T013000 indicates November 4, 2007 at 1:30 A.M. 1566 EDT (UTC-04:00). If the local time described does not occur (when 1567 changing from standard to daylight time), the DATE-TIME value is 1568 interpreted using the UTC offset before the gap in local times. 1569 Thus, TZID=America/New_York:20070311T023000 indicates March 11, 1570 2007 at 3:30 A.M. EDT (UTC-04:00), one hour after 1:30 A.M. EST 1571 (UTC-05:00). 1573 A time value MUST only specify the second 60 when specifying a 1574 positive leap second. For example: 1576 19970630T235960Z 1578 Implementations which do not support leap seconds SHOULD interpret 1579 the second 60 as equivalent to the second 59. 1581 Example: The following represents July 14, 1997, at 1:30 PM in New 1582 York City in each of the three time formats, using the "DTSTART" 1583 property. 1585 DTSTART:19970714T133000 ; Local time 1586 DTSTART:19970714T173000Z ; UTC time 1587 DTSTART;TZID=America/New_York:19970714T133000 1588 ; Local time and time 1589 ; zone reference 1591 3.3.6. Duration 1593 Value Name: DURATION 1595 Purpose: This value type is used to identify properties that contain 1596 a duration of time. 1598 Format Definition: This value type is defined by the following 1599 notation: 1601 dur-value = (["+"] / "-") "P" (dur-date / dur-time / dur-week) 1603 dur-date = dur-day [dur-time] 1604 dur-time = "T" (dur-hour / dur-minute / dur-second) 1605 dur-week = 1*DIGIT "W" 1606 dur-hour = 1*DIGIT "H" [dur-minute] 1607 dur-minute = 1*DIGIT "M" [dur-second] 1608 dur-second = 1*DIGIT "S" 1609 dur-day = 1*DIGIT "D" 1611 Description: If the property permits, multiple "duration" values are 1612 specified by a COMMA character (US-ASCII decimal 44) separated 1613 list of values. The format is based on the [ISO.8601.2004] 1614 complete representation basic format with designators for the 1615 duration of time. The format can represent nominal durations 1616 (weeks and days) and accurate durations (hours, minutes, and 1617 seconds). Note that unlike [ISO.8601.2004] this value type 1618 doesn't support the "Y" and "M" designators to specify durations 1619 in terms of years and months. 1621 The duration of a week or a day depends on its position in the 1622 calendar. In the case of discontinuities in the time scale, such 1623 as the change from standard time to daylight time and back, the 1624 computation of the exact duration requires the substraction or 1625 addition of the change of duration of the discontinuity. Leap 1626 seconds MUST NOT be considered when computing an exact duration. 1627 When computing an exact duration, the greatest order time 1628 components MUST be added first, that is, the number of days MUST 1629 be added first, followed by the number of hours, number of 1630 minutes, and number of seconds. 1632 Negative durations are typically used to schedule an alarm to 1633 trigger before an associated time (see Section 3.8.6.3). 1635 No additional content value encoding (i.e., BACKSLASH character 1636 encoding, see Section 3.3.11) are defined for this value type. 1638 Example: A duration of 15 days, 5 hours and 20 seconds would be: 1640 P15DT5H0M20S 1642 A duration of 7 weeks would be: 1644 P7W 1646 3.3.7. Float 1648 Value Name: FLOAT 1650 Purpose: This value type is used to identify properties that contain 1651 a real number value. 1653 Format Definition: This value type is defined by the following 1654 notation: 1656 float = (["+"] / "-") 1*DIGIT ["." 1*DIGIT] 1658 Description: If the property permits, multiple "float" values are 1659 specified by a COMMA character (US-ASCII decimal 44) separated 1660 list of values. 1662 No additional content value encoding (i.e., BACKSLASH character 1663 encoding, see Section 3.3.11) is defined for this value type. 1665 Example: 1667 1000000.0000001 1668 1.333 1669 -3.14 1671 3.3.8. Integer 1673 Value Name: INTEGER 1675 Purpose: This value type is used to identify properties that contain 1676 a signed integer value. 1678 Format Definition: This value type is defined by the following 1679 notation: 1681 integer = (["+"] / "-") 1*DIGIT 1683 Description: If the property permits, multiple "integer" values are 1684 specified by a COMMA character (US-ASCII decimal 44) separated 1685 list of values. The valid range for "integer" is -2147483648 to 1686 2147483647. If the sign is not specified, then the value is 1687 assumed to be positive. 1689 No additional content value encoding (i.e., BACKSLASH character 1690 encoding, see Section 3.3.11) is defined for this value type. 1692 Example: 1694 1234567890 1695 -1234567890 1696 +1234567890 1697 432109876 1699 3.3.9. Period of Time 1701 Value Name: PERIOD 1703 Purpose: This value type is used to identify values that contain a 1704 precise period of time. 1706 Format Definition: This value type is defined by the following 1707 notation: 1709 period = period-explicit / period-start 1711 period-explicit = date-time "/" date-time 1712 ; [ISO.8601.2004] complete representation basic format for a 1713 ; period of time consisting of a start and end. The start MUST 1714 ; be before the end. 1716 period-start = date-time "/" dur-value 1717 ; [ISO.8601.2004] complete representation basic format for a 1718 ; period of time consisting of a start and positive duration 1719 ; of time. 1721 Description: If the property permits, multiple "period" values are 1722 specified by a COMMA character (US-ASCII decimal 44) separated 1723 list of values. There are two forms of a period of time. First, 1724 a period of time is identified by its start and its end. This 1725 format is based on the [ISO.8601.2004] complete representation, 1726 basic format for "DATE-TIME" start of the period, followed by a 1727 SOLIDUS character (US-ASCII decimal 47), followed by the "DATE- 1728 TIME" of the end of the period. The start of the period MUST be 1729 before the end of the period. Second, a period of time can also 1730 be defined by a start and a positive duration of time. The format 1731 is based on the [ISO.8601.2004] complete representation, basic 1732 format for the "DATE-TIME" start of the period, followed by a 1733 SOLIDUS character (US-ASCII decimal 47), followed by the 1734 [ISO.8601.2004] basic format for "DURATION" of the period. 1736 Example: The period starting at 18:00:00 UTC, on January 1, 1997 and 1737 ending at 07:00:00 UTC on January 2, 1997 would be: 1739 19970101T180000Z/19970102T070000Z 1741 The period start at 18:00:00 on January 1, 1997 and lasting 5 1742 hours and 30 minutes would be: 1744 19970101T180000Z/PT5H30M 1746 No additional content value encoding (i.e., BACKSLASH character 1747 encoding, see Section 3.3.11) is defined for this value type. 1749 3.3.10. Recurrence Rule 1751 Value Name: RECUR 1753 Purpose: This value type is used to identify properties that contain 1754 a recurrence rule specification. 1756 Format Definition: This value type is defined by the following 1757 notation: 1759 recur = recur-rule-part *( ";" recur-rule-part ) 1760 ; 1761 ; The rule parts are not ordered in any 1762 ; particular sequence 1763 ; 1764 ; The FREQ rule part is REQUIRED, 1765 ; but MUST NOT occur more than once 1766 ; 1767 ; The UNTIL or COUNT rule parts are OPTIONAL, 1768 ; but they MUST NOT occur in the same 'recur' 1769 ; 1770 ; The other rule parts are OPTIONAL, 1771 ; but MUST NOT occur more than once 1773 recur-rule-part = ( "FREQ" "=" freq ) 1774 / ( "UNTIL" "=" enddate ) 1775 / ( "COUNT" "=" 1*DIGIT ) 1776 / ( "INTERVAL" "=" 1*DIGIT ) 1777 / ( "BYSECOND" "=" byseclist ) 1778 / ( "BYMINUTE" "=" byminlist ) 1779 / ( "BYHOUR" "=" byhrlist ) 1780 / ( "BYDAY" "=" bywdaylist ) 1781 / ( "BYMONTHDAY" "=" bymodaylist ) 1782 / ( "BYYEARDAY" "=" byyrdaylist ) 1783 / ( "BYWEEKNO" "=" bywknolist ) 1784 / ( "BYMONTH" "=" bymolist ) 1785 / ( "BYSETPOS" "=" bysplist ) 1786 / ( "WKST" "=" weekday ) 1788 freq = "SECONDLY" / "MINUTELY" / "HOURLY" / "DAILY" 1789 / "WEEKLY" / "MONTHLY" / "YEARLY" 1791 enddate = date / date-time 1793 byseclist = ( seconds *("," seconds) ) 1795 seconds = 1*2DIGIT ;0 to 60 1797 byminlist = ( minutes *("," minutes) ) 1799 minutes = 1*2DIGIT ;0 to 59 1801 byhrlist = ( hour *("," hour) ) 1803 hour = 1*2DIGIT ;0 to 23 1805 bywdaylist = ( weekdaynum *("," weekdaynum) ) 1807 weekdaynum = [[plus / minus] ordwk] weekday 1809 plus = "+" 1811 minus = "-" 1813 ordwk = 1*2DIGIT ;1 to 53 1814 weekday = "SU" / "MO" / "TU" / "WE" / "TH" / "FR" / "SA" 1815 ;Corresponding to SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, 1816 ;FRIDAY, and SATURDAY days of the week. 1818 bymodaylist = ( monthdaynum *("," monthdaynum) ) 1820 monthdaynum = [plus / minus] ordmoday 1822 ordmoday = 1*2DIGIT ;1 to 31 1824 byyrdaylist = ( yeardaynum *("," yeardaynum) ) 1826 yeardaynum = [plus / minus] ordyrday 1828 ordyrday = 1*3DIGIT ;1 to 366 1830 bywknolist = ( weeknum *("," weeknum) ) 1832 weeknum = [plus / minus] ordwk 1834 bymolist = ( monthnum *("," monthnum) ) 1836 monthnum = 1*2DIGIT ;1 to 12 1838 bysplist = ( setposday *("," setposday) ) 1840 setposday = yeardaynum 1842 Description: This value type is a structured value consisting of a 1843 list of one or more recurrence grammar parts. Each rule part is 1844 defined by a NAME=VALUE pair. The rule parts are separated from 1845 each other by the SEMICOLON character (US-ASCII decimal 59). The 1846 rule parts are not ordered in any particular sequence. Individual 1847 rule parts MUST only be specified once. Compliant applications 1848 MUST accept rule parts ordered in any sequence, but to ensure 1849 backward compatibility with applications that pre-date this 1850 revision of iCalendar the FREQ rule part MUST be the first rule 1851 part specified in a RECUR value. 1853 The FREQ rule part identifies the type of recurrence rule. This 1854 rule part MUST be specified in the recurrence rule. Valid values 1855 include SECONDLY, to specify repeating events based on an interval 1856 of a second or more; MINUTELY, to specify repeating events based 1857 on an interval of a minute or more; HOURLY, to specify repeating 1858 events based on an interval of an hour or more; DAILY, to specify 1859 repeating events based on an interval of a day or more; WEEKLY, to 1860 specify repeating events based on an interval of a week or more; 1861 MONTHLY, to specify repeating events based on an interval of a 1862 month or more; and YEARLY, to specify repeating events based on an 1863 interval of a year or more. 1865 The INTERVAL rule part contains a positive integer representing at 1866 which intervals the recurrence rule repeats. The default value is 1867 "1", meaning every second for a SECONDLY rule, every minute for a 1868 MINUTELY rule, every hour for an HOURLY rule, every day for a 1869 DAILY rule, every week for a WEEKLY rule, every month for a 1870 MONTHLY rule, and every year for a YEARLY rule. For example, 1871 within a DAILY rule, a value of "8" means every eight days. 1873 The UNTIL rule part defines a DATE or DATE-TIME value which bounds 1874 the recurrence rule in an inclusive manner. If the value 1875 specified by UNTIL is synchronized with the specified recurrence, 1876 this DATE or DATE-TIME becomes the last instance of the 1877 recurrence. The value of the UNTIL rule part MUST have the same 1878 value type as the "DTSTART" property. Furthermore, if the 1879 "DTSTART" property is specified as a date with local time, then 1880 the UNTIL rule part MUST also be specified as a date with local 1881 time. If the "DTSTART" property is specified as a date with UTC 1882 time or a date with local time and time zone reference, then the 1883 UNTIL rule part MUST be specified as a date with UTC time. In the 1884 case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL 1885 rule part MUST always be specified as a date with UTC time. If 1886 specified as a DATE-TIME value, then it MUST be specified in a UTC 1887 time format. If not present, and the COUNT rule part is also not 1888 present, the "RRULE" is considered to repeat forever. 1890 The COUNT rule part defines the number of occurrences at which to 1891 range-bound the recurrence. The "DTSTART" property value always 1892 counts as the first occurrence. 1894 The BYSECOND rule part specifies a COMMA character (US-ASCII 1895 decimal 44) separated list of seconds within a minute. Valid 1896 values are 0 to 60. The BYMINUTE rule part specifies a COMMA 1897 character (US-ASCII decimal 44) separated list of minutes within 1898 an hour. Valid values are 0 to 59. The BYHOUR rule part 1899 specifies a COMMA character (US-ASCII decimal 44) separated list 1900 of hours of the day. Valid values are 0 to 23. The BYSECOND, 1901 BYMINUTE and BYHOUR rule parts MUST NOT be specified when the 1902 associated "DTSTART" property has a DATE value type. These rule 1903 parts MUST be ignored in RECUR value that violate the above 1904 requirement (e.g., generated by applications that pre-date this 1905 revision of iCalendar). 1907 The BYDAY rule part specifies a COMMA character (US-ASCII decimal 1908 44) separated list of days of the week; SU indicates Sunday; MO 1909 indicates Monday; TU indicates Tuesday; WE indicates Wednesday; TH 1910 indicates Thursday; FR indicates Friday; SA indicates Saturday. 1912 Each BYDAY value can also be preceded by a positive (+n) or 1913 negative (-n) integer. If present, this indicates the nth 1914 occurrence of a specific day within the MONTHLY or YEARLY "RRULE". 1915 For example, within a MONTHLY rule, +1MO (or simply 1MO) 1916 represents the first Monday within the month, whereas -1MO 1917 represents the last Monday of the month. The numeric value in a 1918 BYDAY rule part with the FREQ rule part set to YEARLY corresponds 1919 to an offset within the month when the BYMONTH rule part is 1920 present, and corresponds to an offset within the year when the 1921 BYWEEKNO or BYMONTH rule parts are present. If an integer 1922 modifier is not present, it means all days of this type within the 1923 specified frequency. For example, within a MONTHLY rule, MO 1924 represents all Mondays within the month. The BYDAY rule part MUST 1925 NOT be specified with a numeric value when the FREQ rule part is 1926 not set to MONTHLY or YEARLY. Furthermore, the BYDAY rule part 1927 MUST NOT be specified with a numeric value with the FREQ rule part 1928 set to YEARLY when the BYWEEKNO rule part is specified. 1930 The BYMONTHDAY rule part specifies a COMMA character (US-ASCII 1931 decimal 44) separated list of days of the month. Valid values are 1932 1 to 31 or -31 to -1. For example, -10 represents the tenth to 1933 the last day of the month. The BYMONTHDAY rule part MUST NOT be 1934 specified when the FREQ rule part is set to WEEKLY. 1936 The BYYEARDAY rule part specifies a COMMA character (US-ASCII 1937 decimal 44) separated list of days of the year. Valid values are 1938 1 to 366 or -366 to -1. For example, -1 represents the last day 1939 of the year (December 31st) and -306 represents the 306th to the 1940 last day of the year (March 1st). The BYYEARDAY rule part MUST 1941 NOT be specified when the FREQ rule part is set to DAILY, WEEKLY, 1942 or MONTHLY. 1944 The BYWEEKNO rule part specifies a COMMA character (US-ASCII 1945 decimal 44) separated list of ordinals specifying weeks of the 1946 year. Valid values are 1 to 53 or -53 to -1. This corresponds to 1947 weeks according to week numbering as defined in [ISO.8601.2004]. 1948 A week is defined as a seven day period, starting on the day of 1949 the week defined to be the week start (see WKST). Week number one 1950 of the calendar year is the first week which contains at least 1951 four (4) days in that calendar year. This rule part MUST NOT be 1952 used when the FREQ rule part is set to anything other than YEARLY. 1953 For example, 3 represents the third week of the year. 1955 Note: Assuming a Monday week start, week 53 can only occur when 1956 Thursday is January 1 or if it is a leap year and Wednesday is 1957 January 1. 1959 The BYMONTH rule part specifies a COMMA character (US-ASCII 1960 decimal 44) separated list of months of the year. Valid values 1961 are 1 to 12. 1963 The WKST rule part specifies the day on which the workweek starts. 1964 Valid values are MO, TU, WE, TH, FR, SA and SU. This is 1965 significant when a WEEKLY "RRULE" has an interval greater than 1, 1966 and a BYDAY rule part is specified. This is also significant when 1967 in a YEARLY "RRULE" when a BYWEEKNO rule part is specified. The 1968 default value is MO. 1970 The BYSETPOS rule part specifies a COMMA character (US-ASCII 1971 decimal 44) separated list of values which corresponds to the nth 1972 occurrence within the set of recurrence instances specified by the 1973 rule. BYSETPOS operates on a set of recurrence instances in one 1974 interval of the recurrence rule. For example, in a WEEKLY rule, 1975 the interval would be one week A set of recurrence instances 1976 starts at the beginning of the interval defined by the FREQ rule 1977 part. Valid values are 1 to 366 or -366 to -1. It MUST only be 1978 used in conjunction with another BYxxx rule part. For example 1979 "the last work day of the month" could be represented as: 1981 FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1 1983 Each BYSETPOS value can include a positive (+n) or negative (-n) 1984 integer. If present, this indicates the nth occurrence of the 1985 specific occurrence within the set of occurences specified by the 1986 rule. 1988 Recurrence rules may generate recurrence instances with invalid 1989 date (e.g., February 30) or nonexistent local time (e.g., 1:30 AM 1990 on a day where the local time is moved forward by an hour at 1:00 1991 AM). Such recurrence instances MUST be ignored and MUST NOT be 1992 counted as part of the recurrence set. 1994 Information, not contained in the rule, necessary to determine the 1995 various recurrence instance start time and dates are derived from 1996 the Start Time ("DTSTART") component attribute. For example, 1997 "FREQ=YEARLY;BYMONTH=1" doesn't specify a specific day within the 1998 month or a time. This information would be the same as what is 1999 specified for "DTSTART". 2001 BYxxx rule parts modify the recurrence in some manner. BYxxx rule 2002 parts for a period of time which is the same or greater than the 2003 frequency generally reduce or limit the number of occurrences of 2004 the recurrence generated. For example, "FREQ=DAILY;BYMONTH=1" 2005 reduces the number of recurrence instances from all days (if 2006 BYMONTH rule part is not present) to all days in January. BYxxx 2007 rule parts for a period of time less than the frequency generally 2008 increase or expand the number of occurrences of the recurrence. 2009 For example, "FREQ=YEARLY;BYMONTH=1,2" increases the number of 2010 days within the yearly recurrence set from 1 (if BYMONTH rule part 2011 is not present) to 2. 2013 If multiple BYxxx rule parts are specified, then after evaluating 2014 the specified FREQ and INTERVAL rule parts, the BYxxx rule parts 2015 are applied to the current set of evaluated occurrences in the 2016 following order: BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY, BYDAY, 2017 BYHOUR, BYMINUTE, BYSECOND and BYSETPOS; then COUNT and UNTIL are 2018 evaluated. 2020 The table below summarizes the dependency of BYxxx rule part 2021 expand or limit behaviour on the FREQ rule part value. 2023 The term "N/A" means that the corresponding BYxxx rule part MUST 2024 NOT be used with the corresponding FREQ value. 2026 BYDAY has some special behaviour depending on the FREQ value and 2027 this is described in separate notes below the table. 2029 +----------+--------+--------+-------+-------+------+-------+------+ 2030 | |SECONDLY|MINUTELY|HOURLY |DAILY |WEEKLY|MONTHLY|YEARLY| 2031 +----------+--------+--------+-------+-------+------+-------+------+ 2032 |BYMONTH |Limit |Limit |Limit |Limit |Limit |Limit |Expand| 2033 +----------+--------+--------+-------+-------+------+-------+------+ 2034 |BYWEEKNO |N/A |N/A |N/A |N/A |N/A |N/A |Expand| 2035 +----------+--------+--------+-------+-------+------+-------+------+ 2036 |BYYEARDAY |Limit |Limit |Limit |N/A |N/A |N/A |Expand| 2037 +----------+--------+--------+-------+-------+------+-------+------+ 2038 |BYMONTHDAY|Limit |Limit |Limit |Limit |N/A |Expand |Expand| 2039 +----------+--------+--------+-------+-------+------+-------+------+ 2040 |BYDAY |Limit |Limit |Limit |Limit |Expand|Note 1 |Note 2| 2041 +----------+--------+--------+-------+-------+------+-------+------+ 2042 |BYHOUR |Limit |Limit |Limit |Expand |Expand|Expand |Expand| 2043 +----------+--------+--------+-------+-------+------+-------+------+ 2044 |BYMINUTE |Limit |Limit |Expand |Expand |Expand|Expand |Expand| 2045 +----------+--------+--------+-------+-------+------+-------+------+ 2046 |BYSECOND |Limit |Expand |Expand |Expand |Expand|Expand |Expand| 2047 +----------+--------+--------+-------+-------+------+-------+------+ 2048 |BYSETPOS |Limit |Limit |Limit |Limit |Limit |Limit |Limit | 2049 +----------+--------+--------+-------+-------+------+-------+------+ 2051 Note 1: Limit if BYMONTHDAY is present, otherwise special expand 2052 for MONTHLY. 2054 Note 2: Limit if BYYEARDAY or BYMONTHDAY is present, otherwise 2055 special expand for WEEKLY if BYWEEKNO present, otherwise 2056 special expand for MONTHLY if BYMONTH present, otherwise 2057 special expand for YEARLY. 2059 Here is an example of evaluating multiple BYxxx rule parts. 2061 DTSTART;TZID=America/New_York:19970105T083000 2062 RRULE:FREQ=YEARLY;INTERVAL=2;BYMONTH=1;BYDAY=SU;BYHOUR=8,9; 2063 BYMINUTE=30 2065 First, the "INTERVAL=2" would be applied to "FREQ=YEARLY" to 2066 arrive at "every other year". Then, "BYMONTH=1" would be applied 2067 to arrive at "every January, every other year". Then, "BYDAY=SU" 2068 would be applied to arrive at "every Sunday in January, every 2069 other year". Then, "BYHOUR=8,9" would be applied to arrive at 2070 "every Sunday in January at 8 AM and 9 AM, every other year". 2071 Then, "BYMINUTE=30" would be applied to arrive at "every Sunday in 2072 January at 8:30 AM and 9:30 AM, every other year". Then, lacking 2073 information from "RRULE", the second is derived from "DTSTART", to 2074 end up in "every Sunday in January at 8:30:00 AM and 9:30:00 AM, 2075 every other year". Similarly, if the BYMINUTE, BYHOUR, BYDAY, 2076 BYMONTHDAY or BYMONTH rule part were missing, the appropriate 2077 minute, hour, day or month would have been retrieved from the 2078 "DTSTART" property. 2080 If the computed local start time of a recurrence instance does not 2081 exist, or occurs more than once, for the specified time zone, the 2082 time of the recurrence instance is interpreted in the same manner 2083 as an explicit DATE-TIME value describing that date and time, as 2084 specified in Section 3.3.5. 2086 No additional content value encoding (i.e., BACKSLASH character 2087 encoding, see Section 3.3.11) is defined for this value type. 2089 Example: The following is a rule which specifies 10 occurences which 2090 occur every other day: 2092 FREQ=DAILY;COUNT=10;INTERVAL=2 2094 There are other examples specified in Section 3.8.5.3. 2096 3.3.11. Text 2098 Value Name: TEXT 2100 Purpose: This value type is used to identify values that contain 2101 human readable text. 2103 Format Definition: This value type is defined by the following 2104 notation. 2106 text = *(TSAFE-CHAR / ":" / DQUOTE / ESCAPED-CHAR) 2107 ; Folded according to description above 2109 ESCAPED-CHAR = ("\\" / "\;" / "\," / "\N" / "\n") 2110 ; \\ encodes \, \N or \n encodes newline 2111 ; \; encodes ;, \, encodes , 2113 TSAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-5B / 2114 %x5D-7E / NON-US-ASCII 2115 ; Any character except CONTROLs not needed by the current 2116 ; character set, DQUOTE, ";", ":", "\", "," 2118 Description: If the property permits, multiple TEXT values are 2119 specified by a COMMA character (US-ASCII decimal 44) separated 2120 list of values. 2122 The language in which the text is represented can be controlled by 2123 the "LANGUAGE" property parameter. 2125 An intentional formatted text line break MUST only be included in 2126 a "TEXT" property value by representing the line break with the 2127 character sequence of BACKSLASH (US-ASCII decimal 92), followed by 2128 a LATIN SMALL LETTER N (US-ASCII decimal 110) or a LATIN CAPITAL 2129 LETTER N (US-ASCII decimal 78), that is "\n" or "\N". 2131 The "TEXT" property values may also contain special characters 2132 that are used to signify delimiters, such as a COMMA character for 2133 lists of values or a SEMICOLON character for structured values. 2134 In order to support the inclusion of these special characters in 2135 "TEXT" property values, they MUST be escaped with a BACKSLASH 2136 character. A BACKSLASH character (US-ASCII decimal 92) in a 2137 "TEXT" property value MUST be escaped with another BACKSLASH 2138 character. A COMMA character in a "TEXT" property value MUST be 2139 escaped with a BACKSLASH character (US-ASCII decimal 92). A 2140 SEMICOLON character in a "TEXT" property value MUST be escaped 2141 with a BACKSLASH character (US-ASCII decimal 92). However, a 2142 COLON character in a "TEXT" property value SHALL NOT be escaped 2143 with a BACKSLASH character. 2145 Example: A multiple line value of: 2147 Project XYZ Final Review 2148 Conference Room - 3B 2149 Come Prepared. 2151 would be represented as: 2153 Project XYZ Final Review\nConference Room - 3B\nCome Prepared. 2155 3.3.12. Time 2157 Value Name: TIME 2159 Purpose: This value type is used to identify values that contain a 2160 time of day. 2162 Format Definition: This value type is defined by the following 2163 notation: 2165 time = time-hour time-minute time-second [time-utc] 2167 time-hour = 2DIGIT ;00-23 2168 time-minute = 2DIGIT ;00-59 2169 time-second = 2DIGIT ;00-60 2170 ;The "60" value is used to account for positive "leap" seconds. 2172 time-utc = "Z" 2174 Description: If the property permits, multiple "time" values are 2175 specified by a COMMA character (US-ASCII decimal 44) separated 2176 list of values. No additional content value encoding (i.e., 2177 BACKSLASH character encoding, see Section 3.3.11) is defined for 2178 this value type. 2180 The "TIME" value type is used to identify values that contain a 2181 time of day. The format is based on the [ISO.8601.2004] complete 2182 representation, basic format for a time of day. The text format 2183 consists of a two-digit 24-hour of the day (i.e., values 00-23), 2184 two-digit minute in the hour (i.e., values 00-59), and two-digit 2185 seconds in the minute (i.e., values 00-60). The seconds value of 2186 60 MUST only be used to account for positive "leap" seconds. 2187 Fractions of a second are not supported by this format. 2189 In parallel to the "DATE-TIME" definition above, the "TIME" value 2190 type expresses time values in three forms: 2192 The form of time with UTC offset MUST NOT be used. For example, 2193 the following is not valid for a time value: 2195 230000-0800 ;Invalid time format 2197 FORM #1 LOCAL TIME 2199 The local time form is simply a time value that does not contain 2200 the UTC designator nor does it reference a time zone. For 2201 example, 11:00 PM: 2203 230000 2205 Time values of this type are said to be "floating" and are not 2206 bound to any time zone in particular. They are used to represent 2207 the same hour, minute, and second value regardless of which time 2208 zone is currently being observed. For example, an event can be 2209 defined that indicates that an individual will be busy from 11:00 2210 AM to 1:00 PM every day, no matter which time zone the person is 2211 in. In these cases, a local time can be specified. The recipient 2212 of an iCalendar object with a property value consisting of a local 2213 time, without any relative time zone information, SHOULD interpret 2214 the value as being fixed to whatever time zone the "ATTENDEE" is 2215 in at any given moment. This means that two "Attendees", may 2216 participate in the same event at different UTC times; floating 2217 time SHOULD only be used where that is reasonable behavior. 2219 In most cases, a fixed time is desired. To properly communicate a 2220 fixed time in a property value, either UTC time or local time with 2221 time zone reference MUST be specified. 2223 The use of local time in a TIME value without the "TZID" property 2224 parameter is to be interpreted as floating time, regardless of the 2225 existence of "VTIMEZONE" calendar components in the iCalendar 2226 object. 2228 FORM #2: UTC TIME 2230 UTC time, or absolute time, is identified by a LATIN CAPITAL 2231 LETTER Z suffix character (US-ASCII decimal 90), the UTC 2232 designator, appended to the time value. For example, the 2233 following represents 07:00 AM UTC: 2235 070000Z 2237 The "TZID" property parameter MUST NOT be applied to TIME 2238 properties whose time values are specified in UTC. 2240 FORM #3: LOCAL TIME AND TIME ZONE REFERENCE 2242 The local time with reference to time zone information form is 2243 identified by the use the "TZID" property parameter to reference 2244 the appropriate time zone definition. "TZID" is discussed in 2245 detail in Section 3.2.19. 2247 Example: The following represents 8:30 AM in New York in Winter, 2248 five hours behind UTC, in each of the three formats: 2250 083000 2251 133000Z 2253 TZID=America/New_York:083000 2255 3.3.13. URI 2256 Value Name: URI 2258 Purpose: This value type is used to identify values that contain a 2259 uniform resource identifier (URI) type of reference to the 2260 property value. 2262 Format Definition: This value type is defined by the following 2263 notation: 2265 uri = 2267 Description: This value type might be used to reference binary 2268 information, for values that are large, or otherwise undesirable 2269 to include directly in the iCalendar object. 2271 Property values with this value type MUST follow the generic URI 2272 syntax defined in [RFC3986]. 2274 When a property parameter value is a URI value type, the URI MUST 2275 be specified as a quoted-string value. 2277 No additional content value encoding (i.e., BACKSLASH character 2278 encoding, see Section 3.3.11) is defined for this value type. 2280 Example: The following is a URI for a network file: 2282 http://example.com/my-report.txt 2284 3.3.14. UTC Offset 2286 Value Name: UTC-OFFSET 2288 Purpose: This value type is used to identify properties that contain 2289 an offset from UTC to local time. 2291 Format Definition: This value type is defined by the following 2292 notation: 2294 utc-offset = time-numzone 2296 time-numzone = ("+" / "-") time-hour time-minute [time-second] 2298 Description: The PLUS SIGN (US-ASCII decimal 43) character MUST be 2299 specified for positive UTC offsets (i.e., ahead of UTC). The 2300 HYPHEN-MINUS character (US-ASCII decimal 45) MUST be specified for 2301 negative UTC offsets (i.e., behind of UTC). The value of "-0000" 2302 and "-000000" are not allowed. The time-second, if present, MUST 2303 NOT be 60; if absent, it defaults to zero. 2305 No additional content value encoding (i.e., BACKSLASH character 2306 encoding, see Section 3.3.11) is defined for this value type. 2308 Example: The following UTC offsets are given for standard time for 2309 New York (five hours behind UTC) and Geneva (one hour ahead of 2310 UTC): 2312 -0500 2314 +0100 2316 3.4. iCalendar Object 2318 The Calendaring and Scheduling Core Object is a collection of 2319 calendaring and scheduling information. Typically, this information 2320 will consist of an iCalendar stream with a single iCalendar object. 2321 However, multiple iCalendar objects can be sequentially grouped 2322 together in an iCalendar stream. The first line and last line of the 2323 iCalendar object MUST contain a pair of iCalendar object delimiter 2324 strings. The syntax for an iCalendar stream is as follows: 2326 icalstream = 1*icalobject 2328 icalobject = "BEGIN" ":" "VCALENDAR" CRLF 2329 icalbody 2330 "END" ":" "VCALENDAR" CRLF 2332 The following is a simple example of an iCalendar object: 2334 BEGIN:VCALENDAR 2335 VERSION:2.0 2336 PRODID:-//hacksw/handcal//NONSGML v1.0//EN 2337 BEGIN:VEVENT 2338 UID:19970610T172345Z-AF23B2@example.com 2339 DTSTAMP:19970610T172345Z 2340 DTSTART:19970714T170000Z 2341 DTEND:19970715T040000Z 2342 SUMMARY:Bastille Day Party 2343 END:VEVENT 2344 END:VCALENDAR 2346 3.5. Property 2348 A property is the definition of an individual attribute describing a 2349 calendar object or a calendar component. A property takes the form 2350 defined by the "contentline" notation defined in Section 3.1. 2352 The following is an example of a property: 2354 DTSTART:19960415T133000Z 2356 This memo imposes no ordering of properties within an iCalendar 2357 object. 2359 Property names, parameter names and enumerated parameter values are 2360 case insensitive. For example, the property name "DUE" is the same 2361 as "due" and "Due", DTSTART;TZID=America/New_York:19980714T120000 is 2362 the same as DtStart;TzID=America/New_York:19980714T120000. 2364 3.6. Calendar Components 2366 The body of the iCalendar object consists of a sequence of calendar 2367 properties and one or more calendar components. The calendar 2368 properties are attributes that apply to the calendar object as a 2369 whole. The calendar components are collections of properties that 2370 express a particular calendar semantic. For example, the calendar 2371 component can specify an event, a to-do, a journal entry, time zone 2372 information, free/busy time information, or an alarm. 2374 The body of the iCalendar object is defined by the following 2375 notation: 2377 icalbody = calprops component 2379 calprops = *( 2380 ; 2381 ; the following are REQUIRED, 2382 ; but MUST NOT occur more than once 2383 ; 2384 prodid / version / 2385 ; 2386 ; the following are OPTIONAL, 2387 ; but MUST NOT occur more than once 2388 ; 2389 calscale / method / 2390 ; 2391 ; the following are OPTIONAL, 2392 ; and MAY occur more than once 2393 ; 2394 x-prop / iana-prop 2395 ; 2396 ) 2398 component = 1*(eventc / todoc / journalc / freebusyc / 2399 timezonec / iana-comp / x-comp) 2401 iana-comp = "BEGIN" ":" iana-token CRLF 2402 1*contentline 2403 "END" ":" iana-token CRLF 2405 x-comp = "BEGIN" ":" x-name CRLF 2406 1*contentline 2407 "END" ":" x-name CRLF 2409 An iCalendar object MUST include the "PRODID" and "VERSION" calendar 2410 properties. In addition, it MUST include at least one calendar 2411 component. Special forms of iCalendar objects are possible to 2412 publish just busy time (i.e., only a "VFREEBUSY" calendar component) 2413 or time zone (i.e., only a "VTIMEZONE" calendar component) 2414 information. In addition, a complex iCalendar object that is used to 2415 capture a complete snapshot of the contents of a calendar is possible 2416 (e.g., composite of many different calendar components). More 2417 commonly, an iCalendar object will consist of just a single "VEVENT", 2418 "VTODO" or "VJOURNAL" calendar component. Applications MUST ignore 2419 x-comp and iana-comp they don't recognized. Applications that 2420 support importing iCalendar objects SHOULD support all of the 2421 component types defined in this document, and SHOULD NOT silently 2422 drop any components as that can lead to user data loss. 2424 3.6.1. Event Component 2426 Component Name: VEVENT 2428 Purpose: Provide a grouping of component properties that describe an 2429 event. 2431 Format Definition: A "VEVENT" calendar component is defined by the 2432 following notation: 2434 eventc = "BEGIN" ":" "VEVENT" CRLF 2435 eventprop *alarmc 2436 "END" ":" "VEVENT" CRLF 2438 eventprop = *( 2439 ; 2440 ; the following are REQUIRED, 2441 ; but MUST NOT occur more than once 2442 ; 2443 dtstamp / uid / 2444 ; 2445 ; the following is REQUIRED if the component 2446 ; appears in an iCalendar object that doesn't 2447 ; specify the "METHOD" property, otherwise it 2448 ; is OPTIONAL, in any case it MUST NOT occur 2449 ; more than once 2450 ; 2451 dtstart / 2452 ; 2453 ; the following are OPTIONAL, 2454 ; but MUST NOT occur more than once 2455 ; 2456 class / created / description / geo / 2457 last-mod / location / organizer / priority / 2458 seq / status / summary / transp / 2459 url / recurid / 2460 ; 2461 ; the following is OPTIONAL, 2462 ; but SHOULD NOT occur more than once 2463 ; 2464 rrule / 2465 ; 2466 ; either 'dtend' or 'duration' MAY appear in 2467 ; a 'eventprop', but 'dtend' and 'duration' 2468 ; MUST NOT occur in the same 'eventprop' 2469 ; 2470 dtend / duration / 2471 ; 2472 ; the following are OPTIONAL, 2473 ; and MAY occur more than once 2474 ; 2475 attach / attendee / categories / comment / 2476 contact / exdate / rstatus / related / 2477 resources / rdate / x-prop / iana-prop 2478 ; 2479 ) 2481 Description: A "VEVENT" calendar component is a grouping of 2482 component properties, and possibly including "VALARM" calendar 2483 components, that represents a scheduled amount of time on a 2484 calendar. For example, it can be an activity; such as a one-hour 2485 long, department meeting from 8:00 AM to 9:00 AM, tomorrow. 2486 Generally, an event will take up time on an individual calendar. 2487 Hence, the event will appear as an opaque interval in a search for 2488 busy time. Alternately, the event can have its Time Transparency 2489 set to "TRANSPARENT" in order to prevent blocking of the event in 2490 searches for busy time. 2492 The "VEVENT" is also the calendar component used to specify an 2493 anniversary or daily reminder within a calendar. These events 2494 have a DATE value type for the "DTSTART" property instead of the 2495 default value type of DATE-TIME. If such a "VEVENT" has a "DTEND" 2496 property, it MUST be specified as a DATE value also. The 2497 anniversary type of "VEVENT" can span more than one date (i.e., 2498 "DTEND" property value is set to a calendar date after the 2499 "DTSTART" property value). If such a "VEVENT" has a "DURATION" 2500 property, it MUST be specified as a "dur-day" or "dur-week" value. 2502 The "DTSTART" property for a "VEVENT" specifies the inclusive 2503 start of the event. For recurring events, it also specifies the 2504 very first instance in the recurrence set. The "DTEND" property 2505 for a "VEVENT" calendar component specifies the non-inclusive end 2506 of the event. For cases where a "VEVENT" calendar component 2507 specifies a "DTSTART" property with a DATE value type but no 2508 "DTEND" nor "DURATION" property, the event's duration is taken to 2509 be one day. For cases where a "VEVENT" calendar component 2510 specifies a "DTSTART" property with a DATE-TIME value type but no 2511 "DTEND" property, the event ends on the same calendar date and 2512 time of day specified by the "DTSTART" property. 2514 The "VEVENT" calendar component cannot be nested within another 2515 calendar component. However, "VEVENT" calendar components can be 2516 related to each other or to a "VTODO" or to a "VJOURNAL" calendar 2517 component with the "RELATED-TO" property. 2519 Example: The following is an example of the "VEVENT" calendar 2520 component used to represent a meeting that will also be opaque to 2521 searches for busy time: 2523 BEGIN:VEVENT 2524 UID:19970901T130000Z-123401@example.com 2525 DTSTAMP:19970901T130000Z 2526 DTSTART:19970903T163000Z 2527 DTEND:19970903T190000Z 2528 SUMMARY:Annual Employee Review 2529 CLASS:PRIVATE 2530 CATEGORIES:BUSINESS,HUMAN RESOURCES 2531 END:VEVENT 2533 The following is an example of the "VEVENT" calendar component 2534 used to represent a reminder that will not be opaque, but rather 2535 transparent, to searches for busy time: 2537 BEGIN:VEVENT 2538 UID:19970901T130000Z-123402@example.com 2539 DTSTAMP:19970901T130000Z 2540 DTSTART:19970401T163000Z 2541 DTEND:19970402T010000Z 2542 SUMMARY:Laurel is in sensitivity awareness class. 2543 CLASS:PUBLIC 2544 CATEGORIES:BUSINESS,HUMAN RESOURCES 2545 TRANSP:TRANSPARENT 2546 END:VEVENT 2548 The following is an example of the "VEVENT" calendar component 2549 used to represent an anniversary that will occur annually. 2551 BEGIN:VEVENT 2552 UID:19970901T130000Z-123403@example.com 2553 DTSTAMP:19970901T130000Z 2554 DTSTART;VALUE=DATE:19971102 2555 SUMMARY:Our Blissful Anniversary 2556 TRANSP:TRANSPARENT 2557 CLASS:CONFIDENTIAL 2558 CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION 2559 RRULE:FREQ=YEARLY 2560 END:VEVENT 2562 The following is an example of the "VEVENT" calendar component 2563 used to represent a multi-day event scheduled from June 28th, 2007 2564 to July 8th, 2007 inclusively. Note that the "DTEND" property is 2565 set to July 9th, 2007, since the "DTEND" property specifies the 2566 non-inclusive end of the event. 2568 BEGIN:VEVENT 2569 UID:20070423T123432Z-541111@example.com 2570 DTSTAMP:20070423T123432Z 2571 DTSTART;VALUE=DATE:20070628 2572 DTEND;VALUE=DATE:20070709 2573 SUMMARY:Festival International de Jazz de Montreal 2574 TRANSP:TRANSPARENT 2575 END:VEVENT 2577 3.6.2. To-do Component 2579 Component Name: VTODO 2581 Purpose: Provide a grouping of calendar properties that describe a 2582 to-do. 2584 Format Definition: A "VTODO" calendar component is defined by the 2585 following notation: 2587 todoc = "BEGIN" ":" "VTODO" CRLF 2588 todoprop *alarmc 2589 "END" ":" "VTODO" CRLF 2591 todoprop = *( 2592 ; 2593 ; the following are REQUIRED, 2594 ; but MUST NOT occur more than once 2595 ; 2596 dtstamp / uid / 2597 ; 2598 ; the following are OPTIONAL, 2599 ; but MUST NOT occur more than once 2600 ; 2601 class / completed / created / description / 2602 dtstart / geo / last-mod / location / organizer / 2603 percent / priority / recurid / seq / status / 2604 summary / url / 2605 ; 2606 ; the following is OPTIONAL, 2607 ; but SHOULD NOT occur more than once 2608 ; 2609 rrule / 2610 ; 2611 ; either 'due' or 'duration' MAY appear in 2612 ; a 'todoprop', but 'due' and 'duration' 2613 ; MUST NOT occur in the same 'todoprop'. 2614 ; If 'duration' appear in a 'todoprop', 2615 ; then 'dtstart' MUST also appear in 2616 ; the same 'todoprop'. 2617 ; 2618 due / duration / 2619 ; 2620 ; the following are OPTIONAL, 2621 ; and MAY occur more than once 2622 ; 2623 attach / attendee / categories / comment / contact / 2624 exdate / rstatus / related / resources / 2625 rdate / x-prop / iana-prop 2626 ; 2627 ) 2629 Description: A "VTODO" calendar component is a grouping of component 2630 properties and possibly "VALARM" calendar components that 2631 represent an action-item or assignment. For example, it can be 2632 used to represent an item of work assigned to an individual; such 2633 as "turn in travel expense today". 2635 The "VTODO" calendar component cannot be nested within another 2636 calendar component. However, "VTODO" calendar components can be 2637 related to each other or to a "VEVENT" or to a "VJOURNAL" calendar 2638 component with the "RELATED-TO" property. 2640 A "VTODO" calendar component without the "DTSTART" and "DUE" (or 2641 "DURATION") properties specifies a to-do that will be associated 2642 with each successive calendar date, until it is completed. 2644 Examples: The following is an example of a "VTODO" calendar 2645 component that needs to be completed before May 1st, 2007. On 2646 midnight May 1st, 2007 this to-do would be considered overdue. 2648 BEGIN:VTODO 2649 UID:20070313T123432Z-456553@example.com 2650 DTSTAMP:20070313T123432Z 2651 DUE;VALUE=DATE:20070501 2652 SUMMARY:Submit Quebec Income Tax Return for 2006 2653 CLASS:CONFIDENTIAL 2654 CATEGORIES:FAMILY,FINANCE 2655 STATUS:NEEDS-ACTION 2656 END:VTODO 2658 The following is an example of a "VTODO" calendar component that 2659 was due before 1:00 P.M. UTC on July 9th, 2007 and was completed 2660 on July 7th, 2007 at 10:00 A.M. UTC. 2662 BEGIN:VTODO 2663 UID:20070514T103211Z-123404@example.com 2664 DTSTAMP:20070514T103211Z 2665 DTSTART:20070514T110000Z 2666 DUE:20070709T130000Z 2667 COMPLETED:20070707T100000Z 2668 SUMMARY:Submit Revised Internet-Draft 2669 PRIORITY:1 2670 STATUS:NEEDS-ACTION 2671 END:VTODO 2673 3.6.3. Journal Component 2675 Component Name: VJOURNAL 2677 Purpose: Provide a grouping of component properties that describe a 2678 journal entry. 2680 Format Definition: A "VJOURNAL" calendar component is defined by the 2681 following notation: 2683 journalc = "BEGIN" ":" "VJOURNAL" CRLF 2684 jourprop 2685 "END" ":" "VJOURNAL" CRLF 2687 jourprop = *( 2688 ; 2689 ; the following are REQUIRED, 2690 ; but MUST NOT occur more than once 2691 ; 2692 dtstamp / uid / 2693 ; 2694 ; the following are OPTIONAL, 2695 ; but MUST NOT occur more than once 2696 ; 2697 class / created / dtstart / 2698 last-mod / organizer / recurid / seq / 2699 status / summary / url / 2700 ; 2701 ; the following is OPTIONAL, 2702 ; but SHOULD NOT occur more than once 2703 ; 2704 rrule / 2705 ; 2706 ; the following are OPTIONAL, 2707 ; and MAY occur more than once 2708 ; 2709 attach / attendee / categories / comment / 2710 contact / description / exdate / related / rdate / 2711 rstatus / x-prop / iana-prop 2712 ; 2713 ) 2715 Description: A "VJOURNAL" calendar component is a grouping of 2716 component properties that represent one or more descriptive text 2717 notes associated with a particular calendar date. The "DTSTART" 2718 property is used to specify the calendar date that the journal 2719 entry is associated with. Generally, it will have a DATE value 2720 data type, but it can also be used to specify a DATE-TIME value 2721 data type. Examples of a journal entry include a daily record of 2722 a legislative body or a journal entry of individual telephone 2723 contacts for the day or an ordered list of accomplishments for the 2724 day. The "VJOURNAL" calendar component can also be used to 2725 associate a document with a calendar date. 2727 The "VJOURNAL" calendar component does not take up time on a 2728 calendar. Hence, it does not play a role in free or busy time 2729 searches -- it is as though it has a time transparency value of 2730 TRANSPARENT. It is transparent to any such searches. 2732 The "VJOURNAL" calendar component cannot be nested within another 2733 calendar component. However, "VJOURNAL" calendar components can 2734 be related to each other or to a "VEVENT" or to a "VTODO" calendar 2735 component, with the "RELATED-TO" property. 2737 Example: The following is an example of the "VJOURNAL" calendar 2738 component: 2740 BEGIN:VJOURNAL 2741 UID:19970901T130000Z-123405@example.com 2742 DTSTAMP:19970901T130000Z 2743 DTSTART;VALUE=DATE:19970317 2744 SUMMARY:Staff meeting minutes 2745 DESCRIPTION:1. Staff meeting: Participants include Joe\, Lisa 2746 and Bob. Aurora project plans were reviewed. There is currentl 2747 y no budget reserves for this project. Lisa will escalate to 2748 management. Next meeting on Tuesday.\n 2749 2. Telephone Conference: ABC Corp. sales representative called 2750 to discuss new printer. Promised to get us a demo by Friday.\n 2751 3. Henry Miller (Handsoff Insurance): Car was totaled by tree. 2752 Is looking into a loaner car. 555-2323 (tel). 2753 END:VJOURNAL 2755 3.6.4. Free/Busy Component 2757 Component Name: VFREEBUSY 2759 Purpose: Provide a grouping of component properties that describe 2760 either a request for free/busy time, describe a response to a 2761 request for free/busy time or describe a published set of busy 2762 time. 2764 Format Definition: A "VFREEBUSY" calendar component is defined by 2765 the following notation: 2767 freebusyc = "BEGIN" ":" "VFREEBUSY" CRLF 2768 fbprop 2769 "END" ":" "VFREEBUSY" CRLF 2771 fbprop = *( 2772 ; 2773 ; the following are REQUIRED, 2774 ; but MUST NOT occur more than once 2775 ; 2776 dtstamp / uid / 2777 ; 2778 ; the following are OPTIONAL, 2779 ; but MUST NOT occur more than once 2780 ; 2781 contact / dtstart / dtend / 2782 organizer / url / 2783 ; 2784 ; the following are OPTIONAL, 2785 ; and MAY occur more than once 2786 ; 2787 attendee / comment / freebusy / rstatus / x-prop / 2788 iana-prop 2789 ; 2790 ) 2792 Description: A "VFREEBUSY" calendar component is a grouping of 2793 component properties that represents either a request for, a reply 2794 to a request for free or busy time information or a published set 2795 of busy time information. 2797 When used to request free/busy time information, the "ATTENDEE" 2798 property specifies the calendar users whose free/busy time is 2799 being requested; the "ORGANIZER" property specifies the calendar 2800 user who is requesting the free/busy time; the "DTSTART" and 2801 "DTEND" properties specify the window of time for which the free/ 2802 busy time is being requested; the "UID" and "DTSTAMP" properties 2803 are specified to assist in proper sequencing of multiple free/busy 2804 time requests. 2806 When used to reply to a request for free/busy time, the "ATTENDEE" 2807 property specifies the calendar user responding to the free/busy 2808 time request; the "ORGANIZER" property specifies the calendar user 2809 that originally requested the free/busy time; the "FREEBUSY" 2810 property specifies the free/busy time information (if it exists); 2811 and the "UID" and "DTSTAMP" properties are specified to assist in 2812 proper sequencing of multiple free/busy time replies. 2814 When used to publish busy time, the "ORGANIZER" property specifies 2815 the calendar user associated with the published busy time; the 2816 "DTSTART" and "DTEND" properties specify an inclusive time window 2817 that surrounds the busy time information; the "FREEBUSY" property 2818 specifies the published busy time information; and the "DTSTAMP" 2819 property specifies the date/time that iCalendar object was 2820 created. 2822 The "VFREEBUSY" calendar component cannot be nested within another 2823 calendar component. Multiple "VFREEBUSY" calendar components can 2824 be specified within an iCalendar object. This permits the 2825 grouping of Free/Busy information into logical collections, such 2826 as monthly groups of busy time information. 2828 The "VFREEBUSY" calendar component is intended for use in 2829 iCalendar object methods involving requests for free time, 2830 requests for busy time, requests for both free and busy, and the 2831 associated replies. 2833 Free/Busy information is represented with the "FREEBUSY" property. 2834 This property provides a terse representation of time periods. 2835 One or more "FREEBUSY" properties can be specified in the 2836 "VFREEBUSY" calendar component. 2838 When present in a "VFREEBUSY" calendar component, the "DTSTART" 2839 and "DTEND" properties SHOULD be specified prior to any "FREEBUSY" 2840 properties. 2842 The recurrence properties ("RRULE", "RDATE", "EXDATE") are not 2843 permitted within a "VFREEBUSY" calendar component. Any recurring 2844 events are resolved into their individual busy time periods using 2845 the "FREEBUSY" property. 2847 Example: The following is an example of a "VFREEBUSY" calendar 2848 component used to request free or busy time information: 2850 BEGIN:VFREEBUSY 2851 UID:19970901T082949Z-FA43EF@example.com 2852 ORGANIZER:mailto:jane_doe@example.com 2853 ATTENDEE:mailto:john_public@example.com 2854 DTSTART:19971015T050000Z 2855 DTEND:19971016T050000Z 2856 DTSTAMP:19970901T083000Z 2857 END:VFREEBUSY 2859 The following is an example of a "VFREEBUSY" calendar component 2860 used to reply to the request with busy time information: 2862 BEGIN:VFREEBUSY 2863 UID:19970901T095957Z-76A912@example.com 2864 ORGANIZER:mailto:jane_doe@example.com 2865 ATTENDEE:mailto:john_public@example.com 2866 DTSTAMP:19970901T100000Z 2867 FREEBUSY:19971015T050000Z/PT8H30M, 2868 19971015T160000Z/PT5H30M,19971015T223000Z/PT6H30M 2869 URL:http://example.com/pub/busy/jpublic-01.ifb 2870 COMMENT:This iCalendar file contains busy time information for 2871 the next three months. 2872 END:VFREEBUSY 2874 The following is an example of a "VFREEBUSY" calendar component 2875 used to publish busy time information. 2877 BEGIN:VFREEBUSY 2878 UID:19970901T115957Z-76A912@example.com 2879 DTSTAMP:19970901T120000Z 2880 ORGANIZER:jsmith@example.com 2881 DTSTART:19980313T141711Z 2882 DTEND:19980410T141711Z 2883 FREEBUSY:19980314T233000Z/19980315T003000Z 2884 FREEBUSY:19980316T153000Z/19980316T163000Z 2885 FREEBUSY:19980318T030000Z/19980318T040000Z 2886 URL:http://www.example.com/calendar/busytime/jsmith.ifb 2887 END:VFREEBUSY 2889 3.6.5. Time Zone Component 2891 Component Name: VTIMEZONE 2893 Purpose: Provide a grouping of component properties that defines a 2894 time zone. 2896 Format Definition: A "VTIMEZONE" calendar component is defined by 2897 the following notation: 2899 timezonec = "BEGIN" ":" "VTIMEZONE" CRLF 2900 *( 2901 ; 2902 ; 'tzid' is REQUIRED, but MUST NOT occur more 2903 ; than once 2904 ; 2905 tzid / 2906 ; 2907 ; 'last-mod' and 'tzurl' are OPTIONAL, 2908 ; but MUST NOT occur more than once 2909 ; 2910 last-mod / tzurl / 2911 ; 2912 ; one of 'standardc' or 'daylightc' MUST occur 2913 ; and each MAY occur more than once. 2914 ; 2915 standardc / daylightc / 2916 ; 2917 ; the following are OPTIONAL, 2918 ; and MAY occur more than once 2919 ; 2920 x-prop / iana-prop 2921 ; 2922 ) 2923 "END" ":" "VTIMEZONE" CRLF 2925 standardc = "BEGIN" ":" "STANDARD" CRLF 2926 tzprop 2927 "END" ":" "STANDARD" CRLF 2929 daylightc = "BEGIN" ":" "DAYLIGHT" CRLF 2930 tzprop 2931 "END" ":" "DAYLIGHT" CRLF 2933 tzprop = *( 2934 ; 2935 ; the following are REQUIRED, 2936 ; but MUST NOT occur more than once 2937 ; 2938 dtstart / tzoffsetto / tzoffsetfrom / 2939 ; 2940 ; the following is OPTIONAL, 2941 ; but SHOULD NOT occur more than once 2942 ; 2943 rrule / 2944 ; 2945 ; the following are OPTIONAL, 2946 ; and MAY occur more than once 2947 ; 2948 comment / rdate / tzname / x-prop / iana-prop 2949 ; 2950 ) 2952 Description: A time zone is unambiguously defined by the set of time 2953 measurement rules determined by the governing body for a given 2954 geographic area. These rules describe at a minimum the base 2955 offset from UTC for the time zone, often referred to as the 2956 Standard Time offset. Many locations adjust their Standard Time 2957 forward or backward by one hour, in order to accommodate seasonal 2958 changes in number of daylight hours, often referred to as Daylight 2959 Saving Time. Some locations adjust their time by a fraction of an 2960 hour. Standard Time is also known as Winter Time. Daylight 2961 Saving Time is also known as Advanced Time, Summer Time, or Legal 2962 Time in certain countries. The following table shows the changes 2963 in time zone rules in effect for New York City starting from 1967. 2964 Each line represents a description or rule for a particular 2965 observance. 2967 Effective Observance Rule 2969 +-----------+--------------------------+--------+--------------+ 2970 | Date | (Date/Time) | Offset | Abbreviation | 2971 +-----------+--------------------------+--------+--------------+ 2972 | 1967-1973 | last Sun in Apr, 02:00 | -0400 | EDT | 2973 | | | | | 2974 | 1967-2006 | last Sun in Oct, 02:00 | -0500 | EST | 2975 | | | | | 2976 | 1974-1974 | Jan 6, 02:00 | -0400 | EDT | 2977 | | | | | 2978 | 1975-1975 | Feb 23, 02:00 | -0400 | EDT | 2979 | | | | | 2980 | 1976-1986 | last Sun in Apr, 02:00 | -0400 | EDT | 2981 | | | | | 2982 | 1987-2006 | first Sun in Apr, 02:00 | -0400 | EDT | 2983 | | | | | 2984 | 2007-* | second Sun in Mar, 02:00 | -0400 | EDT | 2985 | | | | | 2986 | 2007-* | first Sun in Nov, 02:00 | -0500 | EST | 2987 +-----------+--------------------------+--------+--------------+ 2989 Note: The specification of a global time zone registry is not 2990 addressed by this document and is left for future study. 2991 However, implementers may find the TZ database [TZDB] a useful 2992 reference. It is an informal, public-domain collection of time 2993 zone information, which is currently being maintained by 2994 volunteer Internet participants, and is used in several 2995 operating systems. This database contains current and 2996 historical time zone information for a wide variety of 2997 locations around the globe; it provides a time zone identifier 2998 for every unique time zone rule set in actual use since 1970, 2999 with historical data going back to the introduction of standard 3000 time. 3002 Interoperability between two calendaring and scheduling 3003 applications, especially for recurring events, to-dos or journal 3004 entries, is dependent on the ability to capture and convey date 3005 and time information in an unambiguous format. The specification 3006 of current time zone information is integral to this behavior. 3008 If present, the "VTIMEZONE" calendar component defines the set of 3009 Standard Time and Daylight Saving Time observances (or rules) for 3010 a particular time zone for a given interval of time. The 3011 "VTIMEZONE" calendar component cannot be nested within other 3012 calendar components. Multiple "VTIMEZONE" calendar components can 3013 exist in an iCalendar object. In this situation, each "VTIMEZONE" 3014 MUST represent a unique time zone definition. This is necessary 3015 for some classes of events, such as airline flights, that start in 3016 one time zone and end in another. 3018 The "VTIMEZONE" calendar component MUST include the "TZID" 3019 property and at least one definition of a "STANDARD" or "DAYLIGHT" 3020 sub-component. The "STANDARD" or "DAYLIGHT" subcomponent MUST 3021 include the "DTSTART", "TZOFFSETFROM" and "TZOFFSETTO" properties. 3023 An individual "VTIMEZONE" calendar component MUST be specified for 3024 each unique "TZID" parameter value specified in the iCalendar 3025 object. In addition, a "VTIMEZONE" calendar component, referred 3026 to by a recurring calendar component, MUST provide valid time zone 3027 information for all recurrence instances. 3029 Each "VTIMEZONE" calendar component consists of a collection of 3030 one or more sub-components that describe the rule for a particular 3031 observance (either a Standard Time or a Daylight Saving Time 3032 observance). The "STANDARD" sub-component consists of a 3033 collection of properties that describe Standard Time. The 3034 "DAYLIGHT" sub-component consists of a collection of properties 3035 that describe Daylight Saving Time. In general this collection of 3036 properties consists of: 3038 * the first onset date-time for the observance; 3040 * the last onset date-time for the observance, if a last onset is 3041 known; 3043 * the offset to be applied for the observance; 3044 * a rule that describes the day and time when the observance 3045 takes effect; 3047 * an optional name for the observance. 3049 For a given time zone, there may be multiple unique definitions of 3050 the observances over a period of time. Each observance is 3051 described using either a "STANDARD" or "DAYLIGHT" sub-component. 3052 The collection of these sub-components is used to describe the 3053 time zone for a given period of time. The offset to apply at any 3054 given time is found by locating the observance that has the last 3055 onset date and time before the time in question, and using the 3056 offset value from that observance. 3058 The top-level properties in a "VTIMEZONE" calendar component are: 3060 The mandatory "TZID" property is a text value that uniquely 3061 identifies the "VTIMEZONE" calendar component within the scope of 3062 an iCalendar object. 3064 The optional "LAST-MODIFIED" property is a UTC value that 3065 specifies the date and time that this time zone definition was 3066 last updated. 3068 The optional "TZURL" property is a url value that points to a 3069 published "VTIMEZONE" definition. "TZURL" SHOULD refer to a 3070 resource that is accessible by anyone who might need to interpret 3071 the object. This SHOULD NOT normally be a "file" URL or other URL 3072 that is not widely-accessible. 3074 The collection of properties that are used to define the 3075 "STANDARD" and "DAYLIGHT" sub-components include: 3077 The mandatory "DTSTART" property gives the effective onset date 3078 and local time for the time zone sub-component definition. 3079 "DTSTART" in this usage MUST be specified as a date with local 3080 time value. 3082 The mandatory "TZOFFSETFROM" property gives the UTC offset which 3083 is in use when the onset of this time zone observance begins. 3084 "TZOFFSETFROM" is combined with "DTSTART" to define the effective 3085 onset for the time zone sub-component definition. For example, 3086 the following represents the time at which the observance of 3087 Standard Time took effect in Fall 1967 for New York City: 3089 DTSTART:19671029T020000 3091 TZOFFSETFROM:-0400 3093 The mandatory "TZOFFSETTO" property gives the UTC offset for the 3094 time zone sub-component (Standard Time or Daylight Saving Time) 3095 when this observance is in use. 3097 The optional "TZNAME" property is the customary name for the time 3098 zone. This could be used for displaying dates. 3100 The onset date-times for the observance defined by the time zone 3101 sub-component is defined by the "DTSTART", "RRULE", and "RDATE" 3102 properties. 3104 The "RRULE" property defines the recurrence rule for the onset of 3105 the observance defined by this time zone sub-component. Some 3106 specific requirements for the usage of "RRULE" for this purpose 3107 include: 3109 * If observance is known to have an effective end date, the 3110 "UNTIL" recurrence rule parameter MUST be used to specify the 3111 last valid onset of this observance (i.e., the UNTIL date-time 3112 will be equal to the last instance generated by the recurrence 3113 pattern). It MUST be specified in UTC time. 3115 * The "DTSTART" and the "TZOFFSETFROM" properties MUST be used 3116 when generating the onset date-time values (instances) from the 3117 "RRULE". 3119 The "RDATE" property can also be used to define the onset of the 3120 observance by giving the individual onset date and times. "RDATE" 3121 in this usage MUST be specified as a date with local time value, 3122 relative to the UTC offset specified in the "TZOFFSETFROM" 3123 property. 3125 The optional "COMMENT" property is also allowed for descriptive 3126 explanatory text. 3128 Example: The following are examples of the "VTIMEZONE" calendar 3129 component: 3131 This is an example showing all the time zone rules for New York 3132 City since April 30, 1967 at 03:00:00 EDT. 3134 BEGIN:VTIMEZONE 3135 TZID:America/New_York 3136 LAST-MODIFIED:20050809T050000Z 3137 BEGIN:DAYLIGHT 3138 DTSTART:19670430T020000 3139 RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=-1SU;UNTIL=19730429T070000Z 3140 TZOFFSETFROM:-0500 3141 TZOFFSETTO:-0400 3142 TZNAME:EDT 3143 END:DAYLIGHT 3144 BEGIN:STANDARD 3145 DTSTART:19671029T020000 3146 RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU;UNTIL=20061029T060000Z 3147 TZOFFSETFROM:-0400 3148 TZOFFSETTO:-0500 3149 TZNAME:EST 3150 END:STANDARD 3151 BEGIN:DAYLIGHT 3152 DTSTART:19740106T020000 3153 RDATE:19750223T020000 3154 TZOFFSETFROM:-0500 3155 TZOFFSETTO:-0400 3156 TZNAME:EDT 3157 END:DAYLIGHT 3158 BEGIN:DAYLIGHT 3159 DTSTART:19760425T020000 3160 RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=-1SU;UNTIL=19860427T070000Z 3161 TZOFFSETFROM:-0500 3162 TZOFFSETTO:-0400 3163 TZNAME:EDT 3164 END:DAYLIGHT 3165 BEGIN:DAYLIGHT 3166 DTSTART:19870405T020000 3167 RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=1SU;UNTIL=20060402T070000Z 3168 TZOFFSETFROM:-0500 3169 TZOFFSETTO:-0400 3170 TZNAME:EDT 3171 END:DAYLIGHT 3172 BEGIN:DAYLIGHT 3173 DTSTART:20070311T020000 3174 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU 3175 TZOFFSETFROM:-0500 3176 TZOFFSETTO:-0400 3177 TZNAME:EDT 3178 END:DAYLIGHT 3179 BEGIN:STANDARD 3180 DTSTART:20071104T020000 3181 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU 3182 TZOFFSETFROM:-0400 3183 TZOFFSETTO:-0500 3184 TZNAME:EST 3185 END:STANDARD 3186 END:VTIMEZONE 3188 This is an example showing time zone information for New York City 3189 using only the "DTSTART" property. Note that this is only 3190 suitable for a recurring event that starts on or later than March 3191 11, 2007 at 03:00:00 EDT (i.e., the earliest effective transition 3192 date and time) and ends no later than March 9, 2008 at 01:59:59 3193 EST (i.e., latest valid date and time for EST in this scenario). 3194 For example, this can be used for a recurring event that occurs 3195 every Friday, 8:00 A.M.-9:00 A.M., starting June 1, 2007, ending 3196 December 31, 2007, 3198 BEGIN:VTIMEZONE 3199 TZID:America/New_York 3200 LAST-MODIFIED:20050809T050000Z 3201 BEGIN:STANDARD 3202 DTSTART:20071104T020000 3203 TZOFFSETFROM:-0400 3204 TZOFFSETTO:-0500 3205 TZNAME:EST 3206 END:STANDARD 3207 BEGIN:DAYLIGHT 3208 DTSTART:20070311T020000 3209 TZOFFSETFROM:-0500 3210 TZOFFSETTO:-0400 3211 TZNAME:EDT 3212 END:DAYLIGHT 3213 END:VTIMEZONE 3215 This is a simple example showing the current time zone rules for 3216 New York City using a "RRULE" recurrence pattern. Note that there 3217 is no effective end date to either of the Standard Time or 3218 Daylight Time rules. This information would be valid for a 3219 recurring event starting today and continuing indefinitely. 3221 BEGIN:VTIMEZONE 3222 TZID:America/New_York 3223 LAST-MODIFIED:20050809T050000Z 3224 TZURL:http://zones.example.com/tz/America-New_York.ics 3225 BEGIN:STANDARD 3226 DTSTART:20071104T020000 3227 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU 3228 TZOFFSETFROM:-0400 3229 TZOFFSETTO:-0500 3230 TZNAME:EST 3231 END:STANDARD 3232 BEGIN:DAYLIGHT 3233 DTSTART:20070311T020000 3234 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU 3235 TZOFFSETFROM:-0500 3236 TZOFFSETTO:-0400 3237 TZNAME:EDT 3238 END:DAYLIGHT 3239 END:VTIMEZONE 3241 This is an example showing a set of rules for a fictitious time 3242 zone where the Daylight Time rule has an effective end date (i.e., 3243 after that date, Daylight Time is no longer observed). 3245 BEGIN:VTIMEZONE 3246 TZID:Fictitious 3247 LAST-MODIFIED:19870101T000000Z 3248 BEGIN:STANDARD 3249 DTSTART:19671029T020000 3250 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 3251 TZOFFSETFROM:-0400 3252 TZOFFSETTO:-0500 3253 TZNAME:EST 3254 END:STANDARD 3255 BEGIN:DAYLIGHT 3256 DTSTART:19870405T020000 3257 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T070000Z 3258 TZOFFSETFROM:-0500 3259 TZOFFSETTO:-0400 3260 TZNAME:EDT 3261 END:DAYLIGHT 3262 END:VTIMEZONE 3264 This is an example showing a set of rules for a fictitious time 3265 zone where the first Daylight Time rule has an effective end date. 3266 There is a second Daylight Time rule that picks up where the other 3267 left off. 3269 BEGIN:VTIMEZONE 3270 TZID:Fictitious 3271 LAST-MODIFIED:19870101T000000Z 3272 BEGIN:STANDARD 3273 DTSTART:19671029T020000 3274 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 3275 TZOFFSETFROM:-0400 3276 TZOFFSETTO:-0500 3277 TZNAME:EST 3278 END:STANDARD 3279 BEGIN:DAYLIGHT 3280 DTSTART:19870405T020000 3281 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T070000Z 3282 TZOFFSETFROM:-0500 3283 TZOFFSETTO:-0400 3284 TZNAME:EDT 3285 END:DAYLIGHT 3286 BEGIN:DAYLIGHT 3287 DTSTART:19990424T020000 3288 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=4 3289 TZOFFSETFROM:-0500 3290 TZOFFSETTO:-0400 3291 TZNAME:EDT 3292 END:DAYLIGHT 3293 END:VTIMEZONE 3295 3.6.6. Alarm Component 3297 Component Name: VALARM 3299 Purpose: Provide a grouping of component properties that define an 3300 alarm. 3302 Format Definition: A "VALARM" calendar component is defined by the 3303 following notation: 3305 alarmc = "BEGIN" ":" "VALARM" CRLF 3306 (audioprop / dispprop / emailprop) 3307 "END" ":" "VALARM" CRLF 3309 audioprop = *( 3310 ; 3311 ; 'action' and 'trigger' are both REQUIRED, 3312 ; but MUST NOT occur more than once 3313 ; 3314 action / trigger / 3315 ; 3316 ; 'duration' and 'repeat' are both OPTIONAL, 3317 ; and MUST NOT occur more than once each, 3318 ; but if one occurs, so MUST the other 3319 ; 3320 duration / repeat / 3321 ; 3322 ; the following is OPTIONAL, 3323 ; but MUST NOT occur more than once 3324 ; 3325 attach / 3326 ; 3327 ; the following is OPTIONAL, 3328 ; and MAY occur more than once 3329 ; 3330 x-prop / iana-prop 3331 ; 3332 ) 3334 dispprop = *( 3335 ; 3336 ; the following are REQUIRED, 3337 ; but MUST NOT occur more than once 3338 ; 3339 action / description / trigger / 3340 ; 3341 ; 'duration' and 'repeat' are both OPTIONAL, 3342 ; and MUST NOT occur more than once each, 3343 ; but if one occurs, so MUST the other 3344 ; 3345 duration / repeat / 3346 ; 3347 ; the following is OPTIONAL, 3348 ; and MAY occur more than once 3349 ; 3350 x-prop / iana-prop 3351 ; 3352 ) 3354 emailprop = *( 3355 ; 3356 ; the following are all REQUIRED, 3357 ; but MUST NOT occur more than once 3358 ; 3359 action / description / trigger / summary / 3360 ; 3361 ; the following is REQUIRED, 3362 ; and MAY occur more than once 3363 ; 3364 attendee / 3365 ; 3366 ; 'duration' and 'repeat' are both OPTIONAL, 3367 ; and MUST NOT occur more than once each, 3368 ; but if one occurs, so MUST the other 3369 ; 3370 duration / repeat / 3371 ; 3372 ; the following are OPTIONAL, 3373 ; and MAY occur more than once 3374 ; 3375 attach / x-prop / iana-prop 3376 ; 3377 ) 3379 Description: A "VALARM" calendar component is a grouping of 3380 component properties that is a reminder or alarm for an event or a 3381 to-do. For example, it may be used to define a reminder for a 3382 pending event or an overdue to-do. 3384 The "VALARM" calendar component MUST include the "ACTION" and 3385 "TRIGGER" properties. The "ACTION" property further constrains 3386 the "VALARM" calendar component in the following ways: 3388 When the action is "AUDIO", the alarm can also include one and 3389 only one "ATTACH" property, which MUST point to a sound resource, 3390 which is rendered when the alarm is triggered. 3392 When the action is "DISPLAY", the alarm MUST also include a 3393 "DESCRIPTION" property, which contains the text to be displayed 3394 when the alarm is triggered. 3396 When the action is "EMAIL", the alarm MUST include a "DESCRIPTION" 3397 property, which contains the text to be used as the message body, 3398 a "SUMMARY" property, which contains the text to be used as the 3399 message subject, and one or more "ATTENDEE" properties, which 3400 contain the email address of attendees to receive the message. It 3401 can also include one or more "ATTACH" properties, which are 3402 intended to be sent as message attachments. When the alarm is 3403 triggered, the email message is sent. 3405 The "VALARM" calendar component MUST only appear within either a 3406 "VEVENT" or "VTODO" calendar component. "VALARM" calendar 3407 components cannot be nested. Multiple mutually independent 3408 "VALARM" calendar components can be specified for a single 3409 "VEVENT" or "VTODO" calendar component. 3411 The "TRIGGER" property specifies when the alarm will be triggered. 3412 The "TRIGGER" property specifies a duration prior to the start of 3413 an event or a to-do. The "TRIGGER" edge may be explicitly set to 3414 be relative to the "START" or "END" of the event or to-do with the 3415 "RELATED" parameter of the "TRIGGER" property. The "TRIGGER" 3416 property value type can alternatively be set to an absolute 3417 calendar date with UTC time. 3419 In an alarm set to trigger on the "START" of an event or to-do, 3420 the "DTSTART" property MUST be present in the associated event or 3421 to-do. In an alarm in a "VEVENT" calendar component set to 3422 trigger on the "END" of the event, either the "DTEND" property 3423 MUST be present, or the "DTSTART" and "DURATION" properties MUST 3424 both be present. In an alarm in a "VTODO" calendar component set 3425 to trigger on the "END" of the to-do, either the "DUE" property 3426 MUST be present, or the "DTSTART" and "DURATION" properties MUST 3427 both be present. 3429 The alarm can be defined such that it triggers repeatedly. A 3430 definition of an alarm with a repeating trigger MUST include both 3431 the "DURATION" and "REPEAT" properties. The "DURATION" property 3432 specifies the delay period, after which the alarm will repeat. 3433 The "REPEAT" property specifies the number of additional 3434 repetitions that the alarm will be triggered. This repetition 3435 count is in addition to the initial triggering of the alarm. Both 3436 of these properties MUST be present in order to specify a 3437 repeating alarm. If one of these two properties is absent, then 3438 the alarm will not repeat beyond the initial trigger. 3440 The "ACTION" property is used within the "VALARM" calendar 3441 component to specify the type of action invoked when the alarm is 3442 triggered. The "VALARM" properties provide enough information for 3443 a specific action to be invoked. It is typically the 3444 responsibility of a "Calendar User Agent" (CUA) to deliver the 3445 alarm in the specified fashion. An "ACTION" property value of 3446 AUDIO specifies an alarm that causes a sound to be played to alert 3447 the user; DISPLAY specifies an alarm that causes a text message to 3448 be displayed to the user; and EMAIL specifies an alarm that causes 3449 an electronic email message to be delivered to one or more email 3450 addresses. 3452 In an AUDIO alarm, if the optional "ATTACH" property is included, 3453 it MUST specify an audio sound resource. The intention is that 3454 the sound will be played as the alarm effect. If an "ATTACH" 3455 property is specified that does not refer to a sound resource, or 3456 if the specified sound resource cannot be rendered (because its 3457 format is unsupported, or because it cannot be retrieved), then 3458 the CUA or other entity responsible for playing the sound may 3459 choose a fallback action, such as playing a built-in default 3460 sound, or playing no sound at all. 3462 In a DISPLAY alarm, the intended alarm effect is for the text 3463 value of the "DESCRIPTION" property to be displayed to the user. 3465 In an EMAIL alarm, the intended alarm effect is for an email 3466 message to be composed and delivered to all the addresses 3467 specified by the "ATTENDEE" properties in the "VALARM" calendar 3468 component. The "DESCRIPTION" property of the "VALARM" calendar 3469 component MUST be used as the body text of the message, and the 3470 "SUMMARY" property MUST be used as the subject text. Any "ATTACH" 3471 properties in the "VALARM" calendar component SHOULD be sent as 3472 attachments to the message. 3474 Note: Implementations should carefully consider whether they 3475 accept alarm components from untrusted sources, e.g., when 3476 importing calendar objects from external sources. One 3477 reasonable policy is to always ignore alarm components that the 3478 calendar user has not set herself, or at least ask for 3479 confirmation in such a case. 3481 Example: The following example is for a "VALARM" calendar component 3482 that specifies an audio alarm that will sound at a precise time 3483 and repeat 4 more times at 15 minute intervals: 3485 BEGIN:VALARM 3486 TRIGGER;VALUE=DATE-TIME:19970317T133000Z 3487 REPEAT:4 3488 DURATION:PT15M 3489 ACTION:AUDIO 3490 ATTACH;FMTTYPE=audio/basic:ftp://example.com/pub/ 3491 sounds/bell-01.aud 3492 END:VALARM 3494 The following example is for a "VALARM" calendar component that 3495 specifies a display alarm that will trigger 30 minutes before the 3496 scheduled start of the event or of the to-do it is associated with 3497 and will repeat 2 more times at 15 minute intervals: 3499 BEGIN:VALARM 3500 TRIGGER:-PT30M 3501 REPEAT:2 3502 DURATION:PT15M 3503 ACTION:DISPLAY 3504 DESCRIPTION:Breakfast meeting with executive\n 3505 team at 8:30 AM EST. 3506 END:VALARM 3508 The following example is for a "VALARM" calendar component that 3509 specifies an email alarm that will trigger 2 days before the 3510 scheduled due date/time of a to-do it is associated with. It does 3511 not repeat. The email has a subject, body and attachment link. 3513 BEGIN:VALARM 3514 TRIGGER;RELATED=END:-P2D 3515 ACTION:EMAIL 3516 ATTENDEE:mailto:john_doe@example.com 3517 SUMMARY:*** REMINDER: SEND AGENDA FOR WEEKLY STAFF MEETING *** 3518 DESCRIPTION:A draft agenda needs to be sent out to the attendees 3519 to the weekly managers meeting (MGR-LIST). Attached is a 3520 pointer the document template for the agenda file. 3521 ATTACH;FMTTYPE=application/msword:http://example.com/ 3522 templates/agenda.doc 3523 END:VALARM 3525 3.7. Calendar Properties 3527 The Calendar Properties are attributes that apply to the iCalendar 3528 object, as a whole. These properties do not appear within a calendar 3529 component. They SHOULD be specified after the "BEGIN:VCALENDAR" 3530 delimiter string and prior to any calendar component. 3532 3.7.1. Calendar Scale 3534 Property Name: CALSCALE 3536 Purpose: This property defines the calendar scale used for the 3537 calendar information specified in the iCalendar object. 3539 Value Type: TEXT 3541 Property Parameters: IANA and non-standard property parameters can 3542 be specified on this property. 3544 Conformance: This property can be specified once in an iCalendar 3545 object. The default value is "GREGORIAN". 3547 Description: This memo is based on the Gregorian calendar scale. 3548 The Gregorian calendar scale is assumed if this property is not 3549 specified in the iCalendar object. It is expected that other 3550 calendar scales will be defined in other specifications or by 3551 future versions of this memo. 3553 Format Definition: This property is defined by the following 3554 notation: 3556 calscale = "CALSCALE" calparam ":" calvalue CRLF 3558 calparam = *(";" other-param) 3560 calvalue = "GREGORIAN" 3562 Example: The following is an example of this property: 3564 CALSCALE:GREGORIAN 3566 3.7.2. Method 3568 Property Name: METHOD 3570 Purpose: This property defines the iCalendar object method 3571 associated with the calendar object. 3573 Value Type: TEXT 3575 Property Parameters: IANA and non-standard property parameters can 3576 be specified on this property. 3578 Conformance: This property can be specified once in an iCalendar 3579 object. 3581 Description: When used in a MIME message entity, the value of this 3582 property MUST be the same as the Content-Type "method" parameter 3583 value. If either the "METHOD" property or the Content-Type 3584 "method" parameter is specified, then the other MUST also be 3585 specified. 3587 No methods are defined by this specification. This is the subject 3588 of other specifications, such as the iCalendar Transport- 3589 independent Interoperability Protocol (iTIP) defined by 3590 [I-D.ietf-calsify-2446bis]. 3592 If this property is not present in the iCalendar object, then a 3593 scheduling transaction MUST NOT be assumed. In such cases, the 3594 iCalendar object is merely being used to transport a snapshot of 3595 some calendar information; without the intention of conveying a 3596 scheduling semantic. 3598 Format Definition: This property is defined by the following 3599 notation: 3601 method = "METHOD" metparam ":" metvalue CRLF 3603 metparam = *(";" other-param) 3605 metvalue = iana-token 3607 Example: The following is a hypothetical example of this property to 3608 convey that the iCalendar object is a scheduling request: 3610 METHOD:REQUEST 3612 3.7.3. Product Identifier 3614 Property Name: PRODID 3616 Purpose: This property specifies the identifier for the product that 3617 created the iCalendar object. 3619 Value Type: TEXT 3621 Property Parameters: IANA and non-standard property parameters can 3622 be specified on this property. 3624 Conformance: The property MUST be specified once in an iCalendar 3625 object. 3627 Description: The vendor of the implementation SHOULD assure that 3628 this is a globally unique identifier; using some technique such as 3629 an FPI value, as defined in [ISO.9070.1991]. 3631 This property SHOULD NOT be used to alter the interpretation of an 3632 iCalendar object beyond the semantics specified in this memo. For 3633 example, it is not to be used to further the understanding of non- 3634 standard properties. 3636 Format Definition: This property is defined by the following 3637 notation: 3639 prodid = "PRODID" pidparam ":" pidvalue CRLF 3641 pidparam = *(";" other-param) 3643 pidvalue = text 3644 ;Any text that describes the product and version 3645 ;and that is generally assured of being unique. 3647 Example: The following is an example of this property. It does not 3648 imply that English is the default language. 3650 PRODID:-//ABC Corporation//NONSGML My Product//EN 3652 3.7.4. Version 3654 Property Name: VERSION 3656 Purpose: This property specifies the identifier corresponding to the 3657 highest version number or the minimum and maximum range of the 3658 iCalendar specification that is required in order to interpret the 3659 iCalendar object. 3661 Value Type: TEXT 3663 Property Parameters: IANA and non-standard property parameters can 3664 be specified on this property. 3666 Conformance: This property MUST be specified once in an iCalendar 3667 object. 3669 Description: A value of "2.0" corresponds to this memo. 3671 Format Definition: This property is defined by the following 3672 notation: 3674 version = "VERSION" verparam ":" vervalue CRLF 3676 verparam = *(";" other-param) 3678 vervalue = "2.0" ;This memo 3679 / maxver 3680 / (minver ";" maxver) 3682 minver = 3683 ;Minimum iCalendar version needed to parse the iCalendar object 3685 maxver = 3686 ;Maximum iCalendar version needed to parse the iCalendar object 3688 Example: The following is an example of this property: 3690 VERSION:2.0 3692 3.8. Component Properties 3694 The following properties can appear within calendar components, as 3695 specified by each component property definition. 3697 3.8.1. Descriptive Component Properties 3699 The following properties specify descriptive information about 3700 calendar components. 3702 3.8.1.1. Attachment 3704 Property Name: ATTACH 3706 Purpose: This property provides the capability to associate a 3707 document object with a calendar component. 3709 Value Type: The default value type for this property is URI. The 3710 value type can also be set to BINARY to indicate inline binary 3711 encoded content information. 3713 Property Parameters: IANA, non-standard, inline encoding and value 3714 data type property parameters can be specified on this property. 3715 The format type parameter can be specified on this property and is 3716 RECOMMENDED for inline binary encoded content information. 3718 Conformance: This property can be specified multiple times in a 3719 "VEVENT", "VTODO", "VJOURNAL" or "VALARM" calendar component with 3720 the exception of AUDIO alarm which only allows this property to 3721 occur once . 3723 Description: This property is used in "VEVENT", "VTODO", and 3724 "VJOURNAL" calendar components to associate a resource (e.g., 3725 document) with the calendar component. This property is used in 3726 "VALARM" calendar components to specify an audio sound resource or 3727 an email message attachment. This property can be specified as a 3728 URI pointing to a resource or as inline binary encoded content. 3730 When this property is specified as inline binary encoded content, 3731 calendar applications MAY attempt to guess the media type of the 3732 resource via inspection of its content if and only if the media 3733 type of the resource is not given by the "FMTTYPE" parameter. If 3734 the media type remains unknown, calendar applications SHOULD treat 3735 it as type "application/octet-stream". 3737 Format Definition: This property is defined by the following 3738 notation: 3740 attach = "ATTACH" attachparam ( ":" uri ) / 3741 ( 3742 ";" "ENCODING" "=" "BASE64" 3743 ";" "VALUE" "=" "BINARY" 3744 ":" binary 3745 ) 3746 CRLF 3748 attachparam = *( 3749 ; 3750 ; the following is OPTIONAL for URI value 3751 ; and RECOMMENDED for BINARY value, 3752 ; and MUST NOT occur more than once 3753 ; 3754 (";" fmttypeparam) / 3755 ; 3756 ; the following is OPTIONAL, 3757 ; and MAY occur more than once 3758 ; 3759 (";" other-param) 3760 ; 3761 ) 3763 Example: The following are examples of this property: 3765 ATTACH:CID:jsmith.part3.960817T083000.xyzMail@example.com 3767 ATTACH;FMTTYPE=application/postscript:ftp://example.com/pub/ 3768 reports/r-960812.ps 3770 3.8.1.2. Categories 3772 Property Name: CATEGORIES 3774 Purpose: This property defines the categories for a calendar 3775 component. 3777 Value Type: TEXT 3779 Property Parameters: IANA, non-standard, and language property 3780 parameters can be specified on this property. 3782 Conformance: The property can be specified within "VEVENT", "VTODO" 3783 or "VJOURNAL" calendar components. 3785 Description: This property is used to specify categories or subtypes 3786 of the calendar component. The categories are useful in searching 3787 for a calendar component of a particular type and category. 3788 Within the "VEVENT", "VTODO" or "VJOURNAL" calendar components, 3789 more than one category can be specified as a list of categories 3790 separated by the COMMA character (US-ASCII decimal 44). 3792 Format Definition: This property is defined by the following 3793 notation: 3795 categories = "CATEGORIES" catparam ":" text *("," text) 3796 CRLF 3798 catparam = *( 3799 ; 3800 ; the following is OPTIONAL, 3801 ; but MUST NOT occur more than once 3802 ; 3803 (";" languageparam ) / 3804 ; 3805 ; the following is OPTIONAL, 3806 ; and MAY occur more than once 3807 ; 3808 (";" other-param) 3809 ; 3810 ) 3812 Example: The following are examples of this property: 3814 CATEGORIES:APPOINTMENT,EDUCATION 3816 CATEGORIES:MEETING 3818 3.8.1.3. Classification 3820 Property Name: CLASS 3822 Purpose: This property defines the access classification for a 3823 calendar component. 3825 Value Type: TEXT 3826 Property Parameters: IANA and non-standard property parameters can 3827 be specified on this property. 3829 Conformance: The property can be specified once in a "VEVENT", 3830 "VTODO" or "VJOURNAL" calendar components. 3832 Description: An access classification is only one component of the 3833 general security system within a calendar application. It 3834 provides a method of capturing the scope of the access the 3835 calendar owner intends for information within an individual 3836 calendar entry. The access classification of an individual 3837 iCalendar component is useful when measured along with the other 3838 security components of a calendar system (e.g., calendar user 3839 authentication, authorization, access rights, access role, etc.). 3840 Hence, the semantics of the individual access classifications 3841 cannot be completely defined by this memo alone. Additionally, 3842 due to the "blind" nature of most exchange processes using this 3843 memo, these access classifications cannot serve as an enforcement 3844 statement for a system receiving an iCalendar object. Rather, 3845 they provide a method for capturing the intention of the calendar 3846 owner for the access to the calendar component. If not specified 3847 in a component that allows this property, the default value is 3848 PUBLIC. Applications MUST treat x-name and iana-token value they 3849 don't recognized the same way as they would the PRIVATE value. 3851 Format Definition: This property is defined by the following 3852 notation: 3854 class = "CLASS" classparam ":" classvalue CRLF 3856 classparam = *(";" other-param) 3858 classvalue = "PUBLIC" / "PRIVATE" / "CONFIDENTIAL" / iana-token 3859 / x-name 3860 ;Default is PUBLIC 3862 Example: The following is an example of this property: 3864 CLASS:PUBLIC 3866 3.8.1.4. Comment 3868 Property Name: COMMENT 3870 Purpose: This property specifies non-processing information intended 3871 to provide a comment to the calendar user. 3873 Value Type: TEXT 3875 Property Parameters: IANA, non-standard, alternate text 3876 representation and language property parameters can be specified 3877 on this property. 3879 Conformance: This property can be specified multiple times in 3880 "VEVENT", "VTODO", "VJOURNAL", and "VFREEBUSY" calendar components 3881 as well as in the "STANDARD" and "DAYLIGHT" sub-components. 3883 Description: This property is used to specify a comment to the 3884 calendar user. 3886 Format Definition: This property is defined by the following 3887 notation: 3889 comment = "COMMENT" commparam ":" text CRLF 3891 commparam = *( 3892 ; 3893 ; the following are OPTIONAL, 3894 ; but MUST NOT occur more than once 3895 ; 3896 (";" altrepparam) / (";" languageparam) / 3897 ; 3898 ; the following is OPTIONAL, 3899 ; and MAY occur more than once 3900 ; 3901 (";" other-param) 3902 ; 3903 ) 3905 Example: The following is an example of this property: 3907 COMMENT:The meeting really needs to include both ourselves 3908 and the customer. We can't hold this meeting without them. 3909 As a matter of fact\, the venue for the meeting ought to be at 3910 their site. - - John 3912 3.8.1.5. Description 3914 Property Name: DESCRIPTION 3916 Purpose: This property provides a more complete description of the 3917 calendar component, than that provided by the "SUMMARY" property. 3919 Value Type: TEXT 3921 Property Parameters: IANA, non-standard, alternate text 3922 representation and language property parameters can be specified 3923 on this property. 3925 Conformance: The property can be specified in the "VEVENT", "VTODO", 3926 "VJOURNAL" or "VALARM" calendar components. The property can be 3927 specified multiple times only within a "VJOURNAL" calendar 3928 component. 3930 Description: This property is used in the "VEVENT" and "VTODO" to 3931 capture lengthy textual decriptions associated with the activity. 3933 This property is used in the "VJOURNAL" calendar component to 3934 capture one or more textual journal entries. 3936 This property is used in the "VALARM" calendar component to 3937 capture the display text for a DISPLAY category of alarm, and to 3938 capture the body text for an EMAIL category of alarm. 3940 Format Definition: This property is defined by the following 3941 notation: 3943 description = "DESCRIPTION" descparam ":" text CRLF 3945 descparam = *( 3946 ; 3947 ; the following are OPTIONAL, 3948 ; but MUST NOT occur more than once 3949 ; 3950 (";" altrepparam) / (";" languageparam) / 3951 ; 3952 ; the following is OPTIONAL, 3953 ; and MAY occur more than once 3954 ; 3955 (";" other-param) 3956 ; 3957 ) 3959 Example: The following is an example of this property with formatted 3960 line breaks in the property value: 3962 DESCRIPTION:Meeting to provide technical review for "Phoenix" 3963 design.\nHappy Face Conference Room. Phoenix design team 3964 MUST attend this meeting.\nRSVP to team leader. 3966 3.8.1.6. Geographic Position 3968 Property Name: GEO 3970 Purpose: This property specifies information related to the global 3971 position for the activity specified by a calendar component. 3973 Value Type: FLOAT. The value MUST be two SEMICOLON separated FLOAT 3974 values. 3976 Property Parameters: IANA and non-standard property parameters can 3977 be specified on this property. 3979 Conformance: This property can be specified in "VEVENT" or "VTODO" 3980 calendar components. 3982 Description: This property value specifies latitude and longitude, 3983 in that order (i.e., "LAT LON" ordering). The longitude 3984 represents the location East or West of the prime meridian as a 3985 positive or negative real number, respectively. The longitude and 3986 latitude values MAY be specified up to six decimal places, which 3987 will allow for accuracy to within one meter of geographical 3988 position. Receiving applications MUST accept values of this 3989 precision and MAY truncate values of greater precision. 3991 Values for latitude and longitude shall be expressed as decimal 3992 fractions of degrees. Whole degrees of latitude shall be 3993 represented by a two-digit decimal number ranging from 0 through 3994 90. Whole degrees of longitude shall be represented by a decimal 3995 number ranging from 0 through 180. When a decimal fraction of a 3996 degree is specified, it shall be separated from the whole number 3997 of degrees by a decimal point. 3999 Latitudes North of the equator shall be specified by a plus sign 4000 (+), or by the absence of a minus sign (-), preceding the digits 4001 designating degrees. Latitudes South of the Equator shall be 4002 designated by a minus sign (-) preceding the digits designating 4003 degrees. A point on the Equator shall be assigned to the Northern 4004 Hemisphere. 4006 Longitudes east of the prime meridian shall be specified by a plus 4007 sign (+), or by the absence of a minus sign (-), preceding the 4008 digits designating degrees. Longitudes west of the meridian shall 4009 be designated by minus sign (-) preceding the digits designating 4010 degrees. A point on the prime meridian shall be assigned to the 4011 Eastern Hemisphere. A point on the 180th meridian shall be 4012 assigned to the Western Hemisphere. One exception to this last 4013 convention is permitted. For the special condition of describing 4014 a band of latitude around the earth, the East Bounding Coordinate 4015 data element shall be assigned the value +180 (180) degrees. 4017 Any spatial address with a latitude of +90 (90) or -90 degrees 4018 will specify the position at the North or South Pole, 4019 respectively. The component for longitude may have any legal 4020 value. 4022 With the exception of the special condition described above, this 4023 form is specified in Department of Commerce, 1986, Representation 4024 of geographic point locations for information interchange (Federal 4025 Information Processing Standard 70-1): Washington, Department of 4026 Commerce, National Institute of Standards and Technology. 4028 The simple formula for converting degrees-minutes-seconds into 4029 decimal degrees is: 4031 decimal = degrees + minutes/60 + seconds/3600. 4033 Format Definition: This property is defined by the following 4034 notation: 4036 geo = "GEO" geoparam ":" geovalue CRLF 4038 geoparam = *(";" other-param) 4040 geovalue = float ";" float 4041 ;Latitude and Longitude components 4043 Example: The following is an example of this property: 4045 GEO:37.386013;-122.082932 4047 3.8.1.7. Location 4049 Property Name: LOCATION 4051 Purpose: This property defines the intended venue for the activity 4052 defined by a calendar component. 4054 Value Type: TEXT 4056 Property Parameters: IANA, non-standard, alternate text 4057 representation and language property parameters can be specified 4058 on this property. 4060 Conformance: This property can be specified in "VEVENT" or "VTODO" 4061 calendar component. 4063 Description: Specific venues such as conference or meeting rooms may 4064 be explicitly specified using this property. An alternate 4065 representation may be specified that is a URI that points to 4066 directory information with more structured specification of the 4067 location. For example, the alternate representation may specify 4068 either an LDAP URL [RFC4516] pointing to an LDAP server entry or a 4069 CID URL [RFC2392] pointing to a MIME body part containing a vCard 4070 [RFC2426] for the location. 4072 Format Definition: This property is defined by the following 4073 notation: 4075 location = "LOCATION" locparam ":" text CRLF 4077 locparam = *( 4078 ; 4079 ; the following are OPTIONAL, 4080 ; but MUST NOT occur more than once 4081 ; 4082 (";" altrepparam) / (";" languageparam) / 4083 ; 4084 ; the following is OPTIONAL, 4085 ; and MAY occur more than once 4086 ; 4087 (";" other-param) 4088 ; 4089 ) 4091 Example: The following are some examples of this property: 4093 LOCATION:Conference Room - F123\, Bldg. 002 4095 LOCATION;ALTREP="http://xyzcorp.com/conf-rooms/f123.vcf": 4096 Conference Room - F123\, Bldg. 002 4098 3.8.1.8. Percent Complete 4100 Property Name: PERCENT-COMPLETE 4102 Purpose: This property is used by an assignee or delegatee of a 4103 to-do to convey the percent completion of a to-do to the 4104 "Organizer". 4106 Value Type: INTEGER 4108 Property Parameters: IANA and non-standard property parameters can 4109 be specified on this property. 4111 Conformance: This property can be specified once in a "VTODO" 4112 calendar component. 4114 Description: The property value is a positive integer between zero 4115 and one hundred. A value of "0" indicates the to-do has not yet 4116 been started. A value of "100" indicates that the to-do has been 4117 completed. Integer values in between indicate the percent 4118 partially complete. 4120 When a to-do is assigned to multiple individuals, the property 4121 value indicates the percent complete for that portion of the to-do 4122 assigned to the assignee or delegatee. For example, if a to-do is 4123 assigned to both individuals "A" and "B". A reply from "A" with a 4124 percent complete of "70" indicates that "A" has completed 70% of 4125 the to-do assigned to them. A reply from "B" with a percent 4126 complete of "50" indicates "B" has completed 50% of the to-do 4127 assigned to them. 4129 Format Definition: This property is defined by the following 4130 notation: 4132 percent = "PERCENT-COMPLETE" pctparam ":" integer CRLF 4134 pctparam = *(";" other-param) 4136 Example: The following is an example of this property to show 39% 4137 completion: 4139 PERCENT-COMPLETE:39 4141 3.8.1.9. Priority 4143 Property Name: PRIORITY 4145 Purpose: This property defines the relative priority for a calendar 4146 component. 4148 Value Type: INTEGER 4150 Property Parameters: IANA and non-standard property parameters can 4151 be specified on this property. 4153 Conformance: This property can be specified in "VEVENT" and "VTODO" 4154 calendar components. 4156 Description: This priority is specified as an integer in the range 4157 zero to nine. A value of zero (US-ASCII decimal 48) specifies an 4158 undefined priority. A value of one (US-ASCII decimal 49) is the 4159 highest priority. A value of two (US-ASCII decimal 50) is the 4160 second highest priority. Subsequent numbers specify a decreasing 4161 ordinal priority. A value of nine (US-ASCII decimal 57 ) is the 4162 lowest priority. 4164 A CUA with a three-level priority scheme of "HIGH", "MEDIUM" and 4165 "LOW" is mapped into this property such that a property value in 4166 the range of one (US-ASCII decimal 49) to four (US-ASCII decimal 4167 52) specifies "HIGH" priority. A value of five (US-ASCII decimal 4168 53) is the normal or "MEDIUM" priority. A value in the range of 4169 six (US-ASCII decimal 54) to nine (US-ASCII decimal 57 ) is "LOW" 4170 priority. 4172 A CUA with a priority schema of "A1", "A2", "A3", "B1", "B2", ..., 4173 "C3" is mapped into this property such that a property value of 4174 one (US-ASCII decimal 49) specifies "A1", a property value of two 4175 (US-ASCII decimal 50) specifies "A2", a property value of three 4176 (US-ASCII decimal 51) specifies "A3", and so forth up to a 4177 property value of 9 (US-ASCII decimal 57 ) specifies "C3". 4179 Other integer values are reserved for future use. 4181 Within a "VEVENT" calendar component, this property specifies a 4182 priority for the event. This property may be useful when more 4183 than one event is scheduled for a given time period. 4185 Within a "VTODO" calendar component, this property specified a 4186 priority for the to-do. This property is useful in prioritizing 4187 multiple action items for a given time period. 4189 Format Definition: This property is defined by the following 4190 notation: 4192 priority = "PRIORITY" prioparam ":" priovalue CRLF 4193 ;Default is zero (i.e., undefined) 4195 prioparam = *(";" other-param) 4197 priovalue = integer ;Must be in the range [0..9] 4198 ; All other values are reserved for future use 4200 Example: The following is an example of a property with the highest 4201 priority: 4203 PRIORITY:1 4205 The following is an example of a property with a next highest 4206 priority: 4208 PRIORITY:2 4210 The following is an example of a property with no priority. This 4211 is equivalent to not specifying the "PRIORITY" property: 4213 PRIORITY:0 4215 3.8.1.10. Resources 4217 Property Name: RESOURCES 4219 Purpose: This property defines the equipment or resources 4220 anticipated for an activity specified by a calendar component. 4222 Value Type: TEXT 4224 Property Parameters: IANA, non-standard, alternate text 4225 representation and language property parameters can be specified 4226 on this property. 4228 Conformance: This property can be specified once in "VEVENT" or 4229 "VTODO" calendar component. 4231 Description: The property value is an arbitrary text. More than one 4232 resource can be specified as a list of resources separated by the 4233 COMMA character (US-ASCII decimal 44). 4235 Format Definition: This property is defined by the following 4236 notation: 4238 resources = "RESOURCES" resrcparam ":" text *("," text) CRLF 4240 resrcparam = *( 4241 ; 4242 ; the following are OPTIONAL, 4243 ; but MUST NOT occur more than once 4244 ; 4245 (";" altrepparam) / (";" languageparam) / 4246 ; 4247 ; the following is OPTIONAL, 4248 ; and MAY occur more than once 4249 ; 4250 (";" other-param) 4251 ; 4252 ) 4254 Example: The following is an example of this property: 4256 RESOURCES:EASEL,PROJECTOR,VCR 4258 RESOURCES;LANGUAGE=fr:Nettoyeur haute pression 4260 3.8.1.11. Status 4262 Property Name: STATUS 4264 Purpose: This property defines the overall status or confirmation 4265 for the calendar component. 4267 Value Type: TEXT 4269 Property Parameters: IANA and non-standard property parameters can 4270 be specified on this property. 4272 Conformance: This property can be specified once in "VEVENT", 4273 "VTODO" or "VJOURNAL" calendar components. 4275 Description: In a group scheduled calendar component, the property 4276 is used by the "Organizer" to provide a confirmation of the event 4277 to the "Attendees". For example in a "VEVENT" calendar component, 4278 the "Organizer" can indicate that a meeting is tentative, 4279 confirmed or cancelled. In a "VTODO" calendar component, the 4280 "Organizer" can indicate that an action item needs action, is 4281 completed, is in process or being worked on, or has been 4282 cancelled. In a "VJOURNAL" calendar component, the "Organizer" 4283 can indicate that a journal entry is draft, final or has been 4284 cancelled or removed. 4286 Format Definition: This property is defined by the following 4287 notation: 4289 status = "STATUS" statparam ":" statvalue CRLF 4291 statparam = *(";" other-param) 4293 statvalue = (statvalue-event 4294 / statvalue-todo 4295 / statvalue-jour) 4297 statvalue-event = "TENTATIVE" ;Indicates event is tentative. 4298 / "CONFIRMED" ;Indicates event is definite. 4299 / "CANCELLED" ;Indicates event was cancelled. 4300 ;Status values for a "VEVENT" 4302 statvalue-todo = "NEEDS-ACTION" ;Indicates to-do needs action. 4303 / "COMPLETED" ;Indicates to-do completed. 4304 / "IN-PROCESS" ;Indicates to-do in process of. 4305 / "CANCELLED" ;Indicates to-do was cancelled. 4306 ;Status values for "VTODO". 4308 statvalue-jour = "DRAFT" ;Indicates journal is draft. 4309 / "FINAL" ;Indicates journal is final. 4310 / "CANCELLED" ;Indicates journal is removed. 4311 ;Status values for "VJOURNAL". 4313 Example: The following is an example of this property for a "VEVENT" 4314 calendar component: 4316 STATUS:TENTATIVE 4318 The following is an example of this property for a "VTODO" 4319 calendar component: 4321 STATUS:NEEDS-ACTION 4323 The following is an example of this property for a "VJOURNAL" 4324 calendar component: 4326 STATUS:DRAFT 4328 3.8.1.12. Summary 4329 Property Name: SUMMARY 4331 Purpose: This property defines a short summary or subject for the 4332 calendar component. 4334 Value Type: TEXT 4336 Property Parameters: IANA, non-standard, alternate text 4337 representation and language property parameters can be specified 4338 on this property. 4340 Conformance: The property can be specified in "VEVENT", "VTODO", 4341 "VJOURNAL" or "VALARM" calendar components. 4343 Description: This property is used in the "VEVENT", "VTODO" and 4344 "VJOURNAL" calendar components to capture a short, one line 4345 summary about the activity or journal entry. 4347 This property is used in the "VALARM" calendar component to 4348 capture the subject of an EMAIL category of alarm. 4350 Format Definition: This property is defined by the following 4351 notation: 4353 summary = "SUMMARY" summparam ":" text CRLF 4355 summparam = *( 4356 ; 4357 ; the following are OPTIONAL, 4358 ; but MUST NOT occur more than once 4359 ; 4360 (";" altrepparam) / (";" languageparam) / 4361 ; 4362 ; the following is OPTIONAL, 4363 ; and MAY occur more than once 4364 ; 4365 (";" other-param) 4366 ; 4367 ) 4369 Example: The following is an example of this property: 4371 SUMMARY:Department Party 4373 3.8.2. Date and Time Component Properties 4375 The following properties specify date and time related information in 4376 calendar components. 4378 3.8.2.1. Date/Time Completed 4380 Property Name: COMPLETED 4382 Purpose: This property defines the date and time that a to-do was 4383 actually completed. 4385 Value Type: DATE-TIME 4387 Property Parameters: IANA and non-standard property parameters can 4388 be specified on this property. 4390 Conformance: The property can be specified in a "VTODO" calendar 4391 component. The value MUST be specified as a date with UTC time. 4393 Description: This property defines the date and time that a to-do 4394 was actually completed. 4396 Format Definition: This property is defined by the following 4397 notation: 4399 completed = "COMPLETED" compparam ":" date-time CRLF 4401 compparam = *(";" other-param) 4403 Example: The following is an example of this property: 4405 COMPLETED:19960401T150000Z 4407 3.8.2.2. Date/Time End 4409 Property Name: DTEND 4411 Purpose: This property specifies the date and time that a calendar 4412 component ends. 4414 Value Type: The default value type is DATE-TIME. The value type can 4415 be set to a DATE value type. 4417 Property Parameters: IANA, non-standard, value data type, and time 4418 zone identifier property parameters can be specified on this 4419 property. 4421 Conformance: This property can be specified in "VEVENT" or 4422 "VFREEBUSY" calendar components. 4424 Description: Within the "VEVENT" calendar component, this property 4425 defines the date and time by which the event ends. The value type 4426 of this property MUST be the same as the "DTSTART" property, and 4427 its value MUST be later in time than the value of the "DTSTART" 4428 property. Furthermore, this property MUST be specified as a date 4429 with local time if and only if the "DTSTART" property is also 4430 specified as a date with local time. 4432 Within the "VFREEBUSY" calendar component, this property defines 4433 the end date and time for the free or busy time information. The 4434 time MUST be specified in the UTC time format. The value MUST be 4435 later in time than the value of the "DTSTART" property. 4437 Format Definition: This property is defined by the following 4438 notation: 4440 dtend = "DTEND" dtendparam ":" dtendval CRLF 4442 dtendparam = *( 4443 ; 4444 ; the following are OPTIONAL, 4445 ; but MUST NOT occur more than once 4446 ; 4447 (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / 4448 (";" tzidparam) / 4449 ; 4450 ; the following is OPTIONAL, 4451 ; and MAY occur more than once 4452 ; 4453 (";" other-param) 4454 ; 4455 ) 4457 dtendval = date-time / date 4458 ;Value MUST match value type 4460 Example: The following is an example of this property: 4462 DTEND:19960401T150000Z 4464 DTEND;VALUE=DATE:19980704 4466 3.8.2.3. Date/Time Due 4468 Property Name: DUE 4470 Purpose: This property defines the date and time that a to-do is 4471 expected to be completed. 4473 Value Type: The default value type is DATE-TIME. The value type can 4474 be set to a DATE value type. 4476 Property Parameters: IANA, non-standard, value data type, and time 4477 zone identifier property parameters can be specified on this 4478 property. 4480 Conformance: The property can be specified once in a "VTODO" 4481 calendar component. 4483 Description: This property defines the date and time before which a 4484 to-do is expected to be completed. For cases where this property 4485 is specified in a "VTODO" calendar component that also specifies a 4486 "DTSTART" property, the value type of this property MUST be the 4487 same as the "DTSTART" property, and the value of this property 4488 MUST be later in time than the value of the "DTSTART" property. 4489 Furthermore, this property MUST be specified as a date with local 4490 time if and only if the "DTSTART" property is also specified as a 4491 date with local time. 4493 Format Definition: This property is defined by the following 4494 notation: 4496 due = "DUE" dueparam ":" dueval CRLF 4498 dueparam = *( 4499 ; 4500 ; the following are OPTIONAL, 4501 ; but MUST NOT occur more than once 4502 ; 4503 (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / 4504 (";" tzidparam) / 4505 ; 4506 ; the following is OPTIONAL, 4507 ; and MAY occur more than once 4508 ; 4509 (";" other-param) 4510 ; 4511 ) 4513 dueval = date-time / date 4514 ;Value MUST match value type 4516 Example: The following is an example of this property: 4518 DUE:19980430T000000Z 4520 3.8.2.4. Date/Time Start 4522 Property Name: DTSTART 4524 Purpose: This property specifies when the calendar component begins. 4526 Value Type: The default value type is DATE-TIME. The time value 4527 MUST be one of the forms defined for the DATE-TIME value type. 4528 The value type can be set to a DATE value type. 4530 Property Parameters: IANA, non-standard, value data type, and time 4531 zone identifier property parameters can be specified on this 4532 property. 4534 Conformance: This property can be specified once in the "VEVENT", 4535 "VTODO", or "VFREEBUSY" calendar components as well as in the 4536 "STANDARD" and "DAYLIGHT" sub-components. This property is 4537 REQUIRED in all types of recurring calendar components that 4538 specify the "RRULE" property. This property is also REQUIRED in 4539 "VEVENT" calendar components contained in iCalendar objects that 4540 don't specify the "METHOD" property. 4542 Description: Within the "VEVENT" calendar component, this property 4543 defines the start date and time for the event. 4545 Within the "VFREEBUSY" calendar component, this property defines 4546 the start date and time for the free or busy time information. 4547 The time MUST be specified in UTC time. 4549 Within the "STANDARD" and "DAYLIGHT" sub-components, this property 4550 defines the effective start date and time for a time zone 4551 specification. This property is REQUIRED within each "STANDARD" 4552 and "DAYLIGHT" sub-components included in "VTIMEZONE" calendar 4553 components and MUST be specified as a date with local time without 4554 the "TZID" property parameter. 4556 Format Definition: This property is defined by the following 4557 notation: 4559 dtstart = "DTSTART" dtstparam ":" dtstval CRLF 4561 dtstparam = *( 4562 ; 4563 ; the following are OPTIONAL, 4564 ; but MUST NOT occur more than once 4565 ; 4566 (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / 4567 (";" tzidparam) / 4568 ; 4569 ; the following is OPTIONAL, 4570 ; and MAY occur more than once 4571 ; 4572 (";" other-param) 4573 ; 4574 ) 4576 dtstval = date-time / date 4577 ;Value MUST match value type 4579 Example: The following is an example of this property: 4581 DTSTART:19980118T073000Z 4583 3.8.2.5. Duration 4585 Property Name: DURATION 4587 Purpose: This property specifies a positive duration of time. 4589 Value Type: DURATION 4591 Property Parameters: IANA and non-standard property parameters can 4592 be specified on this property. 4594 Conformance: This property can be specified in "VEVENT", "VTODO", or 4595 "VALARM" calendar components. 4597 Description: In a "VEVENT" calendar component the property may be 4598 used to specify a duration of the event, instead of an explicit 4599 end date/time. In a "VTODO" calendar component the property may 4600 be used to specify a duration for the to-do, instead of an 4601 explicit due date/time. In a "VALARM" calendar component the 4602 property may be used to specify the delay period prior to 4603 repeating an alarm. When the "DURATION" property relates to a 4604 "DTSTART" property that is specified as a DATE value, then the 4605 "DURATION" property MUST be specified as a "dur-day" or "dur-week" 4606 value. 4608 Format Definition: This property is defined by the following 4609 notation: 4611 duration = "DURATION" durparam ":" dur-value CRLF 4612 ;consisting of a positive duration of time. 4614 durparam = *(";" other-param) 4616 Example: The following is an example of this property that specifies 4617 an interval of time of 1 hour and zero minutes and zero seconds: 4619 DURATION:PT1H0M0S 4621 The following is an example of this property that specifies an 4622 interval of time of 15 minutes. 4624 DURATION:PT15M 4626 3.8.2.6. Free/Busy Time 4628 Property Name: FREEBUSY 4630 Purpose: This property defines one or more free or busy time 4631 intervals. 4633 Value Type: PERIOD 4635 Property Parameters: IANA, non-standard, and free/busy time type 4636 property parameters can be specified on this property. 4638 Conformance: The property can be specified in a "VFREEBUSY" calendar 4639 component. 4641 Description: These time periods can be specified as either a start 4642 and end date-time or a start date-time and duration. The date and 4643 time MUST be a UTC time format. 4645 "FREEBUSY" properties within the "VFREEBUSY" calendar component 4646 SHOULD be sorted in ascending order, based on start time and then 4647 end time, with the earliest periods first. 4649 The "FREEBUSY" property can specify more than one value, separated 4650 by the COMMA character (US-ASCII decimal 44). In such cases, the 4651 "FREEBUSY" property values MUST all be of the same "FBTYPE" 4652 property parameter type (e.g., all values of a particular "FBTYPE" 4653 listed together in a single property). 4655 Format Definition: This property is defined by the following 4656 notation: 4658 freebusy = "FREEBUSY" fbparam ":" fbvalue CRLF 4660 fbparam = *( 4661 ; 4662 ; the following is OPTIONAL, 4663 ; but MUST NOT occur more than once 4664 ; 4665 (";" fbtypeparam) / 4666 ; 4667 ; the following is OPTIONAL, 4668 ; and MAY occur more than once 4669 ; 4670 (";" other-param) 4671 ; 4672 ) 4674 fbvalue = period *("," period) 4675 ;Time value MUST be in the UTC time format. 4677 Example: The following are some examples of this property: 4679 FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:19970308T160000Z/PT8H30M 4681 FREEBUSY;FBTYPE=FREE:19970308T160000Z/PT3H,19970308T200000Z/PT1H 4683 FREEBUSY;FBTYPE=FREE:19970308T160000Z/PT3H,19970308T200000Z/PT1H 4684 ,19970308T230000Z/19970309T000000Z 4686 3.8.2.7. Time Transparency 4688 Property Name: TRANSP 4690 Purpose: This property defines whether an event is transparent or 4691 not to busy time searches. 4693 Value Type: TEXT 4695 Property Parameters: IANA and non-standard property parameters can 4696 be specified on this property. 4698 Conformance: This property can be specified once in a "VEVENT" 4699 calendar component. 4701 Description: Time Transparency is the characteristic of an event 4702 that determines whether it appears to consume time on a calendar. 4703 Events that consume actual time for the individual or resource 4704 associated with the calendar SHOULD be recorded as OPAQUE, 4705 allowing them to be detected by free-busy time searches. Other 4706 events, which do not take up the individual's (or resource's) time 4707 SHOULD be recorded as TRANSPARENT, making them invisible to free- 4708 busy time searches. 4710 Format Definition: This property is defined by the following 4711 notation: 4713 transp = "TRANSP" transparam ":" transvalue CRLF 4715 transparam = *(";" other-param) 4717 transvalue = "OPAQUE" 4718 ;Blocks or opaque on busy time searches. 4719 / "TRANSPARENT" 4720 ;Transparent on busy time searches. 4721 ;Default value is OPAQUE 4723 Example: The following is an example of this property for an event 4724 that is transparent or does not block on free/busy time searches: 4726 TRANSP:TRANSPARENT 4728 The following is an example of this property for an event that is 4729 opaque or blocks on free/busy time searches: 4731 TRANSP:OPAQUE 4733 3.8.3. Time Zone Component Properties 4735 The following properties specify time zone information in calendar 4736 components. 4738 3.8.3.1. Time Zone Identifier 4740 Property Name: TZID 4742 Purpose: This property specifies the text value that uniquely 4743 identifies the "VTIMEZONE" calendar component in the scope of an 4744 iCalendar object. 4746 Value Type: TEXT 4748 Property Parameters: IANA and non-standard property parameters can 4749 be specified on this property. 4751 Conformance: This property MUST be specified in a "VTIMEZONE" 4752 calendar component. 4754 Description: This is the label by which a time zone calendar 4755 component is referenced by any iCalendar properties whose value 4756 type is either DATE-TIME or TIME and not intended to specify a UTC 4757 or a "floating" time. The presence of the SOLIDUS character (US- 4758 ASCII decimal 47) as a prefix, indicates that this "TZID" 4759 represents an unique ID in a globally defined time zone registry 4760 (when such registry is defined). 4762 Note: This document does not define a naming convention for 4763 time zone identifiers. Implementers may want to use the naming 4764 conventions defined in existing time zone specifications such 4765 as the public-domain TZ database [TZDB]. The specification of 4766 globally unique time zone identifiers is not addressed by this 4767 document and is left for future study. 4769 Format Definition: This property is defined by the following 4770 notation: 4772 tzid = "TZID" tzidpropparam ":" [tzidprefix] text CRLF 4774 tzidpropparam = *(";" other-param) 4776 ;tzidprefix = "/" 4777 ; Defined previously. Just listed here for reader convenience. 4779 Example: The following are examples of non-globally unique time zone 4780 identifiers: 4782 TZID:America/New_York 4784 TZID:America/Los_Angeles 4786 The following is an example of a fictitious globally unique time 4787 zone identifier: 4789 TZID:/example.org/America/New_York 4791 3.8.3.2. Time Zone Name 4793 Property Name: TZNAME 4795 Purpose: This property specifies the customary designation for a 4796 time zone description. 4798 Value Type: TEXT 4800 Property Parameters: IANA, non-standard, and language property 4801 parameters can be specified on this property. 4803 Conformance: This property can be specified in "STANDARD" and 4804 "DAYLIGHT" sub-components. 4806 Description: This property specifies a customary name that can be 4807 used when displaying dates that occur during the observance 4808 defined by the time zone sub-component. 4810 Format Definition: This property is defined by the following 4811 notation: 4813 tzname = "TZNAME" tznparam ":" text CRLF 4815 tznparam = *( 4816 ; 4817 ; the following is OPTIONAL, 4818 ; but MUST NOT occur more than once 4819 ; 4820 (";" languageparam) / 4821 ; 4822 ; the following is OPTIONAL, 4823 ; and MAY occur more than once 4824 ; 4825 (";" other-param) 4826 ; 4827 ) 4829 Example: The following are examples of this property: 4831 TZNAME:EST 4833 TZNAME;LANGUAGE=fr-CA:HNE 4835 3.8.3.3. Time Zone Offset From 4837 Property Name: TZOFFSETFROM 4839 Purpose: This property specifies the offset which is in use prior to 4840 this time zone observance. 4842 Value Type: UTC-OFFSET 4844 Property Parameters: IANA and non-standard property parameters can 4845 be specified on this property. 4847 Conformance: This property MUST be specified in "STANDARD" and 4848 "DAYLIGHT" sub-components. 4850 Description: This property specifies the offset which is in use 4851 prior to this time observance. It is used to calculate the 4852 absolute time at which the transition to a given observance takes 4853 place. This property MUST only be specified in a "VTIMEZONE" 4854 calendar component. A "VTIMEZONE" calendar component MUST include 4855 this property. The property value is a signed numeric indicating 4856 the number of hours and possibly minutes from UTC. Positive 4857 numbers represent time zones east of the prime meridian, or ahead 4858 of UTC. Negative numbers represent time zones west of the prime 4859 meridian, or behind UTC. 4861 Format Definition: This property is defined by the following 4862 notation: 4864 tzoffsetfrom = "TZOFFSETFROM" frmparam ":" utc-offset 4865 CRLF 4867 frmparam = *(";" other-param) 4869 Example: The following are examples of this property: 4871 TZOFFSETFROM:-0500 4873 TZOFFSETFROM:+1345 4875 3.8.3.4. Time Zone Offset To 4877 Property Name: TZOFFSETTO 4879 Purpose: This property specifies the offset which is in use in this 4880 time zone observance. 4882 Value Type: UTC-OFFSET 4884 Property Parameters: IANA and non-standard property parameters can 4885 be specified on this property. 4887 Conformance: This property MUST be specified in "STANDARD" and 4888 "DAYLIGHT" sub-components. 4890 Description: This property specifies the offset which is in use in 4891 this time zone observance. It is used to calculate the absolute 4892 time for the new observance. The property value is a signed 4893 numeric indicating the number of hours and possibly minutes from 4894 UTC. Positive numbers represent time zones east of the prime 4895 meridian, or ahead of UTC. Negative numbers represent time zones 4896 west of the prime meridian, or behind UTC. 4898 Format Definition: This property is defined by the following 4899 notation: 4901 tzoffsetto = "TZOFFSETTO" toparam ":" utc-offset CRLF 4903 toparam = *(";" other-param) 4905 Example: The following are examples of this property: 4907 TZOFFSETTO:-0400 4909 TZOFFSETTO:+1245 4911 3.8.3.5. Time Zone URL 4913 Property Name: TZURL 4915 Purpose: This property provides a means for a "VTIMEZONE" component 4916 to point to a network location that can be used to retrieve an up- 4917 to-date version of itself. 4919 Value Type: URI 4921 Property Parameters: IANA and non-standard property parameters can 4922 be specified on this property. 4924 Conformance: This property can be specified in a "VTIMEZONE" 4925 calendar component. 4927 Description: This property provides a means for a "VTIMEZONE" 4928 component to point to a network location that can be used to 4929 retrieve an up-to-date version of itself. This provides a hook to 4930 handle changes government bodies impose upon time zone 4931 definitions. Retrieval of this resource results in an iCalendar 4932 object containing a single "VTIMEZONE" component and a "METHOD" 4933 property set to PUBLISH. 4935 Format Definition: This property is defined by the following 4936 notation: 4938 tzurl = "TZURL" tzurlparam ":" uri CRLF 4940 tzurlparam = *(";" other-param) 4942 Example: The following is an example of this property: 4944 TZURL:http://timezones.example.org/tz/America-Los_Angeles.ics 4946 3.8.4. Relationship Component Properties 4948 The following properties specify relationship information in calendar 4949 components. 4951 3.8.4.1. Attendee 4953 Property Name: ATTENDEE 4955 Purpose: This property defines an "Attendee" within a calendar 4956 component. 4958 Value Type: CAL-ADDRESS 4960 Property Parameters: IANA, non-standard, language, calendar user 4961 type, group or list membership, participation role, participation 4962 status, RSVP expectation, delegatee, delegator, sent by, common 4963 name or directory entry reference property parameters can be 4964 specified on this property. 4966 Conformance: This property MUST be specified in an iCalendar object 4967 that specifies a group scheduled calendar entity. This property 4968 MUST NOT be specified in an iCalendar object when publishing the 4969 calendar information (e.g., NOT in an iCalendar object that 4970 specifies the publication of a calendar user's busy time, event, 4971 to-do or journal). This property is not specified in an iCalendar 4972 object that specifies only a time zone definition or that defines 4973 calendar components that are not group scheduled components, but 4974 are components only on a single user's calendar. 4976 Description: This property MUST only be specified within calendar 4977 components to specify participants, non-participants and the chair 4978 of a group scheduled calendar entity. The property is specified 4979 within an "EMAIL" category of the "VALARM" calendar component to 4980 specify an email address that is to receive the email type of 4981 iCalendar alarm. 4983 The property parameter "CN" is for the common or displayable name 4984 associated with the calendar address; "ROLE", for the intended 4985 role that the attendee will have in the calendar component; 4986 "PARTSTAT", for the status of the attendee's participation; 4987 "RSVP", for indicating whether the favor of a reply is requested; 4988 "CUTYPE", to indicate the type of calendar user; "MEMBER", to 4989 indicate the groups that the attendee belongs to; "DELEGATED-TO", 4990 to indicate the calendar users that the original request was 4991 delegated to; and "DELEGATED-FROM", to indicate whom the request 4992 was delegated from; "SENT-BY", to indicate whom is acting on 4993 behalf of the "ATTENDEE"; and "DIR", to indicate the URI that 4994 points to the directory information corresponding to the attendee. 4995 These property parameters can be specified on an "ATTENDEE" 4996 property in either a "VEVENT", "VTODO" or "VJOURNAL" calendar 4997 component. They MUST NOT be specified in an "ATTENDEE" property 4998 in a "VFREEBUSY" or "VALARM" calendar component. If the 4999 "LANGUAGE" property parameter is specified, the identified 5000 language applies to the "CN" parameter. 5002 A recipient delegated a request MUST inherit the "RSVP" and "ROLE" 5003 values from the attendee that delegated the request to them. 5005 Multiple attendees can be specified by including multiple 5006 "ATTENDEE" properties within the calendar component. 5008 Format Definition: This property is defined by the following 5009 notation: 5011 attendee = "ATTENDEE" attparam ":" cal-address CRLF 5013 attparam = *( 5014 ; 5015 ; the following are OPTIONAL, 5016 ; but MUST NOT occur more than once 5017 ; 5018 (";" cutypeparam) / (";" memberparam) / 5019 (";" roleparam) / (";" partstatparam) / 5020 (";" rsvpparam) / (";" deltoparam) / 5021 (";" delfromparam) / (";" sentbyparam) / 5022 (";" cnparam) / (";" dirparam) / 5023 (";" languageparam) / 5024 ; 5025 ; the following is OPTIONAL, 5026 ; and MAY occur more than once 5027 ; 5028 (";" other-param) 5029 ; 5030 ) 5032 Example: The following are examples of this property's use for a 5033 to-do: 5035 ATTENDEE;MEMBER="mailto:DEV-GROUP@example.com": 5036 mailto:joecool@example.com 5037 ATTENDEE;DELEGATED-FROM="mailto:immud@example.com": 5038 mailto:ildoit@example.com 5040 The following is an example of this property used for specifying 5041 multiple attendees to an event: 5043 ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;CN=Henry 5044 Cabot:mailto:hcabot@example.com 5045 ATTENDEE;ROLE=REQ-PARTICIPANT;DELEGATED-FROM="mailto:bob@ 5046 example.com";PARTSTAT=ACCEPTED;CN=Jane Doe:mailto:jdoe@ 5047 example.com 5049 The following is an example of this property with a URI to the 5050 directory information associated with the attendee: 5052 ATTENDEE;CN=John Smith;DIR="ldap://example.com:6666/o=ABC% 5053 20Industries,c=US???(cn=Jim%20Dolittle)":mailto:jimdo@ 5054 example.com 5056 The following is an example of this property with "delegatee" and 5057 "delegator" information for an event: 5059 ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;DELEGATED-FROM= 5060 "mailto:iamboss@example.com";CN=Henry Cabot:mailto:hcabot@ 5061 example.com 5062 ATTENDEE;ROLE=NON-PARTICIPANT;PARTSTAT=DELEGATED;DELEGATED-TO= 5063 "mailto:hcabot@example.com";CN=The Big Cheese:mailto:iamboss 5064 @example.com 5065 ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;CN=Jane Doe 5066 :mailto:jdoe@example.com 5068 Example: The following is an example of this property's use when 5069 another calendar user is acting on behalf of the "Attendee": 5071 ATTENDEE;SENT-BY=mailto:jan_doe@example.com;CN=John Smith: 5072 mailto:jsmith@example.com 5074 3.8.4.2. Contact 5076 Property Name: CONTACT 5078 Purpose: This property is used to represent contact information or 5079 alternately a reference to contact information associated with the 5080 calendar component. 5082 Value Type: TEXT 5084 Property Parameters: IANA, non-standard, alternate text 5085 representation and language property parameters can be specified 5086 on this property. 5088 Conformance: This property can be specified in a "VEVENT", "VTODO", 5089 "VJOURNAL" or "VFREEBUSY" calendar component. 5091 Description: The property value consists of textual contact 5092 information. An alternative representation for the property value 5093 can also be specified that refers to a URI pointing to an 5094 alternate form, such as a vCard [RFC2426], for the contact 5095 information. 5097 Format Definition: This property is defined by the following 5098 notation: 5100 contact = "CONTACT" contparam ":" text CRLF 5102 contparam = *( 5103 ; 5104 ; the following are OPTIONAL, 5105 ; but MUST NOT occur more than once 5106 ; 5107 (";" altrepparam) / (";" languageparam) / 5108 ; 5109 ; the following is OPTIONAL, 5110 ; and MAY occur more than once 5111 ; 5112 (";" other-param) 5113 ; 5114 ) 5116 Example: The following is an example of this property referencing 5117 textual contact information: 5119 CONTACT:Jim Dolittle\, ABC Industries\, +1-919-555-1234 5121 The following is an example of this property with an alternate 5122 representation of a LDAP URI to a directory entry containing the 5123 contact information: 5125 CONTACT;ALTREP="ldap://example.com:6666/o=ABC%20Industries\, 5126 c=US???(cn=Jim%20Dolittle)":Jim Dolittle\, ABC Industries\, 5127 +1-919-555-1234 5129 The following is an example of this property with an alternate 5130 representation of a MIME body part containing the contact 5131 information, such as a vCard [RFC2426] embedded in a text/ 5132 directory media type [RFC2425]: 5134 CONTACT;ALTREP="CID:part3.msg970930T083000SILVER@example.com": 5135 Jim Dolittle\, ABC Industries\, +1-919-555-1234 5137 The following is an example of this property referencing a network 5138 resource, such as a vCard [RFC2426] object containing the contact 5139 information: 5141 CONTACT;ALTREP="http://example.com/pdi/jdoe.vcf":Jim 5142 Dolittle\, ABC Industries\, +1-919-555-1234 5144 3.8.4.3. Organizer 5146 Property Name: ORGANIZER 5148 Purpose: This property defines the organizer for a calendar 5149 component. 5151 Value Type: CAL-ADDRESS 5153 Property Parameters: IANA, non-standard, language, common name, 5154 directory entry reference, sent by property parameters can be 5155 specified on this property. 5157 Conformance: This property MUST be specified in an iCalendar object 5158 that specifies a group scheduled calendar entity. This property 5159 MUST be specified in an iCalendar object that specifies the 5160 publication of a calendar user's busy time. This property MUST 5161 NOT be specified in an iCalendar object that specifies only a time 5162 zone definition or that defines calendar components that are not 5163 group scheduled components, but are components only on a single 5164 user's calendar. 5166 Description: This property is specified within the "VEVENT", 5167 "VTODO", "VJOURNAL" calendar components to specify the organizer 5168 of a group scheduled calendar entity. The property is specified 5169 within the "VFREEBUSY" calendar component to specify the calendar 5170 user requesting the free or busy time. When publishing a 5171 "VFREEBUSY" calendar component, the property is used to specify 5172 the calendar that the published busy time came from. 5174 The property has the property parameters "CN", for specifying the 5175 common or display name associated with the "Organizer", "DIR", for 5176 specifying a pointer to the directory information associated with 5177 the "Organizer", "SENT-BY", for specifying another calendar user 5178 that is acting on behalf of the "Organizer". The non-standard 5179 parameters may also be specified on this property. If the 5180 "LANGUAGE" property parameter is specified, the identified 5181 language applies to the "CN" parameter value. 5183 Format Definition: This property is defined by the following 5184 notation: 5186 organizer = "ORGANIZER" orgparam ":" 5187 cal-address CRLF 5189 orgparam = *( 5190 ; 5191 ; the following are OPTIONAL, 5192 ; but MUST NOT occur more than once 5193 ; 5194 (";" cnparam) / (";" dirparam) / (";" sentbyparam) / 5195 (";" languageparam) / 5196 ; 5197 ; the following is OPTIONAL, 5198 ; and MAY occur more than once 5199 ; 5200 (";" other-param) 5201 ; 5202 ) 5204 Example: The following is an example of this property: 5206 ORGANIZER;CN=John Smith:mailto:jsmith@example.com 5208 The following is an example of this property with a pointer to the 5209 directory information associated with the organizer: 5211 ORGANIZER;CN=JohnSmith;DIR="ldap://example.com:6666/o=DC%20Ass 5212 ociates,c=US???(cn=John%20Smith)":mailto:jsmith@example.com 5214 The following is an example of this property used by another 5215 calendar user who is acting on behalf of the organizer, with 5216 responses intended to be sent back to the organizer, not the other 5217 calendar user: 5219 ORGANIZER;SENT-BY="mailto:jane_doe@example.com": 5220 mailto:jsmith@example.com 5222 3.8.4.4. Recurrence ID 5224 Property Name: RECURRENCE-ID 5226 Purpose: This property is used in conjunction with the "UID" and 5227 "SEQUENCE" property to identify a specific instance of a recurring 5228 "VEVENT", "VTODO" or "VJOURNAL" calendar component. The property 5229 value is the original value of the "DTSTART" property of the 5230 recurrence instance. 5232 Value Type: The default value type for this property is DATE-TIME. 5233 The default value type is DATE-TIME. The value type can be set to 5234 a DATE value type. This property MUST have the same value type as 5235 the "DTSTART" property contained within the recurring component. 5236 Furthermore, this property MUST be specified as a date with local 5237 time if and only if the "DTSTART" property contained within the 5238 recurring component is specified as a date with local time. 5240 Property Parameters: IANA, non-standard, value data type, time zone 5241 identifier and recurrence identifier range parameters can be 5242 specified on this property. 5244 Conformance: This property can be specified in an iCalendar object 5245 containing a recurring calendar component. 5247 Description: The full range of calendar components specified by a 5248 recurrence set is referenced by referring to just the "UID" 5249 property value corresponding to the calendar component. The 5250 "RECURRENCE-ID" property allows the reference to an individual 5251 instance within the recurrence set. 5253 If the value of the "DTSTART" property is a DATE type value, then 5254 the value MUST be the calendar date for the recurrence instance. 5256 The DATE-TIME value is set to the time when the original 5257 recurrence instance would occur; meaning that if the intent is to 5258 change a Friday meeting to Thursday, the DATE-TIME is still set to 5259 the original Friday meeting. 5261 The "RECURRENCE-ID" property is used in conjunction with the "UID" 5262 and "SEQUENCE" property to identify a particular instance of a 5263 recurring event, to-do or journal. For a given pair of "UID" and 5264 "SEQUENCE" property values, the "RECURRENCE-ID" value for a 5265 recurrence instance is fixed. 5267 The "RANGE" parameter is used to specify the effective range of 5268 recurrence instances from the instance specified by the 5269 "RECURRENCE-ID" property value. The value for the range parameter 5270 can only be "THISANDFUTURE" to indicate a range defined by the 5271 given recurrence instance and all subsequent instances. 5272 Subsequent instances are determined by their "RECURRENCE-ID" value 5273 and not their current scheduled start time. Subsequent instances 5274 defined in separate components are not impacted by the given 5275 recurrence instance. When the given recurrence instance is 5276 rescheduled, all subsequent instances are also rescheduled by the 5277 same time difference. For instance, if the given recurrence 5278 instance is rescheduled to start 2 hours later, then all 5279 subsequent instances are also rescheduled 2 hours later. 5281 Similarly, if the duration of the given recurrence instance is 5282 modified, then all subsequence instances are also modified to have 5283 this same duration. 5285 Note: The "RANGE" parameter may not be appropriate to 5286 reschedule specific subsequent instances of complex recurring 5287 calendar component. Assuming an unbounded recurring calendar 5288 component scheduled to occur on Mondays and Wednesdays, the 5289 "RANGE" parameter could not be used to reschedule only the 5290 future Monday instances to occur on Tuesday instead. In such 5291 cases, the calendar application could simply truncate the 5292 unbounded recurring calendar component (i.e., with the "COUNT" 5293 or "UNTIL" rule parts), and create two new unbounded recurring 5294 calendar components for the future instances. 5296 Format Definition: This property is defined by the following 5297 notation: 5299 recurid = "RECURRENCE-ID" ridparam ":" ridval CRLF 5301 ridparam = *( 5302 ; 5303 ; the following are OPTIONAL, 5304 ; but MUST NOT occur more than once 5305 ; 5306 (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / 5307 (";" tzidparam) / (";" rangeparam) / 5308 ; 5309 ; the following is OPTIONAL, 5310 ; and MAY occur more than once 5311 ; 5312 (";" other-param) 5313 ; 5314 ) 5316 ridval = date-time / date 5317 ;Value MUST match value type 5319 Example: The following are examples of this property: 5321 RECURRENCE-ID;VALUE=DATE:19960401 5323 RECURRENCE-ID;RANGE=THISANDFUTURE:19960120T120000Z 5325 3.8.4.5. Related To 5327 Property Name: RELATED-TO 5329 Purpose: This property is used to represent a relationship or 5330 reference between one calendar component and another. 5332 Value Type: TEXT 5334 Property Parameters: IANA, non-standard, and relationship type 5335 property parameters can be specified on this property. 5337 Conformance: This property can be specified in the "VEVENT", "VTODO" 5338 and "VJOURNAL" calendar components. 5340 Description: The property value consists of the persistent, globally 5341 unique identifier of another calendar component. This value would 5342 be represented in a calendar component by the "UID" property. 5344 By default, the property value points to another calendar 5345 component that has a PARENT relationship to the referencing 5346 object. The "RELTYPE" property parameter is used to either 5347 explicitly state the default PARENT relationship type to the 5348 referenced calendar component or to override the default PARENT 5349 relationship type and specify either a CHILD or SIBLING 5350 relationship. The PARENT relationship indicates that the calendar 5351 component is a subordinate of the referenced calendar component. 5352 The CHILD relationship indicates that the calendar component is a 5353 superior of the referenced calendar component. The SIBLING 5354 relationship indicates that the calendar component is a peer of 5355 the referenced calendar component. 5357 Changes to a calendar component referenced by this property can 5358 have an implicit impact on the related calendar component. For 5359 example, if a group event changes its start or end date or time, 5360 then the related, dependent events will need to have their start 5361 and end dates changed in a corresponding way. Similarly, if a 5362 PARENT calendar component is cancelled or deleted, then there is 5363 an implied impact to the related CHILD calendar components. This 5364 property is intended only to provide information on the 5365 relationship of calendar components. It is up to the target 5366 calendar system to maintain any property implications of this 5367 relationship. 5369 Format Definition: This property is defined by the following 5370 notation: 5372 related = "RELATED-TO" relparam ":" text CRLF 5374 relparam = *( 5375 ; 5376 ; the following is OPTIONAL, 5377 ; but MUST NOT occur more than once 5378 ; 5379 (";" reltypeparam) / 5380 ; 5381 ; the following is OPTIONAL, 5382 ; and MAY occur more than once 5383 ; 5384 (";" other-param) 5385 ; 5386 ) 5388 The following is an example of this property: 5390 RELATED-TO:jsmith.part7.19960817T083000.xyzMail@example.com 5392 RELATED-TO:19960401-080045-4000F192713-0052@example.com 5394 3.8.4.6. Uniform Resource Locator 5396 Property Name: URL 5398 Purpose: This property defines a Uniform Resource Locator (URL) 5399 associated with the iCalendar object. 5401 Value Type: URI 5403 Property Parameters: IANA and non-standard property parameters can 5404 be specified on this property. 5406 Conformance: This property can be specified once in the "VEVENT", 5407 "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components. 5409 Description: This property may be used in a calendar component to 5410 convey a location where a more dynamic rendition of the calendar 5411 information associated with the calendar component can be found. 5412 This memo does not attempt to standardize the form of the URI, nor 5413 the format of the resource pointed to by the property value. If 5414 the URL property and Content-Location MIME header are both 5415 specified, they MUST point to the same resource. 5417 Format Definition: This property is defined by the following 5418 notation: 5420 url = "URL" urlparam ":" uri CRLF 5422 urlparam = *(";" other-param) 5424 Example: The following is an example of this property: 5426 URL:http://example.com/pub/calendars/jsmith/mytime.ics 5428 3.8.4.7. Unique Identifier 5430 Property Name: UID 5432 Purpose: This property defines the persistent, globally unique 5433 identifier for the calendar component. 5435 Value Type: TEXT 5437 Property Parameters: IANA and non-standard property parameters can 5438 be specified on this property. 5440 Conformance: The property MUST be specified in the "VEVENT", 5441 "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components. 5443 Description: The "UID" itself MUST be a globally unique identifier. 5444 The generator of the identifier MUST guarantee that the identifier 5445 is unique. There are several algorithms that can be used to 5446 accomplish this. A good method to assure uniqueness is to put the 5447 domain name or a domain literal IP address of the host on which 5448 the identifier was created on the right hand side of an "@", and 5449 on the left hand side, put a combination of the current calendar 5450 date and time of day (i.e., formatted in as a DATE-TIME value) 5451 along with some other currently unique (perhaps sequential) 5452 identifier available on the system (for example, a process id 5453 number). Using a date/time value on the left hand side and a 5454 domain name or domain literal on the right hand side makes it 5455 possible to guarantee uniqueness since no two hosts should be 5456 using the same domain name or IP address at the same time. Though 5457 other algorithms will work, it is RECOMMENDED that the right hand 5458 side contain some domain identifier (either of the host itself or 5459 otherwise) such that the generator of the message identifier can 5460 guarantee the uniqueness of the left hand side within the scope of 5461 that domain. 5463 This is the method for correlating scheduling messages with the 5464 referenced "VEVENT", "VTODO", or "VJOURNAL" calendar component. 5466 The full range of calendar components specified by a recurrence 5467 set is referenced by referring to just the "UID" property value 5468 corresponding to the calendar component. The "RECURRENCE-ID" 5469 property allows the reference to an individual instance within the 5470 recurrence set. 5472 This property is an important method for group scheduling 5473 applications to match requests with later replies, modifications 5474 or deletion requests. Calendaring and scheduling applications 5475 MUST generate this property in "VEVENT", "VTODO" and "VJOURNAL" 5476 calendar components to assure interoperability with other group 5477 scheduling applications. This identifier is created by the 5478 calendar system that generates an iCalendar object. 5480 Implementations MUST be able to receive and persist values of at 5481 least 255 octets for this property but MUST NOT truncate values in 5482 the middle of a UTF-8 multi-octet sequence. 5484 Format Definition: This property is defined by the following 5485 notation: 5487 uid = "UID" uidparam ":" text CRLF 5489 uidparam = *(";" other-param) 5491 Example: The following is an example of this property: 5493 UID:19960401T080045Z-4000F192713-0052@example.com 5495 3.8.5. Recurrence Component Properties 5497 The following properties specify recurrence information in calendar 5498 components. 5500 3.8.5.1. Exception Date/Times 5502 Property Name: EXDATE 5504 Purpose: This property defines the list of date/time exceptions for 5505 recurring events, to-dos, journal entries or time zone 5506 definitions. 5508 Value Type: The default value type for this property is DATE-TIME. 5509 The value type can be set to DATE. 5511 Property Parameters: IANA, non-standard, value data type and time 5512 zone identifier property parameters can be specified on this 5513 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. 5520 Description: The exception dates, if specified, are used in 5521 computing the recurrence set. The recurrence set is the complete 5522 set of recurrence instances for a calendar component. The 5523 recurrence set is generated by considering the initial "DTSTART" 5524 property along with the "RRULE", "RDATE", and "EXDATE" properties 5525 contained within the recurring component. The "DTSTART" property 5526 defines the first instance in the recurrence set. The "DTSTART" 5527 property value SHOULD match the pattern of the recurrence rule, if 5528 specified. The recurrence set generated with a "DTSTART" property 5529 value that doesn't match the pattern of the rule is undefined. 5530 The final recurrence set is generated by gathering all of the 5531 start date-times generated by any of the specified "RRULE" and 5532 "RDATE" properties, and then excluding any start date and times 5533 specified by "EXDATE" properties. This implies that start date 5534 and times specified by "EXDATE" properties take precedence over 5535 those specified by inclusion properties (i.e., "RDATE" and 5536 "RRULE"). When duplicate instances are generated by the "RRULE" 5537 and "RDATE" properties, only one recurrence is considered. 5538 Duplicate instances are ignored. 5540 The "EXDATE" property can be used to exclude the value specified 5541 in "DTSTART". However, in such cases the original "DTSTART" date 5542 MUST still be maintained by the calendaring and scheduling system 5543 because the original "DTSTART" value has inherent usage 5544 dependencies by other properties such as the "RECURRENCE-ID". 5546 Format Definition: This property is defined by the following 5547 notation: 5549 exdate = "EXDATE" exdtparam ":" exdtval *("," exdtval) CRLF 5551 exdtparam = *( 5552 ; 5553 ; the following are OPTIONAL, 5554 ; but MUST NOT occur more than once 5555 ; 5556 (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / 5557 ; 5558 (";" tzidparam) / 5559 ; 5560 ; the following is OPTIONAL, 5561 ; and MAY occur more than once 5562 ; 5563 (";" other-param) 5564 ; 5565 ) 5567 exdtval = date-time / date 5568 ;Value MUST match value type 5570 Example: The following is an example of this property: 5572 EXDATE:19960402T010000Z,19960403T010000Z,19960404T010000Z 5574 3.8.5.2. Recurrence Date/Times 5576 Property Name: RDATE 5578 Purpose: This property defines the list of date/times for recurring 5579 events, to-dos, journal entries or time zone definitions. 5581 Value Type: The default value type for this property is DATE-TIME. 5582 The value type can be set to DATE or PERIOD. 5584 Property Parameters: IANA, non-standard, value data type and time 5585 zone identifier property parameters can be specified on this 5586 property. 5588 Conformance: This property can be specified in recurring "VEVENT", 5589 "VTODO", and "VJOURNAL" calendar components as well as in the 5590 "STANDARD" and "DAYLIGHT" sub-components of the "VTIMEZONE" 5591 calendar component. 5593 Description: This property can appear along with the "RRULE" 5594 property to define an aggregate set of repeating occurrences. 5595 When they both appear in a recurring component, the recurrence 5596 instances are defined by the union of occurrences defined by both 5597 the "RDATE" and "RRULE". 5599 The recurrence dates, if specified, are used in computing the 5600 recurrence set. The recurrence set is the complete set of 5601 recurrence instances for a calendar component. The recurrence set 5602 is generated by considering the initial "DTSTART" property along 5603 with the "RRULE", "RDATE", and "EXDATE" properties contained 5604 within the recurring component. The "DTSTART" property defines 5605 the first instance in the recurrence set. The "DTSTART" property 5606 value SHOULD match the pattern of the recurrence rule, if 5607 specified. The recurrence set generated with a "DTSTART" property 5608 value that doesn't match the pattern of the rule is undefined. 5609 The final recurrence set is generated by gathering all of the 5610 start date-times generated by any of the specified "RRULE" and 5611 "RDATE" properties, and then excluding any start date and times 5612 specified by "EXDATE" properties. This implies that start date/ 5613 times specified by "EXDATE" properties take precedence over those 5614 specified by inclusion properties (i.e., "RDATE" and "RRULE"). 5615 Where duplicate instances are generated by the "RRULE" and "RDATE" 5616 properties, only one recurrence is considered. Duplicate 5617 instances are ignored. 5619 Format Definition: This property is defined by the following 5620 notation: 5622 rdate = "RDATE" rdtparam ":" rdtval *("," rdtval) CRLF 5624 rdtparam = *( 5625 ; 5626 ; the following are OPTIONAL, 5627 ; but MUST NOT occur more than once 5628 ; 5629 (";" "VALUE" "=" ("DATE-TIME" / "DATE" / "PERIOD")) / 5630 (";" tzidparam) / 5631 ; 5632 ; the following is OPTIONAL, 5633 ; and MAY occur more than once 5634 ; 5635 (";" other-param) 5636 ; 5637 ) 5639 rdtval = date-time / date / period 5640 ;Value MUST match value type 5642 Example: The following are examples of this property: 5644 RDATE:19970714T123000Z 5645 RDATE;TZID=America/New_York:19970714T083000 5647 RDATE;VALUE=PERIOD:19960403T020000Z/19960403T040000Z, 5648 19960404T010000Z/PT3H 5650 RDATE;VALUE=DATE:19970101,19970120,19970217,19970421 5651 19970526,19970704,19970901,19971014,19971128,19971129,19971225 5653 3.8.5.3. Recurrence Rule 5655 Property Name: RRULE 5657 Purpose: This property defines a rule or repeating pattern for 5658 recurring events, to-dos, journal entries or time zone 5659 definitions. 5661 Value Type: RECUR 5663 Property Parameters: IANA and non-standard property parameters can 5664 be specified on this property. 5666 Conformance: This property can be specified in recurring "VEVENT", 5667 "VTODO" and "VJOURNAL" calendar components as well as in the 5668 "STANDARD" and "DAYLIGHT" sub-components of the "VTIMEZONE" 5669 calendar component, but it SHOULD NOT be specified more than once. 5670 The recurrence set generated with multiple "RRULE" properties is 5671 undefined. 5673 Description: The recurrence rule, if specified, is used in computing 5674 the recurrence set. The recurrence set is the complete set of 5675 recurrence instances for a calendar component. The recurrence set 5676 is generated by considering the initial "DTSTART" property along 5677 with the "RRULE", "RDATE", and "EXDATE" properties contained 5678 within the recurring component. The "DTSTART" property defines 5679 the first instance in the recurrence set. The "DTSTART" property 5680 value SHOULD be synchronized with the recurrence rule, if 5681 specified. The recurrence set generated with a "DTSTART" property 5682 value not synchronized with the recurrence rule is undefined. The 5683 final recurrence set is generated by gathering all of the start 5684 date/times generated by any of the specified "RRULE" and "RDATE" 5685 properties, and then excluding any start date/times specified by 5686 "EXDATE" properties. This implies that start date/times specified 5687 by "EXDATE" properties take precedence over those specified by 5688 inclusion properties (i.e., "RDATE" and "RRULE"). Where duplicate 5689 instances are generated by the "RRULE" and "RDATE" properties, 5690 only one recurrence is considered. Duplicate instances are 5691 ignored. 5693 The "DTSTART" property specified within the iCalendar object 5694 defines the first instance of the recurrence. In most cases, a 5695 "DTSTART" property of DATE-TIME value type used with a recurrence 5696 rule, should be specified as a date with local time and time zone 5697 reference to make sure all the recurrence instances start at the 5698 same local time regardless of time zone changes. 5700 If the duration of the recurring component is specified with the 5701 "DTEND" or "DUE" property, then the same exact duration will apply 5702 to all the members of the generated recurrence set. Else, if the 5703 duration of the recurring component is specified with the 5704 "DURATION" property, then the same nominal duration will apply to 5705 all the members of the generated recurrence set and the exact 5706 duration of each recurrence instance will depend on its specific 5707 start time. For example, recurrence instances of a nominal 5708 duration of one day will have an exact duration of more or less 5709 than 24 hours on a day where a time zone shift occurs. The 5710 duration of a specific recurrence may be modified in an exception 5711 component or simply by using an "RDATE" property of PERIOD value 5712 type. 5714 Format Definition: This property is defined by the following 5715 notation: 5717 rrule = "RRULE" rrulparam ":" recur CRLF 5719 rrulparam = *(";" other-param) 5721 Example: All examples assume the Eastern United States time zone. 5723 Daily for 10 occurrences: 5725 DTSTART;TZID=America/New_York:19970902T090000 5726 RRULE:FREQ=DAILY;COUNT=10 5728 ==> (1997 9:00 AM EDT) September 2-11 5730 Daily until December 24, 1997: 5732 DTSTART;TZID=America/New_York:19970902T090000 5733 RRULE:FREQ=DAILY;UNTIL=19971224T000000Z 5735 ==> (1997 9:00 AM EDT) September 2-30;October 1-25 5736 (1997 9:00 AM EST) October 26-31;November 1-30;December 1-23 5738 Every other day - forever: 5740 DTSTART;TZID=America/New_York:19970902T090000 5741 RRULE:FREQ=DAILY;INTERVAL=2 5743 ==> (1997 9:00 AM EDT) September 2,4,6,8...24,26,28,30; 5744 October 2,4,6...20,22,24 5745 (1997 9:00 AM EST) October 26,28,30; 5746 November 1,3,5,7...25,27,29; 5747 December 1,3,... 5749 Every 10 days, 5 occurrences: 5751 DTSTART;TZID=America/New_York:19970902T090000 5752 RRULE:FREQ=DAILY;INTERVAL=10;COUNT=5 5754 ==> (1997 9:00 AM EDT) September 2,12,22; 5755 October 2,12 5757 Everyday in January, for 3 years: 5759 DTSTART;TZID=America/New_York:19980101T090000 5761 RRULE:FREQ=YEARLY;UNTIL=20000131T140000Z; 5762 BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA 5763 or 5764 RRULE:FREQ=DAILY;UNTIL=20000131T140000Z;BYMONTH=1 5766 ==> (1998 9:00 AM EST)January 1-31 5767 (1999 9:00 AM EST)January 1-31 5768 (2000 9:00 AM EST)January 1-31 5770 Weekly for 10 occurrences 5772 DTSTART;TZID=America/New_York:19970902T090000 5773 RRULE:FREQ=WEEKLY;COUNT=10 5775 ==> (1997 9:00 AM EDT) September 2,9,16,23,30;October 7,14,21 5776 (1997 9:00 AM EST) October 28;November 4 5778 Weekly until December 24, 1997 5779 DTSTART;TZID=America/New_York:19970902T090000 5780 RRULE:FREQ=WEEKLY;UNTIL=19971224T000000Z 5782 ==> (1997 9:00 AM EDT) September 2,9,16,23,30; 5783 October 7,14,21 5784 (1997 9:00 AM EST) October 28; 5785 November 4,11,18,25; 5786 December 2,9,16,23 5788 Every other week - forever: 5790 DTSTART;TZID=America/New_York:19970902T090000 5791 RRULE:FREQ=WEEKLY;INTERVAL=2;WKST=SU 5793 ==> (1997 9:00 AM EDT) September 2,16,30; 5794 October 14 5795 (1997 9:00 AM EST) October 28; 5796 November 11,25; 5797 December 9,23 5798 (1998 9:00 AM EST) January 6,20; 5799 February 3, 17 5800 ... 5802 Weekly on Tuesday and Thursday for 5 weeks: 5804 DTSTART;TZID=America/New_York:19970902T090000 5805 RRULE:FREQ=WEEKLY;UNTIL=19971007T000000Z;WKST=SU;BYDAY=TU,TH 5807 or 5809 RRULE:FREQ=WEEKLY;COUNT=10;WKST=SU;BYDAY=TU,TH 5811 ==> (1997 9:00 AM EDT) September 2,4,9,11,16,18,23,25,30; 5812 October 2 5814 Every other week on Monday, Wednesday and Friday until December 5815 24, 1997, starting on Monday, September 1, 1997: 5817 DTSTART;TZID=America/New_York:19970901T090000 5818 RRULE:FREQ=WEEKLY;INTERVAL=2;UNTIL=19971224T000000Z;WKST=SU; 5819 BYDAY=MO,WE,FR 5821 ==> (1997 9:00 AM EDT) September 1,3,5,15,17,19,29; 5822 October 1,3,13,15,17 5823 (1997 9:00 AM EST) October 27,29,31; 5824 November 10,12,14,24,26,28; 5825 December 8,10,12,22 5827 Every other week on Tuesday and Thursday, for 8 occurrences: 5829 DTSTART;TZID=America/New_York:19970902T090000 5830 RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=8;WKST=SU;BYDAY=TU,TH 5832 ==> (1997 9:00 AM EDT) September 2,4,16,18,30; 5833 October 2,14,16 5835 Monthly on the 1st Friday for ten occurrences: 5837 DTSTART;TZID=America/New_York:19970905T090000 5838 RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR 5840 ==> (1997 9:00 AM EDT) September 5;October 3 5841 (1997 9:00 AM EST) November 7;December 5 5842 (1998 9:00 AM EST) January 2;February 6;March 6;April 3 5843 (1998 9:00 AM EDT) May 1;June 5 5845 Monthly on the 1st Friday until December 24, 1997: 5847 DTSTART;TZID=America/New_York:19970905T090000 5848 RRULE:FREQ=MONTHLY;UNTIL=19971224T000000Z;BYDAY=1FR 5850 ==> (1997 9:00 AM EDT) September 5; October 3 5851 (1997 9:00 AM EST) November 7; December 5 5853 Every other month on the 1st and last Sunday of the month for 10 5854 occurrences: 5856 DTSTART;TZID=America/New_York:19970907T090000 5857 RRULE:FREQ=MONTHLY;INTERVAL=2;COUNT=10;BYDAY=1SU,-1SU 5859 ==> (1997 9:00 AM EDT) September 7,28 5860 (1997 9:00 AM EST) November 2,30 5861 (1998 9:00 AM EST) January 4,25;March 1,29 5862 (1998 9:00 AM EDT) May 3,31 5864 Monthly on the second to last Monday of the month for 6 months: 5866 DTSTART;TZID=America/New_York:19970922T090000 5867 RRULE:FREQ=MONTHLY;COUNT=6;BYDAY=-2MO 5869 ==> (1997 9:00 AM EDT) September 22;October 20 5870 (1997 9:00 AM EST) November 17;December 22 5871 (1998 9:00 AM EST) January 19;February 16 5873 Monthly on the third to the last day of the month, forever: 5875 DTSTART;TZID=America/New_York:19970928T090000 5876 RRULE:FREQ=MONTHLY;BYMONTHDAY=-3 5878 ==> (1997 9:00 AM EDT) September 28 5879 (1997 9:00 AM EST) October 29;November 28;December 29 5880 (1998 9:00 AM EST) January 29;February 26 5881 ... 5883 Monthly on the 2nd and 15th of the month for 10 occurrences: 5885 DTSTART;TZID=America/New_York:19970902T090000 5886 RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=2,15 5888 ==> (1997 9:00 AM EDT) September 2,15;October 2,15 5889 (1997 9:00 AM EST) November 2,15;December 2,15 5890 (1998 9:00 AM EST) January 2,15 5892 Monthly on the first and last day of the month for 10 occurrences: 5894 DTSTART;TZID=America/New_York:19970930T090000 5895 RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=1,-1 5897 ==> (1997 9:00 AM EDT) September 30;October 1 5898 (1997 9:00 AM EST) October 31;November 1,30;December 1,31 5899 (1998 9:00 AM EST) January 1,31;February 1 5901 Every 18 months on the 10th thru 15th of the month for 10 5902 occurrences: 5904 DTSTART;TZID=America/New_York:19970910T090000 5905 RRULE:FREQ=MONTHLY;INTERVAL=18;COUNT=10;BYMONTHDAY=10,11,12, 5906 13,14,15 5908 ==> (1997 9:00 AM EDT) September 10,11,12,13,14,15 5909 (1999 9:00 AM EST) March 10,11,12,13 5911 Every Tuesday, every other month: 5913 DTSTART;TZID=America/New_York:19970902T090000 5914 RRULE:FREQ=MONTHLY;INTERVAL=2;BYDAY=TU 5916 ==> (1997 9:00 AM EDT) September 2,9,16,23,30 5917 (1997 9:00 AM EST) November 4,11,18,25 5918 (1998 9:00 AM EST) January 6,13,20,27;March 3,10,17,24,31 5919 ... 5921 Yearly in June and July for 10 occurrences: 5923 DTSTART;TZID=America/New_York:19970610T090000 5924 RRULE:FREQ=YEARLY;COUNT=10;BYMONTH=6,7 5926 ==> (1997 9:00 AM EDT) June 10;July 10 5927 (1998 9:00 AM EDT) June 10;July 10 5928 (1999 9:00 AM EDT) June 10;July 10 5929 (2000 9:00 AM EDT) June 10;July 10 5930 (2001 9:00 AM EDT) June 10;July 10 5932 Note: Since none of the BYDAY, BYMONTHDAY or BYYEARDAY 5933 components are specified, the day is gotten from "DTSTART" 5935 Every other year on January, February, and March for 10 5936 occurrences: 5938 DTSTART;TZID=America/New_York:19970310T090000 5939 RRULE:FREQ=YEARLY;INTERVAL=2;COUNT=10;BYMONTH=1,2,3 5941 ==> (1997 9:00 AM EST) March 10 5942 (1999 9:00 AM EST) January 10;February 10;March 10 5943 (2001 9:00 AM EST) January 10;February 10;March 10 5944 (2003 9:00 AM EST) January 10;February 10;March 10 5946 Every 3rd year on the 1st, 100th and 200th day for 10 occurrences: 5948 DTSTART;TZID=America/New_York:19970101T090000 5949 RRULE:FREQ=YEARLY;INTERVAL=3;COUNT=10;BYYEARDAY=1,100,200 5951 ==> (1997 9:00 AM EST) January 1 5952 (1997 9:00 AM EDT) April 10;July 19 5953 (2000 9:00 AM EST) January 1 5954 (2000 9:00 AM EDT) April 9;July 18 5955 (2003 9:00 AM EST) January 1 5956 (2003 9:00 AM EDT) April 10;July 19 5957 (2006 9:00 AM EST) January 1 5959 Every 20th Monday of the year, forever: 5961 DTSTART;TZID=America/New_York:19970519T090000 5962 RRULE:FREQ=YEARLY;BYDAY=20MO 5964 ==> (1997 9:00 AM EDT) May 19 5965 (1998 9:00 AM EDT) May 18 5966 (1999 9:00 AM EDT) May 17 5967 ... 5969 Monday of week number 20 (where the default start of the week is 5970 Monday), forever: 5972 DTSTART;TZID=America/New_York:19970512T090000 5973 RRULE:FREQ=YEARLY;BYWEEKNO=20;BYDAY=MO 5975 ==> (1997 9:00 AM EDT) May 12 5976 (1998 9:00 AM EDT) May 11 5977 (1999 9:00 AM EDT) May 17 5978 ... 5980 Every Thursday in March, forever: 5982 DTSTART;TZID=America/New_York:19970313T090000 5983 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=TH 5985 ==> (1997 9:00 AM EST) March 13,20,27 5986 (1998 9:00 AM EST) March 5,12,19,26 5987 (1999 9:00 AM EST) March 4,11,18,25 5988 ... 5990 Every Thursday, but only during June, July, and August, forever: 5992 DTSTART;TZID=America/New_York:19970605T090000 5993 RRULE:FREQ=YEARLY;BYDAY=TH;BYMONTH=6,7,8 5995 ==> (1997 9:00 AM EDT) June 5,12,19,26;July 3,10,17,24,31; 5996 August 7,14,21,28 5997 (1998 9:00 AM EDT) June 4,11,18,25;July 2,9,16,23,30; 5998 August 6,13,20,27 5999 (1999 9:00 AM EDT) June 3,10,17,24;July 1,8,15,22,29; 6000 August 5,12,19,26 6001 ... 6003 Every Friday the 13th, forever: 6005 DTSTART;TZID=America/New_York:19970902T090000 6006 EXDATE;TZID=America/New_York:19970902T090000 6007 RRULE:FREQ=MONTHLY;BYDAY=FR;BYMONTHDAY=13 6009 ==> (1998 9:00 AM EST) February 13;March 13;November 13 6010 (1999 9:00 AM EDT) August 13 6011 (2000 9:00 AM EDT) October 13 6012 ... 6014 The first Saturday that follows the first Sunday of the month, 6015 forever: 6017 DTSTART;TZID=America/New_York:19970913T090000 6018 RRULE:FREQ=MONTHLY;BYDAY=SA;BYMONTHDAY=7,8,9,10,11,12,13 6020 ==> (1997 9:00 AM EDT) September 13;October 11 6021 (1997 9:00 AM EST) November 8;December 13 6022 (1998 9:00 AM EST) January 10;February 7;March 7 6023 (1998 9:00 AM EDT) April 11;May 9;June 13... 6024 ... 6026 Every four years, the first Tuesday after a Monday in November, 6027 forever (U.S. Presidential Election day): 6029 DTSTART;TZID=America/New_York:19961105T090000 6030 RRULE:FREQ=YEARLY;INTERVAL=4;BYMONTH=11;BYDAY=TU; 6031 BYMONTHDAY=2,3,4,5,6,7,8 6033 ==> (1996 9:00 AM EST) November 5 6034 (2000 9:00 AM EST) November 7 6035 (2004 9:00 AM EST) November 2 6036 ... 6038 The 3rd instance into the month of one of Tuesday, Wednesday or 6039 Thursday, for the next 3 months: 6041 DTSTART;TZID=America/New_York:19970904T090000 6042 RRULE:FREQ=MONTHLY;COUNT=3;BYDAY=TU,WE,TH;BYSETPOS=3 6044 ==> (1997 9:00 AM EDT) September 4;October 7 6045 (1997 9:00 AM EST) November 6 6047 The 2nd to last weekday of the month: 6049 DTSTART;TZID=America/New_York:19970929T090000 6050 RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-2 6052 ==> (1997 9:00 AM EDT) September 29 6053 (1997 9:00 AM EST) October 30;November 27;December 30 6054 (1998 9:00 AM EST) January 29;February 26;March 30 6055 ... 6057 Every 3 hours from 9:00 AM to 5:00 PM on a specific day: 6059 DTSTART;TZID=America/New_York:19970902T090000 6060 RRULE:FREQ=HOURLY;INTERVAL=3;UNTIL=19970902T170000Z 6061 ==> (September 2, 1997 EDT) 09:00,12:00,15:00 6063 Every 15 minutes for 6 occurrences: 6065 DTSTART;TZID=America/New_York:19970902T090000 6066 RRULE:FREQ=MINUTELY;INTERVAL=15;COUNT=6 6068 ==> (September 2, 1997 EDT) 09:00,09:15,09:30,09:45,10:00,10:15 6070 Every hour and a half for 4 occurrences: 6072 DTSTART;TZID=America/New_York:19970902T090000 6073 RRULE:FREQ=MINUTELY;INTERVAL=90;COUNT=4 6075 ==> (September 2, 1997 EDT) 09:00,10:30;12:00;13:30 6077 Every 20 minutes from 9:00 AM to 4:40 PM every day: 6079 DTSTART;TZID=America/New_York:19970902T090000 6080 RRULE:FREQ=DAILY;BYHOUR=9,10,11,12,13,14,15,16;BYMINUTE=0,20,40 6081 or 6082 RRULE:FREQ=MINUTELY;INTERVAL=20;BYHOUR=9,10,11,12,13,14,15,16 6084 ==> (September 2, 1997 EDT) 9:00,9:20,9:40,10:00,10:20, 6085 ... 16:00,16:20,16:40 6086 (September 3, 1997 EDT) 9:00,9:20,9:40,10:00,10:20, 6087 ...16:00,16:20,16:40 6088 ... 6090 An example where the days generated makes a difference because of 6091 WKST: 6093 DTSTART;TZID=America/New_York:19970805T090000 6094 RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=4;BYDAY=TU,SU;WKST=MO 6096 ==> (1997 EDT) August 5,10,19,24 6098 changing only WKST from MO to SU, yields different results... 6100 DTSTART;TZID=America/New_York:19970805T090000 6101 RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=4;BYDAY=TU,SU;WKST=SU 6103 ==> (1997 EDT) August 5,17,19,31 6105 An example where an invalid date (i.e., February 30) is ignored. 6107 DTSTART;TZID=America/New_York:20070115T090000 6108 RRULE:FREQ=MONTHLY;BYMONTHDAY=15,30;COUNT=5 6110 ==> (2007 EST) January 15,30 6111 (2007 EST) February 15 6112 (2007 EDT) March 15,30 6114 3.8.6. Alarm Component Properties 6116 The following properties specify alarm information in calendar 6117 components. 6119 3.8.6.1. Action 6121 Property Name: ACTION 6123 Purpose: This property defines the action to be invoked when an 6124 alarm is triggered. 6126 Value Type: TEXT 6128 Property Parameters: IANA and non-standard property parameters can 6129 be specified on this property. 6131 Conformance: This property MUST be specified once in a "VALARM" 6132 calendar component. 6134 Description: Each "VALARM" calendar component has a particular type 6135 of action associated with it. This property specifies the type of 6136 action. Applications MUST ignore alarms with x-name and iana- 6137 token value they don't recognize. 6139 Format Definition: This property is defined by the following 6140 notation: 6142 action = "ACTION" actionparam ":" actionvalue CRLF 6144 actionparam = *(";" other-param) 6146 actionvalue = "AUDIO" / "DISPLAY" / "EMAIL" 6147 / iana-token / x-name 6149 Example: The following are examples of this property in a "VALARM" 6150 calendar component: 6152 ACTION:AUDIO 6154 ACTION:DISPLAY 6156 3.8.6.2. Repeat Count 6158 Property Name: REPEAT 6160 Purpose: This property defines the number of times the alarm should 6161 be repeated, after the initial trigger. 6163 Value Type: INTEGER 6165 Property Parameters: IANA and non-standard property parameters can 6166 be specified on this property. 6168 Conformance: This property can be specified in a "VALARM" calendar 6169 component. 6171 Description: This property defines the number of time an alarm 6172 should be repeated after its initial trigger. If the alarm 6173 triggers more than once, then this property MUST be specified 6174 along with the "DURATION" property. 6176 Format Definition: This property is defined by the following 6177 notation: 6179 repeat = "REPEAT" repparam ":" integer CRLF 6180 ;Default is "0", zero. 6182 repparam = *(";" other-param) 6184 Example: The following is an example of this property for an alarm 6185 that repeats 4 additional times with a 5 minute delay after the 6186 initial triggering of the alarm: 6188 REPEAT:4 6189 DURATION:PT5M 6191 3.8.6.3. Trigger 6192 Property Name: TRIGGER 6194 Purpose: This property specifies when an alarm will trigger. 6196 Value Type: The default value type is DURATION. The value type can 6197 be set to a DATE-TIME value type, in which case the value MUST 6198 specify a UTC formatted DATE-TIME value. 6200 Property Parameters: IANA, non-standard, value data type, time zone 6201 identifier or trigger relationship property parameters can be 6202 specified on this property. The trigger relationship property 6203 parameter MUST only be specified when the value type is 6204 "DURATION". 6206 Conformance: This property MUST be specified in the "VALARM" 6207 calendar component. 6209 Description: This property defines when an alarm will trigger. The 6210 default value type is DURATION, specifying a relative time for the 6211 trigger of the alarm. The default duration is relative to the 6212 start of an event or to-do that the alarm is associated with. The 6213 duration can be explicitly set to trigger from either the end or 6214 the start of the associated event or to-do with the "RELATED" 6215 parameter. A value of START will set the alarm to trigger off the 6216 start of the associated event or to-do. A value of END will set 6217 the alarm to trigger off the end of the associated event or to-do. 6219 Either a positive or negative duration may be specified for the 6220 "TRIGGER" property. An alarm with a positive duration is 6221 triggered after the associated start or end of the event or to-do. 6222 An alarm with a negative duration is triggered before the 6223 associated start or end of the event or to-do. 6225 The "RELATED" property parameter is not valid if the value type of 6226 the property is set to DATE-TIME (i.e., for an absolute date and 6227 time alarm trigger). If a value type of DATE-TIME is specified, 6228 then the property value MUST be specified in the UTC time format. 6229 If an absolute trigger is specified on an alarm for a recurring 6230 event or to-do, then the alarm will only trigger for the specified 6231 absolute date/time, along with any specified repeating instances. 6233 If the trigger is set relative to START, then the "DTSTART" 6234 property MUST be present in the associated "VEVENT" or "VTODO" 6235 calendar component. If an alarm is specified for an event with 6236 the trigger set relative to the END, then the "DTEND" property or 6237 the "DTSTART" and "DURATION " properties MUST be present in the 6238 associated "VEVENT" calendar component. If the alarm is specified 6239 for a to-do with a trigger set relative to the END, then either 6240 the "DUE" property or the "DTSTART" and "DURATION " properties 6241 MUST be present in the associated "VTODO" calendar component. 6243 Alarms specified in an event or to-do which is defined in terms of 6244 a DATE value type will be triggered relative to 00:00:00 of the 6245 user's configured time zone on the specified date, or relative to 6246 00:00:00 UTC on the specified date if no configured time zone can 6247 be found for the user. For example, if "DTSTART" is a DATE value 6248 set to 19980205 then the duration trigger will be relative to 6249 19980205T000000 America/New_York for a user configured with the 6250 America/New_York time zone. 6252 Format Definition: This property is defined by the following 6253 notation: 6255 trigger = "TRIGGER" (trigrel / trigabs) CRLF 6257 trigrel = *( 6258 ; 6259 ; the following are OPTIONAL, 6260 ; but MUST NOT occur more than once 6261 ; 6262 (";" "VALUE" "=" "DURATION") / 6263 (";" trigrelparam) / 6264 ; 6265 ; the following is OPTIONAL, 6266 ; and MAY occur more than once 6267 ; 6268 (";" other-param) 6269 ; 6270 ) ":" dur-value 6272 trigabs = *( 6273 ; 6274 ; the following is REQUIRED, 6275 ; but MUST NOT occur more than once 6276 ; 6277 (";" "VALUE" "=" "DATE-TIME") / 6278 ; 6279 ; the following is OPTIONAL, 6280 ; and MAY occur more than once 6281 ; 6282 (";" other-param) 6283 ; 6284 ) ":" date-time 6286 Example: A trigger set 15 minutes prior to the start of the event or 6287 to-do. 6289 TRIGGER:-PT15M 6291 A trigger set 5 minutes after the end of an event or the due date 6292 of a to-do. 6294 TRIGGER;RELATED=END:PT5M 6296 A trigger set to an absolute date/time. 6298 TRIGGER;VALUE=DATE-TIME:19980101T050000Z 6300 3.8.7. Change Management Component Properties 6302 The following properties specify change management information in 6303 calendar components. 6305 3.8.7.1. Date/Time Created 6307 Property Name: CREATED 6309 Purpose: This property specifies the date and time that the calendar 6310 information was created by the calendar user agent in the calendar 6311 store. 6313 Note: This is analogous to the creation date and time for a 6314 file in the file system. 6316 Value Type: DATE-TIME 6318 Property Parameters: IANA and non-standard property parameters can 6319 be specified on this property. 6321 Conformance: The property can be specified once in "VEVENT", "VTODO" 6322 or "VJOURNAL" calendar components. The value MUST be specified as 6323 a date with UTC time. 6325 Description: This property specifies the date and time that the 6326 calendar information was created by the calendar user agent in the 6327 calendar store. 6329 Format Definition: This property is defined by the following 6330 notation: 6332 created = "CREATED" creaparam ":" date-time CRLF 6333 creaparam = *(";" other-param) 6335 Example: The following is an example of this property: 6337 CREATED:19960329T133000Z 6339 3.8.7.2. Date/Time Stamp 6341 Property Name: DTSTAMP 6343 Purpose: In the case of an iCalendar object that specifies a 6344 "METHOD" property, this property specifies the date and time that 6345 the instance of the iCalendar object was created. In the case of 6346 an iCalendar object that doesn't specify a "METHOD" property, this 6347 property specifies the date and time that the information 6348 associated with the calendar component was last revised in the 6349 calendar store. 6351 Value Type: DATE-TIME 6353 Property Parameters: IANA and non-standard property parameters can 6354 be specified on this property. 6356 Conformance: This property MUST be included in the "VEVENT", 6357 "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components. 6359 Description: The value MUST be specified in the UTC time format. 6361 This property is also useful to protocols such as 6362 [I-D.ietf-calsify-rfc2447bis] that have inherent latency issues 6363 with the delivery of content. This property will assist in the 6364 proper sequencing of messages containing iCalendar objects. 6366 In the case of an iCalendar object that specifies a "METHOD" 6367 property, this property differs from the "CREATED" and "LAST- 6368 MODIFIED" properties. These two properties are used to specify 6369 when the particular calendar data in the calendar store was 6370 created and last modified. This is different than when the 6371 iCalendar object representation of the calendar service 6372 information was created or last modified. 6374 In the case of an iCalendar object that doesn't specify a "METHOD" 6375 property, this property is equivalent to the "LAST-MODIFIED" 6376 property. 6378 Format Definition: This property is defined by the following 6379 notation: 6381 dtstamp = "DTSTAMP" stmparam ":" date-time CRLF 6383 stmparam = *(";" other-param) 6385 Example: 6387 DTSTAMP:19971210T080000Z 6389 3.8.7.3. Last Modified 6391 Property Name: LAST-MODIFIED 6393 Purpose: This property specifies the date and time that the 6394 information associated with the calendar component was last 6395 revised in the calendar store. 6397 Note: This is analogous to the modification date and time for a 6398 file in the file system. 6400 Value Type: DATE-TIME 6402 Property Parameters: IANA and non-standard property parameters can 6403 be specified on this property. 6405 Conformance: This property can be specified in the "VEVENT", 6406 "VTODO", "VJOURNAL" or "VTIMEZONE" calendar components. 6408 Description: The property value MUST be specified in the UTC time 6409 format. 6411 Format Definition: This property is defined by the following 6412 notation: 6414 last-mod = "LAST-MODIFIED" lstparam ":" date-time CRLF 6416 lstparam = *(";" other-param) 6418 Example: The following is an example of this property: 6420 LAST-MODIFIED:19960817T133000Z 6422 3.8.7.4. Sequence Number 6424 Property Name: SEQUENCE 6426 Purpose: This property defines the revision sequence number of the 6427 calendar component within a sequence of revisions. 6429 Value Type: INTEGER 6431 Property Parameters: IANA and non-standard property parameters can 6432 be specified on this property. 6434 Conformance: The property can be specified in "VEVENT", "VTODO" or 6435 "VJOURNAL" calendar component. 6437 Description: When a calendar component is created, its sequence 6438 number is zero (US-ASCII decimal 48). It is monotonically 6439 incremented by the "Organizer's" CUA each time the "Organizer" 6440 makes a significant revision to the calendar component. 6442 The "Organizer" includes this property in an iCalendar object that 6443 it sends to an "Attendee" to specify the current version of the 6444 calendar component. 6446 The "Attendee" includes this property in an iCalendar object that 6447 it sends to the "Organizer" to specify the version of the calendar 6448 component that the "Attendee" is referring to. 6450 A change to the sequence number is not the mechanism that an 6451 "Organizer" uses to request a response from the "Attendees". The 6452 "RSVP" parameter on the "ATTENDEE" property is used by the 6453 "Organizer" to indicate that a response from the "Attendees" is 6454 requested. 6456 Recurrence instances of a recurring component MAY have different 6457 sequence numbers. 6459 Format Definition: This property is defined by the following 6460 notation: 6462 seq = "SEQUENCE" seqparam ":" integer CRLF 6463 ; Default is "0" 6465 seqparam = *(";" other-param) 6467 Example: The following is an example of this property for a calendar 6468 component that was just created by the "Organizer": 6470 SEQUENCE:0 6472 The following is an example of this property for a calendar 6473 component that has been revised two different times by the 6474 "Organizer": 6476 SEQUENCE:2 6478 3.8.8. Miscellaneous Component Properties 6480 The following properties specify information about a number of 6481 miscellaneous features of calendar components. 6483 3.8.8.1. IANA Properties 6485 Property Name: An IANA registered property name 6487 Value Type: The default value type is TEXT. The value type can be 6488 set to any value type. 6490 Property Parameters: Any parameter can be specified on this 6491 property. 6493 Description: This specification allows other properties registered 6494 with IANA to be specified in any calendar components. Compliant 6495 applications are expected to be able to parse these other IANA 6496 registered properties but can ignore them. 6498 Format Definition: This property is defined by the following 6499 notation: 6501 iana-prop = iana-token *(";" icalparameter) ":" value CRLF 6503 Example: The following are examples of properties that might be 6504 registered to IANA: 6506 DRESSCODE:CASUAL 6508 NON-SMOKING;VALUE=BOOLEAN:TRUE 6510 3.8.8.2. Non-standard Properties 6511 Property Name: Any property name with a "X-" prefix 6513 Purpose: This class of property provides a framework for defining 6514 non-standard properties. 6516 Value Type: The default value type is TEXT. The value type can be 6517 set to any value type. 6519 Property Parameters: IANA, non-standard and language property 6520 parameters can be specified on this property. 6522 Conformance: This property can be specified in any calendar 6523 component. 6525 Description: The MIME Calendaring and Scheduling Content Type 6526 provides a "standard mechanism for doing non-standard things". 6527 This extension support is provided for implementers to "push the 6528 envelope" on the existing version of the memo. Extension 6529 properties are specified by property and/or property parameter 6530 names that have the prefix text of "X-" (the two character 6531 sequence: LATIN CAPITAL LETTER X character followed by the HYPHEN- 6532 MINUS character). It is recommended that vendors concatenate onto 6533 this sentinel another short prefix text to identify the vendor. 6534 This will facilitate readability of the extensions and minimize 6535 possible collision of names between different vendors. User 6536 agents that support this content type are expected to be able to 6537 parse the extension properties and property parameters but can 6538 ignore them. 6540 At present, there is no registration authority for names of 6541 extension properties and property parameters. The value type for 6542 this property is TEXT. Optionally, the value type can be any of 6543 the other valid value types. 6545 Format Definition: This property is defined by the following 6546 notation: 6548 x-prop = x-name *(";" icalparameter) ":" value CRLF 6550 Example: The following might be the ABC vendor's extension for an 6551 audio-clip form of subject property: 6553 X-ABC-MMSUBJ;VALUE=URI;FMTTYPE=audio/basic:http://www.example. 6554 org/mysubj.au 6556 3.8.8.3. Request Status 6558 Property Name: REQUEST-STATUS 6560 Purpose: This property defines the status code returned for a 6561 scheduling request. 6563 Value Type: TEXT 6565 Property Parameters: IANA, non-standard and language property 6566 parameters can be specified on this property. 6568 Conformance: The property can be specified in "VEVENT", "VTODO", 6569 "VJOURNAL" or "VFREEBUSY" calendar component. 6571 Description: This property is used to return status code information 6572 related to the processing of an associated iCalendar object. The 6573 value type for this property is TEXT. 6575 The value consists of a short return status component, a longer 6576 return status description component, and optionally a status- 6577 specific data component. The components of the value are 6578 separated by the SEMICOLON character (US-ASCII decimal 59). 6580 The short return status is a PERIOD character (US-ASCII decimal 6581 46) separated pair or 3-tuple of integers. For example, "3.1" or 6582 "3.1.1". The successive levels of integers provide for a 6583 successive level of status code granularity. 6585 The following are initial classes for the return status code. 6586 Individual iCalendar object methods will define specific return 6587 status codes for these classes. In addition, other classes for 6588 the return status code may be defined using the registration 6589 process defined later in this memo. 6591 +--------+----------------------------------------------------------+ 6592 | Short | Longer Return Status Description | 6593 | Return | | 6594 | Status | | 6595 | Code | | 6596 +--------+----------------------------------------------------------+ 6597 | 1.xx | Preliminary success. This class of status code | 6598 | | indicates that the request has been initially processed | 6599 | | but that completion is pending. | 6600 | | | 6601 | 2.xx | Successful. This class of status code indicates that | 6602 | | the request was completed successfuly. However, the | 6603 | | exact status code can indicate that a fallback has been | 6604 | | taken. | 6605 | | | 6606 | 3.xx | Client Error. This class of status code indicates that | 6607 | | the request was not successful. The error is the result | 6608 | | of either a syntax or a semantic error in the client | 6609 | | formatted request. Request should not be retried until | 6610 | | the condition in the request is corrected. | 6611 | | | 6612 | 4.xx | Scheduling Error. This class of status code indicates | 6613 | | that the request was not successful. Some sort of error | 6614 | | occurred within the calendaring and scheduling service, | 6615 | | not directly related to the request itself. | 6616 +--------+----------------------------------------------------------+ 6618 Format Definition: This property is defined by the following 6619 notation: 6621 rstatus = "REQUEST-STATUS" rstatparam ":" 6622 statcode ";" statdesc [";" extdata] 6624 rstatparam = *( 6625 ; 6626 ; the following is OPTIONAL, 6627 ; but MUST NOT occur more than once 6628 ; 6629 (";" languageparam) / 6630 ; 6631 ; the following is OPTIONAL, 6632 ; and MAY occur more than once 6633 ; 6634 (";" other-param) 6635 ; 6636 ) 6638 statcode = 1*DIGIT 1*2("." 1*DIGIT) 6639 ;Hierarchical, numeric return status code 6641 statdesc = text 6642 ;Textual status description 6644 extdata = text 6645 ;Textual exception data. For example, the offending property 6646 ;name and value or complete property line. 6648 Example: The following are some possible examples of this property. 6650 The COMMA and SEMICOLON separator characters in the property value 6651 are BACKSLASH character escaped because they appear in a text 6652 value. 6654 REQUEST-STATUS:2.0;Success 6656 REQUEST-STATUS:3.1;Invalid property value;DTSTART:96-Apr-01 6658 REQUEST-STATUS:2.8; Success\, repeating event ignored. Scheduled 6659 as a single event.;RRULE:FREQ=WEEKLY\;INTERVAL=2 6661 REQUEST-STATUS:4.1;Event conflict. Date/time is busy. 6663 REQUEST-STATUS:3.7;Invalid calendar user;ATTENDEE: 6664 mailto:jsmith@example.com 6666 4. iCalendar Object Examples 6668 The following examples are provided as an informational source of 6669 illustrative iCalendar objects consistent with this content type. 6671 The following example specifies a three-day conference that begins at 6672 2:30 P.M. UTC, September 18, 1996 and end at 10:00 P.M. UTC, 6673 September 20, 1996. 6675 BEGIN:VCALENDAR 6676 PRODID:-//xyz Corp//NONSGML PDA Calendar Version 1.0//EN 6677 VERSION:2.0 6678 BEGIN:VEVENT 6679 DTSTAMP:19960704T120000Z 6680 UID:uid1@example.com 6681 ORGANIZER:mailto:jsmith@example.com 6682 DTSTART:19960918T143000Z 6683 DTEND:19960920T220000Z 6684 STATUS:CONFIRMED 6685 CATEGORIES:CONFERENCE 6686 SUMMARY:Networld+Interop Conference 6687 DESCRIPTION:Networld+Interop Conference 6688 and Exhibit\nAtlanta World Congress Center\n 6689 Atlanta\, Georgia 6690 END:VEVENT 6691 END:VCALENDAR 6693 The following example specifies a group scheduled meeting that begin 6694 at 8:30 AM EST on March 12, 1998 and end at 9:30 AM EST on March 12, 6695 1998. The "Organizer" has scheduled the meeting with one or more 6696 calendar users in a group. A time zone specification for Eastern 6697 United States has been specified. 6699 BEGIN:VCALENDAR 6700 PRODID:-//RDU Software//NONSGML HandCal//EN 6701 VERSION:2.0 6702 BEGIN:VTIMEZONE 6703 TZID:America/New_York 6704 BEGIN:STANDARD 6705 DTSTART:19981025T020000 6706 TZOFFSETFROM:-0400 6707 TZOFFSETTO:-0500 6708 TZNAME:EST 6709 END:STANDARD 6710 BEGIN:DAYLIGHT 6711 DTSTART:19990404T020000 6712 TZOFFSETFROM:-0500 6713 TZOFFSETTO:-0400 6714 TZNAME:EDT 6715 END:DAYLIGHT 6716 END:VTIMEZONE 6717 BEGIN:VEVENT 6718 DTSTAMP:19980309T231000Z 6719 UID:guid-1.example.com 6720 ORGANIZER:mailto:mrbig@example.com 6721 ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;CUTYPE=GROUP: 6722 mailto:employee-A@example.com 6723 DESCRIPTION:Project XYZ Review Meeting 6724 CATEGORIES:MEETING 6725 CLASS:PUBLIC 6726 CREATED:19980309T130000Z 6727 SUMMARY:XYZ Project Review 6728 DTSTART;TZID=America/New_York:19980312T083000 6729 DTEND;TZID=America/New_York:19980312T093000 6730 LOCATION:1CP Conference Room 4350 6731 END:VEVENT 6732 END:VCALENDAR 6734 The following is an example of an iCalendar object passed in a MIME 6735 message with a single body part consisting of a "text/calendar" 6736 Content Type. 6738 TO:jsmith@example.com 6739 FROM:jdoe@example.com 6740 MIME-VERSION:1.0 6741 MESSAGE-ID: 6742 CONTENT-TYPE:text/calendar; method="xyz"; component="VEVENT" 6744 BEGIN:VCALENDAR 6745 METHOD:xyz 6746 VERSION:2.0 6747 PRODID:-//ABC Corporation//NONSGML My Product//EN 6748 BEGIN:VEVENT 6749 DTSTAMP:19970324T120000Z 6750 SEQUENCE:0 6751 UID:uid3@example.com 6752 ORGANIZER:mailto:jdoe@example.com 6753 ATTENDEE;RSVP=TRUE:mailto:jsmith@example.com 6754 DTSTART:19970324T123000Z 6755 DTEND:19970324T210000Z 6756 CATEGORIES:MEETING,PROJECT 6757 CLASS:PUBLIC 6758 SUMMARY:Calendaring Interoperability Planning Meeting 6759 DESCRIPTION:Discuss how we can test c&s interoperability\n 6760 using iCalendar and other IETF standards. 6761 LOCATION:LDB Lobby 6762 ATTACH;FMTTYPE=application/postscript:ftp://example.com/pub/ 6763 conf/bkgrnd.ps 6764 END:VEVENT 6765 END:VCALENDAR 6767 The following is an example of a to-do due on April 15, 1998. An 6768 audio alarm has been specified to remind the calendar user at noon, 6769 the day before the to-do is expected to be completed and repeat 6770 hourly, four additional times. The to-do definition has been 6771 modified twice since it was initially created. 6773 BEGIN:VCALENDAR 6774 VERSION:2.0 6775 PRODID:-//ABC Corporation//NONSGML My Product//EN 6776 BEGIN:VTODO 6777 DTSTAMP:19980130T134500Z 6778 SEQUENCE:2 6779 UID:uid4@example.com 6780 ORGANIZER:mailto:unclesam@example.com 6781 ATTENDEE;PARTSTAT=ACCEPTED:mailto:jqpublic@example.com 6782 DUE:19980415T000000 6783 STATUS:NEEDS-ACTION 6784 SUMMARY:Submit Income Taxes 6785 BEGIN:VALARM 6786 ACTION:AUDIO 6787 TRIGGER:19980403T120000Z 6788 ATTACH;FMTTYPE=audio/basic:http://example.com/pub/audio- 6789 files/ssbanner.aud 6790 REPEAT:4 6791 DURATION:PT1H 6792 END:VALARM 6793 END:VTODO 6794 END:VCALENDAR 6796 The following is an example of a journal entry. 6798 BEGIN:VCALENDAR 6799 VERSION:2.0 6800 PRODID:-//ABC Corporation//NONSGML My Product//EN 6801 BEGIN:VJOURNAL 6802 DTSTAMP:19970324T120000Z 6803 UID:uid5@example.com 6804 ORGANIZER:mailto:jsmith@example.com 6805 STATUS:DRAFT 6806 CLASS:PUBLIC 6807 CATEGORIES:Project Report,XYZ,Weekly Meeting 6808 DESCRIPTION:Project xyz Review Meeting Minutes\n 6809 Agenda\n1. Review of project version 1.0 requirements.\n2. 6810 Definition 6811 of project processes.\n3. Review of project schedule.\n 6812 Participants: John Smith\, Jane Doe\, Jim Dandy\n-It was 6813 decided that the requirements need to be signed off by 6814 product marketing.\n-Project processes were accepted.\n 6815 -Project schedule needs to account for scheduled holidays 6816 and employee vacation time. Check with HR for specific 6817 dates.\n-New schedule will be distributed by Friday.\n- 6818 Next weeks meeting is cancelled. No meeting until 3/23. 6819 END:VJOURNAL 6820 END:VCALENDAR 6822 The following is an example of published busy time information. The 6823 iCalendar object might be placed in the network resource 6824 http://www.example.com/calendar/busytime/jsmith.ifb. 6826 BEGIN:VCALENDAR 6827 VERSION:2.0 6828 PRODID:-//RDU Software//NONSGML HandCal//EN 6829 BEGIN:VFREEBUSY 6830 ORGANIZER:mailto:jsmith@example.com 6831 DTSTART:19980313T141711Z 6832 DTEND:19980410T141711Z 6833 FREEBUSY:19980314T233000Z/19980315T003000Z 6834 FREEBUSY:19980316T153000Z/19980316T163000Z 6835 FREEBUSY:19980318T030000Z/19980318T040000Z 6836 URL:http://www.example.com/calendar/busytime/jsmith.ifb 6837 END:VFREEBUSY 6838 END:VCALENDAR 6840 5. Recommended Practices 6842 These recommended practices should be followed in order to assure 6843 consistent handling of the following cases for an iCalendar object. 6845 1. Content lines longer than 75 octets SHOULD be folded. 6847 2. When the combination of the "RRULE" and "RDATE" properties in a 6848 recurring component produces multiple instances having the same 6849 start DATE-TIME value, they should be collapsed to, and 6850 considered as, a single instance. If the "RDATE" property is 6851 specified as a PERIOD value the duration of the recurrence 6852 instance will be the one specified by the "RDATE" property, and 6853 not the duration of the recurrence instance defined by the 6854 "DTSTART" property. 6856 3. When a calendar user receives multiple requests for the same 6857 calendar component (e.g., REQUEST for a "VEVENT" calendar 6858 component) as a result of being on multiple mailing lists 6859 specified by "ATTENDEE" properties in the request, they SHOULD 6860 respond to only one of the requests. The calendar user SHOULD 6861 also specify (using the "MEMBER" parameter of the "ATTENDEE" 6862 property) which mailing list they are a member of. 6864 4. An implementation can truncate a "SUMMARY" property value to 255 6865 octets, but MUST NOT truncate the value in the middle of a UTF-8 6866 multi-octet sequence. 6868 5. If seconds of the minute are not supported by an implementation, 6869 then a value of "00" SHOULD be specified for the seconds 6870 component in a time value. 6872 6. "TZURL" values SHOULD NOT be specified as a file URI type. This 6873 URI form can be useful within an organization, but is problematic 6874 in the Internet. 6876 7. Some possible English values for "CATEGORIES" property include 6877 "ANNIVERSARY", "APPOINTMENT", "BUSINESS", "EDUCATION", "HOLIDAY", 6878 "MEETING", "MISCELLANEOUS", "NON-WORKING HOURS", "NOT IN OFFICE", 6879 "PERSONAL", "PHONE CALL", "SICK DAY", "SPECIAL OCCASION", 6880 "TRAVEL", "VACATION". Categories can be specified in any 6881 registered language. 6883 8. Some possible English values for "RESOURCES" property include 6884 "CATERING", "CHAIRS", "COMPUTER PROJECTOR", "EASEL", "OVERHEAD 6885 PROJECTOR", "SPEAKER PHONE", "TABLE", "TV", "VCR", "VIDEO PHONE", 6886 "VEHICLE". Resources can be specified in any registered 6887 language. 6889 6. Internationalization Considerations 6891 Applications MUST generate iCalendar stream in the UTF-8 charset and 6892 MUST accept iCalendar stream in the UTF-8 or US-ASCII charset. 6894 7. Security Considerations 6896 Because calendaring and scheduling information is very privacy- 6897 sensitive, the protocol used for the transmission of calendaring and 6898 scheduling information should have capabilities to protect the 6899 information from possible threats, such as eavesdropping, replay, 6900 message insertion, deletion, modification and man-in-the-middle 6901 attacks. 6903 As this document only defines the data format and media type of text/ 6904 calendar that is independent of any calendar service or protocol, it 6905 is up to the actual protocol specifications such as iTIP 6906 [I-D.ietf-calsify-2446bis], iMIP [I-D.ietf-calsify-rfc2447bis], and 6907 CalDAV [RFC4791] to describe the threats that the above attacks 6908 present, as well as ways in which to mitigate them. 6910 8. IANA Considerations 6912 8.1. iCalendar Media Type Registration 6914 The Calendaring and Scheduling Core Object Specification is intended 6915 for use as a MIME content type. 6917 To: ietf-types@iana.org 6918 Subject: Registration of media type text/calendar 6920 Type name: text 6922 Subtype name: calendar 6924 Required parameters: none 6926 Optional parameters: charset, method, component and optinfo 6928 The "charset" parameter is defined in [RFC2046] for subtypes of 6929 the "text" media type. It is used to indicate the charset used in 6930 the body part. The charset supported by this revision of 6931 iCalendar is UTF-8. The use of any other charset is deprecated by 6932 this revision of iCalendar; however note that this revision 6933 requires that compliant applications MUST accept iCalendar streams 6934 using either the UTF-8 or US-ASCII charset. 6936 The "method" parameter is used to convey the iCalendar object 6937 method or transaction semantics for the calendaring and scheduling 6938 information. It also is an identifier for the restricted set of 6939 properties and values that the iCalendar object consists of. The 6940 parameter is to be used as a guide for applications interpreting 6941 the information contained within the body part. It SHOULD NOT be 6942 used to exclude or require particular pieces of information unless 6943 the identified method definition specifically calls for this 6944 behavior. Unless specifically forbidden by a particular method 6945 definition, a text/calendar content type can contain any set of 6946 properties permitted by the Calendaring and Scheduling Core Object 6947 Specification. The "method" parameter MUST be specified and MUST 6948 be set to the same value as the "METHOD" component property of the 6949 iCalendar objects of the iCalendar stream if and only if the 6950 iCalendar objects in the iCalendar stream all have a "METHOD" 6951 component property set to the same value. 6953 The value for the "method" parameter is defined as follows: 6955 method = 1*(ALPHA / DIGIT / "-") 6956 ; IANA registered iCalendar object method 6958 The "component" parameter conveys the type of iCalendar calendar 6959 component within the body part. If the iCalendar object contains 6960 more than one calendar component type, then multiple component 6961 parameters MUST be specified. 6963 The value for the "component" parameter is defined as follows: 6965 component = "VEVENT" 6966 / "VTODO" 6967 / "VJOURNAL" 6968 / "VFREEBUSY" 6969 / "VTIMEZONE" 6970 / iana-token 6971 / x-name 6973 The "optinfo" parameter conveys optional information about the 6974 iCalendar object within the body part. This parameter can only 6975 specify semantics already specified by the iCalendar object and 6976 that can be otherwise determined by parsing the body part. In 6977 addition, the optional information specified by this parameter 6978 MUST be consistent with that information specified by the 6979 iCalendar object. For example, it can be used to convey the 6980 "Attendee" response status to a meeting request. The parameter 6981 value consists of a string value. 6983 The parameter can be specified multiple times. 6985 The value for the "optinfo" parameter is defined as follows: 6987 optinfo = infovalue / qinfovalue 6989 infovalue = iana-token / x-name 6991 qinfovalue = DQUOTE (infovalue) DQUOTE 6993 Encoding considerations: This media type can contain 8bit 6994 characters, so the use of quoted-printable or base64 MIME Content- 6995 Transfer-Encodings might be necessary when iCalendar objects are 6996 transferred across protocols restricted to the 7bit repertoire. 6997 Note that a text valued property in the content entity can also 6998 have content encoding of special characters using a BACKSLASH 6999 character (US-ASCII decimal 92) escapement technique. This means 7000 that content values can end up encoded twice. 7002 Security considerations: See Section 7. 7004 Interoperability considerations: This media type is intended to 7005 define a common format for conveying calendaring and scheduling 7006 information between different systems. It is heavily based on the 7007 earlier [VCAL] industry specification. 7009 Published specification: This specification. 7011 Applications which use this media type: This media type is designed 7012 for widespread use by Internet calendaring and scheduling 7013 applications. In addition, applications in the workflow and 7014 document management area might find this content-type applicable. 7015 The iTIP [I-D.ietf-calsify-2446bis], iMIP 7016 [I-D.ietf-calsify-rfc2447bis] and CalDAV [RFC4791] Internet 7017 protocols directly use this media type also. 7019 Additional information: 7021 Magic number(s): None. 7023 File extension(s): The file extension of "ics" is to be used to 7024 designate a file containing (an arbitrary set of) calendaring 7025 and scheduling information consistent with this MIME content 7026 type. 7028 The file extension of "ifb" is to be used to designate a file 7029 containing free or busy time information consistent with this 7030 MIME content type. 7032 Macintosh file type code(s): The file type code of "iCal" is to 7033 be used in Apple MacIntosh operating system environments to 7034 designate a file containing calendaring and scheduling 7035 information consistent with this MIME media type. 7037 The file type code of "iFBf" is to be used in Apple MacIntosh 7038 operating system environments to designate a file containing 7039 free or busy time information consistent with this MIME media 7040 type. 7042 Person & email address to contact for further information: See the 7043 "Author's Address" section of this document. 7045 Intended usage: COMMON 7047 Restrictions on usage: There are no restrictions on where this media 7048 type can be used. 7050 Author: See the "Author's Address" section of this document. 7052 Change controller: IETF 7054 8.2. New iCalendar Elements Registration 7056 This section defines the process to register new or modified 7057 iCalendar elements, that is, components, properties, parameters, 7058 value data types, and values, with IANA. 7060 8.2.1. iCalendar Elements Registration Procedure 7062 The IETF will create a mailing list, icalendar@ietf.org [2], which 7063 can be used for public discussion of iCalendar elements proposals 7064 prior to registration. Use of the mailing list is strongly 7065 encouraged. The IESG will appoint a designated expert who will 7066 monitor the icalendar@ietf.org [2] mailing list and review 7067 registrations. 7069 Registration of new iCalendar elements MUST be reviewed by the 7070 designated expert and published in an RFC. A Standard Tracks RFC is 7071 REQUIRED for the regisration of new value data types that modify 7072 existing properties, as well as for the registration of participation 7073 statuses values to be used in "VEVENT" calendar components. A 7074 Standard Tracks RFC is also REQUIRED for registration of iCalendar 7075 elements that modify iCalendar elements previously documented in a 7076 Standard Tracks RFC. 7078 The registration procedure begins when a completed registration 7079 template, defined in the sections below, is sent to 7080 icalendar@ietf.org [2] and iana@iana.org [3]. The designated expert 7081 is expected to tell IANA and the submitter of the registration within 7082 two weeks whether the registration is approved, approved with minor 7083 changes, or rejected with cause. When a registration is rejected 7084 with cause, it can be re-submitted if the concerns listed in the 7085 cause are addressed. Decisions made by the designated expert can be 7086 appealed to the IESG Applications Area Director, then to the IESG. 7087 They follow the normal appeals procedure for IESG decisions. 7089 8.2.2. Registration Template for Components 7091 A component is defined by completing the following template. 7093 Component name: The name of the component. 7095 Purpose: The purpose of the component. Give a short but clear 7096 description. 7098 Format definition: The ABNF for the component definition needs to 7099 be specified. 7101 Description: Any special notes about the component, how it is to 7102 be used, etc. 7104 Example(s): One or more examples of instances of the component 7105 needs to be specified. 7107 8.2.3. Registration Template for Properties 7109 A property is defined by completing the following template. 7111 Property name: The name of the property. 7113 Purpose: The purpose of the property. Give a short but clear 7114 description. 7116 Value type: Any of the valid value types for the property value 7117 needs to be specified. The default value type also needs to be 7118 specified. 7120 Property parameters: Any of the valid property parameters for the 7121 property MUST be specified. 7123 Conformance: The calendar components that the property can appear 7124 in MUST be specified. 7126 Description: Any special notes about the property, how it is to 7127 be used, etc. 7129 Format definition: The ABNF for the property definition needs to 7130 be specified. 7132 Example(s): One or more examples of instances of the property 7133 needs to be specified. 7135 8.2.4. Registration Template for Parameters 7137 A parameter is defined by completing the following template. 7139 Parameter name: The name of the parameter. 7141 Purpose: The purpose of the parameter. Give a short but clear 7142 description. 7144 Format definition: The ABNF for the parameter definition needs to 7145 be specified. 7147 Description: Any special notes about the parameter, how it is to 7148 be used, etc. 7150 Example(s): One or more examples of instances of the parameter 7151 needs to be specified. 7153 8.2.5. Registration Template for Value Data Types 7155 A value data type is defined by completing the following template. 7157 Value name: The name of the value type. 7159 Purpose: The purpose of the value type. Give a short but clear 7160 description. 7162 Format definition: The ABNF for the value type definition needs 7163 to be specified. 7165 Description: Any special notes about the value type, how it is to 7166 be used, etc. 7168 Example(s): One or more examples of instances of the value type 7169 needs to be specified. 7171 8.2.6. Registration Template for Values 7173 A value is defined by completing the following template. 7175 Value: The value literal. 7177 Purpose: The purpose of the value. Give a short but clear 7178 description. 7180 Conformance: The calendar properties and/or parameters that can 7181 take this value needs to be specified. 7183 Example(s): One or more examples of instances of the value needs 7184 to be specified. 7186 The following is a fictitious example of a registration of an 7187 iCalendar value: 7189 Value: TOP-SECRET 7191 Purpose: This value is used to specify the access classification 7192 of top-secret calendar components. 7194 Conformance: This value can be used with the "CLASS" property. 7196 Example(s): The following is an example of this value used with 7197 the "CLASS" property: 7199 CLASS:TOP-SECRET 7201 8.3. Initial iCalendar Elements Registries 7203 The IANA is requested to create and maintain the following registries 7204 for iCalendar elements with pointers to appropriate reference 7205 documents. 7207 8.3.1. Components Registry 7209 The following table is to be used to initialize the components 7210 registry. 7212 +-----------+---------+------------------------+ 7213 | Component | Status | Reference | 7214 +-----------+---------+------------------------+ 7215 | VCALENDAR | Current | RFCXXXX, Section 3.4 | 7216 | | | | 7217 | VEVENT | Current | RFCXXXX, Section 3.6.1 | 7218 | | | | 7219 | VTODO | Current | RFCXXXX, Section 3.6.2 | 7220 | | | | 7221 | VJOURNAL | Current | RFCXXXX, Section 3.6.3 | 7222 | | | | 7223 | VFREEBUSY | Current | RFCXXXX, Section 3.6.4 | 7224 | | | | 7225 | VTIMEZONE | Current | RFCXXXX, Section 3.6.5 | 7226 | | | | 7227 | VALARM | Current | RFCXXXX, Section 3.6.6 | 7228 | | | | 7229 | STANDARD | Current | RFCXXXX, Section 3.6.5 | 7230 | | | | 7231 | DAYLIGHT | Current | RFCXXXX, Section 3.6.5 | 7232 +-----------+---------+------------------------+ 7234 8.3.2. Properties Registry 7236 The following table is to be used to initialize the properties 7237 registry. 7239 +------------------+------------+---------------------------+ 7240 | Property | Status | Reference | 7241 +------------------+------------+---------------------------+ 7242 | CALSCALE | Current | RFCXXXX, Section 3.7.1 | 7243 | | | | 7244 | METHOD | Current | RFCXXXX, Section 3.7.2 | 7245 | | | | 7246 | PRODID | Current | RFCXXXX, Section 3.7.3 | 7247 | | | | 7248 | VERSION | Current | RFCXXXX, Section 3.7.4 | 7249 | | | | 7250 | ATTACH | Current | RFCXXXX, Section 3.8.1.1 | 7251 | | | | 7252 | CATEGORIES | Current | RFCXXXX, Section 3.8.1.2 | 7253 | | | | 7254 | CLASS | Current | RFCXXXX, Section 3.8.1.3 | 7255 | | | | 7256 | COMMENT | Current | RFCXXXX, Section 3.8.1.4 | 7257 | | | | 7258 | DESCRIPTION | Current | RFCXXXX, Section 3.8.1.5 | 7259 | | | | 7260 | GEO | Current | RFCXXXX, Section 3.8.1.6 | 7261 | | | | 7262 | LOCATION | Current | RFCXXXX, Section 3.8.1.7 | 7263 | | | | 7264 | PERCENT-COMPLETE | Current | RFCXXXX, Section 3.8.1.8 | 7265 | | | | 7266 | PRIORITY | Current | RFCXXXX, Section 3.8.1.9 | 7267 | | | | 7268 | RESOURCES | Current | RFCXXXX, Section 3.8.1.10 | 7269 | | | | 7270 | STATUS | Current | RFCXXXX, Section 3.8.1.11 | 7271 | | | | 7272 | SUMMARY | Current | RFCXXXX, Section 3.8.1.12 | 7273 | | | | 7274 | COMPLETED | Current | RFCXXXX, Section 3.8.2.1 | 7275 | | | | 7276 | DTEND | Current | RFCXXXX, Section 3.8.2.2 | 7277 | | | | 7278 | DUE | Current | RFCXXXX, Section 3.8.2.3 | 7279 | | | | 7280 | DTSTART | Current | RFCXXXX, Section 3.8.2.4 | 7281 | | | | 7282 | DURATION | Current | RFCXXXX, Section 3.8.2.5 | 7283 | | | | 7284 | FREEBUSY | Current | RFCXXXX, Section 3.8.2.6 | 7285 | | | | 7286 | TRANSP | Current | RFCXXXX, Section 3.8.2.7 | 7287 | | | | 7288 | TZID | Current | RFCXXXX, Section 3.8.3.1 | 7289 | | | | 7290 | TZNAME | Current | RFCXXXX, Section 3.8.3.2 | 7291 | | | | 7292 | TZOFFSETFROM | Current | RFCXXXX, Section 3.8.3.3 | 7293 | | | | 7294 | TZOFFSETTO | Current | RFCXXXX, Section 3.8.3.4 | 7295 | | | | 7296 | TZURL | Current | RFCXXXX, Section 3.8.3.5 | 7297 | | | | 7298 | ATTENDEE | Current | RFCXXXX, Section 3.8.4.1 | 7299 | | | | 7300 | CONTACT | Current | RFCXXXX, Section 3.8.4.2 | 7301 | | | | 7302 | ORGANIZER | Current | RFCXXXX, Section 3.8.4.3 | 7303 | | | | 7304 | RECURRENCE-ID | Current | RFCXXXX, Section 3.8.4.4 | 7305 | | | | 7306 | RELATED-TO | Current | RFCXXXX, Section 3.8.4.5 | 7307 | | | | 7308 | URL | Current | RFCXXXX, Section 3.8.4.6 | 7309 | | | | 7310 | UID | Current | RFCXXXX, Section 3.8.4.7 | 7311 | | | | 7312 | EXDATE | Current | RFCXXXX, Section 3.8.5.1 | 7313 | | | | 7314 | EXRULE | Deprecated | RFC2445, Section 4.8.5.2 | 7315 | | | | 7316 | RDATE | Current | RFCXXXX, Section 3.8.5.2 | 7317 | | | | 7318 | RRULE | Current | RFCXXXX, Section 3.8.5.3 | 7319 | | | | 7320 | ACTION | Current | RFCXXXX, Section 3.8.6.1 | 7321 | | | | 7322 | REPEAT | Current | RFCXXXX, Section 3.8.6.2 | 7323 | | | | 7324 | TRIGGER | Current | RFCXXXX, Section 3.8.6.3 | 7325 | | | | 7326 | CREATED | Current | RFCXXXX, Section 3.8.7.1 | 7327 | | | | 7328 | DTSTAMP | Current | RFCXXXX, Section 3.8.7.2 | 7329 | | | | 7330 | LAST-MODIFIED | Current | RFCXXXX, Section 3.8.7.3 | 7331 | | | | 7332 | SEQUENCE | Current | RFCXXXX, Section 3.8.7.4 | 7333 | | | | 7334 | REQUEST-STATUS | Current | RFCXXXX, Section 3.8.8.3 | 7335 +------------------+------------+---------------------------+ 7337 8.3.3. Parameters Registry 7339 The following table is to be used to initialize the parameters 7340 registry. 7342 +----------------+---------+-------------------------+ 7343 | Parameter | Status | Reference | 7344 +----------------+---------+-------------------------+ 7345 | ALTREP | Current | RFCXXXX, Section 3.2.1 | 7346 | | | | 7347 | CN | Current | RFCXXXX, Section 3.2.2 | 7348 | | | | 7349 | CUTYPE | Current | RFCXXXX, Section 3.2.3 | 7350 | | | | 7351 | DELEGATED-FROM | Current | RFCXXXX, Section 3.2.4 | 7352 | | | | 7353 | DELEGATED-TO | Current | RFCXXXX, Section 3.2.5 | 7354 | | | | 7355 | DIR | Current | RFCXXXX, Section 3.2.6 | 7356 | | | | 7357 | ENCODING | Current | RFCXXXX, Section 3.2.7 | 7358 | | | | 7359 | FMTTYPE | Current | RFCXXXX, Section 3.2.8 | 7360 | | | | 7361 | FBTYPE | Current | RFCXXXX, Section 3.2.9 | 7362 | | | | 7363 | LANGUAGE | Current | RFCXXXX, Section 3.2.10 | 7364 | | | | 7365 | MEMBER | Current | RFCXXXX, Section 3.2.11 | 7366 | | | | 7367 | PARTSTAT | Current | RFCXXXX, Section 3.2.12 | 7368 | | | | 7369 | RANGE | Current | RFCXXXX, Section 3.2.13 | 7370 | | | | 7371 | RELATED | Current | RFCXXXX, Section 3.2.14 | 7372 | | | | 7373 | RELTYPE | Current | RFCXXXX, Section 3.2.15 | 7374 | | | | 7375 | ROLE | Current | RFCXXXX, Section 3.2.16 | 7376 | | | | 7377 | RSVP | Current | RFCXXXX, Section 3.2.17 | 7378 | | | | 7379 | SENT-BY | Current | RFCXXXX, Section 3.2.18 | 7380 | | | | 7381 | TZID | Current | RFCXXXX, Section 3.2.19 | 7382 | | | | 7383 | VALUE | Current | RFCXXXX, Section 3.2.20 | 7384 +----------------+---------+-------------------------+ 7386 8.3.4. Value Data Types Registry 7388 The following table is to be used to initialize the value data types 7389 registry. 7391 +-----------------+---------+-------------------------+ 7392 | Value Data Type | Status | Reference | 7393 +-----------------+---------+-------------------------+ 7394 | BINARY | Current | RFCXXXX, Section 3.3.1 | 7395 | | | | 7396 | BOOLEAN | Current | RFCXXXX, Section 3.3.2 | 7397 | | | | 7398 | CAL-ADDRESS | Current | RFCXXXX, Section 3.3.3 | 7399 | | | | 7400 | DATE | Current | RFCXXXX, Section 3.3.4 | 7401 | | | | 7402 | DATE-TIME | Current | RFCXXXX, Section 3.3.5 | 7403 | | | | 7404 | DURATION | Current | RFCXXXX, Section 3.3.6 | 7405 | | | | 7406 | FLOAT | Current | RFCXXXX, Section 3.3.7 | 7407 | | | | 7408 | INTEGER | Current | RFCXXXX, Section 3.3.8 | 7409 | | | | 7410 | PERIOD | Current | RFCXXXX, Section 3.3.9 | 7411 | | | | 7412 | RECUR | Current | RFCXXXX, Section 3.3.10 | 7413 | | | | 7414 | TEXT | Current | RFCXXXX, Section 3.3.11 | 7415 | | | | 7416 | TIME | Current | RFCXXXX, Section 3.3.12 | 7417 | | | | 7418 | URI | Current | RFCXXXX, Section 3.3.13 | 7419 | | | | 7420 | UTC-OFFSET | Current | RFCXXXX, Section 3.3.14 | 7421 +-----------------+---------+-------------------------+ 7423 8.3.5. Calendar User Types Registry 7425 The following table is to be used to initialize the calendar user 7426 types registry. 7428 +--------------------+---------+------------------------+ 7429 | Calendar User Type | Status | Reference | 7430 +--------------------+---------+------------------------+ 7431 | INDIVIDUAL | Current | RFCXXXX, Section 3.2.3 | 7432 | | | | 7433 | GROUP | Current | RFCXXXX, Section 3.2.3 | 7434 | | | | 7435 | RESOURCE | Current | RFCXXXX, Section 3.2.3 | 7436 | | | | 7437 | ROOM | Current | RFCXXXX, Section 3.2.3 | 7438 | | | | 7439 | UNKNOWN | Current | RFCXXXX, Section 3.2.3 | 7440 +--------------------+---------+------------------------+ 7442 8.3.6. Free/Busy Time Types Registry 7444 The following table is to be used to initialize the free/busy time 7445 types registry. 7447 +---------------------+---------+------------------------+ 7448 | Free/Busy Time Type | Status | Reference | 7449 +---------------------+---------+------------------------+ 7450 | FREE | Current | RFCXXXX, Section 3.2.9 | 7451 | | | | 7452 | BUSY | Current | RFCXXXX, Section 3.2.9 | 7453 | | | | 7454 | BUSY-UNAVAILABLE | Current | RFCXXXX, Section 3.2.9 | 7455 | | | | 7456 | BUSY-TENTATIVE | Current | RFCXXXX, Section 3.2.9 | 7457 +---------------------+---------+------------------------+ 7459 8.3.7. Participation Statuses Registry 7461 The following table is to be used to initialize the participation 7462 statuses registry. 7464 +--------------------+---------+-------------------------+ 7465 | Participant Status | Status | Reference | 7466 +--------------------+---------+-------------------------+ 7467 | NEEDS-ACTION | Current | RFCXXXX, Section 3.2.12 | 7468 | | | | 7469 | ACCEPTED | Current | RFCXXXX, Section 3.2.12 | 7470 | | | | 7471 | DECLINED | Current | RFCXXXX, Section 3.2.12 | 7472 | | | | 7473 | TENTATIVE | Current | RFCXXXX, Section 3.2.12 | 7474 | | | | 7475 | DELEGATED | Current | RFCXXXX, Section 3.2.12 | 7476 | | | | 7477 | COMPLETED | Current | RFCXXXX, Section 3.2.12 | 7478 | | | | 7479 | IN-PROCESS | Current | RFCXXXX, Section 3.2.12 | 7480 +--------------------+---------+-------------------------+ 7482 8.3.8. Relationship Types Registry 7484 The following table is to be used to initialize the property 7485 parameters registry. 7487 +-------------------+---------+-------------------------+ 7488 | Relationship Type | Status | Reference | 7489 +-------------------+---------+-------------------------+ 7490 | CHILD | Current | RFCXXXX, Section 3.2.15 | 7491 | | | | 7492 | PARENT | Current | RFCXXXX, Section 3.2.15 | 7493 | | | | 7494 | SIBLING | Current | RFCXXXX, Section 3.2.15 | 7495 +-------------------+---------+-------------------------+ 7497 8.3.9. Participation Roles Registry 7499 The following table is to be used to initialize the participation 7500 roles registry. 7502 +-----------------+---------+-------------------------+ 7503 | Role Type | Status | Reference | 7504 +-----------------+---------+-------------------------+ 7505 | CHAIR | Current | RFCXXXX, Section 3.2.16 | 7506 | | | | 7507 | REQ-PARTICIPANT | Current | RFCXXXX, Section 3.2.16 | 7508 | | | | 7509 | OPT-PARTICIPANT | Current | RFCXXXX, Section 3.2.16 | 7510 | | | | 7511 | NON-PARTICIPANT | Current | RFCXXXX, Section 3.2.16 | 7512 +-----------------+---------+-------------------------+ 7514 8.3.10. Actions Registry 7516 The following table is to be used to initialize the actions registry. 7518 +-----------+------------+--------------------------+ 7519 | Action | Status | Reference | 7520 +-----------+------------+--------------------------+ 7521 | AUDIO | Current | RFCXXXX, Section 3.8.6.1 | 7522 | | | | 7523 | DISPLAY | Current | RFCXXXX, Section 3.8.6.1 | 7524 | | | | 7525 | EMAIL | Current | RFCXXXX, Section 3.8.6.1 | 7526 | | | | 7527 | PROCEDURE | Deprecated | RFC2445, Section 4.8.6.1 | 7528 +-----------+------------+--------------------------+ 7530 8.3.11. Classifications Registry 7532 The following table is to be used to initialize the classifications 7533 registry. 7535 +----------------+---------+--------------------------+ 7536 | Classification | Status | Reference | 7537 +----------------+---------+--------------------------+ 7538 | PUBLIC | Current | RFCXXXX, Section 3.8.1.3 | 7539 | | | | 7540 | PRIVATE | Current | RFCXXXX, Section 3.8.1.3 | 7541 | | | | 7542 | CONFIDENTIAL | Current | RFCXXXX, Section 3.8.1.3 | 7543 +----------------+---------+--------------------------+ 7545 8.3.12. Methods Registry 7547 No values are defined in this document for the "METHOD" property. 7549 9. Acknowledgements 7551 The editor of this document wish to thank Frank Dawson and Derik 7552 Stenerson, the original authors of RFC2445, as well as the following 7553 individuals who have participated in the drafting, review and 7554 discussion of this memo: 7556 Joe Abley, Hervey Allen, Steve Allen, Jay Batson, Oliver Block, 7557 Stephane Bortzmeyer, Chris Bryant, Tantek Celik, Mark Crispin, Cyrus 7558 Daboo, Mike Douglass, Andrew N. Dowden, Lisa Dusseault, Lars Eggert, 7559 Gren Eliot, Pasi Eronen, Ben Fortuna, Ned Freed, Neal Gafter, Ted 7560 Hardie, Tim Hare, Jeffrey Harris, Helge Hess, Paul B. Hill, Thomas 7561 Hnetila, Russ Housley, Leif Johansson, Ciny Joy, Bruce Kahn, Reinhold 7562 Kainhofer, Martin Kiff, Patrice Lapierre, Eliot Lear, Michiel van 7563 Leeuwen, Jonathan Lennox, Jeff McCullough, Bill McQuillan, Alexey 7564 Melnikov, Aki Niemi, John W. Noerenberg II, Chuck Norris, Mark 7565 Paterson, Simon Pilette, Arnaud Quillaud, Robert Ransdell, Julian F. 7566 Reschke, Caleb Richardson, Sam Roberts, Dan Romascanu, Mike Samuel, 7567 George Sexton, Nigel Swinson, Clint Talbert, Simon Vaillancourt, 7568 Magnus Westerlund, and Sandy Wills. 7570 The editor would also like to thank the Calendaring and Scheduling 7571 Consortium for advice with this specification, and for organizing 7572 interoperability testing events to help refine it. 7574 10. References 7576 10.1. Normative References 7578 [ISO.8601.2004] International Organization for 7579 Standardization, "Data elements and 7580 interchange formats -- Information 7581 interchange -- Representation of dates 7582 and times", 2004. 7584 [ISO.9070.1991] International Organization for 7585 Standardization, "Information 7586 Technology_SGML Support Facilities -- 7587 Registration Procedures for Public 7588 Text Owner Identifiers, Second 7589 Edition", April 1991. 7591 [RFC2045] Freed, N. and N. Borenstein, 7592 "Multipurpose Internet Mail Extensions 7593 (MIME) Part One: Format of Internet 7594 Message Bodies", RFC 2045, 7595 November 1996. 7597 [RFC2046] Freed, N. and N. Borenstein, 7598 "Multipurpose Internet Mail Extensions 7599 (MIME) Part Two: Media Types", 7600 RFC 2046, November 1996. 7602 [RFC2119] Bradner, S., "Key words for use in 7603 RFCs to Indicate Requirement Levels", 7604 BCP 14, RFC 2119, March 1997. 7606 [RFC2368] Hoffman, P., Masinter, L., and J. 7607 Zawinski, "The mailto URL scheme", 7608 RFC 2368, July 1998. 7610 [RFC3629] Yergeau, F., "UTF-8, a transformation 7611 format of ISO 10646", STD 63, 7612 RFC 3629, November 2003. 7614 [RFC3986] Berners-Lee, T., Fielding, R., and L. 7615 Masinter, "Uniform Resource Identifier 7616 (URI): Generic Syntax", STD 66, 7617 RFC 3986, January 2005. 7619 [RFC4288] Freed, N. and J. Klensin, "Media Type 7620 Specifications and Registration 7621 Procedures", BCP 13, RFC 4288, 7622 December 2005. 7624 [RFC4646] Phillips, A. and M. Davis, "Tags for 7625 Identifying Languages", BCP 47, 7626 RFC 4646, September 2006. 7628 [RFC4648] Josefsson, S., "The Base16, Base32, 7629 and Base64 Data Encodings", RFC 4648, 7630 October 2006. 7632 [RFC5234] Crocker, D. and P. Overell, "Augmented 7633 BNF for Syntax Specifications: ABNF", 7634 STD 68, RFC 5234, January 2008. 7636 10.2. Informative References 7638 [I-D.ietf-calsify-2446bis] Daboo, C., "iCalendar Transport- 7639 Independent Interoperability Protocol 7640 (iTIP)", draft-ietf-calsify-2446bis-09 7641 (work in progress), April 2009. 7643 [I-D.ietf-calsify-rfc2447bis] Melnikov, A., "iCalendar Message-Based 7644 Interoperability Protocol(iMIP)", 7645 draft-ietf-calsify-rfc2447bis-05 (work 7646 in progress), June 2008. 7648 [RFC1738] Berners-Lee, T., Masinter, L., and M. 7649 McCahill, "Uniform Resource Locators 7650 (URL)", RFC 1738, December 1994. 7652 [RFC2392] Levinson, E., "Content-ID and 7653 Message-ID Uniform Resource Locators", 7654 RFC 2392, August 1998. 7656 [RFC2397] Masinter, L., "The "data" URL scheme", 7657 RFC 2397, August 1998. 7659 [RFC2425] Howes, T., Smith, M., and F. Dawson, 7660 "A MIME Content-Type for Directory 7661 Information", RFC 2425, 7662 September 1998. 7664 [RFC2426] Dawson, F. and T. Howes, "vCard MIME 7665 Directory Profile", RFC 2426, 7666 September 1998. 7668 [RFC2616] Fielding, R., Gettys, J., Mogul, J., 7669 Frystyk, H., Masinter, L., Leach, P., 7670 and T. Berners-Lee, "Hypertext 7671 Transfer Protocol -- HTTP/1.1", 7672 RFC 2616, June 1999. 7674 [RFC2818] Rescorla, E., "HTTP Over TLS", 7675 RFC 2818, May 2000. 7677 [RFC4516] Smith, M. and T. Howes, "Lightweight 7678 Directory Access Protocol (LDAP): 7679 Uniform Resource Locator", RFC 4516, 7680 June 2006. 7682 [RFC4791] Daboo, C., Desruisseaux, B., and L. 7683 Dusseault, "Calendaring Extensions to 7684 WebDAV (CalDAV)", RFC 4791, 7685 March 2007. 7687 [TZDB] Eggert, P. and A. Olson, "Sources for 7688 Time Zone and Daylight Saving Time 7689 Data", January 2007, . 7692 [Note to RFC Editor: Change "A. Olson" 7693 to "A.D. Olson".] 7695 [VCAL] Internet Mail Consortium, "vCalendar: 7696 The Electronic Calendaring and 7697 Scheduling Exchange Format", 7698 September 1996, 7699 . 7701 URIs 7703 [1] 7705 [2] 7707 [3] 7709 Appendix A. Differences from RFC 2445 7711 This appendix contains a list of changes that have been made in the 7712 Internet Calendaring and Scheduling Core Object Specification from 7713 RFC 2445. 7715 A.1. New restrictions 7717 1. The "DTSTART" property SHOULD be synchronized with the recurrence 7718 rule, if specified. 7720 2. The "RRULE" property SHOULD NOT occur more than once in a 7721 component. 7723 3. The BYHOUR, BYMINUTE and BYSECOND rule parts MUST NOT be 7724 specified in the "RRULE" property when the "DTSTART" property is 7725 specified as a DATE value. 7727 4. The value type of the "DTEND" or "DUE" properties MUST match the 7728 value type of "DTSTART" property. 7730 5. The "DURATION" property can no longer appear in "VFREEBUSY" 7731 components. 7733 A.2. Restrictions removed 7735 1. The "DTSTART" and "DTEND" properties are no longer required to be 7736 specified as date with local time and time zone reference when 7737 used with a recurrence rule. 7739 A.3. Deprecated features 7741 1. The "EXRULE" property can no longer be specified in a component. 7743 2. The "THISANDPRIOR" value can no longer be used with the "RANGE" 7744 parameter. 7746 3. The "PROCEDURE" value can no longer be used with the "ACTION" 7747 property. 7749 4. The value type RECUR no longer allow multiple values to be 7750 specified by a COMMA (US-ASCII decimal 44) character separated 7751 list of values. 7753 5. x-name rule parts can no longer be specified in properties of 7754 RECUR value type (e.g., "RRULE"). x-param can be used on RECUR 7755 value type properties instead. 7757 Appendix B. Change Log (to be removed by RFC Editor prior to 7758 publication) 7760 B.1. Changes in -10 7762 A detailed list of changes is available at the following page: 7763 http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/ 7764 draft-ietf-calsify-rfc2445bis-10.changes.html. 7766 a. Addressed IESG evaluation comments and discusses. 7768 b. Clarified that the "RECURRENCE-ID" property MUST have the same 7769 value type as the "DTSTART" property contained within the 7770 recurring component and MUST be specified as a date with local 7771 time if and only if the "DTSTART" property contained within the 7772 recurring component is specified as a date with local time. 7774 B.2. Changes in -09 7776 A detailed list of changes is available at the following page: 7777 http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/ 7778 draft-ietf-calsify-rfc2445bis-09.changes.html. 7780 a. Issue 60: Clarified that multi-valued properties MUST NOT be used 7781 to specify multiple language variants of the same value. 7783 b. Issue 67: Forbid the use of the "DURATION" property in 7784 "VFREEBUSY" components. 7786 c. AD-Issue 1: Added note on most commonly used URI schemes for the 7787 "ALTREP" parameter. 7789 d. AD-Issue 2: Added recommendation on the URI schemes to use for 7790 the "DIR" parameter. 7792 e. AD-Issue 4: Added recommendation for calendar applications that 7793 support importing iCalendar objects. 7795 f. iTIP-APPS-Issue 1: Allowed "DTSTART" to be OPTIONAL for iTIP. 7797 g. iTIP-APPS-Issue 2: Fixed time zone example. 7799 h. iTIP-APPS-Issue 3: Clarified that recurrence instances MAY have 7800 different sequence numbers. 7802 i. iTIP-APPS-Issue 4: Clarified description of the "INTERVAL" rule 7803 part. 7805 j. Modified TSAFE-CHAR to allow HTAB (US-ASCII decimal 9) in TEXT 7806 values. 7808 k. Few editorial changes. 7810 l. Added names to the Acknowledgments section. 7812 B.3. Changes in -08 7814 A detailed list of changes is available at the following page: 7815 http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/ 7816 draft-ietf-calsify-rfc2445bis-08.changes.html. 7818 a. Issue 48: Revert the change to deprecate the "RANGE" parameter. 7819 Only the value "THISANDPRIOR" is deprecated. 7821 b. Issue 81: BYSETPOS: Clarify that "a set" starts at the beginning 7822 of the interval defined by the FREQ rule part. 7824 c. Chair Review: Changed requirement to handle unrecognized CUTYPE 7825 values. 7827 d. Chair Review: Changed requirement to handle unrecognized VALUE 7828 data types. 7830 e. Chair Review: Removed requirements for "DELEGATED-TO" and 7831 "DELEGATED-FROM" to be specified as mailto URI. 7833 f. Chair Review: Added note about alarms from untrusted sources. 7835 g. Chair Review: Added text to clarify the structure of the 7836 document. 7838 h. Chair Review: Added forward reference to the section covering 7839 BACKSLASH character encoding. 7841 i. Removed the text that specifies when the sequence number MUST be 7842 incremented. Text will be added to rfc2446bis. 7844 j. Removed normative reference to RFC2822. 7846 k. Changed reference of RFC4234 to RFC5234. 7848 l. Few editorial changes. 7850 B.4. Changes in -07 7852 A detailed list of changes is available at the following page: 7853 http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/ 7854 draft-ietf-calsify-rfc2445bis-07.changes.html. 7856 a. Issue 8: Clarified how to compute the exact duration of a nominal 7857 duration. 7859 b. Issue 10: Added new examples for "VEVENT" and "VTODO" to 7860 demonstrate that end times are always non-inclusive, that is, 7861 even end times specified as DATE values. 7863 c. Issue 11: Added a table that shows the dependency of BYxxx rule 7864 part expand or limit behaviour on the FREQ value in the rule. 7866 d. Issue 19: Removed section "Registration of Content Type 7867 Elements". Added registration templates in IANA Considerations 7868 section. Specified how applications should treat x-name and 7869 x-token they don't recognize. 7871 e. Issue 65: Removed 3rd recommended practice. Added new 7872 requirements to require "DTEND" and "DUE" to be a local date time 7873 if and only if "DTSTART" is a local date time. 7875 f. Issue 68: Clarified handling of date-times that fall in time 7876 discontinutities. 7878 g. Issue 69: Clarified handling of recurrence instances that fall in 7879 time discontinutities 7881 h. Issue 71: Clarified handling of leap seconds. 7883 i. Issue 75: Clarified that the "RDATE" property MUST be specified 7884 as a local DATE-TIME value in "VTIMEZONE" sub-components. 7886 j. Issue 76: Clarified that the value type of the "DTEND" property 7887 MUST be the same as the "DTSTART" property. 7889 k. Issue 77: Clarified that the value type of the "DUE" property 7890 MUST be the same as the "DTSTART" property. 7892 l. Issue 79: Clarified that "DTSTART" always specify an onset date- 7893 time of an observance and that its value does not need to be 7894 repeated in an "RDATE" property. 7896 m. Issue 80: Rewrote Security Considerations section. 7898 n. Issue 81: Clarified the meaning of "the set of events specified 7899 by the rule" in the description of the BYSETPOS rule part. 7901 o. Modified Abstract section. 7903 p. Moved text of section 2.3 International Considerations at the end 7904 of sectino 2.1 Formatting Conventions. 7906 q. Added Internationalization Considerations section. 7908 r. Modified the description of the following properties: "ATTACH", 7909 "COMMENT", "COMPLETED", "CREATED" "DTSTAMP" "DUE", and "REPEAT". 7911 s. Clarified some differences with ISO 8601. 7913 t. Updated reference to CalDAV and ISO 8601. 7915 u. Updated section "Differences from RFC 2445": added new 7916 restrictions and added list of removed restrictions. 7918 v. Numerous editorial changes. 7920 B.5. Changes in -06 7922 A detailed list of changes is available at the following page: 7923 http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/ 7924 draft-ietf-calsify-rfc2445bis-06.changes.html. 7926 a. Issue 19: Defined new IANA registries. [Work in progress]; 7928 b. Issue 23: Clarified that the UNTIL rule part MUST specify a value 7929 of the same type as the value specified by "DTSTART"; 7931 c. Issue 27: Clarified how the duration of generated recurrence 7932 instances is determined; 7934 d. Issue 35: Further clarified the description of the "LANGUAGE" 7935 property; 7937 e. Issue 42: Removed the restriction on the values allowed for the 7938 "ACTION" property in the the "VALARM" component; 7940 f. Issue 47: Clarified that alarm triggers relative to a DATE value 7941 type needs to be triggered to 00:00:00 of the user's configured 7942 time zone; 7944 g. Issue 56: Added a note to specify that FREQ MUST be specified as 7945 the first rule part in generated iCalendar applications, but MUST 7946 be accepted in any order to ensure backward compatibility. The 7947 rest of the RECUR value type ABNF has been further simplified; 7949 h. Issue 59: Clarified the default duration of "VEVENT" components 7950 specified with a "DTSTART" property of DATE value type; 7952 i. Issue 61: Modified all the property ABNFs to allow iana-param in 7953 addition to x-param. Also modified the component ABNFs to allow 7954 iana-prop in addition to x-prop. [Work in progress]; 7956 j. Issue 62: Removed the text that lead to believe that the 7957 "RECURRENCE-ID" of a specific recurrence instance might change; 7959 k. Issue 64: Clarified that REQUEST-STATUS only allows pairs (1.1) 7960 and 3-tuples (1.1.1). 7962 l. Issue 65: Clarified that a different time zone may be used by 7963 "DTSTART" and "DTEND", and "DTSTART" and "DUE" when specified as 7964 date with local time and time zone reference. [Work in 7965 progress]; 7967 m. Issue 66: Clarified that if the "RDATE" property is specified as 7968 a PERIOD, its duration has precedence over the duration of the 7969 recurrence instance defined by the "DTSTART" property; 7971 n. Issue 72: Removed the requirement that a "VTIMEZONE" calendar 7972 component MUST be present if the iCalendar object contains an 7973 RRULE that generates dates on both sides of a time zone shift; 7975 o. Issue 73: Clarified that the "TZID" must be unique in the scope 7976 of an iCalendar object only; 7978 p. Issue 74: Deprecated the "PROCEDURE" value for the "ACTION" 7979 property; 7981 q. Issue 78: Fixed the text to specify that "TZOFFSETFROM" and not 7982 "TZOFFSETTO" must be used with "DTSTART" when generating the 7983 onset date-time values from the "RRULE" in a "VTIMEZONE" 7984 component; 7986 r. Clarified that the "DTSTART" property MUST be specified in a 7987 "VTODO" component when the "DURATION" property is specified; 7989 s. Started to update the time zone information / examples; 7991 t. Numerous editorial changes. 7993 B.6. Changes in -05 7995 A detailed list of changes is available at the following page: 7996 http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/ 7997 draft-ietf-calsify-rfc2445bis-05.changes.html. 7999 a. Fixed ABNF with references in .txt version of the draft; 8001 b. Numerous editorial changes; 8003 c. Clarified that normative statements in ABNF comments should be 8004 considered as normative; 8006 d. Removed notes talking of character sets other than US-ASCII and 8007 UTF-8; 8009 e. Renamed CTL to CONTROL to avoid conflict with the CTL rule 8010 defined in RFC4234; 8012 f. Removed ABNF rules defined in RFC4234; 8014 g. Changed the partstatparam ABNF rule for clarity; 8016 h. Clarified the purpose of negative durations; 8018 i. Added informational references to RFC 2392 (CID URL) and RFC 4516 8019 (LDAP URL). 8021 j. Updated TZDB reference. 8023 B.7. Changes in -04 8025 A detailed list of changes is available at the following page: 8026 http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/ 8027 draft-ietf-calsify-rfc2445bis-04.changes.html. 8029 a. Issue 16: Clarified that recurrence instances, generated by a 8030 recurrence rule, with an invalid date or nonexistent local time 8031 must be ignored and not counted as part of the recurrence set. 8033 b. Issue 26: Clarified how to handle the BYHOUR, BYMINUTE and 8034 BYSECOND rule parts when "DTSTART" is a DATE value. 8036 c. Issue 28: Removed the MUST requirement to specify the "RDATE" 8037 property whenever the duration of a recurrence instance is 8038 modified. 8040 d. Issue 29: Clarified that the "DTSTART" property is REQUIRED in 8041 all types of recurring components. 8043 e. Issue 32: Introduced the notion of an "iCalendar stream" to make 8044 it explicit when we are refering to a "single iCalendar object" 8045 or a "sequence of iCalendar objects". 8047 f. Issue 34: Clarified what should be done with the "method" 8048 parameter when the iCalendar stream is a sequence of iCalendar 8049 objects. 8051 g. Issue 40: Changed to fbprop ABNF rule to specify that the 8052 "DTSTAMP" and the "UID" properties are REQUIRED in "VFREEBUSY" 8053 components. 8055 h. Issue 43: Removed the MUST requirement to specify the "DTSTART" 8056 and the "DTEND" properties as local time in recurring components, 8057 but added a note that in most cases this is the right thing to 8058 do. 8060 i. Issue 44: Changed the x-prop ABNF to allow any parameters on non- 8061 standard properties. 8063 j. Issue 46: Simplified the tzprop, audioprop, dispprop, emailprop, 8064 and procprop ABNF rules by removing the number of required 8065 properties in front of the "*". 8067 k. Issue 48: Deprecated the "RANGE" parameter. 8069 l. Issue 51: Clarified implicit duration of day events with no 8070 "DTEND" nor "DURATION" property. 8072 m. Issue 52: Removed x-name from the "recur" rule part definition. 8073 It should be sufficient to allow xparam on properties of RECUR 8074 value type. 8076 n. Issue 53: Updated the NON-US-ASCII ABNF rule for UTF-8. 8078 o. Issue 56: Changed the "recur" ABNF rule to allow rule parts to be 8079 specified in any order. 8081 p. Issue 57: Specified that the "DURATION" property MUST be 8082 specified as a "dur-day" or "dur-week" value when the "DTSTART" 8083 is a DATE. 8085 q. Issue 58: Changed the jourprop ABNF rule to allow the 8086 "DESCRIPTION" property to occur more than once. 8088 r. Numerous editorial changes. 8090 s. Changed reference to RFC 4646 for Language-Tag. 8092 B.8. Changes in -03 8094 A detailed list of changes is available at the following page: 8095 http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/ 8096 draft-ietf-calsify-rfc2445bis-03.changes.html. 8098 a. Numerous editorial changes. 8100 b. Specified that "DTSTART" should match the pattern of "RRULE" and 8101 is always part of the "COUNT". 8103 c. Specified "RRULE" should not occur more than once in recurring 8104 components. 8106 d. Deprecated "EXRULE". 8108 e. Fixed all ABNF errors reported by Bill Fenner's ABNF parsing web 8109 service available at: 8110 http://rtg.ietf.org/~fenner/abnf.cgi. 8112 f. Changed reference to RFC 4648 for Base64 encoding. 8114 B.9. Changes in -02 8116 A detailed list of changes is available at the following page: 8117 http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/ 8118 draft-ietf-calsify-rfc2445bis-02.changes.html. 8120 a. Numerous editorial changes including the typos listed in the 8121 "RFC2445 Errata": 8122 http://www.rfc-editor.org/cgi-bin/errataSearch.pl?rfc=2445& 8123 and in the "RFC2445 Issues List": 8124 http://www.softwarestudio.org/iCal/2445Issues.html. 8126 b. Clarified line folding requirements. 8128 c. Clarified charset requirements. 8130 d. Clarified line limits requirements. 8132 e. Clarified on the use of the "LANGUAGE" parameter. 8134 f. Fixed the eventprop, todoprop and jourprop ABNF rules with 8135 respect to required properties. 8137 g. Fixed all the examples to use RFC2606-compliant FQDNs. 8139 h. Fixed the Content-ID URLs in the examples. 8141 i. Fixed the LDAP URLs in the examples. 8143 j. Moved multiple references in the Informative References section. 8145 k. Updated the Acknowledgments section. 8147 B.10. Changes in -01 8149 A detailed list of changes is available at the following page: 8150 http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/ 8151 draft-ietf-calsify-rfc2445bis-01.changes.html. 8153 a. Numerous editorial changes (typos, errors in examples, etc.). 8155 b. Fixed invalid media types in examples. 8157 c. Fixed the "DTSTAMP" values in the examples. 8159 d. Moved media type registration in a separate IANA Consideration 8160 section. 8162 e. Added Internationalization Considerations section. 8164 f. Added Security Considerations section. 8166 g. Updated the Acknowledgments section. 8168 Author's Address 8170 Bernard Desruisseaux (editor) 8171 Oracle Corporation 8172 600 blvd. de Maisonneuve West 8173 Suite 1900 8174 Montreal, QC H3A 3J2 8175 CANADA 8177 EMail: bernard.desruisseaux@oracle.com 8178 URI: http://www.oracle.com/