idnits 2.17.1
draft-ietf-calsify-rfc2445bis-02.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 7129.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 7106.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 7113.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 7119.
** 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 11, 2006) is 6405 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 11, 2006
5 Expires: April 14, 2007
7 Internet Calendaring and Scheduling Core Object Specification
8 (iCalendar)
9 draft-ietf-calsify-rfc2445bis-02
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 14, 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 . . . . . . . . . . . . . . . . . . . . . . 20
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 . . . . . . . . . . . . . . . . . . . 51
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 . . . . . . . . . . . . . . . . . . . 67
152 3.7. Calendar Properties . . . . . . . . . . . . . . . . . . . 73
153 3.7.1. Calendar Scale . . . . . . . . . . . . . . . . . . . 73
154 3.7.2. Method . . . . . . . . . . . . . . . . . . . . . . . 74
155 3.7.3. Product Identifier . . . . . . . . . . . . . . . . . 75
156 3.7.4. Version . . . . . . . . . . . . . . . . . . . . . . . 76
157 3.8. Component Properties . . . . . . . . . . . . . . . . . . 77
158 3.8.1. Descriptive Component Properties . . . . . . . . . . 77
159 3.8.1.1. Attachment . . . . . . . . . . . . . . . . . . . 77
160 3.8.1.2. Categories . . . . . . . . . . . . . . . . . . . 78
161 3.8.1.3. Classification . . . . . . . . . . . . . . . . . 79
162 3.8.1.4. Comment . . . . . . . . . . . . . . . . . . . . . 80
163 3.8.1.5. Description . . . . . . . . . . . . . . . . . . . 81
164 3.8.1.6. Geographic Position . . . . . . . . . . . . . . . 82
165 3.8.1.7. Location . . . . . . . . . . . . . . . . . . . . 84
166 3.8.1.8. Percent Complete . . . . . . . . . . . . . . . . 85
167 3.8.1.9. Priority . . . . . . . . . . . . . . . . . . . . 86
168 3.8.1.10. Resources . . . . . . . . . . . . . . . . . . . . 88
169 3.8.1.11. Status . . . . . . . . . . . . . . . . . . . . . 88
170 3.8.1.12. Summary . . . . . . . . . . . . . . . . . . . . . 90
171 3.8.2. Date and Time Component Properties . . . . . . . . . 91
172 3.8.2.1. Date/Time Completed . . . . . . . . . . . . . . . 91
173 3.8.2.2. Date/Time End . . . . . . . . . . . . . . . . . . 92
174 3.8.2.3. Date/Time Due . . . . . . . . . . . . . . . . . . 93
175 3.8.2.4. Date/Time Start . . . . . . . . . . . . . . . . . 94
176 3.8.2.5. Duration . . . . . . . . . . . . . . . . . . . . 95
177 3.8.2.6. Free/Busy Time . . . . . . . . . . . . . . . . . 96
178 3.8.2.7. Time Transparency . . . . . . . . . . . . . . . . 97
179 3.8.3. Time Zone Component Properties . . . . . . . . . . . 98
180 3.8.3.1. Time Zone Identifier . . . . . . . . . . . . . . 99
181 3.8.3.2. Time Zone Name . . . . . . . . . . . . . . . . . 100
182 3.8.3.3. Time Zone Offset From . . . . . . . . . . . . . . 101
183 3.8.3.4. Time Zone Offset To . . . . . . . . . . . . . . . 102
184 3.8.3.5. Time Zone URL . . . . . . . . . . . . . . . . . . 102
185 3.8.4. Relationship Component Properties . . . . . . . . . . 103
186 3.8.4.1. Attendee . . . . . . . . . . . . . . . . . . . . 103
187 3.8.4.2. Contact . . . . . . . . . . . . . . . . . . . . . 106
188 3.8.4.3. Organizer . . . . . . . . . . . . . . . . . . . . 107
189 3.8.4.4. Recurrence ID . . . . . . . . . . . . . . . . . . 109
190 3.8.4.5. Related To . . . . . . . . . . . . . . . . . . . 111
191 3.8.4.6. Uniform Resource Locator . . . . . . . . . . . . 113
192 3.8.4.7. Unique Identifier . . . . . . . . . . . . . . . . 113
193 3.8.5. Recurrence Component Properties . . . . . . . . . . . 115
194 3.8.5.1. Exception Date/Times . . . . . . . . . . . . . . 115
195 3.8.5.2. Exception Rule . . . . . . . . . . . . . . . . . 116
196 3.8.5.3. Recurrence Date/Times . . . . . . . . . . . . . . 118
197 3.8.5.4. Recurrence Rule . . . . . . . . . . . . . . . . . 119
198 3.8.6. Alarm Component Properties . . . . . . . . . . . . . 128
199 3.8.6.1. Action . . . . . . . . . . . . . . . . . . . . . 129
200 3.8.6.2. Repeat Count . . . . . . . . . . . . . . . . . . 129
201 3.8.6.3. Trigger . . . . . . . . . . . . . . . . . . . . . 130
202 3.8.7. Change Management Component Properties . . . . . . . 132
203 3.8.7.1. Date/Time Created . . . . . . . . . . . . . . . . 133
204 3.8.7.2. Date/Time Stamp . . . . . . . . . . . . . . . . . 133
205 3.8.7.3. Last Modified . . . . . . . . . . . . . . . . . . 134
206 3.8.7.4. Sequence Number . . . . . . . . . . . . . . . . . 135
207 3.8.8. Miscellaneous Component Properties . . . . . . . . . 137
208 3.8.8.1. Non-standard Properties . . . . . . . . . . . . . 137
209 3.8.8.2. Request Status . . . . . . . . . . . . . . . . . 138
210 4. iCalendar Object Examples . . . . . . . . . . . . . . . . . . 141
211 5. Recommended Practices . . . . . . . . . . . . . . . . . . . . 145
212 6. Registration of Content Type Elements . . . . . . . . . . . . 146
213 6.1. Registration of New and Modified iCalendar Object
214 Methods . . . . . . . . . . . . . . . . . . . . . . . . . 146
215 6.2. Registration of New Properties . . . . . . . . . . . . . 147
216 6.2.1. Define the property . . . . . . . . . . . . . . . . . 147
217 6.2.2. Post the Property definition . . . . . . . . . . . . 148
218 6.2.3. Allow a comment period . . . . . . . . . . . . . . . 148
219 6.2.4. Submit the property for approval . . . . . . . . . . 148
220 6.3. Property Change Control . . . . . . . . . . . . . . . . . 149
221 7. Internationalization Considerations . . . . . . . . . . . . . 149
222 8. Security Considerations . . . . . . . . . . . . . . . . . . . 149
223 9. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 150
224 9.1. Media Type Registration Information . . . . . . . . . . . 150
225 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 153
226 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 154
227 11.1. Normative References . . . . . . . . . . . . . . . . . . 154
228 11.2. Informative References . . . . . . . . . . . . . . . . . 155
229 Appendix A. Change Log (to be removed by RFC Editor before
230 publication) . . . . . . . . . . . . . . . . . . . . 155
231 A.1. Changes in -02 . . . . . . . . . . . . . . . . . . . . . 155
232 A.2. Changes in -01 . . . . . . . . . . . . . . . . . . . . . 156
233 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 157
234 Intellectual Property and Copyright Statements . . . . . . . . . 158
236 1. Introduction
238 The use of calendaring and scheduling has grown considerably in the
239 last decade. Enterprise and inter-enterprise business has become
240 dependent on rapid scheduling of events and actions using this
241 information technology. However, the longer term growth of
242 calendaring and scheduling, is currently limited by the lack of
243 Internet standards for the message content types that are central to
244 these knowledgeware applications. This memo is intended to progress
245 the level of interoperability possible between dissimilar calendaring
246 and scheduling applications. This memo defines a MIME content type
247 for exchanging electronic calendaring and scheduling information.
248 The Internet Calendaring and Scheduling Core Object Specification, or
249 iCalendar, allows for the capture and exchange of information
250 normally stored within a calendaring and scheduling application; such
251 as a Personal Information Manager (PIM) or a Group Scheduling
252 product.
254 The iCalendar format is suitable as an exchange format between
255 applications or systems. The format is defined in terms of a MIME
256 content type. This will enable the object to be exchanged using
257 several transports, including but not limited to SMTP, HTTP, a file
258 system, desktop interactive protocols such as the use of a memory-
259 based clipboard or drag/drop interactions, point-to-point
260 asynchronous communication, wired-network transport, or some form of
261 unwired transport such as infrared might also be used.
263 The memo also provides for the definition of iCalendar object methods
264 that will map this content type to a set of messages for supporting
265 calendaring and scheduling operations such as requesting, replying
266 to, modifying, and canceling meetings or appointments, to-dos and
267 journal entries. The iCalendar object methods can be used to define
268 other calendaring and scheduling operations such a requesting for and
269 replying with free/busy time data. Such a scheduling protocol is
270 defined in the iCalendar Transport-independent Interoperability
271 Protocol (iTIP) defined in [I-D.ietf-calsify-2446bis].
273 The memo also includes a formal grammar for the content type based on
274 the Internet ABNF defined in [RFC4234] . This ABNF is required for
275 the implementation of parsers and to serve as the definitive
276 reference when ambiguities or questions arise in interpreting the
277 descriptive prose definition of the memo.
279 2. Basic Grammar and Conventions
281 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
282 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" and
283 "OPTIONAL" in this document are to be interpreted as described in
284 [RFC2119].
286 This memo makes use of both a descriptive prose and a more formal
287 notation for defining the calendaring and scheduling format.
289 The notation used in this memo is the ABNF notation of [RFC4234] .
290 Readers intending on implementing this format defined in this memo
291 should be familiar with this notation in order to properly interpret
292 the specifications of this memo.
294 All numeric values used in this memo are given in decimal notation.
296 All names of properties, property parameters, enumerated property
297 values and property parameter values are case-insensitive. However,
298 all other property values are case-sensitive, unless otherwise
299 stated.
301 Note: All indented editorial notes, such as this one, are intended
302 to provide the reader with additional information. The
303 information is not essential to the building of an implementation
304 conformant with this memo. The information is provided to
305 highlight a particular feature or characteristic of the memo.
307 The format for the iCalendar object is based on the syntax of the
308 [RFC2425] content type. While the iCalendar object is not a profile
309 of the [RFC2425] content type, it does reuse a number of the elements
310 from the [RFC2425] specification.
312 2.1. Formatting Conventions
314 The mechanisms defined in this memo are defined in prose. Many of
315 the terms used to describe these have common usage that is different
316 than the standards usage of this memo. In order to reference within
317 this memo elements of the calendaring and scheduling model, core
318 object (this memo) or interoperability protocol [I-D.ietf-calsify-
319 2446bis] some formatting conventions have been used. Calendaring and
320 scheduling roles are referred to in quoted-strings of text with the
321 first character of each word in upper case. For example, "Organizer"
322 refers to a role of a "Calendar User" within the scheduling protocol
323 defined by [I-D.ietf-calsify-2446bis]. Calendar components defined
324 by this memo are referred to with capitalized, quoted-strings of
325 text. All calendar components start with the letter "V". For
326 example, "VEVENT" refers to the event calendar component, "VTODO"
327 refers to the to-do calendar component and "VJOURNAL" refers to the
328 daily journal calendar component. Scheduling methods defined by iTIP
329 [I-D.ietf-calsify-2446bis] are referred to with capitalized, quoted-
330 strings of text. For example, "REQUEST" refers to the method for
331 requesting a scheduling calendar component be created or modified,
332 "REPLY" refers to the method a recipient of a request uses to update
333 their status with the "Organizer" of the calendar component.
335 The properties defined by this memo are referred to with capitalized,
336 quoted-strings of text, followed by the word "property". For
337 example, "ATTENDEE" property refers to the iCalendar property used to
338 convey the calendar address of a calendar user. Property parameters
339 defined by this memo are referred to with lowercase, quoted-strings
340 of text, followed by the word "parameter". For example, "value"
341 parameter refers to the iCalendar property parameter used to override
342 the default data type for a property value. Enumerated values
343 defined by this memo are referred to with capitalized text, either
344 alone or followed by the word "value". For example, the "MINUTELY"
345 value can be used with the "FREQ" component of the "RECUR" data type
346 to specify repeating components based on an interval of one minute or
347 more.
349 2.2. Related Memos
351 Implementers will need to be familiar with several other memos that,
352 along with this memo, form a framework for Internet calendaring and
353 scheduling standards. This memo specifies a core specification of
354 objects, data types, properties and property parameters.
356 o iTIP [I-D.ietf-calsify-2446bis] specifies an interoperability
357 protocol for scheduling between different implementations;
359 o iMIP [I-D.ietf-calsify-rfc2447bis] specifies an Internet email
360 binding for [I-D.ietf-calsify-2446bis].
362 This memo does not attempt to repeat the specification of concepts or
363 definitions from these other memos. Where possible, references are
364 made to the memo that provides for the specification of these
365 concepts or definitions.
367 2.3. International Considerations
369 In the rest of this document, descriptions of characters are of the
370 form "character name (codepoint)", where "codepoint" is from the US-
371 ASCII character set. The "character name" is the authoritative
372 description; (codepoint) is a reference to that character in US-ASCII
373 or US-ASCII compatible sets (for example the ISO-8859-x family,
374 UTF-8, ISO-2022-xx, KOI8-R). If a non-US-ASCII compatible character
375 set is used, appropriate code-point from that character set MUST be
376 chosen instead. Use of non-US-ASCII-compatible character sets is NOT
377 recommended.
379 3. iCalendar Object Specification
381 The following sections define the details of a Calendaring and
382 Scheduling Core Object Specification. This information is intended
383 to be an integral part of the MIME content type registration. In
384 addition, this information can be used independent of such content
385 registration. In particular, this memo has direct applicability for
386 use as a calendaring and scheduling exchange format in file-, memory-
387 or network-based transport mechanisms.
389 3.1. Content Lines
391 The iCalendar object is organized into individual lines of text,
392 called content lines. Content lines are delimited by a line break,
393 which is a CRLF sequence (US-ASCII decimal 13, followed by US-ASCII
394 decimal 10).
396 Lines of text SHOULD NOT be longer than 75 octets, excluding the line
397 break. Long content lines SHOULD be split into a multiple line
398 representations using a line "folding" technique. That is, a long
399 line can be split between any two characters by inserting a CRLF
400 immediately followed by a single linear white space character (i.e.,
401 SPACE, US-ASCII decimal 32 or HTAB, US-ASCII decimal 9). Any
402 sequence of CRLF followed immediately by a single linear white space
403 character is ignored (i.e., removed) when processing the content
404 type.
406 For example the line:
408 DESCRIPTION:This is a long description that exists on a long line.
410 Can be represented as:
412 DESCRIPTION:This is a lo
413 ng description
414 that exists on a long line.
416 The process of moving from this folded multiple line representation
417 to its single line representation is called "unfolding". Unfolding
418 is accomplished by removing the CRLF character and the linear white
419 space character that immediately follows.
421 When parsing a content line, folded lines MUST first be unfolded
422 according to the unfolding procedure described above.
424 Note: It is possible for very simple implementations to generate
425 improperly folded lines in the middle of a UTF-8 multi-octet
426 sequence. For this reason, implementations need to unfold lines
427 in such a way to properly restore the original sequence.
429 The content information associated with an iCalendar object is
430 formatted using a syntax similar to that defined by [RFC2425]. That
431 is, the content information consists of CRLF-separated content lines.
433 The following notation defines the lines of content in an iCalendar
434 object:
436 contentline = name *(";" param ) ":" value CRLF
437 ; This ABNF is just a general definition for an initial parsing
438 ; of the content line into its property name, parameter list,
439 ; and value string
441 ; When parsing a content line, folded lines MUST first
442 ; be unfolded according to the unfolding procedure
443 ; described above. When generating a content line, lines
444 ; longer than 75 octets SHOULD be folded according to
445 ; the folding procedure described above.
447 name = x-name / iana-token
449 iana-token = 1*(ALPHA / DIGIT / "-")
450 ; iCalendar identifier registered with IANA
452 x-name = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-")
453 ; Reserved for experimental use.
455 vendorid = 3*(ALPHA / DIGIT) ;Vendor identification
457 param = param-name "=" param-value
458 *("," param-value)
459 ; Each property defines the specific ABNF for the parameters
460 ; allowed on the property. Refer to specific properties for
461 ; precise parameter ABNF.
463 param-name = iana-token / x-name
465 param-value = paramtext / quoted-string
467 paramtext = *SAFE-CHAR
469 value = *VALUE-CHAR
471 quoted-string = DQUOTE *QSAFE-CHAR DQUOTE
472 QSAFE-CHAR = WSP / %x21 / %x23-7E / NON-US-ASCII
473 ; Any character except CTLs and DQUOTE
475 SAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E
476 / NON-US-ASCII
477 ; Any character except CTLs, DQUOTE, ";", ":", ","
479 VALUE-CHAR = WSP / %x21-7E / NON-US-ASCII
480 ; Any textual character
482 NON-US-ASCII = %x80-F8
483 ; Use restricted by charset parameter
484 ; on outer MIME object (UTF-8 preferred)
486 CR = %x0D
487 ; carriage return
489 LF = %x0A
490 ; line feed
492 CRLF = CR LF
493 ; Internet standard newline
495 CTL = %x00-08 / %x0A-1F / %x7F
496 ; Controls
498 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
500 DIGIT = %x30-39
501 ; 0-9
503 DQUOTE = %x22
504 ; Quotation Mark
506 WSP = SPACE / HTAB
508 SPACE = %x20
510 HTAB = %x09
512 The property value component of a content line has a format that is
513 property specific. Refer to the section describing each property for
514 a definition of this format.
516 All names of properties, property parameters, enumerated property
517 values and property parameter values are case-insensitive. However,
518 all other property values are case-sensitive, unless otherwise
519 stated.
521 3.1.1. List and Field Separators
523 Some properties and parameters allow a list of values. Values in a
524 list of values MUST be separated by a COMMA character (US-ASCII
525 decimal 44). There is no significance to the order of values in a
526 list. For those parameter values (such as those that specify URI
527 values) that are specified in quoted-strings, the individual quoted-
528 strings are separated by a COMMA character (US-ASCII decimal 44).
530 Some property values are defined in terms of multiple parts. These
531 structured property values MUST have their value parts separated by a
532 SEMICOLON character (US-ASCII decimal 59).
534 Some properties allow a list of parameters. Each property parameter
535 in a list of property parameters MUST be separated by a SEMICOLON
536 character (US-ASCII decimal 59).
538 Property parameters with values containing a COLON, a SEMICOLON or a
539 COMMA character MUST be placed in quoted text.
541 For example, in the following properties a SEMICOLON is used to
542 separate property parameters from each other, and a COMMA is used to
543 separate property values in a value list.
545 ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT:MAILTO:
546 jsmith@example.com
548 RDATE;VALUE=DATE:19970304,19970504,19970704,19970904
550 3.1.2. Multiple Values
552 Some properties defined in the iCalendar object can have multiple
553 values. The general rule for encoding multi-valued items is to
554 simply create a new content line for each value, including the
555 property name. However, it should be noted that some properties
556 support encoding multiple values in a single property by separating
557 the values with a COMMA character (US-ASCII decimal 44). Individual
558 property definitions should be consulted for determining whether a
559 specific property allows multiple values and in which of these two
560 forms.
562 3.1.3. Binary Content
564 Binary content information in an iCalendar object SHOULD be
565 referenced using a URI within a property value. That is the binary
566 content information SHOULD be placed in an external MIME entity that
567 can be referenced by a URI from within the iCalendar object. In
568 applications where this is not feasible, binary content information
569 can be included within an iCalendar object, but only after first
570 encoding it into text using the "BASE64" encoding method defined in
571 [RFC2045]. Inline binary contact SHOULD only be used in applications
572 whose special circumstances demand that an iCalendar object be
573 expressed as a single entity. A property containing inline binary
574 content information MUST specify the "ENCODING" property parameter.
575 Binary content information placed external to the iCalendar object
576 MUST be referenced by a uniform resource identifier (URI).
578 The following example specifies an "ATTACH" property that references
579 an attachment external to the iCalendar object with a URI reference:
581 ATTACH:http://example.com/public/quarterly-report.doc
583 The following example specifies an "ATTACH" property with inline
584 binary encoded content information:
586 ATTACH;FMTTYPE=image/basic;ENCODING=BASE64;VALUE=BINARY:
587 MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1U
588 EBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIE
589 <...remainder of "BASE64" encoded binary data...>
591 3.1.4. Character Set
593 There is not a property parameter to declare the charset used in a
594 property value. The default charset for an iCalendar stream is UTF-8
595 as defined in [RFC3629] .
597 The "charset" Content-Type parameter MUST be used in MIME transports
598 to specify the charset being used .
600 3.2. Property Parameters
602 A property can have attributes associated with it. These "property
603 parameters" contain meta-information about the property or the
604 property value. Property parameters are provided to specify such
605 information as the location of an alternate text representation for a
606 property value, the language of a text property value, the data type
607 of the property value and other attributes.
609 Property parameter values that contain the COLON (US-ASCII decimal
610 58), SEMICOLON (US-ASCII decimal 59) or COMMA (US-ASCII decimal 44)
611 character separators MUST be specified as quoted-string text values.
612 Property parameter values MUST NOT contain the DQUOTE (US-ASCII
613 decimal 22) character. The DQUOTE (US-ASCII decimal 22) character is
614 used as a delimiter for parameter values that contain restricted
615 characters or URI text. For example:
617 DESCRIPTION;ALTREP="http://www.example.org":The Fall'98 Wild
618 Wizards Conference - - Las Vegas\, NV\, USA
620 Property parameter values that are not in quoted strings are case
621 insensitive.
623 The general property parameters defined by this memo are defined by
624 the following notation:
626 parameter = altrepparam ; Alternate text representation
627 / cnparam ; Common name
628 / cutypeparam ; Calendar user type
629 / delfromparam ; Delegator
630 / deltoparam ; Delegatee
631 / dirparam ; Directory entry
632 / encodingparam ; Inline encoding
633 / fmttypeparam ; Format type
634 / fbtypeparam ; Free/busy time type
635 / languageparam ; Language for text
636 / memberparam ; Group or list membership
637 / partstatparam ; Participation status
638 / rangeparam ; Recurrence identifier range
639 / trigrelparam ; Alarm trigger relationship
640 / reltypeparam ; Relationship type
641 / roleparam ; Participation role
642 / rsvpparam ; RSVP expectation
643 / sentbyparam ; Sent by
644 / tzidparam ; Reference to time zone object
645 / valuetypeparam ; Property value data type
646 / ianaparam
647 ; Some other IANA registered iCalendar parameter.
648 / xparam
649 ; A non-standard, experimental parameter.
651 ianaparam = iana-token "=" param-value *("," param-value)
653 xparam = x-name "=" param-value *("," param-value)
655 3.2.1. Alternate Text Representation
657 Parameter Name: ALTREP
659 Purpose: To specify an alternate text representation for the property
660 value.
662 Format Definition: The property parameter is defined by the following
663 notation:
665 altrepparam = "ALTREP" "=" DQUOTE uri DQUOTE
667 Description: The parameter specifies a URI that points to an
668 alternate representation for a textual property value. A property
669 specifying this parameter MUST also include a value that reflects
670 the default representation of the text value. The individual URI
671 parameter values MUST each be specified in a quoted-string.
673 Example:
675 DESCRIPTION;ALTREP="CID:part3.msg.970415T083000@example.com":
676 Project XYZ Review Meeting will include the following agenda
677 items: (a) Market Overview\, (b) Finances\, (c) Project Man
678 agement
680 The "ALTREP" property parameter value might point to a "text/html"
681 content portion.
683 Content-Type:text/html
684 Content-Id:
686
687
688
689
690
691
692 Project XYZ Review Meeting will include
693 the following agenda items:
694
695 - Market Overview
696 - Finances
697 - Project Management
698
699
700
701
703 3.2.2. Common Name
705 Parameter Name: CN
706 Purpose: To specify the common name to be associated with the
707 calendar user specified by the property.
709 Format Definition: The property parameter is defined by the following
710 notation:
712 cnparam = "CN" "=" param-value
714 Description: This parameter can be specified on properties with a
715 CAL-ADDRESS value type. The parameter specifies the common name
716 to be associated with the calendar user specified by the property.
717 The parameter value is text. The parameter value can be used for
718 display text to be associated with the calendar address specified
719 by the property.
721 Example:
723 ORGANIZER;CN="John Smith":MAILTO:jsmith@example.com
725 3.2.3. Calendar User Type
727 Parameter Name: CUTYPE
729 Purpose: To specify the type of calendar user specified by the
730 property.
732 Format Definition: The property parameter is defined by the following
733 notation:
735 cutypeparam = "CUTYPE" "="
736 ("INDIVIDUAL" ; An individual
737 / "GROUP" ; A group of individuals
738 / "RESOURCE" ; A physical resource
739 / "ROOM" ; A room resource
740 / "UNKNOWN" ; Otherwise not known
741 / x-name ; Experimental type
742 / iana-token) ; Other IANA registered
743 ; type
744 ; Default is INDIVIDUAL
746 Description: This parameter can be specified on properties with a
747 CAL-ADDRESS value type. The parameter identifies the type of
748 calendar user specified by the property. If not specified on a
749 property that allows this parameter, the default is INDIVIDUAL.
751 Example:
753 ATTENDEE;CUTYPE=GROUP:MAILTO:ietf-calsch@imc.org
755 3.2.4. Delegators
757 Parameter Name: DELEGATED-FROM
759 Purpose: To specify the calendar users that have delegated their
760 participation to the calendar user specified by the property.
762 Format Definition: The property parameter is defined by the following
763 notation:
765 delfromparam = "DELEGATED-FROM" "=" DQUOTE cal-address
766 DQUOTE *("," DQUOTE cal-address DQUOTE)
768 Description: This parameter can be specified on properties with a
769 CAL-ADDRESS value type. This parameter can be specified on a
770 property that has a value type of calendar address. This
771 parameter specifies those calendar users that have delegated their
772 participation in a group scheduled event or to-do to the calendar
773 user specified by the property. The value MUST be a MAILTO URI as
774 defined in [RFC2368] . The individual calendar address parameter
775 values MUST each be specified in a quoted-string.
777 Example:
779 ATTENDEE;DELEGATED-FROM="MAILTO:jsmith@example.com":MAILTO:
780 jdoe@example.com
782 3.2.5. Delegatees
784 Parameter Name: DELEGATED-TO
786 Purpose: To specify the calendar users to whom the calendar user
787 specified by the property has delegated participation.
789 Format Definition: The property parameter is defined by the following
790 notation:
792 deltoparam = "DELEGATED-TO" "=" DQUOTE cal-address DQUOTE
793 *("," DQUOTE cal-address DQUOTE)
795 Description: This parameter can be specified on properties with a
796 CAL-ADDRESS value type. This parameter specifies those calendar
797 users whom have been delegated participation in a group scheduled
798 event or to-do by the calendar user specified by the property.
799 The value MUST be a MAILTO URI as defined in [RFC2368] . The
800 individual calendar address parameter values MUST each be
801 specified in a quoted-string.
803 Example:
805 ATTENDEE;DELEGATED-TO="MAILTO:jdoe@example.com","MAILTO:jqpublic
806 @example.com":MAILTO:jsmith@example.com
808 3.2.6. Directory Entry Reference
810 Parameter Name: DIR
812 Purpose: To specify reference to a directory entry associated with
813 the calendar user specified by the property.
815 Format Definition: The property parameter is defined by the following
816 notation:
818 dirparam = "DIR" "=" DQUOTE uri DQUOTE
820 Description: This parameter can be specified on properties with a
821 CAL-ADDRESS value type. The parameter specifies a reference to
822 the directory entry associated with the calendar user specified by
823 the property. The parameter value is a URI. The URI parameter
824 value MUST be specified in a quoted-string.
826 Example:
828 ORGANIZER;DIR="ldap://example.com:6666/o=ABC%20Industries,
829 c=US???(cn=Jim%20Dolittle)":MAILTO:jimdo@example.com
831 3.2.7. Inline Encoding
833 Parameter Name: ENCODING
835 Purpose: To specify an alternate inline encoding for the property
836 value.
838 Format Definition: The property parameter is defined by the following
839 notation:
841 encodingparam = "ENCODING" "="
842 ("8BIT"
843 ; "8bit" text encoding is defined in [RFC2045]
844 / "BASE64"
845 ; "BASE64" binary encoding format is defined in [RFC2045]
846 / iana-token
847 ; Some other IANA registered iCalendar encoding type
848 / x-name)
849 ; A non-standard, experimental encoding type
851 Description: The property parameter identifies the inline encoding
852 used in a property value. The default encoding is "8BIT",
853 corresponding to a property value consisting of text. The
854 "BASE64" encoding type corresponds to a property value encoded
855 using the "BASE64" encoding defined in [RFC2045].
857 If the value type parameter is ";VALUE=BINARY", then the inline
858 encoding parameter MUST be specified with the value
859 ";ENCODING=BASE64".
861 Example:
863 ATTACH;FMTYPE=IMAGE/JPEG;ENCODING=BASE64;VALUE=BINARY:MIICajC
864 CAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDA
865 qBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMRw
866 <...remainder of "BASE64" encoded binary data...>
868 3.2.8. Format Type
870 Parameter Name: FMTTYPE
872 Purpose: To specify the content type of a referenced object.
874 Format Definition: The property parameter is defined by the following
875 notation:
877 fmttypeparam = "FMTTYPE" "=" iana-token
878 ; A IANA registered content type
879 / x-name
880 ; A non-standard content type
882 Description: This parameter can be specified on properties that are
883 used to reference an object. The parameter specifies the content
884 type of the referenced object. For example, on the "ATTACH"
885 property, a FTP type URI value does not, by itself, necessarily
886 convey the type of content associated with the resource. The
887 parameter value MUST be the TEXT for either an IANA registered
888 content type or a non-standard content type.
890 Example:
892 ATTACH;FMTTYPE=application/msword:ftp://example.com/pub/docs/
893 agenda.doc
895 3.2.9. Free/Busy Time Type
897 Parameter Name: FBTYPE
899 Purpose: To specify the free or busy time type.
901 Format Definition: The property parameter is defined by the following
902 notation:
904 fbtypeparam = "FBTYPE" "=" ("FREE" / "BUSY"
905 / "BUSY-UNAVAILABLE" / "BUSY-TENTATIVE"
906 / x-name
907 ; Some experimental iCalendar data type.
908 / iana-token)
909 ; Some other IANA registered iCalendar data type.
911 Description: The parameter specifies the free or busy time type. The
912 value FREE indicates that the time interval is free for
913 scheduling. The value BUSY indicates that the time interval is
914 busy because one or more events have been scheduled for that
915 interval. The value BUSY-UNAVAILABLE indicates that the time
916 interval is busy and that the interval can not be scheduled. The
917 value BUSY-TENTATIVE indicates that the time interval is busy
918 because one or more events have been tentatively scheduled for
919 that interval. If not specified on a property that allows this
920 parameter, the default is BUSY.
922 Example: The following is an example of this parameter on a FREEBUSY
923 property.
925 FREEBUSY;FBTYPE=BUSY:19980415T133000Z/19980415T170000Z
927 3.2.10. Language
929 Parameter Name: LANGUAGE
931 Purpose: To specify the language for text values in a property or
932 property parameter.
934 Format Definition: The property parameter is defined by the following
935 notation:
937 languageparam = "LANGUAGE" "=" language
939 language =
943 Description: The parameter identifies the language of the text in the
944 property or property parameter value. The value of the "language"
945 property parameter is that defined in [RFC3066] .
947 For transport in a MIME entity, the Content-Language header field
948 can be used to set the default language for the entire body part.
949 Otherwise, no default language is assumed.
951 Example:
953 SUMMARY;LANGUAGE=us-EN:Company Holiday Party
955 LOCATION;LANGUAGE=en:Germany
957 LOCATION;LANGUAGE=no:Tyskland
959 The following example makes use of the Quoted-Printable encoding
960 in order to represent non-ASCII characters.
962 LOCATION;LANGUAGE=3Dda:K=C3=B8benhavn
964 LOCATION;LANGUAGE=en:Copenhagen
966 3.2.11. Group or List Membership
968 Parameter Name: MEMBER
970 Purpose: To specify the group or list membership of the calendar user
971 specified by the property.
973 Format Definition: The property parameter is defined by the following
974 notation:
976 memberparam = "MEMBER" "=" DQUOTE cal-address DQUOTE
977 *("," DQUOTE cal-address DQUOTE)
979 Description: This parameter can be specified on properties with a
980 CAL-ADDRESS value type. The parameter identifies the groups or
981 list membership for the calendar user specified by the property.
982 The parameter value either a single calendar address in a quoted-
983 string or a COMMA character (US-ASCII decimal 44) list of calendar
984 addresses, each in a quoted-string. The individual calendar
985 address parameter values MUST each be specified in a quoted-
986 string.
988 Example:
990 ATTENDEE;MEMBER="MAILTO:ietf-calsch@example.org":MAILTO:
991 jsmith@example.com
993 ATTENDEE;MEMBER="MAILTO:projectA@example.com","MAILTO:pr
994 ojectB@example.com":MAILTO:janedoe@example.com
996 3.2.12. Participation Status
998 Parameter Name: PARTSTAT
1000 Purpose: To specify the participation status for the calendar user
1001 specified by the property.
1003 Format Definition: The property parameter is defined by the following
1004 notation:
1006 partstatparam = "PARTSTAT" "="
1007 ("NEEDS-ACTION" ; Event needs action
1008 / "ACCEPTED" ; Event accepted
1009 / "DECLINED" ; Event declined
1010 / "TENTATIVE" ; Event tentatively
1011 ; accepted
1012 / "DELEGATED" ; Event delegated
1013 / x-name ; Experimental status
1014 / iana-token) ; Other IANA registered
1015 ; status
1016 ; These are the participation statuses for a "VEVENT".
1017 ; Default is NEEDS-ACTION.
1019 partstatparam /= "PARTSTAT" "="
1020 ("NEEDS-ACTION" ; To-do needs action
1021 / "ACCEPTED" ; To-do accepted
1022 / "DECLINED" ; To-do declined
1023 / "TENTATIVE" ; To-do tentatively
1024 ; accepted
1025 / "DELEGATED" ; To-do delegated
1026 / "COMPLETED" ; To-do completed.
1027 ; COMPLETED property has
1028 ; date/time completed.
1029 / "IN-PROCESS" ; To-do in process of
1030 ; being completed
1031 / x-name ; Experimental status
1032 / iana-token) ; Other IANA registered
1033 ; status
1034 ; These are the participation statuses for a "VTODO".
1035 ; Default is NEEDS-ACTION.
1037 partstatparam /= "PARTSTAT" "="
1038 ("NEEDS-ACTION" ; Journal needs action
1039 / "ACCEPTED" ; Journal accepted
1040 / "DECLINED" ; Journal declined
1041 / x-name ; Experimental status
1042 / iana-token) ; Other IANA registered
1043 ; status
1044 ; These are the participation statuses for a "VJOURNAL".
1045 ; Default is NEEDS-ACTION.
1047 Description: This parameter can be specified on properties with a
1048 CAL-ADDRESS value type. The parameter identifies the
1049 participation status for the calendar user specified by the
1050 property value. The parameter values differ depending on whether
1051 they are associated with a group scheduled "VEVENT", "VTODO" or
1052 "VJOURNAL". The values MUST match one of the values allowed for
1053 the given calendar component. If not specified on a property that
1054 allows this parameter, the default value is NEEDS-ACTION.
1056 Example:
1058 ATTENDEE;PARTSTAT=DECLINED:MAILTO:jsmith@example.com
1060 3.2.13. Recurrence Identifier Range
1062 Parameter Name: RANGE
1064 Purpose: To specify the effective range of recurrence instances from
1065 the instance specified by the recurrence identifier specified by
1066 the property.
1068 Format Definition: The property parameter is defined by the following
1069 notation:
1071 rangeparam = "RANGE" "=" ("THISANDPRIOR"
1072 ; To specify all instances prior to the recurrence identifier
1073 / "THISANDFUTURE")
1074 ; To specify the instance specified by the recurrence identifier
1075 ; and all subsequent recurrence instances
1077 Description: The parameter can be specified on a property that
1078 specifies a recurrence identifier. The parameter specifies the
1079 effective range of recurrence instances that is specified by the
1080 property. The effective range is from the recurrence identified
1081 specified by the property. If this parameter is not specified an
1082 allowed property, then the default range is the single instance
1083 specified by the recurrence identifier value of the property. The
1084 parameter value can be "THISANDPRIOR" to indicate a range defined
1085 by the recurrence identified value of the property and all prior
1086 instances. The parameter value can also be "THISANDFUTURE" to
1087 indicate a range defined by the recurrence identifier and all
1088 subsequent instances.
1090 Example:
1092 RECURRENCE-ID;RANGE=THISANDPRIOR:19980401T133000Z
1094 3.2.14. Alarm Trigger Relationship
1096 Parameter Name: RELATED
1098 Purpose: To specify the relationship of the alarm trigger with
1099 respect to the start or end of the calendar component.
1101 Format Definition: The property parameter is defined by the following
1102 notation:
1104 trigrelparam = "RELATED" "="
1105 ("START" ; Trigger off of start
1106 / "END") ; Trigger off of end
1108 Description: The parameter can be specified on properties that
1109 specify an alarm trigger with a DURATION value type. The
1110 parameter specifies whether the alarm will trigger relative to the
1111 start or end of the calendar component. The parameter value START
1112 will set the alarm to trigger off the start of the calendar
1113 component; the parameter value END will set the alarm to trigger
1114 off the end of the calendar component. If the parameter is not
1115 specified on an allowable property, then the default is START.
1117 Example:
1119 TRIGGER;RELATED=END:PT5M
1121 3.2.15. Relationship Type
1123 Parameter Name: RELTYPE
1125 Purpose: To specify the type of hierarchical relationship associated
1126 with the calendar component specified by the property.
1128 Format Definition: The property parameter is defined by the following
1129 notation:
1131 reltypeparam = "RELTYPE" "="
1132 ("PARENT" ; Parent relationship. Default.
1133 / "CHILD" ; Child relationship
1134 / "SIBLING ; Sibling relationship
1135 / iana-token ; Some other IANA registered
1136 ; iCalendar relationship type
1137 / x-name) ; A non-standard, experimental
1138 ; relationship type
1140 Description: This parameter can be specified on a property that
1141 references another related calendar. The parameter specifies the
1142 hierarchical relationship type of the calendar component
1143 referenced by the property. The parameter value can be PARENT, to
1144 indicate that the referenced calendar component is a superior of
1145 calendar component; CHILD to indicate that the referenced calendar
1146 component is a subordinate of the calendar component; SIBLING to
1147 indicate that the referenced calendar component is a peer of the
1148 calendar component. If this parameter is not specified on an
1149 allowable property, the default relationship type is PARENT.
1151 Example:
1153 RELATED-TO;RELTYPE=SIBLING:19960401-080045-4000F192713@
1154 example.com
1156 3.2.16. Participation Role
1158 Parameter Name: ROLE
1160 Purpose: To specify the participation role for the calendar user
1161 specified by the property.
1163 Format Definition: The property parameter is defined by the following
1164 notation:
1166 roleparam = "ROLE" "="
1167 ("CHAIR" ; Indicates chair of the
1168 ; calendar entity
1169 / "REQ-PARTICIPANT" ; Indicates a participant whose
1170 ; participation is required
1171 / "OPT-PARTICIPANT" ; Indicates a participant whose
1172 ; participation is optional
1173 / "NON-PARTICIPANT" ; Indicates a participant who
1174 ; is copied for information
1175 ; purposes only
1176 / x-name ; Experimental role
1177 / iana-token) ; Other IANA role
1178 ; Default is REQ-PARTICIPANT
1180 Description: This parameter can be specified on properties with a
1181 CAL-ADDRESS value type. The parameter specifies the participation
1182 role for the calendar user specified by the property in the group
1183 schedule calendar component. If not specified on a property that
1184 allows this parameter, the default value is REQ-PARTICIPANT.
1186 Example:
1188 ATTENDEE;ROLE=CHAIR:MAILTO:mrbig@example.com
1190 3.2.17. RSVP Expectation
1192 Parameter Name: RSVP
1193 Purpose: To specify whether there is an expectation of a favor of a
1194 reply from the calendar user specified by the property value.
1196 Format Definition: The property parameter is defined by the following
1197 notation:
1199 rsvpparam = "RSVP" "=" ("TRUE" / "FALSE")
1200 ; Default is FALSE
1202 Description: This parameter can be specified on properties with a
1203 CAL-ADDRESS value type. The parameter identifies the expectation
1204 of a reply from the calendar user specified by the property value.
1205 This parameter is used by the "Organizer" to request a
1206 participation status reply from an "Attendee" of a group scheduled
1207 event or to-do. If not specified on a property that allows this
1208 parameter, the default value is FALSE.
1210 Example:
1212 ATTENDEE;RSVP=TRUE:MAILTO:jsmith@example.com
1214 3.2.18. Sent By
1216 Parameter Name: SENT-BY
1218 Purpose: To specify the calendar user that is acting on behalf of the
1219 calendar user specified by the property.
1221 Format Definition: The property parameter is defined by the following
1222 notation:
1224 sentbyparam = "SENT-BY" "=" DQUOTE cal-address DQUOTE
1226 Description: This parameter can be specified on properties with a
1227 CAL-ADDRESS value type. The parameter specifies the calendar user
1228 that is acting on behalf of the calendar user specified by the
1229 property. The parameter value MUST be a MAILTO URI as defined in
1230 [RFC2368] . The individual calendar address parameter values MUST
1231 each be specified in a quoted-string.
1233 Example:
1235 ORGANIZER;SENT-BY="MAILTO:sray@example.com":MAILTO:
1236 jsmith@example.com
1238 3.2.19. Time Zone Identifier
1240 Parameter Name: TZID
1242 Purpose: To specify the identifier for the time zone definition for a
1243 time component in the property value.
1245 Format Definition: The property parameter is defined by the following
1246 notation:
1248 tzidparam = "TZID" "=" [tzidprefix] paramtext
1250 tzidprefix = "/"
1252 Description: The parameter MUST be specified on the "DTSTART",
1253 "DTEND", "DUE", "EXDATE" and "RDATE" properties when either a
1254 DATE- TIME or TIME value type is specified and when the value is
1255 not either a UTC or a "floating" time. Refer to the DATE-TIME or
1256 TIME value type definition for a description of UTC and "floating
1257 time" formats. This property parameter specifies a text value
1258 which uniquely identifies the "VTIMEZONE" calendar component to be
1259 used when evaluating the time portion of the property. The value
1260 of the TZID property parameter will be equal to the value of the
1261 TZID property for the matching time zone definition. An
1262 individual "VTIMEZONE" calendar component MUST be specified for
1263 each unique "TZID" parameter value specified in the iCalendar
1264 object.
1266 The parameter MUST be specified on properties with a DATE-TIME
1267 value if the DATE-TIME is not either a UTC or a "floating" time.
1269 The presence of the SOLIDUS character (US-ASCII decimal 47) as a
1270 prefix, indicates that this TZID represents a unique ID in a
1271 globally defined time zone registry (when such registry is
1272 defined).
1274 Note: This document does not define a naming convention for
1275 time zone identifiers. Implementers may want to use the naming
1276 conventions defined in existing time zone specifications such
1277 as the public-domain Olson database [TZDB]. The specification
1278 of globally unique time zone identifiers is not addressed by
1279 this document and is left for future study.
1281 The following are examples of this property parameter:
1283 DTSTART;TZID=US-Eastern:19980119T020000
1285 DTEND;TZID=US-Eastern:19980119T030000
1287 The TZID property parameter MUST NOT be applied to DATE-TIME or
1288 TIME properties whose time values are specified in UTC.
1290 The use of local time in a DATE-TIME or TIME value without the
1291 TZID property parameter is to be interpreted as a local time
1292 value, regardless of the existence of "VTIMEZONE" calendar
1293 components in the iCalendar object.
1295 For more information see the sections on the data types DATE-TIME
1296 and TIME.
1298 3.2.20. Value Data Types
1300 Parameter Name: VALUE
1302 Purpose: To explicitly specify the data type format for a property
1303 value.
1305 Format Definition: The property parameter is defined by the following
1306 notation:
1308 valuetypeparam = "VALUE" "=" valuetype
1310 valuetype = ("BINARY"
1311 / "BOOLEAN"
1312 / "CAL-ADDRESS"
1313 / "DATE"
1314 / "DATE-TIME"
1315 / "DURATION"
1316 / "FLOAT"
1317 / "INTEGER"
1318 / "PERIOD"
1319 / "RECUR"
1320 / "TEXT"
1321 / "TIME"
1322 / "URI"
1323 / "UTC-OFFSET"
1324 / x-name
1325 ; Some experimental iCalendar data type.
1326 / iana-token)
1327 ; Some other IANA registered iCalendar data type.
1329 Description: The parameter specifies the data type and format of the
1330 property value. The property values MUST be of a single value
1331 type. For example, a "RDATE" property cannot have a combination
1332 of DATE- TIME and TIME value types.
1334 If the property's value is the default value type, then this
1335 parameter need not be specified. However, if the property's
1336 default value type is overridden by some other allowable value
1337 type, then this parameter MUST be specified.
1339 3.3. Property Value Data Types
1341 The properties in an iCalendar object are strongly typed. The
1342 definition of each property restricts the value to be one of the
1343 value data types, or simply value types, defined in this section.
1344 The value type for a property will either be specified implicitly as
1345 the default value type or will be explicitly specified with the
1346 "VALUE" parameter. If the value type of a property is one of the
1347 alternate valid types, then it MUST be explicitly specified with the
1348 "VALUE" parameter.
1350 3.3.1. Binary
1352 Value Name: BINARY
1354 Purpose: This value type is used to identify properties that contain
1355 a character encoding of inline binary data. For example, an
1356 inline attachment of an object code might be included in an
1357 iCalendar object.
1359 Format Definition: The value type is defined by the following
1360 notation:
1362 binary = *(4b-char) [b-end]
1363 ; A "BASE64" encoded character string, as defined by [RFC2045].
1365 b-end = (2b-char "==") / (3b-char "=")
1367 b-char = ALPHA / DIGIT / "+" / "/"
1369 Description: Property values with this value type MUST also include
1370 the inline encoding parameter sequence of ";ENCODING=BASE64".
1371 That is, all inline binary data MUST first be character encoded
1372 using the "BASE64" encoding method defined in [RFC2045]. No
1373 additional content value encoding (i.e., BACKSLASH character
1374 encoding) is defined for this value type.
1376 Example: The following is an abridged example of a "BASE64" encoded
1377 binary value data.
1379 ATTACH;VALUE=BINARY;ENCODING=BASE64:MIICajCCAdOgAwIBAgICBEUwDQY
1380 JKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlI
1381 ENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZv
1382 <...remainder of "BASE64" encoded binary data...>
1384 3.3.2. Boolean
1386 Value Name: BOOLEAN
1388 Purpose: This value type is used to identify properties that contain
1389 either a "TRUE" or "FALSE" Boolean value.
1391 Format Definition: The value type is defined by the following
1392 notation:
1394 boolean = "TRUE" / "FALSE"
1396 Description: These values are case insensitive text. No additional
1397 content value encoding (i.e., BACKSLASH character encoding) is
1398 defined for this value type.
1400 Example: The following is an example of a hypothetical property that
1401 has a BOOLEAN value type:
1403 GIBBERISH:TRUE
1405 3.3.3. Calendar User Address
1407 Value Name: CAL-ADDRESS
1409 Purpose: This value type is used to identify properties that contain
1410 a calendar user address.
1412 Format Definition: The value type is defined by the following
1413 notation:
1415 cal-address = uri
1417 Description: The value is a URI as defined by [RFC3986] or any other
1418 IANA registered form for a URI. When used to address an Internet
1419 email transport address for a calendar user, the value MUST be a
1420 MAILTO URI, as defined by [RFC2368] . No additional content value
1421 encoding (i.e., BACKSLASH character encoding) is defined for this
1422 value type.
1424 Example:
1426 ATTENDEE:MAILTO:jane_doe@example.com
1428 3.3.4. Date
1430 Value Name: DATE
1432 Purpose: This value type is used to identify values that contain a
1433 calendar date.
1435 Format Definition: The value type is defined by the following
1436 notation:
1438 date = date-value
1440 date-value = date-fullyear date-month date-mday
1441 date-fullyear = 4DIGIT
1442 date-month = 2DIGIT ;01-12
1443 date-mday = 2DIGIT ;01-28, 01-29, 01-30, 01-31
1444 ;based on month/year
1446 Description: If the property permits, multiple "date" values are
1447 specified as a COMMA character (US-ASCII decimal 44) separated
1448 list of values. The format for the value type is expressed as the
1449 [ISO.8601.1988] complete representation, basic format for a
1450 calendar date. The textual format specifies a four-digit year,
1451 two-digit month, and two-digit day of the month. There are no
1452 separator characters between the year, month and day component
1453 text.
1455 No additional content value encoding (i.e., BACKSLASH character
1456 encoding) is defined for this value type.
1458 Example: The following represents July 14, 1997:
1460 19970714
1462 3.3.5. Date-Time
1464 Value Name: DATE-TIME
1466 Purpose: This value type is used to identify values that specify a
1467 precise calendar date and time of day.
1469 Format Definition: The value type is defined by the following
1470 notation:
1472 date-time = date "T" time ;As specified in the date and time
1473 ;value definitions
1475 Description: If the property permits, multiple "date-time" values are
1476 specified as a COMMA character (US-ASCII decimal 44) separated
1477 list of values. No additional content value encoding (i.e.,
1478 BACKSLASH character encoding) is defined for this value type.
1480 The "DATE-TIME" data type is used to identify values that contain
1481 a precise calendar date and time of day. The format is based on
1482 the [ISO.8601.1988] complete representation, basic format for a
1483 calendar date and time of day. The text format is a concatenation
1484 of the "date", followed by the LATIN CAPITAL LETTER T character
1485 (US-ASCII decimal 84) time designator, followed by the "time"
1486 format.
1488 The "DATE-TIME" data type expresses time values in three forms:
1490 The form of date and time with UTC offset MUST NOT be used. For
1491 example, the following is not valid for a date-time value:
1493 DTSTART:19980119T230000-0800 ;Invalid time format
1495 FORM #1: DATE WITH LOCAL TIME
1497 The date with local time form is simply a date-time value that
1498 does not contain the UTC designator nor does it reference a time
1499 zone. For example, the following represents January 18, 1998, at
1500 11 PM:
1502 DTSTART:19980118T230000
1504 Date-time values of this type are said to be "floating" and are
1505 not bound to any time zone in particular. They are used to
1506 represent the same hour, minute, and second value regardless of
1507 which time zone is currently being observed. For example, an
1508 event can be defined that indicates that an individual will be
1509 busy from 11:00 AM to 1:00 PM every day, no matter which time zone
1510 the person is in. In these cases, a local time can be specified.
1511 The recipient of an iCalendar object with a property value
1512 consisting of a local time, without any relative time zone
1513 information, SHOULD interpret the value as being fixed to whatever
1514 time zone the ATTENDEE is in at any given moment. This means that
1515 two ATTENDEEs, in different time zones, receiving the same event
1516 definition as a floating time, may be participating in the event
1517 at different actual times. Floating time SHOULD only be used
1518 where that is the reasonable behavior.
1520 In most cases, a fixed time is desired. To properly communicate a
1521 fixed time in a property value, either UTC time or local time with
1522 time zone reference MUST be specified.
1524 The use of local time in a DATE-TIME value without the TZID
1525 property parameter is to be interpreted as floating time,
1526 regardless of the existence of "VTIMEZONE" calendar components in
1527 the iCalendar object.
1529 FORM #2: DATE WITH UTC TIME
1531 The date with UTC time, or absolute time, is identified by a LATIN
1532 CAPITAL LETTER Z suffix character (US-ASCII decimal 90), the UTC
1533 designator, appended to the time value. For example, the
1534 following represents January 19, 1998, at 0700 UTC:
1536 DTSTART:19980119T070000Z
1538 The TZID property parameter MUST NOT be applied to DATE-TIME
1539 properties whose time values are specified in UTC.
1541 FORM #3: DATE WITH LOCAL TIME AND TIME ZONE REFERENCE
1543 The date and local time with reference to time zone information is
1544 identified by the use the TZID property parameter to reference the
1545 appropriate time zone definition. TZID is discussed in detail in
1546 Section 3.2.19 . For example, the following represents 2 AM in
1547 New York on Janurary 19, 1998:
1549 DTSTART;TZID=US-Eastern:19980119T020000
1551 Example: The following represents July 14, 1997, at 1:30 PM in New
1552 York City in each of the three time formats, using the "DTSTART"
1553 property.
1555 DTSTART:19970714T133000 ;Local time
1556 DTSTART:19970714T173000Z ;UTC time
1557 DTSTART;TZID=US-Eastern:19970714T133000 ;Local time and time
1558 ; zone reference
1560 A time value MUST ONLY specify 60 seconds when specifying the
1561 periodic "leap second" in the time value. For example:
1563 COMPLETED:19970630T235960Z
1565 3.3.6. Duration
1567 Value Name: DURATION
1569 Purpose: This value type is used to identify properties that contain
1570 a duration of time.
1572 Format Definition: The value type is defined by the following
1573 notation:
1575 dur-value = (["+"] / "-") "P" (dur-date / dur-time / dur-week)
1577 dur-date = dur-day [dur-time]
1578 dur-time = "T" (dur-hour / dur-minute / dur-second)
1579 dur-week = 1*DIGIT "W"
1580 dur-hour = 1*DIGIT "H" [dur-minute]
1581 dur-minute = 1*DIGIT "M" [dur-second]
1582 dur-second = 1*DIGIT "S"
1583 dur-day = 1*DIGIT "D"
1585 Description: If the property permits, multiple "duration" values are
1586 specified by a COMMA character (US-ASCII decimal 44) separated
1587 list of values. The format is expressed as the [ISO.8601.1988]
1588 basic format for the duration of time. The format can represent
1589 durations in terms of weeks, days, hours, minutes, and seconds.
1591 No additional content value encoding (i.e., BACKSLASH character
1592 encoding) are defined for this value type.
1594 Example: A duration of 15 days, 5 hours and 20 seconds would be:
1596 P15DT5H0M20S
1598 A duration of 7 weeks would be:
1600 P7W
1602 3.3.7. Float
1604 Value Name: FLOAT
1606 Purpose: This value type is used to identify properties that contain
1607 a real number value.
1609 Format Definition: The value type is defined by the following
1610 notation:
1612 float = (["+"] / "-") 1*DIGIT ["." 1*DIGIT]
1614 Description: If the property permits, multiple "float" values are
1615 specified by a COMMA character (US-ASCII decimal 44) separated
1616 list of values.
1618 No additional content value encoding (i.e., BACKSLASH character
1619 encoding) is defined for this value type.
1621 Example:
1623 1000000.0000001
1624 1.333
1625 -3.14
1627 3.3.8. Integer
1629 Value Name: INTEGER
1631 Purpose: This value type is used to identify properties that contain
1632 a signed integer value.
1634 Format Definition: The value type is defined by the following
1635 notation:
1637 integer = (["+"] / "-") 1*DIGIT
1639 Description: If the property permits, multiple "integer" values are
1640 specified by a COMMA character (US-ASCII decimal 44) separated
1641 list of values. The valid range for "integer" is -2147483648 to
1642 2147483647. If the sign is not specified, then the value is
1643 assumed to be positive.
1645 No additional content value encoding (i.e., BACKSLASH character
1646 encoding) is defined for this value type.
1648 Example:
1650 1234567890
1651 -1234567890
1652 +1234567890
1653 432109876
1655 3.3.9. Period of Time
1657 Value Name: PERIOD
1658 Purpose: This value type is used to identify values that contain a
1659 precise period of time.
1661 Format Definition: The value type is defined by the following
1662 notation:
1664 period = period-explicit / period-start
1666 period-explicit = date-time "/" date-time
1667 ; [ISO.8601.1988] complete representation basic format for a
1668 ; period of time consisting of a start and end. The start MUST
1669 ; be before the end.
1671 period-start = date-time "/" dur-value
1672 ; [ISO.8601.1988] complete representation basic format for a
1673 ; period of time consisting of a start and positive duration
1674 ; of time.
1676 Description: If the property permits, multiple "period" values are
1677 specified by a COMMA character (US-ASCII decimal 44) separated
1678 list of values. There are two forms of a period of time. First,
1679 a period of time is identified by its start and its end. This
1680 format is expressed as the [ISO.8601.1988] complete
1681 representation, basic format for "DATE-TIME" start of the period,
1682 followed by a SOLIDUS character (US-ASCII decimal 47), followed by
1683 the "DATE-TIME" of the end of the period. The start of the period
1684 MUST be before the end of the period. Second, a period of time
1685 can also be defined by a start and a positive duration of time.
1686 The format is expressed as the [ISO.8601.1988] complete
1687 representation, basic format for the "DATE-TIME" start of the
1688 period, followed by a SOLIDUS character (US-ASCII decimal 47),
1689 followed by the [ISO.8601.1988] basic format for "DURATION" of the
1690 period.
1692 Example: The period starting at 18:00:00 UTC, on January 1, 1997 and
1693 ending at 07:00:00 UTC on January 2, 1997 would be:
1695 19970101T180000Z/19970102T070000Z
1697 The period start at 18:00:00 on January 1, 1997 and lasting 5
1698 hours and 30 minutes would be:
1700 19970101T180000Z/PT5H30M
1702 No additional content value encoding (i.e., BACKSLASH character
1703 encoding) is defined for this value type.
1705 3.3.10. Recurrence Rule
1707 Value Name: RECUR
1709 Purpose: This value type is used to identify properties that contain
1710 a recurrence rule specification.
1712 Format Definition: The value type is defined by the following
1713 notation:
1715 recur = "FREQ" = freq *(
1717 ; either UNTIL or COUNT may appear in a 'recur',
1718 ; but UNTIL and COUNT MUST NOT occur in the same
1719 ; 'recur'
1721 ( ";" "UNTIL" "=" enddate ) /
1722 ( ";" "COUNT" "=" 1*DIGIT ) /
1724 ; the rest of these keywords are optional,
1725 ; but MUST NOT occur more than once
1727 ( ";" "INTERVAL" "=" 1*DIGIT ) /
1728 ( ";" "BYSECOND" "=" byseclist ) /
1729 ( ";" "BYMINUTE" "=" byminlist ) /
1730 ( ";" "BYHOUR" "=" byhrlist ) /
1731 ( ";" "BYDAY" "=" bywdaylist ) /
1732 ( ";" "BYMONTHDAY" "=" bymodaylist ) /
1733 ( ";" "BYYEARDAY" "=" byyrdaylist ) /
1734 ( ";" "BYWEEKNO" "=" bywknolist ) /
1735 ( ";" "BYMONTH" "=" bymolist ) /
1736 ( ";" "BYSETPOS" "=" bysplist ) /
1737 ( ";" "WKST" "=" weekday ) /
1738 ( ";" x-name "=" text )
1739 )
1741 freq = "SECONDLY" / "MINUTELY" / "HOURLY" / "DAILY"
1742 / "WEEKLY" / "MONTHLY" / "YEARLY"
1744 enddate = date
1745 / date-time ;A UTC value
1747 byseclist = seconds / ( seconds *("," seconds) )
1749 seconds = 1DIGIT / 2DIGIT ;0 to 59
1751 byminlist = minutes / ( minutes *("," minutes) )
1752 minutes = 1DIGIT / 2DIGIT ;0 to 59
1754 byhrlist = hour / ( hour *("," hour) )
1756 hour = 1DIGIT / 2DIGIT ;0 to 23
1758 bywdaylist = weekdaynum / ( weekdaynum *("," weekdaynum) )
1760 weekdaynum = [([plus] ordwk / minus ordwk)] weekday
1762 plus = "+"
1764 minus = "-"
1766 ordwk = 1DIGIT / 2DIGIT ;1 to 53
1768 weekday = "SU" / "MO" / "TU" / "WE" / "TH" / "FR" / "SA"
1769 ;Corresponding to SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY,
1770 ;FRIDAY, SATURDAY and SUNDAY days of the week.
1772 bymodaylist = monthdaynum / ( monthdaynum *("," monthdaynum) )
1774 monthdaynum = ([plus] ordmoday) / (minus ordmoday)
1776 ordmoday = 1DIGIT / 2DIGIT ;1 to 31
1778 byyrdaylist = yeardaynum / ( yeardaynum *("," yeardaynum) )
1780 yeardaynum = ([plus] ordyrday) / (minus ordyrday)
1782 ordyrday = 1DIGIT / 2DIGIT / 3DIGIT ;1 to 366
1784 bywknolist = weeknum / ( weeknum *("," weeknum) )
1786 weeknum = ([plus] ordwk) / (minus ordwk)
1788 bymolist = monthnum / ( monthnum *("," monthnum) )
1790 monthnum = 1DIGIT / 2DIGIT ;1 to 12
1792 bysplist = setposday / ( setposday *("," setposday) )
1794 setposday = yeardaynum
1796 Description: If the property permits, multiple "recur" values are
1797 specified by a COMMA character (US-ASCII decimal 44) separated
1798 list of values. The value type is a structured value consisting
1799 of a list of one or more recurrence grammar parts. Each rule part
1800 is defined by a NAME=VALUE pair. The rule parts are separated
1801 from each other by the SEMICOLON character (US-ASCII decimal 59).
1802 The rule parts are not ordered in any particular sequence.
1803 Individual rule parts MUST only be specified once.
1805 The FREQ rule part identifies the type of recurrence rule. This
1806 rule part MUST be specified in the recurrence rule. Valid values
1807 include SECONDLY, to specify repeating events based on an interval
1808 of a second or more; MINUTELY, to specify repeating events based
1809 on an interval of a minute or more; HOURLY, to specify repeating
1810 events based on an interval of an hour or more; DAILY, to specify
1811 repeating events based on an interval of a day or more; WEEKLY, to
1812 specify repeating events based on an interval of a week or more;
1813 MONTHLY, to specify repeating events based on an interval of a
1814 month or more; and YEARLY, to specify repeating events based on an
1815 interval of a year or more.
1817 The INTERVAL rule part contains a positive integer representing
1818 how often the recurrence rule repeats. The default value is "1",
1819 meaning every second for a SECONDLY rule, or every minute for a
1820 MINUTELY rule, every hour for an HOURLY rule, every day for a
1821 DAILY rule, every week for a WEEKLY rule, every month for a
1822 MONTHLY rule and every year for a YEARLY rule.
1824 The UNTIL rule part defines a date-time value which bounds the
1825 recurrence rule in an inclusive manner. If the value specified by
1826 UNTIL is synchronized with the specified recurrence, this date or
1827 date-time becomes the last instance of the recurrence. If
1828 specified as a date-time value, then it MUST be specified in a UTC
1829 time format. If not present, and the COUNT rule part is also not
1830 present, the RRULE is considered to repeat forever.
1832 The COUNT rule part defines the number of occurrences at which to
1833 range-bound the recurrence. The "DTSTART" property value, if
1834 specified, counts as the first occurrence.
1836 The BYSECOND rule part specifies a COMMA character (US-ASCII
1837 decimal 44) separated list of seconds within a minute. Valid
1838 values are 0 to 59. The BYMINUTE rule part specifies a COMMA
1839 character (US-ASCII decimal 44) separated list of minutes within
1840 an hour. Valid values are 0 to 59. The BYHOUR rule part
1841 specifies a COMMA character (US-ASCII decimal 44) separated list
1842 of hours of the day. Valid values are 0 to 23.
1844 The BYDAY rule part specifies a COMMA character (US-ASCII decimal
1845 44) separated list of days of the week; MO indicates Monday; TU
1846 indicates Tuesday; WE indicates Wednesday; TH indicates Thursday;
1847 FR indicates Friday; SA indicates Saturday; SU indicates Sunday.
1849 Each BYDAY value can also be preceded by a positive (+n) or
1850 negative (-n) integer. If present, this indicates the nth
1851 occurrence of the specific day within the MONTHLY or YEARLY RRULE.
1852 For example, within a MONTHLY rule, +1MO (or simply 1MO)
1853 represents the first Monday within the month, whereas -1MO
1854 represents the last Monday of the month. If an integer modifier
1855 is not present, it means all days of this type within the
1856 specified frequency. For example, within a MONTHLY rule, MO
1857 represents all Mondays within the month.
1859 The BYMONTHDAY rule part specifies a COMMA character (US-ASCII
1860 decimal 44) separated list of days of the month. Valid values are
1861 1 to 31 or -31 to -1. For example, -10 represents the tenth to
1862 the last day of the month.
1864 The BYYEARDAY rule part specifies a COMMA character (US-ASCII
1865 decimal 44) separated list of days of the year. Valid values are
1866 1 to 366 or -366 to -1. For example, -1 represents the last day
1867 of the year (December 31st) and -306 represents the 306th to the
1868 last day of the year (March 1st).
1870 The BYWEEKNO rule part specifies a COMMA character (US-ASCII
1871 decimal 44) separated list of ordinals specifying weeks of the
1872 year. Valid values are 1 to 53 or -53 to -1. This corresponds to
1873 weeks according to week numbering as defined in [ISO.8601.1988].
1874 A week is defined as a seven day period, starting on the day of
1875 the week defined to be the week start (see WKST). Week number one
1876 of the calendar year is the first week which contains at least
1877 four (4) days in that calendar year. This rule part is only valid
1878 for YEARLY rules. For example, 3 represents the third week of the
1879 year.
1881 Note: Assuming a Monday week start, week 53 can only occur when
1882 Thursday is January 1 or if it is a leap year and Wednesday is
1883 January 1.
1885 The BYMONTH rule part specifies a COMMA character (US-ASCII
1886 decimal 44) separated list of months of the year. Valid values
1887 are 1 to 12.
1889 The WKST rule part specifies the day on which the workweek starts.
1890 Valid values are MO, TU, WE, TH, FR, SA and SU. This is
1891 significant when a WEEKLY RRULE has an interval greater than 1,
1892 and a BYDAY rule part is specified. This is also significant when
1893 in a YEARLY RRULE when a BYWEEKNO rule part is specified. The
1894 default value is MO.
1896 The BYSETPOS rule part specifies a COMMA character (US-ASCII
1897 decimal 44) separated list of values which corresponds to the nth
1898 occurrence within the set of events specified by the rule. Valid
1899 values are 1 to 366 or -366 to -1. It MUST only be used in
1900 conjunction with another BYxxx rule part. For example "the last
1901 work day of the month" could be represented as:
1903 RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1
1905 Each BYSETPOS value can include a positive (+n) or negative (-n)
1906 integer. If present, this indicates the nth occurrence of the
1907 specific occurrence within the set of occurences specified by the
1908 rule.
1910 If BYxxx rule part values are found which are beyond the available
1911 scope (ie, BYMONTHDAY=30 in February), they are simply ignored.
1913 Information, not contained in the rule, necessary to determine the
1914 various recurrence instance start time and dates are derived from
1915 the Start Time (DTSTART) entry attribute. For example,
1916 "FREQ=YEARLY;BYMONTH=1" doesn't specify a specific day within the
1917 month or a time. This information would be the same as what is
1918 specified for DTSTART.
1920 BYxxx rule parts modify the recurrence in some manner. BYxxx rule
1921 parts for a period of time which is the same or greater than the
1922 frequency generally reduce or limit the number of occurrences of
1923 the recurrence generated. For example, "FREQ=DAILY;BYMONTH=1"
1924 reduces the number of recurrence instances from all days (if
1925 BYMONTH rule part is not present) to all days in January. BYxxx
1926 rule parts for a period of time less than the frequency generally
1927 increase or expand the number of occurrences of the recurrence.
1928 For example, "FREQ=YEARLY;BYMONTH=1,2" increases the number of
1929 days within the yearly recurrence set from 1 (if BYMONTH rule part
1930 is not present) to 2.
1932 If multiple BYxxx rule parts are specified, then after evaluating
1933 the specified FREQ and INTERVAL rule parts, the BYxxx rule parts
1934 are applied to the current set of evaluated occurrences in the
1935 following order: BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY, BYDAY,
1936 BYHOUR, BYMINUTE, BYSECOND and BYSETPOS; then COUNT and UNTIL are
1937 evaluated.
1939 Here is an example of evaluating multiple BYxxx rule parts.
1941 DTSTART;TZID=US-Eastern:19970105T083000
1942 RRULE:FREQ=YEARLY;INTERVAL=2;BYMONTH=1;BYDAY=SU;BYHOUR=8,9;
1943 BYMINUTE=30
1945 First, the "INTERVAL=2" would be applied to "FREQ=YEARLY" to
1946 arrive at "every other year". Then, "BYMONTH=1" would be applied
1947 to arrive at "every January, every other year". Then, "BYDAY=SU"
1948 would be applied to arrive at "every Sunday in January, every
1949 other year". Then, "BYHOUR=8,9" would be applied to arrive at
1950 "every Sunday in January at 8 AM and 9 AM, every other year".
1951 Then, "BYMINUTE=30" would be applied to arrive at "every Sunday in
1952 January at 8:30 AM and 9:30 AM, every other year". Then, lacking
1953 information from RRULE, the second is derived from DTSTART, to end
1954 up in "every Sunday in January at 8:30:00 AM and 9:30:00 AM, every
1955 other year". Similarly, if the BYMINUTE, BYHOUR, BYDAY,
1956 BYMONTHDAY or BYMONTH rule part were missing, the appropriate
1957 minute, hour, day or month would have been retrieved from the
1958 "DTSTART" property.
1960 No additional content value encoding (i.e., BACKSLASH character
1961 encoding) is defined for this value type.
1963 Example: The following is a rule which specifies 10 occurences which
1964 occur every other day:
1966 FREQ=DAILY;COUNT=10;INTERVAL=2
1968 There are other examples specified in the "RRULE" specification.
1970 3.3.11. Text
1972 Value Name: TEXT
1974 Purpose: This value type is used to identify values that contain
1975 human readable text.
1977 Format Definition: The value type is defined by the following
1978 notation.
1980 text = *(TSAFE-CHAR / ":" / DQUOTE / ESCAPED-CHAR)
1981 ; Folded according to description above
1983 ESCAPED-CHAR = ("\\" / "\;" / "\," / "\N" / "\n")
1984 ; \\ encodes \, \N or \n encodes newline
1985 ; \; encodes ;, \, encodes ,
1987 TSAFE-CHAR = %x20-21 / %x23-2B / %x2D-39 / %x3C-5B /
1988 %x5D-7E / NON-US-ASCII
1989 ; Any character except CTLs not needed by the current
1990 ; character set, DQUOTE, ";", ":", "\", ","
1992 Note: Certain other character sets may require modification of
1993 the above definitions, but this is beyond the scope of this
1994 document.
1996 Description: If the property permits, multiple "text" values are
1997 specified by a COMMA character (US-ASCII decimal 44) separated
1998 list of values.
2000 The language in which the text is represented can be controlled by
2001 the "LANGUAGE" property parameter.
2003 An intentional formatted text line break MUST only be included in
2004 a "TEXT" property value by representing the line break with the
2005 character sequence of BACKSLASH (US-ASCII decimal 92), followed by
2006 a LATIN SMALL LETTER N (US-ASCII decimal 110) or a LATIN CAPITAL
2007 LETTER N (US-ASCII decimal 78), that is "\n" or "\N".
2009 The "TEXT" property values may also contain special characters
2010 that are used to signify delimiters, such as a COMMA character for
2011 lists of values or a SEMICOLON character for structured values.
2012 In order to support the inclusion of these special characters in
2013 "TEXT" property values, they MUST be escaped with a BACKSLASH
2014 character. A BACKSLASH character (US-ASCII decimal 92) in a
2015 "TEXT" property value MUST be escaped with another BACKSLASH
2016 character. A COMMA character in a "TEXT" property value MUST be
2017 escaped with a BACKSLASH character (US-ASCII decimal 92). A
2018 SEMICOLON character in a "TEXT" property value MUST be escaped
2019 with a BACKSLASH character (US-ASCII decimal 92). However, a
2020 COLON character in a "TEXT" property value SHALL NOT be escaped
2021 with a BACKSLASH character.
2023 Example: A multiple line value of:
2025 Project XYZ Final Review
2026 Conference Room - 3B
2027 Come Prepared.
2029 would be represented as:
2031 Project XYZ Final Review\nConference Room - 3B\nCome Prepared.
2033 3.3.12. Time
2035 Value Name: TIME
2037 Purpose: This value type is used to identify values that contain a
2038 time of day.
2040 Format Definition: The data type is defined by the following
2041 notation:
2043 time = time-hour time-minute time-second [time-utc]
2045 time-hour = 2DIGIT ;00-23
2046 time-minute = 2DIGIT ;00-59
2047 time-second = 2DIGIT ;00-60
2048 ;The "60" value is used to account for "leap" seconds.
2050 time-utc = "Z"
2052 Description: If the property permits, multiple "time" values are
2053 specified by a COMMA character (US-ASCII decimal 44) separated
2054 list of values. No additional content value encoding (i.e.,
2055 BACKSLASH character encoding) is defined for this value type.
2057 The "TIME" data type is used to identify values that contain a
2058 time of day. The format is based on the [ISO.8601.1988] complete
2059 representation, basic format for a time of day. The text format
2060 consists of a two-digit 24-hour of the day (i.e., values 0-23),
2061 two- digit minute in the hour (i.e., values 0-59), and two-digit
2062 seconds in the minute (i.e., values 0-60). The seconds value of
2063 60 MUST only be used to account for "leap" seconds. Fractions of
2064 a second are not supported by this format.
2066 In parallel to the "DATE-TIME" definition above, the "TIME" data
2067 type expresses time values in three forms:
2069 The form of time with UTC offset MUST NOT be used. For example,
2070 the following is NOT VALID for a time value:
2072 230000-0800 ;Invalid time format
2074 FORM #1 LOCAL TIME
2076 The local time form is simply a time value that does not contain
2077 the UTC designator nor does it reference a time zone. For
2078 example, 11:00 PM:
2080 230000
2082 Time values of this type are said to be "floating" and are not
2083 bound to any time zone in particular. They are used to represent
2084 the same hour, minute, and second value regardless of which time
2085 zone is currently being observed. For example, an event can be
2086 defined that indicates that an individual will be busy from 11:00
2087 AM to 1:00 PM every day, no matter which time zone the person is
2088 in. In these cases, a local time can be specified. The recipient
2089 of an iCalendar object with a property value consisting of a local
2090 time, without any relative time zone information, SHOULD interpret
2091 the value as being fixed to whatever time zone the ATTENDEE is in
2092 at any given moment. This means that two ATTENDEEs may
2093 participate in the same event at different UTC times; floating
2094 time SHOULD only be used where that is reasonable behavior.
2096 In most cases, a fixed time is desired. To properly communicate a
2097 fixed time in a property value, either UTC time or local time with
2098 time zone reference MUST be specified.
2100 The use of local time in a TIME value without the TZID property
2101 parameter is to be interpreted as a local time value, regardless
2102 of the existence of "VTIMEZONE" calendar components in the
2103 iCalendar object.
2105 FORM #2: UTC TIME
2107 UTC time, or absolute time, is identified by a LATIN CAPITAL
2108 LETTER Z suffix character (US-ASCII decimal 90), the UTC
2109 designator, appended to the time value. For example, the
2110 following represents 07:00 AM UTC:
2112 070000Z
2114 The TZID property parameter MUST NOT be applied to TIME properties
2115 whose time values are specified in UTC.
2117 FORM #3: LOCAL TIME AND TIME ZONE REFERENCE
2119 The local time with reference to time zone information form is
2120 identified by the use the TZID property parameter to reference the
2121 appropriate time zone definition. TZID is discussed in detail in
2122 Section 3.2.19 .
2124 Example: The following represents 8:30 AM in New York in Winter, five
2125 hours behind UTC, in each of the three formats using the "X-ABC-
2126 TIMEOFDAY" non-standard property:
2128 X-ABC-TIMEOFDAY:083000
2130 X-ABC-TIMEOFDAY:133000Z
2132 X-ABC-TIMEOFDAY;TZID=US-Eastern:083000
2134 3.3.13. URI
2136 Value Name: URI
2138 Purpose: This value type is used to identify values that contain a
2139 uniform resource identifier (URI) type of reference to the
2140 property value.
2142 Format Definition: The data type is defined by the following
2143 notation:
2145 uri =
2147 Description: This data type might be used to reference binary
2148 information, for values that are large, or otherwise undesirable
2149 to include directly in the iCalendar object.
2151 The URI value formats in RFC 1738, RFC 2111 and any other IETF
2152 registered value format can be specified.
2154 Any IANA registered URI format can be used. These include, but
2155 are not limited to, those defined in RFC 1738 and RFC 2111.
2157 When a property parameter value is a URI value type, the URI MUST
2158 be specified as a quoted-string value.
2160 No additional content value encoding (i.e., BACKSLASH character
2161 encoding) is defined for this value type.
2163 Example: The following is a URI for a network file:
2165 http://example.com/my-report.txt
2167 3.3.14. UTC Offset
2169 Value Name: UTC-OFFSET
2171 Purpose: This value type is used to identify properties that contain
2172 an offset from UTC to local time.
2174 Format Definition: The data type is defined by the following
2175 notation:
2177 utc-offset = time-numzone ;As defined above in time data type
2179 time-numzone = ("+" / "-") time-hour time-minute [time-
2180 second]
2182 Description: The PLUS SIGN (US-ASCII decimal 43) character MUST be
2183 specified for positive UTC offsets (i.e., ahead of UTC). The
2184 HYPHEN-MINUS character (US-ASCII decimal 45) MUST be specified for
2185 negative UTC offsets (i.e., behind of UTC). The value of "-0000"
2186 and "-000000" are not allowed. The time-second, if present, may
2187 not be 60; if absent, it defaults to zero.
2189 No additional content value encoding (i.e., BACKSLASH character
2190 encoding) is defined for this value type.
2192 Example: The following UTC offsets are given for standard time for
2193 New York (five hours behind UTC) and Geneva (one hour ahead of
2194 UTC):
2196 -0500
2198 +0100
2200 3.4. iCalendar Object
2202 The Calendaring and Scheduling Core Object is a collection of
2203 calendaring and scheduling information. Typically, this information
2204 will consist of a single iCalendar object. However, multiple
2205 iCalendar objects can be sequentially grouped together. The first
2206 line and last line of the iCalendar object MUST contain a pair of
2207 iCalendar object delimiter strings. The syntax for an iCalendar
2208 object is as follows:
2210 icalobject = 1*("BEGIN" ":" "VCALENDAR" CRLF
2211 icalbody
2212 "END" ":" "VCALENDAR" CRLF)
2214 The following is a simple example of an iCalendar object:
2216 BEGIN:VCALENDAR
2217 VERSION:2.0
2218 PRODID:-//hacksw/handcal//NONSGML v1.0//EN
2219 BEGIN:VEVENT
2220 UID:19970610T172345Z-AF23B2@example.com
2221 DTSTAMP:19970610T172345Z
2222 DTSTART:19970714T170000Z
2223 DTEND:19970715T035959Z
2224 SUMMARY:Bastille Day Party
2225 END:VEVENT
2226 END:VCALENDAR
2228 3.5. Property
2230 A property is the definition of an individual attribute describing a
2231 calendar object or a calendar component. A property takes the form
2232 defined by the "contentline" notation defined in Section 3.1 .
2234 The following is an example of a property:
2236 DTSTART:19960415T133000Z
2238 This memo imposes no ordering of properties within an iCalendar
2239 object.
2241 Property names, parameter names and enumerated parameter values are
2242 case insensitive. For example, the property name "DUE" is the same
2243 as "due" and "Due", DTSTART;TZID=US-Eastern:19980714T120000 is the
2244 same as DtStart;TzID=US-Eastern:19980714T120000.
2246 3.6. Calendar Components
2248 The body of the iCalendar object consists of a sequence of calendar
2249 properties and one or more calendar components. The calendar
2250 properties are attributes that apply to the calendar object as a
2251 whole. The calendar components are collections of properties that
2252 express a particular calendar semantic. For example, the calendar
2253 component can specify an event, a to-do, a journal entry, time zone
2254 information, free/busy time information, or an alarm.
2256 The body of the iCalendar object is defined by the following
2257 notation:
2259 icalbody = calprops component
2261 calprops = 2*(
2263 ; 'prodid' and 'version' are both REQUIRED,
2264 ; but MUST NOT occur more than once
2266 prodid / version /
2268 ; 'calscale' and 'method' are optional,
2269 ; but MUST NOT occur more than once
2271 calscale /
2272 method /
2274 ; 'x-prop' is OPTIONAL,
2275 ; and MAY occur more than once
2277 x-prop
2278 )
2280 component = 1*(eventc / todoc / journalc / freebusyc /
2281 timezonec / iana-comp / x-comp)
2283 iana-comp = "BEGIN" ":" iana-token CRLF
2285 1*contentline
2287 "END" ":" iana-token CRLF
2289 x-comp = "BEGIN" ":" x-name CRLF
2291 1*contentline
2293 "END" ":" x-name CRLF
2295 An iCalendar object MUST include the "PRODID" and "VERSION" calendar
2296 properties. In addition, it MUST include at least one calendar
2297 component. Special forms of iCalendar objects are possible to
2298 publish just busy time (i.e., only a "VFREEBUSY" calendar component)
2299 or time zone (i.e., only a "VTIMEZONE" calendar component)
2300 information. In addition, a complex iCalendar object is possible
2301 that is used to capture a complete snapshot of the contents of a
2302 calendar (e.g., composite of many different calendar components).
2303 More commonly, an iCalendar object will consist of just a single
2304 "VEVENT", "VTODO" or "VJOURNAL" calendar component.
2306 3.6.1. Event Component
2308 Component Name: VEVENT
2310 Purpose: Provide a grouping of component properties that describe an
2311 event.
2313 Format Definition: A "VEVENT" calendar component is defined by the
2314 following notation:
2316 eventc = "BEGIN" ":" "VEVENT" CRLF
2317 eventprop *alarmc
2318 "END" ":" "VEVENT" CRLF
2320 eventprop = 3*(
2322 ; the following are REQUIRED,
2323 ; but MUST NOT occur more than once
2325 dtstamp / dtstart / uid /
2327 ; the following are optional,
2328 ; but MUST NOT occur more than once
2330 class / created / description / geo /
2331 last-mod / location / organizer / priority /
2332 seq / status / summary / transp /
2333 url / recurid /
2335 ; either 'dtend' or 'duration' may appear in
2336 ; a 'eventprop', but 'dtend' and 'duration'
2337 ; MUST NOT occur in the same 'eventprop'
2339 dtend / duration /
2341 ; the following are optional,
2342 ; and MAY occur more than once
2344 attach / attendee / categories / comment /
2345 contact / exdate / exrule / rstatus / related /
2346 resources / rdate / rrule / x-prop
2348 )
2350 Description: A "VEVENT" calendar component is a grouping of component
2351 properties, and possibly including "VALARM" calendar components,
2352 that represents a scheduled amount of time on a calendar. For
2353 example, it can be an activity; such as a one-hour long,
2354 department meeting from 8:00 AM to 9:00 AM, tomorrow. Generally,
2355 an event will take up time on an individual calendar. Hence, the
2356 event will appear as an opaque interval in a search for busy time.
2357 Alternately, the event can have its Time Transparency set to
2358 "TRANSPARENT" in order to prevent blocking of the event in
2359 searches for busy time.
2361 The "VEVENT" is also the calendar component used to specify an
2362 anniversary or daily reminder within a calendar. These events
2363 have a DATE value type for the "DTSTART" property instead of the
2364 default data type of DATE-TIME. If such a "VEVENT" has a "DTEND"
2365 property, it MUST be specified as a DATE value also. The
2366 anniversary type of "VEVENT" can span more than one date (i.e,
2367 "DTEND" property value is set to a calendar date after the
2368 "DTSTART" property value).
2370 The "DTSTART" property for a "VEVENT" specifies the inclusive
2371 start of the event. For recurring events, it also specifies the
2372 very first instance in the recurrence set. The "DTEND" property
2373 for a "VEVENT" calendar component specifies the non-inclusive end
2374 of the event. For cases where a "VEVENT" calendar component
2375 specifies a "DTSTART" property with a DATE data type but no
2376 "DTEND" property, the events non-inclusive end is the end of the
2377 calendar date specified by the "DTSTART" property. For cases
2378 where a "VEVENT" calendar component specifies a "DTSTART" property
2379 with a DATE-TIME data type but no "DTEND" property, the event ends
2380 on the same calendar date and time of day specified by the
2381 "DTSTART" property.
2383 The "VEVENT" calendar component cannot be nested within another
2384 calendar component. However, "VEVENT" calendar components can be
2385 related to each other or to a "VTODO" or to a "VJOURNAL" calendar
2386 component with the "RELATED-TO" property.
2388 Example: The following is an example of the "VEVENT" calendar
2389 component used to represent a meeting that will also be opaque to
2390 searches for busy time:
2392 BEGIN:VEVENT
2393 UID:19970901T130000Z-123401@example.com
2394 DTSTAMP:19970901T130000Z
2395 DTSTART:19970903T163000Z
2396 DTEND:19970903T190000Z
2397 SUMMARY:Annual Employee Review
2398 CLASS:PRIVATE
2399 CATEGORIES:BUSINESS,HUMAN RESOURCES
2400 END:VEVENT
2402 The following is an example of the "VEVENT" calendar component
2403 used to represent a reminder that will not be opaque, but rather
2404 transparent, to searches for busy time:
2406 BEGIN:VEVENT
2407 UID:19970901T130000Z-123402@example.com
2408 DTSTAMP:19970901T130000Z
2409 DTSTART:19970401T163000Z
2410 DTEND:19970402T010000Z
2411 SUMMARY:Laurel is in sensitivity awareness class.
2412 CLASS:PUBLIC
2413 CATEGORIES:BUSINESS,HUMAN RESOURCES
2414 TRANSP:TRANSPARENT
2415 END:VEVENT
2417 The following is an example of the "VEVENT" calendar component
2418 used to represent an anniversary that will occur annually. Since
2419 it takes up no time, it will not appear as opaque in a search for
2420 busy time; no matter what the value of the "TRANSP" property
2421 indicates:
2423 BEGIN:VEVENT
2424 UID:19970901T130000Z-123403@example.com
2425 DTSTAMP:19970901T130000Z
2426 DTSTART;VALUE=DATE:19971102
2427 SUMMARY:Our Blissful Anniversary
2428 CLASS:CONFIDENTIAL
2429 CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION
2430 RRULE:FREQ=YEARLY
2431 END:VEVENT
2433 3.6.2. To-do Component
2435 Component Name: VTODO
2436 Purpose: Provide a grouping of calendar properties that describe a
2437 to-do.
2439 Format Definition: A "VTODO" calendar component is defined by the
2440 following notation:
2442 todoc = "BEGIN" ":" "VTODO" CRLF
2443 todoprop *alarmc
2444 "END" ":" "VTODO" CRLF
2446 todoprop = 2*(
2448 ; the following are REQUIRED,
2449 ; but MUST NOT occur more than once
2451 dtstamp / uid /
2453 ; the following are optional,
2454 ; but MUST NOT occur more than once
2456 class / completed / created / description /
2457 dtstart / geo / last-mod / location / organizer /
2458 percent / priority / recurid / seq / status /
2459 summary / url /
2461 ; either 'due' or 'duration' may appear in
2462 ; a 'todoprop', but 'due' and 'duration'
2463 ; MUST NOT occur in the same 'todoprop'
2465 due / duration /
2467 ; the following are optional,
2468 ; and MAY occur more than once
2470 attach / attendee / categories / comment / contact /
2471 exdate / exrule / rstatus / related / resources /
2472 rdate / rrule / x-prop
2474 )
2476 Description: A "VTODO" calendar component is a grouping of component
2477 properties and possibly "VALARM" calendar components that
2478 represent an action-item or assignment. For example, it can be
2479 used to represent an item of work assigned to an individual; such
2480 as "turn in travel expense today".
2482 The "VTODO" calendar component cannot be nested within another
2483 calendar component. However, "VTODO" calendar components can be
2484 related to each other or to a "VEVENT" or to a "VJOURNAL" calendar
2485 component with the "RELATED-TO" property.
2487 A "VTODO" calendar component without the "DTSTART" and "DUE" (or
2488 "DURATION") properties specifies a to-do that will be associated
2489 with each successive calendar date, until it is completed.
2491 Example: The following is an example of a "VTODO" calendar component:
2493 BEGIN:VTODO
2494 UID:19970901T130000Z-123404@example.com
2495 DTSTAMP:19970901T130000Z
2496 DTSTART:19970415T133000Z
2497 DUE:19970416T045959Z
2498 SUMMARY:1996 Income Tax Preparation
2499 CLASS:CONFIDENTIAL
2500 CATEGORIES:FAMILY,FINANCE
2501 PRIORITY:1
2502 STATUS:NEEDS-ACTION
2503 END:VTODO
2505 3.6.3. Journal Component
2507 Component Name: VJOURNAL
2509 Purpose: Provide a grouping of component properties that describe a
2510 journal entry.
2512 Format Definition: A "VJOURNAL" calendar component is defined by the
2513 following notation:
2515 journalc = "BEGIN" ":" "VJOURNAL" CRLF
2516 jourprop
2517 "END" ":" "VJOURNAL" CRLF
2519 jourprop = 1*(
2521 ; the following are REQUIRED,
2522 ; but MUST NOT occur more than once
2524 dtstamp / uid /
2526 ; the following are optional,
2527 ; but MUST NOT occur more than once
2529 class / created / description / dtstart /
2530 last-mod / organizer / recurid / seq / status /
2531 summary / url /
2533 ; the following are optional,
2534 ; and MAY occur more than once
2536 attach / attendee / categories / comment /
2537 contact / exdate / exrule / related / rdate /
2538 rrule / rstatus / x-prop
2539 )
2541 Description: A "VJOURNAL" calendar component is a grouping of
2542 component properties that represent one or more descriptive text
2543 notes associated with a particular calendar date. The "DTSTART"
2544 property is used to specify the calendar date that the journal
2545 entry is associated with. Generally, it will have a DATE value
2546 data type, but it can also be used to specify a DATE-TIME value
2547 data type. Examples of a journal entry include a daily record of
2548 a legislative body or a journal entry of individual telephone
2549 contacts for the day or an ordered list of accomplishments for the
2550 day. The "VJOURNAL" calendar component can also be used to
2551 associate a document with a calendar date.
2553 The "VJOURNAL" calendar component does not take up time on a
2554 calendar. Hence, it does not play a role in free or busy time
2555 searches - - it is as though it has a time transparency value of
2556 TRANSPARENT. It is transparent to any such searches.
2558 The "VJOURNAL" calendar component cannot be nested within another
2559 calendar component. However, "VJOURNAL" calendar components can
2560 be related to each other or to a "VEVENT" or to a "VTODO" calendar
2561 component, with the "RELATED-TO" property.
2563 Example: The following is an example of the "VJOURNAL" calendar
2564 component:
2566 BEGIN:VJOURNAL
2567 UID:19970901T130000Z-123405@example.com
2568 DTSTAMP:19970901T130000Z
2569 DTSTART;VALUE=DATE:19970317
2570 SUMMARY:Staff meeting minutes
2571 DESCRIPTION:1. Staff meeting: Participants include Joe\, Lisa
2572 and Bob. Aurora project plans were reviewed. There is currentl
2573 y no budget reserves for this project. Lisa will escalate to
2574 management. Next meeting on Tuesday.\n
2575 2. Telephone Conference: ABC Corp. sales representative called
2576 to discuss new printer. Promised to get us a demo by Friday.\n
2577 3. Henry Miller (Handsoff Insurance): Car was totaled by tree.
2578 Is looking into a loaner car. 654-2323 (tel).
2579 END:VJOURNAL
2581 3.6.4. Free/Busy Component
2583 Component Name: VFREEBUSY
2585 Purpose: Provide a grouping of component properties that describe
2586 either a request for free/busy time, describe a response to a
2587 request for free/busy time or describe a published set of busy
2588 time.
2590 Format Definition: A "VFREEBUSY" calendar component is defined by the
2591 following notation:
2593 freebusyc = "BEGIN" ":" "VFREEBUSY" CRLF
2594 fbprop
2595 "END" ":" "VFREEBUSY" CRLF
2597 fbprop = *(
2599 ; the following are optional,
2600 ; but MUST NOT occur more than once
2602 contact / dtstart / dtend / duration / dtstamp /
2603 organizer / uid / url /
2605 ; the following are optional,
2606 ; and MAY occur more than once
2608 attendee / comment / freebusy / rstatus / x-prop
2609 )
2611 Description: A "VFREEBUSY" calendar component is a grouping of
2612 component properties that represents either a request for, a reply
2613 to a request for free or busy time information or a published set
2614 of busy time information.
2616 When used to request free/busy time information, the "ATTENDEE"
2617 property specifies the calendar users whose free/busy time is
2618 being requested; the "ORGANIZER" property specifies the calendar
2619 user who is requesting the free/busy time; the "DTSTART" and
2620 "DTEND" properties specify the window of time for which the free/
2621 busy time is being requested; the "UID" and "DTSTAMP" properties
2622 are specified to assist in proper sequencing of multiple free/busy
2623 time requests.
2625 When used to reply to a request for free/busy time, the "ATTENDEE"
2626 property specifies the calendar user responding to the free/busy
2627 time request; the "ORGANIZER" property specifies the calendar user
2628 that originally requested the free/busy time; the "FREEBUSY"
2629 property specifies the free/busy time information (if it exists);
2630 and the "UID" and "DTSTAMP" properties are specified to assist in
2631 proper sequencing of multiple free/busy time replies.
2633 When used to publish busy time, the "ORGANIZER" property specifies
2634 the calendar user associated with the published busy time; the
2635 "DTSTART" and "DTEND" properties specify an inclusive time window
2636 that surrounds the busy time information; the "FREEBUSY" property
2637 specifies the published busy time information; and the "DTSTAMP"
2638 property specifies the date/time that iCalendar object was
2639 created.
2641 The "VFREEBUSY" calendar component cannot be nested within another
2642 calendar component. Multiple "VFREEBUSY" calendar components can
2643 be specified within an iCalendar object. This permits the
2644 grouping of Free/Busy information into logical collections, such
2645 as monthly groups of busy time information.
2647 The "VFREEBUSY" calendar component is intended for use in
2648 iCalendar object methods involving requests for free time,
2649 requests for busy time, requests for both free and busy, and the
2650 associated replies.
2652 Free/Busy information is represented with the "FREEBUSY" property.
2653 This property provides a terse representation of time periods.
2654 One or more "FREEBUSY" properties can be specified in the
2655 "VFREEBUSY" calendar component.
2657 When present in a "VFREEBUSY" calendar component, the "DTSTART"
2658 and "DTEND" properties SHOULD be specified prior to any "FREEBUSY"
2659 properties. In a free time request, these properties can be used
2660 in combination with the "DURATION" property to represent a request
2661 for a duration of free time within a specified window of time.
2663 The recurrence properties ("RRULE", "EXRULE", "RDATE", "EXDATE")
2664 are not permitted within a "VFREEBUSY" calendar component. Any
2665 recurring events are resolved into their individual busy time
2666 periods using the "FREEBUSY" property.
2668 Example: The following is an example of a "VFREEBUSY" calendar
2669 component used to request free or busy time information:
2671 BEGIN:VFREEBUSY
2672 ORGANIZER:MAILTO:jane_doe@example.com
2673 ATTENDEE:MAILTO:john_public@example.com
2674 DTSTART:19971015T050000Z
2675 DTEND:19971016T050000Z
2676 DTSTAMP:19970901T083000Z
2677 END:VFREEBUSY
2679 The following is an example of a "VFREEBUSY" calendar component
2680 used to reply to the request with busy time information:
2682 BEGIN:VFREEBUSY
2683 ORGANIZER:MAILTO:jane_doe@example.com
2684 ATTENDEE:MAILTO:john_public@example.com
2685 DTSTAMP:19970901T100000Z
2687 FREEBUSY:19971015T050000Z/PT8H30M,
2688 19971015T160000Z/PT5H30M,19971015T223000Z/PT6H30M
2689 URL:http://example.com/pub/busy/jpublic-01.ifb
2690 COMMENT:This iCalendar file contains busy time information for
2691 the next three months.
2692 END:VFREEBUSY
2694 The following is an example of a "VFREEBUSY" calendar component
2695 used to publish busy time information.
2697 BEGIN:VFREEBUSY
2698 ORGANIZER:jsmith@example.com
2699 DTSTART:19980313T141711Z
2700 DTEND:19980410T141711Z
2701 FREEBUSY:19980314T233000Z/19980315T003000Z
2702 FREEBUSY:19980316T153000Z/19980316T163000Z
2703 FREEBUSY:19980318T030000Z/19980318T040000Z
2704 URL:http://www.example.com/calendar/busytime/jsmith.ifb
2705 END:VFREEBUSY
2707 3.6.5. Time Zone Component
2709 Component Name: VTIMEZONE
2711 Purpose: Provide a grouping of component properties that defines a
2712 time zone.
2714 Format Definition: A "VTIMEZONE" calendar component is defined by the
2715 following notation:
2717 timezonec = "BEGIN" ":" "VTIMEZONE" CRLF
2719 2*(
2721 ; 'tzid' is required, but MUST NOT occur more
2722 ; than once
2724 tzid /
2726 ; 'last-mod' and 'tzurl' are optional,
2727 but MUST NOT occur more than once
2729 last-mod / tzurl /
2731 ; one of 'standardc' or 'daylightc' MUST occur
2732 ; and each MAY occur more than once.
2734 standardc / daylightc /
2736 ; the following is optional,
2737 ; and MAY occur more than once
2739 x-prop
2741 )
2743 "END" ":" "VTIMEZONE" CRLF
2745 standardc = "BEGIN" ":" "STANDARD" CRLF
2747 tzprop
2749 "END" ":" "STANDARD" CRLF
2751 daylightc = "BEGIN" ":" "DAYLIGHT" CRLF
2752 tzprop
2754 "END" ":" "DAYLIGHT" CRLF
2756 tzprop = 3*(
2758 ; the following are each REQUIRED,
2759 ; but MUST NOT occur more than once
2761 dtstart / tzoffsetto / tzoffsetfrom /
2763 ; the following are optional,
2764 ; and MAY occur more than once
2766 comment / rdate / rrule / tzname / x-prop
2768 )
2770 Description: A time zone is unambiguously defined by the set of time
2771 measurement rules determined by the governing body for a given
2772 geographic area. These rules describe at a minimum the base
2773 offset from UTC for the time zone, often referred to as the
2774 Standard Time offset. Many locations adjust their Standard Time
2775 forward or backward by one hour, in order to accommodate seasonal
2776 changes in number of daylight hours, often referred to as Daylight
2777 Saving Time. Some locations adjust their time by a fraction of an
2778 hour. Standard Time is also known as Winter Time. Daylight
2779 Saving Time is also known as Advanced Time, Summer Time, or Legal
2780 Time in certain countries. The following table shows the changes
2781 in time zone rules in effect for New York City starting from 1967.
2782 Each line represents a description or rule for a particular
2783 observance.
2785 Effective Observance Rule
2787 +-----------+-------------------------+--------+--------------+
2788 | Date | (Date/Time) | Offset | Abbreviation |
2789 +-----------+-------------------------+--------+--------------+
2790 | 1967-* | last Sun in Oct, 02:00 | -0500 | EST |
2791 | 1967-1973 | last Sun in Apr, 02:00 | -0400 | EDT |
2792 | 1974-1974 | Jan 6, 02:00 | -0400 | EDT |
2793 | 1975-1975 | Feb 23, 02:00 | -0400 | EDT |
2794 | 1976-1986 | last Sun in Apr, 02:00 | -0400 | EDT |
2795 | 1987-* | first Sun in Apr, 02:00 | -0400 | EDT |
2796 +-----------+-------------------------+--------+--------------+
2797 Note: The specification of a global time zone registry is not
2798 addressed by this document and is left for future study.
2799 However, implementers may find the Olson time zone database
2800 [TZDB] a useful reference. It is an informal, public-domain
2801 collection of time zone information, which is currently being
2802 maintained by volunteer Internet participants, and is used in
2803 several operating systems. This database contains current and
2804 historical time zone information for a wide variety of
2805 locations around the globe; it provides a time zone identifier
2806 for every unique time zone rule set in actual use since 1970,
2807 with historical data going back to the introduction of standard
2808 time.
2810 Interoperability between two calendaring and scheduling
2811 applications, especially for recurring events, to-dos or journal
2812 entries, is dependent on the ability to capture and convey date
2813 and time information in an unambiguous format. The specification
2814 of current time zone information is integral to this behavior.
2816 If present, the "VTIMEZONE" calendar component defines the set of
2817 Standard Time and Daylight Saving Time observances (or rules) for
2818 a particular time zone for a given interval of time. The
2819 "VTIMEZONE" calendar component cannot be nested within other
2820 calendar components. Multiple "VTIMEZONE" calendar components can
2821 exist in an iCalendar object. In this situation, each "VTIMEZONE"
2822 MUST represent a unique time zone definition. This is necessary
2823 for some classes of events, such as airline flights, that start in
2824 one time zone and end in another.
2826 The "VTIMEZONE" calendar component MUST be present if the
2827 iCalendar object contains an RRULE that generates dates on both
2828 sides of a time zone shift (e.g., both in Standard Time and
2829 Daylight Saving Time) unless the iCalendar object intends to
2830 convey a floating time ( see Section 3.3.12 for proper
2831 interpretation of floating time). It can be present if the
2832 iCalendar object does not contain such a RRULE. In addition, if a
2833 RRULE is present, there MUST be valid time zone information for
2834 all recurrence instances.
2836 The "VTIMEZONE" calendar component MUST include the "TZID"
2837 property and at least one definition of a standard or daylight
2838 component. The standard or daylight component MUST include the
2839 "DTSTART", "TZOFFSETFROM" and "TZOFFSETTO" properties.
2841 An individual "VTIMEZONE" calendar component MUST be specified for
2842 each unique "TZID" parameter value specified in the iCalendar
2843 object.
2845 Each "VTIMEZONE" calendar component consists of a collection of
2846 one or more sub-components that describe the rule for a particular
2847 observance (either a Standard Time or a Daylight Saving Time
2848 observance). The "STANDARD" sub-component consists of a
2849 collection of properties that describe Standard Time. The
2850 "DAYLIGHT" sub-component consists of a collection of properties
2851 that describe Daylight Saving Time. In general this collection of
2852 properties consists of:
2854 * the first onset date-time for the observance
2856 * the last onset date-time for the observance, if a last onset is
2857 known.
2859 * the offset to be applied for the observance
2861 * a rule that describes the day and time when the observance
2862 takes effect
2864 * an optional name for the observance
2866 For a given time zone, there may be multiple unique definitions of
2867 the observances over a period of time. Each observance is
2868 described using either a "STANDARD" or "DAYLIGHT" sub-component.
2869 The collection of these sub-components is used to describe the
2870 time zone for a given period of time. The offset to apply at any
2871 given time is found by locating the observance that has the last
2872 onset date and time before the time in question, and using the
2873 offset value from that observance.
2875 The top-level properties in a "VTIMEZONE" calendar component are:
2877 The mandatory "TZID" property is a text value that uniquely
2878 identifies the VTIMEZONE; and each MAY occur more than once.
2879 calendar component within the scope of an iCalendar object.
2881 The optional "LAST-MODIFIED" property is a UTC value that
2882 specifies the date and time that this time zone definition was
2883 last updated.
2885 The optional "TZURL" property is a url value that points to a
2886 published VTIMEZONE definition. TZURL SHOULD refer to a resource
2887 that is accessible by anyone who might need to interpret the
2888 object. This SHOULD NOT normally be a "file" URL or other URL
2889 that is not widely-accessible.
2891 The collection of properties that are used to define the STANDARD
2892 and DAYLIGHT sub-components include:
2894 The mandatory "DTSTART" property gives the effective onset date
2895 and local time for the time zone sub-component definition.
2896 "DTSTART" in this usage MUST be specified as a local DATE-TIME
2897 value.
2899 The mandatory "TZOFFSETFROM" property gives the UTC offset which
2900 is in use when the onset of this time zone observance begins.
2901 "TZOFFSETFROM" is combined with "DTSTART" to define the effective
2902 onset for the time zone sub-component definition. For example,
2903 the following represents the time at which the observance of
2904 Standard Time took effect in Fall 1967 for New York City:
2906 DTSTART:19671029T020000
2908 TZOFFSETFROM:-0400
2910 The mandatory "TZOFFSETTO " property gives the UTC offset for the
2911 time zone sub-component (Standard Time or Daylight Saving Time)
2912 when this observance is in use.
2914 The optional "TZNAME" property is the customary name for the time
2915 zone. It may be specified multiple times, to allow for specifying
2916 multiple language variants of the time zone names. This could be
2917 used for displaying dates.
2919 If specified, the onset for the observance defined by the time
2920 zone sub-component is defined by either the "RRULE" or "RDATE"
2921 property. If neither is specified, only one sub-component can be
2922 specified in the "VTIMEZONE" calendar component and it is assumed
2923 that the single observance specified is always in effect.
2925 The "RRULE" property defines the recurrence rule for the onset of
2926 the observance defined by this time zone sub-component. Some
2927 specific requirements for the usage of RRULE for this purpose
2928 include:
2930 * If observance is known to have an effective end date, the
2931 "UNTIL" recurrence rule parameter MUST be used to specify the
2932 last valid onset of this observance (i.e., the UNTIL date-time
2933 will be equal to the last instance generated by the recurrence
2934 pattern). It MUST be specified in UTC time.
2936 * The "DTSTART" and the "TZOFFSETTO" properties MUST be used when
2937 generating the onset date-time values (instances) from the
2938 RRULE.
2940 Alternatively, the "RDATE" property can be used to define the
2941 onset of the observance by giving the individual onset date and
2942 times. "RDATE" in this usage MUST be specified as a local DATE-
2943 TIME value in UTC time.
2945 The optional "COMMENT" property is also allowed for descriptive
2946 explanatory text.
2948 Example: The following are examples of the "VTIMEZONE" calendar
2949 component:
2951 This is an example showing time zone information for the Eastern
2952 United States using "RDATE" property. Note that this is only
2953 suitable for a recurring event that starts on or later than April
2954 6, 1997 at 03:00:00 EDT (i.e., the earliest effective transition
2955 date and time) and ends no later than April 7, 1998 02:00:00 EST
2956 (i.e., latest valid date and time for EST in this scenario). For
2957 example, this can be used for a recurring event that occurs every
2958 Friday, 8:00AM-9:00 AM, starting June 1, 1997, ending December 31,
2959 1997.
2961 BEGIN:VTIMEZONE
2962 TZID:US-Eastern
2963 LAST-MODIFIED:19870101T000000Z
2964 BEGIN:STANDARD
2965 DTSTART:19971026T020000
2966 RDATE:19971026T020000
2967 TZOFFSETFROM:-0400
2968 TZOFFSETTO:-0500
2969 TZNAME:EST
2970 END:STANDARD
2971 BEGIN:DAYLIGHT
2972 DTSTART:19970406T020000
2973 RDATE:19970406T020000
2974 TZOFFSETFROM:-0500
2975 TZOFFSETTO:-0400
2976 TZNAME:EDT
2977 END:DAYLIGHT
2978 END:VTIMEZONE
2980 This is a simple example showing the current time zone rules for
2981 the Eastern United States using a RRULE recurrence pattern. Note
2982 that there is no effective end date to either of the Standard Time
2983 or Daylight Time rules. This information would be valid for a
2984 recurring event starting today and continuing indefinitely.
2986 BEGIN:VTIMEZONE
2987 TZID:US-Eastern
2988 LAST-MODIFIED:19870101T000000Z
2989 TZURL:http://zones.example.com/tz/US-Eastern.ics
2990 BEGIN:STANDARD
2991 DTSTART:19671029T020000
2992 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
2993 TZOFFSETFROM:-0400
2994 TZOFFSETTO:-0500
2995 TZNAME:EST
2996 END:STANDARD
2997 BEGIN:DAYLIGHT
2998 DTSTART:19870405T020000
2999 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
3000 TZOFFSETFROM:-0500
3001 TZOFFSETTO:-0400
3002 TZNAME:EDT
3003 END:DAYLIGHT
3004 END:VTIMEZONE
3006 This is an example showing a fictitious set of rules for the
3007 Eastern United States, where the Daylight Time rule has an
3008 effective end date (i.e., after that date, Daylight Time is no
3009 longer observed).
3011 BEGIN:VTIMEZONE
3012 TZID:US--Fictitious-Eastern
3013 LAST-MODIFIED:19870101T000000Z
3014 BEGIN:STANDARD
3015 DTSTART:19671029T020000
3016 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
3017 TZOFFSETFROM:-0400
3018 TZOFFSETTO:-0500
3019 TZNAME:EST
3020 END:STANDARD
3021 BEGIN:DAYLIGHT
3022 DTSTART:19870405T020000
3023 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T070000Z
3024 TZOFFSETFROM:-0500
3025 TZOFFSETTO:-0400
3026 TZNAME:EDT
3027 END:DAYLIGHT
3028 END:VTIMEZONE
3030 This is an example showing a fictitious set of rules for the
3031 Eastern United States, where the first Daylight Time rule has an
3032 effective end date. There is a second Daylight Time rule that
3033 picks up where the other left off.
3035 BEGIN:VTIMEZONE
3036 TZID:US--Fictitious-Eastern
3037 LAST-MODIFIED:19870101T000000Z
3038 BEGIN:STANDARD
3039 DTSTART:19671029T020000
3040 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
3041 TZOFFSETFROM:-0400
3042 TZOFFSETTO:-0500
3043 TZNAME:EST
3044 END:STANDARD
3045 BEGIN:DAYLIGHT
3046 DTSTART:19870405T020000
3047 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T070000Z
3048 TZOFFSETFROM:-0500
3049 TZOFFSETTO:-0400
3050 TZNAME:EDT
3051 END:DAYLIGHT
3052 BEGIN:DAYLIGHT
3053 DTSTART:19990424T020000
3054 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=4
3055 TZOFFSETFROM:-0500
3056 TZOFFSETTO:-0400
3057 TZNAME:EDT
3058 END:DAYLIGHT
3059 END:VTIMEZONE
3061 3.6.6. Alarm Component
3063 Component Name: VALARM
3065 Purpose: Provide a grouping of component properties that define an
3066 alarm.
3068 Format Definition: A "VALARM" calendar component is defined by the
3069 following notation:
3071 alarmc = "BEGIN" ":" "VALARM" CRLF
3072 (audioprop / dispprop / emailprop / procprop)
3073 "END" ":" "VALARM" CRLF
3075 audioprop = 2*(
3076 ; 'action' and 'trigger' are both REQUIRED,
3077 ; but MUST NOT occur more than once
3079 action / trigger /
3081 ; 'duration' and 'repeat' are both optional,
3082 ; and MUST NOT occur more than once each,
3083 ; but if one occurs, so MUST the other
3085 duration / repeat /
3087 ; the following is optional,
3088 ; but MUST NOT occur more than once
3090 attach /
3092 ; the following is optional,
3093 ; and MAY occur more than once
3095 x-prop
3097 )
3099 dispprop = 3*(
3101 ; the following are all REQUIRED,
3102 ; but MUST NOT occur more than once
3104 action / description / trigger /
3106 ; 'duration' and 'repeat' are both optional,
3107 ; and MUST NOT occur more than once each,
3108 ; but if one occurs, so MUST the other
3110 duration / repeat /
3112 ; the following is optional,
3113 ; and MAY occur more than once
3115 x-prop
3117 )
3119 emailprop = 5*(
3121 ; the following are all REQUIRED,
3122 ; but MUST NOT occur more than once
3123 action / description / trigger / summary /
3125 ; the following is REQUIRED,
3126 ; and MAY occur more than once
3128 attendee /
3130 ; 'duration' and 'repeat' are both optional,
3131 ; and MUST NOT occur more than once each,
3132 ; but if one occurs, so MUST the other
3134 duration / repeat /
3136 ; the following are optional,
3137 ; and MAY occur more than once
3139 attach / x-prop
3141 )
3143 procprop = 3*(
3145 ; the following are all REQUIRED,
3146 ; but MUST NOT occur more than once
3148 action / attach / trigger /
3150 ; 'duration' and 'repeat' are both optional,
3151 ; and MUST NOT occur more than once each,
3152 ; but if one occurs, so MUST the other
3154 duration / repeat /
3156 ; 'description' is optional,
3157 ; and MUST NOT occur more than once
3159 description /
3161 ; the following is optional,
3162 ; and MAY occur more than once
3164 x-prop
3166 )
3168 Description: A "VALARM" calendar component is a grouping of component
3169 properties that is a reminder or alarm for an event or a to-do.
3170 For example, it may be used to define a reminder for a pending
3171 event or an overdue to-do.
3173 The "VALARM" calendar component MUST include the "ACTION" and
3174 "TRIGGER" properties. The "ACTION" property further constrains
3175 the "VALARM" calendar component in the following ways:
3177 When the action is "AUDIO", the alarm can also include one and
3178 only one "ATTACH" property, which MUST point to a sound resource,
3179 which is rendered when the alarm is triggered.
3181 When the action is "DISPLAY", the alarm MUST also include a
3182 "DESCRIPTION" property, which contains the text to be displayed
3183 when the alarm is triggered.
3185 When the action is "EMAIL", the alarm MUST include a "DESCRIPTION"
3186 property, which contains the text to be used as the message body,
3187 a "SUMMARY" property, which contains the text to be used as the
3188 message subject, and one or more "ATTENDEE" properties, which
3189 contain the email address of attendees to receive the message. It
3190 can also include one or more "ATTACH" properties, which are
3191 intended to be sent as message attachments. When the alarm is
3192 triggered, the email message is sent.
3194 When the action is "PROCEDURE", the alarm MUST include one and
3195 only one "ATTACH" property, which MUST point to a procedure
3196 resource, which is invoked when the alarm is triggered.
3198 The "VALARM" calendar component MUST only appear within either a
3199 "VEVENT" or "VTODO" calendar component. "VALARM" calendar
3200 components cannot be nested. Multiple mutually independent
3201 "VALARM" calendar components can be specified for a single
3202 "VEVENT" or "VTODO" calendar component.
3204 The "TRIGGER" property specifies when the alarm will be triggered.
3205 The "TRIGGER" property specifies a duration prior to the start of
3206 an event or a to-do. The "TRIGGER" edge may be explicitly set to
3207 be relative to the "START" or "END" of the event or to-do with the
3208 "RELATED" parameter of the "TRIGGER" property. The "TRIGGER"
3209 property value type can alternatively be set to an absolute
3210 calendar date and time of day value.
3212 In an alarm set to trigger on the "START" of an event or to-do,
3213 the "DTSTART" property MUST be present in the associated event or
3214 to-do. In an alarm in a "VEVENT" calendar component set to
3215 trigger on the "END" of the event, either the "DTEND" property
3216 MUST be present, or the "DTSTART" and "DURATION" properties MUST
3217 both be present. In an alarm in a "VTODO" calendar component set
3218 to trigger on the "END" of the to-do, either the "DUE" property
3219 MUST be present, or the "DTSTART" and "DURATION" properties MUST
3220 both be present.
3222 The alarm can be defined such that it triggers repeatedly. A
3223 definition of an alarm with a repeating trigger MUST include both
3224 the "DURATION" and "REPEAT" properties. The "DURATION" property
3225 specifies the delay period, after which the alarm will repeat.
3226 The "REPEAT" property specifies the number of additional
3227 repetitions that the alarm will be triggered. This repetition
3228 count is in addition to the initial triggering of the alarm. Both
3229 of these properties MUST be present in order to specify a
3230 repeating alarm. If one of these two properties is absent, then
3231 the alarm will not repeat beyond the initial trigger.
3233 The "ACTION" property is used within the "VALARM" calendar
3234 component to specify the type of action invoked when the alarm is
3235 triggered. The "VALARM" properties provide enough information for
3236 a specific action to be invoked. It is typically the
3237 responsibility of a "Calendar User Agent" (CUA) to deliver the
3238 alarm in the specified fashion. An "ACTION" property value of
3239 AUDIO specifies an alarm that causes a sound to be played to alert
3240 the user; DISPLAY specifies an alarm that causes a text message to
3241 be displayed to the user; EMAIL specifies an alarm that causes an
3242 electronic email message to be delivered to one or more email
3243 addresses; and PROCEDURE specifies an alarm that causes a
3244 procedure to be executed. The "ACTION" property MUST specify one
3245 and only one of these values.
3247 In an AUDIO alarm, if the optional "ATTACH" property is included,
3248 it MUST specify an audio sound resource. The intention is that
3249 the sound will be played as the alarm effect. If an "ATTACH"
3250 property is specified that does not refer to a sound resource, or
3251 if the specified sound resource cannot be rendered (because its
3252 format is unsupported, or because it cannot be retrieved), then
3253 the CUA or other entity responsible for playing the sound may
3254 choose a fallback action, such as playing a built-in default
3255 sound, or playing no sound at all.
3257 In a DISPLAY alarm, the intended alarm effect is for the text
3258 value of the "DESCRIPTION" property to be displayed to the user.
3260 In an EMAIL alarm, the intended alarm effect is for an email
3261 message to be composed and delivered to all the addresses
3262 specified by the "ATTENDEE" properties in the "VALARM" calendar
3263 component. The "DESCRIPTION" property of the "VALARM" calendar
3264 component MUST be used as the body text of the message, and the
3265 "SUMMARY" property MUST be used as the subject text. Any "ATTACH"
3266 properties in the "VALARM" calendar component SHOULD be sent as
3267 attachments to the message.
3269 In a PROCEDURE alarm, the "ATTACH" property in the "VALARM"
3270 calendar component MUST specify a procedure or program that is
3271 intended to be invoked as the alarm effect. If the procedure or
3272 program is in a format that cannot be rendered, then no procedure
3273 alarm will be invoked. If the "DESCRIPTION" property is present,
3274 its value specifies the argument string to be passed to the
3275 procedure or program. "Calendar User Agents" that receive an
3276 iCalendar object with this category of alarm, can disable or allow
3277 the "Calendar User" to disable, or otherwise ignore this type of
3278 alarm. While a very useful alarm capability, the PROCEDURE type
3279 of alarm SHOULD be treated by the "Calendar User Agent" as a
3280 potential security risk.
3282 Example: The following example is for a "VALARM" calendar component
3283 that specifies an audio alarm that will sound at a precise time
3284 and repeat 4 more times at 15 minute intervals:
3286 BEGIN:VALARM
3287 TRIGGER;VALUE=DATE-TIME:19970317T133000Z
3288 REPEAT:4
3289 DURATION:PT15M
3290 ACTION:AUDIO
3291 ATTACH;FMTTYPE=audio/basic:ftp://example.com/pub/
3292 sounds/bell-01.aud
3293 END:VALARM
3295 The following example is for a "VALARM" calendar component that
3296 specifies a display alarm that will trigger 30 minutes before the
3297 scheduled start of the event or the due date/time of the to-do it
3298 is associated with and will repeat 2 more times at 15 minute
3299 intervals:
3301 BEGIN:VALARM
3302 TRIGGER:-PT30M
3303 REPEAT:2
3304 DURATION:PT15M
3305 ACTION:DISPLAY
3306 DESCRIPTION:Breakfast meeting with executive\n
3307 team at 8:30 AM EST.
3308 END:VALARM
3310 The following example is for a "VALARM" calendar component that
3311 specifies an email alarm that will trigger 2 days before the
3312 scheduled due date/time of a to-do it is associated with. It does
3313 not repeat. The email has a subject, body and attachment link.
3315 BEGIN:VALARM
3316 TRIGGER:-P2D
3317 ACTION:EMAIL
3318 ATTENDEE:MAILTO:john_doe@example.com
3319 SUMMARY:*** REMINDER: SEND AGENDA FOR WEEKLY STAFF MEETING ***
3320 DESCRIPTION:A draft agenda needs to be sent out to the attendees
3321 to the weekly managers meeting (MGR-LIST). Attached is a
3322 pointer the document template for the agenda file.
3323 ATTACH;FMTTYPE=application/msword:http://example.com/
3324 templates/agenda.doc
3325 END:VALARM
3327 The following example is for a "VALARM" calendar component that
3328 specifies a procedural alarm that will trigger at a precise date/
3329 time and will repeat 23 more times at one hour intervals. The
3330 alarm will invoke a procedure file.
3332 BEGIN:VALARM
3333 TRIGGER;VALUE=DATE-TIME:19980101T050000Z
3334 REPEAT:23
3335 DURATION:PT1H
3336 ACTION:PROCEDURE
3337 ATTACH;FMTTYPE=application/octet-stream:ftp://example.com/novo-
3338 procs/felizano.exe
3339 END:VALARM
3341 3.7. Calendar Properties
3343 The Calendar Properties are attributes that apply to the iCalendar
3344 object, as a whole. These properties do not appear within a calendar
3345 component. They SHOULD be specified after the "BEGIN:VCALENDAR"
3346 delimiter string and prior to any calendar component.
3348 3.7.1. Calendar Scale
3350 Property Name: CALSCALE
3352 Purpose: This property defines the calendar scale used for the
3353 calendar information specified in the iCalendar object.
3355 Value Type: TEXT
3357 Property Parameters: Non-standard property parameters can be
3358 specified on this property.
3360 Conformance: Property can be specified in an iCalendar object. The
3361 default value is "GREGORIAN".
3363 Description: This memo is based on the Gregorian calendar scale. The
3364 Gregorian calendar scale is assumed if this property is not
3365 specified in the iCalendar object. It is expected that other
3366 calendar scales will be defined in other specifications or by
3367 future versions of this memo.
3369 Format Definition: The property is defined by the following notation:
3371 calscale = "CALSCALE" calparam ":" calvalue CRLF
3373 calparam = *(";" xparam)
3375 calvalue = "GREGORIAN" / iana-token
3377 Example: The following is an example of this property:
3379 CALSCALE:GREGORIAN
3381 3.7.2. Method
3383 Property Name: METHOD
3385 Purpose: This property defines the iCalendar object method associated
3386 with the calendar object.
3388 Value Type: TEXT
3390 Property Parameters: Non-standard property parameters can be
3391 specified on this property.
3393 Conformance: The property can be specified in an iCalendar object.
3395 Description: When used in a MIME message entity, the value of this
3396 property MUST be the same as the Content-Type "method" parameter
3397 value. This property can only appear once within the iCalendar
3398 object. If either the "METHOD" property or the Content-Type
3399 "method" parameter is specified, then the other MUST also be
3400 specified.
3402 No methods are defined by this specification. This is the subject
3403 of other specifications, such as the iCalendar Transport-
3404 independent Interoperability Protocol (iTIP) defined by [I-D.ietf-
3405 calsify-2446bis].
3407 If this property is not present in the iCalendar object, then a
3408 scheduling transaction MUST NOT be assumed. In such cases, the
3409 iCalendar object is merely being used to transport a snapshot of
3410 some calendar information; without the intention of conveying a
3411 scheduling semantic.
3413 Format Definition: The property is defined by the following notation:
3415 method = "METHOD" metparam ":" metvalue CRLF
3417 metparam = *(";" xparam)
3419 metvalue = iana-token
3421 Example: The following is a hypothetical example of this property to
3422 convey that the iCalendar object is a request for a meeting:
3424 METHOD:REQUEST
3426 3.7.3. Product Identifier
3428 Property Name: PRODID
3430 Purpose: This property specifies the identifier for the product that
3431 created the iCalendar object.
3433 Value Type: TEXT
3435 Property Parameters: Non-standard property parameters can be
3436 specified on this property.
3438 Conformance: The property MUST be specified once in an iCalendar
3439 object.
3441 Description: The vendor of the implementation SHOULD assure that this
3442 is a globally unique identifier; using some technique such as an
3443 FPI value, as defined in [ISO.9070.1991].
3445 This property SHOULD not be used to alter the interpretation of an
3446 iCalendar object beyond the semantics specified in this memo. For
3447 example, it is not to be used to further the understanding of non-
3448 standard properties.
3450 Format Definition: The property is defined by the following notation:
3452 prodid = "PRODID" pidparam ":" pidvalue CRLF
3454 pidparam = *(";" xparam)
3456 pidvalue = text
3457 ;Any text that describes the product and version
3458 ;and that is generally assured of being unique.
3460 Example: The following is an example of this property. It does not
3461 imply that English is the default language.
3463 PRODID:-//ABC Corporation//NONSGML My Product//EN
3465 3.7.4. Version
3467 Property Name: VERSION
3469 Purpose: This property specifies the identifier corresponding to the
3470 highest version number or the minimum and maximum range of the
3471 iCalendar specification that is required in order to interpret the
3472 iCalendar object.
3474 Value Type: TEXT
3476 Property Parameters: Non-standard property parameters can be
3477 specified on this property.
3479 Conformance: This property MUST be specified by an iCalendar object,
3480 but MUST only be specified once.
3482 Description: A value of "2.0" corresponds to this memo.
3484 Format Definition: The property is defined by the following notation:
3486 version = "VERSION" verparam ":" vervalue CRLF
3488 verparam = *(";" xparam)
3490 vervalue = "2.0" ;This memo
3491 / maxver
3492 / (minver ";" maxver)
3494 minver =
3495 ;Minimum iCalendar version needed to parse the iCalendar object
3497 maxver =
3498 ;Maximum iCalendar version needed to parse the iCalendar object
3500 Example: The following is an example of this property:
3502 VERSION:2.0
3504 3.8. Component Properties
3506 The following properties can appear within calendar components, as
3507 specified by each component property definition.
3509 3.8.1. Descriptive Component Properties
3511 The following properties specify descriptive information about
3512 calendar components.
3514 3.8.1.1. Attachment
3516 Property Name: ATTACH
3518 Purpose: The property provides the capability to associate a document
3519 object with a calendar component.
3521 Value Type: The default value type for this property is URI. The
3522 value type can also be set to BINARY to indicate inline binary
3523 encoded content information.
3525 Property Parameters: Non-standard, inline encoding, format type and
3526 value data type property parameters can be specified on this
3527 property.
3529 Conformance: The property can be specified in a "VEVENT", "VTODO",
3530 "VJOURNAL" or "VALARM" calendar components.
3532 Description: The property can be specified within "VEVENT", "VTODO",
3533 "VJOURNAL", or "VALARM" calendar components. This property can be
3534 specified multiple times within an iCalendar object.
3536 Format Definition: The property is defined by the following notation:
3538 attach = "ATTACH" attparam ":" uri CRLF
3540 attach =/ "ATTACH" attparam ";" "ENCODING" "=" "BASE64"
3541 ";" "VALUE" "=" "BINARY" ":" binary
3543 attparam = *(
3545 ; the following is optional,
3546 ; but MUST NOT occur more than once
3548 (";" fmttypeparam) /
3550 ; the following is optional,
3551 ; and MAY occur more than once
3553 (";" xparam)
3555 )
3557 Example: The following are examples of this property:
3559 ATTACH:CID:jsmith.part3.960817T083000.xyzMail@example.com
3561 ATTACH;FMTTYPE=application/postscript:ftp://example.com/pub/
3562 reports/r-960812.ps
3564 3.8.1.2. Categories
3566 Property Name: CATEGORIES
3568 Purpose: This property defines the categories for a calendar
3569 component.
3571 Value Type: TEXT
3573 Property Parameters: Non-standard and language property parameters
3574 can be specified on this property.
3576 Conformance: The property can be specified within "VEVENT", "VTODO"
3577 or "VJOURNAL" calendar components.
3579 Description: This property is used to specify categories or subtypes
3580 of the calendar component. The categories are useful in searching
3581 for a calendar component of a particular type and category.
3582 Within the "VEVENT", "VTODO" or "VJOURNAL" calendar components,
3583 more than one category can be specified as a list of categories
3584 separated by the COMMA character (US-ASCII decimal 44).
3586 Format Definition: The property is defined by the following notation:
3588 categories = "CATEGORIES" catparam ":" text *("," text)
3589 CRLF
3591 catparam = *(
3593 ; the following is optional,
3594 ; but MUST NOT occur more than once
3596 (";" languageparam ) /
3598 ; the following is optional,
3599 ; and MAY occur more than once
3601 (";" xparam)
3603 )
3605 Example: The following are examples of this property:
3607 CATEGORIES:APPOINTMENT,EDUCATION
3609 CATEGORIES:MEETING
3611 3.8.1.3. Classification
3613 Property Name: CLASS
3615 Purpose: This property defines the access classification for a
3616 calendar component.
3618 Value Type: TEXT
3620 Property Parameters: Non-standard property parameters can be
3621 specified on this property.
3623 Conformance: The property can be specified once in a "VEVENT",
3624 "VTODO" or "VJOURNAL" calendar components.
3626 Description: An access classification is only one component of the
3627 general security system within a calendar application. It
3628 provides a method of capturing the scope of the access the
3629 calendar owner intends for information within an individual
3630 calendar entry. The access classification of an individual
3631 iCalendar component is useful when measured along with the other
3632 security components of a calendar system (e.g., calendar user
3633 authentication, authorization, access rights, access role, etc.).
3635 Hence, the semantics of the individual access classifications
3636 cannot be completely defined by this memo alone. Additionally,
3637 due to the "blind" nature of most exchange processes using this
3638 memo, these access classifications cannot serve as an enforcement
3639 statement for a system receiving an iCalendar object. Rather,
3640 they provide a method for capturing the intention of the calendar
3641 owner for the access to the calendar component.
3643 Format Definition: The property is defined by the following notation:
3645 class = "CLASS" classparam ":" classvalue CRLF
3647 classparam = *(";" xparam)
3649 classvalue = "PUBLIC" / "PRIVATE" / "CONFIDENTIAL" / iana-token
3650 / x-name
3651 ;Default is PUBLIC
3653 Example: The following is an example of this property:
3655 CLASS:PUBLIC
3657 3.8.1.4. Comment
3659 Property Name: COMMENT
3661 Purpose: This property specifies non-processing information intended
3662 to provide a comment to the calendar user.
3664 Value Type: TEXT
3666 Property Parameters: Non-standard, alternate text representation and
3667 language property parameters can be specified on this property.
3669 Conformance: This property can be specified in "VEVENT", "VTODO",
3670 "VJOURNAL", "VTIMEZONE" or "VFREEBUSY" calendar components.
3672 Description: The property can be specified multiple times.
3674 Format Definition: The property is defined by the following notation:
3676 comment = "COMMENT" commparam ":" text CRLF
3678 commparam = *(
3680 ; the following are optional,
3681 ; but MUST NOT occur more than once
3683 (";" altrepparam) / (";" languageparam) /
3685 ; the following is optional,
3686 ; and MAY occur more than once
3688 (";" xparam)
3690 )
3692 Example: The following is an example of this property:
3694 COMMENT:The meeting really needs to include both ourselves
3695 and the customer. We can't hold this meeting without them.
3696 As a matter of fact\, the venue for the meeting ought to be at
3697 their site. - - John
3699 3.8.1.5. Description
3701 Property Name: DESCRIPTION
3703 Purpose: This property provides a more complete description of the
3704 calendar component, than that provided by the "SUMMARY" property.
3706 Value Type: TEXT
3708 Property Parameters: Non-standard, alternate text representation and
3709 language property parameters can be specified on this property.
3711 Conformance: The property can be specified in the "VEVENT", "VTODO",
3712 "VJOURNAL" or "VALARM" calendar components. The property can be
3713 specified multiple times only within a "VJOURNAL" calendar
3714 component.
3716 Description: This property is used in the "VEVENT" and "VTODO" to
3717 capture lengthy textual decriptions associated with the activity.
3719 This property is used in the "VJOURNAL" calendar component to
3720 capture one more textual journal entries.
3722 This property is used in the "VALARM" calendar component to
3723 capture the display text for a DISPLAY category of alarm, to
3724 capture the body text for an EMAIL category of alarm and to
3725 capture the argument string for a PROCEDURE category of alarm.
3727 Format Definition: The property is defined by the following notation:
3729 description = "DESCRIPTION" descparam ":" text CRLF
3731 descparam = *(
3733 ; the following are optional,
3734 ; but MUST NOT occur more than once
3736 (";" altrepparam) / (";" languageparam) /
3738 ; the following is optional,
3739 ; and MAY occur more than once
3741 (";" xparam)
3743 )
3745 Example: The following is an example of the property with formatted
3746 line breaks in the property value:
3748 DESCRIPTION:Meeting to provide technical review for "Phoenix"
3749 design.\nHappy Face Conference Room. Phoenix design team
3750 MUST attend this meeting.\nRSVP to team leader.
3752 The following is an example of the property with folding of long
3753 lines:
3755 DESCRIPTION:Last draft of the new novel is to be completed
3756 for the editor's proof today.
3758 3.8.1.6. Geographic Position
3760 Property Name: GEO
3762 Purpose: This property specifies information related to the global
3763 position for the activity specified by a calendar component.
3765 Value Type: FLOAT. The value MUST be two SEMICOLON separated FLOAT
3766 values.
3768 Property Parameters: Non-standard property parameters can be
3769 specified on this property.
3771 Conformance: This property can be specified in "VEVENT" or "VTODO"
3772 calendar components.
3774 Description: The property value specifies latitude and longitude, in
3775 that order (i.e., "LAT LON" ordering). The longitude represents
3776 the location east or west of the prime meridian as a positive or
3777 negative real number, respectively. The longitude and latitude
3778 values MAY be specified up to six decimal places, which will allow
3779 for accuracy to within one meter of geographical position.
3780 Receiving applications MUST accept values of this precision and
3781 MAY truncate values of greater precision.
3783 Values for latitude and longitude shall be expressed as decimal
3784 fractions of degrees. Whole degrees of latitude shall be
3785 represented by a two-digit decimal number ranging from 0 through
3786 90. Whole degrees of longitude shall be represented by a decimal
3787 number ranging from 0 through 180. When a decimal fraction of a
3788 degree is specified, it shall be separated from the whole number
3789 of degrees by a decimal point.
3791 Latitudes north of the equator shall be specified by a plus sign
3792 (+), or by the absence of a minus sign (-), preceding the digits
3793 designating degrees. Latitudes south of the Equator shall be
3794 designated by a minus sign (-) preceding the digits designating
3795 degrees. A point on the Equator shall be assigned to the Northern
3796 Hemisphere.
3798 Longitudes east of the prime meridian shall be specified by a plus
3799 sign (+), or by the absence of a minus sign (-), preceding the
3800 digits designating degrees. Longitudes west of the meridian shall
3801 be designated by minus sign (-) preceding the digits designating
3802 degrees. A point on the prime meridian shall be assigned to the
3803 Eastern Hemisphere. A point on the 180th meridian shall be
3804 assigned to the Western Hemisphere. One exception to this last
3805 convention is permitted. For the special condition of describing
3806 a band of latitude around the earth, the East Bounding Coordinate
3807 data element shall be assigned the value +180 (180) degrees.
3809 Any spatial address with a latitude of +90 (90) or -90 degrees
3810 will specify the position at the North or South Pole,
3811 respectively. The component for longitude may have any legal
3812 value.
3814 With the exception of the special condition described above, this
3815 form is specified in Department of Commerce, 1986, Representation
3816 of geographic point locations for information interchange (Federal
3817 Information Processing Standard 70-1): Washington, Department of
3818 Commerce, National Institute of Standards and Technology.
3820 The simple formula for converting degrees-minutes-seconds into
3821 decimal degrees is:
3823 decimal = degrees + minutes/60 + seconds/3600.
3825 Format Definition: The property is defined by the following notation:
3827 geo = "GEO" geoparam ":" geovalue CRLF
3829 geoparam = *(";" xparam)
3831 geovalue = float ";" float
3832 ;Latitude and Longitude components
3834 Example: The following is an example of this property:
3836 GEO:37.386013;-122.082932
3838 3.8.1.7. Location
3840 Property Name: LOCATION
3842 Purpose: The property defines the intended venue for the activity
3843 defined by a calendar component.
3845 Value Type: TEXT
3847 Property Parameters: Non-standard, alternate text representation and
3848 language property parameters can be specified on this property.
3850 Conformance: This property can be specified in "VEVENT" or "VTODO"
3851 calendar component.
3853 Description: Specific venues such as conference or meeting rooms may
3854 be explicitly specified using this property. An alternate
3855 representation may be specified that is a URI that points to
3856 directory information with more structured specification of the
3857 location. For example, the alternate representation may specify
3858 either an LDAP URI pointing to an LDAP server entry or a CID URI
3859 pointing to a MIME body part containing a vCard [RFC2426] for the
3860 location.
3862 Format Definition: The property is defined by the following notation:
3864 location = "LOCATION locparam ":" text CRLF
3866 locparam = *(
3868 ; the following are optional,
3869 ; but MUST NOT occur more than once
3871 (";" altrepparam) / (";" languageparam) /
3873 ; the following is optional,
3874 ; and MAY occur more than once
3876 (";" xparam)
3878 )
3880 Example: The following are some examples of this property:
3882 LOCATION:Conference Room - F123\, Bldg. 002
3884 LOCATION;ALTREP="http://xyzcorp.com/conf-rooms/f123.vcf":
3885 Conference Room - F123\, Bldg. 002
3887 3.8.1.8. Percent Complete
3889 Property Name: PERCENT-COMPLETE
3891 Purpose: This property is used by an assignee or delegatee of a to-do
3892 to convey the percent completion of a to-do to the Organizer.
3894 Value Type: INTEGER
3896 Property Parameters: Non-standard property parameters can be
3897 specified on this property.
3899 Conformance: This property can be specified in a "VTODO" calendar
3900 component.
3902 Description: The property value is a positive integer between zero
3903 and one hundred. A value of "0" indicates the to-do has not yet
3904 been started. A value of "100" indicates that the to-do has been
3905 completed. Integer values in between indicate the percent
3906 partially complete.
3908 When a to-do is assigned to multiple individuals, the property
3909 value indicates the percent complete for that portion of the to-do
3910 assigned to the assignee or delegatee. For example, if a to-do is
3911 assigned to both individuals "A" and "B". A reply from "A" with a
3912 percent complete of "70" indicates that "A" has completed 70% of
3913 the to-do assigned to them. A reply from "B" with a percent
3914 complete of "50" indicates "B" has completed 50% of the to-do
3915 assigned to them.
3917 Format Definition: The property is defined by the following notation:
3919 percent = "PERCENT-COMPLETE" pctparam ":" integer CRLF
3921 pctparam = *(";" xparam)
3923 Example: The following is an example of this property to show 39%
3924 completion:
3926 PERCENT-COMPLETE:39
3928 3.8.1.9. Priority
3930 Property Name: PRIORITY
3932 Purpose: The property defines the relative priority for a calendar
3933 component.
3935 Value Type: INTEGER
3937 Property Parameters: Non-standard property parameters can be
3938 specified on this property.
3940 Conformance: The property can be specified in a "VEVENT" or "VTODO"
3941 calendar component.
3943 Description: The priority is specified as an integer in the range
3944 zero to nine. A value of zero (US-ASCII decimal 48) specifies an
3945 undefined priority. A value of one (US-ASCII decimal 49) is the
3946 highest priority. A value of two (US-ASCII decimal 50) is the
3947 second highest priority. Subsequent numbers specify a decreasing
3948 ordinal priority. A value of nine (US-ASCII decimal 57 ) is the
3949 lowest priority.
3951 A CUA with a three-level priority scheme of "HIGH", "MEDIUM" and
3952 "LOW" is mapped into this property such that a property value in
3953 the range of one (US-ASCII decimal 49) to four (US-ASCII decimal
3954 52) specifies "HIGH" priority. A value of five (US-ASCII decimal
3955 53) is the normal or "MEDIUM" priority. A value in the range of
3956 six (US-ASCII decimal 54) to nine (US-ASCII decimal 57 ) is "LOW"
3957 priority.
3959 A CUA with a priority schema of "A1", "A2", "A3", "B1", "B2", ...,
3960 "C3" is mapped into this property such that a property value of
3961 one (US-ASCII decimal 49) specifies "A1", a property value of two
3962 (US-ASCII decimal 50) specifies "A2", a property value of three
3963 (US-ASCII decimal 51) specifies "A3", and so forth up to a
3964 property value of 9 (US-ASCII decimal 57 ) specifies "C3".
3966 Other integer values are reserved for future use.
3968 Within a "VEVENT" calendar component, this property specifies a
3969 priority for the event. This property may be useful when more
3970 than one event is scheduled for a given time period.
3972 Within a "VTODO" calendar component, this property specified a
3973 priority for the to-do. This property is useful in prioritizing
3974 multiple action items for a given time period.
3976 Format Definition: The property is defined by the following notation:
3978 priority = "PRIORITY" prioparam ":" privalue CRLF
3979 ;Default is zero
3981 prioparam = *(";" xparam)
3983 privalue = integer ;Must be in the range [0..9]
3984 ; All other values are reserved for future use
3986 Example: The following is an example of a property with the highest
3987 priority:
3989 PRIORITY:1
3991 The following is an example of a property with a next highest
3992 priority:
3994 PRIORITY:2
3996 The following is an example of a property with no priority. This
3997 is equivalent to not specifying the "PRIORITY" property:
3999 PRIORITY:0
4001 3.8.1.10. Resources
4003 Property Name: RESOURCES
4005 Purpose: This property defines the equipment or resources anticipated
4006 for an activity specified by a calendar entity..
4008 Value Type: TEXT
4010 Property Parameters: Non-standard, alternate text representation and
4011 language property parameters can be specified on this property.
4013 Conformance: This property can be specified in "VEVENT" or "VTODO"
4014 calendar component.
4016 Description: The property value is an arbitrary text. More than one
4017 resource can be specified as a list of resources separated by the
4018 COMMA character (US-ASCII decimal 44).
4020 Format Definition: The property is defined by the following notation:
4022 resources = "RESOURCES" resrcparam ":" text *("," text) CRLF
4024 resrcparam = *(
4026 ; the following are optional,
4027 ; but MUST NOT occur more than once
4029 (";" altrepparam) / (";" languageparam) /
4031 ; the following is optional,
4032 ; and MAY occur more than once
4034 (";" xparam)
4036 )
4038 Example: The following is an example of this property:
4040 RESOURCES:EASEL,PROJECTOR,VCR
4042 RESOURCES;LANGUAGE=fr:1 raton-laveur
4044 3.8.1.11. Status
4045 Property Name: STATUS
4047 Purpose: This property defines the overall status or confirmation for
4048 the calendar component.
4050 Value Type: TEXT
4052 Property Parameters: Non-standard property parameters can be
4053 specified on this property.
4055 Conformance: This property can be specified in "VEVENT", "VTODO" or
4056 "VJOURNAL" calendar components.
4058 Description: In a group scheduled calendar component, the property is
4059 used by the "Organizer" to provide a confirmation of the event to
4060 the "Attendees". For example in a "VEVENT" calendar component,
4061 the "Organizer" can indicate that a meeting is tentative,
4062 confirmed or cancelled. In a "VTODO" calendar component, the
4063 "Organizer" can indicate that an action item needs action, is
4064 completed, is in process or being worked on, or has been
4065 cancelled. In a "VJOURNAL" calendar component, the "Organizer"
4066 can indicate that a journal entry is draft, final or has been
4067 cancelled or removed.
4069 Format Definition: The property is defined by the following notation:
4071 status = "STATUS" statparam":" statvalue CRLF
4073 statparam = *(";" xparam)
4075 statvalue = "TENTATIVE" ;Indicates event is
4076 ;tentative.
4077 / "CONFIRMED" ;Indicates event is
4078 ;definite.
4079 / "CANCELLED" ;Indicates event was
4080 ;cancelled.
4081 ;Status values for a "VEVENT"
4083 statvalue = "NEEDS-ACTION" ;Indicates to-do needs action.
4084 / "COMPLETED" ;Indicates to-do completed.
4085 / "IN-PROCESS" ;Indicates to-do in process.
4086 / "CANCELLED" ;Indicates to-do was cancelled.
4087 ;Status values for "VTODO".
4089 statvalue = "DRAFT" ;Indicates journal is draft.
4090 / "FINAL" ;Indicates journal is final.
4091 / "CANCELLED" ;Indicates journal is removed.
4092 ;Status values for "VJOURNAL".
4094 Example: The following is an example of this property for a "VEVENT"
4095 calendar component:
4097 STATUS:TENTATIVE
4099 The following is an example of this property for a "VTODO"
4100 calendar component:
4102 STATUS:NEEDS-ACTION
4104 The following is an example of this property for a "VJOURNAL"
4105 calendar component:
4107 STATUS:DRAFT
4109 3.8.1.12. Summary
4111 Property Name: SUMMARY
4113 Purpose: This property defines a short summary or subject for the
4114 calendar component.
4116 Value Type: TEXT
4118 Property Parameters: Non-standard, alternate text representation and
4119 language property parameters can be specified on this property.
4121 Conformance: The property can be specified in "VEVENT", "VTODO",
4122 "VJOURNAL" or "VALARM" calendar components.
4124 Description: This property is used in the "VEVENT", "VTODO" and
4125 "VJOURNAL" calendar components to capture a short, one line
4126 summary about the activity or journal entry.
4128 This property is used in the "VALARM" calendar component to
4129 capture the subject of an EMAIL category of alarm.
4131 Format Definition: The property is defined by the following notation:
4133 summary = "SUMMARY" summparam ":" text CRLF
4135 summparam = *(
4137 ; the following are optional,
4138 ; but MUST NOT occur more than once
4140 (";" altrepparam) / (";" languageparam) /
4142 ; the following is optional,
4143 ; and MAY occur more than once
4145 (";" xparam)
4147 )
4149 Example: The following is an example of this property:
4151 SUMMARY:Department Party
4153 3.8.2. Date and Time Component Properties
4155 The following properties specify date and time related information in
4156 calendar components.
4158 3.8.2.1. Date/Time Completed
4160 Property Name: COMPLETED
4162 Purpose: This property defines the date and time that a to-do was
4163 actually completed.
4165 Value Type: DATE-TIME
4167 Property Parameters: Non-standard property parameters can be
4168 specified on this property.
4170 Conformance: The property can be specified in a "VTODO" calendar
4171 component.
4173 Description: The date and time MUST be in a UTC format.
4175 Format Definition: The property is defined by the following notation:
4177 completed = "COMPLETED" compparam ":" date-time CRLF
4179 compparam = *(";" xparam)
4181 Example: The following is an example of this property:
4183 COMPLETED:19960401T235959Z
4185 3.8.2.2. Date/Time End
4187 Property Name: DTEND
4189 Purpose: This property specifies the date and time that a calendar
4190 component ends.
4192 Value Type: The default value type is DATE-TIME. The value type can
4193 be set to a DATE value type.
4195 Property Parameters: Non-standard, value data type, time zone
4196 identifier property parameters can be specified on this property.
4198 Conformance: This property can be specified in "VEVENT" or
4199 "VFREEBUSY" calendar components.
4201 Description: Within the "VEVENT" calendar component, this property
4202 defines the date and time by which the event ends. The value MUST
4203 be later in time than the value of the "DTSTART" property.
4205 Within the "VFREEBUSY" calendar component, this property defines
4206 the end date and time for the free or busy time information. The
4207 time MUST be specified in the UTC time format. The value MUST be
4208 later in time than the value of the "DTSTART" property.
4210 Format Definition: The property is defined by the following notation:
4212 dtend = "DTEND" dtendparam ":" dtendval CRLF
4214 dtendparam = *(
4216 ; the following are optional,
4217 ; but MUST NOT occur more than once
4219 (";" "VALUE" "=" ("DATE-TIME" / "DATE")) /
4220 (";" tzidparam) /
4222 ; the following is optional,
4223 ; and MAY occur more than once
4225 (";" xparam)
4227 )
4229 dtendval = date-time / date
4230 ;Value MUST match value type
4232 Example: The following is an example of this property:
4234 DTEND:19960401T235959Z
4236 DTEND;VALUE=DATE:19980704
4238 3.8.2.3. Date/Time Due
4240 Property Name: DUE
4242 Purpose: This property defines the date and time that a to-do is
4243 expected to be completed.
4245 Value Type: The default value type is DATE-TIME. The value type can
4246 be set to a DATE value type.
4248 Property Parameters: Non-standard, value data type, time zone
4249 identifier property parameters can be specified on this property.
4251 Conformance: The property can be specified once in a "VTODO" calendar
4252 component.
4254 Description: The value MUST be a date/time equal to or after the
4255 DTSTART value, if specified.
4257 Format Definition: The property is defined by the following notation:
4259 due = "DUE" dueparam ":" dueval CRLF
4261 dueparam = *(
4262 ; the following are optional,
4263 ; but MUST NOT occur more than once
4265 (";" "VALUE" "=" ("DATE-TIME" / "DATE")) /
4266 (";" tzidparam) /
4268 ; the following is optional,
4269 ; and MAY occur more than once
4271 *(";" xparam)
4273 )
4275 dueval = date-time / date
4276 ;Value MUST match value type
4278 Example: The following is an example of this property:
4280 DUE:19980430T235959Z
4282 3.8.2.4. Date/Time Start
4284 Property Name: DTSTART
4286 Purpose: This property specifies when the calendar component begins.
4288 Value Type: The default value type is DATE-TIME. The time value MUST
4289 be one of the forms defined for the DATE-TIME value type. The
4290 value type can be set to a DATE value type.
4292 Property Parameters: Non-standard, value data type, time zone
4293 identifier property parameters can be specified on this property.
4295 Conformance: This property can be specified in the "VEVENT", "VTODO",
4296 "VFREEBUSY", or "VTIMEZONE" calendar components. This property is
4297 REQUIRED in "VEVENT" calendar components.
4299 Description: Within the "VEVENT" calendar component, this property
4300 defines the start date and time for the event. Events can have a
4301 start date/time but no end date/time. In that case, the event
4302 does not take up any time.
4304 Within the "VFREEBUSY" calendar component, this property defines
4305 the start date and time for the free or busy time information.
4306 The time MUST be specified in UTC time.
4308 Within the "VTIMEZONE" calendar component, this property defines
4309 the effective start date and time for a time zone specification.
4310 This property is REQUIRED within each STANDARD and DAYLIGHT part
4311 included in "VTIMEZONE" calendar components and MUST be specified
4312 as a local DATE-TIME without the "TZID" property parameter.
4314 Format Definition: The property is defined by the following notation:
4316 dtstart = "DTSTART" dtstparam ":" dtstval CRLF
4318 dtstparam = *(
4320 ; the following are optional,
4321 ; but MUST NOT occur more than once
4323 (";" "VALUE" "=" ("DATE-TIME" / "DATE")) /
4324 (";" tzidparam) /
4326 ; the following is optional,
4327 ; and MAY occur more than once
4329 *(";" xparam)
4331 )
4333 dtstval = date-time / date
4334 ;Value MUST match value type
4336 Example: The following is an example of this property:
4338 DTSTART:19980118T073000Z
4340 3.8.2.5. Duration
4342 Property Name: DURATION
4344 Purpose: The property specifies a positive duration of time.
4346 Value Type: DURATION
4348 Property Parameters: Non-standard property parameters can be
4349 specified on this property.
4351 Conformance: The property can be specified in "VEVENT", "VTODO",
4352 "VFREEBUSY" or "VALARM" calendar components.
4354 Description: In a "VEVENT" calendar component the property may be
4355 used to specify a duration of the event, instead of an explicit
4356 end date/time. In a "VTODO" calendar component the property may
4357 be used to specify a duration for the to-do, instead of an
4358 explicit due date/time. In a "VFREEBUSY" calendar component the
4359 property may be used to specify the interval of free time being
4360 requested. In a "VALARM" calendar component the property may be
4361 used to specify the delay period prior to repeating an alarm.
4363 Format Definition: The property is defined by the following notation:
4365 duration = "DURATION" durparam ":" dur-value CRLF
4366 ;consisting of a positive duration of time.
4368 durparam = *(";" xparam)
4370 Example: The following is an example of this property that specifies
4371 an interval of time of 1 hour and zero minutes and zero seconds:
4373 DURATION:PT1H0M0S
4375 The following is an example of this property that specifies an
4376 interval of time of 15 minutes.
4378 DURATION:PT15M
4380 3.8.2.6. Free/Busy Time
4382 Property Name: FREEBUSY
4384 Purpose: The property defines one or more free or busy time
4385 intervals.
4387 Value Type: PERIOD. The date and time values MUST be in a UTC time
4388 format.
4390 Property Parameters: Non-standard or free/busy time type property
4391 parameters can be specified on this property.
4393 Conformance: The property can be specified in a "VFREEBUSY" calendar
4394 component.
4396 Description: These time periods can be specified as either a start
4397 and end date-time or a start date-time and duration. The date and
4398 time MUST be a UTC time format.
4400 "FREEBUSY" properties within the "VFREEBUSY" calendar component
4401 SHOULD be sorted in ascending order, based on start time and then
4402 end time, with the earliest periods first.
4404 The "FREEBUSY" property can specify more than one value, separated
4405 by the COMMA character (US-ASCII decimal 44). In such cases, the
4406 "FREEBUSY" property values SHOULD all be of the same "FBTYPE"
4407 property parameter type (e.g., all values of a particular "FBTYPE"
4408 listed together in a single property).
4410 Format Definition: The property is defined by the following notation:
4412 freebusy = "FREEBUSY" fbparam ":" fbvalue CRLF
4414 fbparam = *(
4415 ; the following is optional,
4416 ; but MUST NOT occur more than once
4418 (";" fbtypeparam) /
4420 ; the following is optional,
4421 ; and MAY occur more than once
4423 (";" xparam)
4425 )
4427 fbvalue = period *("," period
4428 ;Time value MUST be in the UTC time format.
4430 Example: The following are some examples of this property:
4432 FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:19970308T160000Z/PT8H30M
4434 FREEBUSY;FBTYPE=FREE:19970308T160000Z/PT3H,19970308T200000Z/PT1H
4436 FREEBUSY;FBTYPE=FREE:19970308T160000Z/PT3H,19970308T200000Z/PT1H
4437 ,19970308T230000Z/19970309T000000Z
4439 3.8.2.7. Time Transparency
4440 Property Name: TRANSP
4442 Purpose: This property defines whether an event is transparent or not
4443 to busy time searches.
4445 Value Type: TEXT
4447 Property Parameters: Non-standard property parameters can be
4448 specified on this property.
4450 Conformance: This property can be specified once in a "VEVENT"
4451 calendar component.
4453 Description: Time Transparency is the characteristic of an event that
4454 determines whether it appears to consume time on a calendar.
4455 Events that consume actual time for the individual or resource
4456 associated with the calendar SHOULD be recorded as OPAQUE,
4457 allowing them to be detected by free-busy time searches. Other
4458 events, which do not take up the individual's (or resource's) time
4459 SHOULD be recorded as TRANSPARENT, making them invisible to free-
4460 busy time searches.
4462 Format Definition: The property is defined by the following notation:
4464 transp = "TRANSP" transparam ":" transvalue CRLF
4466 transparam = *(";" xparam)
4468 transvalue = "OPAQUE"
4469 ;Blocks or opaque on busy time searches.
4470 / "TRANSPARENT"
4471 ;Transparent on busy time searches.
4472 ;Default value is OPAQUE
4474 Example: The following is an example of this property for an event
4475 that is transparent or does not block on free/busy time searches:
4477 TRANSP:TRANSPARENT
4479 The following is an example of this property for an event that is
4480 opaque or blocks on free/busy time searches:
4482 TRANSP:OPAQUE
4484 3.8.3. Time Zone Component Properties
4486 The following properties specify time zone information in calendar
4487 components.
4489 3.8.3.1. Time Zone Identifier
4491 Property Name: TZID
4493 Purpose: This property specifies the text value that uniquely
4494 identifies the "VTIMEZONE" calendar component.
4496 Value Type: TEXT
4498 Property Parameters: Non-standard property parameters can be
4499 specified on this property.
4501 Conformance: This property MUST be specified in a "VTIMEZONE"
4502 calendar component.
4504 Description: This is the label by which a time zone calendar
4505 component is referenced by any iCalendar properties whose data
4506 type is either DATE-TIME or TIME and not intended to specify a UTC
4507 or a "floating" time. The presence of the SOLIDUS character (US-
4508 ASCII decimal 47) as a prefix, indicates that this TZID represents
4509 an unique ID in a globally defined time zone registry (when such
4510 registry is defined).
4512 Note: This document does not define a naming convention for
4513 time zone identifiers. Implementers may want to use the naming
4514 conventions defined in existing time zone specifications such
4515 as the public-domain Olson database [TZDB]. The specification
4516 of globally unique time zone identifiers is not addressed by
4517 this document and is left for future study.
4519 Format Definition: The property is defined by the following notation:
4521 tzid = "TZID" tzidpropparam ":" [tzidprefix] text CRLF
4523 tzidpropparam = *(";" xparam)
4525 ;tzidprefix = "/"
4526 ; Defined previously. Just listed here for reader convenience.
4528 Example: The following are examples of non-globally unique time zone
4529 identifiers:
4531 TZID:US-Eastern
4533 TZID:California-Los_Angeles
4535 The following is an example of a fictitious globally unique time
4536 zone identifier:
4538 TZID:/US-New_York-New_York
4540 3.8.3.2. Time Zone Name
4542 Property Name: TZNAME
4544 Purpose: This property specifies the customary designation for a time
4545 zone description.
4547 Value Type: TEXT
4549 Property Parameters: Non-standard and language property parameters
4550 can be specified on this property.
4552 Conformance: This property can be specified in a "VTIMEZONE" calendar
4553 component.
4555 Description: This property may be specified in multiple languages; in
4556 order to provide for different language requirements.
4558 Format Definition: The property is defined by the following notation:
4560 tzname = "TZNAME" tznparam ":" text CRLF
4562 tznparam = *(
4564 ; the following is optional,
4565 ; but MUST NOT occur more than once
4567 (";" languageparam) /
4569 ; the following is optional,
4570 ; and MAY occur more than once
4572 (";" xparam)
4574 )
4576 Example: The following are example of this property:
4578 TZNAME:EST
4580 The following is an example of this property when two different
4581 languages for the time zone name are specified:
4583 TZNAME;LANGUAGE=en:EST
4584 TZNAME;LANGUAGE=fr-CA:HNE
4586 3.8.3.3. Time Zone Offset From
4588 Property Name: TZOFFSETFROM
4590 Purpose: This property specifies the offset which is in use prior to
4591 this time zone observance.
4593 Value Type: UTC-OFFSET
4595 Property Parameters: Non-standard property parameters can be
4596 specified on this property.
4598 Conformance: This property MUST be specified in a "VTIMEZONE"
4599 calendar component.
4601 Description: This property specifies the offset which is in use prior
4602 to this time observance. It is used to calculate the absolute
4603 time at which the transition to a given observance takes place.
4604 This property MUST only be specified in a "VTIMEZONE" calendar
4605 component. A "VTIMEZONE" calendar component MUST include this
4606 property. The property value is a signed numeric indicating the
4607 number of hours and possibly minutes from UTC. Positive numbers
4608 represent time zones east of the prime meridian, or ahead of UTC.
4609 Negative numbers represent time zones west of the prime meridian,
4610 or behind UTC.
4612 Format Definition: The property is defined by the following notation:
4614 tzoffsetfrom = "TZOFFSETFROM" frmparam ":" utc-offset
4615 CRLF
4617 frmparam = *(";" xparam)
4619 Example: The following are examples of this property:
4621 TZOFFSETFROM:-0500
4623 TZOFFSETFROM:+1345
4625 3.8.3.4. Time Zone Offset To
4627 Property Name: TZOFFSETTO
4629 Purpose: This property specifies the offset which is in use in this
4630 time zone observance.
4632 Value Type: UTC-OFFSET
4634 Property Parameters: Non-standard property parameters can be
4635 specified on this property.
4637 Conformance: This property MUST be specified in a "VTIMEZONE"
4638 calendar component.
4640 Description: This property specifies the offset which is in use in
4641 this time zone observance. It is used to calculate the absolute
4642 time for the new observance. The property value is a signed
4643 numeric indicating the number of hours and possibly minutes from
4644 UTC. Positive numbers represent time zones east of the prime
4645 meridian, or ahead of UTC. Negative numbers represent time zones
4646 west of the prime meridian, or behind UTC.
4648 Format Definition: The property is defined by the following notation:
4650 tzoffsetto = "TZOFFSETTO" toparam ":" utc-offset CRLF
4652 toparam = *(";" xparam)
4654 Example: The following are examples of this property:
4656 TZOFFSETTO:-0400
4658 TZOFFSETTO:+1245
4660 3.8.3.5. Time Zone URL
4662 Property Name: TZURL
4664 Purpose: The TZURL provides a means for a VTIMEZONE component to
4665 point to a network location that can be used to retrieve an up-to-
4666 date version of itself.
4668 Value Type: URI
4669 Property Parameters: Non-standard property parameters can be
4670 specified on this property.
4672 Conformance: This property can be specified in a "VTIMEZONE" calendar
4673 component.
4675 Description: The TZURL provides a means for a VTIMEZONE component to
4676 point to a network location that can be used to retrieve an up-to-
4677 date version of itself. This provides a hook to handle changes
4678 government bodies impose upon time zone definitions. Retrieval of
4679 this resource results in an iCalendar object containing a single
4680 VTIMEZONE component and a METHOD property set to PUBLISH.
4682 Format Definition: The property is defined by the following notation:
4684 tzurl = "TZURL" tzurlparam ":" uri CRLF
4686 tzurlparam = *(";" xparam)
4688 Example: The following is an example of this property:
4690 TZURL:http://timezones.r.us.net/tz/US-California-Los_Angeles.ics
4692 3.8.4. Relationship Component Properties
4694 The following properties specify relationship information in calendar
4695 components.
4697 3.8.4.1. Attendee
4699 Property Name: ATTENDEE
4701 Purpose: The property defines an "Attendee" within a calendar
4702 component.
4704 Value Type: CAL-ADDRESS
4706 Property Parameters: Non-standard, language, calendar user type,
4707 group or list membership, participation role, participation
4708 status, RSVP expectation, delegatee, delegator, sent by, common
4709 name or directory entry reference property parameters can be
4710 specified on this property.
4712 Conformance: This property MUST be specified in an iCalendar object
4713 that specifies a group scheduled calendar entity. This property
4714 MUST NOT be specified in an iCalendar object when publishing the
4715 calendar information (e.g., NOT in an iCalendar object that
4716 specifies the publication of a calendar user's busy time, event,
4717 to-do or journal). This property is not specified in an iCalendar
4718 object that specifies only a time zone definition or that defines
4719 calendar entities that are not group scheduled entities, but are
4720 entities only on a single user's calendar.
4722 Description: The property MUST only be specified within calendar
4723 components to specify participants, non-participants and the chair
4724 of a group scheduled calendar entity. The property is specified
4725 within an "EMAIL" category of the "VALARM" calendar component to
4726 specify an email address that is to receive the email type of
4727 iCalendar alarm.
4729 The property parameter CN is for the common or displayable name
4730 associated with the calendar address; ROLE, for the intended role
4731 that the attendee will have in the calendar component; PARTSTAT,
4732 for the status of the attendee's participation; RSVP, for
4733 indicating whether the favor of a reply is requested; CUTYPE, to
4734 indicate the type of calendar user; MEMBER, to indicate the groups
4735 that the attendee belongs to; DELEGATED-TO, to indicate the
4736 calendar users that the original request was delegated to; and
4737 DELEGATED-FROM, to indicate whom the request was delegated from;
4738 SENT-BY, to indicate whom is acting on behalf of the ATTENDEE; and
4739 DIR, to indicate the URI that points to the directory information
4740 corresponding to the attendee. These property parameters can be
4741 specified on an "ATTENDEE" property in either a "VEVENT", "VTODO"
4742 or "VJOURNAL" calendar component. They MUST NOT be specified in
4743 an "ATTENDEE" property in a "VFREEBUSY" or "VALARM" calendar
4744 component. If the LANGUAGE property parameter is specified, the
4745 identified language applies to the CN parameter.
4747 A recipient delegated a request MUST inherit the RSVP and ROLE
4748 values from the attendee that delegated the request to them.
4750 Multiple attendees can be specified by including multiple
4751 "ATTENDEE" properties within the calendar component.
4753 Format Definition: The property is defined by the following notation:
4755 attendee = "ATTENDEE" attparam ":" cal-address CRLF
4757 attparam = *(
4759 ; the following are optional,
4760 ; but MUST NOT occur more than once
4762 (";" cutypeparam) / (";"memberparam) /
4763 (";" roleparam) / (";" partstatparam) /
4764 (";" rsvpparam) / (";" deltoparam) /
4765 (";" delfromparam) / (";" sentbyparam) /
4766 (";"cnparam) / (";" dirparam) /
4767 (";" languageparam) /
4769 ; the following is optional,
4770 ; and MAY occur more than once
4772 (";" xparam)
4774 )
4776 Example: The following are examples of this property's use for a
4777 to-do:
4779 ORGANIZER:MAILTO:jsmith@example.com
4780 ATTENDEE;MEMBER="MAILTO:DEV-GROUP@example.com":
4781 MAILTO:joecool@example.com
4782 ATTENDEE;DELEGATED-FROM="MAILTO:immud@example.com":
4783 MAILTO:ildoit@example.com
4785 The following is an example of this property used for specifying
4786 multiple attendees to an event:
4788 ORGANIZER:MAILTO:jsmith@example.com
4789 ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;CN=Henry
4790 Cabot:MAILTO:hcabot@example.com
4791 ATTENDEE;ROLE=REQ-PARTICIPANT;DELEGATED-FROM="MAILTO:bob@
4792 example.com"
4793 ;PARTSTAT=ACCEPTED;CN=Jane Doe:MAILTO:jdoe@example.com
4795 The following is an example of this property with a URI to the
4796 directory information associated with the attendee:
4798 ATTENDEE;CN=John Smith;DIR="ldap://example.com:6666/o=ABC%
4799 20Industries,c=US???(cn=Jim%20Dolittle)":MAILTO:jimdo@
4800 example.com
4802 The following is an example of this property with "delegatee" and
4803 "delegator" information for an event:
4805 ORGANIZER;CN=John Smith:MAILTO:jsmith@example.com
4806 ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;DELEGATED-FROM=
4807 "MAILTO:iamboss@example.com";CN=Henry Cabot:MAILTO:hcabot@
4808 example.com
4809 ATTENDEE;ROLE=NON-PARTICIPANT;PARTSTAT=DELEGATED;DELEGATED-TO=
4810 "MAILTO:hcabot@example.com";CN=The Big Cheese:MAILTO:iamboss
4811 @example.com
4812 ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;CN=Jane Doe
4813 :MAILTO:jdoe@example.com
4815 Example: The following is an example of this property's use when
4816 another calendar user is acting on behalf of the "Attendee":
4818 ATTENDEE;SENT-BY=MAILTO:jan_doe@example.com;CN=John Smith:MAILTO:
4819 jsmith@example.com
4821 3.8.4.2. Contact
4823 Property Name: CONTACT
4825 Purpose: The property is used to represent contact information or
4826 alternately a reference to contact information associated with the
4827 calendar component.
4829 Value Type: TEXT
4831 Property Parameters: Non-standard, alternate text representation and
4832 language property parameters can be specified on this property.
4834 Conformance: The property can be specified in a "VEVENT", "VTODO",
4835 "VJOURNAL" or "VFREEBUSY" calendar component.
4837 Description: The property value consists of textual contact
4838 information. An alternative representation for the property value
4839 can also be specified that refers to a URI pointing to an
4840 alternate form, such as a vCard [RFC2426], for the contact
4841 information.
4843 Format Definition: The property is defined by the following notation:
4845 contact = "CONTACT" contparam ":" text CRLF
4847 contparam = *(
4848 ; the following are optional,
4849 ; but MUST NOT occur more than once
4851 (";" altrepparam) / (";" languageparam) /
4853 ; the following is optional,
4854 ; and MAY occur more than once
4856 (";" xparam)
4858 )
4860 Example: The following is an example of this property referencing
4861 textual contact information:
4863 CONTACT:Jim Dolittle\, ABC Industries\, +1-919-555-1234
4865 The following is an example of this property with an alternate
4866 representation of a LDAP URI to a directory entry containing the
4867 contact information:
4869 CONTACT;ALTREP="ldap://example.com:6666/o=ABC%20Industries\,
4870 c=US???(cn=Jim%20Dolittle)":Jim Dolittle\, ABC Industries\,
4871 +1-919-555-1234
4873 The following is an example of this property with an alternate
4874 representation of a MIME body part containing the contact
4875 information, such as a vCard [RFC2426] embedded in a text/
4876 directory media type [RFC2425] :
4878 CONTACT;ALTREP="CID:part3.msg970930T083000SILVER@example.com":
4879 Jim Dolittle\, ABC Industries\, +1-919-555-1234
4881 The following is an example of this property referencing a network
4882 resource, such as a vCard [RFC2426] object containing the contact
4883 information:
4885 CONTACT;ALTREP="http://example.com/pdi/jdoe.vcf":Jim
4886 Dolittle\, ABC Industries\, +1-919-555-1234
4888 3.8.4.3. Organizer
4889 Property Name: ORGANIZER
4891 Purpose: The property defines the organizer for a calendar component.
4893 Value Type: CAL-ADDRESS
4895 Property Parameters: Non-standard, language, common name, directory
4896 entry reference, sent by property parameters can be specified on
4897 this property.
4899 Conformance: This property MUST be specified in an iCalendar object
4900 that specifies a group scheduled calendar entity. This property
4901 MUST be specified in an iCalendar object that specifies the
4902 publication of a calendar user's busy time. This property MUST
4903 NOT be specified in an iCalendar object that specifies only a time
4904 zone definition or that defines calendar entities that are not
4905 group scheduled entities, but are entities only on a single user's
4906 calendar.
4908 Description: The property is specified within the "VEVENT", "VTODO",
4909 "VJOURNAL" calendar components to specify the organizer of a group
4910 scheduled calendar entity. The property is specified within the
4911 "VFREEBUSY" calendar component to specify the calendar user
4912 requesting the free or busy time. When publishing a "VFREEBUSY"
4913 calendar component, the property is used to specify the calendar
4914 that the published busy time came from.
4916 The property has the property parameters CN, for specifying the
4917 common or display name associated with the "Organizer", DIR, for
4918 specifying a pointer to the directory information associated with
4919 the "Organizer", SENT-BY, for specifying another calendar user
4920 that is acting on behalf of the "Organizer". The non-standard
4921 parameters may also be specified on this property. If the
4922 LANGUAGE property parameter is specified, the identified language
4923 applies to the CN parameter value.
4925 Format Definition: The property is defined by the following notation:
4927 organizer = "ORGANIZER" orgparam ":"
4928 cal-address CRLF
4930 orgparam = *(
4932 ; the following are optional,
4933 ; but MUST NOT occur more than once
4935 (";" cnparam) / (";" dirparam) / (";" sentbyparam) /
4936 (";" languageparam) /
4938 ; the following is optional,
4939 ; and MAY occur more than once
4941 (";" xparam)
4943 )
4945 Example: The following is an example of this property:
4947 ORGANIZER;CN=John Smith:MAILTO:jsmith@example.com
4949 The following is an example of this property with a pointer to the
4950 directory information associated with the organizer:
4952 ORGANIZER;CN=JohnSmith;DIR="ldap://example.com:6666/o=DC%20Ass
4953 ociates,c=US???(cn=John%20Smith)":MAILTO:jsmith@example.com
4955 The following is an example of this property used by another
4956 calendar user who is acting on behalf of the organizer, with
4957 responses intended to be sent back to the organizer, not the other
4958 calendar user:
4960 ORGANIZER;SENT-BY="MAILTO:jane_doe@example.com":
4961 MAILTO:jsmith@example.com
4963 3.8.4.4. Recurrence ID
4965 Property Name: RECURRENCE-ID
4967 Purpose: This property is used in conjunction with the "UID" and
4968 "SEQUENCE" property to identify a specific instance of a recurring
4969 "VEVENT", "VTODO" or "VJOURNAL" calendar component. The property
4970 value is the effective value of the "DTSTART" property of the
4971 recurrence instance.
4973 Value Type: The default value type for this property is DATE-TIME.
4974 The time format can be any of the valid forms defined for a DATE-
4975 TIME value type. See DATE-TIME value type definition for specific
4976 interpretations of the various forms. The value type can be set
4977 to DATE.
4979 Property Parameters: Non-standard property, value data type, time
4980 zone identifier and recurrence identifier range parameters can be
4981 specified on this property.
4983 Conformance: This property can be specified in an iCalendar object
4984 containing a recurring calendar component.
4986 Description: The full range of calendar components specified by a
4987 recurrence set is referenced by referring to just the "UID"
4988 property value corresponding to the calendar component. The
4989 "RECURRENCE-ID" property allows the reference to an individual
4990 instance within the recurrence set.
4992 If the value of the "DTSTART" property is a DATE type value, then
4993 the value MUST be the calendar date for the recurrence instance.
4995 The date/time value is set to the time when the original
4996 recurrence instance would occur; meaning that if the intent is to
4997 change a Friday meeting to Thursday, the date/time is still set to
4998 the original Friday meeting.
5000 The "RECURRENCE-ID" property is used in conjunction with the "UID"
5001 and "SEQUENCE" property to identify a particular instance of a
5002 recurring event, to-do or journal. For a given pair of "UID" and
5003 "SEQUENCE" property values, the "RECURRENCE-ID" value for a
5004 recurrence instance is fixed. When the definition of the
5005 recurrence set for a calendar component changes, and hence the
5006 "SEQUENCE" property value changes, the "RECURRENCE-ID" for a given
5007 recurrence instance might also change.The "RANGE" parameter is
5008 used to specify the effective range of recurrence instances from
5009 the instance specified by the "RECURRENCE-ID" property value. The
5010 default value for the range parameter is the single recurrence
5011 instance only. The value can also be "THISANDPRIOR" to indicate a
5012 range defined by the given recurrence instance and all prior
5013 instances or the value can be "THISANDFUTURE" to indicate a range
5014 defined by the given recurrence instance and all subsequent
5015 instances.
5017 Format Definition: The property is defined by the following notation:
5019 recurid = "RECURRENCE-ID" ridparam ":" ridval CRLF
5021 ridparam = *(
5023 ; the following are optional,
5024 ; but MUST NOT occur more than once
5026 (";" "VALUE" "=" ("DATE-TIME" / "DATE)) /
5027 (";" tzidparam) / (";" rangeparam) /
5029 ; the following is optional,
5030 ; and MAY occur more than once
5032 (";" xparam)
5034 )
5036 ridval = date-time / date
5037 ;Value MUST match value type
5039 Example: The following are examples of this property:
5041 RECURRENCE-ID;VALUE=DATE:19960401
5043 RECURRENCE-ID;RANGE=THISANDFUTURE:19960120T120000Z
5045 3.8.4.5. Related To
5047 Property Name: RELATED-TO
5049 Purpose: The property is used to represent a relationship or
5050 reference between one calendar component and another.
5052 Value Type: TEXT
5054 Property Parameters: Non-standard and relationship type property
5055 parameters can be specified on this property.
5057 Conformance: The property can be specified one or more times in the
5058 "VEVENT", "VTODO" or "VJOURNAL" calendar components.
5060 Description: The property value consists of the persistent, globally
5061 unique identifier of another calendar component. This value would
5062 be represented in a calendar component by the "UID" property.
5064 By default, the property value points to another calendar
5065 component that has a PARENT relationship to the referencing
5066 object. The "RELTYPE" property parameter is used to either
5067 explicitly state the default PARENT relationship type to the
5068 referenced calendar component or to override the default PARENT
5069 relationship type and specify either a CHILD or SIBLING
5070 relationship. The PARENT relationship indicates that the calendar
5071 component is a subordinate of the referenced calendar component.
5072 The CHILD relationship indicates that the calendar component is a
5073 superior of the referenced calendar component. The SIBLING
5074 relationship indicates that the calendar component is a peer of
5075 the referenced calendar component.
5077 Changes to a calendar component referenced by this property can
5078 have an implicit impact on the related calendar component. For
5079 example, if a group event changes its start or end date or time,
5080 then the related, dependent events will need to have their start
5081 and end dates changed in a corresponding way. Similarly, if a
5082 PARENT calendar component is cancelled or deleted, then there is
5083 an implied impact to the related CHILD calendar components. This
5084 property is intended only to provide information on the
5085 relationship of calendar components. It is up to the target
5086 calendar system to maintain any property implications of this
5087 relationship.
5089 Format Definition: The property is defined by the following notation:
5091 related = "RELATED-TO" relparam ":" text CRLF
5093 relparam = *(
5095 ; the following is optional,
5096 ; but MUST NOT occur more than once
5098 (";" reltypeparam) /
5100 ; the following is optional,
5101 ; and MAY occur more than once
5103 (";" xparam)
5105 )
5107 The following is an example of this property:
5109 RELATED-TO:jsmith.part7.19960817T083000.xyzMail@example.com
5110 RELATED-TO:19960401-080045-4000F192713-0052@example.com
5112 3.8.4.6. Uniform Resource Locator
5114 Property Name: URL
5116 Purpose: This property defines a Uniform Resource Locator (URL)
5117 associated with the iCalendar object.
5119 Value Type: URI
5121 Property Parameters: Non-standard property parameters can be
5122 specified on this property.
5124 Conformance: This property can be specified once in the "VEVENT",
5125 "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components.
5127 Description: This property may be used in a calendar component to
5128 convey a location where a more dynamic rendition of the calendar
5129 information associated with the calendar component can be found.
5130 This memo does not attempt to standardize the form of the URI, nor
5131 the format of the resource pointed to by the property value. If
5132 the URL property and Content-Location MIME header are both
5133 specified, they MUST point to the same resource.
5135 Format Definition: The property is defined by the following notation:
5137 url = "URL" urlparam ":" uri CRLF
5139 urlparam = *(";" xparam)
5141 Example: The following is an example of this property:
5143 URL:http://abc.com/pub/calendars/jsmith/mytime.ics
5145 3.8.4.7. Unique Identifier
5147 Property Name: UID
5149 Purpose: This property defines the persistent, globally unique
5150 identifier for the calendar component.
5152 Value Type: TEXT
5154 Property Parameters: Non-standard property parameters can be
5155 specified on this property.
5157 Conformance: The property MUST be specified in the "VEVENT", "VTODO",
5158 "VJOURNAL" or "VFREEBUSY" calendar components.
5160 Description: The UID itself MUST be a globally unique identifier.
5161 The generator of the identifier MUST guarantee that the identifier
5162 is unique. There are several algorithms that can be used to
5163 accomplish this. The identifier is RECOMMENDED to be the
5164 identical syntax to the [RFC2822] addr-spec. A good method to
5165 assure uniqueness is to put the domain name or a domain literal IP
5166 address of the host on which the identifier was created on the
5167 right hand side of the "@", and on the left hand side, put a
5168 combination of the current calendar date and time of day (i.e.,
5169 formatted in as a DATE-TIME value) along with some other currently
5170 unique (perhaps sequential) identifier available on the system
5171 (for example, a process id number). Using a date/time value on
5172 the left hand side and a domain name or domain literal on the
5173 right hand side makes it possible to guarantee uniqueness since no
5174 two hosts should be using the same domain name or IP address at
5175 the same time. Though other algorithms will work, it is
5176 RECOMMENDED that the right hand side contain some domain
5177 identifier (either of the host itself or otherwise) such that the
5178 generator of the message identifier can guarantee the uniqueness
5179 of the left hand side within the scope of that domain.
5181 This is the method for correlating scheduling messages with the
5182 referenced "VEVENT", "VTODO", or "VJOURNAL" calendar component.
5184 The full range of calendar components specified by a recurrence
5185 set is referenced by referring to just the "UID" property value
5186 corresponding to the calendar component. The "RECURRENCE-ID"
5187 property allows the reference to an individual instance within the
5188 recurrence set.
5190 This property is an important method for group scheduling
5191 applications to match requests with later replies, modifications
5192 or deletion requests. Calendaring and scheduling applications
5193 MUST generate this property in "VEVENT", "VTODO" and "VJOURNAL"
5194 calendar components to assure interoperability with other group
5195 scheduling applications. This identifier is created by the
5196 calendar system that generates an iCalendar object.
5198 Implementations MUST be able to receive and persist values of at
5199 least 255 octets for this property but MUST NOT truncate values in
5200 the middle of a UTF-8 multi-octet sequence .
5202 Format Definition: The property is defined by the following notation:
5204 uid = "UID" uidparam ":" text CRLF
5206 uidparam = *(";" xparam)
5208 Example: The following is an example of this property:
5210 UID:19960401T080045Z-4000F192713-0052@example.com
5212 3.8.5. Recurrence Component Properties
5214 The following properties specify recurrence information in calendar
5215 components.
5217 3.8.5.1. Exception Date/Times
5219 Property Name: EXDATE
5221 Purpose: This property defines the list of date/time exceptions for a
5222 recurring calendar component.
5224 Value Type: The default value type for this property is DATE-TIME.
5225 The value type can be set to DATE.
5227 Property Parameters: Non-standard, value data type and time zone
5228 identifier property parameters can be specified on this property.
5230 Conformance: This property can be specified in an iCalendar object
5231 that includes a recurring calendar component.
5233 Description: The exception dates, if specified, are used in computing
5234 the recurrence set. The recurrence set is the complete set of
5235 recurrence instances for a calendar component. The recurrence set
5236 is generated by considering the initial "DTSTART" property along
5237 with the "RRULE", "RDATE", "EXDATE" and "EXRULE" properties
5238 contained within the iCalendar object. The "DTSTART" property
5239 defines the first instance in the recurrence set. Multiple
5240 instances of the "RRULE" and "EXRULE" properties can also be
5241 specified to define more sophisticated recurrence sets. The final
5242 recurrence set is generated by gathering all of the start date-
5243 times generated by any of the specified "RRULE" and "RDATE"
5244 properties, and then excluding any start date and times which fall
5245 within the union of start date and times generated by any
5246 specified "EXRULE" and "EXDATE" properties. This implies that
5247 start date and times within exclusion related properties (i.e.,
5248 "EXDATE" and "EXRULE") take precedence over those specified by
5249 inclusion properties (i.e., "RDATE" and "RRULE"). Where duplicate
5250 instances are generated by the "RRULE" and "RDATE" properties,
5251 only one recurrence is considered. Duplicate instances are
5252 ignored.
5254 The "EXDATE" property can be used to exclude the value specified
5255 in "DTSTART". However, in such cases the original "DTSTART" date
5256 MUST still be maintained by the calendaring and scheduling system
5257 because the original "DTSTART" value has inherent usage
5258 dependencies by other properties such as the "RECURRENCE-ID".
5260 Format Definition: The property is defined by the following notation:
5262 exdate = "EXDATE" exdtparam ":" exdtval *("," exdtval) CRLF
5264 exdtparam = *(
5266 ; the following are optional,
5267 ; but MUST NOT occur more than once
5269 (";" "VALUE" "=" ("DATE-TIME" / "DATE")) /
5271 (";" tzidparam) /
5273 ; the following is optional,
5274 ; and MAY occur more than once
5276 (";" xparam)
5278 )
5280 exdtval = date-time / date
5281 ;Value MUST match value type
5283 Example: The following is an example of this property:
5285 EXDATE:19960402T010000Z,19960403T010000Z,19960404T010000Z
5287 3.8.5.2. Exception Rule
5289 Property Name: EXRULE
5291 Purpose: This property defines a rule or repeating pattern for an
5292 exception to a recurrence set.
5294 Value Type: RECUR
5295 Property Parameters: Non-standard property parameters can be
5296 specified on this property.
5298 Conformance: This property can be specified in "VEVENT", "VTODO" or
5299 "VJOURNAL" calendar components.
5301 Description: The exception rule, if specified, is used in computing
5302 the recurrence set. The recurrence set is the complete set of
5303 recurrence instances for a calendar component. The recurrence set
5304 is generated by considering the initial "DTSTART" property along
5305 with the "RRULE", "RDATE", "EXDATE" and "EXRULE" properties
5306 contained within the iCalendar object. The "DTSTART" defines the
5307 first instance in the recurrence set. Multiple instances of the
5308 "RRULE" and "EXRULE" properties can also be specified to define
5309 more sophisticated recurrence sets. The final recurrence set is
5310 generated by gathering all of the start date-times generated by
5311 any of the specified "RRULE" and "RDATE" properties, and excluding
5312 any start date and times which fall within the union of start date
5313 and times generated by any specified "EXRULE" and "EXDATE"
5314 properties. This implies that start date and times within
5315 exclusion related properties (i.e., "EXDATE" and "EXRULE") take
5316 precedence over those specified by inclusion properties (i.e.,
5317 "RDATE" and "RRULE"). Where duplicate instances are generated by
5318 the "RRULE" and "RDATE" properties, only one recurrence is
5319 considered. Duplicate instances are ignored.
5321 The "EXRULE" property can be used to exclude the value specified
5322 in "DTSTART". However, in such cases the original "DTSTART" date
5323 MUST still be maintained by the calendaring and scheduling system
5324 because the original "DTSTART" value has inherent usage
5325 dependencies by other properties such as the "RECURRENCE-ID".
5327 Format Definition: The property is defined by the following notation:
5329 exrule = "EXRULE" exrparam ":" recur CRLF
5331 exrparam = *(";" xparam)
5333 Example: The following are examples of this property. Except every
5334 other week, on Tuesday and Thursday for 4 occurrences:
5336 EXRULE:FREQ=WEEKLY;COUNT=4;INTERVAL=2;BYDAY=TU,TH
5338 Except daily for 10 occurrences:
5340 EXRULE:FREQ=DAILY;COUNT=10
5342 Except yearly in June and July for 8 occurrences:
5344 EXRULE:FREQ=YEARLY;COUNT=8;BYMONTH=6,7
5346 3.8.5.3. Recurrence Date/Times
5348 Property Name: RDATE
5350 Purpose: This property defines the list of date/times for a
5351 recurrence set.
5353 Value Type: The default value type for this property is DATE-TIME.
5354 The value type can be set to DATE or PERIOD.
5356 Property Parameters: Non-standard, value data type and time zone
5357 identifier property parameters can be specified on this property.
5359 Conformance: The property can be specified in "VEVENT", "VTODO",
5360 "VJOURNAL" or "VTIMEZONE" calendar components.
5362 Description: This property can appear along with the "RRULE" property
5363 to define an aggregate set of repeating occurrences. When they
5364 both appear in an iCalendar object, the recurring events are
5365 defined by the union of occurrences defined by both the "RDATE"
5366 and "RRULE".
5368 The recurrence dates, if specified, are used in computing the
5369 recurrence set. The recurrence set is the complete set of
5370 recurrence instances for a calendar component. The recurrence set
5371 is generated by considering the initial "DTSTART" property along
5372 with the "RRULE", "RDATE", "EXDATE" and "EXRULE" properties
5373 contained within the iCalendar object. The "DTSTART" property
5374 defines the first instance in the recurrence set. Multiple
5375 instances of the "RRULE" and "EXRULE" properties can also be
5376 specified to define more sophisticated recurrence sets. The final
5377 recurrence set is generated by gathering all of the start date/
5378 times generated by any of the specified "RRULE" and "RDATE"
5379 properties, and excluding any start date/times which fall within
5380 the union of start date/times generated by any specified "EXRULE"
5381 and "EXDATE" properties. This implies that start date/times
5382 within exclusion related properties (i.e., "EXDATE" and "EXRULE")
5383 take precedence over those specified by inclusion properties
5384 (i.e., "RDATE" and "RRULE"). Where duplicate instances are
5385 generated by the "RRULE" and "RDATE" properties, only one
5386 recurrence is considered. Duplicate instances are ignored.
5388 Format Definition: The property is defined by the following notation:
5390 rdate = "RDATE" rdtparam ":" rdtval *("," rdtval) CRLF
5392 rdtparam = *(
5394 ; the following are optional,
5395 ; but MUST NOT occur more than once
5397 (";" "VALUE" "=" ("DATE-TIME" / "DATE" / "PERIOD")) /
5398 (";" tzidparam) /
5400 ; the following is optional,
5401 ; and MAY occur more than once
5403 (";" xparam)
5405 )
5407 rdtval = date-time / date / period
5408 ;Value MUST match value type
5410 Example: The following are examples of this property:
5412 RDATE:19970714T123000Z
5414 RDATE;TZID=US-EASTERN:19970714T083000
5416 RDATE;VALUE=PERIOD:19960403T020000Z/19960403T040000Z,
5417 19960404T010000Z/PT3H
5419 RDATE;VALUE=DATE:19970101,19970120,19970217,19970421
5420 19970526,19970704,19970901,19971014,19971128,19971129,19971225
5422 3.8.5.4. Recurrence Rule
5424 Property Name: RRULE
5426 Purpose: This property defines a rule or repeating pattern for
5427 recurring events, to-dos, or time zone definitions.
5429 Value Type: RECUR
5431 Property Parameters: Non-standard property parameters can be
5432 specified on this property.
5434 Conformance: This property can be specified one or more times in
5435 recurring "VEVENT", "VTODO" and "VJOURNAL" calendar components.
5436 It can also be specified once in each STANDARD or DAYLIGHT sub-
5437 component of the "VTIMEZONE" calendar component.
5439 Description: The recurrence rule, if specified, is used in computing
5440 the recurrence set. The recurrence set is the complete set of
5441 recurrence instances for a calendar component. The recurrence set
5442 is generated by considering the initial "DTSTART" property along
5443 with the "RRULE", "RDATE", "EXDATE" and "EXRULE" properties
5444 contained within the iCalendar object. The "DTSTART" property
5445 defines the first instance in the recurrence set. Multiple
5446 instances of the "RRULE" and "EXRULE" properties can also be
5447 specified to define more sophisticated recurrence sets. The final
5448 recurrence set is generated by gathering all of the start date/
5449 times generated by any of the specified "RRULE" and "RDATE"
5450 properties, and excluding any start date/times which fall within
5451 the union of start date/times generated by any specified "EXRULE"
5452 and "EXDATE" properties. This implies that start date/times
5453 within exclusion related properties (i.e., "EXDATE" and "EXRULE")
5454 take precedence over those specified by inclusion properties
5455 (i.e., "RDATE" and "RRULE"). Where duplicate instances are
5456 generated by the "RRULE" and "RDATE" properties, only one
5457 recurrence is considered. Duplicate instances are ignored.
5459 The "DTSTART" and "DTEND" property pair or "DTSTART" and
5460 "DURATION" property pair, specified within the iCalendar object
5461 defines the first instance of the recurrence. When used with a
5462 recurrence rule, the "DTSTART" and "DTEND" properties MUST be
5463 specified in local time and the appropriate set of "VTIMEZONE"
5464 calendar components MUST be included. For detail on the usage of
5465 the "VTIMEZONE" calendar component, see the "VTIMEZONE" calendar
5466 component definition.
5468 Any duration associated with the iCalendar object applies to all
5469 members of the generated recurrence set. Any modified duration
5470 for specific recurrences MUST be explicitly specified using the
5471 "RDATE" property.
5473 Format Definition: The property is defined by the following notation:
5475 rrule = "RRULE" rrulparam ":" recur CRLF
5477 rrulparam = *(";" xparam)
5479 Example: All examples assume the Eastern United States time zone.
5481 Daily for 10 occurrences:
5483 DTSTART;TZID=US-Eastern:19970902T090000
5484 RRULE:FREQ=DAILY;COUNT=10
5486 ==> (1997 9:00 AM EDT)September 2-11
5488 Daily until December 24, 1997:
5490 DTSTART;TZID=US-Eastern:19970902T090000
5491 RRULE:FREQ=DAILY;UNTIL=19971224T000000Z
5493 ==> (1997 9:00 AM EDT)September 2-30;October 1-25
5494 (1997 9:00 AM EST)October 26-31;November 1-30;December 1-23
5496 Every other day - forever:
5498 DTSTART;TZID=US-Eastern:19970902T090000
5499 RRULE:FREQ=DAILY;INTERVAL=2
5501 ==> (1997 9:00 AM EDT)September 2,4,6,8...24,26,28,30;
5502 October 2,4,6...20,22,24
5503 (1997 9:00 AM EST)October 26,28,30;November 1,3,5,7...25,27,29;
5504 December 1,3,...
5506 Every 10 days, 5 occurrences:
5508 DTSTART;TZID=US-Eastern:19970902T090000
5509 RRULE:FREQ=DAILY;INTERVAL=10;COUNT=5
5511 ==> (1997 9:00 AM EDT)September 2,12,22;October 2,12
5513 Everyday in January, for 3 years:
5515 DTSTART;TZID=US-Eastern:19980101T090000
5517 RRULE:FREQ=YEARLY;UNTIL=20000131T140000Z;
5518 BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA
5519 or
5520 RRULE:FREQ=DAILY;UNTIL=20000131T140000Z;BYMONTH=1
5522 ==> (1998 9:00 AM EST)January 1-31
5523 (1999 9:00 AM EST)January 1-31
5524 (2000 9:00 AM EST)January 1-31
5526 Weekly for 10 occurrences
5528 DTSTART;TZID=US-Eastern:19970902T090000
5529 RRULE:FREQ=WEEKLY;COUNT=10
5531 ==> (1997 9:00 AM EDT)September 2,9,16,23,30;October 7,14,21
5532 (1997 9:00 AM EST)October 28;November 4
5534 Weekly until December 24, 1997
5536 DTSTART;TZID=US-Eastern:19970902T090000
5537 RRULE:FREQ=WEEKLY;UNTIL=19971224T000000Z
5539 ==> (1997 9:00 AM EDT)September 2,9,16,23,30;October 7,14,21
5540 (1997 9:00 AM EST)October 28;November 4,11,18,25;
5541 December 2,9,16,23
5543 Every other week - forever:
5545 DTSTART;TZID=US-Eastern:19970902T090000
5546 RRULE:FREQ=WEEKLY;INTERVAL=2;WKST=SU
5548 ==> (1997 9:00 AM EDT)September 2,16,30;October 14
5549 (1997 9:00 AM EST)October 28;November 11,25;December 9,23
5550 (1998 9:00 AM EST)January 6,20;February
5551 ...
5553 Weekly on Tuesday and Thursday for 5 weeks:
5555 DTSTART;TZID=US-Eastern:19970902T090000
5556 RRULE:FREQ=WEEKLY;UNTIL=19971007T000000Z;WKST=SU;BYDAY=TU,TH
5557 or
5559 RRULE:FREQ=WEEKLY;COUNT=10;WKST=SU;BYDAY=TU,TH
5561 ==> (1997 9:00 AM EDT)September 2,4,9,11,16,18,23,25,30;October 2
5563 Every other week on Monday, Wednesday and Friday until December
5564 24, 1997, but starting on Tuesday, September 2, 1997:
5566 DTSTART;TZID=US-Eastern:19970902T090000
5567 RRULE:FREQ=WEEKLY;INTERVAL=2;UNTIL=19971224T000000Z;WKST=SU;
5568 BYDAY=MO,WE,FR
5570 ==> (1997 9:00 AM EDT)September 2,3,5,15,17,19,29;October
5571 1,3,13,15,17
5572 (1997 9:00 AM EST)October 27,29,31;November 10,12,14,24,26,28;
5573 December 8,10,12,22
5575 Every other week on Tuesday and Thursday, for 8 occurrences:
5577 DTSTART;TZID=US-Eastern:19970902T090000
5578 RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=8;WKST=SU;BYDAY=TU,TH
5580 ==> (1997 9:00 AM EDT)September 2,4,16,18,30;October 2,14,16
5582 Monthly on the 1st Friday for ten occurrences:
5584 DTSTART;TZID=US-Eastern:19970905T090000
5585 RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR
5587 ==> (1997 9:00 AM EDT)September 5;October 3
5588 (1997 9:00 AM EST)November 7;December 5
5589 (1998 9:00 AM EST)January 2;February 6;March 6;April 3
5590 (1998 9:00 AM EDT)May 1;June 5
5592 Monthly on the 1st Friday until December 24, 1997:
5594 DTSTART;TZID=US-Eastern:19970905T090000
5595 RRULE:FREQ=MONTHLY;UNTIL=19971224T000000Z;BYDAY=1FR
5597 ==> (1997 9:00 AM EDT)September 5;October 3
5598 (1997 9:00 AM EST)November 7;December 5
5600 Every other month on the 1st and last Sunday of the month for 10
5601 occurrences:
5603 DTSTART;TZID=US-Eastern:19970907T090000
5604 RRULE:FREQ=MONTHLY;INTERVAL=2;COUNT=10;BYDAY=1SU,-1SU
5606 ==> (1997 9:00 AM EDT)September 7,28
5607 (1997 9:00 AM EST)November 2,30
5608 (1998 9:00 AM EST)January 4,25;March 1,29
5609 (1998 9:00 AM EDT)May 3,31
5611 Monthly on the second to last Monday of the month for 6 months:
5613 DTSTART;TZID=US-Eastern:19970922T090000
5614 RRULE:FREQ=MONTHLY;COUNT=6;BYDAY=-2MO
5616 ==> (1997 9:00 AM EDT)September 22;October 20
5617 (1997 9:00 AM EST)November 17;December 22
5618 (1998 9:00 AM EST)January 19;February 16
5620 Monthly on the third to the last day of the month, forever:
5622 DTSTART;TZID=US-Eastern:19970928T090000
5623 RRULE:FREQ=MONTHLY;BYMONTHDAY=-3
5625 ==> (1997 9:00 AM EDT)September 28
5626 (1997 9:00 AM EST)October 29;November 28;December 29
5627 (1998 9:00 AM EST)January 29;February 26
5628 ...
5630 Monthly on the 2nd and 15th of the month for 10 occurrences:
5632 DTSTART;TZID=US-Eastern:19970902T090000
5633 RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=2,15
5635 ==> (1997 9:00 AM EDT)September 2,15;October 2,15
5636 (1997 9:00 AM EST)November 2,15;December 2,15
5637 (1998 9:00 AM EST)January 2,15
5639 Monthly on the first and last day of the month for 10 occurrences:
5641 DTSTART;TZID=US-Eastern:19970930T090000
5642 RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=1,-1
5644 ==> (1997 9:00 AM EDT)September 30;October 1
5645 (1997 9:00 AM EST)October 31;November 1,30;December 1,31
5646 (1998 9:00 AM EST)January 1,31;February 1
5648 Every 18 months on the 10th thru 15th of the month for 10
5649 occurrences:
5651 DTSTART;TZID=US-Eastern:19970910T090000
5652 RRULE:FREQ=MONTHLY;INTERVAL=18;COUNT=10;BYMONTHDAY=10,11,12,13,14,
5653 15
5655 ==> (1997 9:00 AM EDT)September 10,11,12,13,14,15
5656 (1999 9:00 AM EST)March 10,11,12,13
5658 Every Tuesday, every other month:
5660 DTSTART;TZID=US-Eastern:19970902T090000
5661 RRULE:FREQ=MONTHLY;INTERVAL=2;BYDAY=TU
5663 ==> (1997 9:00 AM EDT)September 2,9,16,23,30
5664 (1997 9:00 AM EST)November 4,11,18,25
5665 (1998 9:00 AM EST)January 6,13,20,27;March 3,10,17,24,31
5666 ...
5668 Yearly in June and July for 10 occurrences:
5670 DTSTART;TZID=US-Eastern:19970610T090000
5671 RRULE:FREQ=YEARLY;COUNT=10;BYMONTH=6,7
5672 ==> (1997 9:00 AM EDT)June 10;July 10
5673 (1998 9:00 AM EDT)June 10;July 10
5674 (1999 9:00 AM EDT)June 10;July 10
5675 (2000 9:00 AM EDT)June 10;July 10
5676 (2001 9:00 AM EDT)June 10;July 10
5677 Note: Since none of the BYDAY, BYMONTHDAY or BYYEARDAY components
5678 are specified, the day is gotten from DTSTART
5680 Every other year on January, February, and March for 10
5681 occurrences:
5683 DTSTART;TZID=US-Eastern:19970310T090000
5684 RRULE:FREQ=YEARLY;INTERVAL=2;COUNT=10;BYMONTH=1,2,3
5686 ==> (1997 9:00 AM EST)March 10
5687 (1999 9:00 AM EST)January 10;February 10;March 10
5688 (2001 9:00 AM EST)January 10;February 10;March 10
5689 (2003 9:00 AM EST)January 10;February 10;March 10
5691 Every 3rd year on the 1st, 100th and 200th day for 10 occurrences:
5693 DTSTART;TZID=US-Eastern:19970101T090000
5694 RRULE:FREQ=YEARLY;INTERVAL=3;COUNT=10;BYYEARDAY=1,100,200
5696 ==> (1997 9:00 AM EST)January 1
5697 (1997 9:00 AM EDT)April 10;July 19
5698 (2000 9:00 AM EST)January 1
5699 (2000 9:00 AM EDT)April 9;July 18
5700 (2003 9:00 AM EST)January 1
5701 (2003 9:00 AM EDT)April 10;July 19
5702 (2006 9:00 AM EST)January 1
5704 Every 20th Monday of the year, forever:
5706 DTSTART;TZID=US-Eastern:19970519T090000
5707 RRULE:FREQ=YEARLY;BYDAY=20MO
5709 ==> (1997 9:00 AM EDT)May 19
5710 (1998 9:00 AM EDT)May 18
5711 (1999 9:00 AM EDT)May 17
5712 ...
5714 Monday of week number 20 (where the default start of the week is
5715 Monday), forever:
5717 DTSTART;TZID=US-Eastern:19970512T090000
5718 RRULE:FREQ=YEARLY;BYWEEKNO=20;BYDAY=MO
5720 ==> (1997 9:00 AM EDT)May 12
5721 (1998 9:00 AM EDT)May 11
5722 (1999 9:00 AM EDT)May 17
5723 ...
5725 Every Thursday in March, forever:
5727 DTSTART;TZID=US-Eastern:19970313T090000
5728 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=TH
5730 ==> (1997 9:00 AM EST)March 13,20,27
5731 (1998 9:00 AM EST)March 5,12,19,26
5732 (1999 9:00 AM EST)March 4,11,18,25
5733 ...
5735 Every Thursday, but only during June, July, and August, forever:
5737 DTSTART;TZID=US-Eastern:19970605T090000
5738 RRULE:FREQ=YEARLY;BYDAY=TH;BYMONTH=6,7,8
5740 ==> (1997 9:00 AM EDT)June 5,12,19,26;July 3,10,17,24,31;
5741 August 7,14,21,28
5742 (1998 9:00 AM EDT)June 4,11,18,25;July 2,9,16,23,30;
5743 August 6,13,20,27
5744 (1999 9:00 AM EDT)June 3,10,17,24;July 1,8,15,22,29;
5745 August 5,12,19,26
5746 ...
5748 Every Friday the 13th, forever:
5750 DTSTART;TZID=US-Eastern:19970902T090000
5751 EXDATE;TZID=US-Eastern:19970902T090000
5752 RRULE:FREQ=MONTHLY;BYDAY=FR;BYMONTHDAY=13
5754 ==> (1998 9:00 AM EST)February 13;March 13;November 13
5755 (1999 9:00 AM EDT)August 13
5756 (2000 9:00 AM EDT)October 13
5757 ...
5759 The first Saturday that follows the first Sunday of the month,
5760 forever:
5762 DTSTART;TZID=US-Eastern:19970913T090000
5763 RRULE:FREQ=MONTHLY;BYDAY=SA;BYMONTHDAY=7,8,9,10,11,12,13
5765 ==> (1997 9:00 AM EDT)September 13;October 11
5766 (1997 9:00 AM EST)November 8;December 13
5767 (1998 9:00 AM EST)January 10;February 7;March 7
5768 (1998 9:00 AM EDT)April 11;May 9;June 13...
5769 ...
5771 Every four years, the first Tuesday after a Monday in November,
5772 forever (U.S. Presidential Election day):
5774 DTSTART;TZID=US-Eastern:19961105T090000
5775 RRULE:FREQ=YEARLY;INTERVAL=4;BYMONTH=11;BYDAY=TU;BYMONTHDAY=2,3,4,
5776 5,6,7,8
5778 ==> (1996 9:00 AM EST)November 5
5779 (2000 9:00 AM EST)November 7
5780 (2004 9:00 AM EST)November 2
5781 ...
5783 The 3rd instance into the month of one of Tuesday, Wednesday or
5784 Thursday, for the next 3 months:
5786 DTSTART;TZID=US-Eastern:19970904T090000
5787 RRULE:FREQ=MONTHLY;COUNT=3;BYDAY=TU,WE,TH;BYSETPOS=3
5789 ==> (1997 9:00 AM EDT)September 4;October 7
5790 (1997 9:00 AM EST)November 6
5792 The 2nd to last weekday of the month:
5794 DTSTART;TZID=US-Eastern:19970929T090000
5795 RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-2
5797 ==> (1997 9:00 AM EDT)September 29
5798 (1997 9:00 AM EST)October 30;November 27;December 30
5799 (1998 9:00 AM EST)January 29;February 26;March 30
5800 ...
5802 Every 3 hours from 9:00 AM to 5:00 PM on a specific day:
5804 DTSTART;TZID=US-Eastern:19970902T090000
5805 RRULE:FREQ=HOURLY;INTERVAL=3;UNTIL=19970902T170000Z
5806 ==> (September 2, 1997 EDT)09:00,12:00,15:00
5808 Every 15 minutes for 6 occurrences:
5810 DTSTART;TZID=US-Eastern:19970902T090000
5811 RRULE:FREQ=MINUTELY;INTERVAL=15;COUNT=6
5813 ==> (September 2, 1997 EDT)09:00,09:15,09:30,09:45,10:00,10:15
5815 Every hour and a half for 4 occurrences:
5817 DTSTART;TZID=US-Eastern:19970902T090000
5818 RRULE:FREQ=MINUTELY;INTERVAL=90;COUNT=4
5820 ==> (September 2, 1997 EDT)09:00,10:30;12:00;13:30
5822 Every 20 minutes from 9:00 AM to 4:40 PM every day:
5824 DTSTART;TZID=US-Eastern:19970902T090000
5825 RRULE:FREQ=DAILY;BYHOUR=9,10,11,12,13,14,15,16;BYMINUTE=0,20,40
5826 or
5827 RRULE:FREQ=MINUTELY;INTERVAL=20;BYHOUR=9,10,11,12,13,14,15,16
5829 ==> (September 2, 1997 EDT)9:00,9:20,9:40,10:00,10:20,
5830 ... 16:00,16:20,16:40
5831 (September 3, 1997 EDT)9:00,9:20,9:40,10:00,10:20,
5832 ...16:00,16:20,16:40
5833 ...
5835 An example where the days generated makes a difference because of
5836 WKST:
5838 DTSTART;TZID=US-Eastern:19970805T090000
5839 RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=4;BYDAY=TU,SU;WKST=MO
5841 ==> (1997 EDT)Aug 5,10,19,24
5843 changing only WKST from MO to SU, yields different results...
5845 DTSTART;TZID=US-Eastern:19970805T090000
5846 RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=4;BYDAY=TU,SU;WKST=SU
5847 ==> (1997 EDT)August 5,17,19,31
5849 3.8.6. Alarm Component Properties
5851 The following properties specify alarm information in calendar
5852 components.
5854 3.8.6.1. Action
5856 Property Name: ACTION
5858 Purpose: This property defines the action to be invoked when an alarm
5859 is triggered.
5861 Value Type: TEXT
5863 Property Parameters: Non-standard property parameters can be
5864 specified on this property.
5866 Conformance: This property MUST be specified once in a "VALARM"
5867 calendar component.
5869 Description: Each "VALARM" calendar component has a particular type
5870 of action associated with it. This property specifies the type of
5871 action
5873 Format Definition: The property is defined by the following notation:
5875 action = "ACTION" actionparam ":" actionvalue CRLF
5877 actionparam = *(";" xparam)
5879 actionvalue = "AUDIO" / "DISPLAY" / "EMAIL" / "PROCEDURE"
5880 / iana-token / x-name
5882 Example: The following are examples of this property in a "VALARM"
5883 calendar component:
5885 ACTION:AUDIO
5887 ACTION:DISPLAY
5889 ACTION:PROCEDURE
5891 3.8.6.2. Repeat Count
5893 Property Name: REPEAT
5895 Purpose: This property defines the number of time the alarm should be
5896 repeated, after the initial trigger.
5898 Value Type: INTEGER
5899 Property Parameters: Non-standard property parameters can be
5900 specified on this property.
5902 Conformance: This property can be specified in a "VALARM" calendar
5903 component.
5905 Description: If the alarm triggers more than once, then this property
5906 MUST be specified along with the "DURATION" property.
5908 Format Definition: The property is defined by the following notation:
5910 repeatcnt = "REPEAT" repparam ":" integer CRLF
5911 ;Default is "0", zero.
5913 repparam = *(";" xparam)
5915 Example: The following is an example of this property for an alarm
5916 that repeats 4 additional times with a 5 minute delay after the
5917 initial triggering of the alarm:
5919 REPEAT:4
5920 DURATION:PT5M
5922 3.8.6.3. Trigger
5924 Property Name: TRIGGER
5926 Purpose: This property specifies when an alarm will trigger.
5928 Value Type: The default value type is DURATION. The value type can
5929 be set to a DATE-TIME value type, in which case the value MUST
5930 specify a UTC formatted DATE-TIME value.
5932 Property Parameters: Non-standard, value data type, time zone
5933 identifier or trigger relationship property parameters can be
5934 specified on this property. The trigger relationship property
5935 parameter MUST only be specified when the value type is DURATION.
5937 Conformance: This property MUST be specified in the "VALARM" calendar
5938 component.
5940 Description: Within the "VALARM" calendar component, this property
5941 defines when the alarm will trigger. The default value type is
5942 DURATION, specifying a relative time for the trigger of the alarm.
5943 The default duration is relative to the start of an event or to-do
5944 that the alarm is associated with. The duration can be explicitly
5945 set to trigger from either the end or the start of the associated
5946 event or to-do with the "RELATED" parameter. A value of START
5947 will set the alarm to trigger off the start of the associated
5948 event or to-do. A value of END will set the alarm to trigger off
5949 the end of the associated event or to-do.
5951 Either a positive or negative duration may be specified for the
5952 "TRIGGER" property. An alarm with a positive duration is
5953 triggered after the associated start or end of the event or to-do.
5954 An alarm with a negative duration is triggered before the
5955 associated start or end of the event or to-do.
5957 The "RELATED" property parameter is not valid if the value type of
5958 the property is set to DATE-TIME (i.e., for an absolute date and
5959 time alarm trigger). If a value type of DATE-TIME is specified,
5960 then the property value MUST be specified in the UTC time format.
5961 If an absolute trigger is specified on an alarm for a recurring
5962 event or to-do, then the alarm will only trigger for the specified
5963 absolute date/time, along with any specified repeating instances.
5965 If the trigger is set relative to START, then the "DTSTART"
5966 property MUST be present in the associated "VEVENT" or "VTODO"
5967 calendar component. If an alarm is specified for an event with
5968 the trigger set relative to the END, then the "DTEND" property or
5969 the "DTSTART" and "DURATION " properties MUST be present in the
5970 associated "VEVENT" calendar component. If the alarm is specified
5971 for a to-do with a trigger set relative to the END, then either
5972 the "DUE" property or the "DTSTART" and "DURATION " properties
5973 MUST be present in the associated "VTODO" calendar component.
5975 Alarms specified in an event or to-do which is defined in terms of
5976 a DATE value type will be triggered relative to 00:00:00 UTC on
5977 the specified date. For example, if DTSTART is a DATE value set
5978 to 19980205 then the duration trigger will be relative to
5979 19980205T000000Z.
5981 Format Definition: The property is defined by the following notation:
5983 trigger = "TRIGGER" (trigrel / trigabs) CRLF
5985 trigrel = *(
5987 ; the following are optional,
5988 ; but MUST NOT occur more than once
5990 (";" "VALUE" "=" "DURATION") /
5991 (";" trigrelparam) /
5993 ; the following is optional,
5994 ; and MAY occur more than once
5996 (";" xparam)
5997 ) ":" dur-value
5999 trigabs = 1*(
6001 ; the following is REQUIRED,
6002 ; but MUST NOT occur more than once
6004 (";" "VALUE" "=" "DATE-TIME") /
6006 ; the following is optional,
6007 ; and MAY occur more than once
6009 (";" xparam)
6011 ) ":" date-time
6013 Example: A trigger set 15 minutes prior to the start of the event or
6014 to-do.
6016 TRIGGER:-P15M
6018 A trigger set 5 minutes after the end of the event or to-do.
6020 TRIGGER;RELATED=END:P5M
6022 A trigger set to an absolute date/time.
6024 TRIGGER;VALUE=DATE-TIME:19980101T050000Z
6026 3.8.7. Change Management Component Properties
6028 The following properties specify change management information in
6029 calendar components.
6031 3.8.7.1. Date/Time Created
6033 Property Name: CREATED
6035 Purpose: This property specifies the date and time that the calendar
6036 information was created by the calendar user agent in the calendar
6037 store.
6039 Note: This is analogous to the creation date and time for a
6040 file in the file system.
6042 Value Type: DATE-TIME
6044 Property Parameters: Non-standard property parameters can be
6045 specified on this property.
6047 Conformance: The property can be specified once in "VEVENT", "VTODO"
6048 or "VJOURNAL" calendar components.
6050 Description: The date and time is a UTC value.
6052 Format Definition: The property is defined by the following notation:
6054 created = "CREATED" creaparam ":" date-time CRLF
6056 creaparam = *(";" xparam)
6058 Example: The following is an example of this property:
6060 CREATED:19960329T133000Z
6062 3.8.7.2. Date/Time Stamp
6064 Property Name: DTSTAMP
6066 Purpose: The property indicates the date/time that the instance of
6067 the iCalendar object was created.
6069 Value Type: DATE-TIME
6071 Property Parameters: Non-standard property parameters can be
6072 specified on this property.
6074 Conformance: This property MUST be included in the "VEVENT", "VTODO",
6075 "VJOURNAL" or "VFREEBUSY" calendar components.
6077 Description: The value MUST be specified in the UTC time format.
6079 This property is also useful to protocols such as [I-D.ietf-
6080 calsify-rfc2447bis] that have inherent latency issues with the
6081 delivery of content. This property will assist in the proper
6082 sequencing of messages containing iCalendar objects.
6084 This property is different than the "CREATED" and "LAST-MODIFIED"
6085 properties. These two properties are used to specify when the
6086 particular calendar data in the calendar store was created and
6087 last modified. This is different than when the iCalendar object
6088 representation of the calendar service information was created or
6089 last modified.
6091 Format Definition: The property is defined by the following notation:
6093 dtstamp = "DTSTAMP" stmparam ":" date-time CRLF
6095 stmparam = *(";" xparam)
6097 Example:
6099 DTSTAMP:19971210T080000Z
6101 3.8.7.3. Last Modified
6103 Property Name: LAST-MODIFIED
6105 Purpose: The property specifies the date and time that the
6106 information associated with the calendar component was last
6107 revised in the calendar store.
6109 Note: This is analogous to the modification date and time for a
6110 file in the file system.
6112 Value Type: DATE-TIME
6114 Property Parameters: Non-standard property parameters can be
6115 specified on this property.
6117 Conformance: This property can be specified in the "EVENT", "VTODO",
6118 "VJOURNAL" or "VTIMEZONE" calendar components.
6120 Description: The property value MUST be specified in the UTC time
6121 format.
6123 Format Definition: The property is defined by the following notation:
6125 last-mod = "LAST-MODIFIED" lstparam ":" date-time CRLF
6127 lstparam = *(";" xparam)
6129 Example: The following are examples of this property:
6131 LAST-MODIFIED:19960817T133000Z
6133 3.8.7.4. Sequence Number
6135 Property Name: SEQUENCE
6137 Purpose: This property defines the revision sequence number of the
6138 calendar component within a sequence of revisions.
6140 Value Type: INTEGER
6142 Property Parameters: Non-standard property parameters can be
6143 specified on this property.
6145 Conformance: The property can be specified in "VEVENT", "VTODO" or
6146 "VJOURNAL" calendar component.
6148 Description: When a calendar component is created, its sequence
6149 number is zero (US-ASCII decimal 48). It is monotonically
6150 incremented by the "Organizer's" CUA each time the "Organizer"
6151 makes a significant revision to the calendar component. When the
6152 "Organizer" makes changes to one of the following properties, the
6153 sequence number MUST be incremented:
6155 * "DTSTART"
6157 * "DTEND"
6159 * "DURATION"
6161 * "DUE"
6163 * "RDATE"
6165 * "RRULE"
6167 * "EXDATE"
6169 * "EXRULE"
6170 * "STATUS"
6172 In addition, changes made by the "Organizer" to other properties
6173 can also force the sequence number to be incremented. The
6174 "Organizer" CUA MUST increment the sequence number when ever it
6175 makes changes to properties in the calendar component that the
6176 "Organizer" deems will jeopardize the validity of the
6177 participation status of the "Attendees". For example, changing
6178 the location of a meeting from one locale to another distant
6179 locale could effectively impact the participation status of the
6180 "Attendees".
6182 The "Organizer" includes this property in an iCalendar object that
6183 it sends to an "Attendee" to specify the current version of the
6184 calendar component.
6186 The "Attendee" includes this property in an iCalendar object that
6187 it sends to the "Organizer" to specify the version of the calendar
6188 component that the "Attendee" is referring to.
6190 A change to the sequence number is not the mechanism that an
6191 "Organizer" uses to request a response from the "Attendees". The
6192 "RSVP" parameter on the "ATTENDEE" property is used by the
6193 "Organizer" to indicate that a response from the "Attendees" is
6194 requested.
6196 Format Definition: The property is defined by the following notation:
6198 seq = "SEQUENCE" seqparam ":" integer CRLF
6199 ; Default is "0"
6201 seqparam = *(";" xparam)
6203 Example: The following is an example of this property for a calendar
6204 component that was just created by the "Organizer".
6206 SEQUENCE:0
6208 The following is an example of this property for a calendar
6209 component that has been revised two different times by the
6210 "Organizer".
6212 SEQUENCE:2
6214 3.8.8. Miscellaneous Component Properties
6216 The following properties specify information about a number of
6217 miscellaneous features of calendar components.
6219 3.8.8.1. Non-standard Properties
6221 Property Name: Any property name with a "X-" prefix
6223 Purpose: This class of property provides a framework for defining
6224 non-standard properties.
6226 Value Type: TEXT
6228 Property Parameters: Non-standard and language property parameters
6229 can be specified on this property.
6231 Conformance: This property can be specified in any calendar
6232 component.
6234 Description: The MIME Calendaring and Scheduling Content Type
6235 provides a "standard mechanism for doing non-standard things".
6236 This extension support is provided for implementers to "push the
6237 envelope" on the existing version of the memo. Extension
6238 properties are specified by property and/or property parameter
6239 names that have the prefix text of "X-" (the two character
6240 sequence: LATIN CAPITAL LETTER X character followed by the HYPHEN-
6241 MINUS character). It is recommended that vendors concatenate onto
6242 this sentinel another short prefix text to identify the vendor.
6243 This will facilitate readability of the extensions and minimize
6244 possible collision of names between different vendors. User
6245 agents that support this content type are expected to be able to
6246 parse the extension properties and property parameters but can
6247 ignore them.
6249 At present, there is no registration authority for names of
6250 extension properties and property parameters. The data type for
6251 this property is TEXT. Optionally, the data type can be any of
6252 the other valid data types.
6254 Format Definition: The property is defined by the following notation:
6256 x-prop = x-name *(";" xparam) [";" languageparam] ":" text CRLF
6257 ; Lines longer than 75 octets should be folded
6259 Example: The following might be the ABC vendor's extension for an
6260 audio-clip form of subject property:
6262 X-ABC-MMSUBJ;X-ABC-MMSUBJTYPE=wave:http://load.noise.org/mysubj.wav
6264 3.8.8.2. Request Status
6266 Property Name: REQUEST-STATUS
6268 Purpose: This property defines the status code returned for a
6269 scheduling request.
6271 Value Type: TEXT
6273 Property Parameters: Non-standard and language property parameters
6274 can be specified on this property.
6276 Conformance: The property can be specified in "VEVENT", "VTODO",
6277 "VJOURNAL" or "VFREEBUSY" calendar component.
6279 Description: This property is used to return status code information
6280 related to the processing of an associated iCalendar object. The
6281 data type for this property is TEXT.
6283 The value consists of a short return status component, a longer
6284 return status description component, and optionally a status-
6285 specific data component. The components of the value are
6286 separated by the SEMICOLON character (US-ASCII decimal 59).
6288 The short return status is a PERIOD character (US-ASCII decimal
6289 46) separated 3-tuple of integers. For example, "3.1.1". The
6290 successive levels of integers provide for a successive level of
6291 status code granularity.
6293 The following are initial classes for the return status code.
6294 Individual iCalendar object methods will define specific return
6295 status codes for these classes. In addition, other classes for
6296 the return status code may be defined using the registration
6297 process defined later in this memo.
6299 |==============+===============================================|
6300 | Short Return | Longer Return Status Description |
6301 | Status Code | |
6302 |==============+===============================================|
6303 | 1.xx | Preliminary success. This class of status |
6304 | | of status code indicates that the request has |
6305 | | request has been initially processed but that |
6306 | | completion is pending. |
6307 |==============+===============================================|
6308 | 2.xx | Successful. This class of status code |
6309 | | indicates that the request was completed |
6310 | | successfuly. However, the exact status code |
6311 | | can indicate that a fallback has been taken. |
6312 |==============+===============================================|
6313 | 3.xx | Client Error. This class of status code |
6314 | | indicates that the request was not successful.|
6315 | | The error is the result of either a syntax or |
6316 | | a semantic error in the client formatted |
6317 | | request. Request should not be retried until |
6318 | | the condition in the request is corrected. |
6319 |==============+===============================================|
6320 | 4.xx | Scheduling Error. This class of status code |
6321 | | indicates that the request was not successful.|
6322 | | Some sort of error occurred within the |
6323 | | calendaring and scheduling service, not |
6324 | | directly related to the request itself. |
6325 |==============+===============================================|
6327 Format Definition: The property is defined by the following notation:
6329 rstatus = "REQUEST-STATUS" rstatparam ":"
6330 statcode ";" statdesc [";" extdata]
6332 rstatparam = *(
6334 ; the following is optional,
6335 ; but MUST NOT occur more than once
6337 (";" languageparm) /
6339 ; the following is optional,
6340 ; and MAY occur more than once
6342 (";" xparam)
6344 )
6346 statcode = 1*DIGIT *("." 1*DIGIT)
6347 ;Hierarchical, numeric return status code
6349 statdesc = text
6350 ;Textual status description
6352 extdata = text
6353 ;Textual exception data. For example, the offending property
6354 ;name and value or complete property line.
6356 Example: The following are some possible examples of this property.
6358 The COMMA and SEMICOLON separator characters in the property value
6359 are BACKSLASH character escaped because they appear in a text
6360 value.
6362 REQUEST-STATUS:2.0;Success
6364 REQUEST-STATUS:3.1;Invalid property value;DTSTART:96-Apr-01
6366 REQUEST-STATUS:2.8; Success\, repeating event ignored. Scheduled
6367 as a single event.;RRULE:FREQ=WEEKLY\;INTERVAL=2
6369 REQUEST-STATUS:4.1;Event conflict. Date/time is busy.
6371 REQUEST-STATUS:3.7;Invalid calendar user;ATTENDEE:
6372 MAILTO:jsmith@example.com
6374 4. iCalendar Object Examples
6376 The following examples are provided as an informational source of
6377 illustrative iCalendar objects consistent with this content type.
6379 The following example specifies a three-day conference that begins at
6380 8:00 AM EDT, September 18, 1996 and end at 6:00 PM EDT, September 20,
6381 1996.
6383 BEGIN:VCALENDAR
6384 PRODID:-//xyz Corp//NONSGML PDA Calendar Version 1.0//EN
6385 VERSION:2.0
6386 BEGIN:VEVENT
6387 DTSTAMP:19960704T120000Z
6388 UID:uid1@example.com
6389 ORGANIZER:MAILTO:jsmith@example.com
6390 DTSTART:19960918T143000Z
6391 DTEND:19960920T220000Z
6392 STATUS:CONFIRMED
6393 CATEGORIES:CONFERENCE
6394 SUMMARY:Networld+Interop Conference
6395 DESCRIPTION:Networld+Interop Conference
6396 and Exhibit\nAtlanta World Congress Center\n
6397 Atlanta\, Georgia
6398 END:VEVENT
6399 END:VCALENDAR
6401 The following example specifies a group scheduled meeting that begin
6402 at 8:30 AM EST on March 12, 1998 and end at 9:30 AM EST on March 12,
6403 1998. The "Organizer" has scheduled the meeting with one or more
6404 calendar users in a group. A time zone specification for Eastern
6405 United States has been specified.
6407 BEGIN:VCALENDAR
6408 PRODID:-//RDU Software//NONSGML HandCal//EN
6409 VERSION:2.0
6410 BEGIN:VTIMEZONE
6411 TZID:US-Eastern
6412 BEGIN:STANDARD
6413 DTSTART:19981025T020000
6414 RDATE:19981025T020000
6415 TZOFFSETFROM:-0400
6416 TZOFFSETTO:-0500
6417 TZNAME:EST
6418 END:STANDARD
6419 BEGIN:DAYLIGHT
6420 DTSTART:19990404T020000
6421 RDATE:19990404T020000
6422 TZOFFSETFROM:-0500
6423 TZOFFSETTO:-0400
6424 TZNAME:EDT
6425 END:DAYLIGHT
6426 END:VTIMEZONE
6427 BEGIN:VEVENT
6428 DTSTAMP:19980309T231000Z
6429 UID:guid-1.example.com
6430 ORGANIZER;ROLE=CHAIR:MAILTO:mrbig@example.com
6431 ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;CUTYPE=GROUP:
6432 MAILTO:employee-A@example.com
6433 DESCRIPTION:Project XYZ Review Meeting
6434 CATEGORIES:MEETING
6435 CLASS:PUBLIC
6436 CREATED:19980309T130000Z
6437 SUMMARY:XYZ Project Review
6438 DTSTART;TZID=US-Eastern:19980312T083000
6439 DTEND;TZID=US-Eastern:19980312T093000
6440 LOCATION:1CP Conference Room 4350
6441 END:VEVENT
6442 END:VCALENDAR
6444 The following is an example of an iCalendar object passed in a MIME
6445 message with a single body part consisting of a "text/calendar"
6446 Content Type.
6448 TO:jsmith@example.com
6449 FROM:jdoe@example.com
6450 MIME-VERSION:1.0
6451 MESSAGE-ID:
6452 CONTENT-TYPE:text/calendar; method="xyz"; component="VEVENT"
6454 BEGIN:VCALENDAR
6455 METHOD:xyz
6456 VERSION:2.0
6457 PRODID:-//ABC Corporation//NONSGML My Product//EN
6458 BEGIN:VEVENT
6459 DTSTAMP:19970324T120000Z
6460 SEQUENCE:0
6461 UID:uid3@example.com
6462 ORGANIZER:MAILTO:jdoe@example.com
6463 ATTENDEE;RSVP=TRUE:MAILTO:jsmith@example.com
6464 DTSTART:19970324T123000Z
6465 DTEND:19970324T210000Z
6466 CATEGORIES:MEETING,PROJECT
6467 CLASS:PUBLIC
6468 SUMMARY:Calendaring Interoperability Planning Meeting
6469 DESCRIPTION:Discuss how we can test c&s interoperability\n
6470 using iCalendar and other IETF standards.
6471 LOCATION:LDB Lobby
6472 ATTACH;FMTTYPE=application/postscript:ftp://example.com/pub/
6473 conf/bkgrnd.ps
6474 END:VEVENT
6475 END:VCALENDAR
6477 The following is an example of a to-do due on April 15, 1998. An
6478 audio alarm has been specified to remind the calendar user at noon,
6479 the day before the to-do is expected to be completed and repeat
6480 hourly, four additional times. The to-do definition has been
6481 modified twice since it was initially created.
6483 BEGIN:VCALENDAR
6484 VERSION:2.0
6485 PRODID:-//ABC Corporation//NONSGML My Product//EN
6486 BEGIN:VTODO
6487 DTSTAMP:19980130T134500Z
6488 SEQUENCE:2
6489 UID:uid4@example.com
6490 ORGANIZER:MAILTO:unclesam@us.gov
6491 ATTENDEE;PARTSTAT=ACCEPTED:MAILTO:jqpublic@example.com
6492 DUE:19980415T235959
6493 STATUS:NEEDS-ACTION
6494 SUMMARY:Submit Income Taxes
6495 BEGIN:VALARM
6496 ACTION:AUDIO
6497 TRIGGER:19980403T120000Z
6498 ATTACH;FMTTYPE=audio/basic:http://example.com/pub/audio-
6499 files/ssbanner.aud
6500 REPEAT:4
6501 DURATION:PT1H
6502 END:VALARM
6503 END:VTODO
6504 END:VCALENDAR
6506 The following is an example of a journal entry.
6508 BEGIN:VCALENDAR
6509 VERSION:2.0
6510 PRODID:-//ABC Corporation//NONSGML My Product//EN
6511 BEGIN:VJOURNAL
6512 DTSTAMP:19970324T120000Z
6513 UID:uid5@example.com
6514 ORGANIZER:MAILTO:jsmith@example.com
6515 STATUS:DRAFT
6516 CLASS:PUBLIC
6517 CATEGORIES:Project Report,XYZ,Weekly Meeting
6518 DESCRIPTION:Project xyz Review Meeting Minutes\n
6519 Agenda\n1. Review of project version 1.0 requirements.\n2.
6520 Definition
6521 of project processes.\n3. Review of project schedule.\n
6522 Participants: John Smith\, Jane Doe\, Jim Dandy\n-It was
6523 decided that the requirements need to be signed off by
6524 product marketing.\n-Project processes were accepted.\n
6525 -Project schedule needs to account for scheduled holidays
6526 and employee vacation time. Check with HR for specific
6527 dates.\n-New schedule will be distributed by Friday.\n-
6528 Next weeks meeting is cancelled. No meeting until 3/23.
6529 END:VJOURNAL
6530 END:VCALENDAR
6532 The following is an example of published busy time information. The
6533 iCalendar object might be placed in the network resource
6534 http://www.example.com/calendar/busytime/jsmith.ifb.
6536 BEGIN:VCALENDAR
6537 VERSION:2.0
6538 PRODID:-//RDU Software//NONSGML HandCal//EN
6539 BEGIN:VFREEBUSY
6540 ORGANIZER:MAILTO:jsmith@example.com
6541 DTSTART:19980313T141711Z
6542 DTEND:19980410T141711Z
6543 FREEBUSY:19980314T233000Z/19980315T003000Z
6544 FREEBUSY:19980316T153000Z/19980316T163000Z
6545 FREEBUSY:19980318T030000Z/19980318T040000Z
6546 URL:http://www.example.com/calendar/busytime/jsmith.ifb
6547 END:VFREEBUSY
6548 END:VCALENDAR
6550 5. Recommended Practices
6552 These recommended practices should be followed in order to assure
6553 consistent handling of the following cases for an iCalendar object.
6555 1. Content lines longer than 75 octets SHOULD be folded.
6557 2. A calendar entry with a "DTSTART" property but no "DTEND"
6558 property does not take up any time. It is intended to represent
6559 an event that is associated with a given calendar date and time
6560 of day, such as an anniversary. Since the event does not take
6561 up any time, it MUST NOT be used to record busy time no matter
6562 what the value for the "TRANSP" property.
6564 3. When the "DTSTART" and "DTEND", for "VEVENT", "VJOURNAL" and
6565 "VFREEBUSY" calendar components, and "DTSTART" and "DUE", for
6566 "VTODO" calendar components, have the same value data type
6567 (e.g., DATE-TIME), they SHOULD specify values in the same time
6568 format (e.g., UTC time format).
6570 4. When the combination of the "RRULE" and "RDATE" properties on an
6571 iCalendar object produces multiple instances having the same
6572 start date/time, they should be collapsed to, and considered as,
6573 a single instance.
6575 5. When a calendar user receives multiple requests for the same
6576 calendar component (e.g., REQUEST for a "VEVENT" calendar
6577 component) as a result of being on multiple mailing lists
6578 specified by "ATTENDEE" properties in the request, they SHOULD
6579 respond to only one of the requests. The calendar user SHOULD
6580 also specify (using the "MEMBER" parameter of the "ATTENDEE"
6581 property) which mailing list they are a member of.
6583 6. An implementation can truncate a "SUMMARY" property value to 255
6584 octets, but MUST NOT truncate the value in the middle of a UTF-8
6585 multi-octet sequence .
6587 7. If seconds of the minute are not supported by an implementation,
6588 then a value of "00" SHOULD be specified for the seconds
6589 component in a time value.
6591 8. If the value type parameter (VALUE=) contains an unknown value
6592 type, it SHOULD be treated as TEXT.
6594 9. TZURL values SHOULD NOT be specified as a FILE URI type. This
6595 URI form can be useful within an organization, but is
6596 problematic in the Internet.
6598 10. Some possible English values for CATEGORIES property include
6599 "ANNIVERSARY", "APPOINTMENT", "BUSINESS", "EDUCATION",
6600 "HOLIDAY", "MEETING", "MISCELLANEOUS", "NON-WORKING HOURS", "NOT
6601 IN OFFICE", "PERSONAL", "PHONE CALL", "SICK DAY", "SPECIAL
6602 OCCASION", "TRAVEL", "VACATION". Categories can be specified in
6603 any registered language.
6605 11. Some possible English values for RESOURCES property include
6606 "CATERING", "CHAIRS", "COMPUTER PROJECTOR", "EASEL", "OVERHEAD
6607 PROJECTOR", "SPEAKER PHONE", "TABLE", "TV", "VCR", "VIDEO
6608 PHONE", "VEHICLE". Resources can be specified in any registered
6609 language.
6611 6. Registration of Content Type Elements
6613 This section provides the process for registration of MIME
6614 Calendaring and Scheduling Content Type iCalendar object methods and
6615 new or modified properties.
6617 6.1. Registration of New and Modified iCalendar Object Methods
6619 New MIME Calendaring and Scheduling Content Type iCalendar object
6620 methods are registered by the publication of an IETF Request for
6621 Comments (RFC). Changes to an iCalendar object method are registered
6622 by the publication of a revision of the RFC defining the method.
6624 6.2. Registration of New Properties
6626 This section defines procedures by which new properties or enumerated
6627 property values for the MIME Calendaring and Scheduling Content Type
6628 can be registered with the IANA. Non-IANA properties can be used by
6629 bilateral agreement, provided the associated properties names follow
6630 the "X-" convention.
6632 The procedures defined here are designed to allow public comment and
6633 review of new properties, while posing only a small impediment to the
6634 definition of new properties.
6636 Registration of a new property is accomplished by the following
6637 steps.
6639 6.2.1. Define the property
6641 A property is defined by completing the following template.
6643 To: ietf-calendar@imc.org
6645 Subject: Registration of text/calendar MIME property XXX
6647 Property name:
6649 Property purpose:
6651 Property value type(s):
6653 Property parameter (s):
6655 Conformance:
6657 Description:
6659 Format definition:
6661 Examples:
6663 The meaning of each field in the template is as follows.
6665 Property name: The name of the property, as it will appear in the
6666 body of an text/calendar MIME Content-Type "property: value" line
6667 to the left of the colon ":".
6669 Property purpose: The purpose of the property (e.g., to indicate a
6670 delegate for the event or to-do, etc.). Give a short but clear
6671 description.
6673 Property value type (s): Any of the valid value types for the
6674 property value needs to be specified. The default value type also
6675 needs to be specified. If a new value type is specified, it needs
6676 to be declared in this section.
6678 Property parameter (s): Any of the valid property parameters for the
6679 property needs to be specified.
6681 Conformance: The calendar components that the property can appear in
6682 needs to be specified.
6684 Description: Any special notes about the property, how it is to be
6685 used, etc.
6687 Format definition: The ABNF for the property definition needs to be
6688 specified.
6690 Examples: One or more examples of instances of the property needs to
6691 be specified.
6693 6.2.2. Post the Property definition
6695 The property description MUST be posted to the new property
6696 discussion list, ietf-calendar@imc.org.
6698 6.2.3. Allow a comment period
6700 Discussion on the new property MUST be allowed to take place on the
6701 list for a minimum of two weeks. Consensus MUST be reached on the
6702 property before proceeding to the next step.
6704 6.2.4. Submit the property for approval
6706 Once the two-week comment period has elapsed, and the proposer is
6707 convinced consensus has been reached on the property, the
6708 registration application should be submitted to the Method Reviewer
6709 for approval. The Method Reviewer is appointed by the Application
6710 Area Directors and can either accept or reject the property
6711 registration. An accepted registration should be passed on by the
6712 Method Reviewer to the IANA for inclusion in the official IANA method
6713 registry. The registration can be rejected for any of the following
6714 reasons. 1) Insufficient comment period; 2) Consensus not reached; 3)
6715 Technical deficiencies raised on the list or elsewhere have not been
6716 addressed. The Method Reviewer's decision to reject a property can
6717 be appealed by the proposer to the IESG, or the objections raised can
6718 be addressed by the proposer and the property resubmitted.
6720 6.3. Property Change Control
6722 Existing properties can be changed using the same process by which
6723 they were registered.
6725 1. Define the change
6727 2. Post the change
6729 3. Allow a comment period
6731 4. Submit the property for approval
6733 Note that the original author or any other interested party can
6734 propose a change to an existing property, but that such changes
6735 should only be proposed when there are serious omissions or errors in
6736 the published memo. The Method Reviewer can object to a change if it
6737 is not backward compatible, but is not required to do so.
6739 Property definitions can never be deleted from the IANA registry, but
6740 properties which are no longer believed to be useful can be declared
6741 OBSOLETE by a change to their "intended use" field.
6743 7. Internationalization Considerations
6745 8. Security Considerations
6747 SPOOFING: In this memo, the "Organizer" is the only person authorized
6748 to make changes to an existing "VEVENT", "VTODO", "VJOURNAL"
6749 calendar component and redistribute the updates to the
6750 "Attendees". An iCalendar object that maliciously changes or
6751 cancels an existing "VEVENT", "VTODO" or "VJOURNAL" or "VFREEBUSY"
6752 calendar component might be constructed by someone other than the
6753 "Organizer" and sent to the "Attendees". In addition in this
6754 memo, other than the "Organizer", an "Attendee" of a "VEVENT",
6755 "VTODO", "VJOURNAL" calendar component is the only other person
6756 authorized to update any parameter associated with their
6757 "ATTENDEE" property and send it to the "Organizer". An iCalendar
6758 object that maliciously changes the "ATTENDEE" parameters can be
6759 constructed by someone other than the real "Attendee" and sent to
6760 the "Organizer".
6762 PROCEDURAL ALARMS: An iCalendar object can be created that contains a
6763 "VEVENT" and "VTODO" calendar component with "VALARM" calendar
6764 components. The "VALARM" calendar component can be of type
6765 PROCEDURE and can have an attachment containing some sort of
6766 executable program. Implementations that incorporate these types
6767 of alarms are subject to any virus or malicious attack that might
6768 occur as a result of executing the attachment.
6770 ATTACHMENTS: An iCalendar object can include references to Uniform
6771 Resource Locators that can be programmed resources.
6773 Implementers and users of this memo should be aware of the network
6774 security implications of accepting and parsing such information.
6775 In addition, the security considerations observed by
6776 implementations of electronic mail systems should be followed for
6777 this memo.
6779 9. IANA Consideration
6781 9.1. Media Type Registration Information
6783 The Calendaring and Scheduling Core Object Specification is intended
6784 for use as a MIME content type. However, the implementation of the
6785 memo is in no way limited solely as a MIME content type.
6787 To: ietf-types@iana.org
6788 Subject: Registration of media type text/calendar
6790 Type name: text
6792 Subtype name: calendar
6794 Required parameters: none
6796 Optional parameters: charset, method, component and optinfo
6798 The "charset" parameter is defined in [RFC2046] for subtypes of
6799 the "text" media type. It is used to indicate the charset used in
6800 the body part. The charset supported by this revision of
6801 iCalendar is UTF-8. The use of any other charset is deprecated by
6802 this revision of iCalendar; however note that this revision
6803 requires that compliant applications MUST accept iCalendar objects
6804 using either the UTF-8 or US-ASCII charset.
6806 The "method" parameter is used to convey the iCalendar object
6807 method or transaction semantics for the calendaring and scheduling
6808 information. It also is an identifier for the restricted set of
6809 properties and values that the iCalendar object consists of. The
6810 parameter is to be used as a guide for applications interpreting
6811 the information contained within the body part. It SHOULD NOT be
6812 used to exclude or require particular pieces of information unless
6813 the identified method definition specifically calls for this
6814 behavior. Unless specifically forbidden by a particular method
6815 definition, a text/calendar content type can contain any set of
6816 properties permitted by the Calendaring and Scheduling Core Object
6817 Specification. The "method" parameter MUST be the same value as
6818 that specified in the "METHOD" component property in the iCalendar
6819 object. If one is present, the other MUST also be present.
6821 The value for the "method" parameter is defined as follows:
6823 method = 1*(ALPHA / DIGIT / "-")
6824 ; IANA registered iCalendar object method
6826 The "component" parameter conveys the type of iCalendar calendar
6827 component within the body part. If the iCalendar object contains
6828 more than one calendar component type, then multiple component
6829 parameters MUST be specified.
6831 The value for the "component" parameter is defined as follows:
6833 component = "VEVENT"
6834 / "VTODO"
6835 / "VJOURNAL"
6836 / "VFREEBUSY"
6837 / "VTIMEZONE"
6838 / x-name
6839 / iana-token
6841 The "optinfo" parameter conveys optional information about the
6842 iCalendar object within the body part. This parameter can only
6843 specify semantics already specified by the iCalendar object and
6844 that can be otherwise determined by parsing the body part. In
6845 addition, the optional information specified by this parameter
6846 MUST be consistent with that information specified by the
6847 iCalendar object. For example, it can be used to convey the
6848 "Attendee" response status to a meeting request. The parameter
6849 value consists of a string value.
6851 The parameter can be specified multiple times.
6853 This parameter MAY only specify semantics already specified by the
6854 iCalendar object and that can be otherwise determined by parsing
6855 the body part.
6857 The value for the "optinfo" parameter is defined as follows:
6859 optinfo = infovalue / qinfovalue
6861 infovalue = iana-token / x-name
6863 qinfovalue = DQUOTE (infovalue) DQUOTE
6865 Encoding considerations: This media type can contain 8bit characters,
6866 so the use of quoted-printable or base64 MIME Content-Transfer-
6867 Encodings might be necessary when iCalendar objects are
6868 transferred across protocols restricted to the 7bit repertoire.
6869 Note that a text valued property in the content entity can also
6870 have content encoding of special characters using a BACKSLASH
6871 character (US-ASCII decimal 92) escapement technique. This means
6872 that content values can end up encoded twice.
6874 Security considerations: See Section 8.
6876 Interoperability considerations: This media type is intended to
6877 define a common format for conveying calendaring and scheduling
6878 information between different systems. It is heavily based on the
6879 earlier [VCAL] industry specification.
6881 Published specification: This specification.
6883 Applications which use this media type: This media type is designed
6884 for widespread use by Internet calendaring and scheduling
6885 applications. In addition, applications in the workflow and
6886 document management area might find this content-type applicable.
6887 The iTIP [I-D.ietf-calsify-2446bis], iMIP [I-D.ietf-calsify-
6888 rfc2447bis] and CalDAV [I-D.dusseault-caldav] Internet protocols
6889 directly use this media type also.
6891 Additional information:
6893 Magic number(s): None.
6895 File extension(s): The file extension of "ics" is to be used to
6896 designate a file containing (an arbitrary set of) calendaring
6897 and scheduling information consistent with this MIME content
6898 type.
6900 The file extension of "ifb" is to be used to designate a file
6901 containing free or busy time information consistent with this
6902 MIME content type.
6904 Macintosh file type code(s): The file type code of "iCal" is to be
6905 used in Apple MacIntosh operating system environments to
6906 designate a file containing calendaring and scheduling
6907 information consistent with this MIME media type.
6909 The file type code of "iFBf" is to be used in Apple MacIntosh
6910 operating system environments to designate a file containing
6911 free or busy time information consistent with this MIME media
6912 type.
6914 Person & email address to contact for further information: TBD
6916 Intended usage: COMMON
6918 Restrictions on usage: There are no restrictions on where this media
6919 type can be used.
6921 Author: TBD
6923 Change controller: IETF
6925 10. Acknowledgments
6927 The editor of this document wish to thank Frank Dawson and Stenerson
6928 Derik, the original authors of RFC2445, as well as the following
6929 individuals who have participated in the drafting, review and
6930 discussion of this memo:
6932 Joe Abley, Hervey Allen, Jay Batson, Oliver Block, Chris Bryant,
6933 Tantek Celik, Mark Crispin, Cyrus Daboo, Mike Douglass, Andrew N.
6934 Dowden, Lisa Dusseault, Ned Freed, Ted Hardie, Tim Hare, Jeffrey
6935 Harris, Helge Hess, Leif Johansson, Reinhold Kainhofer, Eliot Lear,
6936 Jeff McCullough, Bill McQuillan, Alexey Melnikov, Aki Niemi, John W.
6937 Noerenberg II, Chuck Norris, Mark Paterson, Simon Pilette, Arnaud
6938 Quillaud, Robert Ransdell, Julian F. Reschke, Caleb Richardson, Sam
6939 Roberts, George Sexton, Simon Vaillancourt, Michiel van Leeuwen, and
6940 Sandy Wills.
6942 The editor would also like to thank the Calendaring and Scheduling
6943 Consortium for advice with this specification, and for organizing
6944 interoperability testing events to help refine it.
6946 11. References
6948 11.1. Normative References
6950 [ISO.8601.1988]
6951 International Organization for Standardization, "Data
6952 elements and interchange formats - Information interchange
6953 - Representation of dates and times",
6954 .
6956 [ISO.9070.1991]
6957 International Organization for Standardization,
6958 "Information Technology_SGML Support Facilities --
6959 Registration Procedures for Public Text Owner Identifiers,
6960 Second Edition", April 1991, .
6963 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
6964 Extensions (MIME) Part One: Format of Internet Message
6965 Bodies", RFC 2045, November 1996.
6967 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
6968 Extensions (MIME) Part Two: Media Types", RFC 2046,
6969 November 1996.
6971 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
6972 Requirement Levels", BCP 14, RFC 2119, March 1997.
6974 [RFC2368] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto
6975 URL scheme", RFC 2368, July 1998.
6977 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
6978 April 2001.
6980 [RFC3066] Alvestrand, H., "Tags for the Identification of
6981 Languages", BCP 47, RFC 3066, January 2001.
6983 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
6984 10646", STD 63, RFC 3629, November 2003.
6986 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
6987 Resource Identifier (URI): Generic Syntax", STD 66,
6988 RFC 3986, January 2005.
6990 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
6991 Specifications: ABNF", RFC 4234, October 2005.
6993 11.2. Informative References
6995 [I-D.dusseault-caldav]
6996 Daboo, C., Desruisseaux, B., and L. Dusseault,
6997 "Calendaring Extensions to WebDAV (CalDAV)",
6998 draft-dusseault-caldav-15 (work in progress),
6999 September 2006.
7001 [I-D.ietf-calsify-2446bis]
7002 Daboo, C., "iCalendar Transport-Independent
7003 Interoperability Protocol (iTIP)",
7004 draft-ietf-calsify-2446bis-02 (work in progress),
7005 June 2006.
7007 [I-D.ietf-calsify-rfc2447bis]
7008 Melnikov, A., "iCalendar Message-Based Interoperability
7009 Protocol(iMIP)", draft-ietf-calsify-rfc2447bis-02 (work in
7010 progress), June 2006.
7012 [RFC2425] Howes, T., Smith, M., and F. Dawson, "A MIME Content-Type
7013 for Directory Information", RFC 2425, September 1998.
7015 [RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile",
7016 RFC 2426, September 1998.
7018 [TZDB] "Time zone code and data", October 2005,
7019 .
7021 [VCAL] Internet Mail Consortium, "vCalendar: The Electronic
7022 Calendaring and Scheduling Exchange Format",
7023 September 1996, .
7025 URIs
7027 [1]
7029 Appendix A. Change Log (to be removed by RFC Editor before publication)
7031 A.1. Changes in -02
7033 A detailed list of changes is available at the following page:
7034 http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/
7035 draft-ietf-calsify-rfc2445bis-02.html.
7037 a. Numerous editorial changes including the typos listed in the
7038 "RFC2445 Errata":
7039 http://www.rfc-editor.org/cgi-bin/errataSearch.pl?rfc=2445&
7040 and in the "RFC2445 Issues List":
7041 http://www.softwarestudio.org/iCal/2445Issues.html.
7043 b. Clarified line folding requirements.
7045 c. Clarified charset requirements.
7047 d. Clarified line limits requirements.
7049 e. Clarified on the use of the LANGUAGE parameter.
7051 f. Fixed the eventprop, todoprop and jourprop ABNF rules with
7052 respect to required properties.
7054 g. Fixed all the examples to use RFC2606-compliant FQDNs.
7056 h. Fixed the Content-ID URLs in the examples.
7058 i. Fixed the LDAP URLs in the examples.
7060 j. Moved multiple references in the Informative References section.
7062 k. Updated the Acknowledgments section.
7064 A.2. Changes in -01
7066 A detailed list of changes is available at the following page:
7067 http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/
7068 draft-ietf-calsify-rfc2445bis-01.html.
7070 a. Numerous editorial changes (typos, errors in examples, etc.).
7072 b. Fixed invalid media types in examples.
7074 c. Fixed the DTSTAMP values in the examples.
7076 d. Moved media type registration in a separate IANA Consideration
7077 section.
7079 e. Added Internationalization Considerations section.
7081 f. Added Security Considerations section.
7083 g. Updated the Acknowledgments section.
7085 Author's Address
7087 Bernard Desruisseaux (editor)
7088 Oracle Corporation
7089 600 blvd. de Maisonneuve West
7090 Suite 1900
7091 Montreal, QC H3A 3J2
7092 CA
7094 Email: bernard.desruisseaux@oracle.com
7095 URI: http://www.oracle.com/
7097 Intellectual Property Statement
7099 The IETF takes no position regarding the validity or scope of any
7100 Intellectual Property Rights or other rights that might be claimed to
7101 pertain to the implementation or use of the technology described in
7102 this document or the extent to which any license under such rights
7103 might or might not be available; nor does it represent that it has
7104 made any independent effort to identify any such rights. Information
7105 on the procedures with respect to rights in RFC documents can be
7106 found in BCP 78 and BCP 79.
7108 Copies of IPR disclosures made to the IETF Secretariat and any
7109 assurances of licenses to be made available, or the result of an
7110 attempt made to obtain a general license or permission for the use of
7111 such proprietary rights by implementers or users of this
7112 specification can be obtained from the IETF on-line IPR repository at
7113 http://www.ietf.org/ipr.
7115 The IETF invites any interested party to bring to its attention any
7116 copyrights, patents or patent applications, or other proprietary
7117 rights that may cover technology that may be required to implement
7118 this standard. Please address the information to the IETF at
7119 ietf-ipr@ietf.org.
7121 Disclaimer of Validity
7123 This document and the information contained herein are provided on an
7124 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
7125 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
7126 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
7127 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
7128 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
7129 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
7131 Copyright Statement
7133 Copyright (C) The Internet Society (2006). This document is subject
7134 to the rights, licenses and restrictions contained in BCP 78, and
7135 except as set forth therein, the authors retain all their rights.
7137 Acknowledgment
7139 Funding for the RFC Editor function is currently provided by the
7140 Internet Society.