idnits 2.17.1 draft-ietf-calsch-ical-03.txt: -(1017): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1024): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1043): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1057): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1069): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1073): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1074): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1075): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1099): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1107): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1112): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1117): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1132): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1139): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1146): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1151): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2827): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There are 64 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 79 longer pages, the longest (page 21) being 79 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 54 characters in excess of 72. ** The abstract seems to contain references ([ICMS], [RFC2048], [ITIP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 2225 has weird spacing: '...ld this meeti...' == 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). -- 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 (Mary 1998) is 9627 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) == Missing Reference: 'RFC 2119' is mentioned on line 223, but not defined == Missing Reference: 'ICAL' is mentioned on line 286, but not defined == Missing Reference: 'IRIP' is mentioned on line 297, but not defined == Missing Reference: 'MIME-DIR' is mentioned on line 2260, but not defined == Unused Reference: 'ISO 9070' is defined on line 3864, but no explicit reference was found in the text == Unused Reference: 'RFC 1738' is defined on line 3882, but no explicit reference was found in the text == Unused Reference: 'RFC 1872' is defined on line 3888, but no explicit reference was found in the text == Unused Reference: 'RFC1983' is defined on line 3891, but no explicit reference was found in the text == Unused Reference: 'RFC 2045' is defined on line 3893, but no explicit reference was found in the text == Unused Reference: 'RFC 2047' is defined on line 3900, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 3908, but no explicit reference was found in the text == Unused Reference: 'VCARD' is defined on line 3915, but no explicit reference was found in the text == Unused Reference: 'XAPIA' is defined on line 3923, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ICMS' -- Possible downref: Non-RFC (?) normative reference: ref. 'IMIP' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO 8601' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO 9070' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITIP' -- Possible downref: Non-RFC (?) normative reference: ref. 'MIME DIR' ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 1766 (Obsoleted by RFC 3066, RFC 3282) ** Obsolete normative reference: RFC 1872 (Obsoleted by RFC 2112) ** Downref: Normative reference to an Informational RFC: RFC 1983 ** Obsolete normative reference: RFC 2048 (Obsoleted by RFC 4288, RFC 4289) -- Possible downref: Non-RFC (?) normative reference: ref. 'UTF-8' -- Possible downref: Non-RFC (?) normative reference: ref. 'VCARD' -- Possible downref: Non-RFC (?) normative reference: ref. 'VCAL' -- Possible downref: Non-RFC (?) normative reference: ref. 'XAPIA' Summary: 16 errors (**), 0 flaws (~~), 19 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Frank Dawson, Lotus 3 Internet Draft Derik Stenerson, Microsoft 4 October 22, 1997 5 Expires Mary 1998 7 Internet Calendaring and Scheduling Core Object Specification 8 (iCalendar) 10 Status of this Memo 12 This memo is an Internet-Draft. Internet-Drafts are working documents 13 of the Internet Engineering Task Force (IETF), its areas, and its 14 working groups. Note that other groups MAY also distribute working 15 documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months. Internet-Drafts MAY be updated, replaced, or made obsolete by 19 other documents at any time. It is not appropriate to use Internet- 20 Drafts as reference material or to cite them other than as a "working 21 draft" or "work in progress". 23 To learn the current status of any Internet-Draft, please check the 24 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 25 Directories on ds.internic.net (US East Coast), nic.nordu.net 26 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 27 Rim). 29 Distribution of this memo is unlimited. 31 Copyright (C) The Internet Society 1997. All Rights Reserved. 33 Abstract 35 There is a clear need to provide and deploy interoperable calendaring 36 and scheduling services for the Internet. Current group scheduling 37 and Personal Information Management (PIM) products are being extended 38 for use across the Internet, today, in proprietary ways. This memo 39 has been defined to provide the a definition of a common format for 40 openly exchanging calendaring and scheduling information across the 41 Internet. 43 This memo is formatted as a registration for a MIME media type per 44 [RFC 2048]. However, the format in this memo is equally applicable 45 for use outside of a MIME message content type. 47 The proposed media type value is ''TEXT/CALENDAR''. This string would 48 label a media type containing calendaring and scheduling information 49 encoded as text characters formatted in a manner outlined below. 51 This MIME media type provides a standard content type for capturing 52 calendar event and to-do information. It also can be used to convey 53 free/busy time information. The content type is suitable as a MIME 54 message entity that can be transferred over MIME based email systems 55 or using HTTP. In addition, the content type is useful as an object 56 for interactions between desktop applications using the operating 57 system clipboard, drag/drop or file systems capabilities. 59 This memo is based on the earlier work of the vCalendar specification 60 for the exchange of personal calendaring and scheduling information. 61 In order to avoid confusion with this referenced work, this memo is 62 to be known as the iCalendar specification. This memo is based on the 63 calendaring and scheduling model defined in []. The document is also 64 the basis for the calendaring and scheduling interoperability 65 protocol defined in [ITIP]. 67 This memo also includes the format for defining iCalendar object 68 methods. An iCalendar object method is a set of usage constraints for 69 the iCalendar object. For example, these methods might define 70 scheduling messages that request an event be scheduled, reply to an 71 event request, send a cancellation notice for an event, modify or 72 replace the definition of an event, provide a counter proposal for an 73 original event request, delegate an event request to another 74 individual, request free or busy time, reply to a free or busy time 75 request, or provide similar scheduling messages for a to-do or 76 journal entry calendar component. 78 Table of Contents 80 1......................................................................7 81 Introduction...........................................................8 82 2. Basic Grammar and Conventions.......................................8 83 2.1 Formatting Conventions...........................................9 84 2.2 Related Memos...................................................10 85 3. TEXT/CALENDAR Registration Information.............................10 86 4. iCalendar Object Specification.....................................12 87 4.1 Content Considerations..........................................13 88 4.1.1 Content Lines................................................13 89 4.1.2 List and Field Separators....................................14 90 4.1.3 Multiple Values..............................................15 91 4.1.4 Binary Content...............................................15 92 4.1.5 Property Parameters..........................................15 93 4.1.6 Alternate Text Representation................................16 94 4.1.7 Character Set................................................17 95 4.1.8 Language.....................................................17 96 4.1.9 Value Data Types.............................................17 97 4.2 iCalendar object................................................28 98 4.3 Property........................................................28 99 4.4 Calendar Components.............................................29 100 4.4.1 Event Component..............................................29 101 4.4.2 To-do Component..............................................31 102 4.4.3 Journal Component............................................31 103 4.4.4 Free/Busy Component..........................................32 104 4.4.5 Alarm Component..............................................33 105 4.4.6 Timezone Component...........................................34 106 4.5 Calendar Properties.............................................38 107 4.5.1 Calendar Scale...............................................38 108 4.5.2 Method.......................................................39 109 4.5.3 Product Identifier...........................................39 110 4.5.4 Source.......................................................40 111 4.5.5 Source Name..................................................40 112 4.5.6 Version......................................................41 113 4.6 Component Properties............................................41 114 4.6.1 Attachment...................................................41 115 4.6.2 Attendee.....................................................42 116 4.6.3 Categories...................................................44 117 4.6.4 Classification...............................................45 118 4.6.5 Comment......................................................46 119 4.6.6 Contact......................................................46 120 4.6.7 Date/Time Completed..........................................47 121 4.6.8 Date/Time Created............................................47 122 4.6.9 Date/Time Due................................................47 123 4.6.10 Date/Time End...............................................48 124 4.6.11 Date/Time Stamp.............................................48 125 4.6.12 Date/Time Start.............................................49 126 4.6.13 Daylight....................................................49 127 4.6.14 Description.................................................50 128 4.6.15 Duration....................................................50 129 4.6.16 Exception Date/Times........................................51 130 4.6.17 Exception Rule..............................................52 131 4.6.18 Free/Busy Time..............................................52 132 4.6.19 Geographic Position.........................................54 133 4.6.20 Last Modified...............................................54 134 4.6.21 Location....................................................54 135 4.6.22 Percent Complete............................................55 136 4.6.23 Priority....................................................56 137 4.6.24 Recurrence Date/Times.......................................56 138 4.6.25 Recurrence ID...............................................57 139 4.6.26 Recurrence Rule.............................................58 140 4.6.27 Related To..................................................65 141 4.6.28 Repeat Count................................................66 142 4.6.29 Request Status..............................................66 143 4.6.30 Resources...................................................68 144 4.6.31 Sequence Number.............................................68 145 4.6.32 Status......................................................69 146 4.6.33 Summary.....................................................70 147 4.6.34 Time Transparency...........................................70 148 4.6.35 Time Zone Name..............................................71 149 4.6.36 Time Zone Offset............................................71 150 4.6.37 Uniform Resource Locator....................................71 151 4.6.38 Unique Identifier...........................................72 152 4.6.39 Non-standard Properties.....................................73 153 5. Recommended Practices..............................................73 154 6. Registration of Content Type Elements..............................74 155 6.1 Registration of New and Modified iCalendar object Methods.......74 156 6.2 Registration of New Properties..................................74 157 6.2.1 Define the property..........................................74 158 6.2.2 Post the Property definition.................................75 159 6.2.3 Allow a comment period.......................................75 160 6.2.4 Submit the property for approval.............................75 161 6.3 Property Change Control.........................................76 162 7. File extension.....................................................76 163 8. Macintosh File Type Code...........................................76 164 9. References.........................................................76 165 10. Acknowledgments...................................................78 166 11. Copyright.........................................................78 167 12. Author's Address..................................................78 168 13. iCalendar object Examples.........................................79 169 14. Full Copyright Statement..........................................82 171 1. 173 Introduction 175 The use of calendaring and scheduling has grown considerably in the 176 last decade. Enterprise and inter-enterprise business has become 177 dependent on rapid scheduling of events and actions using this 178 information technology. However, the longer term growth of 179 calendaring and scheduling, is currently limited by the lack of 180 Internet standards for the message content types that are central to 181 these groupware applications. This memo is intended to progress the 182 level of interoperability possible between dissimilar calendaring and 183 scheduling applications. This memo defines a MIME content type for 184 exchanging electronic calendaring and scheduling information. The 185 Internet Calendaring and Scheduling Core Object Specification, or 186 iCalendar, allows for the capture and exchange of information 187 normally stored within a calendaring and scheduling application; such 188 as a Personal Information Manager or a Group Scheduling product. 190 The calendaring and scheduling model implemented by this memo is 191 defined in the [ICMS]. 193 The format is suitable as an exchange format between applications or 194 systems. The format is defined in terms of a MIME content type. This 195 will enable the object to be exchanged using several transports, 196 including but not limited to SMTP, HTTP, a file system, desktop 197 interactive protocols such as the use of a memory-based clipboard or 198 drag/drop interactions, point-to-point asynchronous communication, 199 wired-network transport, or some form of unwired transport such as 200 infrared might also be used. 202 The definition of a calendaring and scheduling interoperability 203 protocol is the subject of another memo [ITIP]. 205 The memo also provides for the definition of iCalendar object methods 206 that will map this content type to a set of messages for supporting 207 calendaring and scheduling operations such as requesting, replying 208 to, modifying, and canceling meetings or appointments, to-dos and 209 journal entries. The iCalendar object methods can be used to define 210 other calendaring and scheduling operations such a requesting for and 211 replying with free/busy time data. 213 The memo also includes a formal grammar for the content type to aid 214 in the implementation of parsers and to serve as the definitive 215 reference when ambiguities or questions arise in interpreting the 216 descriptive prose definition of the memo. 218 2. Basic Grammar and Conventions 220 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 221 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 222 document are to be interopreted as described in [RFC 2119]. 224 This memo makes use of both a descriptive prose and a more formal 225 notation for defining the calendaring and scheduling format. 227 The notation used in this memo is the augmented BNF notation of [RFC 228 822]. Readers intending on implementing this format defined in this 229 memo should be familiar with this notation in order to properly 230 interpret the specifications of this memo. 232 All numeric and hexadecimal values used in this memo are given in 233 decimal notation. All names of properties, property parameters, 234 enumerated property values and property parameter values are case- 235 insensitive. However, all other property values are case-sensitive, 236 unless otherwise stated. 238 Note: All indented editorial notes, such as this one, are 239 intended to provide the reader with additional information that 240 is not essential to the building of a conformant implementation 241 of the specifications of this memo. The information is provided 242 to highlight a particular feature or characteristic of the 243 specifications. 245 The format for the iCalendar object is based on the syntax of the 246 [MIME DIR] content type. While the iCalendar object is not a profile 247 of the [MIME DIR] content type, it does reuse a number of the 248 elements from the [MIME DIR] specification. 250 2.1 Formatting Conventions 252 The mechanisms defined in this memo are defined in propose. In order 253 to refer to elements of the calendaring and scheduling model, core 254 object or interoperability protocol defined in this memo, [ICMS] and 255 [ITIP], some formatting conventions have been used. Calendaring and 256 scheduling roles defined by [ICMS] are referred to in quoted-strings 257 of text with the first character of each word in upper case. For 258 example, "Organizer" refers to a role of a "Calendar User" within the 259 scheduling protocol defined by [ITIP] Calendar components defined by 260 this memo are referred to with capitalized, quoted-strings of text. 261 All calendar components start with the letter "V". For example, 262 "VEVENT" refers to the event calendar component, "VTODO" refers to 263 the to-do calendar component and "VJOURNAL" refers to the daily 264 journal calendar component. Scheduling methods defined by [ITIP] are 265 referred to with capitalized, quoted-strings of text. For example, 266 "REQUEST" refers to the method for requesting a scheduling calendar 267 component be created or modified, "REPLY" refers to the method a 268 recipient of a request uses to update their status with the 269 "Organizer" of the calendar component. 271 The properties defined by this memo are referred to with capitalized, 272 quoted-strings of text, followed by the word "property". For example, 273 "ATTENDEE" property refers to the iCalendar property used to convey 274 the calendar address of a calendar user. Property parameters defined 275 by this memo are referred to with lower case, quoted-strings of text, 276 followed by the word "parameter". For example, "value" parameter 277 refers to the iCalendar property parameter used to override the 278 default data type for a property value. Enumerated values defined by 279 this memo are referred to with capitalized text, either alone or 280 followed by the word "value". 282 2.2 Related Memos 284 Implementers will need to be familiar with several other memos that, 285 along with this memo, form a framework for Internet calendaring and 286 scheduling standards. This memo, [ICAL], specifies a core 287 specification of objects, data types, properties and property 288 parameters. 290 [ICMS] - specifies a common terminology and abstract; 292 [ITIP] - specifies an interoperability protocol for scheduling 293 between different implementations; 295 [IMIP] specifies an Internet email binding for [ITIP]; 297 [IRIP] - specifies an Internet real time protocol binding for [ITIP]. 299 This memo does not attempt to repeat the specification of concepts or 300 definitions from these other memos. Where possible, references are 301 made to the memo that provides for the specification of these 302 concepts or definitions. 304 3. TEXT/CALENDAR Registration Information 306 The Calendaring and Scheduling Core Object Specification is intended 307 for use as a MIME content type. However, the implementation of the 308 memo is in no way limited solely as a MIME content type. 310 The following text is intended to register this memo as the MIME 311 content type "text/calendar". 313 To: ietf-types@uninett.no 315 Subject: Registration of MIME content type text/calendar. 317 MIME media type name: text 319 MIME subtype name: calendar 321 Required parameters: method 323 The "method" parameter is used to convey the iCalendar object 324 method to which the calendaring and scheduling information 325 pertains. It also is an identifier for the set of properties that 326 the iCalendar object will consist of. The parameter is to be used 327 as a guide for applications interpreting the information contained 328 within the body part. It should NOT be used to exclude or require 329 particular pieces of information unless the identified method 330 definition specifically calls for this behavior. Unless 331 specifically forbidden by a particular method definition, a 332 text/calendar content type MAY contain any set of properties 333 permitted by the Calendaring and Scheduling Core Object 334 Specification. 336 The value for the "method" parameter is defined as follows: 338 method = 341 Optional parameters: charset, component 343 The "charset" parameter is defined in [RFC 2046] for other body 344 parts. It is used to identify the default character set used within 345 the body part. 347 The "component" parameter conveys the type of iCalendar calendar 348 component within the body part. If the iCalendar object contains 349 more than one calendar component, then the components are specified 350 as a comma-separated list of values. 352 The value for the "component" parameter is defined as follows: 354 component = "VEVENT" / "VTODO" / "VJOURNAL" / "VFREEBUSY" 355 / x-token / iana-comp 357 x-token = 361 iana-comp = 365 Optional content header fields: Any header fields defined by [RFC 366 2045]. 368 Encoding considerations: This MIME content type can contain 8bit 369 characters, so the use of quoted-printable or base64 MIME content- 370 transfer-encodings MAY be necessary when iCalendar objects are 371 transferrred across protocols restricted to the 7bit repertoire. 372 Note that each property in the content entity MAY also have special 373 characters encoded using a BACKSLASH character (ASCII decimal 92) 374 escapement technique. This means that content values MAY end up 375 encoded twice. 377 Security considerations: SPOOFING - - In this memo, the "Organizer" 378 is the only person authorized to make changes to an existing 379 "VEVENT", "VTODO", "VJOURNAL" calendar component and redistribute 380 the updates to the "Attendees". An iCalendar object that 381 maliciously changes or cancels an existing "VEVENT", "VTODO" or 382 "VJOURNAL" or "VFREEBUSY" calendar component MAY be constructed by 383 someone other than the "Organizer" and sent to the "Attendees". In 384 addition in this memo, an "Attendee" of a "VEVENT", "VTODO", 385 "VJOURNAL" calendar component is the only person authorized to 386 update any parameter associated with their "ATTENDEE" property and 387 send it to the "Organizer". An iCalendar object that maliciously 388 changes the "ATTENDEE" parameters MAY be constructed by someone 389 other than the real "Attendee" and sent to the "Organizer". 391 PROCEDURAL ALARMS - - An iCalendar object can be created that 392 contains a "VEVENT" and "VTODO" calendar component with an "VALARM" 393 calendar components. The "VALARM" calendar component MAY be of type 394 PROCEDURE and MAY have an attachment containing some sort of 395 executable program. Implementations that incorporate these types of 396 alarms are subject to any virus or malicious attack that MAY occur 397 as a result of executing the attachment. 399 ATTACHMENTS - - An iCalendar object MAY include references to 400 Uniform Resource Locators that MAY be programmed resources. 402 Implementers and users of this memo should be aware of the network 403 security implications of accepting and parsing such information. In 404 addition, the security considerations observed by implementations 405 of electronic mail systems should be followed for this memo. 407 Interoperability considerations: This MIME content type is intended 408 to define a common format for conveying calendaring and scheduling 409 information between different systems. It is heavily based on the 410 earlier [VCAL] industry specification. 412 Intended Usage: COMMON 414 Published specification: This memo. 416 Author/Change controllers: 418 Frank Dawson 419 6544 Battleford Drive 420 Raleigh, NC 27613-3502 421 919-676-9515 (Telephone) 422 919-676-9564 (Data/Facsimile) 423 Frank_Dawson@Lotus.com (Internet Mail) 425 Derik Stenerson 426 One Microsoft Way 427 Redmond, WA 98052-6399 428 425-936-5522 (Telephone) 429 425-936-7329 (Facsimile) 430 deriks@microsoft.com (Internet Mail) 432 4. iCalendar Object Specification 434 The following sections define the details of a Calendaring and 435 Scheduling Core Object Specification. This information is intended to 436 be an integral part of the MIME content type registration. In 437 addition, this information MAY be used independent of such content 438 registration. In particular, this memo has direct applicability for 439 use as a calendaring and scheduling exchange format in file-, memory- 440 or network-based transport mechanisms. 442 4.1 Content Considerations 444 The iCalendar object consists of lines of text. This section defines 445 how the content lines MUST be formatted. 447 4.1.1 Content Lines 449 The iCalendar object consists of individual lines of text, delimited 450 by a line break, which is a CRLF sequence (ASCII decimal 13, followed 451 by ASCII decimal 10). Line of text should not be longer than 76 452 characters, excluding the line break. 454 Long lines of text can be split into a multiple line representations 455 using a line "folding" technique. That is, a long line MAY be split 456 at any point by inserting a CRLF immediately followed by a single 457 LWSP character (i.e., SPACE, ASCII decimal 32 or HTAB, ASCII decimal 458 9). Any sequence of CRLF followed immediately by a single LWSP 459 character is ignored (i.e., removed) when processing the content 460 type. 462 For example the line: 464 DESCRIPTION:This is a long description that exists on a long line. 466 Can be represented as: 468 DESCRIPTION:This is a long description 469 that exists on a long line. 471 The process of moving from this folded multiple line representation 472 to its single line representation is called "unfolding". Unfolding is 473 accomplished by removing the CRLF character and the LWSP character 474 that immediately follows. 476 An intentional formatted text line break MAY only be included in a 477 property value by representing the line break with the character 478 sequence of BACKSLASH (ASCII decimal 92), followed by a LATIN SMALL 479 LETTER N (ASCII decimal 110) or a LATIN CAPITAL LETTER N (ASCII 480 decimal 78), that is "\n" or "\N". 482 For example a multiple line "DESCRIPTION" property value of: 484 Project XYZ Final Review 485 Conference Room - 3B 486 Come Prepared. 488 Could be represented as: 490 DESCRIPTION:Project_XYZ Final_Review\n 491 Conference Room - 3B\nCome_Prepared. 493 The content information associated with an iCalendar object is 494 formatted using a syntax similar to that defined by [MIME DIR]. That 495 is, the content information consists of one or more CRLF-separated 496 content lines as defined by the following notation: 498 contentline = name [";" [ws] paramlist] ":" [ws] value CRLF 499 ;Folding permitted on content lines. 500 ;Lines should be less than 76 characters, excluding CRLF. 502 LWSP = SPACE / HTAB 504 SPACE = 506 HTAB = 508 ws = SPACE / HTAB 510 name = iana-name / x-name ;An iCalendar property 512 iana-name = 516 x-name = 520 value = boolean / cal-address / date / date-time / duration 521 / float / integer / period / recur / text / time / url 522 / utc-offset / x-token 524 iana-value = 528 4.1.2 List and Field Separators 530 List of values MAY be specified for property values or property 531 parameter values. Each value in a list of values MUST be separated by 532 a COMMA character (ASCII decimal 44). A COMMA character in a property 533 value or a property parameter value MUST be escaped with a BACKSLASH 534 character (ASCII decimal 92). 536 Some property values are defined in terms of multiple components. 537 These structured property values MUST have their components separated 538 by a SEMICOLON character (ASCII decimal 59). A SEMICOLON character in 539 a property value MUST be escaped with a BACKSLASH character (ASCII 540 decimal 92). 542 Lists of property parameters MAY be specified for a property. Each 543 property parameter in a list of property parameters MUST be separated 544 by a SEMICOLON character (ASCII decimal 59). A SEMICOLON character in 545 a property parameter value MUST be escaped with a BACKSLASH character 546 (ASCII decimal 92). 548 A COLON character (ASCII decimal 58) in a property parameter value 549 MUST be escaped with a BACKSLASH character (ASCII decimal 92). A 550 COLON character in a property value does not need to be escaped with 551 a BACKSLASH character. 553 A BACKSLASH character (ASCII decimal 92) in a property value or a 554 property parameter value MUST be escaped with another BACKSLASH 555 character. 557 For example, in the following properties a SEMICOLON is used to 558 separate property parameters and property value fields. A COMMA is 559 used to separate values. 561 ATTENDEE;RSVP=TRUE;ROLE=ATTENDEE:J.Smith 563 RDATE;VALUE=DATE:19970304,19970504,19970704,19970904 565 4.1.3 Multiple Values 567 Each property defined in the iCalendar object MAY have multiple 568 values, if allowed in the definition of the specific property. The 569 general rule for encoding multi-valued items is to simply create a 570 new content line for each value; including the property name. 571 However, it should be noted that some properties support encoding 572 multiple values in a single property by separating the values with a 573 COMMA character (ASCII decimal 44). 575 4.1.4 Binary Content 577 There is no support for including binary content information, inline, 578 within an iCalendar object. Binary content information MUST be 579 referenced by a uniform resource locator (URL) type of property 580 value. 582 The following example specifies an "ATTACH" property with a reference 583 to an attachment consisting of a binary object: 585 ATTACH:ftp://xyz.com/public/quarterly-report.doc 587 4.1.5 Property Parameters 589 A property MAY have additional attributes associated with it. These 590 "property parameters" contain meta information about the property or 591 the property value. Property parameters MAY be used to specify the 592 location of an alternate text representation for a property value, 593 the content encoding used on a property value, the language of a text 594 property value or thedata type of the property value. 596 Property parameter values that contain the COLON, SEMICOLON, COMMA or 597 BACKSLASH character separators MUST be specified as quoted-string 598 text values. For example: 600 DESCRIPTION;ALTREP="http://www.wiz.org":The Fall'98 Wild Wizards 601 Conference - - Las Vegas, NV, USA 603 Property parameters are defined by the following notation: 605 ( = parameter *(";" [ws] parameter) 607 parameter = altrepparm ;Alterate text representation 608 / languageparm ;Text language 609 / valuetypeparm ;Property value data type 610 / [parmtype "="] parmvalues ;Parameter extensions 612 parmtype = x-token / iana-ptype 614 iana-ptype = 617 parmvalues = parmvalue / parmvalue *("," [ws] parmvalue) 619 parmvalue = x-name / iana-pvalue 621 iana-pvalue = 624 4.1.6 Alternate Text Representation 626 The "ALTREP" property parameter is an OPTIONAL property parameter. It 627 specifies the URL that points to an alternate representation for a 628 textual property value. The property MUST include a value that 629 reflects the default representation. This property parameter MAY 630 include multiple values, separated by the COMMA character (ASCII 631 decimal 44). The property parameter MAY only be specified in the 632 "COMMENT", "CONTACT", "DESCRIPTION", "LOCATION" and "SUMMARY" 633 properties. 635 For example: 637 DESCRIPTION;ALTREP="CID:":Project 638 XYZ Review Meeting will include the following agenda items: (a) 639 Market Overview, (b) Finances, (c) Project Management 641 The "ALTREP" property parameter value might point to a "text/html" 642 content portion. 644 Content-Type:text/html 645 Content-Id: 646

Project XYZ Review Meeting will include the following 647 agenda items:

  • Market 648 Overview
  • Finances
  • Project Management

    • 650 The "ALTREP" property parameter is defined by the following notation: 652 altrepparm = "altrep" "=" urltype 654 urltype = 656 4.1.7 Character Set 658 There is not a property parameter to declare the character set used 659 in a property value. The default character set for an iCalendar 660 object is [UTF-8]. 662 The "charset" Content-Type parameter MAY be used in MIME transports 663 to specify any other IANA registered character set. 665 4.1.8 Language 667 The "LANGUAGE" property parameter MAY be used to identify the 668 language used in text values. The value of the "language" property 669 parameter is that defined in [RFC 1766]. 671 Note: For transport in a MIME entity, the Content-Language 672 header field MAY be used to set the default language for the 673 entire body part. 675 The "LANGUAGE" property parameter is defined by the following 676 notation: 678 languageparm = "language" "=" language 680 language = 682 4.1.9 Value Data Types 684 The "VALUE" property parameter is an OPTIONAL property parameter. It 685 is used to identify the data type and format of the property value. 686 The values of a property MUST only be of a single data type. For 687 example, a "RDATE" property can not have a combination of DATE-TIME 688 and TIME values. 690 The "VALUE" property parameter is defined by the following notation: 692 valuetypeparm = "value" "=" valuetype 694 valuetype = "boolean" 695 / "cal-address" 696 / "date" 697 / "date-time" 698 / "duration" 699 / "float" 700 / "integer" 701 / "period" 702 / "recur" 703 / "text" 704 / "time" 705 / "url" 706 / "utc-offset" 707 / x-token 708 / iana-value 710 iana-value =     713 The following data types are defined by this memo. 715 4.1.9.1 Boolean 717 The "BOOLEAN" data type is used to identify properties that contain 718 either a "true" or a "false" boolean value. These values are case 719 insensitive. The data type is defined by the following notation: 721 boolean = "TRUE" / "FALSE" 723 For example, any of the following are equivalent: 725 TRUE 726 true 727 TrUe 729 4.1.9.2 Calendar User Address 731 The "CAL-ADDRESS" data type is used to identify properties that 732 contain an address of a calendar user. The phrase component of the 733 address MAY be used to match an unknown address with an otherwise 734 known individual, group, or resource. The data type is as defined by 735 the following notation: 737 cal-address = addr-spec / phrase "<" addr-spec ">" 739 addr-spec = local-part "@" domain ;RFC 822 style address 740 local-part = WORD *("." WORD) 741 domain = domain-ref *("." domain-ref) 742 domain-ref = ATOM 744 phrase = 1*WORD 745 WORD = ATOM / quoted-string 746 quoted-string = <"> *(qtext/quoted-pair) <"> ; Regular qtext or 747 ; quoted chars. 748 qtext = , ; => MAY be folded 749 "\" & CR, and including linear- 750 white-space> 751 quoted-pair ="\" CHAR ; MAY quote any char 752 CHAR = 754 ATOM = 1* 757 4.1.9.3 Date 759 The "DATE" data type is used to identify values that contain a 760 calendar date. The format is expressed as the [ISO 8601] complete 761 representation, basic format for a calendar date. The text format 762 specifies a four-digit year, two-digit month, and two-digit day of 763 the month. There are no separator characters between the year, month 764 and day component text. The data type is defined by the following 765 notation: 767 DIGIT = ;0-9 769 date-fullyear = 4DIGIT 770 date-month = 2DIGIT ;01-12 771 date-mday = 2DIGIT ;01-28, 01-29, 01-30, 01-31 772 ;based on month/year 774 date = date-fullyear date-month date-mday 776 For example, the following represents July 14, 1997: 778 19970714 780 4.1.9.4 Date-Time 782 The "DATE-TIME" data type is used to identify values that contain a 783 precise calendar date and time of day. The format is expressed as the 784 [ISO 8601] complete representation, basic format for a calendar date 785 and time of day. The text format is a concatenation of the "date", 786 followed by the LATIN CAPITAL LETTER T character (ASCII decimal 84) 787 time designator, followed by the "time" format defined above. The 788 data type is defined by the following notation: 790 date-time = date "T" time ;As specified above in date and time 792 The following represents July 14, 1997, at 1:30 PM in UTC and the 793 equivalent time in New York (four hours behind UTC in DST), expressed 794 as a local time and local time with UTC offset: 796 19970714T133000Z 797 19970714T083000 798 19970714T083000-0400 800 4.1.9.5 Duration 802 The "DURATION" data type is used to identify properties that contain 803 a duration of time. The format is expressed as the [ISO 8601] basic 804 format for the duration of time. The format can represent durations 805 in terms of years, months, days, hours, minutes, and seconds. The 806 data type is defined by the following notation: 808 DIGIT = ;0-9 810 dur-second = 1*DIGIT "S" 811 dur-minute = 1*DIGIT "M" [dur-second] 812 dur-hour = 1*DIGIT "H" [dur-minute] 813 dur-time = "T" (dur-hour / dur-minute / dur-second) 815 dur-week = 1*DIGIT "W" 816 dur-day = 1*DIGIT "D" 817 dur-month = 1*DIGIT "M" [dur-day] 818 dur-year = 1*DIGIT "Y" [dur-month] 819 dur-date = (dur-day / dur-month / dur-year) [dur-time] 821 duration = "P" (dur-date / dur-time / dur-week) 823 For example, a duration of 10 years, 3 months, 15 days, 5 hours, 30 824 minutes and 20 seconds would be: 826 P10Y3M15DT5H30M20S 828 4.1.9.6 Float 830 The "FLOAT" data type is used to identify properties that contain a 831 real value number value. If the property permits, multiple "float" 832 values MAY be specified using a COMMA character (ASCII decimal 44) 833 separator character. The data type is defined by the following 834 notation: 836 DIGIT = ;0-9 838 float = ["+" / "-"] *DIGIT ["." *DIGIT] 840 For example: 842 1000000.0000001 843 1.333 844 -3.14 846 4.1.9.7 Integer 848 The "INTEGER" data type is used to identify properties that contain a 849 signed integer value. The valid range for "integer" is -2147483648 to 850 2147483647. If the sign is not specified, then the value is assumed 851 to be positive. If the property permits, multiple "integer" values 852 MAY be specified using a COMMA character (ASCII decimal 44) separator 853 character. The data type is defined by the following notation: 855 DIGIT = ;0-9 857 integer = ["+" / "-"] *DIGIT 858 For example: 860 1234567890 861 -1234567890 862 +1234567890 863 432109876 865 4.1.9.8 Period of Time 867 The "PERIOD" data type is used to identify values that contain a 868 precise period of time. There are two forms of a period of time. 870 A period of time MAY be identified by it start and its end. This 871 format is expressed as the [ISO 8601] complete representation, basic 872 format for "DATE-TIME" start of the period, followed by a SOLIDUS 873 character (ASCII decimal 47), followed by the "DATE-TIME" of the end 874 of the period. For example, the period starting at 10 AM in Seattle 875 (eight hours behind UTC) on January 1, 1997 and ending at 11 PM in 876 Seattle on January 1, 1997 would be: 878 19970101T100000-0800/19970101T230000-0800 880 A period of time MAY also be defined by a start and a duration of 881 time. The format is expressed as the [ISO 8601] complete 882 representation, basic format for the "DATE-TIME" start of the period, 883 followed by a SOLIDUS character (ASCII decimal 47), followed by the 884 [ISO 8601] basic format for "DURATION" of the period. For example, 885 the period start at 10 AM in Seattle (eight hours behind UTC) on 886 January 1, 1997 and lasting 5 hours and 30 minutes would be: 888 19970101T100000-0800/PT5H30M 890 The data type is defined by the following notation: 892 period-explicit = date-time "/" date-time 893 ;ISO 8601 complete representation basic format for a period of time 894 ;consisting of a start and end. The start MUST be before the end. 896 period-start = date-time "/" duration 897 ;ISO 8601 complete representation basic format for a period of time 898 ;consisting of a start and duration of time. 900 period = period-explicit / period-start 902 4.1.9.9 Recurrence Rule 904 The "RECUR" data type is used to identify properties that contain a 905 recurrence rule specification. The data type is a structured value 906 consisting of a list of one or more recurrence grammar components. 907 Each component is defined by a NAME=VALUE pair. The components are 908 separated from each other by the SEMICOLON character (ASCII decimal 909 59). The components are not ordered in any particular sequence. 910 Individual components MAY only be specified once. 912 The FREQ component identifies the type of recurrence rule. This 913 component MUST be specified in the recurrence rule. Valid values 914 include MINUTELY, to specify repeating events based on an interval of 915 a minute or more; HOURLY, to specify repeating events based on an 916 interval of an hour or more; DAILY, to specify repeating events based 917 on an interval of a day or more; WEEKLY, to specify repeating events 918 based on an interval of a week or more; MONTHLY, to specify repeating 919 events based on an interval of a month or more; and YEARLY, to 920 specify repeating events based on an interval of a year or more. 922 The INTERVAL component contains a positive integer representing how 923 often the recurrence rule repeats. The default value is "1" or every 924 minute for a MINUTELY rule, every hour for a HOURLY rule, every day 925 for a DAILY rule, every week for a WEEKLY rule, every month for a 926 MONTHLY rule and every year for a YEARLY rule. 928 The UNTIL component defines a date-time value which bounds the 929 recurrence rule in an inclusive manner. If the value specified by 930 UNTIL is synchronized with the specified recurrence, this date-time 931 becomes the last instance of the recurrence. If not present, and the 932 COUNT component is also not present, the RRULE is considered to 933 repeat forever. 935 The COUNT component defines the number of occurrences at which to 936 range-bound the recurrence. This component is ignored if the "UNTIL" 937 component is also present. 939 The BYMINUTE component specifies a COMMA character (ASCII decimal 44) 940 separated list of minutes within an hour. Valid values are 0 to 60. 941 Zero is the beginning of the hour and 60 is the beginning of the next 942 hour. 944 The BYHOUR component specifies a COMMA character (ASCII decimal 44) 945 separated list of hours of the day. Valid values are 0 to 24. Zero is 946 the start of the day and 24 is the start of the next day. 948 The BYDAY component specifies a COMMA character (ASCII decimal 44) 949 separated list of days of the week; MO, indicates Monday; TU, 950 indicates Tuesday; WE, indicates Wednesday; TH, indicates Thursday; 951 FR, indicates Friday; SA, indicates Saturday; SU, indicates Sunday. 953 Each BYDAY values MAY also be preceded by a positive (+n) or negative 954 (-n) integer. If present, this indicates the nth occurrence of the 955 specific day within the MONTHLY or YEARLY RRULE. For example, within 956 a MONTHLY rule, +1MO (or simply 1MO) represents the first Monday 957 within the month, whereas -1MO represents the last Monday of the 958 month. If an integer modifier is not present, it means all days of 959 this type within the specified frequency. For example, within a 960 MONTHLY rule, MO represents all Mondays within the month. 962 The BYMONTHDAY component specifies a COMMA character (ASCII decimal 963 44) separated list of days of the month. Valid values are 1 to 31 or 964 -31 to -1. 966 Each BYMONTHDAY value MAY be preceeded by a postive (+n) or negative 967 (-n) integer. If present, this indicates the nth occurrence of the 968 specific day of the month within the MONTHLY rule. If an integer 969 modifier is not present, it means all days of this type within the 970 specified frequency. For example, within a MONTHLY rule, -10 971 represents the tenth to the last day of the month. 973 The BYYEARDAY component specifies a COMMA character (ASCII decimal 974 44) separated list of days of the year. Valid values are 1 to 366 or 975 -366 to -1. For example, -1 represents the last day of the year 976 (December 31st). 978 The BYWEEKNO component specifies a comma-separated list of weeks of 979 the year. Valid values are 1 to 53. This corresponds to weeks 980 according to week numbering as defined in [ISO 8601]. That is, a week 981 as "A seven day period within a calendar year, starting on a Monday 982 and identified by its ordinal number within the year; the first 983 calendar week of the year is the one that includes the first Thursday 984 of that year." This component is only valid for YEARLY rules. 986 Each BYWEEKNO value MAY be preceded by a positive (+n) or negative (- 987 n) integer. If present, this indicates the nth occurrence of the 988 specific week of the year within the YEARLY rule. If an integer 989 modifier is not present, it means all days of this type within the 990 specified frequency. For example, within a YEARLY rule, 3 represents 991 the third week of the year. 993 The BYMONTH component specifies a comma separated list of months of 994 the year. Valid values are 1 to 12. 996 The WKST component specifies the day on which the workweek starts. 997 Valid values are MO, TU, WE, TH, FR, SA and SU. This is significant 998 when a WEEKLY RRULE has an interval greater than 1, and a BYDAY 999 component is specified. The default value is MO. 1001 The BYSETPOS component specifies a COMMA character (ASCII decimal 44) 1002 separated list of values which corresponds to the nth occurrence 1003 within the set of events specified by the rule. Valid values are 1 to 1004 366 or -366 to -1. It MUST only be used in conjunction with another 1005 Byxxx component. For example "the last work day of the month" could 1006 be represented as: 1008 RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1 1010 If BYxxx component values are found which are beyond the available 1011 scope (ie, BYMONTHDAY=-30 in February), they are simply ignored 1013 Information, not contained in the rule, necessary to determine the 1014 various recurrence instance start time and dates are derived from the 1015 Start Time (DTSTART) entry attribute. For example, 1016 � �FREQ=YEARLY;BYMONTH=1� 1017 � doesn�t specify a specific day within the 1018 month or a time. This information would be the same as what is 1019 specified for DTSTART. 1021 BYxxx components modify the recurrence in some manner. BYxxx 1022 components for a period of time which is the same or greater than the 1023 frequency generally reduce or limit the number of occurrences of the 1024 recurrence generated. For example, � �FREQ=DAILY;BYMONTH=1� 1025 � reduces 1026 the number of recurrence instances from all days (if BYMONTH tag is 1027 not present) to all days in January. BYxxx components for a period of 1028 time less than the frequency generally increase or expand the number 1029 of occurrences of the recurrence. For example, 1030 � �FREQ=YEARLY;BYMONTH=1,2� 1031 � increases the number of days within the 1032 yearly recurrence set from 1 (if BYMONTH tag is not present) to 2. 1034 If only one BYxxx component is specified in the recurrence rule, the 1035 list of � �n� 1036 � unique values would cause � 1037 �n� 1038 � occurrences of the 1039 recurrence within each specified frequency interval, where each 1040 unique list value is substituted in the appropriate date position 1041 within DTSTART for each such occurrence. 1043 If multiple BYxxx components are specified, then the list of � �n� 1044 � 1045 unique values for each lower frequency BYxxx components is applied to 1046 the list of � �n� 1047 � unique values for higher frequency BYxxx 1048 components. This process will not always increase the set of 1049 occurrences. If a higher component is inconsistent with what was 1050 generated for lower components, it would reduce the set. The ordering 1051 of BYxxx components from lower frequency to higher frequency is as 1052 follows: BYMINUTE, BYHOUR, BYDAY, BYMONTHDAY, BYYEARDAY, BYWEEKNO, 1053 BYMONTH, BYSETPOS. 1055 Here is an example of evaluating multiple BYxxx components. 1057 � �FREQ=YEARLY;INTERVAL=2;BYMONTH=1;BYDAY=SU;BYHOUR=8,9;BYMINUTE=30 1058 � � 1060 would first apply the � �BYMINUTE=30� 1061 � To � 1062 �BYHOUR=8,9� 1063 � to arrive at 1064 � �every 8:30AM and 9:30AM� 1065 �. This in turn would be applied to 1066 � �BYDAY=SU� 1067 � to arrive at � 1068 �every Sunday at 8:30AM and 9:30AM� 1069 �. This 1070 would be applied to � �BYMONTH=1� 1071 � to arrive at � 1072 �every Sunday in 1073 January at 8:30AM and 9:30AM� �. Considering the FREQUENCY and 1074 INTERVAL, this would become � �Every Sunday in January at 8:30AM and 1075 9:30AM, every other year� �. If the BYMINUTE, BYDAY, BYMONTHDAY, 1076 BYYEARDAY, BYHOUR or BYMONTH component was missing, the appropriate 1077 mintues, hour, day or month would have been retrieved from DTSTART. 1079 The data type is defined by the following notation: 1081 recur = � �FREQ� 1082 �=freq ";" 1083 [("UNTIL" "=" enddate ";") / ("COUNT" "=" digits ";")] 1084 ["INTERVAL" "=" digits ";"] 1085 ["BYMINUTE" "=" byminlist ";"] 1086 ["BYHOUR" "=" byhrlist ";"] 1087 ["BYDAY" "=" bywdaylist ";"] 1088 ["BYMONTHDAY" "=" bymodaylist ";"] 1089 ["BYYEARDAY" "=" byyrdaylist ";"] 1090 ["BYWEEKNO" "=" bywknolist ";"] 1091 ["BYMONTH" "=" bymolist ";"] 1093 ["BYSETPOS" "=" bysplist ";"] 1094 ["WKST" "=" weekday ";")] 1095 *("X-" word "=" word) ";" 1096 ;Individual components MAY only be specified once. 1097 ;Rule components need not be specified in particular any order. 1099 freq = "MINUTELY� � / "HOURLY" / "DAILY" / "WEEKLY" / "YEARLY" 1101 enddate = date ;A UTC value 1103 digits = 1*DIGIT 1105 DIGIT = ;0-9 1107 byminlist = minutes / ( minutes *(� �,� 1108 � minutes) ) 1110 minutes = 1*2digits ;0 to 60 1112 byhrlist = hour / ( hour *(� �,� 1113 � hour) ) 1115 hour = 1*2 digits ;0 to 24 1117 bywdaylist = weekdaynum / ( weekdaynum *(� �,� 1118 � weekdaynum) ) 1120 weekdaynum = [([plus] ordwk / minus ordwk)] weekday 1122 plus = "+" 1124 minus = "-" 1126 ordwk = 1*2digits ;1 to 53 1128 weekday = "SU" / "MO" / "TU" / "WE" / "TH" / "FR" / "SA" 1129 ;Corresponding to SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, 1130 ;FRIDAY, SATURDAY and SUNDAY days of the week. 1132 bymodaylist = monthdaynum / ( monthdaynum *(� �,� 1133 � monthdaynum) ) 1135 monthdaynum = ([plus] ordmoday) / (minus ordmoday) 1137 ordmoday = 1*2digits ;1 to 31 1139 byyrdaylist = yeardaynum / ( yeardaynum *(� �,� 1140 � yeardaynum) ) 1142 yeardaynum = ([plus] ordyrday) / (minus ordyrday) 1144 ordyrday = 1*3digits ;1 to 366 1146 bywknolist = weeknum / ( weeknum *(� �,� 1147 � weeknum) ) 1149 weeknum = ([plus] ordwk) / (minus ordwk) 1151 bymolist = monthnum / ( monthnum *(� �,� 1152 � monthnum) ) 1153 monthnum = 1*2digits ;1 to 12 1155 bysplist = setposday / ( setposday *("," setposday) ) 1157 setposday = yeardaynum 1159 For example, the following is a rule which specifies 10 meetings 1160 which occur every other day: 1162 FREQ=DAILY;COUNT=10;INTERVAL=2 1164 There are other examples specified in the "RRULE" specification. 1166 4.1.9.10 Text 1168 The "TEXT" data type is used to identify values that contain human 1169 readable text. The character set and language in which the text is 1170 represented is controlled by the "LANGUAGE" property parameters. The 1171 data type is defined by the following notation: 1173 text = 1176 4.1.9.11 Time 1178 The "TIME" data type is used to identify values that contain a time 1179 of day. The format is expressed as the [ISO 8601] complete 1180 representation, basic format for a time of day. The text format 1181 consists of a two-digit 24-hour of the day (i.e., values 0-23), two- 1182 digit minute in the hour (i.e., values 0-59), and two-digit seconds 1183 in the minute (i.e., values 0-59). If seconds of the minute are not 1184 supported by an implementation, then a value of "00" should be 1185 specified for the seconds component. Fractions of an hour, minute or 1186 second are not supported by this format. This format is used to 1187 represent local time, local time with UTC offset and UTC time. UTC 1188 time is identified by a LATIN CAPITAL LETTER Z suffix character 1189 (ASCII decimal 90), the UTC designator, appended to the time. The 1190 local time with UTC offset is expressed as a local time, suffixed 1191 with the signed offset from UTC. The UTC offset is express as the 2- 1192 digit hours and 2-digit minutes difference from UTC. It is expressed 1193 as positive, with an OPTIONAL leading PLUS SIGN character (ASCII 1194 decimal 43), if the local time is ahead of UTC. It is expressed as a 1195 negative, with a leading HYPEN-MINUS character (ASCII decimal 45), if 1196 the local time is behind UTC. Local time has neither the UTC 1197 designator nor the UTC offset suffix text. The data type is defined 1198 by the following notation: 1200 DIGIT = ;0-9 1202 time-hour = 2DIGIT ;00-23 1203 time-minute = 2DIGIT ;00-59 1204 time-second = 2DIGIT ;00-59 1205 time-numzone = ("+" / "-") time-hour time-minute 1206 time-zone = "Z" / time-numzone 1208 time = time-hour time-minute time-second [time-zone] 1210 For example, the following represents 8:30 AM in New York, five hours 1211 behind UTC, in local time and local time with UTC offset. In 1212 addition, 1:30 PM in UTC is illustrated: 1214 083000 1215 083000-0500 1216 133000Z 1218 There are cases when a floating time is intended within a property 1219 value. For example, an event MAY be defined that indicates that an 1220 individual will be busy from 11:00 AM to 1:00 PM every day. In these 1221 cases, a local time MAY be specified. The recipient of an iCalendar 1222 object with a property value consisting of a local time, without any 1223 relative time zone information, should interpret the value as being 1224 fixed to the recipient's locale and time zone. In most cases, a fixed 1225 time is desired. To properly communicate a fixed time in a property 1226 value, either UTC, local time with UTC offset, or local time with a 1227 "VTIMEZONE" calendar component MUST be specified. 1229 4.1.9.12 URL 1231 The "URL" data type is used to identify values that contain a uniform 1232 resource locator (URL) type of reference to the property value. This 1233 data type might be used to reference binary information, for values 1234 that are large, or otherwise undesirable to include directly in the 1235 iCalendar object. 1237 The URL value formats in RFC 1738, RFC 2111 and any other IETF 1238 registered value format MAY be specified. 1240 The data type is defined by the following notation: 1242 url = 1244 Any IANA registered URL type MAY be used. These include, but are not 1245 limited to, those for FTP and HTTP protocols, file access, content 1246 identifier and message identifier. 1248 For example, the following is an URL for a local file: 1250 file:///my-report.txt 1252 4.1.9.13 UTC Offset 1254 The "UTC-OFFSET" data type is used to identify properties that 1255 contain an offset from UTC to local time. The data type is defined by 1256 the following notation: 1258 utc-offset = time-numzone ;As defined above in time data type 1260 For example, the following are UTC offsets are given for standard 1261 time for New York (five hours behind UTC) and Geneva (one hour ahead 1262 of UTC): 1264 -0500 1266 +0100 1268 4.2 iCalendar object 1270 The Calendaring and Scheduling Core Object is a collection of 1271 calendaring and scheduling information. Typically, this information 1272 will consist of a single iCalendar object. However, multiple 1273 iCalendar objects MAY be sequentially, grouped together. The first 1274 line and last line of the iCalendar object MUST contain a pair of 1275 iCalendar object delimiter strings. The syntax for an iCalendar 1276 object is as follows: 1278 icalobject = "BEGIN" ":" [ws] "VCALENDAR" CRLF 1279 icalbody 1280 "END" ":" [ws] "VCALENDAR" CRLF [icalobject] 1282 The following is a simple example of an iCalendar object: 1284 BEGIN:VCALENDAR 1285 VERSION:2.0 1286 PRODID:-//hacksw/handcal//NONSGML v1.0//EN 1287 BEGIN:VEVENT 1288 DTSTART:19970714T120000-0500 1289 DTEND:19970714T235959-0500 1290 SUMMARY:Bastille Day Party 1291 END:VEVENT 1292 END:VCALENDAR 1294 4.3 Property 1296 A property is the definition of an individual attribute describing a 1297 calendar property or a calendar component. A property takes the 1298 following form: 1300 property = propname [";" [ws] parmlist] ":" [ws] value CRLF 1302 propname = 1303 / iana-prop / x-token 1305 x-token = 1308 iana-prop = 1310 The following is an example of a property: 1312 DTSTART:19960415T083000-05:00 1314 This memo places no imposed ordering of properties within an 1315 iCalendar object. 1317 Property names, parameter names and parameter values (i.e., 1318 everything to the left of the ":" on a line) are case insensitive. 1319 For example, the property name "DUE" is the same as "due" and "Due". 1321 4.4 Calendar Components 1323 The body of the iCalendar object consists of a sequence of calendar 1324 properties and one or more calendar components. The calendar 1325 properties are attributes that apply to the calendar as a whole. The 1326 calendar components are collections of properties that with a 1327 particular calendar semantic. For example, the calendar component MAY 1328 specify a an event, a to-do, journal entry, time zone information, or 1329 free/busy time information, or alarm. 1331 The body of the iCalenar Object is defined by the following notation: 1333 icalbody = calprops 1*component 1335 calprops = [calscale] prodid method [source] [name] version 1337 component = 1*(eventc / todoc / journalc / freebusyc / 1338 / timezonec) 1340 4.4.1 Event Component 1342 A "VEVENT" calendar component is a grouping of component properties 1343 and an OPTIONAL "VALARM" calendar component that represent a 1344 scheduled amount of time on a calendar. For example, it MAY be an 1345 activity; such as a one-hour, department meeting from 8:00 AM to 9:00 1346 AM, tomorrow. Generally, these events will take up time on an 1347 individual calendar. Hence, the event will appear as an opaque 1348 interval in a search for busy time. Alternately, the event MAY have 1349 its Time Transparency set to "TRANSPARENT" in order to prevent 1350 blocking of the event in searches for busy time. 1352 The "VEVENT" is also the calendar component used to specify an 1353 anniversary or daily reminder within a calendar. These events have a 1354 start time but no end time. The start time MAY also be specified as a 1355 DATE value data type, instead of the default DATE-TIME. 1357 A "VEVENT" calendar component is defined by the following notation: 1359 eventc = "BEGIN" ":" [ws] "VEVENT" CRLF 1360 eventprop *alarmc 1361 "END" ":" [ws] "VEVENT" CRLF 1362 eventprop = *attach *attendee *categories [class] *comment 1363 *contact [created] [description] [dtend / duration] 1364 dtstart *exdate *exrule [geo] [last-mod] [location] 1365 [priority] [rstatus] *related *resources *rdate 1366 *rrule dtstamp [seq] [status] summary [transp] uid 1367 *url [recurid] 1369 The "VEVENT" calendar component can not be nested within another 1370 calendar component. The "VEVENT" calendar components MAY be related 1371 to each other or to a "VTODO" or "VJOURNAL" calendar component with 1372 the "RELATED-TO" property. 1374 The following is an example of the "VEVENT" calendar component used 1375 to represent a meeting that will also be opaque to searches for busy 1376 time: 1378 BEGIN:VEVENT 1379 UID:19970901T130000Z-123401@host.com 1380 DTSTAMP:19970901T1300Z 1381 DTSTART:19970903T083000-0800 1382 DTEND:19970903T110000-0800 1383 SUMMARY:Annual Employee Review 1384 CLASS:PRIVATE 1385 CATEGORIES:BUSINESS,HUMAN RESOURCES 1386 END:VEVENT 1388 The following is an example of the "VEVENT" calendar component used 1389 to represent a reminder that will not be opaque, but rather 1390 transparent, to searches for busy time: 1392 BEGIN:VEVENT 1393 UID:19970901T130000Z-123402@host.com 1394 DTSTAMP:19970901T1300Z DTSTART:19970401T083000-0800 1395 DTEND:19970401T170000-0800 1396 SUMMARY:Laurel is in sensitivity awareness class. 1397 CLASS:PUBLIC 1398 CATEGORIES:BUSINESS,HUMAN RESOURCES 1399 TRANSP:TRANSPARENT 1400 END:VEVENT 1402 The following is an example of the "VEVENT" calendar component used 1403 to represent an anniversary that will occur annually. Since it takes 1404 up no time, it will not appear as opaque in a search for busy time; 1405 no matter what the value of the "TRANSP" property indicates: 1407 BEGIN:VEVENT 1408 UID:19970901T130000Z-123403@host.com 1409 DTSTAMP:19970901T1300Z 1410 DTSTART:19971102 1411 SUMMARY:Our Blissful Anniversary 1412 CLASS:CONFIDENTIAL 1413 CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION 1414 RRULE:FREQ=YEARLY 1415 END:VEVENT 1416 4.4.2 To-do Component 1418 A "VTODO" calendar component is a grouping of component properties 1419 and an OPTIONAL "VALARM" calendar component that represent an action- 1420 item or assignment. For example, it MAY be an item of work assigned 1421 to an individual; such as "turn in travel expense today". 1423 A "VTODO" calendar component is defined by the following notation: 1425 todoc = "BEGIN" ":" [ws] "VTODO" CRLF 1426 todoprop *alarmc 1427 "END" ":" [ws] "VTODO" CRLF 1429 todoprop = *attach *attendee *categories [class] *comment 1430 [completed] *contact [created] [description] dtstamp 1431 dtstart [due / duration] *exdate *exrule [geo] 1432 [last-mod] [location] [percent] priority [rstatus] 1433 *related *resources *rdate *rrule [recurid] [seq] 1434 [status] summary uid *url 1436 The "VTODO" calendar component can not be nested within another 1437 calendar component. If "VTODO" calendar components need to be related 1438 to each other or to a "VTODO" or "VJOURNAL" calendar component, they 1439 can specify a relationship with the "RELATED-TO" property. 1441 The following is an example of a "VTODO" calendar component: 1443 BEGIN:VTODO 1444 UID:19970901T130000Z-123404@host.com 1445 DTSTAMP:19970901T1300Z 1446 DTSTART:19970415T083000-0500 1447 DUE:19970415T235959-0500 1448 SUMMARY:1996 Income Tax Preparation 1449 CLASS:CONFIDENTIAL 1450 CATEGORIES:FAMILY,FINANCE 1451 PRIORITY:1 1452 STATUS:NEEDS-ACTION 1453 END:VEVENT 1455 4.4.3 Journal Component 1457 A "VJOURNAL" calendar component is a grouping of component properties 1458 that represent one or more descriptive text notes on a particular 1459 calendar date. The "DTSTART" property is used to specify the calendar 1460 date that the journal entry is associated with. Generally, it will 1461 have a DATE value data type, but it MAY also be used to specify a 1462 DATE-TIME value data type. Examples of a journal entry include a 1463 daily record of a legislative body or a journal entry of individual 1464 telephone contacts for the day or an ordered list of accomplishments 1465 for the day. The calendar component can also be used to associate a 1466 document with a calendar date. 1468 The "VJOURNAL" calendar component does not take up time on a 1469 calendar. Hence, it does not play a role in free or busy time 1470 searches - - it is as though it has a time transparency value of 1471 TRANSPARENT. It is transparent to any such searches. 1473 A "VJOURNAL" calendar component is defined by the following notation: 1475 journalc = "BEGIN" ":" [ws] "VJOURNAL" CRLF 1476 jourprop 1477 "END" ":" [ws] "VJOURNAL" CRLF 1479 jourprop = *attach *attendee *categories [class] *comment 1480 *contact [created] [description] dtstart dtstamp 1481 *exdate *exrule [last-mod] *related *rdate *rrule 1482 [rstatus] [seq] summary uid *url [recurid] 1484 The "VJOURNAL" calendar component can not be nested within another 1485 calendar component. If "VJOURNAL" calendar components need to be 1486 related to each other or to a "VEVENT" or "VTODO" calendar component, 1487 they can specify a relationship with the "RELATED-TO" property. 1489 The following is an example of the "VJOURNAL" calendar component: 1491 BEGIN:VJOURNAL 1492 UID:19970901T130000Z-123405@host.com 1493 DTSTAMP:19970901T1300Z 1494 DTSTART;VALUE=DATE:19970317 1495 SUMMARY:Staff meeting minutes 1496 DESCRIPTION:1. Staff meeting: Participants include Joe\, Lisa 1497 and Bob. Aurora project plans were reviewed. There is currently 1498 no budget reserves for this project. Lisa will escalate to 1499 management. Next meeting on Tuesday. 1500 2. Telephone Conference: ABC Corp. sales representative called 1501 to discuss new printer. Promised to get us a demo by Friday. 1502 3. Henry Miller (Handsoff Insurance): Car was totaled by tree. 1503 Is looking into a loaner car. 654-2323 (tel). 1504 END:VJOURNAL 1506 4.4.4 Free/Busy Component 1508 A "VFREEBUSY" calendar component is a grouping of component 1509 properties that represents either a request for, or a reply with, 1510 free or busy time information. Typically, this component exists in an 1511 iCalendar object that is being used to either request or return free 1512 or busy time information. 1514 A "VFREEBUSY" calendar component is defined by the following 1515 notation: 1517 freebusyc = "BEGIN" ":" [ws] "VFREEBUSY" CRLF 1518 fbprop 1519 "END" ":" [ws] "VFREEBUSY" CRLF 1520 fbprop = fbrequest / fbreply 1522 fbrequest = *attendee dtstart dtend [duration] *comment dtstamp 1523 [last-mod] *related [seq] uid 1524 ;This set of properties is used to for free/busy time request. 1526 fbreply = *attendee [created] *comment [dtstart dtend] dtstamp 1527 *freebusy [last-mod] *related [rstatus] [seq] uid *url 1528 ;This set of properties is used for free/busy time reply. 1530 The "VFREEBUSY" calendar component can not be nested within another 1531 calendar component. The "VFREEBUSY" calendar components MAY be 1532 related to each other with the "RELATED-TO" property. Multiple 1533 "VFREEBUSY" calendar components MAY be specified within a iCalendar 1534 object. This permits the grouping of Free/Busy information into 1535 logical collections, such as monthly groups of busy time information. 1537 The "VFREEBUSY" calendar component is intended for use in iCalendar 1538 object methods involving requests for free time, requests for busy 1539 time, requests for both free and busy, and the associated replies. 1541 Free/Busy information can be expressed using the "FREEBBUSY" 1542 property. This property provides a terse representation of time 1543 periods. One or more "FREEBUSY" properties MAY be specified in the 1544 "VFREEBUSY" calendar component to describe the Free/Busy information. 1546 Optionally, the "DTSTART" and "DTEND" properties MAY be specified to 1547 express the start and end date and time for all of the Free/Busy 1548 information in the "VFREEBUSY"calendar component. When present in a 1549 "VFREEBUSY" calendar component, they should be specified prior to any 1550 "FREEBUSY" properties. In a free time request, these properties MAY 1551 be used in combination with the "DURATION" property to express a 1552 request for a duration of free time within a given window of time. 1554 The recurrence properties ("RRULE", "EXRULE", "RDATE", "EXDATE") are 1555 not permitted within a "VFREEBUSY" calendar component. Any recurring 1556 events are resolved into their individual busy time periods using the 1557 "FREEBUSY" property. 1559 The following is an example of a "VFREEBUSY" calendar component: 1561 BEGIN:VFREEBUSY 1562 DTSTART:19971015T050000Z 1563 DTEND:19971016T050000Z 1564 FREEBUSY;VALUE=PERIOD:19971015T050000Z/PT8H30M, 1565 19971015T160000Z/PT5H30M,19971015T223000Z/PT6H30M 1566 END:VFREEBUSY 1568 4.4.5 Alarm Component 1570 A "VALARM" calendar component is a grouping of component properties 1571 that is a reminder or alarm for an event or a to-do. The "VALARM" 1572 calendar component MAY only be specified in a "VEVENT" or "VTODO" 1573 calendar component. For example, it MAY define a reminder for a 1574 pending event or an overdue to-do. 1576 The "DTSTART" property specifies the calendar date and time of day 1577 that the alarm will be triggered. The value MAY alternately be set to 1578 a period of time, before or after the event or to-do, that the alarm 1579 will be triggered. 1581 A "VALARM" calendar component is defined by the following notation: 1583 alarmc = "BEGIN" ":" [ws] "VALARM" CRLF 1584 alarmprop 1585 "END" ":" [ws] "VALARM" CRLF 1587 alarmprop = *attach 1*categories *comment [description] 1588 dtstart duration *related repeat [summary] 1590 The "VALARM" calendar component can only appear within either a 1591 "VEVENT" or "VTODO" calendar component. The "VALARM" calendar 1592 components can not be nested. 1594 The following is an example of the "VALARM" calendar component: 1596 BEGIN:VALARM 1597 DTSTART:19970317T133000Z 1598 REPEAT:4 1599 DURATION:PT15M 1600 CATEGORIES:DISPLAY,AUDIO 1601 ATTACH:file:///mmedia/sounds/bell1.wav 1602 DESCRIPTION:Breakfast meeting with executive team at 8:30 AM 1603 END:VALARM 1605 4.4.6 Timezone Component 1607 The "VTIMEZONE" calendar component is used to define a time zone. 1609 A time zone is unambiguously defined by the set of time measurement 1610 rules determined by the governing body for a given geographic area. 1611 These rules describe at a minimum the base offset from UTC for the 1612 time zone, often referred to as the Standard Time offset. Many 1613 locations adjust their Standard Time forward or backward by one hour, 1614 in order to accommodate seasonal changes in number of daylight hours, 1615 often referred to as Daylight Saving Time. Some locations adjust 1616 their time by a fraction of an hour. Standard Time is also known as 1617 Winter Time. Daylight Saving Time is also known as Advanced Time, 1618 Summer Time, or Legal Time in certain countries. The following table 1619 shows the changes in time zone rules for the eastern United States. 1621 Effective Transition Rule 1622 Date (Date/Time) Offset Abbreviation 1624 1920-1920 last Sun in Mar, 02:00 -0400 EDT 1625 1920-1920 last Sun in Oct, 02:00 -0500 EST 1627 1921-1966 last Sun in Apr, 02:00 -0400 EDT 1629 1921-1954 last Sun in Sep, 02:00 -0500 EST 1631 1955-1966 last Sun in Oct, 02:00 -0500 EST 1633 1967-* last Sun in Oct, 02:00 -0500 EST 1635 1967-1973 last Sun in Apr, 02:00 -0400 EDT 1637 1974-1974 Jan 6, 02:00 -0400 EDT 1639 1975-1975 Feb 23, 02:00 -0400 EDT 1641 1976-1986 last Sun in Apr, 02:00 -0400 EDT 1643 1987-* first Sun in Apr, 02:00 -0400 EDT 1645 Interoperability between two calendaring and scheduling applications, 1646 especially for recurring events, to-dos or journal entries, is 1647 dependent on the ability to capture and convey date and time 1648 information in an unambiguous format. The specification of current 1649 time zone information is integral to this behavior. 1651 The "VTIMEZONE" calendar component is a grouping of component 1652 properties that define a time zone description. The time zone 1653 description specifies the effective Standard Time or Daylight Savings 1654 Time rules for a particular time zone. The "VTIMEZONE" calendar 1655 component can not be nested within other calendar components. The 1656 "VTIMEZONE" calendar component MAY be specified multiple times. If 1657 the "VTIMEZONE" calendar component is missing, the recipient should 1658 assume all local times are relative to the recipient's time zone. The 1659 "VTIMEZONE" calendar component should be specified in the iCalendar 1660 object before any other calendar components. 1662 A "VTIMEZONE" calendar component is defined by the following 1663 notation: 1665 timezonec = "BEGIN" ":" [ws] "VTIMEZONE" CRLF 1666 tzprop 1667 "END" ":" [ws] "VTIMEZONE" CRLF 1669 tzprop = *comment [daylight] dtstart [rdate / rrule] 1670 [tzname] tzoffset 1672 The "VTIMEZONE" calendar component is important for correct 1673 interpretation of individual as well as recurring calendar components 1674 that span a time zone transition. For example, from EST to EDT. The 1675 exception to this are calendar components that are considered 1676 floating (i.e., occurs at a particular local time no matter what time 1677 zone you are in). If the iCalendar object contains a non-floating 1678 calendar component that has a recurring date pattern (i.e., includes 1679 the "RRULE" property) or a list of date and local time values (i.e., 1680 includes the "RDATE" property), one or more "VTIMEZONE" calendar 1681 components MUST be specified, such that for the given range of the 1682 recurrence (i.e., the earliest instance to latest instance), there is 1683 valid time zone information for all instances. In other words, if all 1684 of the instances of the pattern is entirely within one offset 1685 observance, (e.g., all are in Standard Time), only one "VTIMEZONE" 1686 calendar component need be present. If a time zone transition is 1687 crossed, then other "VTIMEZONE" calendar components are needed. 1688 Further, if there are known changes to the rules for the time zone, 1689 even more "VTIMEZONE" calendar components are needed. 1691 Each "VTIMEZONE" calendar component consists of several properties: 1693 The "DAYLIGHT" property is a BOOLEAN value indicating Standard Time 1694 (FALSE) or Daylight Savings Time (TRUE). The default for DAYLIGHT is 1695 FALSE or Standard Time. 1697 The "DTSTART" property in this usage is a fully specified DATE-TIME 1698 value, including the UTC offset, indicating the effective start date 1699 and time for the time zone information. For example, 19671029T020000- 1700 0400 represents the time at which the transition to Standard Time 1701 took effect in 1967 for the eastern United States. 1703 The "TZOFFSET" property is a UTC-OFFSET value indicating the UTC 1704 offset for the time zone (Standard Time or Daylight Savings Time). 1706 The "TZNAME" property is the customary name for the time zone. 1708 The "RRULE" property indicates the recurrence rule for the transition 1709 to this time zone. For example, in the United States, the transition 1710 from Standard Time to Daylight Saving Time occurs on the first Sunday 1711 in April at 02:00. If a recurrence rule describing the transition is 1712 known to have an effective end date, the UNTIL recurrence rule 1713 parameter is used to specify that end date and time. If the 1714 recurrence rule for a particular observance (Daylight Saving Time) is 1715 changing, then the UNTIL of the first rule will be equal to the last 1716 valid instance (the last date-time) of this particular rule. See 1717 example below. 1719 Alternatively, the "RDATE" property can be used. The "RDATE" property 1720 is a property that indicates the individual dates and/or times that 1721 the transition takes effect. The values supplied for "RDATE" property 1722 for each "VTIMEZONE" calendar component MUST provide valid time zone 1723 information of all instances of the recurrence specified for the 1724 calendar component to which this time zone information is to be 1725 applied. 1727 The following are examples of the "VTIMEZONE" calendar component: 1729 This is a simple example showing time zone information for the 1730 Eastern United States using "RDATE" property. Note that this is only 1731 suitable for a recurring event that starts on or later than 1997, 1732 April 6, at 02:00:00 EST (i.e., the earliest effective transition 1733 date and time) and ends no later than 1998, April 7, 02:00:00 EST 1734 (i.e., latest valid date and time for EST in this scenario). For 1735 example, this can be used for a recurring event that ocurrs every 1736 Friday, 8am-9am, starting June 1, 1997, ending Dec 31, 1997. 1738 BEGIN:VTIMEZONE 1739 DAYLIGHT:FALSE 1740 RDATE:19971026T020000-0400 1741 TZOFFSET:-0500 1742 TZNAME:EST 1743 END:VTIMEZONE 1745 BEGIN:VTIMEZONE 1746 DAYLIGHT:TRUE 1747 RDATE:19970406T020000-0500 1748 TZOFFSET:-0400 1749 TZNAME:EDT 1750 END:VTIMEZONE 1752 This is a simple example showing the current time zone rules for the 1753 Eastern United States using a RRULE recurrence pattern. Note that 1754 there is no effective end date to either of the Standard Time or 1755 Daylight Time rules. This information would be valid for a 1756 recurrening event starting today and continuing on into the known 1757 future. 1759 BEGIN:VTIMEZONE 1760 DAYLIGHT:FALSE 1761 DTSTART:19671029T020000-0400 1762 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 1763 TZOFFSET:-0500 1764 TZNAME:EST 1765 END:VTIMEZONE 1767 BEGIN:VTIMEZONE 1768 DAYLIGHT:TRUE 1769 DTSTART:19870405T020000-0500 1770 RRULE: FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 1771 TZOFFSET:-0400 1772 TZNAME:EDT 1773 END:VTIMEZONE 1775 This is an example showing a ficticious set of rules for the Eastern 1776 United States, where the Daylight Time rule has an effective end date 1777 (i.e., after that date, Daylight Time is no longer observed). 1779 BEGIN:VTIMEZONE 1780 DAYLIGHT:FALSE 1781 DTSTART:19671029T020000-0400 1782 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 1783 TZOFFSET:-0500 1784 TZNAME:EST 1785 END:VTIMEZONE 1786 BEGIN:VTIMEZONE 1787 DAYLIGHT:TRUE 1788 DTSTART:19870405T020000-0500 1789 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T020000-0500 1790 TZOFFSET:-0400 1791 TZNAME:EDT 1792 END:VTIMEZONE 1794 This is an example showing a fictitious set of rules for the Eastern 1795 United States, where the first Daylight Time rule has an effective 1796 end date. There is a second Daylight Time rule that picks up where 1797 the other left off. 1799 BEGIN:VTIMEZONE 1800 DAYLIGHT:FALSE 1801 DTSTART:19671029T020000-0400 1802 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 1803 TZOFFSET:-0500 1804 TZNAME:EST 1805 END:VTIMEZONE 1807 BEGIN:VTIMEZONE 1808 DAYLIGHT:TRUE 1809 DTSTART:19870405T020000-0500 1810 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T020000-0500 1811 TZOFFSET:-0400 1812 TZNAME:EDT 1813 END:VTIMEZONE 1815 BEGIN:VTIMEZONE 1816 DAYLIGHT:TRUE 1817 DTSTART:19990327T020000-0500 1818 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3 1819 TZOFFSET:-0400 1820 TZNAME:EDT 1821 END:VTIMEZONE 1823 4.5 Calendar Properties 1825 The Calendar Properties are attributes that apply to the iCalendar 1826 object, as a whole. These properties do not appear within a calendar 1827 component. They should be specified after the "BEGIN:VCALENDAR" 1828 property and prior to any calendar component. 1830 4.5.1 Calendar Scale 1832 This property is identified by the property name CALSCALE. This 1833 property defines the calendar scale used for the calendar information 1834 specified in the iCalendar object. This memo is based on the 1835 Gregorian calendar scale. The Gregorian calendar scale is assumed if 1836 this property is not specified in the iCalendar object. It is 1837 expected that other calendar scales will be defined in other 1838 specifications or by future versions of this memo. 1840 The property is defined by the following notation: 1842 calscale = "CALSCALE" ":" [ws] calvalue CRLF 1844 calvalue = "GREGORIAN" / iana-scale 1846 iana-scale = 1849 The following is an example of this property: 1851 CALSCALE:GREGORIAN 1853 The data type for this property is TEXT. 1855 4.5.2 Method 1857 This property is identified by the property name METHOD. This 1858 property defines the iCalendar object method associated with the 1859 calendar object. When used in a MIME message entity, the value of 1860 this property MUST be the same as the Content-Type "method" parameter 1861 value. This property can only appear once within the iCalendar 1862 object. 1864 The property is defined by the following notation: 1866 method = "METHOD" ": [ws] profvalue CRLF 1868 profvalue = 1870 The following is an example of this property when the iCalendar 1871 object is used to request a meeting: 1873 METHOD: REQUEST 1875 In the event that this property is not specified, the iCalendar 1876 object method is undefined. The data type for this property is TEXT. 1878 4.5.3 Product Identifier 1880 This property is identified by the property name PRODID. This 1881 property specifies the identifier for the product that created the 1882 iCalendar object. The vendor of the implementation should assure that 1883 this is a globally unique identifier; using some technique such as an 1884 ISO 9070 FPI value. This calendar property MUST be specified in the 1885 iCalendar object but can only appear once. 1887 This property should not be used to alter the interpretation of an 1888 iCalendar object beyond the semantics specified in this memo. For 1889 example, it is not to be used to further the understanding of non- 1890 standard properties. 1892 The property is defined by the following notation: 1894 prodid = "PRODID" ":" [ws] pidvalue CRLF 1896 pidvalue = text 1897 ;Any text that describes the product and version 1898 ;and that is generally assured of being unique. 1900 The following is an example of this property: 1902 PRODID:-//ABC Corporation//NONSGML My Product//EN 1904 The data type for this property is TEXT. 1906 4.5.4 Source 1908 This property is identified by the property name SOURCE. This 1909 property is defined by the [MIME DIR] memo. In this memo, the 1910 property identifies the URL for the source of the iCalendar object. 1911 The URL is useful for accessing the iCalendar object using a calendar 1912 access protocol. 1914 The property is defined by the following notation: 1916 source = "SOURCE" ":" [ws] url CRLF 1918 The following are examples of this property: 1920 SOURCE:http://xyz.corp.com/corp-cals/1997-events.or4 1922 SOURCE:http://xyz.corp.com/calendars/~jdoe 1924 The data type for this property is URL. 1926 4.5.5 Source Name 1928 This property is identified by the property name NAME. This property 1929 is defined by the [MIME DIR] memo. The property identifies the 1930 displayable, presentation name for the source of the iCalendar 1931 object. The source name is a useful text to associate in the user- 1932 interface of an application with the value in the SOURCE property. 1934 The property is defined by the following notation: 1936 name = "NAME" ":" [ws] text CRLF 1938 The following is an example of this property: 1940 NAME:1997 Events Calendar for XYZ Corporation 1942 The data type for this property is TEXT. 1944 4.5.6 Version 1946 This property is identified by the property name VERSION. This 1947 property specifies the identifier corresponding to the highest 1948 version number or the minimum and maximum range of the MIME 1949 Calendaring and Scheduling Content Type specification supported by 1950 the implementation that created the iCalendar object. A value of 1951 "2.0" corresponds to this memo. This calendar property MUST appear 1952 within the iCalendar object but can only appear once. 1954 The property is defined by the following notation: 1956 version = "VERSION" ":" [ws] vervalue CRLF 1958 vervalue = "2.0" ;This memo 1959 / maxver 1960 / (minver ";" [ws] maxver) 1962 minver = 1963 ;Minimum iCalendar version used to create the iCalendar object 1965 maxver = 1966 ;Maximum iCalendar version used to create the iCalendar object 1968 The following is an example of this property: 1970 VERSION:2.0 1972 The data type for this property is TEXT. 1974 4.6 Component Properties 1976 The following properties MAY appear within calendar components, as 1977 specified by each component property definition. 1979 4.6.1 Attachment 1981 This property is identified by the property name ATTACH. The property 1982 provides the capability to associate an external object with a 1983 calendar component. For example, a document to be reviewed at a 1984 scheduled event or the description of the process steps for a to-do. 1985 The property MAY only be specified within "VEVENT", "VTODO", or 1986 "VJOURNAL" calendar components. This property MAY be specified 1987 multiple times within an iCalendar object. 1989 The property is defined by the following notation: 1991 attach = "ATTACH" ":" [ws] url CRLF 1993 The following are examples of this property: 1995 ATTACH:CID:jsmith.part3.960817T083000.xyzMail@host1.com 1996 ATTACH:FTP://xyzCorp.com/pub/reports/r-960812.ps 1998 The data type for this property is URL. 2000 4.6.2 Attendee 2002 This property is identified by the property name ATTENDEE. The 2003 property defines an attendee within a calendar component. The 2004 property MAY only be specified within the "VEVENT", "VTODO", 2005 "VJOURNAL" and "VFREEBUSY" calendar components. 2007 The property has the property parameters TYPE, for the type of 2008 attendee, ROLE, for the intended role of the attendee; STATUS, for 2009 the status of the attendee�s participation; RSVP, for indicating 2010 whether the favor of a reply is requested; EXPECT, to indicate the 2011 expectation of the attendee�s participation by the originator; 2012 MEMBER, to indicate the groups that the attendee belongs to; 2013 DELEGATED-TO, to indicate the people that the original request was 2014 delegated to; and DELEGATED-FROM, to indicated whom the request was 2015 delegated from. 2017 A recipient delegated a request MUST inherit the RSVP and EXPECT 2018 values from the attendee that delegated the request to them. 2020 Multiple attendees MAY be specified by including multiple "ATTENDEE" 2021 properties within the MIME calendaring entity. 2023 The property data type default is CAL-ADDRESS. The property data type 2024 MAY also be set to URL. This provides a useful mechanism to allow 2025 more than just the address of the attendee to be referenced. If the 2026 value is a URL, then it MUST be able to be resolved to a calendar 2027 address. 2029 The property is defined by the following notation: 2031 attendee = "ATTENDEE" [";" [ws] paramlist] 2032 [";" [ws] attparamlist] ":" [ws] 2033 (cal-address / URL) CRLF 2034 ;Value MUST match default or explicit data type 2036 attparamlist = (attparam *(";" attparam) 2038 attparam = typeparm / roleparm / statusparm / rsvpparm 2039 / expectparm / memberparm / deletoparm / delefromparm 2041 typeparm = "TYPE" "=" 2042 ("INDIVIDUAL" ; An individual 2043 / "GROUP" ; A group of individuals 2044 / "RESOURCE" ; A physical resource 2045 / "ROOM" ; A room resource 2046 / "UNKNOWN") ; Otherwise not known 2047 ;Default value is INDIVIDUAL 2048 roleparm = "ROLE" "=" 2049 ("ATTENDEE" ; Indicates a regular attendee 2050 / "OWNER" ; Indicates owner of event or to-do 2051 / "ORGANIZER" ; Indicates organizer of event or to-do 2052 / "DELEGATE") ; Indicates delegate to event or to-do 2053 ;Default is ATTENDEE 2055 statusparm = "STATUS" "=" 2056 ("NEEDS-ACTION" ; Indicates event or to-do needs action 2057 / "ACCEPTED" ; Indicates event or to-do accepted 2058 / "DECLINED" ; Indicates event or to-do not accepted 2059 / "TENTATIVE" ; Indicates event or to-do tentatively 2060 ; accepted. Status MAY change in the future. 2061 / "COMPLETED" ; Indicates to-do was completed. 2062 ; COMPLETED property has date/time completed. 2063 / "IN-PROCESS" ;Indicates to-do is in the process of 2064 ; being completed. 2065 / "DELEGATED" ; Indicateds event or to-do delegated 2066 ; to another ATTENDEE 2067 / "CANCELLED") ; Indicates event or to-do cancelled for 2068 ; ATTENDEE 2069 ;Default is NEEDS-ACTION 2071 rsvpparm = "RSVP" "=" 2072 ("TRUE" ; Indicates response requested 2073 / "FALSE") ; Indicates no response needed 2074 ;Default is FALSE 2076 expectparm = "EXPECT" "=" 2077 ("FYI" ; Indicates request is for your info 2078 / "REQUIRE" ; Indicates presence is required 2079 / "REQUEST") ; Indicates presence is requested 2080 ;Default is FYI 2082 memberparm = "MEMBER" "=" cal-address *("," cal-address) 2083 ; Indicates a group or mailing list 2085 deletoparm = "DELEGATED-TO" "=" cal-address *("," cal-address) 2086 ; Indicates who request delegated to 2088 delefromparm = "DELEGATED-FROM" "=" cal-address *("," cal-address) 2089 ;Indicates who request delegated from 2091 The following are examples of this property�s use for a to-do: 2093 ATTENDEE;ROLE=OWNER;STATUS=COMPLETED:jsmith@host1.com 2094 ATTENDEE;MEMBER=DEV-GROUP@host2.com:joecool@host2.com 2095 ATTENDEE;DELEGATED-FROM=immud@host3.com:ildoit@host1.com 2097 The following is an example of this property used for specifying 2098 multiple attendees to an event: 2100 ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:John Smith 2101 ATTENDEE;ROLE=ATTENDEE;STATUS=TENTATIVE:Henry Cabot 2102 2103 ATTENDEE;ROLE=DELEGATE;STATUS=ACCEPTED:Jane Doe 2105 The following is an example of this property with the value specified 2106 as an URL reference to a vCard that contains the information about 2107 the attendee: 2109 ATTENDEE;ROLE=ATTENDEE;STATUS=ACCEPTED;VALUE=URL: 2110 http://www.xyz.com/~myvcard.vcf 2112 The following is an example of this property with "delegatee" 2113 and"delegator" information for an event: 2115 ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:John Smith 2116 ATTENDEE;ROLE=DELEGATE;STATUS=TENTATIVE;DELEGATED-FROM= 2117 iamboss@host2.com:Henry Cabot 2118 ATTENDEE;ROLE=ATTENDEE;STATUS=DELEGATED;DELEGATED-TO= 2119 hcabot@host2.com=iamboss(The Big Cheese)@host2.com 2120 ATTENDEE;ROLE=DELEGATE;STATUS=ACCEPTED:Jane Doe 2122 The default data type for this property is CAL-ADDRESS. The data type 2123 MAY be reset to URL; in which case the value is a location or message 2124 that contains the information that is to be used to specify the 2125 attendee address. 2127 4.6.3 Categories 2129 This property is identified by the property name CATEGORIES. This 2130 property defines the categories for a calendar component. The 2131 property MAY be specified within the "VEVENT", "VTODO" or "VJOURNAL" 2132 calendar component with an arbitrary text value. In the "VALARM" 2133 calendar component the property MUST be specified to declare the 2134 alarm category. More than one category MAY be specified as a list of 2135 categories separated by the COMMA character (ASCII decimal 44). 2137 The properties is defined by the following notation: 2139 categories = "CATEGORIES" [";" [ws] paramlist] ":" [ws] 2140 catvalue CRLF 2142 catvalue = cat1value *["," [ws] cat1value] 2143 / cat2value *["," [ws] cat2value] 2145 cat1value = "ANNIVERSARY" / "APPOINTMENT" / "BUSINESS" 2146 / "EDUCATION" / "HOLIDAY" / "MEETING" / "MISCELLANEOUS" 2147 / "NON-WORKING HOURS" / "NOT IN OFFICE" / "PERSONAL" 2148 / "PHONE CALL" / "SICK DAY" / "SPECIAL OCCASION" 2149 / "TRAVEL" / "VACATION" / word 2150 ;Used only in "VEVENT", "VTODO" and "VJOURNAL" calendar components. 2152 cat2value = "AUDIO" / "DISPLAY" / "EMAIL" / "PROCEDURE" 2153 / x-token / iana-word 2154 ;Used only in "VALARM" calendar component. 2156 The following are examples of this property in a "VEVENT", "VTODO" or 2157 "VJOURNAL" calendar component: 2159 CATEGORIES:APPOINTMENT,EDUCATION 2161 CATEGORIES:MEETING 2163 The following are examples of this property in a "VALARM" calendar 2164 component: 2166 CATEGORIES:AUDIO,DISPLAY 2168 CATEGORIES:PROCEDURE 2170 The data type for this property is TEXT. 2172 4.6.4 Classification 2174 This property is identified by the property name CLASS. This property 2175 defines the access classification for a calendar component. The 2176 property MAY only be specified in a "VEVENT", "VTODO" or "VJOURNAL" 2177 calendar component. The property MAY only be specified once. 2179 An access classification is only one component of the general 2180 security system within a calendar application. It provides a method 2181 of capturing the scope of the access the calendar owner intends for 2182 information within an individual calendar entry. The access 2183 classification of an individual iCalendar component is useful when 2184 measured along with the other security components of a calendar 2185 system (e.g., calendar user authentication, authorization, access 2186 rights, access role, etc.). Hence, the semantics of the individual 2187 access classifications can not be completely defined by this memo 2188 alone. Additionally, due to the "blind" nature of most exchange 2189 processes using this memo, these access classifications can not serve 2190 as an enforcement statement for a system receiving an iCalendar 2191 object . Rather, they provide a method for capturing the intention of 2192 the calendar owner for the access to the calendar component. . The 2193 [ICMS] provides a broader description of the security system within a 2194 calendar application. 2196 The property is defined by the following notation: 2198 class = "CLASS" [";" [ws] paramlist] ":" [ws] 2199 classvalue CRLF 2201 classvalue = "PUBLIC" / "PRIVATE" / "CONFIDENTIAL" / x-token 2202 ;Default is PUBLIC 2204 The following is an example of this property: 2206 CLASS:PUBLIC 2208 The data type for this property is TEXT. 2210 4.6.5 Comment 2212 This property is identified by the property name COMMENT. This 2213 property specifies non-processing information intended to provide a 2214 comment to the calendar user. The property MAY be specified in any of 2215 the calendar components. The property MAY be specified multiple 2216 times. 2218 The property is defined by the following notation: 2220 comment = "COMMENT" ":" [ws] text CRLF 2222 The following is an example of this property: 2224 COMMENT:The meeting really needs to include both ourselves 2225 and the customer. We can�t hold this meeting without them 2226 As a matter of fact\, the venue for the meeting ought to be at 2227 their site. - - John 2229 The data type for this property is TEXT. 2231 4.6.6 Contact 2233 This property is defined by the property name CONTACT. The property 2234 is used to represent contact information or alternately a reference 2235 to contact information associated with the calendar component. The 2236 property MAY only be specified in the "VEVENT", "VTODO" and 2237 "VJOURNAL" calendar components. The property value consists of 2238 textual contact information. Alternately, the value type for the 2239 property can be reset such that the property references the URL to 2240 the contact information. 2242 The property is defined by the following notation: 2244 contact = "CONTACT" [";" [ws] paramlist] ":" [ws] 2245 text / url CRLF 2247 The following is an example of this property referencing textual 2248 contact information: 2250 CONTACT:Jim Dolittle\, ABC Industries\, +1-919-555-1234 2252 The following is an example of this property referencing a LDAP URL 2253 to a directory entry containing the contact information: 2255 CONTACT;VALUE=URL:"ldap://host.com:6666/o=3DABC%20Industries, 2256 c=3DUS??(cn=3DBJim%20Dolittle)" 2258 The following is an example of this property referencing a MIME body 2259 part containing the contact information, such as a vCard embedded in 2260 a [MIME-DIR] content-type: 2262 CONTACT;VALUE=URL: 2263 The default data type for this property is TEXT. The data type MAY be 2264 reset to URL in order to specify a reference to the contact 2265 information. 2267 4.6.7 Date/Time Completed 2269 This property is identified by the property name COMPLETED. This 2270 property defines the date and time that a to-do was actually 2271 completed. The property MAY be specified once in a "VTODO" component. 2272 The date and time is an UTC value. 2274 The property is defined by the following notation: 2276 completed = "COMPLETED" ":" [ws] date-time CRLF 2278 The following is an example of this property: 2280 COMPLETED:19960401T235959Z 2282 The data type for this property is DATE-TIME. 2284 4.6.8 Date/Time Created 2286 This property is identified by the property name CREATED. This 2287 property specifies the date and time that the calendar information 2288 was created by the Organizer. The property MAY be specified in any of 2289 the calendar components. The property MAY only be specified once. The 2290 date and time is an UTC value. 2292 The property is defined by the following notation: 2294 created = "CREATED" ":" [ws] date-time CRLF 2296 The following is an example of this property: 2298 CREATED:19960329T133000Z 2300 The data type for this property is DATE-TIME. 2302 4.6.9 Date/Time Due 2304 This property is identified by the property name DUE. This property 2305 defines the date and time that a to-do is expected to be completed. 2306 The time can either be in local time, local time with UTC offset or 2307 UTC time. The property MAY only be specified in a "VTODO" calendar 2308 component and only once. The value MUST be a date/time after the 2309 DTSTART value, if specified. 2311 The property is defined by the following notation: 2313 due = "DUE" ":" [ws] date-time CRLF 2315 The following is an example of this property: 2317 DUE:19960401T235959Z 2319 The type for this property is DATE-TIME. 2321 4.6.10 Date/Time End 2323 This property is identified by the property name DTEND. This property 2324 MAY be specified within the "VEVENT", "VFREEBUSY", and "VTIMEZONE" 2325 calendar components. 2327 Within the "VEVENT" calendar component, this property defines the end 2328 date and time for the event. The property is REQUIRED in "VEVENT" 2329 calendar components. The time can either be in local time, local time 2330 with UTC offset or UTC time. The local time is only to be used to 2331 specify date and time values that do not need to be fixed. A 2332 recipient MUST assume their own time zone for data and time values 2333 that do not include time zone information. The value MUST be later in 2334 time than the value of the "DTSTART" property. 2336 Within the "VFREEBUSY" calendar component, this property defines the 2337 end date and time for the free or busy time information. The time 2338 MUST be specified in local time with UTC offset or UTC time. The 2339 value MUST be later in time than the value of the "DTSTART" property. 2341 The property is defined by the following notation: 2343 dtend = "DTEND" ":" [ws] date-time CRLF 2345 The following is an example of this property: 2347 DTEND:19960401T235959Z 2349 The data type for this property is DATE-TIME. 2351 4.6.11 Date/Time Stamp 2353 This property is identified by the property name DTSTAMP. This 2354 property specifies an UTC date/time stamp. The property indicates the 2355 date/time that the iCalendar object instance was created. This 2356 property MUST be included in "VEVENT", "VTODO", "VJOURNAL" and 2357 "VFREEBUSY" calendar components to permit the recipient to know when 2358 the iCalendar object was created. 2360 This property is also useful to protocols such as [IMIP] that have 2361 inherent latency issues with the delivery of content. This property 2362 will assist in the proper sequencing of messages containing iCalendar 2363 objects. 2365 This property is different than the "CREATED" and "LAST-MODIFIED" 2366 properties. These two properties are used to specify when the 2367 calendar service information was created and last modified. This is 2368 different than when the iCalendar object representation of the 2369 calendar service information was created or last modified. 2371 The property is defined by the following notation: 2373 dtstamp = "DTSTAMP" ":" [ws] date-time CRLF 2375 The value type for this property is DATE-TIME. The value MUST be a 2376 UTC date/time value. 2378 4.6.12 Date/Time Start 2380 This property is identified by the property name DTSTART. This 2381 property MAY be specified within the "VEVENT", "VFREEBUSY", and 2382 "VTIMEZONE" calendar components. 2384 Within the "VEVENT" calendar component, this property defines the 2385 start date and time for the event. The property is REQUIRED in 2386 "VEVENT" calendar components. The time can either be in local time, 2387 local time with UTC offset or UTC time. The local time is only to be 2388 used to specify date and time values that do not need to be fixed. A 2389 recipient MUST assume their own time zone for data and time values 2390 that do not include time zone information. Events MAY have a start 2391 date/time but no end date/time. In that case, the event does not take 2392 up any time. 2394 Within the "VFREEBUSY" calendar component, this property defines the 2395 start date and time for the free or busy time information. The time 2396 MUST be specified in local time with UTC offset or UTC time. 2398 Within the "VTIMEZONE" calendar component, this property defines the 2399 effective start date and time for a time zone specification. This 2400 property is REQUIRED within "VTIMEZONE" calendar components. The time 2401 MUST be specified as a UTC time. 2403 The property is defined by the following notation: 2405 dtstart = "DTSTART" [";" [ws] paramlist] ":" [ws] (date-time / 2406 date) CRLF 2408 The following is an example of this property: 2410 DTSTART:19960401T235959-0600 2412 The default data type for this property is DATE-TIME. The data type 2413 MAY be overridden to be DATE. 2415 4.6.13 Daylight 2417 This property is identified by the property name DAYLIGHT. This 2418 property MAY only be specified in a "VTIMEZONE" calendar component. 2419 This property specifies whether Daylight Saving Time (i.e., value is 2420 TRUE) or Standard Time (i.e., value is FALSE) is in effect for the 2421 time zone. The default value is FALSE or Standard Time. 2423 The property is defined by the following notation: 2425 daylight = "DAYLIGHT" ":" [ws] boolean CRLF 2426 ;Default value is FALSE 2428 The following is an example of this property: 2430 DAYLIGHT:TRUE ;Specifies DST in effect in time zone 2432 The data type for this property is BOOLEAN. 2434 4.6.14 Description 2436 This property is identified by the property name DESCRIPTION. This 2437 property provides a more complete description of the calendar 2438 component, than that provided by the "SUMMARY" property. The property 2439 MAY be specified in the "VEVENT", "VTODO" and "VJOURNAL" calendar 2440 components. The property MAY be specified multiple times only within 2441 a "VJOURNAL" calendar component. 2443 The property is defined by the following notation: 2445 Description = "DESCRIPTION" [";" [ws] paramlist] ":" [ws] 2446 text CRLF 2448 The following is an example of the property with formatted line 2449 breaks in the property value: 2451 DESCRIPTION:Meeting to provide technical review for "Phoenix" 2452 design.\n Happy Face Conference Room. Phoenix design team 2453 MUST attend this meeting.\n RSVP to team leader. 2455 The following is an example of the property with folding of long 2456 lines: 2458 DESCRIPTION:Last draft of the new novel is to be completed 2459 for the editor�s proof today. 2461 The data type for this property is TEXT. 2463 4.6.15 Duration 2465 This property is identified by the property name DURATION. The 2466 property specifies a duration of time. The property MAY be specified 2467 in a "VEVENT" calendar component in order to specify a duration of 2468 the event, instead of an explicit end date/time. The property MAY be 2469 specified in a "VTODO" calendar component in order to specify a 2470 duration for the to-do. The property MAY be specified in a 2471 "VFREEBUSY" calendar component in order to specify the amount of free 2472 time being requested. The property MAY be specified in an "VALARM" 2473 calendar component in order to specify the period between repeating 2474 alarms. 2476 The property is defined by the following notation: 2478 duration = "DURATION" ":" [ws] duration CRLF 2480 The following is an example of this property that specifies an 2481 interval of time of 1 hour and zero minutes and zero seconds: 2483 DURATION:PT1H0M0S 2485 The following is an example of this property that specifies an 2486 interval of time of 15 minutes. 2488 DURATION:PT15M 2490 The data type for this property is DURATION. 2492 4.6.16 Exception Date/Times 2494 This property is identified by the property name EXDATE. This 2495 property defines the list of date/time exceptions for a recurring 2496 "VEVENT", "VTODO" or "VJOURNAL" calendar component. The times can 2497 either be in local time, local time with UTC offset or UTC time. 2499 The exception dates, if specified, is used in computing the 2500 recurrence set. The recurrence set is the complete set of recurrence 2501 instances for a calendar component. The recurrence set is generated 2502 by considering the initial "DTSTART" property along with the "RRULE", 2503 "RDATE", "EXDATE" and "EXRULE" properties contained within the 2504 iCalendar object. The "DTSTART" property defines the first instance 2505 in the recurrence set. Multiple instances of the "RRULE" and "EXRULE" 2506 properties MAY also be specified to define more sophisticated 2507 recurrence sets. The final recurrence set is generated by gathering 2508 all of the start date-times generated by any of the specified "RRULE" 2509 and "RDATE" properties, and excluding any start date and times which 2510 fall within the union of start date and times generated by any 2511 specified "EXRULE" and "EXDATE" properties. This implies that start 2512 date and times within exclusion related properties (i.e., "EXDATE" 2513 and "EXRULE") take precedence over those specified by inclusion 2514 properties (i.e., "RDATE" and "RRULE"). Where duplicate instances are 2515 generated by the "RRULE" and "RDATE" properties, only one recurrence 2516 is considered. Duplicate instances are ignored. 2518 The property is defined by the following notation: 2520 exdate = "EXDATE" [";" [ws] paramlist] ":" [ws] [date-time / 2521 date] *("," [ws] date-time/date) CRLF 2522 ;Values MUST match the specified value type. 2524 The following is an example of this property: 2526 EXDATE:19960402T010000Z,19960403T010000Z,19960404T010000Z 2528 The data type for this property is DATE-TIME. The data type MAY be 2529 reset to DATE. 2531 4.6.17 Exception Rule 2533 This property is identified by the property name EXRULE. This 2534 property defines a rule or repeating pattern for an exception to a 2535 recurrence set. This property MAY only be specified in the "VEVENT", 2536 "VTODO" or "VJOURNAL" calendar components. 2538 The exception rule, if specified, is used in computing the recurrence 2539 set. The recurrence set is the complete set of recurrence instances 2540 for a calendar component. The recurrence set is generated by 2541 considering the initial "DTSTART" property along with the "RRULE", 2542 "RDATE", "EXDATE" and "EXRULE" properties contained within the 2543 iCalendar object. The "DTSTART" defines the first instance in the 2544 recurrence set. Multiple instances of the "RRULE" and "EXRULE" 2545 properties MAY also be specified to define more sophisticated 2546 recurrence sets. The final recurrence set is generated by gathering 2547 all of the start date-times generated by any of the specified "RRULE" 2548 and "RDATE" properties, and excluding any start date and times which 2549 fall within the union of start date and times generated by any 2550 specified "EXRULE" and "EXDATE" properties. This implies that start 2551 date and times within exclusion related properties (i.e., "EXDATE" 2552 and "EXRULE") take precedence over those specified by inclusion 2553 properties (i.e., "RDATE" and "RRULE"). Where duplicate instances are 2554 generated by the "RRULE" and "RDATE" properties, only one recurrence 2555 is considered. Duplicate instances are ignored. 2557 The property is defined by the following notation: 2559 exrule = "EXRULE" [";" [ws] paramlist] ":" [ws] recur CRLF 2561 The following are examples of this property. Except every other week, 2562 on Tuesday and Thursday for 4 occurrences: 2564 EXRULE:FREQ=WEEKLY;COUNT=4;INTERVAL=2;BYDAY=TU,TH 2566 Except daily for 10 occurrences: 2568 EXRULE:FREQ=DAILY;COUNT=10 2570 Except yearly in June and July for 8 occurrences: 2572 EXRULE:FREQ=YEARLY;COUNT=8;BYMONTH=6,7 2574 The data type for this property is RECUR. 2576 4.6.18 Free/Busy Time 2578 This property is identified by the property name FREEBUSY. The 2579 property defines one or more free or busy time intervals. These time 2580 periods MAY be specified as either a start and end date-time or a 2581 start date-time and duration. 2583 The date and time is either local time with UTC offset or a UTC 2584 value. 2586 The "FREEBUSY" property MAY include the "TYPE" property parameter to 2587 specify whether the information defines a free or busy time interval. 2588 The default "TYPE" property parameter value is BUSY. The property MAY 2589 also include the "STATUS" property parameter to provide added 2590 information about the busy time. For example, if the busy time is 2591 associated with a time interval that would be unavailable for 2592 scheduling - - in any case - - or busy time that has been tentatively 2593 scheduled. The default "STATUS" property parameter value is BUSY. The 2594 property is defined by the following notation: 2596 freebusy = "FREEBUSY" [";" [ws] paramlist] [";" [ws] fbparmlist] 2597 ":" [ws] fbvalue CRLF 2599 fbparmlist = fbparam *(";" [ws] fbparam) 2601 fbparam = fbtype / fbstatus 2603 fbtype = "TYPE" "=" ("FREE" or "BUSY") 2604 ;Default is BUSY 2606 fbstatus = "STATUS" "=" 2607 "BUSY" ;Represents busy time interval. 2608 / "UNAVAILABLE" ;Represents busy, but unavailable 2609 ;interval for cheduling; such as 2610 ;out-of-office or non-working hours. 2611 / "TENTATIVE" ;Represents busy, but tentatively 2612 ;scheduled interval. 2613 ;Default is BUSY 2615 fbvalue = period *["," [ws] period] 2616 ;Value MUST match default or explicit data type 2618 The following are some examples of this property: 2620 FREEBUSY;STATUS=UNAVAILABLE:19970308T160000Z/PT8H30M 2622 FREEBUSY;TYPE=FREE:19970308T160000Z/PT3H,19970308T200000Z/PT1H 2624 "FREEBUSY" properties within the "VFREEBUSY" calendar component 2625 should be sorted in ascending order, based on start time and then end 2626 time, with the earliest periods first. 2628 The "FREEBUSY" property MAY specify more than one value, separated by 2629 the COMMA character (ASCII decimal 44). In such cases, the "FREEBUSY" 2630 property values should all be of the same "STATUS" property parameter 2631 type (e.g., all values of a particular "STATUS" listed together in a 2632 single property). 2634 The data type for this property is PERIOD. 2636 4.6.19 Geographic Position 2638 This property is identified by the property name GEO. This property 2639 specifies information related to the global position for a "VEVENT" 2640 or "VTODO" calendar component. The property value specifies latitude 2641 and longitude, in that order (i.e., "LAT LON" ordering). The 2642 longitude represents the location east and west of the prime meridian 2643 as a positive or negative real number, respectively. The latitude 2644 represents the location north and south of the equator as a positive 2645 or negative real number, respectively. The longitude and latitude 2646 values MUST be specified as decimal degrees and should be specified 2647 to six decimal places. This will allow for granularity within a meter 2648 of the geographical position. The simple formula for converting 2649 degrees-minutes-seconds into decimal degrees is: 2651 decimal = degrees + minutes/60 + seconds/3600. 2653 The property is defined by the following notation: 2655 geo = "GEO" ":" [ws] geovalue CRLF 2657 geovalue = float ";" [ws] float 2658 ;Latitude and Longitude components 2660 The following is an example of this property: 2662 GEO:37.386013;-122.082932 2664 The default data type for this property is FLOAT. 2666 4.6.20 Last Modified 2668 This property is identified by the property name LAST-MODIFIED. The 2669 property specifies the date and time that the calendar information 2670 was last revised. This property MAY be specified in the "VEVENT", 2671 "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components. The data and 2672 time MUST be a UTC value. 2674 The property is defined by the following notation: 2676 last-mod = "LAST-MODIFIED" ":" [ws] date-time CRLF 2678 The following is are examples of this property: 2680 LAST-MODIFIED:19960817T133000Z 2682 The data type for this property is DATE-TIME. 2684 4.6.21 Location 2686 This property is identified by the property name LOCATION. The 2687 property defines the intended location for the "VEVENT" or "VTODO" 2688 calendar component. The property MAY only be specified within a 2689 "VEVENT" or "VTODO" calendar component. 2691 The property is defined by the following notation: 2693 location = "LOCATION [";" [ws] paramlist] ":" [ws] locavalue 2694 CRLF 2696 locavalue = text / url ;The value MUST be the same type as the 2697 ;default or explicit data type. 2699 The following are some examples of this property: 2701 LOCATION:Conference Room - F123, Bldg. 002 2703 LOCATION;VALUE=URL:http://www.xyzcorp.com/~jsmith.vcf 2705 The default data type for this property is TEXT. The data type MAY be 2706 reset to URL. In the case of the data type being URL, the property 2707 value MAY reference a vCard object. This provides a useful mechanism 2708 to specify a location in terms of its electronic business card. 2710 4.6.22 Percent Complete 2712 This property is identified by the property name PERCENT-COMPLETE. 2713 This property is used by an assignee or delegatee of a to-do to 2714 convey the percent completion of a to-do to the Organizer. The 2715 property MAY only be specified once and within a "VTODO" calendar 2716 component. The property value is an integer between zero and one 2717 hundred. A value of "0" indicates the to-do has not yet been started. 2718 A value of "100" indicates that the to-do has been completed. Integer 2719 values in between indicate the percent partially complete. 2721 When a to-do is assigned to multiple individuals, the property value 2722 indicates the percent complete for that portion of the to-do assigned 2723 to the assignee or delegatee. For example, if a to-do is assigned to 2724 both individuals "A" and "B". A reply from "A" with a percent 2725 complete of "70" indicates that "A" has completed 70% of the to-do 2726 assigned to them. A reply from "B" with a percent complete of "50" 2727 indicates "B" has completed 50% of the to-do assigned to them. 2729 The property is defined by the following notation: 2731 percent = "PERCENT-COMPLETE" ":" [ws] integer CRLF 2733 The following is an example of this property to show 39% completion: 2735 PERCENT-COMPLETE:39 2737 The data type for this property is INTEGER. 2739 4.6.23 Priority 2741 This property is identified by the property name PRIORITY. The 2742 property defines the priority for event or to-do. The property MAY 2743 only be specified within a "VEVENT" or "VTODO" calendar component. 2744 The value is an integer. A value of zero (ASCII decimal 48) specifies 2745 an undefined priority. A value of one (ASCII decimal 49) is the 2746 highest priority. A value of two (ASCII decimal 50) is the second 2747 highest priority. Subsequent numbers specify a decreasing ordinal 2748 priority. 2750 The property is specified by the following notation: 2752 priority = "PRIORITY" ":" [ws] integer CRLF 2753 ;Default is zero 2755 The following is an example of this property: 2757 PRIORITY:2 2759 The data type for this property is INTEGER. 2761 4.6.24 Recurrence Date/Times 2763 This property is identified by the property name RDATE. This property 2764 defines the list of date/times for a recurrence set. The property MAY 2765 only appear within the "VEVENT", "VTODO", "VJOURNAL" or "VTIMEZONE" 2766 calendar components. This property MAY appear along with the "RRULE" 2767 property to define an aggregate set of repeating occurrences. When 2768 they both appear in an iCalendar object, the recurring events are 2769 defined by the union of occurrences defined by both the "RDATE" and 2770 "RRULE". The times can either be in local time, local time with UTC 2771 offset or UTC based time. If local time is used, the "VTIMEZONE" 2772 calendar component MUST be included in the iCalendar object, 2773 otherwise the local time value will be interpreted relative to the 2774 time zone of the recipient. The period values for "RDATE" property 2775 are specified using a specific start and a specific end basic format 2776 (period-explicit) or the period with a specific start and a specific 2777 duration basic format (period-start). 2779 The recurrence dates, if specified, is used in computing the 2780 recurrence set. The recurrence set is the complete set of recurrence 2781 instances for a calendar component. The recurrence set is generated 2782 by considering the initial "DTSTART" property along with the "RRULE", 2783 "RDATE", "EXDATE" and "EXRULE" properties contained within the 2784 iCalendar object. The "DTSTART" property defines the first instance 2785 in the recurrence set. Multiple instances of the "RRULE" and "EXRULE" 2786 properties MAY also be specified to define more sophisticated 2787 recurrence sets. The final recurrence set is generated by gathering 2788 all of the start date-times generated by any of the specified "RRULE" 2789 and "RDATE" properties, and excluding any start date and times which 2790 fall within the union of start date and times generated by any 2791 specified "EXRULE" and "EXDATE" properties. This implies that start 2792 date and times within exclusion related properties (i.e., "EXDATE" 2793 and "EXRULE") take precedence over those specified by inclusion 2794 properties (i.e., "RDATE" and "RRULE"). Where duplicate instances are 2795 generated by the "RRULE" and "RDATE" properties, only one recurrence 2796 is considered. Duplicate instances are ignored. 2798 The property is defined by the following notation: 2800 rdate = "RDATE" [";" [ws] paramlist] ":" [ws] rdvalue 2801 *("," [ws] rdvalue) CRLF 2803 rdvalue = date-time / date / period 2804 ;Value MUST match the specified data type 2806 The following are examples of this property: 2808 RDATE:19970714T083000-0400 2810 RDATE;VALUE=PERIOD:19960403T020000Z/19960403T040000Z, 2811 19960404T010000Z/PT3H 2813 RDATE;VALUE=DATE:19970101,19970120,19970217,19970421 2814 19970526,19970704,19970901,19971014,19971128,19971129,19971225 2816 The default data type for this property is DATE-TIME. The data type 2817 MAY be reset to DATE or PERIOD. 2819 4.6.25 Recurrence ID 2821 This property is identified by the property name RECURRENCE-ID. This 2822 property identifies a specific instance of a recurring "VEVENT", 2823 "VTODO" or "VJOURNAL" calendar component. The property value is the 2824 effective value of the "DTSTART" property of the recurrence instance. 2825 The time of day component for the value MUST be either an UTC or a 2826 local time with UTC offset time format, unless the original calendar 2827 object was expressed as a � �floating� 2828 � calendar object; that is in 2829 local time with no time zone calendar component specified. If the 2830 value of the "DTSTART" property is a DATE type value, then the value 2831 MUST be the calendar date for the recurrence instance. 2833 The date/time value is set to the time when the original recurrence 2834 instance would occur - - meaning that if the intent is to change a 2835 Friday meeting to Thursday, the date/time is still set to the 2836 original Friday meeting. 2838 The "RECURRENCE-ID" property is used in conjunction with the "UID" 2839 property to identify a particular instance of a recurring event, to- 2840 do or journal. 2842 The property is defined by the following notation: 2844 recurid = "RECURRENCE-ID" [";" [ws] rangeparm] [";" [ws] 2845 paramlist] ":" [ws] [date-time / date] 2846 rangeparm = "RANGE" "=" ("THISANDPRIOR" / "THISANDFUTURE") 2848 The default value for the range parameter is the single recurrence 2849 instance only. 2851 The following are examples of this property: 2853 RECURRENCE-ID:19960401T235959Z 2855 RECURRENCE-ID;RANGE=THISANDFUTURE:19960120T120000Z 2857 This default data type for this property is DATE-TIME. The data type 2858 MAY be reset to DATE. 2860 4.6.26 Recurrence Rule 2862 This property is identified by the property name RRULE. This property 2863 defines a rule or repeating pattern for a recurring events, to-dos, 2864 or time zone definitions. The property MAY be specified in the 2865 "VEVENT", "VTODO", "VJOURNAL" or "VTIMEZONE" calendar components. The 2866 data type for this property is RECUR. 2868 The recurring rule, if specified, is used in computing the recurrence 2869 set. The recurrence set is the complete set of recurrence instances 2870 for a calendar component. The recurrence set is generated by 2871 considering the initial "DTSTART" property along with the "RRULE", 2872 "RDATE", "EXDATE" and "EXRULE" properties contained within the 2873 iCalendar object. The "DTSTART" property defines the first instance 2874 in the recurrence set. Multiple instances of the "RRULE" and "EXRULE" 2875 properties MAY also be specified to define more sophisticated 2876 recurrence sets. The final recurrence set is generated by gathering 2877 all of the start date-times generated by any of the specified "RRULE" 2878 and "RDATE" properties, and excluding any start date and times which 2879 fall within the union of start date and times generated by any 2880 specified "EXRULE" and "EXDATE" properties. This implies that start 2881 date and times within exclusion related properties (i.e., "EXDATE" 2882 and "EXRULE") take precedence over those specified by inclusion 2883 properties (i.e., "RDATE" and "RRULE"). Where duplicate instances are 2884 generated by the "RRULE" and "RDATE" properties, only one recurrence 2885 is considered. Duplicate instances are ignored. 2887 The "DTSTART" and "DTEND" property pair or "DTSTART" and "DURATION" 2888 property pair, specified within the iCalendar object defines the 2889 first instance of the recurrence. When used with a recurrence rule, 2890 the "DTSTART" and "DTEND" properties MUST be specified in local time 2891 and the appropriate set of "VTIMEZONE" calendar components MUST be 2892 included. For detail on the usage of the "VTIMEZONE" calendar 2893 component, see the "VTIMEZONE" calendar component definition. 2895 Any duration associated with the iCalendar object applies to all 2896 members of the generated recurrence. Any modified duration for 2897 specific recurrences would have to be explicitly specified using the 2898 "RDATE" property. 2900 This property is defined by the following notation: 2902 rrule = "RRULE" [";" [ws] paramlist] ":" [ws] recur CRLF 2904 Examples of this property include the following. All examples assume 2905 the Eastern United States time zone. 2907 Daily for 10 occurrences: 2909 DTSTART:19970902T090000-0400 2910 RRULE:FREQ=DAILY;COUNT=10 2912 ==> (1997 9AM EDT)September 2-11 2914 Daily until 12/24/97: 2916 DTSTART:19970902T090000-0400 2917 RRULE:FREQ=DAILY;UNTIL=19971224T000000Z 2919 ==> (1997 9AM EDT)September 2-30;October 1-25 2920 (1997 9AM EST)October 26-31;November 1-30;December 1-24 2922 Every other day - forever: 2924 DTSTART:19970902T090000-0400 2925 RRULE:FREQ=DAILY;INTERVAL=2 2926 ==> (1997 9AM EDT)September2,4,6,8...24,26,28,30; 2927 October 2,4,6...20,22,24 2928 (1997 9AM EST)October 26,28,30;November 1,3,5,7...25,27,29; 2929 Dec 1,3,... 2931 Every 10 days, 5 occurrences: 2933 DTSTART:19970902T090000-0400 2934 RRULE:FREQ=DAILY;INTERVAL=10;COUNT=5 2936 ==> (1997 9AM EDT)September 2,12,22;October 2,12 2938 Everyday in January, for 3 years: 2940 DTSTART:19980101T090000-0400 2941 RRULE:FREQ=YEARLY;UNTIL:20000131T090000-0400;BYMONTH=1;BYDAY=SU, 2942 MO,TU,WE,TH,FR,SA 2943 or 2944 RRULE:FREQ=DAILY;UNTIL:20000131T090000-0400;BYMONTH=1 2946 ==> (1998 9AM EDT)January 1-31 2947 (1999 9AM EDT)January 1-31 2948 (2000 9AM EDT)January 1-31 2950 Weekly for 10 occurrences 2952 DTSTART:19970902T090000-0400 2953 RRULE:FREQ=WEEKLY;COUNT=10 2954 ==> (1997 9AM EDT)September 2,9,16,23,30;October 7,14,21 2955 (1997 9AM EST)October 28;November 4 2957 Weekly until 12/24/94 2959 DTSTART:19970902T090000-0400 2960 RRULE:FREQ=WEEKLY;UNTIL=19971224T000000Z 2962 ==> (1997 9AM EDT)September 2,9,16,23,30;October 7,14,21 2963 (1997 9AM EST)October 28;November 4,11,18,25; 2964 December 2,9,16,23,24 2966 Every other week - forever: 2968 DTSTART:19970902T090000-0400 2969 RRULE:FREQ=WEEKLY;INTERVAL=2;WKST=SU 2971 ==> (1997 9AM EDT)September 2,16,30;October 14 2972 (1997 9AM EST)October 28;November 11,25;December 9,23 2973 (1998 9AM EST)January 6,20;February 2974 ... 2976 Weekly on Tuesday and Thursday for 5 weeks: 2978 DTSTART:19970902T090000-0400 2979 RRULE:FREQ=WEEKLY;UNTIL=19971007T000000-0400;WKST=SU;BYDAY=TU,TH 2980 or 2981 RRULE:FREQ=WEEKLY;COUNT=10;WKST=SU;BYDAY=TU,TH 2983 ==> (1997 9AM EDT)September 2,4,9,11,16,18,23,25,30;October 2 2985 Every other week on Monday, Wednesday and Friday until 12/24/97, but 2986 starting on Tuesday, 9/2/97: 2988 DTSTART:19970902T090000-0400 2989 RRULE:FREQ=WEEKLY;INTERVAL=2;UNTIL=19971224T000000-0400;WKST=SU; 2990 BYDAY=MO,WE,FR 2991 ==> (1997 9AM EDT)September 2,3,5,15,17,19,29;October 1,3,13,15,17 2992 (1997 9AM EST)October 27,29,31;November 10,12,14,24,26,28; 2993 December 8,10,12,22,24 2995 Every other week on Tuesday and Thursday, for 8 occurrences: 2997 DTSTART:19970902T090000-0400 2998 RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=8;WKST=SU;BYDAY=TU,TH 3000 ==> (1997 9AM EDT)September 2,4,16,18,30;October 2,14,16 3002 Monthly on the 1st Friday for ten occurrences: 3004 DTSTART:19970905T090000-0400 3005 RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR 3006 ==> (1997 9AM EDT)September 5;October 3 3007 (1997 9AM EST)November 7;Dec 5 3008 (1998 9AM EST)January 2;February 6;March 6;April 3 3009 (1998 9AM EDT)MAY 1;June 5 3011 Monthly on the 1st Friday until 12/24/94: 3013 DTSTART:19970905T090000-0400 3014 RRULE:FREQ=MONTHLY;UNTIL=19971224T000000Z;BYDAY=1FR 3016 ==> (1997 9AM EDT)September 5;October 3 3017 (1997 9AM EST)November 7;December 5 3019 Every other month on the 1st and last Sunday of the month for 10 3020 occurrences: 3022 DTSTART:19970907T090000-0400 3023 RRULE:FREQ=MONTHLY;INTERVAL=2;COUNT=10;BYDAY=1SU,-1SU 3025 ==> (1997 9AM EDT)September 7,28 3026 (1997 9AM EST)November 2,30 3027 (1998 9AM EST)January 4,25;March 1,29 3028 (1998 9AM EDT)MAY 3,31 3030 Monthly on the second to last Monday of the month for 6 months: 3032 DTSTART:19970922T090000-0400 3033 RRULE:FREQ=MONTHLY;COUNT=6;BYDAY=-2MO 3035 ==> (1997 9AM EDT)September 22;October 20 3036 (1997 9AM EST)November 17;December 22 3037 (1998 9AM EST)January 19;February 16 3039 Monthly on the third to the last day of the month, forever: 3041 DTSTART:19970928T090000-0400 3042 RRULE:FREQ=MONTHLY;BYMONTHDAY=-3 3044 ==> (1997 9AM EDT)September 28 3045 (1997 9AM EST)October 29;November 28;December 29 3046 (1998 9AM EDT)January 29;February 26 3047 ... 3049 Monthly on the 2nd and 15th of the month for 10 occurrences: 3051 DTSTART:19970902T090000-0400 3052 RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=2,15 3054 ==> (1997 9AM EDT)September 2,15;October 2,15 3055 (1997 9AM EST)November 2,15;December 2,15 3056 (1998 9AM EST)January 2,15 3058 Monthly on the first and last day of the month for 10 occurrences: 3060 DTSTART:19970930T090000-0400 3061 RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=1,-1 3063 ==> (1997 9AM EDT)September 30;October 1 3064 (1997 9AM EST)October 31;November 1,30;December 1,31 3065 (1998 9AM EST)January 1,31;February 1 3067 Every 18 months on the 10th thru 15th of the month for 10 3068 occurrences: 3070 DTSTART:19970910T090000-0400 3071 RRULE:FREQ=MONTHLY;INTERVAL=18;COUNT=10;BYMONTHDAY=10,11,12,13,14, 3072 15 3074 ==> (1997 9AM EDT)September 10,11,12,13,14,15 3075 (1999 9AM EST)March 10,11,12,13 3077 Every Tuesday, every other month: 3079 DTSTART:19970902T090000-0400 3080 RRULE:FREQ=MONTHLY;INTERVAL=2;BYDAY=TU 3082 ==> (1997 9AM EDT)September 2,9,16,23,30 3083 (1997 9AM EST)November 4,11,18,25 3084 (1998 9AM EST)January 6,13,20,27;March 3,10,17,24,31 3085 ... 3087 Yearly in June and July for 10 occurrences: 3089 DTSTART:19970610T090000-0400 3090 RRULE:FREQ=YEARLY;COUNT=10;BYMONTH=6,7 3092 ==> (1997 9AM EDT)June 10;July 10 3093 (1998 9AM EDT)June 10;July 10 3094 (1999 9AM EDT)June 10;July 10 3095 (2000 9AM EDT)June 10;July 10 3096 (2001 9AM EDT)June 10;July 10 3097 Note: Since none of the BYDAY, BYMONTHDAY or BYYEARDAY components 3098 are specified, the day is gotten from DTSTART 3100 Every other year on January, February, and March for 10 occurrences: 3102 DTSTART:19970310T090000-0400 3103 RRULE:FREQ=YEARLY;INTERVAL=2;COUNT=10;BYMONTH=1,2,3 3105 ==> (1997 9AM EST)March 10 3106 (1999 9AM EST)January 10;February 10;March 10 3107 (2001 9AM EST)January 10;February 10;March 10 3108 (2003 9AM EST)January 10;February 10;March 10 3110 Every 3rd year on the 1st, 100th and 200th day for 10 occurrences: 3112 DTSTART:19970101T090000-0400 3113 RRULE:FREQ=YEARLY;INTERVAL=3;COUNT=10;BYYEARDAY=1,100,200 3114 ==> (1997 9AM EST)January 1 3115 (1997 9AM EDT)April 10;July 19 3116 (2000 9AM EST)January 1 3117 (2000 9AM EDT)April 9;July 18 3118 (2003 9AM EST)January 1 3119 (2003 9AM EDT)April 10;July 19 3120 (2006 9AM EST)January 1 3122 Every 20th Monday of the year, forever: 3124 DTSTART:19970519T090000-0400 3125 RRULE:FREQ=YEARLY;BYDAY=20MO 3127 ==> (1997 9AM EDT)MAY 19 3128 (1998 9AM EDT)MAY 18 3129 (1999 9AM EDT)MAY 17 3130 ... 3132 Monday of Week No. 20, forever: 3134 DTSTART:19970512T090000-0400 3135 RRULE:FREQ=YEARLY;BYWEEKNO=20;BYDAY=MO 3137 ==> (1997 9AM EDT)MAY 12 3138 (1998 9AM EDT)MAY 11 3139 (1999 9AM EDT)MAY 17 3140 ... 3142 Every Thursday in March, forever: 3144 DTSTART:19970313T090000-0400 3145 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=TH 3147 ==> (1997 9AM EST)March 13,20,27 3148 (1998 9AM EST)March 5,12,19,26 3149 (1999 9AM EST)March 4,11,18,25 3150 ... 3152 Every Thursday, but only during summer months, forever: 3154 DTSTART:19970605T090000-0400 3155 RRULE:FREQ=YEARLY;BYDAY=TH;BYMONTH=6,7,8 3157 ==> (1997 9AM EDT)June 5,12,19,26;July 3,10,17,24,31; 3158 August 7,14,21,28 3159 (1998 9AM EDT)June 4,11,18,25;July 2,9,16,23,30; 3160 August 6,13,20,27 3161 (1999 9AM EDT)June 3,10,17,24;July 1,8,15,22,29; 3162 August 5,12,19,26 3163 ... 3165 Every Friday the 13th, forever: 3167 DTSTART:19970902T090000-0400 3168 EXDATE:19970902T090000-0400 3169 RRULE:FREQ=MONTHLY;BYDAY=FR;BYMONTHDAY=13 3171 ==> (1998 9AM EST)February 13;March 13;November 13 3172 (1999 9AM EDT)August 13 3173 (2000 9AM EDT)October 13 3174 ... 3176 The first Saturday that follows the first Sunday of the month, 3177 forever: 3179 DTSTART:19970913T090000-0400 3180 RRULE:FREQ=MONTHLY;BYDAY=SA;BYMONTHDAY=7,8,9,10,11,12,13 3182 ==> (1997 9AM EDT)September 13;October 11 3183 (1997 9AM EST)November 8;December 13 3184 (1998 9AM EST)January 10;February 7;March 7 3185 (1998 9AM EDT)April 11;MAY 9;June 13... 3186 ... 3188 Every four years, the first Tuesday after a Monday in November, 3189 forever (U.S. Presidential Election day): 3191 DTSTART:19961105T090000-0400 3192 RRULE:FREQ=YEARLY;INTERVAL=4;BYMONTH=11;BYDAY=TU;BYMONTHDAY=2,3,4, 3193 5,6,7,8 3195 ==> (1996 9AM EST)November 5 3196 (2000 9AM EST)November 7 3197 (2004 9AM EST)November 2 3198 ... 3200 The 3rd instance into the month of one of Tuesday, Wednesday or 3201 Thursday, for the next 3 months: 3203 DTSTART:19970904T090000-0400 3204 RRULE:FREQ=MONTHLY;COUNT=3;BYDAY=TU,WE,TH;BYSETPOS=3 3206 ==> (1997 9AM EDT)September 4;October 7 3207 (1997 9AM EST)November 5 3209 The 2nd to last weekday of the month: 3211 DTSTART:19970929T090000-0400 3212 RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-2 3214 ==> (1997 9AM EDT)September 29 3215 (1997 9AM EST)October 30;November 27;December 30 3216 (1998 9AM EST)January 29;February 26;March 30 3217 ... 3219 Every 3 hours from 9AM to 5PM on a specific day: 3221 DTSTART:19970902T090000-0400 3222 RRULE:FREQ=HOURLY;INTERVAL=3;UNTIL=19970902T170000-0400 3224 ==> (September 2, 1997 EDT)09:00,12:00,15:00 3226 Every 15 minutes for 6 occurrences: 3228 DTSTART:19970902T090000-0400 3229 RRULE:FREQ=MINUTELY;INTERVAL=15;COUNT=6 3231 ==> (September 2, 1997 EDT)09:00,09:15,09:30,09:45,10:00,10:15 3233 Every hour and a half for 4 occurrences: 3235 DTSTART:19970902T090000-0400 3236 RRULE:FREQ=MINUTELY;INTERVAL=90;COUNT=4 3238 ==> (September 2, 1997 EDT)09:00,10:30;12:00;13:30 3240 Every 20 minutes from 9AM to 4:40PM every day: 3242 DTSTART:19970902T090000-0400 3243 RRULE:FREQ=DAILY;BYHOUR=9,10,11,12,13,14,15,16;BYMINUTE=0,20,40 3244 or 3245 RRULE:FREQ=MINUTELY;INTERVAL=20;BYHOUR=9,10,11,12,13,14,15,16 3247 ==> (September 2, 1997 EDT)9:00,9:20,9:40,10:00,10:20, 3248 ... 16:00,16:20,16:40 3249 (September 3 1997 EDT)9:00,9:20,9:40,10:00,10:20, 3250 ...16:00,16:20,16:40 3251 ... 3253 An example where the days generated makes a difference because of 3254 WKST: 3256 DTSTART:19970805T090000-0400 3257 RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=4;BYDAY=TU,SU;WKST=MO 3259 ==> (1997 EDT)Aug 5,10,19,24 3261 changing only WKST from MO to SU, yields different reults... 3263 DTSTART:19970805T090000-0400 3264 RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=4;BYDAY=TU,SU;WKST=SU 3265 ==> (1997 EDT)August 5,17,19,31 3267 4.6.27 Related To 3269 This property is identified by the property name RELATED-TO. The 3270 property is used to represent relationships or references between one 3271 calendar component and another. The property MAY only be specified in 3272 the "VEVENT", "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components. 3273 The property value consists of the persistent, globally unique 3274 identifier of another calendar component. This value would be 3275 represented in a calendar component by the "UID" property. The 3276 property value always points to another calendar component that has a 3277 "parent" relationship to the referencing object. 3279 A linked relationship can be specified by a series of components that 3280 each, in turn, refer to their parent component. A group relationship 3281 can be specified by a number of components that all refer to one 3282 common parent component. 3284 Changes to a calendar component referenced by this property MAY 3285 impact the related calendar component. For example, if a group event 3286 changes its start or end date or time, then the related, dependent 3287 events will need to have their start and end dates changed in a 3288 corresponding way. This property is intended only to provide 3289 information on the relationship of calendar components. It is up to 3290 the target calendar system to maintain any property implications of 3291 this relationship. 3293 The property is defined by the following notation: 3295 related = "RELATED-TO" [";" [ws] paramlist] ":" [ws] uid CRLF 3297 The following is an example of this property: 3299 RELATED-TO: 3301 RELATED-TO:<19960401-080045-4000F192713-0052@host1.com> 3303 The data type for this property is UID. 3305 4.6.28 Repeat Count 3307 This property is identified by the property name REPEAT. This 3308 property defines the number of repetitions for an alarm. 3310 The property is defined by the following notation: 3312 repeatcnt = "REPEAT" ":" [ws] integer CRLF 3313 ;Default is "1". 3315 The following is an example of this property: 3317 REPEAT:4 3319 The data type for the property is INTEGER. 3321 4.6.29 Request Status 3323 This property is identified by the property name REQUEST-STATUS. This 3324 property defines the status code returned for a scheduling request. 3325 This property is used to return status code information related to 3326 the processing of an associated iCalendar object. The data type for 3327 this property is TEXT. 3329 The value consists of a short return status, a longer return status 3330 description, and optionally the offending data. The components of the 3331 value are separated by the SEMICOLON character (ASCII decimal 59). 3333 The short return status is a PERIOD character (ASCII decimal xx) 3334 separated set of integers. For example, "3.1.1". The successive 3335 levels of integers provide for a successive level of status code 3336 granularity. 3338 The property is defined by the following notation: 3340 Rstatus = "REQUEST-STATUS" ":" [ws] statcode ";" [ws] 3341 statdesc [";" [ws] extdata] 3343 Statcode = 1*DIGIT *("." 1*DIGIT) 3344 ;Hierarchical, numeric return status code 3346 Statdesc = *WORD 3347 ;Textual status description 3349 Extdata = *WORD 3350 ;Textual exception data. For example, the offending property 3351 ;name and value or complete property line. 3353 The following are some possible examples of this property (Note: The 3354 BACKSLASH character escapement of separator characters in a property 3355 value): 3357 REQUEST-STATUS:2.0;Success 3359 REQUEST-STATUS:3.1;Invalid property value;DTSTART:96-Apr-01 3361 REQUEST-STATUS:2.8; Success\, repeating event ignored. Scheduled 3362 as a single event.;RRULE\:FREQ=WEEKLY\;INTERVAL=2 3364 REQUEST-STATUS:4.1;Event conflict. Date/time is busy. 3366 REQUEST-STATUS:3.7;Invalid calendar user;ATTENDEE\: 3367 jsmith@host.com 3369 The following are valid classes for the return status code. 3370 Individual iCalendar object methods will define specific return 3371 status codes for these classes. 3373 |==============+===============================================| 3374 | Short Return | Longer Return Status Description | 3375 | Status Code | | 3376 |==============+===============================================| 3377 | 1.xx | Preliminary success. This class of status | 3378 | | of status code indicates that the request has | 3379 | | request has been initially processed but that | 3380 | | completion is pending. | 3381 |==============+===============================================| 3382 | 2.xx | Successful. This class of status code | 3383 | | indicates that the request was completed | 3384 | | successfuly. However, the exact status code | 3385 | | MAY indicate that a fallback has been taken. | 3386 |==============+===============================================| 3387 | 3.xx | Client Error. This class of status code | 3388 | | indicates that the request was not successful.| 3389 | | The error is the result of either a syntax or | 3390 | | a semantic error in the client formatted | 3391 | | request. Request should not be retried until | 3392 | | the condition in the request is corrected. | 3393 |==============+===============================================| 3394 | 4.xx | Scheduling Error. This class of status code | 3395 | | indicates that the request was not successful.| 3396 | | Some sort of error occurred within the | 3397 | | calendaring and scheduling service, not | 3398 | | directly related to the request itself. | 3399 |==============+===============================================| 3401 4.6.30 Resources 3403 This property is identified by the property name RESOURCES. This 3404 property defines the equipment or resources needed for the event or 3405 to-do. The property value is an arbitrary text. The property MAY only 3406 be specified in the "VEVENT" or "VTODO" calendar component. More than 3407 one resource MAY be specified as a list of resources separated by the 3408 COMMA character (ASCII decimal 44). 3410 The property is defined by the following notation: 3412 resource = "RESOURCES" [";" [ws] paramlist] ":" [ws] 3413 resvalist CRLF 3415 resvalist = resvalue / resvalue "," [ws] resvalist 3417 resvalue = "CATERING" / "CHAIRS" / "COMPUTER PROJECTOR" 3418 / "EASEL" / "OVERHEAD PROJECTOR" / "SPEAKER PHONE" 3419 / "TABLE" / "TV" / "VCR" / "VIDEO PHONE" / "VEHICLE" 3420 / word 3422 The following is an example of this property: 3424 RESOURCES:EASEL,PROJECTOR,VCR 3426 The data type for this property is TEXT. 3428 4.6.31 Sequence Number 3430 This property is identified by the property name SEQUENCE. This 3431 property defines the revision sequence of the calendar component used 3432 in a request. The property MAY only be specified in a "VEVENT", 3433 "VTODO", "VJOURNAL" or "VFREEBUSY" calendar component. This property 3434 is needed to properly handle the receipt and processing of a sequence 3435 of calendar components that have been delivered out of order. Such is 3436 the case for store-and-forward based transports. The first request is 3437 created with a sequence number of "0" (ASCII decimal 48). It is 3438 incremented each time the ORGANIZER or OWNER issues a revision to the 3439 request. The sequence number MUST be monotonically incremented when 3440 one of the following properties in a calendar component is changed: 3442 � "DTSTART" 3443 � "DTEND" 3444 � "DUE" 3445 � "RDATE" 3446 � "RRULE" 3447 � "EXDATE" 3448 � "EXRULE" 3450 The property is defined by the following notation: 3452 sequence = "SEQUENCE" ":" [ws] integer CRLF 3453 ;Default is "0". 3455 The following is an example of this property: 3457 SEQUENCE:1 3459 The data type for this property is INTEGER. 3461 4.6.32 Status 3463 This property is identified by the property name STATUS. This 3464 property defines the orignator's view of the overall status for the 3465 calendar component. This property MAY only be specified in the 3466 "VEVENT", "VTODO", "VJOURNAL" calendar components. The property is 3467 used to specify the originator's view of the general consensus for 3468 the event or the to-do. In addition, when specified in a group 3469 scheduled to-do the property is used to specify the originator's view 3470 of the completion status for the to-do. The property MAY also specify 3471 whether the event or to-do has been cancelled. 3473 The property is defined by the following notation: 3475 status = "STATUS" [";" [ws] paramlist] ":" [ws] statvalue CRLF 3477 statvalue = "NEEDS-ACTION" ;Indicates to-do needs action. 3478 / "COMPLETED" ;Indicates to-do completed. 3479 / "IN-PROCESS" ;Indicates to-do in process of 3480 ;being completed. 3481 / "TENTATIVE" ;Indicates event or to-do is 3482 ;tentative. 3483 / "CONFIRMED" ;Indicates event or to-do is 3484 ;definite. 3486 / "CANCELLED" ;Indicates event or to-do was 3487 ;cancelled. 3489 The following is an example of this property: 3491 STATUS:TENTATIVE 3493 The data type for this property is TEXT. 3495 4.6.33 Summary 3497 This property is identified by the property name SUMMARY. This 3498 property defines a short summary or subject for the calendar 3499 component. The property MUST be specified in the "VEVENT", "VTODO" 3500 and "VJOURNAL" calendar components. In addition, it MAY appear in the 3501 "VALARM" calendar component. 3503 The property is defined by the following notation: 3505 summary = "SUMMARY" [";" [ws] paramlist] ":" [ws] text CRLF 3507 The following is an example of this property: 3509 SUMMARY:Department Party 3511 The data type for this property is TEXT. 3513 4.6.34 Time Transparency 3515 This property is identified by the property name TRANSP. This 3516 property defines whether an event is transparent or not to busy time 3517 searches. This property MAY only be specified in a "VEVENT" calendar 3518 component. 3520 The property is specified by the following notation: 3522 transp = "TRANSP" [";" [ws] paramlist] ":" [ws] transvalue CRLF 3524 transvalue = "OPAQUE" ;Blocks or opaque on busy time searches. 3525 / "TRANSPARENT" ;Transparent on busy time searches. 3527 ;Default value is OPAQUE 3529 The following is an example of this property for an event that is 3530 transparent or does not block on free/busy time searches: 3532 TRANSP:TRANSPARENT 3534 The following is an example of this property for an event that is 3535 opaque or blocks on free/busy time searches: 3537 TRANSP:OPAQUE 3538 The data type for this property is TEXT. 3540 4.6.35 Time Zone Name 3542 This property is identified by the property name TZNAME. This 3543 property specifies the customary designation for a time zone 3544 description. This property MAY only be specified in the "VTIMEZONE" 3545 calendar component. 3547 This property is defined by the following notation: 3549 tzname = "TZNAME" [";" [ws] paramlist] ":" [ws] text CRLF 3551 The following are examples of this property: 3553 TZNAME: EST 3555 TZNAME: PDT 3557 The data type for this property is TEXT. 3559 4.6.36 Time Zone Offset 3561 This property is identified by the property name TZOFFSET. This 3562 property specifies the offset from UTC for a time zone. This property 3563 MAY only be specified in a "VTIMEZONE" calendar component. A 3564 "VTIMEZONE" calendar component MUST include this property. The 3565 property value is a signed numeric indicating the number of hours and 3566 possibly minutes from UTC. Positive numbers represents time zones 3567 east, or ahead of UTC. Negative numbers represents time zones west 3568 of, or behind UTC. 3570 The property is defined by the following notation: 3572 tzoffset = "TZOFFSET" ":" [ws] utc-offset CRLF 3574 The following are examples of this property: 3576 TZOFFSET:-0500 3578 TZOFFSET:+0530 3580 The data type for this property is UTC-OFFSET. 3582 4.6.37 Uniform Resource Locator 3584 This property is identified by the property name URL. This property 3585 defines a Uniform Resource Locator (URL) associated with the 3586 iCalendar object. This property MAY be specified in the "VEVENT", 3587 "VTODO", "VJOURNAL", "VFREEBUSY", and "VALARM" calendar components. 3589 The property is defined by the following notation: 3591 url = "URL" ":" [ws] url CRLF 3593 The following is an example of this property: 3595 URL:http://abc.com/pub/calendars/jsmith/mytime.or3 3597 The data type for this property is URL. 3599 4.6.38 Unique Identifier 3601 This property is identified by the property name UID. This property 3602 defines the persistent, globally unique identifier for the calendar 3603 component. The property MUST be specified in the "VEVENT", "VTODO" 3604 and "VJOURNAL" calendar components. 3606 The UID itself MUST be a globally unique identifier. The generator of 3607 the identifier MUST guarantee that the identifier is unique. There 3608 are several algorithms that can be used to accomplish this. The 3609 identifier is RECOMMENDED to be the identical syntax to the [RFC 822] 3610 addr-spec. A good method to assure uniqueness is to put the domain 3611 name or a domain literal IP address of the host on which the 3612 identifier was created on the right hand side of the "@", and on the 3613 left hand side, put a combination of the current calendar date and 3614 time of day (i.e., formatted in as a DATE-TIME value) along with some 3615 other currently unique (perhaps sequential) identifier available on 3616 the system (for example, a process id number). Using a date/time 3617 value on the left hand side and a domain name or domain literal on 3618 the right hand side makes it possible to guarantee uniqueness since 3619 no two hosts should be using the same domain name or IP address at 3620 the same time. Though other algorithms will work, it is RECOMMENDED 3621 that the right hand side contain some domain identifier (either of 3622 the host itself or otherwise) such that the generator of the message 3623 identifier can guarantee the uniqueness of the left hand side within 3624 the scope of that domain. 3626 This identifier is created by the calendar system that generates an 3627 iCalendar object. The identifier is represented as a text value. This 3628 is the method for correlating scheduling messages with the referenced 3629 event, to-do, or journal. 3631 The property is defined by the following notation: 3633 uid = "UID" ":" [ws] text CRLF 3635 The following is an example of this property: 3637 UID:19960401T080045Z-4000F192713-0052@host1.com 3639 This property is an important method for group scheduling 3640 applications to match requests with later replies, modifications or 3641 deletion requests. Calendaring and scheduling applications MUST 3642 generate this property in "VEVENT", "VTODO" and "VJOURNAL" calendar 3643 components to assure interoperability with other group scheduling 3644 applications. 3646 Implementations MUST be able to receive and persist values of at 3647 least 255 characters for this property. 3649 The data type for this property is TEXT. 3651 4.6.39 Non-standard Properties 3653 The MIME Calendaring and Scheduling Content Type provides a "standard 3654 mechanism for doing non-standard things". This extension support is 3655 provided for implementers to "push the envelope" on the existing 3656 version of the memo. Extension properties are specified by property 3657 and/or property parameter names that have the prefix text of "X-" 3658 (the two character sequence: LATIN CAPITAL LETTER X character 3659 followed by the HYPEN-MINUS character). It is RECOMMENDED that 3660 vendors concatenate onto this sentinel another short prefix text to 3661 identify the vendor. This will facilitate readability of the 3662 extensions and minimize possible collision of names between different 3663 vendors. User agents that support this content type are expected to 3664 be able to parse the extension properties and property parameters but 3665 MAY ignore them. 3667 The property is defined by the following notation: 3669 extension = "X-" [vendorid] "-" word [";" [ws] paramlist] ":" [ws] 3670 value 3672 vendorid = 3*char ;Vendor identification prefix text 3674 The following might be the ABC vendor�s extension for an audio-clip 3675 form of subject property: 3677 X-ABC-MMSUBJ;TYPE=WAVE; VALUE=URL: http://load.noise.org/mysubj.wav 3679 At present, there is no registration authority for names of extension 3680 properties and property parameters. The data type for this property 3681 is TEXT. Optionally, the data type MAY be any of the other valid data 3682 types. 3684 5. Recommended Practices 3686 These recommended practices should be followed in order to assure 3687 consistent handling of the following cases for an iCalendar object. 3689 1. A calendar entry with a "DTSTART" property but no "DTEND" property 3690 - The event does not take up any time. It is intended to represent 3691 an event that is associated with a given calendar date and time of 3692 day, such as an anniversary. Since the event does not take up any 3693 time, it MUST NOT be used to record busy time no matter what the 3694 value for the "TRANSP" property. 3696 2. When the "DTSTART" and "DTEND", for "VEVENT", "VJOURNAL" and 3697 "VFREEBUSY" calendar components, and "DTSTART" and "DUE", for 3698 "VTODO" calendar components, have the same value data type (e.g., 3699 DATE-TIME), they should specify values in the same time format 3700 (e.g., local time with UTC offset). 3702 3. A combination of "RRULE" and "RDATE" properties that produces more 3703 than one instance for a given date/time - Only one recurrence can 3704 occur on a given date/time interval. Just one instance for the 3705 date/time is recorded. 3707 4. A particular iCalendar object method that specifies "ATTENDEE" 3708 properties with the "MEMBER" property parameter, for which the 3709 recipient has multiple memberships - Recipient should reply to 3710 only the first "MEMBER" property parameter value that it can 3711 match. 3713 6. Registration of Content Type Elements 3715 This section provide the process for registration of MIME Calendaring 3716 and Scheduling Content Type iCalendar object methods and new or 3717 modified properties. 3719 6.1 Registration of New and Modified iCalendar object Methods 3721 New MIME Calendaring and Scheduling Content Type iCalendar object 3722 methods are registered by the publication of an IETF Request for 3723 Comment (RFC). Changes to an iCalendar object method are registered 3724 by the publication of a revision of the RFC defining the method. 3726 6.2 Registration of New Properties 3728 This section defines procedures by which new properties or enumerated 3729 property values for the MIME Calendaring and Scheduling Content Type 3730 can be registered with the IANA. Note that non-IANA properties MAY be 3731 used by bilateral agreement, provided the associated properties names 3732 follow the "X-" convention. 3734 The procedures defined here are designed to allow public comment and 3735 review of new properties, while posing only a small impediment to the 3736 definition of new properties. 3738 Registration of a new property is accomplished by the following 3739 steps. 3741 6.2.1 Define the property 3743 A property is defined by completing the following template. 3745 To: ietf-calendar@imc.org 3747 Subject: Registration of text/calendar MIME property XXX 3748 Property name: 3750 Property purpose: 3752 Property data type(s): 3754 Property encoding: 3756 Property special notes (optional): 3758 Intended usage: (one of COMMON, LIMITED USE or OBSOLETE) 3760 The meaning of each field in the template is as follows. 3762 Property name: The name of the property, as it will appear in the 3763 body of an text/calendar MIME Content-Type "property: value" line to 3764 the left of the colon ":". 3766 Property purpose: The purpose of the property (e.g., to indicate a 3767 delegate for the event or to-do, etc.). Give a short but clear 3768 description. 3770 Property data type(s): Any of the valid data types for the property 3771 value needs to be specified. The default data type also needs to be 3772 specified. If a new data type is specified, it needs to be declared 3773 in this section. 3775 Property encoding: The encodings permitted for the property value. 3776 This description MUST be precise and MUST NOT violate the general 3777 encoding rules defined in this memo. 3779 Property special notes: Any special notes about the property, how it 3780 is to be used, etc. 3782 6.2.2 Post the Property definition 3784 The property description MUST be posted to the new property 3785 discussion list, ietf-calendar@imc.org. 3787 6.2.3 Allow a comment period 3789 Discussion on the new property MUST be allowed to take place on the 3790 list for a minimum of two weeks. Consensus MUST be reached on the 3791 property before proceeding to the next step. 3793 6.2.4 Submit the property for approval 3795 Once the two-week comment period has elapsed, and the proposer is 3796 convinced consensus has been reached on the property, the 3797 registration application should be submitted to the Method Reviewer 3798 for approval. The Method Reviewer is appointed to the Application 3799 Area Directors and MAY either accept or reject the property 3800 registration. An accepted registration should be passed on by the 3801 Method Reviewer to the IANA for inclusion in the official IANA method 3802 registry. The registration MAY be rejected for any of the following 3803 reasons. 1) Insufficient comment period; 2) Consensus not reached; 3) 3804 Technical deficiencies raised on the list or elsewhere have not been 3805 addressed. The Method Reviewer's decision to reject a property MAY be 3806 appealed by the proposer to the IESG, or the objections raised can be 3807 addressed by the proposer and the property resubmitted. 3809 6.3 Property Change Control 3811 Existing properties MAY be changed using the same process by which 3812 they were registered. 3814 1. Define the change 3816 2. Post the change 3818 3. Allow a comment period 3820 4. Submit the property for approval 3822 Note that the original author or any other interested party MAY 3823 propose a change to an existing property, but that such changes 3824 should only be proposed when there are serious omissions or errors in 3825 the published memo. The Method Reviewer MAY object to a change if it 3826 is not backwards compatible, but is not required to do so. 3828 Property definitions can never be deleted from the IANA registry, but 3829 properties which are no longer believed to be useful can be declared 3830 OBSOLETE by a change to their "intended use" field. 3832 7. File extension 3834 The file extension of "vcs" is to be used to designate a file 3835 containing calendaring and scheduling information consistent with 3836 this MIME content type. 3838 8. Macintosh File Type Code 3840 The file type code of "vcal" is to be used in Apple MacIntosh 3841 operating system environments to designate a file containing 3842 calendaring and scheduling information consistent with this MIME 3843 media type. 3845 9. References 3847 The following document are referred to within this memo. 3849 [ICMS] "Internet Calendaring Model Specification", Internet-Draft, 3850 July 1997, ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch-mod- 3851 00.txt. 3853 [IMIP] "iCalendar Message-based Interoperability Protocol (IMIP)", 3854 Internet Draft, October 1997, http://www.imc.org/draft-ietf-calsch- 3855 imip-02.txt. 3857 [ISO 8601] ISO 8601, "Data elements and interchange formats- - 3858 - 3859 Information interchange--Representation of dates and times", 3860 International Organization for Standardization, June, 1988. This 3861 standard is also addressed by the Internet Draft document 3862 ftp://ds.internic.net/internet-drafts/draft-newman-datetime-00.txt. 3864 [ISO 9070] ISO/IEC 9070, "Information Technology- - 3865 -SGML Support 3866 Facilities--Registration Procedures for Public Text Owner 3867 Identifiers", Second Edition, International Organization for 3868 Standardization, April, 1991. 3870 [ITIP] "iCalendar Transport-Independent Interoperability Protocol 3871 (iTIP) : Scheduling Events, Busy Time, To-dos and Journal Entries ", 3872 Internet-Draft, October 1997, http://www.imc.org/draft-ietf-calsch- 3873 itip-01.txt. 3875 [MIME DIR] Howes, T., Smith, M., "A MIME Content-Type for Directory 3876 Information", Internet-draft-ietf-asid-mime-direct-06.txt, July, 3877 1997. 3879 [RFC 822] Crocker, D., "Standard for the Format of ARPA Internet Text 3880 Messages", STD 11, RFC 822, August 1982. 3882 [RFC 1738] Berners-Lee, T., Masinter, L., McCahill, M., "Uniform 3883 Resource Locators (URL)", RFC 1738, December 1994. 3885 [RFC 1766] Alvestrand, H., "Tags for the Identification of 3886 Languages", March 1995. 3888 [RFC 1872] Levinson, E., "The MIME Multipart/Related Content-type," 3889 RFC 1872, December 1995. 3891 [RFC1983] "Internet Users' Glossary", RFC 1983, August 1996. 3893 [RFC 2045] Freed, N., Borenstein, N., " Multipurpose Internet Mail 3894 Extensions (MIME) - Part One: Format of Internet Message Bodies", RFC 3895 2045, November 1996. 3897 [RFC 2046] Freed, N., Borenstein, N., " Multipurpose Internet Mail 3898 Extensions (MIME) - Part Two: Media Types", RFC 2046, November 1996. 3900 [RFC 2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME) - 3901 Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, 3902 November 1996. 3904 [RFC 2048] Freed, N., J. Klensin, J. Postel, "Multipurpose Internet 3905 Mail Extensions (MIME) - Part Four: Registration Procedures", RFC 3906 2048, January 1997. 3908 [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels", 3909 RFC 2119, March 1997. 3911 [UTF-8] "UTF-8, a transformation format of Unicode and ISO 3912 10646",Internet-Draft, July,1996, ftp://ftp.ietf.org/internet- 3913 drafts/draft-yergeau-utf8-01.txt. 3915 [VCARD] Internet Mail Consortium, "vCard - The Electronic Business 3916 Card Version 2.1", http://www.versit.com/pdi/vcard-21.txt, September 3917 18, 1996. 3919 [VCAL] Internet Mail Consortium, "vCalendar - The Electronic 3920 Calendaring and Scheduling Exchange Format", 3921 http://www.imc.org/pdi/vcal-10.txt, September 18, 1996. 3923 [XAPIA] "XAPIA CSA, Calendaring and Scheduling Application 3924 Programming Interface (CSA) Version 1.0", X.400 API Association, 3925 November 15, 1994. 3927 10. Acknowledgments 3929 A hearty thanks to the IETF Calendaring and Scheduling Working Group 3930 and also the following individuals who have participated in the 3931 drafting, review and discussion of this memo: 3933 Roland Alden, Harald T. Alvestrand, Eric Berman, Denis Bigorgne, John 3934 Binici, Bill Bliss, Philippe Boucher, Steve Carter, Andre 3935 Courtemanche, Dave Crocker, Alec Dun, John Evans, Ross Finlayson, 3936 Randell Flint, Ned Freed, Patrik Falstrom, Chuck Grandgent, Mark 3937 Handley, Steve Hanna, Paul B. Hill, Paul Hoffman, Ross Hopson, Mark 3938 Horton, Bruce Kahn, C. Harald Koch, Don Lavange, Theodore Lorek, 3939 Steve Mansour, Skip Montanaro, Keith Moore, Cecil Murray, Chris 3940 Newman, John Noerenberg, Ralph Patterson, Pete Resnick, Keith Rhodes, 3941 Robert Ripberger, John Rose, Andras Salamar, Ted Schuh, Vinod 3942 Seraphin, Derrick Shadel, Ken Shan, Andrew Shuman, Steve Silverberg, 3943 William P. Spencer, John Sun, Mark Towfiq, Robert Visnov, James L. 3944 Weiner, Mike Weston, William Wyatt. 3946 11. Copyright 3948 12. Author's Address 3950 The following address information is provided in a MIME-VCARD, 3951 Electronic Business Card, format. 3953 The authors of this draft are: 3955 BEGIN:VCARD 3956 FN:Frank Dawson 3957 ORG:Lotus Development Corporation 3958 ADR;WORK;POSTAL;PARCEL:;;6544 Battleford Drive; 3959 Raleigh;NC;27613-3502;USA 3960 TEL;WORK;MSG:+1-919-676-9515 3961 TEL;WORK;FAX:+1-919-676-9564 3962 EMAIL;INTERNET:fdawson@earthlink.net 3963 URL:http://home.earthlink.net/~fdawson 3964 END:VCARD 3966 BEGIN:VCARD 3967 FN:Derik Stenerson 3968 ORG:Microsoft Corporation 3969 ADR;WORK;POSTAL;PARCEL:;;One Microsoft Way; 3970 Redmond;WA;98052-6399;USA 3971 TEL;WORK;MSG:+1-425-936-5522 3972 TEL;WORK;FAX:+1-425-936-7329 3973 EMAIL;INTERNET:deriks@Microsoft.com 3974 END:VCARD 3976 The iCalendar object is a result of the work of the Internet 3977 Engineering Task Force Calendaring and Scheduling Working Group. The 3978 chairman of that working group is: 3980 BEGIN:VCARD 3981 FN:Anik Ganguly 3982 ORG:OnTime, Inc. 3983 ADR;WORK;POSTAL;PARCEL:10 Floor;;21700 Northwestern Highway; 3984 Southfield;MI;48075;USA 3985 TEL;WORK;MSG:+1-248-559-5955 3986 TEL;WORK;FAX:+1-248-559-5034 3987 EMAIL;INTERNET:anik@ontime.com 3988 END:VCARD 3990 13. iCalendar object Examples 3992 The following examples are provided as an informational source of 3993 illustrative iCalendar objects consistent with this content type. 3995 The following iCalendar object is specified as the content of a MIME 3996 message. The example demonstrates a possible meeting request between 3997 the originator and recipient of the message. 3999 TO:jsmith@host1.com 4000 FROM:jdoe@host1.com 4001 MIME-VERSION:1.0 4002 MESSAGE-ID: 4003 CONTENT-TYPE:text/calendar;method=request 4005 BEGIN:VCALENDAR 4006 METHOD:REQUEST 4007 PRODID:-//xyz Corp//NONSGML PDA Calendar Verson 1.0//EN 4008 VERSION:2.0 4009 BEGIN:VEVENT 4010 DTSTAMP:19960704T120000Z 4011 DTSTART:19960918T143000Z 4012 DTEND:19960920T220000Z 4013 CATEGORIES:CONFERENCE,PROJECT 4014 SUMMARY:Networld+Interop Conference 4015 DESCRIPTION:Networld+Interop Conference 4016 and Exhibit\nAtlanta World Congress Center\n 4017 Atlanta, Georgia 4018 END:VEVENT 4019 END:VCALENDAR 4021 The following example message issues a meeting request that does not 4022 require any reply. The message is sent as a singular "text/calendar" 4023 content type, body part. 4025 From: jsmith@host1.com 4026 To: ietf-calendar@imc.org 4027 Subject: First IETF-Calendar Working Group Meeting 4028 MIME-Version: 1.0 4029 Message-ID: 4030 Content-Type: text/calendar;method=request 4032 BEGIN:VCALENDAR 4033 METHOD:REQUEST 4034 PRODID:-//RDU Software//NONSGML HandCal//EN 4035 VERSION:2.0 4036 BEGIN:VEVENT 4037 DTSTAMP:19961022T133000Z 4038 ATTENDEE;EXPECT=REQUEST:ietf-calendar@imc.org 4039 DESCRIPTION:First IETF-Calendaring and Scheduling Working Group 4040 Meeting 4041 CATEGORIES:MEETING 4042 CLASS:PUBLIC 4043 CREATED:19961022T083000 4044 SUMMARY:IETF Calendaring Working Group Meeting 4045 DTSTART:19961210T210000Z 4046 DTEND:19961210T220000Z 4047 LOCATION:San Jose, CA - Fairmont Hotel 4048 UID:guid-1.host1.com 4049 END:VEVENT 4050 END:VCALENDAR 4052 The following is an example of a MIME message with a single body part 4053 consisting of a text/calendar content type. The message specifies a 4054 meeting request between the originator and recipient of the message. 4056 TO:jsmith@host1.com 4057 FROM:jdoe@host1.com 4058 MIME-VERSION:1.0 4059 MESSAGE-ID: 4060 CONTENT-TYPE:text/calendar;method=request 4061 BEGIN:VCALENDAR 4062 METHOD:REQUEST 4063 VERSION:2.0 4064 PRODID:-//ABC Corporation//NONSGML My Product//EN 4065 BEGIN:VEVENT 4066 DTSTAMP:19970324T1200Z 4067 SEQUENCE:0 4068 UID:19970324T080045Z-4000F192713-0052@host1.com 4069 ATTENDEE;EXPECT=REQUEST:jsmith@host1.com 4070 DTSTART:19970324T123000Z 4071 DTEND:19970324T210000Z 4072 CATEGORIES:CONFERENCE,PROJECT 4073 CLASS:PUBLIC 4074 SUMMARY:Calendaring Interop Conference 4075 DESCRIPTION:Calendaring Interop Conference and Exhibit\n 4076 Atlanta, Georgia 4077 LOCATION:Atlanta World Congress Center 4078 ATTACH;VALUE=URL:file:///xyzCorp.com/conf/bkgrnd.ps 4079 END:VEVENT 4080 END:VCALENDAR 4082 Example of a reply to the above request, accepting the meeting. 4084 TO:jdoe@host1.com 4085 FROM:jsmith@host1.com 4086 MIME-VERSION:1.0 4087 MESSAGE-ID: 4088 CONTENT-TYPE:text/calendar;method=reply 4090 BEGIN:VCALENDAR 4091 METHOD:REPLY 4092 VERSION:2.0 4093 PRODID:-//ABC Corporation//NONSGML My Product//EN 4094 BEGIN:VEVENT 4095 DTSTAMP:19970324T120000Z 4096 SEQUENCE:0 4097 UID:19970324T080045Z-4000F192713-0052@host1.com 4098 ATTENDEE;STATUS=ACCEPTED;EXPECT=REQUEST:jsmith@host1.com 4099 END:VEVENT 4100 END:VCALENDAR 4102 An example of a meeting cancelation: 4104 TO:jsmith@host1.com 4105 FROM:jdoe@host1.com 4106 MIME-VERSION:1.0 4107 MESSAGE-ID: 4108 CONTENT-TYPE:text/calendar;method=cancel 4110 BEGIN:VCALENDAR 4111 METHOD:CANCEL 4112 VERSION:2.0 4113 PRODID:-//ABC Corporation//NONSGML My Product//EN 4114 BEGIN:VEVENT 4115 DTSTAMP:19970324T120000Z 4116 UID:19970324T080045Z-4000F192713-0052@host1.com 4117 END:VEVENT 4118 END:VCALENDAR 4120 14. Full Copyright Statement 4122 "Copyright (C) The Internet Society (date). All Rights Reserved. 4124 This document and translations of it MAY be copied and furnished to 4125 others, and derivative works that comment on or otherwise explain it 4126 or assist in its implmentation MAY be prepared, copied, published and 4127 distributed, in whole or in part, without restriction of any kind, 4128 provided that the above copyright notice and this paragraph are 4129 included on all such copies and derivative works. However, this 4130 document itself MAY not be modified in any way, such as by removing 4131 the copyright notice or references to the Internet Society or other 4132 Internet organizations, except as needed for the purpose of 4133 developing Internet standards in which case the procedures for 4134 copyrights defined in the Internet Standards process MUST be 4135 followed, or as required to translate it into languages other than 4136 English. 4138 The limited permissions granted above are perpetual and will not be 4139 revoked by the Internet Society or its successors or assigns. 4141 This document and the information contained herein is provided on an 4142 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 4143 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 4144 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 4145 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 4146 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.