idnits 2.17.1 draft-ietf-calsch-ical-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. ** Expected the document's filename to be given on the first page, but didn't find any == There are 13 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 68 longer pages, the longest (page 63) being 70 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 4 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-1], [ITIP-2], [ITIP-3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1802: '...egated a request MUST inherit the RSVP...' RFC 2119 keyword, line 2107: '... property SHOULD be included in ever...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 2007 has weird spacing: '...ld this meeti...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (January 1998) is 9591 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: 'ITIP-1' is mentioned on line 220, but not defined == Missing Reference: 'ICSM' is mentioned on line 267, but not defined == Unused Reference: 'ISO 9070' is defined on line 3435, but no explicit reference was found in the text == Unused Reference: 'RFC 1738' is defined on line 3461, but no explicit reference was found in the text == Unused Reference: 'RFC 1872' is defined on line 3467, but no explicit reference was found in the text == Unused Reference: 'VCARD' is defined on line 3489, but no explicit reference was found in the text == Unused Reference: 'XAPIA' is defined on line 3497, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ICMS' -- 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-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITIP-3' -- 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) ** 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: 17 errors (**), 0 flaws (~~), 12 warnings (==), 11 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 July 29, 1997 5 Expires January 1998 7 Internet Calendaring and Scheduling Core Object Specification 8 (iCalendar) 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working 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 document is unlimited. 31 Abstract 33 There is a clear need to provide and deploy interoperable calendaring 34 and scheduling services for the Internet. Current group scheduling 35 and Personal Information Management (PIM) products are being extended 36 for use across the Internet, today, in proprietary ways. This 37 document has been defined to provide the a definition of a common 38 format for openly exchanging calendaring and scheduling information 39 across the Internet. 41 This memo is formatted as a registration for a MIME media type per 42 [RFC 2048]. However, the format in this memo is equally applicable 43 for use outside of a MIME message content type. 45 The proposed media type value is 'TEXT/CALENDAR'. This string would 46 label a media type containing calendaring and scheduling information 47 encoded as text characters formatted in a manner outlined below. 49 This MIME media type provides a standard content type for capturing 50 calendar event and to-do information. It also can be used to convey 51 free/busy time information. The content type is suitable as a MIME 52 message entity that can be transferred over MIME based email systems 53 or using HTTP. In addition, the content type is useful as an object 54 for interactions between desktop applications using the operating 55 system clipboard, drag/drop or file systems capabilities. 57 This document is based on the earlier work of the vCalendar 58 specification for the exchange of personal calendaring and scheduling 59 information. In order to avoid confusion with this referenced work, 60 this document is to be known as the iCalendar specification. This 61 document is based on the calendaring and scheduling model defined in 62 [ICMS]. The document is also the basis for the calendaring and 63 scheduling interoperability protocol defined in [ITIP-1], [ITIP-2] 64 and [ITIP-3]. 66 This document also includes the format for defining content type 67 profiles. A content type profile is a document that defines a set of 68 usage constraints for the iCalendar object. For example, a profile 69 might be defined to specify how the iCalendar object can be used to 70 provide for a set of interpersonal scheduling messages. Such a 71 profile might define scheduling messages that request an event be 72 scheduled, reply to an event request, send a cancellation notice for 73 an event, modify or replace the definition of an event, provide a 74 counter proposal for an original event request, delegate an event 75 request to another individual, request free or busy time, reply to a 76 free or busy time request, or provide similar scheduling messages for 77 a to-do or journal entry calendar component. 79 Table of Contents 81 1. Introduction........................................................5 82 2. Basic Grammar and Conventions.......................................5 83 3. Definitions.........................................................6 84 3.1 Alarm............................................................6 85 3.2 Busy Time........................................................6 86 3.3 Calendar Component...............................................6 87 3.4 Calendar Date....................................................6 88 3.5 Calendar Object..................................................7 89 3.6 Calendar Properties..............................................7 90 3.7 Calendar Scale...................................................7 91 3.8 Component Properties.............................................7 92 3.9 Coordinate Universal Time (UTC)..................................7 93 3.10 Daylight Saving Time (DST)......................................7 94 3.11 Event...........................................................7 95 3.12 Free Time.......................................................7 96 3.13 Gregorian Calendar..............................................8 97 3.14 Journal.........................................................8 98 3.15 Local Time......................................................8 99 3.16 Period..........................................................8 100 3.17 Recurrence Rule.................................................8 101 3.18 Reminder........................................................8 102 3.19 Repeating Event or To-do........................................8 103 3.20 Standard Time...................................................8 104 3.21 Time Zone.......................................................9 105 3.22 To-do...........................................................9 106 4. TEXT/CALENDAR Registration Information..............................9 107 5. iCalendar Object Specification.....................................11 108 5.1 Syntax Considerations...........................................11 109 5.1.1 Content Lines................................................13 110 5.1.2 List and Field Separators....................................14 111 5.1.3 Multiple Values..............................................14 112 5.1.4 Character Set................................................15 113 5.1.5 Language.....................................................15 114 5.1.6 Content Encoding.............................................15 115 5.1.7 Binary Content...............................................15 116 5.1.8 Recurrence Set...............................................15 117 5.1.9 Data Types...................................................16 118 5.2 iCalendar Object................................................21 119 5.3 Property........................................................21 120 5.4 Calendar Components.............................................22 121 5.4.1 Event Component..............................................22 122 5.4.2 To-do Component..............................................23 123 5.4.3 Journal Component............................................23 124 5.4.4 Free/Busy Component..........................................24 125 5.4.5 Alarm Component..............................................25 126 5.4.6 Timezone Component...........................................26 127 5.5 Calendar Properties.............................................30 128 5.5.1 Calendar Scale...............................................30 129 5.5.2 Product Identifier...........................................30 130 5.5.3 Profile......................................................31 131 5.5.4 Profile Version..............................................31 132 5.5.5 Source.......................................................32 133 5.5.6 Source Name..................................................32 134 5.5.7 Version......................................................32 135 5.6 Component Properties............................................33 136 5.6.1 Attachment...................................................33 137 5.6.2 Attendee.....................................................33 138 5.6.3 Categories...................................................36 139 5.6.4 Classification...............................................36 140 5.6.5 Comment......................................................37 141 5.6.6 Date/Time Completed..........................................37 142 5.6.7 Date/Time Created............................................38 143 5.6.8 Date/Time Due................................................38 144 5.6.9 Date/Time End................................................38 145 5.6.10 Date/Time Stamp.............................................39 146 5.6.11 Date/Time Start.............................................39 147 5.6.12 Daylight....................................................40 148 5.6.13 Description.................................................40 149 5.6.14 Duration....................................................41 150 5.6.15 Exception Date/Times........................................41 151 5.6.16 Exception Rule..............................................42 152 5.6.17 Free/Busy Time..............................................42 153 5.6.18 Geographic Position.........................................43 154 5.6.19 Last Modified...............................................44 155 5.6.20 Location....................................................44 156 5.6.21 Priority....................................................45 157 5.6.22 Recurrence Date/Times.......................................45 158 5.6.23 Recurrence ID...............................................46 159 5.6.24 Recurrence Rule.............................................46 160 5.6.25 Related To..................................................52 161 5.6.26 Repeat Count................................................53 162 5.6.27 Request Status..............................................53 163 5.6.28 Resources...................................................55 164 5.6.29 Response Sequence Number....................................56 165 5.6.30 Sequence Number.............................................56 166 5.6.31 Status......................................................57 167 5.6.32 Summary.....................................................57 168 5.6.33 Time Transparency...........................................58 169 5.6.34 Time Zone Name..............................................58 170 5.6.35 Time Zone Offset............................................59 171 5.6.36 Uniform Resource Locator....................................59 172 5.6.37 Unique Identifier...........................................59 173 5.6.38 Non-standard Properties.....................................60 174 6. Recommended Practices..............................................60 175 7. Registration of Content Type Elements..............................61 176 7.1 Registration of New and ModifiedProfiles........................61 177 7.2 Registration of New Properties..................................61 178 7.2.1 Define the property..........................................61 179 7.2.2 Post the Property definition.................................62 180 7.2.3 Allow a comment period.......................................62 181 7.2.4 Submit the property for approval.............................62 182 7.3 Property Change Control.........................................63 183 8. File extension.....................................................63 184 9. Macintosh File Type Code...........................................63 185 10. References........................................................63 186 11. Acknowledgments...................................................65 187 12. Author's Address..................................................65 188 13. iCalendar Object Examples.........................................66 189 1. Introduction 191 The use of calendaring and scheduling has grown considerably in the 192 last decade. Enterprise and inter-enterprise business has become 193 dependent on rapid scheduling of events and actions using this 194 information technology. However, the longer term growth of 195 calendaring and scheduling, is currently limited by the lack of 196 Internet standards for the message content types that are central to 197 these groupware applications. This specification is intended to 198 progress the level of interoperability possible between dissimilar 199 calendaring and scheduling applications. This specification defines a 200 MIME content type for exchanging electronic calendaring and 201 scheduling information. The Internet Calendaring and Scheduling Core 202 Object Specification, or iCalendar, allows for the capture and 203 exchange of information normally stored within a calendaring and 204 scheduling application; such as a Personal Information Manager or a 205 Group Scheduling product. 207 The calendaring and scheduling model implemented by this 208 specification is defined in the [ICMS]. 210 The format is suitable as an exchange format between applications or 211 systems. The format is defined in terms of a MIME content type. This 212 will enable the object to be exchanged using several transports, 213 including but not limited to SMTP, HTTP, a file system, desktop 214 interactive protocols such as the use of a memory-based clipboard or 215 drag/drop interactions, point-to-point asynchronous communication, 216 wired-network transport, or some form of unwired transport such as 217 infrared might also be used. 219 The definition of a calendaring and scheduling interoperability 220 protocol is the subject of another specification [ITIP-1], [ITIP-2] 221 and [ITIP-3]. 223 The specification also provides for the definition of usage profiles 224 that will map this content type to a set of messages for supporting 225 calendaring and scheduling operations such as requesting, replying 226 to, modifying, and canceling meetings or appointments, to-dos and 227 journal entries. The usage profiles can be used to define other 228 calendaring and scheduling operations such a requesting for and 229 replying with free/busy time data. 231 The specification also includes a formal grammar for the content type 232 to aid in the implementation of parsers and to serve as the 233 definitive reference when ambiguities or questions arise in 234 interpreting the descriptive prose definition of the specification. 236 2. Basic Grammar and Conventions 238 This document makes use of both a descriptive prose and a more formal 239 notation for defining the calendaring and scheduling format. 241 The notation used in this document is the augmented BNF notation of 242 [RFC 822]. Readers intending on implementing this format defined in 243 this document should be familiar with this notation in order to 244 properly interpret the specifications of this document. 246 All numeric and hexadecimal values used in this document are given in 247 decimal notation. All names of properties, property parameters, 248 enumerated property values and property parameter values are case- 249 insensitive. However, all other property values are case-sensitive, 250 unless otherwise stated. 252 Note: All indented editorial notes, such as this one, are 253 intended to provide the reader with additional information that 254 is not essential to the building of a conformant implementation 255 of the specifications of this document. The information is 256 provided to highlight a particular feature or characteristic of 257 the specifications. 259 The format for the iCalendar object is based on the syntax of the 260 [MIME DIR] content type. While the iCalendar object is not a profile 261 of the [MIME DIR] content type, it does reuse a number of the 262 elements from the [MIME DIR] specification. 264 3. Definitions 266 EDITORS' NOTE: This section may be removed if this text is added to 267 the [ICSM]. 269 Date and time, as well as, calendaring and scheduling terminology are 270 used in every day conversations. However, there are precise 271 definitions of many of these terms that are used by this memo. 273 3.1 Alarm 275 Also called a reminder. An activity that is an asynchronous mechanism 276 for providing feedback for a pending or past event or to-do. 278 3.2 Busy Time 280 A period of time on a calendar where there is already scheduled one 281 or more events or that is otherwise not available for scheduling. 283 3.3 Calendar Component 285 One of a number of entities that may be found within a calendar 286 object. In particular, a calendar may be composed of calendar 287 properties and event, to-do, journal, free/busy, time zone or alarm 288 calendar components. Calendar components are identified by unique 289 delimiters within a calendar object. Calendar components provide an 290 organized collection of component properties. 292 3.4 Calendar Date 294 A particular day of a calendar year identified by its position within 295 the year. 297 3.5 Calendar Object 299 An entity consisting of an organized collection of calendar 300 properties and calendar components. The calendar object is identified 301 by unique delimiters. 303 3.6 Calendar Properties 305 Attributes that apply to the calendar object as a whole. For example, 306 the iCalendar version used to format the calendar object, an 307 identifier of the product that created the calendar object, the 308 calendar scale used to represent the calendar information and time 309 zone information. 311 3.7 Calendar Scale 313 The particular type of calendar in general use. For example, 314 Gregorian, Buddhist Era, Japanese Emperor Era, Chinese Lunar, 315 Islamic, and Jewish Calendars. 317 3.8 Component Properties 319 Attributes that can only appear within one or more calendar 320 components. For example, the due date can only appear within a to-do 321 calendar component. The start date and time applies to both the event 322 and the to-do component. 324 3.9 Coordinate Universal Time (UTC) 326 The time scale maintained by the Bureau International de l�Heure 327 (International Time Bureau) that forms the basis of a coordinated 328 dissemination of standard frequencies and time signals. UTC is often 329 incorrectly referred to as GMT. 331 3.10 Daylight Saving Time (DST) 333 An adjustment to local to accommodate annual changes in the number of 334 daylight hours. DST is also known as Advanced Time, Summer Time, or 335 Legal Time. Daylight saving time adjustments in the southern 336 hemisphere are opposite to those in the northern hemisphere. 338 3.11 Event 340 A calendar component that defines a scheduled activity, minimally 341 specified by a start and end calendar date and time of day and a 342 description. 344 3.12 Free Time 346 A period of time available on a calendar. 348 3.13 Gregorian Calendar 350 A calendar scale in general use beginning in 1582. It was introduced 351 to correct an error in the Julian Calendar scale. The Gregorian 352 Calendar scale is based on a solar calendar consisting of common 353 years made up of 365 days and leap years made up of 366 days; both 354 divided into 12 sequential months. 356 Note: Initially, this memo addresses specification of calendar 357 information in terms of the Gregorian calendar scale. 359 3.14 Journal 361 A calendar component that defines a collection of information 362 intended for human presentation and is minimally specified by a 363 calendar date and one or more descriptions. 365 3.15 Local Time 367 The clock time in public use in a locale. Local time is often 368 referenced by the customary name for the time zone in which it is 369 located. The relationship between local time and UTC is based on the 370 offset that is in use for a particular time zone. In general, the 371 formula is as follows: 373 local time = UTC + (offset) 375 3.16 Period 377 A duration of time, specified as either a defined length of time or 378 by its beginning and end points. 380 3.17 Recurrence Rule 382 A notation used to represent repeating occurrences, or the exceptions 383 to such a repetition of an event or a to-do. The recurrence rule can 384 also be used in the specification of a time zone description. This 385 document defines a particular notation used in recurrence rules 386 within this specification. 388 3.18 Reminder 390 See Alarm. 392 3.19 Repeating Event or To-do 394 An event or to-do that repeats for one or more additional 395 occurrences. The recurrence may be defined with discrete dates and 396 times and/or with a recurrence rule. 398 3.20 Standard Time 400 Introduced by Sir Sanford Fleming and others around 1870, standard 401 time is a scheme for dividing the world into zones where the same 402 time would be kept. The original proposal was to divide the world 403 into 24 zones, each zone having a width of 15 degrees of longitude. 404 The center zone was originally the meridian passing through 405 Greenwich, England, called Greenwich Mean Time (GMT). The time in the 406 zones was decremented by one hour per zone going westwards and was 407 incremented by one hour per zone going eastwards from GMT. Changes 408 have been made to the original proposal to accommodate political 409 boundaries. In addition, some countries and regions specify 30 or 45 410 minute offsets, rather than the full 60 minute offset. Standard time 411 is also known as Winter Time in some regions. 413 GMT and UTC are generally equivalent. However, by international 414 agreement, the GMT term is discouraged in favor of the term UTC for 415 all general time keeping. 417 3.21 Time Zone 419 The particular time zone that time in a particular location is 420 expressed in. A time zone is unambiguously defined by the set of time 421 measurement rules determined by the governing body for the given 422 location. These rules describe at a minimum the base offset from UTC, 423 often referred to as the Standard Time offset. Optionally, if 424 Daylight Savings Time is observed, the rules will specify the 425 Daylight Savings Time offset and either a set of rules describing the 426 transition to and from Daylight Savings Time or absolute dates 427 describing the movement in and out of Daylight Savings Time. It is 428 important to note that these rules are not static. Time zones may 429 also have a local customary name. However, not all time zones have a 430 special name for their time. The customary names for time zones are 431 often abbreviated. However, not all time zone abbreviations are 432 unique. For example, AST may mean Atlantic Standard Time, Alaska 433 Standard Time, and even Aleutian Standard Time. Each of these are 434 different offsets from UTC. Nevertheless, customary names for time 435 zones are in use in various parts of the world. 437 3.22 To-do 439 A calendar component that defines an action item and is minimally 440 specified by an effective calendar date and time of day, a due 441 calendar date and time of day, a priority and a description. 443 4. TEXT/CALENDAR Registration Information 445 The Calendaring and Scheduling Core Object Specification is intended 446 for use as a MIME content type. However, the implementation of the 447 specification is in no way limited solely as a MIME content type. 449 The following text is intended to register this specification as the 450 MIME content type "text/calendar". 452 To: ietf-types@uninett.no 454 Subject: Registration of MIME content type text/calendar. 456 MIME media type name: text 458 MIME subtype name: calendar 459 Required parameters: profile 461 The "profile" parameter is used to convey the scheduling usage to 462 which the calendaring and scheduling information pertains. It also 463 is an identifier for the set of properties that the iCalendar 464 object will consist of. The parameter is intended to be used as a 465 guide to applications interpreting the information contained within 466 the body part. It should NOT be used to exclude or require 467 particular pieces of information unless the identified profile 468 definition specifically calls for this behavior. Unless 469 specifically forbidden by a particular profile definition, a 470 text/calendar content type may contain any set of properties 471 permitted by the Calendaring and Scheduling Core Object 472 Specification. 474 The value for the "profile" parameter is defined as follows: 476 profile = component "-" usage 478 component = "EVENT" / "event" / "TODO" / "todo" 479 / "JOURNAL" / "journal" / "FREEBUSY" 480 / "freebusy" / x-token / iana-comp 482 usage = "REQUEST" / "request" / "REPLY" / "reply" 483 / "CANCEL" / "cancel" / x-token / iana-usage 485 x-token = 489 iana-comp = 493 iana-usage = 497 Optional parameters: charset 499 The "charset" parameter is defined in [RFC 2046] for other body 500 parts. It is used to identify the default character set used within 501 the body part. 503 Optional content header fields: Any header fields defined by [RFC 504 2045]. 506 Encoding considerations: This MIME content type can contain 8bit 507 characters, so the use of quoted-printable or base64 MIME content- 508 transfer-encodings may be necessary when iCalendar objects are 509 transferrred across protocols restricted to the 7bit repertoire. 510 Note that each property in the content entity may also have an 511 inline encoding for the body part as a whole (i.e., inline encoding 512 is performed first, then Content-Transfer-Encoding is applied to 513 the entire body part). This means that content values may end up 514 encoded twice. 516 Security considerations: The calendaring and scheduling information 517 based on this MIME content type may include references to Uniform 518 Resource Locators that may be programmed resources. In addition, 519 this information may contain direct references to executable 520 programs intended to be used as procedure-based alarms for an event 521 or to-do. Implementers and users of this specification should be 522 aware of the network security implications of accepting and parsing 523 such information. In addition, the security considerations observed 524 by implementations of electronic mail systems should be followed 525 for this specification. 527 Interoperability considerations: This MIME content type is intended 528 to provide interoperability between calendaring and scheduling 529 products. It is heavily based on the earlier [VCAL] industry 530 specification. 532 Intended Usage: COMMON 534 Published specification: This document. 536 Author/Change controllers: 538 Frank Dawson 539 6544 Battleford Drive 540 Raleigh, NC 27613-3502 541 919-676-9515 (Telephone) 542 919-676-9564 (Facsimile) 543 fdawson@earthlink.net (Internet Mail) 545 Derik Stenerson 546 One Microsoft Way 547 Redmond, WA 98052-6399 548 206-936-5522 (Telephone) 549 206-936-7329 (Facsimile) 550 deriks@microsoft.com (Internet Mail) 552 5. iCalendar Object Specification 554 The following sections define the details of a Calendaring and 555 Scheduling Core Object Specification. This information is intended to 556 be an integral part of the MIME content type registration. In 557 addition, this information may be used independent of such content 558 registration. In particular, this specification has direct 559 applicability for use as a calendaring and scheduling exchange format 560 in file-, memory- or network-based transport mechanisms. 562 5.1 Syntax Considerations 564 The content information associated with an iCalendar object is 565 formatted using a syntax similar to that defined by [MIME DIR]. That 566 is, the content information consists of one or more CRLF-separated 567 lines in the following format: 569 contentline = name [";" paramlist] ":" value CRLF 570 ;Folding permitted on content lines. 572 LWSP = SPACE / HTAB 574 SPACE = 576 HTAB = 578 name = x-name / iana-name ;An iCalendar attribute/property 580 x-name = 583 iana-name = 585 paramlist = parameter / paramlist ";" parameter 587 parameter = encodingparm 588 / valuetypeparm ;If not present => inline value 589 / languageparm 590 / [parmtype "="] parmvalues 592 encodingparm = "encoding" "=" encodetype 594 encodetype = "8bit" ;From [RFC 2045] 595 / "7bit" ;From [RFC 2045] 596 / "q" ;From [RFC 2045] 597 / "b" ;From [RFC 2045] 599 valuetypeparm = "value" "=" valuetype 601 valuetype = "url" 602 / "text" 603 / "date" 604 / "time" 605 / "date-time" 606 / "period" 607 / "duration" 608 / "boolean" 609 / "integer" 610 / "float" 611 / "cal-address" 612 / "utc-offset" 613 / x-token 614 / iana-value 616 iana-value = 619 languageparm = "language" "=" language 620 ;As defined in [RFC 1766] 622 parmtype = x-token / iana-ptype 624 iana-ptype = 627 parmvalues = parmvalue / parmvalues "," parmvalue 628 parmvalue = x-name / iana-pvalue 630 iana-pvalue = 633 value = url / text / date / time / date-time / period / 634 / duration / boolean / integer / float / cal-address 635 / utc-offset / x-token / iana-value 637 iana-value = 640 5.1.1 Content Lines 642 Individual lines within the iCalendar object are delimited by a line 643 break, which is a CRLF sequence (ASCII decimal 13, followed by ASCII 644 decimal 10). Line should not be longer than 76 characters, excluding 645 the line break. 647 Long lines of text can be split into a multiple-line representations 648 using a line "folding" technique. That is, a long line may be split 649 at any point by inserting a CRLF immediately followed by a single 650 LWSP character (i.e., SPACE, ASCII decimal 32 or HTAB, ASCII decimal 651 9). Any sequence of CRLF followed immediately by a single LWSP 652 character is ignored (i.e., removed) when processing the content 653 type. 655 For example the line: 657 DESCRIPTION:This is a long description that exists on a long line. 659 Can be represented as: 661 DESCRIPTION:This is a long description 662 that exists on a long line. 664 The process of moving from this folded multiple-line representation 665 to its single line representation is called "unfolding". Unfolding is 666 accomplished by removing the CRLF character and the LWSP character 667 that immediately follows. 669 An intentional formatted text line break in a property value must 670 also be specified by a (RFC 822) line break, which is a CRLF 671 sequence. However, since the CRLF sequence is used to delimit a line, 672 property values with imbedded formatted line breaks (i.e., hard line 673 breaks) must be encoded using an alternate encoding of either the "Q" 674 or "B" encodings, as defined in [RFC 2047]. These encodings are used 675 directly and without any of the additional syntax elements of [RFC 676 2047] encoded-words. 678 Since neither the "Q" nor the "B" encodings ever produce LWSP 679 characters (note that the "Q" encoding turns spaces into 680 underscores), or CRLF character sequences as output, LWSP characters 681 and CRLF character sequences can be freely inserted into encoded 682 material at any point to fold encoded field values. All LWSP 683 characters and CRLF character sequences should be ignored when 684 decoding an encoded field value. The "Q" encoding of multiple lines 685 of formatted text are separated with a Q CRLF sequence of "=0D=0A". 686 The length restrictions [RFC 2047] imposes on encoded-words do not 687 apply in this context, but fields encoded with the "Q" or "B" 688 encodings must be folded into lines of no longer than 76 characters. 690 For example a multiple line DESCRIPTION property value of: 692 Project XYZ Final Review 693 Conference Room - 3B 694 Come Prepared. 696 Could be represented in "Q" encoding as: 698 DESCRIPTION;ENCODING=Q:Project_XYZ 699 _Final_Review=0D=0A 700 Conference_Room_-_3B=0D=0A 701 Come_Prepared. 703 And in the "B" encoding as: 705 DESCRIPTION;ENCODING=UHJvamVjdCBYWVogRmluYWw 706 gUmV2aWV3DQpDb25mZXJIbm NIIFJvb20gLSAzQg0KQ29tZ 707 SBQcmVwYXJIZC4NCg = = 709 5.1.2 List and Field Separators 711 Where a property parameter value consists of a list of values, each 712 value must be separated by a COMMA character (ASCII decimal 44). A 713 COMMA character in a property parameter value must be escaped with a 714 BACKSLASH character (ASCII decimal 92). 716 Structured property values must have their components separated by a 717 SEMICOLON character (ASCII decimal 59). In addition, lists of 718 property parameters must be separated by a SEMICOLON character (ASCII 719 decimal 59). A SEMICOLON character in a property value or property 720 parameter value must be escaped with a BACKSLASH character (ASCII 721 decimal 92). 723 For example, in the following properties a SEMICOLON is used to 724 separate property parameters and property value fields. A COMMA is 725 used to separate values. 727 ATTENDEE;RSVP=TRUE;ROLE=ATTENDEE:"J.Smith" 760 character (ASCII decimal 10) or character (ASCII decimal 13), it 761 must be encoded using either "Q" or "B" encoding, since is 762 used to separate lines in the iCalendar object itself. 764 5.1.7 Binary Content 766 There is no support for inline encoding of binary information in an 767 iCalendar object. Binary information is associated with the iCalendar 768 object through the use of a uniform resource locator (URL) reference 769 to the binary information. 771 5.1.8 Recurrence Set 773 Recurring events and to-dos are supported by this specification. The 774 recurrence within the iCalendar object may be specified as either a 775 list of discrete date and time values or as a recurrence rule. The 776 full recurrence set is generated by considering the initial DTSTART 777 along with the RRULE, RDATE, EXDATE and EXRULE properties contained 778 within the iCalendar object. The DTSTART defines the first instance 779 in the recurrence set. Multiple instances of the RRULE and EXRULE 780 properties may also be specified to define more sophisticated 781 recurrence sets. The final recurrence set is generated by gathering 782 all of the start date-times generated by any of the specified RRULE 783 and RDATE properties, and excluding any start date and times which 784 fall within the union of start date and times generated by any 785 specified EXRULE and EXDATE properties. This implies that start date 786 and times within exclusion related properties (i.e., EXDATE and 787 EXRULE) take precedence over those specified by inclusion properties 788 (i.e., RDATE and RRULE). Where duplicate instances are generated by 789 the RRULE and RDATE specification, only one recurrence is considered. 790 Duplicate instances are ignored. 792 The recurrence rule used in the iCalendar object is defined in the 793 RRULE component property. 795 5.1.9 Data Types 797 The "value" property parameter is an optional property parameter. It 798 is used to identify the data type and format of the property value. 799 The values of a given instance of a property must only be of a single 800 data type. For example, a RDATE property can not have a combination 801 of DATE-TIME and TIME values. The following data types are used by 802 the iCalendar object. 804 5.1.9.1 Boolean 806 The "boolean" data type is used to identify properties that contain 807 either a "true" or a "false" boolean value. These values are case 808 insensitive. The data type is defined by the following notation: 810 boolean = "TRUE" / "FALSE" 812 For example, any of the following are equivalent: 814 TRUE 815 true 816 TrUe 818 5.1.9.2 Calendar User Address 820 The "cal-address" data type is used to identify properties that 821 contain an address of a calendar user. The phrase component of the 822 address may be used to match an unknown address with an otherwise 823 known individual, group, or resource. The data type is as defined by 824 the following notation: 826 cal-address = addr-spec / [phrase] "<" addr-spec ">" 828 addr-spec = local-part "@" domain ;RFC 822 style address 829 local-part = WORD *("." WORD) 830 domain = domain-ref *("." domain-ref) 831 domain-ref = ATOM 833 phrase = 1*WORD 834 WORD = ATOM / quoted-string 835 quoted-string = <"> *(qtext/quoted-pair) <"> ; Regular qtext or 836 ; quoted chars. 837 qtext = , ; => may be folded 838 "\" & CR, and including linear-white-space> 839 quoted-pair ="\" CHAR ; may quote any char 840 CHAR = 841 ATOM = 1* 843 5.1.9.3 Date 845 The "date" data type is used to identify values that contain a 846 calendar date. The format is expressed as the [ISO 8601] complete 847 representation, basic format for a calendar date. The text format 848 specifies a four-digit year, two-digit month, and two-digit day of 849 the month. There are no separator characters between the year, month 850 and day component text. The data type is defined by the following 851 notation: 853 DIGIT = ;0-9 855 date-fullyear = 4DIGIT 856 date-month = 2DIGIT ;01-12 857 date-mday = 2DIGIT ;01-28, 01-29, 01-30, 01-31 858 ;based on month/year 860 date = date-fullyear date-month date-mday 862 For example, the following represents July 14, 1997: 864 19970714 866 5.1.9.4 Date-Time 868 The "date-time" data type is used to identify values that contain a 869 precise calendar date and time of day. The format is expressed as the 870 [ISO 8601] complete representation, basic format for a calendar date 871 and time of day. The text format is a concatenation of the "date", 872 followed by the LATIN CAPITAL LETTER T character (ASCII decimal 84) 873 time designator, followed by the "time" format defined above. The 874 data type is defined by the following notation: 876 date-time = date "T" time ;As specified above in date and time 878 The following represents July 14, 1997, at 1:30 PM in UTC and the 879 equivalent time in New York (five hours behind UTC), expressed as a 880 local time and local time with UTC offset: 882 19970714T133000Z 883 19970714T083000 884 19970714T083000-0500 886 5.1.9.5 Duration 888 The "duration" data type is used to identify properties that contain 889 a duration of time. The format is expressed as the [ISO 8601] basic 890 format for the duration of time. The format can represent durations 891 in terms of years, months, days, hours, minutes, and seconds. The 892 data type is defined by the following notation: 894 DIGIT = ;0-9 896 dur-second = 1*DIGIT "S" 897 dur-minute = 1*DIGIT "M" [dur-second] 898 dur-hour = 1*DIGIT "H" [dur-minute] 899 dur-time = "T" (dur-hour / dur-minute / dur-second) 901 dur-week = 1*DIGIT "W" 902 dur-day = 1*DIGIT "D" 903 dur-month = 1*DIGIT "M" [dur-day] 904 dur-year = 1*DIGIT "Y" [dur-month] 905 dur-date = (dur-day / dur-month / dur-year) [dur-time] 906 duration = "P" (dur-date / dur-time / dur-week) 908 For example, a duration of 10 years, 3 months, 15 days, 5 hours, 30 909 minutes and 20 seconds would be: 911 P10Y3M15DT5H30M20S 913 5.1.9.6 Float 915 The "float" data type is used to identify properties that contain a 916 real value number value. If the property permits, multiple "float" 917 values may be specified using a COMMA character (ASCII decimal 44) 918 separator character. The data type is defined by the following 919 notation: 921 DIGIT = ;0-9 923 float = ["+" / "-"] *DIGIT ["." *DIGIT] 925 For example: 927 1000000.0000001 928 1.333 929 -3.14 931 5.1.9.7 Integer 933 The "integer" data type is used to identify properties that contain a 934 signed integer value. The valid range for "integer" is -2147483648 to 935 2147483647. If the sign is not specified, then the value is assumed 936 to be positive. If the property permits, multiple "integer" values 937 may be specified using a COMMA character (ASCII decimal 44) separator 938 character. The data type is defined by the following notation: 940 DIGIT = ;0-9 942 integer = ["+" / "-"] *DIGIT 944 For example: 946 1234567890 947 -1234567890 948 +1234567890 949 432109876 951 5.1.9.8 Period of Time 953 The "period" data type is used to identify values that contain a 954 precise period of time. There are two forms of a period of time. 956 A period of time may be identified by it start and its end. This 957 format is expressed as the [ISO 8601] complete representation, basic 958 format for "date-time" start of the period, followed by a SOLIDUS 959 character (ASCII decimal 47), followed by the "date-time" of the end 960 of the period. For example, the period starting at 10 AM in Seattle 961 (eight hours behind UTC) on January 1, 1997 and ending at 11 PM in 962 Seattle on January 1, 1997 would be: 964 19970101T100000-0800/19970101T230000-0800 966 A period of time may also be defined by a start and a duration of 967 time. The format is expressed as the [ISO 8601] complete 968 representation, basic format for the "date-time" start of the period, 969 followed by a SOLIDUS character (ASCII decimal 47), followed by the 970 [ISO 8601] basic format for "duration" of the period. For example, 971 the period start at 10 AM in Seattle (eight hours behind UTC) on 972 January 1, 1997 and lasting 5 hours and 30 minutes would be: 974 19970101T100000-0800/P5H30M 976 The data type is defined by the following notation: 978 period-explicit = date-time "/" date-time 979 ;ISO 8601 complete representation basic format for a period of time 980 ;consisting of a start and end. The start must be before the end. 982 period-start = date-time "/" duration 983 ;ISO 8601 complete representation basic format for a period of time 984 ;consisting of a start and duration of time. 986 period = period-explicit / period-start 988 5.1.9.9 Text 990 The "text" data type is used to identify values that contain human 991 readable text. The character set and language in which the text is 992 represented is controlled by the charset and language property 993 parameters. The data type is defined by the following notation: 995 CHAR = 997 5.1.9.10 Time 999 The "time" data type is used to identify values that contain a time 1000 of day. The format is expressed as the [ISO 8601] complete 1001 representation, basic format for a time of day. The text format 1002 consists of a two-digit 24-hour of the day (i.e., values 0-23), two- 1003 digit minute in the hour (i.e., values 0-59), and two-digit seconds 1004 in the minute (i.e., values 0-59). If seconds of the minute are not 1005 supported by an implementation, then a value of "00" should be 1006 specified for the seconds component. Fractions of an hour, minute or 1007 second are not supported by this format. This format is used to 1008 represent local time, local time with UTC offset and UTC time. UTC 1009 time is identified by a LATIN CAPITAL LETTER Z suffix character 1010 (ASCII decimal 90), the UTC designator, appended to the time. The 1011 local time with UTC offset is expressed as a local time, suffixed 1012 with the signed offset from UTC. The UTC offset is express as the 2- 1013 digit hours and 2-digit minutes difference from UTC. It is expressed 1014 as positive, with an optional leading PLUS SIGN character (ASCII 1015 decimal 43), if the local time is ahead of UTC. It is expressed as a 1016 negative, with a leading HYPEN-MINUS character (ASCII decimal 45), if 1017 the local time is behind UTC. Local time has neither the UTC 1018 designator nor the UTC offset suffix text. The data type is defined 1019 by the following notation: 1021 DIGIT = ;0-9 1023 time-hour = 2DIGIT ;00-23 1024 time-minute = 2DIGIT ;00-59 1025 time-second = 2DIGIT ;00-59 1026 time-numzone = ("+" / "-") time-hour time-minute 1027 time-zone = "Z" / time-numzone 1029 time = time-hour time-minute time-second [time-zone] 1031 For example, the following represents 8:30 AM in New York, five hours 1032 behind UTC, in local time and local time with UTC offset. In 1033 addition, 1:30 PM in UTC is illustrated: 1035 083000 1036 083000-0500 1037 133000Z 1039 There are cases when a floating time is intended within a property 1040 value. For example, an event may be defined that indicates that an 1041 individual will be busy from 11:00 AM to 1:00 PM every day. In these 1042 cases, a local time may be specified. The recipient of an iCalendar 1043 object with a property value consisting of a local time, without any 1044 relative time zone information, should interpret the value as being 1045 fixed to the recipient's locale and time zone. In most cases, a fixed 1046 time is desired. To properly communicate a fixed time in a property 1047 value, either UTC, local time with UTC offset, or local time with a 1048 time zone calendar component must be specified. 1050 5.1.9.11 URL 1052 The "url" data type is used to identify values that contain a uniform 1053 resource locator (URL) type of reference to the property value. This 1054 data type might be used to reference binary information, for values 1055 that are large, or otherwise undesirable to include directly in the 1056 iCalendar object. 1058 The URL value formats in RFC 1738, RFC 2111 and any other IETF 1059 registered value format may be specified. 1061 The data type is defined by the following notation: 1063 url = 1065 Any IANA registered URL type may be used. These include, but are not 1066 limited to, those for FTP and HTTP protocols, file access, content 1067 identifier and message identifier. 1069 For example, the following is an URL for a local file: 1071 file:///my-report.txt 1072 text = 1075 5.1.9.12 UTC Offset 1077 The "utc -offset" data type is used to identify properties that 1078 contain an offset from UTC to local time. The data type is defined by 1079 the following notation: 1081 utc-offset = time-numzone ;As defined above in time data type 1083 For example, the following are UTC offsets for New York (five hours 1084 behind UTC) and Geneva (one hour ahead of UTC): 1086 -0500 ;New York 1087 +0100 ;Geneva 1089 5.2 iCalendar Object 1091 The Calendaring and Scheduling Core Object is a collection of 1092 calendaring and scheduling information. Typically, this information 1093 will consist of a single iCalendar object. However, multiple 1094 iCalendar objects may be sequentially, grouped together. The first 1095 line and last line of the iCalendar object must contain a pair of 1096 iCalendar object delimiter strings. The syntax for an iCalendar 1097 object is as follows: 1099 icalobject = "BEGIN" ":" "VCALENDAR" CRLF 1100 icalbody 1101 "END" ":" "VCALENDAR" CRLF [icalobject] 1103 The following is a simple example of an iCalendar object: 1105 BEGIN:VCALENDAR 1106 VERSION:2.0 1107 PRODID:-//hacksw/handcal//NONSGML v1.0//EN 1108 BEGIN:VEVENT 1109 DTSTART:19970714T120000-0500 1110 DTEND:19970714T235959-0500 1111 DESCRIPTION:Bastille Day Party 1112 END:VEVENT 1113 END:VCALENDAR 1115 5.3 Property 1117 A property is the definition of an individual attribute describing a 1118 calendar property or a calendar component. A property takes the 1119 following form: 1121 property = propname [";" parmlist] ":" value CRLF 1123 propname = 1124 / iana-prop / x-token 1126 x-token = 1128 iana-prop = 1131 The following is an example of a property: 1133 DTSTART:19960415T083000-05:00 1135 This document places no imposed ordering of properties within an 1136 iCalendar object. 1138 Property names, parameter names and parameter values (i.e., 1139 everything to the left of the ":" on a line) are case insensitive. 1140 For example, the property name "DUE" is the same as "due" and "Due". 1142 5.4 Calendar Components 1144 The body of the iCalendar object consists of a sequence of calendar 1145 properties and one or more calendar components. The calendar 1146 properties are attributes that apply to the calendar as a whole. The 1147 calendar components are collections of properties that with a 1148 particular calendar semantic. For example, the calendar component may 1149 specify a an event, a to-do, journal entry, time zone information, or 1150 free/busy time information, or alarm. 1152 The body of the iCalenar Object is defined by the following notation: 1154 icalbody = calprops 1*component 1156 calprops = [calscale] prodid [profile] [profile-version] 1157 [source] [name] version 1159 component = 1*(eventc / todoc / journalc / freebusyc / 1160 / timezonec) 1162 5.4.1 Event Component 1164 An Event Calendar Component is a grouping of component properties and 1165 an optional alarm calendar component that represent a scheduled 1166 amount of time on a calendar. For example, it may be an activity; 1167 such as a one-hour, department meeting from 8:00 AM to 9:00 AM, 1168 tomorrow. 1170 An Event Component is defined by the following notation: 1172 eventc = "BEGIN" ":" "VEVENT" CRLF 1173 *eventprop *alarmc 1174 "END" ":" "VEVENT" CRLF 1176 eventprop = *attach *attendee *categories [class] [created] 1177 description [dtend] dtstart *exdate *exrule 1178 [geo] *last-mod [location] [priority] [rstatus] 1179 *related *resources *rdate *rrule dtstamp 1180 [resp-seq] [seq] [status] [summary] [transp] 1181 uid *url [recurid] *(comment) 1182 The Event Component can not be nested within another Calendar 1183 Component. Event components may be related to each other or to a To- 1184 do or Journal Calendar Component with the RELATED-TO property. 1186 The following is an example of the Event Calendar Component: 1188 BEGIN:VEVENT 1189 DTSTART:19970903T083000-0800 1190 DTEND:19970903T110000-0800 1191 DESCRIPTION:Annual Employee Review 1192 CLASS:PRIVATE 1193 CATEGORIES:BUSINESS,HUMAN RESOURCES 1194 END:VEVENT 1196 5.4.2 To-do Component 1198 A To-do Calendar Component is a grouping of component properties and 1199 an optional alarm calendar component that represent an action-item or 1200 assignment. For example, it may be an item of work assigned to an 1201 individual; such as "turn in travel expense today". 1203 A To-do Component is defined by the following notation: 1205 todoc = "BEGIN" ":" "VTODO" CRLF 1206 *todoprop *alarmc 1207 "END" ":" "VTODO" CRLF 1209 todoprop = *attach *attendee *categories [class] [completed] 1210 [created] description dtstamp dtstart due *exdate 1211 *exrule [geo] *last-mod [location] priority [rstatus] 1212 *related *resources *rdate *rrule [resp-seq] [recurid] 1213 [seq] [status] [summary] [transp] uid *url *(comment) 1215 The To-do Component can not be nested within another Calendar 1216 Component. If To-do components need to be related to each other or to 1217 an Event or Journal Calendar Component, they can specify a 1218 relationship with the RELATED-TO property. 1220 The following is an example of a To-do Calendar Component: 1222 BEGIN:VTODO 1223 DTSTART:19970415T083000-0500 1224 DUE:19970415T235959-0500 1225 DESCRIPTION:1996 Income Tax Preparation 1226 CLASS:CONFIDENTIAL 1227 CATEGORIES:FAMILY,FINANCE 1228 PRIORITY:1 1229 STATUS:NEEDS ACTION 1230 END:VEVENT 1232 5.4.3 Journal Component 1234 A Journal Calendar Component is a grouping of component properties 1235 that represent one or more descriptive text on a particular calendar 1236 date. For example, it may be a journal entry of individual telephone 1237 contacts for the day or an ordered list of accomplishments for the 1238 day. 1240 A Journal Component is defined by the following notation: 1242 journalc = "BEGIN" ":" "VJOURNAL" CRLF 1243 *jourprop 1244 "END" ":" "VJOURNAL" CRLF 1246 jourprop = *attach *attendee *categories [class] [created] 1247 description dtstart dtstamp *last-mod *related 1248 [rdate] [rrule] [rstatus] [resp-seq] [seq] uid *url 1249 [recurid] *(comment) 1251 The Journal Component can not be nested within another Calendar 1252 Component. If Journal Components need to be related to each other or 1253 to an Event or To-Do Calendar Component, they can specify a 1254 relationship with the RELATED-TO property. 1256 The following is an example of the Journal Calendar Component: 1258 BEGIN:VJOURNAL 1259 DTSTART:19970317T083000 1260 DESCRIPTION:1. Staff meeting: Participants include Joe, Lisa 1261 and Bob. Aurora project plans were reviewed. There is currently 1262 no budget reserves for this project. Lisa will escalate to 1263 management. Next meeting on Tuesday. 1264 2. Telephone Conference: ABC Corp. sales representative called 1265 to discuss new printer. Promised to get us a demo by Friday. 1266 3. Henry Miller (Handsoff Insurance): Car was totaled by tree. 1267 Is looking into a loaner car. 654-2323 (tel). 1268 END:VJOURNAL 1270 5.4.4 Free/Busy Component 1272 A Free/Busy Calendar Component is a grouping of component properties 1273 that represent free or busy time information. Typically, this 1274 component exists in an iCalendar object that is being used to either 1275 request or return free or busy time information. 1277 A Free/Busy Component is defined by the following notation: 1279 freebusyc = "BEGIN" ":" "VFREEBUSY" CRLF 1280 *fbprop 1281 "END" ":" "VFREEBUSY" CRLF 1283 fbprop = *attendee [created] [duration] [dtend] [dtstart] 1284 dtstamp #freebusy *last-mod *related [rstatus] 1285 [resp-seq] [seq] uid *url *(comment) 1287 The Free/Busy Component can not be nested within another Calendar 1288 Component. Free/Busy components may be related to each other with the 1289 RELATED-TO property. Multiple Free/Busy Calendar Components may be 1290 specified within a iCalendar object. This permits the grouping of 1291 Free/Busy information into logical collections, such as monthly 1292 groups of busy time information. 1294 The Free/Busy Calendar Component is intended for use in profiles 1295 involving requests for free time, requests for busy time, requests 1296 for both free and busy, and the associated replies. 1298 Free/Busy information can be expressed using the FREEBBUSY property. 1299 This property provides a terse representation of time periods. One or 1300 more FREEBUSY properties may be specified in the FREE/BUSY Calendar 1301 Component to describe the Free/Busy information. 1303 Optionally, the DTSTART and DTEND properties may be specified to 1304 express the start and end date and time for Free/Busy information in 1305 the Free/Busy Calendar Component. When present in a Free/Busy 1306 Calendar Component, they should be specified prior to any FREEBUSY 1307 properties. In a free time request, these properties may be used in 1308 combination with the DURATION property to express a request for a 1309 duration of free time within a given window of time. 1311 The recurrence properties (RRULE, EXRULE, RDATE, EXDATE) are not 1312 permitted within a Free/Busy Calendar Component. Any recurring events 1313 are resolved into their individual busy time periods using the 1314 FREEBUSY property. 1316 The following is an example of a Free/Busy Calendar Component: 1318 BEGIN:VFREEBUSY 1319 DTSTART:19971015T050000Z 1320 DTEND:19971016T050000Z 1321 FREEBUSY;VALUE=PERIOD-START:19971015T050000Z/PT8H30M, 1322 19971015T160000Z/PT5H30M, 19971015T223000Z/PT6H30M 1323 END:VFREEBUSY 1325 5.4.5 Alarm Component 1327 An Alarm Calendar Component is a grouping of component properties 1328 that is a reminder or alarm for an event or a to-do. The Alarm 1329 Calendar Component may only be specified in an event or to-do 1330 calendar component. For example, it may define a reminder for a 1331 pending event or an overdue to-do. 1333 The DTSTART property specifies the calendar date and time of day that 1334 the alarm will be triggered. The value may alternately be set to a 1335 period of time, before or after the event or to-do, that the alarm 1336 will be triggered. 1338 An Alarm Component is defined by the following notation: 1340 alarmc = "BEGIN" ":" "VALARM" CRLF 1341 *alarmprop 1342 "END" ":" "VALARM" CRLF 1344 alarmprop = *attach [created] [description] dtstart duration 1345 / *last-mod *related repeat [summary] *(comment) 1347 The Alarm Component can only appear within either an Event or To-Do 1348 Calendar Component. Alarm Components can not be nested. 1350 The following is an example of the Alarm Calendar Component: 1352 BEGIN:VALARM 1353 DTSTART:19970317T133000Z 1354 REPEAT:4 1355 DURATION:PT15M 1356 CATEGORIES:DISPLAY,AUDIO 1357 ATTACH:file:///mmedia/sounds/bell1.wav 1358 DESCRIPTION:Breakfast meeting with executive team at 8:30 AM 1359 END:VALARM 1361 5.4.6 Timezone Component 1363 A time zone is unambiguously defined by the set of time measurement 1364 rules determined by the governing body for a given geographic area. 1365 These rules describe at a minimum the base offset from UTC for the 1366 time zone, often referred to as the Standard Time offset. Many 1367 locations adjust their Standard Time forward or backward by one hour, 1368 in order to accommodate seasonal changes in number of daylight hours, 1369 often referred to as Daylight Saving Time. Some locations adjust 1370 their time by a fraction of an hour. Standard Time is also known as 1371 Winter Time. Daylight Saving Time is also known as Advanced Time, 1372 Summer Time, or Legal Time in certain countries. The following table 1373 shows the changes in time zone rules for the eastern United States. 1375 Effective Transition Rule 1376 Date (Date/Time) Offset Abbreviation 1378 1920-1920 last Sun in Mar, 02:00 -0400 EDT 1380 1920-1920 last Sun in Oct, 02:00 -0500 EST 1382 1921-1966 last Sun in Apr, 02:00 -0400 EDT 1384 1921-1954 last Sun in Sep, 02:00 -0500 EST 1386 1955-1966 last Sun in Oct, 02:00 -0500 EST 1388 1967-* last Sun in Oct, 02:00 -0500 EST 1390 1967-1973 last Sun in Apr, 02:00 -0400 EDT 1392 1974-1974 Jan 6, 02:00 -0400 EDT 1394 1975-1975 Feb 23, 02:00 -0400 EDT 1396 1976-1986 last Sun in Apr, 02:00 -0400 EDT 1398 1987-* first Sun in Apr, 02:00 -0400 EDT 1400 Interoperability between two calendaring and scheduling applications, 1401 especially for recurring events and to-dos, is dependent on the 1402 ability to capture and convey date and time information in an 1403 unambiguous format. The specification of current time zone 1404 information is integral to this behavior. 1406 The Time Zone Calendar Component is a grouping of component 1407 properties that define a time zone description. The time zone 1408 description specifies the effective Standard Time or Daylight Savings 1409 Time rules for a particular time zone. The Timezone Component can not 1410 be nested within other Calendar Components. The Time Zone Component 1411 may be specified multiple times. If the Time Zone Component is 1412 missing, the recipient should assume all local times are relative to 1413 the recipient's time zone. The Time Zone Component should be 1414 specified in the iCalendar object before any other Calendar 1415 Components. 1417 A Time Zone Component is defined by the following notation: 1419 timezonec = "BEGIN" ":" "VTIMEZONE" CRLF 1420 *tzprop 1421 "END" ":" "VTIMEZONE" CRLF 1423 tzprop = [created] [daylight] dtstart [rdate / rrule] 1424 [tzname] tzoffset *(comment) 1426 The Time Zone component is important for correct interpretation of 1427 individual as well as recurring calendar components that span a time 1428 zone transition. For example, from EST to EDT. The exception to this 1429 are calendar components that are considered floating (i.e., occurs at 1430 a particular local time no matter what time zone you are in). If the 1431 iCalendar object contains a non-floating calendar component that has 1432 a recurring date pattern (i.e., includes the RRULE property) or a 1433 list of date and local time values (i.e., includes the RDATE 1434 property), one or more Time Zone components must be specified, such 1435 that for the given range of the recurrence (i.e., the earliest 1436 instance to latest instance), there is valid time zone information 1437 for all instances. In other words, if all of the instances of the 1438 pattern is entirely within one offset observance, (e.g., all are in 1439 Standard Time), only one Time Zone Calendar Component need be 1440 present. If a time zone transition is crossed, then other Time Zone 1441 Components are needed. Further, if there are known changes to the 1442 rules for the time zone, even more Time Zone Components are needed. 1444 Each Time Zone Component consists of several properties: 1446 The CREATED property is a DATE-TIME value that indicates when the 1447 time zone description was created. 1449 The DAYLIGHT property is a BOOLEAN value indicating Standard Time 1450 (FALSE) or Daylight Savings Time (TRUE). The default for DAYLIGHT is 1451 FALSE or Standard Time. 1453 The DTSTART property in this usage is a fully specified DATE-TIME 1454 value, including the UTC offset, indicating the effective start date 1455 and time for the time zone information. For example, 19671029T020000- 1456 0400 represents the time at which the transition to Standard Time 1457 took effect in 1967 for the eastern United States. 1459 The TZOFFSET property is a UTC-OFFSET value indicating the UTC offset 1460 for the time zone (Standard Time or Daylight Savings Time). 1462 The TZNAME property is the customary name for the time zone. 1464 The RRULE property is a TEXT property indicating the recurrence rule 1465 for the transition to this time zone. For example, in the United 1466 States, the transition from Standard Time to Daylight Saving Time 1467 occurs on the first Sunday in April at 02:00. If a recurrence rule 1468 describing the transition is known to have an effective end date, the 1469 UNTIL recurrence rule parameter is used to specify that end date and 1470 time. If the recurrence rule for a particular observance (Daylight 1471 Saving Time) is changing, then the UNTIL of the first rule will be 1472 equal to the DTSTART for the replacement rule. See example below. 1474 Alternatively, the RDATE property can be used. The RDATE property is 1475 a DATE-TIME property indicating the individual dates and times that 1476 the transition takes effect. The values supplied for RDATE for each 1477 Time Zone component must provide valid time zone information of all 1478 instances of the recurrence specified for the calendar component to 1479 which this time zone information is to be applied. 1481 The following are examples of the Time Zone Calendar Component: 1483 This is a simple example showing time zone information for the 1484 Eastern United States using RDATE. Note that this is only suitable 1485 for a recurring event that starts on or later than 1997, April 6, at 1486 02:00:00 EST (i.e., the earliest effective transition date and time) 1487 and ends no later than 1998, April 7, 02:00:00 EST (i.e., latest 1488 valid date and time for EST in this scenario). For example, this can 1489 be used for a recurring event that ocurrs every Friday, 8am-9am, 1490 starting June 1, 1997, ending Dec 31, 1997. 1492 BEGIN:VTIMEZONE 1493 DAYLIGHT:FALSE 1494 RDATE:19971026T020000-0400 1495 TZOFFSET:-0500 1496 TZNAME:EST 1497 END:VTIMEZONE 1499 BEGIN:VTIMEZONE 1500 DAYLIGHT:TRUE 1501 RDATE:19970406T020000-0500 1502 TZOFFSET:-0400 1503 TZNAME:EDT 1504 END:VTIMEZONE 1506 This is a simple example showing the current time zone rules for the 1507 Eastern United States using a RRULE recurrence pattern. Note that 1508 there is no effective end date to either of the Standard Time or 1509 Daylight Time rules. This information would be valid for a 1510 recurrening event starting today and continuing on into the known 1511 future. 1513 BEGIN:VTIMEZONE 1514 DAYLIGHT:FALSE 1515 DTSTART:19671029T020000-0400 1516 RRULE:BYDAY=-1SU;BYMONTH=10;FREQ=YEARLY 1517 TZOFFSET:-0500 1518 TZNAME:EST 1519 END:VTIMEZONE 1520 BEGIN:VTIMEZONE 1521 DAYLIGHT:TRUE 1522 DTSTART:19870405T020000-0500 1523 RRULE:BYDAY=1SU;BYMONTH=4;FREQ=YEARLY 1524 TZOFFSET:-0400 1525 TZNAME:EDT 1526 END:VTIMEZONE 1528 This is an example showing a ficticious set of rules for the Eastern 1529 United States, where the Daylight Time rule has an effective end date 1530 (i.e., after that date, Daylight Time is no longer observed). 1532 BEGIN:VTIMEZONE 1533 DAYLIGHT:FALSE 1534 DTSTART:19671029T020000-0400 1535 RRULE:BYDAY=-1SU;BYMONTH=10;FREQ=YEARLY 1536 TZOFFSET:-0500 1537 TZNAME:EST 1538 END:VTIMEZONE 1540 BEGIN:VTIMEZONE 1541 DAYLIGHT:TRUE 1542 DTSTART:19870405T020000-0500 1543 RRULE:BYDAY=1SU;BYMONTH=4;FREQ=YEARLY;UNTIL=19981025T020000-0400 1544 TZOFFSET:-0400 1545 TZNAME:EDT 1546 END:VTIMEZONE 1548 This is an example showing a ficticious set of rules for the Eastern 1549 United States, where the first Daylight Time rule has an effective 1550 end date. There is a second Daylight Time rule that picks up where 1551 the other left off. 1553 BEGIN:VTIMEZONE 1554 DAYLIGHT:FALSE 1555 DTSTART:19671029T020000-0400 1556 RRULE:BYDAY=-1SU;BYMONTH=10;FREQ=YEARLY 1557 TZOFFSET:-0500 1558 TZNAME:EST 1559 END:VTIMEZONE 1561 BEGIN:VTIMEZONE 1562 DAYLIGHT:TRUE 1563 DTSTART:19870405T020000-0500 1564 RRULE:BYDAY=1SU;BYMONTH=4;FREQ=YEARLY;UNTIL=19990404T020000-0500 1565 TZOFFSET:-0400 1566 TZNAME:EDT 1567 END:VTIMEZONE 1569 BEGIN:VTIMEZONE 1570 DAYLIGHT:TRUE 1571 DTSTART:19990404T020000-0500 1572 RRULE:BYDAY=-1SU;BYMONTH=3;FREQ=YEARLY 1573 TZOFFSET:-0400 1574 TZNAME:EDT 1575 END:VTIMEZONE 1576 5.5 Calendar Properties 1578 The Calendar Properties are attributes that apply to the iCalendar 1579 object, as a whole. These properties do not appear within a Calendar 1580 Component. They should be specified after the BEGIN:VCALENDAR 1581 properties and prior to any Calendar Component. 1583 5.5.1 Calendar Scale 1585 This property is identified by the property name CALSCALE. This 1586 property defines the calendar scale used for the calendar information 1587 specified in the iCalendar object. This specification is based on the 1588 Gregorian calendar scale. The Gregorian calendar scale is assumed if 1589 this property is not specified in the iCalendar object. It is 1590 expected that other calendar scales will be defined in other 1591 specifications or by future versions of this specification. 1593 The property is defined by the following notation: 1595 calscale = "CALSCALE" ":" calvalue CRLF 1597 calvalue = "GREGORIAN" / iana-scale 1599 iana-scale = 1602 The following is an example of this property: 1604 CALSCALE:GREGORIAN 1606 The data type for this property is TEXT. 1608 5.5.2 Product Identifier 1610 This property is identified by the property name PRODID. This 1611 property specifies the identifier for the product that created the 1612 iCalendar object. The vendor of the implementation should assure that 1613 this is a globally unique identifier; using some technique such as an 1614 ISO 9070 FPI value. This calendar property must be specified in the 1615 iCalendar object but can only appear once. 1617 The property is defined by the following notation: 1619 prodid = "prodid" ":" pidvalue CRLF 1621 pidvalue = text 1622 ;Any text that describes the product and version 1623 ;and that is generally assured of being unique. 1625 The following is an example of this property: 1627 PRODID:-//ABC Corporation//NONSGML My Product//EN 1629 The data type for this property is TEXT. 1631 5.5.3 Profile 1633 This property is identified by the property name PROFILE. This 1634 property defines the usage profile associated with the calendar 1635 object. When used in a MIME message entity, the value of this 1636 property must be the same as the Content-Type profile parameter 1637 value. This property can only appear once within the iCalendar 1638 object. 1640 The property is defined by the following notation: 1642 profile = "PROFILE" ": profvalue CRLF 1644 profvalue = " component "-" action 1646 component = "EVENT" / "TODO" / "JOURNAL" / "FREEBUSY" 1647 / iana-component / x-token 1649 action = 1651 x-token = 1654 iana-component = 1656 The following is an example of this property when the iCalendar 1657 object is used to request a meeting: 1659 PROFILE:EVENT-REQUEST 1661 In the event that this property is not specified, the usage profile 1662 is undefined. The data type for this property is TEXT. 1664 5.5.4 Profile Version 1666 This property is identified by the property name PROFILE-VERSION. 1667 This property specifies the identifier corresponding to the highest 1668 version number or the minimum and maximum range of the usage profile 1669 that was used in constructing the iCalendar object. Values for this 1670 property are to be defined by registering an iCalendar usage 1671 profiles. 1673 The property is defined by the following notation: 1675 prof-version = "PROFILE-VERSION" ":" profvalue CRLF 1677 profvalue = iana-prfver 1679 iana-prfver = max-prfver / (min-prfver ";" max-prfver) 1681 min-prfver = 1683 max-prfver = 1685 The following is an example of this property: 1687 PROFILE-VERSION:IPCS-1.0 1689 The data type for this property is TEXT. 1691 5.5.5 Source 1693 This property is identified by the property name SOURCE. This 1694 property is defined by the [MIME DIR] specification. In this 1695 specification, the property identifies the URL for the source of the 1696 iCalendar object. The URL is useful for accessing the iCalendar 1697 object using a calendar access protocol. 1699 The property is defined by the following notation: 1701 source = "SOURCE" ":" url CRLF 1703 The following are examples of this property: 1705 SOURCE:http://xyz.corp.com/corp-cals/1997-events.or4 1707 SOURCE:http://xyz.corp.com/calendars/~jdoe 1709 The data type for this property is URL. 1711 5.5.6 Source Name 1713 This property is identified by the property name NAME. This property 1714 is defined by the [MIME DIR] specification. The property identifies 1715 the displayable, presentation name for the source of the iCalendar 1716 object. The source name is a useful text to associate in the user- 1717 interface of an application with the value in the SOURCE property. 1719 The property is defined by the following notation: 1721 name = "NAME" ":" text CRLF 1723 The following is an example of this property: 1725 NAME:1997 Events Calendar for XYZ Corporation 1727 The data type for this property is TEXT. 1729 5.5.7 Version 1731 This property is identified by the property name VERSION. This 1732 property specifies the identifier corresponding to the highest 1733 version number or the minimum and maximum range of the MIME 1734 Calendaring and Scheduling Content Type specification supported by 1735 the implementation that created the iCalendar object. A value of 1736 "2.0" corresponds to this specification. This calendar property must 1737 appear within the iCalendar object but can only appear once. 1739 The property is defined by the following notation: 1741 version = "VERSION" ":" vervalue CRLF 1742 vervalue = "2.0" ;This specification 1743 / maxver 1744 / (minver ";" maxver) 1746 minver = 1747 ;Minimum iCalendar version used to create the iCalendar object 1749 maxver = 1750 ;Maximum iCalendar version used to create the iCalendar object 1752 The following is an example of this property: 1754 VERSION:2.0 1756 The data type for this property is TEXT. 1758 5.6 Component Properties 1760 The following properties apply to either an event or to-do calendar 1761 object component. 1763 5.6.1 Attachment 1765 This property is identified by the property name ATTACH. The property 1766 provides the capability to associate an external object with a 1767 calendar component. For example, a document to be reviewed at a 1768 scheduled event or the description of the process steps for a to-do. 1769 The property may only be specified within event, to-do, or journal 1770 calendar components. This property may be specified multiple times 1771 within an iCalendar object. 1773 The property is defined by the following notation: 1775 attach = "ATTACH" ":" url CRLF 1777 The following are examples of this property: 1779 ATTACH:CID:jsmith.part3.960817T083000.xyzMail@host1.com 1781 ATTACH:FTP://xyzCorp.com/pub/reports/r-960812.ps 1783 The data type for this property is URL. 1785 5.6.2 Attendee 1787 This property is identified by the property name ATTENDEE. The 1788 property defines an attendee within a calendar component. The 1789 property may only be specified within the event, to-do and free/busy 1790 calendar components. 1792 The property has the property parameters TYPE, for the type of 1793 attendee, ROLE, for the intended role of the attendee; STATUS, for 1794 the status of the attendee�s participation; RSVP, for indicating 1795 whether the favor of a reply is requested; EXPECT, to indicate the 1796 expectation of the attendee�s participation by the originator; 1797 MEMBER, to indicate the group that the attendee belongs to; 1798 DELEGATED-TO, to indicate the person that the original request was 1799 delegated to; and DELEGATED-FROM, to indicated whom the request was 1800 delegated from. 1802 A recipient delegated a request MUST inherit the RSVP and EXPECT 1803 values from the attendee that delegated the request to them. 1805 Multiple attendees may be specified by including multiple ATTENDEE 1806 properties within the MIME calendaring entity. 1808 The property data type default is CAL-ADDRESS. The property data type 1809 may also be set to URL. This provides a useful mechanism to allow 1810 more than just the address of the attendee to be referenced. For 1811 example, the property value may refer to a URL. 1813 The property is defined by the following notation: 1815 attendee = "ATTENDEE" [";" attparamlist] ":" 1816 (cal-address / URL) CRLF 1817 ;Value must match default or explicit data type 1819 attparamlist = attparam / attparamlist ";" attparam 1820 / paramlist / paramlist ";" attparam 1821 / paramlist ";" attparamlist ";" 1822 attparam 1824 attparam = typeparm / roleparm / statusparm / rsvpparm 1825 / expectparm / memberparm / deletoparm / delefromparm 1827 typeparm = "TYPE" "=" 1828 ("INDIVIDUAL" ; An individual 1829 / "GROUP" ; A group of individuals 1830 / "RESOURCE" ; A physical resource 1831 / "ROOM" ; A room resource 1832 / "UNKNOWN") ; Otherwise not known 1833 ;Default value is UNKNOWN 1835 roleparm = "ROLE" "=" 1836 ("ATTENDEE" ; Indicates a regular attendee 1837 / "OWNER" ; Indicates owner of event or to-do 1838 / "ORGANIZER" ; Indicates organizer of event or to-do 1839 / "DELEGATE") ; Indicates delegate to event or to-do 1840 ;Default is ATTENDEE 1842 statusparm = "STATUS" "=" 1843 ("NEEDS-ACTION" ; Indicates event or to-do needs action 1844 / "ACCEPTED" ; Indicates event or to-do accepted 1845 / "DECLINED" ; Indicates event or to-do not accepted 1846 / "TENTATIVE" ; Indicates event or to-do tentatively 1847 ; accepted. Status may change in the future. 1848 / "COMPLETED" ; Indicates to-do was completed. 1849 ; COMPLETED property has date/time completed. 1850 / "DELEGATED" ; Indicateds event or to-do delegated 1851 ; to another ATTENDEE 1852 / "CANCELED") ; Indicates event or to-do canceled for 1853 ; ATTENDEE 1854 ;Default is NEEDS-ACTION 1855 rsvpparm = "RSVP" "=" 1856 ("TRUE" ; Indicates response requested 1857 / "FALSE") ; Indicates no response needed 1858 ;Default is FALSE 1860 expectparm = "EXPECT" "=" 1861 ("FYI" ; Indicates request is for your info 1862 / "REQUIRE" ; Indicates presence is required 1863 / "REQUEST") ; Indicates presence is requested 1864 ;Default is FYI 1866 memberparm = "MEMBER" "=" cal-address 1867 ; Indicates a group or mailing list 1869 deletoparm = "DELEGATED-TO" "=" cal-address 1870 ; Indicates who request delegated to 1872 delefromparm = "DELEGATED-FROM" "=" cal-address 1873 ;Indicates who request delegated from 1875 The following are examples of this property�s use for a to-do: 1877 ATTENDEE;ROLE=OWNER;STATUS=COMPLETED:jsmith@host1.com 1878 ATTENDEE;MEMBER=DEV-GROUP:joecool@host2.com 1879 ATTENDEE;DELEGATED-FROM=immud@host3.com:ildoit@host1.com 1881 The following is an example of this property used for specifying 1882 multiple attendees to an event: 1884 ATTENDEE;ROLE=OWNER;STATUS=CONFIRMED:John Smith 1885 ATTENDEE;ROLE=ATTENDEE;STATUS=TENTATIVE:Henry Cabot 1886 1887 ATTENDEE;ROLE=DELEGATE;STATUS=CONFIRMED:Jane Doe 1889 The following is an example of this property with the value specified 1890 as an URL reference to a vCard that contains the information about 1891 the attendee: 1893 ATTENDEE;ROLE=ATTENDEE;STATUS=CONFIRMED;VALUE=URL: 1894 http://www.xyz.com/~myvcard.vcf 1896 The following is an example of this property with "delegatee" 1897 and"delegator" information for an event: 1899 ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:John Smith 1900 ATTENDEE;ROLE=DELEGATE;STATUS=TENTATIVE;DELEGATED-FROM= 1901 iamboss@host2.com:Henry Cabot 1902 ATTENDEE;ROLE=ATTENDEE;STATUS=DELEGATED;DELEGATED-TO= 1903 hcabot@host2.com=iamboss(The Big Cheese)@host2.com 1904 ATTENDEE;ROLE=DELEGATE;STATUS=ACCEPTED:Jane Doe 1906 The default data type for this property is CAL-ADDRESS. The data type 1907 may be reset to URL; in which case the value is a location or message 1908 that contains the information that is to be used to specify the 1909 attendee address. 1911 5.6.3 Categories 1913 This property is identified by the property name CATEGORIES. This 1914 property defines the categories for a calendar component. The 1915 property may be specified within the event, to-do or journal calendar 1916 component with an arbitrary text value. The property may also be 1917 specified within the alarm property with a value of the alarm 1918 category. More than one category may be specified as a list of 1919 categories separated by the COMMA character (ASCII decimal 44). 1921 The properties is defined by the following notation: 1923 categories = "CATEGORIES" [";" paramlist] ":" 1924 catvalue CRLF 1926 catvalue = cat1value *["," cat1value] 1927 / cat2value *["," cat2value] 1929 cat1value = "APPOINTMENT" / "BUSINESS" / "EDUCATION" / "HOLIDAY" 1930 / "MEETING" / "MISCELLANEOUS" / "NON-WORKING HOURS" 1931 / "NOT IN OFFICE" / "PERSONAL" / "PHONE CALL" 1932 / "SICK DAY" / "SPECIAL OCCASION" / "TRAVEL" 1933 / "VACATION" / word 1934 ;Used in event and to-do components only 1936 cat2value = "AUDIO" / "DISPLAY" / "EMAIL" / "PROCEDURE" 1937 / x-token / iana-word 1938 ;Used in alarm component only 1940 The following are examples of this property in an event, to-do or 1941 journal calendar component: 1943 CATEGORIES:APPOINTMENT,EDUCATION 1945 CATEGORIES:MEETING 1947 The following are examples of this property in an alarm calendar 1948 component: 1950 CATEGORIES:AUDIO,DISPLAY 1952 CATEGORIES:PROCEDURE 1954 The data type for this property is TEXT. 1956 5.6.4 Classification 1958 This property is identified by the property name CLASS. This property 1959 defines the access classification for a calendar component. The 1960 property may only be specified in an event, to-do or journal calendar 1961 component. The property may only be specified once. 1963 An access classification is only one component of the general 1964 security system within a calendar application. It provides a method 1965 of capturing the scope of the access the calendar owner intends for 1966 information within an individual calendar entry. The access 1967 classification of an individual iCalendar component is useful when 1968 measured along with the other security components of a calendar 1969 system (e.g., user authorization, access rights, access role, etc.). 1970 Hence, the semantics of the individual access classifications can not 1971 be completely defined by this specification alone. Additionally, due 1972 to the "blind" nature of most exchange processes using this 1973 specification, these access classifications can not serve as an 1974 enforcement statement for a system receiving an iCalendar object . 1975 Rather, they provide a method for capturing the intention of the 1976 calendar owner for the access to the calendar component. 1978 The property is defined by the following notation: 1980 class = "CLASS" [";" paramlist] ":" 1981 classvalue CRLF 1983 classvalue = "PUBLIC" / "PRIVATE" / "CONFIDENTIAL" / x-token 1984 ;Default is PUBLIC 1986 The following is an example of this property: 1988 CLASS:PUBLIC 1990 The data type for this property is TEXT. 1992 5.6.5 Comment 1994 This property is identified by the property name COMMENT. This 1995 property specifies non-processing information intended to provide a 1996 comment to the calendar user. The property may be specified in any of 1997 the calendar components. The property may be specified multiple 1998 times. 2000 The property is defined by the following notation: 2002 comment = "COMMENT" ":" text CRLF 2004 The following is an example of this property: 2006 COMMENT:The meeting really needs to include both ourselves 2007 and the customer. We can�t hold this meeting without them. 2008 As a matter of fact, the venue for the meeting ought to be at 2009 their site. - - John 2011 The data type for this property is TEXT. 2013 5.6.6 Date/Time Completed 2015 This property is identified by the property name COMPLETED. This 2016 property defines the date and time that a to-do was actually 2017 completed. The property may be specified once in a to-do component. 2018 The date and time is a UTC value. 2020 The property is defined by the following notation: 2022 completed = "COMPLETED" ":" date-time CRLF 2023 The following is an example of this property: 2025 COMPLETED:19960401T235959Z 2027 This property is optional for MIME entities conforming to this 2028 content type. The data type for this property is DATE-TIME. 2030 5.6.7 Date/Time Created 2032 This property is identified by the property name CREATED. This 2033 property specifies the date and time that the calendar information 2034 was created. The property may be specified in any of the calendar 2035 components. The property may only be specified once. The date and 2036 time is an UTC value. 2038 The property is defined by the following notation: 2040 created = "CREATED" ":" date-time CRLF 2042 The following is an example of this property: 2044 CREATED:19960329T133000Z 2046 The data type for this property is DATE-TIME. 2048 5.6.8 Date/Time Due 2050 This property is identified by the property name DUE. This property 2051 defines the date and time that a to-do is expected to be completed. 2052 The value must be later in time than the value for the DTSTART 2053 property. The time can either be in local time, local time with UTC 2054 offset or UTC time. The property must be specified in a to-do 2055 calendar component, but may only be specified once. The DUE value 2056 must be a date/time after the DTSTART value. 2058 The property is defined by the following notation: 2060 due = "DUE" ":" (date-time / duration) CRLF 2061 ;Value data type must match the value 2063 The following is an example of this property: 2065 DUE:19960401T235959Z 2067 The default data type for this property is DATE-TIME. The data type 2068 may be reset to DURATION. 2070 5.6.9 Date/Time End 2072 This property is identified by the property name DTEND. This property 2073 may be specified within the event, free/busy, and time zone calendar 2074 components. 2076 Within the event calendar component, this property defines the end 2077 date and time for the event. The property is required in event 2078 calendar components. The time can either be in local time, local time 2079 with UTC offset or UTC time. The local time is only to be used to 2080 specify date and time values that do not need to be fixed. A 2081 recipient must assume their own time zone for data and time values 2082 that do not include time zone information. Events may have an end 2083 date/time but no start date/time. In that case, the event does not 2084 take up any time. The value must be later in time than the value of 2085 the DTSTART property. 2087 Within the free/busy calendar component, this property defines the 2088 end date and time for the free or busy time information. The time 2089 must be specified in local time with UTC offset or UTC time. The 2090 value must be later in time than the value of the DTSTART property. 2092 The property is defined by the following notation: 2094 dtend = "DTEND" ":" date-time CRLF 2096 The following is an example of this property: 2098 DTEND:19960401T235959Z 2100 The data type for this property is DATE-TIME. 2102 5.6.10 Date/Time Stamp 2104 This property is identified by the property name DTSTAMP. This 2105 property specifies an UTC date/time stamp. The property indicates the 2106 date/time that the iCalendar object instance was created. This 2107 property SHOULD be included in every iCalendar object to permit the 2108 recipient to know when the iCalendar object was created. 2110 This property is different than the CREATED and LAST-MODIFIED 2111 properties. These two properties are used to specify when the 2112 calendar service information was created and last modified. This is 2113 different than when the iCalendar object representation of the 2114 calendar service information was created or last modified. 2116 The property is defined by the following notation: 2118 dtstamp = "DTSTAMP" ":" date-time CRLF 2120 The value type for this property is DATE-TIME. The value must be a 2121 UTC date/time value. 2123 5.6.11 Date/Time Start 2125 This property is identified by the property name DTSTART. This 2126 property may be specified within the event, free/busy, and time zone 2127 calendar components. 2129 Within the event calendar component, this property defines the start 2130 date and time for the event. The property is required in event 2131 calendar components. The time can either be in local time, local time 2132 with UTC offset or UTC time. The local time is only to be used to 2133 specify date and time values that do not need to be fixed. A 2134 recipient must assume their own time zone for data and time values 2135 that do not include time zone information. Events may have a start 2136 date/time but no end date/time. In that case, the event does not take 2137 up any time. 2139 Within the free/busy calendar component, this property defines the 2140 start date and time for the free or busy time information. The time 2141 must be specified in local time with UTC offset or UTC time. 2143 Within the time zone calendar component, this property defines the 2144 effective start date and time for a time zone specification. This 2145 property is required within time zone calendar components. The time 2146 must be specified as a UTC time. 2148 The property is defined by the following notation: 2150 dtstart = "DTSTART" ":" (date-time / date) CRLF 2151 ;Date data type only permitted on Journal calendar component. 2153 The following is an example of this property: 2155 DTSTART:19960401T235959-0600 2157 The default data type for this property is DATE-TIME. For Journal 2158 calendar components, the data type may be overriden to be DATE. 2160 5.6.12 Daylight 2162 This property is identified by the property name DAYLIGHT. This 2163 property may only be specified in a Time Zone Calendar Component. 2164 This property specifies whether Daylight Saving Time (i.e., value is 2165 TRUE) or Standard Time (i.e., value is FALSE) is in effect for the 2166 time zone. The default value is FALSE or Standard Time. 2168 The property is defined by the following notation: 2170 daylight = "DAYLIGHT" ":" boolean CRLF 2171 ;Default value is FALSE 2173 The following is an example of this property: 2175 DAYLIGHT:TRUE ;Specifies DST in effect in time zone 2177 The data type for this property is BOOLEAN. 2179 5.6.13 Description 2181 This property is identified by the property name DESCRIPTION. This 2182 property provides a more complete description of the calendar 2183 component, than that provided by the SUMMARY property. The property 2184 must be specified in the event, to-do and journal calendar 2185 components. The property may be specified multiple times only within 2186 a journal calendar component. 2188 The property is defined by the following notation: 2190 Description = "DESCRIPTION" [";" paramlist] ":" 2191 text CRLF 2193 The following is an example of the property with formatted line 2194 breaks in the property value: 2196 DESCRIPTION;ENCODING=Q:Meeting_to_provide_technical_ 2197 review_for_"Phoenix"_design.=0D=0A 2198 Happy_Face_Conference_Room._Phoenix_design_team 2199 _must_attend_this_meeting._RSVP_to_team_leader. 2201 The following is an example of the property with folding of long 2202 lines: 2204 DESCRIPTION:Last draft of the new novel is to be completed 2205 for the editor�s proof today. 2207 The data type for this property is TEXT. 2209 5.6.14 Duration 2211 This property is identified by the property name DURATION. The 2212 property specifies a duration of time. The property may be specified 2213 in an event calendar component in order to specify a duration of the 2214 event, instead of an explicit end date/time. The property may be 2215 specified in a free/busy calendar component in order to specify the 2216 amount of free time being requested. The property may be specified in 2217 an alarm calendar component in order to specify the period between 2218 repeating alarms. 2220 The property is defined by the following notation: 2222 duration = "DURATION" ":" duration CRLF 2224 The following is an example of this property that specifies an 2225 interval of time of 1 hour and zero minutes and zero seconds: 2227 DURATION:PT1H0M0S 2229 The following is an example of this property that specifies an 2230 interval of time of 15 minutes. 2232 DURATION:PT15M 2234 The data type for this property is DURATION. 2236 5.6.15 Exception Date/Times 2238 This property is identified by the property name EXDATE. This 2239 property defines the list of date/time exceptions for a recurring 2240 event or to-do component. The times can either be in local time, 2241 local time with UTC offset or UTC time. 2243 The property is defined by the following notation: 2245 exdate = "EXDATE" ":" date-time *["," date-time] 2246 CRLF 2248 The following is an example of this property: 2250 EXDATE:19960402T010000Z,19960403T010000Z,19960404T010000Z 2252 The data type for this property is DATE-TIME. 2254 5.6.16 Exception Rule 2256 This property is identified by the property name EXRULE. This 2257 property defines a rule or repeating pattern for an exception to a 2258 recurring event or to-do. This property may only be specified in the 2259 event and to-do calendar components. 2261 This property is defined by the same property values and parameters 2262 as specified for the RRULE property. The property is defined by the 2263 following notation: 2265 exrule = "EXRULE" [";" paramlist] ":" rvalue CRLF 2267 The following are examples of this property. Except every other week, 2268 on Tuesday and Thursday for 4 occurrences: 2270 EXRULE:COUNT=4;INTERVAL=2;BYDAY=TU,TH;FREQ=WEEKLY 2272 Except daily for 10 occurrences: 2274 EXRULE:COUNT=10;FREQ=DAILY 2276 Except yearly in June and July for 8 occurrences: 2278 EXRULE:COUNT=8;BYMONTH=6,7;FREQ=YEARLY 2280 The data type for this property is TEXT. 2282 5.6.17 Free/Busy Time 2284 This property is identified by the property name FREEBUSY. The 2285 property defines one or more free or busy time intervals. These time 2286 periods may be specified as either a start and end date-time or a 2287 start date-time and duration. 2289 The date and time is either local time with UTC offset or a UTC 2290 value. 2292 The FREEBUSY property may include the TYPE property parameter to 2293 specify the information defines a free or busy time interval. The 2294 property may also include the STATUS property parameter to specify 2295 the type of busy time. The STATUS parameter may be utilized by the 2296 application reading the busy time information in order to provide a 2297 richer view of the information. 2299 The property is defined by the following notation: 2301 freebusy = "FREEBUSY" [";" fbparmlist] ":" fbvalue 2302 CRLF 2304 fbparmlist = fbparam / paramlist ";" fbparam 2305 / fbparam ";" fbparmlist 2307 fbparam = fbtype / fbstatus 2309 fbtype = "TYPE" "=" ("FREE" or "BUSY") 2310 ;Default is BUSY 2312 fbstatus = "STATUS" "=" 2313 "BUSY" ;Represents busy time interval 2314 / "OUT" ;Represents out-of-office, non-working 2315 ;hours, or other unavailable interval 2316 / "PRIVATE" ;Represents private unavailable time 2317 / "CONFIDENTIAL" ;Represents confidential unavailable 2318 ;time 2319 ;Default is BUSY 2321 fbvalue = period *["," period] 2322 ;Value must match default or explicit data type 2324 The following are some examples of this property: 2326 FREEBUSY;STATUS=OUT:19970308T160000Z/PT8H30M 2328 FREEBUSY;TYPE=FREE:19970308T160000Z/PT3H,19970308T200000Z/PT1H 2330 FREEBUSY properties within the Free/Busy Calendar Component should be 2331 sorted in ascending order, based on start time and then end time, 2332 with the earliest periods first. 2334 The FREEBUSY property may specify more than one value, separated by 2335 the COMMA character (ASCII decimal 44). In such cases, the FREEBUSY 2336 property values should all be of the same STATUS (e.g., all values of 2337 a particular STATUS listed together in a single property). 2339 The data type for this property is PERIOD. 2341 5.6.18 Geographic Position 2343 This property is identified by the property name GEO. This property 2344 specifies information related to the global position for an event or 2345 to-do calendar component. The property value specifies latitude and 2346 longitude, in that order (i.e., "LAT LON" ordering). The longitude 2347 represents the location east and west of the prime meridian as a 2348 positive or negative real number, respectively. The latitude 2349 represents the location north and south of the equator as a positive 2350 or negative real number, respectively. The longitude and latitude 2351 values must be specified as decimal degrees and should be specified 2352 to six decimal places. This will allow for granularity within a meter 2353 of the geographical position. The simple formula for converting 2354 degrees-minutes-seconds into decimal degrees is: 2356 decimal = degrees + minutes/60 + seconds/3600. 2358 The property is defined by the following notation: 2360 geo = "GEO" ":" geovalue CRLF 2362 geovalue = float ";" float 2363 ;Latitude and Longitude components 2365 The following is an example of this property: 2367 GEO:37.386013;-122.082932 2369 The default data type for this property is FLOAT. 2371 5.6.19 Last Modified 2373 This property is identified by the property name LAST-MODIFIED. The 2374 property specifies the date and time that the calendar information 2375 was last revised. The property value may include multiple "date-time" 2376 values in order to capture the sequence of modifications made to the 2377 calendar information. This property may be specified in the event, 2378 to-do, journal or free/busy calendar components. The data and time 2379 must be a UTC value. 2381 The property is defined by the following notation: 2383 last-mod = "LAST-MODIFIED" ":" date-time ["," date-time] 2384 CRLF 2386 The following is are examples of this property: 2388 LAST-MODIFIED:19960817T133000Z 2390 LAST-MODIFIED:19970104T083000-0500,19970403T090000-0500, 2391 19970901T133000-0400 2393 The data type for this property is DATE-TIME. 2395 5.6.20 Location 2397 This property is identified by the property name LOCATION. The 2398 property defines the intended location for the event or to-do 2399 calendar component. The property may only be specified within an 2400 event or to-do calendar component. 2402 The property is defined by the following notation: 2404 location = "LOCATION [";" paramlist] ":" locavalue 2405 CRLF 2407 locavalue = text / url ;The value must be the same type as the 2408 ;default or explicit data type. 2410 The following are some examples of this property: 2412 LOCATION:Conference Room - F123, Bldg. 002 2413 LOCATION;VALUE=URL:http://www.xyzcorp.com/~jsmith.vcf 2415 The default data type for this property is TEXT. The data type may be 2416 reset to URL. In the case of the data type being URL, the property 2417 value may reference a vCard object. This provides a useful mechanism 2418 to specify a location in terms of its electronic business card. 2420 5.6.21 Priority 2422 This property is identified by the property name PRIORITY. The 2423 property defines the priority for event or to-do. The property may 2424 only be specified within an event or to-do calendar component. The 2425 value is an integer. A value of zero (ASCII decimal 48) specifies an 2426 undefined priority. A value of one (ASCII decimal 49) is the highest 2427 priority. A value of two (ASCII decimal 50) is the second highest 2428 priority. Subsequent numbers specify a decreasing ordinal priority. 2430 The property is specified by the following notation: 2432 priority = "PRIORITY" ":" integer CRLF 2433 ;Default is zero 2435 The following is an example of this property: 2437 PRIORITY:2 2439 The data type for this property is INTEGER. 2441 5.6.22 Recurrence Date/Times 2443 This property is identified by the property name RDATE. This property 2444 defines the list of date/times for a recurring event, to-do or time 2445 zone calendar component. This property may appear along with the 2446 RRULE property to define an aggregate set of repeating occurrences. 2447 When they both appear in an iCalendar object, the recurring events 2448 are defined by the union of occurrences defined by both the RDATE and 2449 RRULE. The times can either be in local time, local time with UTC 2450 offset or UTC based time. If local time is used, the TIMEZONE 2451 component must be included in the iCalendar object, otherwise the 2452 local time value will be interpreted relative to the time zone of the 2453 recipient. The period values for RDATE are specified using a specific 2454 start and a specific end basic format (period-explicit) or the period 2455 with a specific start and a specific duration basic format (period- 2456 start). 2458 The property is defined by the following notation: 2460 rdate = "RDATE" ":" rdvalue *["," rdvalue] CRLF 2462 rdvalue = date-time / period 2463 ;Value must match the default or explicit data type 2465 The following are examples of this property: 2467 RDATE:19970714T083000-0400 2468 RDATE;VALUE=PERIOD:19960403T020000Z/19960403T040000Z, 2469 19960404T010000Z/PT3H 2471 RDATE;VALUE=DATE:19970101,19970120,19970217,19970421 2472 19970526,19970704,19970901,19971014,19971128,19971129,19971225 2474 The default data type for this property is DATE-TIME. The value may 2475 be reset to DATE or PERIOD. 2477 5.6.23 Recurrence ID 2479 This property is identified by the property name RECURRENCE-ID. This 2480 property identifies a specific instance of a recurring event, to-do 2481 or journal calendar component. The property value is the effective 2482 DTSTART value of the recurrence instance. The time of day component 2483 for the value must be either an UTC or a local time with UTC offset 2484 time format, unless the original calendar object was expressed as a 2485 � �floating� 2486 � calendar object; that is in local time with no timezone 2487 calendar component specified.. 2489 The date/time value is set to the time when the original recurrence 2490 instance would occur - - meaning that if the intent is to change a 2491 Friday meeting to Thursday, the date/time is still set to the 2492 original Friday meeting. 2494 Recurrence ID is used in conjunction with the UID property to 2495 identify a particular instance of a recurring event, to-do or 2496 journal. 2498 The property is defined by the following notation: 2500 recurid = "RECURRENCE-ID" [";" rangeparm] ":" date-time 2502 rangeparm = "RANGE" "=" ("THISANDPRIOR" / "THISANDFUTURE") 2504 The default value for the range parameter is the single recurrence 2505 instance only. 2507 The following are examples of this property: 2509 RECURRENCE-ID:19960401T235959Z 2511 RECURRENCE-ID;RANGE=THISANDFUTURE:19960120T120000Z 2513 5.6.24 Recurrence Rule 2515 This property is identified by the property name RRULE. This property 2516 defines a rule or repeating pattern for a recurring events, to-dos, 2517 or time zone definitions. The property may be specified in the event, 2518 to-do, or time zone calendar components. 2520 The property value is a structured value consisting of a list of one 2521 or more recurrence grammar components. Each component is defined by a 2522 NAME=VALUE pair. The components are separated from each other by the 2523 SEMICOLON character (ASCII decimal 59). 2525 The FREQ component identifies the type of recurrence rule. This 2526 component must be specified in the recurrence rule. Valid values 2527 include HOURLY, to specify repeating events based on an interval of 2528 an hour or more; DAILY, to specify repeating events based on an 2529 interval of a day or more; WEEKLY, to specify repeating events based 2530 on an interval of a week or more; MONTHLY, to specify repeating 2531 events based on an interval of a month or more; and YEARLY, to 2532 specify repeating events based on an interval of a year or more. 2534 The INTERVAL component contains a positive integer representing how 2535 often the RRULE repeats. The default value is "1" or every hour for a 2536 HOURLY rule, every day for a DAILY rule, every week for a WEEKLY 2537 rule, every month for a MONTHLY rule and every year for a YEARLY 2538 rule. For a HOURLY rule, the value may also be expressed as a 2539 duration value, specifying hours and minutes for the repeat interval. 2540 For example, PT1H30M, would represent a 1 hour and 30 minute repeat 2541 interval. 2543 The UNTIL component defines a date-time value which bounds the RRULE. 2544 If not present, and the COUNT component is also not present, the 2545 RRULE is considered to repeat forever. 2547 The COUNT component defines the number of occurrences at which to 2548 bound the RRULE. This component is ignored if the UNTIL property 2549 parameter is also present. 2551 The BYDAY component specifies a COMMA character (ASCII decimal 44) 2552 separated list of days of the week; MO, indicates Monday; TU, 2553 indicates Tuesday; WE, indicates Wednesday; TH, indicates Thursday; 2554 FR, indicates Friday; SA, indicates Saturday; SU, indicates Sunday. 2556 Each of these values may also be preceded by a positive (+n) or 2557 negative (-n) integer. If present, this indicates the nth occurrence 2558 of the specific day within the MONTHLY or YEARLY RRULE. For example, 2559 within a MONTHLY rule, +1MO (or simply 1MO) represents the first 2560 Monday within the month, whereas -1MO represents the last Monday of 2561 the month. 2563 The BYMONTHDAY component specifies a COMMA character (ASCII decimal 2564 44) separated list of days of the month. Valid values are 1 to 31 or 2565 -31 to -1. 2567 The BYYEARDAY component specifies a COMMA character (ASCII decimal 2568 44) separated list of days of the year. Valid values are 1 to 366 or 2569 -366 to -1. For example, -1 represents the last day of the year 2570 (December 31st). 2572 The BYSETPOS component specifies a COMMA character (ASCII decimal 44) 2573 separated list of values which corresponds to the nth occurrence 2574 within the set of events specified by the rule. Valid values are 1 to 2575 366 or -366 to -1. It must only be used in conjunction with another 2576 Byxxx component. For example "the last work day of the month" could 2577 be represented as: 2579 RRULE:BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1;FREQ=MONTHLY 2580 The BYWEEKNO component specifies a comma separated list of weeks of 2581 the year. Valid values are 1 to 52. This corresponds to weeks 2582 according to week numbering as defined in [ISO 8601]. That is, a week 2583 as "A seven day period within a calendar year, starting on a Monday 2584 and identified by its ordinal number within the year; the first 2585 calendar week of the year is the one that includes the first Thursday 2586 of that year." This property parameter is only valid for YEARLY 2587 rules. 2589 The BYMONTH component specifies a comma separated list of months of 2590 the year. Valid values are 1 to 12. 2592 The WKST property parameter specifies the day on which the workweek 2593 starts. Valid values are MO, TU, WE, TH, FR, SA and SU. This is 2594 significant when a WEEKLY RRULE has an interval greater than 1. The 2595 default value is MO. 2597 If two different Byxxx components are specified within the RRULE, the 2598 recurrence occurrence must meet both criteria. 2600 If Byxxx component values are found which are beyond the available 2601 scope (ie, BYMONTHDAY=-30 in February), they are simply ignored. If a 2602 positive range limit is beyond the available scope, it will be 2603 interpreted as -1. Likewise, if a negative range limits beyond the 2604 available scope, it will be interpreted as +1. 2606 The RRULE property requires referencing the DTSTART, DTEND or 2607 DURATION properties in the iCalendar object to calculate the Event or 2608 To-do instances. 2610 The DTSTART and DTEND pair or DTSTART and DURATION pair, specified 2611 within the iCalendar object defines the first instance of the 2612 recurrence. When used with a recurrence rule, the DTSTART and DTEND 2613 properties must be specified in local time and the appropriate set of 2614 TIMEZONE components must be included. For detail on the usage of the 2615 TIMEZONE component, see the Time Zone Calendar Component definition. 2617 Any duration associated with the iCalendar object applies to all 2618 members of the generated recurrence. Any modified duration for 2619 specific recurrences would have to be explicitly specified using the 2620 RDATE property. 2622 This property is defined by the following notation: 2624 rrule = "RRULE" [paramlist] ":" rvalue CRLF 2626 paramlist = param / paramlist ";" param 2628 rvalue = "FREQ" = freq 2629 *("UNTIL" "=" enddate 2630 / "COUNT" "=" interval 2631 / "INTERVAL" "=" rinterval 2632 / "BYDAY" "=" bdweekdaylist 2633 / "BYMONTHDAY" "=" bmdaylist 2634 / "BYYEARDAY" "=" bydaylist 2635 / "BYSETPOS" "=" bsplist 2636 / "BYWEEKNO" "=" bwdaylist 2637 / "BYMONTH" "=" bmlist 2638 / "WKST" "=" weekday 2639 / "X-" word "=" word) 2641 freq = "HOURLY" / "DAILY" / "WEEKLY" / "YEARLY" 2643 rinterval = interval ; For any rvalue 2644 / duration ; Only for rvalue = HOURLY 2646 DIGIT = ;0-9 2648 digits = 1*DIGIT 2650 interval = digits 2652 enddate = date ;A UTC value 2654 plus = "+" 2656 minus = "-" 2658 ordmoday = 1*2digits ;1 to 31 2660 ordwk = 1*2digits ;1 to 52 2662 ordyrday = 1*3digits ;1 to 366 2664 daynumber = (plus / minus) ordmoday 2666 weekday = "SU" / "MO" / "TU" / "WE" / "TH" / "FR" / "SA" 2667 ;Corresponding to SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, 2668 ;FRIDAY, SATURDAY and SUNDAY days of the week. 2670 bdweekdaynum = [daynumber] weekday 2672 bdweekdaylist = bdweekdaynum / bdweekdaynum "," 2673 *(bdweekdaynum) 2675 bmposday = [plus] ordmoday 2677 bmnegday = minus ordmoday 2679 bmdaylist = bmposday *("," bmposday / bmnegday) 2680 / bmnegday *("," bmnegday / bmposday) 2682 byposday = [plus] ordyrday 2684 bynegday = minus ordyrday 2686 bydaylist = byposday *("," byposday / bynegday) 2687 / bynegday *("," bynegday / byposday) 2689 bsplist = byposday *("," byposday / bynegday) 2690 / bynegday *("," bynegday / byposday) 2692 bwposday = [plus] ordwk 2693 bwnegday = minus ordwk 2695 bwdaylist = bwposday *("," bwposday / bwnegday) 2696 / bwnegday *("," bwnegday / bwposday) 2698 bmposmon = 1*2digits ;1 to 12 2700 bmlist = bmposmon *("," bmposmon) 2702 Examples of this property include the following. Daily for 10 2703 occurrences: 2705 RRULE:COUNT=10;FREQ=DAILY 2707 Daily until 12/24/94: 2709 RRULE:UNTIL=19941224T000000Z;FREQ=DAILY 2711 Every other day - forever: 2713 RRULE:INTERVAL=2;FREQ=DAILY 2715 Every 10 days, 5 occurrences: 2717 RRULE:COUNT=5;INTERVAL=10;FREQ=DAILY 2719 Weekly for 10 occurrences 2721 RRULE:COUNT=10;FREQ=WEEKLY 2723 Weekly until 12/24/94 2725 RRULE:UNTIL=19941224T000000Z;FREQ=WEEKLY 2727 Every other week - forever: 2729 RRULE:INTERVAL=2;WKST=SU;FREQ=WEEKLY 2731 Weekly on Tuesday and Thursday for 5 weeks: 2733 RRULE:INTERVAL=5;WKST=SU;BYDAY=TU,TH;FREQ=WEEKLY 2735 Every other week on Monday, Wednesday and Friday until 12/24/94: 2737 RRULE:INTERVAL=2;WKST=SU;BYDAY=MO,WE,FR;=UNTIL=19941224T000000Z; 2738 FREQ=WEEKLY 2740 Every other week on Tuesday and Thursday, for 8 occurrences: 2742 RRULE:INTERVAL=2;WKST=SU;COUNT=8;BYDAY=TU,TH;FREQ=WEEKLY 2744 Monthly on the 1st Friday for ten occurrences: 2746 RRULE:COUNT=10;BYDAY=1FR;FREQ=MONTHLY 2748 Monthly on the 1st Friday until 12/24/94: 2750 RRULE:UNTIL=19941224T000000Z;BYDAY=1FR;FREQ=MONTHLY 2752 Every other month on the 1st and last Sunday of the month for 2753 10occurrences: 2755 RRULE:COUNT=10;BYDAY=1SU,-1SU;FREQ=MONTHLY 2757 Monthly on the second to last Monday of the month for 6 months: 2759 RRULE:COUNT=6;BYDAY=-2MO;FREQ=MONTHLY 2761 Monthly on the third to the last day of the month, forever: 2763 RRULE:BYMONTHDAY=-3;FREQ=MONTHLY 2765 Monthly on the 2nd and 15th of the month for 10 occurrences: 2767 RRULE:COUNT=10;BYMONTHDAY=2,15;FREQ=MONTHLY 2769 Monthly on the first and last day of the month for 10 occurrences: 2771 RRULE:COUNT=10;BYMONTHDAY=1,-1;FREQ=MONTHLY 2773 Every 18 months on the 10th thru 15th of the month for 10 2774 occurrences: 2776 RRULE:COUNT=10;INTERVAL=18;BYMONTHDAY=10,11,12,13,14,15; 2777 FREQ=MONTHLY 2779 Monthly on the second to the last day for 5 months. So, if the start 2780 date is August 1996, the event would repeat on 8/30/96, 9/29/96, 2781 10/30/96, 11/29/96, and 12/30/96: 2783 RRULE:COUNT=5;BYMONTHDAY=-2;FREQ=MONTHLY 2785 Yearly in June and July for 10 occurrences: 2787 RRULE:COUNT=10;BYMONTH=6,7;FREQ=YEARLY 2789 Every other year on January, February, and March for 10 occurrences: 2791 RRULE:COUNT=10;INTERVAL=2;BYMONTH=1,2,3;FREQ=YEARLY 2793 Every 3rd year on the 1st, 100th and 200th day for 10 occurrences: 2795 RRULE:COUNT=10;INTERVAL=3;BYYEARDAY=1,100,200;FREQ=YEARLY 2797 Every 20th Monday of the year, forever: 2799 RRULE:BYDAY=20MO;FREQ=YEARLY 2801 Monday of Week No. 20, forever: 2803 RRULE:BYWEEKNO=20;BYDAY=MO;FREQ=YEARLY 2805 Every Thursday in March, forever: 2807 RRULE:BYDAY=TH;BYMONTH=3;FREQ=YEARLY 2809 Every Thursday, but only in the summer, forever: 2811 RRULE:BYDAY=TH;BYMONTH=6,7,8;FREQ=YEARLY 2813 Every Friday the 13th, forever: 2815 RRULE:BYDAY=FR;BYMONTHDAY=13;FREQ=MONTHLY 2817 The first Saturday that follows the first Sunday of the month, 2818 forever: 2820 RRULE:BYDAY=SA;BYMONTHDAY=7,8,9,10,11,12,13;FREQ=MONTHLY 2822 Every four years, the first Tuesday after a Monday in November, 2823 forever (U.S. Election day): 2825 RRULE:INTERVAL=4;BYDAY=TU;BYMONTHDAY=7,8,9,10,11,12,13; 2826 FREQ=YEARLY 2828 The 3rd instance into the month of any of Tuesday, Wednesday or 2829 Thursday, for the next 3 months: 2831 RRULE:COUNT=3;BYDAY=TU,WE,TH;BYSETPOS=3;FREQ=MONTHLY 2833 The 2nd to last weekday of the month" 2835 RRULE:BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-2;FREQ=MONTHLY 2837 The data type for this property is TEXT. 2839 5.6.25 Related To 2841 This property is identified by the property name RELATED-TO. The 2842 property is used to represent relationships or references between one 2843 calendar component and another. The property may only be specified in 2844 the event, to-do and journal calendar components. The property value 2845 consists of the persistent, globally unique identifier of another 2846 MIME calendar component. This value would be represented in a MIME 2847 calendar component by the UID property. 2849 A linked relationship can be specified by a series of components that 2850 each, in turn, refer to their parent component. A group relationship 2851 can be specified by a number of components that all refer to one 2852 common parent component. 2854 Changes to a calendar component referenced by this property may 2855 impact the related calendar component. For example, if a group event 2856 changes its start or end date or time, then the related, dependent 2857 events will need to have their start and end dates changed in a 2858 corresponding way. This property is intended only to provide 2859 information on the relationship of calendar components. It is up to 2860 the target calendar system to maintain any property implications of 2861 this relationship. 2863 The property is defined by the following notation: 2865 related = "RELATED-TO" [";" paramlist] ":" relvalue 2866 CRLF 2868 relvalue = text 2870 The following is an example of this property: 2872 RELATED-TO: 2874 RELATED-TO:19960401-080045-4000F192713-0052 2876 The data type for this property is TEXT. 2878 5.6.26 Repeat Count 2880 This property is identified by the property name REPEAT. This 2881 property defines the number of repetitions for an alarm. 2883 The property is defined by the following notation: 2885 repeatcnt = "REPEAT" ":" integer CRLF 2886 ;Default is "1". 2888 The following is an example of this property: 2890 REPEAT:4 2892 The data type for the property is INTEGER. 2894 5.6.27 Request Status 2896 This property is identified by the property name REQUEST-STATUS. This 2897 property defines the status code returned for a scheduling request. 2898 This property is used to return status code information related to 2899 the processing of an associated iCalendar object. The data type for 2900 this property is TEXT. 2902 The value consists of a short return status, a longer return status 2903 description, and optionally the offending data. The components of the 2904 value are separated by the SEMICOLON character (ASCII decimal 59). 2906 The property is defined by the following notation: 2908 Rstatus = "REQUEST-STATUS" ":" statcode ";" 2909 statdesc [";" extdata] 2911 Statcode = 3*DIGIT 2912 ;Numeric return status code 2914 Statdesc = *WORD 2915 ;Textual status description 2916 Extdata = *WORD 2917 ;Textual exception data. For example, the offending property 2918 ;name and value or complete property line. 2920 The following are some examples of this property: 2922 REQUEST-STATUS:200;Success 2924 REQUEST-STATUS:301;Invalid property value;DTSTART\:96-Apr-01 2925 ;Note escapement of the colon character in property value. 2927 REQUEST-STATUS:208; Success, repeating event ignored. Scheduled 2928 as a single event.;RRULE:INTERVAL=2;FREQ=WEEKLY 2930 REQUEST-STATUS:401;Event conflict. Date/time is busy. 2932 REQUEST-STATUS:307;Invalid calendar user;ATTENDEE: 2933 jsmith@host.com 2935 The following are valid classes for the return status code. 2936 Individual iCalendar profiles will define specific return status 2937 codes for these classes. 2939 Short Return Status Code Longer Return Status 2940 Description 2942 1xx Preliminary success. This 2943 class of status code 2944 indicates that the request 2945 has been initially 2946 processed, but that 2947 completion is pending. 2949 2xx Successful. This class of 2950 status code indicates that 2951 the request was completed 2952 successfully. However, the 2953 exact status code my 2954 indicate that a fallback has 2955 been taken. 2957 3xx Client Error. This class of 2958 status code indicates that 2959 the request was not 2960 successful. The error is the 2961 result of either a syntax or 2962 a semantic error in the 2963 client formatted request. 2964 Request should not be 2965 retried until the condition 2966 in the request is corrected. 2968 4xx Scheduling Error. This class 2969 of status code indicates 2970 that the request was not 2971 successful. The error is the 2972 result of a scheduling 2973 conflict with the 2974 information in the 2975 associated calendar. 2977 5xx Service Error. This class of 2978 status code indicates that 2979 the request was not 2980 successful. Some sort of 2981 error occurred within the 2982 calendaring and scheduling 2983 service, not directly 2984 related to the request 2985 itself. 2987 5.6.28 Resources 2989 This property is identified by the property name RESOURCES. This 2990 property defines the equipment or resources needed for the event or 2991 to-do. The property value is an arbitrary text. The property may only 2992 be specified in the event or to-do calendar component. More than one 2993 resource may be specified as a list of resources separated by the 2994 COMMA character (ASCII decimal 44). 2996 The property is defined by the following notation: 2998 resource = "RESOURCES" [";" paramlist] ":" 2999 resvalist CRLF 3001 resvalist = resvalue / resvalue "," resvalist 3003 resvalue = "CATERING" / "CHAIRS" / "COMPUTER PROJECTOR" 3004 / "EASEL" / "OVERHEAD PROJECTOR" / "SPEAKER PHONE" 3005 / "TABLE" / "TV" / "VCR" / "VIDEO PHONE" / "VEHICLE" 3006 / word 3008 The following is an example of this property: 3010 RESOURCES:EASEL,PROJECTOR,VCR 3012 The data type for this property is TEXT. 3014 5.6.29 Response Sequence Number 3016 This property is identified by the property name RESPONSE-SEQUENCE. 3017 This property defines the revision sequence of the calendar 3018 component. The property may only be specified in an event, to-do, 3019 journal or free/busy calendar component. This property is needed to 3020 properly handle the receipt and processing of a sequence of MIME 3021 calendar components that have been delivered out of order. Such is 3022 the case for store-and-forward based transports. The first response 3023 to an a request is created with response sequence number of "0" 3024 (ASCII decimal 48). If the value is non-zero, it must be specified. 3025 It is incremented each time another reply is sent. 3027 The property is defined by the following notation: 3029 respseq = "RESPONSE-SEQUENCE" ":" integer CRLF 3030 ;Default is "0". 3032 The following is an example of this property: 3034 RESPONSE-SEQUENCE:1 3036 The data type for this property is INTEGER. 3038 5.6.30 Sequence Number 3040 This property is identified by the property name SEQUENCE. This 3041 property defines the revision sequence of the calendar component used 3042 in a request. The property may only be specified in an event, to-do, 3043 journal or free/busy calendar component. This property is needed to 3044 properly handle the receipt and processing of a sequence of MIME 3045 calendar components that have been delivered out of order. Such is 3046 the case for store-and-forward based transports. The first request is 3047 created with a sequence number of "0" (ASCII decimal 48). It is 3048 incremented each time the ORGANIZER or OWNER issues a revision to the 3049 request. A monotonic increment to the sequence number is caused by a 3050 change to one of the following properties by the Organizer or Owner: 3052 � DTSTART 3053 � DTEND 3054 � LOCATION 3055 � DUE 3057 The property is defined by the following notation: 3059 sequence = "SEQUENCE" ":" integer CRLF 3060 ;Default is "0". 3062 The following is an example of this property: 3064 SEQUENCE:1 3066 The data type for this property is INTEGER. 3068 5.6.31 Status 3070 This property is identified by the property name STATUS. This 3071 property defines the orignator's view of the overall status for the 3072 calendar component. This property may only be specified in the event 3073 and to-do calendar components. When specified in an event calendar 3074 component, the property is used to specify the originator's view of 3075 the general consensus for the meeting. When specified in a group 3076 scheduled to-do, the property is used to specify the originator's 3077 view of the completion status for the to-do. 3079 The property is defined by the following notation: 3081 status = "STATUS" [";" paramlist] ":" statvalue CRLF 3083 statvalue = "NEEDS ACTION" ;Indicates to-do needs action. 3084 / "COMPLETED" ;Indicates to-do completed 3085 / "TENTATIVE" ;Indicates event is being 3086 ;tentatively scheduled 3087 / "CONFIRMED" ;Indicates event is definite 3088 / "CANCELLED" ;Indicates event was canceled 3090 The following is an example of this property: 3092 STATUS:TENTATIVE 3094 The data type for this property is TEXT. 3096 5.6.32 Summary 3098 This property is identified by the property name SUMMARY. This 3099 property defines a short summary or subject for the calendar 3100 component. The property may only be specified in the event, to-do and 3101 alarm calendar component. 3103 The property is defined by the following notation: 3105 summary = "SUMMARY" [";" paramlist] ":" text CRLF 3107 The following is an example of this property: 3109 SUMMARY:Department Party 3111 The data type for this property is TEXT. 3113 5.6.33 Time Transparency 3115 This property is identified by the property name TRANSP. This 3116 property defines whether an event is transparent or not to free/busy 3117 time searches. This property may only be specified in an event 3118 calendar component. 3120 The property is specified by the following notation: 3122 transp = "TRANSP" [";" paramlist] ":" transvalue 3123 CRLF 3125 transvalue = "BUSY" ;Opaque/blocks on free/busy searches 3126 ;Default value is BUSY 3127 / "OUT" ;Opaque/blocks on free/busy searches 3128 / "PRIVATE" ;Opaque/blocks on free/busy searches 3129 / "CONFIDENTIAL" ;Opaque/blocks on free/busy searches 3130 / "TRANSPARENT" ;Transparent on free/time searches 3132 The following is an example of this property for an event that is 3133 transparent or does not block on free/busy time searches: 3135 TRANSP:TRANSPARENT 3137 The following is an example of this property for an event that is 3138 opaque or blocks on free/busy time searches: 3140 TRANSP:BUSY 3142 The data type for this property is TEXT. 3144 5.6.34 Time Zone Name 3146 This property is identified by the property name TZNAME. This 3147 property specifies the customary designation for a time zone 3148 descripiton. This property may only be specified in the Time Zone 3149 Calendar Component. 3151 This property is defined by the following notation: 3153 tzname = "TZNAME" [";" paramlist] ":" text CRLF 3155 The following are examples of this property: 3157 TZNAME: EST 3159 TZNAME: PDT 3160 The data type for this property is TEXT. 3162 5.6.35 Time Zone Offset 3164 This property is identified by the property name TZOFFSET. This 3165 property specifies the offset from UTC for a time zone. This property 3166 may only be specified in a Time Zone Calendar Component. A Time Zone 3167 Calendar Component must include this property. The property value is 3168 a signed numeric indicating the number of hours and possibly minutes 3169 from UTC. Positive numbers represents time zones east, or ahead of 3170 UTC. Negative numbers represents time zones west of, or behind UTC. 3172 The property is defined by the following notation: 3174 tzoffset = "TZOFFSET" ":" utc-offset CRLF 3176 The following are examples of this property: 3178 TZOFFSET:-0500 3180 TZOFFSET:+0530 3182 The data type for this property is UTC-OFFSET. 3184 5.6.36 Uniform Resource Locator 3186 This property is identified by the property name URL. This property 3187 defines a Uniform Resource Locator (URL) associated with the 3188 iCalendar object. This property may be specified in the event, to-do, 3189 journal, free/busy, and alarm calendar components. 3191 The property is defined by the following notation: 3193 url = "URL" ":" url CRLF 3195 The following is an example of this property: 3197 URL:http://abc.com/pub/calendars/jsmith/mytime.or3 3199 The data type for this property is URL. 3201 5.6.37 Unique Identifier 3203 This property is identified by the property name UID. This property 3204 defines the persistent, globally unique identifier for the calendar 3205 component. The property must be specified in the event, to-do and 3206 journal calendar components. 3208 This identifier is created by the calendar system that generates an 3209 iCalendar Object. The identifier is represented as a text value. This 3210 is the method for correlating scheduling messages with the referenced 3211 event, to-do, or journal. 3213 The property is defined by the following notation: 3215 uid = "UID" [";" paramlist] ":" text CRLF 3216 The following is an example of this property: 3218 UID:19960401-080045-4000F192713-0052 3220 This property is an important method for group scheduling 3221 applications to match requests with later replies, modifications or 3222 deletion requests. Calendaring and scheduling applications must 3223 generate this property in event, to-do and journal calendar 3224 components to assure interoperability with other group scheduling 3225 applications. 3227 The data type for this property is TEXT. 3229 5.6.38 Non-standard Properties 3231 The MIME Calendaring and Scheduling Content Type provides a "standard 3232 mechanism for doing non-standard things". This extension support is 3233 provided for implementers to "push the envelope" on the existing 3234 version of the specification. Extension properties are specified by 3235 property and/or property parameter names that have the prefix text of 3236 "X-" (the two character sequence: LATIN CAPITAL LETTER X character 3237 followed by the HYPEN-MINUS character). It is recommended that 3238 vendors concatenate onto this sentinel another short prefix text to 3239 identify the vendor. This will facilitate readability of the 3240 extensions and minimize possible collision of names between different 3241 vendors. User agents that support this content type are expected to 3242 be able to parse the extension properties and property parameters but 3243 may ignore them. 3245 The property is defined by the following notation: 3247 extension = "X-" [vendorid] word [";" paramlist] ":" 3248 value 3250 vendorid = 1*char "-" ;Vendor identification prefix text 3252 The following might be the ABC vendor�s extension for an audio-clip 3253 form of subject property: 3255 X-ABC-MMSUBJ;TYPE=WAVE; VALUE=URL: http://load.noise.org/mysubj.wav 3257 At present, there is no registration authority for names of extension 3258 properties and property parameters. The data type for this property 3259 is TEXT. Optionally, the data type may be any of the other valid data 3260 types. 3262 6. Recommended Practices 3264 These recommended practices should be followed in order to assure 3265 consistent handling of the following cases for an iCalendar object. 3267 1. A calendar entry with a DTSTART but no DTEND - The event does not 3268 take up any time. It is intended to represent an event that is 3269 associated with a given calendar date and time of day, such as an 3270 anniversary. Since the event does not take up any time, it must 3271 not be used to record busy time no matter what the value for the 3272 TRANSP property. 3274 2. A combination of RRULE and RDATE that produces more than one 3275 instance for a given date/time - Only one recurrence can occur on 3276 a given date/time interval. Just one instance for the date/time is 3277 recorded. 3279 3. A particular calendar profile that specifies ATTENDEE properties 3280 with the MEMBER property parameter, for which the recipient has 3281 multiple memberships - Recipient should reply to only the first 3282 MEMBER value that it can match. 3284 7. Registration of Content Type Elements 3286 This section provide the process for registration of MIME Calendaring 3287 and Scheduling Content Type profiles and new or modified properties. 3289 7.1 Registration of New and ModifiedProfiles 3291 New MIME Calendaring and Scheduling Content Type profile types are 3292 registered by the publication of an IETF Request for Comment (RFC). 3293 Changes to a profile type are registered by the publication of a 3294 revision of the RFC defining the profile type. 3296 7.2 Registration of New Properties 3298 This section defines procedures by which new properties or enumerated 3299 property values for the MIME Calendaring and Scheduling Content Type 3300 can be registered with the IANA. Note that non-IANA properties may be 3301 used by bilateral agreement, provided the associated properties names 3302 follow the "X-" convention. 3304 The procedures defined here are designed to allow public comment and 3305 review of new properties, while posing only a small impediment to the 3306 definition of new properties. 3308 Registration of a new property is accomplished by the following 3309 steps. 3311 7.2.1 Define the property 3313 A property is defined by completing the following template. 3315 To: ietf-calendar@imc.org 3317 Subject: Registration of text/calendar MIME property XXX 3319 Property name: 3321 Property purpose: 3323 Property data type(s): 3325 Property encoding: 3327 Property special notes (optional): 3329 Intended usage: (one of COMMON, LIMITED USE or OBSOLETE) 3331 The meaning of each field in the template is as follows. 3333 Property name: The name of the property, as it will appear in the 3334 body of an text/calendar MIME Content-Type "property: value" line to 3335 the left of the colon ":". 3337 Property purpose: The purpose of the property (e.g., to indicate a 3338 delegate for the event or to-do, etc.). Give a short but clear 3339 description. 3341 Property data type(s): Any of the valid data types for the property 3342 value needs to be specified. The default data type also needs to be 3343 specified. If a new data type is specified, it needs to be declared 3344 in this section. 3346 Property encoding: The encodings permitted for the property value. 3347 This description must be precise and must not violate the general 3348 encoding rules defined in this document. 3350 Property special notes: Any special notes about the property, how it 3351 is to be used, etc. 3353 7.2.2 Post the Property definition 3355 The property description must be posted to the new property 3356 discussion list, ietf-calendar@imc.org. 3358 7.2.3 Allow a comment period 3360 Discussion on the new property must be allowed to take place on the 3361 list for a minimum of two weeks. Consensus must be reached on the 3362 property before proceeding to the next step. 3364 7.2.4 Submit the property for approval 3366 Once the two-week comment period has elapsed, and the proposer is 3367 convinced consensus has been reached on the property, the 3368 registration application should be submitted to the Profile Reviewer 3369 for approval. The Profile Reviewer is appointed to the Application 3370 Area Directors and may either accept or reject the property 3371 registration. An accepted registration should be passed on by the 3372 Profile Reviewer to the IANA for inclusion in the official IANA 3373 profile registry. The registration may be rejected for any of the 3374 following reasons. 1) Insufficient comment period; 2) Consensus not 3375 reached; 3) Technical deficiencies raised on the list or elsewhere 3376 have not been addressed. The Profile Reviewer's decision to 3378 reject a property may be appealed by the proposer to the IESG, or the 3379 objections raised can be addressed by the proposer and the property 3380 resubmitted. 3382 7.3 Property Change Control 3384 Existing properties may be changed using the same process by which 3385 they were registered. 3387 1. Define the change 3389 2. Post the change 3391 3. Allow a comment period 3393 4. Submit the property for approval 3395 Note that the original author or any other interested party may 3396 propose a change to an existing property, but that such changes 3397 should only be proposed when there are serious omissions or errors in 3398 the published specification. The Profile Reviewer may object to a 3399 change if it is not backwards compatible, but is not required to do 3400 so. 3402 Property definitions can never be deleted from the IANA registry, but 3403 properties which are no longer believed to be useful can be declared 3404 OBSOLETE by a change to their "intended use" field. 3406 8. File extension 3408 The file extension of "vcs" is to be used to designate a file 3409 containing calendaring and scheduling information consistent with 3410 this MIME content type. 3412 9. Macintosh File Type Code 3414 The file type code of "vcal" is to be used in Apple MacIntosh 3415 operating system environments to designate a file containing 3416 calendaring and scheduling information consistent with this MIME 3417 media type. 3419 10. References 3421 The following document are referred to within this document. 3423 [ICMS] "Internet Calendaring Model Specification", Internet-Draft, 3424 July 1997, ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch-mod- 3425 00.txt. 3427 [ISO 8601] ISO 8601, "Data elements and interchange formats- - 3428 - 3429 Information interchange- - 3430 -Representation of dates and times", 3431 International Organization for Standardization, June, 1988. This 3432 standard is also addressed by the Internet Draft document 3433 ftp://ds.internic.net/internet-drafts/draft-newman-datetime-00.txt. 3435 [ISO 9070] ISO/IEC 9070, "Information Technology- - 3436 -SGML Support 3437 Facilities- - 3438 -Registration Procedures for Public Text Owner 3439 Identifiers", Second Edition, International Organization for 3440 Standardization, April, 1991. 3442 ITIP-1] "iCalendar Transport-Independent Interoperability Protocol 3443 (iTIP) - Part 1: Scheduling Events and Busytime", Internet-Draft, 3444 July 1997, http://www.imc.org/draft-ietf-calsch-itip-part1-00.txt. 3446 [ITIP-2] "iCalendar Transport-Independent Interoperability Protocol 3447 (iTIP) - Part 2: Scheduling To-dos", Internet-Draft, July 1997, 3448 http://www.imc.org/draft-ietf-calsch-itip-part2-00.txt. 3450 [ITIP-3] "iCalendar Transport-Independent Interoperability Protocol 3451 (iTIP) - Part 3: Scheduling Journal Entries", Internet-Draft, July 3452 1997, http://www.imc.org/draft-ietf-calsch-itip-part3-00.txt. 3454 [MIME DIR] Howes, T., Smith, M., "A MIME Content-Type for Directory 3455 Information", Internet-draft-ietf-asid-mime-direct-06.txt, July, 3456 1997. 3458 [RFC 822] Crocker, D., "Standard for the Format of ARPA Internet Text 3459 Messages", STD 11, RFC 822, August 1982. 3461 [RFC 1738] Berners-Lee, T., Masinter, L., McCahill, M., "Uniform 3462 Resource Locators (URL)", RFC 1738, December 1994. 3464 [RFC 1766] Alvestrand, H., "Tags for the Identification of 3465 Languages", March 1995. 3467 [RFC 1872] Levinson, E., "The MIME Multipart/Related Content-type," 3468 RFC 1872, December 1995. 3470 [RFC 2045] Freed, N., Borenstein, N., " Multipurpose Internet Mail 3471 Extensions (MIME) - Part One: Format of Internet Message Bodies", RFC 3472 2045, November 1996. 3474 [RFC 2046] Freed, N., Borenstein, N., " Multipurpose Internet Mail 3475 Extensions (MIME) - Part Two: Media Types", RFC 2046, November 1996. 3477 [RFC 2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME) - 3478 Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, 3479 November 1996. 3481 [RFC 2048] Freed, N., J. Klensin, J. Postel, "Multipurpose Internet 3482 Mail Extensions (MIME) - Part Four: Registration Procedures", RFC 3483 2048, January 1997. 3485 [UTF-8] "UTF-8, a transformation format of Unicode and ISO 3486 10646",Internet-Draft, July,1996, ftp://ftp.ietf.org/internet- 3487 drafts/draft-yergeau-utf8-01.txt. 3489 [VCARD] Internet Mail Consortium, "vCard - The Electronic Business 3490 Card Version 2.1", http://www.versit.com/pdi/vcard-21.txt, September 3491 18, 1996. 3493 [VCAL] Internet Mail Consortium, "vCalendar - The Electronic 3494 Calendaring and Scheduling Exchange Format", 3495 http://www.imc.org/pdi/vcal-10.txt, September 18, 1996. 3497 [XAPIA] "XAPIA CSA, Calendaring and Scheduling Application 3498 Programming Interface (CSA) Version 1.0", X.400 API Association, 3499 November 15, 1994. 3501 11. Acknowledgments 3503 A hearty thanks to the IETF Calendaring and Scheduling Working Group 3504 and also the following individuals who have participated in the 3505 drafting, review and discussion of this memo: 3507 Roland Alden, Harald T. Alvestrand, Eric Berman, Denis Bigorgne, John 3508 Binici, Bill Bliss, Steve Carter, Andre Courtemanche, Dave Crocker, 3509 Alec Dun, John Evans, Ross Finlayson, Randell Flink, Ned Freed, 3510 Patrik Falstrom, Chuck Grandgent, Mark Handley, Steve Hanna, Paul B. 3511 Hill, Paul Hoffman, Ross Hopson, Mark Horton, Bruce Kahn, C. Harald 3512 Koch, Don Lavange, Theodore Lorek, Steve Mansour, Skip Montanaro, 3513 Keith Moore, Cecil Murray, Chris Newman, John Noerenberg, Ralph 3514 Patterson, Pete Resnick, Keith Rhodes, Robert Ripberger, John Rose, 3515 Andras Salamar, Ted Schuh, Vinod Seraphin, Derrick Shadel, Ken Shan, 3516 Andrew Shuman, Steve Silverberg, William P. Spencer, Mark Towfiq, 3517 Robert Visnov, James L. Weiner, Mike Weston, William Wyatt. 3519 12. Author's Address 3521 The following address information is provided in a MIME-VCARD, 3522 Electronic Business Card, format. 3524 The authors of this draft are: 3526 BEGIN:VCARD 3527 FN:Frank Dawson 3528 ORG:Lotus Development Corporation 3529 ADR;WORK;POSTAL;PARCEL:;;6544 Battleford Drive; 3530 Raleigh;NC;27613-3502;USA 3531 TEL;WORK;MSG:+1-919-676-9515 3532 TEL;WORK;FAX:+1-919-676-9564 3533 EMAIL;INTERNET:fdawson@earthlink.net 3534 URL:http://home.earthlink.net/~fdawson 3535 END:VCARD 3537 BEGIN:VCARD 3538 FN:Derik Stenerson 3539 ORG:Microsoft Corporation 3540 ADR;WORK;POSTAL;PARCEL:;;One Microsoft Way; 3541 Redmond;WA;98052-6399;USA 3542 TEL;WORK;MSG:+1-206-936-5522 3543 TEL;WORK;FAX:+1-206-936-7329 3544 EMAIL;INTERNET:deriks@Exchange.Microsoft.com 3545 END:VCARD 3547 The iCalendar object is a result of the work of the Internet 3548 Engineering Task Force Calendaring and Scheduling Working Group. The 3549 chairman of that working group is: 3551 BEGIN:VCARD 3552 FN:Anik Ganguly 3553 ORG:OnTime, Inc. 3554 ADR;WORK;POSTAL;PARCEL:10 Floor;;21700 Northwestern Highway; 3555 Southfield;MI;48075;USA 3556 TEL;WORK;MSG:+1-810-559-5955 3557 TEL;WORK;FAX:+1-810-559-5034 3558 EMAIL;INTERNET:anik@ontime.com 3559 END:VCARD 3561 13. iCalendar Object Examples 3563 The following examples are provided as an informational source of 3564 illustrative iCalendar objects consistent with this content type. 3566 The following iCalendar object is specified as the content of a MIME 3567 message. The example demonstrates a possible meeting request between 3568 the originator and recipient of the message. 3570 TO:jsmith@host1.com 3571 FROM:jdoe@host1.com 3572 MIME-VERSION:2.0 3573 MESSAGE-ID:<19960704 08:30:00 EDT xyz@host1.com> 3574 CONTENT-TYPE:text/calendar;PROFILE=request-event 3576 BEGIN:VCALENDAR 3577 PROFILE:event-request 3578 PRODID:-//xyz Corp//NONSGML PDA Calendar Verson 1.0//EN 3579 VERSION:2.0 3580 BEGIN:VEVENT 3581 DTSTART:19960918T143000Z 3582 DTEND:19960920T220000Z 3583 CATEGORIES:CONFERENCE,PROJECT 3584 SUMMARY:Networld+Interop Conference 3585 DESCRIPTION;ENCODING=Q:Networld+Interop_Conference_ 3586 and_Exhibit=0D=0A 3587 Atlanta_World_Congress_Center=0D=0A 3588 Atlanta,_Georgia 3589 END:VEVENT 3590 END:VCALENDAR 3592 The following example message issues a meeting request that does not 3593 require any reply. The message is sent as a singular "text/calendar" 3594 content type, body part. 3596 From: jsmith@host1.com 3597 To: ietf-calendar@imc.org 3598 Subject: First IETF-Calendar Working Group Meeting 3599 MIME-Version: 2.0 3600 Message-ID: 3601 Content-Type: text/calendar;Profile=event,request 3603 BEGIN:VCALENDAR 3604 PROFILE:event-request 3605 PRODID:-//RDU Software//NONSGML HandCal//EN 3606 VERSION:2.0 3607 BEGIN:VEVENT 3608 ATTENDEE;EXPECT=REQUEST:ietf-calendar@imc.org 3609 DESCRIPTION:First IETF-Calendaring and Scheduling Working Group 3610 Meeting 3611 CATEGORIES:MEETING 3612 CLASS:PUBLIC 3613 CREATED:19961022T083000 3614 SUMMARY:IETF Calendaring Working Group Meeting 3615 DTSTART:19961210T210000Z 3616 DTEND:19961210T220000Z 3617 LOCATION:San Jose, CA - Fairmont Hotel 3618 UID:guid-1.host1.com 3619 END:VEVENT 3620 END:VCALENDAR 3622 The following is an example of a MIME message with a single body part 3623 consisting of a text/calendar content type. The message specifies a 3624 meeting request between the originator and recipient of the message. 3626 TO:jsmith@host1.com 3627 FROM:jdoe@host1.com 3628 MIME-VERSION:1.0 3629 MESSAGE-ID:<19970322 08:30:00 EDT xyz@host1.com> 3630 CONTENT-TYPE:text/calendar;PROFILE=event-request 3632 BEGIN:VCALENDAR 3633 PROFILE:event-request 3634 VERSION:2.0 3635 PRODID:-//ABC Corporation//NONSGML My Product//EN 3636 BEGIN:VEVENT 3637 SEQUENCE:0 3638 UID:19970324-080045-4000F192713-0052 3639 ATTENDEE;EXPECT=REQUEST:jsmith@host1.com 3640 DTSTART:19970324T123000Z 3641 DTEND:19970324T210000Z 3642 CATEGORIES:CONFERENCE,PROJECT 3643 CLASS:PUBLIC 3644 SUMMARY:Calendaring Interop Conference 3645 DESCRIPTION;ENCODING=Q:Calendaring_Interop_ 3646 Conference_and_Exhibit=0D=0A 3647 Atlanta,_Georgia 3648 LOCATION:Atlanta World Congress Center 3649 ATTACH;VALUE=URL:file://xyzCorp.com/conf/bkgrnd.ps 3650 END:VEVENT 3651 END:VCALENDAR 3653 Example of a reply to the above request, accepting the meeting. 3655 TO:jdoe@host1.com 3656 FROM:jsmith@host1.com 3657 MIME-VERSION:1.0 3658 MESSAGE-ID:<19970322 08:30:00 EDT xyz@host1.com> 3659 CONTENT-TYPE:text/calendar;PROFILE=event-reply 3661 BEGIN:VCALENDAR 3662 PROFILE:event-reply 3663 VERSION:2.0 3664 PRODID:-//ABC Corporation//NONSGML My Product//EN 3665 BEGIN:VEVENT 3666 SEQUENCE:0 3667 RESPONSE-SEQUENCE:0 3668 UID:19970324-080045-4000F192713-0052 3669 ATTENDEE;STATUS=CONFIRMED;EXPECT=REQUEST:jsmith@host1.com 3670 END:VEVENT 3671 END:VCALENDAR 3673 An example of a meeting cancelation: 3675 TO:jsmith@host1.com 3676 FROM:jdoe@host1.com 3677 MIME-VERSION:1.0 3678 MESSAGE-ID:<19970322 08:30:00 EDT xyz@host1.com> 3679 CONTENT-TYPE:text/calendar;PROFILE=event-cancel 3681 BEGIN:VCALENDAR 3682 PROFILE:event-cancel 3683 VERSION:2.0 3684 PRODID:-//ABC Corporation//NONSGML My Product//EN 3685 BEGIN:VEVENT 3686 UID:19970324-080045-4000F192713-0052 3687 END:VEVENT 3688 END:VCALENDAR