rfc2445.txt - libical - A simple ical library.
(HTM) git clone git://r-36.net/libical
(DIR) Log
(DIR) Files
(DIR) Refs
(DIR) README
(DIR) LICENSE
---
rfc2445.txt (291838B)
---
1
2
3
4
5
6
7 Network Working Group F. Dawson
8 Request for Comments: 2445 Lotus
9 Category: Standards Track D. Stenerson
10 Microsoft
11 November 1998
12
13
14 Internet Calendaring and Scheduling Core Object Specification
15 (iCalendar)
16
17 Status of this Memo
18
19 This document specifies an Internet standards track protocol for the
20 Internet community, and requests discussion and suggestions for
21 improvements. Please refer to the current edition of the "Internet
22 Official Protocol Standards" (STD 1) for the standardization state
23 and status of this protocol. Distribution of this memo is unlimited.
24
25 Copyright Notice
26
27 Copyright (C) The Internet Society (1998). All Rights Reserved.
28
29 Abstract
30
31 There is a clear need to provide and deploy interoperable calendaring
32 and scheduling services for the Internet. Current group scheduling
33 and Personal Information Management (PIM) products are being extended
34 for use across the Internet, today, in proprietary ways. This memo
35 has been defined to provide the definition of a common format for
36 openly exchanging calendaring and scheduling information across the
37 Internet.
38
39 This memo is formatted as a registration for a MIME media type per
40 [RFC 2048]. However, the format in this memo is equally applicable
41 for use outside of a MIME message content type.
42
43 The proposed media type value is 'text/calendar'. This string would
44 label a media type containing calendaring and scheduling information
45 encoded as text characters formatted in a manner outlined below.
46
47 This MIME media type provides a standard content type for capturing
48 calendar event, to-do and journal entry information. It also can be
49 used to convey free/busy time information. The content type is
50 suitable as a MIME message entity that can be transferred over MIME
51 based email systems, using HTTP or some other Internet transport. In
52
53
54
55
56
57
58 Dawson & Stenerson Standards Track [Page 1]
59
60 RFC 2445 iCalendar November 1998
61
62
63 addition, the content type is useful as an object for interactions
64 between desktop applications using the operating system clipboard,
65 drag/drop or file systems capabilities.
66
67 This memo is based on the earlier work of the vCalendar specification
68 for the exchange of personal calendaring and scheduling information.
69 In order to avoid confusion with this referenced work, this memo is
70 to be known as the iCalendar specification.
71
72 This memo defines the format for specifying iCalendar object methods.
73 An iCalendar object method is a set of usage constraints for the
74 iCalendar object. For example, these methods might define scheduling
75 messages that request an event be scheduled, reply to an event
76 request, send a cancellation notice for an event, modify or replace
77 the definition of an event, provide a counter proposal for an
78 original event request, delegate an event request to another
79 individual, request free or busy time, reply to a free or busy time
80 request, or provide similar scheduling messages for a to-do or
81 journal entry calendar component. The iCalendar Transport-indendent
82 Interoperability Protocol (iTIP) defined in [ITIP] is one such
83 scheduling protocol.
84
85 Table of Contents
86
87 1 Introduction.....................................................5
88 2 Basic Grammar and Conventions....................................6
89 2.1 Formatting Conventions .......................................7
90 2.2 Related Memos ................................................8
91 2.3 International Considerations .................................8
92 3 Registration Information.........................................8
93 3.1 Content Type .................................................8
94 3.2 Parameters ...................................................9
95 3.3 Content Header Fields .......................................10
96 3.4 Encoding Considerations .....................................10
97 3.5 Security Considerations .....................................10
98 3.6 Interoperability Considerations .............................11
99 3.7 Applications Which Use This Media Type ......................11
100 3.8 Additional Information ......................................11
101 3.9 Magic Numbers ...............................................11
102 3.10 File Extensions ............................................11
103 3.11 Contact for Further Information: ...........................12
104 3.12 Intended Usage .............................................12
105 3.13 Authors/Change Controllers .................................12
106 4 iCalendar Object Specification..................................13
107 4.1 Content Lines ...............................................13
108 4.1.1 List and Field Separators ................................16
109 4.1.2 Multiple Values ..........................................16
110 4.1.3 Binary Content ...........................................16
111
112
113
114 Dawson & Stenerson Standards Track [Page 2]
115
116 RFC 2445 iCalendar November 1998
117
118
119 4.1.4 Character Set ............................................17
120 4.2 Property Parameters .........................................17
121 4.2.1 Alternate Text Representation ............................18
122 4.2.2 Common Name ..............................................19
123 4.2.3 Calendar User Type .......................................20
124 4.2.4 Delegators ...............................................20
125 4.2.5 Delegatees ...............................................21
126 4.2.6 Directory Entry Reference ................................21
127 4.2.7 Inline Encoding ..........................................22
128 4.2.8 Format Type ..............................................23
129 4.2.9 Free/Busy Time Type ......................................23
130 4.2.10 Language ................................................24
131 4.2.11 Group or List Membership ................................25
132 4.2.12 Participation Status ....................................25
133 4.2.13 Recurrence Identifier Range .............................27
134 4.2.14 Alarm Trigger Relationship ..............................27
135 4.2.15 Relationship Type .......................................28
136 4.2.16 Participation Role ......................................29
137 4.2.17 RSVP Expectation ........................................29
138 4.2.18 Sent By .................................................30
139 4.2.19 Time Zone Identifier ....................................30
140 4.2.20 Value Data Types ........................................32
141 4.3 Property Value Data Types ...................................32
142 4.3.1 Binary ...................................................33
143 4.3.2 Boolean ..................................................33
144 4.3.3 Calendar User Address ....................................34
145 4.3.4 Date .....................................................34
146 4.3.5 Date-Time ................................................35
147 4.3.6 Duration .................................................37
148 4.3.7 Float ....................................................38
149 4.3.8 Integer ..................................................38
150 4.3.9 Period of Time ...........................................39
151 4.3.10 Recurrence Rule .........................................40
152 4.3.11 Text ....................................................45
153 4.3.12 Time ....................................................47
154 4.3.13 URI .....................................................49
155 4.3.14 UTC Offset ..............................................49
156 4.4 iCalendar Object ............................................50
157 4.5 Property ....................................................51
158 4.6 Calendar Components .........................................51
159 4.6.1 Event Component ..........................................52
160 4.6.2 To-do Component ..........................................55
161 4.6.3 Journal Component ........................................56
162 4.6.4 Free/Busy Component ......................................58
163 4.6.5 Time Zone Component ......................................60
164 4.6.6 Alarm Component ..........................................67
165 4.7 Calendar Properties .........................................73
166 4.7.1 Calendar Scale ...........................................73
167
168
169
170 Dawson & Stenerson Standards Track [Page 3]
171
172 RFC 2445 iCalendar November 1998
173
174
175 4.7.2 Method ...................................................74
176 4.7.3 Product Identifier .......................................75
177 4.7.4 Version ..................................................76
178 4.8 Component Properties ........................................77
179 4.8.1 Descriptive Component Properties .........................77
180 4.8.1.1 Attachment ...........................................77
181 4.8.1.2 Categories ...........................................78
182 4.8.1.3 Classification .......................................79
183 4.8.1.4 Comment ..............................................80
184 4.8.1.5 Description ..........................................81
185 4.8.1.6 Geographic Position ..................................82
186 4.8.1.7 Location .............................................84
187 4.8.1.8 Percent Complete .....................................85
188 4.8.1.9 Priority .............................................85
189 4.8.1.10 Resources ...........................................87
190 4.8.1.11 Status ..............................................88
191 4.8.1.12 Summary .............................................89
192 4.8.2 Date and Time Component Properties .......................90
193 4.8.2.1 Date/Time Completed ..................................90
194 4.8.2.2 Date/Time End ........................................91
195 4.8.2.3 Date/Time Due ........................................92
196 4.8.2.4 Date/Time Start ......................................93
197 4.8.2.5 Duration .............................................94
198 4.8.2.6 Free/Busy Time .......................................95
199 4.8.2.7 Time Transparency ....................................96
200 4.8.3 Time Zone Component Properties ...........................97
201 4.8.3.1 Time Zone Identifier .................................97
202 4.8.3.2 Time Zone Name .......................................98
203 4.8.3.3 Time Zone Offset From ................................99
204 4.8.3.4 Time Zone Offset To .................................100
205 4.8.3.5 Time Zone URL .......................................101
206 4.8.4 Relationship Component Properties .......................102
207 4.8.4.1 Attendee ............................................102
208 4.8.4.2 Contact .............................................104
209 4.8.4.3 Organizer ...........................................106
210 4.8.4.4 Recurrence ID .......................................107
211 4.8.4.5 Related To ..........................................109
212 4.8.4.6 Uniform Resource Locator ............................110
213 4.8.4.7 Unique Identifier ...................................111
214 4.8.5 Recurrence Component Properties .........................112
215 4.8.5.1 Exception Date/Times ................................112
216 4.8.5.2 Exception Rule ......................................114
217 4.8.5.3 Recurrence Date/Times ...............................115
218 4.8.5.4 Recurrence Rule .....................................117
219 4.8.6 Alarm Component Properties ..............................126
220 4.8.6.1 Action ..............................................126
221 4.8.6.2 Repeat Count ........................................126
222 4.8.6.3 Trigger .............................................127
223
224
225
226 Dawson & Stenerson Standards Track [Page 4]
227
228 RFC 2445 iCalendar November 1998
229
230
231 4.8.7 Change Management Component Properties ..................129
232 4.8.7.1 Date/Time Created ...................................129
233 4.8.7.2 Date/Time Stamp .....................................130
234 4.8.7.3 Last Modified .......................................131
235 4.8.7.4 Sequence Number .....................................131
236 4.8.8 Miscellaneous Component Properties ......................133
237 4.8.8.1 Non-standard Properties .............................133
238 4.8.8.2 Request Status ......................................134
239 5 iCalendar Object Examples......................................136
240 6 Recommended Practices..........................................140
241 7 Registration of Content Type Elements..........................141
242 7.1 Registration of New and Modified iCalendar Object Methods ..141
243 7.2 Registration of New Properties .............................141
244 7.2.1 Define the property .....................................142
245 7.2.2 Post the Property definition ............................143
246 7.2.3 Allow a comment period ..................................143
247 7.2.4 Submit the property for approval ........................143
248 7.3 Property Change Control ....................................143
249 8 References.....................................................144
250 9 Acknowledgments................................................145
251 10 Authors' and Chairs' Addresses................................146
252 11 Full Copyright Statement......................................148
253
254 1 Introduction
255
256 The use of calendaring and scheduling has grown considerably in the
257 last decade. Enterprise and inter-enterprise business has become
258 dependent on rapid scheduling of events and actions using this
259 information technology. However, the longer term growth of
260 calendaring and scheduling, is currently limited by the lack of
261 Internet standards for the message content types that are central to
262 these knowledgeware applications. This memo is intended to progress
263 the level of interoperability possible between dissimilar calendaring
264 and scheduling applications. This memo defines a MIME content type
265 for exchanging electronic calendaring and scheduling information. The
266 Internet Calendaring and Scheduling Core Object Specification, or
267 iCalendar, allows for the capture and exchange of information
268 normally stored within a calendaring and scheduling application; such
269 as a Personal Information Manager (PIM) or a Group Scheduling
270 product.
271
272 The iCalendar format is suitable as an exchange format between
273 applications or systems. The format is defined in terms of a MIME
274 content type. This will enable the object to be exchanged using
275 several transports, including but not limited to SMTP, HTTP, a file
276 system, desktop interactive protocols such as the use of a memory-
277 based clipboard or drag/drop interactions, point-to-point
278 asynchronous communication, wired-network transport, or some form of
279
280
281
282 Dawson & Stenerson Standards Track [Page 5]
283
284 RFC 2445 iCalendar November 1998
285
286
287 unwired transport such as infrared might also be used.
288
289 The memo also provides for the definition of iCalendar object methods
290 that will map this content type to a set of messages for supporting
291 calendaring and scheduling operations such as requesting, replying
292 to, modifying, and canceling meetings or appointments, to-dos and
293 journal entries. The iCalendar object methods can be used to define
294 other calendaring and scheduling operations such a requesting for and
295 replying with free/busy time data. Such a scheduling protocol is
296 defined in the iCalendar Transport-independent Interoperability
297 Protocol (iTIP) defined in [ITIP].
298
299 The memo also includes a formal grammar for the content type based on
300 the Internet ABNF defined in [RFC 2234]. This ABNF is required for
301 the implementation of parsers and to serve as the definitive
302 reference when ambiguities or questions arise in interpreting the
303 descriptive prose definition of the memo.
304
305 2 Basic Grammar and Conventions
306
307 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
308 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" and
309 "OPTIONAL" in this document are to be interoperated as described in
310 [RFC 2119].
311
312 This memo makes use of both a descriptive prose and a more formal
313 notation for defining the calendaring and scheduling format.
314
315 The notation used in this memo is the ABNF notation of [RFC 2234].
316 Readers intending on implementing this format defined in this memo
317 should be familiar with this notation in order to properly interpret
318 the specifications of this memo.
319
320 All numeric and hexadecimal values used in this memo are given in
321 decimal notation.
322
323 All names of properties, property parameters, enumerated property
324 values and property parameter values are case-insensitive. However,
325 all other property values are case-sensitive, unless otherwise
326 stated.
327
328 Note: All indented editorial notes, such as this one, are
329 intended to provide the reader with additional information. The
330 information is not essential to the building of an
331 implementation conformant with this memo. The information is
332 provided to highlight a particular feature or characteristic of
333 the memo.
334
335
336
337
338 Dawson & Stenerson Standards Track [Page 6]
339
340 RFC 2445 iCalendar November 1998
341
342
343 The format for the iCalendar object is based on the syntax of the
344 [RFC 2425] content type. While the iCalendar object is not a profile
345 of the [RFC 2425] content type, it does reuse a number of the
346 elements from the [RFC 2425] specification.
347
348 2.1 Formatting Conventions
349
350 The mechanisms defined in this memo are defined in prose. Many of the
351 terms used to describe these have common usage that is different than
352 the standards usage of this memo. In order to reference within this
353 memo elements of the calendaring and scheduling model, core object
354 (this memo) or interoperability protocol [ITIP] some formatting
355 conventions have been used. Calendaring and scheduling roles are
356 referred to in quoted-strings of text with the first character of
357 each word in upper case. For example, "Organizer" refers to a role of
358 a "Calendar User" within the scheduling protocol defined by [ITIP].
359 Calendar components defined by this memo are referred to with
360 capitalized, quoted-strings of text. All calendar components start
361 with the letter "V". For example, "VEVENT" refers to the event
362 calendar component, "VTODO" refers to the to-do calendar component
363 and "VJOURNAL" refers to the daily journal calendar component.
364 Scheduling methods defined by [ITIP] are referred to with
365 capitalized, quoted-strings of text. For example, "REQUEST" refers to
366 the method for requesting a scheduling calendar component be created
367 or modified, "REPLY" refers to the method a recipient of a request
368 uses to update their status with the "Organizer" of the calendar
369 component.
370
371 The properties defined by this memo are referred to with capitalized,
372 quoted-strings of text, followed by the word "property". For example,
373 "ATTENDEE" property refers to the iCalendar property used to convey
374 the calendar address of a calendar user. Property parameters defined
375 by this memo are referred to with lowercase, quoted-strings of text,
376 followed by the word "parameter". For example, "value" parameter
377 refers to the iCalendar property parameter used to override the
378 default data type for a property value. Enumerated values defined by
379 this memo are referred to with capitalized text, either alone or
380 followed by the word "value". For example, the "MINUTELY" value can
381 be used with the "FREQ" component of the "RECUR" data type to specify
382 repeating components based on an interval of one minute or more.
383
384
385
386
387
388
389
390
391
392
393
394 Dawson & Stenerson Standards Track [Page 7]
395
396 RFC 2445 iCalendar November 1998
397
398
399 2.2 Related Memos
400
401 Implementers will need to be familiar with several other memos that,
402 along with this memo, form a framework for Internet calendaring and
403 scheduling standards. This memo, [ICAL], specifies a core
404 specification of objects, data types, properties and property
405 parameters.
406
407 [ITIP] - specifies an interoperability protocol for scheduling
408 between different implementations;
409
410 [IMIP] specifies an Internet email binding for [ITIP].
411
412 This memo does not attempt to repeat the specification of concepts or
413 definitions from these other memos. Where possible, references are
414 made to the memo that provides for the specification of these
415 concepts or definitions.
416
417 2.3 International Considerations
418
419 In the rest of this document, descriptions of characters are of the
420 form "character name (codepoint)", where "codepoint" is from the US-
421 ASCII character set. The "character name" is the authoritative
422 description; (codepoint) is a reference to that character in US-ASCII
423 or US-ASCII compatible sets (for example the ISO-8859-x family, UTF-
424 8, ISO-2022-xx, KOI8-R). If a non-US-ASCII compatible character set
425 is used, appropriate code-point from that character set MUST be
426 chosen instead. Use of non-US-ASCII-compatible character sets is NOT
427 recommended.
428
429 3 Registration Information
430
431 The Calendaring and Scheduling Core Object Specification is intended
432 for use as a MIME content type. However, the implementation of the
433 memo is in no way limited solely as a MIME content type.
434
435 3.1 Content Type
436
437 The following text is intended to register this memo as the MIME
438 content type "text/calendar".
439
440 To: ietf-types@uninett.no
441
442 Subject: Registration of MIME content type text/calendar.
443
444 MIME media type name: text
445
446 MIME subtype name: calendar
447
448
449
450 Dawson & Stenerson Standards Track [Page 8]
451
452 RFC 2445 iCalendar November 1998
453
454
455 3.2 Parameters
456
457 Required parameters: none
458
459 Optional parameters: charset, method, component and optinfo
460
461 The "charset" parameter is defined in [RFC 2046] for other body
462 parts. It is used to identify the default character set used within
463 the body part.
464
465 The "method" parameter is used to convey the iCalendar object method
466 or transaction semantics for the calendaring and scheduling
467 information. It also is an identifier for the restricted set of
468 properties and values that the iCalendar object consists of. The
469 parameter is to be used as a guide for applications interpreting the
470 information contained within the body part. It SHOULD NOT be used to
471 exclude or require particular pieces of information unless the
472 identified method definition specifically calls for this behavior.
473 Unless specifically forbidden by a particular method definition, a
474 text/calendar content type can contain any set of properties
475 permitted by the Calendaring and Scheduling Core Object
476 Specification. The "method" parameter MUST be the same value as that
477 specified in the "METHOD" component property in the iCalendar object.
478 If one is present, the other MUST also be present.
479
480 The value for the "method" parameter is defined as follows:
481
482 method = 1*(ALPHA / DIGIT / "-")
483 ; IANA registered iCalendar object method
484
485 The "component" parameter conveys the type of iCalendar calendar
486 component within the body part. If the iCalendar object contains more
487 than one calendar component type, then multiple component parameters
488 MUST be specified.
489
490 The value for the "component" parameter is defined as follows:
491
492 component = ("VEVENT" / "VTODO" / "VJOURNAL" / "VFREEBUSY"
493 / "VTIMEZONE" / x-name / iana-token)
494
495 The "optinfo" parameter conveys optional information about the
496 iCalendar object within the body part. This parameter can only
497 specify semantics already specified by the iCalendar object and that
498 can be otherwise determined by parsing the body part. In addition,
499 the optional information specified by this parameter MUST be
500 consistent with that information specified by the iCalendar object.
501 For example, it can be used to convey the "Attendee" response status
502 to a meeting request. The parameter value consists of a string value.
503
504
505
506 Dawson & Stenerson Standards Track [Page 9]
507
508 RFC 2445 iCalendar November 1998
509
510
511 The parameter can be specified multiple times.
512
513 This parameter MAY only specify semantics already specified by the
514 iCalendar object and that can be otherwise determined by parsing the
515 body part.
516
517 The value for the "optinfo" parameter is defined as follows:
518
519 optinfo = infovalue / qinfovalue
520
521 infovalue = iana-token / x-name
522
523 qinfovalue = DQUOTE (infovalue) DQUOTE
524
525 3.3 Content Header Fields
526
527 Optional content header fields: Any header fields defined by [RFC
528 2045].
529
530 3.4 Encoding Considerations
531
532 This MIME content type can contain 8bit characters, so the use of
533 quoted-printable or BASE64 MIME content-transfer-encodings might be
534 necessary when iCalendar objects are transferred across protocols
535 restricted to the 7bit repertoire. Note that a text valued property
536 in the content entity can also have content encoding of special
537 characters using a BACKSLASH character (US-ASCII decimal 92)
538 escapement technique. This means that content values can end up
539 encoded twice.
540
541 3.5 Security Considerations
542
543 SPOOFING - - In this memo, the "Organizer" is the only person
544 authorized to make changes to an existing "VEVENT", "VTODO",
545 "VJOURNAL" calendar component and redistribute the updates to the
546 "Attendees". An iCalendar object that maliciously changes or cancels
547 an existing "VEVENT", "VTODO" or "VJOURNAL" or "VFREEBUSY" calendar
548 component might be constructed by someone other than the "Organizer"
549 and sent to the "Attendees". In addition in this memo, other than the
550 "Organizer", an "Attendee" of a "VEVENT", "VTODO", "VJOURNAL"
551 calendar component is the only other person authorized to update any
552 parameter associated with their "ATTENDEE" property and send it to
553 the "Organizer". An iCalendar object that maliciously changes the
554 "ATTENDEE" parameters can be constructed by someone other than the
555 real "Attendee" and sent to the "Organizer".
556
557
558
559
560
561
562 Dawson & Stenerson Standards Track [Page 10]
563
564 RFC 2445 iCalendar November 1998
565
566
567 PROCEDURAL ALARMS - - An iCalendar object can be created that
568 contains a "VEVENT" and "VTODO" calendar component with "VALARM"
569 calendar components. The "VALARM" calendar component can be of type
570 PROCEDURE and can have an attachment containing some sort of
571 executable program. Implementations that incorporate these types of
572 alarms are subject to any virus or malicious attack that might occur
573 as a result of executing the attachment.
574
575 ATTACHMENTS - - An iCalendar object can include references to Uniform
576 Resource Locators that can be programmed resources.
577
578 Implementers and users of this memo should be aware of the network
579 security implications of accepting and parsing such information. In
580 addition, the security considerations observed by implementations of
581 electronic mail systems should be followed for this memo.
582
583 3.6 Interoperability Considerations
584
585 This MIME content type is intended to define a common format for
586 conveying calendaring and scheduling information between different
587 systems. It is heavily based on the earlier [VCAL] industry
588 specification.
589
590 3.7 Applications Which Use This Media Type
591
592 This content-type is designed for widespread use by Internet
593 calendaring and scheduling applications. In addition, applications in
594 the workflow and document management area might find this content-
595 type applicable. The [ITIP] and [IMIP] Internet protocols directly
596 use this content-type also. Future work on an Internet calendar
597 access protocol will utilize this content-type too.
598
599 3.8 Additional Information
600
601 This memo defines this content-type.
602
603 3.9 Magic Numbers
604
605 None.
606
607 3.10 File Extensions
608
609 The file extension of "ics" is to be used to designate a file
610 containing (an arbitrary set of) calendaring and scheduling
611 information consistent with this MIME content type.
612
613
614
615
616
617
618 Dawson & Stenerson Standards Track [Page 11]
619
620 RFC 2445 iCalendar November 1998
621
622
623 The file extension of "ifb" is to be used to designate a file
624 containing free or busy time information consistent with this MIME
625 content type.
626
627 Macintosh file type codes: The file type code of "iCal" is to be used
628 in Apple MacIntosh operating system environments to designate a file
629 containing calendaring and scheduling information consistent with
630 this MIME media type.
631
632 The file type code of "iFBf" is to be used in Apple MacIntosh
633 operating system environments to designate a file containing free or
634 busy time information consistent with this MIME media type.
635
636 3.11 Contact for Further Information:
637
638 Frank Dawson
639 6544 Battleford Drive
640 Raleigh, NC 27613-3502
641 919-676-9515 (Telephone)
642 919-676-9564 (Data/Facsimile)
643 Frank_Dawson@Lotus.com (Internet Mail)
644
645 Derik Stenerson
646 One Microsoft Way
647 Redmond, WA 98052-6399
648 425-936-5522 (Telephone)
649 425-936-7329 (Facsimile)
650 deriks@microsoft.com (Internet Mail)
651
652 3.12 Intended Usage
653
654 COMMON
655
656 3.13 Authors/Change Controllers
657
658 Frank Dawson
659 6544 Battleford Drive
660 Raleigh, NC 27613-3502
661 919-676-9515 (Telephone)
662 919-676-9564 (Data/Facsimile)
663 Frank_Dawson@Lotus.com (Internet Mail)
664
665 Derik Stenerson
666 One Microsoft Way
667 Redmond, WA 98052-6399
668 425-936-5522 (Telephone)
669 425-936-7329 (Facsimile)
670 deriks@microsoft.com (Internet Mail)
671
672
673
674 Dawson & Stenerson Standards Track [Page 12]
675
676 RFC 2445 iCalendar November 1998
677
678
679 4 iCalendar Object Specification
680
681 The following sections define the details of a Calendaring and
682 Scheduling Core Object Specification. This information is intended to
683 be an integral part of the MIME content type registration. In
684 addition, this information can be used independent of such content
685 registration. In particular, this memo has direct applicability for
686 use as a calendaring and scheduling exchange format in file-, memory-
687 or network-based transport mechanisms.
688
689 4.1 Content Lines
690
691 The iCalendar object is organized into individual lines of text,
692 called content lines. Content lines are delimited by a line break,
693 which is a CRLF sequence (US-ASCII decimal 13, followed by US-ASCII
694 decimal 10).
695
696 Lines of text SHOULD NOT be longer than 75 octets, excluding the line
697 break. Long content lines SHOULD be split into a multiple line
698 representations using a line "folding" technique. That is, a long
699 line can be split between any two characters by inserting a CRLF
700 immediately followed by a single linear white space character (i.e.,
701 SPACE, US-ASCII decimal 32 or HTAB, US-ASCII decimal 9). Any sequence
702 of CRLF followed immediately by a single linear white space character
703 is ignored (i.e., removed) when processing the content type.
704
705 For example the line:
706
707 DESCRIPTION:This is a long description that exists on a long line.
708
709 Can be represented as:
710
711 DESCRIPTION:This is a lo
712 ng description
713 that exists on a long line.
714
715 The process of moving from this folded multiple line representation
716 to its single line representation is called "unfolding". Unfolding is
717 accomplished by removing the CRLF character and the linear white
718 space character that immediately follows.
719
720 When parsing a content line, folded lines MUST first be unfolded
721 according to the unfolding procedure described above. When generating
722 a content line, lines longer than 75 octets SHOULD be folded
723 according to the folding procedure described above.
724
725
726
727
728
729
730 Dawson & Stenerson Standards Track [Page 13]
731
732 RFC 2445 iCalendar November 1998
733
734
735 The content information associated with an iCalendar object is
736 formatted using a syntax similar to that defined by [RFC 2425]. That
737 is, the content information consists of CRLF-separated content lines.
738
739 The following notation defines the lines of content in an iCalendar
740 object:
741
742 contentline = name *(";" param ) ":" value CRLF
743 ; This ABNF is just a general definition for an initial parsing
744 ; of the content line into its property name, parameter list,
745 ; and value string
746
747 ; When parsing a content line, folded lines MUST first
748 ; be unfolded according to the unfolding procedure
749 ; described above. When generating a content line, lines
750 ; longer than 75 octets SHOULD be folded according to
751 ; the folding procedure described above.
752
753 name = x-name / iana-token
754
755 iana-token = 1*(ALPHA / DIGIT / "-")
756 ; iCalendar identifier registered with IANA
757
758 x-name = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-")
759 ; Reservered for experimental use. Not intended for use in
760 ; released products.
761
762 vendorid = 3*(ALPHA / DIGIT) ;Vendor identification
763
764 param = param-name "=" param-value
765 *("," param-value)
766 ; Each property defines the specific ABNF for the parameters
767 ; allowed on the property. Refer to specific properties for
768 ; precise parameter ABNF.
769
770 param-name = iana-token / x-token
771
772 param-value = paramtext / quoted-string
773
774 paramtext = *SAFE-CHAR
775
776 value = *VALUE-CHAR
777
778 quoted-string = DQUOTE *QSAFE-CHAR DQUOTE
779
780 NON-US-ASCII = %x80-F8
781 ; Use restricted by charset parameter
782 ; on outer MIME object (UTF-8 preferred)
783
784
785
786 Dawson & Stenerson Standards Track [Page 14]
787
788 RFC 2445 iCalendar November 1998
789
790
791 QSAFE-CHAR = WSP / %x21 / %x23-7E / NON-US-ASCII
792 ; Any character except CTLs and DQUOTE
793
794 SAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E
795 / NON-US-ASCII
796 ; Any character except CTLs, DQUOTE, ";", ":", ","
797
798 VALUE-CHAR = WSP / %x21-7E / NON-US-ASCII
799 ; Any textual character
800
801 CR = %x0D
802 ; carriage return
803
804 LF = %x0A
805 ; line feed
806
807 CRLF = CR LF
808 ; Internet standard newline
809
810 CTL = %x00-08 / %x0A-1F / %x7F
811 ; Controls
812
813 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
814
815 DIGIT = %x30-39
816 ; 0-9
817
818 DQUOTE = %x22
819 ; Quotation Mark
820
821 WSP = SPACE / HTAB
822
823 SPACE = %x20
824
825 HTAB = %x09
826
827 The property value component of a content line has a format that is
828 property specific. Refer to the section describing each property for
829 a definition of this format.
830
831 All names of properties, property parameters, enumerated property
832 values and property parameter values are case-insensitive. However,
833 all other property values are case-sensitive, unless otherwise
834 stated.
835
836
837
838
839
840
841
842 Dawson & Stenerson Standards Track [Page 15]
843
844 RFC 2445 iCalendar November 1998
845
846
847 4.1.1 List and Field Separators
848
849 Some properties and parameters allow a list of values. Values in a
850 list of values MUST be separated by a COMMA character (US-ASCII
851 decimal 44). There is no significance to the order of values in a
852 list. For those parameter values (such as those that specify URI
853 values) that are specified in quoted-strings, the individual quoted-
854 strings are separated by a COMMA character (US-ASCII decimal 44).
855
856 Some property values are defined in terms of multiple parts. These
857 structured property values MUST have their value parts separated by a
858 SEMICOLON character (US-ASCII decimal 59).
859
860 Some properties allow a list of parameters. Each property parameter
861 in a list of property parameters MUST be separated by a SEMICOLON
862 character (US-ASCII decimal 59).
863
864 Property parameters with values containing a COLON, a SEMICOLON or a
865 COMMA character MUST be placed in quoted text.
866
867 For example, in the following properties a SEMICOLON is used to
868 separate property parameters from each other, and a COMMA is used to
869 separate property values in a value list.
870
871 ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT:MAILTO:
872 jsmith@host.com
873
874 RDATE;VALUE=DATE:19970304,19970504,19970704,19970904
875
876 4.1.2 Multiple Values
877
878 Some properties defined in the iCalendar object can have multiple
879 values. The general rule for encoding multi-valued items is to simply
880 create a new content line for each value, including the property
881 name. However, it should be noted that some properties support
882 encoding multiple values in a single property by separating the
883 values with a COMMA character (US-ASCII decimal 44). Individual
884 property definitions should be consulted for determining whether a
885 specific property allows multiple values and in which of these two
886 forms.
887
888 4.1.3 Binary Content
889
890 Binary content information in an iCalendar object SHOULD be
891 referenced using a URI within a property value. That is the binary
892 content information SHOULD be placed in an external MIME entity that
893 can be referenced by a URI from within the iCalendar object. In
894 applications where this is not feasible, binary content information
895
896
897
898 Dawson & Stenerson Standards Track [Page 16]
899
900 RFC 2445 iCalendar November 1998
901
902
903 can be included within an iCalendar object, but only after first
904 encoding it into text using the "BASE64" encoding method defined in
905 [RFC 2045]. Inline binary contact SHOULD only be used in applications
906 whose special circumstances demand that an iCalendar object be
907 expressed as a single entity. A property containing inline binary
908 content information MUST specify the "ENCODING" property parameter.
909 Binary content information placed external to the iCalendar object
910 MUST be referenced by a uniform resource identifier (URI).
911
912 The following example specifies an "ATTACH" property that references
913 an attachment external to the iCalendar object with a URI reference:
914
915 ATTACH:http://xyz.com/public/quarterly-report.doc
916
917 The following example specifies an "ATTACH" property with inline
918 binary encoded content information:
919
920 ATTACH;FMTTYPE=image/basic;ENCODING=BASE64;VALUE=BINARY:
921 MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1U
922 EBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIE
923 <...remainder of "BASE64" encoded binary data...>
924
925 4.1.4 Character Set
926
927 There is not a property parameter to declare the character set used
928 in a property value. The default character set for an iCalendar
929 object is UTF-8 as defined in [RFC 2279].
930
931 The "charset" Content-Type parameter can be used in MIME transports
932 to specify any other IANA registered character set.
933
934 4.2 Property Parameters
935
936 A property can have attributes associated with it. These "property
937 parameters" contain meta-information about the property or the
938 property value. Property parameters are provided to specify such
939 information as the location of an alternate text representation for a
940 property value, the language of a text property value, the data type
941 of the property value and other attributes.
942
943 Property parameter values that contain the COLON (US-ASCII decimal
944 58), SEMICOLON (US-ASCII decimal 59) or COMMA (US-ASCII decimal 44)
945 character separators MUST be specified as quoted-string text values.
946 Property parameter values MUST NOT contain the DOUBLE-QUOTE (US-ASCII
947 decimal 22) character. The DOUBLE-QUOTE (US-ASCII decimal 22)
948 character is used as a delimiter for parameter values that contain
949 restricted characters or URI text. For example:
950
951
952
953
954 Dawson & Stenerson Standards Track [Page 17]
955
956 RFC 2445 iCalendar November 1998
957
958
959 DESCRIPTION;ALTREP="http://www.wiz.org":The Fall'98 Wild Wizards
960 Conference - - Las Vegas, NV, USA
961
962 Property parameter values that are not in quoted strings are case
963 insensitive.
964
965 The general property parameters defined by this memo are defined by
966 the following notation:
967
968 parameter = altrepparam ; Alternate text representation
969 / cnparam ; Common name
970 / cutypeparam ; Calendar user type
971 / delfromparam ; Delegator
972 / deltoparam ; Delegatee
973 / dirparam ; Directory entry
974 / encodingparam ; Inline encoding
975 / fmttypeparam ; Format type
976 / fbtypeparam ; Free/busy time type
977 / languageparam ; Language for text
978 / memberparam ; Group or list membership
979 / partstatparam ; Participation status
980 / rangeparam ; Recurrence identifier range
981 / trigrelparam ; Alarm trigger relationship
982 / reltypeparam ; Relationship type
983 / roleparam ; Participation role
984 / rsvpparam ; RSVP expectation
985 / sentbyparam ; Sent by
986 / tzidparam ; Reference to time zone object
987 / valuetypeparam ; Property value data type
988 / ianaparam
989 ; Some other IANA registered iCalendar parameter.
990 / xparam
991 ; A non-standard, experimental parameter.
992
993 ianaparam = iana-token "=" param-value *("," param-value)
994
995 xparam =x-name "=" param-value *("," param-value)
996
997 4.2.1 Alternate Text Representation
998
999 Parameter Name: ALTREP
1000
1001 Purpose: To specify an alternate text representation for the property
1002 value.
1003
1004 Format Definition: The property parameter is defined by the following
1005 notation:
1006
1007
1008
1009
1010 Dawson & Stenerson Standards Track [Page 18]
1011
1012 RFC 2445 iCalendar November 1998
1013
1014
1015 altrepparam = "ALTREP" "=" DQUOTE uri DQUOTE
1016
1017 Description: The parameter specifies a URI that points to an
1018 alternate representation for a textual property value. A property
1019 specifying this parameter MUST also include a value that reflects the
1020 default representation of the text value. The individual URI
1021 parameter values MUST each be specified in a quoted-string.
1022
1023 Example:
1024
1025 DESCRIPTION;ALTREP="CID:<part3.msg.970415T083000@host.com>":Project
1026 XYZ Review Meeting will include the following agenda items: (a)
1027 Market Overview, (b) Finances, (c) Project Management
1028
1029 The "ALTREP" property parameter value might point to a "text/html"
1030 content portion.
1031
1032 Content-Type:text/html
1033 Content-Id:<part3.msg.970415T083000@host.com>
1034
1035 <html><body>
1036 <p><b>Project XYZ Review Meeting</b> will include the following
1037 agenda items:<ol><li>Market
1038 Overview</li><li>Finances</li><li>Project Management</li></ol></p>
1039 </body></html>
1040
1041 4.2.2 Common Name
1042
1043 Parameter Name: CN
1044
1045 Purpose: To specify the common name to be associated with the
1046 calendar user specified by the property.
1047
1048 Format Definition: The property parameter is defined by the following
1049 notation:
1050
1051 cnparam = "CN" "=" param-value
1052
1053 Description: This parameter can be specified on properties with a
1054 CAL-ADDRESS value type. The parameter specifies the common name to be
1055 associated with the calendar user specified by the property. The
1056 parameter value is text. The parameter value can be used for display
1057 text to be associated with the calendar address specified by the
1058 property.
1059
1060
1061
1062
1063
1064
1065
1066 Dawson & Stenerson Standards Track [Page 19]
1067
1068 RFC 2445 iCalendar November 1998
1069
1070
1071 Example:
1072
1073 ORGANIZER;CN="John Smith":MAILTO:jsmith@host.com
1074
1075 4.2.3 Calendar User Type
1076
1077 Parameter Name: CUTYPE
1078
1079 Purpose: To specify the type of calendar user specified by the
1080 property.
1081
1082 Format Definition: The property parameter is defined by the following
1083 notation:
1084
1085 cutypeparam = "CUTYPE" "="
1086 ("INDIVIDUAL" ; An individual
1087 / "GROUP" ; A group of individuals
1088 / "RESOURCE" ; A physical resource
1089 / "ROOM" ; A room resource
1090 / "UNKNOWN" ; Otherwise not known
1091 / x-name ; Experimental type
1092 / iana-token) ; Other IANA registered
1093 ; type
1094 ; Default is INDIVIDUAL
1095
1096 Description: This parameter can be specified on properties with a
1097 CAL-ADDRESS value type. The parameter identifies the type of calendar
1098 user specified by the property. If not specified on a property that
1099 allows this parameter, the default is INDIVIDUAL.
1100
1101 Example:
1102
1103 ATTENDEE;CUTYPE=GROUP:MAILTO:ietf-calsch@imc.org
1104
1105 4.2.4 Delegators
1106
1107 Parameter Name: DELEGATED-FROM
1108
1109 Purpose: To specify the calendar users that have delegated their
1110 participation to the calendar user specified by the property.
1111
1112 Format Definition: The property parameter is defined by the following
1113 notation:
1114
1115 delfromparam = "DELEGATED-FROM" "=" DQUOTE cal-address DQUOTE
1116 *("," DQUOTE cal-address DQUOTE)
1117
1118
1119
1120
1121
1122 Dawson & Stenerson Standards Track [Page 20]
1123
1124 RFC 2445 iCalendar November 1998
1125
1126
1127 Description: This parameter can be specified on properties with a
1128 CAL-ADDRESS value type. This parameter can be specified on a property
1129 that has a value type of calendar address. This parameter specifies
1130 those calendar uses that have delegated their participation in a
1131 group scheduled event or to-do to the calendar user specified by the
1132 property. The value MUST be a MAILTO URI as defined in [RFC 1738].
1133 The individual calendar address parameter values MUST each be
1134 specified in a quoted-string.
1135
1136 Example:
1137
1138 ATTENDEE;DELEGATED-FROM="MAILTO:jsmith@host.com":MAILTO:
1139 jdoe@host.com
1140
1141 4.2.5 Delegatees
1142
1143 Parameter Name: DELEGATED-TO
1144
1145 Purpose: To specify the calendar users to whom the calendar user
1146 specified by the property has delegated participation.
1147
1148 Format Definition: The property parameter is defined by the following
1149 notation:
1150
1151 deltoparam = "DELEGATED-TO" "=" DQUOTE cal-address DQUOTE
1152 *("," DQUOTE cal-address DQUOTE)
1153
1154 Description: This parameter can be specified on properties with a
1155 CAL-ADDRESS value type. This parameter specifies those calendar users
1156 whom have been delegated participation in a group scheduled event or
1157 to-do by the calendar user specified by the property. The value MUST
1158 be a MAILTO URI as defined in [RFC 1738]. The individual calendar
1159 address parameter values MUST each be specified in a quoted-string.
1160
1161 Example:
1162
1163 ATTENDEE;DELEGATED-TO="MAILTO:jdoe@host.com","MAILTO:jqpublic@
1164 host.com":MAILTO:jsmith@host.com
1165
1166 4.2.6 Directory Entry Reference
1167
1168 Parameter Name: DIR
1169
1170 Purpose: To specify reference to a directory entry associated with
1171 the calendar user specified by the property.
1172
1173 Format Definition: The property parameter is defined by the following
1174 notation:
1175
1176
1177
1178 Dawson & Stenerson Standards Track [Page 21]
1179
1180 RFC 2445 iCalendar November 1998
1181
1182
1183 dirparam = "DIR" "=" DQUOTE uri DQUOTE
1184
1185 Description: This parameter can be specified on properties with a
1186 CAL-ADDRESS value type. The parameter specifies a reference to the
1187 directory entry associated with the calendar user specified by the
1188 property. The parameter value is a URI. The individual URI parameter
1189 values MUST each be specified in a quoted-string.
1190
1191 Example:
1192
1193 ORGANIZER;DIR="ldap://host.com:6666/o=eDABC%20Industries,c=3DUS??
1194 (cn=3DBJim%20Dolittle)":MAILTO:jimdo@host1.com
1195
1196 4.2.7 Inline Encoding
1197
1198 Parameter Name: ENCODING
1199
1200 Purpose: To specify an alternate inline encoding for the property
1201 value.
1202
1203 Format Definition: The property parameter is defined by the following
1204 notation:
1205
1206 encodingparam = "ENCODING" "="
1207 ("8BIT"
1208 ; "8bit" text encoding is defined in [RFC 2045]
1209 / "BASE64"
1210 ; "BASE64" binary encoding format is defined in [RFC 2045]
1211 / iana-token
1212 ; Some other IANA registered iCalendar encoding type
1213 / x-name)
1214 ; A non-standard, experimental encoding type
1215
1216 Description: The property parameter identifies the inline encoding
1217 used in a property value. The default encoding is "8BIT",
1218 corresponding to a property value consisting of text. The "BASE64"
1219 encoding type corresponds to a property value encoded using the
1220 "BASE64" encoding defined in [RFC 2045].
1221
1222 If the value type parameter is ";VALUE=BINARY", then the inline
1223 encoding parameter MUST be specified with the value
1224 ";ENCODING=BASE64".
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234 Dawson & Stenerson Standards Track [Page 22]
1235
1236 RFC 2445 iCalendar November 1998
1237
1238
1239 Example:
1240
1241 ATTACH;FMTYPE=IMAGE/JPEG;ENCODING=BASE64;VALUE=BINARY:MIICajC
1242 CAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDA
1243 qBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMRw
1244 <...remainder of "BASE64" encoded binary data...>
1245
1246 4.2.8 Format Type
1247
1248 Parameter Name: FMTTYPE
1249
1250 Purpose: To specify the content type of a referenced object.
1251
1252 Format Definition: The property parameter is defined by the following
1253 notation:
1254
1255 fmttypeparam = "FMTTYPE" "=" iana-token
1256 ; A IANA registered content type
1257 / x-name
1258 ; A non-standard content type
1259
1260 Description: This parameter can be specified on properties that are
1261 used to reference an object. The parameter specifies the content type
1262 of the referenced object. For example, on the "ATTACH" property, a
1263 FTP type URI value does not, by itself, necessarily convey the type
1264 of content associated with the resource. The parameter value MUST be
1265 the TEXT for either an IANA registered content type or a non-standard
1266 content type.
1267
1268 Example:
1269
1270 ATTACH;FMTTYPE=application/binary:ftp://domain.com/pub/docs/
1271 agenda.doc
1272
1273 4.2.9 Free/Busy Time Type
1274
1275 Parameter Name: FBTYPE
1276
1277 Purpose: To specify the free or busy time type.
1278
1279 Format Definition: The property parameter is defined by the following
1280 notation:
1281
1282 fbtypeparam = "FBTYPE" "=" ("FREE" / "BUSY"
1283 / "BUSY-UNAVAILABLE" / "BUSY-TENTATIVE"
1284 / x-name
1285 ; Some experimental iCalendar data type.
1286 / iana-token)
1287
1288
1289
1290 Dawson & Stenerson Standards Track [Page 23]
1291
1292 RFC 2445 iCalendar November 1998
1293
1294
1295 ; Some other IANA registered iCalendar data type.
1296
1297 Description: The parameter specifies the free or busy time type. The
1298 value FREE indicates that the time interval is free for scheduling.
1299 The value BUSY indicates that the time interval is busy because one
1300 or more events have been scheduled for that interval. The value
1301 BUSY-UNAVAILABLE indicates that the time interval is busy and that
1302 the interval can not be scheduled. The value BUSY-TENTATIVE indicates
1303 that the time interval is busy because one or more events have been
1304 tentatively scheduled for that interval. If not specified on a
1305 property that allows this parameter, the default is BUSY.
1306
1307 Example: The following is an example of this parameter on a FREEBUSY
1308 property.
1309
1310 FREEBUSY;FBTYPE=BUSY:19980415T133000Z/19980415T170000Z
1311
1312 4.2.10 Language
1313
1314 Parameter Name: LANGUAGE
1315
1316 Purpose: To specify the language for text values in a property or
1317 property parameter.
1318
1319 Format Definition: The property parameter is defined by the following
1320 notation:
1321
1322 languageparam = "LANGUAGE" "=" language
1323
1324 language = <Text identifying a language, as defined in [RFC 1766]>
1325
1326 Description: This parameter can be specified on properties with a
1327 text value type. The parameter identifies the language of the text in
1328 the property or property parameter value. The value of the "language"
1329 property parameter is that defined in [RFC 1766].
1330
1331 For transport in a MIME entity, the Content-Language header field can
1332 be used to set the default language for the entire body part.
1333 Otherwise, no default language is assumed.
1334
1335 Example:
1336
1337 SUMMARY;LANGUAGE=us-EN:Company Holiday Party
1338
1339 LOCATION;LANGUAGE=en:Germany
1340 LOCATION;LANGUAGE=no:Tyskland
1341
1342
1343
1344
1345
1346 Dawson & Stenerson Standards Track [Page 24]
1347
1348 RFC 2445 iCalendar November 1998
1349
1350
1351 The following example makes use of the Quoted-Printable encoding in
1352 order to represent non-ASCII characters.
1353
1354 LOCATION;LANGUAGE=da:K=F8benhavn
1355 LOCATION;LANGUAGE=en:Copenhagen
1356
1357 4.2.11 Group or List Membership
1358
1359 Parameter Name: MEMBER
1360
1361 Purpose: To specify the group or list membership of the calendar user
1362 specified by the property.
1363
1364 Format Definition: The property parameter is defined by the following
1365 notation:
1366
1367 memberparam = "MEMBER" "=" DQUOTE cal-address DQUOTE
1368 *("," DQUOTE cal-address DQUOTE)
1369
1370 Description: This parameter can be specified on properties with a
1371 CAL-ADDRESS value type. The parameter identifies the groups or list
1372 membership for the calendar user specified by the property. The
1373 parameter value either a single calendar address in a quoted-string
1374 or a COMMA character (US-ASCII decimal 44) list of calendar
1375 addresses, each in a quoted-string. The individual calendar address
1376 parameter values MUST each be specified in a quoted-string.
1377
1378 Example:
1379
1380 ATTENDEE;MEMBER="MAILTO:ietf-calsch@imc.org":MAILTO:jsmith@host.com
1381
1382 ATTENDEE;MEMBER="MAILTO:projectA@host.com","MAILTO:projectB@host.
1383 com":MAILTO:janedoe@host.com
1384
1385 4.2.12 Participation Status
1386
1387 Parameter Name: PARTSTAT
1388
1389 Purpose: To specify the participation status for the calendar user
1390 specified by the property.
1391
1392 Format Definition: The property parameter is defined by the following
1393 notation:
1394
1395 partstatparam = "PARTSTAT" "="
1396 ("NEEDS-ACTION" ; Event needs action
1397 / "ACCEPTED" ; Event accepted
1398 / "DECLINED" ; Event declined
1399
1400
1401
1402 Dawson & Stenerson Standards Track [Page 25]
1403
1404 RFC 2445 iCalendar November 1998
1405
1406
1407 / "TENTATIVE" ; Event tentatively
1408 ; accepted
1409 / "DELEGATED" ; Event delegated
1410 / x-name ; Experimental status
1411 / iana-token) ; Other IANA registered
1412 ; status
1413 ; These are the participation statuses for a "VEVENT". Default is
1414 ; NEEDS-ACTION
1415 partstatparam /= "PARTSTAT" "="
1416 ("NEEDS-ACTION" ; To-do needs action
1417 / "ACCEPTED" ; To-do accepted
1418 / "DECLINED" ; To-do declined
1419 / "TENTATIVE" ; To-do tentatively
1420 ; accepted
1421 / "DELEGATED" ; To-do delegated
1422 / "COMPLETED" ; To-do completed.
1423 ; COMPLETED property has
1424 ;date/time completed.
1425 / "IN-PROCESS" ; To-do in process of
1426 ; being completed
1427 / x-name ; Experimental status
1428 / iana-token) ; Other IANA registered
1429 ; status
1430 ; These are the participation statuses for a "VTODO". Default is
1431 ; NEEDS-ACTION
1432
1433 partstatparam /= "PARTSTAT" "="
1434 ("NEEDS-ACTION" ; Journal needs action
1435 / "ACCEPTED" ; Journal accepted
1436 / "DECLINED" ; Journal declined
1437 / x-name ; Experimental status
1438 / iana-token) ; Other IANA registered
1439 ; status
1440 ; These are the participation statuses for a "VJOURNAL". Default is
1441 ; NEEDS-ACTION
1442
1443 Description: This parameter can be specified on properties with a
1444 CAL-ADDRESS value type. The parameter identifies the participation
1445 status for the calendar user specified by the property value. The
1446 parameter values differ depending on whether they are associated with
1447 a group scheduled "VEVENT", "VTODO" or "VJOURNAL". The values MUST
1448 match one of the values allowed for the given calendar component. If
1449 not specified on a property that allows this parameter, the default
1450 value is NEEDS-ACTION.
1451
1452 Example:
1453
1454 ATTENDEE;PARTSTAT=DECLINED:MAILTO:jsmith@host.com
1455
1456
1457
1458 Dawson & Stenerson Standards Track [Page 26]
1459
1460 RFC 2445 iCalendar November 1998
1461
1462
1463 4.2.13 Recurrence Identifier Range
1464
1465 Parameter Name: RANGE
1466
1467 Purpose: To specify the effective range of recurrence instances from
1468 the instance specified by the recurrence identifier specified by the
1469 property.
1470
1471 Format Definition: The property parameter is defined by the following
1472 notation:
1473
1474 rangeparam = "RANGE" "=" ("THISANDPRIOR"
1475 ; To specify all instances prior to the recurrence identifier
1476 / "THISANDFUTURE")
1477 ; To specify the instance specified by the recurrence identifier
1478 ; and all subsequent recurrence instances
1479
1480 Description: The parameter can be specified on a property that
1481 specifies a recurrence identifier. The parameter specifies the
1482 effective range of recurrence instances that is specified by the
1483 property. The effective range is from the recurrence identified
1484 specified by the property. If this parameter is not specified an
1485 allowed property, then the default range is the single instance
1486 specified by the recurrence identifier value of the property. The
1487 parameter value can be "THISANDPRIOR" to indicate a range defined by
1488 the recurrence identified value of the property and all prior
1489 instances. The parameter value can also be "THISANDFUTURE" to
1490 indicate a range defined by the recurrence identifier and all
1491 subsequent instances.
1492
1493 Example:
1494
1495 RECURRENCE-ID;RANGE=THISANDPRIOR:19980401T133000Z
1496
1497 4.2.14 Alarm Trigger Relationship
1498
1499 Parameter Name: RELATED
1500
1501 Purpose: To specify the relationship of the alarm trigger with
1502 respect to the start or end of the calendar component.
1503
1504 Format Definition: The property parameter is defined by the following
1505 notation:
1506
1507 trigrelparam = "RELATED" "="
1508 ("START" ; Trigger off of start
1509 / "END") ; Trigger off of end
1510
1511
1512
1513
1514 Dawson & Stenerson Standards Track [Page 27]
1515
1516 RFC 2445 iCalendar November 1998
1517
1518
1519 Description: The parameter can be specified on properties that
1520 specify an alarm trigger with a DURATION value type. The parameter
1521 specifies whether the alarm will trigger relative to the start or end
1522 of the calendar component. The parameter value START will set the
1523 alarm to trigger off the start of the calendar component; the
1524 parameter value END will set the alarm to trigger off the end of the
1525 calendar component. If the parameter is not specified on an allowable
1526 property, then the default is START.
1527
1528 Example:
1529
1530 TRIGGER;RELATED=END:PT5M
1531
1532 4.2.15 Relationship Type
1533
1534 Parameter Name: RELTYPE
1535
1536 Purpose: To specify the type of hierarchical relationship associated
1537 with the calendar component specified by the property.
1538
1539 Format Definition: The property parameter is defined by the following
1540 notation:
1541
1542 reltypeparam = "RELTYPE" "="
1543 ("PARENT" ; Parent relationship. Default.
1544 / "CHILD" ; Child relationship
1545 / "SIBLING ; Sibling relationship
1546 / iana-token ; Some other IANA registered
1547 ; iCalendar relationship type
1548 / x-name) ; A non-standard, experimental
1549 ; relationship type
1550
1551 Description: This parameter can be specified on a property that
1552 references another related calendar. The parameter specifies the
1553 hierarchical relationship type of the calendar component referenced
1554 by the property. The parameter value can be PARENT, to indicate that
1555 the referenced calendar component is a superior of calendar
1556 component; CHILD to indicate that the referenced calendar component
1557 is a subordinate of the calendar component; SIBLING to indicate that
1558 the referenced calendar component is a peer of the calendar
1559 component. If this parameter is not specified on an allowable
1560 property, the default relationship type is PARENT.
1561
1562 Example:
1563
1564 RELATED-TO;RELTYPE=SIBLING:<19960401-080045-4000F192713@host.com>
1565
1566
1567
1568
1569
1570 Dawson & Stenerson Standards Track [Page 28]
1571
1572 RFC 2445 iCalendar November 1998
1573
1574
1575 4.2.16 Participation Role
1576
1577 Parameter Name: ROLE
1578
1579 Purpose: To specify the participation role for the calendar user
1580 specified by the property.
1581
1582 Format Definition: The property parameter is defined by the following
1583 notation:
1584
1585 roleparam = "ROLE" "="
1586 ("CHAIR" ; Indicates chair of the
1587 ; calendar entity
1588 / "REQ-PARTICIPANT" ; Indicates a participant whose
1589 ; participation is required
1590 / "OPT-PARTICIPANT" ; Indicates a participant whose
1591 ; participation is optional
1592 / "NON-PARTICIPANT" ; Indicates a participant who is
1593 ; copied for information
1594 ; purposes only
1595 / x-name ; Experimental role
1596 / iana-token) ; Other IANA role
1597 ; Default is REQ-PARTICIPANT
1598
1599 Description: This parameter can be specified on properties with a
1600 CAL-ADDRESS value type. The parameter specifies the participation
1601 role for the calendar user specified by the property in the group
1602 schedule calendar component. If not specified on a property that
1603 allows this parameter, the default value is REQ-PARTICIPANT.
1604
1605 Example:
1606
1607 ATTENDEE;ROLE=CHAIR:MAILTO:mrbig@host.com
1608
1609 4.2.17 RSVP Expectation
1610
1611 Parameter Name: RSVP
1612
1613 Purpose: To specify whether there is an expectation of a favor of a
1614 reply from the calendar user specified by the property value.
1615
1616 Format Definition: The property parameter is defined by the following
1617 notation:
1618
1619 rsvpparam = "RSVP" "=" ("TRUE" / "FALSE")
1620 ; Default is FALSE
1621
1622
1623
1624
1625
1626 Dawson & Stenerson Standards Track [Page 29]
1627
1628 RFC 2445 iCalendar November 1998
1629
1630
1631 Description: This parameter can be specified on properties with a
1632 CAL-ADDRESS value type. The parameter identifies the expectation of a
1633 reply from the calendar user specified by the property value. This
1634 parameter is used by the "Organizer" to request a participation
1635 status reply from an "Attendee" of a group scheduled event or to-do.
1636 If not specified on a property that allows this parameter, the
1637 default value is FALSE.
1638
1639 Example:
1640
1641 ATTENDEE;RSVP=TRUE:MAILTO:jsmith@host.com
1642
1643 4.2.18 Sent By
1644
1645 Parameter Name: SENT-BY
1646
1647 Purpose: To specify the calendar user that is acting on behalf of the
1648 calendar user specified by the property.
1649
1650 Format Definition: The property parameter is defined by the following
1651 notation:
1652
1653 sentbyparam = "SENT-BY" "=" DQUOTE cal-address DQUOTE
1654
1655 Description: This parameter can be specified on properties with a
1656 CAL-ADDRESS value type. The parameter specifies the calendar user
1657 that is acting on behalf of the calendar user specified by the
1658 property. The parameter value MUST be a MAILTO URI as defined in [RFC
1659 1738]. The individual calendar address parameter values MUST each be
1660 specified in a quoted-string.
1661
1662 Example:
1663
1664 ORGANIZER;SENT-BY:"MAILTO:sray@host.com":MAILTO:jsmith@host.com
1665
1666 4.2.19 Time Zone Identifier
1667
1668 Parameter Name: TZID
1669
1670 Purpose: To specify the identifier for the time zone definition for a
1671 time component in the property value.
1672
1673 Format Definition: This property parameter is defined by the
1674 following notation:
1675
1676 tzidparam = "TZID" "=" [tzidprefix] paramtext CRLF
1677
1678 tzidprefix = "/"
1679
1680
1681
1682 Dawson & Stenerson Standards Track [Page 30]
1683
1684 RFC 2445 iCalendar November 1998
1685
1686
1687 Description: The parameter MUST be specified on the "DTSTART",
1688 "DTEND", "DUE", "EXDATE" and "RDATE" properties when either a DATE-
1689 TIME or TIME value type is specified and when the value is not either
1690 a UTC or a "floating" time. Refer to the DATE-TIME or TIME value type
1691 definition for a description of UTC and "floating time" formats. This
1692 property parameter specifies a text value which uniquely identifies
1693 the "VTIMEZONE" calendar component to be used when evaluating the
1694 time portion of the property. The value of the TZID property
1695 parameter will be equal to the value of the TZID property for the
1696 matching time zone definition. An individual "VTIMEZONE" calendar
1697 component MUST be specified for each unique "TZID" parameter value
1698 specified in the iCalendar object.
1699
1700 The parameter MUST be specified on properties with a DATE-TIME value
1701 if the DATE-TIME is not either a UTC or a "floating" time.
1702
1703 The presence of the SOLIDUS character (US-ASCII decimal 47) as a
1704 prefix, indicates that this TZID represents a unique ID in a globally
1705 defined time zone registry (when such registry is defined).
1706
1707 Note: This document does not define a naming convention for time
1708 zone identifiers. Implementers may want to use the naming
1709 conventions defined in existing time zone specifications such as
1710 the public-domain Olson database [TZ]. The specification of
1711 globally unique time zone identifiers is not addressed by this
1712 document and is left for future study.
1713
1714 The following are examples of this property parameter:
1715
1716 DTSTART;TZID=US-Eastern:19980119T020000
1717
1718 DTEND;TZID=US-Eastern:19980119T030000
1719
1720 The TZID property parameter MUST NOT be applied to DATE-TIME or TIME
1721 properties whose time values are specified in UTC.
1722
1723 The use of local time in a DATE-TIME or TIME value without the TZID
1724 property parameter is to be interpreted as a local time value,
1725 regardless of the existence of "VTIMEZONE" calendar components in the
1726 iCalendar object.
1727
1728 For more information see the sections on the data types DATE-TIME and
1729 TIME.
1730
1731
1732
1733
1734
1735
1736
1737
1738 Dawson & Stenerson Standards Track [Page 31]
1739
1740 RFC 2445 iCalendar November 1998
1741
1742
1743 4.2.20 Value Data Types
1744
1745 Parameter Name: VALUE
1746
1747 Purpose: To explicitly specify the data type format for a property
1748 value.
1749
1750 Format Definition: The "VALUE" property parameter is defined by the
1751 following notation:
1752
1753 valuetypeparam = "VALUE" "=" valuetype
1754
1755 valuetype = ("BINARY"
1756 / "BOOLEAN"
1757 / "CAL-ADDRESS"
1758 / "DATE"
1759 / "DATE-TIME"
1760 / "DURATION"
1761 / "FLOAT"
1762 / "INTEGER"
1763 / "PERIOD"
1764 / "RECUR"
1765 / "TEXT"
1766 / "TIME"
1767 / "URI"
1768 / "UTC-OFFSET"
1769 / x-name
1770 ; Some experimental iCalendar data type.
1771 / iana-token)
1772 ; Some other IANA registered iCalendar data type.
1773
1774 Description: The parameter specifies the data type and format of the
1775 property value. The property values MUST be of a single value type.
1776 For example, a "RDATE" property cannot have a combination of DATE-
1777 TIME and TIME value types.
1778
1779 If the property's value is the default value type, then this
1780 parameter need not be specified. However, if the property's default
1781 value type is overridden by some other allowable value type, then
1782 this parameter MUST be specified.
1783
1784 4.3 Property Value Data Types
1785
1786 The properties in an iCalendar object are strongly typed. The
1787 definition of each property restricts the value to be one of the
1788 value data types, or simply value types, defined in this section. The
1789 value type for a property will either be specified implicitly as the
1790 default value type or will be explicitly specified with the "VALUE"
1791
1792
1793
1794 Dawson & Stenerson Standards Track [Page 32]
1795
1796 RFC 2445 iCalendar November 1998
1797
1798
1799 parameter. If the value type of a property is one of the alternate
1800 valid types, then it MUST be explicitly specified with the "VALUE"
1801 parameter.
1802
1803 4.3.1 Binary
1804
1805 Value Name: BINARY
1806
1807 Purpose: This value type is used to identify properties that contain
1808 a character encoding of inline binary data. For example, an inline
1809 attachment of an object code might be included in an iCalendar
1810 object.
1811
1812 Formal Definition: The value type is defined by the following
1813 notation:
1814
1815 binary = *(4b-char) [b-end]
1816 ; A "BASE64" encoded character string, as defined by [RFC 2045].
1817
1818 b-end = (2b-char "==") / (3b-char "=")
1819
1820 b-char = ALPHA / DIGIT / "+" / "/"
1821
1822 Description: Property values with this value type MUST also include
1823 the inline encoding parameter sequence of ";ENCODING=BASE64". That
1824 is, all inline binary data MUST first be character encoded using the
1825 "BASE64" encoding method defined in [RFC 2045]. No additional content
1826 value encoding (i.e., BACKSLASH character encoding) is defined for
1827 this value type.
1828
1829 Example: The following is an abridged example of a "BASE64" encoded
1830 binary value data.
1831
1832 ATTACH;VALUE=BINARY;ENCODING=BASE64:MIICajCCAdOgAwIBAgICBEUwDQY
1833 JKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlI
1834 ENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZv
1835 <...remainder of "BASE64" encoded binary data...>
1836
1837 4.3.2 Boolean
1838
1839 Value Name: BOOLEAN
1840
1841 Purpose: This value type is used to identify properties that contain
1842 either a "TRUE" or "FALSE" Boolean value.
1843
1844 Formal Definition: The value type is defined by the following
1845 notation:
1846
1847
1848
1849
1850 Dawson & Stenerson Standards Track [Page 33]
1851
1852 RFC 2445 iCalendar November 1998
1853
1854
1855 boolean = "TRUE" / "FALSE"
1856
1857 Description: These values are case insensitive text. No additional
1858 content value encoding (i.e., BACKSLASH character encoding) is
1859 defined for this value type.
1860
1861 Example: The following is an example of a hypothetical property that
1862 has a BOOLEAN value type:
1863
1864 GIBBERISH:TRUE
1865
1866 4.3.3 Calendar User Address
1867
1868 Value Name: CAL-ADDRESS
1869
1870 Purpose: This value type is used to identify properties that contain
1871 a calendar user address.
1872
1873 Formal Definition: The value type is as defined by the following
1874 notation:
1875
1876 cal-address = uri
1877
1878 Description: The value is a URI as defined by [RFC 1738] or any other
1879 IANA registered form for a URI. When used to address an Internet
1880 email transport address for a calendar user, the value MUST be a
1881 MAILTO URI, as defined by [RFC 1738]. No additional content value
1882 encoding (i.e., BACKSLASH character encoding) is defined for this
1883 value type.
1884
1885 Example:
1886
1887 ATTENDEE:MAILTO:jane_doe@host.com
1888
1889 4.3.4 Date
1890
1891 Value Name: DATE
1892
1893 Purpose: This value type is used to identify values that contain a
1894 calendar date.
1895
1896 Formal Definition: The value type is defined by the following
1897 notation:
1898
1899 date = date-value
1900
1901 date-value = date-fullyear date-month date-mday
1902 date-fullyear = 4DIGIT
1903
1904
1905
1906 Dawson & Stenerson Standards Track [Page 34]
1907
1908 RFC 2445 iCalendar November 1998
1909
1910
1911 date-month = 2DIGIT ;01-12
1912 date-mday = 2DIGIT ;01-28, 01-29, 01-30, 01-31
1913 ;based on month/year
1914
1915 Description: If the property permits, multiple "date" values are
1916 specified as a COMMA character (US-ASCII decimal 44) separated list
1917 of values. The format for the value type is expressed as the [ISO
1918 8601] complete representation, basic format for a calendar date. The
1919 textual format specifies a four-digit year, two-digit month, and
1920 two-digit day of the month. There are no separator characters between
1921 the year, month and day component text.
1922
1923 No additional content value encoding (i.e., BACKSLASH character
1924 encoding) is defined for this value type.
1925
1926 Example: The following represents July 14, 1997:
1927
1928 19970714
1929
1930 4.3.5 Date-Time
1931
1932 Value Name: DATE-TIME
1933
1934 Purpose: This value type is used to identify values that specify a
1935 precise calendar date and time of day.
1936
1937 Formal Definition: The value type is defined by the following
1938 notation:
1939
1940 date-time = date "T" time ;As specified in the date and time
1941 ;value definitions
1942
1943 Description: If the property permits, multiple "date-time" values are
1944 specified as a COMMA character (US-ASCII decimal 44) separated list
1945 of values. No additional content value encoding (i.e., BACKSLASH
1946 character encoding) is defined for this value type.
1947
1948 The "DATE-TIME" data type is used to identify values that contain a
1949 precise calendar date and time of day. The format is based on the
1950 [ISO 8601] complete representation, basic format for a calendar date
1951 and time of day. The text format is a concatenation of the "date",
1952 followed by the LATIN CAPITAL LETTER T character (US-ASCII decimal
1953 84) time designator, followed by the "time" format.
1954
1955 The "DATE-TIME" data type expresses time values in three forms:
1956
1957 The form of date and time with UTC offset MUST NOT be used. For
1958 example, the following is not valid for a date-time value:
1959
1960
1961
1962 Dawson & Stenerson Standards Track [Page 35]
1963
1964 RFC 2445 iCalendar November 1998
1965
1966
1967 DTSTART:19980119T230000-0800 ;Invalid time format
1968
1969 FORM #1: DATE WITH LOCAL TIME
1970
1971 The date with local time form is simply a date-time value that does
1972 not contain the UTC designator nor does it reference a time zone. For
1973 example, the following represents Janurary 18, 1998, at 11 PM:
1974
1975 DTSTART:19980118T230000
1976
1977 Date-time values of this type are said to be "floating" and are not
1978 bound to any time zone in particular. They are used to represent the
1979 same hour, minute, and second value regardless of which time zone is
1980 currently being observed. For example, an event can be defined that
1981 indicates that an individual will be busy from 11:00 AM to 1:00 PM
1982 every day, no matter which time zone the person is in. In these
1983 cases, a local time can be specified. The recipient of an iCalendar
1984 object with a property value consisting of a local time, without any
1985 relative time zone information, SHOULD interpret the value as being
1986 fixed to whatever time zone the ATTENDEE is in at any given moment.
1987 This means that two ATTENDEEs, in different time zones, receiving the
1988 same event definition as a floating time, may be participating in the
1989 event at different actual times. Floating time SHOULD only be used
1990 where that is the reasonable behavior.
1991
1992 In most cases, a fixed time is desired. To properly communicate a
1993 fixed time in a property value, either UTC time or local time with
1994 time zone reference MUST be specified.
1995
1996 The use of local time in a DATE-TIME value without the TZID property
1997 parameter is to be interpreted as floating time, regardless of the
1998 existence of "VTIMEZONE" calendar components in the iCalendar object.
1999
2000 FORM #2: DATE WITH UTC TIME
2001
2002 The date with UTC time, or absolute time, is identified by a LATIN
2003 CAPITAL LETTER Z suffix character (US-ASCII decimal 90), the UTC
2004 designator, appended to the time value. For example, the following
2005 represents January 19, 1998, at 0700 UTC:
2006
2007 DTSTART:19980119T070000Z
2008
2009 The TZID property parameter MUST NOT be applied to DATE-TIME
2010 properties whose time values are specified in UTC.
2011
2012 FORM #3: DATE WITH LOCAL TIME AND TIME ZONE REFERENCE
2013
2014
2015
2016
2017
2018 Dawson & Stenerson Standards Track [Page 36]
2019
2020 RFC 2445 iCalendar November 1998
2021
2022
2023 The date and local time with reference to time zone information is
2024 identified by the use the TZID property parameter to reference the
2025 appropriate time zone definition. TZID is discussed in detail in the
2026 section on Time Zone. For example, the following represents 2 AM in
2027 New York on Janurary 19, 1998:
2028
2029 DTSTART;TZID=US-Eastern:19980119T020000
2030
2031 Example: The following represents July 14, 1997, at 1:30 PM in New
2032 York City in each of the three time formats, using the "DTSTART"
2033 property.
2034
2035 DTSTART:19970714T133000 ;Local time
2036 DTSTART:19970714T173000Z ;UTC time
2037 DTSTART;TZID=US-Eastern:19970714T133000 ;Local time and time
2038 ; zone reference
2039
2040 A time value MUST ONLY specify 60 seconds when specifying the
2041 periodic "leap second" in the time value. For example:
2042
2043 COMPLETED:19970630T235960Z
2044
2045 4.3.6 Duration
2046
2047 Value Name: DURATION
2048
2049 Purpose: This value type is used to identify properties that contain
2050 a duration of time.
2051
2052 Formal Definition: The value type is defined by the following
2053 notation:
2054
2055 dur-value = (["+"] / "-") "P" (dur-date / dur-time / dur-week)
2056
2057 dur-date = dur-day [dur-time]
2058 dur-time = "T" (dur-hour / dur-minute / dur-second)
2059 dur-week = 1*DIGIT "W"
2060 dur-hour = 1*DIGIT "H" [dur-minute]
2061 dur-minute = 1*DIGIT "M" [dur-second]
2062 dur-second = 1*DIGIT "S"
2063 dur-day = 1*DIGIT "D"
2064
2065 Description: If the property permits, multiple "duration" values are
2066 specified by a COMMA character (US-ASCII decimal 44) separated list
2067 of values. The format is expressed as the [ISO 8601] basic format for
2068 the duration of time. The format can represent durations in terms of
2069 weeks, days, hours, minutes, and seconds.
2070
2071
2072
2073
2074 Dawson & Stenerson Standards Track [Page 37]
2075
2076 RFC 2445 iCalendar November 1998
2077
2078
2079 No additional content value encoding (i.e., BACKSLASH character
2080 encoding) are defined for this value type.
2081
2082 Example: A duration of 15 days, 5 hours and 20 seconds would be:
2083
2084 P15DT5H0M20S
2085
2086 A duration of 7 weeks would be:
2087
2088 P7W
2089
2090 4.3.7 Float
2091
2092 Value Name: FLOAT
2093
2094 Purpose: This value type is used to identify properties that contain
2095 a real number value.
2096
2097 Formal Definition: The value type is defined by the following
2098 notation:
2099
2100 float = (["+"] / "-") 1*DIGIT ["." 1*DIGIT]
2101
2102 Description: If the property permits, multiple "float" values are
2103 specified by a COMMA character (US-ASCII decimal 44) separated list
2104 of values.
2105
2106 No additional content value encoding (i.e., BACKSLASH character
2107 encoding) is defined for this value type.
2108
2109 Example:
2110
2111 1000000.0000001
2112 1.333
2113 -3.14
2114
2115 4.3.8 Integer
2116
2117 Value Name:INTEGER
2118
2119 Purpose: This value type is used to identify properties that contain
2120 a signed integer value.
2121
2122 Formal Definition: The value type is defined by the following
2123 notation:
2124
2125 integer = (["+"] / "-") 1*DIGIT
2126
2127
2128
2129
2130 Dawson & Stenerson Standards Track [Page 38]
2131
2132 RFC 2445 iCalendar November 1998
2133
2134
2135 Description: If the property permits, multiple "integer" values are
2136 specified by a COMMA character (US-ASCII decimal 44) separated list
2137 of values. The valid range for "integer" is -2147483648 to
2138 2147483647. If the sign is not specified, then the value is assumed
2139 to be positive.
2140
2141 No additional content value encoding (i.e., BACKSLASH character
2142 encoding) is defined for this value type.
2143
2144 Example:
2145
2146 1234567890
2147 -1234567890
2148 +1234567890
2149 432109876
2150
2151 4.3.9 Period of Time
2152
2153 Value Name: PERIOD
2154
2155 Purpose: This value type is used to identify values that contain a
2156 precise period of time.
2157
2158 Formal Definition: The data type is defined by the following
2159 notation:
2160
2161 period = period-explicit / period-start
2162
2163 period-explicit = date-time "/" date-time
2164 ; [ISO 8601] complete representation basic format for a period of
2165 ; time consisting of a start and end. The start MUST be before the
2166 ; end.
2167
2168 period-start = date-time "/" dur-value
2169 ; [ISO 8601] complete representation basic format for a period of
2170 ; time consisting of a start and positive duration of time.
2171
2172 Description: If the property permits, multiple "period" values are
2173 specified by a COMMA character (US-ASCII decimal 44) separated list
2174 of values. There are two forms of a period of time. First, a period
2175 of time is identified by its start and its end. This format is
2176 expressed as the [ISO 8601] complete representation, basic format for
2177 "DATE-TIME" start of the period, followed by a SOLIDUS character
2178 (US-ASCII decimal 47), followed by the "DATE-TIME" of the end of the
2179 period. The start of the period MUST be before the end of the period.
2180 Second, a period of time can also be defined by a start and a
2181 positive duration of time. The format is expressed as the [ISO 8601]
2182 complete representation, basic format for the "DATE-TIME" start of
2183
2184
2185
2186 Dawson & Stenerson Standards Track [Page 39]
2187
2188 RFC 2445 iCalendar November 1998
2189
2190
2191 the period, followed by a SOLIDUS character (US-ASCII decimal 47),
2192 followed by the [ISO 8601] basic format for "DURATION" of the period.
2193
2194 Example: The period starting at 18:00:00 UTC, on January 1, 1997 and
2195 ending at 07:00:00 UTC on January 2, 1997 would be:
2196
2197 19970101T180000Z/19970102T070000Z
2198
2199 The period start at 18:00:00 on January 1, 1997 and lasting 5 hours
2200 and 30 minutes would be:
2201
2202 19970101T180000Z/PT5H30M
2203
2204 No additional content value encoding (i.e., BACKSLASH character
2205 encoding) is defined for this value type.
2206
2207 4.3.10 Recurrence Rule
2208
2209 Value Name: RECUR
2210
2211 Purpose: This value type is used to identify properties that contain
2212 a recurrence rule specification.
2213
2214 Formal Definition: The value type is defined by the following
2215 notation:
2216
2217 recur = "FREQ"=freq *(
2218
2219 ; either UNTIL or COUNT may appear in a 'recur',
2220 ; but UNTIL and COUNT MUST NOT occur in the same 'recur'
2221
2222 ( ";" "UNTIL" "=" enddate ) /
2223 ( ";" "COUNT" "=" 1*DIGIT ) /
2224
2225 ; the rest of these keywords are optional,
2226 ; but MUST NOT occur more than once
2227
2228 ( ";" "INTERVAL" "=" 1*DIGIT ) /
2229 ( ";" "BYSECOND" "=" byseclist ) /
2230 ( ";" "BYMINUTE" "=" byminlist ) /
2231 ( ";" "BYHOUR" "=" byhrlist ) /
2232 ( ";" "BYDAY" "=" bywdaylist ) /
2233 ( ";" "BYMONTHDAY" "=" bymodaylist ) /
2234 ( ";" "BYYEARDAY" "=" byyrdaylist ) /
2235 ( ";" "BYWEEKNO" "=" bywknolist ) /
2236 ( ";" "BYMONTH" "=" bymolist ) /
2237 ( ";" "BYSETPOS" "=" bysplist ) /
2238 ( ";" "WKST" "=" weekday ) /
2239
2240
2241
2242 Dawson & Stenerson Standards Track [Page 40]
2243
2244 RFC 2445 iCalendar November 1998
2245
2246
2247 ( ";" x-name "=" text )
2248 )
2249
2250 freq = "SECONDLY" / "MINUTELY" / "HOURLY" / "DAILY"
2251 / "WEEKLY" / "MONTHLY" / "YEARLY"
2252
2253 enddate = date
2254 enddate =/ date-time ;An UTC value
2255
2256 byseclist = seconds / ( seconds *("," seconds) )
2257
2258 seconds = 1DIGIT / 2DIGIT ;0 to 59
2259
2260 byminlist = minutes / ( minutes *("," minutes) )
2261
2262 minutes = 1DIGIT / 2DIGIT ;0 to 59
2263
2264 byhrlist = hour / ( hour *("," hour) )
2265
2266 hour = 1DIGIT / 2DIGIT ;0 to 23
2267
2268 bywdaylist = weekdaynum / ( weekdaynum *("," weekdaynum) )
2269
2270 weekdaynum = [([plus] ordwk / minus ordwk)] weekday
2271
2272 plus = "+"
2273
2274 minus = "-"
2275
2276 ordwk = 1DIGIT / 2DIGIT ;1 to 53
2277
2278 weekday = "SU" / "MO" / "TU" / "WE" / "TH" / "FR" / "SA"
2279 ;Corresponding to SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY,
2280 ;FRIDAY, SATURDAY and SUNDAY days of the week.
2281
2282 bymodaylist = monthdaynum / ( monthdaynum *("," monthdaynum) )
2283
2284 monthdaynum = ([plus] ordmoday) / (minus ordmoday)
2285
2286 ordmoday = 1DIGIT / 2DIGIT ;1 to 31
2287
2288 byyrdaylist = yeardaynum / ( yeardaynum *("," yeardaynum) )
2289
2290 yeardaynum = ([plus] ordyrday) / (minus ordyrday)
2291
2292 ordyrday = 1DIGIT / 2DIGIT / 3DIGIT ;1 to 366
2293
2294 bywknolist = weeknum / ( weeknum *("," weeknum) )
2295
2296
2297
2298 Dawson & Stenerson Standards Track [Page 41]
2299
2300 RFC 2445 iCalendar November 1998
2301
2302
2303 weeknum = ([plus] ordwk) / (minus ordwk)
2304
2305 bymolist = monthnum / ( monthnum *("," monthnum) )
2306
2307 monthnum = 1DIGIT / 2DIGIT ;1 to 12
2308
2309 bysplist = setposday / ( setposday *("," setposday) )
2310
2311 setposday = yeardaynum
2312
2313 Description: If the property permits, multiple "recur" values are
2314 specified by a COMMA character (US-ASCII decimal 44) separated list
2315 of values. The value type is a structured value consisting of a list
2316 of one or more recurrence grammar parts. Each rule part is defined by
2317 a NAME=VALUE pair. The rule parts are separated from each other by
2318 the SEMICOLON character (US-ASCII decimal 59). The rule parts are not
2319 ordered in any particular sequence. Individual rule parts MUST only
2320 be specified once.
2321
2322 The FREQ rule part identifies the type of recurrence rule. This rule
2323 part MUST be specified in the recurrence rule. Valid values include
2324 SECONDLY, to specify repeating events based on an interval of a
2325 second or more; MINUTELY, to specify repeating events based on an
2326 interval of a minute or more; HOURLY, to specify repeating events
2327 based on an interval of an hour or more; DAILY, to specify repeating
2328 events based on an interval of a day or more; WEEKLY, to specify
2329 repeating events based on an interval of a week or more; MONTHLY, to
2330 specify repeating events based on an interval of a month or more; and
2331 YEARLY, to specify repeating events based on an interval of a year or
2332 more.
2333
2334 The INTERVAL rule part contains a positive integer representing how
2335 often the recurrence rule repeats. The default value is "1", meaning
2336 every second for a SECONDLY rule, or every minute for a MINUTELY
2337 rule, every hour for an HOURLY rule, every day for a DAILY rule,
2338 every week for a WEEKLY rule, every month for a MONTHLY rule and
2339 every year for a YEARLY rule.
2340
2341 The UNTIL rule part defines a date-time value which bounds the
2342 recurrence rule in an inclusive manner. If the value specified by
2343 UNTIL is synchronized with the specified recurrence, this date or
2344 date-time becomes the last instance of the recurrence. If specified
2345 as a date-time value, then it MUST be specified in an UTC time
2346 format. If not present, and the COUNT rule part is also not present,
2347 the RRULE is considered to repeat forever.
2348
2349 The COUNT rule part defines the number of occurrences at which to
2350 range-bound the recurrence. The "DTSTART" property value, if
2351
2352
2353
2354 Dawson & Stenerson Standards Track [Page 42]
2355
2356 RFC 2445 iCalendar November 1998
2357
2358
2359 specified, counts as the first occurrence.
2360
2361 The BYSECOND rule part specifies a COMMA character (US-ASCII decimal
2362 44) separated list of seconds within a minute. Valid values are 0 to
2363 59. The BYMINUTE rule part specifies a COMMA character (US-ASCII
2364 decimal 44) separated list of minutes within an hour. Valid values
2365 are 0 to 59. The BYHOUR rule part specifies a COMMA character (US-
2366 ASCII decimal 44) separated list of hours of the day. Valid values
2367 are 0 to 23.
2368
2369 The BYDAY rule part specifies a COMMA character (US-ASCII decimal 44)
2370 separated list of days of the week; MO indicates Monday; TU indicates
2371 Tuesday; WE indicates Wednesday; TH indicates Thursday; FR indicates
2372 Friday; SA indicates Saturday; SU indicates Sunday.
2373
2374 Each BYDAY value can also be preceded by a positive (+n) or negative
2375 (-n) integer. If present, this indicates the nth occurrence of the
2376 specific day within the MONTHLY or YEARLY RRULE. For example, within
2377 a MONTHLY rule, +1MO (or simply 1MO) represents the first Monday
2378 within the month, whereas -1MO represents the last Monday of the
2379 month. If an integer modifier is not present, it means all days of
2380 this type within the specified frequency. For example, within a
2381 MONTHLY rule, MO represents all Mondays within the month.
2382
2383 The BYMONTHDAY rule part specifies a COMMA character (ASCII decimal
2384 44) separated list of days of the month. Valid values are 1 to 31 or
2385 -31 to -1. For example, -10 represents the tenth to the last day of
2386 the month.
2387
2388 The BYYEARDAY rule part specifies a COMMA character (US-ASCII decimal
2389 44) separated list of days of the year. Valid values are 1 to 366 or
2390 -366 to -1. For example, -1 represents the last day of the year
2391 (December 31st) and -306 represents the 306th to the last day of the
2392 year (March 1st).
2393
2394 The BYWEEKNO rule part specifies a COMMA character (US-ASCII decimal
2395 44) separated list of ordinals specifying weeks of the year. Valid
2396 values are 1 to 53 or -53 to -1. This corresponds to weeks according
2397 to week numbering as defined in [ISO 8601]. A week is defined as a
2398 seven day period, starting on the day of the week defined to be the
2399 week start (see WKST). Week number one of the calendar year is the
2400 first week which contains at least four (4) days in that calendar
2401 year. This rule part is only valid for YEARLY rules. For example, 3
2402 represents the third week of the year.
2403
2404 Note: Assuming a Monday week start, week 53 can only occur when
2405 Thursday is January 1 or if it is a leap year and Wednesday is
2406 January 1.
2407
2408
2409
2410 Dawson & Stenerson Standards Track [Page 43]
2411
2412 RFC 2445 iCalendar November 1998
2413
2414
2415 The BYMONTH rule part specifies a COMMA character (US-ASCII decimal
2416 44) separated list of months of the year. Valid values are 1 to 12.
2417
2418 The WKST rule part specifies the day on which the workweek starts.
2419 Valid values are MO, TU, WE, TH, FR, SA and SU. This is significant
2420 when a WEEKLY RRULE has an interval greater than 1, and a BYDAY rule
2421 part is specified. This is also significant when in a YEARLY RRULE
2422 when a BYWEEKNO rule part is specified. The default value is MO.
2423
2424 The BYSETPOS rule part specifies a COMMA character (US-ASCII decimal
2425 44) separated list of values which corresponds to the nth occurrence
2426 within the set of events specified by the rule. Valid values are 1 to
2427 366 or -366 to -1. It MUST only be used in conjunction with another
2428 BYxxx rule part. For example "the last work day of the month" could
2429 be represented as:
2430
2431 RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1
2432
2433 Each BYSETPOS value can include a positive (+n) or negative (-n)
2434 integer. If present, this indicates the nth occurrence of the
2435 specific occurrence within the set of events specified by the rule.
2436
2437 If BYxxx rule part values are found which are beyond the available
2438 scope (ie, BYMONTHDAY=30 in February), they are simply ignored.
2439
2440 Information, not contained in the rule, necessary to determine the
2441 various recurrence instance start time and dates are derived from the
2442 Start Time (DTSTART) entry attribute. For example,
2443 "FREQ=YEARLY;BYMONTH=1" doesn't specify a specific day within the
2444 month or a time. This information would be the same as what is
2445 specified for DTSTART.
2446
2447 BYxxx rule parts modify the recurrence in some manner. BYxxx rule
2448 parts for a period of time which is the same or greater than the
2449 frequency generally reduce or limit the number of occurrences of the
2450 recurrence generated. For example, "FREQ=DAILY;BYMONTH=1" reduces the
2451 number of recurrence instances from all days (if BYMONTH tag is not
2452 present) to all days in January. BYxxx rule parts for a period of
2453 time less than the frequency generally increase or expand the number
2454 of occurrences of the recurrence. For example,
2455 "FREQ=YEARLY;BYMONTH=1,2" increases the number of days within the
2456 yearly recurrence set from 1 (if BYMONTH tag is not present) to 2.
2457
2458 If multiple BYxxx rule parts are specified, then after evaluating the
2459 specified FREQ and INTERVAL rule parts, the BYxxx rule parts are
2460 applied to the current set of evaluated occurrences in the following
2461 order: BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY, BYDAY, BYHOUR,
2462 BYMINUTE, BYSECOND and BYSETPOS; then COUNT and UNTIL are evaluated.
2463
2464
2465
2466 Dawson & Stenerson Standards Track [Page 44]
2467
2468 RFC 2445 iCalendar November 1998
2469
2470
2471 Here is an example of evaluating multiple BYxxx rule parts.
2472
2473 DTSTART;TZID=US-Eastern:19970105T083000
2474 RRULE:FREQ=YEARLY;INTERVAL=2;BYMONTH=1;BYDAY=SU;BYHOUR=8,9;
2475 BYMINUTE=30
2476
2477 First, the "INTERVAL=2" would be applied to "FREQ=YEARLY" to arrive
2478 at "every other year". Then, "BYMONTH=1" would be applied to arrive
2479 at "every January, every other year". Then, "BYDAY=SU" would be
2480 applied to arrive at "every Sunday in January, every other year".
2481 Then, "BYHOUR=8,9" would be applied to arrive at "every Sunday in
2482 January at 8 AM and 9 AM, every other year". Then, "BYMINUTE=30"
2483 would be applied to arrive at "every Sunday in January at 8:30 AM and
2484 9:30 AM, every other year". Then, lacking information from RRULE, the
2485 second is derived from DTSTART, to end up in "every Sunday in January
2486 at 8:30:00 AM and 9:30:00 AM, every other year". Similarly, if the
2487 BYMINUTE, BYHOUR, BYDAY, BYMONTHDAY or BYMONTH rule part were
2488 missing, the appropriate minute, hour, day or month would have been
2489 retrieved from the "DTSTART" property.
2490
2491 No additional content value encoding (i.e., BACKSLASH character
2492 encoding) is defined for this value type.
2493
2494 Example: The following is a rule which specifies 10 meetings which
2495 occur every other day:
2496
2497 FREQ=DAILY;COUNT=10;INTERVAL=2
2498
2499 There are other examples specified in the "RRULE" specification.
2500
2501 4.3.11 Text
2502
2503 Value Name: TEXT
2504
2505 Purpose This value type is used to identify values that contain human
2506 readable text.
2507
2508 Formal Definition: The character sets supported by this revision of
2509 iCalendar are UTF-8 and US ASCII thereof. The applicability to other
2510 character sets is for future work. The value type is defined by the
2511 following notation.
2512
2513 text = *(TSAFE-CHAR / ":" / DQUOTE / ESCAPED-CHAR)
2514 ; Folded according to description above
2515
2516 ESCAPED-CHAR = "\\" / "\;" / "\," / "\N" / "\n")
2517 ; \\ encodes \, \N or \n encodes newline
2518 ; \; encodes ;, \, encodes ,
2519
2520
2521
2522 Dawson & Stenerson Standards Track [Page 45]
2523
2524 RFC 2445 iCalendar November 1998
2525
2526
2527 TSAFE-CHAR = %x20-21 / %x23-2B / %x2D-39 / %x3C-5B
2528 %x5D-7E / NON-US-ASCII
2529 ; Any character except CTLs not needed by the current
2530 ; character set, DQUOTE, ";", ":", "\", ","
2531
2532 Note: Certain other character sets may require modification of the
2533 above definitions, but this is beyond the scope of this document.
2534
2535 Description: If the property permits, multiple "text" values are
2536 specified by a COMMA character (US-ASCII decimal 44) separated list
2537 of values.
2538
2539 The language in which the text is represented can be controlled by
2540 the "LANGUAGE" property parameter.
2541
2542 An intentional formatted text line break MUST only be included in a
2543 "TEXT" property value by representing the line break with the
2544 character sequence of BACKSLASH (US-ASCII decimal 92), followed by a
2545 LATIN SMALL LETTER N (US-ASCII decimal 110) or a LATIN CAPITAL LETTER
2546 N (US-ASCII decimal 78), that is "\n" or "\N".
2547
2548 The "TEXT" property values may also contain special characters that
2549 are used to signify delimiters, such as a COMMA character for lists
2550 of values or a SEMICOLON character for structured values. In order to
2551 support the inclusion of these special characters in "TEXT" property
2552 values, they MUST be escaped with a BACKSLASH character. A BACKSLASH
2553 character (US-ASCII decimal 92) in a "TEXT" property value MUST be
2554 escaped with another BACKSLASH character. A COMMA character in a
2555 "TEXT" property value MUST be escaped with a BACKSLASH character
2556 (US-ASCII decimal 92). A SEMICOLON character in a "TEXT" property
2557 value MUST be escaped with a BACKSLASH character (US-ASCII decimal
2558 92). However, a COLON character in a "TEXT" property value SHALL NOT
2559 be escaped with a BACKSLASH character.Example: A multiple line value
2560 of:
2561
2562 Project XYZ Final Review
2563 Conference Room - 3B
2564 Come Prepared.
2565
2566 would be represented as:
2567
2568 Project XYZ Final Review\nConference Room - 3B\nCome Prepared.
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578 Dawson & Stenerson Standards Track [Page 46]
2579
2580 RFC 2445 iCalendar November 1998
2581
2582
2583 4.3.12 Time
2584
2585 Value Name: TIME
2586
2587 Purpose: This value type is used to identify values that contain a
2588 time of day.
2589
2590 Formal Definition: The data type is defined by the following
2591 notation:
2592
2593 time = time-hour time-minute time-second [time-utc]
2594
2595 time-hour = 2DIGIT ;00-23
2596 time-minute = 2DIGIT ;00-59
2597 time-second = 2DIGIT ;00-60
2598 ;The "60" value is used to account for "leap" seconds.
2599
2600 time-utc = "Z"
2601
2602 Description: If the property permits, multiple "time" values are
2603 specified by a COMMA character (US-ASCII decimal 44) separated list
2604 of values. No additional content value encoding (i.e., BACKSLASH
2605 character encoding) is defined for this value type.
2606
2607 The "TIME" data type is used to identify values that contain a time
2608 of day. The format is based on the [ISO 8601] complete
2609 representation, basic format for a time of day. The text format
2610 consists of a two-digit 24-hour of the day (i.e., values 0-23), two-
2611 digit minute in the hour (i.e., values 0-59), and two-digit seconds
2612 in the minute (i.e., values 0-60). The seconds value of 60 MUST only
2613 to be used to account for "leap" seconds. Fractions of a second are
2614 not supported by this format.
2615
2616 In parallel to the "DATE-TIME" definition above, the "TIME" data type
2617 expresses time values in three forms:
2618
2619 The form of time with UTC offset MUST NOT be used. For example, the
2620 following is NOT VALID for a time value:
2621
2622 230000-0800 ;Invalid time format
2623
2624 FORM #1 LOCAL TIME
2625
2626 The local time form is simply a time value that does not contain the
2627 UTC designator nor does it reference a time zone. For example, 11:00
2628 PM:
2629
2630 230000
2631
2632
2633
2634 Dawson & Stenerson Standards Track [Page 47]
2635
2636 RFC 2445 iCalendar November 1998
2637
2638
2639 Time values of this type are said to be "floating" and are not bound
2640 to any time zone in particular. They are used to represent the same
2641 hour, minute, and second value regardless of which time zone is
2642 currently being observed. For example, an event can be defined that
2643 indicates that an individual will be busy from 11:00 AM to 1:00 PM
2644 every day, no matter which time zone the person is in. In these
2645 cases, a local time can be specified. The recipient of an iCalendar
2646 object with a property value consisting of a local time, without any
2647 relative time zone information, SHOULD interpret the value as being
2648 fixed to whatever time zone the ATTENDEE is in at any given moment.
2649 This means that two ATTENDEEs may participate in the same event at
2650 different UTC times; floating time SHOULD only be used where that is
2651 reasonable behavior.
2652
2653 In most cases, a fixed time is desired. To properly communicate a
2654 fixed time in a property value, either UTC time or local time with
2655 time zone reference MUST be specified.
2656
2657 The use of local time in a TIME value without the TZID property
2658 parameter is to be interpreted as a local time value, regardless of
2659 the existence of "VTIMEZONE" calendar components in the iCalendar
2660 object.
2661
2662 FORM #2: UTC TIME
2663
2664 UTC time, or absolute time, is identified by a LATIN CAPITAL LETTER Z
2665 suffix character (US-ASCII decimal 90), the UTC designator, appended
2666 to the time value. For example, the following represents 07:00 AM
2667 UTC:
2668
2669 070000Z
2670
2671 The TZID property parameter MUST NOT be applied to TIME properties
2672 whose time values are specified in UTC.
2673
2674 FORM #3: LOCAL TIME AND TIME ZONE REFERENCE
2675
2676 The local time with reference to time zone information form is
2677 identified by the use the TZID property parameter to reference the
2678 appropriate time zone definition. TZID is discussed in detail in the
2679 section on Time Zone.
2680
2681 Example: The following represents 8:30 AM in New York in Winter, five
2682 hours behind UTC, in each of the three formats using the "X-
2683 TIMEOFDAY" non-standard property:
2684
2685
2686
2687
2688
2689
2690 Dawson & Stenerson Standards Track [Page 48]
2691
2692 RFC 2445 iCalendar November 1998
2693
2694
2695 X-TIMEOFDAY:083000
2696
2697 X-TIMEOFDAY:133000Z
2698
2699 X-TIMEOFDAY;TZID=US-Eastern:083000
2700
2701 4.3.13 URI
2702
2703 Value Name: URI
2704
2705 Purpose: This value type is used to identify values that contain a
2706 uniform resource identifier (URI) type of reference to the property
2707 value.
2708
2709 Formal Definition: The data type is defined by the following
2710 notation:
2711
2712 uri = <As defined by any IETF RFC>
2713
2714 Description: This data type might be used to reference binary
2715 information, for values that are large, or otherwise undesirable to
2716 include directly in the iCalendar object.
2717
2718 The URI value formats in RFC 1738, RFC 2111 and any other IETF
2719 registered value format can be specified.
2720
2721 Any IANA registered URI format can be used. These include, but are
2722 not limited to, those defined in RFC 1738 and RFC 2111.
2723
2724 When a property parameter value is a URI value type, the URI MUST be
2725 specified as a quoted-string value.
2726
2727 No additional content value encoding (i.e., BACKSLASH character
2728 encoding) is defined for this value type.
2729
2730 Example: The following is a URI for a network file:
2731
2732 http://host1.com/my-report.txt
2733
2734 4.3.14 UTC Offset
2735
2736 Value Name: UTC-OFFSET
2737
2738 Purpose: This value type is used to identify properties that contain
2739 an offset from UTC to local time.
2740
2741 Formal Definition: The data type is defined by the following
2742 notation:
2743
2744
2745
2746 Dawson & Stenerson Standards Track [Page 49]
2747
2748 RFC 2445 iCalendar November 1998
2749
2750
2751 utc-offset = time-numzone ;As defined above in time data type
2752
2753 time-numzone = ("+" / "-") time-hour time-minute [time-
2754 second]
2755
2756 Description: The PLUS SIGN character MUST be specified for positive
2757 UTC offsets (i.e., ahead of UTC). The value of "-0000" and "-000000"
2758 are not allowed. The time-second, if present, may not be 60; if
2759 absent, it defaults to zero.
2760
2761 No additional content value encoding (i.e., BACKSLASH character
2762 encoding) is defined for this value type.
2763
2764 Example: The following UTC offsets are given for standard time for
2765 New York (five hours behind UTC) and Geneva (one hour ahead of UTC):
2766
2767 -0500
2768
2769 +0100
2770
2771 4.4 iCalendar Object
2772
2773 The Calendaring and Scheduling Core Object is a collection of
2774 calendaring and scheduling information. Typically, this information
2775 will consist of a single iCalendar object. However, multiple
2776 iCalendar objects can be sequentially grouped together. The first
2777 line and last line of the iCalendar object MUST contain a pair of
2778 iCalendar object delimiter strings. The syntax for an iCalendar
2779 object is as follows:
2780
2781 icalobject = 1*("BEGIN" ":" "VCALENDAR" CRLF
2782 icalbody
2783 "END" ":" "VCALENDAR" CRLF)
2784
2785 The following is a simple example of an iCalendar object:
2786
2787 BEGIN:VCALENDAR
2788 VERSION:2.0
2789 PRODID:-//hacksw/handcal//NONSGML v1.0//EN
2790 BEGIN:VEVENT
2791 DTSTART:19970714T170000Z
2792 DTEND:19970715T035959Z
2793 SUMMARY:Bastille Day Party
2794 END:VEVENT
2795 END:VCALENDAR
2796
2797
2798
2799
2800
2801
2802 Dawson & Stenerson Standards Track [Page 50]
2803
2804 RFC 2445 iCalendar November 1998
2805
2806
2807 4.5 Property
2808
2809 A property is the definition of an individual attribute describing a
2810 calendar or a calendar component. A property takes the form defined
2811 by the "contentline" notation defined in section 4.1.1.
2812
2813 The following is an example of a property:
2814
2815 DTSTART:19960415T133000Z
2816
2817 This memo imposes no ordering of properties within an iCalendar
2818 object.
2819
2820 Property names, parameter names and enumerated parameter values are
2821 case insensitive. For example, the property name "DUE" is the same as
2822 "due" and "Due", DTSTART;TZID=US-Eastern:19980714T120000 is the same
2823 as DtStart;TzID=US-Eastern:19980714T120000.
2824
2825 4.6 Calendar Components
2826
2827 The body of the iCalendar object consists of a sequence of calendar
2828 properties and one or more calendar components. The calendar
2829 properties are attributes that apply to the calendar as a whole. The
2830 calendar components are collections of properties that express a
2831 particular calendar semantic. For example, the calendar component can
2832 specify an event, a to-do, a journal entry, time zone information, or
2833 free/busy time information, or an alarm.
2834
2835 The body of the iCalendar object is defined by the following
2836 notation:
2837
2838 icalbody = calprops component
2839
2840 calprops = 2*(
2841
2842 ; 'prodid' and 'version' are both REQUIRED,
2843 ; but MUST NOT occur more than once
2844
2845 prodid /version /
2846
2847 ; 'calscale' and 'method' are optional,
2848 ; but MUST NOT occur more than once
2849
2850 calscale /
2851 method /
2852
2853 x-prop
2854
2855
2856
2857
2858 Dawson & Stenerson Standards Track [Page 51]
2859
2860 RFC 2445 iCalendar November 1998
2861
2862
2863 )
2864
2865 component = 1*(eventc / todoc / journalc / freebusyc /
2866 / timezonec / iana-comp / x-comp)
2867
2868 iana-comp = "BEGIN" ":" iana-token CRLF
2869
2870 1*contentline
2871
2872 "END" ":" iana-token CRLF
2873
2874 x-comp = "BEGIN" ":" x-name CRLF
2875
2876 1*contentline
2877
2878 "END" ":" x-name CRLF
2879
2880 An iCalendar object MUST include the "PRODID" and "VERSION" calendar
2881 properties. In addition, it MUST include at least one calendar
2882 component. Special forms of iCalendar objects are possible to publish
2883 just busy time (i.e., only a "VFREEBUSY" calendar component) or time
2884 zone (i.e., only a "VTIMEZONE" calendar component) information. In
2885 addition, a complex iCalendar object is possible that is used to
2886 capture a complete snapshot of the contents of a calendar (e.g.,
2887 composite of many different calendar components). More commonly, an
2888 iCalendar object will consist of just a single "VEVENT", "VTODO" or
2889 "VJOURNAL" calendar component.
2890
2891 4.6.1 Event Component
2892
2893 Component Name: "VEVENT"
2894
2895 Purpose: Provide a grouping of component properties that describe an
2896 event.
2897
2898 Format Definition: A "VEVENT" calendar component is defined by the
2899 following notation:
2900
2901 eventc = "BEGIN" ":" "VEVENT" CRLF
2902 eventprop *alarmc
2903 "END" ":" "VEVENT" CRLF
2904
2905 eventprop = *(
2906
2907 ; the following are optional,
2908 ; but MUST NOT occur more than once
2909
2910 class / created / description / dtstart / geo /
2911
2912
2913
2914 Dawson & Stenerson Standards Track [Page 52]
2915
2916 RFC 2445 iCalendar November 1998
2917
2918
2919 last-mod / location / organizer / priority /
2920 dtstamp / seq / status / summary / transp /
2921 uid / url / recurid /
2922
2923 ; either 'dtend' or 'duration' may appear in
2924 ; a 'eventprop', but 'dtend' and 'duration'
2925 ; MUST NOT occur in the same 'eventprop'
2926
2927 dtend / duration /
2928
2929 ; the following are optional,
2930 ; and MAY occur more than once
2931
2932 attach / attendee / categories / comment /
2933 contact / exdate / exrule / rstatus / related /
2934 resources / rdate / rrule / x-prop
2935
2936 )
2937
2938 Description: A "VEVENT" calendar component is a grouping of component
2939 properties, and possibly including "VALARM" calendar components, that
2940 represents a scheduled amount of time on a calendar. For example, it
2941 can be an activity; such as a one-hour long, department meeting from
2942 8:00 AM to 9:00 AM, tomorrow. Generally, an event will take up time
2943 on an individual calendar. Hence, the event will appear as an opaque
2944 interval in a search for busy time. Alternately, the event can have
2945 its Time Transparency set to "TRANSPARENT" in order to prevent
2946 blocking of the event in searches for busy time.
2947
2948 The "VEVENT" is also the calendar component used to specify an
2949 anniversary or daily reminder within a calendar. These events have a
2950 DATE value type for the "DTSTART" property instead of the default
2951 data type of DATE-TIME. If such a "VEVENT" has a "DTEND" property, it
2952 MUST be specified as a DATE value also. The anniversary type of
2953 "VEVENT" can span more than one date (i.e, "DTEND" property value is
2954 set to a calendar date after the "DTSTART" property value).
2955
2956 The "DTSTART" property for a "VEVENT" specifies the inclusive start
2957 of the event. For recurring events, it also specifies the very first
2958 instance in the recurrence set. The "DTEND" property for a "VEVENT"
2959 calendar component specifies the non-inclusive end of the event. For
2960 cases where a "VEVENT" calendar component specifies a "DTSTART"
2961 property with a DATE data type but no "DTEND" property, the events
2962 non-inclusive end is the end of the calendar date specified by the
2963 "DTSTART" property. For cases where a "VEVENT" calendar component
2964 specifies a "DTSTART" property with a DATE-TIME data type but no
2965 "DTEND" property, the event ends on the same calendar date and time
2966 of day specified by the "DTSTART" property.
2967
2968
2969
2970 Dawson & Stenerson Standards Track [Page 53]
2971
2972 RFC 2445 iCalendar November 1998
2973
2974
2975 The "VEVENT" calendar component cannot be nested within another
2976 calendar component. However, "VEVENT" calendar components can be
2977 related to each other or to a "VTODO" or to a "VJOURNAL" calendar
2978 component with the "RELATED-TO" property.
2979
2980 Example: The following is an example of the "VEVENT" calendar
2981 component used to represent a meeting that will also be opaque to
2982 searches for busy time:
2983
2984 BEGIN:VEVENT
2985 UID:19970901T130000Z-123401@host.com
2986 DTSTAMP:19970901T1300Z
2987 DTSTART:19970903T163000Z
2988 DTEND:19970903T190000Z
2989 SUMMARY:Annual Employee Review
2990 CLASS:PRIVATE
2991 CATEGORIES:BUSINESS,HUMAN RESOURCES
2992 END:VEVENT
2993
2994 The following is an example of the "VEVENT" calendar component used
2995 to represent a reminder that will not be opaque, but rather
2996 transparent, to searches for busy time:
2997
2998 BEGIN:VEVENT
2999 UID:19970901T130000Z-123402@host.com
3000 DTSTAMP:19970901T1300Z
3001 DTSTART:19970401T163000Z
3002 DTEND:19970402T010000Z
3003 SUMMARY:Laurel is in sensitivity awareness class.
3004 CLASS:PUBLIC
3005 CATEGORIES:BUSINESS,HUMAN RESOURCES
3006 TRANSP:TRANSPARENT
3007 END:VEVENT
3008
3009 The following is an example of the "VEVENT" calendar component used
3010 to represent an anniversary that will occur annually. Since it takes
3011 up no time, it will not appear as opaque in a search for busy time;
3012 no matter what the value of the "TRANSP" property indicates:
3013
3014 BEGIN:VEVENT
3015 UID:19970901T130000Z-123403@host.com
3016 DTSTAMP:19970901T1300Z
3017 DTSTART:19971102
3018 SUMMARY:Our Blissful Anniversary
3019 CLASS:CONFIDENTIAL
3020 CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION
3021 RRULE:FREQ=YEARLY
3022 END:VEVENT
3023
3024
3025
3026 Dawson & Stenerson Standards Track [Page 54]
3027
3028 RFC 2445 iCalendar November 1998
3029
3030
3031 4.6.2 To-do Component
3032
3033 Component Name: VTODO
3034
3035 Purpose: Provide a grouping of calendar properties that describe a
3036 to-do.
3037
3038 Formal Definition: A "VTODO" calendar component is defined by the
3039 following notation:
3040
3041 todoc = "BEGIN" ":" "VTODO" CRLF
3042 todoprop *alarmc
3043 "END" ":" "VTODO" CRLF
3044
3045 todoprop = *(
3046
3047 ; the following are optional,
3048 ; but MUST NOT occur more than once
3049
3050 class / completed / created / description / dtstamp /
3051 dtstart / geo / last-mod / location / organizer /
3052 percent / priority / recurid / seq / status /
3053 summary / uid / url /
3054
3055 ; either 'due' or 'duration' may appear in
3056 ; a 'todoprop', but 'due' and 'duration'
3057 ; MUST NOT occur in the same 'todoprop'
3058
3059 due / duration /
3060
3061 ; the following are optional,
3062 ; and MAY occur more than once
3063 attach / attendee / categories / comment / contact /
3064 exdate / exrule / rstatus / related / resources /
3065 rdate / rrule / x-prop
3066
3067 )
3068
3069 Description: A "VTODO" calendar component is a grouping of component
3070 properties and possibly "VALARM" calendar components that represent
3071 an action-item or assignment. For example, it can be used to
3072 represent an item of work assigned to an individual; such as "turn in
3073 travel expense today".
3074
3075 The "VTODO" calendar component cannot be nested within another
3076 calendar component. However, "VTODO" calendar components can be
3077 related to each other or to a "VTODO" or to a "VJOURNAL" calendar
3078 component with the "RELATED-TO" property.
3079
3080
3081
3082 Dawson & Stenerson Standards Track [Page 55]
3083
3084 RFC 2445 iCalendar November 1998
3085
3086
3087 A "VTODO" calendar component without the "DTSTART" and "DUE" (or
3088 "DURATION") properties specifies a to-do that will be associated with
3089 each successive calendar date, until it is completed.
3090
3091 Example: The following is an example of a "VTODO" calendar component:
3092
3093 BEGIN:VTODO
3094 UID:19970901T130000Z-123404@host.com
3095 DTSTAMP:19970901T1300Z
3096 DTSTART:19970415T133000Z
3097 DUE:19970416T045959Z
3098 SUMMARY:1996 Income Tax Preparation
3099 CLASS:CONFIDENTIAL
3100 CATEGORIES:FAMILY,FINANCE
3101 PRIORITY:1
3102 STATUS:NEEDS-ACTION
3103 END:VTODO
3104
3105 4.6.3 Journal Component
3106
3107 Component Name: VJOURNAL
3108
3109 Purpose: Provide a grouping of component properties that describe a
3110 journal entry.
3111
3112 Formal Definition: A "VJOURNAL" calendar component is defined by the
3113 following notation:
3114
3115 journalc = "BEGIN" ":" "VJOURNAL" CRLF
3116 jourprop
3117 "END" ":" "VJOURNAL" CRLF
3118
3119 jourprop = *(
3120
3121 ; the following are optional,
3122 ; but MUST NOT occur more than once
3123
3124 class / created / description / dtstart / dtstamp /
3125 last-mod / organizer / recurid / seq / status /
3126 summary / uid / url /
3127
3128 ; the following are optional,
3129 ; and MAY occur more than once
3130
3131 attach / attendee / categories / comment /
3132 contact / exdate / exrule / related / rdate /
3133 rrule / rstatus / x-prop
3134
3135
3136
3137
3138 Dawson & Stenerson Standards Track [Page 56]
3139
3140 RFC 2445 iCalendar November 1998
3141
3142
3143 )
3144
3145 Description: A "VJOURNAL" calendar component is a grouping of
3146 component properties that represent one or more descriptive text
3147 notes associated with a particular calendar date. The "DTSTART"
3148 property is used to specify the calendar date that the journal entry
3149 is associated with. Generally, it will have a DATE value data type,
3150 but it can also be used to specify a DATE-TIME value data type.
3151 Examples of a journal entry include a daily record of a legislative
3152 body or a journal entry of individual telephone contacts for the day
3153 or an ordered list of accomplishments for the day. The "VJOURNAL"
3154 calendar component can also be used to associate a document with a
3155 calendar date.
3156
3157 The "VJOURNAL" calendar component does not take up time on a
3158 calendar. Hence, it does not play a role in free or busy time
3159 searches - - it is as though it has a time transparency value of
3160 TRANSPARENT. It is transparent to any such searches.
3161
3162 The "VJOURNAL" calendar component cannot be nested within another
3163 calendar component. However, "VJOURNAL" calendar components can be
3164 related to each other or to a "VEVENT" or to a "VTODO" calendar
3165 component, with the "RELATED-TO" property.
3166
3167 Example: The following is an example of the "VJOURNAL" calendar
3168 component:
3169
3170 BEGIN:VJOURNAL
3171 UID:19970901T130000Z-123405@host.com
3172 DTSTAMP:19970901T1300Z
3173 DTSTART;VALUE=DATE:19970317
3174 SUMMARY:Staff meeting minutes
3175 DESCRIPTION:1. Staff meeting: Participants include Joe\, Lisa
3176 and Bob. Aurora project plans were reviewed. There is currently
3177 no budget reserves for this project. Lisa will escalate to
3178 management. Next meeting on Tuesday.\n
3179 2. Telephone Conference: ABC Corp. sales representative called
3180 to discuss new printer. Promised to get us a demo by Friday.\n
3181 3. Henry Miller (Handsoff Insurance): Car was totaled by tree.
3182 Is looking into a loaner car. 654-2323 (tel).
3183 END:VJOURNAL
3184
3185
3186
3187
3188
3189
3190
3191
3192
3193
3194 Dawson & Stenerson Standards Track [Page 57]
3195
3196 RFC 2445 iCalendar November 1998
3197
3198
3199 4.6.4 Free/Busy Component
3200
3201 Component Name: VFREEBUSY
3202
3203 Purpose: Provide a grouping of component properties that describe
3204 either a request for free/busy time, describe a response to a request
3205 for free/busy time or describe a published set of busy time.
3206
3207 Formal Definition: A "VFREEBUSY" calendar component is defined by the
3208 following notation:
3209
3210 freebusyc = "BEGIN" ":" "VFREEBUSY" CRLF
3211 fbprop
3212 "END" ":" "VFREEBUSY" CRLF
3213
3214 fbprop = *(
3215
3216 ; the following are optional,
3217 ; but MUST NOT occur more than once
3218
3219 contact / dtstart / dtend / duration / dtstamp /
3220 organizer / uid / url /
3221
3222 ; the following are optional,
3223 ; and MAY occur more than once
3224
3225 attendee / comment / freebusy / rstatus / x-prop
3226
3227 )
3228
3229 Description: A "VFREEBUSY" calendar component is a grouping of
3230 component properties that represents either a request for, a reply to
3231 a request for free or busy time information or a published set of
3232 busy time information.
3233
3234 When used to request free/busy time information, the "ATTENDEE"
3235 property specifies the calendar users whose free/busy time is being
3236 requested; the "ORGANIZER" property specifies the calendar user who
3237 is requesting the free/busy time; the "DTSTART" and "DTEND"
3238 properties specify the window of time for which the free/busy time is
3239 being requested; the "UID" and "DTSTAMP" properties are specified to
3240 assist in proper sequencing of multiple free/busy time requests.
3241
3242 When used to reply to a request for free/busy time, the "ATTENDEE"
3243 property specifies the calendar user responding to the free/busy time
3244 request; the "ORGANIZER" property specifies the calendar user that
3245 originally requested the free/busy time; the "FREEBUSY" property
3246 specifies the free/busy time information (if it exists); and the
3247
3248
3249
3250 Dawson & Stenerson Standards Track [Page 58]
3251
3252 RFC 2445 iCalendar November 1998
3253
3254
3255 "UID" and "DTSTAMP" properties are specified to assist in proper
3256 sequencing of multiple free/busy time replies.
3257
3258 When used to publish busy time, the "ORGANIZER" property specifies
3259 the calendar user associated with the published busy time; the
3260 "DTSTART" and "DTEND" properties specify an inclusive time window
3261 that surrounds the busy time information; the "FREEBUSY" property
3262 specifies the published busy time information; and the "DTSTAMP"
3263 property specifies the date/time that iCalendar object was created.
3264
3265 The "VFREEBUSY" calendar component cannot be nested within another
3266 calendar component. Multiple "VFREEBUSY" calendar components can be
3267 specified within an iCalendar object. This permits the grouping of
3268 Free/Busy information into logical collections, such as monthly
3269 groups of busy time information.
3270
3271 The "VFREEBUSY" calendar component is intended for use in iCalendar
3272 object methods involving requests for free time, requests for busy
3273 time, requests for both free and busy, and the associated replies.
3274
3275 Free/Busy information is represented with the "FREEBUSY" property.
3276 This property provides a terse representation of time periods. One or
3277 more "FREEBUSY" properties can be specified in the "VFREEBUSY"
3278 calendar component.
3279
3280 When present in a "VFREEBUSY" calendar component, the "DTSTART" and
3281 "DTEND" properties SHOULD be specified prior to any "FREEBUSY"
3282 properties. In a free time request, these properties can be used in
3283 combination with the "DURATION" property to represent a request for a
3284 duration of free time within a specified window of time.
3285
3286 The recurrence properties ("RRULE", "EXRULE", "RDATE", "EXDATE") are
3287 not permitted within a "VFREEBUSY" calendar component. Any recurring
3288 events are resolved into their individual busy time periods using the
3289 "FREEBUSY" property.
3290
3291 Example: The following is an example of a "VFREEBUSY" calendar
3292 component used to request free or busy time information:
3293
3294 BEGIN:VFREEBUSY
3295 ORGANIZER:MAILTO:jane_doe@host1.com
3296 ATTENDEE:MAILTO:john_public@host2.com
3297 DTSTART:19971015T050000Z
3298 DTEND:19971016T050000Z
3299 DTSTAMP:19970901T083000Z
3300 END:VFREEBUSY
3301
3302
3303
3304
3305
3306 Dawson & Stenerson Standards Track [Page 59]
3307
3308 RFC 2445 iCalendar November 1998
3309
3310
3311 The following is an example of a "VFREEBUSY" calendar component used
3312 to reply to the request with busy time information:
3313
3314 BEGIN:VFREEBUSY
3315 ORGANIZER:MAILTO:jane_doe@host1.com
3316 ATTENDEE:MAILTO:john_public@host2.com
3317 DTSTAMP:19970901T100000Z
3318 FREEBUSY;VALUE=PERIOD:19971015T050000Z/PT8H30M,
3319 19971015T160000Z/PT5H30M,19971015T223000Z/PT6H30M
3320 URL:http://host2.com/pub/busy/jpublic-01.ifb
3321 COMMENT:This iCalendar file contains busy time information for
3322 the next three months.
3323 END:VFREEBUSY
3324
3325 The following is an example of a "VFREEBUSY" calendar component used
3326 to publish busy time information.
3327
3328 BEGIN:VFREEBUSY
3329 ORGANIZER:jsmith@host.com
3330 DTSTART:19980313T141711Z
3331 DTEND:19980410T141711Z
3332 FREEBUSY:19980314T233000Z/19980315T003000Z
3333 FREEBUSY:19980316T153000Z/19980316T163000Z
3334 FREEBUSY:19980318T030000Z/19980318T040000Z
3335 URL:http://www.host.com/calendar/busytime/jsmith.ifb
3336 END:VFREEBUSY
3337
3338 4.6.5 Time Zone Component
3339
3340 Component Name: VTIMEZONE
3341
3342 Purpose: Provide a grouping of component properties that defines a
3343 time zone.
3344
3345 Formal Definition: A "VTIMEZONE" calendar component is defined by the
3346 following notation:
3347
3348 timezonec = "BEGIN" ":" "VTIMEZONE" CRLF
3349
3350 2*(
3351
3352 ; 'tzid' is required, but MUST NOT occur more
3353 ; than once
3354
3355 tzid /
3356
3357 ; 'last-mod' and 'tzurl' are optional,
3358 but MUST NOT occur more than once
3359
3360
3361
3362 Dawson & Stenerson Standards Track [Page 60]
3363
3364 RFC 2445 iCalendar November 1998
3365
3366
3367 last-mod / tzurl /
3368
3369 ; one of 'standardc' or 'daylightc' MUST occur
3370 ..; and each MAY occur more than once.
3371
3372 standardc / daylightc /
3373
3374 ; the following is optional,
3375 ; and MAY occur more than once
3376
3377 x-prop
3378
3379 )
3380
3381 "END" ":" "VTIMEZONE" CRLF
3382
3383 standardc = "BEGIN" ":" "STANDARD" CRLF
3384
3385 tzprop
3386
3387 "END" ":" "STANDARD" CRLF
3388
3389 daylightc = "BEGIN" ":" "DAYLIGHT" CRLF
3390
3391 tzprop
3392
3393 "END" ":" "DAYLIGHT" CRLF
3394
3395 tzprop = 3*(
3396
3397 ; the following are each REQUIRED,
3398 ; but MUST NOT occur more than once
3399
3400 dtstart / tzoffsetto / tzoffsetfrom /
3401
3402 ; the following are optional,
3403 ; and MAY occur more than once
3404
3405 comment / rdate / rrule / tzname / x-prop
3406
3407 )
3408
3409 Description: A time zone is unambiguously defined by the set of time
3410 measurement rules determined by the governing body for a given
3411 geographic area. These rules describe at a minimum the base offset
3412 from UTC for the time zone, often referred to as the Standard Time
3413 offset. Many locations adjust their Standard Time forward or backward
3414 by one hour, in order to accommodate seasonal changes in number of
3415
3416
3417
3418 Dawson & Stenerson Standards Track [Page 61]
3419
3420 RFC 2445 iCalendar November 1998
3421
3422
3423 daylight hours, often referred to as Daylight Saving Time. Some
3424 locations adjust their time by a fraction of an hour. Standard Time
3425 is also known as Winter Time. Daylight Saving Time is also known as
3426 Advanced Time, Summer Time, or Legal Time in certain countries. The
3427 following table shows the changes in time zone rules in effect for
3428 New York City starting from 1967. Each line represents a description
3429 or rule for a particular observance.
3430
3431 Effective Observance Rule
3432
3433 Date (Date/Time) Offset Abbreviation
3434
3435 1967-* last Sun in Oct, 02:00 -0500 EST
3436
3437 1967-1973 last Sun in Apr, 02:00 -0400 EDT
3438
3439 1974-1974 Jan 6, 02:00 -0400 EDT
3440
3441 1975-1975 Feb 23, 02:00 -0400 EDT
3442
3443 1976-1986 last Sun in Apr, 02:00 -0400 EDT
3444
3445 1987-* first Sun in Apr, 02:00 -0400 EDT
3446
3447 Note: The specification of a global time zone registry is not
3448 addressed by this document and is left for future study.
3449 However, implementers may find the Olson time zone database [TZ]
3450 a useful reference. It is an informal, public-domain collection
3451 of time zone information, which is currently being maintained by
3452 volunteer Internet participants, and is used in several
3453 operating systems. This database contains current and historical
3454 time zone information for a wide variety of locations around the
3455 globe; it provides a time zone identifier for every unique time
3456 zone rule set in actual use since 1970, with historical data
3457 going back to the introduction of standard time.
3458
3459 Interoperability between two calendaring and scheduling applications,
3460 especially for recurring events, to-dos or journal entries, is
3461 dependent on the ability to capture and convey date and time
3462 information in an unambiguous format. The specification of current
3463 time zone information is integral to this behavior.
3464
3465 If present, the "VTIMEZONE" calendar component defines the set of
3466 Standard Time and Daylight Saving Time observances (or rules) for a
3467 particular time zone for a given interval of time. The "VTIMEZONE"
3468 calendar component cannot be nested within other calendar components.
3469 Multiple "VTIMEZONE" calendar components can exist in an iCalendar
3470 object. In this situation, each "VTIMEZONE" MUST represent a unique
3471
3472
3473
3474 Dawson & Stenerson Standards Track [Page 62]
3475
3476 RFC 2445 iCalendar November 1998
3477
3478
3479 time zone definition. This is necessary for some classes of events,
3480 such as airline flights, that start in one time zone and end in
3481 another.
3482
3483 The "VTIMEZONE" calendar component MUST be present if the iCalendar
3484 object contains an RRULE that generates dates on both sides of a time
3485 zone shift (e.g. both in Standard Time and Daylight Saving Time)
3486 unless the iCalendar object intends to convey a floating time (See
3487 the section "4.1.10.11 Time" for proper interpretation of floating
3488 time). It can be present if the iCalendar object does not contain
3489 such a RRULE. In addition, if a RRULE is present, there MUST be valid
3490 time zone information for all recurrence instances.
3491
3492 The "VTIMEZONE" calendar component MUST include the "TZID" property
3493 and at least one definition of a standard or daylight component. The
3494 standard or daylight component MUST include the "DTSTART",
3495 "TZOFFSETFROM" and "TZOFFSETTO" properties.
3496
3497 An individual "VTIMEZONE" calendar component MUST be specified for
3498 each unique "TZID" parameter value specified in the iCalendar object.
3499
3500 Each "VTIMEZONE" calendar component consists of a collection of one
3501 or more sub-components that describe the rule for a particular
3502 observance (either a Standard Time or a Daylight Saving Time
3503 observance). The "STANDARD" sub-component consists of a collection of
3504 properties that describe Standard Time. The "DAYLIGHT" sub-component
3505 consists of a collection of properties that describe Daylight Saving
3506 Time. In general this collection of properties consists of:
3507
3508 - the first onset date-time for the observance
3509
3510 - the last onset date-time for the observance, if a last onset
3511 is known.
3512
3513 - the offset to be applied for the observance
3514
3515 - a rule that describes the day and time when the observance
3516 takes effect
3517
3518 - an optional name for the observance
3519
3520 For a given time zone, there may be multiple unique definitions of
3521 the observances over a period of time. Each observance is described
3522 using either a "STANDARD" or "DAYLIGHT" sub-component. The collection
3523 of these sub-components is used to describe the time zone for a given
3524 period of time. The offset to apply at any given time is found by
3525 locating the observance that has the last onset date and time before
3526 the time in question, and using the offset value from that
3527
3528
3529
3530 Dawson & Stenerson Standards Track [Page 63]
3531
3532 RFC 2445 iCalendar November 1998
3533
3534
3535 observance.
3536
3537 The top-level properties in a "VTIMEZONE" calendar component are:
3538
3539 The mandatory "TZID" property is a text value that uniquely
3540 identifies the VTIMZONE calendar component within the scope of an
3541 iCalendar object.
3542
3543 The optional "LAST-MODIFIED" property is a UTC value that specifies
3544 the date and time that this time zone definition was last updated.
3545
3546 The optional "TZURL" property is url value that points to a published
3547 VTIMEZONE definition. TZURL SHOULD refer to a resource that is
3548 accessible by anyone who might need to interpret the object. This
3549 SHOULD NOT normally be a file: URL or other URL that is not widely-
3550 accessible.
3551
3552 The collection of properties that are used to define the STANDARD and
3553 DAYLIGHT sub-components include:
3554
3555 The mandatory "DTSTART" property gives the effective onset date and
3556 local time for the time zone sub-component definition. "DTSTART" in
3557 this usage MUST be specified as a local DATE-TIME value.
3558
3559 The mandatory "TZOFFSETFROM" property gives the UTC offset which is
3560 in use when the onset of this time zone observance begins.
3561 "TZOFFSETFROM" is combined with "DTSTART" to define the effective
3562 onset for the time zone sub-component definition. For example, the
3563 following represents the time at which the observance of Standard
3564 Time took effect in Fall 1967 for New York City:
3565
3566 DTSTART:19671029T020000
3567
3568 TZOFFSETFROM:-0400
3569
3570 The mandatory "TZOFFSETTO " property gives the UTC offset for the
3571 time zone sub-component (Standard Time or Daylight Saving Time) when
3572 this observance is in use.
3573
3574 The optional "TZNAME" property is the customary name for the time
3575 zone. It may be specified multiple times, to allow for specifying
3576 multiple language variants of the time zone names. This could be used
3577 for displaying dates.
3578
3579 If specified, the onset for the observance defined by the time zone
3580 sub-component is defined by either the "RRULE" or "RDATE" property.
3581 If neither is specified, only one sub-component can be specified in
3582 the "VTIMEZONE" calendar component and it is assumed that the single
3583
3584
3585
3586 Dawson & Stenerson Standards Track [Page 64]
3587
3588 RFC 2445 iCalendar November 1998
3589
3590
3591 observance specified is always in effect.
3592
3593 The "RRULE" property defines the recurrence rule for the onset of the
3594 observance defined by this time zone sub-component. Some specific
3595 requirements for the usage of RRULE for this purpose include:
3596
3597 - If observance is known to have an effective end date, the
3598 "UNTIL" recurrence rule parameter MUST be used to specify the
3599 last valid onset of this observance (i.e., the UNTIL date-time
3600 will be equal to the last instance generated by the recurrence
3601 pattern). It MUST be specified in UTC time.
3602
3603 - The "DTSTART" and the "TZOFFSETTO" properties MUST be used
3604 when generating the onset date-time values (instances) from the
3605 RRULE.
3606
3607 Alternatively, the "RDATE" property can be used to define the onset
3608 of the observance by giving the individual onset date and times.
3609 "RDATE" in this usage MUST be specified as a local DATE-TIME value in
3610 UTC time.
3611
3612 The optional "COMMENT" property is also allowed for descriptive
3613 explanatory text.
3614
3615 Example: The following are examples of the "VTIMEZONE" calendar
3616 component:
3617
3618 This is an example showing time zone information for the Eastern
3619 United States using "RDATE" property. Note that this is only suitable
3620 for a recurring event that starts on or later than April 6, 1997 at
3621 03:00:00 EDT (i.e., the earliest effective transition date and time)
3622 and ends no later than April 7, 1998 02:00:00 EST (i.e., latest valid
3623 date and time for EST in this scenario). For example, this can be
3624 used for a recurring event that occurs every Friday, 8am-9:00 AM,
3625 starting June 1, 1997, ending December 31, 1997.
3626
3627 BEGIN:VTIMEZONE
3628 TZID:US-Eastern
3629 LAST-MODIFIED:19870101T000000Z
3630 BEGIN:STANDARD
3631 DTSTART:19971026T020000
3632 RDATE:19971026T020000
3633 TZOFFSETFROM:-0400
3634 TZOFFSETTO:-0500
3635 TZNAME:EST
3636 END:STANDARD
3637 BEGIN:DAYLIGHT
3638 DTSTART:19971026T020000
3639
3640
3641
3642 Dawson & Stenerson Standards Track [Page 65]
3643
3644 RFC 2445 iCalendar November 1998
3645
3646
3647 RDATE:19970406T020000
3648 TZOFFSETFROM:-0500
3649 TZOFFSETTO:-0400
3650 TZNAME:EDT
3651 END:DAYLIGHT
3652 END:VTIMEZONE
3653
3654 This is a simple example showing the current time zone rules for the
3655 Eastern United States using a RRULE recurrence pattern. Note that
3656 there is no effective end date to either of the Standard Time or
3657 Daylight Time rules. This information would be valid for a recurring
3658 event starting today and continuing indefinitely.
3659
3660 BEGIN:VTIMEZONE
3661 TZID:US-Eastern
3662 LAST-MODIFIED:19870101T000000Z
3663 TZURL:http://zones.stds_r_us.net/tz/US-Eastern
3664 BEGIN:STANDARD
3665 DTSTART:19671029T020000
3666 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
3667 TZOFFSETFROM:-0400
3668 TZOFFSETTO:-0500
3669 TZNAME:EST
3670 END:STANDARD
3671 BEGIN:DAYLIGHT
3672 DTSTART:19870405T020000
3673 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
3674 TZOFFSETFROM:-0500
3675 TZOFFSETTO:-0400
3676 TZNAME:EDT
3677 END:DAYLIGHT
3678 END:VTIMEZONE
3679
3680 This is an example showing a fictitious set of rules for the Eastern
3681 United States, where the Daylight Time rule has an effective end date
3682 (i.e., after that date, Daylight Time is no longer observed).
3683
3684 BEGIN:VTIMEZONE
3685 TZID:US--Fictitious-Eastern
3686 LAST-MODIFIED:19870101T000000Z
3687 BEGIN:STANDARD
3688 DTSTART:19671029T020000
3689 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
3690 TZOFFSETFROM:-0400
3691 TZOFFSETTO:-0500
3692 TZNAME:EST
3693 END:STANDARD
3694
3695
3696
3697
3698 Dawson & Stenerson Standards Track [Page 66]
3699
3700 RFC 2445 iCalendar November 1998
3701
3702
3703 BEGIN:DAYLIGHT
3704 DTSTART:19870405T020000
3705 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T070000Z
3706 TZOFFSETFROM:-0500
3707 TZOFFSETTO:-0400
3708 TZNAME:EDT
3709 END:DAYLIGHT
3710 END:VTIMEZONE
3711
3712 This is an example showing a fictitious set of rules for the Eastern
3713 United States, where the first Daylight Time rule has an effective
3714 end date. There is a second Daylight Time rule that picks up where
3715 the other left off.
3716
3717 BEGIN:VTIMEZONE
3718 TZID:US--Fictitious-Eastern
3719 LAST-MODIFIED:19870101T000000Z
3720 BEGIN:STANDARD
3721 DTSTART:19671029T020000
3722 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
3723 TZOFFSETFROM:-0400
3724 TZOFFSETTO:-0500
3725 TZNAME:EST
3726 END:STANDARD
3727 BEGIN:DAYLIGHT
3728 DTSTART:19870405T020000
3729 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T070000Z
3730 TZOFFSETFROM:-0500
3731 TZOFFSETTO:-0400
3732 TZNAME:EDT
3733 END:DAYLIGHT
3734 BEGIN:DAYLIGHT
3735 DTSTART:19990424T020000
3736 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=4
3737 TZOFFSETFROM:-0500
3738 TZOFFSETTO:-0400
3739 TZNAME:EDT
3740 END:DAYLIGHT
3741 END:VTIMEZONE
3742
3743 4.6.6 Alarm Component
3744
3745 Component Name: VALARM
3746
3747 Purpose: Provide a grouping of component properties that define an
3748 alarm.
3749
3750
3751
3752
3753
3754 Dawson & Stenerson Standards Track [Page 67]
3755
3756 RFC 2445 iCalendar November 1998
3757
3758
3759 Formal Definition: A "VALARM" calendar component is defined by the
3760 following notation:
3761
3762 alarmc = "BEGIN" ":" "VALARM" CRLF
3763 (audioprop / dispprop / emailprop / procprop)
3764 "END" ":" "VALARM" CRLF
3765
3766 audioprop = 2*(
3767
3768 ; 'action' and 'trigger' are both REQUIRED,
3769 ; but MUST NOT occur more than once
3770
3771 action / trigger /
3772
3773 ; 'duration' and 'repeat' are both optional,
3774 ; and MUST NOT occur more than once each,
3775 ; but if one occurs, so MUST the other
3776
3777 duration / repeat /
3778
3779 ; the following is optional,
3780 ; but MUST NOT occur more than once
3781
3782 attach /
3783
3784 ; the following is optional,
3785 ; and MAY occur more than once
3786
3787 x-prop
3788
3789 )
3790
3791
3792
3793 dispprop = 3*(
3794
3795 ; the following are all REQUIRED,
3796 ; but MUST NOT occur more than once
3797
3798 action / description / trigger /
3799
3800 ; 'duration' and 'repeat' are both optional,
3801 ; and MUST NOT occur more than once each,
3802 ; but if one occurs, so MUST the other
3803
3804 duration / repeat /
3805
3806 ; the following is optional,
3807
3808
3809
3810 Dawson & Stenerson Standards Track [Page 68]
3811
3812 RFC 2445 iCalendar November 1998
3813
3814
3815 ; and MAY occur more than once
3816
3817 *x-prop
3818
3819 )
3820
3821
3822
3823 emailprop = 5*(
3824
3825 ; the following are all REQUIRED,
3826 ; but MUST NOT occur more than once
3827
3828 action / description / trigger / summary
3829
3830 ; the following is REQUIRED,
3831 ; and MAY occur more than once
3832
3833 attendee /
3834
3835 ; 'duration' and 'repeat' are both optional,
3836 ; and MUST NOT occur more than once each,
3837 ; but if one occurs, so MUST the other
3838
3839 duration / repeat /
3840
3841 ; the following are optional,
3842 ; and MAY occur more than once
3843
3844 attach / x-prop
3845
3846 )
3847
3848
3849
3850 procprop = 3*(
3851
3852 ; the following are all REQUIRED,
3853 ; but MUST NOT occur more than once
3854
3855 action / attach / trigger /
3856
3857 ; 'duration' and 'repeat' are both optional,
3858 ; and MUST NOT occur more than once each,
3859 ; but if one occurs, so MUST the other
3860
3861 duration / repeat /
3862
3863
3864
3865
3866 Dawson & Stenerson Standards Track [Page 69]
3867
3868 RFC 2445 iCalendar November 1998
3869
3870
3871 ; 'description' is optional,
3872 ; and MUST NOT occur more than once
3873
3874 description /
3875
3876 ; the following is optional,
3877 ; and MAY occur more than once
3878
3879 x-prop
3880
3881 )
3882
3883 Description: A "VALARM" calendar component is a grouping of component
3884 properties that is a reminder or alarm for an event or a to-do. For
3885 example, it may be used to define a reminder for a pending event or
3886 an overdue to-do.
3887
3888 The "VALARM" calendar component MUST include the "ACTION" and
3889 "TRIGGER" properties. The "ACTION" property further constrains the
3890 "VALARM" calendar component in the following ways:
3891
3892 When the action is "AUDIO", the alarm can also include one and only
3893 one "ATTACH" property, which MUST point to a sound resource, which is
3894 rendered when the alarm is triggered.
3895
3896 When the action is "DISPLAY", the alarm MUST also include a
3897 "DESCRIPTION" property, which contains the text to be displayed when
3898 the alarm is triggered.
3899
3900 When the action is "EMAIL", the alarm MUST include a "DESCRIPTION"
3901 property, which contains the text to be used as the message body, a
3902 "SUMMARY" property, which contains the text to be used as the message
3903 subject, and one or more "ATTENDEE" properties, which contain the
3904 email address of attendees to receive the message. It can also
3905 include one or more "ATTACH" properties, which are intended to be
3906 sent as message attachments. When the alarm is triggered, the email
3907 message is sent.
3908
3909 When the action is "PROCEDURE", the alarm MUST include one and only
3910 one "ATTACH" property, which MUST point to a procedure resource,
3911 which is invoked when the alarm is triggered.
3912
3913 The "VALARM" calendar component MUST only appear within either a
3914 "VEVENT" or "VTODO" calendar component. "VALARM" calendar components
3915 cannot be nested. Multiple mutually independent "VALARM" calendar
3916 components can be specified for a single "VEVENT" or "VTODO" calendar
3917 component.
3918
3919
3920
3921
3922 Dawson & Stenerson Standards Track [Page 70]
3923
3924 RFC 2445 iCalendar November 1998
3925
3926
3927 The "TRIGGER" property specifies when the alarm will be triggered.
3928 The "TRIGGER" property specifies a duration prior to the start of an
3929 event or a to-do. The "TRIGGER" edge may be explicitly set to be
3930 relative to the "START" or "END" of the event or to-do with the
3931 "RELATED" parameter of the "TRIGGER" property. The "TRIGGER" property
3932 value type can alternatively be set to an absolute calendar date and
3933 time of day value.
3934
3935 In an alarm set to trigger on the "START" of an event or to-do, the
3936 "DTSTART" property MUST be present in the associated event or to-do.
3937 In an alarm in a "VEVENT" calendar component set to trigger on the
3938 "END" of the event, either the "DTEND" property MUST be present, or
3939 the "DTSTART" and "DURATION" properties MUST both be present. In an
3940 alarm in a "VTODO" calendar component set to trigger on the "END" of
3941 the to-do, either the "DUE" property MUST be present, or the
3942 "DTSTART" and "DURATION" properties MUST both be present.
3943
3944 The alarm can be defined such that it triggers repeatedly. A
3945 definition of an alarm with a repeating trigger MUST include both the
3946 "DURATION" and "REPEAT" properties. The "DURATION" property specifies
3947 the delay period, after which the alarm will repeat. The "REPEAT"
3948 property specifies the number of additional repetitions that the
3949 alarm will triggered. This repitition count is in addition to the
3950 initial triggering of the alarm. Both of these properties MUST be
3951 present in order to specify a repeating alarm. If one of these two
3952 properties is absent, then the alarm will not repeat beyond the
3953 initial trigger.
3954
3955 The "ACTION" property is used within the "VALARM" calendar component
3956 to specify the type of action invoked when the alarm is triggered.
3957 The "VALARM" properties provide enough information for a specific
3958 action to be invoked. It is typically the responsibility of a
3959 "Calendar User Agent" (CUA) to deliver the alarm in the specified
3960 fashion. An "ACTION" property value of AUDIO specifies an alarm that
3961 causes a sound to be played to alert the user; DISPLAY specifies an
3962 alarm that causes a text message to be displayed to the user; EMAIL
3963 specifies an alarm that causes an electronic email message to be
3964 delivered to one or more email addresses; and PROCEDURE specifies an
3965 alarm that causes a procedure to be executed. The "ACTION" property
3966 MUST specify one and only one of these values.
3967
3968 In an AUDIO alarm, if the optional "ATTACH" property is included, it
3969 MUST specify an audio sound resource. The intention is that the sound
3970 will be played as the alarm effect. If an "ATTACH" property is
3971 specified that does not refer to a sound resource, or if the
3972 specified sound resource cannot be rendered (because its format is
3973 unsupported, or because it cannot be retrieved), then the CUA or
3974 other entity responsible for playing the sound may choose a fallback
3975
3976
3977
3978 Dawson & Stenerson Standards Track [Page 71]
3979
3980 RFC 2445 iCalendar November 1998
3981
3982
3983 action, such as playing a built-in default sound, or playing no sound
3984 at all.
3985
3986 In a DISPLAY alarm, the intended alarm effect is for the text value
3987 of the "DESCRIPTION" property to be displayed to the user.
3988
3989 In an EMAIL alarm, the intended alarm effect is for an email message
3990 to be composed and delivered to all the addresses specified by the
3991 "ATTENDEE" properties in the "VALARM" calendar component. The
3992 "DESCRIPTION" property of the "VALARM" calendar component MUST be
3993 used as the body text of the message, and the "SUMMARY" property MUST
3994 be used as the subject text. Any "ATTACH" properties in the "VALARM"
3995 calendar component SHOULD be sent as attachments to the message.
3996
3997 In a PROCEDURE alarm, the "ATTACH" property in the "VALARM" calendar
3998 component MUST specify a procedure or program that is intended to be
3999 invoked as the alarm effect. If the procedure or program is in a
4000 format that cannot be rendered, then no procedure alarm will be
4001 invoked. If the "DESCRIPTION" property is present, its value
4002 specifies the argument string to be passed to the procedure or
4003 program. "Calendar User Agents" that receive an iCalendar object with
4004 this category of alarm, can disable or allow the "Calendar User" to
4005 disable, or otherwise ignore this type of alarm. While a very useful
4006 alarm capability, the PROCEDURE type of alarm SHOULD be treated by
4007 the "Calendar User Agent" as a potential security risk.
4008
4009 Example: The following example is for a "VALARM" calendar component
4010 that specifies an audio alarm that will sound at a precise time and
4011 repeat 4 more times at 15 minute intervals:
4012
4013 BEGIN:VALARM
4014 TRIGGER;VALUE=DATE-TIME:19970317T133000Z
4015 REPEAT:4
4016 DURATION:PT15M
4017 ACTION:AUDIO
4018 ATTACH;FMTTYPE=audio/basic:ftp://host.com/pub/sounds/bell-01.aud
4019 END:VALARM
4020
4021 The following example is for a "VALARM" calendar component that
4022 specifies a display alarm that will trigger 30 minutes before the
4023 scheduled start of the event or the due date/time of the to-do it is
4024 associated with and will repeat 2 more times at 15 minute intervals:
4025
4026 BEGIN:VALARM
4027 TRIGGER:-PT30M
4028 REPEAT:2
4029 DURATION:PT15M
4030 ACTION:DISPLAY
4031
4032
4033
4034 Dawson & Stenerson Standards Track [Page 72]
4035
4036 RFC 2445 iCalendar November 1998
4037
4038
4039 DESCRIPTION:Breakfast meeting with executive\n
4040 team at 8:30 AM EST.
4041 END:VALARM
4042
4043 The following example is for a "VALARM" calendar component that
4044 specifies an email alarm that will trigger 2 days before the
4045 scheduled due date/time of a to-do it is associated with. It does not
4046 repeat. The email has a subject, body and attachment link.
4047
4048 BEGIN:VALARM
4049 TRIGGER:-P2D
4050 ACTION:EMAIL
4051 ATTENDEE:MAILTO:john_doe@host.com
4052 SUMMARY:*** REMINDER: SEND AGENDA FOR WEEKLY STAFF MEETING ***
4053 DESCRIPTION:A draft agenda needs to be sent out to the attendees
4054 to the weekly managers meeting (MGR-LIST). Attached is a
4055 pointer the document template for the agenda file.
4056 ATTACH;FMTTYPE=application/binary:http://host.com/templates/agen
4057 da.doc
4058 END:VALARM
4059
4060 The following example is for a "VALARM" calendar component that
4061 specifies a procedural alarm that will trigger at a precise date/time
4062 and will repeat 23 more times at one hour intervals. The alarm will
4063 invoke a procedure file.
4064
4065 BEGIN:VALARM
4066 TRIGGER;VALUE=DATE-TIME:19980101T050000Z
4067 REPEAT:23
4068 DURATION:PT1H
4069 ACTION:PROCEDURE
4070 ATTACH;FMTTYPE=application/binary:ftp://host.com/novo-
4071 procs/felizano.exe
4072 END:VALARM
4073
4074 4.7 Calendar Properties
4075
4076 The Calendar Properties are attributes that apply to the iCalendar
4077 object, as a whole. These properties do not appear within a calendar
4078 component. They SHOULD be specified after the "BEGIN:VCALENDAR"
4079 property and prior to any calendar component.
4080
4081 4.7.1 Calendar Scale
4082
4083 Property Name: CALSCALE
4084
4085 Purpose: This property defines the calendar scale used for the
4086 calendar information specified in the iCalendar object.
4087
4088
4089
4090 Dawson & Stenerson Standards Track [Page 73]
4091
4092 RFC 2445 iCalendar November 1998
4093
4094
4095 Value Type: TEXT
4096
4097 Property Parameters: Non-standard property parameters can be
4098 specified on this property.
4099
4100 Conformance: Property can be specified in an iCalendar object. The
4101 default value is "GREGORIAN".
4102
4103 Description: This memo is based on the Gregorian calendar scale. The
4104 Gregorian calendar scale is assumed if this property is not specified
4105 in the iCalendar object. It is expected that other calendar scales
4106 will be defined in other specifications or by future versions of this
4107 memo.
4108
4109 Format Definition: The property is defined by the following notation:
4110
4111 calscale = "CALSCALE" calparam ":" calvalue CRLF
4112
4113 calparam = *(";" xparam)
4114
4115 calvalue = "GREGORIAN" / iana-token
4116
4117 Example: The following is an example of this property:
4118
4119 CALSCALE:GREGORIAN
4120
4121 4.7.2 Method
4122
4123 Property Name: METHOD
4124
4125 Purpose: This property defines the iCalendar object method associated
4126 with the calendar object.
4127
4128 Value Type: TEXT
4129
4130 Property Parameters: Non-standard property parameters can be
4131 specified on this property.
4132
4133 Conformance: The property can be specified in an iCalendar object.
4134
4135 Description: When used in a MIME message entity, the value of this
4136 property MUST be the same as the Content-Type "method" parameter
4137 value. This property can only appear once within the iCalendar
4138 object. If either the "METHOD" property or the Content-Type "method"
4139 parameter is specified, then the other MUST also be specified.
4140
4141 No methods are defined by this specification. This is the subject of
4142 other specifications, such as the iCalendar Transport-independent
4143
4144
4145
4146 Dawson & Stenerson Standards Track [Page 74]
4147
4148 RFC 2445 iCalendar November 1998
4149
4150
4151 Interoperability Protocol (iTIP) defined by [ITIP].
4152
4153 If this property is not present in the iCalendar object, then a
4154 scheduling transaction MUST NOT be assumed. In such cases, the
4155 iCalendar object is merely being used to transport a snapshot of some
4156 calendar information; without the intention of conveying a scheduling
4157 semantic.
4158
4159 Format Definition: The property is defined by the following notation:
4160
4161 method = "METHOD" metparam ":" metvalue CRLF
4162
4163 metparam = *(";" xparam)
4164
4165 metvalue = iana-token
4166
4167 Example: The following is a hypothetical example of this property to
4168 convey that the iCalendar object is a request for a meeting:
4169
4170 METHOD:REQUEST
4171
4172 4.7.3 Product Identifier
4173
4174 Property Name: PRODID
4175
4176 Purpose: This property specifies the identifier for the product that
4177 created the iCalendar object.
4178
4179 Value Type: TEXT
4180
4181 Property Parameters: Non-standard property parameters can be
4182 specified on this property.
4183
4184 Conformance: The property MUST be specified once in an iCalendar
4185 object.
4186
4187 Description: The vendor of the implementation SHOULD assure that this
4188 is a globally unique identifier; using some technique such as an FPI
4189 value, as defined in [ISO 9070].
4190
4191 This property SHOULD not be used to alter the interpretation of an
4192 iCalendar object beyond the semantics specified in this memo. For
4193 example, it is not to be used to further the understanding of non-
4194 standard properties.
4195
4196 Format Definition: The property is defined by the following notation:
4197
4198 prodid = "PRODID" pidparam ":" pidvalue CRLF
4199
4200
4201
4202 Dawson & Stenerson Standards Track [Page 75]
4203
4204 RFC 2445 iCalendar November 1998
4205
4206
4207 pidparam = *(";" xparam)
4208
4209 pidvalue = text
4210 ;Any text that describes the product and version
4211 ;and that is generally assured of being unique.
4212
4213 Example: The following is an example of this property. It does not
4214 imply that English is the default language.
4215
4216 PRODID:-//ABC Corporation//NONSGML My Product//EN
4217
4218 4.7.4 Version
4219
4220 Property Name: VERSION
4221
4222 Purpose: This property specifies the identifier corresponding to the
4223 highest version number or the minimum and maximum range of the
4224 iCalendar specification that is required in order to interpret the
4225 iCalendar object.
4226
4227 Value Type: TEXT
4228
4229 Property Parameters: Non-standard property parameters can be
4230 specified on this property.
4231
4232 Conformance: This property MUST be specified by an iCalendar object,
4233 but MUST only be specified once.
4234
4235 Description: A value of "2.0" corresponds to this memo.
4236
4237 Format Definition: The property is defined by the following notation:
4238
4239 version = "VERSION" verparam ":" vervalue CRLF
4240
4241 verparam = *(";" xparam)
4242
4243 vervalue = "2.0" ;This memo
4244 / maxver
4245 / (minver ";" maxver)
4246
4247 minver = <A IANA registered iCalendar version identifier>
4248 ;Minimum iCalendar version needed to parse the iCalendar object
4249
4250 maxver = <A IANA registered iCalendar version identifier>
4251 ;Maximum iCalendar version needed to parse the iCalendar object
4252
4253 Example: The following is an example of this property:
4254
4255
4256
4257
4258 Dawson & Stenerson Standards Track [Page 76]
4259
4260 RFC 2445 iCalendar November 1998
4261
4262
4263 VERSION:2.0
4264
4265 4.8 Component Properties
4266
4267 The following properties can appear within calendar components, as
4268 specified by each component property definition.
4269
4270 4.8.1 Descriptive Component Properties
4271
4272 The following properties specify descriptive information about
4273 calendar components.
4274
4275 4.8.1.1 Attachment
4276
4277 Property Name: ATTACH
4278
4279 Purpose: The property provides the capability to associate a document
4280 object with a calendar component.
4281
4282 Value Type: The default value type for this property is URI. The
4283 value type can also be set to BINARY to indicate inline binary
4284 encoded content information.
4285
4286 Property Parameters: Non-standard, inline encoding, format type and
4287 value data type property parameters can be specified on this
4288 property.
4289
4290 Conformance: The property can be specified in a "VEVENT", "VTODO",
4291 "VJOURNAL" or "VALARM" calendar components.
4292
4293 Description: The property can be specified within "VEVENT", "VTODO",
4294 "VJOURNAL", or "VALARM" calendar components. This property can be
4295 specified multiple times within an iCalendar object.
4296
4297 Format Definition: The property is defined by the following notation:
4298
4299 attach = "ATTACH" attparam ":" uri CRLF
4300
4301 attach =/ "ATTACH" attparam ";" "ENCODING" "=" "BASE64"
4302 ";" "VALUE" "=" "BINARY" ":" binary
4303
4304 attparam = *(
4305
4306 ; the following is optional,
4307 ; but MUST NOT occur more than once
4308
4309 (";" fmttypeparam) /
4310
4311
4312
4313
4314 Dawson & Stenerson Standards Track [Page 77]
4315
4316 RFC 2445 iCalendar November 1998
4317
4318
4319 ; the following is optional,
4320 ; and MAY occur more than once
4321
4322 (";" xparam)
4323
4324 )
4325
4326 Example: The following are examples of this property:
4327
4328 ATTACH:CID:jsmith.part3.960817T083000.xyzMail@host1.com
4329
4330 ATTACH;FMTTYPE=application/postscript:ftp://xyzCorp.com/pub/
4331 reports/r-960812.ps
4332
4333 4.8.1.2 Categories
4334
4335 Property Name: CATEGORIES
4336
4337 Purpose: This property defines the categories for a calendar
4338 component.
4339
4340 Value Type: TEXT
4341
4342 Property Parameters: Non-standard and language property parameters
4343 can be specified on this property.
4344
4345 Conformance: The property can be specified within "VEVENT", "VTODO"
4346 or "VJOURNAL" calendar components.
4347
4348 Description: This property is used to specify categories or subtypes
4349 of the calendar component. The categories are useful in searching for
4350 a calendar component of a particular type and category. Within the
4351 "VEVENT", "VTODO" or "VJOURNAL" calendar components, more than one
4352 category can be specified as a list of categories separated by the
4353 COMMA character (US-ASCII decimal 44).
4354
4355 Format Definition: The property is defined by the following notation:
4356
4357 categories = "CATEGORIES" catparam ":" text *("," text)
4358 CRLF
4359
4360 catparam = *(
4361
4362 ; the following is optional,
4363 ; but MUST NOT occur more than once
4364
4365 (";" languageparam ) /
4366
4367
4368
4369
4370 Dawson & Stenerson Standards Track [Page 78]
4371
4372 RFC 2445 iCalendar November 1998
4373
4374
4375 ; the following is optional,
4376 ; and MAY occur more than once
4377
4378 (";" xparam)
4379
4380 )
4381
4382 Example: The following are examples of this property:
4383
4384 CATEGORIES:APPOINTMENT,EDUCATION
4385
4386 CATEGORIES:MEETING
4387
4388 4.8.1.3 Classification
4389
4390 Property Name: CLASS
4391
4392 Purpose: This property defines the access classification for a
4393 calendar component.
4394
4395 Value Type: TEXT
4396
4397 Property Parameters: Non-standard property parameters can be
4398 specified on this property.
4399
4400 Conformance: The property can be specified once in a "VEVENT",
4401 "VTODO" or "VJOURNAL" calendar components.
4402
4403 Description: An access classification is only one component of the
4404 general security system within a calendar application. It provides a
4405 method of capturing the scope of the access the calendar owner
4406 intends for information within an individual calendar entry. The
4407 access classification of an individual iCalendar component is useful
4408 when measured along with the other security components of a calendar
4409 system (e.g., calendar user authentication, authorization, access
4410 rights, access role, etc.). Hence, the semantics of the individual
4411 access classifications cannot be completely defined by this memo
4412 alone. Additionally, due to the "blind" nature of most exchange
4413 processes using this memo, these access classifications cannot serve
4414 as an enforcement statement for a system receiving an iCalendar
4415 object. Rather, they provide a method for capturing the intention of
4416 the calendar owner for the access to the calendar component.
4417
4418 Format Definition: The property is defined by the following notation:
4419
4420 class = "CLASS" classparam ":" classvalue CRLF
4421
4422 classparam = *(";" xparam)
4423
4424
4425
4426 Dawson & Stenerson Standards Track [Page 79]
4427
4428 RFC 2445 iCalendar November 1998
4429
4430
4431 classvalue = "PUBLIC" / "PRIVATE" / "CONFIDENTIAL" / iana-token
4432 / x-name
4433 ;Default is PUBLIC
4434
4435 Example: The following is an example of this property:
4436
4437 CLASS:PUBLIC
4438
4439 4.8.1.4 Comment
4440
4441 Property Name: COMMENT
4442
4443 Purpose: This property specifies non-processing information intended
4444 to provide a comment to the calendar user.
4445
4446 Value Type: TEXT
4447
4448 Property Parameters: Non-standard, alternate text representation and
4449 language property parameters can be specified on this property.
4450
4451 Conformance: This property can be specified in "VEVENT", "VTODO",
4452 "VJOURNAL", "VTIMEZONE" or "VFREEBUSY" calendar components.
4453
4454 Description: The property can be specified multiple times.
4455
4456 Format Definition: The property is defined by the following notation:
4457
4458 comment = "COMMENT" commparam ":" text CRLF
4459
4460 commparam = *(
4461
4462 ; the following are optional,
4463 ; but MUST NOT occur more than once
4464
4465 (";" altrepparam) / (";" languageparam) /
4466
4467 ; the following is optional,
4468 ; and MAY occur more than once
4469
4470 (";" xparam)
4471
4472 )
4473
4474 Example: The following is an example of this property:
4475
4476 COMMENT:The meeting really needs to include both ourselves
4477 and the customer. We can't hold this meeting without them.
4478 As a matter of fact\, the venue for the meeting ought to be at
4479
4480
4481
4482 Dawson & Stenerson Standards Track [Page 80]
4483
4484 RFC 2445 iCalendar November 1998
4485
4486
4487 their site. - - John
4488
4489 The data type for this property is TEXT.
4490
4491 4.8.1.5 Description
4492
4493 Property Name: DESCRIPTION
4494
4495 Purpose: This property provides a more complete description of the
4496 calendar component, than that provided by the "SUMMARY" property.
4497
4498 Value Type: TEXT
4499
4500 Property Parameters: Non-standard, alternate text representation and
4501 language property parameters can be specified on this property.
4502
4503 Conformance: The property can be specified in the "VEVENT", "VTODO",
4504 "VJOURNAL" or "VALARM" calendar components. The property can be
4505 specified multiple times only within a "VJOURNAL" calendar component.
4506
4507 Description: This property is used in the "VEVENT" and "VTODO" to
4508 capture lengthy textual decriptions associated with the activity.
4509
4510 This property is used in the "VJOURNAL" calendar component to capture
4511 one more textual journal entries.
4512
4513 This property is used in the "VALARM" calendar component to capture
4514 the display text for a DISPLAY category of alarm, to capture the body
4515 text for an EMAIL category of alarm and to capture the argument
4516 string for a PROCEDURE category of alarm.
4517
4518 Format Definition: The property is defined by the following notation:
4519
4520 description = "DESCRIPTION" descparam ":" text CRLF
4521
4522 descparam = *(
4523
4524 ; the following are optional,
4525 ; but MUST NOT occur more than once
4526
4527 (";" altrepparam) / (";" languageparam) /
4528
4529 ; the following is optional,
4530 ; and MAY occur more than once
4531
4532 (";" xparam)
4533
4534 )
4535
4536
4537
4538 Dawson & Stenerson Standards Track [Page 81]
4539
4540 RFC 2445 iCalendar November 1998
4541
4542
4543 Example: The following is an example of the property with formatted
4544 line breaks in the property value:
4545
4546 DESCRIPTION:Meeting to provide technical review for "Phoenix"
4547 design.\n Happy Face Conference Room. Phoenix design team
4548 MUST attend this meeting.\n RSVP to team leader.
4549
4550 The following is an example of the property with folding of long
4551 lines:
4552
4553 DESCRIPTION:Last draft of the new novel is to be completed
4554 for the editor's proof today.
4555
4556 4.8.1.6 Geographic Position
4557
4558 Property Name: GEO
4559
4560 Purpose: This property specifies information related to the global
4561 position for the activity specified by a calendar component.
4562
4563 Value Type: FLOAT. The value MUST be two SEMICOLON separated FLOAT
4564 values.
4565
4566 Property Parameters: Non-standard property parameters can be
4567 specified on this property.
4568
4569 Conformance: This property can be specified in "VEVENT" or "VTODO"
4570 calendar components.
4571
4572 Description: The property value specifies latitude and longitude, in
4573 that order (i.e., "LAT LON" ordering). The longitude represents the
4574 location east or west of the prime meridian as a positive or negative
4575 real number, respectively. The longitude and latitude values MAY be
4576 specified up to six decimal places, which will allow for accuracy to
4577 within one meter of geographical position. Receiving applications
4578 MUST accept values of this precision and MAY truncate values of
4579 greater precision.
4580
4581 Values for latitude and longitude shall be expressed as decimal
4582 fractions of degrees. Whole degrees of latitude shall be represented
4583 by a two-digit decimal number ranging from 0 through 90. Whole
4584 degrees of longitude shall be represented by a decimal number ranging
4585 from 0 through 180. When a decimal fraction of a degree is specified,
4586 it shall be separated from the whole number of degrees by a decimal
4587 point.
4588
4589
4590
4591
4592
4593
4594 Dawson & Stenerson Standards Track [Page 82]
4595
4596 RFC 2445 iCalendar November 1998
4597
4598
4599 Latitudes north of the equator shall be specified by a plus sign (+),
4600 or by the absence of a minus sign (-), preceding the digits
4601 designating degrees. Latitudes south of the Equator shall be
4602 designated by a minus sign (-) preceding the digits designating
4603 degrees. A point on the Equator shall be assigned to the Northern
4604 Hemisphere.
4605
4606 Longitudes east of the prime meridian shall be specified by a plus
4607 sign (+), or by the absence of a minus sign (-), preceding the digits
4608 designating degrees. Longitudes west of the meridian shall be
4609 designated by minus sign (-) preceding the digits designating
4610 degrees. A point on the prime meridian shall be assigned to the
4611 Eastern Hemisphere. A point on the 180th meridian shall be assigned
4612 to the Western Hemisphere. One exception to this last convention is
4613 permitted. For the special condition of describing a band of latitude
4614 around the earth, the East Bounding Coordinate data element shall be
4615 assigned the value +180 (180) degrees.
4616
4617 Any spatial address with a latitude of +90 (90) or -90 degrees will
4618 specify the position at the North or South Pole, respectively. The
4619 component for longitude may have any legal value.
4620
4621 With the exception of the special condition described above, this
4622 form is specified in Department of Commerce, 1986, Representation of
4623 geographic point locations for information interchange (Federal
4624 Information Processing Standard 70-1): Washington, Department of
4625 Commerce, National Institute of Standards and Technology.
4626
4627 The simple formula for converting degrees-minutes-seconds into
4628 decimal degrees is:
4629
4630 decimal = degrees + minutes/60 + seconds/3600.
4631
4632 Format Definition: The property is defined by the following notation:
4633
4634 geo = "GEO" geoparam ":" geovalue CRLF
4635
4636 geoparam = *(";" xparam)
4637
4638 geovalue = float ";" float
4639 ;Latitude and Longitude components
4640
4641 Example: The following is an example of this property:
4642
4643 GEO:37.386013;-122.082932
4644
4645
4646
4647
4648
4649
4650 Dawson & Stenerson Standards Track [Page 83]
4651
4652 RFC 2445 iCalendar November 1998
4653
4654
4655 4.8.1.7 Location
4656
4657 Property Name: LOCATION
4658
4659 Purpose: The property defines the intended venue for the activity
4660 defined by a calendar component.
4661
4662 Value Type: TEXT
4663
4664 Property Parameters: Non-standard, alternate text representation and
4665 language property parameters can be specified on this property.
4666
4667 Conformance: This property can be specified in "VEVENT" or "VTODO"
4668 calendar component.
4669
4670 Description: Specific venues such as conference or meeting rooms may
4671 be explicitly specified using this property. An alternate
4672 representation may be specified that is a URI that points to
4673 directory information with more structured specification of the
4674 location. For example, the alternate representation may specify
4675 either an LDAP URI pointing to an LDAP server entry or a CID URI
4676 pointing to a MIME body part containing a vCard [RFC 2426] for the
4677 location.
4678
4679 Format Definition: The property is defined by the following notation:
4680
4681 location = "LOCATION locparam ":" text CRLF
4682
4683 locparam = *(
4684
4685 ; the following are optional,
4686 ; but MUST NOT occur more than once
4687
4688 (";" altrepparam) / (";" languageparam) /
4689
4690 ; the following is optional,
4691 ; and MAY occur more than once
4692
4693 (";" xparam)
4694
4695 )
4696
4697 Example: The following are some examples of this property:
4698
4699 LOCATION:Conference Room - F123, Bldg. 002
4700
4701 LOCATION;ALTREP="http://xyzcorp.com/conf-rooms/f123.vcf":
4702 Conference Room - F123, Bldg. 002
4703
4704
4705
4706 Dawson & Stenerson Standards Track [Page 84]
4707
4708 RFC 2445 iCalendar November 1998
4709
4710
4711 4.8.1.8 Percent Complete
4712
4713 Property Name: PERCENT-COMPLETE
4714
4715 Purpose: This property is used by an assignee or delegatee of a to-do
4716 to convey the percent completion of a to-do to the Organizer.
4717
4718 Value Type: INTEGER
4719
4720 Property Parameters: Non-standard property parameters can be
4721 specified on this property.
4722
4723 Conformance: This property can be specified in a "VTODO" calendar
4724 component.
4725
4726 Description: The property value is a positive integer between zero
4727 and one hundred. A value of "0" indicates the to-do has not yet been
4728 started. A value of "100" indicates that the to-do has been
4729 completed. Integer values in between indicate the percent partially
4730 complete.
4731
4732 When a to-do is assigned to multiple individuals, the property value
4733 indicates the percent complete for that portion of the to-do assigned
4734 to the assignee or delegatee. For example, if a to-do is assigned to
4735 both individuals "A" and "B". A reply from "A" with a percent
4736 complete of "70" indicates that "A" has completed 70% of the to-do
4737 assigned to them. A reply from "B" with a percent complete of "50"
4738 indicates "B" has completed 50% of the to-do assigned to them.
4739
4740 Format Definition: The property is defined by the following notation:
4741
4742 percent = "PERCENT-COMPLETE" pctparam ":" integer CRLF
4743
4744 pctparam = *(";" xparam)
4745
4746 Example: The following is an example of this property to show 39%
4747 completion:
4748
4749 PERCENT-COMPLETE:39
4750
4751 4.8.1.9 Priority
4752
4753 Property Name: PRIORITY
4754
4755 Purpose: The property defines the relative priority for a calendar
4756 component.
4757
4758 Value Type: INTEGER
4759
4760
4761
4762 Dawson & Stenerson Standards Track [Page 85]
4763
4764 RFC 2445 iCalendar November 1998
4765
4766
4767 Property Parameters: Non-standard property parameters can be
4768 specified on this property.
4769
4770 Conformance: The property can be specified in a "VEVENT" or "VTODO"
4771 calendar component.
4772
4773 Description: The priority is specified as an integer in the range
4774 zero to nine. A value of zero (US-ASCII decimal 48) specifies an
4775 undefined priority. A value of one (US-ASCII decimal 49) is the
4776 highest priority. A value of two (US-ASCII decimal 50) is the second
4777 highest priority. Subsequent numbers specify a decreasing ordinal
4778 priority. A value of nine (US-ASCII decimal 58) is the lowest
4779 priority.
4780
4781 A CUA with a three-level priority scheme of "HIGH", "MEDIUM" and
4782 "LOW" is mapped into this property such that a property value in the
4783 range of one (US-ASCII decimal 49) to four (US-ASCII decimal 52)
4784 specifies "HIGH" priority. A value of five (US-ASCII decimal 53) is
4785 the normal or "MEDIUM" priority. A value in the range of six (US-
4786 ASCII decimal 54) to nine (US-ASCII decimal 58) is "LOW" priority.
4787
4788 A CUA with a priority schema of "A1", "A2", "A3", "B1", "B2", ...,
4789 "C3" is mapped into this property such that a property value of one
4790 (US-ASCII decimal 49) specifies "A1", a property value of two (US-
4791 ASCII decimal 50) specifies "A2", a property value of three (US-ASCII
4792 decimal 51) specifies "A3", and so forth up to a property value of 9
4793 (US-ASCII decimal 58) specifies "C3".
4794
4795 Other integer values are reserved for future use.
4796
4797 Within a "VEVENT" calendar component, this property specifies a
4798 priority for the event. This property may be useful when more than
4799 one event is scheduled for a given time period.
4800
4801 Within a "VTODO" calendar component, this property specified a
4802 priority for the to-do. This property is useful in prioritizing
4803 multiple action items for a given time period.
4804
4805 Format Definition: The property is specified by the following
4806 notation:
4807
4808 priority = "PRIORITY" prioparam ":" privalue CRLF
4809 ;Default is zero
4810
4811 prioparam = *(";" xparam)
4812
4813 privalue = integer ;Must be in the range [0..9]
4814 ; All other values are reserved for future use
4815
4816
4817
4818 Dawson & Stenerson Standards Track [Page 86]
4819
4820 RFC 2445 iCalendar November 1998
4821
4822
4823 The following is an example of a property with the highest priority:
4824
4825 PRIORITY:1
4826
4827 The following is an example of a property with a next highest
4828 priority:
4829
4830 PRIORITY:2
4831
4832 Example: The following is an example of a property with no priority.
4833 This is equivalent to not specifying the "PRIORITY" property:
4834
4835 PRIORITY:0
4836
4837 4.8.1.10 Resources
4838
4839 Property Name: RESOURCES
4840
4841 Purpose: This property defines the equipment or resources anticipated
4842 for an activity specified by a calendar entity..
4843
4844 Value Type: TEXT
4845
4846 Property Parameters: Non-standard, alternate text representation and
4847 language property parameters can be specified on this property.
4848
4849 Conformance: This property can be specified in "VEVENT" or "VTODO"
4850 calendar component.
4851
4852 Description: The property value is an arbitrary text. More than one
4853 resource can be specified as a list of resources separated by the
4854 COMMA character (US-ASCII decimal 44).
4855
4856 Format Definition: The property is defined by the following notation:
4857
4858 resources = "RESOURCES" resrcparam ":" text *("," text) CRLF
4859
4860 resrcparam = *(
4861
4862 ; the following are optional,
4863 ; but MUST NOT occur more than once
4864
4865 (";" altrepparam) / (";" languageparam) /
4866
4867 ; the following is optional,
4868 ; and MAY occur more than once
4869
4870
4871
4872
4873
4874 Dawson & Stenerson Standards Track [Page 87]
4875
4876 RFC 2445 iCalendar November 1998
4877
4878
4879 (";" xparam)
4880
4881 )
4882
4883 Example: The following is an example of this property:
4884
4885 RESOURCES:EASEL,PROJECTOR,VCR
4886
4887 RESOURCES;LANGUAGE=fr:1 raton-laveur
4888
4889 4.8.1.11 Status
4890
4891 Property Name: STATUS
4892
4893 Purpose: This property defines the overall status or confirmation for
4894 the calendar component.
4895
4896 Value Type: TEXT
4897
4898 Property Parameters: Non-standard property parameters can be
4899 specified on this property.
4900
4901 Conformance: This property can be specified in "VEVENT", "VTODO" or
4902 "VJOURNAL" calendar components.
4903
4904 Description: In a group scheduled calendar component, the property is
4905 used by the "Organizer" to provide a confirmation of the event to the
4906 "Attendees". For example in a "VEVENT" calendar component, the
4907 "Organizer" can indicate that a meeting is tentative, confirmed or
4908 cancelled. In a "VTODO" calendar component, the "Organizer" can
4909 indicate that an action item needs action, is completed, is in
4910 process or being worked on, or has been cancelled. In a "VJOURNAL"
4911 calendar component, the "Organizer" can indicate that a journal entry
4912 is draft, final or has been cancelled or removed.
4913
4914 Format Definition: The property is defined by the following notation:
4915
4916 status = "STATUS" statparam] ":" statvalue CRLF
4917
4918 statparam = *(";" xparam)
4919
4920 statvalue = "TENTATIVE" ;Indicates event is
4921 ;tentative.
4922 / "CONFIRMED" ;Indicates event is
4923 ;definite.
4924 / "CANCELLED" ;Indicates event was
4925 ;cancelled.
4926 ;Status values for a "VEVENT"
4927
4928
4929
4930 Dawson & Stenerson Standards Track [Page 88]
4931
4932 RFC 2445 iCalendar November 1998
4933
4934
4935 statvalue =/ "NEEDS-ACTION" ;Indicates to-do needs action.
4936 / "COMPLETED" ;Indicates to-do completed.
4937 / "IN-PROCESS" ;Indicates to-do in process of
4938 / "CANCELLED" ;Indicates to-do was cancelled.
4939 ;Status values for "VTODO".
4940
4941 statvalue =/ "DRAFT" ;Indicates journal is draft.
4942 / "FINAL" ;Indicates journal is final.
4943 / "CANCELLED" ;Indicates journal is removed.
4944 ;Status values for "VJOURNAL".
4945
4946 Example: The following is an example of this property for a "VEVENT"
4947 calendar component:
4948
4949 STATUS:TENTATIVE
4950
4951 The following is an example of this property for a "VTODO" calendar
4952 component:
4953
4954 STATUS:NEEDS-ACTION
4955
4956 The following is an example of this property for a "VJOURNAL"
4957 calendar component:
4958
4959 STATUS:DRAFT
4960
4961 4.8.1.12 Summary
4962
4963 Property Name: SUMMARY
4964
4965 Purpose: This property defines a short summary or subject for the
4966 calendar component.
4967
4968 Value Type: TEXT
4969
4970 Property Parameters: Non-standard, alternate text representation and
4971 language property parameters can be specified on this property.
4972
4973 Conformance: The property can be specified in "VEVENT", "VTODO",
4974 "VJOURNAL" or "VALARM" calendar components.
4975
4976 Description: This property is used in the "VEVENT", "VTODO" and
4977 "VJOURNAL" calendar components to capture a short, one line summary
4978 about the activity or journal entry.
4979
4980 This property is used in the "VALARM" calendar component to capture
4981 the subject of an EMAIL category of alarm.
4982
4983
4984
4985
4986 Dawson & Stenerson Standards Track [Page 89]
4987
4988 RFC 2445 iCalendar November 1998
4989
4990
4991 Format Definition: The property is defined by the following notation:
4992
4993 summary = "SUMMARY" summparam ":" text CRLF
4994
4995 summparam = *(
4996
4997 ; the following are optional,
4998 ; but MUST NOT occur more than once
4999
5000 (";" altrepparam) / (";" languageparam) /
5001
5002 ; the following is optional,
5003 ; and MAY occur more than once
5004
5005 (";" xparam)
5006
5007 )
5008
5009 Example: The following is an example of this property:
5010
5011 SUMMARY:Department Party
5012
5013 4.8.2 Date and Time Component Properties
5014
5015 The following properties specify date and time related information in
5016 calendar components.
5017
5018 4.8.2.1 Date/Time Completed
5019
5020 Property Name: COMPLETED
5021
5022 Purpose: This property defines the date and time that a to-do was
5023 actually completed.
5024
5025 Value Type: DATE-TIME
5026
5027 Property Parameters: Non-standard property parameters can be
5028 specified on this property.
5029
5030 Conformance: The property can be specified in a "VTODO" calendar
5031 component.
5032
5033 Description: The date and time MUST be in a UTC format.
5034
5035 Format Definition: The property is defined by the following notation:
5036
5037 completed = "COMPLETED" compparam ":" date-time CRLF
5038
5039
5040
5041
5042 Dawson & Stenerson Standards Track [Page 90]
5043
5044 RFC 2445 iCalendar November 1998
5045
5046
5047 compparam = *(";" xparam)
5048
5049 Example: The following is an example of this property:
5050
5051 COMPLETED:19960401T235959Z
5052
5053 4.8.2.2 Date/Time End
5054
5055 Property Name: DTEND
5056
5057 Purpose: This property specifies the date and time that a calendar
5058 component ends.
5059
5060 Value Type: The default value type is DATE-TIME. The value type can
5061 be set to a DATE value type.
5062
5063 Property Parameters: Non-standard, value data type, time zone
5064 identifier property parameters can be specified on this property.
5065
5066 Conformance: This property can be specified in "VEVENT" or
5067 "VFREEBUSY" calendar components.
5068
5069 Description: Within the "VEVENT" calendar component, this property
5070 defines the date and time by which the event ends. The value MUST be
5071 later in time than the value of the "DTSTART" property.
5072
5073 Within the "VFREEBUSY" calendar component, this property defines the
5074 end date and time for the free or busy time information. The time
5075 MUST be specified in the UTC time format. The value MUST be later in
5076 time than the value of the "DTSTART" property.
5077
5078 Format Definition: The property is defined by the following notation:
5079
5080 dtend = "DTEND" dtendparam":" dtendval CRLF
5081
5082 dtendparam = *(
5083
5084 ; the following are optional,
5085 ; but MUST NOT occur more than once
5086
5087 (";" "VALUE" "=" ("DATE-TIME" / "DATE")) /
5088 (";" tzidparam) /
5089
5090 ; the following is optional,
5091 ; and MAY occur more than once
5092
5093
5094
5095
5096
5097
5098 Dawson & Stenerson Standards Track [Page 91]
5099
5100 RFC 2445 iCalendar November 1998
5101
5102
5103 (";" xparam)
5104
5105 )
5106
5107
5108
5109 dtendval = date-time / date
5110 ;Value MUST match value type
5111
5112 Example: The following is an example of this property:
5113
5114 DTEND:19960401T235959Z
5115
5116 DTEND;VALUE=DATE:19980704
5117
5118 4.8.2.3 Date/Time Due
5119
5120 Property Name: DUE
5121
5122 Purpose: This property defines the date and time that a to-do is
5123 expected to be completed.
5124
5125 Value Type: The default value type is DATE-TIME. The value type can
5126 be set to a DATE value type.
5127
5128 Property Parameters: Non-standard, value data type, time zone
5129 identifier property parameters can be specified on this property.
5130
5131 Conformance: The property can be specified once in a "VTODO" calendar
5132 component.
5133
5134 Description: The value MUST be a date/time equal to or after the
5135 DTSTART value, if specified.
5136
5137 Format Definition: The property is defined by the following notation:
5138
5139 due = "DUE" dueparam":" dueval CRLF
5140
5141 dueparam = *(
5142 ; the following are optional,
5143 ; but MUST NOT occur more than once
5144
5145 (";" "VALUE" "=" ("DATE-TIME" / "DATE")) /
5146 (";" tzidparam) /
5147
5148 ; the following is optional,
5149 ; and MAY occur more than once
5150
5151
5152
5153
5154 Dawson & Stenerson Standards Track [Page 92]
5155
5156 RFC 2445 iCalendar November 1998
5157
5158
5159 *(";" xparam)
5160
5161 )
5162
5163
5164
5165 dueval = date-time / date
5166 ;Value MUST match value type
5167
5168 Example: The following is an example of this property:
5169
5170 DUE:19980430T235959Z
5171
5172 4.8.2.4 Date/Time Start
5173
5174 Property Name: DTSTART
5175
5176 Purpose: This property specifies when the calendar component begins.
5177
5178 Value Type: The default value type is DATE-TIME. The time value MUST
5179 be one of the forms defined for the DATE-TIME value type. The value
5180 type can be set to a DATE value type.
5181
5182 Property Parameters: Non-standard, value data type, time zone
5183 identifier property parameters can be specified on this property.
5184
5185 Conformance: This property can be specified in the "VEVENT", "VTODO",
5186 "VFREEBUSY", or "VTIMEZONE" calendar components.
5187
5188 Description: Within the "VEVENT" calendar component, this property
5189 defines the start date and time for the event. The property is
5190 REQUIRED in "VEVENT" calendar components. Events can have a start
5191 date/time but no end date/time. In that case, the event does not take
5192 up any time.
5193
5194 Within the "VFREEBUSY" calendar component, this property defines the
5195 start date and time for the free or busy time information. The time
5196 MUST be specified in UTC time.
5197
5198 Within the "VTIMEZONE" calendar component, this property defines the
5199 effective start date and time for a time zone specification. This
5200 property is REQUIRED within each STANDARD and DAYLIGHT part included
5201 in "VTIMEZONE" calendar components and MUST be specified as a local
5202 DATE-TIME without the "TZID" property parameter.
5203
5204 Format Definition: The property is defined by the following notation:
5205
5206 dtstart = "DTSTART" dtstparam ":" dtstval CRLF
5207
5208
5209
5210 Dawson & Stenerson Standards Track [Page 93]
5211
5212 RFC 2445 iCalendar November 1998
5213
5214
5215 dtstparam = *(
5216
5217 ; the following are optional,
5218 ; but MUST NOT occur more than once
5219
5220 (";" "VALUE" "=" ("DATE-TIME" / "DATE")) /
5221 (";" tzidparam) /
5222
5223 ; the following is optional,
5224 ; and MAY occur more than once
5225
5226 *(";" xparam)
5227
5228 )
5229
5230
5231
5232 dtstval = date-time / date
5233 ;Value MUST match value type
5234
5235 Example: The following is an example of this property:
5236
5237 DTSTART:19980118T073000Z
5238
5239 4.8.2.5 Duration
5240
5241 Property Name: DURATION
5242
5243 Purpose: The property specifies a positive duration of time.
5244
5245 Value Type: DURATION
5246
5247 Property Parameters: Non-standard property parameters can be
5248 specified on this property.
5249
5250 Conformance: The property can be specified in "VEVENT", "VTODO",
5251 "VFREEBUSY" or "VALARM" calendar components.
5252
5253 Description: In a "VEVENT" calendar component the property may be
5254 used to specify a duration of the event, instead of an explicit end
5255 date/time. In a "VTODO" calendar component the property may be used
5256 to specify a duration for the to-do, instead of an explicit due
5257 date/time. In a "VFREEBUSY" calendar component the property may be
5258 used to specify the interval of free time being requested. In a
5259 "VALARM" calendar component the property may be used to specify the
5260 delay period prior to repeating an alarm.
5261
5262 Format Definition: The property is defined by the following notation:
5263
5264
5265
5266 Dawson & Stenerson Standards Track [Page 94]
5267
5268 RFC 2445 iCalendar November 1998
5269
5270
5271 duration = "DURATION" durparam ":" dur-value CRLF
5272 ;consisting of a positive duration of time.
5273
5274 durparam = *(";" xparam)
5275
5276 Example: The following is an example of this property that specifies
5277 an interval of time of 1 hour and zero minutes and zero seconds:
5278
5279 DURATION:PT1H0M0S
5280
5281 The following is an example of this property that specifies an
5282 interval of time of 15 minutes.
5283
5284 DURATION:PT15M
5285
5286 4.8.2.6 Free/Busy Time
5287
5288 Property Name: FREEBUSY
5289
5290 Purpose: The property defines one or more free or busy time
5291 intervals.
5292
5293 Value Type: PERIOD. The date and time values MUST be in an UTC time
5294 format.
5295
5296 Property Parameters: Non-standard or free/busy time type property
5297 parameters can be specified on this property.
5298
5299 Conformance: The property can be specified in a "VFREEBUSY" calendar
5300 component.
5301
5302 Property Parameter: "FBTYPE" and non-standard parameters can be
5303 specified on this property.
5304
5305 Description: These time periods can be specified as either a start
5306 and end date-time or a start date-time and duration. The date and
5307 time MUST be a UTC time format.
5308
5309 "FREEBUSY" properties within the "VFREEBUSY" calendar component
5310 SHOULD be sorted in ascending order, based on start time and then end
5311 time, with the earliest periods first.
5312
5313 The "FREEBUSY" property can specify more than one value, separated by
5314 the COMMA character (US-ASCII decimal 44). In such cases, the
5315 "FREEBUSY" property values SHOULD all be of the same "FBTYPE"
5316 property parameter type (e.g., all values of a particular "FBTYPE"
5317 listed together in a single property).
5318
5319
5320
5321
5322 Dawson & Stenerson Standards Track [Page 95]
5323
5324 RFC 2445 iCalendar November 1998
5325
5326
5327 Format Definition: The property is defined by the following notation:
5328
5329 freebusy = "FREEBUSY" fbparam ":" fbvalue
5330 CRLF
5331
5332 fbparam = *(
5333 ; the following is optional,
5334 ; but MUST NOT occur more than once
5335
5336 (";" fbtypeparam) /
5337
5338 ; the following is optional,
5339 ; and MAY occur more than once
5340
5341 (";" xparam)
5342
5343 )
5344
5345 fbvalue = period *["," period]
5346 ;Time value MUST be in the UTC time format.
5347
5348 Example: The following are some examples of this property:
5349
5350 FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:19970308T160000Z/PT8H30M
5351
5352 FREEBUSY;FBTYPE=FREE:19970308T160000Z/PT3H,19970308T200000Z/PT1H
5353
5354 FREEBUSY;FBTYPE=FREE:19970308T160000Z/PT3H,19970308T200000Z/PT1H,
5355 19970308T230000Z/19970309T000000Z
5356
5357 4.8.2.7 Time Transparency
5358
5359 Property Name: TRANSP
5360
5361 Purpose: This property defines whether an event is transparent or not
5362 to busy time searches.
5363
5364 Value Type: TEXT
5365
5366 Property Parameters: Non-standard property parameters can be
5367 specified on this property.
5368
5369 Conformance: This property can be specified once in a "VEVENT"
5370 calendar component.
5371
5372 Description: Time Transparency is the characteristic of an event that
5373 determines whether it appears to consume time on a calendar. Events
5374 that consume actual time for the individual or resource associated
5375
5376
5377
5378 Dawson & Stenerson Standards Track [Page 96]
5379
5380 RFC 2445 iCalendar November 1998
5381
5382
5383 with the calendar SHOULD be recorded as OPAQUE, allowing them to be
5384 detected by free-busy time searches. Other events, which do not take
5385 up the individual's (or resource's) time SHOULD be recorded as
5386 TRANSPARENT, making them invisible to free-busy time searches.
5387
5388 Format Definition: The property is specified by the following
5389 notation:
5390
5391 transp = "TRANSP" tranparam ":" transvalue CRLF
5392
5393 tranparam = *(";" xparam)
5394
5395 transvalue = "OPAQUE" ;Blocks or opaque on busy time searches.
5396 / "TRANSPARENT" ;Transparent on busy time searches.
5397 ;Default value is OPAQUE
5398
5399 Example: The following is an example of this property for an event
5400 that is transparent or does not block on free/busy time searches:
5401
5402 TRANSP:TRANSPARENT
5403
5404 The following is an example of this property for an event that is
5405 opaque or blocks on free/busy time searches:
5406
5407 TRANSP:OPAQUE
5408
5409 4.8.3 Time Zone Component Properties
5410
5411 The following properties specify time zone information in calendar
5412 components.
5413
5414 4.8.3.1 Time Zone Identifier
5415
5416 Property Name: TZID
5417
5418 Purpose: This property specifies the text value that uniquely
5419 identifies the "VTIMEZONE" calendar component.
5420
5421 Value Type: TEXT
5422
5423 Property Parameters: Non-standard property parameters can be
5424 specified on this property.
5425
5426 Conformance: This property MUST be specified in a "VTIMEZONE"
5427 calendar component.
5428
5429
5430
5431
5432
5433
5434 Dawson & Stenerson Standards Track [Page 97]
5435
5436 RFC 2445 iCalendar November 1998
5437
5438
5439 Description: This is the label by which a time zone calendar
5440 component is referenced by any iCalendar properties whose data type
5441 is either DATE-TIME or TIME and not intended to specify a UTC or a
5442 "floating" time. The presence of the SOLIDUS character (US-ASCII
5443 decimal 47) as a prefix, indicates that this TZID represents an
5444 unique ID in a globally defined time zone registry (when such
5445 registry is defined).
5446
5447 Note: This document does not define a naming convention for time
5448 zone identifiers. Implementers may want to use the naming
5449 conventions defined in existing time zone specifications such as
5450 the public-domain Olson database [TZ]. The specification of
5451 globally unique time zone identifiers is not addressed by this
5452 document and is left for future study.
5453
5454 Format Definition: This property is defined by the following
5455 notation:
5456
5457 tzid = "TZID" tzidpropparam ":" [tzidprefix] text CRLF
5458
5459 tzidpropparam = *(";" xparam)
5460
5461 ;tzidprefix = "/"
5462 ; Defined previously. Just listed here for reader convenience.
5463
5464 Example: The following are examples of non-globally unique time zone
5465 identifiers:
5466
5467 TZID:US-Eastern
5468
5469 TZID:California-Los_Angeles
5470
5471 The following is an example of a fictitious globally unique time zone
5472 identifier:
5473
5474 TZID:/US-New_York-New_York
5475
5476 4.8.3.2 Time Zone Name
5477
5478 Property Name: TZNAME
5479
5480 Purpose: This property specifies the customary designation for a time
5481 zone description.
5482
5483 Value Type: TEXT
5484
5485 Property Parameters: Non-standard and language property parameters
5486 can be specified on this property.
5487
5488
5489
5490 Dawson & Stenerson Standards Track [Page 98]
5491
5492 RFC 2445 iCalendar November 1998
5493
5494
5495 Conformance: This property can be specified in a "VTIMEZONE" calendar
5496 component.
5497
5498 Description: This property may be specified in multiple languages; in
5499 order to provide for different language requirements.
5500
5501 Format Definition: This property is defined by the following
5502 notation:
5503
5504 tzname = "TZNAME" tznparam ":" text CRLF
5505
5506 tznparam = *(
5507
5508 ; the following is optional,
5509 ; but MUST NOT occur more than once
5510
5511 (";" languageparam) /
5512
5513 ; the following is optional,
5514 ; and MAY occur more than once
5515
5516 (";" xparam)
5517
5518 )
5519
5520 Example: The following are example of this property:
5521
5522 TZNAME:EST
5523
5524 The following is an example of this property when two different
5525 languages for the time zone name are specified:
5526
5527 TZNAME;LANGUAGE=en:EST
5528 TZNAME;LANGUAGE=fr-CA:HNE
5529
5530 4.8.3.3 Time Zone Offset From
5531
5532 Property Name: TZOFFSETFROM
5533
5534 Purpose: This property specifies the offset which is in use prior to
5535 this time zone observance.
5536
5537 Value Type: UTC-OFFSET
5538
5539 Property Parameters: Non-standard property parameters can be
5540 specified on this property.
5541
5542
5543
5544
5545
5546 Dawson & Stenerson Standards Track [Page 99]
5547
5548 RFC 2445 iCalendar November 1998
5549
5550
5551 Conformance: This property MUST be specified in a "VTIMEZONE"
5552 calendar component.
5553
5554 Description: This property specifies the offset which is in use prior
5555 to this time observance. It is used to calculate the absolute time at
5556 which the transition to a given observance takes place. This property
5557 MUST only be specified in a "VTIMEZONE" calendar component. A
5558 "VTIMEZONE" calendar component MUST include this property. The
5559 property value is a signed numeric indicating the number of hours and
5560 possibly minutes from UTC. Positive numbers represent time zones east
5561 of the prime meridian, or ahead of UTC. Negative numbers represent
5562 time zones west of the prime meridian, or behind UTC.
5563
5564 Format Definition: The property is defined by the following notation:
5565
5566 tzoffsetfrom = "TZOFFSETFROM" frmparam ":" utc-offset
5567 CRLF
5568
5569 frmparam = *(";" xparam)
5570
5571 Example: The following are examples of this property:
5572
5573 TZOFFSETFROM:-0500
5574
5575 TZOFFSETFROM:+1345
5576
5577 4.8.3.4 Time Zone Offset To
5578
5579 Property Name: TZOFFSETTO
5580
5581 Purpose: This property specifies the offset which is in use in this
5582 time zone observance.
5583
5584 Value Type: UTC-OFFSET
5585
5586 Property Parameters: Non-standard property parameters can be
5587 specified on this property.
5588
5589 Conformance: This property MUST be specified in a "VTIMEZONE"
5590 calendar component.
5591
5592 Description: This property specifies the offset which is in use in
5593 this time zone observance. It is used to calculate the absolute time
5594 for the new observance. The property value is a signed numeric
5595 indicating the number of hours and possibly minutes from UTC.
5596 Positive numbers represent time zones east of the prime meridian, or
5597 ahead of UTC. Negative numbers represent time zones west of the prime
5598 meridian, or behind UTC.
5599
5600
5601
5602 Dawson & Stenerson Standards Track [Page 100]
5603
5604 RFC 2445 iCalendar November 1998
5605
5606
5607 Format Definition: The property is defined by the following notation:
5608
5609 tzoffsetto = "TZOFFSETTO" toparam ":" utc-offset CRLF
5610
5611 toparam = *(";" xparam)
5612
5613 Example: The following are examples of this property:
5614
5615 TZOFFSETTO:-0400
5616
5617 TZOFFSETTO:+1245
5618
5619 4.8.3.5 Time Zone URL
5620
5621 Property Name: TZURL
5622
5623 Purpose: The TZURL provides a means for a VTIMEZONE component to
5624 point to a network location that can be used to retrieve an up-to-
5625 date version of itself.
5626
5627 Value Type: URI
5628
5629 Property Parameters: Non-standard property parameters can be
5630 specified on this property.
5631
5632 Conformance: This property can be specified in a "VTIMEZONE" calendar
5633 component.
5634
5635 Description: The TZURL provides a means for a VTIMEZONE component to
5636 point to a network location that can be used to retrieve an up-to-
5637 date version of itself. This provides a hook to handle changes
5638 government bodies impose upon time zone definitions. Retrieval of
5639 this resource results in an iCalendar object containing a single
5640 VTIMEZONE component and a METHOD property set to PUBLISH.
5641
5642 Format Definition: The property is defined by the following notation:
5643
5644 tzurl = "TZURL" tzurlparam ":" uri CRLF
5645
5646 tzurlparam = *(";" xparam)
5647
5648 Example: The following is an example of this property:
5649
5650 TZURL:http://timezones.r.us.net/tz/US-California-Los_Angeles
5651
5652
5653
5654
5655
5656
5657
5658 Dawson & Stenerson Standards Track [Page 101]
5659
5660 RFC 2445 iCalendar November 1998
5661
5662
5663 4.8.4 Relationship Component Properties
5664
5665 The following properties specify relationship information in calendar
5666 components.
5667
5668 4.8.4.1 Attendee
5669
5670 Property Name: ATTENDEE
5671
5672 Purpose: The property defines an "Attendee" within a calendar
5673 component.
5674
5675 Value Type: CAL-ADDRESS
5676
5677 Property Parameters: Non-standard, language, calendar user type,
5678 group or list membership, participation role, participation status,
5679 RSVP expectation, delegatee, delegator, sent by, common name or
5680 directory entry reference property parameters can be specified on
5681 this property.
5682
5683 Conformance: This property MUST be specified in an iCalendar object
5684 that specifies a group scheduled calendar entity. This property MUST
5685 NOT be specified in an iCalendar object when publishing the calendar
5686 information (e.g., NOT in an iCalendar object that specifies the
5687 publication of a calendar user's busy time, event, to-do or journal).
5688 This property is not specified in an iCalendar object that specifies
5689 only a time zone definition or that defines calendar entities that
5690 are not group scheduled entities, but are entities only on a single
5691 user's calendar.
5692
5693 Description: The property MUST only be specified within calendar
5694 components to specify participants, non-participants and the chair of
5695 a group scheduled calendar entity. The property is specified within
5696 an "EMAIL" category of the "VALARM" calendar component to specify an
5697 email address that is to receive the email type of iCalendar alarm.
5698
5699 The property parameter CN is for the common or displayable name
5700 associated with the calendar address; ROLE, for the intended role
5701 that the attendee will have in the calendar component; PARTSTAT, for
5702 the status of the attendee's participation; RSVP, for indicating
5703 whether the favor of a reply is requested; CUTYPE, to indicate the
5704 type of calendar user; MEMBER, to indicate the groups that the
5705 attendee belongs to; DELEGATED-TO, to indicate the calendar users
5706 that the original request was delegated to; and DELEGATED-FROM, to
5707 indicate whom the request was delegated from; SENT-BY, to indicate
5708 whom is acting on behalf of the ATTENDEE; and DIR, to indicate the
5709 URI that points to the directory information corresponding to the
5710 attendee. These property parameters can be specified on an "ATTENDEE"
5711
5712
5713
5714 Dawson & Stenerson Standards Track [Page 102]
5715
5716 RFC 2445 iCalendar November 1998
5717
5718
5719 property in either a "VEVENT", "VTODO" or "VJOURNAL" calendar
5720 component. They MUST not be specified in an "ATTENDEE" property in a
5721 "VFREEBUSY" or "VALARM" calendar component. If the LANGUAGE property
5722 parameter is specified, the identified language applies to the CN
5723 parameter.
5724
5725 A recipient delegated a request MUST inherit the RSVP and ROLE values
5726 from the attendee that delegated the request to them.
5727
5728 Multiple attendees can be specified by including multiple "ATTENDEE"
5729 properties within the calendar component.
5730
5731 Format Definition: The property is defined by the following notation:
5732
5733 attendee = "ATTENDEE" attparam ":" cal-address CRLF
5734
5735 attparam = *(
5736
5737 ; the following are optional,
5738 ; but MUST NOT occur more than once
5739
5740 (";" cutypeparam) / (";"memberparam) /
5741 (";" roleparam) / (";" partstatparam) /
5742 (";" rsvpparam) / (";" deltoparam) /
5743 (";" delfromparam) / (";" sentbyparam) /
5744 (";"cnparam) / (";" dirparam) /
5745 (";" languageparam) /
5746
5747 ; the following is optional,
5748 ; and MAY occur more than once
5749
5750 (";" xparam)
5751
5752 )
5753
5754 Example: The following are examples of this property's use for a to-
5755 do:
5756
5757 ORGANIZER:MAILTO:jsmith@host1.com
5758 ATTENDEE;MEMBER="MAILTO:DEV-GROUP@host2.com":
5759 MAILTO:joecool@host2.com
5760 ATTENDEE;DELEGATED-FROM="MAILTO:immud@host3.com":
5761 MAILTO:ildoit@host1.com
5762
5763 The following is an example of this property used for specifying
5764 multiple attendees to an event:
5765
5766
5767
5768
5769
5770 Dawson & Stenerson Standards Track [Page 103]
5771
5772 RFC 2445 iCalendar November 1998
5773
5774
5775 ORGANIZER:MAILTO:jsmith@host1.com
5776 ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;CN=Henry Cabot
5777 :MAILTO:hcabot@host2.com
5778 ATTENDEE;ROLE=REQ-PARTICIPANT;DELEGATED-FROM="MAILTO:bob@host.com"
5779 ;PARTSTAT=ACCEPTED;CN=Jane Doe:MAILTO:jdoe@host1.com
5780
5781 The following is an example of this property with a URI to the
5782 directory information associated with the attendee:
5783
5784 ATTENDEE;CN=John Smith;DIR="ldap://host.com:6666/o=eDABC%
5785 20Industries,c=3DUS??(cn=3DBJim%20Dolittle)":MAILTO:jimdo@
5786 host1.com
5787
5788 The following is an example of this property with "delegatee" and
5789 "delegator" information for an event:
5790
5791 ORGANIZER;CN=John Smith:MAILTO:jsmith@host.com
5792 ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;DELEGATED-FROM=
5793 "MAILTO:iamboss@host2.com";CN=Henry Cabot:MAILTO:hcabot@
5794 host2.com
5795 ATTENDEE;ROLE=NON-PARTICIPANT;PARTSTAT=DELEGATED;DELEGATED-TO=
5796 "MAILTO:hcabot@host2.com";CN=The Big Cheese:MAILTO:iamboss
5797 @host2.com
5798 ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;CN=Jane Doe
5799 :MAILTO:jdoe@host1.com
5800
5801 Example: The following is an example of this property's use when
5802 another calendar user is acting on behalf of the "Attendee":
5803
5804 ATTENDEE;SENT-BY=MAILTO:jan_doe@host1.com;CN=John Smith:MAILTO:
5805 jsmith@host1.com
5806
5807 4.8.4.2 Contact
5808
5809 Property Name: CONTACT
5810
5811 Purpose: The property is used to represent contact information or
5812 alternately a reference to contact information associated with the
5813 calendar component.
5814
5815 Value Type: TEXT
5816
5817 Property Parameters: Non-standard, alternate text representation and
5818 language property parameters can be specified on this property.
5819
5820 Conformance: The property can be specified in a "VEVENT", "VTODO",
5821 "VJOURNAL" or "VFREEBUSY" calendar component.
5822
5823
5824
5825
5826 Dawson & Stenerson Standards Track [Page 104]
5827
5828 RFC 2445 iCalendar November 1998
5829
5830
5831 Description: The property value consists of textual contact
5832 information. An alternative representation for the property value can
5833 also be specified that refers to a URI pointing to an alternate form,
5834 such as a vCard [RFC 2426], for the contact information.
5835
5836 Format Definition: The property is defined by the following notation:
5837
5838 contact = "CONTACT" contparam ":" text CRLF
5839
5840 contparam = *(
5841 ; the following are optional,
5842 ; but MUST NOT occur more than once
5843
5844 (";" altrepparam) / (";" languageparam) /
5845
5846 ; the following is optional,
5847 ; and MAY occur more than once
5848
5849 (";" xparam)
5850
5851 )
5852
5853 Example: The following is an example of this property referencing
5854 textual contact information:
5855
5856 CONTACT:Jim Dolittle\, ABC Industries\, +1-919-555-1234
5857
5858 The following is an example of this property with an alternate
5859 representation of a LDAP URI to a directory entry containing the
5860 contact information:
5861
5862 CONTACT;ALTREP="ldap://host.com:6666/o=3DABC%20Industries\,
5863 c=3DUS??(cn=3DBJim%20Dolittle)":Jim Dolittle\, ABC Industries\,
5864 +1-919-555-1234
5865
5866 The following is an example of this property with an alternate
5867 representation of a MIME body part containing the contact
5868 information, such as a vCard [RFC 2426] embedded in a [MIME-DIR]
5869 content-type:
5870
5871 CONTACT;ALTREP="CID=<part3.msg970930T083000SILVER@host.com>":Jim
5872 Dolittle\, ABC Industries\, +1-919-555-1234
5873
5874 The following is an example of this property referencing a network
5875 resource, such as a vCard [RFC 2426] object containing the contact
5876 information:
5877
5878
5879
5880
5881
5882 Dawson & Stenerson Standards Track [Page 105]
5883
5884 RFC 2445 iCalendar November 1998
5885
5886
5887 CONTACT;ALTREP="http://host.com/pdi/jdoe.vcf":Jim
5888 Dolittle\, ABC Industries\, +1-919-555-1234
5889
5890 4.8.4.3 Organizer
5891
5892 Property Name: ORGANIZER
5893
5894 Purpose: The property defines the organizer for a calendar component.
5895
5896 Value Type: CAL-ADDRESS
5897
5898 Property Parameters: Non-standard, language, common name, directory
5899 entry reference, sent by property parameters can be specified on this
5900 property.
5901
5902 Conformance: This property MUST be specified in an iCalendar object
5903 that specifies a group scheduled calendar entity. This property MUST
5904 be specified in an iCalendar object that specifies the publication of
5905 a calendar user's busy time. This property MUST NOT be specified in
5906 an iCalendar object that specifies only a time zone definition or
5907 that defines calendar entities that are not group scheduled entities,
5908 but are entities only on a single user's calendar.
5909
5910 Description: The property is specified within the "VEVENT", "VTODO",
5911 "VJOURNAL calendar components to specify the organizer of a group
5912 scheduled calendar entity. The property is specified within the
5913 "VFREEBUSY" calendar component to specify the calendar user
5914 requesting the free or busy time. When publishing a "VFREEBUSY"
5915 calendar component, the property is used to specify the calendar that
5916 the published busy time came from.
5917
5918 The property has the property parameters CN, for specifying the
5919 common or display name associated with the "Organizer", DIR, for
5920 specifying a pointer to the directory information associated with the
5921 "Organizer", SENT-BY, for specifying another calendar user that is
5922 acting on behalf of the "Organizer". The non-standard parameters may
5923 also be specified on this property. If the LANGUAGE property
5924 parameter is specified, the identified language applies to the CN
5925 parameter value.
5926
5927 Format Definition: The property is defined by the following notation:
5928
5929 organizer = "ORGANIZER" orgparam ":"
5930 cal-address CRLF
5931
5932 orgparam = *(
5933
5934 ; the following are optional,
5935
5936
5937
5938 Dawson & Stenerson Standards Track [Page 106]
5939
5940 RFC 2445 iCalendar November 1998
5941
5942
5943 ; but MUST NOT occur more than once
5944
5945 (";" cnparam) / (";" dirparam) / (";" sentbyparam) /
5946 (";" languageparam) /
5947
5948 ; the following is optional,
5949 ; and MAY occur more than once
5950
5951 (";" xparam)
5952
5953 )
5954
5955 Example: The following is an example of this property:
5956
5957 ORGANIZER;CN=John Smith:MAILTO:jsmith@host1.com
5958
5959 The following is an example of this property with a pointer to the
5960 directory information associated with the organizer:
5961
5962 ORGANIZER;CN=JohnSmith;DIR="ldap://host.com:6666/o=3DDC%20Associ
5963 ates,c=3DUS??(cn=3DJohn%20Smith)":MAILTO:jsmith@host1.com
5964
5965 The following is an example of this property used by another calendar
5966 user who is acting on behalf of the organizer, with responses
5967 intended to be sent back to the organizer, not the other calendar
5968 user:
5969
5970 ORGANIZER;SENT-BY="MAILTO:jane_doe@host.com":
5971 MAILTO:jsmith@host1.com
5972
5973 4.8.4.4 Recurrence ID
5974
5975 Property Name: RECURRENCE-ID
5976
5977 Purpose: This property is used in conjunction with the "UID" and
5978 "SEQUENCE" property to identify a specific instance of a recurring
5979 "VEVENT", "VTODO" or "VJOURNAL" calendar component. The property
5980 value is the effective value of the "DTSTART" property of the
5981 recurrence instance.
5982
5983 Value Type: The default value type for this property is DATE-TIME.
5984 The time format can be any of the valid forms defined for a DATE-TIME
5985 value type. See DATE-TIME value type definition for specific
5986 interpretations of the various forms. The value type can be set to
5987 DATE.
5988
5989
5990
5991
5992
5993
5994 Dawson & Stenerson Standards Track [Page 107]
5995
5996 RFC 2445 iCalendar November 1998
5997
5998
5999 Property Parameters: Non-standard property, value data type, time
6000 zone identifier and recurrence identifier range parameters can be
6001 specified on this property.
6002
6003 Conformance: This property can be specified in an iCalendar object
6004 containing a recurring calendar component.
6005
6006 Description: The full range of calendar components specified by a
6007 recurrence set is referenced by referring to just the "UID" property
6008 value corresponding to the calendar component. The "RECURRENCE-ID"
6009 property allows the reference to an individual instance within the
6010 recurrence set.
6011
6012 If the value of the "DTSTART" property is a DATE type value, then the
6013 value MUST be the calendar date for the recurrence instance.
6014
6015 The date/time value is set to the time when the original recurrence
6016 instance would occur; meaning that if the intent is to change a
6017 Friday meeting to Thursday, the date/time is still set to the
6018 original Friday meeting.
6019
6020 The "RECURRENCE-ID" property is used in conjunction with the "UID"
6021 and "SEQUENCE" property to identify a particular instance of a
6022 recurring event, to-do or journal. For a given pair of "UID" and
6023 "SEQUENCE" property values, the "RECURRENCE-ID" value for a
6024 recurrence instance is fixed. When the definition of the recurrence
6025 set for a calendar component changes, and hence the "SEQUENCE"
6026 property value changes, the "RECURRENCE-ID" for a given recurrence
6027 instance might also change.The "RANGE" parameter is used to specify
6028 the effective range of recurrence instances from the instance
6029 specified by the "RECURRENCE-ID" property value. The default value
6030 for the range parameter is the single recurrence instance only. The
6031 value can also be "THISANDPRIOR" to indicate a range defined by the
6032 given recurrence instance and all prior instances or the value can be
6033 "THISANDFUTURE" to indicate a range defined by the given recurrence
6034 instance and all subsequent instances.
6035
6036 Format Definition: The property is defined by the following notation:
6037
6038 recurid = "RECURRENCE-ID" ridparam ":" ridval CRLF
6039
6040 ridparam = *(
6041
6042 ; the following are optional,
6043 ; but MUST NOT occur more than once
6044
6045 (";" "VALUE" "=" ("DATE-TIME" / "DATE)) /
6046 (";" tzidparam) / (";" rangeparam) /
6047
6048
6049
6050 Dawson & Stenerson Standards Track [Page 108]
6051
6052 RFC 2445 iCalendar November 1998
6053
6054
6055 ; the following is optional,
6056 ; and MAY occur more than once
6057
6058 (";" xparam)
6059
6060 )
6061
6062 ridval = date-time / date
6063 ;Value MUST match value type
6064
6065 Example: The following are examples of this property:
6066
6067 RECURRENCE-ID;VALUE=DATE:19960401
6068
6069 RECURRENCE-ID;RANGE=THISANDFUTURE:19960120T120000Z
6070
6071 4.8.4.5 Related To
6072
6073 Property Name: RELATED-TO
6074
6075 Purpose: The property is used to represent a relationship or
6076 reference between one calendar component and another.
6077
6078 Value Type: TEXT
6079
6080 Property Parameters: Non-standard and relationship type property
6081 parameters can be specified on this property.
6082
6083 Conformance: The property can be specified one or more times in the
6084 "VEVENT", "VTODO" or "VJOURNAL" calendar components.
6085
6086 Description: The property value consists of the persistent, globally
6087 unique identifier of another calendar component. This value would be
6088 represented in a calendar component by the "UID" property.
6089
6090 By default, the property value points to another calendar component
6091 that has a PARENT relationship to the referencing object. The
6092 "RELTYPE" property parameter is used to either explicitly state the
6093 default PARENT relationship type to the referenced calendar component
6094 or to override the default PARENT relationship type and specify
6095 either a CHILD or SIBLING relationship. The PARENT relationship
6096 indicates that the calendar component is a subordinate of the
6097 referenced calendar component. The CHILD relationship indicates that
6098 the calendar component is a superior of the referenced calendar
6099 component. The SIBLING relationship indicates that the calendar
6100 component is a peer of the referenced calendar component.
6101
6102
6103
6104
6105
6106 Dawson & Stenerson Standards Track [Page 109]
6107
6108 RFC 2445 iCalendar November 1998
6109
6110
6111 Changes to a calendar component referenced by this property can have
6112 an implicit impact on the related calendar component. For example, if
6113 a group event changes its start or end date or time, then the
6114 related, dependent events will need to have their start and end dates
6115 changed in a corresponding way. Similarly, if a PARENT calendar
6116 component is canceled or deleted, then there is an implied impact to
6117 the related CHILD calendar components. This property is intended only
6118 to provide information on the relationship of calendar components. It
6119 is up to the target calendar system to maintain any property
6120 implications of this relationship.
6121
6122 Format Definition: The property is defined by the following notation:
6123
6124 related = "RELATED-TO" [relparam] ":" text CRLF
6125
6126 relparam = *(
6127
6128 ; the following is optional,
6129 ; but MUST NOT occur more than once
6130
6131 (";" reltypeparam) /
6132
6133 ; the following is optional,
6134 ; and MAY occur more than once
6135
6136 (";" xparm)
6137
6138 )
6139
6140 The following is an example of this property:
6141
6142 RELATED-TO:<jsmith.part7.19960817T083000.xyzMail@host3.com>
6143
6144 RELATED-TO:<19960401-080045-4000F192713-0052@host1.com>
6145
6146 4.8.4.6 Uniform Resource Locator
6147
6148 Property Name: URL
6149
6150 Purpose: This property defines a Uniform Resource Locator (URL)
6151 associated with the iCalendar object.
6152
6153 Value Type: URI
6154
6155 Property Parameters: Non-standard property parameters can be
6156 specified on this property.
6157
6158
6159
6160
6161
6162 Dawson & Stenerson Standards Track [Page 110]
6163
6164 RFC 2445 iCalendar November 1998
6165
6166
6167 Conformance: This property can be specified once in the "VEVENT",
6168 "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components.
6169
6170 Description: This property may be used in a calendar component to
6171 convey a location where a more dynamic rendition of the calendar
6172 information associated with the calendar component can be found. This
6173 memo does not attempt to standardize the form of the URI, nor the
6174 format of the resource pointed to by the property value. If the URL
6175 property and Content-Location MIME header are both specified, they
6176 MUST point to the same resource.
6177
6178 Format Definition: The property is defined by the following notation:
6179
6180 url = "URL" urlparam ":" uri CRLF
6181
6182 urlparam = *(";" xparam)
6183
6184 Example: The following is an example of this property:
6185
6186 URL:http://abc.com/pub/calendars/jsmith/mytime.ics
6187
6188 4.8.4.7 Unique Identifier
6189
6190 Property Name: UID
6191
6192 Purpose: This property defines the persistent, globally unique
6193 identifier for the calendar component.
6194
6195 Value Type: TEXT
6196
6197 Property Parameters: Non-standard property parameters can be
6198 specified on this property.
6199
6200 Conformance: The property MUST be specified in the "VEVENT", "VTODO",
6201 "VJOURNAL" or "VFREEBUSY" calendar components.
6202
6203 Description: The UID itself MUST be a globally unique identifier. The
6204 generator of the identifier MUST guarantee that the identifier is
6205 unique. There are several algorithms that can be used to accomplish
6206 this. The identifier is RECOMMENDED to be the identical syntax to the
6207 [RFC 822] addr-spec. A good method to assure uniqueness is to put the
6208 domain name or a domain literal IP address of the host on which the
6209 identifier was created on the right hand side of the "@", and on the
6210 left hand side, put a combination of the current calendar date and
6211 time of day (i.e., formatted in as a DATE-TIME value) along with some
6212 other currently unique (perhaps sequential) identifier available on
6213 the system (for example, a process id number). Using a date/time
6214 value on the left hand side and a domain name or domain literal on
6215
6216
6217
6218 Dawson & Stenerson Standards Track [Page 111]
6219
6220 RFC 2445 iCalendar November 1998
6221
6222
6223 the right hand side makes it possible to guarantee uniqueness since
6224 no two hosts should be using the same domain name or IP address at
6225 the same time. Though other algorithms will work, it is RECOMMENDED
6226 that the right hand side contain some domain identifier (either of
6227 the host itself or otherwise) such that the generator of the message
6228 identifier can guarantee the uniqueness of the left hand side within
6229 the scope of that domain.
6230
6231 This is the method for correlating scheduling messages with the
6232 referenced "VEVENT", "VTODO", or "VJOURNAL" calendar component.
6233
6234 The full range of calendar components specified by a recurrence set
6235 is referenced by referring to just the "UID" property value
6236 corresponding to the calendar component. The "RECURRENCE-ID" property
6237 allows the reference to an individual instance within the recurrence
6238 set.
6239
6240 This property is an important method for group scheduling
6241 applications to match requests with later replies, modifications or
6242 deletion requests. Calendaring and scheduling applications MUST
6243 generate this property in "VEVENT", "VTODO" and "VJOURNAL" calendar
6244 components to assure interoperability with other group scheduling
6245 applications. This identifier is created by the calendar system that
6246 generates an iCalendar object.
6247
6248 Implementations MUST be able to receive and persist values of at
6249 least 255 characters for this property.
6250
6251 Format Definition: The property is defined by the following notation:
6252
6253 uid = "UID" uidparam ":" text CRLF
6254
6255 uidparam = *(";" xparam)
6256
6257 Example: The following is an example of this property:
6258
6259 UID:19960401T080045Z-4000F192713-0052@host1.com
6260
6261 4.8.5 Recurrence Component Properties
6262
6263 The following properties specify recurrence information in calendar
6264 components.
6265
6266 4.8.5.1 Exception Date/Times
6267
6268 Property Name: EXDATE
6269
6270
6271
6272
6273
6274 Dawson & Stenerson Standards Track [Page 112]
6275
6276 RFC 2445 iCalendar November 1998
6277
6278
6279 Purpose: This property defines the list of date/time exceptions for a
6280 recurring calendar component.
6281
6282 Value Type: The default value type for this property is DATE-TIME.
6283 The value type can be set to DATE.
6284
6285 Property Parameters: Non-standard, value data type and time zone
6286 identifier property parameters can be specified on this property.
6287
6288 Conformance: This property can be specified in an iCalendar object
6289 that includes a recurring calendar component.
6290
6291 Description: The exception dates, if specified, are used in computing
6292 the recurrence set. The recurrence set is the complete set of
6293 recurrence instances for a calendar component. The recurrence set is
6294 generated by considering the initial "DTSTART" property along with
6295 the "RRULE", "RDATE", "EXDATE" and "EXRULE" properties contained
6296 within the iCalendar object. The "DTSTART" property defines the first
6297 instance in the recurrence set. Multiple instances of the "RRULE" and
6298 "EXRULE" properties can also be specified to define more
6299 sophisticated recurrence sets. The final recurrence set is generated
6300 by gathering all of the start date-times generated by any of the
6301 specified "RRULE" and "RDATE" properties, and then excluding any
6302 start date and times which fall within the union of start date and
6303 times generated by any specified "EXRULE" and "EXDATE" properties.
6304 This implies that start date and times within exclusion related
6305 properties (i.e., "EXDATE" and "EXRULE") take precedence over those
6306 specified by inclusion properties (i.e., "RDATE" and "RRULE"). Where
6307 duplicate instances are generated by the "RRULE" and "RDATE"
6308 properties, only one recurrence is considered. Duplicate instances
6309 are ignored.
6310
6311 The "EXDATE" property can be used to exclude the value specified in
6312 "DTSTART". However, in such cases the original "DTSTART" date MUST
6313 still be maintained by the calendaring and scheduling system because
6314 the original "DTSTART" value has inherent usage dependencies by other
6315 properties such as the "RECURRENCE-ID".
6316
6317 Format Definition: The property is defined by the following notation:
6318
6319 exdate = "EXDATE" exdtparam ":" exdtval *("," exdtval) CRLF
6320
6321 exdtparam = *(
6322
6323 ; the following are optional,
6324 ; but MUST NOT occur more than once
6325
6326 (";" "VALUE" "=" ("DATE-TIME" / "DATE")) /
6327
6328
6329
6330 Dawson & Stenerson Standards Track [Page 113]
6331
6332 RFC 2445 iCalendar November 1998
6333
6334
6335 (";" tzidparam) /
6336
6337 ; the following is optional,
6338 ; and MAY occur more than once
6339
6340 (";" xparam)
6341
6342 )
6343
6344 exdtval = date-time / date
6345 ;Value MUST match value type
6346
6347 Example: The following is an example of this property:
6348
6349 EXDATE:19960402T010000Z,19960403T010000Z,19960404T010000Z
6350
6351 4.8.5.2 Exception Rule
6352
6353 Property Name: EXRULE
6354
6355 Purpose: This property defines a rule or repeating pattern for an
6356 exception to a recurrence set.
6357
6358 Value Type: RECUR
6359
6360 Property Parameters: Non-standard property parameters can be
6361 specified on this property.
6362
6363 Conformance: This property can be specified in "VEVENT", "VTODO" or
6364 "VJOURNAL" calendar components.
6365
6366 Description: The exception rule, if specified, is used in computing
6367 the recurrence set. The recurrence set is the complete set of
6368 recurrence instances for a calendar component. The recurrence set is
6369 generated by considering the initial "DTSTART" property along with
6370 the "RRULE", "RDATE", "EXDATE" and "EXRULE" properties contained
6371 within the iCalendar object. The "DTSTART" defines the first instance
6372 in the recurrence set. Multiple instances of the "RRULE" and "EXRULE"
6373 properties can also be specified to define more sophisticated
6374 recurrence sets. The final recurrence set is generated by gathering
6375 all of the start date-times generated by any of the specified "RRULE"
6376 and "RDATE" properties, and excluding any start date and times which
6377 fall within the union of start date and times generated by any
6378 specified "EXRULE" and "EXDATE" properties. This implies that start
6379 date and times within exclusion related properties (i.e., "EXDATE"
6380 and "EXRULE") take precedence over those specified by inclusion
6381
6382
6383
6384
6385
6386 Dawson & Stenerson Standards Track [Page 114]
6387
6388 RFC 2445 iCalendar November 1998
6389
6390
6391 properties (i.e., "RDATE" and "RRULE"). Where duplicate instances are
6392 generated by the "RRULE" and "RDATE" properties, only one recurrence
6393 is considered. Duplicate instances are ignored.
6394
6395 The "EXRULE" property can be used to exclude the value specified in
6396 "DTSTART". However, in such cases the original "DTSTART" date MUST
6397 still be maintained by the calendaring and scheduling system because
6398 the original "DTSTART" value has inherent usage dependencies by other
6399 properties such as the "RECURRENCE-ID".
6400
6401 Format Definition: The property is defined by the following notation:
6402
6403 exrule = "EXRULE" exrparam ":" recur CRLF
6404
6405 exrparam = *(";" xparam)
6406
6407 Example: The following are examples of this property. Except every
6408 other week, on Tuesday and Thursday for 4 occurrences:
6409
6410 EXRULE:FREQ=WEEKLY;COUNT=4;INTERVAL=2;BYDAY=TU,TH
6411
6412 Except daily for 10 occurrences:
6413
6414 EXRULE:FREQ=DAILY;COUNT=10
6415
6416 Except yearly in June and July for 8 occurrences:
6417
6418 EXRULE:FREQ=YEARLY;COUNT=8;BYMONTH=6,7
6419
6420 4.8.5.3 Recurrence Date/Times
6421
6422 Property Name: RDATE
6423
6424 Purpose: This property defines the list of date/times for a
6425 recurrence set.
6426
6427 Value Type: The default value type for this property is DATE-TIME.
6428 The value type can be set to DATE or PERIOD.
6429
6430 Property Parameters: Non-standard, value data type and time zone
6431 identifier property parameters can be specified on this property.
6432
6433 Conformance: The property can be specified in "VEVENT", "VTODO",
6434 "VJOURNAL" or "VTIMEZONE" calendar components.
6435
6436
6437
6438
6439
6440
6441
6442 Dawson & Stenerson Standards Track [Page 115]
6443
6444 RFC 2445 iCalendar November 1998
6445
6446
6447 Description: This property can appear along with the "RRULE" property
6448 to define an aggregate set of repeating occurrences. When they both
6449 appear in an iCalendar object, the recurring events are defined by
6450 the union of occurrences defined by both the "RDATE" and "RRULE".
6451
6452 The recurrence dates, if specified, are used in computing the
6453 recurrence set. The recurrence set is the complete set of recurrence
6454 instances for a calendar component. The recurrence set is generated
6455 by considering the initial "DTSTART" property along with the "RRULE",
6456 "RDATE", "EXDATE" and "EXRULE" properties contained within the
6457 iCalendar object. The "DTSTART" property defines the first instance
6458 in the recurrence set. Multiple instances of the "RRULE" and "EXRULE"
6459 properties can also be specified to define more sophisticated
6460 recurrence sets. The final recurrence set is generated by gathering
6461 all of the start date/times generated by any of the specified "RRULE"
6462 and "RDATE" properties, and excluding any start date/times which fall
6463 within the union of start date/times generated by any specified
6464 "EXRULE" and "EXDATE" properties. This implies that start date/times
6465 within exclusion related properties (i.e., "EXDATE" and "EXRULE")
6466 take precedence over those specified by inclusion properties (i.e.,
6467 "RDATE" and "RRULE"). Where duplicate instances are generated by the
6468 "RRULE" and "RDATE" properties, only one recurrence is considered.
6469 Duplicate instances are ignored.
6470
6471 Format Definition: The property is defined by the following notation:
6472
6473 rdate = "RDATE" rdtparam ":" rdtval *("," rdtval) CRLF
6474
6475 rdtparam = *(
6476
6477 ; the following are optional,
6478 ; but MUST NOT occur more than once
6479
6480 (";" "VALUE" "=" ("DATE-TIME" / "DATE" / "PERIOD")) /
6481 (";" tzidparam) /
6482
6483 ; the following is optional,
6484 ; and MAY occur more than once
6485
6486 (";" xparam)
6487
6488 )
6489
6490 rdtval = date-time / date / period
6491 ;Value MUST match value type
6492
6493 Example: The following are examples of this property:
6494
6495
6496
6497
6498 Dawson & Stenerson Standards Track [Page 116]
6499
6500 RFC 2445 iCalendar November 1998
6501
6502
6503 RDATE:19970714T123000Z
6504
6505 RDATE;TZID=US-EASTERN:19970714T083000
6506
6507 RDATE;VALUE=PERIOD:19960403T020000Z/19960403T040000Z,
6508 19960404T010000Z/PT3H
6509
6510 RDATE;VALUE=DATE:19970101,19970120,19970217,19970421
6511 19970526,19970704,19970901,19971014,19971128,19971129,19971225
6512
6513 4.8.5.4 Recurrence Rule
6514
6515 Property Name: RRULE
6516
6517 Purpose: This property defines a rule or repeating pattern for
6518 recurring events, to-dos, or time zone definitions.
6519
6520 Value Type: RECUR
6521
6522 Property Parameters: Non-standard property parameters can be
6523 specified on this property.
6524
6525 Conformance: This property can be specified one or more times in
6526 recurring "VEVENT", "VTODO" and "VJOURNAL" calendar components. It
6527 can also be specified once in each STANDARD or DAYLIGHT sub-component
6528 of the "VTIMEZONE" calendar component.
6529
6530 Description: The recurrence rule, if specified, is used in computing
6531 the recurrence set. The recurrence set is the complete set of
6532 recurrence instances for a calendar component. The recurrence set is
6533 generated by considering the initial "DTSTART" property along with
6534 the "RRULE", "RDATE", "EXDATE" and "EXRULE" properties contained
6535 within the iCalendar object. The "DTSTART" property defines the first
6536 instance in the recurrence set. Multiple instances of the "RRULE" and
6537 "EXRULE" properties can also be specified to define more
6538 sophisticated recurrence sets. The final recurrence set is generated
6539 by gathering all of the start date/times generated by any of the
6540 specified "RRULE" and "RDATE" properties, and excluding any start
6541 date/times which fall within the union of start date/times generated
6542 by any specified "EXRULE" and "EXDATE" properties. This implies that
6543 start date/times within exclusion related properties (i.e., "EXDATE"
6544 and "EXRULE") take precedence over those specified by inclusion
6545 properties (i.e., "RDATE" and "RRULE"). Where duplicate instances are
6546 generated by the "RRULE" and "RDATE" properties, only one recurrence
6547 is considered. Duplicate instances are ignored.
6548
6549
6550
6551
6552
6553
6554 Dawson & Stenerson Standards Track [Page 117]
6555
6556 RFC 2445 iCalendar November 1998
6557
6558
6559 The "DTSTART" and "DTEND" property pair or "DTSTART" and "DURATION"
6560 property pair, specified within the iCalendar object defines the
6561 first instance of the recurrence. When used with a recurrence rule,
6562 the "DTSTART" and "DTEND" properties MUST be specified in local time
6563 and the appropriate set of "VTIMEZONE" calendar components MUST be
6564 included. For detail on the usage of the "VTIMEZONE" calendar
6565 component, see the "VTIMEZONE" calendar component definition.
6566
6567 Any duration associated with the iCalendar object applies to all
6568 members of the generated recurrence set. Any modified duration for
6569 specific recurrences MUST be explicitly specified using the "RDATE"
6570 property.
6571
6572 Format Definition: This property is defined by the following
6573 notation:
6574
6575 rrule = "RRULE" rrulparam ":" recur CRLF
6576
6577 rrulparam = *(";" xparam)
6578
6579 Example: All examples assume the Eastern United States time zone.
6580
6581 Daily for 10 occurrences:
6582
6583 DTSTART;TZID=US-Eastern:19970902T090000
6584 RRULE:FREQ=DAILY;COUNT=10
6585
6586 ==> (1997 9:00 AM EDT)September 2-11
6587
6588 Daily until December 24, 1997:
6589
6590 DTSTART;TZID=US-Eastern:19970902T090000
6591 RRULE:FREQ=DAILY;UNTIL=19971224T000000Z
6592
6593 ==> (1997 9:00 AM EDT)September 2-30;October 1-25
6594 (1997 9:00 AM EST)October 26-31;November 1-30;December 1-23
6595
6596 Every other day - forever:
6597
6598 DTSTART;TZID=US-Eastern:19970902T090000
6599 RRULE:FREQ=DAILY;INTERVAL=2
6600 ==> (1997 9:00 AM EDT)September2,4,6,8...24,26,28,30;
6601 October 2,4,6...20,22,24
6602 (1997 9:00 AM EST)October 26,28,30;November 1,3,5,7...25,27,29;
6603 Dec 1,3,...
6604
6605 Every 10 days, 5 occurrences:
6606
6607
6608
6609
6610 Dawson & Stenerson Standards Track [Page 118]
6611
6612 RFC 2445 iCalendar November 1998
6613
6614
6615 DTSTART;TZID=US-Eastern:19970902T090000
6616 RRULE:FREQ=DAILY;INTERVAL=10;COUNT=5
6617
6618 ==> (1997 9:00 AM EDT)September 2,12,22;October 2,12
6619
6620 Everyday in January, for 3 years:
6621
6622 DTSTART;TZID=US-Eastern:19980101T090000
6623 RRULE:FREQ=YEARLY;UNTIL=20000131T090000Z;
6624 BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA
6625 or
6626 RRULE:FREQ=DAILY;UNTIL=20000131T090000Z;BYMONTH=1
6627
6628 ==> (1998 9:00 AM EDT)January 1-31
6629 (1999 9:00 AM EDT)January 1-31
6630 (2000 9:00 AM EDT)January 1-31
6631
6632 Weekly for 10 occurrences
6633
6634 DTSTART;TZID=US-Eastern:19970902T090000
6635 RRULE:FREQ=WEEKLY;COUNT=10
6636
6637 ==> (1997 9:00 AM EDT)September 2,9,16,23,30;October 7,14,21
6638 (1997 9:00 AM EST)October 28;November 4
6639
6640 Weekly until December 24, 1997
6641
6642 DTSTART;TZID=US-Eastern:19970902T090000
6643 RRULE:FREQ=WEEKLY;UNTIL=19971224T000000Z
6644
6645 ==> (1997 9:00 AM EDT)September 2,9,16,23,30;October 7,14,21
6646 (1997 9:00 AM EST)October 28;November 4,11,18,25;
6647 December 2,9,16,23
6648 Every other week - forever:
6649
6650 DTSTART;TZID=US-Eastern:19970902T090000
6651 RRULE:FREQ=WEEKLY;INTERVAL=2;WKST=SU
6652
6653 ==> (1997 9:00 AM EDT)September 2,16,30;October 14
6654 (1997 9:00 AM EST)October 28;November 11,25;December 9,23
6655 (1998 9:00 AM EST)January 6,20;February
6656 ...
6657
6658 Weekly on Tuesday and Thursday for 5 weeks:
6659
6660 DTSTART;TZID=US-Eastern:19970902T090000
6661 RRULE:FREQ=WEEKLY;UNTIL=19971007T000000Z;WKST=SU;BYDAY=TU,TH
6662 or
6663
6664
6665
6666 Dawson & Stenerson Standards Track [Page 119]
6667
6668 RFC 2445 iCalendar November 1998
6669
6670
6671 RRULE:FREQ=WEEKLY;COUNT=10;WKST=SU;BYDAY=TU,TH
6672
6673 ==> (1997 9:00 AM EDT)September 2,4,9,11,16,18,23,25,30;October 2
6674
6675 Every other week on Monday, Wednesday and Friday until December 24,
6676 1997, but starting on Tuesday, September 2, 1997:
6677
6678 DTSTART;TZID=US-Eastern:19970902T090000
6679 RRULE:FREQ=WEEKLY;INTERVAL=2;UNTIL=19971224T000000Z;WKST=SU;
6680 BYDAY=MO,WE,FR
6681 ==> (1997 9:00 AM EDT)September 2,3,5,15,17,19,29;October
6682 1,3,13,15,17
6683 (1997 9:00 AM EST)October 27,29,31;November 10,12,14,24,26,28;
6684 December 8,10,12,22
6685
6686 Every other week on Tuesday and Thursday, for 8 occurrences:
6687
6688 DTSTART;TZID=US-Eastern:19970902T090000
6689 RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=8;WKST=SU;BYDAY=TU,TH
6690
6691 ==> (1997 9:00 AM EDT)September 2,4,16,18,30;October 2,14,16
6692
6693 Monthly on the 1st Friday for ten occurrences:
6694
6695 DTSTART;TZID=US-Eastern:19970905T090000
6696 RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR
6697
6698 ==> (1997 9:00 AM EDT)September 5;October 3
6699 (1997 9:00 AM EST)November 7;Dec 5
6700 (1998 9:00 AM EST)January 2;February 6;March 6;April 3
6701 (1998 9:00 AM EDT)May 1;June 5
6702
6703 Monthly on the 1st Friday until December 24, 1997:
6704
6705 DTSTART;TZID=US-Eastern:19970905T090000
6706 RRULE:FREQ=MONTHLY;UNTIL=19971224T000000Z;BYDAY=1FR
6707
6708 ==> (1997 9:00 AM EDT)September 5;October 3
6709 (1997 9:00 AM EST)November 7;December 5
6710
6711 Every other month on the 1st and last Sunday of the month for 10
6712 occurrences:
6713
6714 DTSTART;TZID=US-Eastern:19970907T090000
6715 RRULE:FREQ=MONTHLY;INTERVAL=2;COUNT=10;BYDAY=1SU,-1SU
6716
6717 ==> (1997 9:00 AM EDT)September 7,28
6718 (1997 9:00 AM EST)November 2,30
6719
6720
6721
6722 Dawson & Stenerson Standards Track [Page 120]
6723
6724 RFC 2445 iCalendar November 1998
6725
6726
6727 (1998 9:00 AM EST)January 4,25;March 1,29
6728 (1998 9:00 AM EDT)May 3,31
6729
6730 Monthly on the second to last Monday of the month for 6 months:
6731
6732 DTSTART;TZID=US-Eastern:19970922T090000
6733 RRULE:FREQ=MONTHLY;COUNT=6;BYDAY=-2MO
6734
6735 ==> (1997 9:00 AM EDT)September 22;October 20
6736 (1997 9:00 AM EST)November 17;December 22
6737 (1998 9:00 AM EST)January 19;February 16
6738
6739 Monthly on the third to the last day of the month, forever:
6740
6741 DTSTART;TZID=US-Eastern:19970928T090000
6742 RRULE:FREQ=MONTHLY;BYMONTHDAY=-3
6743
6744 ==> (1997 9:00 AM EDT)September 28
6745 (1997 9:00 AM EST)October 29;November 28;December 29
6746 (1998 9:00 AM EST)January 29;February 26
6747 ...
6748
6749 Monthly on the 2nd and 15th of the month for 10 occurrences:
6750
6751 DTSTART;TZID=US-Eastern:19970902T090000
6752 RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=2,15
6753
6754 ==> (1997 9:00 AM EDT)September 2,15;October 2,15
6755 (1997 9:00 AM EST)November 2,15;December 2,15
6756 (1998 9:00 AM EST)January 2,15
6757
6758 Monthly on the first and last day of the month for 10 occurrences:
6759
6760 DTSTART;TZID=US-Eastern:19970930T090000
6761 RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=1,-1
6762
6763 ==> (1997 9:00 AM EDT)September 30;October 1
6764 (1997 9:00 AM EST)October 31;November 1,30;December 1,31
6765 (1998 9:00 AM EST)January 1,31;February 1
6766
6767 Every 18 months on the 10th thru 15th of the month for 10
6768 occurrences:
6769
6770 DTSTART;TZID=US-Eastern:19970910T090000
6771 RRULE:FREQ=MONTHLY;INTERVAL=18;COUNT=10;BYMONTHDAY=10,11,12,13,14,
6772 15
6773
6774 ==> (1997 9:00 AM EDT)September 10,11,12,13,14,15
6775
6776
6777
6778 Dawson & Stenerson Standards Track [Page 121]
6779
6780 RFC 2445 iCalendar November 1998
6781
6782
6783 (1999 9:00 AM EST)March 10,11,12,13
6784
6785 Every Tuesday, every other month:
6786
6787 DTSTART;TZID=US-Eastern:19970902T090000
6788 RRULE:FREQ=MONTHLY;INTERVAL=2;BYDAY=TU
6789
6790 ==> (1997 9:00 AM EDT)September 2,9,16,23,30
6791 (1997 9:00 AM EST)November 4,11,18,25
6792 (1998 9:00 AM EST)January 6,13,20,27;March 3,10,17,24,31
6793 ...
6794
6795 Yearly in June and July for 10 occurrences:
6796
6797 DTSTART;TZID=US-Eastern:19970610T090000
6798 RRULE:FREQ=YEARLY;COUNT=10;BYMONTH=6,7
6799 ==> (1997 9:00 AM EDT)June 10;July 10
6800 (1998 9:00 AM EDT)June 10;July 10
6801 (1999 9:00 AM EDT)June 10;July 10
6802 (2000 9:00 AM EDT)June 10;July 10
6803 (2001 9:00 AM EDT)June 10;July 10
6804 Note: Since none of the BYDAY, BYMONTHDAY or BYYEARDAY components
6805 are specified, the day is gotten from DTSTART
6806
6807 Every other year on January, February, and March for 10 occurrences:
6808
6809 DTSTART;TZID=US-Eastern:19970310T090000
6810 RRULE:FREQ=YEARLY;INTERVAL=2;COUNT=10;BYMONTH=1,2,3
6811
6812 ==> (1997 9:00 AM EST)March 10
6813 (1999 9:00 AM EST)January 10;February 10;March 10
6814 (2001 9:00 AM EST)January 10;February 10;March 10
6815 (2003 9:00 AM EST)January 10;February 10;March 10
6816
6817 Every 3rd year on the 1st, 100th and 200th day for 10 occurrences:
6818
6819 DTSTART;TZID=US-Eastern:19970101T090000
6820 RRULE:FREQ=YEARLY;INTERVAL=3;COUNT=10;BYYEARDAY=1,100,200
6821
6822 ==> (1997 9:00 AM EST)January 1
6823 (1997 9:00 AM EDT)April 10;July 19
6824 (2000 9:00 AM EST)January 1
6825 (2000 9:00 AM EDT)April 9;July 18
6826 (2003 9:00 AM EST)January 1
6827 (2003 9:00 AM EDT)April 10;July 19
6828 (2006 9:00 AM EST)January 1
6829
6830 Every 20th Monday of the year, forever:
6831
6832
6833
6834 Dawson & Stenerson Standards Track [Page 122]
6835
6836 RFC 2445 iCalendar November 1998
6837
6838
6839 DTSTART;TZID=US-Eastern:19970519T090000
6840 RRULE:FREQ=YEARLY;BYDAY=20MO
6841
6842 ==> (1997 9:00 AM EDT)May 19
6843 (1998 9:00 AM EDT)May 18
6844 (1999 9:00 AM EDT)May 17
6845 ...
6846
6847 Monday of week number 20 (where the default start of the week is
6848 Monday), forever:
6849
6850 DTSTART;TZID=US-Eastern:19970512T090000
6851 RRULE:FREQ=YEARLY;BYWEEKNO=20;BYDAY=MO
6852
6853 ==> (1997 9:00 AM EDT)May 12
6854 (1998 9:00 AM EDT)May 11
6855 (1999 9:00 AM EDT)May 17
6856 ...
6857
6858 Every Thursday in March, forever:
6859
6860 DTSTART;TZID=US-Eastern:19970313T090000
6861 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=TH
6862
6863 ==> (1997 9:00 AM EST)March 13,20,27
6864 (1998 9:00 AM EST)March 5,12,19,26
6865 (1999 9:00 AM EST)March 4,11,18,25
6866 ...
6867
6868 Every Thursday, but only during June, July, and August, forever:
6869
6870 DTSTART;TZID=US-Eastern:19970605T090000
6871 RRULE:FREQ=YEARLY;BYDAY=TH;BYMONTH=6,7,8
6872
6873 ==> (1997 9:00 AM EDT)June 5,12,19,26;July 3,10,17,24,31;
6874 August 7,14,21,28
6875 (1998 9:00 AM EDT)June 4,11,18,25;July 2,9,16,23,30;
6876 August 6,13,20,27
6877 (1999 9:00 AM EDT)June 3,10,17,24;July 1,8,15,22,29;
6878 August 5,12,19,26
6879 ...
6880
6881 Every Friday the 13th, forever:
6882
6883 DTSTART;TZID=US-Eastern:19970902T090000
6884 EXDATE;TZID=US-Eastern:19970902T090000
6885 RRULE:FREQ=MONTHLY;BYDAY=FR;BYMONTHDAY=13
6886
6887
6888
6889
6890 Dawson & Stenerson Standards Track [Page 123]
6891
6892 RFC 2445 iCalendar November 1998
6893
6894
6895 ==> (1998 9:00 AM EST)February 13;March 13;November 13
6896 (1999 9:00 AM EDT)August 13
6897 (2000 9:00 AM EDT)October 13
6898 ...
6899
6900 The first Saturday that follows the first Sunday of the month,
6901 forever:
6902
6903 DTSTART;TZID=US-Eastern:19970913T090000
6904 RRULE:FREQ=MONTHLY;BYDAY=SA;BYMONTHDAY=7,8,9,10,11,12,13
6905
6906 ==> (1997 9:00 AM EDT)September 13;October 11
6907 (1997 9:00 AM EST)November 8;December 13
6908 (1998 9:00 AM EST)January 10;February 7;March 7
6909 (1998 9:00 AM EDT)April 11;May 9;June 13...
6910 ...
6911
6912 Every four years, the first Tuesday after a Monday in November,
6913 forever (U.S. Presidential Election day):
6914
6915 DTSTART;TZID=US-Eastern:19961105T090000
6916 RRULE:FREQ=YEARLY;INTERVAL=4;BYMONTH=11;BYDAY=TU;BYMONTHDAY=2,3,4,
6917 5,6,7,8
6918
6919 ==> (1996 9:00 AM EST)November 5
6920 (2000 9:00 AM EST)November 7
6921 (2004 9:00 AM EST)November 2
6922 ...
6923
6924 The 3rd instance into the month of one of Tuesday, Wednesday or
6925 Thursday, for the next 3 months:
6926
6927 DTSTART;TZID=US-Eastern:19970904T090000
6928 RRULE:FREQ=MONTHLY;COUNT=3;BYDAY=TU,WE,TH;BYSETPOS=3
6929
6930 ==> (1997 9:00 AM EDT)September 4;October 7
6931 (1997 9:00 AM EST)November 6
6932
6933 The 2nd to last weekday of the month:
6934
6935 DTSTART;TZID=US-Eastern:19970929T090000
6936 RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-2
6937
6938 ==> (1997 9:00 AM EDT)September 29
6939 (1997 9:00 AM EST)October 30;November 27;December 30
6940 (1998 9:00 AM EST)January 29;February 26;March 30
6941 ...
6942
6943
6944
6945
6946 Dawson & Stenerson Standards Track [Page 124]
6947
6948 RFC 2445 iCalendar November 1998
6949
6950
6951 Every 3 hours from 9:00 AM to 5:00 PM on a specific day:
6952
6953 DTSTART;TZID=US-Eastern:19970902T090000
6954 RRULE:FREQ=HOURLY;INTERVAL=3;UNTIL=19970902T170000Z
6955
6956 ==> (September 2, 1997 EDT)09:00,12:00,15:00
6957
6958 Every 15 minutes for 6 occurrences:
6959
6960 DTSTART;TZID=US-Eastern:19970902T090000
6961 RRULE:FREQ=MINUTELY;INTERVAL=15;COUNT=6
6962
6963 ==> (September 2, 1997 EDT)09:00,09:15,09:30,09:45,10:00,10:15
6964
6965 Every hour and a half for 4 occurrences:
6966
6967 DTSTART;TZID=US-Eastern:19970902T090000
6968 RRULE:FREQ=MINUTELY;INTERVAL=90;COUNT=4
6969
6970 ==> (September 2, 1997 EDT)09:00,10:30;12:00;13:30
6971
6972 Every 20 minutes from 9:00 AM to 4:40 PM every day:
6973
6974 DTSTART;TZID=US-Eastern:19970902T090000
6975 RRULE:FREQ=DAILY;BYHOUR=9,10,11,12,13,14,15,16;BYMINUTE=0,20,40
6976 or
6977 RRULE:FREQ=MINUTELY;INTERVAL=20;BYHOUR=9,10,11,12,13,14,15,16
6978
6979 ==> (September 2, 1997 EDT)9:00,9:20,9:40,10:00,10:20,
6980 ... 16:00,16:20,16:40
6981 (September 3, 1997 EDT)9:00,9:20,9:40,10:00,10:20,
6982 ...16:00,16:20,16:40
6983 ...
6984
6985 An example where the days generated makes a difference because of
6986 WKST:
6987
6988 DTSTART;TZID=US-Eastern:19970805T090000
6989 RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=4;BYDAY=TU,SU;WKST=MO
6990
6991 ==> (1997 EDT)Aug 5,10,19,24
6992
6993 changing only WKST from MO to SU, yields different results...
6994
6995 DTSTART;TZID=US-Eastern:19970805T090000
6996 RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=4;BYDAY=TU,SU;WKST=SU
6997 ==> (1997 EDT)August 5,17,19,31
6998
6999
7000
7001
7002 Dawson & Stenerson Standards Track [Page 125]
7003
7004 RFC 2445 iCalendar November 1998
7005
7006
7007 4.8.6 Alarm Component Properties
7008
7009 The following properties specify alarm information in calendar
7010 components.
7011
7012 4.8.6.1 Action
7013
7014 Property Name: ACTION
7015
7016 Purpose: This property defines the action to be invoked when an alarm
7017 is triggered.
7018
7019 Value Type: TEXT
7020
7021 Property Parameters: Non-standard property parameters can be
7022 specified on this property.
7023
7024 Conformance: This property MUST be specified once in a "VALARM"
7025 calendar component.
7026
7027 Description: Each "VALARM" calendar component has a particular type
7028 of action associated with it. This property specifies the type of
7029 action
7030
7031 Format Definition: The property is defined by the following notation:
7032
7033 action = "ACTION" actionparam ":" actionvalue CRLF
7034
7035 actionparam = *(";" xparam)
7036
7037 actionvalue = "AUDIO" / "DISPLAY" / "EMAIL" / "PROCEDURE"
7038 / iana-token / x-name
7039
7040 Example: The following are examples of this property in a "VALARM"
7041 calendar component:
7042
7043 ACTION:AUDIO
7044
7045 ACTION:DISPLAY
7046
7047 ACTION:PROCEDURE
7048
7049 4.8.6.2 Repeat Count
7050
7051 Property Name: REPEAT
7052
7053 Purpose: This property defines the number of time the alarm should be
7054 repeated, after the initial trigger.
7055
7056
7057
7058 Dawson & Stenerson Standards Track [Page 126]
7059
7060 RFC 2445 iCalendar November 1998
7061
7062
7063 Value Type: INTEGER
7064
7065 Property Parameters: Non-standard property parameters can be
7066 specified on this property.
7067
7068 Conformance: This property can be specified in a "VALARM" calendar
7069 component.
7070
7071 Description: If the alarm triggers more than once, then this property
7072 MUST be specified along with the "DURATION" property.
7073
7074 Format Definition: The property is defined by the following notation:
7075
7076 repeatcnt = "REPEAT" repparam ":" integer CRLF
7077 ;Default is "0", zero.
7078
7079 repparam = *(";" xparam)
7080
7081 Example: The following is an example of this property for an alarm
7082 that repeats 4 additional times with a 5 minute delay after the
7083 initial triggering of the alarm:
7084
7085 REPEAT:4
7086 DURATION:PT5M
7087
7088 4.8.6.3 Trigger
7089
7090 Property Name: TRIGGER
7091
7092 Purpose: This property specifies when an alarm will trigger.
7093
7094 Value Type: The default value type is DURATION. The value type can be
7095 set to a DATE-TIME value type, in which case the value MUST specify a
7096 UTC formatted DATE-TIME value.
7097
7098 Property Parameters: Non-standard, value data type, time zone
7099 identifier or trigger relationship property parameters can be
7100 specified on this property. The trigger relationship property
7101 parameter MUST only be specified when the value type is DURATION.
7102
7103 Conformance: This property MUST be specified in the "VALARM" calendar
7104 component.
7105
7106 Description: Within the "VALARM" calendar component, this property
7107 defines when the alarm will trigger. The default value type is
7108 DURATION, specifying a relative time for the trigger of the alarm.
7109 The default duration is relative to the start of an event or to-do
7110 that the alarm is associated with. The duration can be explicitly set
7111
7112
7113
7114 Dawson & Stenerson Standards Track [Page 127]
7115
7116 RFC 2445 iCalendar November 1998
7117
7118
7119 to trigger from either the end or the start of the associated event
7120 or to-do with the "RELATED" parameter. A value of START will set the
7121 alarm to trigger off the start of the associated event or to-do. A
7122 value of END will set the alarm to trigger off the end of the
7123 associated event or to-do.
7124
7125 Either a positive or negative duration may be specified for the
7126 "TRIGGER" property. An alarm with a positive duration is triggered
7127 after the associated start or end of the event or to-do. An alarm
7128 with a negative duration is triggered before the associated start or
7129 end of the event or to-do.
7130
7131 The "RELATED" property parameter is not valid if the value type of
7132 the property is set to DATE-TIME (i.e., for an absolute date and time
7133 alarm trigger). If a value type of DATE-TIME is specified, then the
7134 property value MUST be specified in the UTC time format. If an
7135 absolute trigger is specified on an alarm for a recurring event or
7136 to-do, then the alarm will only trigger for the specified absolute
7137 date/time, along with any specified repeating instances.
7138
7139 If the trigger is set relative to START, then the "DTSTART" property
7140 MUST be present in the associated "VEVENT" or "VTODO" calendar
7141 component. If an alarm is specified for an event with the trigger set
7142 relative to the END, then the "DTEND" property or the "DSTART" and
7143 "DURATION' properties MUST be present in the associated "VEVENT"
7144 calendar component. If the alarm is specified for a to-do with a
7145 trigger set relative to the END, then either the "DUE" property or
7146 the "DSTART" and "DURATION' properties MUST be present in the
7147 associated "VTODO" calendar component.
7148
7149 Alarms specified in an event or to-do which is defined in terms of a
7150 DATE value type will be triggered relative to 00:00:00 UTC on the
7151 specified date. For example, if "DTSTART:19980205, then the duration
7152 trigger will be relative to19980205T000000Z.
7153
7154 Format Definition: The property is defined by the following notation:
7155
7156 trigger = "TRIGGER" (trigrel / trigabs)
7157
7158 trigrel = *(
7159
7160 ; the following are optional,
7161 ; but MUST NOT occur more than once
7162
7163 (";" "VALUE" "=" "DURATION") /
7164 (";" trigrelparam) /
7165
7166 ; the following is optional,
7167
7168
7169
7170 Dawson & Stenerson Standards Track [Page 128]
7171
7172 RFC 2445 iCalendar November 1998
7173
7174
7175 ; and MAY occur more than once
7176
7177 (";" xparam)
7178 ) ":" dur-value
7179
7180 trigabs = 1*(
7181
7182 ; the following is REQUIRED,
7183 ; but MUST NOT occur more than once
7184
7185 (";" "VALUE" "=" "DATE-TIME") /
7186
7187 ; the following is optional,
7188 ; and MAY occur more than once
7189
7190 (";" xparam)
7191
7192 ) ":" date-time
7193
7194 Example: A trigger set 15 minutes prior to the start of the event or
7195 to-do.
7196
7197 TRIGGER:-P15M
7198
7199 A trigger set 5 minutes after the end of the event or to-do.
7200
7201 TRIGGER;RELATED=END:P5M
7202
7203 A trigger set to an absolute date/time.
7204
7205 TRIGGER;VALUE=DATE-TIME:19980101T050000Z
7206
7207 4.8.7 Change Management Component Properties
7208
7209 The following properties specify change management information in
7210 calendar components.
7211
7212 4.8.7.1 Date/Time Created
7213
7214 Property Name: CREATED
7215
7216 Purpose: This property specifies the date and time that the calendar
7217 information was created by the calendar user agent in the calendar
7218 store.
7219
7220 Note: This is analogous to the creation date and time for a file
7221 in the file system.
7222
7223
7224
7225
7226 Dawson & Stenerson Standards Track [Page 129]
7227
7228 RFC 2445 iCalendar November 1998
7229
7230
7231 Value Type: DATE-TIME
7232
7233 Property Parameters: Non-standard property parameters can be
7234 specified on this property.
7235
7236 Conformance: The property can be specified once in "VEVENT", "VTODO"
7237 or "VJOURNAL" calendar components.
7238
7239 Description: The date and time is a UTC value.
7240
7241 Format Definition: The property is defined by the following notation:
7242
7243 created = "CREATED" creaparam ":" date-time CRLF
7244
7245 creaparam = *(";" xparam)
7246
7247 Example: The following is an example of this property:
7248
7249 CREATED:19960329T133000Z
7250
7251 4.8.7.2 Date/Time Stamp
7252
7253 Property Name: DTSTAMP
7254
7255 Purpose: The property indicates the date/time that the instance of
7256 the iCalendar object was created.
7257
7258 Value Type: DATE-TIME
7259
7260 Property Parameters: Non-standard property parameters can be
7261 specified on this property.
7262
7263 Conformance: This property MUST be included in the "VEVENT", "VTODO",
7264 "VJOURNAL" or "VFREEBUSY" calendar components.
7265
7266 Description: The value MUST be specified in the UTC time format.
7267
7268 This property is also useful to protocols such as [IMIP] that have
7269 inherent latency issues with the delivery of content. This property
7270 will assist in the proper sequencing of messages containing iCalendar
7271 objects.
7272
7273 This property is different than the "CREATED" and "LAST-MODIFIED"
7274 properties. These two properties are used to specify when the
7275 particular calendar data in the calendar store was created and last
7276 modified. This is different than when the iCalendar object
7277 representation of the calendar service information was created or
7278 last modified.
7279
7280
7281
7282 Dawson & Stenerson Standards Track [Page 130]
7283
7284 RFC 2445 iCalendar November 1998
7285
7286
7287 Format Definition: The property is defined by the following notation:
7288
7289 dtstamp = "DTSTAMP" stmparam ":" date-time CRLF
7290
7291 stmparam = *(";" xparam)
7292
7293 Example:
7294
7295 DTSTAMP:19971210T080000Z
7296
7297 4.8.7.3 Last Modified
7298
7299 Property Name: LAST-MODIFIED
7300
7301 Purpose: The property specifies the date and time that the
7302 information associated with the calendar component was last revised
7303 in the calendar store.
7304
7305 Note: This is analogous to the modification date and time for a
7306 file in the file system.
7307
7308 Value Type: DATE-TIME
7309
7310 Property Parameters: Non-standard property parameters can be
7311 specified on this property.
7312
7313 Conformance: This property can be specified in the "EVENT", "VTODO",
7314 "VJOURNAL" or "VTIMEZONE" calendar components.
7315
7316 Description: The property value MUST be specified in the UTC time
7317 format.
7318
7319 Format Definition: The property is defined by the following notation:
7320
7321 last-mod = "LAST-MODIFIED" lstparam ":" date-time CRLF
7322
7323 lstparam = *(";" xparam)
7324
7325 Example: The following is are examples of this property:
7326
7327 LAST-MODIFIED:19960817T133000Z
7328
7329 4.8.7.4 Sequence Number
7330
7331 Property Name: SEQUENCE
7332
7333 Purpose: This property defines the revision sequence number of the
7334 calendar component within a sequence of revisions.
7335
7336
7337
7338 Dawson & Stenerson Standards Track [Page 131]
7339
7340 RFC 2445 iCalendar November 1998
7341
7342
7343 Value Type: integer
7344
7345 Property Parameters: Non-standard property parameters can be
7346 specified on this property.
7347
7348 Conformance: The property can be specified in "VEVENT", "VTODO" or
7349 "VJOURNAL" calendar component.
7350
7351 Description: When a calendar component is created, its sequence
7352 number is zero (US-ASCII decimal 48). It is monotonically incremented
7353 by the "Organizer's" CUA each time the "Organizer" makes a
7354 significant revision to the calendar component. When the "Organizer"
7355 makes changes to one of the following properties, the sequence number
7356 MUST be incremented:
7357
7358 . "DTSTART"
7359
7360 . "DTEND"
7361
7362 . "DUE"
7363
7364 . "RDATE"
7365
7366 . "RRULE"
7367
7368 . "EXDATE"
7369
7370 . "EXRULE"
7371
7372 . "STATUS"
7373
7374 In addition, changes made by the "Organizer" to other properties can
7375 also force the sequence number to be incremented. The "Organizer" CUA
7376 MUST increment the sequence number when ever it makes changes to
7377 properties in the calendar component that the "Organizer" deems will
7378 jeopardize the validity of the participation status of the
7379 "Attendees". For example, changing the location of a meeting from one
7380 locale to another distant locale could effectively impact the
7381 participation status of the "Attendees".
7382
7383 The "Organizer" includes this property in an iCalendar object that it
7384 sends to an "Attendee" to specify the current version of the calendar
7385 component.
7386
7387 The "Attendee" includes this property in an iCalendar object that it
7388 sends to the "Organizer" to specify the version of the calendar
7389 component that the "Attendee" is referring to.
7390
7391
7392
7393
7394 Dawson & Stenerson Standards Track [Page 132]
7395
7396 RFC 2445 iCalendar November 1998
7397
7398
7399 A change to the sequence number is not the mechanism that an
7400 "Organizer" uses to request a response from the "Attendees". The
7401 "RSVP" parameter on the "ATTENDEE" property is used by the
7402 "Organizer" to indicate that a response from the "Attendees" is
7403 requested.
7404
7405 Format Definition: This property is defined by the following
7406 notation:
7407
7408 seq = "SEQUENCE" seqparam ":" integer CRLF
7409 ; Default is "0"
7410
7411 seqparam = *(";" xparam)
7412
7413 Example: The following is an example of this property for a calendar
7414 component that was just created by the "Organizer".
7415
7416 SEQUENCE:0
7417
7418 The following is an example of this property for a calendar component
7419 that has been revised two different times by the "Organizer".
7420
7421 SEQUENCE:2
7422
7423 4.8.8 Miscellaneous Component Properties
7424
7425 The following properties specify information about a number of
7426 miscellaneous features of calendar components.
7427
7428 4.8.8.1 Non-standard Properties
7429
7430 Property Name: Any property name with a "X-" prefix
7431
7432 Purpose: This class of property provides a framework for defining
7433 non-standard properties.
7434
7435 Value Type: TEXT
7436
7437 Property Parameters: Non-standard and language property parameters
7438 can be specified on this property.
7439
7440 Conformance: This property can be specified in any calendar
7441 component.
7442
7443 Description: The MIME Calendaring and Scheduling Content Type
7444 provides a "standard mechanism for doing non-standard things". This
7445 extension support is provided for implementers to "push the envelope"
7446 on the existing version of the memo. Extension properties are
7447
7448
7449
7450 Dawson & Stenerson Standards Track [Page 133]
7451
7452 RFC 2445 iCalendar November 1998
7453
7454
7455 specified by property and/or property parameter names that have the
7456 prefix text of "X-" (the two character sequence: LATIN CAPITAL LETTER
7457 X character followed by the HYPEN-MINUS character). It is recommended
7458 that vendors concatenate onto this sentinel another short prefix text
7459 to identify the vendor. This will facilitate readability of the
7460 extensions and minimize possible collision of names between different
7461 vendors. User agents that support this content type are expected to
7462 be able to parse the extension properties and property parameters but
7463 can ignore them.
7464
7465 At present, there is no registration authority for names of extension
7466 properties and property parameters. The data type for this property
7467 is TEXT. Optionally, the data type can be any of the other valid data
7468 types.
7469
7470 Format Definition: The property is defined by the following notation:
7471
7472 x-prop = x-name *(";" xparam) [";" languageparam] ":" text CRLF
7473 ; Lines longer than 75 octets should be folded
7474
7475 Example: The following might be the ABC vendor's extension for an
7476 audio-clip form of subject property:
7477
7478 X-ABC-MMSUBJ;X-ABC-MMSUBJTYPE=wave:http://load.noise.org/mysubj.wav
7479
7480 4.8.8.2 Request Status
7481
7482 Property Name: REQUEST-STATUS
7483
7484 Purpose: This property defines the status code returned for a
7485 scheduling request.
7486
7487 Value Type: TEXT
7488
7489 Property Parameters: Non-standard and language property parameters
7490 can be specified on this property.
7491
7492 Conformance: The property can be specified in "VEVENT", "VTODO",
7493 "VJOURNAL" or "VFREEBUSY" calendar component.
7494
7495 Description: This property is used to return status code information
7496 related to the processing of an associated iCalendar object. The data
7497 type for this property is TEXT.
7498
7499 The value consists of a short return status component, a longer
7500 return status description component, and optionally a status-specific
7501 data component. The components of the value are separated by the
7502 SEMICOLON character (US-ASCII decimal 59).
7503
7504
7505
7506 Dawson & Stenerson Standards Track [Page 134]
7507
7508 RFC 2445 iCalendar November 1998
7509
7510
7511 The short return status is a PERIOD character (US-ASCII decimal 46)
7512 separated 3-tuple of integers. For example, "3.1.1". The successive
7513 levels of integers provide for a successive level of status code
7514 granularity.
7515
7516 The following are initial classes for the return status code.
7517 Individual iCalendar object methods will define specific return
7518 status codes for these classes. In addition, other classes for the
7519 return status code may be defined using the registration process
7520 defined later in this memo.
7521
7522 |==============+===============================================|
7523 | Short Return | Longer Return Status Description |
7524 | Status Code | |
7525 |==============+===============================================|
7526 | 1.xx | Preliminary success. This class of status |
7527 | | of status code indicates that the request has |
7528 | | request has been initially processed but that |
7529 | | completion is pending. |
7530 |==============+===============================================|
7531 | 2.xx | Successful. This class of status code |
7532 | | indicates that the request was completed |
7533 | | successfuly. However, the exact status code |
7534 | | can indicate that a fallback has been taken. |
7535 |==============+===============================================|
7536 | 3.xx | Client Error. This class of status code |
7537 | | indicates that the request was not successful.|
7538 | | The error is the result of either a syntax or |
7539 | | a semantic error in the client formatted |
7540 | | request. Request should not be retried until |
7541 | | the condition in the request is corrected. |
7542 |==============+===============================================|
7543 | 4.xx | Scheduling Error. This class of status code |
7544 | | indicates that the request was not successful.|
7545 | | Some sort of error occurred within the |
7546 | | calendaring and scheduling service, not |
7547 | | directly related to the request itself. |
7548 |==============+===============================================|
7549
7550 Format Definition: The property is defined by the following notation:
7551
7552 rstatus = "REQUEST-STATUS" rstatparam ":"
7553 statcode ";" statdesc [";" extdata]
7554
7555 rstatparam = *(
7556
7557 ; the following is optional,
7558 ; but MUST NOT occur more than once
7559
7560
7561
7562 Dawson & Stenerson Standards Track [Page 135]
7563
7564 RFC 2445 iCalendar November 1998
7565
7566
7567 (";" languageparm) /
7568
7569 ; the following is optional,
7570 ; and MAY occur more than once
7571
7572 (";" xparam)
7573
7574 )
7575
7576 statcode = 1*DIGIT *("." 1*DIGIT)
7577 ;Hierarchical, numeric return status code
7578
7579 statdesc = text
7580 ;Textual status description
7581
7582 extdata = text
7583 ;Textual exception data. For example, the offending property
7584 ;name and value or complete property line.
7585
7586 Example: The following are some possible examples of this property.
7587 The COMMA and SEMICOLON separator characters in the property value
7588 are BACKSLASH character escaped because they appear in a text value.
7589
7590 REQUEST-STATUS:2.0;Success
7591
7592 REQUEST-STATUS:3.1;Invalid property value;DTSTART:96-Apr-01
7593
7594 REQUEST-STATUS:2.8; Success\, repeating event ignored. Scheduled
7595 as a single event.;RRULE:FREQ=WEEKLY\;INTERVAL=2
7596
7597 REQUEST-STATUS:4.1;Event conflict. Date/time is busy.
7598
7599 REQUEST-STATUS:3.7;Invalid calendar user;ATTENDEE:
7600 MAILTO:jsmith@host.com
7601
7602 5 iCalendar Object Examples
7603
7604 The following examples are provided as an informational source of
7605 illustrative iCalendar objects consistent with this content type.
7606
7607 The following example specifies a three-day conference that begins at
7608 8:00 AM EDT, September 18, 1996 and end at 6:00 PM EDT, September 20,
7609 1996.
7610
7611 BEGIN:VCALENDAR PRODID:-//xyz Corp//NONSGML PDA Calendar Verson
7612 1.0//EN VERSION:2.0 BEGIN:VEVENT DTSTAMP:19960704T120000Z
7613 UID:uid1@host.com ORGANIZER:MAILTO:jsmith@host.com
7614 DTSTART:19960918T143000Z DTEND:19960920T220000Z STATUS:CONFIRMED
7615
7616
7617
7618 Dawson & Stenerson Standards Track [Page 136]
7619
7620 RFC 2445 iCalendar November 1998
7621
7622
7623 CATEGORIES:CONFERENCE SUMMARY:Networld+Interop Conference
7624 DESCRIPTION:Networld+Interop Conference
7625 and Exhibit\nAtlanta World Congress Center\n
7626 Atlanta, Georgia END:VEVENT END:VCALENDAR
7627
7628 The following example specifies a group scheduled meeting that begin
7629 at 8:30 AM EST on March 12, 1998 and end at 9:30 AM EST on March 12,
7630 1998. The "Organizer" has scheduled the meeting with one or more
7631 calendar users in a group. A time zone specification for Eastern
7632 United States has been specified.
7633
7634 BEGIN:VCALENDAR
7635 PRODID:-//RDU Software//NONSGML HandCal//EN
7636 VERSION:2.0
7637 BEGIN:VTIMEZONE
7638 TZID:US-Eastern
7639 BEGIN:STANDARD
7640 DTSTART:19981025T020000
7641 RDATE:19981025T020000
7642 TZOFFSETFROM:-0400
7643 TZOFFSETTO:-0500
7644 TZNAME:EST
7645 END:STANDARD
7646 BEGIN:DAYLIGHT
7647 DTSTART:19990404T020000
7648 RDATE:19990404T020000
7649 TZOFFSETFROM:-0500
7650 TZOFFSETTO:-0400
7651 TZNAME:EDT
7652 END:DAYLIGHT
7653 END:VTIMEZONE
7654 BEGIN:VEVENT
7655 DTSTAMP:19980309T231000Z
7656 UID:guid-1.host1.com
7657 ORGANIZER;ROLE=CHAIR:MAILTO:mrbig@host.com
7658 ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;CUTYPE=GROUP:
7659 MAILTO:employee-A@host.com
7660 DESCRIPTION:Project XYZ Review Meeting
7661 CATEGORIES:MEETING
7662 CLASS:PUBLIC
7663 CREATED:19980309T130000Z
7664 SUMMARY:XYZ Project Review
7665 DTSTART;TZID=US-Eastern:19980312T083000
7666 DTEND;TZID=US-Eastern:19980312T093000
7667 LOCATION:1CP Conference Room 4350
7668 END:VEVENT
7669 END:VCALENDAR
7670
7671
7672
7673
7674 Dawson & Stenerson Standards Track [Page 137]
7675
7676 RFC 2445 iCalendar November 1998
7677
7678
7679 The following is an example of an iCalendar object passed in a MIME
7680 message with a single body part consisting of a "text/calendar"
7681 Content Type.
7682
7683 TO:jsmith@host1.com
7684 FROM:jdoe@host1.com
7685 MIME-VERSION:1.0
7686 MESSAGE-ID:<id3@host1.com>
7687 CONTENT-TYPE:text/calendar
7688
7689 BEGIN:VCALENDAR
7690 METHOD:xyz
7691 VERSION:2.0
7692 PRODID:-//ABC Corporation//NONSGML My Product//EN
7693 BEGIN:VEVENT
7694 DTSTAMP:19970324T1200Z
7695 SEQUENCE:0
7696 UID:uid3@host1.com
7697 ORGANIZER:MAILTO:jdoe@host1.com
7698 ATTENDEE;RSVP=TRUE:MAILTO:jsmith@host1.com
7699 DTSTART:19970324T123000Z
7700 DTEND:19970324T210000Z
7701 CATEGORIES:MEETING,PROJECT
7702 CLASS:PUBLIC
7703 SUMMARY:Calendaring Interoperability Planning Meeting
7704 DESCRIPTION:Discuss how we can test c&s interoperability\n
7705 using iCalendar and other IETF standards.
7706 LOCATION:LDB Lobby
7707 ATTACH;FMTTYPE=application/postscript:ftp://xyzCorp.com/pub/
7708 conf/bkgrnd.ps
7709 END:VEVENT
7710 END:VCALENDAR
7711
7712 The following is an example of a to-do due on April 15, 1998. An
7713 audio alarm has been specified to remind the calendar user at noon,
7714 the day before the to-do is expected to be completed and repeat
7715 hourly, four additional times. The to-do definition has been modified
7716 twice since it was initially created.
7717
7718 BEGIN:VCALENDAR
7719 VERSION:2.0
7720 PRODID:-//ABC Corporation//NONSGML My Product//EN
7721 BEGIN:VTODO
7722 DTSTAMP:19980130T134500Z
7723 SEQUENCE:2
7724 UID:uid4@host1.com
7725 ORGANIZER:MAILTO:unclesam@us.gov
7726 ATTENDEE;PARTSTAT=ACCEPTED:MAILTO:jqpublic@host.com
7727
7728
7729
7730 Dawson & Stenerson Standards Track [Page 138]
7731
7732 RFC 2445 iCalendar November 1998
7733
7734
7735 DUE:19980415T235959
7736 STATUS:NEEDS-ACTION
7737 SUMMARY:Submit Income Taxes
7738 BEGIN:VALARM
7739 ACTION:AUDIO
7740 TRIGGER:19980403T120000
7741 ATTACH;FMTTYPE=audio/basic:http://host.com/pub/audio-
7742 files/ssbanner.aud
7743 REPEAT:4
7744 DURATION:PT1H
7745 END:VALARM
7746 END:VTODO
7747 END:VCALENDAR
7748
7749 The following is an example of a journal entry.
7750
7751 BEGIN:VCALENDAR
7752 VERSION:2.0
7753 PRODID:-//ABC Corporation//NONSGML My Product//EN
7754 BEGIN:VJOURNAL
7755 DTSTAMP:19970324T120000Z
7756 UID:uid5@host1.com
7757 ORGANIZER:MAILTO:jsmith@host.com
7758 STATUS:DRAFT
7759 CLASS:PUBLIC
7760 CATEGORY:Project Report, XYZ, Weekly Meeting
7761 DESCRIPTION:Project xyz Review Meeting Minutes\n
7762 Agenda\n1. Review of project version 1.0 requirements.\n2.
7763 Definition
7764 of project processes.\n3. Review of project schedule.\n
7765 Participants: John Smith, Jane Doe, Jim Dandy\n-It was
7766 decided that the requirements need to be signed off by
7767 product marketing.\n-Project processes were accepted.\n
7768 -Project schedule needs to account for scheduled holidays
7769 and employee vacation time. Check with HR for specific
7770 dates.\n-New schedule will be distributed by Friday.\n-
7771 Next weeks meeting is cancelled. No meeting until 3/23.
7772 END:VJOURNAL
7773 END:VCALENDAR
7774
7775 The following is an example of published busy time information. The
7776 iCalendar object might be placed in the network resource
7777 www.host.com/calendar/busytime/jsmith.ifb.
7778
7779 BEGIN:VCALENDAR
7780 VERSION:2.0
7781 PRODID:-//RDU Software//NONSGML HandCal//EN
7782 BEGIN:VFREEBUSY
7783
7784
7785
7786 Dawson & Stenerson Standards Track [Page 139]
7787
7788 RFC 2445 iCalendar November 1998
7789
7790
7791 ORGANIZER:MAILTO:jsmith@host.com
7792 DTSTART:19980313T141711Z
7793 DTEND:19980410T141711Z
7794 FREEBUSY:19980314T233000Z/19980315T003000Z
7795 FREEBUSY:19980316T153000Z/19980316T163000Z
7796 FREEBUSY:19980318T030000Z/19980318T040000Z
7797 URL:http://www.host.com/calendar/busytime/jsmith.ifb
7798 END:VFREEBUSY
7799 END:VCALENDAR
7800
7801 6 Recommended Practices
7802
7803 These recommended practices should be followed in order to assure
7804 consistent handling of the following cases for an iCalendar object.
7805
7806 1. Content lines longer than 75 octets SHOULD be folded.
7807
7808 2. A calendar entry with a "DTSTART" property but no "DTEND"
7809 property does not take up any time. It is intended to represent
7810 an event that is associated with a given calendar date and time
7811 of day, such as an anniversary. Since the event does not take up
7812 any time, it MUST NOT be used to record busy time no matter what
7813 the value for the "TRANSP" property.
7814
7815 3. When the "DTSTART" and "DTEND", for "VEVENT", "VJOURNAL" and
7816 "VFREEBUSY" calendar components, and "DTSTART" and "DUE", for
7817 "VTODO" calendar components, have the same value data type (e.g.,
7818 DATE-TIME), they SHOULD specify values in the same time format
7819 (e.g., UTC time format).
7820
7821 4. When the combination of the "RRULE" and "RDATE" properties on an
7822 iCalendar object produces multiple instances having the same
7823 start date/time, they should be collapsed to, and considered as,
7824 a single instance.
7825
7826 5. When a calendar user receives multiple requests for the same
7827 calendar component (e.g., REQUEST for a "VEVENT" calendar
7828 component) as a result of being on multiple mailing lists
7829 specified by "ATTENDEE" properties in the request, they SHOULD
7830 respond to only one of the requests. The calendar user SHOULD
7831 also specify (using the "MEMBER" parameter of the "ATTENDEE"
7832 property) which mailing list they are a member of.
7833
7834 6. An implementation can truncate a "SUMMARY" property value to 255
7835 characters.
7836
7837
7838
7839
7840
7841
7842 Dawson & Stenerson Standards Track [Page 140]
7843
7844 RFC 2445 iCalendar November 1998
7845
7846
7847 7. If seconds of the minute are not supported by an implementation,
7848 then a value of "00" SHOULD be specified for the seconds
7849 component in a time value.
7850
7851 8. If the value type parameter (VALUE=) contains an unknown value
7852 type, it SHOULD be treated as TEXT.
7853
7854 9. TZURL values SHOULD NOT be specified as a FILE URI type. This URI
7855 form can be useful within an organization, but is problematic in
7856 the Internet.
7857
7858 10. Some possible English values for CATEGORIES property include
7859 "ANNIVERSARY", "APPOINTMENT", "BUSINESS", "EDUCATION",
7860 "HOLIDAY", "MEETING", "MISCELLANEOUS", "NON-WORKING HOURS", "NOT
7861 IN OFFICE", "PERSONAL", "PHONE CALL", "SICK DAY", "SPECIAL
7862 OCCASION", "TRAVEL", "VACATION". Categories can be specified in
7863 any registered language.
7864
7865 11. Some possible English values for RESOURCES property include
7866 "CATERING", "CHAIRS", "COMPUTER PROJECTOR", "EASEL", "OVERHEAD
7867 PROJECTOR", "SPEAKER PHONE", "TABLE", "TV", "VCR", "VIDEO
7868 PHONE", "VEHICLE". Resources can be specified in any registered
7869 language.
7870
7871 7 Registration of Content Type Elements
7872
7873 This section provides the process for registration of MIME
7874 Calendaring and Scheduling Content Type iCalendar object methods and
7875 new or modified properties.
7876
7877 7.1 Registration of New and Modified iCalendar Object Methods
7878
7879 New MIME Calendaring and Scheduling Content Type iCalendar object
7880 methods are registered by the publication of an IETF Request for
7881 Comments (RFC). Changes to an iCalendar object method are registered
7882 by the publication of a revision of the RFC defining the method.
7883
7884 7.2 Registration of New Properties
7885
7886 This section defines procedures by which new properties or enumerated
7887 property values for the MIME Calendaring and Scheduling Content Type
7888 can be registered with the IANA. Non-IANA properties can be used by
7889 bilateral agreement, provided the associated properties names follow
7890 the "X-" convention.
7891
7892 The procedures defined here are designed to allow public comment and
7893 review of new properties, while posing only a small impediment to the
7894 definition of new properties.
7895
7896
7897
7898 Dawson & Stenerson Standards Track [Page 141]
7899
7900 RFC 2445 iCalendar November 1998
7901
7902
7903 Registration of a new property is accomplished by the following
7904 steps.
7905
7906 7.2.1 Define the property
7907
7908 A property is defined by completing the following template.
7909
7910 To: ietf-calendar@imc.org
7911
7912 Subject: Registration of text/calendar MIME property XXX
7913
7914 Property name:
7915
7916 Property purpose:
7917
7918 Property value type(s):
7919
7920 Property parameter (s):
7921
7922 Conformance:
7923
7924 Description:
7925
7926 Format definition:
7927
7928 Examples:
7929
7930 The meaning of each field in the template is as follows.
7931
7932 Property name: The name of the property, as it will appear in the
7933 body of an text/calendar MIME Content-Type "property: value" line to
7934 the left of the colon ":".
7935
7936 Property purpose: The purpose of the property (e.g., to indicate a
7937 delegate for the event or to-do, etc.). Give a short but clear
7938 description.
7939
7940 Property value type (s): Any of the valid value types for the
7941 property value needs to be specified. The default value type also
7942 needs to be specified. If a new value type is specified, it needs to
7943 be declared in this section.
7944
7945 Property parameter (s): Any of the valid property parameters for the
7946 property needs to be specified.
7947
7948 Conformance: The calendar components that the property can appear in
7949 needs to be specified.
7950
7951
7952
7953
7954 Dawson & Stenerson Standards Track [Page 142]
7955
7956 RFC 2445 iCalendar November 1998
7957
7958
7959 Description: Any special notes about the property, how it is to be
7960 used, etc.
7961
7962 Format definition: The ABNF for the property definition needs to be
7963 specified.
7964
7965 Examples: One or more examples of instances of the property needs to
7966 be specified.
7967
7968 7.2.2 Post the Property definition
7969
7970 The property description MUST be posted to the new property
7971 discussion list, ietf-calendar@imc.org.
7972
7973 7.2.3 Allow a comment period
7974
7975 Discussion on the new property MUST be allowed to take place on the
7976 list for a minimum of two weeks. Consensus MUST be reached on the
7977 property before proceeding to the next step.
7978
7979 7.2.4 Submit the property for approval
7980
7981 Once the two-week comment period has elapsed, and the proposer is
7982 convinced consensus has been reached on the property, the
7983 registration application should be submitted to the Method Reviewer
7984 for approval. The Method Reviewer is appointed to the Application
7985 Area Directors and can either accept or reject the property
7986 registration. An accepted registration should be passed on by the
7987 Method Reviewer to the IANA for inclusion in the official IANA method
7988 registry. The registration can be rejected for any of the following
7989 reasons. 1) Insufficient comment period; 2) Consensus not reached; 3)
7990 Technical deficiencies raised on the list or elsewhere have not been
7991 addressed. The Method Reviewer's decision to reject a property can be
7992 appealed by the proposer to the IESG, or the objections raised can be
7993 addressed by the proposer and the property resubmitted.
7994
7995 7.3 Property Change Control
7996
7997 Existing properties can be changed using the same process by which
7998 they were registered.
7999
8000 1. Define the change
8001
8002 2. Post the change
8003
8004 3. Allow a comment period
8005
8006 4. Submit the property for approval
8007
8008
8009
8010 Dawson & Stenerson Standards Track [Page 143]
8011
8012 RFC 2445 iCalendar November 1998
8013
8014
8015 Note that the original author or any other interested party can
8016 propose a change to an existing property, but that such changes
8017 should only be proposed when there are serious omissions or errors in
8018 the published memo. The Method Reviewer can object to a change if it
8019 is not backward compatible, but is not required to do so.
8020
8021 Property definitions can never be deleted from the IANA registry, but
8022 properties which are no longer believed to be useful can be declared
8023 OBSOLETE by a change to their "intended use" field.
8024
8025 8 References
8026
8027 [IMIP] Dawson, F., Mansour, S. and S. Silverberg, "iCalendar
8028 Message-based Interoperability Protocol (IMIP)", RFC 2447,
8029 November 1998.
8030
8031 [ITIP] Silverberg, S., Mansour, S., Dawson, F. and R. Hopson,
8032 "iCalendar Transport-Independent Interoperability Protocol
8033 (iTIP) : Scheduling Events, Busy Time, To-dos and Journal
8034 Entries", RFC 2446, November 1998.
8035
8036 [ISO 8601] ISO 8601, "Data elements and interchange formats-
8037 Information interchange--Representation of dates and
8038 times", International Organization for Standardization,
8039 June, 1988.
8040
8041 [ISO 9070] ISO/IEC 9070, "Information Technology_SGML Support
8042 Facilities--Registration Procedures for Public Text Owner
8043 Identifiers", Second Edition, International Organization
8044 for Standardization, April 1991.
8045
8046 [RFC 822] Crocker, D., "Standard for the Format of ARPA Internet
8047 Text Messages", STD 11, RFC 822, August 1982.
8048
8049 [RFC 1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform
8050 Resource Locators (URL)", RFC 1738, December 1994.
8051
8052 [RFC 1766] Alvestrand, H., "Tags for the Identification of
8053 Languages", RFC 1766, March 1995.
8054
8055 [RFC 2045] Freed, N. and N. Borenstein, " Multipurpose Internet Mail
8056 Extensions (MIME) - Part One: Format of Internet Message
8057 Bodies", RFC 2045, November 1996.
8058
8059 [RFC 2046] Freed, N. and N. Borenstein, " Multipurpose Internet Mail
8060 Extensions (MIME) - Part Two: Media Types", RFC 2046,
8061 November 1996.
8062
8063
8064
8065
8066 Dawson & Stenerson Standards Track [Page 144]
8067
8068 RFC 2445 iCalendar November 1998
8069
8070
8071 [RFC 2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose
8072 Internet Mail Extensions (MIME) - Part Four: Registration
8073 Procedures", RFC 2048, January 1997.
8074
8075 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
8076 Requirement Levels", BCP 14, RFC 2119, March 1997.
8077
8078 [RFC 2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
8079 Specifications: ABNF", RFC 2234, November 1997.
8080
8081 [RFC 2279] Yergeau, F., "UTF-8, a transformation format of ISO
8082 10646", RFC 2279, January 1998.
8083
8084 [RFC 2425] Howes, T., Smith, M. and F. Dawson, "A MIME Content-Type
8085 for Directory Information", RFC 2425, September 1998.
8086
8087 [RFC 2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile",
8088 RFC 2426, September 1998.
8089
8090 [TZ] Olson, A.D., et al, Time zone code and data,
8091 ftp://elsie.nci.nih.gov/pub/, updated periodically.
8092
8093 [VCAL] Internet Mail Consortium, "vCalendar - The Electronic
8094 Calendaring and Scheduling Exchange Format",
8095 http://www.imc.org/pdi/vcal-10.txt, September 18, 1996.
8096
8097 9 Acknowledgments
8098
8099 A hearty thanks to the IETF Calendaring and Scheduling Working Group
8100 and also the following individuals who have participated in the
8101 drafting, review and discussion of this memo:
8102
8103 Roland Alden, Harald T. Alvestrand, Eric Berman, Denis Bigorgne, John
8104 Binici, Bill Bliss, Philippe Boucher, Steve Carter, Andre
8105 Courtemanche, Dave Crocker, David Curley, Alec Dun, John Evans, Ross
8106 Finlayson, Randell Flint, Ned Freed, Patrik Faltstrom, Chuck
8107 Grandgent, Mark Handley, Steve Hanna, Paul B. Hill, Paul Hoffman,
8108 Ross Hopson, Mark Horton, Daryl Huff, Bruce Kahn, C. Harald Koch,
8109 Ryan Jansen, Don Lavange, Antoine Leca, Theodore Lorek, Steve
8110 Mansour, Skip Montanaro, Keith Moore, Cecil Murray, Chris Newman,
8111 John Noerenberg, Ralph Patterson, Pete Resnick, Keith Rhodes, Robert
8112 Ripberger, John Rose, Doug Royer, Andras Salamar, Ted Schuh, Vinod
8113 Seraphin, Derrick Shadel, Ken Shan, Andrew Shuman, Steve Silverberg,
8114 William P. Spencer, John Sun, Mark Towfiq, Yvonne Tso, Robert Visnov,
8115 James L. Weiner, Mike Weston, William Wyatt.
8116
8117
8118
8119
8120
8121
8122 Dawson & Stenerson Standards Track [Page 145]
8123
8124 RFC 2445 iCalendar November 1998
8125
8126
8127 10 Authors' and Chairs' Addresses
8128
8129 The following address information is provided in a MIME-VCARD,
8130 Electronic Business Card, format.
8131
8132 The authors of this memo are:
8133
8134 BEGIN:VCARD
8135 VERSION:3.0
8136 N:Dawson;Frank
8137 FN:Frank Dawson
8138 ORG:Lotus Development Corporation
8139 ADR;TYPE=WORK,POSTAL,PARCEL:;;6544 Battleford Drive;
8140 Raleigh;NC;27613-3502;USA
8141 TEL;TYPE=WORK,MSG:+1-919-676-9515
8142 TEL;TYPE=WORK,FAX:+1-919-676-9564
8143 EMAIL;TYPE=PREF,INTERNET:Frank_Dawson@Lotus.com
8144 EMAIL;TYPE=INTERNET:fdawson@earthlink.net
8145 URL:http://home.earthlink.net/~fdawson
8146 END:VCARD
8147
8148 BEGIN:VCARD
8149 VERSION:3.0
8150 N:Stenerson;Derik
8151 FN:Derik Stenerson
8152 ORG:Microsoft Corporation
8153 ADR;TYPE=WORK,POSTAL,PARCEL:;;One Microsoft Way;
8154 Redmond;WA;98052-6399;USA
8155 TEL;TYPE=WORK,MSG:+1-425-936-5522
8156 TEL;TYPE=WORK,FAX:+1-425-936-7329
8157 EMAIL;TYPE=INTERNET:deriks@Microsoft.com
8158 END:VCARD
8159
8160 The iCalendar object is a result of the work of the Internet
8161 Engineering Task Force Calendaring and Scheduling Working Group. The
8162 chairmen of that working group are:
8163
8164 BEGIN:VCARD
8165 VERSION:3.0
8166 N:Ganguly;Anik
8167 FN:Anik Ganguly
8168 ORG: Open Text Inc.
8169 ADR;TYPE=WORK,POSTAL,PARCEL:;Suite 101;38777 West Six Mile Road;
8170 Livonia;MI;48152;USA
8171 TEL;TYPE=WORK,MSG:+1-734-542-5955
8172 EMAIL;TYPE=INTERNET:ganguly@acm.org
8173 END:VCARD
8174
8175
8176
8177
8178 Dawson & Stenerson Standards Track [Page 146]
8179
8180 RFC 2445 iCalendar November 1998
8181
8182
8183 The co-chairman of that working group is:
8184
8185 BEGIN:VCARD
8186 VERSION:3.0
8187 N:Moskowitz;Robert
8188 FN:Robert Moskowitz
8189 EMAIL;TYPE=INTERNET:rgm-ietf@htt-consult.com
8190 END:VCARD
8191
8192
8193
8194
8195
8196
8197
8198
8199
8200
8201
8202
8203
8204
8205
8206
8207
8208
8209
8210
8211
8212
8213
8214
8215
8216
8217
8218
8219
8220
8221
8222
8223
8224
8225
8226
8227
8228
8229
8230
8231
8232
8233
8234 Dawson & Stenerson Standards Track [Page 147]
8235
8236 RFC 2445 iCalendar November 1998
8237
8238
8239 11. Full Copyright Statement
8240
8241 Copyright (C) The Internet Society (1998). All Rights Reserved.
8242
8243 This document and translations of it may be copied and furnished to
8244 others, and derivative works that comment on or otherwise explain it
8245 or assist in its implementation may be prepared, copied, published
8246 and distributed, in whole or in part, without restriction of any
8247 kind, provided that the above copyright notice and this paragraph are
8248 included on all such copies and derivative works. However, this
8249 document itself may not be modified in any way, such as by removing
8250 the copyright notice or references to the Internet Society or other
8251 Internet organizations, except as needed for the purpose of
8252 developing Internet standards in which case the procedures for
8253 copyrights defined in the Internet Standards process must be
8254 followed, or as required to translate it into languages other than
8255 English.
8256
8257 The limited permissions granted above are perpetual and will not be
8258 revoked by the Internet Society or its successors or assigns.
8259
8260 This document and the information contained herein is provided on an
8261 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
8262 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
8263 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
8264 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
8265 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
8266
8267
8268
8269
8270
8271
8272
8273
8274
8275
8276
8277
8278
8279
8280
8281
8282
8283
8284
8285
8286
8287
8288
8289
8290 Dawson & Stenerson Standards Track [Page 148]
8291