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

670 Project XYZ Review Meeting will include 671 the following agenda items: 672

    673
  1. Market Overview
    2. 674
  2. Finances
    3. 675
  3. Project Management
    4. 676
677

678 679 681 3.2.2. Common Name 683 Parameter Name: CN 685 Purpose: To specify the common name to be associated with the 686 calendar user specified by the property. 688 Format Definition: This property parameter is defined by the 689 following notation: 691 cnparam = "CN" "=" param-value 693 Description: This parameter can be specified on properties with a 694 CAL-ADDRESS value type. The parameter specifies the common name 695 to be associated with the calendar user specified by the property. 696 The parameter value is text. The parameter value can be used for 697 display text to be associated with the calendar address specified 698 by the property. 700 Example: 702 ORGANIZER;CN="John Smith":mailto:jsmith@example.com 704 3.2.3. Calendar User Type 706 Parameter Name: CUTYPE 708 Purpose: To specify the type of calendar user specified by the 709 property. 711 Format Definition: This property parameter is defined by the 712 following notation: 714 cutypeparam = "CUTYPE" "=" 715 ("INDIVIDUAL" ; An individual 716 / "GROUP" ; A group of individuals 717 / "RESOURCE" ; A physical resource 718 / "ROOM" ; A room resource 719 / "UNKNOWN" ; Otherwise not known 720 / x-name ; Experimental type 721 / iana-token) ; Other IANA registered 722 ; type 723 ; Default is INDIVIDUAL 725 Description: This parameter can be specified on properties with a 726 CAL-ADDRESS value type. The parameter identifies the type of 727 calendar user specified by the property. If not specified on a 728 property that allows this parameter, the default is INDIVIDUAL. 730 Example: 732 ATTENDEE;CUTYPE=GROUP:mailto:ietf-calsch@example.org 734 3.2.4. Delegators 736 Parameter Name: DELEGATED-FROM 738 Purpose: To specify the calendar users that have delegated their 739 participation to the calendar user specified by the property. 741 Format Definition: This property parameter is defined by the 742 following notation: 744 delfromparam = "DELEGATED-FROM" "=" DQUOTE cal-address 745 DQUOTE *("," DQUOTE cal-address DQUOTE) 747 Description: This parameter can be specified on properties with a 748 CAL-ADDRESS value type. This parameter specifies those calendar 749 users that have delegated their participation in a group scheduled 750 event or to-do to the calendar user specified by the property. 751 The value MUST be a mailto URI as defined in [RFC2368]. The 752 individual calendar address parameter values MUST each be 753 specified in a quoted-string. 755 Example: 757 ATTENDEE;DELEGATED-FROM="mailto:jsmith@example.com":mailto: 758 jdoe@example.com 760 3.2.5. Delegatees 762 Parameter Name: DELEGATED-TO 764 Purpose: To specify the calendar users to whom the calendar user 765 specified by the property has delegated participation. 767 Format Definition: This property parameter is defined by the 768 following notation: 770 deltoparam = "DELEGATED-TO" "=" DQUOTE cal-address DQUOTE 771 *("," DQUOTE cal-address DQUOTE) 773 Description: This parameter can be specified on properties with a 774 CAL-ADDRESS value type. This parameter specifies those calendar 775 users whom have been delegated participation in a group scheduled 776 event or to-do by the calendar user specified by the property. 777 The value MUST be a mailto URI as defined in [RFC2368]. The 778 individual calendar address parameter values MUST each be 779 specified in a quoted-string. 781 Example: 783 ATTENDEE;DELEGATED-TO="mailto:jdoe@example.com","mailto:jqpublic 784 @example.com":mailto:jsmith@example.com 786 3.2.6. Directory Entry Reference 788 Parameter Name: DIR 790 Purpose: To specify reference to a directory entry associated with 791 the calendar user specified by the property. 793 Format Definition: This property parameter is defined by the 794 following notation: 796 dirparam = "DIR" "=" DQUOTE uri DQUOTE 798 Description: This parameter can be specified on properties with a 799 CAL-ADDRESS value type. The parameter specifies a reference to 800 the directory entry associated with the calendar user specified by 801 the property. The parameter value is a URI. The URI parameter 802 value MUST be specified in a quoted-string. 804 Example: 806 ORGANIZER;DIR="ldap://example.com:6666/o=ABC%20Industries, 807 c=US???(cn=Jim%20Dolittle)":mailto:jimdo@example.com 809 3.2.7. Inline Encoding 811 Parameter Name: ENCODING 813 Purpose: To specify an alternate inline encoding for the property 814 value. 816 Format Definition: This property parameter is defined by the 817 following notation: 819 encodingparam = "ENCODING" "=" 820 ( "8BIT" 821 ; "8bit" text encoding is defined in [RFC2045] 822 / "BASE64" 823 ; "BASE64" binary encoding format is defined in [RFC4648] 824 ) 826 Description: This property parameter identifies the inline encoding 827 used in a property value. The default encoding is "8BIT", 828 corresponding to a property value consisting of text. The 829 "BASE64" encoding type corresponds to a property value encoded 830 using the "BASE64" encoding defined in [RFC2045]. 832 If the value type parameter is ";VALUE=BINARY", then the inline 833 encoding parameter MUST be specified with the value 834 ";ENCODING=BASE64". 836 Example: 838 ATTACH;FMTYPE=IMAGE/JPEG;ENCODING=BASE64;VALUE=BINARY:MIICajC 839 CAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDA 840 qBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMRw 841 <...remainder of "BASE64" encoded binary data...> 843 3.2.8. Format Type 845 Parameter Name: FMTTYPE 847 Purpose: To specify the content type of a referenced object. 849 Format Definition: This property parameter is defined by the 850 following notation: 852 fmttypeparam = "FMTTYPE" "=" type "/" subtype *(";" parameter) 853 ; Where "type", "subtype", and "parameter" 854 ; are defined in section 5.1 of [RFC2045] 856 Description: This parameter can be specified on properties that are 857 used to reference an object. The parameter specifies the content 858 type of the referenced object. For example, on the "ATTACH" 859 property, a FTP type URI value does not, by itself, necessarily 860 convey the type of content associated with the resource. The 861 parameter value MUST be the text for either an IANA registered 862 media type or a non-standard media type. 864 Example: 866 ATTACH;FMTTYPE=application/msword:ftp://example.com/pub/docs/ 867 agenda.doc 869 3.2.9. Free/Busy Time Type 871 Parameter Name: FBTYPE 873 Purpose: To specify the free or busy time type. 875 Format Definition: This property parameter is defined by the 876 following notation: 878 fbtypeparam = "FBTYPE" "=" ("FREE" / "BUSY" 879 / "BUSY-UNAVAILABLE" / "BUSY-TENTATIVE" 880 / x-name 881 ; Some experimental iCalendar free busy type. 882 / iana-token) 883 ; Some other IANA registered iCalendar free busy type. 885 Description: This parameter specifies the free or busy time type. 886 The value FREE indicates that the time interval is free for 887 scheduling. The value BUSY indicates that the time interval is 888 busy because one or more events have been scheduled for that 889 interval. The value BUSY-UNAVAILABLE indicates that the time 890 interval is busy and that the interval can not be scheduled. The 891 value BUSY-TENTATIVE indicates that the time interval is busy 892 because one or more events have been tentatively scheduled for 893 that interval. If not specified on a property that allows this 894 parameter, the default is BUSY. 896 Example: The following is an example of this parameter on a 897 "FREEBUSY" property. 899 FREEBUSY;FBTYPE=BUSY:19980415T133000Z/19980415T170000Z 901 3.2.10. Language 903 Parameter Name: LANGUAGE 905 Purpose: To specify the language for text values in a property or 906 property parameter. 908 Format Definition: This property parameter is defined by the 909 following notation: 911 languageparam = "LANGUAGE" "=" language 913 language = Language-Tag 914 ; As defined in [RFC4646] 916 Description: This parameter identifies the language of the text in 917 the property value and of all property parameter values of the 918 property. The value of the "LANGUAGE" property parameter is that 919 defined in [RFC4646]. 921 For transport in a MIME entity, the Content-Language header field 922 can be used to set the default language for the entire body part. 923 Otherwise, no default language is assumed. 925 Example: The following are examples of this parameter on the 926 "SUMMARY" and "LOCATION" properties: 928 SUMMARY;LANGUAGE=us-EN:Company Holiday Party 930 LOCATION;LANGUAGE=en:Germany 932 LOCATION;LANGUAGE=no:Tyskland 934 3.2.11. Group or List Membership 936 Parameter Name: MEMBER 938 Purpose: To specify the group or list membership of the calendar 939 user specified by the property. 941 Format Definition: This property parameter is defined by the 942 following notation: 944 memberparam = "MEMBER" "=" DQUOTE cal-address DQUOTE 945 *("," DQUOTE cal-address DQUOTE) 947 Description: This parameter can be specified on properties with a 948 CAL-ADDRESS value type. The parameter identifies the groups or 949 list membership for the calendar user specified by the property. 950 The parameter value is either a single calendar address in a 951 quoted-string or a COMMA character (US-ASCII decimal 44) separated 952 list of calendar addresses, each in a quoted-string. The 953 individual calendar address parameter values MUST each be 954 specified in a quoted-string. 956 Example: 958 ATTENDEE;MEMBER="mailto:ietf-calsch@example.org":mailto: 959 jsmith@example.com 961 ATTENDEE;MEMBER="mailto:projectA@example.com","mailto:pr 962 ojectB@example.com":mailto:janedoe@example.com 964 3.2.12. Participation Status 966 Parameter Name: PARTSTAT 968 Purpose: To specify the participation status for the calendar user 969 specified by the property. 971 Format Definition: This property parameter is defined by the 972 following notation: 974 partstatparam = "PARTSTAT" "=" 975 (partstat-event 976 / partstat-todo 977 / partstat-jour) 979 partstat-event = ("NEEDS-ACTION" ; Event needs action 980 / "ACCEPTED" ; Event accepted 981 / "DECLINED" ; Event declined 982 / "TENTATIVE" ; Event tentatively 983 ; accepted 984 / "DELEGATED" ; Event delegated 985 / x-name ; Experimental status 986 / iana-token) ; Other IANA registered 987 ; status 988 ; These are the participation statuses for a "VEVENT". 989 ; Default is NEEDS-ACTION. 991 partstat-todo = ("NEEDS-ACTION" ; To-do needs action 992 / "ACCEPTED" ; To-do accepted 993 / "DECLINED" ; To-do declined 994 / "TENTATIVE" ; To-do tentatively 995 ; accepted 996 / "DELEGATED" ; To-do delegated 997 / "COMPLETED" ; To-do completed. 998 ; COMPLETED property has 999 ; date/time completed. 1000 / "IN-PROCESS" ; To-do in process of 1001 ; being completed 1002 / x-name ; Experimental status 1003 / iana-token) ; Other IANA registered 1004 ; status 1005 ; These are the participation statuses for a "VTODO". 1006 ; Default is NEEDS-ACTION. 1008 partstat-jour = ("NEEDS-ACTION" ; Journal needs action 1009 / "ACCEPTED" ; Journal accepted 1010 / "DECLINED" ; Journal declined 1011 / x-name ; Experimental status 1012 / iana-token) ; Other IANA registered 1013 ; status 1014 ; These are the participation statuses for a "VJOURNAL". 1015 ; Default is NEEDS-ACTION. 1017 Description: This parameter can be specified on properties with a 1018 CAL-ADDRESS value type. The parameter identifies the 1019 participation status for the calendar user specified by the 1020 property value. The parameter values differ depending on whether 1021 they are associated with a group scheduled "VEVENT", "VTODO" or 1022 "VJOURNAL". The values MUST match one of the values allowed for 1023 the given calendar component. If not specified on a property that 1024 allows this parameter, the default value is NEEDS-ACTION. 1026 Example: 1028 ATTENDEE;PARTSTAT=DECLINED:mailto:jsmith@example.com 1030 3.2.13. Alarm Trigger Relationship 1032 Parameter Name: RELATED 1034 Purpose: To specify the relationship of the alarm trigger with 1035 respect to the start or end of the calendar component. 1037 Format Definition: This property parameter is defined by the 1038 following notation: 1040 trigrelparam = "RELATED" "=" 1041 ("START" ; Trigger off of start 1042 / "END") ; Trigger off of end 1044 Description: This parameter can be specified on properties that 1045 specify an alarm trigger with a "DURATION" value type. The 1046 parameter specifies whether the alarm will trigger relative to the 1047 start or end of the calendar component. The parameter value START 1048 will set the alarm to trigger off the start of the calendar 1049 component; the parameter value END will set the alarm to trigger 1050 off the end of the calendar component. If the parameter is not 1051 specified on an allowable property, then the default is START. 1053 Example: 1055 TRIGGER;RELATED=END:PT5M 1057 3.2.14. Relationship Type 1059 Parameter Name: RELTYPE 1061 Purpose: To specify the type of hierarchical relationship associated 1062 with the calendar component specified by the property. 1064 Format Definition: This property parameter is defined by the 1065 following notation: 1067 reltypeparam = "RELTYPE" "=" 1068 ("PARENT" ; Parent relationship. Default. 1069 / "CHILD" ; Child relationship 1070 / "SIBLING" ; Sibling relationship 1071 / iana-token ; Some other IANA registered 1072 ; iCalendar relationship type 1073 / x-name) ; A non-standard, experimental 1074 ; relationship type 1076 Description: This parameter can be specified on a property that 1077 references another related calendar. The parameter specifies the 1078 hierarchical relationship type of the calendar component 1079 referenced by the property. The parameter value can be PARENT, to 1080 indicate that the referenced calendar component is a superior of 1081 calendar component; CHILD to indicate that the referenced calendar 1082 component is a subordinate of the calendar component; SIBLING to 1083 indicate that the referenced calendar component is a peer of the 1084 calendar component. If this parameter is not specified on an 1085 allowable property, the default relationship type is PARENT. 1087 Example: 1089 RELATED-TO;RELTYPE=SIBLING:19960401-080045-4000F192713@ 1090 example.com 1092 3.2.15. Participation Role 1094 Parameter Name: ROLE 1096 Purpose: To specify the participation role for the calendar user 1097 specified by the property. 1099 Format Definition: This property parameter is defined by the 1100 following notation: 1102 roleparam = "ROLE" "=" 1103 ("CHAIR" ; Indicates chair of the 1104 ; calendar entity 1105 / "REQ-PARTICIPANT" ; Indicates a participant whose 1106 ; participation is required 1107 / "OPT-PARTICIPANT" ; Indicates a participant whose 1108 ; participation is optional 1109 / "NON-PARTICIPANT" ; Indicates a participant who 1110 ; is copied for information 1111 ; purposes only 1112 / x-name ; Experimental role 1113 / iana-token) ; Other IANA role 1114 ; Default is REQ-PARTICIPANT 1116 Description: This parameter can be specified on properties with a 1117 CAL-ADDRESS value type. The parameter specifies the participation 1118 role for the calendar user specified by the property in the group 1119 schedule calendar component. If not specified on a property that 1120 allows this parameter, the default value is REQ-PARTICIPANT. 1122 Example: 1124 ATTENDEE;ROLE=CHAIR:mailto:mrbig@example.com 1126 3.2.16. RSVP Expectation 1128 Parameter Name: RSVP 1130 Purpose: To specify whether there is an expectation of a favor of a 1131 reply from the calendar user specified by the property value. 1133 Format Definition: This property parameter is defined by the 1134 following notation: 1136 rsvpparam = "RSVP" "=" ("TRUE" / "FALSE") 1137 ; Default is FALSE 1139 Description: This parameter can be specified on properties with a 1140 CAL-ADDRESS value type. The parameter identifies the expectation 1141 of a reply from the calendar user specified by the property value. 1142 This parameter is used by the "Organizer" to request a 1143 participation status reply from an "Attendee" of a group scheduled 1144 event or to-do. If not specified on a property that allows this 1145 parameter, the default value is FALSE. 1147 Example: 1149 ATTENDEE;RSVP=TRUE:mailto:jsmith@example.com 1151 3.2.17. Sent By 1153 Parameter Name: SENT-BY 1155 Purpose: To specify the calendar user that is acting on behalf of 1156 the calendar user specified by the property. 1158 Format Definition: This property parameter is defined by the 1159 following notation: 1161 sentbyparam = "SENT-BY" "=" DQUOTE cal-address DQUOTE 1163 Description: This parameter can be specified on properties with a 1164 CAL-ADDRESS value type. The parameter specifies the calendar user 1165 that is acting on behalf of the calendar user specified by the 1166 property. The parameter value MUST be a mailto URI as defined in 1167 [RFC2368]. The individual calendar address parameter values MUST 1168 each be specified in a quoted-string. 1170 Example: 1172 ORGANIZER;SENT-BY="mailto:sray@example.com":mailto: 1173 jsmith@example.com 1175 3.2.18. Time Zone Identifier 1177 Parameter Name: TZID 1179 Purpose: To specify the identifier for the time zone definition for 1180 a time component in the property value. 1182 Format Definition: This property parameter is defined by the 1183 following notation: 1185 tzidparam = "TZID" "=" [tzidprefix] paramtext 1187 tzidprefix = "/" 1189 Description: This parameter MUST be specified on the "DTSTART", 1190 "DTEND", "DUE", "EXDATE" and "RDATE" properties when either a 1191 DATE-TIME or TIME value type is specified and when the value is 1192 not either a UTC or a "floating" time. Refer to the DATE-TIME or 1193 TIME value type definition for a description of UTC and "floating 1194 time" formats. This property parameter specifies a text value 1195 which uniquely identifies the "VTIMEZONE" calendar component to be 1196 used when evaluating the time portion of the property. The value 1197 of the "TZID" property parameter will be equal to the value of the 1198 "TZID" property for the matching time zone definition. An 1199 individual "VTIMEZONE" calendar component MUST be specified for 1200 each unique "TZID" parameter value specified in the iCalendar 1201 object. 1203 The parameter MUST be specified on properties with a DATE-TIME 1204 value if the DATE-TIME is not either a UTC or a "floating" time. 1206 The presence of the SOLIDUS character (US-ASCII decimal 47) as a 1207 prefix, indicates that this "TZID" represents a unique ID in a 1208 globally defined time zone registry (when such registry is 1209 defined). 1211 Note: This document does not define a naming convention for 1212 time zone identifiers. Implementers may want to use the naming 1213 conventions defined in existing time zone specifications such 1214 as the public-domain TZ database [TZDB]. The specification of 1215 globally unique time zone identifiers is not addressed by this 1216 document and is left for future study. 1218 The following are examples of this property parameter: 1220 DTSTART;TZID=America/New_York:19980119T020000 1222 DTEND;TZID=America/New_York:19980119T030000 1224 The "TZID" property parameter MUST NOT be applied to DATE-TIME or 1225 TIME properties whose time values are specified in UTC. 1227 The use of local time in a DATE-TIME or TIME value without the 1228 "TZID" property parameter is to be interpreted as a local time 1229 value, regardless of the existence of "VTIMEZONE" calendar 1230 components in the iCalendar object. 1232 For more information see the sections on the value types DATE-TIME 1233 and TIME. 1235 3.2.19. Value Data Types 1237 Parameter Name: VALUE 1239 Purpose: To explicitly specify the value type format for a property 1240 value. 1242 Format Definition: This property parameter is defined by the 1243 following notation: 1245 valuetypeparam = "VALUE" "=" valuetype 1247 valuetype = ("BINARY" 1248 / "BOOLEAN" 1249 / "CAL-ADDRESS" 1250 / "DATE" 1251 / "DATE-TIME" 1252 / "DURATION" 1253 / "FLOAT" 1254 / "INTEGER" 1255 / "PERIOD" 1256 / "RECUR" 1257 / "TEXT" 1258 / "TIME" 1259 / "URI" 1260 / "UTC-OFFSET" 1261 / x-name 1262 ; Some experimental iCalendar value type. 1263 / iana-token) 1264 ; Some other IANA registered iCalendar value type. 1266 Description: This parameter specifies the value type and format of 1267 the property value. The property values MUST be of a single value 1268 type. For example, a "RDATE" property cannot have a combination 1269 of DATE-TIME and TIME value types. 1271 If the property's value is the default value type, then this 1272 parameter need not be specified. However, if the property's 1273 default value type is overridden by some other allowable value 1274 type, then this parameter MUST be specified. 1276 3.3. Property Value Data Types 1278 The properties in an iCalendar object are strongly typed. The 1279 definition of each property restricts the value to be one of the 1280 value data types, or simply value types, defined in this section. 1281 The value type for a property will either be specified implicitly as 1282 the default value type or will be explicitly specified with the 1283 "VALUE" parameter. If the value type of a property is one of the 1284 alternate valid types, then it MUST be explicitly specified with the 1285 "VALUE" parameter. 1287 3.3.1. Binary 1288 Value Name: BINARY 1290 Purpose: This value type is used to identify properties that contain 1291 a character encoding of inline binary data. For example, an 1292 inline attachment of a document might be included in an iCalendar 1293 object. 1295 Format Definition: This value type is defined by the following 1296 notation: 1298 binary = *(4b-char) [b-end] 1299 ; A "BASE64" encoded character string, as defined by [RFC4648]. 1301 b-end = (2b-char "==") / (3b-char "=") 1303 b-char = ALPHA / DIGIT / "+" / "/" 1305 Description: Property values with this value type MUST also include 1306 the inline encoding parameter sequence of ";ENCODING=BASE64". 1307 That is, all inline binary data MUST first be character encoded 1308 using the "BASE64" encoding method defined in [RFC2045]. No 1309 additional content value encoding (i.e., BACKSLASH character 1310 encoding) is defined for this value type. 1312 Example: The following is an abridged example of a "BASE64" encoded 1313 binary value data. 1315 JKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlI 1316 ENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZv 1317 <...remainder of "BASE64" encoded binary data...> 1319 3.3.2. Boolean 1321 Value Name: BOOLEAN 1323 Purpose: This value type is used to identify properties that contain 1324 either a "TRUE" or "FALSE" Boolean value. 1326 Format Definition: This value type is defined by the following 1327 notation: 1329 boolean = "TRUE" / "FALSE" 1331 Description: These values are case insensitive text. No additional 1332 content value encoding (i.e., BACKSLASH character encoding) is 1333 defined for this value type. 1335 Example: The following is an example of a hypothetical property that 1336 has a BOOLEAN value type: 1338 TRUE 1340 3.3.3. Calendar User Address 1342 Value Name: CAL-ADDRESS 1344 Purpose: This value type is used to identify properties that contain 1345 a calendar user address. 1347 Format Definition: This value type is defined by the following 1348 notation: 1350 cal-address = uri 1352 Description: The value is a URI as defined by [RFC3986] or any other 1353 IANA registered form for a URI. When used to address an Internet 1354 email transport address for a calendar user, the value MUST be a 1355 mailto URI, as defined by [RFC2368]. No additional content value 1356 encoding (i.e., BACKSLASH character encoding) is defined for this 1357 value type. 1359 Example: 1361 mailto:jane_doe@example.com 1363 3.3.4. Date 1365 Value Name: DATE 1367 Purpose: This value type is used to identify values that contain a 1368 calendar date. 1370 Format Definition: This value type is defined by the following 1371 notation: 1373 date = date-value 1375 date-value = date-fullyear date-month date-mday 1376 date-fullyear = 4DIGIT 1377 date-month = 2DIGIT ;01-12 1378 date-mday = 2DIGIT ;01-28, 01-29, 01-30, 01-31 1379 ;based on month/year 1381 Description: If the property permits, multiple "date" values are 1382 specified as a COMMA character (US-ASCII decimal 44) separated 1383 list of values. The format for the value type is expressed as the 1384 [ISO.8601.1988] complete representation, basic format for a 1385 calendar date. The textual format specifies a four-digit year, 1386 two-digit month, and two-digit day of the month. There are no 1387 separator characters between the year, month and day component 1388 text. 1390 No additional content value encoding (i.e., BACKSLASH character 1391 encoding) is defined for this value type. 1393 Example: The following represents July 14, 1997: 1395 19970714 1397 3.3.5. Date-Time 1399 Value Name: DATE-TIME 1401 Purpose: This value type is used to identify values that specify a 1402 precise calendar date and time of day. 1404 Format Definition: This value type is defined by the following 1405 notation: 1407 date-time = date "T" time ;As specified in the date and time 1408 ;value definitions 1410 Description: If the property permits, multiple "date-time" values 1411 are specified as a COMMA character (US-ASCII decimal 44) separated 1412 list of values. No additional content value encoding (i.e., 1413 BACKSLASH character encoding) is defined for this value type. 1415 The "DATE-TIME" value type is used to identify values that contain 1416 a precise calendar date and time of day. The format is based on 1417 the [ISO.8601.1988] complete representation, basic format for a 1418 calendar date and time of day. The text format is a concatenation 1419 of the "date", followed by the LATIN CAPITAL LETTER T character 1420 (US-ASCII decimal 84) time designator, followed by the "time" 1421 format. 1423 The "DATE-TIME" value type expresses time values in three forms: 1425 The form of date and time with UTC offset MUST NOT be used. For 1426 example, the following is not valid for a date-time value: 1428 19980119T230000-0800 ;Invalid time format 1430 FORM #1: DATE WITH LOCAL TIME 1432 The date with local time form is simply a date-time value that 1433 does not contain the UTC designator nor does it reference a time 1434 zone. For example, the following represents January 18, 1998, at 1435 11 PM: 1437 19980118T230000 1439 Date-time values of this type are said to be "floating" and are 1440 not bound to any time zone in particular. They are used to 1441 represent the same hour, minute, and second value regardless of 1442 which time zone is currently being observed. For example, an 1443 event can be defined that indicates that an individual will be 1444 busy from 11:00 AM to 1:00 PM every day, no matter which time zone 1445 the person is in. In these cases, a local time can be specified. 1446 The recipient of an iCalendar object with a property value 1447 consisting of a local time, without any relative time zone 1448 information, SHOULD interpret the value as being fixed to whatever 1449 time zone the "ATTENDEE" is in at any given moment. This means 1450 that two "Attendees", in different time zones, receiving the same 1451 event definition as a floating time, may be participating in the 1452 event at different actual times. Floating time SHOULD only be 1453 used where that is the reasonable behavior. 1455 In most cases, a fixed time is desired. To properly communicate a 1456 fixed time in a property value, either UTC time or local time with 1457 time zone reference MUST be specified. 1459 The use of local time in a DATE-TIME value without the "TZID" 1460 property parameter is to be interpreted as floating time, 1461 regardless of the existence of "VTIMEZONE" calendar components in 1462 the iCalendar object. 1464 FORM #2: DATE WITH UTC TIME 1466 The date with UTC time, or absolute time, is identified by a LATIN 1467 CAPITAL LETTER Z suffix character (US-ASCII decimal 90), the UTC 1468 designator, appended to the time value. For example, the 1469 following represents January 19, 1998, at 0700 UTC: 1471 19980119T070000Z 1473 The "TZID" property parameter MUST NOT be applied to DATE-TIME 1474 properties whose time values are specified in UTC. 1476 FORM #3: DATE WITH LOCAL TIME AND TIME ZONE REFERENCE 1478 The date and local time with reference to time zone information is 1479 identified by the use the "TZID" property parameter to reference 1480 the appropriate time zone definition. "TZID" is discussed in 1481 detail in Section 3.2.18. For example, the following represents 1482 2:00 A.M. in New York on Janurary 19, 1998: 1484 TZID=America/New_York:19980119T020000 1486 Example: The following represents July 14, 1997, at 1:30 PM in New 1487 York City in each of the three time formats, using the "DTSTART" 1488 property. 1490 DTSTART:19970714T133000 ; Local time 1491 DTSTART:19970714T173000Z ; UTC time 1492 DTSTART;TZID=America/New_York:19970714T133000 1493 ; Local time and time 1494 ; zone reference 1496 A time value MUST only specify the second 60 when specifying a 1497 positive "leap second" . For example: 1499 19970630T235960Z 1501 3.3.6. Duration 1503 Value Name: DURATION 1505 Purpose: This value type is used to identify properties that contain 1506 a duration of time. 1508 Format Definition: This value type is defined by the following 1509 notation: 1511 dur-value = (["+"] / "-") "P" (dur-date / dur-time / dur-week) 1513 dur-date = dur-day [dur-time] 1514 dur-time = "T" (dur-hour / dur-minute / dur-second) 1515 dur-week = 1*DIGIT "W" 1516 dur-hour = 1*DIGIT "H" [dur-minute] 1517 dur-minute = 1*DIGIT "M" [dur-second] 1518 dur-second = 1*DIGIT "S" 1519 dur-day = 1*DIGIT "D" 1521 Description: If the property permits, multiple "duration" values are 1522 specified by a COMMA character (US-ASCII decimal 44) separated 1523 list of values. The format is expressed as the [ISO.8601.1988] 1524 basic format for the duration of time. The format can represent 1525 durations in terms of weeks, days, hours, minutes, and seconds. 1526 Negative durations are typically used to schedule an alarm to 1527 trigger before an associated time (see Section 3.8.6.3). 1529 No additional content value encoding (i.e., BACKSLASH character 1530 encoding) are defined for this value type. 1532 Example: A duration of 15 days, 5 hours and 20 seconds would be: 1534 P15DT5H0M20S 1536 A duration of 7 weeks would be: 1538 P7W 1540 3.3.7. Float 1542 Value Name: FLOAT 1544 Purpose: This value type is used to identify properties that contain 1545 a real number value. 1547 Format Definition: This value type is defined by the following 1548 notation: 1550 float = (["+"] / "-") 1*DIGIT ["." 1*DIGIT] 1552 Description: If the property permits, multiple "float" values are 1553 specified by a COMMA character (US-ASCII decimal 44) separated 1554 list of values. 1556 No additional content value encoding (i.e., BACKSLASH character 1557 encoding) is defined for this value type. 1559 Example: 1561 1000000.0000001 1562 1.333 1563 -3.14 1565 3.3.8. Integer 1567 Value Name: INTEGER 1569 Purpose: This value type is used to identify properties that contain 1570 a signed integer value. 1572 Format Definition: This value type is defined by the following 1573 notation: 1575 integer = (["+"] / "-") 1*DIGIT 1577 Description: If the property permits, multiple "integer" values are 1578 specified by a COMMA character (US-ASCII decimal 44) separated 1579 list of values. The valid range for "integer" is -2147483648 to 1580 2147483647. If the sign is not specified, then the value is 1581 assumed to be positive. 1583 No additional content value encoding (i.e., BACKSLASH character 1584 encoding) is defined for this value type. 1586 Example: 1588 1234567890 1589 -1234567890 1590 +1234567890 1591 432109876 1593 3.3.9. Period of Time 1595 Value Name: PERIOD 1597 Purpose: This value type is used to identify values that contain a 1598 precise period of time. 1600 Format Definition: This value type is defined by the following 1601 notation: 1603 period = period-explicit / period-start 1605 period-explicit = date-time "/" date-time 1606 ; [ISO.8601.1988] complete representation basic format for a 1607 ; period of time consisting of a start and end. The start MUST 1608 ; be before the end. 1610 period-start = date-time "/" dur-value 1611 ; [ISO.8601.1988] complete representation basic format for a 1612 ; period of time consisting of a start and positive duration 1613 ; of time. 1615 Description: If the property permits, multiple "period" values are 1616 specified by a COMMA character (US-ASCII decimal 44) separated 1617 list of values. There are two forms of a period of time. First, 1618 a period of time is identified by its start and its end. This 1619 format is expressed as the [ISO.8601.1988] complete 1620 representation, basic format for "DATE-TIME" start of the period, 1621 followed by a SOLIDUS character (US-ASCII decimal 47), followed by 1622 the "DATE-TIME" of the end of the period. The start of the period 1623 MUST be before the end of the period. Second, a period of time 1624 can also be defined by a start and a positive duration of time. 1625 The format is expressed as the [ISO.8601.1988] complete 1626 representation, basic format for the "DATE-TIME" start of the 1627 period, followed by a SOLIDUS character (US-ASCII decimal 47), 1628 followed by the [ISO.8601.1988] basic format for "DURATION" of the 1629 period. 1631 Example: The period starting at 18:00:00 UTC, on January 1, 1997 and 1632 ending at 07:00:00 UTC on January 2, 1997 would be: 1634 19970101T180000Z/19970102T070000Z 1636 The period start at 18:00:00 on January 1, 1997 and lasting 5 1637 hours and 30 minutes would be: 1639 19970101T180000Z/PT5H30M 1641 No additional content value encoding (i.e., BACKSLASH character 1642 encoding) is defined for this value type. 1644 3.3.10. Recurrence Rule 1646 Value Name: RECUR 1648 Purpose: This value type is used to identify properties that contain 1649 a recurrence rule specification. 1651 Format Definition: This value type is defined by the following 1652 notation: 1654 recur = recur-rule-part *( ";" recur-rule-part ) 1655 ; 1656 ; The rule parts are not ordered in any 1657 ; particular sequence 1658 ; 1659 ; The FREQ rule part is REQUIRED, 1660 ; but MUST NOT occur more than once 1661 ; 1662 ; The UNTIL or COUNT rule parts are OPTIONAL, 1663 ; but they MUST NOT occur in the same 'recur' 1664 ; 1665 ; The other rule parts are OPTIONAL, 1666 ; but MUST NOT occur more than once 1668 recur-rule-part = ( "FREQ" "=" freq ) 1669 / ( "UNTIL" "=" enddate ) 1670 / ( "COUNT" "=" 1*DIGIT ) 1671 / ( "INTERVAL" "=" 1*DIGIT ) 1672 / ( "BYSECOND" "=" byseclist ) 1673 / ( "BYMINUTE" "=" byminlist ) 1674 / ( "BYHOUR" "=" byhrlist ) 1675 / ( "BYDAY" "=" bywdaylist ) 1676 / ( "BYMONTHDAY" "=" bymodaylist ) 1677 / ( "BYYEARDAY" "=" byyrdaylist ) 1678 / ( "BYWEEKNO" "=" bywknolist ) 1679 / ( "BYMONTH" "=" bymolist ) 1680 / ( "BYSETPOS" "=" bysplist ) 1681 / ( "WKST" "=" weekday ) 1683 freq = "SECONDLY" / "MINUTELY" / "HOURLY" / "DAILY" 1684 / "WEEKLY" / "MONTHLY" / "YEARLY" 1686 enddate = date / date-time ;A UTC value 1688 byseclist = ( seconds *("," seconds) ) 1690 seconds = 1*2DIGIT ;0 to 60 1692 byminlist = ( minutes *("," minutes) ) 1694 minutes = 1*2DIGIT ;0 to 59 1696 byhrlist = ( hour *("," hour) ) 1698 hour = 1*2DIGIT ;0 to 23 1700 bywdaylist = ( weekdaynum *("," weekdaynum) ) 1702 weekdaynum = [[plus / minus] ordwk] weekday 1704 plus = "+" 1706 minus = "-" 1708 ordwk = 1*2DIGIT ;1 to 53 1709 weekday = "SU" / "MO" / "TU" / "WE" / "TH" / "FR" / "SA" 1710 ;Corresponding to SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, 1711 ;FRIDAY, and SATURDAY days of the week. 1713 bymodaylist = ( monthdaynum *("," monthdaynum) ) 1715 monthdaynum = [plus / minus] ordmoday 1717 ordmoday = 1*2DIGIT ;1 to 31 1719 byyrdaylist = ( yeardaynum *("," yeardaynum) ) 1721 yeardaynum = [plus / minus] ordyrday 1723 ordyrday = 1*3DIGIT ;1 to 366 1725 bywknolist = ( weeknum *("," weeknum) ) 1727 weeknum = [plus / minus] ordwk 1729 bymolist = ( monthnum *("," monthnum) ) 1731 monthnum = 1*2DIGIT ;1 to 12 1733 bysplist = ( setposday *("," setposday) ) 1735 setposday = yeardaynum 1737 Description: This value type is a structured value consisting of a 1738 list of one or more recurrence grammar parts. Each rule part is 1739 defined by a NAME=VALUE pair. The rule parts are separated from 1740 each other by the SEMICOLON character (US-ASCII decimal 59). The 1741 rule parts are not ordered in any particular sequence. Individual 1742 rule parts MUST only be specified once. 1744 Note: Compliant applications MUST accept rule parts ordered in 1745 any sequence, but to ensure backward compatibility with 1746 applications that pre-date this revision of iCalendar the FREQ 1747 rule part MUST be the first rule part specified in a RECUR 1748 value. 1750 The FREQ rule part identifies the type of recurrence rule. This 1751 rule part MUST be specified in the recurrence rule. Valid values 1752 include SECONDLY, to specify repeating events based on an interval 1753 of a second or more; MINUTELY, to specify repeating events based 1754 on an interval of a minute or more; HOURLY, to specify repeating 1755 events based on an interval of an hour or more; DAILY, to specify 1756 repeating events based on an interval of a day or more; WEEKLY, to 1757 specify repeating events based on an interval of a week or more; 1758 MONTHLY, to specify repeating events based on an interval of a 1759 month or more; and YEARLY, to specify repeating events based on an 1760 interval of a year or more. 1762 The INTERVAL rule part contains a positive integer representing 1763 how often the recurrence rule repeats. The default value is "1", 1764 meaning every second for a SECONDLY rule, or every minute for a 1765 MINUTELY rule, every hour for an HOURLY rule, every day for a 1766 DAILY rule, every week for a WEEKLY rule, every month for a 1767 MONTHLY rule and every year for a YEARLY rule. 1769 The UNTIL rule part defines a DATE or DATE-TIME value which bounds 1770 the recurrence rule in an inclusive manner. If the value 1771 specified by UNTIL is synchronized with the specified recurrence, 1772 this DATE or DATE-TIME becomes the last instance of the 1773 recurrence. The value of the UNTIL rule part MUST have the same 1774 value type as the "DTSTART" property. If specified as a DATE-TIME 1775 value, then it MUST be specified in a UTC time format. If not 1776 present, and the COUNT rule part is also not present, the "RRULE" 1777 is considered to repeat forever. 1779 The COUNT rule part defines the number of occurrences at which to 1780 range-bound the recurrence. The "DTSTART" property value always 1781 counts as the first occurrence. 1783 The BYSECOND rule part specifies a COMMA character (US-ASCII 1784 decimal 44) separated list of seconds within a minute. Valid 1785 values are 0 to 60. The BYMINUTE rule part specifies a COMMA 1786 character (US-ASCII decimal 44) separated list of minutes within 1787 an hour. Valid values are 0 to 59. The BYHOUR rule part 1788 specifies a COMMA character (US-ASCII decimal 44) separated list 1789 of hours of the day. Valid values are 0 to 23. The BYSECOND, 1790 BYMINUTE and BYHOUR rule parts MUST NOT be specified when the 1791 associated "DTSTART" property has a DATE value type. These rule 1792 parts MUST be ignored in RECUR value that violate the above 1793 requirement (e.g., generated by applications that pre-date this 1794 revision of iCalendar). 1796 The BYDAY rule part specifies a COMMA character (US-ASCII decimal 1797 44) separated list of days of the week; SU indicates Sunday; MO 1798 indicates Monday; TU indicates Tuesday; WE indicates Wednesday; TH 1799 indicates Thursday; FR indicates Friday; SA indicates Saturday. 1801 Each BYDAY value can also be preceded by a positive (+n) or 1802 negative (-n) integer. If present, this indicates the nth 1803 occurrence of the specific day within the MONTHLY or YEARLY 1804 "RRULE". For example, within a MONTHLY rule, +1MO (or simply 1MO) 1805 represents the first Monday within the month, whereas -1MO 1806 represents the last Monday of the month. If an integer modifier 1807 is not present, it means all days of this type within the 1808 specified frequency. For example, within a MONTHLY rule, MO 1809 represents all Mondays within the month. 1811 The BYMONTHDAY rule part specifies a COMMA character (US-ASCII 1812 decimal 44) separated list of days of the month. Valid values are 1813 1 to 31 or -31 to -1. For example, -10 represents the tenth to 1814 the last day of the month. 1816 The BYYEARDAY rule part specifies a COMMA character (US-ASCII 1817 decimal 44) separated list of days of the year. Valid values are 1818 1 to 366 or -366 to -1. For example, -1 represents the last day 1819 of the year (December 31st) and -306 represents the 306th to the 1820 last day of the year (March 1st). 1822 The BYWEEKNO rule part specifies a COMMA character (US-ASCII 1823 decimal 44) separated list of ordinals specifying weeks of the 1824 year. Valid values are 1 to 53 or -53 to -1. This corresponds to 1825 weeks according to week numbering as defined in [ISO.8601.1988]. 1826 A week is defined as a seven day period, starting on the day of 1827 the week defined to be the week start (see WKST). Week number one 1828 of the calendar year is the first week which contains at least 1829 four (4) days in that calendar year. This rule part is only valid 1830 for YEARLY rules. For example, 3 represents the third week of the 1831 year. 1833 Note: Assuming a Monday week start, week 53 can only occur when 1834 Thursday is January 1 or if it is a leap year and Wednesday is 1835 January 1. 1837 The BYMONTH rule part specifies a COMMA character (US-ASCII 1838 decimal 44) separated list of months of the year. Valid values 1839 are 1 to 12. 1841 The WKST rule part specifies the day on which the workweek starts. 1842 Valid values are MO, TU, WE, TH, FR, SA and SU. This is 1843 significant when a WEEKLY "RRULE" has an interval greater than 1, 1844 and a BYDAY rule part is specified. This is also significant when 1845 in a YEARLY "RRULE" when a BYWEEKNO rule part is specified. The 1846 default value is MO. 1848 The BYSETPOS rule part specifies a COMMA character (US-ASCII 1849 decimal 44) separated list of values which corresponds to the nth 1850 occurrence within the set of events specified by the rule. Valid 1851 values are 1 to 366 or -366 to -1. It MUST only be used in 1852 conjunction with another BYxxx rule part. For example "the last 1853 work day of the month" could be represented as: 1855 FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1 1857 Each BYSETPOS value can include a positive (+n) or negative (-n) 1858 integer. If present, this indicates the nth occurrence of the 1859 specific occurrence within the set of occurences specified by the 1860 rule. 1862 Recurrence rules may generate recurrence instances with invalid 1863 date (e.g., February 30) or nonexistent local time (e.g., 1:30 AM 1864 on a day where the local time is moved forward by an hour at 1:00 1865 AM). Such recurrence instances MUST be ignored and MUST NOT be 1866 counted as part of the recurrence set. 1868 Information, not contained in the rule, necessary to determine the 1869 various recurrence instance start time and dates are derived from 1870 the Start Time ("DTSTART") component attribute. For example, 1871 "FREQ=YEARLY;BYMONTH=1" doesn't specify a specific day within the 1872 month or a time. This information would be the same as what is 1873 specified for "DTSTART". 1875 BYxxx rule parts modify the recurrence in some manner. BYxxx rule 1876 parts for a period of time which is the same or greater than the 1877 frequency generally reduce or limit the number of occurrences of 1878 the recurrence generated. For example, "FREQ=DAILY;BYMONTH=1" 1879 reduces the number of recurrence instances from all days (if 1880 BYMONTH rule part is not present) to all days in January. BYxxx 1881 rule parts for a period of time less than the frequency generally 1882 increase or expand the number of occurrences of the recurrence. 1883 For example, "FREQ=YEARLY;BYMONTH=1,2" increases the number of 1884 days within the yearly recurrence set from 1 (if BYMONTH rule part 1885 is not present) to 2. 1887 If multiple BYxxx rule parts are specified, then after evaluating 1888 the specified FREQ and INTERVAL rule parts, the BYxxx rule parts 1889 are applied to the current set of evaluated occurrences in the 1890 following order: BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY, BYDAY, 1891 BYHOUR, BYMINUTE, BYSECOND and BYSETPOS; then COUNT and UNTIL are 1892 evaluated. 1894 Here is an example of evaluating multiple BYxxx rule parts. 1896 DTSTART;TZID=America/New_York:19970105T083000 1897 RRULE:FREQ=YEARLY;INTERVAL=2;BYMONTH=1;BYDAY=SU;BYHOUR=8,9; 1898 BYMINUTE=30 1900 First, the "INTERVAL=2" would be applied to "FREQ=YEARLY" to 1901 arrive at "every other year". Then, "BYMONTH=1" would be applied 1902 to arrive at "every January, every other year". Then, "BYDAY=SU" 1903 would be applied to arrive at "every Sunday in January, every 1904 other year". Then, "BYHOUR=8,9" would be applied to arrive at 1905 "every Sunday in January at 8 AM and 9 AM, every other year". 1906 Then, "BYMINUTE=30" would be applied to arrive at "every Sunday in 1907 January at 8:30 AM and 9:30 AM, every other year". Then, lacking 1908 information from "RRULE", the second is derived from "DTSTART", to 1909 end up in "every Sunday in January at 8:30:00 AM and 9:30:00 AM, 1910 every other year". Similarly, if the BYMINUTE, BYHOUR, BYDAY, 1911 BYMONTHDAY or BYMONTH rule part were missing, the appropriate 1912 minute, hour, day or month would have been retrieved from the 1913 "DTSTART" property. 1915 No additional content value encoding (i.e., BACKSLASH character 1916 encoding) is defined for this value type. 1918 Example: The following is a rule which specifies 10 occurences which 1919 occur every other day: 1921 FREQ=DAILY;COUNT=10;INTERVAL=2 1923 There are other examples specified in Section 3.8.5.3. 1925 3.3.11. Text 1927 Value Name: TEXT 1929 Purpose: This value type is used to identify values that contain 1930 human readable text. 1932 Format Definition: This value type is defined by the following 1933 notation. 1935 text = *(TSAFE-CHAR / ":" / DQUOTE / ESCAPED-CHAR) 1936 ; Folded according to description above 1938 ESCAPED-CHAR = ("\\" / "\;" / "\," / "\N" / "\n") 1939 ; \\ encodes \, \N or \n encodes newline 1940 ; \; encodes ;, \, encodes , 1942 TSAFE-CHAR = %x20-21 / %x23-2B / %x2D-39 / %x3C-5B / 1943 %x5D-7E / NON-US-ASCII 1944 ; Any character except CTLs not needed by the current 1945 ; character set, DQUOTE, ";", ":", "\", "," 1947 Description: If the property permits, multiple TEXT values are 1948 specified by a COMMA character (US-ASCII decimal 44) separated 1949 list of values. 1951 The language in which the text is represented can be controlled by 1952 the "LANGUAGE" property parameter. 1954 An intentional formatted text line break MUST only be included in 1955 a "TEXT" property value by representing the line break with the 1956 character sequence of BACKSLASH (US-ASCII decimal 92), followed by 1957 a LATIN SMALL LETTER N (US-ASCII decimal 110) or a LATIN CAPITAL 1958 LETTER N (US-ASCII decimal 78), that is "\n" or "\N". 1960 The "TEXT" property values may also contain special characters 1961 that are used to signify delimiters, such as a COMMA character for 1962 lists of values or a SEMICOLON character for structured values. 1963 In order to support the inclusion of these special characters in 1964 "TEXT" property values, they MUST be escaped with a BACKSLASH 1965 character. A BACKSLASH character (US-ASCII decimal 92) in a 1966 "TEXT" property value MUST be escaped with another BACKSLASH 1967 character. A COMMA character in a "TEXT" property value MUST be 1968 escaped with a BACKSLASH character (US-ASCII decimal 92). A 1969 SEMICOLON character in a "TEXT" property value MUST be escaped 1970 with a BACKSLASH character (US-ASCII decimal 92). However, a 1971 COLON character in a "TEXT" property value SHALL NOT be escaped 1972 with a BACKSLASH character. 1974 Example: A multiple line value of: 1976 Project XYZ Final Review 1977 Conference Room - 3B 1978 Come Prepared. 1980 would be represented as: 1982 Project XYZ Final Review\nConference Room - 3B\nCome Prepared. 1984 3.3.12. Time 1986 Value Name: TIME 1988 Purpose: This value type is used to identify values that contain a 1989 time of day. 1991 Format Definition: This value type is defined by the following 1992 notation: 1994 time = time-hour time-minute time-second [time-utc] 1996 time-hour = 2DIGIT ;00-23 1997 time-minute = 2DIGIT ;00-59 1998 time-second = 2DIGIT ;00-60 1999 ;The "60" value is used to account for positive "leap" seconds. 2001 time-utc = "Z" 2003 Description: If the property permits, multiple "time" values are 2004 specified by a COMMA character (US-ASCII decimal 44) separated 2005 list of values. No additional content value encoding (i.e., 2006 BACKSLASH character encoding) is defined for this value type. 2008 The "TIME" value type is used to identify values that contain a 2009 time of day. The format is based on the [ISO.8601.1988] complete 2010 representation, basic format for a time of day. The text format 2011 consists of a two-digit 24-hour of the day (i.e., values 00-23), 2012 two-digit minute in the hour (i.e., values 00-59), and two-digit 2013 seconds in the minute (i.e., values 00-60). The seconds value of 2014 60 MUST only be used to account for positive "leap" seconds. 2015 Fractions of a second are not supported by this format. 2017 In parallel to the "DATE-TIME" definition above, the "TIME" value 2018 type expresses time values in three forms: 2020 The form of time with UTC offset MUST NOT be used. For example, 2021 the following is not valid for a time value: 2023 230000-0800 ;Invalid time format 2025 FORM #1 LOCAL TIME 2027 The local time form is simply a time value that does not contain 2028 the UTC designator nor does it reference a time zone. For 2029 example, 11:00 PM: 2031 230000 2033 Time values of this type are said to be "floating" and are not 2034 bound to any time zone in particular. They are used to represent 2035 the same hour, minute, and second value regardless of which time 2036 zone is currently being observed. For example, an event can be 2037 defined that indicates that an individual will be busy from 11:00 2038 AM to 1:00 PM every day, no matter which time zone the person is 2039 in. In these cases, a local time can be specified. The recipient 2040 of an iCalendar object with a property value consisting of a local 2041 time, without any relative time zone information, SHOULD interpret 2042 the value as being fixed to whatever time zone the "ATTENDEE" is 2043 in at any given moment. This means that two "Attendees", may 2044 participate in the same event at different UTC times; floating 2045 time SHOULD only be used where that is reasonable behavior. 2047 In most cases, a fixed time is desired. To properly communicate a 2048 fixed time in a property value, either UTC time or local time with 2049 time zone reference MUST be specified. 2051 The use of local time in a TIME value without the "TZID" property 2052 parameter is to be interpreted as a local time value, regardless 2053 of the existence of "VTIMEZONE" calendar components in the 2054 iCalendar object. 2056 FORM #2: UTC TIME 2058 UTC time, or absolute time, is identified by a LATIN CAPITAL 2059 LETTER Z suffix character (US-ASCII decimal 90), the UTC 2060 designator, appended to the time value. For example, the 2061 following represents 07:00 AM UTC: 2063 070000Z 2065 The "TZID" property parameter MUST NOT be applied to TIME 2066 properties whose time values are specified in UTC. 2068 FORM #3: LOCAL TIME AND TIME ZONE REFERENCE 2070 The local time with reference to time zone information form is 2071 identified by the use the "TZID" property parameter to reference 2072 the appropriate time zone definition. "TZID" is discussed in 2073 detail in Section 3.2.18. 2075 Example: The following represents 8:30 AM in New York in Winter, 2076 five hours behind UTC, in each of the three formats : 2078 083000 2079 133000Z 2081 TZID=America/New_York:083000 2083 3.3.13. URI 2085 Value Name: URI 2086 Purpose: This value type is used to identify values that contain a 2087 uniform resource identifier (URI) type of reference to the 2088 property value. 2090 Format Definition: This value type is defined by the following 2091 notation: 2093 uri = 2095 Description: This value type might be used to reference binary 2096 information, for values that are large, or otherwise undesirable 2097 to include directly in the iCalendar object. 2099 Property values with this value type MUST follow the generic URI 2100 syntax defined in [RFC3986]. 2102 When a property parameter value is a URI value type, the URI MUST 2103 be specified as a quoted-string value. 2105 No additional content value encoding (i.e., BACKSLASH character 2106 encoding) is defined for this value type. 2108 Example: The following is a URI for a network file: 2110 http://example.com/my-report.txt 2112 3.3.14. UTC Offset 2114 Value Name: UTC-OFFSET 2116 Purpose: This value type is used to identify properties that contain 2117 an offset from UTC to local time. 2119 Format Definition: This value type is defined by the following 2120 notation: 2122 utc-offset = time-numzone 2124 time-numzone = ("+" / "-") time-hour time-minute [time-second] 2126 Description: The PLUS SIGN (US-ASCII decimal 43) character MUST be 2127 specified for positive UTC offsets (i.e., ahead of UTC). The 2128 HYPHEN-MINUS character (US-ASCII decimal 45) MUST be specified for 2129 negative UTC offsets (i.e., behind of UTC). The value of "-0000" 2130 and "-000000" are not allowed. The time-second, if present, MUST 2131 NOT be 60; if absent, it defaults to zero. 2133 No additional content value encoding (i.e., BACKSLASH character 2134 encoding) is defined for this value type. 2136 Example: The following UTC offsets are given for standard time for 2137 New York (five hours behind UTC) and Geneva (one hour ahead of 2138 UTC): 2140 -0500 2142 +0100 2144 3.4. iCalendar Object 2146 The Calendaring and Scheduling Core Object is a collection of 2147 calendaring and scheduling information. Typically, this information 2148 will consist of an iCalendar stream with a single iCalendar object. 2149 However, multiple iCalendar objects can be sequentially grouped 2150 together in an iCalendar stream. The first line and last line of the 2151 iCalendar object MUST contain a pair of iCalendar object delimiter 2152 strings. The syntax for an iCalendar stream is as follows: 2154 icalstream = 1*icalobject 2156 icalobject = "BEGIN" ":" "VCALENDAR" CRLF 2157 icalbody 2158 "END" ":" "VCALENDAR" CRLF 2160 The following is a simple example of an iCalendar object: 2162 BEGIN:VCALENDAR 2163 VERSION:2.0 2164 PRODID:-//hacksw/handcal//NONSGML v1.0//EN 2165 BEGIN:VEVENT 2166 UID:19970610T172345Z-AF23B2@example.com 2167 DTSTAMP:19970610T172345Z 2168 DTSTART:19970714T170000Z 2169 DTEND:19970715T035959Z 2170 SUMMARY:Bastille Day Party 2171 END:VEVENT 2172 END:VCALENDAR 2174 3.5. Property 2176 A property is the definition of an individual attribute describing a 2177 calendar object or a calendar component. A property takes the form 2178 defined by the "contentline" notation defined in Section 3.1. 2180 The following is an example of a property: 2182 DTSTART:19960415T133000Z 2184 This memo imposes no ordering of properties within an iCalendar 2185 object. 2187 Property names, parameter names and enumerated parameter values are 2188 case insensitive. For example, the property name "DUE" is the same 2189 as "due" and "Due", DTSTART;TZID=America/New_York:19980714T120000 is 2190 the same as DtStart;TzID=America/New_York:19980714T120000. 2192 3.6. Calendar Components 2194 The body of the iCalendar object consists of a sequence of calendar 2195 properties and one or more calendar components. The calendar 2196 properties are attributes that apply to the calendar object as a 2197 whole. The calendar components are collections of properties that 2198 express a particular calendar semantic. For example, the calendar 2199 component can specify an event, a to-do, a journal entry, time zone 2200 information, free/busy time information, or an alarm. 2202 The body of the iCalendar object is defined by the following 2203 notation: 2205 icalbody = calprops component 2207 calprops = *( 2209 ; the following are REQUIRED, 2210 ; but MUST NOT occur more than once 2212 prodid / version / 2214 ; the following are OPTIONAL, 2215 ; but MUST NOT occur more than once 2217 calscale / method / 2219 ; the following are OPTIONAL, 2220 ; and MAY occur more than once 2222 x-prop / iana-prop 2223 ) 2225 component = 1*(eventc / todoc / journalc / freebusyc / 2226 timezonec / iana-comp / x-comp) 2228 iana-comp = "BEGIN" ":" iana-token CRLF 2229 1*contentline 2230 "END" ":" iana-token CRLF 2232 x-comp = "BEGIN" ":" x-name CRLF 2233 1*contentline 2234 "END" ":" x-name CRLF 2236 An iCalendar object MUST include the "PRODID" and "VERSION" calendar 2237 properties. In addition, it MUST include at least one calendar 2238 component. Special forms of iCalendar objects are possible to 2239 publish just busy time (i.e., only a "VFREEBUSY" calendar component) 2240 or time zone (i.e., only a "VTIMEZONE" calendar component) 2241 information. In addition, a complex iCalendar object that is used to 2242 capture a complete snapshot of the contents of a calendar is possible 2243 (e.g., composite of many different calendar components). More 2244 commonly, an iCalendar object will consist of just a single "VEVENT", 2245 "VTODO" or "VJOURNAL" calendar component. 2247 3.6.1. Event Component 2248 Component Name: VEVENT 2250 Purpose: Provide a grouping of component properties that describe an 2251 event. 2253 Format Definition: A "VEVENT" calendar component is defined by the 2254 following notation: 2256 eventc = "BEGIN" ":" "VEVENT" CRLF 2257 eventprop *alarmc 2258 "END" ":" "VEVENT" CRLF 2260 eventprop = *( 2262 ; the following are REQUIRED, 2263 ; but MUST NOT occur more than once 2265 dtstamp / dtstart / uid / 2267 ; the following are OPTIONAL, 2268 ; but MUST NOT occur more than once 2270 class / created / description / geo / 2271 last-mod / location / organizer / priority / 2272 seq / status / summary / transp / 2273 url / recurid / 2275 ; the following is OPTIONAL, 2276 ; but SHOULD NOT occur more than once 2278 rrule / 2280 ; either 'dtend' or 'duration' MAY appear in 2281 ; a 'eventprop', but 'dtend' and 'duration' 2282 ; MUST NOT occur in the same 'eventprop' 2284 dtend / duration / 2286 ; the following are OPTIONAL, 2287 ; and MAY occur more than once 2289 attach / attendee / categories / comment / 2290 contact / exdate / rstatus / related / 2291 resources / rdate / x-prop / iana-prop 2293 ) 2295 Description: A "VEVENT" calendar component is a grouping of 2296 component properties, and possibly including "VALARM" calendar 2297 components, that represents a scheduled amount of time on a 2298 calendar. For example, it can be an activity; such as a one-hour 2299 long, department meeting from 8:00 AM to 9:00 AM, tomorrow. 2300 Generally, an event will take up time on an individual calendar. 2301 Hence, the event will appear as an opaque interval in a search for 2302 busy time. Alternately, the event can have its Time Transparency 2303 set to "TRANSPARENT" in order to prevent blocking of the event in 2304 searches for busy time. 2306 The "VEVENT" is also the calendar component used to specify an 2307 anniversary or daily reminder within a calendar. These events 2308 have a DATE value type for the "DTSTART" property instead of the 2309 default value type of DATE-TIME. If such a "VEVENT" has a "DTEND" 2310 property, it MUST be specified as a DATE value also. The 2311 anniversary type of "VEVENT" can span more than one date (i.e., 2312 "DTEND" property value is set to a calendar date after the 2313 "DTSTART" property value). If such a "VEVENT" has a "DURATION" 2314 property, it MUST be specified as a "dur-day" or "dur-week" value. 2316 The "DTSTART" property for a "VEVENT" specifies the inclusive 2317 start of the event. For recurring events, it also specifies the 2318 very first instance in the recurrence set. The "DTEND" property 2319 for a "VEVENT" calendar component specifies the non-inclusive end 2320 of the event. For cases where a "VEVENT" calendar component 2321 specifies a "DTSTART" property with a DATE value type but no 2322 "DTEND" nor DURATION property, the event's duration is taken to be 2323 one day. For cases where a "VEVENT" calendar component specifies 2324 a "DTSTART" property with a DATE-TIME value type but no "DTEND" 2325 property, the event ends on the same calendar date and time of day 2326 specified by the "DTSTART" property. 2328 The "VEVENT" calendar component cannot be nested within another 2329 calendar component. However, "VEVENT" calendar components can be 2330 related to each other or to a "VTODO" or to a "VJOURNAL" calendar 2331 component with the "RELATED-TO" property. 2333 Example: The following is an example of the "VEVENT" calendar 2334 component used to represent a meeting that will also be opaque to 2335 searches for busy time: 2337 BEGIN:VEVENT 2338 UID:19970901T130000Z-123401@example.com 2339 DTSTAMP:19970901T130000Z 2340 DTSTART:19970903T163000Z 2341 DTEND:19970903T190000Z 2342 SUMMARY:Annual Employee Review 2343 CLASS:PRIVATE 2344 CATEGORIES:BUSINESS,HUMAN RESOURCES 2345 END:VEVENT 2347 The following is an example of the "VEVENT" calendar component 2348 used to represent a reminder that will not be opaque, but rather 2349 transparent, to searches for busy time: 2351 BEGIN:VEVENT 2352 UID:19970901T130000Z-123402@example.com 2353 DTSTAMP:19970901T130000Z 2354 DTSTART:19970401T163000Z 2355 DTEND:19970402T010000Z 2356 SUMMARY:Laurel is in sensitivity awareness class. 2357 CLASS:PUBLIC 2358 CATEGORIES:BUSINESS,HUMAN RESOURCES 2359 TRANSP:TRANSPARENT 2360 END:VEVENT 2362 The following is an example of the "VEVENT" calendar component 2363 used to represent an anniversary that will occur annually. 2365 BEGIN:VEVENT 2366 UID:19970901T130000Z-123403@example.com 2367 DTSTAMP:19970901T130000Z 2368 DTSTART;VALUE=DATE:19971102 2369 SUMMARY:Our Blissful Anniversary 2370 TRANSP:TRANSPARENT 2371 CLASS:CONFIDENTIAL 2372 CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION 2373 RRULE:FREQ=YEARLY 2374 END:VEVENT 2376 3.6.2. To-do Component 2378 Component Name: VTODO 2380 Purpose: Provide a grouping of calendar properties that describe a 2381 to-do. 2383 Format Definition: A "VTODO" calendar component is defined by the 2384 following notation: 2386 todoc = "BEGIN" ":" "VTODO" CRLF 2387 todoprop *alarmc 2388 "END" ":" "VTODO" CRLF 2390 todoprop = *( 2392 ; the following are REQUIRED, 2393 ; but MUST NOT occur more than once 2395 dtstamp / uid / 2397 ; the following are OPTIONAL, 2398 ; but MUST NOT occur more than once 2400 class / completed / created / description / 2401 dtstart / geo / last-mod / location / organizer / 2402 percent / priority / recurid / seq / status / 2403 summary / url / 2405 ; the following is OPTIONAL, 2406 ; but SHOULD NOT occur more than once 2408 rrule / 2410 ; either 'due' or 'duration' MAY appear in 2411 ; a 'todoprop', but 'due' and 'duration' 2412 ; MUST NOT occur in the same 'todoprop'. 2413 ; If 'duration' appear in a 'todoprop', 2414 ; then 'dtstart' MUST also appear in 2415 ' the same 'todoprop'. 2417 due / duration / 2419 ; the following are OPTIONAL, 2420 ; and MAY occur more than once 2422 attach / attendee / categories / comment / contact / 2423 exdate / rstatus / related / resources / 2424 rdate / x-prop / iana-prop 2426 ) 2428 Description: A "VTODO" calendar component is a grouping of component 2429 properties and possibly "VALARM" calendar components that 2430 represent an action-item or assignment. For example, it can be 2431 used to represent an item of work assigned to an individual; such 2432 as "turn in travel expense today". 2434 The "VTODO" calendar component cannot be nested within another 2435 calendar component. However, "VTODO" calendar components can be 2436 related to each other or to a "VEVENT" or to a "VJOURNAL" calendar 2437 component with the "RELATED-TO" property. 2439 A "VTODO" calendar component without the "DTSTART" and "DUE" (or 2440 "DURATION") properties specifies a to-do that will be associated 2441 with each successive calendar date, until it is completed. 2443 Example: The following is an example of a "VTODO" calendar 2444 component: 2446 BEGIN:VTODO 2447 UID:19970901T130000Z-123404@example.com 2448 DTSTAMP:19970901T130000Z 2449 DTSTART:19970415T133000Z 2450 DUE:19970416T045959Z 2451 SUMMARY:1996 Income Tax Preparation 2452 CLASS:CONFIDENTIAL 2453 CATEGORIES:FAMILY,FINANCE 2454 PRIORITY:1 2455 STATUS:NEEDS-ACTION 2456 END:VTODO 2458 3.6.3. Journal Component 2460 Component Name: VJOURNAL 2462 Purpose: Provide a grouping of component properties that describe a 2463 journal entry. 2465 Format Definition: A "VJOURNAL" calendar component is defined by the 2466 following notation: 2468 journalc = "BEGIN" ":" "VJOURNAL" CRLF 2469 jourprop 2470 "END" ":" "VJOURNAL" CRLF 2472 jourprop = *( 2474 ; the following are REQUIRED, 2475 ; but MUST NOT occur more than once 2477 dtstamp / uid / 2479 ; the following are OPTIONAL, 2480 ; but MUST NOT occur more than once 2482 class / created / dtstart / 2483 last-mod / organizer / recurid / seq / 2484 status / summary / url / 2486 ; the following is OPTIONAL, 2487 ; but SHOULD NOT occur more than once 2489 rrule / 2491 ; the following are OPTIONAL, 2492 ; and MAY occur more than once 2494 attach / attendee / categories / comment / 2495 contact / description / exdate / related / rdate / 2496 rstatus / x-prop / iana-prop 2497 ) 2499 Description: A "VJOURNAL" calendar component is a grouping of 2500 component properties that represent one or more descriptive text 2501 notes associated with a particular calendar date. The "DTSTART" 2502 property is used to specify the calendar date that the journal 2503 entry is associated with. Generally, it will have a DATE value 2504 data type, but it can also be used to specify a DATE-TIME value 2505 data type. Examples of a journal entry include a daily record of 2506 a legislative body or a journal entry of individual telephone 2507 contacts for the day or an ordered list of accomplishments for the 2508 day. The "VJOURNAL" calendar component can also be used to 2509 associate a document with a calendar date. 2511 The "VJOURNAL" calendar component does not take up time on a 2512 calendar. Hence, it does not play a role in free or busy time 2513 searches -- it is as though it has a time transparency value of 2514 TRANSPARENT. It is transparent to any such searches. 2516 The "VJOURNAL" calendar component cannot be nested within another 2517 calendar component. However, "VJOURNAL" calendar components can 2518 be related to each other or to a "VEVENT" or to a "VTODO" calendar 2519 component, with the "RELATED-TO" property. 2521 Example: The following is an example of the "VJOURNAL" calendar 2522 component: 2524 BEGIN:VJOURNAL 2525 UID:19970901T130000Z-123405@example.com 2526 DTSTAMP:19970901T130000Z 2527 DTSTART;VALUE=DATE:19970317 2528 SUMMARY:Staff meeting minutes 2529 DESCRIPTION:1. Staff meeting: Participants include Joe\, Lisa 2530 and Bob. Aurora project plans were reviewed. There is currentl 2531 y no budget reserves for this project. Lisa will escalate to 2532 management. Next meeting on Tuesday.\n 2533 2. Telephone Conference: ABC Corp. sales representative called 2534 to discuss new printer. Promised to get us a demo by Friday.\n 2535 3. Henry Miller (Handsoff Insurance): Car was totaled by tree. 2536 Is looking into a loaner car. 555-2323 (tel). 2537 END:VJOURNAL 2539 3.6.4. Free/Busy Component 2541 Component Name: VFREEBUSY 2543 Purpose: Provide a grouping of component properties that describe 2544 either a request for free/busy time, describe a response to a 2545 request for free/busy time or describe a published set of busy 2546 time. 2548 Format Definition: A "VFREEBUSY" calendar component is defined by 2549 the following notation: 2551 freebusyc = "BEGIN" ":" "VFREEBUSY" CRLF 2552 fbprop 2553 "END" ":" "VFREEBUSY" CRLF 2555 fbprop = *( 2557 ; the following are REQUIRED, 2558 ; but MUST NOT occur more than once 2560 dtstamp / uid / 2562 ; the following are OPTIONAL, 2563 ; but MUST NOT occur more than once 2565 contact / dtstart / dtend / duration / dtstamp / 2566 organizer / uid / url / 2568 ; the following are OPTIONAL, 2569 ; and MAY occur more than once 2571 attendee / comment / freebusy / rstatus / x-prop / 2572 iana-prop 2573 ) 2575 Description: A "VFREEBUSY" calendar component is a grouping of 2576 component properties that represents either a request for, a reply 2577 to a request for free or busy time information or a published set 2578 of busy time information. 2580 When used to request free/busy time information, the "ATTENDEE" 2581 property specifies the calendar users whose free/busy time is 2582 being requested; the "ORGANIZER" property specifies the calendar 2583 user who is requesting the free/busy time; the "DTSTART" and 2584 "DTEND" properties specify the window of time for which the free/ 2585 busy time is being requested; the "UID" and "DTSTAMP" properties 2586 are specified to assist in proper sequencing of multiple free/busy 2587 time requests. 2589 When used to reply to a request for free/busy time, the "ATTENDEE" 2590 property specifies the calendar user responding to the free/busy 2591 time request; the "ORGANIZER" property specifies the calendar user 2592 that originally requested the free/busy time; the "FREEBUSY" 2593 property specifies the free/busy time information (if it exists); 2594 and the "UID" and "DTSTAMP" properties are specified to assist in 2595 proper sequencing of multiple free/busy time replies. 2597 When used to publish busy time, the "ORGANIZER" property specifies 2598 the calendar user associated with the published busy time; the 2599 "DTSTART" and "DTEND" properties specify an inclusive time window 2600 that surrounds the busy time information; the "FREEBUSY" property 2601 specifies the published busy time information; and the "DTSTAMP" 2602 property specifies the date/time that iCalendar object was 2603 created. 2605 The "VFREEBUSY" calendar component cannot be nested within another 2606 calendar component. Multiple "VFREEBUSY" calendar components can 2607 be specified within an iCalendar object. This permits the 2608 grouping of Free/Busy information into logical collections, such 2609 as monthly groups of busy time information. 2611 The "VFREEBUSY" calendar component is intended for use in 2612 iCalendar object methods involving requests for free time, 2613 requests for busy time, requests for both free and busy, and the 2614 associated replies. 2616 Free/Busy information is represented with the "FREEBUSY" property. 2617 This property provides a terse representation of time periods. 2618 One or more "FREEBUSY" properties can be specified in the 2619 "VFREEBUSY" calendar component. 2621 When present in a "VFREEBUSY" calendar component, the "DTSTART" 2622 and "DTEND" properties SHOULD be specified prior to any "FREEBUSY" 2623 properties. In a free time request, these properties can be used 2624 in combination with the "DURATION" property to represent a request 2625 for a duration of free time within a specified window of time. 2627 The recurrence properties ("RRULE", "RDATE", "EXDATE") are not 2628 permitted within a "VFREEBUSY" calendar component. Any recurring 2629 events are resolved into their individual busy time periods using 2630 the "FREEBUSY" property. 2632 Example: The following is an example of a "VFREEBUSY" calendar 2633 component used to request free or busy time information: 2635 BEGIN:VFREEBUSY 2636 UID:19970901T082949Z-FA43EF@example.com 2637 ORGANIZER:mailto:jane_doe@example.com 2638 ATTENDEE:mailto:john_public@example.com 2639 DTSTART:19971015T050000Z 2640 DTEND:19971016T050000Z 2641 DTSTAMP:19970901T083000Z 2642 END:VFREEBUSY 2644 The following is an example of a "VFREEBUSY" calendar component 2645 used to reply to the request with busy time information: 2647 BEGIN:VFREEBUSY 2648 UID:19970901T095957Z-76A912@example.com 2649 ORGANIZER:mailto:jane_doe@example.com 2650 ATTENDEE:mailto:john_public@example.com 2651 DTSTAMP:19970901T100000Z 2652 FREEBUSY:19971015T050000Z/PT8H30M, 2653 19971015T160000Z/PT5H30M,19971015T223000Z/PT6H30M 2654 URL:http://example.com/pub/busy/jpublic-01.ifb 2655 COMMENT:This iCalendar file contains busy time information for 2656 the next three months. 2657 END:VFREEBUSY 2659 The following is an example of a "VFREEBUSY" calendar component 2660 used to publish busy time information. 2662 BEGIN:VFREEBUSY 2663 UID:19970901T115957Z-76A912@example.com 2664 DTSTAMP:19970901T120000Z 2665 ORGANIZER:jsmith@example.com 2666 DTSTART:19980313T141711Z 2667 DTEND:19980410T141711Z 2668 FREEBUSY:19980314T233000Z/19980315T003000Z 2669 FREEBUSY:19980316T153000Z/19980316T163000Z 2670 FREEBUSY:19980318T030000Z/19980318T040000Z 2671 URL:http://www.example.com/calendar/busytime/jsmith.ifb 2672 END:VFREEBUSY 2674 3.6.5. Time Zone Component 2676 Component Name: VTIMEZONE 2678 Purpose: Provide a grouping of component properties that defines a 2679 time zone. 2681 Format Definition: A "VTIMEZONE" calendar component is defined by 2682 the following notation: 2684 timezonec = "BEGIN" ":" "VTIMEZONE" CRLF 2685 *( 2687 ; 'tzid' is REQUIRED, but MUST NOT occur more 2688 ; than once 2690 tzid / 2691 ; 'last-mod' and 'tzurl' are OPTIONAL, 2692 ; but MUST NOT occur more than once 2694 last-mod / tzurl / 2696 ; one of 'standardc' or 'daylightc' MUST occur 2697 ; and each MAY occur more than once. 2699 standardc / daylightc / 2701 ; the following are OPTIONAL, 2702 ; and MAY occur more than once 2704 x-prop / iana-prop 2706 ) 2708 "END" ":" "VTIMEZONE" CRLF 2710 standardc = "BEGIN" ":" "STANDARD" CRLF 2711 tzprop 2712 "END" ":" "STANDARD" CRLF 2714 daylightc = "BEGIN" ":" "DAYLIGHT" CRLF 2715 tzprop 2716 "END" ":" "DAYLIGHT" CRLF 2718 tzprop = *( 2720 ; the following are REQUIRED, 2721 ; but MUST NOT occur more than once 2723 dtstart / tzoffsetto / tzoffsetfrom / 2725 ; the following is OPTIONAL, 2726 ; but SHOULD NOT occur more than once 2728 rrule / 2730 ; the following are OPTIONAL, 2731 ; and MAY occur more than once 2733 comment / rdate / tzname / x-prop / iana-prop 2735 ) 2737 Description: A time zone is unambiguously defined by the set of time 2738 measurement rules determined by the governing body for a given 2739 geographic area. These rules describe at a minimum the base 2740 offset from UTC for the time zone, often referred to as the 2741 Standard Time offset. Many locations adjust their Standard Time 2742 forward or backward by one hour, in order to accommodate seasonal 2743 changes in number of daylight hours, often referred to as Daylight 2744 Saving Time. Some locations adjust their time by a fraction of an 2745 hour. Standard Time is also known as Winter Time. Daylight 2746 Saving Time is also known as Advanced Time, Summer Time, or Legal 2747 Time in certain countries. The following table shows the changes 2748 in time zone rules in effect for New York City starting from 1967. 2749 Each line represents a description or rule for a particular 2750 observance. 2752 Effective Observance Rule 2754 +-----------+--------------------------+--------+--------------+ 2755 | Date | (Date/Time) | Offset | Abbreviation | 2756 +-----------+--------------------------+--------+--------------+ 2757 | 1967-2006 | last Sun in Oct, 02:00 | -0500 | EST | 2758 | 1967-1973 | last Sun in Apr, 02:00 | -0400 | EDT | 2759 | 1974-1974 | Jan 6, 02:00 | -0400 | EDT | 2760 | 1975-1975 | Feb 23, 02:00 | -0400 | EDT | 2761 | 1976-1986 | last Sun in Apr, 02:00 | -0400 | EDT | 2762 | 1987-2006 | first Sun in Apr, 02:00 | -0400 | EDT | 2763 | 2007-* | first Sun in Nov, 02:00 | -0500 | EST | 2764 | 2007-* | second Sun in Mar, 02:00 | -0400 | EDT | 2765 +-----------+--------------------------+--------+--------------+ 2767 Note: The specification of a global time zone registry is not 2768 addressed by this document and is left for future study. 2769 However, implementers may find the TZ database [TZDB] a useful 2770 reference. It is an informal, public-domain collection of time 2771 zone information, which is currently being maintained by 2772 volunteer Internet participants, and is used in several 2773 operating systems. This database contains current and 2774 historical time zone information for a wide variety of 2775 locations around the globe; it provides a time zone identifier 2776 for every unique time zone rule set in actual use since 1970, 2777 with historical data going back to the introduction of standard 2778 time. 2780 Interoperability between two calendaring and scheduling 2781 applications, especially for recurring events, to-dos or journal 2782 entries, is dependent on the ability to capture and convey date 2783 and time information in an unambiguous format. The specification 2784 of current time zone information is integral to this behavior. 2786 If present, the "VTIMEZONE" calendar component defines the set of 2787 Standard Time and Daylight Saving Time observances (or rules) for 2788 a particular time zone for a given interval of time. The 2789 "VTIMEZONE" calendar component cannot be nested within other 2790 calendar components. Multiple "VTIMEZONE" calendar components can 2791 exist in an iCalendar object. In this situation, each "VTIMEZONE" 2792 MUST represent a unique time zone definition. This is necessary 2793 for some classes of events, such as airline flights, that start in 2794 one time zone and end in another. 2796 The "VTIMEZONE" calendar component MUST include the "TZID" 2797 property and at least one definition of a "STANDARD" or "DAYLIGHT" 2798 sub-component. The "STANDARD" or "DAYLIGHT" subcomponent MUST 2799 include the "DTSTART", "TZOFFSETFROM" and "TZOFFSETTO" properties. 2801 An individual "VTIMEZONE" calendar component MUST be specified for 2802 each unique "TZID" parameter value specified in the iCalendar 2803 object. In addition, a "VTIMEZONE" calendar component, referred 2804 to by a recurring calendar component, MUST provide valid time zone 2805 information for all recurrence instances. 2807 Each "VTIMEZONE" calendar component consists of a collection of 2808 one or more sub-components that describe the rule for a particular 2809 observance (either a Standard Time or a Daylight Saving Time 2810 observance). The "STANDARD" sub-component consists of a 2811 collection of properties that describe Standard Time. The 2812 "DAYLIGHT" sub-component consists of a collection of properties 2813 that describe Daylight Saving Time. In general this collection of 2814 properties consists of: 2816 * the first onset date-time for the observance; 2818 * the last onset date-time for the observance, if a last onset is 2819 known; 2821 * the offset to be applied for the observance; 2823 * a rule that describes the day and time when the observance 2824 takes effect; 2826 * an optional name for the observance. 2828 For a given time zone, there may be multiple unique definitions of 2829 the observances over a period of time. Each observance is 2830 described using either a "STANDARD" or "DAYLIGHT" sub-component. 2831 The collection of these sub-components is used to describe the 2832 time zone for a given period of time. The offset to apply at any 2833 given time is found by locating the observance that has the last 2834 onset date and time before the time in question, and using the 2835 offset value from that observance. 2837 The top-level properties in a "VTIMEZONE" calendar component are: 2839 The mandatory "TZID" property is a text value that uniquely 2840 identifies the "VTIMEZONE" calendar component within the scope of 2841 an iCalendar object. 2843 The optional "LAST-MODIFIED" property is a UTC value that 2844 specifies the date and time that this time zone definition was 2845 last updated. 2847 The optional "TZURL" property is a url value that points to a 2848 published "VTIMEZONE" definition. "TZURL" SHOULD refer to a 2849 resource that is accessible by anyone who might need to interpret 2850 the object. This SHOULD NOT normally be a "file" URL or other URL 2851 that is not widely-accessible. 2853 The collection of properties that are used to define the 2854 "STANDARD" and "DAYLIGHT" sub-components include: 2856 The mandatory "DTSTART" property gives the effective onset date 2857 and local time for the time zone sub-component definition. 2858 "DTSTART" in this usage MUST be specified as a local DATE-TIME 2859 value. 2861 The mandatory "TZOFFSETFROM" property gives the UTC offset which 2862 is in use when the onset of this time zone observance begins. 2863 "TZOFFSETFROM" is combined with "DTSTART" to define the effective 2864 onset for the time zone sub-component definition. For example, 2865 the following represents the time at which the observance of 2866 Standard Time took effect in Fall 1967 for New York City: 2868 DTSTART:19671029T020000 2870 TZOFFSETFROM:-0400 2872 The mandatory "TZOFFSETTO" property gives the UTC offset for the 2873 time zone sub-component (Standard Time or Daylight Saving Time) 2874 when this observance is in use. 2876 The optional "TZNAME" property is the customary name for the time 2877 zone. It may be specified multiple times, to allow for specifying 2878 multiple language variants of the time zone names. This could be 2879 used for displaying dates. 2881 If specified, the onset for the observance defined by the time 2882 zone sub-component is defined by either the "RRULE" or "RDATE" 2883 property. If neither is specified, only one sub-component can be 2884 specified in the "VTIMEZONE" calendar component and it is assumed 2885 that the single observance specified is always in effect. 2887 The "RRULE" property defines the recurrence rule for the onset of 2888 the observance defined by this time zone sub-component. Some 2889 specific requirements for the usage of "RRULE" for this purpose 2890 include: 2892 * If observance is known to have an effective end date, the 2893 "UNTIL" recurrence rule parameter MUST be used to specify the 2894 last valid onset of this observance (i.e., the UNTIL date-time 2895 will be equal to the last instance generated by the recurrence 2896 pattern). It MUST be specified in UTC time. 2898 * The "DTSTART" and the "TZOFFSETFROM" properties MUST be used 2899 when generating the onset date-time values (instances) from the 2900 "RRULE". 2902 Alternatively, the "RDATE" property can be used to define the 2903 onset of the observance by giving the individual onset date and 2904 times. "RDATE" in this usage MUST be specified as a local DATE- 2905 TIME value . 2907 The optional "COMMENT" property is also allowed for descriptive 2908 explanatory text. 2910 Example: The following are examples of the "VTIMEZONE" calendar 2911 component: 2913 This is an example showing all the time zone rules for New York 2914 City since April 30, 1967 at 03:00:00 EDT. 2916 BEGIN:VTIMEZONE 2917 TZID:America/New_York 2918 LAST-MODIFIED:20050809T050000Z 2919 BEGIN:STANDARD 2920 TZOFFSETFROM:-0400 2921 TZOFFSETTO:-0500 2922 TZNAME:EST 2923 DTSTART:19671029T020000 2924 RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU;UNTIL=20061029T060000Z 2925 END:STANDARD 2926 BEGIN:STANDARD 2927 TZOFFSETFROM:-0400 2928 TZOFFSETTO:-0500 2929 TZNAME:EST 2930 DTSTART:20071104T020000 2931 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU 2932 END:STANDARD 2933 BEGIN:DAYLIGHT 2934 TZOFFSETFROM:-0500 2935 TZOFFSETTO:-0400 2936 TZNAME:EDT 2937 DTSTART:19670430T020000 2938 RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=-1SU;UNTIL=19730429T070000Z 2939 END:DAYLIGHT 2940 BEGIN:DAYLIGHT 2941 TZOFFSETFROM:-0500 2942 TZOFFSETTO:-0400 2943 TZNAME:EDT 2944 DTSTART:19740106T020000 2945 RDATE:19750223T020000 2946 END:DAYLIGHT 2947 BEGIN:DAYLIGHT 2948 TZOFFSETFROM:-0500 2949 TZOFFSETTO:-0400 2950 TZNAME:EDT 2951 DTSTART:19760425T020000 2952 RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=-1SU;UNTIL=19860427T070000Z 2953 END:DAYLIGHT 2954 BEGIN:DAYLIGHT 2955 TZOFFSETFROM:-0500 2956 TZOFFSETTO:-0400 2957 TZNAME:EDT 2958 DTSTART:19870405T020000 2959 RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=1SU;UNTIL=20060402T070000Z 2960 END:DAYLIGHT 2961 BEGIN:DAYLIGHT 2962 TZOFFSETFROM:-0500 2963 TZOFFSETTO:-0400 2964 TZNAME:EDT 2965 DTSTART:20070311T020000 2966 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU 2967 END:DAYLIGHT 2968 END:VTIMEZONE 2970 This is an example showing time zone information for New York City 2971 using "RDATE" property. Note that this is only suitable for a 2972 recurring event that starts on or later than March 11, 2007 at 03: 2973 00:00 EDT (i.e., the earliest effective transition date and time) 2974 and ends no later than April 7, 1998 02:00:00 EST (i.e., latest 2975 valid date and time for EST in this scenario). For example, this 2976 can be used for a recurring event that occurs every Friday, 8:00 2977 A.M.-9:00 A.M., starting June 1, 1997, ending December 31, 1997. 2979 BEGIN:VTIMEZONE 2980 TZID:America/New_York 2981 LAST-MODIFIED:19870101T000000Z 2982 BEGIN:STANDARD 2983 DTSTART:19971026T020000 2984 RDATE:19971026T020000 2985 TZOFFSETFROM:-0400 2986 TZOFFSETTO:-0500 2987 TZNAME:EST 2988 END:STANDARD 2989 BEGIN:DAYLIGHT 2990 DTSTART:19970406T020000 2991 RDATE:19970406T020000 2992 TZOFFSETFROM:-0500 2993 TZOFFSETTO:-0400 2994 TZNAME:EDT 2995 END:DAYLIGHT 2996 END:VTIMEZONE 2998 This is a simple example showing the current time zone rules for 2999 the Eastern United States using a "RRULE" recurrence pattern. 3000 Note that there is no effective end date to either of the Standard 3001 Time or Daylight Time rules. This information would be valid for 3002 a recurring event starting today and continuing indefinitely. 3004 BEGIN:VTIMEZONE 3005 TZID:America/New_York 3006 LAST-MODIFIED:19870101T000000Z 3007 TZURL:http://zones.example.com/tz/America-New_York.ics 3008 BEGIN:STANDARD 3009 DTSTART:19671029T020000 3010 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 3011 TZOFFSETFROM:-0400 3012 TZOFFSETTO:-0500 3013 TZNAME:EST 3014 END:STANDARD 3015 BEGIN:DAYLIGHT 3016 DTSTART:19870405T020000 3017 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 3018 TZOFFSETFROM:-0500 3019 TZOFFSETTO:-0400 3020 TZNAME:EDT 3021 END:DAYLIGHT 3022 END:VTIMEZONE 3024 This is an example showing a fictitious set of rules for the 3025 Eastern United States, where the Daylight Time rule has an 3026 effective end date (i.e., after that date, Daylight Time is no 3027 longer observed). 3029 BEGIN:VTIMEZONE 3030 TZID:Fictitious--America/New_York 3031 LAST-MODIFIED:19870101T000000Z 3032 BEGIN:STANDARD 3033 DTSTART:19671029T020000 3034 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 3035 TZOFFSETFROM:-0400 3036 TZOFFSETTO:-0500 3037 TZNAME:EST 3038 END:STANDARD 3039 BEGIN:DAYLIGHT 3040 DTSTART:19870405T020000 3041 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T070000Z 3042 TZOFFSETFROM:-0500 3043 TZOFFSETTO:-0400 3044 TZNAME:EDT 3045 END:DAYLIGHT 3046 END:VTIMEZONE 3048 This is an example showing a fictitious set of rules for the 3049 Eastern United States, where the first Daylight Time rule has an 3050 effective end date. There is a second Daylight Time rule that 3051 picks up where the other left off. 3053 BEGIN:VTIMEZONE 3054 TZID:Fictitious--America/New_York 3055 LAST-MODIFIED:19870101T000000Z 3056 BEGIN:STANDARD 3057 DTSTART:19671029T020000 3058 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 3059 TZOFFSETFROM:-0400 3060 TZOFFSETTO:-0500 3061 TZNAME:EST 3062 END:STANDARD 3063 BEGIN:DAYLIGHT 3064 DTSTART:19870405T020000 3065 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T070000Z 3066 TZOFFSETFROM:-0500 3067 TZOFFSETTO:-0400 3068 TZNAME:EDT 3069 END:DAYLIGHT 3070 BEGIN:DAYLIGHT 3071 DTSTART:19990424T020000 3072 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=4 3073 TZOFFSETFROM:-0500 3074 TZOFFSETTO:-0400 3075 TZNAME:EDT 3076 END:DAYLIGHT 3077 END:VTIMEZONE 3079 3.6.6. Alarm Component 3081 Component Name: VALARM 3083 Purpose: Provide a grouping of component properties that define an 3084 alarm. 3086 Format Definition: A "VALARM" calendar component is defined by the 3087 following notation: 3089 alarmc = "BEGIN" ":" "VALARM" CRLF 3090 (audioprop / dispprop / emailprop / procprop) 3091 "END" ":" "VALARM" CRLF 3093 audioprop = *( 3095 ; 'action' and 'trigger' are both REQUIRED, 3096 ; but MUST NOT occur more than once 3098 action / trigger / 3100 ; 'duration' and 'repeat' are both OPTIONAL, 3101 ; and MUST NOT occur more than once each, 3102 ; but if one occurs, so MUST the other 3104 duration / repeat / 3106 ; the following is OPTIONAL, 3107 ; but MUST NOT occur more than once 3109 attach / 3111 ; the following is OPTIONAL, 3112 ; and MAY occur more than once 3114 x-prop / iana-prop 3116 ) 3118 dispprop = *( 3120 ; the following are REQUIRED, 3121 ; but MUST NOT occur more than once 3123 action / description / trigger / 3125 ; 'duration' and 'repeat' are both OPTIONAL, 3126 ; and MUST NOT occur more than once each, 3127 ; but if one occurs, so MUST the other 3129 duration / repeat / 3131 ; the following is OPTIONAL, 3132 ; and MAY occur more than once 3134 x-prop / iana-prop 3136 ) 3138 emailprop = *( 3140 ; the following are all REQUIRED, 3141 ; but MUST NOT occur more than once 3143 action / description / trigger / summary / 3144 ; the following is REQUIRED, 3145 ; and MAY occur more than once 3147 attendee / 3149 ; 'duration' and 'repeat' are both OPTIONAL, 3150 ; and MUST NOT occur more than once each, 3151 ; but if one occurs, so MUST the other 3153 duration / repeat / 3155 ; the following are OPTIONAL, 3156 ; and MAY occur more than once 3158 attach / x-prop / iana-prop 3160 ) 3162 procprop = *( 3164 ; the following are all REQUIRED, 3165 ; but MUST NOT occur more than once 3167 action / attach / trigger / 3169 ; 'duration' and 'repeat' are both OPTIONAL, 3170 ; and MUST NOT occur more than once each, 3171 ; but if one occurs, so MUST the other 3173 duration / repeat / 3175 ; 'description' is OPTIONAL, 3176 ; and MUST NOT occur more than once 3178 description / 3180 ; the following is OPTIONAL, 3181 ; and MAY occur more than once 3183 x-prop / iana-prop 3185 ) 3187 Description: A "VALARM" calendar component is a grouping of 3188 component properties that is a reminder or alarm for an event or a 3189 to-do. For example, it may be used to define a reminder for a 3190 pending event or an overdue to-do. 3192 The "VALARM" calendar component MUST include the "ACTION" and 3193 "TRIGGER" properties. The "ACTION" property further constrains 3194 the "VALARM" calendar component in the following ways: 3196 When the action is "AUDIO", the alarm can also include one and 3197 only one "ATTACH" property, which MUST point to a sound resource, 3198 which is rendered when the alarm is triggered. 3200 When the action is "DISPLAY", the alarm MUST also include a 3201 "DESCRIPTION" property, which contains the text to be displayed 3202 when the alarm is triggered. 3204 When the action is "EMAIL", the alarm MUST include a "DESCRIPTION" 3205 property, which contains the text to be used as the message body, 3206 a "SUMMARY" property, which contains the text to be used as the 3207 message subject, and one or more "ATTENDEE" properties, which 3208 contain the email address of attendees to receive the message. It 3209 can also include one or more "ATTACH" properties, which are 3210 intended to be sent as message attachments. When the alarm is 3211 triggered, the email message is sent. 3213 The "VALARM" calendar component MUST only appear within either a 3214 "VEVENT" or "VTODO" calendar component. "VALARM" calendar 3215 components cannot be nested. Multiple mutually independent 3216 "VALARM" calendar components can be specified for a single 3217 "VEVENT" or "VTODO" calendar component. 3219 The "TRIGGER" property specifies when the alarm will be triggered. 3220 The "TRIGGER" property specifies a duration prior to the start of 3221 an event or a to-do. The "TRIGGER" edge may be explicitly set to 3222 be relative to the "START" or "END" of the event or to-do with the 3223 "RELATED" parameter of the "TRIGGER" property. The "TRIGGER" 3224 property value type can alternatively be set to an absolute 3225 calendar date with UTC time. 3227 In an alarm set to trigger on the "START" of an event or to-do, 3228 the "DTSTART" property MUST be present in the associated event or 3229 to-do. In an alarm in a "VEVENT" calendar component set to 3230 trigger on the "END" of the event, either the "DTEND" property 3231 MUST be present, or the "DTSTART" and "DURATION" properties MUST 3232 both be present. In an alarm in a "VTODO" calendar component set 3233 to trigger on the "END" of the to-do, either the "DUE" property 3234 MUST be present, or the "DTSTART" and "DURATION" properties MUST 3235 both be present. 3237 The alarm can be defined such that it triggers repeatedly. A 3238 definition of an alarm with a repeating trigger MUST include both 3239 the "DURATION" and "REPEAT" properties. The "DURATION" property 3240 specifies the delay period, after which the alarm will repeat. 3241 The "REPEAT" property specifies the number of additional 3242 repetitions that the alarm will be triggered. This repetition 3243 count is in addition to the initial triggering of the alarm. Both 3244 of these properties MUST be present in order to specify a 3245 repeating alarm. If one of these two properties is absent, then 3246 the alarm will not repeat beyond the initial trigger. 3248 The "ACTION" property is used within the "VALARM" calendar 3249 component to specify the type of action invoked when the alarm is 3250 triggered. The "VALARM" properties provide enough information for 3251 a specific action to be invoked. It is typically the 3252 responsibility of a "Calendar User Agent" (CUA) to deliver the 3253 alarm in the specified fashion. An "ACTION" property value of 3254 AUDIO specifies an alarm that causes a sound to be played to alert 3255 the user; DISPLAY specifies an alarm that causes a text message to 3256 be displayed to the user; and EMAIL specifies an alarm that causes 3257 an electronic email message to be delivered to one or more email 3258 addresses. 3260 In an AUDIO alarm, if the optional "ATTACH" property is included, 3261 it MUST specify an audio sound resource. The intention is that 3262 the sound will be played as the alarm effect. If an "ATTACH" 3263 property is specified that does not refer to a sound resource, or 3264 if the specified sound resource cannot be rendered (because its 3265 format is unsupported, or because it cannot be retrieved), then 3266 the CUA or other entity responsible for playing the sound may 3267 choose a fallback action, such as playing a built-in default 3268 sound, or playing no sound at all. 3270 In a DISPLAY alarm, the intended alarm effect is for the text 3271 value of the "DESCRIPTION" property to be displayed to the user. 3273 In an EMAIL alarm, the intended alarm effect is for an email 3274 message to be composed and delivered to all the addresses 3275 specified by the "ATTENDEE" properties in the "VALARM" calendar 3276 component. The "DESCRIPTION" property of the "VALARM" calendar 3277 component MUST be used as the body text of the message, and the 3278 "SUMMARY" property MUST be used as the subject text. Any "ATTACH" 3279 properties in the "VALARM" calendar component SHOULD be sent as 3280 attachments to the message. 3282 Example: The following example is for a "VALARM" calendar component 3283 that specifies an audio alarm that will sound at a precise time 3284 and repeat 4 more times at 15 minute intervals: 3286 BEGIN:VALARM 3287 TRIGGER;VALUE=DATE-TIME:19970317T133000Z 3288 REPEAT:4 3289 DURATION:PT15M 3290 ACTION:AUDIO 3291 ATTACH;FMTTYPE=audio/basic:ftp://example.com/pub/ 3292 sounds/bell-01.aud 3293 END:VALARM 3295 The following example is for a "VALARM" calendar component that 3296 specifies a display alarm that will trigger 30 minutes before the 3297 scheduled start of the event or of the to-do it is associated with 3298 and will repeat 2 more times at 15 minute intervals: 3300 BEGIN:VALARM 3301 TRIGGER:-PT30M 3302 REPEAT:2 3303 DURATION:PT15M 3304 ACTION:DISPLAY 3305 DESCRIPTION:Breakfast meeting with executive\n 3306 team at 8:30 AM EST. 3307 END:VALARM 3309 The following example is for a "VALARM" calendar component that 3310 specifies an email alarm that will trigger 2 days before the 3311 scheduled due date/time of a to-do it is associated with. It does 3312 not repeat. The email has a subject, body and attachment link. 3314 BEGIN:VALARM 3315 TRIGGER;RELATED=END:-P2D 3316 ACTION:EMAIL 3317 ATTENDEE:mailto:john_doe@example.com 3318 SUMMARY:*** REMINDER: SEND AGENDA FOR WEEKLY STAFF MEETING *** 3319 DESCRIPTION:A draft agenda needs to be sent out to the attendees 3320 to the weekly managers meeting (MGR-LIST). Attached is a 3321 pointer the document template for the agenda file. 3322 ATTACH;FMTTYPE=application/msword:http://example.com/ 3323 templates/agenda.doc 3324 END:VALARM 3326 3.7. Calendar Properties 3328 The Calendar Properties are attributes that apply to the iCalendar 3329 object, as a whole. These properties do not appear within a calendar 3330 component. They SHOULD be specified after the "BEGIN:VCALENDAR" 3331 delimiter string and prior to any calendar component. 3333 3.7.1. Calendar Scale 3335 Property Name: CALSCALE 3337 Purpose: This property defines the calendar scale used for the 3338 calendar information specified in the iCalendar object. 3340 Value Type: TEXT 3342 Property Parameters: IANA and non-standard property parameters can 3343 be specified on this property. 3345 Conformance: This property can be specified once in an iCalendar 3346 object. The default value is "GREGORIAN". 3348 Description: This memo is based on the Gregorian calendar scale. 3349 The Gregorian calendar scale is assumed if this property is not 3350 specified in the iCalendar object. It is expected that other 3351 calendar scales will be defined in other specifications or by 3352 future versions of this memo. 3354 Format Definition: This property is defined by the following 3355 notation: 3357 calscale = "CALSCALE" calparam ":" calvalue CRLF 3359 calparam = *(";" other-param) 3361 calvalue = "GREGORIAN" 3363 Example: The following is an example of this property: 3365 CALSCALE:GREGORIAN 3367 3.7.2. Method 3369 Property Name: METHOD 3370 Purpose: This property defines the iCalendar object method 3371 associated with the calendar object. 3373 Value Type: TEXT 3375 Property Parameters: IANA and non-standard property parameters can 3376 be specified on this property. 3378 Conformance: This property can be specified once in an iCalendar 3379 object. 3381 Description: When used in a MIME message entity, the value of this 3382 property MUST be the same as the Content-Type "method" parameter 3383 value. If either the "METHOD" property or the Content-Type 3384 "method" parameter is specified, then the other MUST also be 3385 specified. 3387 No methods are defined by this specification. This is the subject 3388 of other specifications, such as the iCalendar Transport- 3389 independent Interoperability Protocol (iTIP) defined by 3390 [I-D.ietf-calsify-2446bis]. 3392 If this property is not present in the iCalendar object, then a 3393 scheduling transaction MUST NOT be assumed. In such cases, the 3394 iCalendar object is merely being used to transport a snapshot of 3395 some calendar information; without the intention of conveying a 3396 scheduling semantic. 3398 Format Definition: This property is defined by the following 3399 notation: 3401 method = "METHOD" metparam ":" metvalue CRLF 3403 metparam = *(";" other-param) 3405 metvalue = iana-token 3407 Example: The following is a hypothetical example of this property to 3408 convey that the iCalendar object is a scheduling request : 3410 METHOD:REQUEST 3412 3.7.3. Product Identifier 3413 Property Name: PRODID 3415 Purpose: This property specifies the identifier for the product that 3416 created the iCalendar object. 3418 Value Type: TEXT 3420 Property Parameters: IANA and non-standard property parameters can 3421 be specified on this property. 3423 Conformance: The property MUST be specified once in an iCalendar 3424 object. 3426 Description: The vendor of the implementation SHOULD assure that 3427 this is a globally unique identifier; using some technique such as 3428 an FPI value, as defined in [ISO.9070.1991]. 3430 This property SHOULD not be used to alter the interpretation of an 3431 iCalendar object beyond the semantics specified in this memo. For 3432 example, it is not to be used to further the understanding of non- 3433 standard properties. 3435 Format Definition: This property is defined by the following 3436 notation: 3438 prodid = "PRODID" pidparam ":" pidvalue CRLF 3440 pidparam = *(";" other-param) 3442 pidvalue = text 3443 ;Any text that describes the product and version 3444 ;and that is generally assured of being unique. 3446 Example: The following is an example of this property. It does not 3447 imply that English is the default language. 3449 PRODID:-//ABC Corporation//NONSGML My Product//EN 3451 3.7.4. Version 3453 Property Name: VERSION 3455 Purpose: This property specifies the identifier corresponding to the 3456 highest version number or the minimum and maximum range of the 3457 iCalendar specification that is required in order to interpret the 3458 iCalendar object. 3460 Value Type: TEXT 3462 Property Parameters: IANA and non-standard property parameters can 3463 be specified on this property. 3465 Conformance: This property MUST be specified once in an iCalendar 3466 object. 3468 Description: A value of "2.0" corresponds to this memo. 3470 Format Definition: This property is defined by the following 3471 notation: 3473 version = "VERSION" verparam ":" vervalue CRLF 3475 verparam = *(";" other-param) 3477 vervalue = "2.0" ;This memo 3478 / maxver 3479 / (minver ";" maxver) 3481 minver = 3482 ;Minimum iCalendar version needed to parse the iCalendar object 3484 maxver = 3485 ;Maximum iCalendar version needed to parse the iCalendar object 3487 Example: The following is an example of this property: 3489 VERSION:2.0 3491 3.8. Component Properties 3493 The following properties can appear within calendar components, as 3494 specified by each component property definition. 3496 3.8.1. Descriptive Component Properties 3498 The following properties specify descriptive information about 3499 calendar components. 3501 3.8.1.1. Attachment 3503 Property Name: ATTACH 3504 Purpose: This property provides the capability to associate a 3505 document object with a calendar component. 3507 Value Type: The default value type for this property is URI. The 3508 value type can also be set to BINARY to indicate inline binary 3509 encoded content information. 3511 Property Parameters: IANA, non-standard, inline encoding, format 3512 type and value data type property parameters can be specified on 3513 this property. 3515 Conformance: The property can be specified in a "VEVENT", "VTODO", 3516 "VJOURNAL" or "VALARM" calendar components. 3518 Description: This property can be specified within "VEVENT", 3519 "VTODO", "VJOURNAL", or "VALARM" calendar components. This 3520 property can be specified multiple times within an iCalendar 3521 object. 3523 Format Definition: This property is defined by the following 3524 notation: 3526 attach = "ATTACH" attachparam ":" uri CRLF 3528 / "ATTACH" attachparam ";" "ENCODING" "=" "BASE64" 3529 ";" "VALUE" "=" "BINARY" ":" binary 3531 attachparam = *( 3533 ; the following is OPTIONAL, 3534 ; but MUST NOT occur more than once 3536 (";" fmttypeparam) / 3538 ; the following is OPTIONAL, 3539 ; and MAY occur more than once 3541 (";" other-param) 3543 ) 3545 Example: The following are examples of this property: 3547 ATTACH:CID:jsmith.part3.960817T083000.xyzMail@example.com 3549 ATTACH;FMTTYPE=application/postscript:ftp://example.com/pub/ 3550 reports/r-960812.ps 3552 3.8.1.2. Categories 3554 Property Name: CATEGORIES 3556 Purpose: This property defines the categories for a calendar 3557 component. 3559 Value Type: TEXT 3561 Property Parameters: IANA, non-standard, and language property 3562 parameters can be specified on this property. 3564 Conformance: The property can be specified within "VEVENT", "VTODO" 3565 or "VJOURNAL" calendar components. 3567 Description: This property is used to specify categories or subtypes 3568 of the calendar component. The categories are useful in searching 3569 for a calendar component of a particular type and category. 3570 Within the "VEVENT", "VTODO" or "VJOURNAL" calendar components, 3571 more than one category can be specified as a list of categories 3572 separated by the COMMA character (US-ASCII decimal 44). 3574 Format Definition: This property is defined by the following 3575 notation: 3577 categories = "CATEGORIES" catparam ":" text *("," text) 3578 CRLF 3580 catparam = *( 3582 ; the following is OPTIONAL, 3583 ; but MUST NOT occur more than once 3585 (";" languageparam ) / 3587 ; the following is OPTIONAL, 3588 ; and MAY occur more than once 3590 (";" other-param) 3592 ) 3594 Example: The following are examples of this property: 3596 CATEGORIES:APPOINTMENT,EDUCATION 3598 CATEGORIES:MEETING 3600 3.8.1.3. Classification 3602 Property Name: CLASS 3604 Purpose: This property defines the access classification for a 3605 calendar component. 3607 Value Type: TEXT 3609 Property Parameters: IANA and non-standard property parameters can 3610 be specified on this property. 3612 Conformance: The property can be specified once in a "VEVENT", 3613 "VTODO" or "VJOURNAL" calendar components. 3615 Description: An access classification is only one component of the 3616 general security system within a calendar application. It 3617 provides a method of capturing the scope of the access the 3618 calendar owner intends for information within an individual 3619 calendar entry. The access classification of an individual 3620 iCalendar component is useful when measured along with the other 3621 security components of a calendar system (e.g., calendar user 3622 authentication, authorization, access rights, access role, etc.). 3623 Hence, the semantics of the individual access classifications 3624 cannot be completely defined by this memo alone. Additionally, 3625 due to the "blind" nature of most exchange processes using this 3626 memo, these access classifications cannot serve as an enforcement 3627 statement for a system receiving an iCalendar object. Rather, 3628 they provide a method for capturing the intention of the calendar 3629 owner for the access to the calendar component. 3631 Format Definition: This property is defined by the following 3632 notation: 3634 class = "CLASS" classparam ":" classvalue CRLF 3636 classparam = *(";" other-param) 3638 classvalue = "PUBLIC" / "PRIVATE" / "CONFIDENTIAL" / iana-token 3639 / x-name 3640 ;Default is PUBLIC 3642 Example: The following is an example of this property: 3644 CLASS:PUBLIC 3646 3.8.1.4. Comment 3648 Property Name: COMMENT 3650 Purpose: This property specifies non-processing information intended 3651 to provide a comment to the calendar user. 3653 Value Type: TEXT 3655 Property Parameters: IANA, non-standard, alternate text 3656 representation and language property parameters can be specified 3657 on this property. 3659 Conformance: This property can be specified one or more times in 3660 "VEVENT", "VTODO", "VJOURNAL", and "VFREEBUSY" calendar components 3661 as well as in the "STANDARD" and "DAYLIGHT" sub-components. 3663 Description: The property can be specified multiple times. 3665 Format Definition: This property is defined by the following 3666 notation: 3668 comment = "COMMENT" commparam ":" text CRLF 3670 commparam = *( 3672 ; the following are OPTIONAL, 3673 ; but MUST NOT occur more than once 3675 (";" altrepparam) / (";" languageparam) / 3677 ; the following is OPTIONAL, 3678 ; and MAY occur more than once 3680 (";" other-param) 3682 ) 3684 Example: The following is an example of this property: 3686 COMMENT:The meeting really needs to include both ourselves 3687 and the customer. We can't hold this meeting without them. 3688 As a matter of fact\, the venue for the meeting ought to be at 3689 their site. - - John 3691 3.8.1.5. Description 3693 Property Name: DESCRIPTION 3695 Purpose: This property provides a more complete description of the 3696 calendar component, than that provided by the "SUMMARY" property. 3698 Value Type: TEXT 3700 Property Parameters: IANA, non-standard, alternate text 3701 representation and language property parameters can be specified 3702 on this property. 3704 Conformance: The property can be specified in the "VEVENT", "VTODO", 3705 "VJOURNAL" or "VALARM" calendar components. The property can be 3706 specified multiple times only within a "VJOURNAL" calendar 3707 component. 3709 Description: This property is used in the "VEVENT" and "VTODO" to 3710 capture lengthy textual decriptions associated with the activity. 3712 This property is used in the "VJOURNAL" calendar component to 3713 capture one or more textual journal entries. 3715 This property is used in the "VALARM" calendar component to 3716 capture the display text for a DISPLAY category of alarm, and to 3717 capture the body text for an EMAIL category of alarm . 3719 Format Definition: This property is defined by the following 3720 notation: 3722 description = "DESCRIPTION" descparam ":" text CRLF 3724 descparam = *( 3726 ; the following are OPTIONAL, 3727 ; but MUST NOT occur more than once 3729 (";" altrepparam) / (";" languageparam) / 3731 ; the following is OPTIONAL, 3732 ; and MAY occur more than once 3734 (";" other-param) 3736 ) 3738 Example: The following is an example of this property with formatted 3739 line breaks in the property value: 3741 DESCRIPTION:Meeting to provide technical review for "Phoenix" 3742 design.\nHappy Face Conference Room. Phoenix design team 3743 MUST attend this meeting.\nRSVP to team leader. 3745 3.8.1.6. Geographic Position 3747 Property Name: GEO 3749 Purpose: This property specifies information related to the global 3750 position for the activity specified by a calendar component. 3752 Value Type: FLOAT. The value MUST be two SEMICOLON separated FLOAT 3753 values. 3755 Property Parameters: IANA and non-standard property parameters can 3756 be specified on this property. 3758 Conformance: This property can be specified in "VEVENT" or "VTODO" 3759 calendar components. 3761 Description: This property value specifies latitude and longitude, 3762 in that order (i.e., "LAT LON" ordering). The longitude 3763 represents the location East or West of the prime meridian as a 3764 positive or negative real number, respectively. The longitude and 3765 latitude values MAY be specified up to six decimal places, which 3766 will allow for accuracy to within one meter of geographical 3767 position. Receiving applications MUST accept values of this 3768 precision and MAY truncate values of greater precision. 3770 Values for latitude and longitude shall be expressed as decimal 3771 fractions of degrees. Whole degrees of latitude shall be 3772 represented by a two-digit decimal number ranging from 0 through 3773 90. Whole degrees of longitude shall be represented by a decimal 3774 number ranging from 0 through 180. When a decimal fraction of a 3775 degree is specified, it shall be separated from the whole number 3776 of degrees by a decimal point. 3778 Latitudes North of the equator shall be specified by a plus sign 3779 (+), or by the absence of a minus sign (-), preceding the digits 3780 designating degrees. Latitudes South of the Equator shall be 3781 designated by a minus sign (-) preceding the digits designating 3782 degrees. A point on the Equator shall be assigned to the Northern 3783 Hemisphere. 3785 Longitudes east of the prime meridian shall be specified by a plus 3786 sign (+), or by the absence of a minus sign (-), preceding the 3787 digits designating degrees. Longitudes west of the meridian shall 3788 be designated by minus sign (-) preceding the digits designating 3789 degrees. A point on the prime meridian shall be assigned to the 3790 Eastern Hemisphere. A point on the 180th meridian shall be 3791 assigned to the Western Hemisphere. One exception to this last 3792 convention is permitted. For the special condition of describing 3793 a band of latitude around the earth, the East Bounding Coordinate 3794 data element shall be assigned the value +180 (180) degrees. 3796 Any spatial address with a latitude of +90 (90) or -90 degrees 3797 will specify the position at the North or South Pole, 3798 respectively. The component for longitude may have any legal 3799 value. 3801 With the exception of the special condition described above, this 3802 form is specified in Department of Commerce, 1986, Representation 3803 of geographic point locations for information interchange (Federal 3804 Information Processing Standard 70-1): Washington, Department of 3805 Commerce, National Institute of Standards and Technology. 3807 The simple formula for converting degrees-minutes-seconds into 3808 decimal degrees is: 3810 decimal = degrees + minutes/60 + seconds/3600. 3812 Format Definition: This property is defined by the following 3813 notation: 3815 geo = "GEO" geoparam ":" geovalue CRLF 3817 geoparam = *(";" other-param) 3819 geovalue = float ";" float 3820 ;Latitude and Longitude components 3822 Example: The following is an example of this property: 3824 GEO:37.386013;-122.082932 3826 3.8.1.7. Location 3828 Property Name: LOCATION 3829 Purpose: This property defines the intended venue for the activity 3830 defined by a calendar component. 3832 Value Type: TEXT 3834 Property Parameters: IANA, non-standard, alternate text 3835 representation and language property parameters can be specified 3836 on this property. 3838 Conformance: This property can be specified in "VEVENT" or "VTODO" 3839 calendar component. 3841 Description: Specific venues such as conference or meeting rooms may 3842 be explicitly specified using this property. An alternate 3843 representation may be specified that is a URI that points to 3844 directory information with more structured specification of the 3845 location. For example, the alternate representation may specify 3846 either an LDAP URL [RFC4516] pointing to an LDAP server entry or a 3847 CID URL [RFC2392] pointing to a MIME body part containing a vCard 3848 [RFC2426] for the location. 3850 Format Definition: This property is defined by the following 3851 notation: 3853 location = "LOCATION" locparam ":" text CRLF 3855 locparam = *( 3857 ; the following are OPTIONAL, 3858 ; but MUST NOT occur more than once 3860 (";" altrepparam) / (";" languageparam) / 3862 ; the following is OPTIONAL, 3863 ; and MAY occur more than once 3865 (";" other-param) 3867 ) 3869 Example: The following are some examples of this property: 3871 LOCATION:Conference Room - F123\, Bldg. 002 3873 LOCATION;ALTREP="http://xyzcorp.com/conf-rooms/f123.vcf": 3874 Conference Room - F123\, Bldg. 002 3876 3.8.1.8. Percent Complete 3878 Property Name: PERCENT-COMPLETE 3880 Purpose: This property is used by an assignee or delegatee of a 3881 to-do to convey the percent completion of a to-do to the 3882 "Organizer". 3884 Value Type: INTEGER 3886 Property Parameters: IANA and non-standard property parameters can 3887 be specified on this property. 3889 Conformance: This property can be specified once in a "VTODO" 3890 calendar component. 3892 Description: The property value is a positive integer between zero 3893 and one hundred. A value of "0" indicates the to-do has not yet 3894 been started. A value of "100" indicates that the to-do has been 3895 completed. Integer values in between indicate the percent 3896 partially complete. 3898 When a to-do is assigned to multiple individuals, the property 3899 value indicates the percent complete for that portion of the to-do 3900 assigned to the assignee or delegatee. For example, if a to-do is 3901 assigned to both individuals "A" and "B". A reply from "A" with a 3902 percent complete of "70" indicates that "A" has completed 70% of 3903 the to-do assigned to them. A reply from "B" with a percent 3904 complete of "50" indicates "B" has completed 50% of the to-do 3905 assigned to them. 3907 Format Definition: This property is defined by the following 3908 notation: 3910 percent = "PERCENT-COMPLETE" pctparam ":" integer CRLF 3912 pctparam = *(";" other-param) 3914 Example: The following is an example of this property to show 39% 3915 completion: 3917 PERCENT-COMPLETE:39 3919 3.8.1.9. Priority 3920 Property Name: PRIORITY 3922 Purpose: This property defines the relative priority for a calendar 3923 component. 3925 Value Type: INTEGER 3927 Property Parameters: IANA and non-standard property parameters can 3928 be specified on this property. 3930 Conformance: This property can be specified in "VEVENT" and "VTODO" 3931 calendar components. 3933 Description: This priority is specified as an integer in the range 3934 zero to nine. A value of zero (US-ASCII decimal 48) specifies an 3935 undefined priority. A value of one (US-ASCII decimal 49) is the 3936 highest priority. A value of two (US-ASCII decimal 50) is the 3937 second highest priority. Subsequent numbers specify a decreasing 3938 ordinal priority. A value of nine (US-ASCII decimal 57 ) is the 3939 lowest priority. 3941 A CUA with a three-level priority scheme of "HIGH", "MEDIUM" and 3942 "LOW" is mapped into this property such that a property value in 3943 the range of one (US-ASCII decimal 49) to four (US-ASCII decimal 3944 52) specifies "HIGH" priority. A value of five (US-ASCII decimal 3945 53) is the normal or "MEDIUM" priority. A value in the range of 3946 six (US-ASCII decimal 54) to nine (US-ASCII decimal 57 ) is "LOW" 3947 priority. 3949 A CUA with a priority schema of "A1", "A2", "A3", "B1", "B2", ..., 3950 "C3" is mapped into this property such that a property value of 3951 one (US-ASCII decimal 49) specifies "A1", a property value of two 3952 (US-ASCII decimal 50) specifies "A2", a property value of three 3953 (US-ASCII decimal 51) specifies "A3", and so forth up to a 3954 property value of 9 (US-ASCII decimal 57 ) specifies "C3". 3956 Other integer values are reserved for future use. 3958 Within a "VEVENT" calendar component, this property specifies a 3959 priority for the event. This property may be useful when more 3960 than one event is scheduled for a given time period. 3962 Within a "VTODO" calendar component, this property specified a 3963 priority for the to-do. This property is useful in prioritizing 3964 multiple action items for a given time period. 3966 Format Definition: This property is defined by the following 3967 notation: 3969 priority = "PRIORITY" prioparam ":" priovalue CRLF 3970 ;Default is zero (i.e., undefined) 3972 prioparam = *(";" other-param) 3974 priovalue = integer ;Must be in the range [0..9] 3975 ; All other values are reserved for future use 3977 Example: The following is an example of a property with the highest 3978 priority: 3980 PRIORITY:1 3982 The following is an example of a property with a next highest 3983 priority: 3985 PRIORITY:2 3987 The following is an example of a property with no priority. This 3988 is equivalent to not specifying the "PRIORITY" property: 3990 PRIORITY:0 3992 3.8.1.10. Resources 3994 Property Name: RESOURCES 3996 Purpose: This property defines the equipment or resources 3997 anticipated for an activity specified by a calendar component. 3999 Value Type: TEXT 4001 Property Parameters: IANA, non-standard, alternate text 4002 representation and language property parameters can be specified 4003 on this property. 4005 Conformance: This property can be specified once in "VEVENT" or 4006 "VTODO" calendar component. 4008 Description: The property value is an arbitrary text. More than one 4009 resource can be specified as a list of resources separated by the 4010 COMMA character (US-ASCII decimal 44). 4012 Format Definition: This property is defined by the following 4013 notation: 4015 resources = "RESOURCES" resrcparam ":" text *("," text) CRLF 4017 resrcparam = *( 4019 ; the following are OPTIONAL, 4020 ; but MUST NOT occur more than once 4022 (";" altrepparam) / (";" languageparam) / 4024 ; the following is OPTIONAL, 4025 ; and MAY occur more than once 4027 (";" other-param) 4029 ) 4031 Example: The following is an example of this property: 4033 RESOURCES:EASEL,PROJECTOR,VCR 4035 RESOURCES;LANGUAGE=fr:1 raton-laveur 4037 3.8.1.11. Status 4039 Property Name: STATUS 4041 Purpose: This property defines the overall status or confirmation 4042 for the calendar component. 4044 Value Type: TEXT 4046 Property Parameters: IANA and non-standard property parameters can 4047 be specified on this property. 4049 Conformance: This property can be specified once in "VEVENT", 4050 "VTODO" or "VJOURNAL" calendar components. 4052 Description: In a group scheduled calendar component, the property 4053 is used by the "Organizer" to provide a confirmation of the event 4054 to the "Attendees". For example in a "VEVENT" calendar component, 4055 the "Organizer" can indicate that a meeting is tentative, 4056 confirmed or cancelled. In a "VTODO" calendar component, the 4057 "Organizer" can indicate that an action item needs action, is 4058 completed, is in process or being worked on, or has been 4059 cancelled. In a "VJOURNAL" calendar component, the "Organizer" 4060 can indicate that a journal entry is draft, final or has been 4061 cancelled or removed. 4063 Format Definition: This property is defined by the following 4064 notation: 4066 status = "STATUS" statparam ":" statvalue CRLF 4068 statparam = *(";" other-param) 4070 statvalue = (statvalue-event 4071 / statvalue-todo 4072 / statvalue-jour) 4074 statvalue-event = "TENTATIVE" ;Indicates event is tentative. 4075 / "CONFIRMED" ;Indicates event is definite. 4076 / "CANCELLED" ;Indicates event was cancelled. 4077 ;Status values for a "VEVENT" 4079 statvalue-todo = "NEEDS-ACTION" ;Indicates to-do needs action. 4080 / "COMPLETED" ;Indicates to-do completed. 4081 / "IN-PROCESS" ;Indicates to-do in process of. 4082 / "CANCELLED" ;Indicates to-do was cancelled. 4083 ;Status values for "VTODO". 4085 statvalue-jour = "DRAFT" ;Indicates journal is draft. 4086 / "FINAL" ;Indicates journal is final. 4087 / "CANCELLED" ;Indicates journal is removed. 4088 ;Status values for "VJOURNAL". 4090 Example: The following is an example of this property for a "VEVENT" 4091 calendar component: 4093 STATUS:TENTATIVE 4095 The following is an example of this property for a "VTODO" 4096 calendar component: 4098 STATUS:NEEDS-ACTION 4100 The following is an example of this property for a "VJOURNAL" 4101 calendar component: 4103 STATUS:DRAFT 4105 3.8.1.12. Summary 4107 Property Name: SUMMARY 4109 Purpose: This property defines a short summary or subject for the 4110 calendar component. 4112 Value Type: TEXT 4114 Property Parameters: IANA, non-standard, alternate text 4115 representation and language property parameters can be specified 4116 on this property. 4118 Conformance: The property can be specified in "VEVENT", "VTODO", 4119 "VJOURNAL" or "VALARM" calendar components. 4121 Description: This property is used in the "VEVENT", "VTODO" and 4122 "VJOURNAL" calendar components to capture a short, one line 4123 summary about the activity or journal entry. 4125 This property is used in the "VALARM" calendar component to 4126 capture the subject of an EMAIL category of alarm. 4128 Format Definition: This property is defined by the following 4129 notation: 4131 summary = "SUMMARY" summparam ":" text CRLF 4133 summparam = *( 4135 ; the following are OPTIONAL, 4136 ; but MUST NOT occur more than once 4138 (";" altrepparam) / (";" languageparam) / 4140 ; the following is OPTIONAL, 4141 ; and MAY occur more than once 4143 (";" other-param) 4145 ) 4147 Example: The following is an example of this property: 4149 SUMMARY:Department Party 4151 3.8.2. Date and Time Component Properties 4153 The following properties specify date and time related information in 4154 calendar components. 4156 3.8.2.1. Date/Time Completed 4158 Property Name: COMPLETED 4160 Purpose: This property defines the date and time that a to-do was 4161 actually completed. 4163 Value Type: DATE-TIME 4165 Property Parameters: IANA and non-standard property parameters can 4166 be specified on this property. 4168 Conformance: The property can be specified in a "VTODO" calendar 4169 component. 4171 Description: The date and time MUST be in a UTC format. 4173 Format Definition: This property is defined by the following 4174 notation: 4176 completed = "COMPLETED" compparam ":" date-time CRLF 4178 compparam = *(";" other-param) 4180 Example: The following is an example of this property: 4182 COMPLETED:19960401T150000Z 4184 3.8.2.2. Date/Time End 4186 Property Name: DTEND 4188 Purpose: This property specifies the date and time that a calendar 4189 component ends. 4191 Value Type: The default value type is DATE-TIME. The value type can 4192 be set to a DATE value type. 4194 Property Parameters: IANA, non-standard, value data type, and time 4195 zone identifier property parameters can be specified on this 4196 property. 4198 Conformance: This property can be specified in "VEVENT" or 4199 "VFREEBUSY" calendar components. 4201 Description: Within the "VEVENT" calendar component, this property 4202 defines the date and time by which the event ends. The value MUST 4203 be later in time than the value of the "DTSTART" property. 4205 Within the "VFREEBUSY" calendar component, this property defines 4206 the end date and time for the free or busy time information. The 4207 time MUST be specified in the UTC time format. The value MUST be 4208 later in time than the value of the "DTSTART" property. 4210 Format Definition: This property is defined by the following 4211 notation: 4213 dtend = "DTEND" dtendparam ":" dtendval CRLF 4215 dtendparam = *( 4217 ; the following are OPTIONAL, 4218 ; but MUST NOT occur more than once 4220 (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / 4221 (";" tzidparam) / 4223 ; the following is OPTIONAL, 4224 ; and MAY occur more than once 4226 (";" other-param) 4228 ) 4230 dtendval = date-time / date 4231 ;Value MUST match value type 4233 Example: The following is an example of this property: 4235 DTEND:19960401T150000Z 4237 DTEND;VALUE=DATE:19980704 4239 3.8.2.3. Date/Time Due 4240 Property Name: DUE 4242 Purpose: This property defines the date and time that a to-do is 4243 expected to be completed. 4245 Value Type: The default value type is DATE-TIME. The value type can 4246 be set to a DATE value type. 4248 Property Parameters: IANA, non-standard, value data type, and time 4249 zone identifier property parameters can be specified on this 4250 property. 4252 Conformance: The property can be specified once in a "VTODO" 4253 calendar component. 4255 Description: The value MUST be a date/time equal to or after the 4256 "DTSTART" value, if specified. 4258 Format Definition: This property is defined by the following 4259 notation: 4261 due = "DUE" dueparam ":" dueval CRLF 4263 dueparam = *( 4265 ; the following are OPTIONAL, 4266 ; but MUST NOT occur more than once 4268 (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / 4269 (";" tzidparam) / 4271 ; the following is OPTIONAL, 4272 ; and MAY occur more than once 4274 (";" other-param) 4276 ) 4278 dueval = date-time / date 4279 ;Value MUST match value type 4281 Example: The following is an example of this property: 4283 DUE:19980430T000000Z 4285 3.8.2.4. Date/Time Start 4287 Property Name: DTSTART 4289 Purpose: This property specifies when the calendar component begins. 4291 Value Type: The default value type is DATE-TIME. The time value 4292 MUST be one of the forms defined for the DATE-TIME value type. 4293 The value type can be set to a DATE value type. 4295 Property Parameters: IANA, non-standard, value data type, and time 4296 zone identifier property parameters can be specified on this 4297 property. 4299 Conformance: This property can be specified once in the "VEVENT", 4300 "VTODO", or "VFREEBUSY" calendar components as well as in the 4301 "STANDARD" and "DAYLIGHT" sub-components. This property is 4302 REQUIRED in "VEVENT" calendar components and in all types of 4303 recurring calendar components. 4305 Description: Within the "VEVENT" calendar component, this property 4306 defines the start date and time for the event. 4308 Within the "VFREEBUSY" calendar component, this property defines 4309 the start date and time for the free or busy time information. 4310 The time MUST be specified in UTC time. 4312 Within the "STANDARD" and "DAYLIGHT" sub-components, this property 4313 defines the effective start date and time for a time zone 4314 specification. This property is REQUIRED within each "STANDARD" 4315 and "DAYLIGHT" sub-components included in "VTIMEZONE" calendar 4316 components and MUST be specified as a local DATE-TIME without the 4317 "TZID" property parameter. 4319 Format Definition: This property is defined by the following 4320 notation: 4322 dtstart = "DTSTART" dtstparam ":" dtstval CRLF 4324 dtstparam = *( 4326 ; the following are OPTIONAL, 4327 ; but MUST NOT occur more than once 4329 (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / 4330 (";" tzidparam) / 4332 ; the following is OPTIONAL, 4333 ; and MAY occur more than once 4335 (";" other-param) 4337 ) 4339 dtstval = date-time / date 4340 ;Value MUST match value type 4342 Example: The following is an example of this property: 4344 DTSTART:19980118T073000Z 4346 3.8.2.5. Duration 4348 Property Name: DURATION 4350 Purpose: This property specifies a positive duration of time. 4352 Value Type: DURATION 4354 Property Parameters: IANA and non-standard property parameters can 4355 be specified on this property. 4357 Conformance: This property can be specified in "VEVENT", "VTODO", 4358 "VFREEBUSY" or "VALARM" calendar components. 4360 Description: In a "VEVENT" calendar component the property may be 4361 used to specify a duration of the event, instead of an explicit 4362 end date/time. In a "VTODO" calendar component the property may 4363 be used to specify a duration for the to-do, instead of an 4364 explicit due date/time. In a "VFREEBUSY" calendar component the 4365 property may be used to specify the interval of free time being 4366 requested. In a "VALARM" calendar component the property may be 4367 used to specify the delay period prior to repeating an alarm. 4369 Format Definition: This property is defined by the following 4370 notation: 4372 duration = "DURATION" durparam ":" dur-value CRLF 4373 ;consisting of a positive duration of time. 4375 durparam = *(";" other-param) 4377 Example: The following is an example of this property that specifies 4378 an interval of time of 1 hour and zero minutes and zero seconds: 4380 DURATION:PT1H0M0S 4382 The following is an example of this property that specifies an 4383 interval of time of 15 minutes. 4385 DURATION:PT15M 4387 3.8.2.6. Free/Busy Time 4389 Property Name: FREEBUSY 4391 Purpose: This property defines one or more free or busy time 4392 intervals. 4394 Value Type: PERIOD 4396 Property Parameters: IANA, non-standard, and free/busy time type 4397 property parameters can be specified on this property. 4399 Conformance: The property can be specified in a "VFREEBUSY" calendar 4400 component. 4402 Description: These time periods can be specified as either a start 4403 and end date-time or a start date-time and duration. The date and 4404 time MUST be a UTC time format. 4406 "FREEBUSY" properties within the "VFREEBUSY" calendar component 4407 SHOULD be sorted in ascending order, based on start time and then 4408 end time, with the earliest periods first. 4410 The "FREEBUSY" property can specify more than one value, separated 4411 by the COMMA character (US-ASCII decimal 44). In such cases, the 4412 "FREEBUSY" property values MUST all be of the same "FBTYPE" 4413 property parameter type (e.g., all values of a particular "FBTYPE" 4414 listed together in a single property). 4416 Format Definition: This property is defined by the following 4417 notation: 4419 freebusy = "FREEBUSY" fbparam ":" fbvalue CRLF 4421 fbparam = *( 4422 ; the following is OPTIONAL, 4423 ; but MUST NOT occur more than once 4425 (";" fbtypeparam) / 4427 ; the following is OPTIONAL, 4428 ; and MAY occur more than once 4430 (";" other-param) 4432 ) 4434 fbvalue = period *("," period) 4435 ;Time value MUST be in the UTC time format. 4437 Example: The following are some examples of this property: 4439 FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:19970308T160000Z/PT8H30M 4441 FREEBUSY;FBTYPE=FREE:19970308T160000Z/PT3H,19970308T200000Z/PT1H 4443 FREEBUSY;FBTYPE=FREE:19970308T160000Z/PT3H,19970308T200000Z/PT1H 4444 ,19970308T230000Z/19970309T000000Z 4446 3.8.2.7. Time Transparency 4448 Property Name: TRANSP 4450 Purpose: This property defines whether an event is transparent or 4451 not to busy time searches. 4453 Value Type: TEXT 4455 Property Parameters: IANA and non-standard property parameters can 4456 be specified on this property. 4458 Conformance: This property can be specified once in a "VEVENT" 4459 calendar component. 4461 Description: Time Transparency is the characteristic of an event 4462 that determines whether it appears to consume time on a calendar. 4463 Events that consume actual time for the individual or resource 4464 associated with the calendar SHOULD be recorded as OPAQUE, 4465 allowing them to be detected by free-busy time searches. Other 4466 events, which do not take up the individual's (or resource's) time 4467 SHOULD be recorded as TRANSPARENT, making them invisible to free- 4468 busy time searches. 4470 Format Definition: This property is defined by the following 4471 notation: 4473 transp = "TRANSP" transparam ":" transvalue CRLF 4475 transparam = *(";" other-param) 4477 transvalue = "OPAQUE" 4478 ;Blocks or opaque on busy time searches. 4479 / "TRANSPARENT" 4480 ;Transparent on busy time searches. 4481 ;Default value is OPAQUE 4483 Example: The following is an example of this property for an event 4484 that is transparent or does not block on free/busy time searches: 4486 TRANSP:TRANSPARENT 4488 The following is an example of this property for an event that is 4489 opaque or blocks on free/busy time searches: 4491 TRANSP:OPAQUE 4493 3.8.3. Time Zone Component Properties 4495 The following properties specify time zone information in calendar 4496 components. 4498 3.8.3.1. Time Zone Identifier 4500 Property Name: TZID 4502 Purpose: This property specifies the text value that uniquely 4503 identifies the "VTIMEZONE" calendar component in the scope of an 4504 iCalendar object. 4506 Value Type: TEXT 4508 Property Parameters: IANA and non-standard property parameters can 4509 be specified on this property. 4511 Conformance: This property MUST be specified in a "VTIMEZONE" 4512 calendar component. 4514 Description: This is the label by which a time zone calendar 4515 component is referenced by any iCalendar properties whose value 4516 type is either DATE-TIME or TIME and not intended to specify a UTC 4517 or a "floating" time. The presence of the SOLIDUS character (US- 4518 ASCII decimal 47) as a prefix, indicates that this "TZID" 4519 represents an unique ID in a globally defined time zone registry 4520 (when such registry is defined). 4522 Note: This document does not define a naming convention for 4523 time zone identifiers. Implementers may want to use the naming 4524 conventions defined in existing time zone specifications such 4525 as the public-domain TZ database [TZDB]. The specification of 4526 globally unique time zone identifiers is not addressed by this 4527 document and is left for future study. 4529 Format Definition: This property is defined by the following 4530 notation: 4532 tzid = "TZID" tzidpropparam ":" [tzidprefix] text CRLF 4534 tzidpropparam = *(";" other-param) 4536 ;tzidprefix = "/" 4537 ; Defined previously. Just listed here for reader convenience. 4539 Example: The following are examples of non-globally unique time zone 4540 identifiers: 4542 TZID:America/New_York 4544 TZID:America/Los_Angeles 4546 The following is an example of a fictitious globally unique time 4547 zone identifier: 4549 TZID:/example.org/America/New_York 4551 3.8.3.2. Time Zone Name 4553 Property Name: TZNAME 4555 Purpose: This property specifies the customary designation for a 4556 time zone description. 4558 Value Type: TEXT 4560 Property Parameters: IANA, non-standard, and language property 4561 parameters can be specified on this property. 4563 Conformance: This property can be specified in "STANDARD" and 4564 "DAYLIGHT" sub-components. 4566 Description: This property may be specified in multiple languages; 4567 in order to provide for different language requirements. 4569 Format Definition: This property is defined by the following 4570 notation: 4572 tzname = "TZNAME" tznparam ":" text CRLF 4574 tznparam = *( 4576 ; the following is OPTIONAL, 4577 ; but MUST NOT occur more than once 4579 (";" languageparam) / 4581 ; the following is OPTIONAL, 4582 ; and MAY occur more than once 4584 (";" other-param) 4586 ) 4588 Example: The following are example of this property: 4590 TZNAME:EST 4592 The following is an example of this property when two different 4593 languages for the time zone name are specified: 4595 TZNAME;LANGUAGE=en:EST 4596 TZNAME;LANGUAGE=fr-CA:HNE 4598 3.8.3.3. Time Zone Offset From 4600 Property Name: TZOFFSETFROM 4602 Purpose: This property specifies the offset which is in use prior to 4603 this time zone observance. 4605 Value Type: UTC-OFFSET 4607 Property Parameters: IANA and non-standard property parameters can 4608 be specified on this property. 4610 Conformance: This property MUST be specified in "STANDARD" and 4611 "DAYLIGHT" sub-components. 4613 Description: This property specifies the offset which is in use 4614 prior to this time observance. It is used to calculate the 4615 absolute time at which the transition to a given observance takes 4616 place. This property MUST only be specified in a "VTIMEZONE" 4617 calendar component. A "VTIMEZONE" calendar component MUST include 4618 this property. The property value is a signed numeric indicating 4619 the number of hours and possibly minutes from UTC. Positive 4620 numbers represent time zones east of the prime meridian, or ahead 4621 of UTC. Negative numbers represent time zones west of the prime 4622 meridian, or behind UTC. 4624 Format Definition: This property is defined by the following 4625 notation: 4627 tzoffsetfrom = "TZOFFSETFROM" frmparam ":" utc-offset 4628 CRLF 4630 frmparam = *(";" other-param) 4632 Example: The following are examples of this property: 4634 TZOFFSETFROM:-0500 4636 TZOFFSETFROM:+1345 4638 3.8.3.4. Time Zone Offset To 4640 Property Name: TZOFFSETTO 4642 Purpose: This property specifies the offset which is in use in this 4643 time zone observance. 4645 Value Type: UTC-OFFSET 4647 Property Parameters: IANA and non-standard property parameters can 4648 be specified on this property. 4650 Conformance: This property MUST be specified in "STANDARD" and 4651 "DAYLIGHT" sub-components. 4653 Description: This property specifies the offset which is in use in 4654 this time zone observance. It is used to calculate the absolute 4655 time for the new observance. The property value is a signed 4656 numeric indicating the number of hours and possibly minutes from 4657 UTC. Positive numbers represent time zones east of the prime 4658 meridian, or ahead of UTC. Negative numbers represent time zones 4659 west of the prime meridian, or behind UTC. 4661 Format Definition: This property is defined by the following 4662 notation: 4664 tzoffsetto = "TZOFFSETTO" toparam ":" utc-offset CRLF 4666 toparam = *(";" other-param) 4668 Example: The following are examples of this property: 4670 TZOFFSETTO:-0400 4672 TZOFFSETTO:+1245 4674 3.8.3.5. Time Zone URL 4676 Property Name: TZURL 4678 Purpose: This property provides a means for a "VTIMEZONE" component 4679 to point to a network location that can be used to retrieve an up- 4680 to-date version of itself. 4682 Value Type: URI 4684 Property Parameters: IANA and non-standard property parameters can 4685 be specified on this property. 4687 Conformance: This property can be specified in a "VTIMEZONE" 4688 calendar component. 4690 Description: This property provides a means for a "VTIMEZONE" 4691 component to point to a network location that can be used to 4692 retrieve an up-to-date version of itself. This provides a hook to 4693 handle changes government bodies impose upon time zone 4694 definitions. Retrieval of this resource results in an iCalendar 4695 object containing a single "VTIMEZONE" component and a "METHOD" 4696 property set to PUBLISH. 4698 Format Definition: This property is defined by the following 4699 notation: 4701 tzurl = "TZURL" tzurlparam ":" uri CRLF 4703 tzurlparam = *(";" other-param) 4705 Example: The following is an example of this property: 4707 TZURL:http://timezones.example.org/tz/America-Los_Angeles.ics 4709 3.8.4. Relationship Component Properties 4711 The following properties specify relationship information in calendar 4712 components. 4714 3.8.4.1. Attendee 4716 Property Name: ATTENDEE 4718 Purpose: This property defines an "Attendee" within a calendar 4719 component. 4721 Value Type: CAL-ADDRESS 4723 Property Parameters: IANA, non-standard, language, calendar user 4724 type, group or list membership, participation role, participation 4725 status, RSVP expectation, delegatee, delegator, sent by, common 4726 name or directory entry reference property parameters can be 4727 specified on this property. 4729 Conformance: This property MUST be specified in an iCalendar object 4730 that specifies a group scheduled calendar entity. This property 4731 MUST NOT be specified in an iCalendar object when publishing the 4732 calendar information (e.g., NOT in an iCalendar object that 4733 specifies the publication of a calendar user's busy time, event, 4734 to-do or journal). This property is not specified in an iCalendar 4735 object that specifies only a time zone definition or that defines 4736 calendar components that are not group scheduled components, but 4737 are components only on a single user's calendar. 4739 Description: This property MUST only be specified within calendar 4740 components to specify participants, non-participants and the chair 4741 of a group scheduled calendar entity. The property is specified 4742 within an "EMAIL" category of the "VALARM" calendar component to 4743 specify an email address that is to receive the email type of 4744 iCalendar alarm. 4746 The property parameter "CN" is for the common or displayable name 4747 associated with the calendar address; "ROLE", for the intended 4748 role that the attendee will have in the calendar component; 4749 "PARTSTAT", for the status of the attendee's participation; 4750 "RSVP", for indicating whether the favor of a reply is requested; 4751 "CUTYPE", to indicate the type of calendar user; "MEMBER", to 4752 indicate the groups that the attendee belongs to; "DELEGATED-TO", 4753 to indicate the calendar users that the original request was 4754 delegated to; and "DELEGATED-FROM", to indicate whom the request 4755 was delegated from; "SENT-BY", to indicate whom is acting on 4756 behalf of the "ATTENDEE"; and "DIR", to indicate the URI that 4757 points to the directory information corresponding to the attendee. 4758 These property parameters can be specified on an "ATTENDEE" 4759 property in either a "VEVENT", "VTODO" or "VJOURNAL" calendar 4760 component. They MUST NOT be specified in an "ATTENDEE" property 4761 in a "VFREEBUSY" or "VALARM" calendar component. If the 4762 "LANGUAGE" property parameter is specified, the identified 4763 language applies to the "CN" parameter. 4765 A recipient delegated a request MUST inherit the "RSVP" and "ROLE" 4766 values from the attendee that delegated the request to them. 4768 Multiple attendees can be specified by including multiple 4769 "ATTENDEE" properties within the calendar component. 4771 Format Definition: This property is defined by the following 4772 notation: 4774 attendee = "ATTENDEE" attparam ":" cal-address CRLF 4776 attparam = *( 4778 ; the following are OPTIONAL, 4779 ; but MUST NOT occur more than once 4781 (";" cutypeparam) / (";" memberparam) / 4782 (";" roleparam) / (";" partstatparam) / 4783 (";" rsvpparam) / (";" deltoparam) / 4784 (";" delfromparam) / (";" sentbyparam) / 4785 (";" cnparam) / (";" dirparam) / 4786 (";" languageparam) / 4788 ; the following is OPTIONAL, 4789 ; and MAY occur more than once 4791 (";" other-param) 4793 ) 4795 Example: The following are examples of this property's use for a 4796 to-do: 4798 ATTENDEE;MEMBER="mailto:DEV-GROUP@example.com": 4799 mailto:joecool@example.com 4800 ATTENDEE;DELEGATED-FROM="mailto:immud@example.com": 4801 mailto:ildoit@example.com 4803 The following is an example of this property used for specifying 4804 multiple attendees to an event: 4806 ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;CN=Henry 4807 Cabot:mailto:hcabot@example.com 4808 ATTENDEE;ROLE=REQ-PARTICIPANT;DELEGATED-FROM="mailto:bob@ 4809 example.com";PARTSTAT=ACCEPTED;CN=Jane Doe:mailto:jdoe@ 4810 example.com 4812 The following is an example of this property with a URI to the 4813 directory information associated with the attendee: 4815 ATTENDEE;CN=John Smith;DIR="ldap://example.com:6666/o=ABC% 4816 20Industries,c=US???(cn=Jim%20Dolittle)":mailto:jimdo@ 4817 example.com 4819 The following is an example of this property with "delegatee" and 4820 "delegator" information for an event: 4822 ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;DELEGATED-FROM= 4823 "mailto:iamboss@example.com";CN=Henry Cabot:mailto:hcabot@ 4824 example.com 4825 ATTENDEE;ROLE=NON-PARTICIPANT;PARTSTAT=DELEGATED;DELEGATED-TO= 4826 "mailto:hcabot@example.com";CN=The Big Cheese:mailto:iamboss 4827 @example.com 4828 ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;CN=Jane Doe 4829 :mailto:jdoe@example.com 4831 Example: The following is an example of this property's use when 4832 another calendar user is acting on behalf of the "Attendee": 4834 ATTENDEE;SENT-BY=mailto:jan_doe@example.com;CN=John Smith: 4835 mailto:jsmith@example.com 4837 3.8.4.2. Contact 4839 Property Name: CONTACT 4841 Purpose: This property is used to represent contact information or 4842 alternately a reference to contact information associated with the 4843 calendar component. 4845 Value Type: TEXT 4847 Property Parameters: IANA, non-standard, alternate text 4848 representation and language property parameters can be specified 4849 on this property. 4851 Conformance: This property can be specified in a "VEVENT", "VTODO", 4852 "VJOURNAL" or "VFREEBUSY" calendar component. 4854 Description: The property value consists of textual contact 4855 information. An alternative representation for the property value 4856 can also be specified that refers to a URI pointing to an 4857 alternate form, such as a vCard [RFC2426], for the contact 4858 information. 4860 Format Definition: This property is defined by the following 4861 notation: 4863 contact = "CONTACT" contparam ":" text CRLF 4865 contparam = *( 4866 ; the following are OPTIONAL, 4867 ; but MUST NOT occur more than once 4869 (";" altrepparam) / (";" languageparam) / 4871 ; the following is OPTIONAL, 4872 ; and MAY occur more than once 4874 (";" other-param) 4876 ) 4878 Example: The following is an example of this property referencing 4879 textual contact information: 4881 CONTACT:Jim Dolittle\, ABC Industries\, +1-919-555-1234 4883 The following is an example of this property with an alternate 4884 representation of a LDAP URI to a directory entry containing the 4885 contact information: 4887 CONTACT;ALTREP="ldap://example.com:6666/o=ABC%20Industries\, 4888 c=US???(cn=Jim%20Dolittle)":Jim Dolittle\, ABC Industries\, 4889 +1-919-555-1234 4891 The following is an example of this property with an alternate 4892 representation of a MIME body part containing the contact 4893 information, such as a vCard [RFC2426] embedded in a text/ 4894 directory media type [RFC2425]: 4896 CONTACT;ALTREP="CID:part3.msg970930T083000SILVER@example.com": 4897 Jim Dolittle\, ABC Industries\, +1-919-555-1234 4899 The following is an example of this property referencing a network 4900 resource, such as a vCard [RFC2426] object containing the contact 4901 information: 4903 CONTACT;ALTREP="http://example.com/pdi/jdoe.vcf":Jim 4904 Dolittle\, ABC Industries\, +1-919-555-1234 4906 3.8.4.3. Organizer 4907 Property Name: ORGANIZER 4909 Purpose: This property defines the organizer for a calendar 4910 component. 4912 Value Type: CAL-ADDRESS 4914 Property Parameters: IANA, non-standard, language, common name, 4915 directory entry reference, sent by property parameters can be 4916 specified on this property. 4918 Conformance: This property MUST be specified in an iCalendar object 4919 that specifies a group scheduled calendar entity. This property 4920 MUST be specified in an iCalendar object that specifies the 4921 publication of a calendar user's busy time. This property MUST 4922 NOT be specified in an iCalendar object that specifies only a time 4923 zone definition or that defines calendar components that are not 4924 group scheduled components, but are components only on a single 4925 user's calendar. 4927 Description: This property is specified within the "VEVENT", 4928 "VTODO", "VJOURNAL" calendar components to specify the organizer 4929 of a group scheduled calendar entity. The property is specified 4930 within the "VFREEBUSY" calendar component to specify the calendar 4931 user requesting the free or busy time. When publishing a 4932 "VFREEBUSY" calendar component, the property is used to specify 4933 the calendar that the published busy time came from. 4935 The property has the property parameters "CN", for specifying the 4936 common or display name associated with the "Organizer", "DIR", for 4937 specifying a pointer to the directory information associated with 4938 the "Organizer", "SENT-BY", for specifying another calendar user 4939 that is acting on behalf of the "Organizer". The non-standard 4940 parameters may also be specified on this property. If the 4941 "LANGUAGE" property parameter is specified, the identified 4942 language applies to the "CN" parameter value. 4944 Format Definition: This property is defined by the following 4945 notation: 4947 organizer = "ORGANIZER" orgparam ":" 4948 cal-address CRLF 4950 orgparam = *( 4952 ; the following are OPTIONAL, 4953 ; but MUST NOT occur more than once 4955 (";" cnparam) / (";" dirparam) / (";" sentbyparam) / 4956 (";" languageparam) / 4958 ; the following is OPTIONAL, 4959 ; and MAY occur more than once 4961 (";" other-param) 4963 ) 4965 Example: The following is an example of this property: 4967 ORGANIZER;CN=John Smith:mailto:jsmith@example.com 4969 The following is an example of this property with a pointer to the 4970 directory information associated with the organizer: 4972 ORGANIZER;CN=JohnSmith;DIR="ldap://example.com:6666/o=DC%20Ass 4973 ociates,c=US???(cn=John%20Smith)":mailto:jsmith@example.com 4975 The following is an example of this property used by another 4976 calendar user who is acting on behalf of the organizer, with 4977 responses intended to be sent back to the organizer, not the other 4978 calendar user: 4980 ORGANIZER;SENT-BY="mailto:jane_doe@example.com": 4981 mailto:jsmith@example.com 4983 3.8.4.4. Recurrence ID 4985 Property Name: RECURRENCE-ID 4987 Purpose: This property is used in conjunction with the "UID" and 4988 "SEQUENCE" property to identify a specific instance of a recurring 4989 "VEVENT", "VTODO" or "VJOURNAL" calendar component. The property 4990 value is the original value of the "DTSTART" property of the 4991 recurrence instance. 4993 Value Type: The default value type for this property is DATE-TIME. 4994 The time format can be any of the valid forms defined for a DATE- 4995 TIME value type. See DATE-TIME value type definition for specific 4996 interpretations of the various forms. The value type can be set 4997 to DATE. 4999 Property Parameters: IANA, non-standard, value data type, and time 5000 zone identifier parameters can be specified on this property. 5002 Conformance: This property can be specified in an iCalendar object 5003 containing a recurring calendar component. 5005 Description: The full range of calendar components specified by a 5006 recurrence set is referenced by referring to just the "UID" 5007 property value corresponding to the calendar component. The 5008 "RECURRENCE-ID" property allows the reference to an individual 5009 instance within the recurrence set. 5011 If the value of the "DTSTART" property is a DATE type value, then 5012 the value MUST be the calendar date for the recurrence instance. 5014 The date/time value is set to the time when the original 5015 recurrence instance would occur; meaning that if the intent is to 5016 change a Friday meeting to Thursday, the date/time is still set to 5017 the original Friday meeting. 5019 The "RECURRENCE-ID" property is used in conjunction with the "UID" 5020 and "SEQUENCE" property to identify a particular instance of a 5021 recurring event, to-do or journal. For a given pair of "UID" and 5022 "SEQUENCE" property values, the "RECURRENCE-ID" value for a 5023 recurrence instance is fixed. 5025 Format Definition: This property is defined by the following 5026 notation: 5028 recurid = "RECURRENCE-ID" ridparam ":" ridval CRLF 5030 ridparam = *( 5032 ; the following are OPTIONAL, 5033 ; but MUST NOT occur more than once 5035 (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / 5036 (";" tzidparam) / 5038 ; the following is OPTIONAL, 5039 ; and MAY occur more than once 5041 (";" other-param) 5043 ) 5045 ridval = date-time / date 5046 ;Value MUST match value type 5048 Example: The following are examples of this property: 5050 RECURRENCE-ID;VALUE=DATE:19960401 5052 RECURRENCE-ID:19960120T120000Z 5054 3.8.4.5. Related To 5056 Property Name: RELATED-TO 5058 Purpose: This property is used to represent a relationship or 5059 reference between one calendar component and another. 5061 Value Type: TEXT 5063 Property Parameters: IANA, non-standard, and relationship type 5064 property parameters can be specified on this property. 5066 Conformance: This property can be specified in the "VEVENT", "VTODO" 5067 and "VJOURNAL" calendar components. 5069 Description: The property value consists of the persistent, globally 5070 unique identifier of another calendar component. This value would 5071 be represented in a calendar component by the "UID" property. 5073 By default, the property value points to another calendar 5074 component that has a PARENT relationship to the referencing 5075 object. The "RELTYPE" property parameter is used to either 5076 explicitly state the default PARENT relationship type to the 5077 referenced calendar component or to override the default PARENT 5078 relationship type and specify either a CHILD or SIBLING 5079 relationship. The PARENT relationship indicates that the calendar 5080 component is a subordinate of the referenced calendar component. 5081 The CHILD relationship indicates that the calendar component is a 5082 superior of the referenced calendar component. The SIBLING 5083 relationship indicates that the calendar component is a peer of 5084 the referenced calendar component. 5086 Changes to a calendar component referenced by this property can 5087 have an implicit impact on the related calendar component. For 5088 example, if a group event changes its start or end date or time, 5089 then the related, dependent events will need to have their start 5090 and end dates changed in a corresponding way. Similarly, if a 5091 PARENT calendar component is cancelled or deleted, then there is 5092 an implied impact to the related CHILD calendar components. This 5093 property is intended only to provide information on the 5094 relationship of calendar components. It is up to the target 5095 calendar system to maintain any property implications of this 5096 relationship. 5098 Format Definition: This property is defined by the following 5099 notation: 5101 related = "RELATED-TO" relparam ":" text CRLF 5103 relparam = *( 5105 ; the following is OPTIONAL, 5106 ; but MUST NOT occur more than once 5108 (";" reltypeparam) / 5110 ; the following is OPTIONAL, 5111 ; and MAY occur more than once 5113 (";" other-param) 5115 ) 5117 The following is an example of this property: 5119 RELATED-TO:jsmith.part7.19960817T083000.xyzMail@example.com 5121 RELATED-TO:19960401-080045-4000F192713-0052@example.com 5123 3.8.4.6. Uniform Resource Locator 5125 Property Name: URL 5127 Purpose: This property defines a Uniform Resource Locator (URL) 5128 associated with the iCalendar object. 5130 Value Type: URI 5132 Property Parameters: IANA and non-standard property parameters can 5133 be specified on this property. 5135 Conformance: This property can be specified once in the "VEVENT", 5136 "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components. 5138 Description: This property may be used in a calendar component to 5139 convey a location where a more dynamic rendition of the calendar 5140 information associated with the calendar component can be found. 5141 This memo does not attempt to standardize the form of the URI, nor 5142 the format of the resource pointed to by the property value. If 5143 the URL property and Content-Location MIME header are both 5144 specified, they MUST point to the same resource. 5146 Format Definition: This property is defined by the following 5147 notation: 5149 url = "URL" urlparam ":" uri CRLF 5151 urlparam = *(";" other-param) 5153 Example: The following is an example of this property: 5155 URL:http://example.com/pub/calendars/jsmith/mytime.ics 5157 3.8.4.7. Unique Identifier 5159 Property Name: UID 5161 Purpose: This property defines the persistent, globally unique 5162 identifier for the calendar component. 5164 Value Type: TEXT 5166 Property Parameters: IANA and non-standard property parameters can 5167 be specified on this property. 5169 Conformance: The property MUST be specified in the "VEVENT", 5170 "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components. 5172 Description: The "UID" itself MUST be a globally unique identifier. 5173 The generator of the identifier MUST guarantee that the identifier 5174 is unique. There are several algorithms that can be used to 5175 accomplish this. The identifier is RECOMMENDED to be the 5176 identical syntax to the [RFC2822] addr-spec. A good method to 5177 assure uniqueness is to put the domain name or a domain literal IP 5178 address of the host on which the identifier was created on the 5179 right hand side of the "@", and on the left hand side, put a 5180 combination of the current calendar date and time of day (i.e., 5181 formatted in as a DATE-TIME value) along with some other currently 5182 unique (perhaps sequential) identifier available on the system 5183 (for example, a process id number). Using a date/time value on 5184 the left hand side and a domain name or domain literal on the 5185 right hand side makes it possible to guarantee uniqueness since no 5186 two hosts should be using the same domain name or IP address at 5187 the same time. Though other algorithms will work, it is 5188 RECOMMENDED that the right hand side contain some domain 5189 identifier (either of the host itself or otherwise) such that the 5190 generator of the message identifier can guarantee the uniqueness 5191 of the left hand side within the scope of that domain. 5193 This is the method for correlating scheduling messages with the 5194 referenced "VEVENT", "VTODO", or "VJOURNAL" calendar component. 5196 The full range of calendar components specified by a recurrence 5197 set is referenced by referring to just the "UID" property value 5198 corresponding to the calendar component. The "RECURRENCE-ID" 5199 property allows the reference to an individual instance within the 5200 recurrence set. 5202 This property is an important method for group scheduling 5203 applications to match requests with later replies, modifications 5204 or deletion requests. Calendaring and scheduling applications 5205 MUST generate this property in "VEVENT", "VTODO" and "VJOURNAL" 5206 calendar components to assure interoperability with other group 5207 scheduling applications. This identifier is created by the 5208 calendar system that generates an iCalendar object. 5210 Implementations MUST be able to receive and persist values of at 5211 least 255 octets for this property but MUST NOT truncate values in 5212 the middle of a UTF-8 multi-octet sequence. 5214 Format Definition: This property is defined by the following 5215 notation: 5217 uid = "UID" uidparam ":" text CRLF 5219 uidparam = *(";" other-param) 5221 Example: The following is an example of this property: 5223 UID:19960401T080045Z-4000F192713-0052@example.com 5225 3.8.5. Recurrence Component Properties 5227 The following properties specify recurrence information in calendar 5228 components. 5230 3.8.5.1. Exception Date/Times 5232 Property Name: EXDATE 5234 Purpose: This property defines the list of date/time exceptions for 5235 recurring events, to-dos, journal entries or time zone 5236 definitions. 5238 Value Type: The default value type for this property is DATE-TIME. 5239 The value type can be set to DATE. 5241 Property Parameters: IANA, non-standard, value data type and time 5242 zone identifier property parameters can be specified on this 5243 property. 5245 Conformance: This property can be specified in recurring "VEVENT", 5246 "VTODO", and "VJOURNAL" calendar components as well as in the 5247 "STANDARD" and "DAYLIGHT" sub-components of the "VTIMEZONE" 5248 calendar component. 5250 Description: The exception dates, if specified, are used in 5251 computing the recurrence set. The recurrence set is the complete 5252 set of recurrence instances for a calendar component. The 5253 recurrence set is generated by considering the initial "DTSTART" 5254 property along with the "RRULE", "RDATE", and "EXDATE" properties 5255 contained within the recurring component. The "DTSTART" property 5256 defines the first instance in the recurrence set. The "DTSTART" 5257 property value SHOULD match the pattern of the recurrence rule, if 5258 specified. The recurrence set generated with a "DTSTART" property 5259 value that doesn't match the pattern of the rule is undefined. 5260 The final recurrence set is generated by gathering all of the 5261 start date-times generated by any of the specified "RRULE" and 5262 "RDATE" properties, and then excluding any start date and times 5263 specified by "EXDATE" properties. This implies that start date 5264 and times specified by "EXDATE" properties take precedence over 5265 those specified by inclusion properties (i.e., "RDATE" and 5266 "RRULE"). When duplicate instances are generated by the "RRULE" 5267 and "RDATE" properties, only one recurrence is considered. 5268 Duplicate instances are ignored. 5270 The "EXDATE" property can be used to exclude the value specified 5271 in "DTSTART". However, in such cases the original "DTSTART" date 5272 MUST still be maintained by the calendaring and scheduling system 5273 because the original "DTSTART" value has inherent usage 5274 dependencies by other properties such as the "RECURRENCE-ID". 5276 Format Definition: This property is defined by the following 5277 notation: 5279 exdate = "EXDATE" exdtparam ":" exdtval *("," exdtval) CRLF 5281 exdtparam = *( 5283 ; the following are OPTIONAL, 5284 ; but MUST NOT occur more than once 5286 (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / 5288 (";" tzidparam) / 5290 ; the following is OPTIONAL, 5291 ; and MAY occur more than once 5293 (";" other-param) 5295 ) 5297 exdtval = date-time / date 5298 ;Value MUST match value type 5300 Example: The following is an example of this property: 5302 EXDATE:19960402T010000Z,19960403T010000Z,19960404T010000Z 5304 3.8.5.2. Recurrence Date/Times 5306 Property Name: RDATE 5308 Purpose: This property defines the list of date/times for recurring 5309 events, to-dos, journal entries or time zone definitions. 5311 Value Type: The default value type for this property is DATE-TIME. 5312 The value type can be set to DATE or PERIOD. 5314 Property Parameters: IANA, non-standard, value data type and time 5315 zone identifier property parameters can be specified on this 5316 property. 5318 Conformance: This property can be specified in recurring "VEVENT", 5319 "VTODO", and "VJOURNAL" calendar components as well as in the 5320 "STANDARD" and "DAYLIGHT" sub-components of the "VTIMEZONE" 5321 calendar component. 5323 Description: This property can appear along with the "RRULE" 5324 property to define an aggregate set of repeating occurrences. 5325 When they both appear in a recurring component, the recurrence 5326 instances are defined by the union of occurrences defined by both 5327 the "RDATE" and "RRULE". 5329 The recurrence dates, if specified, are used in computing the 5330 recurrence set. The recurrence set is the complete set of 5331 recurrence instances for a calendar component. The recurrence set 5332 is generated by considering the initial "DTSTART" property along 5333 with the "RRULE", "RDATE", and "EXDATE" properties contained 5334 within the recurring component. The "DTSTART" property defines 5335 the first instance in the recurrence set. The "DTSTART" property 5336 value SHOULD match the pattern of the recurrence rule, if 5337 specified. The recurrence set generated with a "DTSTART" property 5338 value that doesn't match the pattern of the rule is undefined. 5339 The final recurrence set is generated by gathering all of the 5340 start date-times generated by any of the specified "RRULE" and 5341 "RDATE" properties, and then excluding any start date and times 5342 specified by "EXDATE" properties. This implies that start date/ 5343 times specified by "EXDATE" properties take precedence over those 5344 specified by inclusion properties (i.e., "RDATE" and "RRULE"). 5345 Where duplicate instances are generated by the "RRULE" and "RDATE" 5346 properties, only one recurrence is considered. Duplicate 5347 instances are ignored. 5349 Format Definition: This property is defined by the following 5350 notation: 5352 rdate = "RDATE" rdtparam ":" rdtval *("," rdtval) CRLF 5354 rdtparam = *( 5356 ; the following are OPTIONAL, 5357 ; but MUST NOT occur more than once 5359 (";" "VALUE" "=" ("DATE-TIME" / "DATE" / "PERIOD")) / 5360 (";" tzidparam) / 5362 ; the following is OPTIONAL, 5363 ; and MAY occur more than once 5365 (";" other-param) 5367 ) 5369 rdtval = date-time / date / period 5370 ;Value MUST match value type 5372 Example: The following are examples of this property: 5374 RDATE:19970714T123000Z 5375 RDATE;TZID=America/New_York:19970714T083000 5377 RDATE;VALUE=PERIOD:19960403T020000Z/19960403T040000Z, 5378 19960404T010000Z/PT3H 5380 RDATE;VALUE=DATE:19970101,19970120,19970217,19970421 5381 19970526,19970704,19970901,19971014,19971128,19971129,19971225 5383 3.8.5.3. Recurrence Rule 5385 Property Name: RRULE 5387 Purpose: This property defines a rule or repeating pattern for 5388 recurring events, to-dos, journal entries or time zone 5389 definitions. 5391 Value Type: RECUR 5393 Property Parameters: IANA and non-standard property parameters can 5394 be specified on this property. 5396 Conformance: This property can be specified in recurring "VEVENT", 5397 "VTODO" and "VJOURNAL" calendar components as well as in the 5398 "STANDARD" and "DAYLIGHT" sub-components of the "VTIMEZONE" 5399 calendar component, but it SHOULD NOT be specified more than once. 5400 The recurrence set generated with multiple "RRULE" properties is 5401 undefined. 5403 Description: The recurrence rule, if specified, is used in computing 5404 the recurrence set. The recurrence set is the complete set of 5405 recurrence instances for a calendar component. The recurrence set 5406 is generated by considering the initial "DTSTART" property along 5407 with the "RRULE", "RDATE", and "EXDATE" properties contained 5408 within the recurring component. The "DTSTART" property defines 5409 the first instance in the recurrence set. The "DTSTART" property 5410 value SHOULD be synchronized with the recurrence rule, if 5411 specified. The recurrence set generated with a "DTSTART" property 5412 value not synchronized with the recurrence rule is undefined. The 5413 final recurrence set is generated by gathering all of the start 5414 date/times generated by any of the specified "RRULE" and "RDATE" 5415 properties, and then excluding any start date/times specified by 5416 "EXDATE" properties. This implies that start date/times specified 5417 by "EXDATE" properties take precedence over those specified by 5418 inclusion properties (i.e., "RDATE" and "RRULE"). Where duplicate 5419 instances are generated by the "RRULE" and "RDATE" properties, 5420 only one recurrence is considered. Duplicate instances are 5421 ignored. 5423 The "DTSTART" property specified within the iCalendar object 5424 defines the first instance of the recurrence. In most cases, a 5425 "DTSTART" property of DATE-TIME value type used with a recurrence 5426 rule, should be specified as a date with local time and time zone 5427 reference to make sure all the recurrence instances start at the 5428 same local time regardless of time zone changes. 5430 If the duration of the recurring component is specified with the 5431 "DTEND" or "DUE" property, then the same exact duration will apply 5432 to all the members of the generated recurrence set. Else, if the 5433 duration of the recurring component is specified with the 5434 "DURATION" property, then the same nominal duration will apply to 5435 all the members of the generated recurrence set and the exact 5436 duration of each recurrence instance will depend on its specific 5437 start time. For example, recurrence instances of a nominal 5438 duration of one day will have an exact duration of more or less 5439 than 24 hours on a day where a time zone shift occurs. The 5440 duration of a specific recurrence may be modified in an exception 5441 component or simply by using an "RDATE" property of PERIOD value 5442 type. 5444 Format Definition: This property is defined by the following 5445 notation: 5447 rrule = "RRULE" rrulparam ":" recur CRLF 5449 rrulparam = *(";" other-param) 5451 Example: All examples assume the Eastern United States time zone. 5453 Daily for 10 occurrences: 5455 DTSTART;TZID=America/New_York:19970902T090000 5456 RRULE:FREQ=DAILY;COUNT=10 5458 ==> (1997 9:00 AM EDT) September 2-11 5460 Daily until December 24, 1997: 5462 DTSTART;TZID=America/New_York:19970902T090000 5463 RRULE:FREQ=DAILY;UNTIL=19971224T000000Z 5465 ==> (1997 9:00 AM EDT) September 2-30;October 1-25 5466 (1997 9:00 AM EST) October 26-31;November 1-30;December 1-23 5468 Every other day - forever: 5470 DTSTART;TZID=America/New_York:19970902T090000 5471 RRULE:FREQ=DAILY;INTERVAL=2 5473 ==> (1997 9:00 AM EDT) September 2,4,6,8...24,26,28,30; 5474 October 2,4,6...20,22,24 5475 (1997 9:00 AM EST) October 26,28,30; 5476 November 1,3,5,7...25,27,29; 5477 December 1,3,... 5479 Every 10 days, 5 occurrences: 5481 DTSTART;TZID=America/New_York:19970902T090000 5482 RRULE:FREQ=DAILY;INTERVAL=10;COUNT=5 5484 ==> (1997 9:00 AM EDT) September 2,12,22; 5485 October 2,12 5487 Everyday in January, for 3 years: 5489 DTSTART;TZID=America/New_York:19980101T090000 5491 RRULE:FREQ=YEARLY;UNTIL=20000131T140000Z; 5492 BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA 5493 or 5494 RRULE:FREQ=DAILY;UNTIL=20000131T140000Z;BYMONTH=1 5496 ==> (1998 9:00 AM EST)January 1-31 5497 (1999 9:00 AM EST)January 1-31 5498 (2000 9:00 AM EST)January 1-31 5500 Weekly for 10 occurrences 5502 DTSTART;TZID=America/New_York:19970902T090000 5503 RRULE:FREQ=WEEKLY;COUNT=10 5505 ==> (1997 9:00 AM EDT) September 2,9,16,23,30;October 7,14,21 5506 (1997 9:00 AM EST) October 28;November 4 5508 Weekly until December 24, 1997 5510 DTSTART;TZID=America/New_York:19970902T090000 5511 RRULE:FREQ=WEEKLY;UNTIL=19971224T000000Z 5513 ==> (1997 9:00 AM EDT) September 2,9,16,23,30; 5514 October 7,14,21 5515 (1997 9:00 AM EST) October 28; 5516 November 4,11,18,25; 5517 December 2,9,16,23 5519 Every other week - forever: 5521 DTSTART;TZID=America/New_York:19970902T090000 5522 RRULE:FREQ=WEEKLY;INTERVAL=2;WKST=SU 5524 ==> (1997 9:00 AM EDT) September 2,16,30; 5525 October 14 5526 (1997 9:00 AM EST) October 28; 5527 November 11,25; 5528 December 9,23 5529 (1998 9:00 AM EST) January 6,20; 5530 February 3, 17 5531 ... 5533 Weekly on Tuesday and Thursday for 5 weeks: 5535 DTSTART;TZID=America/New_York:19970902T090000 5536 RRULE:FREQ=WEEKLY;UNTIL=19971007T000000Z;WKST=SU;BYDAY=TU,TH 5538 or 5540 RRULE:FREQ=WEEKLY;COUNT=10;WKST=SU;BYDAY=TU,TH 5542 ==> (1997 9:00 AM EDT) September 2,4,9,11,16,18,23,25,30; 5543 October 2 5545 Every other week on Monday, Wednesday and Friday until December 5546 24, 1997, starting on Monday, September 1, 1997: 5548 DTSTART;TZID=America/New_York:19970901T090000 5549 RRULE:FREQ=WEEKLY;INTERVAL=2;UNTIL=19971224T000000Z;WKST=SU; 5550 BYDAY=MO,WE,FR 5552 ==> (1997 9:00 AM EDT) September 1,3,5,15,17,19,29; 5553 October 1,3,13,15,17 5554 (1997 9:00 AM EST) October 27,29,31; 5555 November 10,12,14,24,26,28; 5556 December 8,10,12,22 5558 Every other week on Tuesday and Thursday, for 8 occurrences: 5560 DTSTART;TZID=America/New_York:19970902T090000 5561 RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=8;WKST=SU;BYDAY=TU,TH 5563 ==> (1997 9:00 AM EDT) September 2,4,16,18,30; 5564 October 2,14,16 5566 Monthly on the 1st Friday for ten occurrences: 5568 DTSTART;TZID=America/New_York:19970905T090000 5569 RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR 5571 ==> (1997 9:00 AM EDT) September 5;October 3 5572 (1997 9:00 AM EST) November 7;December 5 5573 (1998 9:00 AM EST) January 2;February 6;March 6;April 3 5574 (1998 9:00 AM EDT) May 1;June 5 5576 Monthly on the 1st Friday until December 24, 1997: 5578 DTSTART;TZID=America/New_York:19970905T090000 5579 RRULE:FREQ=MONTHLY;UNTIL=19971224T000000Z;BYDAY=1FR 5581 ==> (1997 9:00 AM EDT) September 5; October 3 5582 (1997 9:00 AM EST) November 7; December 5 5584 Every other month on the 1st and last Sunday of the month for 10 5585 occurrences: 5587 DTSTART;TZID=America/New_York:19970907T090000 5588 RRULE:FREQ=MONTHLY;INTERVAL=2;COUNT=10;BYDAY=1SU,-1SU 5590 ==> (1997 9:00 AM EDT) September 7,28 5591 (1997 9:00 AM EST) November 2,30 5592 (1998 9:00 AM EST) January 4,25;March 1,29 5593 (1998 9:00 AM EDT) May 3,31 5595 Monthly on the second to last Monday of the month for 6 months: 5597 DTSTART;TZID=America/New_York:19970922T090000 5598 RRULE:FREQ=MONTHLY;COUNT=6;BYDAY=-2MO 5600 ==> (1997 9:00 AM EDT) September 22;October 20 5601 (1997 9:00 AM EST) November 17;December 22 5602 (1998 9:00 AM EST) January 19;February 16 5604 Monthly on the third to the last day of the month, forever: 5606 DTSTART;TZID=America/New_York:19970928T090000 5607 RRULE:FREQ=MONTHLY;BYMONTHDAY=-3 5609 ==> (1997 9:00 AM EDT) September 28 5610 (1997 9:00 AM EST) October 29;November 28;December 29 5611 (1998 9:00 AM EST) January 29;February 26 5612 ... 5614 Monthly on the 2nd and 15th of the month for 10 occurrences: 5616 DTSTART;TZID=America/New_York:19970902T090000 5617 RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=2,15 5619 ==> (1997 9:00 AM EDT) September 2,15;October 2,15 5620 (1997 9:00 AM EST) November 2,15;December 2,15 5621 (1998 9:00 AM EST) January 2,15 5623 Monthly on the first and last day of the month for 10 occurrences: 5625 DTSTART;TZID=America/New_York:19970930T090000 5626 RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=1,-1 5628 ==> (1997 9:00 AM EDT) September 30;October 1 5629 (1997 9:00 AM EST) October 31;November 1,30;December 1,31 5630 (1998 9:00 AM EST) January 1,31;February 1 5632 Every 18 months on the 10th thru 15th of the month for 10 5633 occurrences: 5635 DTSTART;TZID=America/New_York:19970910T090000 5636 RRULE:FREQ=MONTHLY;INTERVAL=18;COUNT=10;BYMONTHDAY=10,11,12, 5637 13,14,15 5639 ==> (1997 9:00 AM EDT) September 10,11,12,13,14,15 5640 (1999 9:00 AM EST) March 10,11,12,13 5642 Every Tuesday, every other month: 5644 DTSTART;TZID=America/New_York:19970902T090000 5645 RRULE:FREQ=MONTHLY;INTERVAL=2;BYDAY=TU 5647 ==> (1997 9:00 AM EDT) September 2,9,16,23,30 5648 (1997 9:00 AM EST) November 4,11,18,25 5649 (1998 9:00 AM EST) January 6,13,20,27;March 3,10,17,24,31 5650 ... 5652 Yearly in June and July for 10 occurrences: 5654 DTSTART;TZID=America/New_York:19970610T090000 5655 RRULE:FREQ=YEARLY;COUNT=10;BYMONTH=6,7 5657 ==> (1997 9:00 AM EDT) June 10;July 10 5658 (1998 9:00 AM EDT) June 10;July 10 5659 (1999 9:00 AM EDT) June 10;July 10 5660 (2000 9:00 AM EDT) June 10;July 10 5661 (2001 9:00 AM EDT) June 10;July 10 5663 Note: Since none of the BYDAY, BYMONTHDAY or BYYEARDAY 5664 components are specified, the day is gotten from "DTSTART" 5666 Every other year on January, February, and March for 10 5667 occurrences: 5669 DTSTART;TZID=America/New_York:19970310T090000 5670 RRULE:FREQ=YEARLY;INTERVAL=2;COUNT=10;BYMONTH=1,2,3 5672 ==> (1997 9:00 AM EST) March 10 5673 (1999 9:00 AM EST) January 10;February 10;March 10 5674 (2001 9:00 AM EST) January 10;February 10;March 10 5675 (2003 9:00 AM EST) January 10;February 10;March 10 5677 Every 3rd year on the 1st, 100th and 200th day for 10 occurrences: 5679 DTSTART;TZID=America/New_York:19970101T090000 5680 RRULE:FREQ=YEARLY;INTERVAL=3;COUNT=10;BYYEARDAY=1,100,200 5682 ==> (1997 9:00 AM EST) January 1 5683 (1997 9:00 AM EDT) April 10;July 19 5684 (2000 9:00 AM EST) January 1 5685 (2000 9:00 AM EDT) April 9;July 18 5686 (2003 9:00 AM EST) January 1 5687 (2003 9:00 AM EDT) April 10;July 19 5688 (2006 9:00 AM EST) January 1 5690 Every 20th Monday of the year, forever: 5692 DTSTART;TZID=America/New_York:19970519T090000 5693 RRULE:FREQ=YEARLY;BYDAY=20MO 5695 ==> (1997 9:00 AM EDT) May 19 5696 (1998 9:00 AM EDT) May 18 5697 (1999 9:00 AM EDT) May 17 5698 ... 5700 Monday of week number 20 (where the default start of the week is 5701 Monday), forever: 5703 DTSTART;TZID=America/New_York:19970512T090000 5704 RRULE:FREQ=YEARLY;BYWEEKNO=20;BYDAY=MO 5706 ==> (1997 9:00 AM EDT) May 12 5707 (1998 9:00 AM EDT) May 11 5708 (1999 9:00 AM EDT) May 17 5709 ... 5711 Every Thursday in March, forever: 5713 DTSTART;TZID=America/New_York:19970313T090000 5714 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=TH 5716 ==> (1997 9:00 AM EST) March 13,20,27 5717 (1998 9:00 AM EST) March 5,12,19,26 5718 (1999 9:00 AM EST) March 4,11,18,25 5719 ... 5721 Every Thursday, but only during June, July, and August, forever: 5723 DTSTART;TZID=America/New_York:19970605T090000 5724 RRULE:FREQ=YEARLY;BYDAY=TH;BYMONTH=6,7,8 5726 ==> (1997 9:00 AM EDT) June 5,12,19,26;July 3,10,17,24,31; 5727 August 7,14,21,28 5728 (1998 9:00 AM EDT) June 4,11,18,25;July 2,9,16,23,30; 5729 August 6,13,20,27 5730 (1999 9:00 AM EDT) June 3,10,17,24;July 1,8,15,22,29; 5731 August 5,12,19,26 5732 ... 5734 Every Friday the 13th, forever: 5736 DTSTART;TZID=America/New_York:19970902T090000 5737 EXDATE;TZID=America/New_York:19970902T090000 5738 RRULE:FREQ=MONTHLY;BYDAY=FR;BYMONTHDAY=13 5740 ==> (1998 9:00 AM EST) February 13;March 13;November 13 5741 (1999 9:00 AM EDT) August 13 5742 (2000 9:00 AM EDT) October 13 5743 ... 5745 The first Saturday that follows the first Sunday of the month, 5746 forever: 5748 DTSTART;TZID=America/New_York:19970913T090000 5749 RRULE:FREQ=MONTHLY;BYDAY=SA;BYMONTHDAY=7,8,9,10,11,12,13 5751 ==> (1997 9:00 AM EDT) September 13;October 11 5752 (1997 9:00 AM EST) November 8;December 13 5753 (1998 9:00 AM EST) January 10;February 7;March 7 5754 (1998 9:00 AM EDT) April 11;May 9;June 13... 5755 ... 5757 Every four years, the first Tuesday after a Monday in November, 5758 forever (U.S. Presidential Election day): 5760 DTSTART;TZID=America/New_York:19961105T090000 5761 RRULE:FREQ=YEARLY;INTERVAL=4;BYMONTH=11;BYDAY=TU; 5762 BYMONTHDAY=2,3,4,5,6,7,8 5764 ==> (1996 9:00 AM EST) November 5 5765 (2000 9:00 AM EST) November 7 5766 (2004 9:00 AM EST) November 2 5767 ... 5769 The 3rd instance into the month of one of Tuesday, Wednesday or 5770 Thursday, for the next 3 months: 5772 DTSTART;TZID=America/New_York:19970904T090000 5773 RRULE:FREQ=MONTHLY;COUNT=3;BYDAY=TU,WE,TH;BYSETPOS=3 5775 ==> (1997 9:00 AM EDT) September 4;October 7 5776 (1997 9:00 AM EST) November 6 5778 The 2nd to last weekday of the month: 5780 DTSTART;TZID=America/New_York:19970929T090000 5781 RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-2 5783 ==> (1997 9:00 AM EDT) September 29 5784 (1997 9:00 AM EST) October 30;November 27;December 30 5785 (1998 9:00 AM EST) January 29;February 26;March 30 5786 ... 5788 Every 3 hours from 9:00 AM to 5:00 PM on a specific day: 5790 DTSTART;TZID=America/New_York:19970902T090000 5791 RRULE:FREQ=HOURLY;INTERVAL=3;UNTIL=19970902T170000Z 5793 ==> (September 2, 1997 EDT) 09:00,12:00,15:00 5795 Every 15 minutes for 6 occurrences: 5797 DTSTART;TZID=America/New_York:19970902T090000 5798 RRULE:FREQ=MINUTELY;INTERVAL=15;COUNT=6 5800 ==> (September 2, 1997 EDT) 09:00,09:15,09:30,09:45,10:00,10:15 5802 Every hour and a half for 4 occurrences: 5804 DTSTART;TZID=America/New_York:19970902T090000 5805 RRULE:FREQ=MINUTELY;INTERVAL=90;COUNT=4 5807 ==> (September 2, 1997 EDT) 09:00,10:30;12:00;13:30 5809 Every 20 minutes from 9:00 AM to 4:40 PM every day: 5811 DTSTART;TZID=America/New_York:19970902T090000 5812 RRULE:FREQ=DAILY;BYHOUR=9,10,11,12,13,14,15,16;BYMINUTE=0,20,40 5813 or 5814 RRULE:FREQ=MINUTELY;INTERVAL=20;BYHOUR=9,10,11,12,13,14,15,16 5816 ==> (September 2, 1997 EDT) 9:00,9:20,9:40,10:00,10:20, 5817 ... 16:00,16:20,16:40 5818 (September 3, 1997 EDT) 9:00,9:20,9:40,10:00,10:20, 5819 ...16:00,16:20,16:40 5820 ... 5822 An example where the days generated makes a difference because of 5823 WKST: 5825 DTSTART;TZID=America/New_York:19970805T090000 5826 RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=4;BYDAY=TU,SU;WKST=MO 5828 ==> (1997 EDT) August 5,10,19,24 5830 changing only WKST from MO to SU, yields different results... 5832 DTSTART;TZID=America/New_York:19970805T090000 5833 RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=4;BYDAY=TU,SU;WKST=SU 5835 ==> (1997 EDT) August 5,17,19,31 5837 An example where an invalid date (i.e., February 30) is ignored. 5839 DTSTART;TZID=America/New_York:20070115T090000 5840 RRULE:FREQ=MONTHLY;BYMONTHDAY=15,30;COUNT=5 5842 ==> (2007 EST) January 15,30 5843 (2007 EST) February 15 5844 (2007 EDT) March 15,30 5846 3.8.6. Alarm Component Properties 5848 The following properties specify alarm information in calendar 5849 components. 5851 3.8.6.1. Action 5853 Property Name: ACTION 5855 Purpose: This property defines the action to be invoked when an 5856 alarm is triggered. 5858 Value Type: TEXT 5860 Property Parameters: IANA and non-standard property parameters can 5861 be specified on this property. 5863 Conformance: This property MUST be specified once in a "VALARM" 5864 calendar component. 5866 Description: Each "VALARM" calendar component has a particular type 5867 of action associated with it. This property specifies the type of 5868 action. 5870 Format Definition: This property is defined by the following 5871 notation: 5873 action = "ACTION" actionparam ":" actionvalue CRLF 5875 actionparam = *(";" other-param) 5877 actionvalue = "AUDIO" / "DISPLAY" / "EMAIL" 5878 / iana-token / x-name 5880 Example: The following are examples of this property in a "VALARM" 5881 calendar component: 5883 ACTION:AUDIO 5885 ACTION:DISPLAY 5887 3.8.6.2. Repeat Count 5888 Property Name: REPEAT 5890 Purpose: This property defines the number of time the alarm should 5891 be repeated, after the initial trigger. 5893 Value Type: INTEGER 5895 Property Parameters: IANA and non-standard property parameters can 5896 be specified on this property. 5898 Conformance: This property can be specified in a "VALARM" calendar 5899 component. 5901 Description: If the alarm triggers more than once, then this 5902 property MUST be specified along with the "DURATION" property. 5904 Format Definition: This property is defined by the following 5905 notation: 5907 repeat = "REPEAT" repparam ":" integer CRLF 5908 ;Default is "0", zero. 5910 repparam = *(";" other-param) 5912 Example: The following is an example of this property for an alarm 5913 that repeats 4 additional times with a 5 minute delay after the 5914 initial triggering of the alarm: 5916 REPEAT:4 5917 DURATION:PT5M 5919 3.8.6.3. Trigger 5921 Property Name: TRIGGER 5923 Purpose: This property specifies when an alarm will trigger. 5925 Value Type: The default value type is DURATION. The value type can 5926 be set to a DATE-TIME value type, in which case the value MUST 5927 specify a UTC formatted DATE-TIME value. 5929 Property Parameters: IANA, non-standard, value data type, time zone 5930 identifier or trigger relationship property parameters can be 5931 specified on this property. The trigger relationship property 5932 parameter MUST only be specified when the value type is 5933 "DURATION". 5935 Conformance: This property MUST be specified in the "VALARM" 5936 calendar component. 5938 Description: This property defines when an alarm will trigger. The 5939 default value type is DURATION, specifying a relative time for the 5940 trigger of the alarm. The default duration is relative to the 5941 start of an event or to-do that the alarm is associated with. The 5942 duration can be explicitly set to trigger from either the end or 5943 the start of the associated event or to-do with the "RELATED" 5944 parameter. A value of START will set the alarm to trigger off the 5945 start of the associated event or to-do. A value of END will set 5946 the alarm to trigger off the end of the associated event or to-do. 5948 Either a positive or negative duration may be specified for the 5949 "TRIGGER" property. An alarm with a positive duration is 5950 triggered after the associated start or end of the event or to-do. 5951 An alarm with a negative duration is triggered before the 5952 associated start or end of the event or to-do. 5954 The "RELATED" property parameter is not valid if the value type of 5955 the property is set to DATE-TIME (i.e., for an absolute date and 5956 time alarm trigger). If a value type of DATE-TIME is specified, 5957 then the property value MUST be specified in the UTC time format. 5958 If an absolute trigger is specified on an alarm for a recurring 5959 event or to-do, then the alarm will only trigger for the specified 5960 absolute date/time, along with any specified repeating instances. 5962 If the trigger is set relative to START, then the "DTSTART" 5963 property MUST be present in the associated "VEVENT" or "VTODO" 5964 calendar component. If an alarm is specified for an event with 5965 the trigger set relative to the END, then the "DTEND" property or 5966 the "DTSTART" and "DURATION " properties MUST be present in the 5967 associated "VEVENT" calendar component. If the alarm is specified 5968 for a to-do with a trigger set relative to the END, then either 5969 the "DUE" property or the "DTSTART" and "DURATION " properties 5970 MUST be present in the associated "VTODO" calendar component. 5972 Alarms specified in an event or to-do which is defined in terms of 5973 a DATE value type will be triggered relative to 00:00:00 of the 5974 user's configured time zone on the specified date, or relative to 5975 00:00:00 UTC on the specified date if no configured time zone can 5976 be found for the user. For example, if "DTSTART" is a DATE value 5977 set to 19980205 then the duration trigger will be relative to 5978 19980205T000000 America/New_York for a user configured with the 5979 America/New_York time zone. 5981 Format Definition: This property is defined by the following 5982 notation: 5984 trigger = "TRIGGER" (trigrel / trigabs) CRLF 5986 trigrel = *( 5988 ; the following are OPTIONAL, 5989 ; but MUST NOT occur more than once 5991 (";" "VALUE" "=" "DURATION") / 5992 (";" trigrelparam) / 5994 ; the following is OPTIONAL, 5995 ; and MAY occur more than once 5997 (";" other-param) 5998 ) ":" dur-value 6000 trigabs = *( 6002 ; the following is REQUIRED, 6003 ; but MUST NOT occur more than once 6005 (";" "VALUE" "=" "DATE-TIME") / 6007 ; the following is OPTIONAL, 6008 ; and MAY occur more than once 6010 (";" other-param) 6012 ) ":" date-time 6014 Example: A trigger set 15 minutes prior to the start of the event or 6015 to-do. 6017 TRIGGER:-PT15M 6019 A trigger set 5 minutes after the end of an event or the due date 6020 of a to-do. 6022 TRIGGER;RELATED=END:PT5M 6024 A trigger set to an absolute date/time. 6026 TRIGGER;VALUE=DATE-TIME:19980101T050000Z 6028 3.8.7. Change Management Component Properties 6030 The following properties specify change management information in 6031 calendar components. 6033 3.8.7.1. Date/Time Created 6035 Property Name: CREATED 6037 Purpose: This property specifies the date and time that the calendar 6038 information was created by the calendar user agent in the calendar 6039 store. 6041 Note: This is analogous to the creation date and time for a 6042 file in the file system. 6044 Value Type: DATE-TIME 6046 Property Parameters: IANA and non-standard property parameters can 6047 be specified on this property. 6049 Conformance: The property can be specified once in "VEVENT", "VTODO" 6050 or "VJOURNAL" calendar components. 6052 Description: The date and time is a UTC value. 6054 Format Definition: This property is defined by the following 6055 notation: 6057 created = "CREATED" creaparam ":" date-time CRLF 6059 creaparam = *(";" other-param) 6061 Example: The following is an example of this property: 6063 CREATED:19960329T133000Z 6065 3.8.7.2. Date/Time Stamp 6067 Property Name: DTSTAMP 6069 Purpose: This property indicates the date/time that the instance of 6070 the iCalendar object was created. 6072 Value Type: DATE-TIME 6073 Property Parameters: IANA and non-standard property parameters can 6074 be specified on this property. 6076 Conformance: This property MUST be included in the "VEVENT", 6077 "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components. 6079 Description: The value MUST be specified in the UTC time format. 6081 This property is also useful to protocols such as 6082 [I-D.ietf-calsify-rfc2447bis] that have inherent latency issues 6083 with the delivery of content. This property will assist in the 6084 proper sequencing of messages containing iCalendar objects. 6086 This property is different than the "CREATED" and "LAST-MODIFIED" 6087 properties. These two properties are used to specify when the 6088 particular calendar data in the calendar store was created and 6089 last modified. This is different than when the iCalendar object 6090 representation of the calendar service information was created or 6091 last modified. 6093 Format Definition: This property is defined by the following 6094 notation: 6096 dtstamp = "DTSTAMP" stmparam ":" date-time CRLF 6098 stmparam = *(";" other-param) 6100 Example: 6102 DTSTAMP:19971210T080000Z 6104 3.8.7.3. Last Modified 6106 Property Name: LAST-MODIFIED 6108 Purpose: This property specifies the date and time that the 6109 information associated with the calendar component was last 6110 revised in the calendar store. 6112 Note: This is analogous to the modification date and time for a 6113 file in the file system. 6115 Value Type: DATE-TIME 6117 Property Parameters: IANA and non-standard property parameters can 6118 be specified on this property. 6120 Conformance: This property can be specified in the "VEVENT", 6121 "VTODO", "VJOURNAL" or "VTIMEZONE" calendar components. 6123 Description: The property value MUST be specified in the UTC time 6124 format. 6126 Format Definition: This property is defined by the following 6127 notation: 6129 last-mod = "LAST-MODIFIED" lstparam ":" date-time CRLF 6131 lstparam = *(";" other-param) 6133 Example: The following is an example of this property: 6135 LAST-MODIFIED:19960817T133000Z 6137 3.8.7.4. Sequence Number 6139 Property Name: SEQUENCE 6141 Purpose: This property defines the revision sequence number of the 6142 calendar component within a sequence of revisions. 6144 Value Type: INTEGER 6146 Property Parameters: IANA and non-standard property parameters can 6147 be specified on this property. 6149 Conformance: The property can be specified in "VEVENT", "VTODO" or 6150 "VJOURNAL" calendar component. 6152 Description: When a calendar component is created, its sequence 6153 number is zero (US-ASCII decimal 48). It is monotonically 6154 incremented by the "Organizer's" CUA each time the "Organizer" 6155 makes a significant revision to the calendar component. When the 6156 "Organizer" makes changes to one of the following properties, the 6157 sequence number MUST be incremented: 6159 * "DTSTART" 6161 * "DTEND" 6163 * "DURATION" 6165 * "DUE" 6166 * "RDATE" 6168 * "RRULE" 6170 * "EXDATE" 6172 * "STATUS" 6174 In addition, changes made by the "Organizer" to other properties 6175 can also force the sequence number to be incremented. The 6176 "Organizer" CUA MUST increment the sequence number whenever it 6177 makes changes to properties in the calendar component that the 6178 "Organizer" deems will jeopardize the validity of the 6179 participation status of the "Attendees". For example, changing 6180 the location of a meeting from one locale to another distant 6181 locale could effectively impact the participation status of the 6182 "Attendees". 6184 The "Organizer" includes this property in an iCalendar object that 6185 it sends to an "Attendee" to specify the current version of the 6186 calendar component. 6188 The "Attendee" includes this property in an iCalendar object that 6189 it sends to the "Organizer" to specify the version of the calendar 6190 component that the "Attendee" is referring to. 6192 A change to the sequence number is not the mechanism that an 6193 "Organizer" uses to request a response from the "Attendees". The 6194 "RSVP" parameter on the "ATTENDEE" property is used by the 6195 "Organizer" to indicate that a response from the "Attendees" is 6196 requested. 6198 Format Definition: This property is defined by the following 6199 notation: 6201 seq = "SEQUENCE" seqparam ":" integer CRLF 6202 ; Default is "0" 6204 seqparam = *(";" other-param) 6206 Example: The following is an example of this property for a calendar 6207 component that was just created by the "Organizer": 6209 SEQUENCE:0 6211 The following is an example of this property for a calendar 6212 component that has been revised two different times by the 6213 "Organizer": 6215 SEQUENCE:2 6217 3.8.8. Miscellaneous Component Properties 6219 The following properties specify information about a number of 6220 miscellaneous features of calendar components. 6222 3.8.8.1. IANA Properties 6224 Property Name: An IANA registered property name 6226 Value Type: The default value type is TEXT. The value type can be 6227 set to any value type. 6229 Property Parameters: Any parameter can be specified on this 6230 property. 6232 Description: This specification allows other properties registered 6233 with IANA to be specified in any calendar components. Compliant 6234 applications are expected to be able to parse these other IANA 6235 registered properties but can ignore them. 6237 Format Definition: This property is defined by the following 6238 notation: 6240 iana-prop = iana-token *(";" icalparameter) ":" value CRLF 6242 Example: The following are examples of properties that might be 6243 registered to IANA: 6245 DRESSCODE:CASUAL 6247 NON-SMOKING;VALUE=BOOLEAN:TRUE 6249 3.8.8.2. Non-standard Properties 6251 Property Name: Any property name with a "X-" prefix 6253 Purpose: This class of property provides a framework for defining 6254 non-standard properties. 6256 Value Type: The default value type is TEXT. The value type can be 6257 set to any value type. 6259 Property Parameters: IANA, non-standard and language property 6260 parameters can be specified on this property. 6262 Conformance: This property can be specified in any calendar 6263 component. 6265 Description: The MIME Calendaring and Scheduling Content Type 6266 provides a "standard mechanism for doing non-standard things". 6267 This extension support is provided for implementers to "push the 6268 envelope" on the existing version of the memo. Extension 6269 properties are specified by property and/or property parameter 6270 names that have the prefix text of "X-" (the two character 6271 sequence: LATIN CAPITAL LETTER X character followed by the HYPHEN- 6272 MINUS character). It is recommended that vendors concatenate onto 6273 this sentinel another short prefix text to identify the vendor. 6274 This will facilitate readability of the extensions and minimize 6275 possible collision of names between different vendors. User 6276 agents that support this content type are expected to be able to 6277 parse the extension properties and property parameters but can 6278 ignore them. 6280 At present, there is no registration authority for names of 6281 extension properties and property parameters. The value type for 6282 this property is TEXT. Optionally, the value type can be any of 6283 the other valid value types. 6285 Format Definition: This property is defined by the following 6286 notation: 6288 x-prop = x-name *(";" icalparameter) ":" value CRLF 6290 Example: The following might be the ABC vendor's extension for an 6291 audio-clip form of subject property: 6293 X-ABC-MMSUBJ;VALUE=URI;FMTTYPE=audio/basic:http://www.example. 6294 org/mysubj.au 6296 3.8.8.3. Request Status 6298 Property Name: REQUEST-STATUS 6300 Purpose: This property defines the status code returned for a 6301 scheduling request. 6303 Value Type: TEXT 6305 Property Parameters: IANA, non-standard and language property 6306 parameters can be specified on this property. 6308 Conformance: The property can be specified in "VEVENT", "VTODO", 6309 "VJOURNAL" or "VFREEBUSY" calendar component. 6311 Description: This property is used to return status code information 6312 related to the processing of an associated iCalendar object. The 6313 value type for this property is TEXT. 6315 The value consists of a short return status component, a longer 6316 return status description component, and optionally a status- 6317 specific data component. The components of the value are 6318 separated by the SEMICOLON character (US-ASCII decimal 59). 6320 The short return status is a PERIOD character (US-ASCII decimal 6321 46) separated pair or 3-tuple of integers. For example, "3.1" or 6322 "3.1.1". The successive levels of integers provide for a 6323 successive level of status code granularity. 6325 The following are initial classes for the return status code. 6326 Individual iCalendar object methods will define specific return 6327 status codes for these classes. In addition, other classes for 6328 the return status code may be defined using the registration 6329 process defined later in this memo. 6331 |==============+===============================================| 6332 | Short Return | Longer Return Status Description | 6333 | Status Code | | 6334 |==============+===============================================| 6335 | 1.xx | Preliminary success. This class of status | 6336 | | of status code indicates that the request has | 6337 | | request has been initially processed but that | 6338 | | completion is pending. | 6339 |==============+===============================================| 6340 | 2.xx | Successful. This class of status code | 6341 | | indicates that the request was completed | 6342 | | successfuly. However, the exact status code | 6343 | | can indicate that a fallback has been taken. | 6344 |==============+===============================================| 6345 | 3.xx | Client Error. This class of status code | 6346 | | indicates that the request was not successful.| 6347 | | The error is the result of either a syntax or | 6348 | | a semantic error in the client formatted | 6349 | | request. Request should not be retried until | 6350 | | the condition in the request is corrected. | 6351 |==============+===============================================| 6352 | 4.xx | Scheduling Error. This class of status code | 6353 | | indicates that the request was not successful.| 6354 | | Some sort of error occurred within the | 6355 | | calendaring and scheduling service, not | 6356 | | directly related to the request itself. | 6357 |==============+===============================================| 6359 Format Definition: This property is defined by the following 6360 notation: 6362 rstatus = "REQUEST-STATUS" rstatparam ":" 6363 statcode ";" statdesc [";" extdata] 6365 rstatparam = *( 6367 ; the following is OPTIONAL, 6368 ; but MUST NOT occur more than once 6370 (";" languageparam) / 6372 ; the following is OPTIONAL, 6373 ; and MAY occur more than once 6375 (";" other-param) 6377 ) 6379 statcode = 1*DIGIT 1*2("." 1*DIGIT) 6380 ;Hierarchical, numeric return status code 6382 statdesc = text 6383 ;Textual status description 6385 extdata = text 6386 ;Textual exception data. For example, the offending property 6387 ;name and value or complete property line. 6389 Example: The following are some possible examples of this property. 6391 The COMMA and SEMICOLON separator characters in the property value 6392 are BACKSLASH character escaped because they appear in a text 6393 value. 6395 REQUEST-STATUS:2.0;Success 6397 REQUEST-STATUS:3.1;Invalid property value;DTSTART:96-Apr-01 6399 REQUEST-STATUS:2.8; Success\, repeating event ignored. Scheduled 6400 as a single event.;RRULE:FREQ=WEEKLY\;INTERVAL=2 6402 REQUEST-STATUS:4.1;Event conflict. Date/time is busy. 6404 REQUEST-STATUS:3.7;Invalid calendar user;ATTENDEE: 6405 mailto:jsmith@example.com 6407 4. iCalendar Object Examples 6409 The following examples are provided as an informational source of 6410 illustrative iCalendar objects consistent with this content type. 6412 The following example specifies a three-day conference that begins at 6413 2:30 P.M. UTC, September 18, 1996 and end at 10:00 P.M. UTC, 6414 September 20, 1996. 6416 BEGIN:VCALENDAR 6417 PRODID:-//xyz Corp//NONSGML PDA Calendar Version 1.0//EN 6418 VERSION:2.0 6419 BEGIN:VEVENT 6420 DTSTAMP:19960704T120000Z 6421 UID:uid1@example.com 6422 ORGANIZER:mailto:jsmith@example.com 6423 DTSTART:19960918T143000Z 6424 DTEND:19960920T220000Z 6425 STATUS:CONFIRMED 6426 CATEGORIES:CONFERENCE 6427 SUMMARY:Networld+Interop Conference 6428 DESCRIPTION:Networld+Interop Conference 6429 and Exhibit\nAtlanta World Congress Center\n 6430 Atlanta\, Georgia 6431 END:VEVENT 6432 END:VCALENDAR 6434 The following example specifies a group scheduled meeting that begin 6435 at 8:30 AM EST on March 12, 1998 and end at 9:30 AM EST on March 12, 6436 1998. The "Organizer" has scheduled the meeting with one or more 6437 calendar users in a group. A time zone specification for Eastern 6438 United States has been specified. 6440 BEGIN:VCALENDAR 6441 PRODID:-//RDU Software//NONSGML HandCal//EN 6442 VERSION:2.0 6443 BEGIN:VTIMEZONE 6444 TZID:America/New_York 6445 BEGIN:STANDARD 6446 DTSTART:19981025T020000 6447 RDATE:19981025T020000 6448 TZOFFSETFROM:-0400 6449 TZOFFSETTO:-0500 6450 TZNAME:EST 6451 END:STANDARD 6452 BEGIN:DAYLIGHT 6453 DTSTART:19990404T020000 6454 RDATE:19990404T020000 6455 TZOFFSETFROM:-0500 6456 TZOFFSETTO:-0400 6457 TZNAME:EDT 6458 END:DAYLIGHT 6459 END:VTIMEZONE 6460 BEGIN:VEVENT 6461 DTSTAMP:19980309T231000Z 6462 UID:guid-1.example.com 6463 ORGANIZER;ROLE=CHAIR:mailto:mrbig@example.com 6464 ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;CUTYPE=GROUP: 6465 mailto:employee-A@example.com 6466 DESCRIPTION:Project XYZ Review Meeting 6467 CATEGORIES:MEETING 6468 CLASS:PUBLIC 6469 CREATED:19980309T130000Z 6470 SUMMARY:XYZ Project Review 6471 DTSTART;TZID=America/New_York:19980312T083000 6472 DTEND;TZID=America/New_York:19980312T093000 6473 LOCATION:1CP Conference Room 4350 6474 END:VEVENT 6475 END:VCALENDAR 6477 The following is an example of an iCalendar object passed in a MIME 6478 message with a single body part consisting of a "text/calendar" 6479 Content Type. 6481 TO:jsmith@example.com 6482 FROM:jdoe@example.com 6483 MIME-VERSION:1.0 6484 MESSAGE-ID: 6485 CONTENT-TYPE:text/calendar; method="xyz"; component="VEVENT" 6487 BEGIN:VCALENDAR 6488 METHOD:xyz 6489 VERSION:2.0 6490 PRODID:-//ABC Corporation//NONSGML My Product//EN 6491 BEGIN:VEVENT 6492 DTSTAMP:19970324T120000Z 6493 SEQUENCE:0 6494 UID:uid3@example.com 6495 ORGANIZER:mailto:jdoe@example.com 6496 ATTENDEE;RSVP=TRUE:mailto:jsmith@example.com 6497 DTSTART:19970324T123000Z 6498 DTEND:19970324T210000Z 6499 CATEGORIES:MEETING,PROJECT 6500 CLASS:PUBLIC 6501 SUMMARY:Calendaring Interoperability Planning Meeting 6502 DESCRIPTION:Discuss how we can test c&s interoperability\n 6503 using iCalendar and other IETF standards. 6504 LOCATION:LDB Lobby 6505 ATTACH;FMTTYPE=application/postscript:ftp://example.com/pub/ 6506 conf/bkgrnd.ps 6507 END:VEVENT 6508 END:VCALENDAR 6510 The following is an example of a to-do due on April 15, 1998. An 6511 audio alarm has been specified to remind the calendar user at noon, 6512 the day before the to-do is expected to be completed and repeat 6513 hourly, four additional times. The to-do definition has been 6514 modified twice since it was initially created. 6516 BEGIN:VCALENDAR 6517 VERSION:2.0 6518 PRODID:-//ABC Corporation//NONSGML My Product//EN 6519 BEGIN:VTODO 6520 DTSTAMP:19980130T134500Z 6521 SEQUENCE:2 6522 UID:uid4@example.com 6523 ORGANIZER:mailto:unclesam@example.com 6524 ATTENDEE;PARTSTAT=ACCEPTED:mailto:jqpublic@example.com 6525 DUE:19980415T000000 6526 STATUS:NEEDS-ACTION 6527 SUMMARY:Submit Income Taxes 6528 BEGIN:VALARM 6529 ACTION:AUDIO 6530 TRIGGER:19980403T120000Z 6531 ATTACH;FMTTYPE=audio/basic:http://example.com/pub/audio- 6532 files/ssbanner.aud 6533 REPEAT:4 6534 DURATION:PT1H 6535 END:VALARM 6536 END:VTODO 6537 END:VCALENDAR 6539 The following is an example of a journal entry. 6541 BEGIN:VCALENDAR 6542 VERSION:2.0 6543 PRODID:-//ABC Corporation//NONSGML My Product//EN 6544 BEGIN:VJOURNAL 6545 DTSTAMP:19970324T120000Z 6546 UID:uid5@example.com 6547 ORGANIZER:mailto:jsmith@example.com 6548 STATUS:DRAFT 6549 CLASS:PUBLIC 6550 CATEGORIES:Project Report,XYZ,Weekly Meeting 6551 DESCRIPTION:Project xyz Review Meeting Minutes\n 6552 Agenda\n1. Review of project version 1.0 requirements.\n2. 6553 Definition 6554 of project processes.\n3. Review of project schedule.\n 6555 Participants: John Smith\, Jane Doe\, Jim Dandy\n-It was 6556 decided that the requirements need to be signed off by 6557 product marketing.\n-Project processes were accepted.\n 6558 -Project schedule needs to account for scheduled holidays 6559 and employee vacation time. Check with HR for specific 6560 dates.\n-New schedule will be distributed by Friday.\n- 6561 Next weeks meeting is cancelled. No meeting until 3/23. 6562 END:VJOURNAL 6563 END:VCALENDAR 6565 The following is an example of published busy time information. The 6566 iCalendar object might be placed in the network resource 6567 http://www.example.com/calendar/busytime/jsmith.ifb. 6569 BEGIN:VCALENDAR 6570 VERSION:2.0 6571 PRODID:-//RDU Software//NONSGML HandCal//EN 6572 BEGIN:VFREEBUSY 6573 ORGANIZER:mailto:jsmith@example.com 6574 DTSTART:19980313T141711Z 6575 DTEND:19980410T141711Z 6576 FREEBUSY:19980314T233000Z/19980315T003000Z 6577 FREEBUSY:19980316T153000Z/19980316T163000Z 6578 FREEBUSY:19980318T030000Z/19980318T040000Z 6579 URL:http://www.example.com/calendar/busytime/jsmith.ifb 6580 END:VFREEBUSY 6581 END:VCALENDAR 6583 5. Recommended Practices 6585 These recommended practices should be followed in order to assure 6586 consistent handling of the following cases for an iCalendar object. 6588 1. Content lines longer than 75 octets SHOULD be folded. 6590 2. When the "DTSTART" and "DTEND" properties , for "VEVENT"and 6591 "VJOURNAL" calendar components, and "DTSTART" and "DUE" 6592 properties , for "VTODO" calendar components, have the same 6593 value data type (e.g., DATE-TIME), they SHOULD specify values in 6594 the same time format (e.g., date with local time, date with UTC 6595 time, or date with local time and time zone reference). In the 6596 case of date with local time and time zone reference, a 6597 different time zone MAY be used for each property. 6599 3. When the combination of the "RRULE" and "RDATE" properties in a 6600 recurring component produces multiple instances having the same 6601 start DATE-TIME value, they should be collapsed to, and 6602 considered as, a single instance. If the "RDATE" property is 6603 specified as a PERIOD value the duration of the recurrence 6604 instance will be the one specified by the "RDATE" property, and 6605 not the duration of the recurrence instance defined by the 6606 "DTSTART" property. 6608 4. When a calendar user receives multiple requests for the same 6609 calendar component (e.g., REQUEST for a "VEVENT" calendar 6610 component) as a result of being on multiple mailing lists 6611 specified by "ATTENDEE" properties in the request, they SHOULD 6612 respond to only one of the requests. The calendar user SHOULD 6613 also specify (using the "MEMBER" parameter of the "ATTENDEE" 6614 property) which mailing list they are a member of. 6616 5. An implementation can truncate a "SUMMARY" property value to 255 6617 octets, but MUST NOT truncate the value in the middle of a UTF-8 6618 multi-octet sequence. 6620 6. If seconds of the minute are not supported by an implementation, 6621 then a value of "00" SHOULD be specified for the seconds 6622 component in a time value. 6624 7. If the value type parameter (VALUE=) contains an unknown value 6625 type, it SHOULD be treated as TEXT. 6627 8. "TZURL" values SHOULD NOT be specified as a file URI type. This 6628 URI form can be useful within an organization, but is 6629 problematic in the Internet. 6631 9. Some possible English values for "CATEGORIES" property include 6632 "ANNIVERSARY", "APPOINTMENT", "BUSINESS", "EDUCATION", 6633 "HOLIDAY", "MEETING", "MISCELLANEOUS", "NON-WORKING HOURS", "NOT 6634 IN OFFICE", "PERSONAL", "PHONE CALL", "SICK DAY", "SPECIAL 6635 OCCASION", "TRAVEL", "VACATION". Categories can be specified in 6636 any registered language. 6638 10. Some possible English values for "RESOURCES" property include 6639 "CATERING", "CHAIRS", "COMPUTER PROJECTOR", "EASEL", "OVERHEAD 6640 PROJECTOR", "SPEAKER PHONE", "TABLE", "TV", "VCR", "VIDEO 6641 PHONE", "VEHICLE". Resources can be specified in any registered 6642 language. 6644 6. Registration of Content Type Elements 6646 This section provides the process for registration of MIME 6647 Calendaring and Scheduling Content Type iCalendar object methods and 6648 new or modified properties. 6650 6.1. Registration of New and Modified iCalendar Object Methods 6652 New MIME Calendaring and Scheduling Content Type iCalendar object 6653 methods are registered by the publication of an IETF Request for 6654 Comments (RFC). Changes to an iCalendar object method are registered 6655 by the publication of a revision of the RFC defining the method. 6657 6.2. Registration of New Properties 6659 This section defines procedures by which new properties or enumerated 6660 property values for the MIME Calendaring and Scheduling Content Type 6661 can be registered with the IANA. Non-IANA properties can be used by 6662 bilateral agreement, provided the associated properties names follow 6663 the "X-" convention. 6665 The procedures defined here are designed to allow public comment and 6666 review of new properties, while posing only a small impediment to the 6667 definition of new properties. 6669 Registration of a new property is accomplished by the following 6670 steps. 6672 6.2.1. Define the property 6674 A property is defined by completing the following template. 6676 To: ietf-calendar@imc.org 6678 Subject: Registration of text/calendar MIME property XXX 6680 Property name: 6682 Property purpose: 6684 Property value type(s): 6686 Property parameter (s): 6688 Conformance: 6690 Description: 6692 Format definition: 6694 Examples: 6696 The meaning of each field in the template is as follows. 6698 Property name: The name of the property, as it will appear in the 6699 body of an text/calendar MIME Content-Type "property: value" line 6700 to the left of the colon ":". 6702 Property purpose: The purpose of the property (e.g., to indicate a 6703 delegate for the event or to-do, etc.). Give a short but clear 6704 description. 6706 Property value type (s): Any of the valid value types for the 6707 property value needs to be specified. The default value type also 6708 needs to be specified. If a new value type is specified, it needs 6709 to be declared in this section. 6711 Property parameter (s): Any of the valid property parameters for the 6712 property needs to be specified. 6714 Conformance: The calendar components that the property can appear in 6715 needs to be specified. 6717 Description: Any special notes about the property, how it is to be 6718 used, etc. 6720 Format definition: The ABNF for the property definition needs to be 6721 specified. 6723 Examples: One or more examples of instances of the property needs to 6724 be specified. 6726 6.2.2. Post the Property definition 6728 The property description MUST be posted to the new property 6729 discussion list, ietf-calendar@imc.org. 6731 6.2.3. Allow a comment period 6733 Discussion on the new property MUST be allowed to take place on the 6734 list for a minimum of two weeks. Consensus MUST be reached on the 6735 property before proceeding to the next step. 6737 6.2.4. Submit the property for approval 6739 Once the two-week comment period has elapsed, and the proposer is 6740 convinced consensus has been reached on the property, the 6741 registration application should be submitted to the Method Reviewer 6742 for approval. The Method Reviewer is appointed by the Application 6743 Area Directors and can either accept or reject the property 6744 registration. An accepted registration should be passed on by the 6745 Method Reviewer to the IANA for inclusion in the official IANA method 6746 registry. The registration can be rejected for any of the following 6747 reasons. 1) Insufficient comment period; 2) Consensus not reached; 3) 6748 Technical deficiencies raised on the list or elsewhere have not been 6749 addressed. The Method Reviewer's decision to reject a property can 6750 be appealed by the proposer to the IESG, or the objections raised can 6751 be addressed by the proposer and the property resubmitted. 6753 6.3. Property Change Control 6755 Existing properties can be changed using the same process by which 6756 they were registered. 6758 1. Define the change 6760 2. Post the change 6762 3. Allow a comment period 6764 4. Submit the property for approval 6766 Note that the original author or any other interested party can 6767 propose a change to an existing property, but that such changes 6768 should only be proposed when there are serious omissions or errors in 6769 the published memo. The Method Reviewer can object to a change if it 6770 is not backward compatible, but is not required to do so. 6772 Property definitions can never be deleted from the IANA registry, but 6773 properties which are no longer believed to be useful can be declared 6774 OBSOLETE by a change to their "intended use" field. 6776 7. Internationalization Considerations 6778 8. Security Considerations 6780 SPOOFING: In this memo, the "Organizer" is the only person 6781 authorized to make changes to an existing "VEVENT", "VTODO", 6782 "VJOURNAL" calendar component and redistribute the updates to the 6783 "Attendees". An iCalendar object that maliciously changes or 6784 cancels an existing "VEVENT", "VTODO" or "VJOURNAL" or "VFREEBUSY" 6785 calendar component might be constructed by someone other than the 6786 "Organizer" and sent to the "Attendees". In addition in this 6787 memo, other than the "Organizer", an "Attendee" of a "VEVENT", 6788 "VTODO", "VJOURNAL" calendar component is the only other person 6789 authorized to update any parameter associated with their 6790 "ATTENDEE" property and send it to the "Organizer". An iCalendar 6791 object that maliciously changes the "ATTENDEE" parameters can be 6792 constructed by someone other than the real "Attendee" and sent to 6793 the "Organizer". 6795 ATTACHMENTS: An iCalendar object can include references to Uniform 6796 Resource Locators that can be programmed resources. 6798 Implementers and users of this memo should be aware of the network 6799 security implications of accepting and parsing such information. 6800 In addition, the security considerations observed by 6801 implementations of electronic mail systems should be followed for 6802 this memo. 6804 9. IANA Considerations 6806 The IANA is requested to create and maintain a number of registries. 6807 The table below describes each. Subsections below contain the 6808 initial registrations and additional instructions for registrations. 6810 +---------------+------------------------------------+--------------+ 6811 | Registry Name | Registration Requirements | Reference | 6812 +---------------+------------------------------------+--------------+ 6813 | Components | RFC, Expert Review | Section 9.1 | 6814 | Properties | RFC, Expert Review | Section 9.2 | 6815 | Property | RFC, Expert Review | Section 9.3 | 6816 | Parameters | | | 6817 | Value Data | Standards Action Required for new | Section 9.4 | 6818 | Type Values | values that modify existing | | 6819 | | parameters | | 6820 | Calendar User | RFC, Expert Review | Section 9.5 | 6821 | Type Values | | | 6822 | Free/Busy | RFC, Expert Review | Section 9.6 | 6823 | Time Type | | | 6824 | Values | | | 6825 | Participation | Internet Standards Action for | Section 9.7 | 6826 | Status Values | VEVENTs, otherwise Expert Review | | 6827 | Relationship | RFC, Expert Review | Section 9.8 | 6828 | Type Values | | | 6829 | Participation | RFC, Expert Review | Section 9.9 | 6830 | Role Values | | | 6831 | Action Values | RFC, Expert Review | Section 9.10 | 6832 | Method Values | RFC, Expert Review | Section 9.11 | 6833 +---------------+------------------------------------+--------------+ 6835 Each of the above is described in separate sub-sections below. 6837 9.1. Components Registry 6839 The following table is to be used to initialize the components 6840 registry. 6842 +----------------+---------+------------------------+ 6843 | Component Name | Status | Reference | 6844 +----------------+---------+------------------------+ 6845 | VCALENDAR | Current | RFCXXXX, Section 3.4 | 6846 | VEVENT | Current | RFCXXXX, Section 3.6.1 | 6847 | VTODO | Current | RFCXXXX, Section 3.6.2 | 6848 | VJOURNAL | Current | RFCXXXX, Section 3.6.3 | 6849 | VFREEBUSY | Current | RFCXXXX, Section 3.6.4 | 6850 | VTIMEZONE | Current | RFCXXXX, Section 3.6.5 | 6851 | VALARM | Current | RFCXXXX, Section 3.6.6 | 6852 | STANDARD | Current | RFCXXXX, Section 3.6.5 | 6853 | DAYLIGHT | Current | RFCXXXX, Section 3.6.5 | 6854 +----------------+---------+------------------------+ 6856 9.2. Properties Registry 6858 Properties that are registered with IANA are to be document via the 6859 RFC process. It is not necessary for properties to be placed on the 6860 standards track to be registered unless the usage of other standard 6861 properties, parameters, or enumerations are changed. Components 6862 specifically require standards action. However, each property MUST 6863 specify what standard parameters, if any, are allowed, and in what 6864 components the property is valid (e.g., "VEVENT", "VTODO", etc.). 6865 The IANA is requested to maintain a table of such properties with 6866 pointers to appropriate reference documents. 6868 The following table is to be used to initialize the property 6869 registry. 6871 +------------------+------------+---------------------------+ 6872 | Property Name | Status | Reference | 6873 +------------------+------------+---------------------------+ 6874 | CALSCALE | Current | RFCXXXX, Section 3.7.1 | 6875 | METHOD | Current | RFCXXXX, Section 3.7.2 | 6876 | PRODID | Current | RFCXXXX, Section 3.7.3 | 6877 | VERSION | Current | RFCXXXX, Section 3.7.4 | 6878 | ATTACH | Current | RFCXXXX, Section 3.8.1.1 | 6879 | CATEGORIES | Current | RFCXXXX, Section 3.8.1.2 | 6880 | CLASS | Current | RFCXXXX, Section 3.8.1.3 | 6881 | COMMENT | Current | RFCXXXX, Section 3.8.1.4 | 6882 | DESCRIPTION | Current | RFCXXXX, Section 3.8.1.5 | 6883 | GEO | Current | RFCXXXX, Section 3.8.1.6 | 6884 | LOCATION | Current | RFCXXXX, Section 3.8.1.7 | 6885 | PERCENT-COMPLETE | Current | RFCXXXX, Section 3.8.1.8 | 6886 | PRIORITY | Current | RFCXXXX, Section 3.8.1.9 | 6887 | RESOURCES | Current | RFCXXXX, Section 3.8.1.10 | 6888 | STATUS | Current | RFCXXXX, Section 3.8.1.11 | 6889 | SUMMARY | Current | RFCXXXX, Section 3.8.1.12 | 6890 | COMPLETED | Current | RFCXXXX, Section 3.8.2.1 | 6891 | DTEND | Current | RFCXXXX, Section 3.8.2.2 | 6892 | DUE | Current | RFCXXXX, Section 3.8.2.3 | 6893 | DTSTART | Current | RFCXXXX, Section 3.8.2.4 | 6894 | DURATION | Current | RFCXXXX, Section 3.8.2.5 | 6895 | FREEBUSY | Current | RFCXXXX, Section 3.8.2.6 | 6896 | TRANSP | Current | RFCXXXX, Section 3.8.2.7 | 6897 | TZID | Current | RFCXXXX, Section 3.8.3.1 | 6898 | TZNAME | Current | RFCXXXX, Section 3.8.3.2 | 6899 | TZOFFSETFROM | Current | RFCXXXX, Section 3.8.3.3 | 6900 | TZOFFSETTO | Current | RFCXXXX, Section 3.8.3.4 | 6901 | TZURL | Current | RFCXXXX, Section 3.8.3.5 | 6902 | ATTENDEE | Current | RFCXXXX, Section 3.8.4.1 | 6903 | CONTACT | Current | RFCXXXX, Section 3.8.4.2 | 6904 | ORGANIZER | Current | RFCXXXX, Section 3.8.4.3 | 6905 | RECURRENCE-ID | Current | RFCXXXX, Section 3.8.4.4 | 6906 | RELATED-TO | Current | RFCXXXX, Section 3.8.4.5 | 6907 | URL | Current | RFCXXXX, Section 3.8.4.6 | 6908 | UID | Current | RFCXXXX, Section 3.8.4.7 | 6909 | EXDATE | Current | RFCXXXX, Section 3.8.5.1 | 6910 | EXRULE | Deprecated | RFC2445, Section 4.8.5.2 | 6911 | RDATE | Current | RFCXXXX, Section 3.8.5.2 | 6912 | RRULE | Current | RFCXXXX, Section 3.8.5.3 | 6913 | ACTION | Current | RFCXXXX, Section 3.8.6.1 | 6914 | REPEAT | Current | RFCXXXX, Section 3.8.6.2 | 6915 | TRIGGER | Current | RFCXXXX, Section 3.8.6.3 | 6916 | CREATED | Current | RFCXXXX, Section 3.8.7.1 | 6917 | DTSTAMP | Current | RFCXXXX, Section 3.8.7.2 | 6918 | LAST-MODIFIED | Current | RFCXXXX, Section 3.8.7.3 | 6919 | SEQUENCE | Current | RFCXXXX, Section 3.8.7.4 | 6920 | REQUEST-STATUS | Current | RFCXXXX, Section 3.8.8.3 | 6921 +------------------+------------+---------------------------+ 6923 9.3. Property Parameters Registry 6925 The IANA is requested to establish and maintain a table of property 6926 parameters for the iCalendar standard. Additional parameters may be 6927 added to this table as follows: 6929 o Those parameters that do not modify standard properties or 6930 parameters may be added through the publishing of informational or 6931 experimental RFCs with expert review through the APPS Area of the 6932 IETF. 6934 o Those property parameters that modify existing standard properties 6935 or parameters MUST update this memo, and hence be promoted through 6936 the Internet standards process. 6938 In all cases, each parameter MUST list the property it will be used 6939 with. Implementations that are unable to recognize a property 6940 parameter MUST ignore the property. 6942 The following table is to be initialized with the following values: 6944 +-------------------------+------------+-------------------------+ 6945 | Property Parameter Name | Status | Reference | 6946 +-------------------------+------------+-------------------------+ 6947 | ALTREP | Current | RFCXXXX, Section 3.2.1 | 6948 | CN | Current | RFCXXXX, Section 3.2.2 | 6949 | CUTYPE | Current | RFCXXXX, Section 3.2.3 | 6950 | DELEGATED-FROM | Current | RFCXXXX, Section 3.2.4 | 6951 | DELEGATED-TO | Current | RFCXXXX, Section 3.2.5 | 6952 | DIR | Current | RFCXXXX, Section 3.2.6 | 6953 | ENCODING | Current | RFCXXXX, Section 3.2.7 | 6954 | FMTTYPE | Current | RFCXXXX, Section 3.2.8 | 6955 | FBTYPE | Current | RFCXXXX, Section 3.2.9 | 6956 | LANGUAGE | Current | RFCXXXX, Section 3.2.10 | 6957 | MEMBER | Current | RFCXXXX, Section 3.2.11 | 6958 | PARTSTAT | Current | RFCXXXX, Section 3.2.12 | 6959 | RANGE | Deprecated | RFC2445, Section 4.2.13 | 6960 | RELATED | Current | RFCXXXX, Section 3.2.13 | 6961 | RELTYPE | Current | RFCXXXX, Section 3.2.14 | 6962 | ROLE | Current | RFCXXXX, Section 3.2.15 | 6963 | RSVP | Current | RFCXXXX, Section 3.2.16 | 6964 | SENT-BY | Current | RFCXXXX, Section 3.2.17 | 6965 | TZID | Current | RFCXXXX, Section 3.2.18 | 6966 | VALUE | Current | RFCXXXX, Section 3.2.19 | 6967 +-------------------------+------------+-------------------------+ 6969 9.4. Value Data Type Values Registry 6971 The IANA is requested to establish a registry of Property Value Data 6972 Types for the iCalendar standard. Additional data types may only be 6973 added through the Internet standards process. The initial values are 6974 as follows: 6976 +-------------------------------+---------+-------------------------+ 6977 | Property Parameter Value Type | Status | Reference | 6978 +-------------------------------+---------+-------------------------+ 6979 | BINARY | Current | RFCXXXX, Section 3.3.1 | 6980 | BOOLEAN | Current | RFCXXXX, Section 3.3.2 | 6981 | CAL-ADDRESS | Current | RFCXXXX, Section 3.3.3 | 6982 | DATE | Current | RFCXXXX, Section 3.3.4 | 6983 | DATE-TIME | Current | RFCXXXX, Section 3.3.5 | 6984 | DURATION | Current | RFCXXXX, Section 3.3.6 | 6985 | FLOAT | Current | RFCXXXX, Section 3.3.7 | 6986 | INTEGER | Current | RFCXXXX, Section 3.3.8 | 6987 | PERIOD | Current | RFCXXXX, Section 3.3.9 | 6988 | RECUR | Current | RFCXXXX, Section 3.3.10 | 6989 | TEXT | Current | RFCXXXX, Section 3.3.11 | 6990 | TIME | Current | RFCXXXX, Section 3.3.12 | 6991 | URI | Current | RFCXXXX, Section 3.3.13 | 6992 | UTC-OFFSET | Current | RFCXXXX, Section 3.3.14 | 6993 +-------------------------------+---------+-------------------------+ 6995 9.5. Calendar User Type Values Registry 6997 Calendar user types (CUTYPEs) are used to indicate the sort of user 6998 associated with a CAL-ADDRESS. It is described in more detail in 6999 Section 3.2.3. Expert review is required for an IANA assignment. 7000 The following values are currently allowed: 7002 +--------------------+---------+------------------------+ 7003 | Calendar User Type | Status | Reference | 7004 +--------------------+---------+------------------------+ 7005 | INDIVIDUAL | Current | RFCXXXX, Section 3.2.3 | 7006 | GROUP | Current | RFCXXXX, Section 3.2.3 | 7007 | RESOURCE | Current | RFCXXXX, Section 3.2.3 | 7008 | ROOM | Current | RFCXXXX, Section 3.2.3 | 7009 | UNKNOWN | Current | RFCXXXX, Section 3.2.3 | 7010 +--------------------+---------+------------------------+ 7012 Implementations that do not recognize a calendar user type MUST treat 7013 the CAL-ADDRESS as an INDIVIDUAL. 7015 9.6. Free/Busy Time Type Values Registry 7017 This parameter is described in Section 3.2.9. New entries require 7018 expert review. The table below specifies the initial registry: 7020 +------------------+---------+------------------------+ 7021 | Free/Busy Type | Status | Reference | 7022 +------------------+---------+------------------------+ 7023 | FREE | Current | RFCXXXX, Section 3.2.9 | 7024 | BUSY | Current | RFCXXXX, Section 3.2.9 | 7025 | BUSY-UNAVAILABLE | Current | RFCXXXX, Section 3.2.9 | 7026 | BUSY-TENTATIVE | Current | RFCXXXX, Section 3.2.9 | 7027 +------------------+---------+------------------------+ 7029 Implementations that do not recognize a particular fbtype MUST treat 7030 that calendar user as BUSY. 7032 9.7. Participation Status Values Registry 7034 PARTSTAT denotes participate status and is described in 7035 Section 3.2.12. The following table initializes the registry for 7036 participant status: 7038 +--------------------------+---------+-------------------------+ 7039 | Participant Status Value | Status | Reference | 7040 +--------------------------+---------+-------------------------+ 7041 | NEEDS-ACTION | Current | RFCXXXX, Section 3.2.12 | 7042 | ACCEPTED | Current | RFCXXXX, Section 3.2.12 | 7043 | DECLINED | Current | RFCXXXX, Section 3.2.12 | 7044 | TENTATIVE | Current | RFCXXXX, Section 3.2.12 | 7045 | DELEGATED | Current | RFCXXXX, Section 3.2.12 | 7046 | COMPLETED | Current | RFCXXXX, Section 3.2.12 | 7047 | IN-PROCESS | Current | RFCXXXX, Section 3.2.12 | 7048 +--------------------------+---------+-------------------------+ 7050 Existing implementations MUST treat an unknown PARTSTAT value as 7051 NEEDS-ACTION. 7053 9.8. Relationship Type Values Registry 7055 This parameter is described in Section 3.2.14. Expert review is 7056 required for an addition. The table below initializes the registry. 7058 +-------------------+---------+-------------------------+ 7059 | Relationship Type | Status | Reference | 7060 +-------------------+---------+-------------------------+ 7061 | CHILD | Current | RFCXXXX, Section 3.2.14 | 7062 | PARENT | Current | RFCXXXX, Section 3.2.14 | 7063 | SIBLING | Current | RFCXXXX, Section 3.2.14 | 7064 +-------------------+---------+-------------------------+ 7066 Implementations MUST treat an unknown relationship as a PARENT. 7068 9.9. Participation Role Values Registry 7070 Roles are described in Section 3.2.15. The initial registration is 7071 as follows: 7073 +-----------------+---------+-------------------------+ 7074 | Role Type | Status | Reference | 7075 +-----------------+---------+-------------------------+ 7076 | CHAIR | Current | RFCXXXX, Section 3.2.15 | 7077 | REQ-PARTICIPANT | Current | RFCXXXX, Section 3.2.15 | 7078 | OPT-PARTICIPANT | Current | RFCXXXX, Section 3.2.15 | 7079 | NON-PARTICIPANT | Current | RFCXXXX, Section 3.2.15 | 7080 +-----------------+---------+-------------------------+ 7082 Implementations that do not recognize a specific ROLE should treat 7083 the calendar user as REQ-PARTICIPANT. 7085 9.10. Action Values Registry 7087 Actions are covered in Section 3.8.6.1. The following table 7088 intializes the registry. 7090 +-----------------------+------------+--------------------------+ 7091 | ACTION Property Value | Status | Reference | 7092 +-----------------------+------------+--------------------------+ 7093 | AUDIO | Current | RFCXXXX, Section 3.8.6.1 | 7094 | DISPLAY | Current | RFCXXXX, Section 3.8.6.1 | 7095 | EMAIL | Current | RFCXXXX, Section 3.8.6.1 | 7096 | PROCEDURE | Deprecated | RFC2445, Section 4.8.6.1 | 7097 +-----------------------+------------+--------------------------+ 7099 Implementations MUST ignore unrecognized "ACTION" property values. 7101 9.11. Method Values Registry 7103 Methods are covered in Section 3.7.2. No values are defined in this 7104 document for the "METHOD" property. 7106 9.12. Media Type Registration Information 7108 The Calendaring and Scheduling Core Object Specification is intended 7109 for use as a MIME content type. However, the implementation of the 7110 memo is in no way limited solely as a MIME content type. 7112 To: ietf-types@iana.org 7113 Subject: Registration of media type text/calendar 7114 Type name: text 7116 Subtype name: calendar 7118 Required parameters: none 7120 Optional parameters: charset, method, component and optinfo 7122 The "charset" parameter is defined in [RFC2046] for subtypes of 7123 the "text" media type. It is used to indicate the charset used in 7124 the body part. The charset supported by this revision of 7125 iCalendar is UTF-8. The use of any other charset is deprecated by 7126 this revision of iCalendar; however note that this revision 7127 requires that compliant applications MUST accept iCalendar objects 7128 using either the UTF-8 or US-ASCII charset. 7130 The "method" parameter is used to convey the iCalendar object 7131 method or transaction semantics for the calendaring and scheduling 7132 information. It also is an identifier for the restricted set of 7133 properties and values that the iCalendar object consists of. The 7134 parameter is to be used as a guide for applications interpreting 7135 the information contained within the body part. It SHOULD NOT be 7136 used to exclude or require particular pieces of information unless 7137 the identified method definition specifically calls for this 7138 behavior. Unless specifically forbidden by a particular method 7139 definition, a text/calendar content type can contain any set of 7140 properties permitted by the Calendaring and Scheduling Core Object 7141 Specification. The "method" parameter MUST be specified and MUST 7142 be set to the same value as the "METHOD" component property of the 7143 iCalendar objects of the iCalendar stream if and only if the 7144 iCalendar objects in the iCalendar stream all have a "METHOD" 7145 component property set to the same value. 7147 The value for the "method" parameter is defined as follows: 7149 method = 1*(ALPHA / DIGIT / "-") 7150 ; IANA registered iCalendar object method 7152 The "component" parameter conveys the type of iCalendar calendar 7153 component within the body part. If the iCalendar object contains 7154 more than one calendar component type, then multiple component 7155 parameters MUST be specified. 7157 The value for the "component" parameter is defined as follows: 7159 component = "VEVENT" 7160 / "VTODO" 7161 / "VJOURNAL" 7162 / "VFREEBUSY" 7163 / "VTIMEZONE" 7164 / iana-token 7165 / x-name 7167 The "optinfo" parameter conveys optional information about the 7168 iCalendar object within the body part. This parameter can only 7169 specify semantics already specified by the iCalendar object and 7170 that can be otherwise determined by parsing the body part. In 7171 addition, the optional information specified by this parameter 7172 MUST be consistent with that information specified by the 7173 iCalendar object. For example, it can be used to convey the 7174 "Attendee" response status to a meeting request. The parameter 7175 value consists of a string value. 7177 The parameter can be specified multiple times. 7179 The value for the "optinfo" parameter is defined as follows: 7181 optinfo = infovalue / qinfovalue 7183 infovalue = iana-token / x-name 7185 qinfovalue = DQUOTE (infovalue) DQUOTE 7187 Encoding considerations: This media type can contain 8bit 7188 characters, so the use of quoted-printable or base64 MIME Content- 7189 Transfer-Encodings might be necessary when iCalendar objects are 7190 transferred across protocols restricted to the 7bit repertoire. 7191 Note that a text valued property in the content entity can also 7192 have content encoding of special characters using a BACKSLASH 7193 character (US-ASCII decimal 92) escapement technique. This means 7194 that content values can end up encoded twice. 7196 Security considerations: See Section 8. 7198 Interoperability considerations: This media type is intended to 7199 define a common format for conveying calendaring and scheduling 7200 information between different systems. It is heavily based on the 7201 earlier [VCAL] industry specification. 7203 Published specification: This specification. 7205 Applications which use this media type: This media type is designed 7206 for widespread use by Internet calendaring and scheduling 7207 applications. In addition, applications in the workflow and 7208 document management area might find this content-type applicable. 7209 The iTIP [I-D.ietf-calsify-2446bis], iMIP 7210 [I-D.ietf-calsify-rfc2447bis] and CalDAV [I-D.dusseault-caldav] 7211 Internet protocols directly use this media type also. 7213 Additional information: 7215 Magic number(s): None. 7217 File extension(s): The file extension of "ics" is to be used to 7218 designate a file containing (an arbitrary set of) calendaring 7219 and scheduling information consistent with this MIME content 7220 type. 7222 The file extension of "ifb" is to be used to designate a file 7223 containing free or busy time information consistent with this 7224 MIME content type. 7226 Macintosh file type code(s): The file type code of "iCal" is to 7227 be used in Apple MacIntosh operating system environments to 7228 designate a file containing calendaring and scheduling 7229 information consistent with this MIME media type. 7231 The file type code of "iFBf" is to be used in Apple MacIntosh 7232 operating system environments to designate a file containing 7233 free or busy time information consistent with this MIME media 7234 type. 7236 Person & email address to contact for further information: TBD 7238 Intended usage: COMMON 7240 Restrictions on usage: There are no restrictions on where this media 7241 type can be used. 7243 Author: TBD 7245 Change controller: IETF 7247 10. Acknowledgements 7249 The editor of this document wish to thank Frank Dawson and Stenerson 7250 Derik, the original authors of RFC2445, as well as the following 7251 individuals who have participated in the drafting, review and 7252 discussion of this memo: 7254 Joe Abley, Hervey Allen, Jay Batson, Oliver Block, Stephane 7255 Bortzmeyer, Chris Bryant, Tantek Celik, Mark Crispin, Cyrus Daboo, 7256 Mike Douglass, Andrew N. Dowden, Lisa Dusseault, Ned Freed, Ted 7257 Hardie, Tim Hare, Jeffrey Harris, Helge Hess, Leif Johansson, 7258 Reinhold Kainhofer, Eliot Lear, Michiel van Leeuwen, Jonathan Lennox, 7259 Jeff McCullough, Bill McQuillan, Alexey Melnikov, Aki Niemi, John W. 7260 Noerenberg II, Chuck Norris, Mark Paterson, Simon Pilette, Arnaud 7261 Quillaud, Robert Ransdell, Julian F. Reschke, Caleb Richardson, Sam 7262 Roberts, George Sexton, Nigel Swinson, Simon Vaillancourt, and Sandy 7263 Wills. 7265 The editor would also like to thank the Calendaring and Scheduling 7266 Consortium for advice with this specification, and for organizing 7267 interoperability testing events to help refine it. 7269 11. References 7271 11.1. Normative References 7273 [ISO.8601.1988] International Organization for 7274 Standardization, "Data elements and 7275 interchange formats - Information 7276 interchange - Representation of dates 7277 and times", 7278 . 7280 [ISO.9070.1991] International Organization for 7281 Standardization, "Information 7282 Technology_SGML Support Facilities -- 7283 Registration Procedures for Public 7284 Text Owner Identifiers, Second 7285 Edition", April 1991, . 7289 [RFC2045] Freed, N. and N. Borenstein, 7290 "Multipurpose Internet Mail Extensions 7291 (MIME) Part One: Format of Internet 7292 Message Bodies", RFC 2045, 7293 November 1996. 7295 [RFC2046] Freed, N. and N. Borenstein, 7296 "Multipurpose Internet Mail Extensions 7297 (MIME) Part Two: Media Types", 7298 RFC 2046, November 1996. 7300 [RFC2119] Bradner, S., "Key words for use in 7301 RFCs to Indicate Requirement Levels", 7302 BCP 14, RFC 2119, March 1997. 7304 [RFC2368] Hoffman, P., Masinter, L., and J. 7305 Zawinski, "The mailto URL scheme", 7306 RFC 2368, July 1998. 7308 [RFC2822] Resnick, P., "Internet Message 7309 Format", RFC 2822, April 2001. 7311 [RFC3629] Yergeau, F., "UTF-8, a transformation 7312 format of ISO 10646", STD 63, 7313 RFC 3629, November 2003. 7315 [RFC3986] Berners-Lee, T., Fielding, R., and L. 7316 Masinter, "Uniform Resource Identifier 7317 (URI): Generic Syntax", STD 66, 7318 RFC 3986, January 2005. 7320 [RFC4234] Crocker, D., Ed. and P. Overell, 7321 "Augmented BNF for Syntax 7322 Specifications: ABNF", RFC 4234, 7323 October 2005. 7325 [RFC4646] Phillips, A. and M. Davis, "Tags for 7326 Identifying Languages", BCP 47, 7327 RFC 4646, September 2006. 7329 [RFC4648] Josefsson, S., "The Base16, Base32, 7330 and Base64 Data Encodings", RFC 4648, 7331 October 2006. 7333 11.2. Informative References 7335 [I-D.dusseault-caldav] Daboo, C., Desruisseaux, B., and L. 7336 Dusseault, "Calendaring Extensions to 7337 WebDAV (CalDAV)", 7338 draft-dusseault-caldav-15 (work in 7339 progress), September 2006. 7341 [I-D.ietf-calsify-2446bis] Daboo, C., "iCalendar Transport- 7342 Independent Interoperability Protocol 7343 (iTIP)", draft-ietf-calsify-2446bis-02 7344 (work in progress), June 2006. 7346 [I-D.ietf-calsify-rfc2447bis] Melnikov, A., "iCalendar Message-Based 7347 Interoperability Protocol(iMIP)", 7348 draft-ietf-calsify-rfc2447bis-02 (work 7349 in progress), June 2006. 7351 [RFC2392] Levinson, E., "Content-ID and 7352 Message-ID Uniform Resource Locators", 7353 RFC 2392, August 1998. 7355 [RFC2425] Howes, T., Smith, M., and F. Dawson, 7356 "A MIME Content-Type for Directory 7357 Information", RFC 2425, 7358 September 1998. 7360 [RFC2426] Dawson, F. and T. Howes, "vCard MIME 7361 Directory Profile", RFC 2426, 7362 September 1998. 7364 [RFC4516] Smith, M. and T. Howes, "Lightweight 7365 Directory Access Protocol (LDAP): 7366 Uniform Resource Locator", RFC 4516, 7367 June 2006. 7369 [TZDB] Eggert, P. and A. Olson, "Sources for 7370 Time Zone and Daylight Saving Time 7371 Data", January 2007, . 7374 [Note to RFC Editor: Change "A. Olson" 7375 to "A.D. Olson".] 7377 [VCAL] Internet Mail Consortium, "vCalendar: 7378 The Electronic Calendaring and 7379 Scheduling Exchange Format", 7380 September 1996, 7381 . 7383 URIs 7385 [1] 7387 Appendix A. Differences from RFC 2445 7389 This appendix contains a list of changes that have been made in the 7390 Internet Calendaring and Scheduling Core Object Specification from 7391 RFC 2445. 7393 A.1. New restrictions 7395 1. The "DTSTART" property SHOULD match the pattern of the recurrence 7396 rule, if specified. 7398 2. The "RRULE" property SHOULD NOT occur more than once in a 7399 component. 7401 A.2. Deprecated features 7403 1. The "EXRULE" property can no longer be specified in a component. 7405 2. The "RANGE" parameter can no longer be specified on the 7406 "RECURRENCE-ID" property. 7408 3. The "PROCEDURE" value can no longer be used with the "ACTION" 7409 property. 7411 Appendix B. Change Log (to be removed by RFC Editor prior to 7412 publication) 7414 B.1. Changes in -06 7416 A detailed list of changes is available at the following page: 7417 http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/ 7418 draft-ietf-calsify-rfc2445bis-06.changes.html. 7420 a. Issue 19: Defined new IANA registries. [Work in progress]; 7422 b. Issue 23: Clarified that the UNTIL rule part MUST specify a value 7423 of the same type as the value specified by "DTSTART"; 7425 c. Issue 27: Clarified how the duration of generated recurrence 7426 instances is determined; 7428 d. Issue 35: Further clarified the description of the "LANGUAGE" 7429 property; 7431 e. Issue 42: Removed the restriction on the values allowed for the 7432 "ACTION" property in the the "VALARM" component; 7434 f. Issue 47: Clarified that alarm triggers relative to a DATE value 7435 type needs to be triggered to 00:00:00 of the user's configured 7436 time zone; 7438 g. Issue 56: Added a note to specify that FREQ MUST be specified as 7439 the first rule part in generated iCalendar applications, but MUST 7440 be accepted in any order to ensure backward compatibility. The 7441 rest of the RECUR value type ABNF has been further simplified; 7443 h. Issue 59: Clarified the default duration of "VEVENT" components 7444 specified with a "DTSTART" property of DATE value type; 7446 i. Issue 61: Modified all the property ABNFs to allow iana-param in 7447 addition to x-param. Also modified the component ABNFs to allow 7448 iana-prop in addition to x-prop. [Work in progress]; 7450 j. Issue 62: Removed the text that lead to believe that the 7451 "RECURRENCE-ID" of a specific recurrence instance might change; 7453 k. Issue 64: Clarified that REQUEST-STATUS only allows pairs (1.1) 7454 and 3-tuples (1.1.1). 7456 l. Issue 65: Clarified that a different time zone may be used by 7457 "DTSTART" and "DTEND", and "DTSTART" and "DUE" when specified as 7458 date with local time and time zone reference. [Work in 7459 progress]; 7461 m. Issue 66: Clarified that if the "RDATE" property is specified as 7462 a PERIOD, its duration has precedence over the duration of the 7463 recurrence instance defined by the "DTSTART" property; 7465 n. Issue 72: Removed the requirement that a "VTIMEZONE" calendar 7466 component MUST be present if the iCalendar object contains an 7467 RRULE that generates dates on both sides of a time zone shift; 7469 o. Issue 73: Clarified that the "TZID" must be unique in the scope 7470 of an iCalendar object only; 7472 p. Issue 74: Deprecated the "PROCEDURE" value for the "ACTION" 7473 property; 7475 q. Issue 78: Fixed the text to specify that "TZOFFSETFROM" and not 7476 "TZOFFSETTO" must be used with "DTSTART" when generating the 7477 onset date-time values from the "RRULE" in a "VTIMEZONE" 7478 component; 7480 r. Clarified that the "DTSTART" property MUST be specified in a 7481 "VTODO" component when the "DURATION" property is specified; 7483 s. Started to update the time zone information / examples; 7485 t. Numerous editorial changes. 7487 B.2. Changes in -05 7489 A detailed list of changes is available at the following page: 7490 http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/ 7491 draft-ietf-calsify-rfc2445bis-05.changes.html. 7493 a. Fixed ABNF with references in .txt version of the draft; 7495 b. Numerous editorial changes; 7497 c. Clarified that normative statements in ABNF comments should be 7498 considered as normative; 7500 d. Removed notes talking of character sets other than US-ASCII and 7501 UTF-8; 7503 e. Renamed CTL to CONTROL to avoid conflict with the CTL rule 7504 defined in RFC4234; 7506 f. Removed ABNF rules defined in RFC4234; 7508 g. Changed the partstatparam ABNF rule for clarity; 7510 h. Clarified the purpose of negative durations; 7512 i. Added informational references to RFC 2392 (CID URL) and RFC 4516 7513 (LDAP URL). 7515 j. Updated TZDB reference. 7517 B.3. Changes in -04 7519 A detailed list of changes is available at the following page: 7520 http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/ 7521 draft-ietf-calsify-rfc2445bis-04.changes.html. 7523 a. Issue 16: Clarified that recurrence instances, generated by a 7524 recurrence rule, with an invalid date or nonexistent local time 7525 must be ignored and not counted as part of the recurrence set. 7527 b. Issue 26: Clarified how to handle the BYHOUR, BYMINUTE and 7528 BYSECOND rule parts when "DTSTART" is a DATE value. 7530 c. Issue 28: Removed the MUST requirement to specify the "RDATE" 7531 property whenever the duration of a recurrence instance is 7532 modified. 7534 d. Issue 29: Clarified that the "DTSTART" property is REQUIRED in 7535 all types of recurring components. 7537 e. Issue 32: Introduced the notion of an "iCalendar stream" to make 7538 it explicit when we are refering to a "single iCalendar object" 7539 or a "sequence of iCalendar objects". 7541 f. Issue 34: Clarified what should be done with the "method" 7542 parameter when the iCalendar stream is a sequence of iCalendar 7543 objects. 7545 g. Issue 40: Changed to fbprop ABNF rule to specify that the 7546 "DTSTAMP" and the "UID" properties are REQUIRED in "VFREEBUSY" 7547 components. 7549 h. Issue 43: Removed the MUST requirement to specify the "DTSTART" 7550 and the "DTEND" properties as local time in recurring components, 7551 but added a note that in most cases this is the right thing to 7552 do. 7554 i. Issue 44: Changed the x-prop ABNF to allow any parameters on non- 7555 standard properties. 7557 j. Issue 46: Simplified the tzprop, audioprop, dispprop, emailprop, 7558 and procprop ABNF rules by removing the number of required 7559 properties in front of the "*". 7561 k. Issue 48: Deprecated the "RANGE" parameter. 7563 l. Issue 51: Clarified implicit duration of day events with no 7564 "DTEND" nor "DURATION" property. 7566 m. Issue 52: Removed x-name from the "recur" rule part definition. 7567 It should be sufficient to allow xparam on properties of RECUR 7568 value type. 7570 n. Issue 53: Updated the NON-US-ASCII ABNF rule for UTF-8. 7572 o. Issue 56: Changed the "recur" ABNF rule to allow rule parts to be 7573 specified in any order. 7575 p. Issue 57: Specified that the "DURATION" property MUST be 7576 specified as a "dur-day" or "dur-week" value when the "DTSTART" 7577 is a DATE. 7579 q. Issue 58: Changed the jourprop ABNF rule to allow the 7580 "DESCRIPTION" property to occur more than once. 7582 r. Numerous editorial changes. 7584 s. Changed reference to RFC 4646 for Language-Tag. 7586 B.4. Changes in -03 7588 A detailed list of changes is available at the following page: 7589 http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/ 7590 draft-ietf-calsify-rfc2445bis-03.changes.html. 7592 a. Numerous editorial changes. 7594 b. Specified that "DTSTART" should match the pattern of "RRULE" and 7595 is always part of the "COUNT". 7597 c. Specified "RRULE" should not occur more than once in recurring 7598 components. 7600 d. Deprecated "EXRULE". 7602 e. Fixed all ABNF errors reported by Bill Fenner's ABNF parsing web 7603 service available at: 7604 http://rtg.ietf.org/~fenner/abnf.cgi. 7606 f. Changed reference to RFC 4648 for Base64 encoding. 7608 B.5. Changes in -02 7610 A detailed list of changes is available at the following page: 7611 http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/ 7612 draft-ietf-calsify-rfc2445bis-02.changes.html. 7614 a. Numerous editorial changes including the typos listed in the 7615 "RFC2445 Errata": 7616 http://www.rfc-editor.org/cgi-bin/errataSearch.pl?rfc=2445& 7617 and in the "RFC2445 Issues List": 7618 http://www.softwarestudio.org/iCal/2445Issues.html. 7620 b. Clarified line folding requirements. 7622 c. Clarified charset requirements. 7624 d. Clarified line limits requirements. 7626 e. Clarified on the use of the "LANGUAGE" parameter. 7628 f. Fixed the eventprop, todoprop and jourprop ABNF rules with 7629 respect to required properties. 7631 g. Fixed all the examples to use RFC2606-compliant FQDNs. 7633 h. Fixed the Content-ID URLs in the examples. 7635 i. Fixed the LDAP URLs in the examples. 7637 j. Moved multiple references in the Informative References section. 7639 k. Updated the Acknowledgments section. 7641 B.6. Changes in -01 7643 A detailed list of changes is available at the following page: 7644 http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/ 7645 draft-ietf-calsify-rfc2445bis-01.changes.html. 7647 a. Numerous editorial changes (typos, errors in examples, etc.). 7649 b. Fixed invalid media types in examples. 7651 c. Fixed the "DTSTAMP" values in the examples. 7653 d. Moved media type registration in a separate IANA Consideration 7654 section. 7656 e. Added Internationalization Considerations section. 7658 f. Added Security Considerations section. 7660 g. Updated the Acknowledgments section. 7662 Appendix C. Open issues (to be removed by RFC Editor prior to 7663 publication) 7665 C.1. update_intro 7667 Type: edit 7669 bernard.desruisseaux@oracle.com (2007-02-20): Update Introduction 7670 section. 7672 C.2. update_vtimezone_examples 7674 Type: edit 7676 bernard.desruisseaux@oracle.com (2007-02-07): The time zone 7677 information for US/Eastern needs to be updated. 7679 Resolution: Done. 7681 C.3. #issue10+end_date_not_inclusive 7683 Type: change 7685 7688 reinhold@kainhofer.com (2006-06-03): 7690 Resolution: 7692 C.4. #issue61+ianaparam 7694 Type: change 7696 7699 bernard.desruisseaux@oracle.com (2006-11-05): All properties should 7700 allow ianaparam the same way they allow xparam. All components 7701 should allow iana-prop the same way they allow x-prop. 7703 Resolution: Changed all ABNF accordingly. 7705 C.5. #issue11+4.3.10_byxxx_rule_part_examples 7707 Type: change 7709 7712 reinhold@kainhofer.com (2006-06-03): We should add more BYXXX rule 7713 parts examples. 7715 Resolution: 7717 C.6. #issue75+4.6.5_rdate_format_in_vtimezone 7719 Type: change 7721 7724 bernard.desruisseaux@oracle.com (2007-02-07): We need to clarify the 7725 DATE-TIME format required for the "RDATE" property in "VTIMEZONE" 7726 components. 7728 Resolution: The "RDATE" property MUST be specified as a local DATE- 7729 TIME value. 7731 C.7. #issue79+4.6.5_dtstart_and_rdate_in_vtimezone 7733 Type: change 7735 7738 bernard.desruisseaux@oracle.com (2007-02-15): We need to clarify that 7739 "DTSTART" always specify a onset date-time of an observance and that 7740 its value does not need to be repeated in an "RDATE" property. 7742 Resolution: 7744 C.8. 4.8.1.1_attach_description_incomplete 7746 Type: change 7748 bernard.desruisseaux@oracle.com (2007-02-14): The description of the 7749 "ATTACH" property is incomplete. 7751 Resolution: 7753 C.9. 4.8.1.4_comment_description_incomplete 7755 Type: change 7757 bernard.desruisseaux@oracle.com (2007-02-14): The description of the 7758 "COMMENT" property is incomplete. 7760 Resolution: 7762 C.10. 4.8.2.1_completed_description_incomplete 7764 Type: change 7766 bernard.desruisseaux@oracle.com (2007-02-14): The description of the 7767 "COMPLETED" property is incomplete. 7769 Resolution: 7771 C.11. #issue76+4.8.2.2_dtend_dtstart_value_type 7773 Type: change 7775 7777 bernard.desruisseaux@oracle.com (2007-02-13): We should clarify that 7778 the value type of the "DTEND" property MUST be the same as the 7779 "DTSTART" property 7781 Resolution: Done. 7783 C.12. #issue77+4.8.2.3_due_dtstart_value_type 7785 Type: change 7787 7790 bernard.desruisseaux@oracle.com (2007-02-13): We should clarify that 7791 the value type of the "DUE" property MUST be the same as the 7792 "DTSTART" property 7794 Resolution: Done. 7796 C.13. 4.8.2.3_due_description_incomplete 7798 Type: change 7800 bernard.desruisseaux@oracle.com (2007-02-14): The description of the 7801 "DUE" property is incomplete. 7803 Resolution: 7805 C.14. #issue63+4.8.5.3_rdate_and_dtstart 7807 Type: change 7809 7812 bernard.desruisseaux@oracle.com (2006-11-05): We need to clarify 7813 whether RDATE can specify a value earlier in time than DTSTART. 7815 Resolution: 7817 C.15. 4.8.6.2_repeat_description_incomplete 7819 Type: change 7821 bernard.desruisseaux@oracle.com (2007-02-14): The description of the 7822 "REPEAT" property is incomplete. 7824 Resolution: 7826 C.16. 4.8.7.1_created_description_incomplete 7828 Type: change 7830 bernard.desruisseaux@oracle.com (2007-02-14): The description of the 7831 "CREATED" property is incomplete. 7833 Resolution: 7835 C.17. 4.8.7.2_dtstamp_description_incomplete 7837 Type: change 7839 bernard.desruisseaux@oracle.com (2007-02-14): The description of the 7840 "DTSTAMP" property is incomplete. 7842 Resolution: 7844 C.18. #issue65+6_recommended_practices_tzid 7846 Type: change 7848 7851 bernard.desruisseaux@oracle.com (2006-11-05): We should clarify the 7852 3rd recommendations to specify that DTSTART and DTEND/DUE of DATE- 7853 TIME value type may be specified with different TZID parameter 7854 values. 7856 Resolution: Done. 7858 C.19. add_i18n_section 7860 Type: change 7862 bernard.desruisseaux@oracle.com (2006-06-21): Add 7863 Internationalization Considerations section. 7865 C.20. #issue19+iana_considerations 7867 Type: change 7869 <> 7871 lear@cisco.com (): The IANA Considerations sections needs to define 7872 new registries and templates for new registrations. 7874 Resolution: 7876 Author's Address 7878 Bernard Desruisseaux (editor) 7879 Oracle Corporation 7880 600 blvd. de Maisonneuve West 7881 Suite 1900 7882 Montreal, QC H3A 3J2 7883 CANADA 7885 EMail: bernard.desruisseaux@oracle.com 7886 URI: http://www.oracle.com/ 7888 Full Copyright Statement 7890 Copyright (C) The IETF Trust (2007). 7892 This document is subject to the rights, licenses and restrictions 7893 contained in BCP 78, and except as set forth therein, the authors 7894 retain all their rights. 7896 This document and the information contained herein are provided on an 7897 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 7898 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 7899 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 7900 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 7901 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 7902 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 7904 Intellectual Property 7906 The IETF takes no position regarding the validity or scope of any 7907 Intellectual Property Rights or other rights that might be claimed to 7908 pertain to the implementation or use of the technology described in 7909 this document or the extent to which any license under such rights 7910 might or might not be available; nor does it represent that it has 7911 made any independent effort to identify any such rights. Information 7912 on the procedures with respect to rights in RFC documents can be 7913 found in BCP 78 and BCP 79. 7915 Copies of IPR disclosures made to the IETF Secretariat and any 7916 assurances of licenses to be made available, or the result of an 7917 attempt made to obtain a general license or permission for the use of 7918 such proprietary rights by implementers or users of this 7919 specification can be obtained from the IETF on-line IPR repository at 7920 http://www.ietf.org/ipr. 7922 The IETF invites any interested party to bring to its attention any 7923 copyrights, patents or patent applications, or other proprietary 7924 rights that may cover technology that may be required to implement 7925 this standard. Please address the information to the IETF at 7926 ietf-ipr@ietf.org. 7928 Acknowledgement 7930 Funding for the RFC Editor function is provided by the IETF 7931 Administrative Support Activity (IASA).