idnits 2.17.1
draft-ietf-calsify-rfc2445bis-03.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3978, Section 5.1 on line 16.
-- Found old boilerplate from RFC 3978, Section 5.5 on line 7135.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 7112.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 7119.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 7125.
** This document has an original RFC 3978 Section 5.4 Copyright Line,
instead of the newer IETF Trust Copyright according to RFC 4748.
** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
of the newer disclaimer which includes the IETF Trust according to RFC
4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The abstract seems to contain references ([1]), which it shouldn't.
Please replace those with straight textual mentions of the documents in
question.
-- The draft header indicates that this document obsoletes RFC2445, but the
abstract doesn't seem to mention this, which it should.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
== The document seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords -- however, there's a paragraph with
a matching beginning. Boilerplate error?
(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires).
== Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please
use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
mean).
Found 'SHOULD not' in this paragraph:
This property SHOULD not be used to alter the interpretation of an
iCalendar object beyond the semantics specified in this memo. For
example, it is not to be used to further the understanding of
non-standard properties.
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (October 23, 2006) is 6386 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
** Obsolete normative reference: RFC 2368 (Obsoleted by RFC 6068)
** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322)
** Obsolete normative reference: RFC 3066 (Obsoleted by RFC 4646, RFC 4647)
** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234)
== Outdated reference: A later version (-10) exists of
draft-ietf-calsify-2446bis-02
== Outdated reference: A later version (-11) exists of
draft-ietf-calsify-rfc2447bis-02
-- Obsolete informational reference (is this intentional?): RFC 2425
(Obsoleted by RFC 6350)
-- Obsolete informational reference (is this intentional?): RFC 2426
(Obsoleted by RFC 6350)
Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 10 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group B. Desruisseaux, Ed.
3 Internet-Draft Oracle
4 Obsoletes: 2445 (if approved) October 23, 2006
5 Expires: April 26, 2007
7 Internet Calendaring and Scheduling Core Object Specification
8 (iCalendar)
9 draft-ietf-calsify-rfc2445bis-03
11 Status of this Memo
13 By submitting this Internet-Draft, each author represents that any
14 applicable patent or other IPR claims of which he or she is aware
15 have been or will be disclosed, and any of which he or she becomes
16 aware will be disclosed, in accordance with Section 6 of BCP 79.
18 Internet-Drafts are working documents of the Internet Engineering
19 Task Force (IETF), its areas, and its working groups. Note that
20 other groups may also distribute working documents as Internet-
21 Drafts.
23 Internet-Drafts are draft documents valid for a maximum of six months
24 and may be updated, replaced, or obsoleted by other documents at any
25 time. It is inappropriate to use Internet-Drafts as reference
26 material or to cite them other than as "work in progress."
28 The list of current Internet-Drafts can be accessed at
29 http://www.ietf.org/ietf/1id-abstracts.txt.
31 The list of Internet-Draft Shadow Directories can be accessed at
32 http://www.ietf.org/shadow.html.
34 This Internet-Draft will expire on April 26, 2007.
36 Copyright Notice
38 Copyright (C) The Internet Society (2006).
40 Abstract
42 There is a clear need to provide and deploy interoperable calendaring
43 and scheduling services for the Internet. Current group scheduling
44 and Personal Information Management (PIM) products are being extended
45 for use across the Internet, today, in proprietary ways. This memo
46 has been defined to provide the definition of a common format for
47 openly exchanging calendaring and scheduling information across the
48 Internet.
50 This memo is formatted as a registration for a MIME media type .
51 However, the format in this memo is equally applicable for use
52 outside of a MIME message content type.
54 The proposed media type value is 'text/calendar'. This string would
55 label a media type containing calendaring and scheduling information
56 encoded as text characters formatted in a manner outlined below.
58 This MIME media type provides a standard content type for capturing
59 calendar event, to-do and journal entry information. It also can be
60 used to convey free/busy time information. The content type is
61 suitable as a MIME message entity that can be transferred over MIME
62 based email systems, using HTTP or some other Internet transport. In
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.
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.
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) is one such scheduling protocol.
84 Editorial Note (To be removed by RFC Editor before publication)
86 This document is a product of the Calendaring and Scheduling
87 Standards Simplification (Calsify) working group of the Internet
88 Engineering Task Force. Comments on this draft are welcomed, and
89 should be addressed to the ietf-calsify@osafoundation.org [1] mailing
90 list. The issues raised on this mailing list are being tracked at
91 the following web site:
92 http://www.ofcourseimright.com/cgi-bin/roundup/calsify.
94 Table of Contents
96 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
97 2. Basic Grammar and Conventions . . . . . . . . . . . . . . . . 6
98 2.1. Formatting Conventions . . . . . . . . . . . . . . . . . 7
99 2.2. Related Memos . . . . . . . . . . . . . . . . . . . . . . 8
100 2.3. International Considerations . . . . . . . . . . . . . . 8
101 3. iCalendar Object Specification . . . . . . . . . . . . . . . 9
102 3.1. Content Lines . . . . . . . . . . . . . . . . . . . . . . 9
103 3.1.1. List and Field Separators . . . . . . . . . . . . . . 12
104 3.1.2. Multiple Values . . . . . . . . . . . . . . . . . . . 12
105 3.1.3. Binary Content . . . . . . . . . . . . . . . . . . . 12
106 3.1.4. Character Set . . . . . . . . . . . . . . . . . . . . 13
107 3.2. Property Parameters . . . . . . . . . . . . . . . . . . . 13
108 3.2.1. Alternate Text Representation . . . . . . . . . . . . 14
109 3.2.2. Common Name . . . . . . . . . . . . . . . . . . . . . 15
110 3.2.3. Calendar User Type . . . . . . . . . . . . . . . . . 16
111 3.2.4. Delegators . . . . . . . . . . . . . . . . . . . . . 17
112 3.2.5. Delegatees . . . . . . . . . . . . . . . . . . . . . 17
113 3.2.6. Directory Entry Reference . . . . . . . . . . . . . . 18
114 3.2.7. Inline Encoding . . . . . . . . . . . . . . . . . . . 18
115 3.2.8. Format Type . . . . . . . . . . . . . . . . . . . . . 19
116 3.2.9. Free/Busy Time Type . . . . . . . . . . . . . . . . . 20
117 3.2.10. Language . . . . . . . . . . . . . . . . . . . . . . 21
118 3.2.11. Group or List Membership . . . . . . . . . . . . . . 21
119 3.2.12. Participation Status . . . . . . . . . . . . . . . . 22
120 3.2.13. Recurrence Identifier Range . . . . . . . . . . . . . 24
121 3.2.14. Alarm Trigger Relationship . . . . . . . . . . . . . 24
122 3.2.15. Relationship Type . . . . . . . . . . . . . . . . . . 25
123 3.2.16. Participation Role . . . . . . . . . . . . . . . . . 26
124 3.2.17. RSVP Expectation . . . . . . . . . . . . . . . . . . 26
125 3.2.18. Sent By . . . . . . . . . . . . . . . . . . . . . . . 27
126 3.2.19. Time Zone Identifier . . . . . . . . . . . . . . . . 28
127 3.2.20. Value Data Types . . . . . . . . . . . . . . . . . . 29
128 3.3. Property Value Data Types . . . . . . . . . . . . . . . . 30
129 3.3.1. Binary . . . . . . . . . . . . . . . . . . . . . . . 30
130 3.3.2. Boolean . . . . . . . . . . . . . . . . . . . . . . . 31
131 3.3.3. Calendar User Address . . . . . . . . . . . . . . . . 31
132 3.3.4. Date . . . . . . . . . . . . . . . . . . . . . . . . 32
133 3.3.5. Date-Time . . . . . . . . . . . . . . . . . . . . . . 32
134 3.3.6. Duration . . . . . . . . . . . . . . . . . . . . . . 35
135 3.3.7. Float . . . . . . . . . . . . . . . . . . . . . . . . 35
136 3.3.8. Integer . . . . . . . . . . . . . . . . . . . . . . . 36
137 3.3.9. Period of Time . . . . . . . . . . . . . . . . . . . 36
138 3.3.10. Recurrence Rule . . . . . . . . . . . . . . . . . . . 38
139 3.3.11. Text . . . . . . . . . . . . . . . . . . . . . . . . 43
140 3.3.12. Time . . . . . . . . . . . . . . . . . . . . . . . . 45
141 3.3.13. URI . . . . . . . . . . . . . . . . . . . . . . . . . 47
142 3.3.14. UTC Offset . . . . . . . . . . . . . . . . . . . . . 48
143 3.4. iCalendar Object . . . . . . . . . . . . . . . . . . . . 48
144 3.5. Property . . . . . . . . . . . . . . . . . . . . . . . . 49
145 3.6. Calendar Components . . . . . . . . . . . . . . . . . . . 49
146 3.6.1. Event Component . . . . . . . . . . . . . . . . . . . 50
147 3.6.2. To-do Component . . . . . . . . . . . . . . . . . . . 53
148 3.6.3. Journal Component . . . . . . . . . . . . . . . . . . 55
149 3.6.4. Free/Busy Component . . . . . . . . . . . . . . . . . 57
150 3.6.5. Time Zone Component . . . . . . . . . . . . . . . . . 60
151 3.6.6. Alarm Component . . . . . . . . . . . . . . . . . . . 68
152 3.7. Calendar Properties . . . . . . . . . . . . . . . . . . . 74
153 3.7.1. Calendar Scale . . . . . . . . . . . . . . . . . . . 74
154 3.7.2. Method . . . . . . . . . . . . . . . . . . . . . . . 75
155 3.7.3. Product Identifier . . . . . . . . . . . . . . . . . 76
156 3.7.4. Version . . . . . . . . . . . . . . . . . . . . . . . 77
157 3.8. Component Properties . . . . . . . . . . . . . . . . . . 78
158 3.8.1. Descriptive Component Properties . . . . . . . . . . 78
159 3.8.1.1. Attachment . . . . . . . . . . . . . . . . . . . 78
160 3.8.1.2. Categories . . . . . . . . . . . . . . . . . . . 79
161 3.8.1.3. Classification . . . . . . . . . . . . . . . . . 80
162 3.8.1.4. Comment . . . . . . . . . . . . . . . . . . . . . 81
163 3.8.1.5. Description . . . . . . . . . . . . . . . . . . . 82
164 3.8.1.6. Geographic Position . . . . . . . . . . . . . . . 83
165 3.8.1.7. Location . . . . . . . . . . . . . . . . . . . . 85
166 3.8.1.8. Percent Complete . . . . . . . . . . . . . . . . 86
167 3.8.1.9. Priority . . . . . . . . . . . . . . . . . . . . 87
168 3.8.1.10. Resources . . . . . . . . . . . . . . . . . . . . 89
169 3.8.1.11. Status . . . . . . . . . . . . . . . . . . . . . 89
170 3.8.1.12. Summary . . . . . . . . . . . . . . . . . . . . . 91
171 3.8.2. Date and Time Component Properties . . . . . . . . . 92
172 3.8.2.1. Date/Time Completed . . . . . . . . . . . . . . . 92
173 3.8.2.2. Date/Time End . . . . . . . . . . . . . . . . . . 93
174 3.8.2.3. Date/Time Due . . . . . . . . . . . . . . . . . . 94
175 3.8.2.4. Date/Time Start . . . . . . . . . . . . . . . . . 95
176 3.8.2.5. Duration . . . . . . . . . . . . . . . . . . . . 96
177 3.8.2.6. Free/Busy Time . . . . . . . . . . . . . . . . . 97
178 3.8.2.7. Time Transparency . . . . . . . . . . . . . . . . 98
179 3.8.3. Time Zone Component Properties . . . . . . . . . . . 99
180 3.8.3.1. Time Zone Identifier . . . . . . . . . . . . . . 100
181 3.8.3.2. Time Zone Name . . . . . . . . . . . . . . . . . 101
182 3.8.3.3. Time Zone Offset From . . . . . . . . . . . . . . 102
183 3.8.3.4. Time Zone Offset To . . . . . . . . . . . . . . . 103
184 3.8.3.5. Time Zone URL . . . . . . . . . . . . . . . . . . 103
185 3.8.4. Relationship Component Properties . . . . . . . . . . 104
186 3.8.4.1. Attendee . . . . . . . . . . . . . . . . . . . . 104
187 3.8.4.2. Contact . . . . . . . . . . . . . . . . . . . . . 107
188 3.8.4.3. Organizer . . . . . . . . . . . . . . . . . . . . 108
189 3.8.4.4. Recurrence ID . . . . . . . . . . . . . . . . . . 110
190 3.8.4.5. Related To . . . . . . . . . . . . . . . . . . . 112
191 3.8.4.6. Uniform Resource Locator . . . . . . . . . . . . 114
192 3.8.4.7. Unique Identifier . . . . . . . . . . . . . . . . 114
193 3.8.5. Recurrence Component Properties . . . . . . . . . . . 116
194 3.8.5.1. Exception Date/Times . . . . . . . . . . . . . . 116
195 3.8.5.2. Recurrence Date/Times . . . . . . . . . . . . . . 117
196 3.8.5.3. Recurrence Rule . . . . . . . . . . . . . . . . . 119
197 3.8.6. Alarm Component Properties . . . . . . . . . . . . . 128
198 3.8.6.1. Action . . . . . . . . . . . . . . . . . . . . . 129
199 3.8.6.2. Repeat Count . . . . . . . . . . . . . . . . . . 129
200 3.8.6.3. Trigger . . . . . . . . . . . . . . . . . . . . . 130
201 3.8.7. Change Management Component Properties . . . . . . . 132
202 3.8.7.1. Date/Time Created . . . . . . . . . . . . . . . . 133
203 3.8.7.2. Date/Time Stamp . . . . . . . . . . . . . . . . . 133
204 3.8.7.3. Last Modified . . . . . . . . . . . . . . . . . . 134
205 3.8.7.4. Sequence Number . . . . . . . . . . . . . . . . . 135
206 3.8.8. Miscellaneous Component Properties . . . . . . . . . 136
207 3.8.8.1. Non-standard Properties . . . . . . . . . . . . . 137
208 3.8.8.2. Request Status . . . . . . . . . . . . . . . . . 138
209 4. iCalendar Object Examples . . . . . . . . . . . . . . . . . . 141
210 5. Recommended Practices . . . . . . . . . . . . . . . . . . . . 145
211 6. Registration of Content Type Elements . . . . . . . . . . . . 146
212 6.1. Registration of New and Modified iCalendar Object
213 Methods . . . . . . . . . . . . . . . . . . . . . . . . . 146
214 6.2. Registration of New Properties . . . . . . . . . . . . . 147
215 6.2.1. Define the property . . . . . . . . . . . . . . . . . 147
216 6.2.2. Post the Property definition . . . . . . . . . . . . 148
217 6.2.3. Allow a comment period . . . . . . . . . . . . . . . 148
218 6.2.4. Submit the property for approval . . . . . . . . . . 148
219 6.3. Property Change Control . . . . . . . . . . . . . . . . . 149
220 7. Internationalization Considerations . . . . . . . . . . . . . 149
221 8. Security Considerations . . . . . . . . . . . . . . . . . . . 149
222 9. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 150
223 9.1. Media Type Registration Information . . . . . . . . . . . 150
224 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 153
225 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 154
226 11.1. Normative References . . . . . . . . . . . . . . . . . . 154
227 11.2. Informative References . . . . . . . . . . . . . . . . . 155
228 Appendix A. Differences from RFC 2445 . . . . . . . . . . . . . 155
229 A.1. New restrictions . . . . . . . . . . . . . . . . . . . . 155
230 A.2. Deprecated features . . . . . . . . . . . . . . . . . . . 156
231 Appendix B. Change Log (to be removed by RFC Editor before
232 publication) . . . . . . . . . . . . . . . . . . . . 156
233 B.1. Changes in -03 . . . . . . . . . . . . . . . . . . . . . 156
234 B.2. Changes in -02 . . . . . . . . . . . . . . . . . . . . . 156
235 B.3. Changes in -01 . . . . . . . . . . . . . . . . . . . . . 157
236 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 158
237 Intellectual Property and Copyright Statements . . . . . . . . . 159
239 1. Introduction
241 The use of calendaring and scheduling has grown considerably in the
242 last decade. Enterprise and inter-enterprise business has become
243 dependent on rapid scheduling of events and actions using this
244 information technology. However, the longer term growth of
245 calendaring and scheduling, is currently limited by the lack of
246 Internet standards for the message content types that are central to
247 these knowledgeware applications. This memo is intended to progress
248 the level of interoperability possible between dissimilar calendaring
249 and scheduling applications. This memo defines a MIME content type
250 for exchanging electronic calendaring and scheduling information.
251 The Internet Calendaring and Scheduling Core Object Specification, or
252 iCalendar, allows for the capture and exchange of information
253 normally stored within a calendaring and scheduling application; such
254 as a Personal Information Manager (PIM) or a Group Scheduling
255 product.
257 The iCalendar format is suitable as an exchange format between
258 applications or systems. The format is defined in terms of a MIME
259 content type. This will enable the object to be exchanged using
260 several transports, including but not limited to SMTP, HTTP, a file
261 system, desktop interactive protocols such as the use of a memory-
262 based clipboard or drag/drop interactions, point-to-point
263 asynchronous communication, wired-network transport, or some form of
264 unwired transport such as infrared might also be used.
266 The memo also provides for the definition of iCalendar object methods
267 that will map this content type to a set of messages for supporting
268 calendaring and scheduling operations such as requesting, replying
269 to, modifying, and canceling meetings or appointments, to-dos and
270 journal entries. The iCalendar object methods can be used to define
271 other calendaring and scheduling operations such a requesting for and
272 replying with free/busy time data. Such a scheduling protocol is
273 defined in the iCalendar Transport-independent Interoperability
274 Protocol (iTIP) defined in [I-D.ietf-calsify-2446bis].
276 The memo also includes a formal grammar for the content type based on
277 the Internet ABNF defined in [RFC4234] . This ABNF is required for
278 the implementation of parsers and to serve as the definitive
279 reference when ambiguities or questions arise in interpreting the
280 descriptive prose definition of the memo.
282 2. Basic Grammar and Conventions
284 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
285 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" and
286 "OPTIONAL" in this document are to be interpreted as described in
287 [RFC2119].
289 This memo makes use of both a descriptive prose and a more formal
290 notation for defining the calendaring and scheduling format.
292 The notation used in this memo is the ABNF notation of [RFC4234] .
293 Readers intending on implementing this format defined in this memo
294 should be familiar with this notation in order to properly interpret
295 the specifications of this memo.
297 All numeric values used in this memo are given in decimal notation.
299 All names of properties, property parameters, enumerated property
300 values and property parameter values are case-insensitive. However,
301 all other property values are case-sensitive, unless otherwise
302 stated.
304 Note: All indented editorial notes, such as this one, are intended
305 to provide the reader with additional information. The
306 information is not essential to the building of an implementation
307 conformant with this memo. The information is provided to
308 highlight a particular feature or characteristic of the memo.
310 The format for the iCalendar object is based on the syntax of the
311 [RFC2425] content type. While the iCalendar object is not a profile
312 of the [RFC2425] content type, it does reuse a number of the elements
313 from the [RFC2425] specification.
315 2.1. Formatting Conventions
317 The mechanisms defined in this memo are defined in prose. Many of
318 the terms used to describe these have common usage that is different
319 than the standards usage of this memo. In order to reference within
320 this memo elements of the calendaring and scheduling model, core
321 object (this memo) or interoperability protocol [I-D.ietf-calsify-
322 2446bis] some formatting conventions have been used. Calendaring and
323 scheduling roles are referred to in quoted-strings of text with the
324 first character of each word in upper case. For example, "Organizer"
325 refers to a role of a "Calendar User" within the scheduling protocol
326 defined by [I-D.ietf-calsify-2446bis]. Calendar components defined
327 by this memo are referred to with capitalized, quoted-strings of
328 text. All calendar components start with the letter "V". For
329 example, "VEVENT" refers to the event calendar component, "VTODO"
330 refers to the to-do calendar component and "VJOURNAL" refers to the
331 daily journal calendar component. Scheduling methods defined by iTIP
332 [I-D.ietf-calsify-2446bis] are referred to with capitalized, quoted-
333 strings of text. For example, "REQUEST" refers to the method for
334 requesting a scheduling calendar component be created or modified,
335 "REPLY" refers to the method a recipient of a request uses to update
336 their status with the "Organizer" of the calendar component.
338 The properties defined by this memo are referred to with capitalized,
339 quoted-strings of text, followed by the word "property". For
340 example, "ATTENDEE" property refers to the iCalendar property used to
341 convey the calendar address of a calendar user. Property parameters
342 defined by this memo are referred to with lowercase, quoted-strings
343 of text, followed by the word "parameter". For example, "value"
344 parameter refers to the iCalendar property parameter used to override
345 the default data type for a property value. Enumerated values
346 defined by this memo are referred to with capitalized text, either
347 alone or followed by the word "value". For example, the "MINUTELY"
348 value can be used with the "FREQ" component of the "RECUR" data type
349 to specify repeating components based on an interval of one minute or
350 more.
352 2.2. Related Memos
354 Implementers will need to be familiar with several other memos that,
355 along with this memo, form a framework for Internet calendaring and
356 scheduling standards. This memo specifies a core specification of
357 objects, data types, properties and property parameters.
359 o iTIP [I-D.ietf-calsify-2446bis] specifies an interoperability
360 protocol for scheduling between different implementations;
362 o iMIP [I-D.ietf-calsify-rfc2447bis] specifies an Internet email
363 binding for [I-D.ietf-calsify-2446bis].
365 This memo does not attempt to repeat the specification of concepts or
366 definitions from these other memos. Where possible, references are
367 made to the memo that provides for the specification of these
368 concepts or definitions.
370 2.3. International Considerations
372 In the rest of this document, descriptions of characters are of the
373 form "character name (codepoint)", where "codepoint" is from the US-
374 ASCII character set. The "character name" is the authoritative
375 description; (codepoint) is a reference to that character in US-ASCII
376 or US-ASCII compatible sets (for example the ISO-8859-x family,
377 UTF-8, ISO-2022-xx, KOI8-R). If a non-US-ASCII compatible character
378 set is used, appropriate code-point from that character set MUST be
379 chosen instead. Use of non-US-ASCII-compatible character sets is NOT
380 recommended.
382 3. iCalendar Object Specification
384 The following sections define the details of a Calendaring and
385 Scheduling Core Object Specification. This information is intended
386 to be an integral part of the MIME content type registration. In
387 addition, this information can be used independent of such content
388 registration. In particular, this memo has direct applicability for
389 use as a calendaring and scheduling exchange format in file-, memory-
390 or network-based transport mechanisms.
392 3.1. Content Lines
394 The iCalendar object is organized into individual lines of text,
395 called content lines. Content lines are delimited by a line break,
396 which is a CRLF sequence (US-ASCII decimal 13, followed by US-ASCII
397 decimal 10).
399 Lines of text SHOULD NOT be longer than 75 octets, excluding the line
400 break. Long content lines SHOULD be split into a multiple line
401 representations using a line "folding" technique. That is, a long
402 line can be split between any two characters by inserting a CRLF
403 immediately followed by a single linear white space character (i.e.,
404 SPACE, US-ASCII decimal 32 or HTAB, US-ASCII decimal 9). Any
405 sequence of CRLF followed immediately by a single linear white space
406 character is ignored (i.e., removed) when processing the content
407 type.
409 For example the line:
411 DESCRIPTION:This is a long description that exists on a long line.
413 Can be represented as:
415 DESCRIPTION:This is a lo
416 ng description
417 that exists on a long line.
419 The process of moving from this folded multiple line representation
420 to its single line representation is called "unfolding". Unfolding
421 is accomplished by removing the CRLF character and the linear white
422 space character that immediately follows.
424 When parsing a content line, folded lines MUST first be unfolded
425 according to the unfolding procedure described above.
427 Note: It is possible for very simple implementations to generate
428 improperly folded lines in the middle of a UTF-8 multi-octet
429 sequence. For this reason, implementations need to unfold lines
430 in such a way to properly restore the original sequence.
432 The content information associated with an iCalendar object is
433 formatted using a syntax similar to that defined by [RFC2425]. That
434 is, the content information consists of CRLF-separated content lines.
436 The following notation defines the lines of content in an iCalendar
437 object:
439 contentline = name *(";" param ) ":" value CRLF
440 ; This ABNF is just a general definition for an initial parsing
441 ; of the content line into its property name, parameter list,
442 ; and value string
444 ; When parsing a content line, folded lines MUST first
445 ; be unfolded according to the unfolding procedure
446 ; described above. When generating a content line, lines
447 ; longer than 75 octets SHOULD be folded according to
448 ; the folding procedure described above.
450 name = x-name / iana-token
452 iana-token = 1*(ALPHA / DIGIT / "-")
453 ; iCalendar identifier registered with IANA
455 x-name = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-")
456 ; Reserved for experimental use.
458 vendorid = 3*(ALPHA / DIGIT) ;Vendor identification
460 param = param-name "=" param-value
461 *("," param-value)
462 ; Each property defines the specific ABNF for the parameters
463 ; allowed on the property. Refer to specific properties for
464 ; precise parameter ABNF.
466 param-name = iana-token / x-name
468 param-value = paramtext / quoted-string
470 paramtext = *SAFE-CHAR
472 value = *VALUE-CHAR
474 quoted-string = DQUOTE *QSAFE-CHAR DQUOTE
475 QSAFE-CHAR = WSP / %x21 / %x23-7E / NON-US-ASCII
476 ; Any character except CTLs and DQUOTE
478 SAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E
479 / NON-US-ASCII
480 ; Any character except CTLs, DQUOTE, ";", ":", ","
482 VALUE-CHAR = WSP / %x21-7E / NON-US-ASCII
483 ; Any textual character
485 NON-US-ASCII = %x80-F8
486 ; Use restricted by charset parameter
487 ; on outer MIME object (UTF-8 preferred)
489 CR = %x0D
490 ; carriage return
492 LF = %x0A
493 ; line feed
495 CRLF = CR LF
496 ; Internet standard newline
498 CTL = %x00-08 / %x0A-1F / %x7F
499 ; Controls
501 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
503 DIGIT = %x30-39
504 ; 0-9
506 DQUOTE = %x22
507 ; Quotation Mark
509 WSP = SPACE / HTAB
511 SPACE = %x20
513 HTAB = %x09
515 The property value component of a content line has a format that is
516 property specific. Refer to the section describing each property for
517 a definition of this format.
519 All names of properties, property parameters, enumerated property
520 values and property parameter values are case-insensitive. However,
521 all other property values are case-sensitive, unless otherwise
522 stated.
524 3.1.1. List and Field Separators
526 Some properties and parameters allow a list of values. Values in a
527 list of values MUST be separated by a COMMA character (US-ASCII
528 decimal 44). There is no significance to the order of values in a
529 list. For those parameter values (such as those that specify URI
530 values) that are specified in quoted-strings, the individual quoted-
531 strings are separated by a COMMA character (US-ASCII decimal 44).
533 Some property values are defined in terms of multiple parts. These
534 structured property values MUST have their value parts separated by a
535 SEMICOLON character (US-ASCII decimal 59).
537 Some properties allow a list of parameters. Each property parameter
538 in a list of property parameters MUST be separated by a SEMICOLON
539 character (US-ASCII decimal 59).
541 Property parameters with values containing a COLON, a SEMICOLON or a
542 COMMA character MUST be placed in quoted text.
544 For example, in the following properties a SEMICOLON is used to
545 separate property parameters from each other, and a COMMA is used to
546 separate property values in a value list.
548 ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT:MAILTO:
549 jsmith@example.com
551 RDATE;VALUE=DATE:19970304,19970504,19970704,19970904
553 3.1.2. Multiple Values
555 Some properties defined in the iCalendar object can have multiple
556 values. The general rule for encoding multi-valued items is to
557 simply create a new content line for each value, including the
558 property name. However, it should be noted that some properties
559 support encoding multiple values in a single property by separating
560 the values with a COMMA character (US-ASCII decimal 44). Individual
561 property definitions should be consulted for determining whether a
562 specific property allows multiple values and in which of these two
563 forms.
565 3.1.3. Binary Content
567 Binary content information in an iCalendar object SHOULD be
568 referenced using a URI within a property value. That is the binary
569 content information SHOULD be placed in an external MIME entity that
570 can be referenced by a URI from within the iCalendar object. In
571 applications where this is not feasible, binary content information
572 can be included within an iCalendar object, but only after first
573 encoding it into text using the "BASE64" encoding method defined in
574 [RFC4648] . Inline binary contact SHOULD only be used in
575 applications whose special circumstances demand that an iCalendar
576 object be expressed as a single entity. A property containing inline
577 binary content information MUST specify the "ENCODING" property
578 parameter. Binary content information placed external to the
579 iCalendar object MUST be referenced by a uniform resource identifier
580 (URI).
582 The following example specifies an "ATTACH" property that references
583 an attachment external to the iCalendar object with a URI reference:
585 ATTACH:http://example.com/public/quarterly-report.doc
587 The following example specifies an "ATTACH" property with inline
588 binary encoded content information:
590 ATTACH;FMTTYPE=image/basic;ENCODING=BASE64;VALUE=BINARY:
591 MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1U
592 EBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIE
593 <...remainder of "BASE64" encoded binary data...>
595 3.1.4. Character Set
597 There is not a property parameter to declare the charset used in a
598 property value. The default charset for an iCalendar stream is UTF-8
599 as defined in [RFC3629] .
601 The "charset" Content-Type parameter MUST be used in MIME transports
602 to specify the charset being used .
604 3.2. Property Parameters
606 A property can have attributes associated with it. These "property
607 parameters" contain meta-information about the property or the
608 property value. Property parameters are provided to specify such
609 information as the location of an alternate text representation for a
610 property value, the language of a text property value, the data type
611 of the property value and other attributes.
613 Property parameter values that contain the COLON (US-ASCII decimal
614 58), SEMICOLON (US-ASCII decimal 59) or COMMA (US-ASCII decimal 44)
615 character separators MUST be specified as quoted-string text values.
616 Property parameter values MUST NOT contain the DQUOTE (US-ASCII
617 decimal 22) character. The DQUOTE (US-ASCII decimal 22) character is
618 used as a delimiter for parameter values that contain restricted
619 characters or URI text. For example:
621 DESCRIPTION;ALTREP="http://www.example.org":The Fall'98 Wild
622 Wizards Conference - - Las Vegas\, NV\, USA
624 Property parameter values that are not in quoted strings are case
625 insensitive.
627 The general property parameters defined by this memo are defined by
628 the following notation:
630 parameter = altrepparam ; Alternate text representation
631 / cnparam ; Common name
632 / cutypeparam ; Calendar user type
633 / delfromparam ; Delegator
634 / deltoparam ; Delegatee
635 / dirparam ; Directory entry
636 / encodingparam ; Inline encoding
637 / fmttypeparam ; Format type
638 / fbtypeparam ; Free/busy time type
639 / languageparam ; Language for text
640 / memberparam ; Group or list membership
641 / partstatparam ; Participation status
642 / rangeparam ; Recurrence identifier range
643 / trigrelparam ; Alarm trigger relationship
644 / reltypeparam ; Relationship type
645 / roleparam ; Participation role
646 / rsvpparam ; RSVP expectation
647 / sentbyparam ; Sent by
648 / tzidparam ; Reference to time zone object
649 / valuetypeparam ; Property value data type
650 / ianaparam
651 ; Some other IANA registered iCalendar parameter.
652 / xparam
653 ; A non-standard, experimental parameter.
655 ianaparam = iana-token "=" param-value *("," param-value)
657 xparam = x-name "=" param-value *("," param-value)
659 3.2.1. Alternate Text Representation
661 Parameter Name: ALTREP
663 Purpose: To specify an alternate text representation for the property
664 value.
666 Format Definition: The property parameter is defined by the following
667 notation:
669 altrepparam = "ALTREP" "=" DQUOTE uri DQUOTE
671 Description: The parameter specifies a URI that points to an
672 alternate representation for a textual property value. A property
673 specifying this parameter MUST also include a value that reflects
674 the default representation of the text value. The individual URI
675 parameter values MUST each be specified in a quoted-string.
677 Example:
679 DESCRIPTION;ALTREP="CID:part3.msg.970415T083000@example.com":
680 Project XYZ Review Meeting will include the following agenda
681 items: (a) Market Overview\, (b) Finances\, (c) Project Man
682 agement
684 The "ALTREP" property parameter value might point to a "text/html"
685 content portion.
687 Content-Type:text/html
688 Content-Id:
690
691
692
693
694
695
696 Project XYZ Review Meeting will include
697 the following agenda items:
698
699 - Market Overview
700 - Finances
701 - Project Management
702
703
704
705
707 3.2.2. Common Name
709 Parameter Name: CN
710 Purpose: To specify the common name to be associated with the
711 calendar user specified by the property.
713 Format Definition: The property parameter is defined by the following
714 notation:
716 cnparam = "CN" "=" param-value
718 Description: This parameter can be specified on properties with a
719 CAL-ADDRESS value type. The parameter specifies the common name
720 to be associated with the calendar user specified by the property.
721 The parameter value is text. The parameter value can be used for
722 display text to be associated with the calendar address specified
723 by the property.
725 Example:
727 ORGANIZER;CN="John Smith":MAILTO:jsmith@example.com
729 3.2.3. Calendar User Type
731 Parameter Name: CUTYPE
733 Purpose: To specify the type of calendar user specified by the
734 property.
736 Format Definition: The property parameter is defined by the following
737 notation:
739 cutypeparam = "CUTYPE" "="
740 ("INDIVIDUAL" ; An individual
741 / "GROUP" ; A group of individuals
742 / "RESOURCE" ; A physical resource
743 / "ROOM" ; A room resource
744 / "UNKNOWN" ; Otherwise not known
745 / x-name ; Experimental type
746 / iana-token) ; Other IANA registered
747 ; type
748 ; Default is INDIVIDUAL
750 Description: This parameter can be specified on properties with a
751 CAL-ADDRESS value type. The parameter identifies the type of
752 calendar user specified by the property. If not specified on a
753 property that allows this parameter, the default is INDIVIDUAL.
755 Example:
757 ATTENDEE;CUTYPE=GROUP:MAILTO:ietf-calsch@imc.org
759 3.2.4. Delegators
761 Parameter Name: DELEGATED-FROM
763 Purpose: To specify the calendar users that have delegated their
764 participation to the calendar user specified by the property.
766 Format Definition: The property parameter is defined by the following
767 notation:
769 delfromparam = "DELEGATED-FROM" "=" DQUOTE cal-address
770 DQUOTE *("," DQUOTE cal-address DQUOTE)
772 Description: This parameter can be specified on properties with a
773 CAL-ADDRESS value type. This parameter can be specified on a
774 property that has a value type of calendar address. This
775 parameter specifies those calendar users that have delegated their
776 participation in a group scheduled event or to-do to the calendar
777 user specified by the property. The value MUST be a MAILTO URI as
778 defined in [RFC2368] . The individual calendar address parameter
779 values MUST each be specified in a quoted-string.
781 Example:
783 ATTENDEE;DELEGATED-FROM="MAILTO:jsmith@example.com":MAILTO:
784 jdoe@example.com
786 3.2.5. Delegatees
788 Parameter Name: DELEGATED-TO
790 Purpose: To specify the calendar users to whom the calendar user
791 specified by the property has delegated participation.
793 Format Definition: The property parameter is defined by the following
794 notation:
796 deltoparam = "DELEGATED-TO" "=" DQUOTE cal-address DQUOTE
797 *("," DQUOTE cal-address DQUOTE)
799 Description: This parameter can be specified on properties with a
800 CAL-ADDRESS value type. This parameter specifies those calendar
801 users whom have been delegated participation in a group scheduled
802 event or to-do by the calendar user specified by the property.
803 The value MUST be a MAILTO URI as defined in [RFC2368] . The
804 individual calendar address parameter values MUST each be
805 specified in a quoted-string.
807 Example:
809 ATTENDEE;DELEGATED-TO="MAILTO:jdoe@example.com","MAILTO:jqpublic
810 @example.com":MAILTO:jsmith@example.com
812 3.2.6. Directory Entry Reference
814 Parameter Name: DIR
816 Purpose: To specify reference to a directory entry associated with
817 the calendar user specified by the property.
819 Format Definition: The property parameter is defined by the following
820 notation:
822 dirparam = "DIR" "=" DQUOTE uri DQUOTE
824 Description: This parameter can be specified on properties with a
825 CAL-ADDRESS value type. The parameter specifies a reference to
826 the directory entry associated with the calendar user specified by
827 the property. The parameter value is a URI. The URI parameter
828 value MUST be specified in a quoted-string.
830 Example:
832 ORGANIZER;DIR="ldap://example.com:6666/o=ABC%20Industries,
833 c=US???(cn=Jim%20Dolittle)":MAILTO:jimdo@example.com
835 3.2.7. Inline Encoding
837 Parameter Name: ENCODING
839 Purpose: To specify an alternate inline encoding for the property
840 value.
842 Format Definition: The property parameter is defined by the following
843 notation:
845 encodingparam = "ENCODING" "="
846 ("8BIT"
847 ; "8bit" text encoding is defined in
848 [RFC2045]
850 / "BASE64"
851 ; "BASE64" binary encoding format is defined in
852 [RFC4648]
854 / iana-token
855 ; Some other IANA registered iCalendar encoding type
856 / x-name)
857 ; A non-standard, experimental encoding type
859 Description: The property parameter identifies the inline encoding
860 used in a property value. The default encoding is "8BIT",
861 corresponding to a property value consisting of text. The
862 "BASE64" encoding type corresponds to a property value encoded
863 using the "BASE64" encoding defined in [RFC2045].
865 If the value type parameter is ";VALUE=BINARY", then the inline
866 encoding parameter MUST be specified with the value
867 ";ENCODING=BASE64".
869 Example:
871 ATTACH;FMTYPE=IMAGE/JPEG;ENCODING=BASE64;VALUE=BINARY:MIICajC
872 CAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDA
873 qBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMRw
874 <...remainder of "BASE64" encoded binary data...>
876 3.2.8. Format Type
878 Parameter Name: FMTTYPE
880 Purpose: To specify the content type of a referenced object.
882 Format Definition: The property parameter is defined by the following
883 notation:
885 fmttypeparam = "FMTTYPE" "=" iana-token
886 ; A IANA registered content type
887 / x-name
888 ; A non-standard content type
890 Description: This parameter can be specified on properties that are
891 used to reference an object. The parameter specifies the content
892 type of the referenced object. For example, on the "ATTACH"
893 property, a FTP type URI value does not, by itself, necessarily
894 convey the type of content associated with the resource. The
895 parameter value MUST be the TEXT for either an IANA registered
896 content type or a non-standard content type.
898 Example:
900 ATTACH;FMTTYPE=application/msword:ftp://example.com/pub/docs/
901 agenda.doc
903 3.2.9. Free/Busy Time Type
905 Parameter Name: FBTYPE
907 Purpose: To specify the free or busy time type.
909 Format Definition: The property parameter is defined by the following
910 notation:
912 fbtypeparam = "FBTYPE" "=" ("FREE" / "BUSY"
913 / "BUSY-UNAVAILABLE" / "BUSY-TENTATIVE"
914 / x-name
915 ; Some experimental iCalendar data type.
916 / iana-token)
917 ; Some other IANA registered iCalendar data type.
919 Description: The parameter specifies the free or busy time type. The
920 value FREE indicates that the time interval is free for
921 scheduling. The value BUSY indicates that the time interval is
922 busy because one or more events have been scheduled for that
923 interval. The value BUSY-UNAVAILABLE indicates that the time
924 interval is busy and that the interval can not be scheduled. The
925 value BUSY-TENTATIVE indicates that the time interval is busy
926 because one or more events have been tentatively scheduled for
927 that interval. If not specified on a property that allows this
928 parameter, the default is BUSY.
930 Example: The following is an example of this parameter on a FREEBUSY
931 property.
933 FREEBUSY;FBTYPE=BUSY:19980415T133000Z/19980415T170000Z
935 3.2.10. Language
937 Parameter Name: LANGUAGE
939 Purpose: To specify the language for text values in a property or
940 property parameter.
942 Format Definition: The property parameter is defined by the following
943 notation:
945 languageparam = "LANGUAGE" "=" language
947 language =
951 Description: The parameter identifies the language of the text in the
952 property or property parameter value. The value of the "language"
953 property parameter is that defined in [RFC3066] .
955 For transport in a MIME entity, the Content-Language header field
956 can be used to set the default language for the entire body part.
957 Otherwise, no default language is assumed.
959 Example:
961 SUMMARY;LANGUAGE=us-EN:Company Holiday Party
963 LOCATION;LANGUAGE=en:Germany
965 LOCATION;LANGUAGE=no:Tyskland
967 The following example makes use of the Quoted-Printable encoding
968 in order to represent non-ASCII characters.
970 LOCATION;LANGUAGE=3Dda:K=C3=B8benhavn
972 LOCATION;LANGUAGE=en:Copenhagen
974 3.2.11. Group or List Membership
976 Parameter Name: MEMBER
978 Purpose: To specify the group or list membership of the calendar user
979 specified by the property.
981 Format Definition: The property parameter is defined by the following
982 notation:
984 memberparam = "MEMBER" "=" DQUOTE cal-address DQUOTE
985 *("," DQUOTE cal-address DQUOTE)
987 Description: This parameter can be specified on properties with a
988 CAL-ADDRESS value type. The parameter identifies the groups or
989 list membership for the calendar user specified by the property.
990 The parameter value either a single calendar address in a quoted-
991 string or a COMMA character (US-ASCII decimal 44) list of calendar
992 addresses, each in a quoted-string. The individual calendar
993 address parameter values MUST each be specified in a quoted-
994 string.
996 Example:
998 ATTENDEE;MEMBER="MAILTO:ietf-calsch@example.org":MAILTO:
999 jsmith@example.com
1001 ATTENDEE;MEMBER="MAILTO:projectA@example.com","MAILTO:pr
1002 ojectB@example.com":MAILTO:janedoe@example.com
1004 3.2.12. Participation Status
1006 Parameter Name: PARTSTAT
1008 Purpose: To specify the participation status for the calendar user
1009 specified by the property.
1011 Format Definition: The property parameter is defined by the following
1012 notation:
1014 partstatparam = "PARTSTAT" "="
1015 ("NEEDS-ACTION" ; Event needs action
1016 / "ACCEPTED" ; Event accepted
1017 / "DECLINED" ; Event declined
1018 / "TENTATIVE" ; Event tentatively
1019 ; accepted
1020 / "DELEGATED" ; Event delegated
1021 / x-name ; Experimental status
1022 / iana-token) ; Other IANA registered
1023 ; status
1024 ; These are the participation statuses for a "VEVENT".
1025 ; Default is NEEDS-ACTION.
1027 /
1028 ("NEEDS-ACTION" ; To-do needs action
1029 / "ACCEPTED" ; To-do accepted
1030 / "DECLINED" ; To-do declined
1031 / "TENTATIVE" ; To-do tentatively
1032 ; accepted
1033 / "DELEGATED" ; To-do delegated
1034 / "COMPLETED" ; To-do completed.
1035 ; COMPLETED property has
1036 ; date/time completed.
1037 / "IN-PROCESS" ; To-do in process of
1038 ; being completed
1039 / x-name ; Experimental status
1040 / iana-token) ; Other IANA registered
1041 ; status
1042 ; These are the participation statuses for a "VTODO".
1043 ; Default is NEEDS-ACTION.
1045 /
1046 ("NEEDS-ACTION" ; Journal needs action
1047 / "ACCEPTED" ; Journal accepted
1048 / "DECLINED" ; Journal declined
1049 / x-name ; Experimental status
1050 / iana-token) ; Other IANA registered
1051 ; status
1052 ; These are the participation statuses for a "VJOURNAL".
1053 ; Default is NEEDS-ACTION.
1055 Description: This parameter can be specified on properties with a
1056 CAL-ADDRESS value type. The parameter identifies the
1057 participation status for the calendar user specified by the
1058 property value. The parameter values differ depending on whether
1059 they are associated with a group scheduled "VEVENT", "VTODO" or
1060 "VJOURNAL". The values MUST match one of the values allowed for
1061 the given calendar component. If not specified on a property that
1062 allows this parameter, the default value is NEEDS-ACTION.
1064 Example:
1066 ATTENDEE;PARTSTAT=DECLINED:MAILTO:jsmith@example.com
1068 3.2.13. Recurrence Identifier Range
1070 Parameter Name: RANGE
1072 Purpose: To specify the effective range of recurrence instances from
1073 the instance specified by the recurrence identifier specified by
1074 the property.
1076 Format Definition: The property parameter is defined by the following
1077 notation:
1079 rangeparam = "RANGE" "=" ("THISANDPRIOR"
1080 ; To specify all instances prior to the recurrence identifier
1081 / "THISANDFUTURE")
1082 ; To specify the instance specified by the recurrence identifier
1083 ; and all subsequent recurrence instances
1085 Description: The parameter can be specified on a property that
1086 specifies a recurrence identifier. The parameter specifies the
1087 effective range of recurrence instances that is specified by the
1088 property. The effective range is from the recurrence identified
1089 specified by the property. If this parameter is not specified an
1090 allowed property, then the default range is the single instance
1091 specified by the recurrence identifier value of the property. The
1092 parameter value can be "THISANDPRIOR" to indicate a range defined
1093 by the recurrence identified value of the property and all prior
1094 instances. The parameter value can also be "THISANDFUTURE" to
1095 indicate a range defined by the recurrence identifier and all
1096 subsequent instances.
1098 Example:
1100 RECURRENCE-ID;RANGE=THISANDPRIOR:19980401T133000Z
1102 3.2.14. Alarm Trigger Relationship
1104 Parameter Name: RELATED
1106 Purpose: To specify the relationship of the alarm trigger with
1107 respect to the start or end of the calendar component.
1109 Format Definition: The property parameter is defined by the following
1110 notation:
1112 trigrelparam = "RELATED" "="
1113 ("START" ; Trigger off of start
1114 / "END") ; Trigger off of end
1116 Description: The parameter can be specified on properties that
1117 specify an alarm trigger with a DURATION value type. The
1118 parameter specifies whether the alarm will trigger relative to the
1119 start or end of the calendar component. The parameter value START
1120 will set the alarm to trigger off the start of the calendar
1121 component; the parameter value END will set the alarm to trigger
1122 off the end of the calendar component. If the parameter is not
1123 specified on an allowable property, then the default is START.
1125 Example:
1127 TRIGGER;RELATED=END:PT5M
1129 3.2.15. Relationship Type
1131 Parameter Name: RELTYPE
1133 Purpose: To specify the type of hierarchical relationship associated
1134 with the calendar component specified by the property.
1136 Format Definition: The property parameter is defined by the following
1137 notation:
1139 reltypeparam = "RELTYPE" "="
1140 ("PARENT" ; Parent relationship. Default.
1141 / "CHILD" ; Child relationship
1142 / "SIBLING" ; Sibling relationship
1143 / iana-token ; Some other IANA registered
1144 ; iCalendar relationship type
1145 / x-name) ; A non-standard, experimental
1146 ; relationship type
1148 Description: This parameter can be specified on a property that
1149 references another related calendar. The parameter specifies the
1150 hierarchical relationship type of the calendar component
1151 referenced by the property. The parameter value can be PARENT, to
1152 indicate that the referenced calendar component is a superior of
1153 calendar component; CHILD to indicate that the referenced calendar
1154 component is a subordinate of the calendar component; SIBLING to
1155 indicate that the referenced calendar component is a peer of the
1156 calendar component. If this parameter is not specified on an
1157 allowable property, the default relationship type is PARENT.
1159 Example:
1161 RELATED-TO;RELTYPE=SIBLING:19960401-080045-4000F192713@
1162 example.com
1164 3.2.16. Participation Role
1166 Parameter Name: ROLE
1168 Purpose: To specify the participation role for the calendar user
1169 specified by the property.
1171 Format Definition: The property parameter is defined by the following
1172 notation:
1174 roleparam = "ROLE" "="
1175 ("CHAIR" ; Indicates chair of the
1176 ; calendar entity
1177 / "REQ-PARTICIPANT" ; Indicates a participant whose
1178 ; participation is required
1179 / "OPT-PARTICIPANT" ; Indicates a participant whose
1180 ; participation is optional
1181 / "NON-PARTICIPANT" ; Indicates a participant who
1182 ; is copied for information
1183 ; purposes only
1184 / x-name ; Experimental role
1185 / iana-token) ; Other IANA role
1186 ; Default is REQ-PARTICIPANT
1188 Description: This parameter can be specified on properties with a
1189 CAL-ADDRESS value type. The parameter specifies the participation
1190 role for the calendar user specified by the property in the group
1191 schedule calendar component. If not specified on a property that
1192 allows this parameter, the default value is REQ-PARTICIPANT.
1194 Example:
1196 ATTENDEE;ROLE=CHAIR:MAILTO:mrbig@example.com
1198 3.2.17. RSVP Expectation
1200 Parameter Name: RSVP
1201 Purpose: To specify whether there is an expectation of a favor of a
1202 reply from the calendar user specified by the property value.
1204 Format Definition: The property parameter is defined by the following
1205 notation:
1207 rsvpparam = "RSVP" "=" ("TRUE" / "FALSE")
1208 ; Default is FALSE
1210 Description: This parameter can be specified on properties with a
1211 CAL-ADDRESS value type. The parameter identifies the expectation
1212 of a reply from the calendar user specified by the property value.
1213 This parameter is used by the "Organizer" to request a
1214 participation status reply from an "Attendee" of a group scheduled
1215 event or to-do. If not specified on a property that allows this
1216 parameter, the default value is FALSE.
1218 Example:
1220 ATTENDEE;RSVP=TRUE:MAILTO:jsmith@example.com
1222 3.2.18. Sent By
1224 Parameter Name: SENT-BY
1226 Purpose: To specify the calendar user that is acting on behalf of the
1227 calendar user specified by the property.
1229 Format Definition: The property parameter is defined by the following
1230 notation:
1232 sentbyparam = "SENT-BY" "=" DQUOTE cal-address DQUOTE
1234 Description: This parameter can be specified on properties with a
1235 CAL-ADDRESS value type. The parameter specifies the calendar user
1236 that is acting on behalf of the calendar user specified by the
1237 property. The parameter value MUST be a MAILTO URI as defined in
1238 [RFC2368] . The individual calendar address parameter values MUST
1239 each be specified in a quoted-string.
1241 Example:
1243 ORGANIZER;SENT-BY="MAILTO:sray@example.com":MAILTO:
1244 jsmith@example.com
1246 3.2.19. Time Zone Identifier
1248 Parameter Name: TZID
1250 Purpose: To specify the identifier for the time zone definition for a
1251 time component in the property value.
1253 Format Definition: The property parameter is defined by the following
1254 notation:
1256 tzidparam = "TZID" "=" [tzidprefix] paramtext
1258 tzidprefix = "/"
1260 Description: The parameter MUST be specified on the "DTSTART",
1261 "DTEND", "DUE", "EXDATE" and "RDATE" properties when either a
1262 DATE- TIME or TIME value type is specified and when the value is
1263 not either a UTC or a "floating" time. Refer to the DATE-TIME or
1264 TIME value type definition for a description of UTC and "floating
1265 time" formats. This property parameter specifies a text value
1266 which uniquely identifies the "VTIMEZONE" calendar component to be
1267 used when evaluating the time portion of the property. The value
1268 of the TZID property parameter will be equal to the value of the
1269 TZID property for the matching time zone definition. An
1270 individual "VTIMEZONE" calendar component MUST be specified for
1271 each unique "TZID" parameter value specified in the iCalendar
1272 object.
1274 The parameter MUST be specified on properties with a DATE-TIME
1275 value if the DATE-TIME is not either a UTC or a "floating" time.
1277 The presence of the SOLIDUS character (US-ASCII decimal 47) as a
1278 prefix, indicates that this TZID represents a unique ID in a
1279 globally defined time zone registry (when such registry is
1280 defined).
1282 Note: This document does not define a naming convention for
1283 time zone identifiers. Implementers may want to use the naming
1284 conventions defined in existing time zone specifications such
1285 as the public-domain Olson database [TZDB]. The specification
1286 of globally unique time zone identifiers is not addressed by
1287 this document and is left for future study.
1289 The following are examples of this property parameter:
1291 DTSTART;TZID=US-Eastern:19980119T020000
1293 DTEND;TZID=US-Eastern:19980119T030000
1295 The TZID property parameter MUST NOT be applied to DATE-TIME or
1296 TIME properties whose time values are specified in UTC.
1298 The use of local time in a DATE-TIME or TIME value without the
1299 TZID property parameter is to be interpreted as a local time
1300 value, regardless of the existence of "VTIMEZONE" calendar
1301 components in the iCalendar object.
1303 For more information see the sections on the data types DATE-TIME
1304 and TIME.
1306 3.2.20. Value Data Types
1308 Parameter Name: VALUE
1310 Purpose: To explicitly specify the data type format for a property
1311 value.
1313 Format Definition: The property parameter is defined by the following
1314 notation:
1316 valuetypeparam = "VALUE" "=" valuetype
1318 valuetype = ("BINARY"
1319 / "BOOLEAN"
1320 / "CAL-ADDRESS"
1321 / "DATE"
1322 / "DATE-TIME"
1323 / "DURATION"
1324 / "FLOAT"
1325 / "INTEGER"
1326 / "PERIOD"
1327 / "RECUR"
1328 / "TEXT"
1329 / "TIME"
1330 / "URI"
1331 / "UTC-OFFSET"
1332 / x-name
1333 ; Some experimental iCalendar data type.
1334 / iana-token)
1335 ; Some other IANA registered iCalendar data type.
1337 Description: The parameter specifies the data type and format of the
1338 property value. The property values MUST be of a single value
1339 type. For example, a "RDATE" property cannot have a combination
1340 of DATE- TIME and TIME value types.
1342 If the property's value is the default value type, then this
1343 parameter need not be specified. However, if the property's
1344 default value type is overridden by some other allowable value
1345 type, then this parameter MUST be specified.
1347 3.3. Property Value Data Types
1349 The properties in an iCalendar object are strongly typed. The
1350 definition of each property restricts the value to be one of the
1351 value data types, or simply value types, defined in this section.
1352 The value type for a property will either be specified implicitly as
1353 the default value type or will be explicitly specified with the
1354 "VALUE" parameter. If the value type of a property is one of the
1355 alternate valid types, then it MUST be explicitly specified with the
1356 "VALUE" parameter.
1358 3.3.1. Binary
1360 Value Name: BINARY
1362 Purpose: This value type is used to identify properties that contain
1363 a character encoding of inline binary data. For example, an
1364 inline attachment of an object code might be included in an
1365 iCalendar object.
1367 Format Definition: The value type is defined by the following
1368 notation:
1370 binary = *(4b-char) [b-end]
1371 ; A "BASE64" encoded character string, as defined by
1372 [RFC4648]
1373 .
1375 b-end = (2b-char "==") / (3b-char "=")
1377 b-char = ALPHA / DIGIT / "+" / "/"
1379 Description: Property values with this value type MUST also include
1380 the inline encoding parameter sequence of ";ENCODING=BASE64".
1381 That is, all inline binary data MUST first be character encoded
1382 using the "BASE64" encoding method defined in [RFC2045]. No
1383 additional content value encoding (i.e., BACKSLASH character
1384 encoding) is defined for this value type.
1386 Example: The following is an abridged example of a "BASE64" encoded
1387 binary value data.
1389 ATTACH;VALUE=BINARY;ENCODING=BASE64:MIICajCCAdOgAwIBAgICBEUwDQY
1390 JKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlI
1391 ENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZv
1392 <...remainder of "BASE64" encoded binary data...>
1394 3.3.2. Boolean
1396 Value Name: BOOLEAN
1398 Purpose: This value type is used to identify properties that contain
1399 either a "TRUE" or "FALSE" Boolean value.
1401 Format Definition: The value type is defined by the following
1402 notation:
1404 boolean = "TRUE" / "FALSE"
1406 Description: These values are case insensitive text. No additional
1407 content value encoding (i.e., BACKSLASH character encoding) is
1408 defined for this value type.
1410 Example: The following is an example of a hypothetical property that
1411 has a BOOLEAN value type:
1413 GIBBERISH:TRUE
1415 3.3.3. Calendar User Address
1417 Value Name: CAL-ADDRESS
1419 Purpose: This value type is used to identify properties that contain
1420 a calendar user address.
1422 Format Definition: The value type is defined by the following
1423 notation:
1425 cal-address = uri
1427 Description: The value is a URI as defined by [RFC3986] or any other
1428 IANA registered form for a URI. When used to address an Internet
1429 email transport address for a calendar user, the value MUST be a
1430 MAILTO URI, as defined by [RFC2368] . No additional content value
1431 encoding (i.e., BACKSLASH character encoding) is defined for this
1432 value type.
1434 Example:
1436 ATTENDEE:MAILTO:jane_doe@example.com
1438 3.3.4. Date
1440 Value Name: DATE
1442 Purpose: This value type is used to identify values that contain a
1443 calendar date.
1445 Format Definition: The value type is defined by the following
1446 notation:
1448 date = date-value
1450 date-value = date-fullyear date-month date-mday
1451 date-fullyear = 4DIGIT
1452 date-month = 2DIGIT ;01-12
1453 date-mday = 2DIGIT ;01-28, 01-29, 01-30, 01-31
1454 ;based on month/year
1456 Description: If the property permits, multiple "date" values are
1457 specified as a COMMA character (US-ASCII decimal 44) separated
1458 list of values. The format for the value type is expressed as the
1459 [ISO.8601.1988] complete representation, basic format for a
1460 calendar date. The textual format specifies a four-digit year,
1461 two-digit month, and two-digit day of the month. There are no
1462 separator characters between the year, month and day component
1463 text.
1465 No additional content value encoding (i.e., BACKSLASH character
1466 encoding) is defined for this value type.
1468 Example: The following represents July 14, 1997:
1470 19970714
1472 3.3.5. Date-Time
1474 Value Name: DATE-TIME
1476 Purpose: This value type is used to identify values that specify a
1477 precise calendar date and time of day.
1479 Format Definition: The value type is defined by the following
1480 notation:
1482 date-time = date "T" time ;As specified in the date and time
1483 ;value definitions
1485 Description: If the property permits, multiple "date-time" values are
1486 specified as a COMMA character (US-ASCII decimal 44) separated
1487 list of values. No additional content value encoding (i.e.,
1488 BACKSLASH character encoding) is defined for this value type.
1490 The "DATE-TIME" data type is used to identify values that contain
1491 a precise calendar date and time of day. The format is based on
1492 the [ISO.8601.1988] complete representation, basic format for a
1493 calendar date and time of day. The text format is a concatenation
1494 of the "date", followed by the LATIN CAPITAL LETTER T character
1495 (US-ASCII decimal 84) time designator, followed by the "time"
1496 format.
1498 The "DATE-TIME" data type expresses time values in three forms:
1500 The form of date and time with UTC offset MUST NOT be used. For
1501 example, the following is not valid for a date-time value:
1503 DTSTART:19980119T230000-0800 ;Invalid time format
1505 FORM #1: DATE WITH LOCAL TIME
1507 The date with local time form is simply a date-time value that
1508 does not contain the UTC designator nor does it reference a time
1509 zone. For example, the following represents January 18, 1998, at
1510 11 PM:
1512 DTSTART:19980118T230000
1514 Date-time values of this type are said to be "floating" and are
1515 not bound to any time zone in particular. They are used to
1516 represent the same hour, minute, and second value regardless of
1517 which time zone is currently being observed. For example, an
1518 event can be defined that indicates that an individual will be
1519 busy from 11:00 AM to 1:00 PM every day, no matter which time zone
1520 the person is in. In these cases, a local time can be specified.
1521 The recipient of an iCalendar object with a property value
1522 consisting of a local time, without any relative time zone
1523 information, SHOULD interpret the value as being fixed to whatever
1524 time zone the ATTENDEE is in at any given moment. This means that
1525 two ATTENDEEs, in different time zones, receiving the same event
1526 definition as a floating time, may be participating in the event
1527 at different actual times. Floating time SHOULD only be used
1528 where that is the reasonable behavior.
1530 In most cases, a fixed time is desired. To properly communicate a
1531 fixed time in a property value, either UTC time or local time with
1532 time zone reference MUST be specified.
1534 The use of local time in a DATE-TIME value without the TZID
1535 property parameter is to be interpreted as floating time,
1536 regardless of the existence of "VTIMEZONE" calendar components in
1537 the iCalendar object.
1539 FORM #2: DATE WITH UTC TIME
1541 The date with UTC time, or absolute time, is identified by a LATIN
1542 CAPITAL LETTER Z suffix character (US-ASCII decimal 90), the UTC
1543 designator, appended to the time value. For example, the
1544 following represents January 19, 1998, at 0700 UTC:
1546 DTSTART:19980119T070000Z
1548 The TZID property parameter MUST NOT be applied to DATE-TIME
1549 properties whose time values are specified in UTC.
1551 FORM #3: DATE WITH LOCAL TIME AND TIME ZONE REFERENCE
1553 The date and local time with reference to time zone information is
1554 identified by the use the TZID property parameter to reference the
1555 appropriate time zone definition. TZID is discussed in detail in
1556 Section 3.2.19 . For example, the following represents 2 AM in
1557 New York on Janurary 19, 1998:
1559 DTSTART;TZID=US-Eastern:19980119T020000
1561 Example: The following represents July 14, 1997, at 1:30 PM in New
1562 York City in each of the three time formats, using the "DTSTART"
1563 property.
1565 DTSTART:19970714T133000 ;Local time
1566 DTSTART:19970714T173000Z ;UTC time
1567 DTSTART;TZID=US-Eastern:19970714T133000 ;Local time and time
1568 ; zone reference
1570 A time value MUST ONLY specify 60 seconds when specifying the
1571 periodic "leap second" in the time value. For example:
1573 COMPLETED:19970630T235960Z
1575 3.3.6. Duration
1577 Value Name: DURATION
1579 Purpose: This value type is used to identify properties that contain
1580 a duration of time.
1582 Format Definition: The value type is defined by the following
1583 notation:
1585 dur-value = (["+"] / "-") "P" (dur-date / dur-time / dur-week)
1587 dur-date = dur-day [dur-time]
1588 dur-time = "T" (dur-hour / dur-minute / dur-second)
1589 dur-week = 1*DIGIT "W"
1590 dur-hour = 1*DIGIT "H" [dur-minute]
1591 dur-minute = 1*DIGIT "M" [dur-second]
1592 dur-second = 1*DIGIT "S"
1593 dur-day = 1*DIGIT "D"
1595 Description: If the property permits, multiple "duration" values are
1596 specified by a COMMA character (US-ASCII decimal 44) separated
1597 list of values. The format is expressed as the [ISO.8601.1988]
1598 basic format for the duration of time. The format can represent
1599 durations in terms of weeks, days, hours, minutes, and seconds.
1601 No additional content value encoding (i.e., BACKSLASH character
1602 encoding) are defined for this value type.
1604 Example: A duration of 15 days, 5 hours and 20 seconds would be:
1606 P15DT5H0M20S
1608 A duration of 7 weeks would be:
1610 P7W
1612 3.3.7. Float
1614 Value Name: FLOAT
1616 Purpose: This value type is used to identify properties that contain
1617 a real number value.
1619 Format Definition: The value type is defined by the following
1620 notation:
1622 float = (["+"] / "-") 1*DIGIT ["." 1*DIGIT]
1624 Description: If the property permits, multiple "float" values are
1625 specified by a COMMA character (US-ASCII decimal 44) separated
1626 list of values.
1628 No additional content value encoding (i.e., BACKSLASH character
1629 encoding) is defined for this value type.
1631 Example:
1633 1000000.0000001
1634 1.333
1635 -3.14
1637 3.3.8. Integer
1639 Value Name: INTEGER
1641 Purpose: This value type is used to identify properties that contain
1642 a signed integer value.
1644 Format Definition: The value type is defined by the following
1645 notation:
1647 integer = (["+"] / "-") 1*DIGIT
1649 Description: If the property permits, multiple "integer" values are
1650 specified by a COMMA character (US-ASCII decimal 44) separated
1651 list of values. The valid range for "integer" is -2147483648 to
1652 2147483647. If the sign is not specified, then the value is
1653 assumed to be positive.
1655 No additional content value encoding (i.e., BACKSLASH character
1656 encoding) is defined for this value type.
1658 Example:
1660 1234567890
1661 -1234567890
1662 +1234567890
1663 432109876
1665 3.3.9. Period of Time
1667 Value Name: PERIOD
1668 Purpose: This value type is used to identify values that contain a
1669 precise period of time.
1671 Format Definition: The value type is defined by the following
1672 notation:
1674 period = period-explicit / period-start
1676 period-explicit = date-time "/" date-time
1677 ; [ISO.8601.1988] complete representation basic format for a
1678 ; period of time consisting of a start and end. The start MUST
1679 ; be before the end.
1681 period-start = date-time "/" dur-value
1682 ; [ISO.8601.1988] complete representation basic format for a
1683 ; period of time consisting of a start and positive duration
1684 ; of time.
1686 Description: If the property permits, multiple "period" values are
1687 specified by a COMMA character (US-ASCII decimal 44) separated
1688 list of values. There are two forms of a period of time. First,
1689 a period of time is identified by its start and its end. This
1690 format is expressed as the [ISO.8601.1988] complete
1691 representation, basic format for "DATE-TIME" start of the period,
1692 followed by a SOLIDUS character (US-ASCII decimal 47), followed by
1693 the "DATE-TIME" of the end of the period. The start of the period
1694 MUST be before the end of the period. Second, a period of time
1695 can also be defined by a start and a positive duration of time.
1696 The format is expressed as the [ISO.8601.1988] complete
1697 representation, basic format for the "DATE-TIME" start of the
1698 period, followed by a SOLIDUS character (US-ASCII decimal 47),
1699 followed by the [ISO.8601.1988] basic format for "DURATION" of the
1700 period.
1702 Example: The period starting at 18:00:00 UTC, on January 1, 1997 and
1703 ending at 07:00:00 UTC on January 2, 1997 would be:
1705 19970101T180000Z/19970102T070000Z
1707 The period start at 18:00:00 on January 1, 1997 and lasting 5
1708 hours and 30 minutes would be:
1710 19970101T180000Z/PT5H30M
1712 No additional content value encoding (i.e., BACKSLASH character
1713 encoding) is defined for this value type.
1715 3.3.10. Recurrence Rule
1717 Value Name: RECUR
1719 Purpose: This value type is used to identify properties that contain
1720 a recurrence rule specification.
1722 Format Definition: The value type is defined by the following
1723 notation:
1725 recur = "FREQ" "=" freq *(
1727 ; either UNTIL or COUNT may appear in a 'recur',
1728 ; but UNTIL and COUNT MUST NOT occur in the same
1729 ; 'recur'
1731 ( ";" "UNTIL" "=" enddate ) /
1732 ( ";" "COUNT" "=" 1*DIGIT ) /
1734 ; the rest of these keywords are optional,
1735 ; but MUST NOT occur more than once
1737 ( ";" "INTERVAL" "=" 1*DIGIT ) /
1738 ( ";" "BYSECOND" "=" byseclist ) /
1739 ( ";" "BYMINUTE" "=" byminlist ) /
1740 ( ";" "BYHOUR" "=" byhrlist ) /
1741 ( ";" "BYDAY" "=" bywdaylist ) /
1742 ( ";" "BYMONTHDAY" "=" bymodaylist ) /
1743 ( ";" "BYYEARDAY" "=" byyrdaylist ) /
1744 ( ";" "BYWEEKNO" "=" bywknolist ) /
1745 ( ";" "BYMONTH" "=" bymolist ) /
1746 ( ";" "BYSETPOS" "=" bysplist ) /
1747 ( ";" "WKST" "=" weekday ) /
1748 ( ";" x-name "=" text )
1749 )
1751 freq = "SECONDLY" / "MINUTELY" / "HOURLY" / "DAILY"
1752 / "WEEKLY" / "MONTHLY" / "YEARLY"
1754 enddate = date
1755 / date-time ;A UTC value
1757 byseclist = seconds / ( seconds *("," seconds) )
1759 seconds = DIGIT / 2DIGIT ;0 to 59
1761 byminlist = minutes / ( minutes *("," minutes) )
1762 minutes = DIGIT / 2DIGIT ;0 to 59
1764 byhrlist = hour / ( hour *("," hour) )
1766 hour = DIGIT / 2DIGIT ;0 to 23
1768 bywdaylist = weekdaynum / ( weekdaynum *("," weekdaynum) )
1770 weekdaynum = [([plus] ordwk / minus ordwk)] weekday
1772 plus = "+"
1774 minus = "-"
1776 ordwk = DIGIT / 2DIGIT ;1 to 53
1778 weekday = "SU" / "MO" / "TU" / "WE" / "TH" / "FR" / "SA"
1779 ;Corresponding to SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY,
1780 ;FRIDAY, and SATURDAY days of the week.
1782 bymodaylist = monthdaynum / ( monthdaynum *("," monthdaynum) )
1784 monthdaynum = ([plus] ordmoday) / (minus ordmoday)
1786 ordmoday = DIGIT / 2DIGIT ;1 to 31
1788 byyrdaylist = yeardaynum / ( yeardaynum *("," yeardaynum) )
1790 yeardaynum = ([plus] ordyrday) / (minus ordyrday)
1792 ordyrday = DIGIT / 2DIGIT / 3DIGIT ;1 to 366
1794 bywknolist = weeknum / ( weeknum *("," weeknum) )
1796 weeknum = ([plus] ordwk) / (minus ordwk)
1798 bymolist = monthnum / ( monthnum *("," monthnum) )
1800 monthnum = DIGIT / 2DIGIT ;1 to 12
1802 bysplist = setposday / ( setposday *("," setposday) )
1804 setposday = yeardaynum
1806 Description: The value type is a structured value consisting of a
1807 list of one or more recurrence grammar parts. Each rule part is
1808 defined by a NAME=VALUE pair. The rule parts are separated from
1809 each other by the SEMICOLON character (US-ASCII decimal 59). The
1810 rule parts are not ordered in any particular sequence. Individual
1811 rule parts MUST only be specified once.
1813 The FREQ rule part identifies the type of recurrence rule. This
1814 rule part MUST be specified in the recurrence rule. Valid values
1815 include SECONDLY, to specify repeating events based on an interval
1816 of a second or more; MINUTELY, to specify repeating events based
1817 on an interval of a minute or more; HOURLY, to specify repeating
1818 events based on an interval of an hour or more; DAILY, to specify
1819 repeating events based on an interval of a day or more; WEEKLY, to
1820 specify repeating events based on an interval of a week or more;
1821 MONTHLY, to specify repeating events based on an interval of a
1822 month or more; and YEARLY, to specify repeating events based on an
1823 interval of a year or more.
1825 The INTERVAL rule part contains a positive integer representing
1826 how often the recurrence rule repeats. The default value is "1",
1827 meaning every second for a SECONDLY rule, or every minute for a
1828 MINUTELY rule, every hour for an HOURLY rule, every day for a
1829 DAILY rule, every week for a WEEKLY rule, every month for a
1830 MONTHLY rule and every year for a YEARLY rule.
1832 The UNTIL rule part defines a date-time value which bounds the
1833 recurrence rule in an inclusive manner. If the value specified by
1834 UNTIL is synchronized with the specified recurrence, this date or
1835 date-time becomes the last instance of the recurrence. If
1836 specified as a date-time value, then it MUST be specified in a UTC
1837 time format. If not present, and the COUNT rule part is also not
1838 present, the RRULE is considered to repeat forever.
1840 The COUNT rule part defines the number of occurrences at which to
1841 range-bound the recurrence. The "DTSTART" property value always
1842 counts as the first occurrence.
1844 The BYSECOND rule part specifies a COMMA character (US-ASCII
1845 decimal 44) separated list of seconds within a minute. Valid
1846 values are 0 to 59. The BYMINUTE rule part specifies a COMMA
1847 character (US-ASCII decimal 44) separated list of minutes within
1848 an hour. Valid values are 0 to 59. The BYHOUR rule part
1849 specifies a COMMA character (US-ASCII decimal 44) separated list
1850 of hours of the day. Valid values are 0 to 23.
1852 The BYDAY rule part specifies a COMMA character (US-ASCII decimal
1853 44) separated list of days of the week; MO indicates Monday; TU
1854 indicates Tuesday; WE indicates Wednesday; TH indicates Thursday;
1855 FR indicates Friday; SA indicates Saturday; SU indicates Sunday.
1857 Each BYDAY value can also be preceded by a positive (+n) or
1858 negative (-n) integer. If present, this indicates the nth
1859 occurrence of the specific day within the MONTHLY or YEARLY RRULE.
1860 For example, within a MONTHLY rule, +1MO (or simply 1MO)
1861 represents the first Monday within the month, whereas -1MO
1862 represents the last Monday of the month. If an integer modifier
1863 is not present, it means all days of this type within the
1864 specified frequency. For example, within a MONTHLY rule, MO
1865 represents all Mondays within the month.
1867 The BYMONTHDAY rule part specifies a COMMA character (US-ASCII
1868 decimal 44) separated list of days of the month. Valid values are
1869 1 to 31 or -31 to -1. For example, -10 represents the tenth to
1870 the last day of the month.
1872 The BYYEARDAY rule part specifies a COMMA character (US-ASCII
1873 decimal 44) separated list of days of the year. Valid values are
1874 1 to 366 or -366 to -1. For example, -1 represents the last day
1875 of the year (December 31st) and -306 represents the 306th to the
1876 last day of the year (March 1st).
1878 The BYWEEKNO rule part specifies a COMMA character (US-ASCII
1879 decimal 44) separated list of ordinals specifying weeks of the
1880 year. Valid values are 1 to 53 or -53 to -1. This corresponds to
1881 weeks according to week numbering as defined in [ISO.8601.1988].
1882 A week is defined as a seven day period, starting on the day of
1883 the week defined to be the week start (see WKST). Week number one
1884 of the calendar year is the first week which contains at least
1885 four (4) days in that calendar year. This rule part is only valid
1886 for YEARLY rules. For example, 3 represents the third week of the
1887 year.
1889 Note: Assuming a Monday week start, week 53 can only occur when
1890 Thursday is January 1 or if it is a leap year and Wednesday is
1891 January 1.
1893 The BYMONTH rule part specifies a COMMA character (US-ASCII
1894 decimal 44) separated list of months of the year. Valid values
1895 are 1 to 12.
1897 The WKST rule part specifies the day on which the workweek starts.
1898 Valid values are MO, TU, WE, TH, FR, SA and SU. This is
1899 significant when a WEEKLY RRULE has an interval greater than 1,
1900 and a BYDAY rule part is specified. This is also significant when
1901 in a YEARLY RRULE when a BYWEEKNO rule part is specified. The
1902 default value is MO.
1904 The BYSETPOS rule part specifies a COMMA character (US-ASCII
1905 decimal 44) separated list of values which corresponds to the nth
1906 occurrence within the set of events specified by the rule. Valid
1907 values are 1 to 366 or -366 to -1. It MUST only be used in
1908 conjunction with another BYxxx rule part. For example "the last
1909 work day of the month" could be represented as:
1911 RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1
1913 Each BYSETPOS value can include a positive (+n) or negative (-n)
1914 integer. If present, this indicates the nth occurrence of the
1915 specific occurrence within the set of occurences specified by the
1916 rule.
1918 If BYxxx rule part values are found which are beyond the available
1919 scope (ie, BYMONTHDAY=30 in February), they are simply ignored.
1921 Information, not contained in the rule, necessary to determine the
1922 various recurrence instance start time and dates are derived from
1923 the Start Time (DTSTART) entry attribute. For example,
1924 "FREQ=YEARLY;BYMONTH=1" doesn't specify a specific day within the
1925 month or a time. This information would be the same as what is
1926 specified for DTSTART.
1928 BYxxx rule parts modify the recurrence in some manner. BYxxx rule
1929 parts for a period of time which is the same or greater than the
1930 frequency generally reduce or limit the number of occurrences of
1931 the recurrence generated. For example, "FREQ=DAILY;BYMONTH=1"
1932 reduces the number of recurrence instances from all days (if
1933 BYMONTH rule part is not present) to all days in January. BYxxx
1934 rule parts for a period of time less than the frequency generally
1935 increase or expand the number of occurrences of the recurrence.
1936 For example, "FREQ=YEARLY;BYMONTH=1,2" increases the number of
1937 days within the yearly recurrence set from 1 (if BYMONTH rule part
1938 is not present) to 2.
1940 If multiple BYxxx rule parts are specified, then after evaluating
1941 the specified FREQ and INTERVAL rule parts, the BYxxx rule parts
1942 are applied to the current set of evaluated occurrences in the
1943 following order: BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY, BYDAY,
1944 BYHOUR, BYMINUTE, BYSECOND and BYSETPOS; then COUNT and UNTIL are
1945 evaluated.
1947 Here is an example of evaluating multiple BYxxx rule parts.
1949 DTSTART;TZID=US-Eastern:19970105T083000
1950 RRULE:FREQ=YEARLY;INTERVAL=2;BYMONTH=1;BYDAY=SU;BYHOUR=8,9;
1951 BYMINUTE=30
1953 First, the "INTERVAL=2" would be applied to "FREQ=YEARLY" to
1954 arrive at "every other year". Then, "BYMONTH=1" would be applied
1955 to arrive at "every January, every other year". Then, "BYDAY=SU"
1956 would be applied to arrive at "every Sunday in January, every
1957 other year". Then, "BYHOUR=8,9" would be applied to arrive at
1958 "every Sunday in January at 8 AM and 9 AM, every other year".
1959 Then, "BYMINUTE=30" would be applied to arrive at "every Sunday in
1960 January at 8:30 AM and 9:30 AM, every other year". Then, lacking
1961 information from RRULE, the second is derived from DTSTART, to end
1962 up in "every Sunday in January at 8:30:00 AM and 9:30:00 AM, every
1963 other year". Similarly, if the BYMINUTE, BYHOUR, BYDAY,
1964 BYMONTHDAY or BYMONTH rule part were missing, the appropriate
1965 minute, hour, day or month would have been retrieved from the
1966 "DTSTART" property.
1968 No additional content value encoding (i.e., BACKSLASH character
1969 encoding) is defined for this value type.
1971 Example: The following is a rule which specifies 10 occurences which
1972 occur every other day:
1974 FREQ=DAILY;COUNT=10;INTERVAL=2
1976 There are other examples specified in the "RRULE" specification.
1978 3.3.11. Text
1980 Value Name: TEXT
1982 Purpose: This value type is used to identify values that contain
1983 human readable text.
1985 Format Definition: The value type is defined by the following
1986 notation.
1988 text = *(TSAFE-CHAR / ":" / DQUOTE / ESCAPED-CHAR)
1989 ; Folded according to description above
1991 ESCAPED-CHAR = ("\\" / "\;" / "\," / "\N" / "\n")
1992 ; \\ encodes \, \N or \n encodes newline
1993 ; \; encodes ;, \, encodes ,
1995 TSAFE-CHAR = %x20-21 / %x23-2B / %x2D-39 / %x3C-5B /
1996 %x5D-7E / NON-US-ASCII
1997 ; Any character except CTLs not needed by the current
1998 ; character set, DQUOTE, ";", ":", "\", ","
2000 Note: Certain other character sets may require modification of
2001 the above definitions, but this is beyond the scope of this
2002 document.
2004 Description: If the property permits, multiple "text" values are
2005 specified by a COMMA character (US-ASCII decimal 44) separated
2006 list of values.
2008 The language in which the text is represented can be controlled by
2009 the "LANGUAGE" property parameter.
2011 An intentional formatted text line break MUST only be included in
2012 a "TEXT" property value by representing the line break with the
2013 character sequence of BACKSLASH (US-ASCII decimal 92), followed by
2014 a LATIN SMALL LETTER N (US-ASCII decimal 110) or a LATIN CAPITAL
2015 LETTER N (US-ASCII decimal 78), that is "\n" or "\N".
2017 The "TEXT" property values may also contain special characters
2018 that are used to signify delimiters, such as a COMMA character for
2019 lists of values or a SEMICOLON character for structured values.
2020 In order to support the inclusion of these special characters in
2021 "TEXT" property values, they MUST be escaped with a BACKSLASH
2022 character. A BACKSLASH character (US-ASCII decimal 92) in a
2023 "TEXT" property value MUST be escaped with another BACKSLASH
2024 character. A COMMA character in a "TEXT" property value MUST be
2025 escaped with a BACKSLASH character (US-ASCII decimal 92). A
2026 SEMICOLON character in a "TEXT" property value MUST be escaped
2027 with a BACKSLASH character (US-ASCII decimal 92). However, a
2028 COLON character in a "TEXT" property value SHALL NOT be escaped
2029 with a BACKSLASH character.
2031 Example: A multiple line value of:
2033 Project XYZ Final Review
2034 Conference Room - 3B
2035 Come Prepared.
2037 would be represented as:
2039 Project XYZ Final Review\nConference Room - 3B\nCome Prepared.
2041 3.3.12. Time
2043 Value Name: TIME
2045 Purpose: This value type is used to identify values that contain a
2046 time of day.
2048 Format Definition: The data type is defined by the following
2049 notation:
2051 time = time-hour time-minute time-second [time-utc]
2053 time-hour = 2DIGIT ;00-23
2054 time-minute = 2DIGIT ;00-59
2055 time-second = 2DIGIT ;00-60
2056 ;The "60" value is used to account for "leap" seconds.
2058 time-utc = "Z"
2060 Description: If the property permits, multiple "time" values are
2061 specified by a COMMA character (US-ASCII decimal 44) separated
2062 list of values. No additional content value encoding (i.e.,
2063 BACKSLASH character encoding) is defined for this value type.
2065 The "TIME" data type is used to identify values that contain a
2066 time of day. The format is based on the [ISO.8601.1988] complete
2067 representation, basic format for a time of day. The text format
2068 consists of a two-digit 24-hour of the day (i.e., values 0-23),
2069 two- digit minute in the hour (i.e., values 0-59), and two-digit
2070 seconds in the minute (i.e., values 0-60). The seconds value of
2071 60 MUST only be used to account for "leap" seconds. Fractions of
2072 a second are not supported by this format.
2074 In parallel to the "DATE-TIME" definition above, the "TIME" data
2075 type expresses time values in three forms:
2077 The form of time with UTC offset MUST NOT be used. For example,
2078 the following is NOT VALID for a time value:
2080 230000-0800 ;Invalid time format
2082 FORM #1 LOCAL TIME
2084 The local time form is simply a time value that does not contain
2085 the UTC designator nor does it reference a time zone. For
2086 example, 11:00 PM:
2088 230000
2090 Time values of this type are said to be "floating" and are not
2091 bound to any time zone in particular. They are used to represent
2092 the same hour, minute, and second value regardless of which time
2093 zone is currently being observed. For example, an event can be
2094 defined that indicates that an individual will be busy from 11:00
2095 AM to 1:00 PM every day, no matter which time zone the person is
2096 in. In these cases, a local time can be specified. The recipient
2097 of an iCalendar object with a property value consisting of a local
2098 time, without any relative time zone information, SHOULD interpret
2099 the value as being fixed to whatever time zone the ATTENDEE is in
2100 at any given moment. This means that two ATTENDEEs may
2101 participate in the same event at different UTC times; floating
2102 time SHOULD only be used where that is reasonable behavior.
2104 In most cases, a fixed time is desired. To properly communicate a
2105 fixed time in a property value, either UTC time or local time with
2106 time zone reference MUST be specified.
2108 The use of local time in a TIME value without the TZID property
2109 parameter is to be interpreted as a local time value, regardless
2110 of the existence of "VTIMEZONE" calendar components in the
2111 iCalendar object.
2113 FORM #2: UTC TIME
2115 UTC time, or absolute time, is identified by a LATIN CAPITAL
2116 LETTER Z suffix character (US-ASCII decimal 90), the UTC
2117 designator, appended to the time value. For example, the
2118 following represents 07:00 AM UTC:
2120 070000Z
2122 The TZID property parameter MUST NOT be applied to TIME properties
2123 whose time values are specified in UTC.
2125 FORM #3: LOCAL TIME AND TIME ZONE REFERENCE
2127 The local time with reference to time zone information form is
2128 identified by the use the TZID property parameter to reference the
2129 appropriate time zone definition. TZID is discussed in detail in
2130 Section 3.2.19 .
2132 Example: The following represents 8:30 AM in New York in Winter, five
2133 hours behind UTC, in each of the three formats using the "X-ABC-
2134 TIMEOFDAY" non-standard property:
2136 X-ABC-TIMEOFDAY:083000
2138 X-ABC-TIMEOFDAY:133000Z
2140 X-ABC-TIMEOFDAY;TZID=US-Eastern:083000
2142 3.3.13. URI
2144 Value Name: URI
2146 Purpose: This value type is used to identify values that contain a
2147 uniform resource identifier (URI) type of reference to the
2148 property value.
2150 Format Definition: The data type is defined by the following
2151 notation:
2153 uri =
2155 Description: This data type might be used to reference binary
2156 information, for values that are large, or otherwise undesirable
2157 to include directly in the iCalendar object.
2159 The URI value formats in RFC 1738, RFC 2111 and any other IETF
2160 registered value format can be specified.
2162 Any IANA registered URI format can be used. These include, but
2163 are not limited to, those defined in RFC 1738 and RFC 2111.
2165 When a property parameter value is a URI value type, the URI MUST
2166 be specified as a quoted-string value.
2168 No additional content value encoding (i.e., BACKSLASH character
2169 encoding) is defined for this value type.
2171 Example: The following is a URI for a network file:
2173 http://example.com/my-report.txt
2175 3.3.14. UTC Offset
2177 Value Name: UTC-OFFSET
2179 Purpose: This value type is used to identify properties that contain
2180 an offset from UTC to local time.
2182 Format Definition: The data type is defined by the following
2183 notation:
2185 utc-offset = time-numzone ;As defined above in time data type
2187 time-numzone = ("+" / "-") time-hour time-minute [time-second]
2189 Description: The PLUS SIGN (US-ASCII decimal 43) character MUST be
2190 specified for positive UTC offsets (i.e., ahead of UTC). The
2191 HYPHEN-MINUS character (US-ASCII decimal 45) MUST be specified for
2192 negative UTC offsets (i.e., behind of UTC). The value of "-0000"
2193 and "-000000" are not allowed. The time-second, if present, may
2194 not be 60; if absent, it defaults to zero.
2196 No additional content value encoding (i.e., BACKSLASH character
2197 encoding) is defined for this value type.
2199 Example: The following UTC offsets are given for standard time for
2200 New York (five hours behind UTC) and Geneva (one hour ahead of
2201 UTC):
2203 -0500
2205 +0100
2207 3.4. iCalendar Object
2209 The Calendaring and Scheduling Core Object is a collection of
2210 calendaring and scheduling information. Typically, this information
2211 will consist of a single iCalendar object. However, multiple
2212 iCalendar objects can be sequentially grouped together. The first
2213 line and last line of the iCalendar object MUST contain a pair of
2214 iCalendar object delimiter strings. The syntax for an iCalendar
2215 object is as follows:
2217 icalobject = 1*("BEGIN" ":" "VCALENDAR" CRLF
2218 icalbody
2219 "END" ":" "VCALENDAR" CRLF)
2221 The following is a simple example of an iCalendar object:
2223 BEGIN:VCALENDAR
2224 VERSION:2.0
2225 PRODID:-//hacksw/handcal//NONSGML v1.0//EN
2226 BEGIN:VEVENT
2227 UID:19970610T172345Z-AF23B2@example.com
2228 DTSTAMP:19970610T172345Z
2229 DTSTART:19970714T170000Z
2230 DTEND:19970715T035959Z
2231 SUMMARY:Bastille Day Party
2232 END:VEVENT
2233 END:VCALENDAR
2235 3.5. Property
2237 A property is the definition of an individual attribute describing a
2238 calendar object or a calendar component. A property takes the form
2239 defined by the "contentline" notation defined in Section 3.1 .
2241 The following is an example of a property:
2243 DTSTART:19960415T133000Z
2245 This memo imposes no ordering of properties within an iCalendar
2246 object.
2248 Property names, parameter names and enumerated parameter values are
2249 case insensitive. For example, the property name "DUE" is the same
2250 as "due" and "Due", DTSTART;TZID=US-Eastern:19980714T120000 is the
2251 same as DtStart;TzID=US-Eastern:19980714T120000.
2253 3.6. Calendar Components
2255 The body of the iCalendar object consists of a sequence of calendar
2256 properties and one or more calendar components. The calendar
2257 properties are attributes that apply to the calendar object as a
2258 whole. The calendar components are collections of properties that
2259 express a particular calendar semantic. For example, the calendar
2260 component can specify an event, a to-do, a journal entry, time zone
2261 information, free/busy time information, or an alarm.
2263 The body of the iCalendar object is defined by the following
2264 notation:
2266 icalbody = calprops component
2268 calprops = 2*(
2270 ; 'prodid' and 'version' are both REQUIRED,
2271 ; but MUST NOT occur more than once
2273 prodid / version /
2275 ; 'calscale' and 'method' are optional,
2276 ; but MUST NOT occur more than once
2278 calscale /
2279 method /
2281 ; 'x-prop' is OPTIONAL,
2282 ; and MAY occur more than once
2284 x-prop
2285 )
2287 component = 1*(eventc / todoc / journalc / freebusyc /
2288 timezonec / iana-comp / x-comp)
2290 iana-comp = "BEGIN" ":" iana-token CRLF
2291 1*contentline
2292 "END" ":" iana-token CRLF
2294 x-comp = "BEGIN" ":" x-name CRLF
2295 1*contentline
2296 "END" ":" x-name CRLF
2298 An iCalendar object MUST include the "PRODID" and "VERSION" calendar
2299 properties. In addition, it MUST include at least one calendar
2300 component. Special forms of iCalendar objects are possible to
2301 publish just busy time (i.e., only a "VFREEBUSY" calendar component)
2302 or time zone (i.e., only a "VTIMEZONE" calendar component)
2303 information. In addition, a complex iCalendar object is possible
2304 that is used to capture a complete snapshot of the contents of a
2305 calendar (e.g., composite of many different calendar components).
2306 More commonly, an iCalendar object will consist of just a single
2307 "VEVENT", "VTODO" or "VJOURNAL" calendar component.
2309 3.6.1. Event Component
2310 Component Name: VEVENT
2312 Purpose: Provide a grouping of component properties that describe an
2313 event.
2315 Format Definition: A "VEVENT" calendar component is defined by the
2316 following notation:
2318 eventc = "BEGIN" ":" "VEVENT" CRLF
2319 eventprop *alarmc
2320 "END" ":" "VEVENT" CRLF
2322 eventprop = 3*(
2324 ; the following are REQUIRED,
2325 ; but MUST NOT occur more than once
2327 dtstamp / dtstart / uid /
2329 ; the following are optional,
2330 ; but MUST NOT occur more than once
2332 class / created / description / geo /
2333 last-mod / location / organizer / priority /
2334 seq / status / summary / transp /
2335 url / recurid /
2337 ; the following is OPTIONAL,
2338 ; but SHOULD NOT occur more than once
2340 rrule /
2342 ; either 'dtend' or 'duration' may appear in
2343 ; a 'eventprop', but 'dtend' and 'duration'
2344 ; MUST NOT occur in the same 'eventprop'
2346 dtend / duration /
2348 ; the following are optional,
2349 ; and MAY occur more than once
2351 attach / attendee / categories / comment /
2352 contact / exdate / rstatus / related /
2353 resources / rdate / x-prop
2355 )
2357 Description: A "VEVENT" calendar component is a grouping of component
2358 properties, and possibly including "VALARM" calendar components,
2359 that represents a scheduled amount of time on a calendar. For
2360 example, it can be an activity; such as a one-hour long,
2361 department meeting from 8:00 AM to 9:00 AM, tomorrow. Generally,
2362 an event will take up time on an individual calendar. Hence, the
2363 event will appear as an opaque interval in a search for busy time.
2364 Alternately, the event can have its Time Transparency set to
2365 "TRANSPARENT" in order to prevent blocking of the event in
2366 searches for busy time.
2368 The "VEVENT" is also the calendar component used to specify an
2369 anniversary or daily reminder within a calendar. These events
2370 have a DATE value type for the "DTSTART" property instead of the
2371 default data type of DATE-TIME. If such a "VEVENT" has a "DTEND"
2372 property, it MUST be specified as a DATE value also. The
2373 anniversary type of "VEVENT" can span more than one date (i.e,
2374 "DTEND" property value is set to a calendar date after the
2375 "DTSTART" property value).
2377 The "DTSTART" property for a "VEVENT" specifies the inclusive
2378 start of the event. For recurring events, it also specifies the
2379 very first instance in the recurrence set. The "DTEND" property
2380 for a "VEVENT" calendar component specifies the non-inclusive end
2381 of the event. For cases where a "VEVENT" calendar component
2382 specifies a "DTSTART" property with a DATE data type but no
2383 "DTEND" property, the events non-inclusive end is the end of the
2384 calendar date specified by the "DTSTART" property. For cases
2385 where a "VEVENT" calendar component specifies a "DTSTART" property
2386 with a DATE-TIME data type but no "DTEND" property, the event ends
2387 on the same calendar date and time of day specified by the
2388 "DTSTART" property.
2390 The "VEVENT" calendar component cannot be nested within another
2391 calendar component. However, "VEVENT" calendar components can be
2392 related to each other or to a "VTODO" or to a "VJOURNAL" calendar
2393 component with the "RELATED-TO" property.
2395 Example: The following is an example of the "VEVENT" calendar
2396 component used to represent a meeting that will also be opaque to
2397 searches for busy time:
2399 BEGIN:VEVENT
2400 UID:19970901T130000Z-123401@example.com
2401 DTSTAMP:19970901T130000Z
2402 DTSTART:19970903T163000Z
2403 DTEND:19970903T190000Z
2404 SUMMARY:Annual Employee Review
2405 CLASS:PRIVATE
2406 CATEGORIES:BUSINESS,HUMAN RESOURCES
2407 END:VEVENT
2409 The following is an example of the "VEVENT" calendar component
2410 used to represent a reminder that will not be opaque, but rather
2411 transparent, to searches for busy time:
2413 BEGIN:VEVENT
2414 UID:19970901T130000Z-123402@example.com
2415 DTSTAMP:19970901T130000Z
2416 DTSTART:19970401T163000Z
2417 DTEND:19970402T010000Z
2418 SUMMARY:Laurel is in sensitivity awareness class.
2419 CLASS:PUBLIC
2420 CATEGORIES:BUSINESS,HUMAN RESOURCES
2421 TRANSP:TRANSPARENT
2422 END:VEVENT
2424 The following is an example of the "VEVENT" calendar component
2425 used to represent an anniversary that will occur annually. Since
2426 it takes up no time, it will not appear as opaque in a search for
2427 busy time; no matter what the value of the "TRANSP" property
2428 indicates:
2430 BEGIN:VEVENT
2431 UID:19970901T130000Z-123403@example.com
2432 DTSTAMP:19970901T130000Z
2433 DTSTART;VALUE=DATE:19971102
2434 SUMMARY:Our Blissful Anniversary
2435 CLASS:CONFIDENTIAL
2436 CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION
2437 RRULE:FREQ=YEARLY
2438 END:VEVENT
2440 3.6.2. To-do Component
2442 Component Name: VTODO
2443 Purpose: Provide a grouping of calendar properties that describe a
2444 to-do.
2446 Format Definition: A "VTODO" calendar component is defined by the
2447 following notation:
2449 todoc = "BEGIN" ":" "VTODO" CRLF
2450 todoprop *alarmc
2451 "END" ":" "VTODO" CRLF
2453 todoprop = 2*(
2455 ; the following are REQUIRED,
2456 ; but MUST NOT occur more than once
2458 dtstamp / uid /
2460 ; the following are optional,
2461 ; but MUST NOT occur more than once
2463 class / completed / created / description /
2464 dtstart / geo / last-mod / location / organizer /
2465 percent / priority / recurid / seq / status /
2466 summary / url /
2468 ; the following is OPTIONAL,
2469 ; but SHOULD NOT occur more than once
2471 rrule /
2473 ; either 'due' or 'duration' may appear in
2474 ; a 'todoprop', but 'due' and 'duration'
2475 ; MUST NOT occur in the same 'todoprop'
2477 due / duration /
2479 ; the following are optional,
2480 ; and MAY occur more than once
2482 attach / attendee / categories / comment / contact /
2483 exdate / rstatus / related / resources /
2484 rdate / x-prop
2486 )
2488 Description: A "VTODO" calendar component is a grouping of component
2489 properties and possibly "VALARM" calendar components that
2490 represent an action-item or assignment. For example, it can be
2491 used to represent an item of work assigned to an individual; such
2492 as "turn in travel expense today".
2494 The "VTODO" calendar component cannot be nested within another
2495 calendar component. However, "VTODO" calendar components can be
2496 related to each other or to a "VEVENT" or to a "VJOURNAL" calendar
2497 component with the "RELATED-TO" property.
2499 A "VTODO" calendar component without the "DTSTART" and "DUE" (or
2500 "DURATION") properties specifies a to-do that will be associated
2501 with each successive calendar date, until it is completed.
2503 Example: The following is an example of a "VTODO" calendar component:
2505 BEGIN:VTODO
2506 UID:19970901T130000Z-123404@example.com
2507 DTSTAMP:19970901T130000Z
2508 DTSTART:19970415T133000Z
2509 DUE:19970416T045959Z
2510 SUMMARY:1996 Income Tax Preparation
2511 CLASS:CONFIDENTIAL
2512 CATEGORIES:FAMILY,FINANCE
2513 PRIORITY:1
2514 STATUS:NEEDS-ACTION
2515 END:VTODO
2517 3.6.3. Journal Component
2519 Component Name: VJOURNAL
2521 Purpose: Provide a grouping of component properties that describe a
2522 journal entry.
2524 Format Definition: A "VJOURNAL" calendar component is defined by the
2525 following notation:
2527 journalc = "BEGIN" ":" "VJOURNAL" CRLF
2528 jourprop
2529 "END" ":" "VJOURNAL" CRLF
2531 jourprop = 1*(
2533 ; the following are REQUIRED,
2534 ; but MUST NOT occur more than once
2536 dtstamp / uid /
2538 ; the following are optional,
2539 ; but MUST NOT occur more than once
2541 class / created / description / dtstart /
2542 last-mod / organizer / recurid / seq /
2543 status / summary / url /
2545 ; the following is OPTIONAL,
2546 ; but SHOULD NOT occur more than once
2548 rrule /
2550 ; the following are optional,
2551 ; and MAY occur more than once
2553 attach / attendee / categories / comment /
2554 contact / exdate / related / rdate /
2555 rstatus / x-prop
2556 )
2558 Description: A "VJOURNAL" calendar component is a grouping of
2559 component properties that represent one or more descriptive text
2560 notes associated with a particular calendar date. The "DTSTART"
2561 property is used to specify the calendar date that the journal
2562 entry is associated with. Generally, it will have a DATE value
2563 data type, but it can also be used to specify a DATE-TIME value
2564 data type. Examples of a journal entry include a daily record of
2565 a legislative body or a journal entry of individual telephone
2566 contacts for the day or an ordered list of accomplishments for the
2567 day. The "VJOURNAL" calendar component can also be used to
2568 associate a document with a calendar date.
2570 The "VJOURNAL" calendar component does not take up time on a
2571 calendar. Hence, it does not play a role in free or busy time
2572 searches - - it is as though it has a time transparency value of
2573 TRANSPARENT. It is transparent to any such searches.
2575 The "VJOURNAL" calendar component cannot be nested within another
2576 calendar component. However, "VJOURNAL" calendar components can
2577 be related to each other or to a "VEVENT" or to a "VTODO" calendar
2578 component, with the "RELATED-TO" property.
2580 Example: The following is an example of the "VJOURNAL" calendar
2581 component:
2583 BEGIN:VJOURNAL
2584 UID:19970901T130000Z-123405@example.com
2585 DTSTAMP:19970901T130000Z
2586 DTSTART;VALUE=DATE:19970317
2587 SUMMARY:Staff meeting minutes
2588 DESCRIPTION:1. Staff meeting: Participants include Joe\, Lisa
2589 and Bob. Aurora project plans were reviewed. There is currentl
2590 y no budget reserves for this project. Lisa will escalate to
2591 management. Next meeting on Tuesday.\n
2592 2. Telephone Conference: ABC Corp. sales representative called
2593 to discuss new printer. Promised to get us a demo by Friday.\n
2594 3. Henry Miller (Handsoff Insurance): Car was totaled by tree.
2595 Is looking into a loaner car. 654-2323 (tel).
2596 END:VJOURNAL
2598 3.6.4. Free/Busy Component
2600 Component Name: VFREEBUSY
2602 Purpose: Provide a grouping of component properties that describe
2603 either a request for free/busy time, describe a response to a
2604 request for free/busy time or describe a published set of busy
2605 time.
2607 Format Definition: A "VFREEBUSY" calendar component is defined by the
2608 following notation:
2610 freebusyc = "BEGIN" ":" "VFREEBUSY" CRLF
2611 fbprop
2612 "END" ":" "VFREEBUSY" CRLF
2614 fbprop = *(
2616 ; the following are optional,
2617 ; but MUST NOT occur more than once
2619 contact / dtstart / dtend / duration / dtstamp /
2620 organizer / uid / url /
2622 ; the following are optional,
2623 ; and MAY occur more than once
2625 attendee / comment / freebusy / rstatus / x-prop
2626 )
2628 Description: A "VFREEBUSY" calendar component is a grouping of
2629 component properties that represents either a request for, a reply
2630 to a request for free or busy time information or a published set
2631 of busy time information.
2633 When used to request free/busy time information, the "ATTENDEE"
2634 property specifies the calendar users whose free/busy time is
2635 being requested; the "ORGANIZER" property specifies the calendar
2636 user who is requesting the free/busy time; the "DTSTART" and
2637 "DTEND" properties specify the window of time for which the free/
2638 busy time is being requested; the "UID" and "DTSTAMP" properties
2639 are specified to assist in proper sequencing of multiple free/busy
2640 time requests.
2642 When used to reply to a request for free/busy time, the "ATTENDEE"
2643 property specifies the calendar user responding to the free/busy
2644 time request; the "ORGANIZER" property specifies the calendar user
2645 that originally requested the free/busy time; the "FREEBUSY"
2646 property specifies the free/busy time information (if it exists);
2647 and the "UID" and "DTSTAMP" properties are specified to assist in
2648 proper sequencing of multiple free/busy time replies.
2650 When used to publish busy time, the "ORGANIZER" property specifies
2651 the calendar user associated with the published busy time; the
2652 "DTSTART" and "DTEND" properties specify an inclusive time window
2653 that surrounds the busy time information; the "FREEBUSY" property
2654 specifies the published busy time information; and the "DTSTAMP"
2655 property specifies the date/time that iCalendar object was
2656 created.
2658 The "VFREEBUSY" calendar component cannot be nested within another
2659 calendar component. Multiple "VFREEBUSY" calendar components can
2660 be specified within an iCalendar object. This permits the
2661 grouping of Free/Busy information into logical collections, such
2662 as monthly groups of busy time information.
2664 The "VFREEBUSY" calendar component is intended for use in
2665 iCalendar object methods involving requests for free time,
2666 requests for busy time, requests for both free and busy, and the
2667 associated replies.
2669 Free/Busy information is represented with the "FREEBUSY" property.
2670 This property provides a terse representation of time periods.
2671 One or more "FREEBUSY" properties can be specified in the
2672 "VFREEBUSY" calendar component.
2674 When present in a "VFREEBUSY" calendar component, the "DTSTART"
2675 and "DTEND" properties SHOULD be specified prior to any "FREEBUSY"
2676 properties. In a free time request, these properties can be used
2677 in combination with the "DURATION" property to represent a request
2678 for a duration of free time within a specified window of time.
2680 The recurrence properties ("RRULE", "RDATE", "EXDATE") are not
2681 permitted within a "VFREEBUSY" calendar component. Any recurring
2682 events are resolved into their individual busy time periods using
2683 the "FREEBUSY" property.
2685 Example: The following is an example of a "VFREEBUSY" calendar
2686 component used to request free or busy time information:
2688 BEGIN:VFREEBUSY
2689 ORGANIZER:MAILTO:jane_doe@example.com
2690 ATTENDEE:MAILTO:john_public@example.com
2691 DTSTART:19971015T050000Z
2692 DTEND:19971016T050000Z
2693 DTSTAMP:19970901T083000Z
2694 END:VFREEBUSY
2696 The following is an example of a "VFREEBUSY" calendar component
2697 used to reply to the request with busy time information:
2699 BEGIN:VFREEBUSY
2700 ORGANIZER:MAILTO:jane_doe@example.com
2701 ATTENDEE:MAILTO:john_public@example.com
2702 DTSTAMP:19970901T100000Z
2704 FREEBUSY:19971015T050000Z/PT8H30M,
2705 19971015T160000Z/PT5H30M,19971015T223000Z/PT6H30M
2706 URL:http://example.com/pub/busy/jpublic-01.ifb
2707 COMMENT:This iCalendar file contains busy time information for
2708 the next three months.
2709 END:VFREEBUSY
2711 The following is an example of a "VFREEBUSY" calendar component
2712 used to publish busy time information.
2714 BEGIN:VFREEBUSY
2715 ORGANIZER:jsmith@example.com
2716 DTSTART:19980313T141711Z
2717 DTEND:19980410T141711Z
2718 FREEBUSY:19980314T233000Z/19980315T003000Z
2719 FREEBUSY:19980316T153000Z/19980316T163000Z
2720 FREEBUSY:19980318T030000Z/19980318T040000Z
2721 URL:http://www.example.com/calendar/busytime/jsmith.ifb
2722 END:VFREEBUSY
2724 3.6.5. Time Zone Component
2726 Component Name: VTIMEZONE
2728 Purpose: Provide a grouping of component properties that defines a
2729 time zone.
2731 Format Definition: A "VTIMEZONE" calendar component is defined by the
2732 following notation:
2734 timezonec = "BEGIN" ":" "VTIMEZONE" CRLF
2735 2*(
2737 ; 'tzid' is required, but MUST NOT occur more
2738 ; than once
2740 tzid /
2742 ; 'last-mod' and 'tzurl' are optional,
2743 ; but MUST NOT occur more than once
2745 last-mod / tzurl /
2746 ; one of 'standardc' or 'daylightc' MUST occur
2747 ; and each MAY occur more than once.
2749 standardc / daylightc /
2751 ; the following is optional,
2752 ; and MAY occur more than once
2754 x-prop
2756 )
2758 "END" ":" "VTIMEZONE" CRLF
2760 standardc = "BEGIN" ":" "STANDARD" CRLF
2761 tzprop
2762 "END" ":" "STANDARD" CRLF
2764 daylightc = "BEGIN" ":" "DAYLIGHT" CRLF
2765 tzprop
2766 "END" ":" "DAYLIGHT" CRLF
2768 tzprop = 3*(
2770 ; the following are each REQUIRED,
2771 ; but MUST NOT occur more than once
2773 dtstart / tzoffsetto / tzoffsetfrom /
2775 ; the following is OPTIONAL,
2776 ; but SHOULD NOT occur more than once
2778 rrule /
2780 ; the following are optional,
2781 ; and MAY occur more than once
2783 comment / rdate / tzname / x-prop
2785 )
2787 Description: A time zone is unambiguously defined by the set of time
2788 measurement rules determined by the governing body for a given
2789 geographic area. These rules describe at a minimum the base
2790 offset from UTC for the time zone, often referred to as the
2791 Standard Time offset. Many locations adjust their Standard Time
2792 forward or backward by one hour, in order to accommodate seasonal
2793 changes in number of daylight hours, often referred to as Daylight
2794 Saving Time. Some locations adjust their time by a fraction of an
2795 hour. Standard Time is also known as Winter Time. Daylight
2796 Saving Time is also known as Advanced Time, Summer Time, or Legal
2797 Time in certain countries. The following table shows the changes
2798 in time zone rules in effect for New York City starting from 1967.
2799 Each line represents a description or rule for a particular
2800 observance.
2802 Effective Observance Rule
2804 +-----------+-------------------------+--------+--------------+
2805 | Date | (Date/Time) | Offset | Abbreviation |
2806 +-----------+-------------------------+--------+--------------+
2807 | 1967-* | last Sun in Oct, 02:00 | -0500 | EST |
2808 | 1967-1973 | last Sun in Apr, 02:00 | -0400 | EDT |
2809 | 1974-1974 | Jan 6, 02:00 | -0400 | EDT |
2810 | 1975-1975 | Feb 23, 02:00 | -0400 | EDT |
2811 | 1976-1986 | last Sun in Apr, 02:00 | -0400 | EDT |
2812 | 1987-* | first Sun in Apr, 02:00 | -0400 | EDT |
2813 +-----------+-------------------------+--------+--------------+
2815 Note: The specification of a global time zone registry is not
2816 addressed by this document and is left for future study.
2817 However, implementers may find the Olson time zone database
2818 [TZDB] a useful reference. It is an informal, public-domain
2819 collection of time zone information, which is currently being
2820 maintained by volunteer Internet participants, and is used in
2821 several operating systems. This database contains current and
2822 historical time zone information for a wide variety of
2823 locations around the globe; it provides a time zone identifier
2824 for every unique time zone rule set in actual use since 1970,
2825 with historical data going back to the introduction of standard
2826 time.
2828 Interoperability between two calendaring and scheduling
2829 applications, especially for recurring events, to-dos or journal
2830 entries, is dependent on the ability to capture and convey date
2831 and time information in an unambiguous format. The specification
2832 of current time zone information is integral to this behavior.
2834 If present, the "VTIMEZONE" calendar component defines the set of
2835 Standard Time and Daylight Saving Time observances (or rules) for
2836 a particular time zone for a given interval of time. The
2837 "VTIMEZONE" calendar component cannot be nested within other
2838 calendar components. Multiple "VTIMEZONE" calendar components can
2839 exist in an iCalendar object. In this situation, each "VTIMEZONE"
2840 MUST represent a unique time zone definition. This is necessary
2841 for some classes of events, such as airline flights, that start in
2842 one time zone and end in another.
2844 The "VTIMEZONE" calendar component MUST be present if the
2845 iCalendar object contains an RRULE that generates dates on both
2846 sides of a time zone shift (e.g., both in Standard Time and
2847 Daylight Saving Time) unless the iCalendar object intends to
2848 convey a floating time ( see Section 3.3.12 for proper
2849 interpretation of floating time). It can be present if the
2850 iCalendar object does not contain such a RRULE. In addition, if a
2851 RRULE is present, there MUST be valid time zone information for
2852 all recurrence instances.
2854 The "VTIMEZONE" calendar component MUST include the "TZID"
2855 property and at least one definition of a standard or daylight
2856 component. The standard or daylight component MUST include the
2857 "DTSTART", "TZOFFSETFROM" and "TZOFFSETTO" properties.
2859 An individual "VTIMEZONE" calendar component MUST be specified for
2860 each unique "TZID" parameter value specified in the iCalendar
2861 object.
2863 Each "VTIMEZONE" calendar component consists of a collection of
2864 one or more sub-components that describe the rule for a particular
2865 observance (either a Standard Time or a Daylight Saving Time
2866 observance). The "STANDARD" sub-component consists of a
2867 collection of properties that describe Standard Time. The
2868 "DAYLIGHT" sub-component consists of a collection of properties
2869 that describe Daylight Saving Time. In general this collection of
2870 properties consists of:
2872 * the first onset date-time for the observance
2874 * the last onset date-time for the observance, if a last onset is
2875 known.
2877 * the offset to be applied for the observance
2879 * a rule that describes the day and time when the observance
2880 takes effect
2882 * an optional name for the observance
2884 For a given time zone, there may be multiple unique definitions of
2885 the observances over a period of time. Each observance is
2886 described using either a "STANDARD" or "DAYLIGHT" sub-component.
2887 The collection of these sub-components is used to describe the
2888 time zone for a given period of time. The offset to apply at any
2889 given time is found by locating the observance that has the last
2890 onset date and time before the time in question, and using the
2891 offset value from that observance.
2893 The top-level properties in a "VTIMEZONE" calendar component are:
2895 The mandatory "TZID" property is a text value that uniquely
2896 identifies the "VTIMEZONE" calendar component within the scope of
2897 an iCalendar object.
2899 The optional "LAST-MODIFIED" property is a UTC value that
2900 specifies the date and time that this time zone definition was
2901 last updated.
2903 The optional "TZURL" property is a url value that points to a
2904 published VTIMEZONE definition. TZURL SHOULD refer to a resource
2905 that is accessible by anyone who might need to interpret the
2906 object. This SHOULD NOT normally be a "file" URL or other URL
2907 that is not widely-accessible.
2909 The collection of properties that are used to define the STANDARD
2910 and DAYLIGHT sub-components include:
2912 The mandatory "DTSTART" property gives the effective onset date
2913 and local time for the time zone sub-component definition.
2914 "DTSTART" in this usage MUST be specified as a local DATE-TIME
2915 value.
2917 The mandatory "TZOFFSETFROM" property gives the UTC offset which
2918 is in use when the onset of this time zone observance begins.
2919 "TZOFFSETFROM" is combined with "DTSTART" to define the effective
2920 onset for the time zone sub-component definition. For example,
2921 the following represents the time at which the observance of
2922 Standard Time took effect in Fall 1967 for New York City:
2924 DTSTART:19671029T020000
2926 TZOFFSETFROM:-0400
2928 The mandatory "TZOFFSETTO " property gives the UTC offset for the
2929 time zone sub-component (Standard Time or Daylight Saving Time)
2930 when this observance is in use.
2932 The optional "TZNAME" property is the customary name for the time
2933 zone. It may be specified multiple times, to allow for specifying
2934 multiple language variants of the time zone names. This could be
2935 used for displaying dates.
2937 If specified, the onset for the observance defined by the time
2938 zone sub-component is defined by either the "RRULE" or "RDATE"
2939 property. If neither is specified, only one sub-component can be
2940 specified in the "VTIMEZONE" calendar component and it is assumed
2941 that the single observance specified is always in effect.
2943 The "RRULE" property defines the recurrence rule for the onset of
2944 the observance defined by this time zone sub-component. Some
2945 specific requirements for the usage of RRULE for this purpose
2946 include:
2948 * If observance is known to have an effective end date, the
2949 "UNTIL" recurrence rule parameter MUST be used to specify the
2950 last valid onset of this observance (i.e., the UNTIL date-time
2951 will be equal to the last instance generated by the recurrence
2952 pattern). It MUST be specified in UTC time.
2954 * The "DTSTART" and the "TZOFFSETTO" properties MUST be used when
2955 generating the onset date-time values (instances) from the
2956 RRULE.
2958 Alternatively, the "RDATE" property can be used to define the
2959 onset of the observance by giving the individual onset date and
2960 times. "RDATE" in this usage MUST be specified as a local DATE-
2961 TIME value in UTC time.
2963 The optional "COMMENT" property is also allowed for descriptive
2964 explanatory text.
2966 Example: The following are examples of the "VTIMEZONE" calendar
2967 component:
2969 This is an example showing time zone information for the Eastern
2970 United States using "RDATE" property. Note that this is only
2971 suitable for a recurring event that starts on or later than April
2972 6, 1997 at 03:00:00 EDT (i.e., the earliest effective transition
2973 date and time) and ends no later than April 7, 1998 02:00:00 EST
2974 (i.e., latest valid date and time for EST in this scenario). For
2975 example, this can be used for a recurring event that occurs every
2976 Friday, 8:00AM-9:00 AM, starting June 1, 1997, ending December 31,
2977 1997.
2979 BEGIN:VTIMEZONE
2980 TZID:US-Eastern
2981 LAST-MODIFIED:19870101T000000Z
2982 BEGIN:STANDARD
2983 DTSTART:19971026T020000
2984 RDATE:19971026T020000
2985 TZOFFSETFROM:-0400
2986 TZOFFSETTO:-0500
2987 TZNAME:EST
2988 END:STANDARD
2989 BEGIN:DAYLIGHT
2990 DTSTART:19970406T020000
2991 RDATE:19970406T020000
2992 TZOFFSETFROM:-0500
2993 TZOFFSETTO:-0400
2994 TZNAME:EDT
2995 END:DAYLIGHT
2996 END:VTIMEZONE
2998 This is a simple example showing the current time zone rules for
2999 the Eastern United States using a RRULE recurrence pattern. Note
3000 that there is no effective end date to either of the Standard Time
3001 or Daylight Time rules. This information would be valid for a
3002 recurring event starting today and continuing indefinitely.
3004 BEGIN:VTIMEZONE
3005 TZID:US-Eastern
3006 LAST-MODIFIED:19870101T000000Z
3007 TZURL:http://zones.example.com/tz/US-Eastern.ics
3008 BEGIN:STANDARD
3009 DTSTART:19671029T020000
3010 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
3011 TZOFFSETFROM:-0400
3012 TZOFFSETTO:-0500
3013 TZNAME:EST
3014 END:STANDARD
3015 BEGIN:DAYLIGHT
3016 DTSTART:19870405T020000
3017 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
3018 TZOFFSETFROM:-0500
3019 TZOFFSETTO:-0400
3020 TZNAME:EDT
3021 END:DAYLIGHT
3022 END:VTIMEZONE
3024 This is an example showing a fictitious set of rules for the
3025 Eastern United States, where the Daylight Time rule has an
3026 effective end date (i.e., after that date, Daylight Time is no
3027 longer observed).
3029 BEGIN:VTIMEZONE
3030 TZID:US--Fictitious-Eastern
3031 LAST-MODIFIED:19870101T000000Z
3032 BEGIN:STANDARD
3033 DTSTART:19671029T020000
3034 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
3035 TZOFFSETFROM:-0400
3036 TZOFFSETTO:-0500
3037 TZNAME:EST
3038 END:STANDARD
3039 BEGIN:DAYLIGHT
3040 DTSTART:19870405T020000
3041 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T070000Z
3042 TZOFFSETFROM:-0500
3043 TZOFFSETTO:-0400
3044 TZNAME:EDT
3045 END:DAYLIGHT
3046 END:VTIMEZONE
3048 This is an example showing a fictitious set of rules for the
3049 Eastern United States, where the first Daylight Time rule has an
3050 effective end date. There is a second Daylight Time rule that
3051 picks up where the other left off.
3053 BEGIN:VTIMEZONE
3054 TZID:US--Fictitious-Eastern
3055 LAST-MODIFIED:19870101T000000Z
3056 BEGIN:STANDARD
3057 DTSTART:19671029T020000
3058 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
3059 TZOFFSETFROM:-0400
3060 TZOFFSETTO:-0500
3061 TZNAME:EST
3062 END:STANDARD
3063 BEGIN:DAYLIGHT
3064 DTSTART:19870405T020000
3065 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T070000Z
3066 TZOFFSETFROM:-0500
3067 TZOFFSETTO:-0400
3068 TZNAME:EDT
3069 END:DAYLIGHT
3070 BEGIN:DAYLIGHT
3071 DTSTART:19990424T020000
3072 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=4
3073 TZOFFSETFROM:-0500
3074 TZOFFSETTO:-0400
3075 TZNAME:EDT
3076 END:DAYLIGHT
3077 END:VTIMEZONE
3079 3.6.6. Alarm Component
3081 Component Name: VALARM
3083 Purpose: Provide a grouping of component properties that define an
3084 alarm.
3086 Format Definition: A "VALARM" calendar component is defined by the
3087 following notation:
3089 alarmc = "BEGIN" ":" "VALARM" CRLF
3090 (audioprop / dispprop / emailprop / procprop)
3091 "END" ":" "VALARM" CRLF
3093 audioprop = 2*(
3095 ; 'action' and 'trigger' are both REQUIRED,
3096 ; but MUST NOT occur more than once
3098 action / trigger /
3100 ; 'duration' and 'repeat' are both optional,
3101 ; and MUST NOT occur more than once each,
3102 ; but if one occurs, so MUST the other
3104 duration / repeat /
3106 ; the following is optional,
3107 ; but MUST NOT occur more than once
3109 attach /
3111 ; the following is optional,
3112 ; and MAY occur more than once
3114 x-prop
3116 )
3118 dispprop = 3*(
3120 ; the following are all REQUIRED,
3121 ; but MUST NOT occur more than once
3123 action / description / trigger /
3125 ; 'duration' and 'repeat' are both optional,
3126 ; and MUST NOT occur more than once each,
3127 ; but if one occurs, so MUST the other
3129 duration / repeat /
3131 ; the following is optional,
3132 ; and MAY occur more than once
3134 x-prop
3136 )
3138 emailprop = 5*(
3140 ; the following are all REQUIRED,
3141 ; but MUST NOT occur more than once
3143 action / description / trigger / summary /
3145 ; the following is REQUIRED,
3146 ; and MAY occur more than once
3148 attendee /
3149 ; 'duration' and 'repeat' are both optional,
3150 ; and MUST NOT occur more than once each,
3151 ; but if one occurs, so MUST the other
3153 duration / repeat /
3155 ; the following are optional,
3156 ; and MAY occur more than once
3158 attach / x-prop
3160 )
3162 procprop = 3*(
3164 ; the following are all REQUIRED,
3165 ; but MUST NOT occur more than once
3167 action / attach / trigger /
3169 ; 'duration' and 'repeat' are both optional,
3170 ; and MUST NOT occur more than once each,
3171 ; but if one occurs, so MUST the other
3173 duration / repeat /
3175 ; 'description' is optional,
3176 ; and MUST NOT occur more than once
3178 description /
3180 ; the following is optional,
3181 ; and MAY occur more than once
3183 x-prop
3185 )
3187 Description: A "VALARM" calendar component is a grouping of component
3188 properties that is a reminder or alarm for an event or a to-do.
3189 For example, it may be used to define a reminder for a pending
3190 event or an overdue to-do.
3192 The "VALARM" calendar component MUST include the "ACTION" and
3193 "TRIGGER" properties. The "ACTION" property further constrains
3194 the "VALARM" calendar component in the following ways:
3196 When the action is "AUDIO", the alarm can also include one and
3197 only one "ATTACH" property, which MUST point to a sound resource,
3198 which is rendered when the alarm is triggered.
3200 When the action is "DISPLAY", the alarm MUST also include a
3201 "DESCRIPTION" property, which contains the text to be displayed
3202 when the alarm is triggered.
3204 When the action is "EMAIL", the alarm MUST include a "DESCRIPTION"
3205 property, which contains the text to be used as the message body,
3206 a "SUMMARY" property, which contains the text to be used as the
3207 message subject, and one or more "ATTENDEE" properties, which
3208 contain the email address of attendees to receive the message. It
3209 can also include one or more "ATTACH" properties, which are
3210 intended to be sent as message attachments. When the alarm is
3211 triggered, the email message is sent.
3213 When the action is "PROCEDURE", the alarm MUST include one and
3214 only one "ATTACH" property, which MUST point to a procedure
3215 resource, which is invoked when the alarm is triggered.
3217 The "VALARM" calendar component MUST only appear within either a
3218 "VEVENT" or "VTODO" calendar component. "VALARM" calendar
3219 components cannot be nested. Multiple mutually independent
3220 "VALARM" calendar components can be specified for a single
3221 "VEVENT" or "VTODO" calendar component.
3223 The "TRIGGER" property specifies when the alarm will be triggered.
3224 The "TRIGGER" property specifies a duration prior to the start of
3225 an event or a to-do. The "TRIGGER" edge may be explicitly set to
3226 be relative to the "START" or "END" of the event or to-do with the
3227 "RELATED" parameter of the "TRIGGER" property. The "TRIGGER"
3228 property value type can alternatively be set to an absolute
3229 calendar date and time of day value.
3231 In an alarm set to trigger on the "START" of an event or to-do,
3232 the "DTSTART" property MUST be present in the associated event or
3233 to-do. In an alarm in a "VEVENT" calendar component set to
3234 trigger on the "END" of the event, either the "DTEND" property
3235 MUST be present, or the "DTSTART" and "DURATION" properties MUST
3236 both be present. In an alarm in a "VTODO" calendar component set
3237 to trigger on the "END" of the to-do, either the "DUE" property
3238 MUST be present, or the "DTSTART" and "DURATION" properties MUST
3239 both be present.
3241 The alarm can be defined such that it triggers repeatedly. A
3242 definition of an alarm with a repeating trigger MUST include both
3243 the "DURATION" and "REPEAT" properties. The "DURATION" property
3244 specifies the delay period, after which the alarm will repeat.
3245 The "REPEAT" property specifies the number of additional
3246 repetitions that the alarm will be triggered. This repetition
3247 count is in addition to the initial triggering of the alarm. Both
3248 of these properties MUST be present in order to specify a
3249 repeating alarm. If one of these two properties is absent, then
3250 the alarm will not repeat beyond the initial trigger.
3252 The "ACTION" property is used within the "VALARM" calendar
3253 component to specify the type of action invoked when the alarm is
3254 triggered. The "VALARM" properties provide enough information for
3255 a specific action to be invoked. It is typically the
3256 responsibility of a "Calendar User Agent" (CUA) to deliver the
3257 alarm in the specified fashion. An "ACTION" property value of
3258 AUDIO specifies an alarm that causes a sound to be played to alert
3259 the user; DISPLAY specifies an alarm that causes a text message to
3260 be displayed to the user; EMAIL specifies an alarm that causes an
3261 electronic email message to be delivered to one or more email
3262 addresses; and PROCEDURE specifies an alarm that causes a
3263 procedure to be executed. The "ACTION" property MUST specify one
3264 and only one of these values.
3266 In an AUDIO alarm, if the optional "ATTACH" property is included,
3267 it MUST specify an audio sound resource. The intention is that
3268 the sound will be played as the alarm effect. If an "ATTACH"
3269 property is specified that does not refer to a sound resource, or
3270 if the specified sound resource cannot be rendered (because its
3271 format is unsupported, or because it cannot be retrieved), then
3272 the CUA or other entity responsible for playing the sound may
3273 choose a fallback action, such as playing a built-in default
3274 sound, or playing no sound at all.
3276 In a DISPLAY alarm, the intended alarm effect is for the text
3277 value of the "DESCRIPTION" property to be displayed to the user.
3279 In an EMAIL alarm, the intended alarm effect is for an email
3280 message to be composed and delivered to all the addresses
3281 specified by the "ATTENDEE" properties in the "VALARM" calendar
3282 component. The "DESCRIPTION" property of the "VALARM" calendar
3283 component MUST be used as the body text of the message, and the
3284 "SUMMARY" property MUST be used as the subject text. Any "ATTACH"
3285 properties in the "VALARM" calendar component SHOULD be sent as
3286 attachments to the message.
3288 In a PROCEDURE alarm, the "ATTACH" property in the "VALARM"
3289 calendar component MUST specify a procedure or program that is
3290 intended to be invoked as the alarm effect. If the procedure or
3291 program is in a format that cannot be rendered, then no procedure
3292 alarm will be invoked. If the "DESCRIPTION" property is present,
3293 its value specifies the argument string to be passed to the
3294 procedure or program. "Calendar User Agents" that receive an
3295 iCalendar object with this category of alarm, can disable or allow
3296 the "Calendar User" to disable, or otherwise ignore this type of
3297 alarm. While a very useful alarm capability, the PROCEDURE type
3298 of alarm SHOULD be treated by the "Calendar User Agent" as a
3299 potential security risk.
3301 Example: The following example is for a "VALARM" calendar component
3302 that specifies an audio alarm that will sound at a precise time
3303 and repeat 4 more times at 15 minute intervals:
3305 BEGIN:VALARM
3306 TRIGGER;VALUE=DATE-TIME:19970317T133000Z
3307 REPEAT:4
3308 DURATION:PT15M
3309 ACTION:AUDIO
3310 ATTACH;FMTTYPE=audio/basic:ftp://example.com/pub/
3311 sounds/bell-01.aud
3312 END:VALARM
3314 The following example is for a "VALARM" calendar component that
3315 specifies a display alarm that will trigger 30 minutes before the
3316 scheduled start of the event or the due date/time of the to-do it
3317 is associated with and will repeat 2 more times at 15 minute
3318 intervals:
3320 BEGIN:VALARM
3321 TRIGGER:-PT30M
3322 REPEAT:2
3323 DURATION:PT15M
3324 ACTION:DISPLAY
3325 DESCRIPTION:Breakfast meeting with executive\n
3326 team at 8:30 AM EST.
3327 END:VALARM
3329 The following example is for a "VALARM" calendar component that
3330 specifies an email alarm that will trigger 2 days before the
3331 scheduled due date/time of a to-do it is associated with. It does
3332 not repeat. The email has a subject, body and attachment link.
3334 BEGIN:VALARM
3335 TRIGGER:-P2D
3336 ACTION:EMAIL
3337 ATTENDEE:MAILTO:john_doe@example.com
3338 SUMMARY:*** REMINDER: SEND AGENDA FOR WEEKLY STAFF MEETING ***
3339 DESCRIPTION:A draft agenda needs to be sent out to the attendees
3340 to the weekly managers meeting (MGR-LIST). Attached is a
3341 pointer the document template for the agenda file.
3342 ATTACH;FMTTYPE=application/msword:http://example.com/
3343 templates/agenda.doc
3344 END:VALARM
3346 The following example is for a "VALARM" calendar component that
3347 specifies a procedural alarm that will trigger at a precise date/
3348 time and will repeat 23 more times at one hour intervals. The
3349 alarm will invoke a procedure file.
3351 BEGIN:VALARM
3352 TRIGGER;VALUE=DATE-TIME:19980101T050000Z
3353 REPEAT:23
3354 DURATION:PT1H
3355 ACTION:PROCEDURE
3356 ATTACH;FMTTYPE=application/octet-stream:ftp://example.com/novo-
3357 procs/felizano.exe
3358 END:VALARM
3360 3.7. Calendar Properties
3362 The Calendar Properties are attributes that apply to the iCalendar
3363 object, as a whole. These properties do not appear within a calendar
3364 component. They SHOULD be specified after the "BEGIN:VCALENDAR"
3365 delimiter string and prior to any calendar component.
3367 3.7.1. Calendar Scale
3369 Property Name: CALSCALE
3371 Purpose: This property defines the calendar scale used for the
3372 calendar information specified in the iCalendar object.
3374 Value Type: TEXT
3376 Property Parameters: Non-standard property parameters can be
3377 specified on this property.
3379 Conformance: Property can be specified in an iCalendar object. The
3380 default value is "GREGORIAN".
3382 Description: This memo is based on the Gregorian calendar scale. The
3383 Gregorian calendar scale is assumed if this property is not
3384 specified in the iCalendar object. It is expected that other
3385 calendar scales will be defined in other specifications or by
3386 future versions of this memo.
3388 Format Definition: The property is defined by the following notation:
3390 calscale = "CALSCALE" calparam ":" calvalue CRLF
3392 calparam = *(";" xparam)
3394 calvalue = "GREGORIAN" / iana-token
3396 Example: The following is an example of this property:
3398 CALSCALE:GREGORIAN
3400 3.7.2. Method
3402 Property Name: METHOD
3404 Purpose: This property defines the iCalendar object method associated
3405 with the calendar object.
3407 Value Type: TEXT
3409 Property Parameters: Non-standard property parameters can be
3410 specified on this property.
3412 Conformance: The property can be specified in an iCalendar object.
3414 Description: When used in a MIME message entity, the value of this
3415 property MUST be the same as the Content-Type "method" parameter
3416 value. This property can only appear once within the iCalendar
3417 object. If either the "METHOD" property or the Content-Type
3418 "method" parameter is specified, then the other MUST also be
3419 specified.
3421 No methods are defined by this specification. This is the subject
3422 of other specifications, such as the iCalendar Transport-
3423 independent Interoperability Protocol (iTIP) defined by [I-D.ietf-
3424 calsify-2446bis].
3426 If this property is not present in the iCalendar object, then a
3427 scheduling transaction MUST NOT be assumed. In such cases, the
3428 iCalendar object is merely being used to transport a snapshot of
3429 some calendar information; without the intention of conveying a
3430 scheduling semantic.
3432 Format Definition: The property is defined by the following notation:
3434 method = "METHOD" metparam ":" metvalue CRLF
3436 metparam = *(";" xparam)
3438 metvalue = iana-token
3440 Example: The following is a hypothetical example of this property to
3441 convey that the iCalendar object is a request for a meeting:
3443 METHOD:REQUEST
3445 3.7.3. Product Identifier
3447 Property Name: PRODID
3449 Purpose: This property specifies the identifier for the product that
3450 created the iCalendar object.
3452 Value Type: TEXT
3454 Property Parameters: Non-standard property parameters can be
3455 specified on this property.
3457 Conformance: The property MUST be specified once in an iCalendar
3458 object.
3460 Description: The vendor of the implementation SHOULD assure that this
3461 is a globally unique identifier; using some technique such as an
3462 FPI value, as defined in [ISO.9070.1991].
3464 This property SHOULD not be used to alter the interpretation of an
3465 iCalendar object beyond the semantics specified in this memo. For
3466 example, it is not to be used to further the understanding of non-
3467 standard properties.
3469 Format Definition: The property is defined by the following notation:
3471 prodid = "PRODID" pidparam ":" pidvalue CRLF
3473 pidparam = *(";" xparam)
3475 pidvalue = text
3476 ;Any text that describes the product and version
3477 ;and that is generally assured of being unique.
3479 Example: The following is an example of this property. It does not
3480 imply that English is the default language.
3482 PRODID:-//ABC Corporation//NONSGML My Product//EN
3484 3.7.4. Version
3486 Property Name: VERSION
3488 Purpose: This property specifies the identifier corresponding to the
3489 highest version number or the minimum and maximum range of the
3490 iCalendar specification that is required in order to interpret the
3491 iCalendar object.
3493 Value Type: TEXT
3495 Property Parameters: Non-standard property parameters can be
3496 specified on this property.
3498 Conformance: This property MUST be specified by an iCalendar object,
3499 but MUST only be specified once.
3501 Description: A value of "2.0" corresponds to this memo.
3503 Format Definition: The property is defined by the following notation:
3505 version = "VERSION" verparam ":" vervalue CRLF
3507 verparam = *(";" xparam)
3509 vervalue = "2.0" ;This memo
3510 / maxver
3511 / (minver ";" maxver)
3513 minver =
3514 ;Minimum iCalendar version needed to parse the iCalendar object
3516 maxver =
3517 ;Maximum iCalendar version needed to parse the iCalendar object
3519 Example: The following is an example of this property:
3521 VERSION:2.0
3523 3.8. Component Properties
3525 The following properties can appear within calendar components, as
3526 specified by each component property definition.
3528 3.8.1. Descriptive Component Properties
3530 The following properties specify descriptive information about
3531 calendar components.
3533 3.8.1.1. Attachment
3535 Property Name: ATTACH
3537 Purpose: The property provides the capability to associate a document
3538 object with a calendar component.
3540 Value Type: The default value type for this property is URI. The
3541 value type can also be set to BINARY to indicate inline binary
3542 encoded content information.
3544 Property Parameters: Non-standard, inline encoding, format type and
3545 value data type property parameters can be specified on this
3546 property.
3548 Conformance: The property can be specified in a "VEVENT", "VTODO",
3549 "VJOURNAL" or "VALARM" calendar components.
3551 Description: The property can be specified within "VEVENT", "VTODO",
3552 "VJOURNAL", or "VALARM" calendar components. This property can be
3553 specified multiple times within an iCalendar object.
3555 Format Definition: The property is defined by the following notation:
3557 attach = "ATTACH" attachparam ":" uri CRLF
3559 / "ATTACH" attparam ";" "ENCODING" "=" "BASE64"
3560 ";" "VALUE" "=" "BINARY" ":" binary
3562 attachparam = *(
3564 ; the following is optional,
3565 ; but MUST NOT occur more than once
3567 (";" fmttypeparam) /
3569 ; the following is optional,
3570 ; and MAY occur more than once
3572 (";" xparam)
3574 )
3576 Example: The following are examples of this property:
3578 ATTACH:CID:jsmith.part3.960817T083000.xyzMail@example.com
3580 ATTACH;FMTTYPE=application/postscript:ftp://example.com/pub/
3581 reports/r-960812.ps
3583 3.8.1.2. Categories
3585 Property Name: CATEGORIES
3587 Purpose: This property defines the categories for a calendar
3588 component.
3590 Value Type: TEXT
3592 Property Parameters: Non-standard and language property parameters
3593 can be specified on this property.
3595 Conformance: The property can be specified within "VEVENT", "VTODO"
3596 or "VJOURNAL" calendar components.
3598 Description: This property is used to specify categories or subtypes
3599 of the calendar component. The categories are useful in searching
3600 for a calendar component of a particular type and category.
3601 Within the "VEVENT", "VTODO" or "VJOURNAL" calendar components,
3602 more than one category can be specified as a list of categories
3603 separated by the COMMA character (US-ASCII decimal 44).
3605 Format Definition: The property is defined by the following notation:
3607 categories = "CATEGORIES" catparam ":" text *("," text)
3608 CRLF
3610 catparam = *(
3612 ; the following is optional,
3613 ; but MUST NOT occur more than once
3615 (";" languageparam ) /
3617 ; the following is optional,
3618 ; and MAY occur more than once
3620 (";" xparam)
3622 )
3624 Example: The following are examples of this property:
3626 CATEGORIES:APPOINTMENT,EDUCATION
3628 CATEGORIES:MEETING
3630 3.8.1.3. Classification
3632 Property Name: CLASS
3634 Purpose: This property defines the access classification for a
3635 calendar component.
3637 Value Type: TEXT
3639 Property Parameters: Non-standard property parameters can be
3640 specified on this property.
3642 Conformance: The property can be specified once in a "VEVENT",
3643 "VTODO" or "VJOURNAL" calendar components.
3645 Description: An access classification is only one component of the
3646 general security system within a calendar application. It
3647 provides a method of capturing the scope of the access the
3648 calendar owner intends for information within an individual
3649 calendar entry. The access classification of an individual
3650 iCalendar component is useful when measured along with the other
3651 security components of a calendar system (e.g., calendar user
3652 authentication, authorization, access rights, access role, etc.).
3654 Hence, the semantics of the individual access classifications
3655 cannot be completely defined by this memo alone. Additionally,
3656 due to the "blind" nature of most exchange processes using this
3657 memo, these access classifications cannot serve as an enforcement
3658 statement for a system receiving an iCalendar object. Rather,
3659 they provide a method for capturing the intention of the calendar
3660 owner for the access to the calendar component.
3662 Format Definition: The property is defined by the following notation:
3664 class = "CLASS" classparam ":" classvalue CRLF
3666 classparam = *(";" xparam)
3668 classvalue = "PUBLIC" / "PRIVATE" / "CONFIDENTIAL" / iana-token
3669 / x-name
3670 ;Default is PUBLIC
3672 Example: The following is an example of this property:
3674 CLASS:PUBLIC
3676 3.8.1.4. Comment
3678 Property Name: COMMENT
3680 Purpose: This property specifies non-processing information intended
3681 to provide a comment to the calendar user.
3683 Value Type: TEXT
3685 Property Parameters: Non-standard, alternate text representation and
3686 language property parameters can be specified on this property.
3688 Conformance: This property can be specified in "VEVENT", "VTODO",
3689 "VJOURNAL", "VTIMEZONE" or "VFREEBUSY" calendar components.
3691 Description: The property can be specified multiple times.
3693 Format Definition: The property is defined by the following notation:
3695 comment = "COMMENT" commparam ":" text CRLF
3697 commparam = *(
3699 ; the following are optional,
3700 ; but MUST NOT occur more than once
3702 (";" altrepparam) / (";" languageparam) /
3704 ; the following is optional,
3705 ; and MAY occur more than once
3707 (";" xparam)
3709 )
3711 Example: The following is an example of this property:
3713 COMMENT:The meeting really needs to include both ourselves
3714 and the customer. We can't hold this meeting without them.
3715 As a matter of fact\, the venue for the meeting ought to be at
3716 their site. - - John
3718 3.8.1.5. Description
3720 Property Name: DESCRIPTION
3722 Purpose: This property provides a more complete description of the
3723 calendar component, than that provided by the "SUMMARY" property.
3725 Value Type: TEXT
3727 Property Parameters: Non-standard, alternate text representation and
3728 language property parameters can be specified on this property.
3730 Conformance: The property can be specified in the "VEVENT", "VTODO",
3731 "VJOURNAL" or "VALARM" calendar components. The property can be
3732 specified multiple times only within a "VJOURNAL" calendar
3733 component.
3735 Description: This property is used in the "VEVENT" and "VTODO" to
3736 capture lengthy textual decriptions associated with the activity.
3738 This property is used in the "VJOURNAL" calendar component to
3739 capture one more textual journal entries.
3741 This property is used in the "VALARM" calendar component to
3742 capture the display text for a DISPLAY category of alarm, to
3743 capture the body text for an EMAIL category of alarm and to
3744 capture the argument string for a PROCEDURE category of alarm.
3746 Format Definition: The property is defined by the following notation:
3748 description = "DESCRIPTION" descparam ":" text CRLF
3750 descparam = *(
3752 ; the following are optional,
3753 ; but MUST NOT occur more than once
3755 (";" altrepparam) / (";" languageparam) /
3757 ; the following is optional,
3758 ; and MAY occur more than once
3760 (";" xparam)
3762 )
3764 Example: The following is an example of the property with formatted
3765 line breaks in the property value:
3767 DESCRIPTION:Meeting to provide technical review for "Phoenix"
3768 design.\nHappy Face Conference Room. Phoenix design team
3769 MUST attend this meeting.\nRSVP to team leader.
3771 The following is an example of the property with folding of long
3772 lines:
3774 DESCRIPTION:Last draft of the new novel is to be completed
3775 for the editor's proof today.
3777 3.8.1.6. Geographic Position
3779 Property Name: GEO
3781 Purpose: This property specifies information related to the global
3782 position for the activity specified by a calendar component.
3784 Value Type: FLOAT. The value MUST be two SEMICOLON separated FLOAT
3785 values.
3787 Property Parameters: Non-standard property parameters can be
3788 specified on this property.
3790 Conformance: This property can be specified in "VEVENT" or "VTODO"
3791 calendar components.
3793 Description: The property value specifies latitude and longitude, in
3794 that order (i.e., "LAT LON" ordering). The longitude represents
3795 the location east or west of the prime meridian as a positive or
3796 negative real number, respectively. The longitude and latitude
3797 values MAY be specified up to six decimal places, which will allow
3798 for accuracy to within one meter of geographical position.
3799 Receiving applications MUST accept values of this precision and
3800 MAY truncate values of greater precision.
3802 Values for latitude and longitude shall be expressed as decimal
3803 fractions of degrees. Whole degrees of latitude shall be
3804 represented by a two-digit decimal number ranging from 0 through
3805 90. Whole degrees of longitude shall be represented by a decimal
3806 number ranging from 0 through 180. When a decimal fraction of a
3807 degree is specified, it shall be separated from the whole number
3808 of degrees by a decimal point.
3810 Latitudes north of the equator shall be specified by a plus sign
3811 (+), or by the absence of a minus sign (-), preceding the digits
3812 designating degrees. Latitudes south of the Equator shall be
3813 designated by a minus sign (-) preceding the digits designating
3814 degrees. A point on the Equator shall be assigned to the Northern
3815 Hemisphere.
3817 Longitudes east of the prime meridian shall be specified by a plus
3818 sign (+), or by the absence of a minus sign (-), preceding the
3819 digits designating degrees. Longitudes west of the meridian shall
3820 be designated by minus sign (-) preceding the digits designating
3821 degrees. A point on the prime meridian shall be assigned to the
3822 Eastern Hemisphere. A point on the 180th meridian shall be
3823 assigned to the Western Hemisphere. One exception to this last
3824 convention is permitted. For the special condition of describing
3825 a band of latitude around the earth, the East Bounding Coordinate
3826 data element shall be assigned the value +180 (180) degrees.
3828 Any spatial address with a latitude of +90 (90) or -90 degrees
3829 will specify the position at the North or South Pole,
3830 respectively. The component for longitude may have any legal
3831 value.
3833 With the exception of the special condition described above, this
3834 form is specified in Department of Commerce, 1986, Representation
3835 of geographic point locations for information interchange (Federal
3836 Information Processing Standard 70-1): Washington, Department of
3837 Commerce, National Institute of Standards and Technology.
3839 The simple formula for converting degrees-minutes-seconds into
3840 decimal degrees is:
3842 decimal = degrees + minutes/60 + seconds/3600.
3844 Format Definition: The property is defined by the following notation:
3846 geo = "GEO" geoparam ":" geovalue CRLF
3848 geoparam = *(";" xparam)
3850 geovalue = float ";" float
3851 ;Latitude and Longitude components
3853 Example: The following is an example of this property:
3855 GEO:37.386013;-122.082932
3857 3.8.1.7. Location
3859 Property Name: LOCATION
3861 Purpose: The property defines the intended venue for the activity
3862 defined by a calendar component.
3864 Value Type: TEXT
3866 Property Parameters: Non-standard, alternate text representation and
3867 language property parameters can be specified on this property.
3869 Conformance: This property can be specified in "VEVENT" or "VTODO"
3870 calendar component.
3872 Description: Specific venues such as conference or meeting rooms may
3873 be explicitly specified using this property. An alternate
3874 representation may be specified that is a URI that points to
3875 directory information with more structured specification of the
3876 location. For example, the alternate representation may specify
3877 either an LDAP URI pointing to an LDAP server entry or a CID URI
3878 pointing to a MIME body part containing a vCard [RFC2426] for the
3879 location.
3881 Format Definition: The property is defined by the following notation:
3883 location = "LOCATION" locparam ":" text CRLF
3885 locparam = *(
3887 ; the following are optional,
3888 ; but MUST NOT occur more than once
3890 (";" altrepparam) / (";" languageparam) /
3892 ; the following is optional,
3893 ; and MAY occur more than once
3895 (";" xparam)
3897 )
3899 Example: The following are some examples of this property:
3901 LOCATION:Conference Room - F123\, Bldg. 002
3903 LOCATION;ALTREP="http://xyzcorp.com/conf-rooms/f123.vcf":
3904 Conference Room - F123\, Bldg. 002
3906 3.8.1.8. Percent Complete
3908 Property Name: PERCENT-COMPLETE
3910 Purpose: This property is used by an assignee or delegatee of a to-do
3911 to convey the percent completion of a to-do to the Organizer.
3913 Value Type: INTEGER
3915 Property Parameters: Non-standard property parameters can be
3916 specified on this property.
3918 Conformance: This property can be specified in a "VTODO" calendar
3919 component.
3921 Description: The property value is a positive integer between zero
3922 and one hundred. A value of "0" indicates the to-do has not yet
3923 been started. A value of "100" indicates that the to-do has been
3924 completed. Integer values in between indicate the percent
3925 partially complete.
3927 When a to-do is assigned to multiple individuals, the property
3928 value indicates the percent complete for that portion of the to-do
3929 assigned to the assignee or delegatee. For example, if a to-do is
3930 assigned to both individuals "A" and "B". A reply from "A" with a
3931 percent complete of "70" indicates that "A" has completed 70% of
3932 the to-do assigned to them. A reply from "B" with a percent
3933 complete of "50" indicates "B" has completed 50% of the to-do
3934 assigned to them.
3936 Format Definition: The property is defined by the following notation:
3938 percent = "PERCENT-COMPLETE" pctparam ":" integer CRLF
3940 pctparam = *(";" xparam)
3942 Example: The following is an example of this property to show 39%
3943 completion:
3945 PERCENT-COMPLETE:39
3947 3.8.1.9. Priority
3949 Property Name: PRIORITY
3951 Purpose: The property defines the relative priority for a calendar
3952 component.
3954 Value Type: INTEGER
3956 Property Parameters: Non-standard property parameters can be
3957 specified on this property.
3959 Conformance: The property can be specified in a "VEVENT" or "VTODO"
3960 calendar component.
3962 Description: The priority is specified as an integer in the range
3963 zero to nine. A value of zero (US-ASCII decimal 48) specifies an
3964 undefined priority. A value of one (US-ASCII decimal 49) is the
3965 highest priority. A value of two (US-ASCII decimal 50) is the
3966 second highest priority. Subsequent numbers specify a decreasing
3967 ordinal priority. A value of nine (US-ASCII decimal 57 ) is the
3968 lowest priority.
3970 A CUA with a three-level priority scheme of "HIGH", "MEDIUM" and
3971 "LOW" is mapped into this property such that a property value in
3972 the range of one (US-ASCII decimal 49) to four (US-ASCII decimal
3973 52) specifies "HIGH" priority. A value of five (US-ASCII decimal
3974 53) is the normal or "MEDIUM" priority. A value in the range of
3975 six (US-ASCII decimal 54) to nine (US-ASCII decimal 57 ) is "LOW"
3976 priority.
3978 A CUA with a priority schema of "A1", "A2", "A3", "B1", "B2", ...,
3979 "C3" is mapped into this property such that a property value of
3980 one (US-ASCII decimal 49) specifies "A1", a property value of two
3981 (US-ASCII decimal 50) specifies "A2", a property value of three
3982 (US-ASCII decimal 51) specifies "A3", and so forth up to a
3983 property value of 9 (US-ASCII decimal 57 ) specifies "C3".
3985 Other integer values are reserved for future use.
3987 Within a "VEVENT" calendar component, this property specifies a
3988 priority for the event. This property may be useful when more
3989 than one event is scheduled for a given time period.
3991 Within a "VTODO" calendar component, this property specified a
3992 priority for the to-do. This property is useful in prioritizing
3993 multiple action items for a given time period.
3995 Format Definition: The property is defined by the following notation:
3997 priority = "PRIORITY" prioparam ":" privalue CRLF
3998 ;Default is zero
4000 prioparam = *(";" xparam)
4002 privalue = integer ;Must be in the range [0..9]
4003 ; All other values are reserved for future use
4005 Example: The following is an example of a property with the highest
4006 priority:
4008 PRIORITY:1
4010 The following is an example of a property with a next highest
4011 priority:
4013 PRIORITY:2
4015 The following is an example of a property with no priority. This
4016 is equivalent to not specifying the "PRIORITY" property:
4018 PRIORITY:0
4020 3.8.1.10. Resources
4022 Property Name: RESOURCES
4024 Purpose: This property defines the equipment or resources anticipated
4025 for an activity specified by a calendar entity..
4027 Value Type: TEXT
4029 Property Parameters: Non-standard, alternate text representation and
4030 language property parameters can be specified on this property.
4032 Conformance: This property can be specified in "VEVENT" or "VTODO"
4033 calendar component.
4035 Description: The property value is an arbitrary text. More than one
4036 resource can be specified as a list of resources separated by the
4037 COMMA character (US-ASCII decimal 44).
4039 Format Definition: The property is defined by the following notation:
4041 resources = "RESOURCES" resrcparam ":" text *("," text) CRLF
4043 resrcparam = *(
4045 ; the following are optional,
4046 ; but MUST NOT occur more than once
4048 (";" altrepparam) / (";" languageparam) /
4050 ; the following is optional,
4051 ; and MAY occur more than once
4053 (";" xparam)
4055 )
4057 Example: The following is an example of this property:
4059 RESOURCES:EASEL,PROJECTOR,VCR
4061 RESOURCES;LANGUAGE=fr:1 raton-laveur
4063 3.8.1.11. Status
4064 Property Name: STATUS
4066 Purpose: This property defines the overall status or confirmation for
4067 the calendar component.
4069 Value Type: TEXT
4071 Property Parameters: Non-standard property parameters can be
4072 specified on this property.
4074 Conformance: This property can be specified in "VEVENT", "VTODO" or
4075 "VJOURNAL" calendar components.
4077 Description: In a group scheduled calendar component, the property is
4078 used by the "Organizer" to provide a confirmation of the event to
4079 the "Attendees". For example in a "VEVENT" calendar component,
4080 the "Organizer" can indicate that a meeting is tentative,
4081 confirmed or cancelled. In a "VTODO" calendar component, the
4082 "Organizer" can indicate that an action item needs action, is
4083 completed, is in process or being worked on, or has been
4084 cancelled. In a "VJOURNAL" calendar component, the "Organizer"
4085 can indicate that a journal entry is draft, final or has been
4086 cancelled or removed.
4088 Format Definition: The property is defined by the following notation:
4090 status = "STATUS" statparam ":" statvalue CRLF
4092 statparam = *(";" xparam)
4094 statvalue = ( "TENTATIVE" ;Indicates event is tentative.
4095 / "CONFIRMED" ;Indicates event is definite.
4096 / "CANCELLED" ) ;Indicates event was cancelled.
4097 ;Status values for a "VEVENT"
4099 /
4100 ( "NEEDS-ACTION" ;Indicates to-do needs action.
4101 / "COMPLETED" ;Indicates to-do completed.
4102 / "IN-PROCESS" ;Indicates to-do in process.
4103 / "CANCELLED" ) ;Indicates to-do was cancelled.
4104 ;Status values for "VTODO".
4106 /
4107 ( "DRAFT" ;Indicates journal is draft.
4108 / "FINAL" ;Indicates journal is final.
4109 / "CANCELLED" ) ;Indicates journal is removed.
4110 ;Status values for "VJOURNAL".
4112 Example: The following is an example of this property for a "VEVENT"
4113 calendar component:
4115 STATUS:TENTATIVE
4117 The following is an example of this property for a "VTODO"
4118 calendar component:
4120 STATUS:NEEDS-ACTION
4122 The following is an example of this property for a "VJOURNAL"
4123 calendar component:
4125 STATUS:DRAFT
4127 3.8.1.12. Summary
4129 Property Name: SUMMARY
4131 Purpose: This property defines a short summary or subject for the
4132 calendar component.
4134 Value Type: TEXT
4136 Property Parameters: Non-standard, alternate text representation and
4137 language property parameters can be specified on this property.
4139 Conformance: The property can be specified in "VEVENT", "VTODO",
4140 "VJOURNAL" or "VALARM" calendar components.
4142 Description: This property is used in the "VEVENT", "VTODO" and
4143 "VJOURNAL" calendar components to capture a short, one line
4144 summary about the activity or journal entry.
4146 This property is used in the "VALARM" calendar component to
4147 capture the subject of an EMAIL category of alarm.
4149 Format Definition: The property is defined by the following notation:
4151 summary = "SUMMARY" summparam ":" text CRLF
4153 summparam = *(
4155 ; the following are optional,
4156 ; but MUST NOT occur more than once
4158 (";" altrepparam) / (";" languageparam) /
4160 ; the following is optional,
4161 ; and MAY occur more than once
4163 (";" xparam)
4165 )
4167 Example: The following is an example of this property:
4169 SUMMARY:Department Party
4171 3.8.2. Date and Time Component Properties
4173 The following properties specify date and time related information in
4174 calendar components.
4176 3.8.2.1. Date/Time Completed
4178 Property Name: COMPLETED
4180 Purpose: This property defines the date and time that a to-do was
4181 actually completed.
4183 Value Type: DATE-TIME
4185 Property Parameters: Non-standard property parameters can be
4186 specified on this property.
4188 Conformance: The property can be specified in a "VTODO" calendar
4189 component.
4191 Description: The date and time MUST be in a UTC format.
4193 Format Definition: The property is defined by the following notation:
4195 completed = "COMPLETED" compparam ":" date-time CRLF
4197 compparam = *(";" xparam)
4199 Example: The following is an example of this property:
4201 COMPLETED:19960401T235959Z
4203 3.8.2.2. Date/Time End
4205 Property Name: DTEND
4207 Purpose: This property specifies the date and time that a calendar
4208 component ends.
4210 Value Type: The default value type is DATE-TIME. The value type can
4211 be set to a DATE value type.
4213 Property Parameters: Non-standard, value data type, time zone
4214 identifier property parameters can be specified on this property.
4216 Conformance: This property can be specified in "VEVENT" or
4217 "VFREEBUSY" calendar components.
4219 Description: Within the "VEVENT" calendar component, this property
4220 defines the date and time by which the event ends. The value MUST
4221 be later in time than the value of the "DTSTART" property.
4223 Within the "VFREEBUSY" calendar component, this property defines
4224 the end date and time for the free or busy time information. The
4225 time MUST be specified in the UTC time format. The value MUST be
4226 later in time than the value of the "DTSTART" property.
4228 Format Definition: The property is defined by the following notation:
4230 dtend = "DTEND" dtendparam ":" dtendval CRLF
4232 dtendparam = *(
4234 ; the following are optional,
4235 ; but MUST NOT occur more than once
4237 (";" "VALUE" "=" ("DATE-TIME" / "DATE")) /
4238 (";" tzidparam) /
4240 ; the following is optional,
4241 ; and MAY occur more than once
4243 (";" xparam)
4245 )
4247 dtendval = date-time / date
4248 ;Value MUST match value type
4250 Example: The following is an example of this property:
4252 DTEND:19960401T235959Z
4254 DTEND;VALUE=DATE:19980704
4256 3.8.2.3. Date/Time Due
4258 Property Name: DUE
4260 Purpose: This property defines the date and time that a to-do is
4261 expected to be completed.
4263 Value Type: The default value type is DATE-TIME. The value type can
4264 be set to a DATE value type.
4266 Property Parameters: Non-standard, value data type, time zone
4267 identifier property parameters can be specified on this property.
4269 Conformance: The property can be specified once in a "VTODO" calendar
4270 component.
4272 Description: The value MUST be a date/time equal to or after the
4273 DTSTART value, if specified.
4275 Format Definition: The property is defined by the following notation:
4277 due = "DUE" dueparam ":" dueval CRLF
4279 dueparam = *(
4280 ; the following are optional,
4281 ; but MUST NOT occur more than once
4283 (";" "VALUE" "=" ("DATE-TIME" / "DATE")) /
4284 (";" tzidparam) /
4286 ; the following is optional,
4287 ; and MAY occur more than once
4289 *(";" xparam)
4291 )
4293 dueval = date-time / date
4294 ;Value MUST match value type
4296 Example: The following is an example of this property:
4298 DUE:19980430T235959Z
4300 3.8.2.4. Date/Time Start
4302 Property Name: DTSTART
4304 Purpose: This property specifies when the calendar component begins.
4306 Value Type: The default value type is DATE-TIME. The time value MUST
4307 be one of the forms defined for the DATE-TIME value type. The
4308 value type can be set to a DATE value type.
4310 Property Parameters: Non-standard, value data type, time zone
4311 identifier property parameters can be specified on this property.
4313 Conformance: This property can be specified in the "VEVENT", "VTODO",
4314 "VFREEBUSY", or "VTIMEZONE" calendar components. This property is
4315 REQUIRED in "VEVENT" calendar components.
4317 Description: Within the "VEVENT" calendar component, this property
4318 defines the start date and time for the event. Events can have a
4319 start date/time but no end date/time. In that case, the event
4320 does not take up any time.
4322 Within the "VFREEBUSY" calendar component, this property defines
4323 the start date and time for the free or busy time information.
4324 The time MUST be specified in UTC time.
4326 Within the "VTIMEZONE" calendar component, this property defines
4327 the effective start date and time for a time zone specification.
4328 This property is REQUIRED within each STANDARD and DAYLIGHT part
4329 included in "VTIMEZONE" calendar components and MUST be specified
4330 as a local DATE-TIME without the "TZID" property parameter.
4332 Format Definition: The property is defined by the following notation:
4334 dtstart = "DTSTART" dtstparam ":" dtstval CRLF
4336 dtstparam = *(
4338 ; the following are optional,
4339 ; but MUST NOT occur more than once
4341 (";" "VALUE" "=" ("DATE-TIME" / "DATE")) /
4342 (";" tzidparam) /
4344 ; the following is optional,
4345 ; and MAY occur more than once
4347 *(";" xparam)
4349 )
4351 dtstval = date-time / date
4352 ;Value MUST match value type
4354 Example: The following is an example of this property:
4356 DTSTART:19980118T073000Z
4358 3.8.2.5. Duration
4360 Property Name: DURATION
4362 Purpose: The property specifies a positive duration of time.
4364 Value Type: DURATION
4366 Property Parameters: Non-standard property parameters can be
4367 specified on this property.
4369 Conformance: The property can be specified in "VEVENT", "VTODO",
4370 "VFREEBUSY" or "VALARM" calendar components.
4372 Description: In a "VEVENT" calendar component the property may be
4373 used to specify a duration of the event, instead of an explicit
4374 end date/time. In a "VTODO" calendar component the property may
4375 be used to specify a duration for the to-do, instead of an
4376 explicit due date/time. In a "VFREEBUSY" calendar component the
4377 property may be used to specify the interval of free time being
4378 requested. In a "VALARM" calendar component the property may be
4379 used to specify the delay period prior to repeating an alarm.
4381 Format Definition: The property is defined by the following notation:
4383 duration = "DURATION" durparam ":" dur-value CRLF
4384 ;consisting of a positive duration of time.
4386 durparam = *(";" xparam)
4388 Example: The following is an example of this property that specifies
4389 an interval of time of 1 hour and zero minutes and zero seconds:
4391 DURATION:PT1H0M0S
4393 The following is an example of this property that specifies an
4394 interval of time of 15 minutes.
4396 DURATION:PT15M
4398 3.8.2.6. Free/Busy Time
4400 Property Name: FREEBUSY
4402 Purpose: The property defines one or more free or busy time
4403 intervals.
4405 Value Type: PERIOD. The date and time values MUST be in a UTC time
4406 format.
4408 Property Parameters: Non-standard or free/busy time type property
4409 parameters can be specified on this property.
4411 Conformance: The property can be specified in a "VFREEBUSY" calendar
4412 component.
4414 Description: These time periods can be specified as either a start
4415 and end date-time or a start date-time and duration. The date and
4416 time MUST be a UTC time format.
4418 "FREEBUSY" properties within the "VFREEBUSY" calendar component
4419 SHOULD be sorted in ascending order, based on start time and then
4420 end time, with the earliest periods first.
4422 The "FREEBUSY" property can specify more than one value, separated
4423 by the COMMA character (US-ASCII decimal 44). In such cases, the
4424 "FREEBUSY" property values SHOULD all be of the same "FBTYPE"
4425 property parameter type (e.g., all values of a particular "FBTYPE"
4426 listed together in a single property).
4428 Format Definition: The property is defined by the following notation:
4430 freebusy = "FREEBUSY" fbparam ":" fbvalue CRLF
4432 fbparam = *(
4433 ; the following is optional,
4434 ; but MUST NOT occur more than once
4436 (";" fbtypeparam) /
4438 ; the following is optional,
4439 ; and MAY occur more than once
4441 (";" xparam)
4443 )
4445 fbvalue = period *("," period)
4446 ;Time value MUST be in the UTC time format.
4448 Example: The following are some examples of this property:
4450 FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:19970308T160000Z/PT8H30M
4452 FREEBUSY;FBTYPE=FREE:19970308T160000Z/PT3H,19970308T200000Z/PT1H
4454 FREEBUSY;FBTYPE=FREE:19970308T160000Z/PT3H,19970308T200000Z/PT1H
4455 ,19970308T230000Z/19970309T000000Z
4457 3.8.2.7. Time Transparency
4458 Property Name: TRANSP
4460 Purpose: This property defines whether an event is transparent or not
4461 to busy time searches.
4463 Value Type: TEXT
4465 Property Parameters: Non-standard property parameters can be
4466 specified on this property.
4468 Conformance: This property can be specified once in a "VEVENT"
4469 calendar component.
4471 Description: Time Transparency is the characteristic of an event that
4472 determines whether it appears to consume time on a calendar.
4473 Events that consume actual time for the individual or resource
4474 associated with the calendar SHOULD be recorded as OPAQUE,
4475 allowing them to be detected by free-busy time searches. Other
4476 events, which do not take up the individual's (or resource's) time
4477 SHOULD be recorded as TRANSPARENT, making them invisible to free-
4478 busy time searches.
4480 Format Definition: The property is defined by the following notation:
4482 transp = "TRANSP" transparam ":" transvalue CRLF
4484 transparam = *(";" xparam)
4486 transvalue = "OPAQUE"
4487 ;Blocks or opaque on busy time searches.
4488 / "TRANSPARENT"
4489 ;Transparent on busy time searches.
4490 ;Default value is OPAQUE
4492 Example: The following is an example of this property for an event
4493 that is transparent or does not block on free/busy time searches:
4495 TRANSP:TRANSPARENT
4497 The following is an example of this property for an event that is
4498 opaque or blocks on free/busy time searches:
4500 TRANSP:OPAQUE
4502 3.8.3. Time Zone Component Properties
4504 The following properties specify time zone information in calendar
4505 components.
4507 3.8.3.1. Time Zone Identifier
4509 Property Name: TZID
4511 Purpose: This property specifies the text value that uniquely
4512 identifies the "VTIMEZONE" calendar component.
4514 Value Type: TEXT
4516 Property Parameters: Non-standard property parameters can be
4517 specified on this property.
4519 Conformance: This property MUST be specified in a "VTIMEZONE"
4520 calendar component.
4522 Description: This is the label by which a time zone calendar
4523 component is referenced by any iCalendar properties whose data
4524 type is either DATE-TIME or TIME and not intended to specify a UTC
4525 or a "floating" time. The presence of the SOLIDUS character (US-
4526 ASCII decimal 47) as a prefix, indicates that this TZID represents
4527 an unique ID in a globally defined time zone registry (when such
4528 registry is defined).
4530 Note: This document does not define a naming convention for
4531 time zone identifiers. Implementers may want to use the naming
4532 conventions defined in existing time zone specifications such
4533 as the public-domain Olson database [TZDB]. The specification
4534 of globally unique time zone identifiers is not addressed by
4535 this document and is left for future study.
4537 Format Definition: The property is defined by the following notation:
4539 tzid = "TZID" tzidpropparam ":" [tzidprefix] text CRLF
4541 tzidpropparam = *(";" xparam)
4543 ;tzidprefix = "/"
4544 ; Defined previously. Just listed here for reader convenience.
4546 Example: The following are examples of non-globally unique time zone
4547 identifiers:
4549 TZID:US-Eastern
4551 TZID:California-Los_Angeles
4553 The following is an example of a fictitious globally unique time
4554 zone identifier:
4556 TZID:/US-New_York-New_York
4558 3.8.3.2. Time Zone Name
4560 Property Name: TZNAME
4562 Purpose: This property specifies the customary designation for a time
4563 zone description.
4565 Value Type: TEXT
4567 Property Parameters: Non-standard and language property parameters
4568 can be specified on this property.
4570 Conformance: This property can be specified in a "VTIMEZONE" calendar
4571 component.
4573 Description: This property may be specified in multiple languages; in
4574 order to provide for different language requirements.
4576 Format Definition: The property is defined by the following notation:
4578 tzname = "TZNAME" tznparam ":" text CRLF
4580 tznparam = *(
4582 ; the following is optional,
4583 ; but MUST NOT occur more than once
4585 (";" languageparam) /
4587 ; the following is optional,
4588 ; and MAY occur more than once
4590 (";" xparam)
4592 )
4594 Example: The following are example of this property:
4596 TZNAME:EST
4598 The following is an example of this property when two different
4599 languages for the time zone name are specified:
4601 TZNAME;LANGUAGE=en:EST
4602 TZNAME;LANGUAGE=fr-CA:HNE
4604 3.8.3.3. Time Zone Offset From
4606 Property Name: TZOFFSETFROM
4608 Purpose: This property specifies the offset which is in use prior to
4609 this time zone observance.
4611 Value Type: UTC-OFFSET
4613 Property Parameters: Non-standard property parameters can be
4614 specified on this property.
4616 Conformance: This property MUST be specified in a "VTIMEZONE"
4617 calendar component.
4619 Description: This property specifies the offset which is in use prior
4620 to this time observance. It is used to calculate the absolute
4621 time at which the transition to a given observance takes place.
4622 This property MUST only be specified in a "VTIMEZONE" calendar
4623 component. A "VTIMEZONE" calendar component MUST include this
4624 property. The property value is a signed numeric indicating the
4625 number of hours and possibly minutes from UTC. Positive numbers
4626 represent time zones east of the prime meridian, or ahead of UTC.
4627 Negative numbers represent time zones west of the prime meridian,
4628 or behind UTC.
4630 Format Definition: The property is defined by the following notation:
4632 tzoffsetfrom = "TZOFFSETFROM" frmparam ":" utc-offset
4633 CRLF
4635 frmparam = *(";" xparam)
4637 Example: The following are examples of this property:
4639 TZOFFSETFROM:-0500
4641 TZOFFSETFROM:+1345
4643 3.8.3.4. Time Zone Offset To
4645 Property Name: TZOFFSETTO
4647 Purpose: This property specifies the offset which is in use in this
4648 time zone observance.
4650 Value Type: UTC-OFFSET
4652 Property Parameters: Non-standard property parameters can be
4653 specified on this property.
4655 Conformance: This property MUST be specified in a "VTIMEZONE"
4656 calendar component.
4658 Description: This property specifies the offset which is in use in
4659 this time zone observance. It is used to calculate the absolute
4660 time for the new observance. The property value is a signed
4661 numeric indicating the number of hours and possibly minutes from
4662 UTC. Positive numbers represent time zones east of the prime
4663 meridian, or ahead of UTC. Negative numbers represent time zones
4664 west of the prime meridian, or behind UTC.
4666 Format Definition: The property is defined by the following notation:
4668 tzoffsetto = "TZOFFSETTO" toparam ":" utc-offset CRLF
4670 toparam = *(";" xparam)
4672 Example: The following are examples of this property:
4674 TZOFFSETTO:-0400
4676 TZOFFSETTO:+1245
4678 3.8.3.5. Time Zone URL
4680 Property Name: TZURL
4682 Purpose: The TZURL provides a means for a VTIMEZONE component to
4683 point to a network location that can be used to retrieve an up-to-
4684 date version of itself.
4686 Value Type: URI
4687 Property Parameters: Non-standard property parameters can be
4688 specified on this property.
4690 Conformance: This property can be specified in a "VTIMEZONE" calendar
4691 component.
4693 Description: The TZURL provides a means for a VTIMEZONE component to
4694 point to a network location that can be used to retrieve an up-to-
4695 date version of itself. This provides a hook to handle changes
4696 government bodies impose upon time zone definitions. Retrieval of
4697 this resource results in an iCalendar object containing a single
4698 VTIMEZONE component and a METHOD property set to PUBLISH.
4700 Format Definition: The property is defined by the following notation:
4702 tzurl = "TZURL" tzurlparam ":" uri CRLF
4704 tzurlparam = *(";" xparam)
4706 Example: The following is an example of this property:
4708 TZURL:http://timezones.r.us.net/tz/US-California-Los_Angeles.ics
4710 3.8.4. Relationship Component Properties
4712 The following properties specify relationship information in calendar
4713 components.
4715 3.8.4.1. Attendee
4717 Property Name: ATTENDEE
4719 Purpose: The property defines an "Attendee" within a calendar
4720 component.
4722 Value Type: CAL-ADDRESS
4724 Property Parameters: Non-standard, language, calendar user type,
4725 group or list membership, participation role, participation
4726 status, RSVP expectation, delegatee, delegator, sent by, common
4727 name or directory entry reference property parameters can be
4728 specified on this property.
4730 Conformance: This property MUST be specified in an iCalendar object
4731 that specifies a group scheduled calendar entity. This property
4732 MUST NOT be specified in an iCalendar object when publishing the
4733 calendar information (e.g., NOT in an iCalendar object that
4734 specifies the publication of a calendar user's busy time, event,
4735 to-do or journal). This property is not specified in an iCalendar
4736 object that specifies only a time zone definition or that defines
4737 calendar entities that are not group scheduled entities, but are
4738 entities only on a single user's calendar.
4740 Description: The property MUST only be specified within calendar
4741 components to specify participants, non-participants and the chair
4742 of a group scheduled calendar entity. The property is specified
4743 within an "EMAIL" category of the "VALARM" calendar component to
4744 specify an email address that is to receive the email type of
4745 iCalendar alarm.
4747 The property parameter CN is for the common or displayable name
4748 associated with the calendar address; ROLE, for the intended role
4749 that the attendee will have in the calendar component; PARTSTAT,
4750 for the status of the attendee's participation; RSVP, for
4751 indicating whether the favor of a reply is requested; CUTYPE, to
4752 indicate the type of calendar user; MEMBER, to indicate the groups
4753 that the attendee belongs to; DELEGATED-TO, to indicate the
4754 calendar users that the original request was delegated to; and
4755 DELEGATED-FROM, to indicate whom the request was delegated from;
4756 SENT-BY, to indicate whom is acting on behalf of the ATTENDEE; and
4757 DIR, to indicate the URI that points to the directory information
4758 corresponding to the attendee. These property parameters can be
4759 specified on an "ATTENDEE" property in either a "VEVENT", "VTODO"
4760 or "VJOURNAL" calendar component. They MUST NOT be specified in
4761 an "ATTENDEE" property in a "VFREEBUSY" or "VALARM" calendar
4762 component. If the LANGUAGE property parameter is specified, the
4763 identified language applies to the CN parameter.
4765 A recipient delegated a request MUST inherit the RSVP and ROLE
4766 values from the attendee that delegated the request to them.
4768 Multiple attendees can be specified by including multiple
4769 "ATTENDEE" properties within the calendar component.
4771 Format Definition: The property is defined by the following notation:
4773 attendee = "ATTENDEE" attparam ":" cal-address CRLF
4775 attparam = *(
4777 ; the following are optional,
4778 ; but MUST NOT occur more than once
4780 (";" cutypeparam) / (";" memberparam) /
4781 (";" roleparam) / (";" partstatparam) /
4782 (";" rsvpparam) / (";" deltoparam) /
4783 (";" delfromparam) / (";" sentbyparam) /
4784 (";" cnparam) / (";" dirparam) /
4785 (";" languageparam) /
4787 ; the following is optional,
4788 ; and MAY occur more than once
4790 (";" xparam)
4792 )
4794 Example: The following are examples of this property's use for a
4795 to-do:
4797 ORGANIZER:MAILTO:jsmith@example.com
4798 ATTENDEE;MEMBER="MAILTO:DEV-GROUP@example.com":
4799 MAILTO:joecool@example.com
4800 ATTENDEE;DELEGATED-FROM="MAILTO:immud@example.com":
4801 MAILTO:ildoit@example.com
4803 The following is an example of this property used for specifying
4804 multiple attendees to an event:
4806 ORGANIZER:MAILTO:jsmith@example.com
4807 ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;CN=Henry
4808 Cabot:MAILTO:hcabot@example.com
4809 ATTENDEE;ROLE=REQ-PARTICIPANT;DELEGATED-FROM="MAILTO:bob@
4810 example.com"
4811 ;PARTSTAT=ACCEPTED;CN=Jane Doe:MAILTO:jdoe@example.com
4813 The following is an example of this property with a URI to the
4814 directory information associated with the attendee:
4816 ATTENDEE;CN=John Smith;DIR="ldap://example.com:6666/o=ABC%
4817 20Industries,c=US???(cn=Jim%20Dolittle)":MAILTO:jimdo@
4818 example.com
4820 The following is an example of this property with "delegatee" and
4821 "delegator" information for an event:
4823 ORGANIZER;CN=John Smith:MAILTO:jsmith@example.com
4824 ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;DELEGATED-FROM=
4825 "MAILTO:iamboss@example.com";CN=Henry Cabot:MAILTO:hcabot@
4826 example.com
4827 ATTENDEE;ROLE=NON-PARTICIPANT;PARTSTAT=DELEGATED;DELEGATED-TO=
4828 "MAILTO:hcabot@example.com";CN=The Big Cheese:MAILTO:iamboss
4829 @example.com
4830 ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;CN=Jane Doe
4831 :MAILTO:jdoe@example.com
4833 Example: The following is an example of this property's use when
4834 another calendar user is acting on behalf of the "Attendee":
4836 ATTENDEE;SENT-BY=MAILTO:jan_doe@example.com;CN=John Smith:MAILTO:
4837 jsmith@example.com
4839 3.8.4.2. Contact
4841 Property Name: CONTACT
4843 Purpose: The property is used to represent contact information or
4844 alternately a reference to contact information associated with the
4845 calendar component.
4847 Value Type: TEXT
4849 Property Parameters: Non-standard, alternate text representation and
4850 language property parameters can be specified on this property.
4852 Conformance: The property can be specified in a "VEVENT", "VTODO",
4853 "VJOURNAL" or "VFREEBUSY" calendar component.
4855 Description: The property value consists of textual contact
4856 information. An alternative representation for the property value
4857 can also be specified that refers to a URI pointing to an
4858 alternate form, such as a vCard [RFC2426], for the contact
4859 information.
4861 Format Definition: The property is defined by the following notation:
4863 contact = "CONTACT" contparam ":" text CRLF
4865 contparam = *(
4866 ; the following are optional,
4867 ; but MUST NOT occur more than once
4869 (";" altrepparam) / (";" languageparam) /
4871 ; the following is optional,
4872 ; and MAY occur more than once
4874 (";" xparam)
4876 )
4878 Example: The following is an example of this property referencing
4879 textual contact information:
4881 CONTACT:Jim Dolittle\, ABC Industries\, +1-919-555-1234
4883 The following is an example of this property with an alternate
4884 representation of a LDAP URI to a directory entry containing the
4885 contact information:
4887 CONTACT;ALTREP="ldap://example.com:6666/o=ABC%20Industries\,
4888 c=US???(cn=Jim%20Dolittle)":Jim Dolittle\, ABC Industries\,
4889 +1-919-555-1234
4891 The following is an example of this property with an alternate
4892 representation of a MIME body part containing the contact
4893 information, such as a vCard [RFC2426] embedded in a text/
4894 directory media type [RFC2425]:
4896 CONTACT;ALTREP="CID:part3.msg970930T083000SILVER@example.com":
4897 Jim Dolittle\, ABC Industries\, +1-919-555-1234
4899 The following is an example of this property referencing a network
4900 resource, such as a vCard [RFC2426] object containing the contact
4901 information:
4903 CONTACT;ALTREP="http://example.com/pdi/jdoe.vcf":Jim
4904 Dolittle\, ABC Industries\, +1-919-555-1234
4906 3.8.4.3. Organizer
4907 Property Name: ORGANIZER
4909 Purpose: The property defines the organizer for a calendar component.
4911 Value Type: CAL-ADDRESS
4913 Property Parameters: Non-standard, language, common name, directory
4914 entry reference, sent by property parameters can be specified on
4915 this property.
4917 Conformance: This property MUST be specified in an iCalendar object
4918 that specifies a group scheduled calendar entity. This property
4919 MUST be specified in an iCalendar object that specifies the
4920 publication of a calendar user's busy time. This property MUST
4921 NOT be specified in an iCalendar object that specifies only a time
4922 zone definition or that defines calendar entities that are not
4923 group scheduled entities, but are entities only on a single user's
4924 calendar.
4926 Description: The property is specified within the "VEVENT", "VTODO",
4927 "VJOURNAL" calendar components to specify the organizer of a group
4928 scheduled calendar entity. The property is specified within the
4929 "VFREEBUSY" calendar component to specify the calendar user
4930 requesting the free or busy time. When publishing a "VFREEBUSY"
4931 calendar component, the property is used to specify the calendar
4932 that the published busy time came from.
4934 The property has the property parameters CN, for specifying the
4935 common or display name associated with the "Organizer", DIR, for
4936 specifying a pointer to the directory information associated with
4937 the "Organizer", SENT-BY, for specifying another calendar user
4938 that is acting on behalf of the "Organizer". The non-standard
4939 parameters may also be specified on this property. If the
4940 LANGUAGE property parameter is specified, the identified language
4941 applies to the CN parameter value.
4943 Format Definition: The property is defined by the following notation:
4945 organizer = "ORGANIZER" orgparam ":"
4946 cal-address CRLF
4948 orgparam = *(
4950 ; the following are optional,
4951 ; but MUST NOT occur more than once
4953 (";" cnparam) / (";" dirparam) / (";" sentbyparam) /
4954 (";" languageparam) /
4956 ; the following is optional,
4957 ; and MAY occur more than once
4959 (";" xparam)
4961 )
4963 Example: The following is an example of this property:
4965 ORGANIZER;CN=John Smith:MAILTO:jsmith@example.com
4967 The following is an example of this property with a pointer to the
4968 directory information associated with the organizer:
4970 ORGANIZER;CN=JohnSmith;DIR="ldap://example.com:6666/o=DC%20Ass
4971 ociates,c=US???(cn=John%20Smith)":MAILTO:jsmith@example.com
4973 The following is an example of this property used by another
4974 calendar user who is acting on behalf of the organizer, with
4975 responses intended to be sent back to the organizer, not the other
4976 calendar user:
4978 ORGANIZER;SENT-BY="MAILTO:jane_doe@example.com":
4979 MAILTO:jsmith@example.com
4981 3.8.4.4. Recurrence ID
4983 Property Name: RECURRENCE-ID
4985 Purpose: This property is used in conjunction with the "UID" and
4986 "SEQUENCE" property to identify a specific instance of a recurring
4987 "VEVENT", "VTODO" or "VJOURNAL" calendar component. The property
4988 value is the effective value of the "DTSTART" property of the
4989 recurrence instance.
4991 Value Type: The default value type for this property is DATE-TIME.
4992 The time format can be any of the valid forms defined for a DATE-
4993 TIME value type. See DATE-TIME value type definition for specific
4994 interpretations of the various forms. The value type can be set
4995 to DATE.
4997 Property Parameters: Non-standard property, value data type, time
4998 zone identifier and recurrence identifier range parameters can be
4999 specified on this property.
5001 Conformance: This property can be specified in an iCalendar object
5002 containing a recurring calendar component.
5004 Description: The full range of calendar components specified by a
5005 recurrence set is referenced by referring to just the "UID"
5006 property value corresponding to the calendar component. The
5007 "RECURRENCE-ID" property allows the reference to an individual
5008 instance within the recurrence set.
5010 If the value of the "DTSTART" property is a DATE type value, then
5011 the value MUST be the calendar date for the recurrence instance.
5013 The date/time value is set to the time when the original
5014 recurrence instance would occur; meaning that if the intent is to
5015 change a Friday meeting to Thursday, the date/time is still set to
5016 the original Friday meeting.
5018 The "RECURRENCE-ID" property is used in conjunction with the "UID"
5019 and "SEQUENCE" property to identify a particular instance of a
5020 recurring event, to-do or journal. For a given pair of "UID" and
5021 "SEQUENCE" property values, the "RECURRENCE-ID" value for a
5022 recurrence instance is fixed. When the definition of the
5023 recurrence set for a calendar component changes, and hence the
5024 "SEQUENCE" property value changes, the "RECURRENCE-ID" for a given
5025 recurrence instance might also change.The "RANGE" parameter is
5026 used to specify the effective range of recurrence instances from
5027 the instance specified by the "RECURRENCE-ID" property value. The
5028 default value for the range parameter is the single recurrence
5029 instance only. The value can also be "THISANDPRIOR" to indicate a
5030 range defined by the given recurrence instance and all prior
5031 instances or the value can be "THISANDFUTURE" to indicate a range
5032 defined by the given recurrence instance and all subsequent
5033 instances.
5035 Format Definition: The property is defined by the following notation:
5037 recurid = "RECURRENCE-ID" ridparam ":" ridval CRLF
5039 ridparam = *(
5041 ; the following are optional,
5042 ; but MUST NOT occur more than once
5044 (";" "VALUE" "=" ("DATE-TIME" / "DATE")) /
5045 (";" tzidparam) / (";" rangeparam) /
5047 ; the following is optional,
5048 ; and MAY occur more than once
5050 (";" xparam)
5052 )
5054 ridval = date-time / date
5055 ;Value MUST match value type
5057 Example: The following are examples of this property:
5059 RECURRENCE-ID;VALUE=DATE:19960401
5061 RECURRENCE-ID;RANGE=THISANDFUTURE:19960120T120000Z
5063 3.8.4.5. Related To
5065 Property Name: RELATED-TO
5067 Purpose: The property is used to represent a relationship or
5068 reference between one calendar component and another.
5070 Value Type: TEXT
5072 Property Parameters: Non-standard and relationship type property
5073 parameters can be specified on this property.
5075 Conformance: The property can be specified one or more times in the
5076 "VEVENT", "VTODO" or "VJOURNAL" calendar components.
5078 Description: The property value consists of the persistent, globally
5079 unique identifier of another calendar component. This value would
5080 be represented in a calendar component by the "UID" property.
5082 By default, the property value points to another calendar
5083 component that has a PARENT relationship to the referencing
5084 object. The "RELTYPE" property parameter is used to either
5085 explicitly state the default PARENT relationship type to the
5086 referenced calendar component or to override the default PARENT
5087 relationship type and specify either a CHILD or SIBLING
5088 relationship. The PARENT relationship indicates that the calendar
5089 component is a subordinate of the referenced calendar component.
5090 The CHILD relationship indicates that the calendar component is a
5091 superior of the referenced calendar component. The SIBLING
5092 relationship indicates that the calendar component is a peer of
5093 the referenced calendar component.
5095 Changes to a calendar component referenced by this property can
5096 have an implicit impact on the related calendar component. For
5097 example, if a group event changes its start or end date or time,
5098 then the related, dependent events will need to have their start
5099 and end dates changed in a corresponding way. Similarly, if a
5100 PARENT calendar component is cancelled or deleted, then there is
5101 an implied impact to the related CHILD calendar components. This
5102 property is intended only to provide information on the
5103 relationship of calendar components. It is up to the target
5104 calendar system to maintain any property implications of this
5105 relationship.
5107 Format Definition: The property is defined by the following notation:
5109 related = "RELATED-TO" relparam ":" text CRLF
5111 relparam = *(
5113 ; the following is optional,
5114 ; but MUST NOT occur more than once
5116 (";" reltypeparam) /
5118 ; the following is optional,
5119 ; and MAY occur more than once
5121 (";" xparam)
5123 )
5125 The following is an example of this property:
5127 RELATED-TO:jsmith.part7.19960817T083000.xyzMail@example.com
5128 RELATED-TO:19960401-080045-4000F192713-0052@example.com
5130 3.8.4.6. Uniform Resource Locator
5132 Property Name: URL
5134 Purpose: This property defines a Uniform Resource Locator (URL)
5135 associated with the iCalendar object.
5137 Value Type: URI
5139 Property Parameters: Non-standard property parameters can be
5140 specified on this property.
5142 Conformance: This property can be specified once in the "VEVENT",
5143 "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components.
5145 Description: This property may be used in a calendar component to
5146 convey a location where a more dynamic rendition of the calendar
5147 information associated with the calendar component can be found.
5148 This memo does not attempt to standardize the form of the URI, nor
5149 the format of the resource pointed to by the property value. If
5150 the URL property and Content-Location MIME header are both
5151 specified, they MUST point to the same resource.
5153 Format Definition: The property is defined by the following notation:
5155 url = "URL" urlparam ":" uri CRLF
5157 urlparam = *(";" xparam)
5159 Example: The following is an example of this property:
5161 URL:http://abc.com/pub/calendars/jsmith/mytime.ics
5163 3.8.4.7. Unique Identifier
5165 Property Name: UID
5167 Purpose: This property defines the persistent, globally unique
5168 identifier for the calendar component.
5170 Value Type: TEXT
5172 Property Parameters: Non-standard property parameters can be
5173 specified on this property.
5175 Conformance: The property MUST be specified in the "VEVENT", "VTODO",
5176 "VJOURNAL" or "VFREEBUSY" calendar components.
5178 Description: The UID itself MUST be a globally unique identifier.
5179 The generator of the identifier MUST guarantee that the identifier
5180 is unique. There are several algorithms that can be used to
5181 accomplish this. The identifier is RECOMMENDED to be the
5182 identical syntax to the [RFC2822] addr-spec. A good method to
5183 assure uniqueness is to put the domain name or a domain literal IP
5184 address of the host on which the identifier was created on the
5185 right hand side of the "@", and on the left hand side, put a
5186 combination of the current calendar date and time of day (i.e.,
5187 formatted in as a DATE-TIME value) along with some other currently
5188 unique (perhaps sequential) identifier available on the system
5189 (for example, a process id number). Using a date/time value on
5190 the left hand side and a domain name or domain literal on the
5191 right hand side makes it possible to guarantee uniqueness since no
5192 two hosts should be using the same domain name or IP address at
5193 the same time. Though other algorithms will work, it is
5194 RECOMMENDED that the right hand side contain some domain
5195 identifier (either of the host itself or otherwise) such that the
5196 generator of the message identifier can guarantee the uniqueness
5197 of the left hand side within the scope of that domain.
5199 This is the method for correlating scheduling messages with the
5200 referenced "VEVENT", "VTODO", or "VJOURNAL" calendar component.
5202 The full range of calendar components specified by a recurrence
5203 set is referenced by referring to just the "UID" property value
5204 corresponding to the calendar component. The "RECURRENCE-ID"
5205 property allows the reference to an individual instance within the
5206 recurrence set.
5208 This property is an important method for group scheduling
5209 applications to match requests with later replies, modifications
5210 or deletion requests. Calendaring and scheduling applications
5211 MUST generate this property in "VEVENT", "VTODO" and "VJOURNAL"
5212 calendar components to assure interoperability with other group
5213 scheduling applications. This identifier is created by the
5214 calendar system that generates an iCalendar object.
5216 Implementations MUST be able to receive and persist values of at
5217 least 255 octets for this property but MUST NOT truncate values in
5218 the middle of a UTF-8 multi-octet sequence .
5220 Format Definition: The property is defined by the following notation:
5222 uid = "UID" uidparam ":" text CRLF
5224 uidparam = *(";" xparam)
5226 Example: The following is an example of this property:
5228 UID:19960401T080045Z-4000F192713-0052@example.com
5230 3.8.5. Recurrence Component Properties
5232 The following properties specify recurrence information in calendar
5233 components.
5235 3.8.5.1. Exception Date/Times
5237 Property Name: EXDATE
5239 Purpose: This property defines the list of date/time exceptions for
5240 recurring events, to-dos, journal entries or time zone
5241 definitions.
5243 Value Type: The default value type for this property is DATE-TIME.
5244 The value type can be set to DATE.
5246 Property Parameters: Non-standard, value data type and time zone
5247 identifier property parameters can be specified on this property.
5249 Conformance: This property can be specified in recurring "VEVENT",
5250 "VTODO", and "VJOURNAL" calendar components as well as in the
5251 "STANDARD" and "DAYLIGHT" sub-components of the "VTIMEZONE"
5252 calendar component.
5254 Description: The exception dates, if specified, are used in computing
5255 the recurrence set. The recurrence set is the complete set of
5256 recurrence instances for a calendar component. The recurrence set
5257 is generated by considering the initial "DTSTART" property along
5258 with the "RRULE", "RDATE", and "EXDATE" properties contained
5259 within the recurring component. The "DTSTART" property defines
5260 the first instance in the recurrence set. The "DTSTART" property
5261 value SHOULD match the pattern of the recurrence rule, if
5262 specified. The recurrence set generated with a "DTSTART" property
5263 value that doesn't match the pattern of the rule is undefined.
5264 The final recurrence set is generated by gathering all of the
5265 start date-times generated by any of the specified "RRULE" and
5266 "RDATE" properties, and then excluding any start date and times
5267 specified by "EXDATE" properties. This implies that start date
5268 and times specified by "EXDATE" properties take precedence over
5269 those specified by inclusion properties (i.e., "RDATE" and
5270 "RRULE"). Where duplicate instances are generated by the "RRULE"
5271 and "RDATE" properties, only one recurrence is considered.
5272 Duplicate instances are ignored.
5274 The "EXDATE" property can be used to exclude the value specified
5275 in "DTSTART". However, in such cases the original "DTSTART" date
5276 MUST still be maintained by the calendaring and scheduling system
5277 because the original "DTSTART" value has inherent usage
5278 dependencies by other properties such as the "RECURRENCE-ID".
5280 Format Definition: The property is defined by the following notation:
5282 exdate = "EXDATE" exdtparam ":" exdtval *("," exdtval) CRLF
5284 exdtparam = *(
5286 ; the following are optional,
5287 ; but MUST NOT occur more than once
5289 (";" "VALUE" "=" ("DATE-TIME" / "DATE")) /
5291 (";" tzidparam) /
5293 ; the following is optional,
5294 ; and MAY occur more than once
5296 (";" xparam)
5298 )
5300 exdtval = date-time / date
5301 ;Value MUST match value type
5303 Example: The following is an example of this property:
5305 EXDATE:19960402T010000Z,19960403T010000Z,19960404T010000Z
5307 3.8.5.2. Recurrence Date/Times
5309 Property Name: RDATE
5311 Purpose: This property defines the list of date/times for recurring
5312 events, to-dos, journal entries or time zone definitions.
5314 Value Type: The default value type for this property is DATE-TIME.
5315 The value type can be set to DATE or PERIOD.
5317 Property Parameters: Non-standard, value data type and time zone
5318 identifier property parameters can be specified on this property.
5320 Conformance: This property can be specified in recurring "VEVENT",
5321 "VTODO", and "VJOURNAL" calendar components as well as in the
5322 "STANDARD" and "DAYLIGHT" sub-components of the "VTIMEZONE"
5323 calendar component.
5325 Description: This property can appear along with the "RRULE" property
5326 to define an aggregate set of repeating occurrences. When they
5327 both appear in a recurring component, the recurrence instances are
5328 defined by the union of occurrences defined by both the "RDATE"
5329 and "RRULE".
5331 The recurrence dates, if specified, are used in computing the
5332 recurrence set. The recurrence set is the complete set of
5333 recurrence instances for a calendar component. The recurrence set
5334 is generated by considering the initial "DTSTART" property along
5335 with the "RRULE", "RDATE", and "EXDATE" properties contained
5336 within the recurring component. The "DTSTART" property defines
5337 the first instance in the recurrence set. The "DTSTART" property
5338 value SHOULD match the pattern of the recurrence rule, if
5339 specified. The recurrence set generated with a "DTSTART" property
5340 value that doesn't match the pattern of the rule is undefined.
5341 The final recurrence set is generated by gathering all of the
5342 start date-times generated by any of the specified "RRULE" and
5343 "RDATE" properties, and then excluding any start date and times
5344 specified by "EXDATE" properties. This implies that start date/
5345 times specified by "EXDATE" properties take precedence over those
5346 specified by inclusion properties (i.e., "RDATE" and "RRULE").
5347 Where duplicate instances are generated by the "RRULE" and "RDATE"
5348 properties, only one recurrence is considered. Duplicate
5349 instances are ignored.
5351 Format Definition: The property is defined by the following notation:
5353 rdate = "RDATE" rdtparam ":" rdtval *("," rdtval) CRLF
5355 rdtparam = *(
5357 ; the following are optional,
5358 ; but MUST NOT occur more than once
5360 (";" "VALUE" "=" ("DATE-TIME" / "DATE" / "PERIOD")) /
5361 (";" tzidparam) /
5363 ; the following is optional,
5364 ; and MAY occur more than once
5366 (";" xparam)
5368 )
5370 rdtval = date-time / date / period
5371 ;Value MUST match value type
5373 Example: The following are examples of this property:
5375 RDATE:19970714T123000Z
5377 RDATE;TZID=US-EASTERN:19970714T083000
5379 RDATE;VALUE=PERIOD:19960403T020000Z/19960403T040000Z,
5380 19960404T010000Z/PT3H
5382 RDATE;VALUE=DATE:19970101,19970120,19970217,19970421
5383 19970526,19970704,19970901,19971014,19971128,19971129,19971225
5385 3.8.5.3. Recurrence Rule
5387 Property Name: RRULE
5389 Purpose: This property defines a rule or repeating pattern for
5390 recurring events, to-dos, journal entries or time zone
5391 definitions.
5393 Value Type: RECUR
5395 Property Parameters: Non-standard property parameters can be
5396 specified on this property.
5398 Conformance: This property can be specified in recurring "VEVENT",
5399 "VTODO" and "VJOURNAL" calendar components as well as in the
5400 "STANDARD" and "DAYLIGHT" sub-components of the "VTIMEZONE"
5401 calendar component, but it SHOULD NOT be specified more than once.
5402 The recurrence set generated with multiple RRULE properties is
5403 undefined.
5405 Description: The recurrence rule, if specified, is used in computing
5406 the recurrence set. The recurrence set is the complete set of
5407 recurrence instances for a calendar component. The recurrence set
5408 is generated by considering the initial "DTSTART" property along
5409 with the "RRULE", "RDATE", and "EXDATE" properties contained
5410 within the recurring component. The "DTSTART" property defines
5411 the first instance in the recurrence set. The "DTSTART" property
5412 value SHOULD match the pattern of the recurrence rule, if
5413 specified. The recurrence set generated with a "DTSTART" property
5414 value that doesn't match the pattern of the rule is undefined.
5415 The final recurrence set is generated by gathering all of the
5416 start date/times generated by any of the specified "RRULE" and
5417 "RDATE" properties, and then excluding any start date/times
5418 specified by "EXDATE" properties. This implies that start date/
5419 times specified by "EXDATE" properties take precedence over those
5420 specified by inclusion properties (i.e., "RDATE" and "RRULE").
5421 Where duplicate instances are generated by the "RRULE" and "RDATE"
5422 properties, only one recurrence is considered. Duplicate
5423 instances are ignored.
5425 The "DTSTART" and "DTEND" property pair or "DTSTART" and
5426 "DURATION" property pair, specified within the iCalendar object
5427 defines the first instance of the recurrence. When used with a
5428 recurrence rule, the "DTSTART" and "DTEND" properties MUST be
5429 specified in local time and the appropriate set of "VTIMEZONE"
5430 calendar components MUST be included. For detail on the usage of
5431 the "VTIMEZONE" calendar component, see the "VTIMEZONE" calendar
5432 component definition.
5434 Any duration associated with the iCalendar object applies to all
5435 members of the generated recurrence set. Any modified duration
5436 for specific recurrences MUST be explicitly specified using the
5437 "RDATE" property.
5439 Format Definition: The property is defined by the following notation:
5441 rrule = "RRULE" rrulparam ":" recur CRLF
5443 rrulparam = *(";" xparam)
5445 Example: All examples assume the Eastern United States time zone.
5447 Daily for 10 occurrences:
5449 DTSTART;TZID=US-Eastern:19970902T090000
5450 RRULE:FREQ=DAILY;COUNT=10
5452 ==> (1997 9:00 AM EDT)September 2-11
5454 Daily until December 24, 1997:
5456 DTSTART;TZID=US-Eastern:19970902T090000
5457 RRULE:FREQ=DAILY;UNTIL=19971224T000000Z
5459 ==> (1997 9:00 AM EDT)September 2-30;October 1-25
5460 (1997 9:00 AM EST)October 26-31;November 1-30;December 1-23
5462 Every other day - forever:
5464 DTSTART;TZID=US-Eastern:19970902T090000
5465 RRULE:FREQ=DAILY;INTERVAL=2
5467 ==> (1997 9:00 AM EDT)September 2,4,6,8...24,26,28,30;
5468 October 2,4,6...20,22,24
5469 (1997 9:00 AM EST)October 26,28,30;November 1,3,5,7...25,27,29;
5470 December 1,3,...
5472 Every 10 days, 5 occurrences:
5474 DTSTART;TZID=US-Eastern:19970902T090000
5475 RRULE:FREQ=DAILY;INTERVAL=10;COUNT=5
5477 ==> (1997 9:00 AM EDT)September 2,12,22;October 2,12
5479 Everyday in January, for 3 years:
5481 DTSTART;TZID=US-Eastern:19980101T090000
5483 RRULE:FREQ=YEARLY;UNTIL=20000131T140000Z;
5484 BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA
5485 or
5486 RRULE:FREQ=DAILY;UNTIL=20000131T140000Z;BYMONTH=1
5488 ==> (1998 9:00 AM EST)January 1-31
5489 (1999 9:00 AM EST)January 1-31
5490 (2000 9:00 AM EST)January 1-31
5492 Weekly for 10 occurrences
5494 DTSTART;TZID=US-Eastern:19970902T090000
5495 RRULE:FREQ=WEEKLY;COUNT=10
5497 ==> (1997 9:00 AM EDT)September 2,9,16,23,30;October 7,14,21
5498 (1997 9:00 AM EST)October 28;November 4
5500 Weekly until December 24, 1997
5502 DTSTART;TZID=US-Eastern:19970902T090000
5503 RRULE:FREQ=WEEKLY;UNTIL=19971224T000000Z
5505 ==> (1997 9:00 AM EDT)September 2,9,16,23,30;October 7,14,21
5506 (1997 9:00 AM EST)October 28;November 4,11,18,25;
5507 December 2,9,16,23
5509 Every other week - forever:
5511 DTSTART;TZID=US-Eastern:19970902T090000
5512 RRULE:FREQ=WEEKLY;INTERVAL=2;WKST=SU
5514 ==> (1997 9:00 AM EDT)September 2,16,30;October 14
5515 (1997 9:00 AM EST)October 28;November 11,25;December 9,23
5516 (1998 9:00 AM EST)January 6,20;February
5517 ...
5519 Weekly on Tuesday and Thursday for 5 weeks:
5521 DTSTART;TZID=US-Eastern:19970902T090000
5522 RRULE:FREQ=WEEKLY;UNTIL=19971007T000000Z;WKST=SU;BYDAY=TU,TH
5523 or
5525 RRULE:FREQ=WEEKLY;COUNT=10;WKST=SU;BYDAY=TU,TH
5527 ==> (1997 9:00 AM EDT)September 2,4,9,11,16,18,23,25,30;October 2
5529 Every other week on Monday, Wednesday and Friday until December
5530 24, 1997, but starting on Tuesday, September 2, 1997:
5532 DTSTART;TZID=US-Eastern:19970902T090000
5533 RRULE:FREQ=WEEKLY;INTERVAL=2;UNTIL=19971224T000000Z;WKST=SU;
5534 BYDAY=MO,WE,FR
5536 ==> (1997 9:00 AM EDT)September 2,3,5,15,17,19,29;October
5537 1,3,13,15,17
5538 (1997 9:00 AM EST)October 27,29,31;November 10,12,14,24,26,28;
5539 December 8,10,12,22
5541 Every other week on Tuesday and Thursday, for 8 occurrences:
5543 DTSTART;TZID=US-Eastern:19970902T090000
5544 RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=8;WKST=SU;BYDAY=TU,TH
5546 ==> (1997 9:00 AM EDT)September 2,4,16,18,30;October 2,14,16
5548 Monthly on the 1st Friday for ten occurrences:
5550 DTSTART;TZID=US-Eastern:19970905T090000
5551 RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR
5553 ==> (1997 9:00 AM EDT)September 5;October 3
5554 (1997 9:00 AM EST)November 7;December 5
5555 (1998 9:00 AM EST)January 2;February 6;March 6;April 3
5556 (1998 9:00 AM EDT)May 1;June 5
5558 Monthly on the 1st Friday until December 24, 1997:
5560 DTSTART;TZID=US-Eastern:19970905T090000
5561 RRULE:FREQ=MONTHLY;UNTIL=19971224T000000Z;BYDAY=1FR
5563 ==> (1997 9:00 AM EDT)September 5;October 3
5564 (1997 9:00 AM EST)November 7;December 5
5566 Every other month on the 1st and last Sunday of the month for 10
5567 occurrences:
5569 DTSTART;TZID=US-Eastern:19970907T090000
5570 RRULE:FREQ=MONTHLY;INTERVAL=2;COUNT=10;BYDAY=1SU,-1SU
5572 ==> (1997 9:00 AM EDT)September 7,28
5573 (1997 9:00 AM EST)November 2,30
5574 (1998 9:00 AM EST)January 4,25;March 1,29
5575 (1998 9:00 AM EDT)May 3,31
5577 Monthly on the second to last Monday of the month for 6 months:
5579 DTSTART;TZID=US-Eastern:19970922T090000
5580 RRULE:FREQ=MONTHLY;COUNT=6;BYDAY=-2MO
5582 ==> (1997 9:00 AM EDT)September 22;October 20
5583 (1997 9:00 AM EST)November 17;December 22
5584 (1998 9:00 AM EST)January 19;February 16
5586 Monthly on the third to the last day of the month, forever:
5588 DTSTART;TZID=US-Eastern:19970928T090000
5589 RRULE:FREQ=MONTHLY;BYMONTHDAY=-3
5591 ==> (1997 9:00 AM EDT)September 28
5592 (1997 9:00 AM EST)October 29;November 28;December 29
5593 (1998 9:00 AM EST)January 29;February 26
5594 ...
5596 Monthly on the 2nd and 15th of the month for 10 occurrences:
5598 DTSTART;TZID=US-Eastern:19970902T090000
5599 RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=2,15
5601 ==> (1997 9:00 AM EDT)September 2,15;October 2,15
5602 (1997 9:00 AM EST)November 2,15;December 2,15
5603 (1998 9:00 AM EST)January 2,15
5605 Monthly on the first and last day of the month for 10 occurrences:
5607 DTSTART;TZID=US-Eastern:19970930T090000
5608 RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=1,-1
5610 ==> (1997 9:00 AM EDT)September 30;October 1
5611 (1997 9:00 AM EST)October 31;November 1,30;December 1,31
5612 (1998 9:00 AM EST)January 1,31;February 1
5614 Every 18 months on the 10th thru 15th of the month for 10
5615 occurrences:
5617 DTSTART;TZID=US-Eastern:19970910T090000
5618 RRULE:FREQ=MONTHLY;INTERVAL=18;COUNT=10;BYMONTHDAY=10,11,12,13,14,
5619 15
5621 ==> (1997 9:00 AM EDT)September 10,11,12,13,14,15
5622 (1999 9:00 AM EST)March 10,11,12,13
5624 Every Tuesday, every other month:
5626 DTSTART;TZID=US-Eastern:19970902T090000
5627 RRULE:FREQ=MONTHLY;INTERVAL=2;BYDAY=TU
5629 ==> (1997 9:00 AM EDT)September 2,9,16,23,30
5630 (1997 9:00 AM EST)November 4,11,18,25
5631 (1998 9:00 AM EST)January 6,13,20,27;March 3,10,17,24,31
5632 ...
5634 Yearly in June and July for 10 occurrences:
5636 DTSTART;TZID=US-Eastern:19970610T090000
5637 RRULE:FREQ=YEARLY;COUNT=10;BYMONTH=6,7
5638 ==> (1997 9:00 AM EDT)June 10;July 10
5639 (1998 9:00 AM EDT)June 10;July 10
5640 (1999 9:00 AM EDT)June 10;July 10
5641 (2000 9:00 AM EDT)June 10;July 10
5642 (2001 9:00 AM EDT)June 10;July 10
5643 Note: Since none of the BYDAY, BYMONTHDAY or BYYEARDAY components
5644 are specified, the day is gotten from DTSTART
5646 Every other year on January, February, and March for 10
5647 occurrences:
5649 DTSTART;TZID=US-Eastern:19970310T090000
5650 RRULE:FREQ=YEARLY;INTERVAL=2;COUNT=10;BYMONTH=1,2,3
5652 ==> (1997 9:00 AM EST)March 10
5653 (1999 9:00 AM EST)January 10;February 10;March 10
5654 (2001 9:00 AM EST)January 10;February 10;March 10
5655 (2003 9:00 AM EST)January 10;February 10;March 10
5657 Every 3rd year on the 1st, 100th and 200th day for 10 occurrences:
5659 DTSTART;TZID=US-Eastern:19970101T090000
5660 RRULE:FREQ=YEARLY;INTERVAL=3;COUNT=10;BYYEARDAY=1,100,200
5662 ==> (1997 9:00 AM EST)January 1
5663 (1997 9:00 AM EDT)April 10;July 19
5664 (2000 9:00 AM EST)January 1
5665 (2000 9:00 AM EDT)April 9;July 18
5666 (2003 9:00 AM EST)January 1
5667 (2003 9:00 AM EDT)April 10;July 19
5668 (2006 9:00 AM EST)January 1
5670 Every 20th Monday of the year, forever:
5672 DTSTART;TZID=US-Eastern:19970519T090000
5673 RRULE:FREQ=YEARLY;BYDAY=20MO
5675 ==> (1997 9:00 AM EDT)May 19
5676 (1998 9:00 AM EDT)May 18
5677 (1999 9:00 AM EDT)May 17
5678 ...
5680 Monday of week number 20 (where the default start of the week is
5681 Monday), forever:
5683 DTSTART;TZID=US-Eastern:19970512T090000
5684 RRULE:FREQ=YEARLY;BYWEEKNO=20;BYDAY=MO
5686 ==> (1997 9:00 AM EDT)May 12
5687 (1998 9:00 AM EDT)May 11
5688 (1999 9:00 AM EDT)May 17
5689 ...
5691 Every Thursday in March, forever:
5693 DTSTART;TZID=US-Eastern:19970313T090000
5694 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=TH
5696 ==> (1997 9:00 AM EST)March 13,20,27
5697 (1998 9:00 AM EST)March 5,12,19,26
5698 (1999 9:00 AM EST)March 4,11,18,25
5699 ...
5701 Every Thursday, but only during June, July, and August, forever:
5703 DTSTART;TZID=US-Eastern:19970605T090000
5704 RRULE:FREQ=YEARLY;BYDAY=TH;BYMONTH=6,7,8
5706 ==> (1997 9:00 AM EDT)June 5,12,19,26;July 3,10,17,24,31;
5707 August 7,14,21,28
5708 (1998 9:00 AM EDT)June 4,11,18,25;July 2,9,16,23,30;
5709 August 6,13,20,27
5710 (1999 9:00 AM EDT)June 3,10,17,24;July 1,8,15,22,29;
5711 August 5,12,19,26
5712 ...
5714 Every Friday the 13th, forever:
5716 DTSTART;TZID=US-Eastern:19970902T090000
5717 EXDATE;TZID=US-Eastern:19970902T090000
5718 RRULE:FREQ=MONTHLY;BYDAY=FR;BYMONTHDAY=13
5720 ==> (1998 9:00 AM EST)February 13;March 13;November 13
5721 (1999 9:00 AM EDT)August 13
5722 (2000 9:00 AM EDT)October 13
5723 ...
5725 The first Saturday that follows the first Sunday of the month,
5726 forever:
5728 DTSTART;TZID=US-Eastern:19970913T090000
5729 RRULE:FREQ=MONTHLY;BYDAY=SA;BYMONTHDAY=7,8,9,10,11,12,13
5731 ==> (1997 9:00 AM EDT)September 13;October 11
5732 (1997 9:00 AM EST)November 8;December 13
5733 (1998 9:00 AM EST)January 10;February 7;March 7
5734 (1998 9:00 AM EDT)April 11;May 9;June 13...
5735 ...
5737 Every four years, the first Tuesday after a Monday in November,
5738 forever (U.S. Presidential Election day):
5740 DTSTART;TZID=US-Eastern:19961105T090000
5741 RRULE:FREQ=YEARLY;INTERVAL=4;BYMONTH=11;BYDAY=TU;BYMONTHDAY=2,3,4,
5742 5,6,7,8
5744 ==> (1996 9:00 AM EST)November 5
5745 (2000 9:00 AM EST)November 7
5746 (2004 9:00 AM EST)November 2
5747 ...
5749 The 3rd instance into the month of one of Tuesday, Wednesday or
5750 Thursday, for the next 3 months:
5752 DTSTART;TZID=US-Eastern:19970904T090000
5753 RRULE:FREQ=MONTHLY;COUNT=3;BYDAY=TU,WE,TH;BYSETPOS=3
5755 ==> (1997 9:00 AM EDT)September 4;October 7
5756 (1997 9:00 AM EST)November 6
5758 The 2nd to last weekday of the month:
5760 DTSTART;TZID=US-Eastern:19970929T090000
5761 RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-2
5763 ==> (1997 9:00 AM EDT)September 29
5764 (1997 9:00 AM EST)October 30;November 27;December 30
5765 (1998 9:00 AM EST)January 29;February 26;March 30
5766 ...
5768 Every 3 hours from 9:00 AM to 5:00 PM on a specific day:
5770 DTSTART;TZID=US-Eastern:19970902T090000
5771 RRULE:FREQ=HOURLY;INTERVAL=3;UNTIL=19970902T170000Z
5772 ==> (September 2, 1997 EDT)09:00,12:00,15:00
5774 Every 15 minutes for 6 occurrences:
5776 DTSTART;TZID=US-Eastern:19970902T090000
5777 RRULE:FREQ=MINUTELY;INTERVAL=15;COUNT=6
5779 ==> (September 2, 1997 EDT)09:00,09:15,09:30,09:45,10:00,10:15
5781 Every hour and a half for 4 occurrences:
5783 DTSTART;TZID=US-Eastern:19970902T090000
5784 RRULE:FREQ=MINUTELY;INTERVAL=90;COUNT=4
5786 ==> (September 2, 1997 EDT)09:00,10:30;12:00;13:30
5788 Every 20 minutes from 9:00 AM to 4:40 PM every day:
5790 DTSTART;TZID=US-Eastern:19970902T090000
5791 RRULE:FREQ=DAILY;BYHOUR=9,10,11,12,13,14,15,16;BYMINUTE=0,20,40
5792 or
5793 RRULE:FREQ=MINUTELY;INTERVAL=20;BYHOUR=9,10,11,12,13,14,15,16
5795 ==> (September 2, 1997 EDT)9:00,9:20,9:40,10:00,10:20,
5796 ... 16:00,16:20,16:40
5797 (September 3, 1997 EDT)9:00,9:20,9:40,10:00,10:20,
5798 ...16:00,16:20,16:40
5799 ...
5801 An example where the days generated makes a difference because of
5802 WKST:
5804 DTSTART;TZID=US-Eastern:19970805T090000
5805 RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=4;BYDAY=TU,SU;WKST=MO
5807 ==> (1997 EDT)Aug 5,10,19,24
5809 changing only WKST from MO to SU, yields different results...
5811 DTSTART;TZID=US-Eastern:19970805T090000
5812 RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=4;BYDAY=TU,SU;WKST=SU
5813 ==> (1997 EDT)August 5,17,19,31
5815 3.8.6. Alarm Component Properties
5817 The following properties specify alarm information in calendar
5818 components.
5820 3.8.6.1. Action
5822 Property Name: ACTION
5824 Purpose: This property defines the action to be invoked when an alarm
5825 is triggered.
5827 Value Type: TEXT
5829 Property Parameters: Non-standard property parameters can be
5830 specified on this property.
5832 Conformance: This property MUST be specified once in a "VALARM"
5833 calendar component.
5835 Description: Each "VALARM" calendar component has a particular type
5836 of action associated with it. This property specifies the type of
5837 action
5839 Format Definition: The property is defined by the following notation:
5841 action = "ACTION" actionparam ":" actionvalue CRLF
5843 actionparam = *(";" xparam)
5845 actionvalue = "AUDIO" / "DISPLAY" / "EMAIL" / "PROCEDURE"
5846 / iana-token / x-name
5848 Example: The following are examples of this property in a "VALARM"
5849 calendar component:
5851 ACTION:AUDIO
5853 ACTION:DISPLAY
5855 ACTION:PROCEDURE
5857 3.8.6.2. Repeat Count
5859 Property Name: REPEAT
5861 Purpose: This property defines the number of time the alarm should be
5862 repeated, after the initial trigger.
5864 Value Type: INTEGER
5865 Property Parameters: Non-standard property parameters can be
5866 specified on this property.
5868 Conformance: This property can be specified in a "VALARM" calendar
5869 component.
5871 Description: If the alarm triggers more than once, then this property
5872 MUST be specified along with the "DURATION" property.
5874 Format Definition: The property is defined by the following notation:
5876 repeat = "REPEAT" repparam ":" integer CRLF
5877 ;Default is "0", zero.
5879 repparam = *(";" xparam)
5881 Example: The following is an example of this property for an alarm
5882 that repeats 4 additional times with a 5 minute delay after the
5883 initial triggering of the alarm:
5885 REPEAT:4
5886 DURATION:PT5M
5888 3.8.6.3. Trigger
5890 Property Name: TRIGGER
5892 Purpose: This property specifies when an alarm will trigger.
5894 Value Type: The default value type is DURATION. The value type can
5895 be set to a DATE-TIME value type, in which case the value MUST
5896 specify a UTC formatted DATE-TIME value.
5898 Property Parameters: Non-standard, value data type, time zone
5899 identifier or trigger relationship property parameters can be
5900 specified on this property. The trigger relationship property
5901 parameter MUST only be specified when the value type is DURATION.
5903 Conformance: This property MUST be specified in the "VALARM" calendar
5904 component.
5906 Description: Within the "VALARM" calendar component, this property
5907 defines when the alarm will trigger. The default value type is
5908 DURATION, specifying a relative time for the trigger of the alarm.
5909 The default duration is relative to the start of an event or to-do
5910 that the alarm is associated with. The duration can be explicitly
5911 set to trigger from either the end or the start of the associated
5912 event or to-do with the "RELATED" parameter. A value of START
5913 will set the alarm to trigger off the start of the associated
5914 event or to-do. A value of END will set the alarm to trigger off
5915 the end of the associated event or to-do.
5917 Either a positive or negative duration may be specified for the
5918 "TRIGGER" property. An alarm with a positive duration is
5919 triggered after the associated start or end of the event or to-do.
5920 An alarm with a negative duration is triggered before the
5921 associated start or end of the event or to-do.
5923 The "RELATED" property parameter is not valid if the value type of
5924 the property is set to DATE-TIME (i.e., for an absolute date and
5925 time alarm trigger). If a value type of DATE-TIME is specified,
5926 then the property value MUST be specified in the UTC time format.
5927 If an absolute trigger is specified on an alarm for a recurring
5928 event or to-do, then the alarm will only trigger for the specified
5929 absolute date/time, along with any specified repeating instances.
5931 If the trigger is set relative to START, then the "DTSTART"
5932 property MUST be present in the associated "VEVENT" or "VTODO"
5933 calendar component. If an alarm is specified for an event with
5934 the trigger set relative to the END, then the "DTEND" property or
5935 the "DTSTART" and "DURATION " properties MUST be present in the
5936 associated "VEVENT" calendar component. If the alarm is specified
5937 for a to-do with a trigger set relative to the END, then either
5938 the "DUE" property or the "DTSTART" and "DURATION " properties
5939 MUST be present in the associated "VTODO" calendar component.
5941 Alarms specified in an event or to-do which is defined in terms of
5942 a DATE value type will be triggered relative to 00:00:00 UTC on
5943 the specified date. For example, if DTSTART is a DATE value set
5944 to 19980205 then the duration trigger will be relative to
5945 19980205T000000Z.
5947 Format Definition: The property is defined by the following notation:
5949 trigger = "TRIGGER" (trigrel / trigabs) CRLF
5951 trigrel = *(
5953 ; the following are optional,
5954 ; but MUST NOT occur more than once
5956 (";" "VALUE" "=" "DURATION") /
5957 (";" trigrelparam) /
5959 ; the following is optional,
5960 ; and MAY occur more than once
5962 (";" xparam)
5963 ) ":" dur-value
5965 trigabs = 1*(
5967 ; the following is REQUIRED,
5968 ; but MUST NOT occur more than once
5970 (";" "VALUE" "=" "DATE-TIME") /
5972 ; the following is optional,
5973 ; and MAY occur more than once
5975 (";" xparam)
5977 ) ":" date-time
5979 Example: A trigger set 15 minutes prior to the start of the event or
5980 to-do.
5982 TRIGGER:-P15M
5984 A trigger set 5 minutes after the end of the event or to-do.
5986 TRIGGER;RELATED=END:P5M
5988 A trigger set to an absolute date/time.
5990 TRIGGER;VALUE=DATE-TIME:19980101T050000Z
5992 3.8.7. Change Management Component Properties
5994 The following properties specify change management information in
5995 calendar components.
5997 3.8.7.1. Date/Time Created
5999 Property Name: CREATED
6001 Purpose: This property specifies the date and time that the calendar
6002 information was created by the calendar user agent in the calendar
6003 store.
6005 Note: This is analogous to the creation date and time for a
6006 file in the file system.
6008 Value Type: DATE-TIME
6010 Property Parameters: Non-standard property parameters can be
6011 specified on this property.
6013 Conformance: The property can be specified once in "VEVENT", "VTODO"
6014 or "VJOURNAL" calendar components.
6016 Description: The date and time is a UTC value.
6018 Format Definition: The property is defined by the following notation:
6020 created = "CREATED" creaparam ":" date-time CRLF
6022 creaparam = *(";" xparam)
6024 Example: The following is an example of this property:
6026 CREATED:19960329T133000Z
6028 3.8.7.2. Date/Time Stamp
6030 Property Name: DTSTAMP
6032 Purpose: The property indicates the date/time that the instance of
6033 the iCalendar object was created.
6035 Value Type: DATE-TIME
6037 Property Parameters: Non-standard property parameters can be
6038 specified on this property.
6040 Conformance: This property MUST be included in the "VEVENT", "VTODO",
6041 "VJOURNAL" or "VFREEBUSY" calendar components.
6043 Description: The value MUST be specified in the UTC time format.
6045 This property is also useful to protocols such as [I-D.ietf-
6046 calsify-rfc2447bis] that have inherent latency issues with the
6047 delivery of content. This property will assist in the proper
6048 sequencing of messages containing iCalendar objects.
6050 This property is different than the "CREATED" and "LAST-MODIFIED"
6051 properties. These two properties are used to specify when the
6052 particular calendar data in the calendar store was created and
6053 last modified. This is different than when the iCalendar object
6054 representation of the calendar service information was created or
6055 last modified.
6057 Format Definition: The property is defined by the following notation:
6059 dtstamp = "DTSTAMP" stmparam ":" date-time CRLF
6061 stmparam = *(";" xparam)
6063 Example:
6065 DTSTAMP:19971210T080000Z
6067 3.8.7.3. Last Modified
6069 Property Name: LAST-MODIFIED
6071 Purpose: The property specifies the date and time that the
6072 information associated with the calendar component was last
6073 revised in the calendar store.
6075 Note: This is analogous to the modification date and time for a
6076 file in the file system.
6078 Value Type: DATE-TIME
6080 Property Parameters: Non-standard property parameters can be
6081 specified on this property.
6083 Conformance: This property can be specified in the "EVENT", "VTODO",
6084 "VJOURNAL" or "VTIMEZONE" calendar components.
6086 Description: The property value MUST be specified in the UTC time
6087 format.
6089 Format Definition: The property is defined by the following notation:
6091 last-mod = "LAST-MODIFIED" lstparam ":" date-time CRLF
6093 lstparam = *(";" xparam)
6095 Example: The following are examples of this property:
6097 LAST-MODIFIED:19960817T133000Z
6099 3.8.7.4. Sequence Number
6101 Property Name: SEQUENCE
6103 Purpose: This property defines the revision sequence number of the
6104 calendar component within a sequence of revisions.
6106 Value Type: INTEGER
6108 Property Parameters: Non-standard property parameters can be
6109 specified on this property.
6111 Conformance: The property can be specified in "VEVENT", "VTODO" or
6112 "VJOURNAL" calendar component.
6114 Description: When a calendar component is created, its sequence
6115 number is zero (US-ASCII decimal 48). It is monotonically
6116 incremented by the "Organizer's" CUA each time the "Organizer"
6117 makes a significant revision to the calendar component. When the
6118 "Organizer" makes changes to one of the following properties, the
6119 sequence number MUST be incremented:
6121 * "DTSTART"
6123 * "DTEND"
6125 * "DURATION"
6127 * "DUE"
6129 * "RDATE"
6131 * "RRULE"
6133 * "EXDATE"
6135 * "STATUS"
6136 In addition, changes made by the "Organizer" to other properties
6137 can also force the sequence number to be incremented. The
6138 "Organizer" CUA MUST increment the sequence number when ever it
6139 makes changes to properties in the calendar component that the
6140 "Organizer" deems will jeopardize the validity of the
6141 participation status of the "Attendees". For example, changing
6142 the location of a meeting from one locale to another distant
6143 locale could effectively impact the participation status of the
6144 "Attendees".
6146 The "Organizer" includes this property in an iCalendar object that
6147 it sends to an "Attendee" to specify the current version of the
6148 calendar component.
6150 The "Attendee" includes this property in an iCalendar object that
6151 it sends to the "Organizer" to specify the version of the calendar
6152 component that the "Attendee" is referring to.
6154 A change to the sequence number is not the mechanism that an
6155 "Organizer" uses to request a response from the "Attendees". The
6156 "RSVP" parameter on the "ATTENDEE" property is used by the
6157 "Organizer" to indicate that a response from the "Attendees" is
6158 requested.
6160 Format Definition: The property is defined by the following notation:
6162 seq = "SEQUENCE" seqparam ":" integer CRLF
6163 ; Default is "0"
6165 seqparam = *(";" xparam)
6167 Example: The following is an example of this property for a calendar
6168 component that was just created by the "Organizer".
6170 SEQUENCE:0
6172 The following is an example of this property for a calendar
6173 component that has been revised two different times by the
6174 "Organizer".
6176 SEQUENCE:2
6178 3.8.8. Miscellaneous Component Properties
6180 The following properties specify information about a number of
6181 miscellaneous features of calendar components.
6183 3.8.8.1. Non-standard Properties
6185 Property Name: Any property name with a "X-" prefix
6187 Purpose: This class of property provides a framework for defining
6188 non-standard properties.
6190 Value Type: TEXT
6192 Property Parameters: Non-standard and language property parameters
6193 can be specified on this property.
6195 Conformance: This property can be specified in any calendar
6196 component.
6198 Description: The MIME Calendaring and Scheduling Content Type
6199 provides a "standard mechanism for doing non-standard things".
6200 This extension support is provided for implementers to "push the
6201 envelope" on the existing version of the memo. Extension
6202 properties are specified by property and/or property parameter
6203 names that have the prefix text of "X-" (the two character
6204 sequence: LATIN CAPITAL LETTER X character followed by the HYPHEN-
6205 MINUS character). It is recommended that vendors concatenate onto
6206 this sentinel another short prefix text to identify the vendor.
6207 This will facilitate readability of the extensions and minimize
6208 possible collision of names between different vendors. User
6209 agents that support this content type are expected to be able to
6210 parse the extension properties and property parameters but can
6211 ignore them.
6213 At present, there is no registration authority for names of
6214 extension properties and property parameters. The data type for
6215 this property is TEXT. Optionally, the data type can be any of
6216 the other valid data types.
6218 Format Definition: The property is defined by the following notation:
6220 x-prop = x-name *(";" xparam) [";" languageparam] ":" text CRLF
6221 ; Lines longer than 75 octets should be folded
6223 Example: The following might be the ABC vendor's extension for an
6224 audio-clip form of subject property:
6226 X-ABC-MMSUBJ;X-ABC-MMSUBJTYPE=wave:http://load.noise.org/mysubj.wav
6228 3.8.8.2. Request Status
6230 Property Name: REQUEST-STATUS
6232 Purpose: This property defines the status code returned for a
6233 scheduling request.
6235 Value Type: TEXT
6237 Property Parameters: Non-standard and language property parameters
6238 can be specified on this property.
6240 Conformance: The property can be specified in "VEVENT", "VTODO",
6241 "VJOURNAL" or "VFREEBUSY" calendar component.
6243 Description: This property is used to return status code information
6244 related to the processing of an associated iCalendar object. The
6245 data type for this property is TEXT.
6247 The value consists of a short return status component, a longer
6248 return status description component, and optionally a status-
6249 specific data component. The components of the value are
6250 separated by the SEMICOLON character (US-ASCII decimal 59).
6252 The short return status is a PERIOD character (US-ASCII decimal
6253 46) separated 3-tuple of integers. For example, "3.1.1". The
6254 successive levels of integers provide for a successive level of
6255 status code granularity.
6257 The following are initial classes for the return status code.
6258 Individual iCalendar object methods will define specific return
6259 status codes for these classes. In addition, other classes for
6260 the return status code may be defined using the registration
6261 process defined later in this memo.
6263 |==============+===============================================|
6264 | Short Return | Longer Return Status Description |
6265 | Status Code | |
6266 |==============+===============================================|
6267 | 1.xx | Preliminary success. This class of status |
6268 | | of status code indicates that the request has |
6269 | | request has been initially processed but that |
6270 | | completion is pending. |
6271 |==============+===============================================|
6272 | 2.xx | Successful. This class of status code |
6273 | | indicates that the request was completed |
6274 | | successfuly. However, the exact status code |
6275 | | can indicate that a fallback has been taken. |
6276 |==============+===============================================|
6277 | 3.xx | Client Error. This class of status code |
6278 | | indicates that the request was not successful.|
6279 | | The error is the result of either a syntax or |
6280 | | a semantic error in the client formatted |
6281 | | request. Request should not be retried until |
6282 | | the condition in the request is corrected. |
6283 |==============+===============================================|
6284 | 4.xx | Scheduling Error. This class of status code |
6285 | | indicates that the request was not successful.|
6286 | | Some sort of error occurred within the |
6287 | | calendaring and scheduling service, not |
6288 | | directly related to the request itself. |
6289 |==============+===============================================|
6291 Format Definition: The property is defined by the following notation:
6293 rstatus = "REQUEST-STATUS" rstatparam ":"
6294 statcode ";" statdesc [";" extdata]
6296 rstatparam = *(
6298 ; the following is optional,
6299 ; but MUST NOT occur more than once
6301 (";" languageparam) /
6303 ; the following is optional,
6304 ; and MAY occur more than once
6306 (";" xparam)
6308 )
6310 statcode = 1*DIGIT *("." 1*DIGIT)
6311 ;Hierarchical, numeric return status code
6313 statdesc = text
6314 ;Textual status description
6316 extdata = text
6317 ;Textual exception data. For example, the offending property
6318 ;name and value or complete property line.
6320 Example: The following are some possible examples of this property.
6322 The COMMA and SEMICOLON separator characters in the property value
6323 are BACKSLASH character escaped because they appear in a text
6324 value.
6326 REQUEST-STATUS:2.0;Success
6328 REQUEST-STATUS:3.1;Invalid property value;DTSTART:96-Apr-01
6330 REQUEST-STATUS:2.8; Success\, repeating event ignored. Scheduled
6331 as a single event.;RRULE:FREQ=WEEKLY\;INTERVAL=2
6333 REQUEST-STATUS:4.1;Event conflict. Date/time is busy.
6335 REQUEST-STATUS:3.7;Invalid calendar user;ATTENDEE:
6336 MAILTO:jsmith@example.com
6338 4. iCalendar Object Examples
6340 The following examples are provided as an informational source of
6341 illustrative iCalendar objects consistent with this content type.
6343 The following example specifies a three-day conference that begins at
6344 8:00 AM EDT, September 18, 1996 and end at 6:00 PM EDT, September 20,
6345 1996.
6347 BEGIN:VCALENDAR
6348 PRODID:-//xyz Corp//NONSGML PDA Calendar Version 1.0//EN
6349 VERSION:2.0
6350 BEGIN:VEVENT
6351 DTSTAMP:19960704T120000Z
6352 UID:uid1@example.com
6353 ORGANIZER:MAILTO:jsmith@example.com
6354 DTSTART:19960918T143000Z
6355 DTEND:19960920T220000Z
6356 STATUS:CONFIRMED
6357 CATEGORIES:CONFERENCE
6358 SUMMARY:Networld+Interop Conference
6359 DESCRIPTION:Networld+Interop Conference
6360 and Exhibit\nAtlanta World Congress Center\n
6361 Atlanta\, Georgia
6362 END:VEVENT
6363 END:VCALENDAR
6365 The following example specifies a group scheduled meeting that begin
6366 at 8:30 AM EST on March 12, 1998 and end at 9:30 AM EST on March 12,
6367 1998. The "Organizer" has scheduled the meeting with one or more
6368 calendar users in a group. A time zone specification for Eastern
6369 United States has been specified.
6371 BEGIN:VCALENDAR
6372 PRODID:-//RDU Software//NONSGML HandCal//EN
6373 VERSION:2.0
6374 BEGIN:VTIMEZONE
6375 TZID:US-Eastern
6376 BEGIN:STANDARD
6377 DTSTART:19981025T020000
6378 RDATE:19981025T020000
6379 TZOFFSETFROM:-0400
6380 TZOFFSETTO:-0500
6381 TZNAME:EST
6382 END:STANDARD
6383 BEGIN:DAYLIGHT
6384 DTSTART:19990404T020000
6385 RDATE:19990404T020000
6386 TZOFFSETFROM:-0500
6387 TZOFFSETTO:-0400
6388 TZNAME:EDT
6389 END:DAYLIGHT
6390 END:VTIMEZONE
6391 BEGIN:VEVENT
6392 DTSTAMP:19980309T231000Z
6393 UID:guid-1.example.com
6394 ORGANIZER;ROLE=CHAIR:MAILTO:mrbig@example.com
6395 ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;CUTYPE=GROUP:
6396 MAILTO:employee-A@example.com
6397 DESCRIPTION:Project XYZ Review Meeting
6398 CATEGORIES:MEETING
6399 CLASS:PUBLIC
6400 CREATED:19980309T130000Z
6401 SUMMARY:XYZ Project Review
6402 DTSTART;TZID=US-Eastern:19980312T083000
6403 DTEND;TZID=US-Eastern:19980312T093000
6404 LOCATION:1CP Conference Room 4350
6405 END:VEVENT
6406 END:VCALENDAR
6408 The following is an example of an iCalendar object passed in a MIME
6409 message with a single body part consisting of a "text/calendar"
6410 Content Type.
6412 TO:jsmith@example.com
6413 FROM:jdoe@example.com
6414 MIME-VERSION:1.0
6415 MESSAGE-ID:
6416 CONTENT-TYPE:text/calendar; method="xyz"; component="VEVENT"
6418 BEGIN:VCALENDAR
6419 METHOD:xyz
6420 VERSION:2.0
6421 PRODID:-//ABC Corporation//NONSGML My Product//EN
6422 BEGIN:VEVENT
6423 DTSTAMP:19970324T120000Z
6424 SEQUENCE:0
6425 UID:uid3@example.com
6426 ORGANIZER:MAILTO:jdoe@example.com
6427 ATTENDEE;RSVP=TRUE:MAILTO:jsmith@example.com
6428 DTSTART:19970324T123000Z
6429 DTEND:19970324T210000Z
6430 CATEGORIES:MEETING,PROJECT
6431 CLASS:PUBLIC
6432 SUMMARY:Calendaring Interoperability Planning Meeting
6433 DESCRIPTION:Discuss how we can test c&s interoperability\n
6434 using iCalendar and other IETF standards.
6435 LOCATION:LDB Lobby
6436 ATTACH;FMTTYPE=application/postscript:ftp://example.com/pub/
6437 conf/bkgrnd.ps
6438 END:VEVENT
6439 END:VCALENDAR
6441 The following is an example of a to-do due on April 15, 1998. An
6442 audio alarm has been specified to remind the calendar user at noon,
6443 the day before the to-do is expected to be completed and repeat
6444 hourly, four additional times. The to-do definition has been
6445 modified twice since it was initially created.
6447 BEGIN:VCALENDAR
6448 VERSION:2.0
6449 PRODID:-//ABC Corporation//NONSGML My Product//EN
6450 BEGIN:VTODO
6451 DTSTAMP:19980130T134500Z
6452 SEQUENCE:2
6453 UID:uid4@example.com
6454 ORGANIZER:MAILTO:unclesam@us.gov
6455 ATTENDEE;PARTSTAT=ACCEPTED:MAILTO:jqpublic@example.com
6456 DUE:19980415T235959
6457 STATUS:NEEDS-ACTION
6458 SUMMARY:Submit Income Taxes
6459 BEGIN:VALARM
6460 ACTION:AUDIO
6461 TRIGGER:19980403T120000Z
6462 ATTACH;FMTTYPE=audio/basic:http://example.com/pub/audio-
6463 files/ssbanner.aud
6464 REPEAT:4
6465 DURATION:PT1H
6466 END:VALARM
6467 END:VTODO
6468 END:VCALENDAR
6470 The following is an example of a journal entry.
6472 BEGIN:VCALENDAR
6473 VERSION:2.0
6474 PRODID:-//ABC Corporation//NONSGML My Product//EN
6475 BEGIN:VJOURNAL
6476 DTSTAMP:19970324T120000Z
6477 UID:uid5@example.com
6478 ORGANIZER:MAILTO:jsmith@example.com
6479 STATUS:DRAFT
6480 CLASS:PUBLIC
6481 CATEGORIES:Project Report,XYZ,Weekly Meeting
6482 DESCRIPTION:Project xyz Review Meeting Minutes\n
6483 Agenda\n1. Review of project version 1.0 requirements.\n2.
6484 Definition
6485 of project processes.\n3. Review of project schedule.\n
6486 Participants: John Smith\, Jane Doe\, Jim Dandy\n-It was
6487 decided that the requirements need to be signed off by
6488 product marketing.\n-Project processes were accepted.\n
6489 -Project schedule needs to account for scheduled holidays
6490 and employee vacation time. Check with HR for specific
6491 dates.\n-New schedule will be distributed by Friday.\n-
6492 Next weeks meeting is cancelled. No meeting until 3/23.
6493 END:VJOURNAL
6494 END:VCALENDAR
6496 The following is an example of published busy time information. The
6497 iCalendar object might be placed in the network resource
6498 http://www.example.com/calendar/busytime/jsmith.ifb.
6500 BEGIN:VCALENDAR
6501 VERSION:2.0
6502 PRODID:-//RDU Software//NONSGML HandCal//EN
6503 BEGIN:VFREEBUSY
6504 ORGANIZER:MAILTO:jsmith@example.com
6505 DTSTART:19980313T141711Z
6506 DTEND:19980410T141711Z
6507 FREEBUSY:19980314T233000Z/19980315T003000Z
6508 FREEBUSY:19980316T153000Z/19980316T163000Z
6509 FREEBUSY:19980318T030000Z/19980318T040000Z
6510 URL:http://www.example.com/calendar/busytime/jsmith.ifb
6511 END:VFREEBUSY
6512 END:VCALENDAR
6514 5. Recommended Practices
6516 These recommended practices should be followed in order to assure
6517 consistent handling of the following cases for an iCalendar object.
6519 1. Content lines longer than 75 octets SHOULD be folded.
6521 2. A calendar entry with a "DTSTART" property but no "DTEND"
6522 property does not take up any time. It is intended to represent
6523 an event that is associated with a given calendar date and time
6524 of day, such as an anniversary. Since the event does not take
6525 up any time, it MUST NOT be used to record busy time no matter
6526 what the value for the "TRANSP" property.
6528 3. When the "DTSTART" and "DTEND", for "VEVENT", "VJOURNAL" and
6529 "VFREEBUSY" calendar components, and "DTSTART" and "DUE", for
6530 "VTODO" calendar components, have the same value data type
6531 (e.g., DATE-TIME), they SHOULD specify values in the same time
6532 format (e.g., UTC time format).
6534 4. When the combination of the "RRULE" and "RDATE" properties on an
6535 iCalendar object produces multiple instances having the same
6536 start date/time, they should be collapsed to, and considered as,
6537 a single instance.
6539 5. When a calendar user receives multiple requests for the same
6540 calendar component (e.g., REQUEST for a "VEVENT" calendar
6541 component) as a result of being on multiple mailing lists
6542 specified by "ATTENDEE" properties in the request, they SHOULD
6543 respond to only one of the requests. The calendar user SHOULD
6544 also specify (using the "MEMBER" parameter of the "ATTENDEE"
6545 property) which mailing list they are a member of.
6547 6. An implementation can truncate a "SUMMARY" property value to 255
6548 octets, but MUST NOT truncate the value in the middle of a UTF-8
6549 multi-octet sequence.
6551 7. If seconds of the minute are not supported by an implementation,
6552 then a value of "00" SHOULD be specified for the seconds
6553 component in a time value.
6555 8. If the value type parameter (VALUE=) contains an unknown value
6556 type, it SHOULD be treated as TEXT.
6558 9. TZURL values SHOULD NOT be specified as a FILE URI type. This
6559 URI form can be useful within an organization, but is
6560 problematic in the Internet.
6562 10. Some possible English values for CATEGORIES property include
6563 "ANNIVERSARY", "APPOINTMENT", "BUSINESS", "EDUCATION",
6564 "HOLIDAY", "MEETING", "MISCELLANEOUS", "NON-WORKING HOURS", "NOT
6565 IN OFFICE", "PERSONAL", "PHONE CALL", "SICK DAY", "SPECIAL
6566 OCCASION", "TRAVEL", "VACATION". Categories can be specified in
6567 any registered language.
6569 11. Some possible English values for RESOURCES property include
6570 "CATERING", "CHAIRS", "COMPUTER PROJECTOR", "EASEL", "OVERHEAD
6571 PROJECTOR", "SPEAKER PHONE", "TABLE", "TV", "VCR", "VIDEO
6572 PHONE", "VEHICLE". Resources can be specified in any registered
6573 language.
6575 6. Registration of Content Type Elements
6577 This section provides the process for registration of MIME
6578 Calendaring and Scheduling Content Type iCalendar object methods and
6579 new or modified properties.
6581 6.1. Registration of New and Modified iCalendar Object Methods
6583 New MIME Calendaring and Scheduling Content Type iCalendar object
6584 methods are registered by the publication of an IETF Request for
6585 Comments (RFC). Changes to an iCalendar object method are registered
6586 by the publication of a revision of the RFC defining the method.
6588 6.2. Registration of New Properties
6590 This section defines procedures by which new properties or enumerated
6591 property values for the MIME Calendaring and Scheduling Content Type
6592 can be registered with the IANA. Non-IANA properties can be used by
6593 bilateral agreement, provided the associated properties names follow
6594 the "X-" convention.
6596 The procedures defined here are designed to allow public comment and
6597 review of new properties, while posing only a small impediment to the
6598 definition of new properties.
6600 Registration of a new property is accomplished by the following
6601 steps.
6603 6.2.1. Define the property
6605 A property is defined by completing the following template.
6607 To: ietf-calendar@imc.org
6609 Subject: Registration of text/calendar MIME property XXX
6611 Property name:
6613 Property purpose:
6615 Property value type(s):
6617 Property parameter (s):
6619 Conformance:
6621 Description:
6623 Format definition:
6625 Examples:
6627 The meaning of each field in the template is as follows.
6629 Property name: The name of the property, as it will appear in the
6630 body of an text/calendar MIME Content-Type "property: value" line
6631 to the left of the colon ":".
6633 Property purpose: The purpose of the property (e.g., to indicate a
6634 delegate for the event or to-do, etc.). Give a short but clear
6635 description.
6637 Property value type (s): Any of the valid value types for the
6638 property value needs to be specified. The default value type also
6639 needs to be specified. If a new value type is specified, it needs
6640 to be declared in this section.
6642 Property parameter (s): Any of the valid property parameters for the
6643 property needs to be specified.
6645 Conformance: The calendar components that the property can appear in
6646 needs to be specified.
6648 Description: Any special notes about the property, how it is to be
6649 used, etc.
6651 Format definition: The ABNF for the property definition needs to be
6652 specified.
6654 Examples: One or more examples of instances of the property needs to
6655 be specified.
6657 6.2.2. Post the Property definition
6659 The property description MUST be posted to the new property
6660 discussion list, ietf-calendar@imc.org.
6662 6.2.3. Allow a comment period
6664 Discussion on the new property MUST be allowed to take place on the
6665 list for a minimum of two weeks. Consensus MUST be reached on the
6666 property before proceeding to the next step.
6668 6.2.4. Submit the property for approval
6670 Once the two-week comment period has elapsed, and the proposer is
6671 convinced consensus has been reached on the property, the
6672 registration application should be submitted to the Method Reviewer
6673 for approval. The Method Reviewer is appointed by the Application
6674 Area Directors and can either accept or reject the property
6675 registration. An accepted registration should be passed on by the
6676 Method Reviewer to the IANA for inclusion in the official IANA method
6677 registry. The registration can be rejected for any of the following
6678 reasons. 1) Insufficient comment period; 2) Consensus not reached; 3)
6679 Technical deficiencies raised on the list or elsewhere have not been
6680 addressed. The Method Reviewer's decision to reject a property can
6681 be appealed by the proposer to the IESG, or the objections raised can
6682 be addressed by the proposer and the property resubmitted.
6684 6.3. Property Change Control
6686 Existing properties can be changed using the same process by which
6687 they were registered.
6689 1. Define the change
6691 2. Post the change
6693 3. Allow a comment period
6695 4. Submit the property for approval
6697 Note that the original author or any other interested party can
6698 propose a change to an existing property, but that such changes
6699 should only be proposed when there are serious omissions or errors in
6700 the published memo. The Method Reviewer can object to a change if it
6701 is not backward compatible, but is not required to do so.
6703 Property definitions can never be deleted from the IANA registry, but
6704 properties which are no longer believed to be useful can be declared
6705 OBSOLETE by a change to their "intended use" field.
6707 7. Internationalization Considerations
6709 8. Security Considerations
6711 SPOOFING: In this memo, the "Organizer" is the only person authorized
6712 to make changes to an existing "VEVENT", "VTODO", "VJOURNAL"
6713 calendar component and redistribute the updates to the
6714 "Attendees". An iCalendar object that maliciously changes or
6715 cancels an existing "VEVENT", "VTODO" or "VJOURNAL" or "VFREEBUSY"
6716 calendar component might be constructed by someone other than the
6717 "Organizer" and sent to the "Attendees". In addition in this
6718 memo, other than the "Organizer", an "Attendee" of a "VEVENT",
6719 "VTODO", "VJOURNAL" calendar component is the only other person
6720 authorized to update any parameter associated with their
6721 "ATTENDEE" property and send it to the "Organizer". An iCalendar
6722 object that maliciously changes the "ATTENDEE" parameters can be
6723 constructed by someone other than the real "Attendee" and sent to
6724 the "Organizer".
6726 PROCEDURAL ALARMS: An iCalendar object can be created that contains a
6727 "VEVENT" and "VTODO" calendar component with "VALARM" calendar
6728 components. The "VALARM" calendar component can be of type
6729 PROCEDURE and can have an attachment containing some sort of
6730 executable program. Implementations that incorporate these types
6731 of alarms are subject to any virus or malicious attack that might
6732 occur as a result of executing the attachment.
6734 ATTACHMENTS: An iCalendar object can include references to Uniform
6735 Resource Locators that can be programmed resources.
6737 Implementers and users of this memo should be aware of the network
6738 security implications of accepting and parsing such information.
6739 In addition, the security considerations observed by
6740 implementations of electronic mail systems should be followed for
6741 this memo.
6743 9. IANA Consideration
6745 9.1. Media Type Registration Information
6747 The Calendaring and Scheduling Core Object Specification is intended
6748 for use as a MIME content type. However, the implementation of the
6749 memo is in no way limited solely as a MIME content type.
6751 To: ietf-types@iana.org
6752 Subject: Registration of media type text/calendar
6754 Type name: text
6756 Subtype name: calendar
6758 Required parameters: none
6760 Optional parameters: charset, method, component and optinfo
6762 The "charset" parameter is defined in [RFC2046] for subtypes of
6763 the "text" media type. It is used to indicate the charset used in
6764 the body part. The charset supported by this revision of
6765 iCalendar is UTF-8. The use of any other charset is deprecated by
6766 this revision of iCalendar; however note that this revision
6767 requires that compliant applications MUST accept iCalendar objects
6768 using either the UTF-8 or US-ASCII charset.
6770 The "method" parameter is used to convey the iCalendar object
6771 method or transaction semantics for the calendaring and scheduling
6772 information. It also is an identifier for the restricted set of
6773 properties and values that the iCalendar object consists of. The
6774 parameter is to be used as a guide for applications interpreting
6775 the information contained within the body part. It SHOULD NOT be
6776 used to exclude or require particular pieces of information unless
6777 the identified method definition specifically calls for this
6778 behavior. Unless specifically forbidden by a particular method
6779 definition, a text/calendar content type can contain any set of
6780 properties permitted by the Calendaring and Scheduling Core Object
6781 Specification. The "method" parameter MUST be the same value as
6782 that specified in the "METHOD" component property in the iCalendar
6783 object. If one is present, the other MUST also be present.
6785 The value for the "method" parameter is defined as follows:
6787 method = 1*(ALPHA / DIGIT / "-")
6788 ; IANA registered iCalendar object method
6790 The "component" parameter conveys the type of iCalendar calendar
6791 component within the body part. If the iCalendar object contains
6792 more than one calendar component type, then multiple component
6793 parameters MUST be specified.
6795 The value for the "component" parameter is defined as follows:
6797 component = "VEVENT"
6798 / "VTODO"
6799 / "VJOURNAL"
6800 / "VFREEBUSY"
6801 / "VTIMEZONE"
6802 / x-name
6803 / iana-token
6805 The "optinfo" parameter conveys optional information about the
6806 iCalendar object within the body part. This parameter can only
6807 specify semantics already specified by the iCalendar object and
6808 that can be otherwise determined by parsing the body part. In
6809 addition, the optional information specified by this parameter
6810 MUST be consistent with that information specified by the
6811 iCalendar object. For example, it can be used to convey the
6812 "Attendee" response status to a meeting request. The parameter
6813 value consists of a string value.
6815 The parameter can be specified multiple times.
6817 This parameter MAY only specify semantics already specified by the
6818 iCalendar object and that can be otherwise determined by parsing
6819 the body part.
6821 The value for the "optinfo" parameter is defined as follows:
6823 optinfo = infovalue / qinfovalue
6825 infovalue = iana-token / x-name
6827 qinfovalue = DQUOTE (infovalue) DQUOTE
6829 Encoding considerations: This media type can contain 8bit characters,
6830 so the use of quoted-printable or base64 MIME Content-Transfer-
6831 Encodings might be necessary when iCalendar objects are
6832 transferred across protocols restricted to the 7bit repertoire.
6833 Note that a text valued property in the content entity can also
6834 have content encoding of special characters using a BACKSLASH
6835 character (US-ASCII decimal 92) escapement technique. This means
6836 that content values can end up encoded twice.
6838 Security considerations: See Section 8.
6840 Interoperability considerations: This media type is intended to
6841 define a common format for conveying calendaring and scheduling
6842 information between different systems. It is heavily based on the
6843 earlier [VCAL] industry specification.
6845 Published specification: This specification.
6847 Applications which use this media type: This media type is designed
6848 for widespread use by Internet calendaring and scheduling
6849 applications. In addition, applications in the workflow and
6850 document management area might find this content-type applicable.
6851 The iTIP [I-D.ietf-calsify-2446bis], iMIP [I-D.ietf-calsify-
6852 rfc2447bis] and CalDAV [I-D.dusseault-caldav] Internet protocols
6853 directly use this media type also.
6855 Additional information:
6857 Magic number(s): None.
6859 File extension(s): The file extension of "ics" is to be used to
6860 designate a file containing (an arbitrary set of) calendaring
6861 and scheduling information consistent with this MIME content
6862 type.
6864 The file extension of "ifb" is to be used to designate a file
6865 containing free or busy time information consistent with this
6866 MIME content type.
6868 Macintosh file type code(s): The file type code of "iCal" is to be
6869 used in Apple MacIntosh operating system environments to
6870 designate a file containing calendaring and scheduling
6871 information consistent with this MIME media type.
6873 The file type code of "iFBf" is to be used in Apple MacIntosh
6874 operating system environments to designate a file containing
6875 free or busy time information consistent with this MIME media
6876 type.
6878 Person & email address to contact for further information: TBD
6880 Intended usage: COMMON
6882 Restrictions on usage: There are no restrictions on where this media
6883 type can be used.
6885 Author: TBD
6887 Change controller: IETF
6889 10. Acknowledgments
6891 The editor of this document wish to thank Frank Dawson and Stenerson
6892 Derik, the original authors of RFC2445, as well as the following
6893 individuals who have participated in the drafting, review and
6894 discussion of this memo:
6896 Joe Abley, Hervey Allen, Jay Batson, Oliver Block, Chris Bryant,
6897 Tantek Celik, Mark Crispin, Cyrus Daboo, Mike Douglass, Andrew N.
6898 Dowden, Lisa Dusseault, Ned Freed, Ted Hardie, Tim Hare, Jeffrey
6899 Harris, Helge Hess, Leif Johansson, Reinhold Kainhofer, Eliot Lear,
6900 Jeff McCullough, Bill McQuillan, Alexey Melnikov, Aki Niemi, John W.
6901 Noerenberg II, Chuck Norris, Mark Paterson, Simon Pilette, Arnaud
6902 Quillaud, Robert Ransdell, Julian F. Reschke, Caleb Richardson, Sam
6903 Roberts, George Sexton, Simon Vaillancourt, Michiel van Leeuwen, and
6904 Sandy Wills.
6906 The editor would also like to thank the Calendaring and Scheduling
6907 Consortium for advice with this specification, and for organizing
6908 interoperability testing events to help refine it.
6910 11. References
6912 11.1. Normative References
6914 [ISO.8601.1988]
6915 International Organization for Standardization, "Data
6916 elements and interchange formats - Information interchange
6917 - Representation of dates and times",
6918 .
6920 [ISO.9070.1991]
6921 International Organization for Standardization,
6922 "Information Technology_SGML Support Facilities --
6923 Registration Procedures for Public Text Owner Identifiers,
6924 Second Edition", April 1991, .
6927 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
6928 Extensions (MIME) Part One: Format of Internet Message
6929 Bodies", RFC 2045, November 1996.
6931 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
6932 Extensions (MIME) Part Two: Media Types", RFC 2046,
6933 November 1996.
6935 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
6936 Requirement Levels", BCP 14, RFC 2119, March 1997.
6938 [RFC2368] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto
6939 URL scheme", RFC 2368, July 1998.
6941 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
6942 April 2001.
6944 [RFC3066] Alvestrand, H., "Tags for the Identification of
6945 Languages", BCP 47, RFC 3066, January 2001.
6947 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
6948 10646", STD 63, RFC 3629, November 2003.
6950 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
6951 Resource Identifier (URI): Generic Syntax", STD 66,
6952 RFC 3986, January 2005.
6954 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
6955 Specifications: ABNF", RFC 4234, October 2005.
6957 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
6958 Encodings", RFC 4648, October 2006.
6960 11.2. Informative References
6962 [I-D.dusseault-caldav]
6963 Daboo, C., Desruisseaux, B., and L. Dusseault,
6964 "Calendaring Extensions to WebDAV (CalDAV)",
6965 draft-dusseault-caldav-15 (work in progress),
6966 September 2006.
6968 [I-D.ietf-calsify-2446bis]
6969 Daboo, C., "iCalendar Transport-Independent
6970 Interoperability Protocol (iTIP)",
6971 draft-ietf-calsify-2446bis-02 (work in progress),
6972 June 2006.
6974 [I-D.ietf-calsify-rfc2447bis]
6975 Melnikov, A., "iCalendar Message-Based Interoperability
6976 Protocol(iMIP)", draft-ietf-calsify-rfc2447bis-02 (work in
6977 progress), June 2006.
6979 [RFC2425] Howes, T., Smith, M., and F. Dawson, "A MIME Content-Type
6980 for Directory Information", RFC 2425, September 1998.
6982 [RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile",
6983 RFC 2426, September 1998.
6985 [TZDB] "Time zone code and data", October 2005,
6986 .
6988 [VCAL] Internet Mail Consortium, "vCalendar: The Electronic
6989 Calendaring and Scheduling Exchange Format",
6990 September 1996, .
6992 URIs
6994 [1]
6996 Appendix A. Differences from RFC 2445
6998 This appendix contains a list of changes that have been made in the
6999 Internet Calendaring and Scheduling Core Object Specification from
7000 RFC 2445.
7002 A.1. New restrictions
7003 1. The "DTSTART" property SHOULD match the pattern of the recurrence
7004 rule, if specified.
7006 2. The "RRULE" property SHOULD NOT occur more than once in a
7007 component.
7009 A.2. Deprecated features
7011 1. The "EXRULE" property can no longer be specified in a component.
7013 Appendix B. Change Log (to be removed by RFC Editor before publication)
7015 B.1. Changes in -03
7017 A detailed list of changes is available at the following page:
7018 http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/
7019 draft-ietf-calsify-rfc2445bis-03.html.
7021 a. Numerous editorial changes.
7023 b. Specified that DTSTART should match the pattern of RRULE and is
7024 always part of the COUNT.
7026 c. Specified RRULE should not occur more than once in recurring
7027 components.
7029 d. Deprecated EXRULE.
7031 e. Fixed all ABNF errors reported by Bill Fenner's ABNF parsing web
7032 service available at:
7033 http://rtg.ietf.org/~fenner/abnf.cgi.
7035 f. Changed reference to RFC 4648 for Base64 encoding.
7037 B.2. Changes in -02
7039 A detailed list of changes is available at the following page:
7040 http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/
7041 draft-ietf-calsify-rfc2445bis-02.html.
7043 a. Numerous editorial changes including the typos listed in the
7044 "RFC2445 Errata":
7045 http://www.rfc-editor.org/cgi-bin/errataSearch.pl?rfc=2445&
7046 and in the "RFC2445 Issues List":
7047 http://www.softwarestudio.org/iCal/2445Issues.html.
7049 b. Clarified line folding requirements.
7051 c. Clarified charset requirements.
7053 d. Clarified line limits requirements.
7055 e. Clarified on the use of the LANGUAGE parameter.
7057 f. Fixed the eventprop, todoprop and jourprop ABNF rules with
7058 respect to required properties.
7060 g. Fixed all the examples to use RFC2606-compliant FQDNs.
7062 h. Fixed the Content-ID URLs in the examples.
7064 i. Fixed the LDAP URLs in the examples.
7066 j. Moved multiple references in the Informative References section.
7068 k. Updated the Acknowledgments section.
7070 B.3. Changes in -01
7072 A detailed list of changes is available at the following page:
7073 http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/
7074 draft-ietf-calsify-rfc2445bis-01.html.
7076 a. Numerous editorial changes (typos, errors in examples, etc.).
7078 b. Fixed invalid media types in examples.
7080 c. Fixed the DTSTAMP values in the examples.
7082 d. Moved media type registration in a separate IANA Consideration
7083 section.
7085 e. Added Internationalization Considerations section.
7087 f. Added Security Considerations section.
7089 g. Updated the Acknowledgments section.
7091 Author's Address
7093 Bernard Desruisseaux (editor)
7094 Oracle Corporation
7095 600 blvd. de Maisonneuve West
7096 Suite 1900
7097 Montreal, QC H3A 3J2
7098 CA
7100 Email: bernard.desruisseaux@oracle.com
7101 URI: http://www.oracle.com/
7103 Intellectual Property Statement
7105 The IETF takes no position regarding the validity or scope of any
7106 Intellectual Property Rights or other rights that might be claimed to
7107 pertain to the implementation or use of the technology described in
7108 this document or the extent to which any license under such rights
7109 might or might not be available; nor does it represent that it has
7110 made any independent effort to identify any such rights. Information
7111 on the procedures with respect to rights in RFC documents can be
7112 found in BCP 78 and BCP 79.
7114 Copies of IPR disclosures made to the IETF Secretariat and any
7115 assurances of licenses to be made available, or the result of an
7116 attempt made to obtain a general license or permission for the use of
7117 such proprietary rights by implementers or users of this
7118 specification can be obtained from the IETF on-line IPR repository at
7119 http://www.ietf.org/ipr.
7121 The IETF invites any interested party to bring to its attention any
7122 copyrights, patents or patent applications, or other proprietary
7123 rights that may cover technology that may be required to implement
7124 this standard. Please address the information to the IETF at
7125 ietf-ipr@ietf.org.
7127 Disclaimer of Validity
7129 This document and the information contained herein are provided on an
7130 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
7131 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
7132 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
7133 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
7134 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
7135 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
7137 Copyright Statement
7139 Copyright (C) The Internet Society (2006). This document is subject
7140 to the rights, licenses and restrictions contained in BCP 78, and
7141 except as set forth therein, the authors retain all their rights.
7143 Acknowledgment
7145 Funding for the RFC Editor function is currently provided by the
7146 Internet Society.