mirror of
https://github.com/EGroupware/egroupware.git
synced 2024-12-23 15:18:58 +01:00
8292 lines
285 KiB
Plaintext
8292 lines
285 KiB
Plaintext
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Network Working Group F. Dawson
|
|||
|
Request for Comments: 2445 Lotus
|
|||
|
Category: Standards Track D. Stenerson
|
|||
|
Microsoft
|
|||
|
November 1998
|
|||
|
|
|||
|
|
|||
|
Internet Calendaring and Scheduling Core Object Specification
|
|||
|
(iCalendar)
|
|||
|
|
|||
|
Status of this Memo
|
|||
|
|
|||
|
This document specifies an Internet standards track protocol for the
|
|||
|
Internet community, and requests discussion and suggestions for
|
|||
|
improvements. Please refer to the current edition of the "Internet
|
|||
|
Official Protocol Standards" (STD 1) for the standardization state
|
|||
|
and status of this protocol. Distribution of this memo is unlimited.
|
|||
|
|
|||
|
Copyright Notice
|
|||
|
|
|||
|
Copyright (C) The Internet Society (1998). All Rights Reserved.
|
|||
|
|
|||
|
Abstract
|
|||
|
|
|||
|
There is a clear need to provide and deploy interoperable calendaring
|
|||
|
and scheduling services for the Internet. Current group scheduling
|
|||
|
and Personal Information Management (PIM) products are being extended
|
|||
|
for use across the Internet, today, in proprietary ways. This memo
|
|||
|
has been defined to provide the definition of a common format for
|
|||
|
openly exchanging calendaring and scheduling information across the
|
|||
|
Internet.
|
|||
|
|
|||
|
This memo is formatted as a registration for a MIME media type per
|
|||
|
[RFC 2048]. However, the format in this memo is equally applicable
|
|||
|
for use outside of a MIME message content type.
|
|||
|
|
|||
|
The proposed media type value is 'text/calendar'. This string would
|
|||
|
label a media type containing calendaring and scheduling information
|
|||
|
encoded as text characters formatted in a manner outlined below.
|
|||
|
|
|||
|
This MIME media type provides a standard content type for capturing
|
|||
|
calendar event, to-do and journal entry information. It also can be
|
|||
|
used to convey free/busy time information. The content type is
|
|||
|
suitable as a MIME message entity that can be transferred over MIME
|
|||
|
based email systems, using HTTP or some other Internet transport. In
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 1]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
addition, the content type is useful as an object for interactions
|
|||
|
between desktop applications using the operating system clipboard,
|
|||
|
drag/drop or file systems capabilities.
|
|||
|
|
|||
|
This memo is based on the earlier work of the vCalendar specification
|
|||
|
for the exchange of personal calendaring and scheduling information.
|
|||
|
In order to avoid confusion with this referenced work, this memo is
|
|||
|
to be known as the iCalendar specification.
|
|||
|
|
|||
|
This memo defines the format for specifying iCalendar object methods.
|
|||
|
An iCalendar object method is a set of usage constraints for the
|
|||
|
iCalendar object. For example, these methods might define scheduling
|
|||
|
messages that request an event be scheduled, reply to an event
|
|||
|
request, send a cancellation notice for an event, modify or replace
|
|||
|
the definition of an event, provide a counter proposal for an
|
|||
|
original event request, delegate an event request to another
|
|||
|
individual, request free or busy time, reply to a free or busy time
|
|||
|
request, or provide similar scheduling messages for a to-do or
|
|||
|
journal entry calendar component. The iCalendar Transport-indendent
|
|||
|
Interoperability Protocol (iTIP) defined in [ITIP] is one such
|
|||
|
scheduling protocol.
|
|||
|
|
|||
|
Table of Contents
|
|||
|
|
|||
|
1 Introduction.....................................................5
|
|||
|
2 Basic Grammar and Conventions....................................6
|
|||
|
2.1 Formatting Conventions .......................................7
|
|||
|
2.2 Related Memos ................................................8
|
|||
|
2.3 International Considerations .................................8
|
|||
|
3 Registration Information.........................................8
|
|||
|
3.1 Content Type .................................................8
|
|||
|
3.2 Parameters ...................................................9
|
|||
|
3.3 Content Header Fields .......................................10
|
|||
|
3.4 Encoding Considerations .....................................10
|
|||
|
3.5 Security Considerations .....................................10
|
|||
|
3.6 Interoperability Considerations .............................11
|
|||
|
3.7 Applications Which Use This Media Type ......................11
|
|||
|
3.8 Additional Information ......................................11
|
|||
|
3.9 Magic Numbers ...............................................11
|
|||
|
3.10 File Extensions ............................................11
|
|||
|
3.11 Contact for Further Information: ...........................12
|
|||
|
3.12 Intended Usage .............................................12
|
|||
|
3.13 Authors/Change Controllers .................................12
|
|||
|
4 iCalendar Object Specification..................................13
|
|||
|
4.1 Content Lines ...............................................13
|
|||
|
4.1.1 List and Field Separators ................................16
|
|||
|
4.1.2 Multiple Values ..........................................16
|
|||
|
4.1.3 Binary Content ...........................................16
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 2]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
4.1.4 Character Set ............................................17
|
|||
|
4.2 Property Parameters .........................................17
|
|||
|
4.2.1 Alternate Text Representation ............................18
|
|||
|
4.2.2 Common Name ..............................................19
|
|||
|
4.2.3 Calendar User Type .......................................20
|
|||
|
4.2.4 Delegators ...............................................20
|
|||
|
4.2.5 Delegatees ...............................................21
|
|||
|
4.2.6 Directory Entry Reference ................................21
|
|||
|
4.2.7 Inline Encoding ..........................................22
|
|||
|
4.2.8 Format Type ..............................................23
|
|||
|
4.2.9 Free/Busy Time Type ......................................23
|
|||
|
4.2.10 Language ................................................24
|
|||
|
4.2.11 Group or List Membership ................................25
|
|||
|
4.2.12 Participation Status ....................................25
|
|||
|
4.2.13 Recurrence Identifier Range .............................27
|
|||
|
4.2.14 Alarm Trigger Relationship ..............................27
|
|||
|
4.2.15 Relationship Type .......................................28
|
|||
|
4.2.16 Participation Role ......................................29
|
|||
|
4.2.17 RSVP Expectation ........................................29
|
|||
|
4.2.18 Sent By .................................................30
|
|||
|
4.2.19 Time Zone Identifier ....................................30
|
|||
|
4.2.20 Value Data Types ........................................32
|
|||
|
4.3 Property Value Data Types ...................................32
|
|||
|
4.3.1 Binary ...................................................33
|
|||
|
4.3.2 Boolean ..................................................33
|
|||
|
4.3.3 Calendar User Address ....................................34
|
|||
|
4.3.4 Date .....................................................34
|
|||
|
4.3.5 Date-Time ................................................35
|
|||
|
4.3.6 Duration .................................................37
|
|||
|
4.3.7 Float ....................................................38
|
|||
|
4.3.8 Integer ..................................................38
|
|||
|
4.3.9 Period of Time ...........................................39
|
|||
|
4.3.10 Recurrence Rule .........................................40
|
|||
|
4.3.11 Text ....................................................45
|
|||
|
4.3.12 Time ....................................................47
|
|||
|
4.3.13 URI .....................................................49
|
|||
|
4.3.14 UTC Offset ..............................................49
|
|||
|
4.4 iCalendar Object ............................................50
|
|||
|
4.5 Property ....................................................51
|
|||
|
4.6 Calendar Components .........................................51
|
|||
|
4.6.1 Event Component ..........................................52
|
|||
|
4.6.2 To-do Component ..........................................55
|
|||
|
4.6.3 Journal Component ........................................56
|
|||
|
4.6.4 Free/Busy Component ......................................58
|
|||
|
4.6.5 Time Zone Component ......................................60
|
|||
|
4.6.6 Alarm Component ..........................................67
|
|||
|
4.7 Calendar Properties .........................................73
|
|||
|
4.7.1 Calendar Scale ...........................................73
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 3]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
4.7.2 Method ...................................................74
|
|||
|
4.7.3 Product Identifier .......................................75
|
|||
|
4.7.4 Version ..................................................76
|
|||
|
4.8 Component Properties ........................................77
|
|||
|
4.8.1 Descriptive Component Properties .........................77
|
|||
|
4.8.1.1 Attachment ...........................................77
|
|||
|
4.8.1.2 Categories ...........................................78
|
|||
|
4.8.1.3 Classification .......................................79
|
|||
|
4.8.1.4 Comment ..............................................80
|
|||
|
4.8.1.5 Description ..........................................81
|
|||
|
4.8.1.6 Geographic Position ..................................82
|
|||
|
4.8.1.7 Location .............................................84
|
|||
|
4.8.1.8 Percent Complete .....................................85
|
|||
|
4.8.1.9 Priority .............................................85
|
|||
|
4.8.1.10 Resources ...........................................87
|
|||
|
4.8.1.11 Status ..............................................88
|
|||
|
4.8.1.12 Summary .............................................89
|
|||
|
4.8.2 Date and Time Component Properties .......................90
|
|||
|
4.8.2.1 Date/Time Completed ..................................90
|
|||
|
4.8.2.2 Date/Time End ........................................91
|
|||
|
4.8.2.3 Date/Time Due ........................................92
|
|||
|
4.8.2.4 Date/Time Start ......................................93
|
|||
|
4.8.2.5 Duration .............................................94
|
|||
|
4.8.2.6 Free/Busy Time .......................................95
|
|||
|
4.8.2.7 Time Transparency ....................................96
|
|||
|
4.8.3 Time Zone Component Properties ...........................97
|
|||
|
4.8.3.1 Time Zone Identifier .................................97
|
|||
|
4.8.3.2 Time Zone Name .......................................98
|
|||
|
4.8.3.3 Time Zone Offset From ................................99
|
|||
|
4.8.3.4 Time Zone Offset To .................................100
|
|||
|
4.8.3.5 Time Zone URL .......................................101
|
|||
|
4.8.4 Relationship Component Properties .......................102
|
|||
|
4.8.4.1 Attendee ............................................102
|
|||
|
4.8.4.2 Contact .............................................104
|
|||
|
4.8.4.3 Organizer ...........................................106
|
|||
|
4.8.4.4 Recurrence ID .......................................107
|
|||
|
4.8.4.5 Related To ..........................................109
|
|||
|
4.8.4.6 Uniform Resource Locator ............................110
|
|||
|
4.8.4.7 Unique Identifier ...................................111
|
|||
|
4.8.5 Recurrence Component Properties .........................112
|
|||
|
4.8.5.1 Exception Date/Times ................................112
|
|||
|
4.8.5.2 Exception Rule ......................................114
|
|||
|
4.8.5.3 Recurrence Date/Times ...............................115
|
|||
|
4.8.5.4 Recurrence Rule .....................................117
|
|||
|
4.8.6 Alarm Component Properties ..............................126
|
|||
|
4.8.6.1 Action ..............................................126
|
|||
|
4.8.6.2 Repeat Count ........................................126
|
|||
|
4.8.6.3 Trigger .............................................127
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 4]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
4.8.7 Change Management Component Properties ..................129
|
|||
|
4.8.7.1 Date/Time Created ...................................129
|
|||
|
4.8.7.2 Date/Time Stamp .....................................130
|
|||
|
4.8.7.3 Last Modified .......................................131
|
|||
|
4.8.7.4 Sequence Number .....................................131
|
|||
|
4.8.8 Miscellaneous Component Properties ......................133
|
|||
|
4.8.8.1 Non-standard Properties .............................133
|
|||
|
4.8.8.2 Request Status ......................................134
|
|||
|
5 iCalendar Object Examples......................................136
|
|||
|
6 Recommended Practices..........................................140
|
|||
|
7 Registration of Content Type Elements..........................141
|
|||
|
7.1 Registration of New and Modified iCalendar Object Methods ..141
|
|||
|
7.2 Registration of New Properties .............................141
|
|||
|
7.2.1 Define the property .....................................142
|
|||
|
7.2.2 Post the Property definition ............................143
|
|||
|
7.2.3 Allow a comment period ..................................143
|
|||
|
7.2.4 Submit the property for approval ........................143
|
|||
|
7.3 Property Change Control ....................................143
|
|||
|
8 References.....................................................144
|
|||
|
9 Acknowledgments................................................145
|
|||
|
10 Authors' and Chairs' Addresses................................146
|
|||
|
11 Full Copyright Statement......................................148
|
|||
|
|
|||
|
1 Introduction
|
|||
|
|
|||
|
The use of calendaring and scheduling has grown considerably in the
|
|||
|
last decade. Enterprise and inter-enterprise business has become
|
|||
|
dependent on rapid scheduling of events and actions using this
|
|||
|
information technology. However, the longer term growth of
|
|||
|
calendaring and scheduling, is currently limited by the lack of
|
|||
|
Internet standards for the message content types that are central to
|
|||
|
these knowledgeware applications. This memo is intended to progress
|
|||
|
the level of interoperability possible between dissimilar calendaring
|
|||
|
and scheduling applications. This memo defines a MIME content type
|
|||
|
for exchanging electronic calendaring and scheduling information. The
|
|||
|
Internet Calendaring and Scheduling Core Object Specification, or
|
|||
|
iCalendar, allows for the capture and exchange of information
|
|||
|
normally stored within a calendaring and scheduling application; such
|
|||
|
as a Personal Information Manager (PIM) or a Group Scheduling
|
|||
|
product.
|
|||
|
|
|||
|
The iCalendar format is suitable as an exchange format between
|
|||
|
applications or systems. The format is defined in terms of a MIME
|
|||
|
content type. This will enable the object to be exchanged using
|
|||
|
several transports, including but not limited to SMTP, HTTP, a file
|
|||
|
system, desktop interactive protocols such as the use of a memory-
|
|||
|
based clipboard or drag/drop interactions, point-to-point
|
|||
|
asynchronous communication, wired-network transport, or some form of
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 5]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
unwired transport such as infrared might also be used.
|
|||
|
|
|||
|
The memo also provides for the definition of iCalendar object methods
|
|||
|
that will map this content type to a set of messages for supporting
|
|||
|
calendaring and scheduling operations such as requesting, replying
|
|||
|
to, modifying, and canceling meetings or appointments, to-dos and
|
|||
|
journal entries. The iCalendar object methods can be used to define
|
|||
|
other calendaring and scheduling operations such a requesting for and
|
|||
|
replying with free/busy time data. Such a scheduling protocol is
|
|||
|
defined in the iCalendar Transport-independent Interoperability
|
|||
|
Protocol (iTIP) defined in [ITIP].
|
|||
|
|
|||
|
The memo also includes a formal grammar for the content type based on
|
|||
|
the Internet ABNF defined in [RFC 2234]. This ABNF is required for
|
|||
|
the implementation of parsers and to serve as the definitive
|
|||
|
reference when ambiguities or questions arise in interpreting the
|
|||
|
descriptive prose definition of the memo.
|
|||
|
|
|||
|
2 Basic Grammar and Conventions
|
|||
|
|
|||
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|||
|
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" and
|
|||
|
"OPTIONAL" in this document are to be interoperated as described in
|
|||
|
[RFC 2119].
|
|||
|
|
|||
|
This memo makes use of both a descriptive prose and a more formal
|
|||
|
notation for defining the calendaring and scheduling format.
|
|||
|
|
|||
|
The notation used in this memo is the ABNF notation of [RFC 2234].
|
|||
|
Readers intending on implementing this format defined in this memo
|
|||
|
should be familiar with this notation in order to properly interpret
|
|||
|
the specifications of this memo.
|
|||
|
|
|||
|
All numeric and hexadecimal values used in this memo are given in
|
|||
|
decimal notation.
|
|||
|
|
|||
|
All names of properties, property parameters, enumerated property
|
|||
|
values and property parameter values are case-insensitive. However,
|
|||
|
all other property values are case-sensitive, unless otherwise
|
|||
|
stated.
|
|||
|
|
|||
|
Note: All indented editorial notes, such as this one, are
|
|||
|
intended to provide the reader with additional information. The
|
|||
|
information is not essential to the building of an
|
|||
|
implementation conformant with this memo. The information is
|
|||
|
provided to highlight a particular feature or characteristic of
|
|||
|
the memo.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 6]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
The format for the iCalendar object is based on the syntax of the
|
|||
|
[RFC 2425] content type. While the iCalendar object is not a profile
|
|||
|
of the [RFC 2425] content type, it does reuse a number of the
|
|||
|
elements from the [RFC 2425] specification.
|
|||
|
|
|||
|
2.1 Formatting Conventions
|
|||
|
|
|||
|
The mechanisms defined in this memo are defined in prose. Many of the
|
|||
|
terms used to describe these have common usage that is different than
|
|||
|
the standards usage of this memo. In order to reference within this
|
|||
|
memo elements of the calendaring and scheduling model, core object
|
|||
|
(this memo) or interoperability protocol [ITIP] some formatting
|
|||
|
conventions have been used. Calendaring and scheduling roles are
|
|||
|
referred to in quoted-strings of text with the first character of
|
|||
|
each word in upper case. For example, "Organizer" refers to a role of
|
|||
|
a "Calendar User" within the scheduling protocol defined by [ITIP].
|
|||
|
Calendar components defined by this memo are referred to with
|
|||
|
capitalized, quoted-strings of text. All calendar components start
|
|||
|
with the letter "V". For example, "VEVENT" refers to the event
|
|||
|
calendar component, "VTODO" refers to the to-do calendar component
|
|||
|
and "VJOURNAL" refers to the daily journal calendar component.
|
|||
|
Scheduling methods defined by [ITIP] are referred to with
|
|||
|
capitalized, quoted-strings of text. For example, "REQUEST" refers to
|
|||
|
the method for requesting a scheduling calendar component be created
|
|||
|
or modified, "REPLY" refers to the method a recipient of a request
|
|||
|
uses to update their status with the "Organizer" of the calendar
|
|||
|
component.
|
|||
|
|
|||
|
The properties defined by this memo are referred to with capitalized,
|
|||
|
quoted-strings of text, followed by the word "property". For example,
|
|||
|
"ATTENDEE" property refers to the iCalendar property used to convey
|
|||
|
the calendar address of a calendar user. Property parameters defined
|
|||
|
by this memo are referred to with lowercase, quoted-strings of text,
|
|||
|
followed by the word "parameter". For example, "value" parameter
|
|||
|
refers to the iCalendar property parameter used to override the
|
|||
|
default data type for a property value. Enumerated values defined by
|
|||
|
this memo are referred to with capitalized text, either alone or
|
|||
|
followed by the word "value". For example, the "MINUTELY" value can
|
|||
|
be used with the "FREQ" component of the "RECUR" data type to specify
|
|||
|
repeating components based on an interval of one minute or more.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 7]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
2.2 Related Memos
|
|||
|
|
|||
|
Implementers will need to be familiar with several other memos that,
|
|||
|
along with this memo, form a framework for Internet calendaring and
|
|||
|
scheduling standards. This memo, [ICAL], specifies a core
|
|||
|
specification of objects, data types, properties and property
|
|||
|
parameters.
|
|||
|
|
|||
|
[ITIP] - specifies an interoperability protocol for scheduling
|
|||
|
between different implementations;
|
|||
|
|
|||
|
[IMIP] specifies an Internet email binding for [ITIP].
|
|||
|
|
|||
|
This memo does not attempt to repeat the specification of concepts or
|
|||
|
definitions from these other memos. Where possible, references are
|
|||
|
made to the memo that provides for the specification of these
|
|||
|
concepts or definitions.
|
|||
|
|
|||
|
2.3 International Considerations
|
|||
|
|
|||
|
In the rest of this document, descriptions of characters are of the
|
|||
|
form "character name (codepoint)", where "codepoint" is from the US-
|
|||
|
ASCII character set. The "character name" is the authoritative
|
|||
|
description; (codepoint) is a reference to that character in US-ASCII
|
|||
|
or US-ASCII compatible sets (for example the ISO-8859-x family, UTF-
|
|||
|
8, ISO-2022-xx, KOI8-R). If a non-US-ASCII compatible character set
|
|||
|
is used, appropriate code-point from that character set MUST be
|
|||
|
chosen instead. Use of non-US-ASCII-compatible character sets is NOT
|
|||
|
recommended.
|
|||
|
|
|||
|
3 Registration Information
|
|||
|
|
|||
|
The Calendaring and Scheduling Core Object Specification is intended
|
|||
|
for use as a MIME content type. However, the implementation of the
|
|||
|
memo is in no way limited solely as a MIME content type.
|
|||
|
|
|||
|
3.1 Content Type
|
|||
|
|
|||
|
The following text is intended to register this memo as the MIME
|
|||
|
content type "text/calendar".
|
|||
|
|
|||
|
To: ietf-types@uninett.no
|
|||
|
|
|||
|
Subject: Registration of MIME content type text/calendar.
|
|||
|
|
|||
|
MIME media type name: text
|
|||
|
|
|||
|
MIME subtype name: calendar
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 8]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
3.2 Parameters
|
|||
|
|
|||
|
Required parameters: none
|
|||
|
|
|||
|
Optional parameters: charset, method, component and optinfo
|
|||
|
|
|||
|
The "charset" parameter is defined in [RFC 2046] for other body
|
|||
|
parts. It is used to identify the default character set used within
|
|||
|
the body part.
|
|||
|
|
|||
|
The "method" parameter is used to convey the iCalendar object method
|
|||
|
or transaction semantics for the calendaring and scheduling
|
|||
|
information. It also is an identifier for the restricted set of
|
|||
|
properties and values that the iCalendar object consists of. The
|
|||
|
parameter is to be used as a guide for applications interpreting the
|
|||
|
information contained within the body part. It SHOULD NOT be used to
|
|||
|
exclude or require particular pieces of information unless the
|
|||
|
identified method definition specifically calls for this behavior.
|
|||
|
Unless specifically forbidden by a particular method definition, a
|
|||
|
text/calendar content type can contain any set of properties
|
|||
|
permitted by the Calendaring and Scheduling Core Object
|
|||
|
Specification. The "method" parameter MUST be the same value as that
|
|||
|
specified in the "METHOD" component property in the iCalendar object.
|
|||
|
If one is present, the other MUST also be present.
|
|||
|
|
|||
|
The value for the "method" parameter is defined as follows:
|
|||
|
|
|||
|
method = 1*(ALPHA / DIGIT / "-")
|
|||
|
; IANA registered iCalendar object method
|
|||
|
|
|||
|
The "component" parameter conveys the type of iCalendar calendar
|
|||
|
component within the body part. If the iCalendar object contains more
|
|||
|
than one calendar component type, then multiple component parameters
|
|||
|
MUST be specified.
|
|||
|
|
|||
|
The value for the "component" parameter is defined as follows:
|
|||
|
|
|||
|
component = ("VEVENT" / "VTODO" / "VJOURNAL" / "VFREEBUSY"
|
|||
|
/ "VTIMEZONE" / x-name / iana-token)
|
|||
|
|
|||
|
The "optinfo" parameter conveys optional information about the
|
|||
|
iCalendar object within the body part. This parameter can only
|
|||
|
specify semantics already specified by the iCalendar object and that
|
|||
|
can be otherwise determined by parsing the body part. In addition,
|
|||
|
the optional information specified by this parameter MUST be
|
|||
|
consistent with that information specified by the iCalendar object.
|
|||
|
For example, it can be used to convey the "Attendee" response status
|
|||
|
to a meeting request. The parameter value consists of a string value.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 9]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
The parameter can be specified multiple times.
|
|||
|
|
|||
|
This parameter MAY only specify semantics already specified by the
|
|||
|
iCalendar object and that can be otherwise determined by parsing the
|
|||
|
body part.
|
|||
|
|
|||
|
The value for the "optinfo" parameter is defined as follows:
|
|||
|
|
|||
|
optinfo = infovalue / qinfovalue
|
|||
|
|
|||
|
infovalue = iana-token / x-name
|
|||
|
|
|||
|
qinfovalue = DQUOTE (infovalue) DQUOTE
|
|||
|
|
|||
|
3.3 Content Header Fields
|
|||
|
|
|||
|
Optional content header fields: Any header fields defined by [RFC
|
|||
|
2045].
|
|||
|
|
|||
|
3.4 Encoding Considerations
|
|||
|
|
|||
|
This MIME content type can contain 8bit characters, so the use of
|
|||
|
quoted-printable or BASE64 MIME content-transfer-encodings might be
|
|||
|
necessary when iCalendar objects are transferred across protocols
|
|||
|
restricted to the 7bit repertoire. Note that a text valued property
|
|||
|
in the content entity can also have content encoding of special
|
|||
|
characters using a BACKSLASH character (US-ASCII decimal 92)
|
|||
|
escapement technique. This means that content values can end up
|
|||
|
encoded twice.
|
|||
|
|
|||
|
3.5 Security Considerations
|
|||
|
|
|||
|
SPOOFING - - In this memo, the "Organizer" is the only person
|
|||
|
authorized to make changes to an existing "VEVENT", "VTODO",
|
|||
|
"VJOURNAL" calendar component and redistribute the updates to the
|
|||
|
"Attendees". An iCalendar object that maliciously changes or cancels
|
|||
|
an existing "VEVENT", "VTODO" or "VJOURNAL" or "VFREEBUSY" calendar
|
|||
|
component might be constructed by someone other than the "Organizer"
|
|||
|
and sent to the "Attendees". In addition in this memo, other than the
|
|||
|
"Organizer", an "Attendee" of a "VEVENT", "VTODO", "VJOURNAL"
|
|||
|
calendar component is the only other person authorized to update any
|
|||
|
parameter associated with their "ATTENDEE" property and send it to
|
|||
|
the "Organizer". An iCalendar object that maliciously changes the
|
|||
|
"ATTENDEE" parameters can be constructed by someone other than the
|
|||
|
real "Attendee" and sent to the "Organizer".
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 10]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
PROCEDURAL ALARMS - - An iCalendar object can be created that
|
|||
|
contains a "VEVENT" and "VTODO" calendar component with "VALARM"
|
|||
|
calendar components. The "VALARM" calendar component can be of type
|
|||
|
PROCEDURE and can have an attachment containing some sort of
|
|||
|
executable program. Implementations that incorporate these types of
|
|||
|
alarms are subject to any virus or malicious attack that might occur
|
|||
|
as a result of executing the attachment.
|
|||
|
|
|||
|
ATTACHMENTS - - An iCalendar object can include references to Uniform
|
|||
|
Resource Locators that can be programmed resources.
|
|||
|
|
|||
|
Implementers and users of this memo should be aware of the network
|
|||
|
security implications of accepting and parsing such information. In
|
|||
|
addition, the security considerations observed by implementations of
|
|||
|
electronic mail systems should be followed for this memo.
|
|||
|
|
|||
|
3.6 Interoperability Considerations
|
|||
|
|
|||
|
This MIME content type is intended to define a common format for
|
|||
|
conveying calendaring and scheduling information between different
|
|||
|
systems. It is heavily based on the earlier [VCAL] industry
|
|||
|
specification.
|
|||
|
|
|||
|
3.7 Applications Which Use This Media Type
|
|||
|
|
|||
|
This content-type is designed for widespread use by Internet
|
|||
|
calendaring and scheduling applications. In addition, applications in
|
|||
|
the workflow and document management area might find this content-
|
|||
|
type applicable. The [ITIP] and [IMIP] Internet protocols directly
|
|||
|
use this content-type also. Future work on an Internet calendar
|
|||
|
access protocol will utilize this content-type too.
|
|||
|
|
|||
|
3.8 Additional Information
|
|||
|
|
|||
|
This memo defines this content-type.
|
|||
|
|
|||
|
3.9 Magic Numbers
|
|||
|
|
|||
|
None.
|
|||
|
|
|||
|
3.10 File Extensions
|
|||
|
|
|||
|
The file extension of "ics" is to be used to designate a file
|
|||
|
containing (an arbitrary set of) calendaring and scheduling
|
|||
|
information consistent with this MIME content type.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 11]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
The file extension of "ifb" is to be used to designate a file
|
|||
|
containing free or busy time information consistent with this MIME
|
|||
|
content type.
|
|||
|
|
|||
|
Macintosh file type codes: The file type code of "iCal" is to be used
|
|||
|
in Apple MacIntosh operating system environments to designate a file
|
|||
|
containing calendaring and scheduling information consistent with
|
|||
|
this MIME media type.
|
|||
|
|
|||
|
The file type code of "iFBf" is to be used in Apple MacIntosh
|
|||
|
operating system environments to designate a file containing free or
|
|||
|
busy time information consistent with this MIME media type.
|
|||
|
|
|||
|
3.11 Contact for Further Information:
|
|||
|
|
|||
|
Frank Dawson
|
|||
|
6544 Battleford Drive
|
|||
|
Raleigh, NC 27613-3502
|
|||
|
919-676-9515 (Telephone)
|
|||
|
919-676-9564 (Data/Facsimile)
|
|||
|
Frank_Dawson@Lotus.com (Internet Mail)
|
|||
|
|
|||
|
Derik Stenerson
|
|||
|
One Microsoft Way
|
|||
|
Redmond, WA 98052-6399
|
|||
|
425-936-5522 (Telephone)
|
|||
|
425-936-7329 (Facsimile)
|
|||
|
deriks@microsoft.com (Internet Mail)
|
|||
|
|
|||
|
3.12 Intended Usage
|
|||
|
|
|||
|
COMMON
|
|||
|
|
|||
|
3.13 Authors/Change Controllers
|
|||
|
|
|||
|
Frank Dawson
|
|||
|
6544 Battleford Drive
|
|||
|
Raleigh, NC 27613-3502
|
|||
|
919-676-9515 (Telephone)
|
|||
|
919-676-9564 (Data/Facsimile)
|
|||
|
Frank_Dawson@Lotus.com (Internet Mail)
|
|||
|
|
|||
|
Derik Stenerson
|
|||
|
One Microsoft Way
|
|||
|
Redmond, WA 98052-6399
|
|||
|
425-936-5522 (Telephone)
|
|||
|
425-936-7329 (Facsimile)
|
|||
|
deriks@microsoft.com (Internet Mail)
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 12]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
4 iCalendar Object Specification
|
|||
|
|
|||
|
The following sections define the details of a Calendaring and
|
|||
|
Scheduling Core Object Specification. This information is intended to
|
|||
|
be an integral part of the MIME content type registration. In
|
|||
|
addition, this information can be used independent of such content
|
|||
|
registration. In particular, this memo has direct applicability for
|
|||
|
use as a calendaring and scheduling exchange format in file-, memory-
|
|||
|
or network-based transport mechanisms.
|
|||
|
|
|||
|
4.1 Content Lines
|
|||
|
|
|||
|
The iCalendar object is organized into individual lines of text,
|
|||
|
called content lines. Content lines are delimited by a line break,
|
|||
|
which is a CRLF sequence (US-ASCII decimal 13, followed by US-ASCII
|
|||
|
decimal 10).
|
|||
|
|
|||
|
Lines of text SHOULD NOT be longer than 75 octets, excluding the line
|
|||
|
break. Long content lines SHOULD be split into a multiple line
|
|||
|
representations using a line "folding" technique. That is, a long
|
|||
|
line can be split between any two characters by inserting a CRLF
|
|||
|
immediately followed by a single linear white space character (i.e.,
|
|||
|
SPACE, US-ASCII decimal 32 or HTAB, US-ASCII decimal 9). Any sequence
|
|||
|
of CRLF followed immediately by a single linear white space character
|
|||
|
is ignored (i.e., removed) when processing the content type.
|
|||
|
|
|||
|
For example the line:
|
|||
|
|
|||
|
DESCRIPTION:This is a long description that exists on a long line.
|
|||
|
|
|||
|
Can be represented as:
|
|||
|
|
|||
|
DESCRIPTION:This is a lo
|
|||
|
ng description
|
|||
|
that exists on a long line.
|
|||
|
|
|||
|
The process of moving from this folded multiple line representation
|
|||
|
to its single line representation is called "unfolding". Unfolding is
|
|||
|
accomplished by removing the CRLF character and the linear white
|
|||
|
space character that immediately follows.
|
|||
|
|
|||
|
When parsing a content line, folded lines MUST first be unfolded
|
|||
|
according to the unfolding procedure described above. When generating
|
|||
|
a content line, lines longer than 75 octets SHOULD be folded
|
|||
|
according to the folding procedure described above.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 13]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
The content information associated with an iCalendar object is
|
|||
|
formatted using a syntax similar to that defined by [RFC 2425]. That
|
|||
|
is, the content information consists of CRLF-separated content lines.
|
|||
|
|
|||
|
The following notation defines the lines of content in an iCalendar
|
|||
|
object:
|
|||
|
|
|||
|
contentline = name *(";" param ) ":" value CRLF
|
|||
|
; This ABNF is just a general definition for an initial parsing
|
|||
|
; of the content line into its property name, parameter list,
|
|||
|
; and value string
|
|||
|
|
|||
|
; When parsing a content line, folded lines MUST first
|
|||
|
; be unfolded according to the unfolding procedure
|
|||
|
; described above. When generating a content line, lines
|
|||
|
; longer than 75 octets SHOULD be folded according to
|
|||
|
; the folding procedure described above.
|
|||
|
|
|||
|
name = x-name / iana-token
|
|||
|
|
|||
|
iana-token = 1*(ALPHA / DIGIT / "-")
|
|||
|
; iCalendar identifier registered with IANA
|
|||
|
|
|||
|
x-name = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-")
|
|||
|
; Reservered for experimental use. Not intended for use in
|
|||
|
; released products.
|
|||
|
|
|||
|
vendorid = 3*(ALPHA / DIGIT) ;Vendor identification
|
|||
|
|
|||
|
param = param-name "=" param-value
|
|||
|
*("," param-value)
|
|||
|
; Each property defines the specific ABNF for the parameters
|
|||
|
; allowed on the property. Refer to specific properties for
|
|||
|
; precise parameter ABNF.
|
|||
|
|
|||
|
param-name = iana-token / x-token
|
|||
|
|
|||
|
param-value = paramtext / quoted-string
|
|||
|
|
|||
|
paramtext = *SAFE-CHAR
|
|||
|
|
|||
|
value = *VALUE-CHAR
|
|||
|
|
|||
|
quoted-string = DQUOTE *QSAFE-CHAR DQUOTE
|
|||
|
|
|||
|
NON-US-ASCII = %x80-F8
|
|||
|
; Use restricted by charset parameter
|
|||
|
; on outer MIME object (UTF-8 preferred)
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 14]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
QSAFE-CHAR = WSP / %x21 / %x23-7E / NON-US-ASCII
|
|||
|
; Any character except CTLs and DQUOTE
|
|||
|
|
|||
|
SAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E
|
|||
|
/ NON-US-ASCII
|
|||
|
; Any character except CTLs, DQUOTE, ";", ":", ","
|
|||
|
|
|||
|
VALUE-CHAR = WSP / %x21-7E / NON-US-ASCII
|
|||
|
; Any textual character
|
|||
|
|
|||
|
CR = %x0D
|
|||
|
; carriage return
|
|||
|
|
|||
|
LF = %x0A
|
|||
|
; line feed
|
|||
|
|
|||
|
CRLF = CR LF
|
|||
|
; Internet standard newline
|
|||
|
|
|||
|
CTL = %x00-08 / %x0A-1F / %x7F
|
|||
|
; Controls
|
|||
|
|
|||
|
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
|
|||
|
|
|||
|
DIGIT = %x30-39
|
|||
|
; 0-9
|
|||
|
|
|||
|
DQUOTE = %x22
|
|||
|
; Quotation Mark
|
|||
|
|
|||
|
WSP = SPACE / HTAB
|
|||
|
|
|||
|
SPACE = %x20
|
|||
|
|
|||
|
HTAB = %x09
|
|||
|
|
|||
|
The property value component of a content line has a format that is
|
|||
|
property specific. Refer to the section describing each property for
|
|||
|
a definition of this format.
|
|||
|
|
|||
|
All names of properties, property parameters, enumerated property
|
|||
|
values and property parameter values are case-insensitive. However,
|
|||
|
all other property values are case-sensitive, unless otherwise
|
|||
|
stated.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 15]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
4.1.1 List and Field Separators
|
|||
|
|
|||
|
Some properties and parameters allow a list of values. Values in a
|
|||
|
list of values MUST be separated by a COMMA character (US-ASCII
|
|||
|
decimal 44). There is no significance to the order of values in a
|
|||
|
list. For those parameter values (such as those that specify URI
|
|||
|
values) that are specified in quoted-strings, the individual quoted-
|
|||
|
strings are separated by a COMMA character (US-ASCII decimal 44).
|
|||
|
|
|||
|
Some property values are defined in terms of multiple parts. These
|
|||
|
structured property values MUST have their value parts separated by a
|
|||
|
SEMICOLON character (US-ASCII decimal 59).
|
|||
|
|
|||
|
Some properties allow a list of parameters. Each property parameter
|
|||
|
in a list of property parameters MUST be separated by a SEMICOLON
|
|||
|
character (US-ASCII decimal 59).
|
|||
|
|
|||
|
Property parameters with values containing a COLON, a SEMICOLON or a
|
|||
|
COMMA character MUST be placed in quoted text.
|
|||
|
|
|||
|
For example, in the following properties a SEMICOLON is used to
|
|||
|
separate property parameters from each other, and a COMMA is used to
|
|||
|
separate property values in a value list.
|
|||
|
|
|||
|
ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT:MAILTO:
|
|||
|
jsmith@host.com
|
|||
|
|
|||
|
RDATE;VALUE=DATE:19970304,19970504,19970704,19970904
|
|||
|
|
|||
|
4.1.2 Multiple Values
|
|||
|
|
|||
|
Some properties defined in the iCalendar object can have multiple
|
|||
|
values. The general rule for encoding multi-valued items is to simply
|
|||
|
create a new content line for each value, including the property
|
|||
|
name. However, it should be noted that some properties support
|
|||
|
encoding multiple values in a single property by separating the
|
|||
|
values with a COMMA character (US-ASCII decimal 44). Individual
|
|||
|
property definitions should be consulted for determining whether a
|
|||
|
specific property allows multiple values and in which of these two
|
|||
|
forms.
|
|||
|
|
|||
|
4.1.3 Binary Content
|
|||
|
|
|||
|
Binary content information in an iCalendar object SHOULD be
|
|||
|
referenced using a URI within a property value. That is the binary
|
|||
|
content information SHOULD be placed in an external MIME entity that
|
|||
|
can be referenced by a URI from within the iCalendar object. In
|
|||
|
applications where this is not feasible, binary content information
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 16]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
can be included within an iCalendar object, but only after first
|
|||
|
encoding it into text using the "BASE64" encoding method defined in
|
|||
|
[RFC 2045]. Inline binary contact SHOULD only be used in applications
|
|||
|
whose special circumstances demand that an iCalendar object be
|
|||
|
expressed as a single entity. A property containing inline binary
|
|||
|
content information MUST specify the "ENCODING" property parameter.
|
|||
|
Binary content information placed external to the iCalendar object
|
|||
|
MUST be referenced by a uniform resource identifier (URI).
|
|||
|
|
|||
|
The following example specifies an "ATTACH" property that references
|
|||
|
an attachment external to the iCalendar object with a URI reference:
|
|||
|
|
|||
|
ATTACH:http://xyz.com/public/quarterly-report.doc
|
|||
|
|
|||
|
The following example specifies an "ATTACH" property with inline
|
|||
|
binary encoded content information:
|
|||
|
|
|||
|
ATTACH;FMTTYPE=image/basic;ENCODING=BASE64;VALUE=BINARY:
|
|||
|
MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1U
|
|||
|
EBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIE
|
|||
|
<...remainder of "BASE64" encoded binary data...>
|
|||
|
|
|||
|
4.1.4 Character Set
|
|||
|
|
|||
|
There is not a property parameter to declare the character set used
|
|||
|
in a property value. The default character set for an iCalendar
|
|||
|
object is UTF-8 as defined in [RFC 2279].
|
|||
|
|
|||
|
The "charset" Content-Type parameter can be used in MIME transports
|
|||
|
to specify any other IANA registered character set.
|
|||
|
|
|||
|
4.2 Property Parameters
|
|||
|
|
|||
|
A property can have attributes associated with it. These "property
|
|||
|
parameters" contain meta-information about the property or the
|
|||
|
property value. Property parameters are provided to specify such
|
|||
|
information as the location of an alternate text representation for a
|
|||
|
property value, the language of a text property value, the data type
|
|||
|
of the property value and other attributes.
|
|||
|
|
|||
|
Property parameter values that contain the COLON (US-ASCII decimal
|
|||
|
58), SEMICOLON (US-ASCII decimal 59) or COMMA (US-ASCII decimal 44)
|
|||
|
character separators MUST be specified as quoted-string text values.
|
|||
|
Property parameter values MUST NOT contain the DOUBLE-QUOTE (US-ASCII
|
|||
|
decimal 22) character. The DOUBLE-QUOTE (US-ASCII decimal 22)
|
|||
|
character is used as a delimiter for parameter values that contain
|
|||
|
restricted characters or URI text. For example:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 17]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
DESCRIPTION;ALTREP="http://www.wiz.org":The Fall'98 Wild Wizards
|
|||
|
Conference - - Las Vegas, NV, USA
|
|||
|
|
|||
|
Property parameter values that are not in quoted strings are case
|
|||
|
insensitive.
|
|||
|
|
|||
|
The general property parameters defined by this memo are defined by
|
|||
|
the following notation:
|
|||
|
|
|||
|
parameter = altrepparam ; Alternate text representation
|
|||
|
/ cnparam ; Common name
|
|||
|
/ cutypeparam ; Calendar user type
|
|||
|
/ delfromparam ; Delegator
|
|||
|
/ deltoparam ; Delegatee
|
|||
|
/ dirparam ; Directory entry
|
|||
|
/ encodingparam ; Inline encoding
|
|||
|
/ fmttypeparam ; Format type
|
|||
|
/ fbtypeparam ; Free/busy time type
|
|||
|
/ languageparam ; Language for text
|
|||
|
/ memberparam ; Group or list membership
|
|||
|
/ partstatparam ; Participation status
|
|||
|
/ rangeparam ; Recurrence identifier range
|
|||
|
/ trigrelparam ; Alarm trigger relationship
|
|||
|
/ reltypeparam ; Relationship type
|
|||
|
/ roleparam ; Participation role
|
|||
|
/ rsvpparam ; RSVP expectation
|
|||
|
/ sentbyparam ; Sent by
|
|||
|
/ tzidparam ; Reference to time zone object
|
|||
|
/ valuetypeparam ; Property value data type
|
|||
|
/ ianaparam
|
|||
|
; Some other IANA registered iCalendar parameter.
|
|||
|
/ xparam
|
|||
|
; A non-standard, experimental parameter.
|
|||
|
|
|||
|
ianaparam = iana-token "=" param-value *("," param-value)
|
|||
|
|
|||
|
xparam =x-name "=" param-value *("," param-value)
|
|||
|
|
|||
|
4.2.1 Alternate Text Representation
|
|||
|
|
|||
|
Parameter Name: ALTREP
|
|||
|
|
|||
|
Purpose: To specify an alternate text representation for the property
|
|||
|
value.
|
|||
|
|
|||
|
Format Definition: The property parameter is defined by the following
|
|||
|
notation:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 18]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
altrepparam = "ALTREP" "=" DQUOTE uri DQUOTE
|
|||
|
|
|||
|
Description: The parameter specifies a URI that points to an
|
|||
|
alternate representation for a textual property value. A property
|
|||
|
specifying this parameter MUST also include a value that reflects the
|
|||
|
default representation of the text value. The individual URI
|
|||
|
parameter values MUST each be specified in a quoted-string.
|
|||
|
|
|||
|
Example:
|
|||
|
|
|||
|
DESCRIPTION;ALTREP="CID:<part3.msg.970415T083000@host.com>":Project
|
|||
|
XYZ Review Meeting will include the following agenda items: (a)
|
|||
|
Market Overview, (b) Finances, (c) Project Management
|
|||
|
|
|||
|
The "ALTREP" property parameter value might point to a "text/html"
|
|||
|
content portion.
|
|||
|
|
|||
|
Content-Type:text/html
|
|||
|
Content-Id:<part3.msg.970415T083000@host.com>
|
|||
|
|
|||
|
<html><body>
|
|||
|
<p><b>Project XYZ Review Meeting</b> will include the following
|
|||
|
agenda items:<ol><li>Market
|
|||
|
Overview</li><li>Finances</li><li>Project Management</li></ol></p>
|
|||
|
</body></html>
|
|||
|
|
|||
|
4.2.2 Common Name
|
|||
|
|
|||
|
Parameter Name: CN
|
|||
|
|
|||
|
Purpose: To specify the common name to be associated with the
|
|||
|
calendar user specified by the property.
|
|||
|
|
|||
|
Format Definition: The property parameter is defined by the following
|
|||
|
notation:
|
|||
|
|
|||
|
cnparam = "CN" "=" param-value
|
|||
|
|
|||
|
Description: This parameter can be specified on properties with a
|
|||
|
CAL-ADDRESS value type. The parameter specifies the common name to be
|
|||
|
associated with the calendar user specified by the property. The
|
|||
|
parameter value is text. The parameter value can be used for display
|
|||
|
text to be associated with the calendar address specified by the
|
|||
|
property.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 19]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
Example:
|
|||
|
|
|||
|
ORGANIZER;CN="John Smith":MAILTO:jsmith@host.com
|
|||
|
|
|||
|
4.2.3 Calendar User Type
|
|||
|
|
|||
|
Parameter Name: CUTYPE
|
|||
|
|
|||
|
Purpose: To specify the type of calendar user specified by the
|
|||
|
property.
|
|||
|
|
|||
|
Format Definition: The property parameter is defined by the following
|
|||
|
notation:
|
|||
|
|
|||
|
cutypeparam = "CUTYPE" "="
|
|||
|
("INDIVIDUAL" ; An individual
|
|||
|
/ "GROUP" ; A group of individuals
|
|||
|
/ "RESOURCE" ; A physical resource
|
|||
|
/ "ROOM" ; A room resource
|
|||
|
/ "UNKNOWN" ; Otherwise not known
|
|||
|
/ x-name ; Experimental type
|
|||
|
/ iana-token) ; Other IANA registered
|
|||
|
; type
|
|||
|
; Default is INDIVIDUAL
|
|||
|
|
|||
|
Description: This parameter can be specified on properties with a
|
|||
|
CAL-ADDRESS value type. The parameter identifies the type of calendar
|
|||
|
user specified by the property. If not specified on a property that
|
|||
|
allows this parameter, the default is INDIVIDUAL.
|
|||
|
|
|||
|
Example:
|
|||
|
|
|||
|
ATTENDEE;CUTYPE=GROUP:MAILTO:ietf-calsch@imc.org
|
|||
|
|
|||
|
4.2.4 Delegators
|
|||
|
|
|||
|
Parameter Name: DELEGATED-FROM
|
|||
|
|
|||
|
Purpose: To specify the calendar users that have delegated their
|
|||
|
participation to the calendar user specified by the property.
|
|||
|
|
|||
|
Format Definition: The property parameter is defined by the following
|
|||
|
notation:
|
|||
|
|
|||
|
delfromparam = "DELEGATED-FROM" "=" DQUOTE cal-address DQUOTE
|
|||
|
*("," DQUOTE cal-address DQUOTE)
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 20]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
Description: This parameter can be specified on properties with a
|
|||
|
CAL-ADDRESS value type. This parameter can be specified on a property
|
|||
|
that has a value type of calendar address. This parameter specifies
|
|||
|
those calendar uses that have delegated their participation in a
|
|||
|
group scheduled event or to-do to the calendar user specified by the
|
|||
|
property. The value MUST be a MAILTO URI as defined in [RFC 1738].
|
|||
|
The individual calendar address parameter values MUST each be
|
|||
|
specified in a quoted-string.
|
|||
|
|
|||
|
Example:
|
|||
|
|
|||
|
ATTENDEE;DELEGATED-FROM="MAILTO:jsmith@host.com":MAILTO:
|
|||
|
jdoe@host.com
|
|||
|
|
|||
|
4.2.5 Delegatees
|
|||
|
|
|||
|
Parameter Name: DELEGATED-TO
|
|||
|
|
|||
|
Purpose: To specify the calendar users to whom the calendar user
|
|||
|
specified by the property has delegated participation.
|
|||
|
|
|||
|
Format Definition: The property parameter is defined by the following
|
|||
|
notation:
|
|||
|
|
|||
|
deltoparam = "DELEGATED-TO" "=" DQUOTE cal-address DQUOTE
|
|||
|
*("," DQUOTE cal-address DQUOTE)
|
|||
|
|
|||
|
Description: This parameter can be specified on properties with a
|
|||
|
CAL-ADDRESS value type. This parameter specifies those calendar users
|
|||
|
whom have been delegated participation in a group scheduled event or
|
|||
|
to-do by the calendar user specified by the property. The value MUST
|
|||
|
be a MAILTO URI as defined in [RFC 1738]. The individual calendar
|
|||
|
address parameter values MUST each be specified in a quoted-string.
|
|||
|
|
|||
|
Example:
|
|||
|
|
|||
|
ATTENDEE;DELEGATED-TO="MAILTO:jdoe@host.com","MAILTO:jqpublic@
|
|||
|
host.com":MAILTO:jsmith@host.com
|
|||
|
|
|||
|
4.2.6 Directory Entry Reference
|
|||
|
|
|||
|
Parameter Name: DIR
|
|||
|
|
|||
|
Purpose: To specify reference to a directory entry associated with
|
|||
|
the calendar user specified by the property.
|
|||
|
|
|||
|
Format Definition: The property parameter is defined by the following
|
|||
|
notation:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 21]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
dirparam = "DIR" "=" DQUOTE uri DQUOTE
|
|||
|
|
|||
|
Description: This parameter can be specified on properties with a
|
|||
|
CAL-ADDRESS value type. The parameter specifies a reference to the
|
|||
|
directory entry associated with the calendar user specified by the
|
|||
|
property. The parameter value is a URI. The individual URI parameter
|
|||
|
values MUST each be specified in a quoted-string.
|
|||
|
|
|||
|
Example:
|
|||
|
|
|||
|
ORGANIZER;DIR="ldap://host.com:6666/o=eDABC%20Industries,c=3DUS??
|
|||
|
(cn=3DBJim%20Dolittle)":MAILTO:jimdo@host1.com
|
|||
|
|
|||
|
4.2.7 Inline Encoding
|
|||
|
|
|||
|
Parameter Name: ENCODING
|
|||
|
|
|||
|
Purpose: To specify an alternate inline encoding for the property
|
|||
|
value.
|
|||
|
|
|||
|
Format Definition: The property parameter is defined by the following
|
|||
|
notation:
|
|||
|
|
|||
|
encodingparam = "ENCODING" "="
|
|||
|
("8BIT"
|
|||
|
; "8bit" text encoding is defined in [RFC 2045]
|
|||
|
/ "BASE64"
|
|||
|
; "BASE64" binary encoding format is defined in [RFC 2045]
|
|||
|
/ iana-token
|
|||
|
; Some other IANA registered iCalendar encoding type
|
|||
|
/ x-name)
|
|||
|
; A non-standard, experimental encoding type
|
|||
|
|
|||
|
Description: The property parameter identifies the inline encoding
|
|||
|
used in a property value. The default encoding is "8BIT",
|
|||
|
corresponding to a property value consisting of text. The "BASE64"
|
|||
|
encoding type corresponds to a property value encoded using the
|
|||
|
"BASE64" encoding defined in [RFC 2045].
|
|||
|
|
|||
|
If the value type parameter is ";VALUE=BINARY", then the inline
|
|||
|
encoding parameter MUST be specified with the value
|
|||
|
";ENCODING=BASE64".
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 22]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
Example:
|
|||
|
|
|||
|
ATTACH;FMTYPE=IMAGE/JPEG;ENCODING=BASE64;VALUE=BINARY:MIICajC
|
|||
|
CAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDA
|
|||
|
qBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMRw
|
|||
|
<...remainder of "BASE64" encoded binary data...>
|
|||
|
|
|||
|
4.2.8 Format Type
|
|||
|
|
|||
|
Parameter Name: FMTTYPE
|
|||
|
|
|||
|
Purpose: To specify the content type of a referenced object.
|
|||
|
|
|||
|
Format Definition: The property parameter is defined by the following
|
|||
|
notation:
|
|||
|
|
|||
|
fmttypeparam = "FMTTYPE" "=" iana-token
|
|||
|
; A IANA registered content type
|
|||
|
/ x-name
|
|||
|
; A non-standard content type
|
|||
|
|
|||
|
Description: This parameter can be specified on properties that are
|
|||
|
used to reference an object. The parameter specifies the content type
|
|||
|
of the referenced object. For example, on the "ATTACH" property, a
|
|||
|
FTP type URI value does not, by itself, necessarily convey the type
|
|||
|
of content associated with the resource. The parameter value MUST be
|
|||
|
the TEXT for either an IANA registered content type or a non-standard
|
|||
|
content type.
|
|||
|
|
|||
|
Example:
|
|||
|
|
|||
|
ATTACH;FMTTYPE=application/binary:ftp://domain.com/pub/docs/
|
|||
|
agenda.doc
|
|||
|
|
|||
|
4.2.9 Free/Busy Time Type
|
|||
|
|
|||
|
Parameter Name: FBTYPE
|
|||
|
|
|||
|
Purpose: To specify the free or busy time type.
|
|||
|
|
|||
|
Format Definition: The property parameter is defined by the following
|
|||
|
notation:
|
|||
|
|
|||
|
fbtypeparam = "FBTYPE" "=" ("FREE" / "BUSY"
|
|||
|
/ "BUSY-UNAVAILABLE" / "BUSY-TENTATIVE"
|
|||
|
/ x-name
|
|||
|
; Some experimental iCalendar data type.
|
|||
|
/ iana-token)
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 23]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
; Some other IANA registered iCalendar data type.
|
|||
|
|
|||
|
Description: The parameter specifies the free or busy time type. The
|
|||
|
value FREE indicates that the time interval is free for scheduling.
|
|||
|
The value BUSY indicates that the time interval is busy because one
|
|||
|
or more events have been scheduled for that interval. The value
|
|||
|
BUSY-UNAVAILABLE indicates that the time interval is busy and that
|
|||
|
the interval can not be scheduled. The value BUSY-TENTATIVE indicates
|
|||
|
that the time interval is busy because one or more events have been
|
|||
|
tentatively scheduled for that interval. If not specified on a
|
|||
|
property that allows this parameter, the default is BUSY.
|
|||
|
|
|||
|
Example: The following is an example of this parameter on a FREEBUSY
|
|||
|
property.
|
|||
|
|
|||
|
FREEBUSY;FBTYPE=BUSY:19980415T133000Z/19980415T170000Z
|
|||
|
|
|||
|
4.2.10 Language
|
|||
|
|
|||
|
Parameter Name: LANGUAGE
|
|||
|
|
|||
|
Purpose: To specify the language for text values in a property or
|
|||
|
property parameter.
|
|||
|
|
|||
|
Format Definition: The property parameter is defined by the following
|
|||
|
notation:
|
|||
|
|
|||
|
languageparam = "LANGUAGE" "=" language
|
|||
|
|
|||
|
language = <Text identifying a language, as defined in [RFC 1766]>
|
|||
|
|
|||
|
Description: This parameter can be specified on properties with a
|
|||
|
text value type. The parameter identifies the language of the text in
|
|||
|
the property or property parameter value. The value of the "language"
|
|||
|
property parameter is that defined in [RFC 1766].
|
|||
|
|
|||
|
For transport in a MIME entity, the Content-Language header field can
|
|||
|
be used to set the default language for the entire body part.
|
|||
|
Otherwise, no default language is assumed.
|
|||
|
|
|||
|
Example:
|
|||
|
|
|||
|
SUMMARY;LANGUAGE=us-EN:Company Holiday Party
|
|||
|
|
|||
|
LOCATION;LANGUAGE=en:Germany
|
|||
|
LOCATION;LANGUAGE=no:Tyskland
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 24]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
The following example makes use of the Quoted-Printable encoding in
|
|||
|
order to represent non-ASCII characters.
|
|||
|
|
|||
|
LOCATION;LANGUAGE=da:K=F8benhavn
|
|||
|
LOCATION;LANGUAGE=en:Copenhagen
|
|||
|
|
|||
|
4.2.11 Group or List Membership
|
|||
|
|
|||
|
Parameter Name: MEMBER
|
|||
|
|
|||
|
Purpose: To specify the group or list membership of the calendar user
|
|||
|
specified by the property.
|
|||
|
|
|||
|
Format Definition: The property parameter is defined by the following
|
|||
|
notation:
|
|||
|
|
|||
|
memberparam = "MEMBER" "=" DQUOTE cal-address DQUOTE
|
|||
|
*("," DQUOTE cal-address DQUOTE)
|
|||
|
|
|||
|
Description: This parameter can be specified on properties with a
|
|||
|
CAL-ADDRESS value type. The parameter identifies the groups or list
|
|||
|
membership for the calendar user specified by the property. The
|
|||
|
parameter value either a single calendar address in a quoted-string
|
|||
|
or a COMMA character (US-ASCII decimal 44) list of calendar
|
|||
|
addresses, each in a quoted-string. The individual calendar address
|
|||
|
parameter values MUST each be specified in a quoted-string.
|
|||
|
|
|||
|
Example:
|
|||
|
|
|||
|
ATTENDEE;MEMBER="MAILTO:ietf-calsch@imc.org":MAILTO:jsmith@host.com
|
|||
|
|
|||
|
ATTENDEE;MEMBER="MAILTO:projectA@host.com","MAILTO:projectB@host.
|
|||
|
com":MAILTO:janedoe@host.com
|
|||
|
|
|||
|
4.2.12 Participation Status
|
|||
|
|
|||
|
Parameter Name: PARTSTAT
|
|||
|
|
|||
|
Purpose: To specify the participation status for the calendar user
|
|||
|
specified by the property.
|
|||
|
|
|||
|
Format Definition: The property parameter is defined by the following
|
|||
|
notation:
|
|||
|
|
|||
|
partstatparam = "PARTSTAT" "="
|
|||
|
("NEEDS-ACTION" ; Event needs action
|
|||
|
/ "ACCEPTED" ; Event accepted
|
|||
|
/ "DECLINED" ; Event declined
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 25]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
/ "TENTATIVE" ; Event tentatively
|
|||
|
; accepted
|
|||
|
/ "DELEGATED" ; Event delegated
|
|||
|
/ x-name ; Experimental status
|
|||
|
/ iana-token) ; Other IANA registered
|
|||
|
; status
|
|||
|
; These are the participation statuses for a "VEVENT". Default is
|
|||
|
; NEEDS-ACTION
|
|||
|
partstatparam /= "PARTSTAT" "="
|
|||
|
("NEEDS-ACTION" ; To-do needs action
|
|||
|
/ "ACCEPTED" ; To-do accepted
|
|||
|
/ "DECLINED" ; To-do declined
|
|||
|
/ "TENTATIVE" ; To-do tentatively
|
|||
|
; accepted
|
|||
|
/ "DELEGATED" ; To-do delegated
|
|||
|
/ "COMPLETED" ; To-do completed.
|
|||
|
; COMPLETED property has
|
|||
|
;date/time completed.
|
|||
|
/ "IN-PROCESS" ; To-do in process of
|
|||
|
; being completed
|
|||
|
/ x-name ; Experimental status
|
|||
|
/ iana-token) ; Other IANA registered
|
|||
|
; status
|
|||
|
; These are the participation statuses for a "VTODO". Default is
|
|||
|
; NEEDS-ACTION
|
|||
|
|
|||
|
partstatparam /= "PARTSTAT" "="
|
|||
|
("NEEDS-ACTION" ; Journal needs action
|
|||
|
/ "ACCEPTED" ; Journal accepted
|
|||
|
/ "DECLINED" ; Journal declined
|
|||
|
/ x-name ; Experimental status
|
|||
|
/ iana-token) ; Other IANA registered
|
|||
|
; status
|
|||
|
; These are the participation statuses for a "VJOURNAL". Default is
|
|||
|
; NEEDS-ACTION
|
|||
|
|
|||
|
Description: This parameter can be specified on properties with a
|
|||
|
CAL-ADDRESS value type. The parameter identifies the participation
|
|||
|
status for the calendar user specified by the property value. The
|
|||
|
parameter values differ depending on whether they are associated with
|
|||
|
a group scheduled "VEVENT", "VTODO" or "VJOURNAL". The values MUST
|
|||
|
match one of the values allowed for the given calendar component. If
|
|||
|
not specified on a property that allows this parameter, the default
|
|||
|
value is NEEDS-ACTION.
|
|||
|
|
|||
|
Example:
|
|||
|
|
|||
|
ATTENDEE;PARTSTAT=DECLINED:MAILTO:jsmith@host.com
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 26]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
4.2.13 Recurrence Identifier Range
|
|||
|
|
|||
|
Parameter Name: RANGE
|
|||
|
|
|||
|
Purpose: To specify the effective range of recurrence instances from
|
|||
|
the instance specified by the recurrence identifier specified by the
|
|||
|
property.
|
|||
|
|
|||
|
Format Definition: The property parameter is defined by the following
|
|||
|
notation:
|
|||
|
|
|||
|
rangeparam = "RANGE" "=" ("THISANDPRIOR"
|
|||
|
; To specify all instances prior to the recurrence identifier
|
|||
|
/ "THISANDFUTURE")
|
|||
|
; To specify the instance specified by the recurrence identifier
|
|||
|
; and all subsequent recurrence instances
|
|||
|
|
|||
|
Description: The parameter can be specified on a property that
|
|||
|
specifies a recurrence identifier. The parameter specifies the
|
|||
|
effective range of recurrence instances that is specified by the
|
|||
|
property. The effective range is from the recurrence identified
|
|||
|
specified by the property. If this parameter is not specified an
|
|||
|
allowed property, then the default range is the single instance
|
|||
|
specified by the recurrence identifier value of the property. The
|
|||
|
parameter value can be "THISANDPRIOR" to indicate a range defined by
|
|||
|
the recurrence identified value of the property and all prior
|
|||
|
instances. The parameter value can also be "THISANDFUTURE" to
|
|||
|
indicate a range defined by the recurrence identifier and all
|
|||
|
subsequent instances.
|
|||
|
|
|||
|
Example:
|
|||
|
|
|||
|
RECURRENCE-ID;RANGE=THISANDPRIOR:19980401T133000Z
|
|||
|
|
|||
|
4.2.14 Alarm Trigger Relationship
|
|||
|
|
|||
|
Parameter Name: RELATED
|
|||
|
|
|||
|
Purpose: To specify the relationship of the alarm trigger with
|
|||
|
respect to the start or end of the calendar component.
|
|||
|
|
|||
|
Format Definition: The property parameter is defined by the following
|
|||
|
notation:
|
|||
|
|
|||
|
trigrelparam = "RELATED" "="
|
|||
|
("START" ; Trigger off of start
|
|||
|
/ "END") ; Trigger off of end
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 27]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
Description: The parameter can be specified on properties that
|
|||
|
specify an alarm trigger with a DURATION value type. The parameter
|
|||
|
specifies whether the alarm will trigger relative to the start or end
|
|||
|
of the calendar component. The parameter value START will set the
|
|||
|
alarm to trigger off the start of the calendar component; the
|
|||
|
parameter value END will set the alarm to trigger off the end of the
|
|||
|
calendar component. If the parameter is not specified on an allowable
|
|||
|
property, then the default is START.
|
|||
|
|
|||
|
Example:
|
|||
|
|
|||
|
TRIGGER;RELATED=END:PT5M
|
|||
|
|
|||
|
4.2.15 Relationship Type
|
|||
|
|
|||
|
Parameter Name: RELTYPE
|
|||
|
|
|||
|
Purpose: To specify the type of hierarchical relationship associated
|
|||
|
with the calendar component specified by the property.
|
|||
|
|
|||
|
Format Definition: The property parameter is defined by the following
|
|||
|
notation:
|
|||
|
|
|||
|
reltypeparam = "RELTYPE" "="
|
|||
|
("PARENT" ; Parent relationship. Default.
|
|||
|
/ "CHILD" ; Child relationship
|
|||
|
/ "SIBLING ; Sibling relationship
|
|||
|
/ iana-token ; Some other IANA registered
|
|||
|
; iCalendar relationship type
|
|||
|
/ x-name) ; A non-standard, experimental
|
|||
|
; relationship type
|
|||
|
|
|||
|
Description: This parameter can be specified on a property that
|
|||
|
references another related calendar. The parameter specifies the
|
|||
|
hierarchical relationship type of the calendar component referenced
|
|||
|
by the property. The parameter value can be PARENT, to indicate that
|
|||
|
the referenced calendar component is a superior of calendar
|
|||
|
component; CHILD to indicate that the referenced calendar component
|
|||
|
is a subordinate of the calendar component; SIBLING to indicate that
|
|||
|
the referenced calendar component is a peer of the calendar
|
|||
|
component. If this parameter is not specified on an allowable
|
|||
|
property, the default relationship type is PARENT.
|
|||
|
|
|||
|
Example:
|
|||
|
|
|||
|
RELATED-TO;RELTYPE=SIBLING:<19960401-080045-4000F192713@host.com>
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 28]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
4.2.16 Participation Role
|
|||
|
|
|||
|
Parameter Name: ROLE
|
|||
|
|
|||
|
Purpose: To specify the participation role for the calendar user
|
|||
|
specified by the property.
|
|||
|
|
|||
|
Format Definition: The property parameter is defined by the following
|
|||
|
notation:
|
|||
|
|
|||
|
roleparam = "ROLE" "="
|
|||
|
("CHAIR" ; Indicates chair of the
|
|||
|
; calendar entity
|
|||
|
/ "REQ-PARTICIPANT" ; Indicates a participant whose
|
|||
|
; participation is required
|
|||
|
/ "OPT-PARTICIPANT" ; Indicates a participant whose
|
|||
|
; participation is optional
|
|||
|
/ "NON-PARTICIPANT" ; Indicates a participant who is
|
|||
|
; copied for information
|
|||
|
; purposes only
|
|||
|
/ x-name ; Experimental role
|
|||
|
/ iana-token) ; Other IANA role
|
|||
|
; Default is REQ-PARTICIPANT
|
|||
|
|
|||
|
Description: This parameter can be specified on properties with a
|
|||
|
CAL-ADDRESS value type. The parameter specifies the participation
|
|||
|
role for the calendar user specified by the property in the group
|
|||
|
schedule calendar component. If not specified on a property that
|
|||
|
allows this parameter, the default value is REQ-PARTICIPANT.
|
|||
|
|
|||
|
Example:
|
|||
|
|
|||
|
ATTENDEE;ROLE=CHAIR:MAILTO:mrbig@host.com
|
|||
|
|
|||
|
4.2.17 RSVP Expectation
|
|||
|
|
|||
|
Parameter Name: RSVP
|
|||
|
|
|||
|
Purpose: To specify whether there is an expectation of a favor of a
|
|||
|
reply from the calendar user specified by the property value.
|
|||
|
|
|||
|
Format Definition: The property parameter is defined by the following
|
|||
|
notation:
|
|||
|
|
|||
|
rsvpparam = "RSVP" "=" ("TRUE" / "FALSE")
|
|||
|
; Default is FALSE
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 29]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
Description: This parameter can be specified on properties with a
|
|||
|
CAL-ADDRESS value type. The parameter identifies the expectation of a
|
|||
|
reply from the calendar user specified by the property value. This
|
|||
|
parameter is used by the "Organizer" to request a participation
|
|||
|
status reply from an "Attendee" of a group scheduled event or to-do.
|
|||
|
If not specified on a property that allows this parameter, the
|
|||
|
default value is FALSE.
|
|||
|
|
|||
|
Example:
|
|||
|
|
|||
|
ATTENDEE;RSVP=TRUE:MAILTO:jsmith@host.com
|
|||
|
|
|||
|
4.2.18 Sent By
|
|||
|
|
|||
|
Parameter Name: SENT-BY
|
|||
|
|
|||
|
Purpose: To specify the calendar user that is acting on behalf of the
|
|||
|
calendar user specified by the property.
|
|||
|
|
|||
|
Format Definition: The property parameter is defined by the following
|
|||
|
notation:
|
|||
|
|
|||
|
sentbyparam = "SENT-BY" "=" DQUOTE cal-address DQUOTE
|
|||
|
|
|||
|
Description: This parameter can be specified on properties with a
|
|||
|
CAL-ADDRESS value type. The parameter specifies the calendar user
|
|||
|
that is acting on behalf of the calendar user specified by the
|
|||
|
property. The parameter value MUST be a MAILTO URI as defined in [RFC
|
|||
|
1738]. The individual calendar address parameter values MUST each be
|
|||
|
specified in a quoted-string.
|
|||
|
|
|||
|
Example:
|
|||
|
|
|||
|
ORGANIZER;SENT-BY:"MAILTO:sray@host.com":MAILTO:jsmith@host.com
|
|||
|
|
|||
|
4.2.19 Time Zone Identifier
|
|||
|
|
|||
|
Parameter Name: TZID
|
|||
|
|
|||
|
Purpose: To specify the identifier for the time zone definition for a
|
|||
|
time component in the property value.
|
|||
|
|
|||
|
Format Definition: This property parameter is defined by the
|
|||
|
following notation:
|
|||
|
|
|||
|
tzidparam = "TZID" "=" [tzidprefix] paramtext CRLF
|
|||
|
|
|||
|
tzidprefix = "/"
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 30]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
Description: The parameter MUST be specified on the "DTSTART",
|
|||
|
"DTEND", "DUE", "EXDATE" and "RDATE" properties when either a DATE-
|
|||
|
TIME or TIME value type is specified and when the value is not either
|
|||
|
a UTC or a "floating" time. Refer to the DATE-TIME or TIME value type
|
|||
|
definition for a description of UTC and "floating time" formats. This
|
|||
|
property parameter specifies a text value which uniquely identifies
|
|||
|
the "VTIMEZONE" calendar component to be used when evaluating the
|
|||
|
time portion of the property. The value of the TZID property
|
|||
|
parameter will be equal to the value of the TZID property for the
|
|||
|
matching time zone definition. An individual "VTIMEZONE" calendar
|
|||
|
component MUST be specified for each unique "TZID" parameter value
|
|||
|
specified in the iCalendar object.
|
|||
|
|
|||
|
The parameter MUST be specified on properties with a DATE-TIME value
|
|||
|
if the DATE-TIME is not either a UTC or a "floating" time.
|
|||
|
|
|||
|
The presence of the SOLIDUS character (US-ASCII decimal 47) as a
|
|||
|
prefix, indicates that this TZID represents a unique ID in a globally
|
|||
|
defined time zone registry (when such registry is defined).
|
|||
|
|
|||
|
Note: This document does not define a naming convention for time
|
|||
|
zone identifiers. Implementers may want to use the naming
|
|||
|
conventions defined in existing time zone specifications such as
|
|||
|
the public-domain Olson database [TZ]. The specification of
|
|||
|
globally unique time zone identifiers is not addressed by this
|
|||
|
document and is left for future study.
|
|||
|
|
|||
|
The following are examples of this property parameter:
|
|||
|
|
|||
|
DTSTART;TZID=US-Eastern:19980119T020000
|
|||
|
|
|||
|
DTEND;TZID=US-Eastern:19980119T030000
|
|||
|
|
|||
|
The TZID property parameter MUST NOT be applied to DATE-TIME or TIME
|
|||
|
properties whose time values are specified in UTC.
|
|||
|
|
|||
|
The use of local time in a DATE-TIME or TIME value without the TZID
|
|||
|
property parameter is to be interpreted as a local time value,
|
|||
|
regardless of the existence of "VTIMEZONE" calendar components in the
|
|||
|
iCalendar object.
|
|||
|
|
|||
|
For more information see the sections on the data types DATE-TIME and
|
|||
|
TIME.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 31]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
4.2.20 Value Data Types
|
|||
|
|
|||
|
Parameter Name: VALUE
|
|||
|
|
|||
|
Purpose: To explicitly specify the data type format for a property
|
|||
|
value.
|
|||
|
|
|||
|
Format Definition: The "VALUE" property parameter is defined by the
|
|||
|
following notation:
|
|||
|
|
|||
|
valuetypeparam = "VALUE" "=" valuetype
|
|||
|
|
|||
|
valuetype = ("BINARY"
|
|||
|
/ "BOOLEAN"
|
|||
|
/ "CAL-ADDRESS"
|
|||
|
/ "DATE"
|
|||
|
/ "DATE-TIME"
|
|||
|
/ "DURATION"
|
|||
|
/ "FLOAT"
|
|||
|
/ "INTEGER"
|
|||
|
/ "PERIOD"
|
|||
|
/ "RECUR"
|
|||
|
/ "TEXT"
|
|||
|
/ "TIME"
|
|||
|
/ "URI"
|
|||
|
/ "UTC-OFFSET"
|
|||
|
/ x-name
|
|||
|
; Some experimental iCalendar data type.
|
|||
|
/ iana-token)
|
|||
|
; Some other IANA registered iCalendar data type.
|
|||
|
|
|||
|
Description: The parameter specifies the data type and format of the
|
|||
|
property value. The property values MUST be of a single value type.
|
|||
|
For example, a "RDATE" property cannot have a combination of DATE-
|
|||
|
TIME and TIME value types.
|
|||
|
|
|||
|
If the property's value is the default value type, then this
|
|||
|
parameter need not be specified. However, if the property's default
|
|||
|
value type is overridden by some other allowable value type, then
|
|||
|
this parameter MUST be specified.
|
|||
|
|
|||
|
4.3 Property Value Data Types
|
|||
|
|
|||
|
The properties in an iCalendar object are strongly typed. The
|
|||
|
definition of each property restricts the value to be one of the
|
|||
|
value data types, or simply value types, defined in this section. The
|
|||
|
value type for a property will either be specified implicitly as the
|
|||
|
default value type or will be explicitly specified with the "VALUE"
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 32]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
parameter. If the value type of a property is one of the alternate
|
|||
|
valid types, then it MUST be explicitly specified with the "VALUE"
|
|||
|
parameter.
|
|||
|
|
|||
|
4.3.1 Binary
|
|||
|
|
|||
|
Value Name: BINARY
|
|||
|
|
|||
|
Purpose: This value type is used to identify properties that contain
|
|||
|
a character encoding of inline binary data. For example, an inline
|
|||
|
attachment of an object code might be included in an iCalendar
|
|||
|
object.
|
|||
|
|
|||
|
Formal Definition: The value type is defined by the following
|
|||
|
notation:
|
|||
|
|
|||
|
binary = *(4b-char) [b-end]
|
|||
|
; A "BASE64" encoded character string, as defined by [RFC 2045].
|
|||
|
|
|||
|
b-end = (2b-char "==") / (3b-char "=")
|
|||
|
|
|||
|
b-char = ALPHA / DIGIT / "+" / "/"
|
|||
|
|
|||
|
Description: Property values with this value type MUST also include
|
|||
|
the inline encoding parameter sequence of ";ENCODING=BASE64". That
|
|||
|
is, all inline binary data MUST first be character encoded using the
|
|||
|
"BASE64" encoding method defined in [RFC 2045]. No additional content
|
|||
|
value encoding (i.e., BACKSLASH character encoding) is defined for
|
|||
|
this value type.
|
|||
|
|
|||
|
Example: The following is an abridged example of a "BASE64" encoded
|
|||
|
binary value data.
|
|||
|
|
|||
|
ATTACH;VALUE=BINARY;ENCODING=BASE64:MIICajCCAdOgAwIBAgICBEUwDQY
|
|||
|
JKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlI
|
|||
|
ENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZv
|
|||
|
<...remainder of "BASE64" encoded binary data...>
|
|||
|
|
|||
|
4.3.2 Boolean
|
|||
|
|
|||
|
Value Name: BOOLEAN
|
|||
|
|
|||
|
Purpose: This value type is used to identify properties that contain
|
|||
|
either a "TRUE" or "FALSE" Boolean value.
|
|||
|
|
|||
|
Formal Definition: The value type is defined by the following
|
|||
|
notation:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 33]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
boolean = "TRUE" / "FALSE"
|
|||
|
|
|||
|
Description: These values are case insensitive text. No additional
|
|||
|
content value encoding (i.e., BACKSLASH character encoding) is
|
|||
|
defined for this value type.
|
|||
|
|
|||
|
Example: The following is an example of a hypothetical property that
|
|||
|
has a BOOLEAN value type:
|
|||
|
|
|||
|
GIBBERISH:TRUE
|
|||
|
|
|||
|
4.3.3 Calendar User Address
|
|||
|
|
|||
|
Value Name: CAL-ADDRESS
|
|||
|
|
|||
|
Purpose: This value type is used to identify properties that contain
|
|||
|
a calendar user address.
|
|||
|
|
|||
|
Formal Definition: The value type is as defined by the following
|
|||
|
notation:
|
|||
|
|
|||
|
cal-address = uri
|
|||
|
|
|||
|
Description: The value is a URI as defined by [RFC 1738] or any other
|
|||
|
IANA registered form for a URI. When used to address an Internet
|
|||
|
email transport address for a calendar user, the value MUST be a
|
|||
|
MAILTO URI, as defined by [RFC 1738]. No additional content value
|
|||
|
encoding (i.e., BACKSLASH character encoding) is defined for this
|
|||
|
value type.
|
|||
|
|
|||
|
Example:
|
|||
|
|
|||
|
ATTENDEE:MAILTO:jane_doe@host.com
|
|||
|
|
|||
|
4.3.4 Date
|
|||
|
|
|||
|
Value Name: DATE
|
|||
|
|
|||
|
Purpose: This value type is used to identify values that contain a
|
|||
|
calendar date.
|
|||
|
|
|||
|
Formal Definition: The value type is defined by the following
|
|||
|
notation:
|
|||
|
|
|||
|
date = date-value
|
|||
|
|
|||
|
date-value = date-fullyear date-month date-mday
|
|||
|
date-fullyear = 4DIGIT
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 34]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
date-month = 2DIGIT ;01-12
|
|||
|
date-mday = 2DIGIT ;01-28, 01-29, 01-30, 01-31
|
|||
|
;based on month/year
|
|||
|
|
|||
|
Description: If the property permits, multiple "date" values are
|
|||
|
specified as a COMMA character (US-ASCII decimal 44) separated list
|
|||
|
of values. The format for the value type is expressed as the [ISO
|
|||
|
8601] complete representation, basic format for a calendar date. The
|
|||
|
textual format specifies a four-digit year, two-digit month, and
|
|||
|
two-digit day of the month. There are no separator characters between
|
|||
|
the year, month and day component text.
|
|||
|
|
|||
|
No additional content value encoding (i.e., BACKSLASH character
|
|||
|
encoding) is defined for this value type.
|
|||
|
|
|||
|
Example: The following represents July 14, 1997:
|
|||
|
|
|||
|
19970714
|
|||
|
|
|||
|
4.3.5 Date-Time
|
|||
|
|
|||
|
Value Name: DATE-TIME
|
|||
|
|
|||
|
Purpose: This value type is used to identify values that specify a
|
|||
|
precise calendar date and time of day.
|
|||
|
|
|||
|
Formal Definition: The value type is defined by the following
|
|||
|
notation:
|
|||
|
|
|||
|
date-time = date "T" time ;As specified in the date and time
|
|||
|
;value definitions
|
|||
|
|
|||
|
Description: If the property permits, multiple "date-time" values are
|
|||
|
specified as a COMMA character (US-ASCII decimal 44) separated list
|
|||
|
of values. No additional content value encoding (i.e., BACKSLASH
|
|||
|
character encoding) is defined for this value type.
|
|||
|
|
|||
|
The "DATE-TIME" data type is used to identify values that contain a
|
|||
|
precise calendar date and time of day. The format is based on the
|
|||
|
[ISO 8601] complete representation, basic format for a calendar date
|
|||
|
and time of day. The text format is a concatenation of the "date",
|
|||
|
followed by the LATIN CAPITAL LETTER T character (US-ASCII decimal
|
|||
|
84) time designator, followed by the "time" format.
|
|||
|
|
|||
|
The "DATE-TIME" data type expresses time values in three forms:
|
|||
|
|
|||
|
The form of date and time with UTC offset MUST NOT be used. For
|
|||
|
example, the following is not valid for a date-time value:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 35]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
DTSTART:19980119T230000-0800 ;Invalid time format
|
|||
|
|
|||
|
FORM #1: DATE WITH LOCAL TIME
|
|||
|
|
|||
|
The date with local time form is simply a date-time value that does
|
|||
|
not contain the UTC designator nor does it reference a time zone. For
|
|||
|
example, the following represents Janurary 18, 1998, at 11 PM:
|
|||
|
|
|||
|
DTSTART:19980118T230000
|
|||
|
|
|||
|
Date-time values of this type are said to be "floating" and are not
|
|||
|
bound to any time zone in particular. They are used to represent the
|
|||
|
same hour, minute, and second value regardless of which time zone is
|
|||
|
currently being observed. For example, an event can be defined that
|
|||
|
indicates that an individual will be busy from 11:00 AM to 1:00 PM
|
|||
|
every day, no matter which time zone the person is in. In these
|
|||
|
cases, a local time can be specified. The recipient of an iCalendar
|
|||
|
object with a property value consisting of a local time, without any
|
|||
|
relative time zone information, SHOULD interpret the value as being
|
|||
|
fixed to whatever time zone the ATTENDEE is in at any given moment.
|
|||
|
This means that two ATTENDEEs, in different time zones, receiving the
|
|||
|
same event definition as a floating time, may be participating in the
|
|||
|
event at different actual times. Floating time SHOULD only be used
|
|||
|
where that is the reasonable behavior.
|
|||
|
|
|||
|
In most cases, a fixed time is desired. To properly communicate a
|
|||
|
fixed time in a property value, either UTC time or local time with
|
|||
|
time zone reference MUST be specified.
|
|||
|
|
|||
|
The use of local time in a DATE-TIME value without the TZID property
|
|||
|
parameter is to be interpreted as floating time, regardless of the
|
|||
|
existence of "VTIMEZONE" calendar components in the iCalendar object.
|
|||
|
|
|||
|
FORM #2: DATE WITH UTC TIME
|
|||
|
|
|||
|
The date with UTC time, or absolute time, is identified by a LATIN
|
|||
|
CAPITAL LETTER Z suffix character (US-ASCII decimal 90), the UTC
|
|||
|
designator, appended to the time value. For example, the following
|
|||
|
represents January 19, 1998, at 0700 UTC:
|
|||
|
|
|||
|
DTSTART:19980119T070000Z
|
|||
|
|
|||
|
The TZID property parameter MUST NOT be applied to DATE-TIME
|
|||
|
properties whose time values are specified in UTC.
|
|||
|
|
|||
|
FORM #3: DATE WITH LOCAL TIME AND TIME ZONE REFERENCE
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 36]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
The date and local time with reference to time zone information is
|
|||
|
identified by the use the TZID property parameter to reference the
|
|||
|
appropriate time zone definition. TZID is discussed in detail in the
|
|||
|
section on Time Zone. For example, the following represents 2 AM in
|
|||
|
New York on Janurary 19, 1998:
|
|||
|
|
|||
|
DTSTART;TZID=US-Eastern:19980119T020000
|
|||
|
|
|||
|
Example: The following represents July 14, 1997, at 1:30 PM in New
|
|||
|
York City in each of the three time formats, using the "DTSTART"
|
|||
|
property.
|
|||
|
|
|||
|
DTSTART:19970714T133000 ;Local time
|
|||
|
DTSTART:19970714T173000Z ;UTC time
|
|||
|
DTSTART;TZID=US-Eastern:19970714T133000 ;Local time and time
|
|||
|
; zone reference
|
|||
|
|
|||
|
A time value MUST ONLY specify 60 seconds when specifying the
|
|||
|
periodic "leap second" in the time value. For example:
|
|||
|
|
|||
|
COMPLETED:19970630T235960Z
|
|||
|
|
|||
|
4.3.6 Duration
|
|||
|
|
|||
|
Value Name: DURATION
|
|||
|
|
|||
|
Purpose: This value type is used to identify properties that contain
|
|||
|
a duration of time.
|
|||
|
|
|||
|
Formal Definition: The value type is defined by the following
|
|||
|
notation:
|
|||
|
|
|||
|
dur-value = (["+"] / "-") "P" (dur-date / dur-time / dur-week)
|
|||
|
|
|||
|
dur-date = dur-day [dur-time]
|
|||
|
dur-time = "T" (dur-hour / dur-minute / dur-second)
|
|||
|
dur-week = 1*DIGIT "W"
|
|||
|
dur-hour = 1*DIGIT "H" [dur-minute]
|
|||
|
dur-minute = 1*DIGIT "M" [dur-second]
|
|||
|
dur-second = 1*DIGIT "S"
|
|||
|
dur-day = 1*DIGIT "D"
|
|||
|
|
|||
|
Description: If the property permits, multiple "duration" values are
|
|||
|
specified by a COMMA character (US-ASCII decimal 44) separated list
|
|||
|
of values. The format is expressed as the [ISO 8601] basic format for
|
|||
|
the duration of time. The format can represent durations in terms of
|
|||
|
weeks, days, hours, minutes, and seconds.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 37]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
No additional content value encoding (i.e., BACKSLASH character
|
|||
|
encoding) are defined for this value type.
|
|||
|
|
|||
|
Example: A duration of 15 days, 5 hours and 20 seconds would be:
|
|||
|
|
|||
|
P15DT5H0M20S
|
|||
|
|
|||
|
A duration of 7 weeks would be:
|
|||
|
|
|||
|
P7W
|
|||
|
|
|||
|
4.3.7 Float
|
|||
|
|
|||
|
Value Name: FLOAT
|
|||
|
|
|||
|
Purpose: This value type is used to identify properties that contain
|
|||
|
a real number value.
|
|||
|
|
|||
|
Formal Definition: The value type is defined by the following
|
|||
|
notation:
|
|||
|
|
|||
|
float = (["+"] / "-") 1*DIGIT ["." 1*DIGIT]
|
|||
|
|
|||
|
Description: If the property permits, multiple "float" values are
|
|||
|
specified by a COMMA character (US-ASCII decimal 44) separated list
|
|||
|
of values.
|
|||
|
|
|||
|
No additional content value encoding (i.e., BACKSLASH character
|
|||
|
encoding) is defined for this value type.
|
|||
|
|
|||
|
Example:
|
|||
|
|
|||
|
1000000.0000001
|
|||
|
1.333
|
|||
|
-3.14
|
|||
|
|
|||
|
4.3.8 Integer
|
|||
|
|
|||
|
Value Name:INTEGER
|
|||
|
|
|||
|
Purpose: This value type is used to identify properties that contain
|
|||
|
a signed integer value.
|
|||
|
|
|||
|
Formal Definition: The value type is defined by the following
|
|||
|
notation:
|
|||
|
|
|||
|
integer = (["+"] / "-") 1*DIGIT
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 38]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
Description: If the property permits, multiple "integer" values are
|
|||
|
specified by a COMMA character (US-ASCII decimal 44) separated list
|
|||
|
of values. The valid range for "integer" is -2147483648 to
|
|||
|
2147483647. If the sign is not specified, then the value is assumed
|
|||
|
to be positive.
|
|||
|
|
|||
|
No additional content value encoding (i.e., BACKSLASH character
|
|||
|
encoding) is defined for this value type.
|
|||
|
|
|||
|
Example:
|
|||
|
|
|||
|
1234567890
|
|||
|
-1234567890
|
|||
|
+1234567890
|
|||
|
432109876
|
|||
|
|
|||
|
4.3.9 Period of Time
|
|||
|
|
|||
|
Value Name: PERIOD
|
|||
|
|
|||
|
Purpose: This value type is used to identify values that contain a
|
|||
|
precise period of time.
|
|||
|
|
|||
|
Formal Definition: The data type is defined by the following
|
|||
|
notation:
|
|||
|
|
|||
|
period = period-explicit / period-start
|
|||
|
|
|||
|
period-explicit = date-time "/" date-time
|
|||
|
; [ISO 8601] complete representation basic format for a period of
|
|||
|
; time consisting of a start and end. The start MUST be before the
|
|||
|
; end.
|
|||
|
|
|||
|
period-start = date-time "/" dur-value
|
|||
|
; [ISO 8601] complete representation basic format for a period of
|
|||
|
; time consisting of a start and positive duration of time.
|
|||
|
|
|||
|
Description: If the property permits, multiple "period" values are
|
|||
|
specified by a COMMA character (US-ASCII decimal 44) separated list
|
|||
|
of values. There are two forms of a period of time. First, a period
|
|||
|
of time is identified by its start and its end. This format is
|
|||
|
expressed as the [ISO 8601] complete representation, basic format for
|
|||
|
"DATE-TIME" start of the period, followed by a SOLIDUS character
|
|||
|
(US-ASCII decimal 47), followed by the "DATE-TIME" of the end of the
|
|||
|
period. The start of the period MUST be before the end of the period.
|
|||
|
Second, a period of time can also be defined by a start and a
|
|||
|
positive duration of time. The format is expressed as the [ISO 8601]
|
|||
|
complete representation, basic format for the "DATE-TIME" start of
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 39]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
the period, followed by a SOLIDUS character (US-ASCII decimal 47),
|
|||
|
followed by the [ISO 8601] basic format for "DURATION" of the period.
|
|||
|
|
|||
|
Example: The period starting at 18:00:00 UTC, on January 1, 1997 and
|
|||
|
ending at 07:00:00 UTC on January 2, 1997 would be:
|
|||
|
|
|||
|
19970101T180000Z/19970102T070000Z
|
|||
|
|
|||
|
The period start at 18:00:00 on January 1, 1997 and lasting 5 hours
|
|||
|
and 30 minutes would be:
|
|||
|
|
|||
|
19970101T180000Z/PT5H30M
|
|||
|
|
|||
|
No additional content value encoding (i.e., BACKSLASH character
|
|||
|
encoding) is defined for this value type.
|
|||
|
|
|||
|
4.3.10 Recurrence Rule
|
|||
|
|
|||
|
Value Name: RECUR
|
|||
|
|
|||
|
Purpose: This value type is used to identify properties that contain
|
|||
|
a recurrence rule specification.
|
|||
|
|
|||
|
Formal Definition: The value type is defined by the following
|
|||
|
notation:
|
|||
|
|
|||
|
recur = "FREQ"=freq *(
|
|||
|
|
|||
|
; either UNTIL or COUNT may appear in a 'recur',
|
|||
|
; but UNTIL and COUNT MUST NOT occur in the same 'recur'
|
|||
|
|
|||
|
( ";" "UNTIL" "=" enddate ) /
|
|||
|
( ";" "COUNT" "=" 1*DIGIT ) /
|
|||
|
|
|||
|
; the rest of these keywords are optional,
|
|||
|
; but MUST NOT occur more than once
|
|||
|
|
|||
|
( ";" "INTERVAL" "=" 1*DIGIT ) /
|
|||
|
( ";" "BYSECOND" "=" byseclist ) /
|
|||
|
( ";" "BYMINUTE" "=" byminlist ) /
|
|||
|
( ";" "BYHOUR" "=" byhrlist ) /
|
|||
|
( ";" "BYDAY" "=" bywdaylist ) /
|
|||
|
( ";" "BYMONTHDAY" "=" bymodaylist ) /
|
|||
|
( ";" "BYYEARDAY" "=" byyrdaylist ) /
|
|||
|
( ";" "BYWEEKNO" "=" bywknolist ) /
|
|||
|
( ";" "BYMONTH" "=" bymolist ) /
|
|||
|
( ";" "BYSETPOS" "=" bysplist ) /
|
|||
|
( ";" "WKST" "=" weekday ) /
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 40]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
( ";" x-name "=" text )
|
|||
|
)
|
|||
|
|
|||
|
freq = "SECONDLY" / "MINUTELY" / "HOURLY" / "DAILY"
|
|||
|
/ "WEEKLY" / "MONTHLY" / "YEARLY"
|
|||
|
|
|||
|
enddate = date
|
|||
|
enddate =/ date-time ;An UTC value
|
|||
|
|
|||
|
byseclist = seconds / ( seconds *("," seconds) )
|
|||
|
|
|||
|
seconds = 1DIGIT / 2DIGIT ;0 to 59
|
|||
|
|
|||
|
byminlist = minutes / ( minutes *("," minutes) )
|
|||
|
|
|||
|
minutes = 1DIGIT / 2DIGIT ;0 to 59
|
|||
|
|
|||
|
byhrlist = hour / ( hour *("," hour) )
|
|||
|
|
|||
|
hour = 1DIGIT / 2DIGIT ;0 to 23
|
|||
|
|
|||
|
bywdaylist = weekdaynum / ( weekdaynum *("," weekdaynum) )
|
|||
|
|
|||
|
weekdaynum = [([plus] ordwk / minus ordwk)] weekday
|
|||
|
|
|||
|
plus = "+"
|
|||
|
|
|||
|
minus = "-"
|
|||
|
|
|||
|
ordwk = 1DIGIT / 2DIGIT ;1 to 53
|
|||
|
|
|||
|
weekday = "SU" / "MO" / "TU" / "WE" / "TH" / "FR" / "SA"
|
|||
|
;Corresponding to SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY,
|
|||
|
;FRIDAY, SATURDAY and SUNDAY days of the week.
|
|||
|
|
|||
|
bymodaylist = monthdaynum / ( monthdaynum *("," monthdaynum) )
|
|||
|
|
|||
|
monthdaynum = ([plus] ordmoday) / (minus ordmoday)
|
|||
|
|
|||
|
ordmoday = 1DIGIT / 2DIGIT ;1 to 31
|
|||
|
|
|||
|
byyrdaylist = yeardaynum / ( yeardaynum *("," yeardaynum) )
|
|||
|
|
|||
|
yeardaynum = ([plus] ordyrday) / (minus ordyrday)
|
|||
|
|
|||
|
ordyrday = 1DIGIT / 2DIGIT / 3DIGIT ;1 to 366
|
|||
|
|
|||
|
bywknolist = weeknum / ( weeknum *("," weeknum) )
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 41]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
weeknum = ([plus] ordwk) / (minus ordwk)
|
|||
|
|
|||
|
bymolist = monthnum / ( monthnum *("," monthnum) )
|
|||
|
|
|||
|
monthnum = 1DIGIT / 2DIGIT ;1 to 12
|
|||
|
|
|||
|
bysplist = setposday / ( setposday *("," setposday) )
|
|||
|
|
|||
|
setposday = yeardaynum
|
|||
|
|
|||
|
Description: If the property permits, multiple "recur" values are
|
|||
|
specified by a COMMA character (US-ASCII decimal 44) separated list
|
|||
|
of values. The value type is a structured value consisting of a list
|
|||
|
of one or more recurrence grammar parts. Each rule part is defined by
|
|||
|
a NAME=VALUE pair. The rule parts are separated from each other by
|
|||
|
the SEMICOLON character (US-ASCII decimal 59). The rule parts are not
|
|||
|
ordered in any particular sequence. Individual rule parts MUST only
|
|||
|
be specified once.
|
|||
|
|
|||
|
The FREQ rule part identifies the type of recurrence rule. This rule
|
|||
|
part MUST be specified in the recurrence rule. Valid values include
|
|||
|
SECONDLY, to specify repeating events based on an interval of a
|
|||
|
second or more; MINUTELY, to specify repeating events based on an
|
|||
|
interval of a minute or more; HOURLY, to specify repeating events
|
|||
|
based on an interval of an hour or more; DAILY, to specify repeating
|
|||
|
events based on an interval of a day or more; WEEKLY, to specify
|
|||
|
repeating events based on an interval of a week or more; MONTHLY, to
|
|||
|
specify repeating events based on an interval of a month or more; and
|
|||
|
YEARLY, to specify repeating events based on an interval of a year or
|
|||
|
more.
|
|||
|
|
|||
|
The INTERVAL rule part contains a positive integer representing how
|
|||
|
often the recurrence rule repeats. The default value is "1", meaning
|
|||
|
every second for a SECONDLY rule, or every minute for a MINUTELY
|
|||
|
rule, every hour for an HOURLY rule, every day for a DAILY rule,
|
|||
|
every week for a WEEKLY rule, every month for a MONTHLY rule and
|
|||
|
every year for a YEARLY rule.
|
|||
|
|
|||
|
The UNTIL rule part defines a date-time value which bounds the
|
|||
|
recurrence rule in an inclusive manner. If the value specified by
|
|||
|
UNTIL is synchronized with the specified recurrence, this date or
|
|||
|
date-time becomes the last instance of the recurrence. If specified
|
|||
|
as a date-time value, then it MUST be specified in an UTC time
|
|||
|
format. If not present, and the COUNT rule part is also not present,
|
|||
|
the RRULE is considered to repeat forever.
|
|||
|
|
|||
|
The COUNT rule part defines the number of occurrences at which to
|
|||
|
range-bound the recurrence. The "DTSTART" property value, if
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 42]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
specified, counts as the first occurrence.
|
|||
|
|
|||
|
The BYSECOND rule part specifies a COMMA character (US-ASCII decimal
|
|||
|
44) separated list of seconds within a minute. Valid values are 0 to
|
|||
|
59. The BYMINUTE rule part specifies a COMMA character (US-ASCII
|
|||
|
decimal 44) separated list of minutes within an hour. Valid values
|
|||
|
are 0 to 59. The BYHOUR rule part specifies a COMMA character (US-
|
|||
|
ASCII decimal 44) separated list of hours of the day. Valid values
|
|||
|
are 0 to 23.
|
|||
|
|
|||
|
The BYDAY rule part specifies a COMMA character (US-ASCII decimal 44)
|
|||
|
separated list of days of the week; MO indicates Monday; TU indicates
|
|||
|
Tuesday; WE indicates Wednesday; TH indicates Thursday; FR indicates
|
|||
|
Friday; SA indicates Saturday; SU indicates Sunday.
|
|||
|
|
|||
|
Each BYDAY value can also be preceded by a positive (+n) or negative
|
|||
|
(-n) integer. If present, this indicates the nth occurrence of the
|
|||
|
specific day within the MONTHLY or YEARLY RRULE. For example, within
|
|||
|
a MONTHLY rule, +1MO (or simply 1MO) represents the first Monday
|
|||
|
within the month, whereas -1MO represents the last Monday of the
|
|||
|
month. If an integer modifier is not present, it means all days of
|
|||
|
this type within the specified frequency. For example, within a
|
|||
|
MONTHLY rule, MO represents all Mondays within the month.
|
|||
|
|
|||
|
The BYMONTHDAY rule part specifies a COMMA character (ASCII decimal
|
|||
|
44) separated list of days of the month. Valid values are 1 to 31 or
|
|||
|
-31 to -1. For example, -10 represents the tenth to the last day of
|
|||
|
the month.
|
|||
|
|
|||
|
The BYYEARDAY rule part specifies a COMMA character (US-ASCII decimal
|
|||
|
44) separated list of days of the year. Valid values are 1 to 366 or
|
|||
|
-366 to -1. For example, -1 represents the last day of the year
|
|||
|
(December 31st) and -306 represents the 306th to the last day of the
|
|||
|
year (March 1st).
|
|||
|
|
|||
|
The BYWEEKNO rule part specifies a COMMA character (US-ASCII decimal
|
|||
|
44) separated list of ordinals specifying weeks of the year. Valid
|
|||
|
values are 1 to 53 or -53 to -1. This corresponds to weeks according
|
|||
|
to week numbering as defined in [ISO 8601]. A week is defined as a
|
|||
|
seven day period, starting on the day of the week defined to be the
|
|||
|
week start (see WKST). Week number one of the calendar year is the
|
|||
|
first week which contains at least four (4) days in that calendar
|
|||
|
year. This rule part is only valid for YEARLY rules. For example, 3
|
|||
|
represents the third week of the year.
|
|||
|
|
|||
|
Note: Assuming a Monday week start, week 53 can only occur when
|
|||
|
Thursday is January 1 or if it is a leap year and Wednesday is
|
|||
|
January 1.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 43]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
The BYMONTH rule part specifies a COMMA character (US-ASCII decimal
|
|||
|
44) separated list of months of the year. Valid values are 1 to 12.
|
|||
|
|
|||
|
The WKST rule part specifies the day on which the workweek starts.
|
|||
|
Valid values are MO, TU, WE, TH, FR, SA and SU. This is significant
|
|||
|
when a WEEKLY RRULE has an interval greater than 1, and a BYDAY rule
|
|||
|
part is specified. This is also significant when in a YEARLY RRULE
|
|||
|
when a BYWEEKNO rule part is specified. The default value is MO.
|
|||
|
|
|||
|
The BYSETPOS rule part specifies a COMMA character (US-ASCII decimal
|
|||
|
44) separated list of values which corresponds to the nth occurrence
|
|||
|
within the set of events specified by the rule. Valid values are 1 to
|
|||
|
366 or -366 to -1. It MUST only be used in conjunction with another
|
|||
|
BYxxx rule part. For example "the last work day of the month" could
|
|||
|
be represented as:
|
|||
|
|
|||
|
RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1
|
|||
|
|
|||
|
Each BYSETPOS value can include a positive (+n) or negative (-n)
|
|||
|
integer. If present, this indicates the nth occurrence of the
|
|||
|
specific occurrence within the set of events specified by the rule.
|
|||
|
|
|||
|
If BYxxx rule part values are found which are beyond the available
|
|||
|
scope (ie, BYMONTHDAY=30 in February), they are simply ignored.
|
|||
|
|
|||
|
Information, not contained in the rule, necessary to determine the
|
|||
|
various recurrence instance start time and dates are derived from the
|
|||
|
Start Time (DTSTART) entry attribute. For example,
|
|||
|
"FREQ=YEARLY;BYMONTH=1" doesn't specify a specific day within the
|
|||
|
month or a time. This information would be the same as what is
|
|||
|
specified for DTSTART.
|
|||
|
|
|||
|
BYxxx rule parts modify the recurrence in some manner. BYxxx rule
|
|||
|
parts for a period of time which is the same or greater than the
|
|||
|
frequency generally reduce or limit the number of occurrences of the
|
|||
|
recurrence generated. For example, "FREQ=DAILY;BYMONTH=1" reduces the
|
|||
|
number of recurrence instances from all days (if BYMONTH tag is not
|
|||
|
present) to all days in January. BYxxx rule parts for a period of
|
|||
|
time less than the frequency generally increase or expand the number
|
|||
|
of occurrences of the recurrence. For example,
|
|||
|
"FREQ=YEARLY;BYMONTH=1,2" increases the number of days within the
|
|||
|
yearly recurrence set from 1 (if BYMONTH tag is not present) to 2.
|
|||
|
|
|||
|
If multiple BYxxx rule parts are specified, then after evaluating the
|
|||
|
specified FREQ and INTERVAL rule parts, the BYxxx rule parts are
|
|||
|
applied to the current set of evaluated occurrences in the following
|
|||
|
order: BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY, BYDAY, BYHOUR,
|
|||
|
BYMINUTE, BYSECOND and BYSETPOS; then COUNT and UNTIL are evaluated.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 44]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
Here is an example of evaluating multiple BYxxx rule parts.
|
|||
|
|
|||
|
DTSTART;TZID=US-Eastern:19970105T083000
|
|||
|
RRULE:FREQ=YEARLY;INTERVAL=2;BYMONTH=1;BYDAY=SU;BYHOUR=8,9;
|
|||
|
BYMINUTE=30
|
|||
|
|
|||
|
First, the "INTERVAL=2" would be applied to "FREQ=YEARLY" to arrive
|
|||
|
at "every other year". Then, "BYMONTH=1" would be applied to arrive
|
|||
|
at "every January, every other year". Then, "BYDAY=SU" would be
|
|||
|
applied to arrive at "every Sunday in January, every other year".
|
|||
|
Then, "BYHOUR=8,9" would be applied to arrive at "every Sunday in
|
|||
|
January at 8 AM and 9 AM, every other year". Then, "BYMINUTE=30"
|
|||
|
would be applied to arrive at "every Sunday in January at 8:30 AM and
|
|||
|
9:30 AM, every other year". Then, lacking information from RRULE, the
|
|||
|
second is derived from DTSTART, to end up in "every Sunday in January
|
|||
|
at 8:30:00 AM and 9:30:00 AM, every other year". Similarly, if the
|
|||
|
BYMINUTE, BYHOUR, BYDAY, BYMONTHDAY or BYMONTH rule part were
|
|||
|
missing, the appropriate minute, hour, day or month would have been
|
|||
|
retrieved from the "DTSTART" property.
|
|||
|
|
|||
|
No additional content value encoding (i.e., BACKSLASH character
|
|||
|
encoding) is defined for this value type.
|
|||
|
|
|||
|
Example: The following is a rule which specifies 10 meetings which
|
|||
|
occur every other day:
|
|||
|
|
|||
|
FREQ=DAILY;COUNT=10;INTERVAL=2
|
|||
|
|
|||
|
There are other examples specified in the "RRULE" specification.
|
|||
|
|
|||
|
4.3.11 Text
|
|||
|
|
|||
|
Value Name: TEXT
|
|||
|
|
|||
|
Purpose This value type is used to identify values that contain human
|
|||
|
readable text.
|
|||
|
|
|||
|
Formal Definition: The character sets supported by this revision of
|
|||
|
iCalendar are UTF-8 and US ASCII thereof. The applicability to other
|
|||
|
character sets is for future work. The value type is defined by the
|
|||
|
following notation.
|
|||
|
|
|||
|
text = *(TSAFE-CHAR / ":" / DQUOTE / ESCAPED-CHAR)
|
|||
|
; Folded according to description above
|
|||
|
|
|||
|
ESCAPED-CHAR = "\\" / "\;" / "\," / "\N" / "\n")
|
|||
|
; \\ encodes \, \N or \n encodes newline
|
|||
|
; \; encodes ;, \, encodes ,
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 45]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
TSAFE-CHAR = %x20-21 / %x23-2B / %x2D-39 / %x3C-5B
|
|||
|
%x5D-7E / NON-US-ASCII
|
|||
|
; Any character except CTLs not needed by the current
|
|||
|
; character set, DQUOTE, ";", ":", "\", ","
|
|||
|
|
|||
|
Note: Certain other character sets may require modification of the
|
|||
|
above definitions, but this is beyond the scope of this document.
|
|||
|
|
|||
|
Description: If the property permits, multiple "text" values are
|
|||
|
specified by a COMMA character (US-ASCII decimal 44) separated list
|
|||
|
of values.
|
|||
|
|
|||
|
The language in which the text is represented can be controlled by
|
|||
|
the "LANGUAGE" property parameter.
|
|||
|
|
|||
|
An intentional formatted text line break MUST only be included in a
|
|||
|
"TEXT" property value by representing the line break with the
|
|||
|
character sequence of BACKSLASH (US-ASCII decimal 92), followed by a
|
|||
|
LATIN SMALL LETTER N (US-ASCII decimal 110) or a LATIN CAPITAL LETTER
|
|||
|
N (US-ASCII decimal 78), that is "\n" or "\N".
|
|||
|
|
|||
|
The "TEXT" property values may also contain special characters that
|
|||
|
are used to signify delimiters, such as a COMMA character for lists
|
|||
|
of values or a SEMICOLON character for structured values. In order to
|
|||
|
support the inclusion of these special characters in "TEXT" property
|
|||
|
values, they MUST be escaped with a BACKSLASH character. A BACKSLASH
|
|||
|
character (US-ASCII decimal 92) in a "TEXT" property value MUST be
|
|||
|
escaped with another BACKSLASH character. A COMMA character in a
|
|||
|
"TEXT" property value MUST be escaped with a BACKSLASH character
|
|||
|
(US-ASCII decimal 92). A SEMICOLON character in a "TEXT" property
|
|||
|
value MUST be escaped with a BACKSLASH character (US-ASCII decimal
|
|||
|
92). However, a COLON character in a "TEXT" property value SHALL NOT
|
|||
|
be escaped with a BACKSLASH character.Example: A multiple line value
|
|||
|
of:
|
|||
|
|
|||
|
Project XYZ Final Review
|
|||
|
Conference Room - 3B
|
|||
|
Come Prepared.
|
|||
|
|
|||
|
would be represented as:
|
|||
|
|
|||
|
Project XYZ Final Review\nConference Room - 3B\nCome Prepared.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 46]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
4.3.12 Time
|
|||
|
|
|||
|
Value Name: TIME
|
|||
|
|
|||
|
Purpose: This value type is used to identify values that contain a
|
|||
|
time of day.
|
|||
|
|
|||
|
Formal Definition: The data type is defined by the following
|
|||
|
notation:
|
|||
|
|
|||
|
time = time-hour time-minute time-second [time-utc]
|
|||
|
|
|||
|
time-hour = 2DIGIT ;00-23
|
|||
|
time-minute = 2DIGIT ;00-59
|
|||
|
time-second = 2DIGIT ;00-60
|
|||
|
;The "60" value is used to account for "leap" seconds.
|
|||
|
|
|||
|
time-utc = "Z"
|
|||
|
|
|||
|
Description: If the property permits, multiple "time" values are
|
|||
|
specified by a COMMA character (US-ASCII decimal 44) separated list
|
|||
|
of values. No additional content value encoding (i.e., BACKSLASH
|
|||
|
character encoding) is defined for this value type.
|
|||
|
|
|||
|
The "TIME" data type is used to identify values that contain a time
|
|||
|
of day. The format is based on the [ISO 8601] complete
|
|||
|
representation, basic format for a time of day. The text format
|
|||
|
consists of a two-digit 24-hour of the day (i.e., values 0-23), two-
|
|||
|
digit minute in the hour (i.e., values 0-59), and two-digit seconds
|
|||
|
in the minute (i.e., values 0-60). The seconds value of 60 MUST only
|
|||
|
to be used to account for "leap" seconds. Fractions of a second are
|
|||
|
not supported by this format.
|
|||
|
|
|||
|
In parallel to the "DATE-TIME" definition above, the "TIME" data type
|
|||
|
expresses time values in three forms:
|
|||
|
|
|||
|
The form of time with UTC offset MUST NOT be used. For example, the
|
|||
|
following is NOT VALID for a time value:
|
|||
|
|
|||
|
230000-0800 ;Invalid time format
|
|||
|
|
|||
|
FORM #1 LOCAL TIME
|
|||
|
|
|||
|
The local time form is simply a time value that does not contain the
|
|||
|
UTC designator nor does it reference a time zone. For example, 11:00
|
|||
|
PM:
|
|||
|
|
|||
|
230000
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 47]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
Time values of this type are said to be "floating" and are not bound
|
|||
|
to any time zone in particular. They are used to represent the same
|
|||
|
hour, minute, and second value regardless of which time zone is
|
|||
|
currently being observed. For example, an event can be defined that
|
|||
|
indicates that an individual will be busy from 11:00 AM to 1:00 PM
|
|||
|
every day, no matter which time zone the person is in. In these
|
|||
|
cases, a local time can be specified. The recipient of an iCalendar
|
|||
|
object with a property value consisting of a local time, without any
|
|||
|
relative time zone information, SHOULD interpret the value as being
|
|||
|
fixed to whatever time zone the ATTENDEE is in at any given moment.
|
|||
|
This means that two ATTENDEEs may participate in the same event at
|
|||
|
different UTC times; floating time SHOULD only be used where that is
|
|||
|
reasonable behavior.
|
|||
|
|
|||
|
In most cases, a fixed time is desired. To properly communicate a
|
|||
|
fixed time in a property value, either UTC time or local time with
|
|||
|
time zone reference MUST be specified.
|
|||
|
|
|||
|
The use of local time in a TIME value without the TZID property
|
|||
|
parameter is to be interpreted as a local time value, regardless of
|
|||
|
the existence of "VTIMEZONE" calendar components in the iCalendar
|
|||
|
object.
|
|||
|
|
|||
|
FORM #2: UTC TIME
|
|||
|
|
|||
|
UTC time, or absolute time, is identified by a LATIN CAPITAL LETTER Z
|
|||
|
suffix character (US-ASCII decimal 90), the UTC designator, appended
|
|||
|
to the time value. For example, the following represents 07:00 AM
|
|||
|
UTC:
|
|||
|
|
|||
|
070000Z
|
|||
|
|
|||
|
The TZID property parameter MUST NOT be applied to TIME properties
|
|||
|
whose time values are specified in UTC.
|
|||
|
|
|||
|
FORM #3: LOCAL TIME AND TIME ZONE REFERENCE
|
|||
|
|
|||
|
The local time with reference to time zone information form is
|
|||
|
identified by the use the TZID property parameter to reference the
|
|||
|
appropriate time zone definition. TZID is discussed in detail in the
|
|||
|
section on Time Zone.
|
|||
|
|
|||
|
Example: The following represents 8:30 AM in New York in Winter, five
|
|||
|
hours behind UTC, in each of the three formats using the "X-
|
|||
|
TIMEOFDAY" non-standard property:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 48]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
X-TIMEOFDAY:083000
|
|||
|
|
|||
|
X-TIMEOFDAY:133000Z
|
|||
|
|
|||
|
X-TIMEOFDAY;TZID=US-Eastern:083000
|
|||
|
|
|||
|
4.3.13 URI
|
|||
|
|
|||
|
Value Name: URI
|
|||
|
|
|||
|
Purpose: This value type is used to identify values that contain a
|
|||
|
uniform resource identifier (URI) type of reference to the property
|
|||
|
value.
|
|||
|
|
|||
|
Formal Definition: The data type is defined by the following
|
|||
|
notation:
|
|||
|
|
|||
|
uri = <As defined by any IETF RFC>
|
|||
|
|
|||
|
Description: This data type might be used to reference binary
|
|||
|
information, for values that are large, or otherwise undesirable to
|
|||
|
include directly in the iCalendar object.
|
|||
|
|
|||
|
The URI value formats in RFC 1738, RFC 2111 and any other IETF
|
|||
|
registered value format can be specified.
|
|||
|
|
|||
|
Any IANA registered URI format can be used. These include, but are
|
|||
|
not limited to, those defined in RFC 1738 and RFC 2111.
|
|||
|
|
|||
|
When a property parameter value is a URI value type, the URI MUST be
|
|||
|
specified as a quoted-string value.
|
|||
|
|
|||
|
No additional content value encoding (i.e., BACKSLASH character
|
|||
|
encoding) is defined for this value type.
|
|||
|
|
|||
|
Example: The following is a URI for a network file:
|
|||
|
|
|||
|
http://host1.com/my-report.txt
|
|||
|
|
|||
|
4.3.14 UTC Offset
|
|||
|
|
|||
|
Value Name: UTC-OFFSET
|
|||
|
|
|||
|
Purpose: This value type is used to identify properties that contain
|
|||
|
an offset from UTC to local time.
|
|||
|
|
|||
|
Formal Definition: The data type is defined by the following
|
|||
|
notation:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 49]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
utc-offset = time-numzone ;As defined above in time data type
|
|||
|
|
|||
|
time-numzone = ("+" / "-") time-hour time-minute [time-
|
|||
|
second]
|
|||
|
|
|||
|
Description: The PLUS SIGN character MUST be specified for positive
|
|||
|
UTC offsets (i.e., ahead of UTC). The value of "-0000" and "-000000"
|
|||
|
are not allowed. The time-second, if present, may not be 60; if
|
|||
|
absent, it defaults to zero.
|
|||
|
|
|||
|
No additional content value encoding (i.e., BACKSLASH character
|
|||
|
encoding) is defined for this value type.
|
|||
|
|
|||
|
Example: The following UTC offsets are given for standard time for
|
|||
|
New York (five hours behind UTC) and Geneva (one hour ahead of UTC):
|
|||
|
|
|||
|
-0500
|
|||
|
|
|||
|
+0100
|
|||
|
|
|||
|
4.4 iCalendar Object
|
|||
|
|
|||
|
The Calendaring and Scheduling Core Object is a collection of
|
|||
|
calendaring and scheduling information. Typically, this information
|
|||
|
will consist of a single iCalendar object. However, multiple
|
|||
|
iCalendar objects can be sequentially grouped together. The first
|
|||
|
line and last line of the iCalendar object MUST contain a pair of
|
|||
|
iCalendar object delimiter strings. The syntax for an iCalendar
|
|||
|
object is as follows:
|
|||
|
|
|||
|
icalobject = 1*("BEGIN" ":" "VCALENDAR" CRLF
|
|||
|
icalbody
|
|||
|
"END" ":" "VCALENDAR" CRLF)
|
|||
|
|
|||
|
The following is a simple example of an iCalendar object:
|
|||
|
|
|||
|
BEGIN:VCALENDAR
|
|||
|
VERSION:2.0
|
|||
|
PRODID:-//hacksw/handcal//NONSGML v1.0//EN
|
|||
|
BEGIN:VEVENT
|
|||
|
DTSTART:19970714T170000Z
|
|||
|
DTEND:19970715T035959Z
|
|||
|
SUMMARY:Bastille Day Party
|
|||
|
END:VEVENT
|
|||
|
END:VCALENDAR
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 50]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
4.5 Property
|
|||
|
|
|||
|
A property is the definition of an individual attribute describing a
|
|||
|
calendar or a calendar component. A property takes the form defined
|
|||
|
by the "contentline" notation defined in section 4.1.1.
|
|||
|
|
|||
|
The following is an example of a property:
|
|||
|
|
|||
|
DTSTART:19960415T133000Z
|
|||
|
|
|||
|
This memo imposes no ordering of properties within an iCalendar
|
|||
|
object.
|
|||
|
|
|||
|
Property names, parameter names and enumerated parameter values are
|
|||
|
case insensitive. For example, the property name "DUE" is the same as
|
|||
|
"due" and "Due", DTSTART;TZID=US-Eastern:19980714T120000 is the same
|
|||
|
as DtStart;TzID=US-Eastern:19980714T120000.
|
|||
|
|
|||
|
4.6 Calendar Components
|
|||
|
|
|||
|
The body of the iCalendar object consists of a sequence of calendar
|
|||
|
properties and one or more calendar components. The calendar
|
|||
|
properties are attributes that apply to the calendar as a whole. The
|
|||
|
calendar components are collections of properties that express a
|
|||
|
particular calendar semantic. For example, the calendar component can
|
|||
|
specify an event, a to-do, a journal entry, time zone information, or
|
|||
|
free/busy time information, or an alarm.
|
|||
|
|
|||
|
The body of the iCalendar object is defined by the following
|
|||
|
notation:
|
|||
|
|
|||
|
icalbody = calprops component
|
|||
|
|
|||
|
calprops = 2*(
|
|||
|
|
|||
|
; 'prodid' and 'version' are both REQUIRED,
|
|||
|
; but MUST NOT occur more than once
|
|||
|
|
|||
|
prodid /version /
|
|||
|
|
|||
|
; 'calscale' and 'method' are optional,
|
|||
|
; but MUST NOT occur more than once
|
|||
|
|
|||
|
calscale /
|
|||
|
method /
|
|||
|
|
|||
|
x-prop
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 51]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
)
|
|||
|
|
|||
|
component = 1*(eventc / todoc / journalc / freebusyc /
|
|||
|
/ timezonec / iana-comp / x-comp)
|
|||
|
|
|||
|
iana-comp = "BEGIN" ":" iana-token CRLF
|
|||
|
|
|||
|
1*contentline
|
|||
|
|
|||
|
"END" ":" iana-token CRLF
|
|||
|
|
|||
|
x-comp = "BEGIN" ":" x-name CRLF
|
|||
|
|
|||
|
1*contentline
|
|||
|
|
|||
|
"END" ":" x-name CRLF
|
|||
|
|
|||
|
An iCalendar object MUST include the "PRODID" and "VERSION" calendar
|
|||
|
properties. In addition, it MUST include at least one calendar
|
|||
|
component. Special forms of iCalendar objects are possible to publish
|
|||
|
just busy time (i.e., only a "VFREEBUSY" calendar component) or time
|
|||
|
zone (i.e., only a "VTIMEZONE" calendar component) information. In
|
|||
|
addition, a complex iCalendar object is possible that is used to
|
|||
|
capture a complete snapshot of the contents of a calendar (e.g.,
|
|||
|
composite of many different calendar components). More commonly, an
|
|||
|
iCalendar object will consist of just a single "VEVENT", "VTODO" or
|
|||
|
"VJOURNAL" calendar component.
|
|||
|
|
|||
|
4.6.1 Event Component
|
|||
|
|
|||
|
Component Name: "VEVENT"
|
|||
|
|
|||
|
Purpose: Provide a grouping of component properties that describe an
|
|||
|
event.
|
|||
|
|
|||
|
Format Definition: A "VEVENT" calendar component is defined by the
|
|||
|
following notation:
|
|||
|
|
|||
|
eventc = "BEGIN" ":" "VEVENT" CRLF
|
|||
|
eventprop *alarmc
|
|||
|
"END" ":" "VEVENT" CRLF
|
|||
|
|
|||
|
eventprop = *(
|
|||
|
|
|||
|
; the following are optional,
|
|||
|
; but MUST NOT occur more than once
|
|||
|
|
|||
|
class / created / description / dtstart / geo /
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 52]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
last-mod / location / organizer / priority /
|
|||
|
dtstamp / seq / status / summary / transp /
|
|||
|
uid / url / recurid /
|
|||
|
|
|||
|
; either 'dtend' or 'duration' may appear in
|
|||
|
; a 'eventprop', but 'dtend' and 'duration'
|
|||
|
; MUST NOT occur in the same 'eventprop'
|
|||
|
|
|||
|
dtend / duration /
|
|||
|
|
|||
|
; the following are optional,
|
|||
|
; and MAY occur more than once
|
|||
|
|
|||
|
attach / attendee / categories / comment /
|
|||
|
contact / exdate / exrule / rstatus / related /
|
|||
|
resources / rdate / rrule / x-prop
|
|||
|
|
|||
|
)
|
|||
|
|
|||
|
Description: A "VEVENT" calendar component is a grouping of component
|
|||
|
properties, and possibly including "VALARM" calendar components, that
|
|||
|
represents a scheduled amount of time on a calendar. For example, it
|
|||
|
can be an activity; such as a one-hour long, department meeting from
|
|||
|
8:00 AM to 9:00 AM, tomorrow. Generally, an event will take up time
|
|||
|
on an individual calendar. Hence, the event will appear as an opaque
|
|||
|
interval in a search for busy time. Alternately, the event can have
|
|||
|
its Time Transparency set to "TRANSPARENT" in order to prevent
|
|||
|
blocking of the event in searches for busy time.
|
|||
|
|
|||
|
The "VEVENT" is also the calendar component used to specify an
|
|||
|
anniversary or daily reminder within a calendar. These events have a
|
|||
|
DATE value type for the "DTSTART" property instead of the default
|
|||
|
data type of DATE-TIME. If such a "VEVENT" has a "DTEND" property, it
|
|||
|
MUST be specified as a DATE value also. The anniversary type of
|
|||
|
"VEVENT" can span more than one date (i.e, "DTEND" property value is
|
|||
|
set to a calendar date after the "DTSTART" property value).
|
|||
|
|
|||
|
The "DTSTART" property for a "VEVENT" specifies the inclusive start
|
|||
|
of the event. For recurring events, it also specifies the very first
|
|||
|
instance in the recurrence set. The "DTEND" property for a "VEVENT"
|
|||
|
calendar component specifies the non-inclusive end of the event. For
|
|||
|
cases where a "VEVENT" calendar component specifies a "DTSTART"
|
|||
|
property with a DATE data type but no "DTEND" property, the events
|
|||
|
non-inclusive end is the end of the calendar date specified by the
|
|||
|
"DTSTART" property. For cases where a "VEVENT" calendar component
|
|||
|
specifies a "DTSTART" property with a DATE-TIME data type but no
|
|||
|
"DTEND" property, the event ends on the same calendar date and time
|
|||
|
of day specified by the "DTSTART" property.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 53]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
The "VEVENT" calendar component cannot be nested within another
|
|||
|
calendar component. However, "VEVENT" calendar components can be
|
|||
|
related to each other or to a "VTODO" or to a "VJOURNAL" calendar
|
|||
|
component with the "RELATED-TO" property.
|
|||
|
|
|||
|
Example: The following is an example of the "VEVENT" calendar
|
|||
|
component used to represent a meeting that will also be opaque to
|
|||
|
searches for busy time:
|
|||
|
|
|||
|
BEGIN:VEVENT
|
|||
|
UID:19970901T130000Z-123401@host.com
|
|||
|
DTSTAMP:19970901T1300Z
|
|||
|
DTSTART:19970903T163000Z
|
|||
|
DTEND:19970903T190000Z
|
|||
|
SUMMARY:Annual Employee Review
|
|||
|
CLASS:PRIVATE
|
|||
|
CATEGORIES:BUSINESS,HUMAN RESOURCES
|
|||
|
END:VEVENT
|
|||
|
|
|||
|
The following is an example of the "VEVENT" calendar component used
|
|||
|
to represent a reminder that will not be opaque, but rather
|
|||
|
transparent, to searches for busy time:
|
|||
|
|
|||
|
BEGIN:VEVENT
|
|||
|
UID:19970901T130000Z-123402@host.com
|
|||
|
DTSTAMP:19970901T1300Z
|
|||
|
DTSTART:19970401T163000Z
|
|||
|
DTEND:19970402T010000Z
|
|||
|
SUMMARY:Laurel is in sensitivity awareness class.
|
|||
|
CLASS:PUBLIC
|
|||
|
CATEGORIES:BUSINESS,HUMAN RESOURCES
|
|||
|
TRANSP:TRANSPARENT
|
|||
|
END:VEVENT
|
|||
|
|
|||
|
The following is an example of the "VEVENT" calendar component used
|
|||
|
to represent an anniversary that will occur annually. Since it takes
|
|||
|
up no time, it will not appear as opaque in a search for busy time;
|
|||
|
no matter what the value of the "TRANSP" property indicates:
|
|||
|
|
|||
|
BEGIN:VEVENT
|
|||
|
UID:19970901T130000Z-123403@host.com
|
|||
|
DTSTAMP:19970901T1300Z
|
|||
|
DTSTART:19971102
|
|||
|
SUMMARY:Our Blissful Anniversary
|
|||
|
CLASS:CONFIDENTIAL
|
|||
|
CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION
|
|||
|
RRULE:FREQ=YEARLY
|
|||
|
END:VEVENT
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 54]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
4.6.2 To-do Component
|
|||
|
|
|||
|
Component Name: VTODO
|
|||
|
|
|||
|
Purpose: Provide a grouping of calendar properties that describe a
|
|||
|
to-do.
|
|||
|
|
|||
|
Formal Definition: A "VTODO" calendar component is defined by the
|
|||
|
following notation:
|
|||
|
|
|||
|
todoc = "BEGIN" ":" "VTODO" CRLF
|
|||
|
todoprop *alarmc
|
|||
|
"END" ":" "VTODO" CRLF
|
|||
|
|
|||
|
todoprop = *(
|
|||
|
|
|||
|
; the following are optional,
|
|||
|
; but MUST NOT occur more than once
|
|||
|
|
|||
|
class / completed / created / description / dtstamp /
|
|||
|
dtstart / geo / last-mod / location / organizer /
|
|||
|
percent / priority / recurid / seq / status /
|
|||
|
summary / uid / url /
|
|||
|
|
|||
|
; either 'due' or 'duration' may appear in
|
|||
|
; a 'todoprop', but 'due' and 'duration'
|
|||
|
; MUST NOT occur in the same 'todoprop'
|
|||
|
|
|||
|
due / duration /
|
|||
|
|
|||
|
; the following are optional,
|
|||
|
; and MAY occur more than once
|
|||
|
attach / attendee / categories / comment / contact /
|
|||
|
exdate / exrule / rstatus / related / resources /
|
|||
|
rdate / rrule / x-prop
|
|||
|
|
|||
|
)
|
|||
|
|
|||
|
Description: A "VTODO" calendar component is a grouping of component
|
|||
|
properties and possibly "VALARM" calendar components that represent
|
|||
|
an action-item or assignment. For example, it can be used to
|
|||
|
represent an item of work assigned to an individual; such as "turn in
|
|||
|
travel expense today".
|
|||
|
|
|||
|
The "VTODO" calendar component cannot be nested within another
|
|||
|
calendar component. However, "VTODO" calendar components can be
|
|||
|
related to each other or to a "VTODO" or to a "VJOURNAL" calendar
|
|||
|
component with the "RELATED-TO" property.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 55]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
A "VTODO" calendar component without the "DTSTART" and "DUE" (or
|
|||
|
"DURATION") properties specifies a to-do that will be associated with
|
|||
|
each successive calendar date, until it is completed.
|
|||
|
|
|||
|
Example: The following is an example of a "VTODO" calendar component:
|
|||
|
|
|||
|
BEGIN:VTODO
|
|||
|
UID:19970901T130000Z-123404@host.com
|
|||
|
DTSTAMP:19970901T1300Z
|
|||
|
DTSTART:19970415T133000Z
|
|||
|
DUE:19970416T045959Z
|
|||
|
SUMMARY:1996 Income Tax Preparation
|
|||
|
CLASS:CONFIDENTIAL
|
|||
|
CATEGORIES:FAMILY,FINANCE
|
|||
|
PRIORITY:1
|
|||
|
STATUS:NEEDS-ACTION
|
|||
|
END:VTODO
|
|||
|
|
|||
|
4.6.3 Journal Component
|
|||
|
|
|||
|
Component Name: VJOURNAL
|
|||
|
|
|||
|
Purpose: Provide a grouping of component properties that describe a
|
|||
|
journal entry.
|
|||
|
|
|||
|
Formal Definition: A "VJOURNAL" calendar component is defined by the
|
|||
|
following notation:
|
|||
|
|
|||
|
journalc = "BEGIN" ":" "VJOURNAL" CRLF
|
|||
|
jourprop
|
|||
|
"END" ":" "VJOURNAL" CRLF
|
|||
|
|
|||
|
jourprop = *(
|
|||
|
|
|||
|
; the following are optional,
|
|||
|
; but MUST NOT occur more than once
|
|||
|
|
|||
|
class / created / description / dtstart / dtstamp /
|
|||
|
last-mod / organizer / recurid / seq / status /
|
|||
|
summary / uid / url /
|
|||
|
|
|||
|
; the following are optional,
|
|||
|
; and MAY occur more than once
|
|||
|
|
|||
|
attach / attendee / categories / comment /
|
|||
|
contact / exdate / exrule / related / rdate /
|
|||
|
rrule / rstatus / x-prop
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 56]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
)
|
|||
|
|
|||
|
Description: A "VJOURNAL" calendar component is a grouping of
|
|||
|
component properties that represent one or more descriptive text
|
|||
|
notes associated with a particular calendar date. The "DTSTART"
|
|||
|
property is used to specify the calendar date that the journal entry
|
|||
|
is associated with. Generally, it will have a DATE value data type,
|
|||
|
but it can also be used to specify a DATE-TIME value data type.
|
|||
|
Examples of a journal entry include a daily record of a legislative
|
|||
|
body or a journal entry of individual telephone contacts for the day
|
|||
|
or an ordered list of accomplishments for the day. The "VJOURNAL"
|
|||
|
calendar component can also be used to associate a document with a
|
|||
|
calendar date.
|
|||
|
|
|||
|
The "VJOURNAL" calendar component does not take up time on a
|
|||
|
calendar. Hence, it does not play a role in free or busy time
|
|||
|
searches - - it is as though it has a time transparency value of
|
|||
|
TRANSPARENT. It is transparent to any such searches.
|
|||
|
|
|||
|
The "VJOURNAL" calendar component cannot be nested within another
|
|||
|
calendar component. However, "VJOURNAL" calendar components can be
|
|||
|
related to each other or to a "VEVENT" or to a "VTODO" calendar
|
|||
|
component, with the "RELATED-TO" property.
|
|||
|
|
|||
|
Example: The following is an example of the "VJOURNAL" calendar
|
|||
|
component:
|
|||
|
|
|||
|
BEGIN:VJOURNAL
|
|||
|
UID:19970901T130000Z-123405@host.com
|
|||
|
DTSTAMP:19970901T1300Z
|
|||
|
DTSTART;VALUE=DATE:19970317
|
|||
|
SUMMARY:Staff meeting minutes
|
|||
|
DESCRIPTION:1. Staff meeting: Participants include Joe\, Lisa
|
|||
|
and Bob. Aurora project plans were reviewed. There is currently
|
|||
|
no budget reserves for this project. Lisa will escalate to
|
|||
|
management. Next meeting on Tuesday.\n
|
|||
|
2. Telephone Conference: ABC Corp. sales representative called
|
|||
|
to discuss new printer. Promised to get us a demo by Friday.\n
|
|||
|
3. Henry Miller (Handsoff Insurance): Car was totaled by tree.
|
|||
|
Is looking into a loaner car. 654-2323 (tel).
|
|||
|
END:VJOURNAL
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 57]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
4.6.4 Free/Busy Component
|
|||
|
|
|||
|
Component Name: VFREEBUSY
|
|||
|
|
|||
|
Purpose: Provide a grouping of component properties that describe
|
|||
|
either a request for free/busy time, describe a response to a request
|
|||
|
for free/busy time or describe a published set of busy time.
|
|||
|
|
|||
|
Formal Definition: A "VFREEBUSY" calendar component is defined by the
|
|||
|
following notation:
|
|||
|
|
|||
|
freebusyc = "BEGIN" ":" "VFREEBUSY" CRLF
|
|||
|
fbprop
|
|||
|
"END" ":" "VFREEBUSY" CRLF
|
|||
|
|
|||
|
fbprop = *(
|
|||
|
|
|||
|
; the following are optional,
|
|||
|
; but MUST NOT occur more than once
|
|||
|
|
|||
|
contact / dtstart / dtend / duration / dtstamp /
|
|||
|
organizer / uid / url /
|
|||
|
|
|||
|
; the following are optional,
|
|||
|
; and MAY occur more than once
|
|||
|
|
|||
|
attendee / comment / freebusy / rstatus / x-prop
|
|||
|
|
|||
|
)
|
|||
|
|
|||
|
Description: A "VFREEBUSY" calendar component is a grouping of
|
|||
|
component properties that represents either a request for, a reply to
|
|||
|
a request for free or busy time information or a published set of
|
|||
|
busy time information.
|
|||
|
|
|||
|
When used to request free/busy time information, the "ATTENDEE"
|
|||
|
property specifies the calendar users whose free/busy time is being
|
|||
|
requested; the "ORGANIZER" property specifies the calendar user who
|
|||
|
is requesting the free/busy time; the "DTSTART" and "DTEND"
|
|||
|
properties specify the window of time for which the free/busy time is
|
|||
|
being requested; the "UID" and "DTSTAMP" properties are specified to
|
|||
|
assist in proper sequencing of multiple free/busy time requests.
|
|||
|
|
|||
|
When used to reply to a request for free/busy time, the "ATTENDEE"
|
|||
|
property specifies the calendar user responding to the free/busy time
|
|||
|
request; the "ORGANIZER" property specifies the calendar user that
|
|||
|
originally requested the free/busy time; the "FREEBUSY" property
|
|||
|
specifies the free/busy time information (if it exists); and the
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 58]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
"UID" and "DTSTAMP" properties are specified to assist in proper
|
|||
|
sequencing of multiple free/busy time replies.
|
|||
|
|
|||
|
When used to publish busy time, the "ORGANIZER" property specifies
|
|||
|
the calendar user associated with the published busy time; the
|
|||
|
"DTSTART" and "DTEND" properties specify an inclusive time window
|
|||
|
that surrounds the busy time information; the "FREEBUSY" property
|
|||
|
specifies the published busy time information; and the "DTSTAMP"
|
|||
|
property specifies the date/time that iCalendar object was created.
|
|||
|
|
|||
|
The "VFREEBUSY" calendar component cannot be nested within another
|
|||
|
calendar component. Multiple "VFREEBUSY" calendar components can be
|
|||
|
specified within an iCalendar object. This permits the grouping of
|
|||
|
Free/Busy information into logical collections, such as monthly
|
|||
|
groups of busy time information.
|
|||
|
|
|||
|
The "VFREEBUSY" calendar component is intended for use in iCalendar
|
|||
|
object methods involving requests for free time, requests for busy
|
|||
|
time, requests for both free and busy, and the associated replies.
|
|||
|
|
|||
|
Free/Busy information is represented with the "FREEBUSY" property.
|
|||
|
This property provides a terse representation of time periods. One or
|
|||
|
more "FREEBUSY" properties can be specified in the "VFREEBUSY"
|
|||
|
calendar component.
|
|||
|
|
|||
|
When present in a "VFREEBUSY" calendar component, the "DTSTART" and
|
|||
|
"DTEND" properties SHOULD be specified prior to any "FREEBUSY"
|
|||
|
properties. In a free time request, these properties can be used in
|
|||
|
combination with the "DURATION" property to represent a request for a
|
|||
|
duration of free time within a specified window of time.
|
|||
|
|
|||
|
The recurrence properties ("RRULE", "EXRULE", "RDATE", "EXDATE") are
|
|||
|
not permitted within a "VFREEBUSY" calendar component. Any recurring
|
|||
|
events are resolved into their individual busy time periods using the
|
|||
|
"FREEBUSY" property.
|
|||
|
|
|||
|
Example: The following is an example of a "VFREEBUSY" calendar
|
|||
|
component used to request free or busy time information:
|
|||
|
|
|||
|
BEGIN:VFREEBUSY
|
|||
|
ORGANIZER:MAILTO:jane_doe@host1.com
|
|||
|
ATTENDEE:MAILTO:john_public@host2.com
|
|||
|
DTSTART:19971015T050000Z
|
|||
|
DTEND:19971016T050000Z
|
|||
|
DTSTAMP:19970901T083000Z
|
|||
|
END:VFREEBUSY
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 59]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
The following is an example of a "VFREEBUSY" calendar component used
|
|||
|
to reply to the request with busy time information:
|
|||
|
|
|||
|
BEGIN:VFREEBUSY
|
|||
|
ORGANIZER:MAILTO:jane_doe@host1.com
|
|||
|
ATTENDEE:MAILTO:john_public@host2.com
|
|||
|
DTSTAMP:19970901T100000Z
|
|||
|
FREEBUSY;VALUE=PERIOD:19971015T050000Z/PT8H30M,
|
|||
|
19971015T160000Z/PT5H30M,19971015T223000Z/PT6H30M
|
|||
|
URL:http://host2.com/pub/busy/jpublic-01.ifb
|
|||
|
COMMENT:This iCalendar file contains busy time information for
|
|||
|
the next three months.
|
|||
|
END:VFREEBUSY
|
|||
|
|
|||
|
The following is an example of a "VFREEBUSY" calendar component used
|
|||
|
to publish busy time information.
|
|||
|
|
|||
|
BEGIN:VFREEBUSY
|
|||
|
ORGANIZER:jsmith@host.com
|
|||
|
DTSTART:19980313T141711Z
|
|||
|
DTEND:19980410T141711Z
|
|||
|
FREEBUSY:19980314T233000Z/19980315T003000Z
|
|||
|
FREEBUSY:19980316T153000Z/19980316T163000Z
|
|||
|
FREEBUSY:19980318T030000Z/19980318T040000Z
|
|||
|
URL:http://www.host.com/calendar/busytime/jsmith.ifb
|
|||
|
END:VFREEBUSY
|
|||
|
|
|||
|
4.6.5 Time Zone Component
|
|||
|
|
|||
|
Component Name: VTIMEZONE
|
|||
|
|
|||
|
Purpose: Provide a grouping of component properties that defines a
|
|||
|
time zone.
|
|||
|
|
|||
|
Formal Definition: A "VTIMEZONE" calendar component is defined by the
|
|||
|
following notation:
|
|||
|
|
|||
|
timezonec = "BEGIN" ":" "VTIMEZONE" CRLF
|
|||
|
|
|||
|
2*(
|
|||
|
|
|||
|
; 'tzid' is required, but MUST NOT occur more
|
|||
|
; than once
|
|||
|
|
|||
|
tzid /
|
|||
|
|
|||
|
; 'last-mod' and 'tzurl' are optional,
|
|||
|
but MUST NOT occur more than once
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 60]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
last-mod / tzurl /
|
|||
|
|
|||
|
; one of 'standardc' or 'daylightc' MUST occur
|
|||
|
..; and each MAY occur more than once.
|
|||
|
|
|||
|
standardc / daylightc /
|
|||
|
|
|||
|
; the following is optional,
|
|||
|
; and MAY occur more than once
|
|||
|
|
|||
|
x-prop
|
|||
|
|
|||
|
)
|
|||
|
|
|||
|
"END" ":" "VTIMEZONE" CRLF
|
|||
|
|
|||
|
standardc = "BEGIN" ":" "STANDARD" CRLF
|
|||
|
|
|||
|
tzprop
|
|||
|
|
|||
|
"END" ":" "STANDARD" CRLF
|
|||
|
|
|||
|
daylightc = "BEGIN" ":" "DAYLIGHT" CRLF
|
|||
|
|
|||
|
tzprop
|
|||
|
|
|||
|
"END" ":" "DAYLIGHT" CRLF
|
|||
|
|
|||
|
tzprop = 3*(
|
|||
|
|
|||
|
; the following are each REQUIRED,
|
|||
|
; but MUST NOT occur more than once
|
|||
|
|
|||
|
dtstart / tzoffsetto / tzoffsetfrom /
|
|||
|
|
|||
|
; the following are optional,
|
|||
|
; and MAY occur more than once
|
|||
|
|
|||
|
comment / rdate / rrule / tzname / x-prop
|
|||
|
|
|||
|
)
|
|||
|
|
|||
|
Description: A time zone is unambiguously defined by the set of time
|
|||
|
measurement rules determined by the governing body for a given
|
|||
|
geographic area. These rules describe at a minimum the base offset
|
|||
|
from UTC for the time zone, often referred to as the Standard Time
|
|||
|
offset. Many locations adjust their Standard Time forward or backward
|
|||
|
by one hour, in order to accommodate seasonal changes in number of
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 61]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
daylight hours, often referred to as Daylight Saving Time. Some
|
|||
|
locations adjust their time by a fraction of an hour. Standard Time
|
|||
|
is also known as Winter Time. Daylight Saving Time is also known as
|
|||
|
Advanced Time, Summer Time, or Legal Time in certain countries. The
|
|||
|
following table shows the changes in time zone rules in effect for
|
|||
|
New York City starting from 1967. Each line represents a description
|
|||
|
or rule for a particular observance.
|
|||
|
|
|||
|
Effective Observance Rule
|
|||
|
|
|||
|
Date (Date/Time) Offset Abbreviation
|
|||
|
|
|||
|
1967-* last Sun in Oct, 02:00 -0500 EST
|
|||
|
|
|||
|
1967-1973 last Sun in Apr, 02:00 -0400 EDT
|
|||
|
|
|||
|
1974-1974 Jan 6, 02:00 -0400 EDT
|
|||
|
|
|||
|
1975-1975 Feb 23, 02:00 -0400 EDT
|
|||
|
|
|||
|
1976-1986 last Sun in Apr, 02:00 -0400 EDT
|
|||
|
|
|||
|
1987-* first Sun in Apr, 02:00 -0400 EDT
|
|||
|
|
|||
|
Note: The specification of a global time zone registry is not
|
|||
|
addressed by this document and is left for future study.
|
|||
|
However, implementers may find the Olson time zone database [TZ]
|
|||
|
a useful reference. It is an informal, public-domain collection
|
|||
|
of time zone information, which is currently being maintained by
|
|||
|
volunteer Internet participants, and is used in several
|
|||
|
operating systems. This database contains current and historical
|
|||
|
time zone information for a wide variety of locations around the
|
|||
|
globe; it provides a time zone identifier for every unique time
|
|||
|
zone rule set in actual use since 1970, with historical data
|
|||
|
going back to the introduction of standard time.
|
|||
|
|
|||
|
Interoperability between two calendaring and scheduling applications,
|
|||
|
especially for recurring events, to-dos or journal entries, is
|
|||
|
dependent on the ability to capture and convey date and time
|
|||
|
information in an unambiguous format. The specification of current
|
|||
|
time zone information is integral to this behavior.
|
|||
|
|
|||
|
If present, the "VTIMEZONE" calendar component defines the set of
|
|||
|
Standard Time and Daylight Saving Time observances (or rules) for a
|
|||
|
particular time zone for a given interval of time. The "VTIMEZONE"
|
|||
|
calendar component cannot be nested within other calendar components.
|
|||
|
Multiple "VTIMEZONE" calendar components can exist in an iCalendar
|
|||
|
object. In this situation, each "VTIMEZONE" MUST represent a unique
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 62]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
time zone definition. This is necessary for some classes of events,
|
|||
|
such as airline flights, that start in one time zone and end in
|
|||
|
another.
|
|||
|
|
|||
|
The "VTIMEZONE" calendar component MUST be present if the iCalendar
|
|||
|
object contains an RRULE that generates dates on both sides of a time
|
|||
|
zone shift (e.g. both in Standard Time and Daylight Saving Time)
|
|||
|
unless the iCalendar object intends to convey a floating time (See
|
|||
|
the section "4.1.10.11 Time" for proper interpretation of floating
|
|||
|
time). It can be present if the iCalendar object does not contain
|
|||
|
such a RRULE. In addition, if a RRULE is present, there MUST be valid
|
|||
|
time zone information for all recurrence instances.
|
|||
|
|
|||
|
The "VTIMEZONE" calendar component MUST include the "TZID" property
|
|||
|
and at least one definition of a standard or daylight component. The
|
|||
|
standard or daylight component MUST include the "DTSTART",
|
|||
|
"TZOFFSETFROM" and "TZOFFSETTO" properties.
|
|||
|
|
|||
|
An individual "VTIMEZONE" calendar component MUST be specified for
|
|||
|
each unique "TZID" parameter value specified in the iCalendar object.
|
|||
|
|
|||
|
Each "VTIMEZONE" calendar component consists of a collection of one
|
|||
|
or more sub-components that describe the rule for a particular
|
|||
|
observance (either a Standard Time or a Daylight Saving Time
|
|||
|
observance). The "STANDARD" sub-component consists of a collection of
|
|||
|
properties that describe Standard Time. The "DAYLIGHT" sub-component
|
|||
|
consists of a collection of properties that describe Daylight Saving
|
|||
|
Time. In general this collection of properties consists of:
|
|||
|
|
|||
|
- the first onset date-time for the observance
|
|||
|
|
|||
|
- the last onset date-time for the observance, if a last onset
|
|||
|
is known.
|
|||
|
|
|||
|
- the offset to be applied for the observance
|
|||
|
|
|||
|
- a rule that describes the day and time when the observance
|
|||
|
takes effect
|
|||
|
|
|||
|
- an optional name for the observance
|
|||
|
|
|||
|
For a given time zone, there may be multiple unique definitions of
|
|||
|
the observances over a period of time. Each observance is described
|
|||
|
using either a "STANDARD" or "DAYLIGHT" sub-component. The collection
|
|||
|
of these sub-components is used to describe the time zone for a given
|
|||
|
period of time. The offset to apply at any given time is found by
|
|||
|
locating the observance that has the last onset date and time before
|
|||
|
the time in question, and using the offset value from that
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 63]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
observance.
|
|||
|
|
|||
|
The top-level properties in a "VTIMEZONE" calendar component are:
|
|||
|
|
|||
|
The mandatory "TZID" property is a text value that uniquely
|
|||
|
identifies the VTIMZONE calendar component within the scope of an
|
|||
|
iCalendar object.
|
|||
|
|
|||
|
The optional "LAST-MODIFIED" property is a UTC value that specifies
|
|||
|
the date and time that this time zone definition was last updated.
|
|||
|
|
|||
|
The optional "TZURL" property is url value that points to a published
|
|||
|
VTIMEZONE definition. TZURL SHOULD refer to a resource that is
|
|||
|
accessible by anyone who might need to interpret the object. This
|
|||
|
SHOULD NOT normally be a file: URL or other URL that is not widely-
|
|||
|
accessible.
|
|||
|
|
|||
|
The collection of properties that are used to define the STANDARD and
|
|||
|
DAYLIGHT sub-components include:
|
|||
|
|
|||
|
The mandatory "DTSTART" property gives the effective onset date and
|
|||
|
local time for the time zone sub-component definition. "DTSTART" in
|
|||
|
this usage MUST be specified as a local DATE-TIME value.
|
|||
|
|
|||
|
The mandatory "TZOFFSETFROM" property gives the UTC offset which is
|
|||
|
in use when the onset of this time zone observance begins.
|
|||
|
"TZOFFSETFROM" is combined with "DTSTART" to define the effective
|
|||
|
onset for the time zone sub-component definition. For example, the
|
|||
|
following represents the time at which the observance of Standard
|
|||
|
Time took effect in Fall 1967 for New York City:
|
|||
|
|
|||
|
DTSTART:19671029T020000
|
|||
|
|
|||
|
TZOFFSETFROM:-0400
|
|||
|
|
|||
|
The mandatory "TZOFFSETTO " property gives the UTC offset for the
|
|||
|
time zone sub-component (Standard Time or Daylight Saving Time) when
|
|||
|
this observance is in use.
|
|||
|
|
|||
|
The optional "TZNAME" property is the customary name for the time
|
|||
|
zone. It may be specified multiple times, to allow for specifying
|
|||
|
multiple language variants of the time zone names. This could be used
|
|||
|
for displaying dates.
|
|||
|
|
|||
|
If specified, the onset for the observance defined by the time zone
|
|||
|
sub-component is defined by either the "RRULE" or "RDATE" property.
|
|||
|
If neither is specified, only one sub-component can be specified in
|
|||
|
the "VTIMEZONE" calendar component and it is assumed that the single
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 64]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
observance specified is always in effect.
|
|||
|
|
|||
|
The "RRULE" property defines the recurrence rule for the onset of the
|
|||
|
observance defined by this time zone sub-component. Some specific
|
|||
|
requirements for the usage of RRULE for this purpose include:
|
|||
|
|
|||
|
- If observance is known to have an effective end date, the
|
|||
|
"UNTIL" recurrence rule parameter MUST be used to specify the
|
|||
|
last valid onset of this observance (i.e., the UNTIL date-time
|
|||
|
will be equal to the last instance generated by the recurrence
|
|||
|
pattern). It MUST be specified in UTC time.
|
|||
|
|
|||
|
- The "DTSTART" and the "TZOFFSETTO" properties MUST be used
|
|||
|
when generating the onset date-time values (instances) from the
|
|||
|
RRULE.
|
|||
|
|
|||
|
Alternatively, the "RDATE" property can be used to define the onset
|
|||
|
of the observance by giving the individual onset date and times.
|
|||
|
"RDATE" in this usage MUST be specified as a local DATE-TIME value in
|
|||
|
UTC time.
|
|||
|
|
|||
|
The optional "COMMENT" property is also allowed for descriptive
|
|||
|
explanatory text.
|
|||
|
|
|||
|
Example: The following are examples of the "VTIMEZONE" calendar
|
|||
|
component:
|
|||
|
|
|||
|
This is an example showing time zone information for the Eastern
|
|||
|
United States using "RDATE" property. Note that this is only suitable
|
|||
|
for a recurring event that starts on or later than April 6, 1997 at
|
|||
|
03:00:00 EDT (i.e., the earliest effective transition date and time)
|
|||
|
and ends no later than April 7, 1998 02:00:00 EST (i.e., latest valid
|
|||
|
date and time for EST in this scenario). For example, this can be
|
|||
|
used for a recurring event that occurs every Friday, 8am-9:00 AM,
|
|||
|
starting June 1, 1997, ending December 31, 1997.
|
|||
|
|
|||
|
BEGIN:VTIMEZONE
|
|||
|
TZID:US-Eastern
|
|||
|
LAST-MODIFIED:19870101T000000Z
|
|||
|
BEGIN:STANDARD
|
|||
|
DTSTART:19971026T020000
|
|||
|
RDATE:19971026T020000
|
|||
|
TZOFFSETFROM:-0400
|
|||
|
TZOFFSETTO:-0500
|
|||
|
TZNAME:EST
|
|||
|
END:STANDARD
|
|||
|
BEGIN:DAYLIGHT
|
|||
|
DTSTART:19971026T020000
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 65]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
RDATE:19970406T020000
|
|||
|
TZOFFSETFROM:-0500
|
|||
|
TZOFFSETTO:-0400
|
|||
|
TZNAME:EDT
|
|||
|
END:DAYLIGHT
|
|||
|
END:VTIMEZONE
|
|||
|
|
|||
|
This is a simple example showing the current time zone rules for the
|
|||
|
Eastern United States using a RRULE recurrence pattern. Note that
|
|||
|
there is no effective end date to either of the Standard Time or
|
|||
|
Daylight Time rules. This information would be valid for a recurring
|
|||
|
event starting today and continuing indefinitely.
|
|||
|
|
|||
|
BEGIN:VTIMEZONE
|
|||
|
TZID:US-Eastern
|
|||
|
LAST-MODIFIED:19870101T000000Z
|
|||
|
TZURL:http://zones.stds_r_us.net/tz/US-Eastern
|
|||
|
BEGIN:STANDARD
|
|||
|
DTSTART:19671029T020000
|
|||
|
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
|
|||
|
TZOFFSETFROM:-0400
|
|||
|
TZOFFSETTO:-0500
|
|||
|
TZNAME:EST
|
|||
|
END:STANDARD
|
|||
|
BEGIN:DAYLIGHT
|
|||
|
DTSTART:19870405T020000
|
|||
|
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
|
|||
|
TZOFFSETFROM:-0500
|
|||
|
TZOFFSETTO:-0400
|
|||
|
TZNAME:EDT
|
|||
|
END:DAYLIGHT
|
|||
|
END:VTIMEZONE
|
|||
|
|
|||
|
This is an example showing a fictitious set of rules for the Eastern
|
|||
|
United States, where the Daylight Time rule has an effective end date
|
|||
|
(i.e., after that date, Daylight Time is no longer observed).
|
|||
|
|
|||
|
BEGIN:VTIMEZONE
|
|||
|
TZID:US--Fictitious-Eastern
|
|||
|
LAST-MODIFIED:19870101T000000Z
|
|||
|
BEGIN:STANDARD
|
|||
|
DTSTART:19671029T020000
|
|||
|
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
|
|||
|
TZOFFSETFROM:-0400
|
|||
|
TZOFFSETTO:-0500
|
|||
|
TZNAME:EST
|
|||
|
END:STANDARD
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 66]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
BEGIN:DAYLIGHT
|
|||
|
DTSTART:19870405T020000
|
|||
|
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T070000Z
|
|||
|
TZOFFSETFROM:-0500
|
|||
|
TZOFFSETTO:-0400
|
|||
|
TZNAME:EDT
|
|||
|
END:DAYLIGHT
|
|||
|
END:VTIMEZONE
|
|||
|
|
|||
|
This is an example showing a fictitious set of rules for the Eastern
|
|||
|
United States, where the first Daylight Time rule has an effective
|
|||
|
end date. There is a second Daylight Time rule that picks up where
|
|||
|
the other left off.
|
|||
|
|
|||
|
BEGIN:VTIMEZONE
|
|||
|
TZID:US--Fictitious-Eastern
|
|||
|
LAST-MODIFIED:19870101T000000Z
|
|||
|
BEGIN:STANDARD
|
|||
|
DTSTART:19671029T020000
|
|||
|
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
|
|||
|
TZOFFSETFROM:-0400
|
|||
|
TZOFFSETTO:-0500
|
|||
|
TZNAME:EST
|
|||
|
END:STANDARD
|
|||
|
BEGIN:DAYLIGHT
|
|||
|
DTSTART:19870405T020000
|
|||
|
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T070000Z
|
|||
|
TZOFFSETFROM:-0500
|
|||
|
TZOFFSETTO:-0400
|
|||
|
TZNAME:EDT
|
|||
|
END:DAYLIGHT
|
|||
|
BEGIN:DAYLIGHT
|
|||
|
DTSTART:19990424T020000
|
|||
|
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=4
|
|||
|
TZOFFSETFROM:-0500
|
|||
|
TZOFFSETTO:-0400
|
|||
|
TZNAME:EDT
|
|||
|
END:DAYLIGHT
|
|||
|
END:VTIMEZONE
|
|||
|
|
|||
|
4.6.6 Alarm Component
|
|||
|
|
|||
|
Component Name: VALARM
|
|||
|
|
|||
|
Purpose: Provide a grouping of component properties that define an
|
|||
|
alarm.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 67]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
Formal Definition: A "VALARM" calendar component is defined by the
|
|||
|
following notation:
|
|||
|
|
|||
|
alarmc = "BEGIN" ":" "VALARM" CRLF
|
|||
|
(audioprop / dispprop / emailprop / procprop)
|
|||
|
"END" ":" "VALARM" CRLF
|
|||
|
|
|||
|
audioprop = 2*(
|
|||
|
|
|||
|
; 'action' and 'trigger' are both REQUIRED,
|
|||
|
; but MUST NOT occur more than once
|
|||
|
|
|||
|
action / trigger /
|
|||
|
|
|||
|
; 'duration' and 'repeat' are both optional,
|
|||
|
; and MUST NOT occur more than once each,
|
|||
|
; but if one occurs, so MUST the other
|
|||
|
|
|||
|
duration / repeat /
|
|||
|
|
|||
|
; the following is optional,
|
|||
|
; but MUST NOT occur more than once
|
|||
|
|
|||
|
attach /
|
|||
|
|
|||
|
; the following is optional,
|
|||
|
; and MAY occur more than once
|
|||
|
|
|||
|
x-prop
|
|||
|
|
|||
|
)
|
|||
|
|
|||
|
|
|||
|
|
|||
|
dispprop = 3*(
|
|||
|
|
|||
|
; the following are all REQUIRED,
|
|||
|
; but MUST NOT occur more than once
|
|||
|
|
|||
|
action / description / trigger /
|
|||
|
|
|||
|
; 'duration' and 'repeat' are both optional,
|
|||
|
; and MUST NOT occur more than once each,
|
|||
|
; but if one occurs, so MUST the other
|
|||
|
|
|||
|
duration / repeat /
|
|||
|
|
|||
|
; the following is optional,
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 68]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
; and MAY occur more than once
|
|||
|
|
|||
|
*x-prop
|
|||
|
|
|||
|
)
|
|||
|
|
|||
|
|
|||
|
|
|||
|
emailprop = 5*(
|
|||
|
|
|||
|
; the following are all REQUIRED,
|
|||
|
; but MUST NOT occur more than once
|
|||
|
|
|||
|
action / description / trigger / summary
|
|||
|
|
|||
|
; the following is REQUIRED,
|
|||
|
; and MAY occur more than once
|
|||
|
|
|||
|
attendee /
|
|||
|
|
|||
|
; 'duration' and 'repeat' are both optional,
|
|||
|
; and MUST NOT occur more than once each,
|
|||
|
; but if one occurs, so MUST the other
|
|||
|
|
|||
|
duration / repeat /
|
|||
|
|
|||
|
; the following are optional,
|
|||
|
; and MAY occur more than once
|
|||
|
|
|||
|
attach / x-prop
|
|||
|
|
|||
|
)
|
|||
|
|
|||
|
|
|||
|
|
|||
|
procprop = 3*(
|
|||
|
|
|||
|
; the following are all REQUIRED,
|
|||
|
; but MUST NOT occur more than once
|
|||
|
|
|||
|
action / attach / trigger /
|
|||
|
|
|||
|
; 'duration' and 'repeat' are both optional,
|
|||
|
; and MUST NOT occur more than once each,
|
|||
|
; but if one occurs, so MUST the other
|
|||
|
|
|||
|
duration / repeat /
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 69]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
; 'description' is optional,
|
|||
|
; and MUST NOT occur more than once
|
|||
|
|
|||
|
description /
|
|||
|
|
|||
|
; the following is optional,
|
|||
|
; and MAY occur more than once
|
|||
|
|
|||
|
x-prop
|
|||
|
|
|||
|
)
|
|||
|
|
|||
|
Description: A "VALARM" calendar component is a grouping of component
|
|||
|
properties that is a reminder or alarm for an event or a to-do. For
|
|||
|
example, it may be used to define a reminder for a pending event or
|
|||
|
an overdue to-do.
|
|||
|
|
|||
|
The "VALARM" calendar component MUST include the "ACTION" and
|
|||
|
"TRIGGER" properties. The "ACTION" property further constrains the
|
|||
|
"VALARM" calendar component in the following ways:
|
|||
|
|
|||
|
When the action is "AUDIO", the alarm can also include one and only
|
|||
|
one "ATTACH" property, which MUST point to a sound resource, which is
|
|||
|
rendered when the alarm is triggered.
|
|||
|
|
|||
|
When the action is "DISPLAY", the alarm MUST also include a
|
|||
|
"DESCRIPTION" property, which contains the text to be displayed when
|
|||
|
the alarm is triggered.
|
|||
|
|
|||
|
When the action is "EMAIL", the alarm MUST include a "DESCRIPTION"
|
|||
|
property, which contains the text to be used as the message body, a
|
|||
|
"SUMMARY" property, which contains the text to be used as the message
|
|||
|
subject, and one or more "ATTENDEE" properties, which contain the
|
|||
|
email address of attendees to receive the message. It can also
|
|||
|
include one or more "ATTACH" properties, which are intended to be
|
|||
|
sent as message attachments. When the alarm is triggered, the email
|
|||
|
message is sent.
|
|||
|
|
|||
|
When the action is "PROCEDURE", the alarm MUST include one and only
|
|||
|
one "ATTACH" property, which MUST point to a procedure resource,
|
|||
|
which is invoked when the alarm is triggered.
|
|||
|
|
|||
|
The "VALARM" calendar component MUST only appear within either a
|
|||
|
"VEVENT" or "VTODO" calendar component. "VALARM" calendar components
|
|||
|
cannot be nested. Multiple mutually independent "VALARM" calendar
|
|||
|
components can be specified for a single "VEVENT" or "VTODO" calendar
|
|||
|
component.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 70]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
The "TRIGGER" property specifies when the alarm will be triggered.
|
|||
|
The "TRIGGER" property specifies a duration prior to the start of an
|
|||
|
event or a to-do. The "TRIGGER" edge may be explicitly set to be
|
|||
|
relative to the "START" or "END" of the event or to-do with the
|
|||
|
"RELATED" parameter of the "TRIGGER" property. The "TRIGGER" property
|
|||
|
value type can alternatively be set to an absolute calendar date and
|
|||
|
time of day value.
|
|||
|
|
|||
|
In an alarm set to trigger on the "START" of an event or to-do, the
|
|||
|
"DTSTART" property MUST be present in the associated event or to-do.
|
|||
|
In an alarm in a "VEVENT" calendar component set to trigger on the
|
|||
|
"END" of the event, either the "DTEND" property MUST be present, or
|
|||
|
the "DTSTART" and "DURATION" properties MUST both be present. In an
|
|||
|
alarm in a "VTODO" calendar component set to trigger on the "END" of
|
|||
|
the to-do, either the "DUE" property MUST be present, or the
|
|||
|
"DTSTART" and "DURATION" properties MUST both be present.
|
|||
|
|
|||
|
The alarm can be defined such that it triggers repeatedly. A
|
|||
|
definition of an alarm with a repeating trigger MUST include both the
|
|||
|
"DURATION" and "REPEAT" properties. The "DURATION" property specifies
|
|||
|
the delay period, after which the alarm will repeat. The "REPEAT"
|
|||
|
property specifies the number of additional repetitions that the
|
|||
|
alarm will triggered. This repitition count is in addition to the
|
|||
|
initial triggering of the alarm. Both of these properties MUST be
|
|||
|
present in order to specify a repeating alarm. If one of these two
|
|||
|
properties is absent, then the alarm will not repeat beyond the
|
|||
|
initial trigger.
|
|||
|
|
|||
|
The "ACTION" property is used within the "VALARM" calendar component
|
|||
|
to specify the type of action invoked when the alarm is triggered.
|
|||
|
The "VALARM" properties provide enough information for a specific
|
|||
|
action to be invoked. It is typically the responsibility of a
|
|||
|
"Calendar User Agent" (CUA) to deliver the alarm in the specified
|
|||
|
fashion. An "ACTION" property value of AUDIO specifies an alarm that
|
|||
|
causes a sound to be played to alert the user; DISPLAY specifies an
|
|||
|
alarm that causes a text message to be displayed to the user; EMAIL
|
|||
|
specifies an alarm that causes an electronic email message to be
|
|||
|
delivered to one or more email addresses; and PROCEDURE specifies an
|
|||
|
alarm that causes a procedure to be executed. The "ACTION" property
|
|||
|
MUST specify one and only one of these values.
|
|||
|
|
|||
|
In an AUDIO alarm, if the optional "ATTACH" property is included, it
|
|||
|
MUST specify an audio sound resource. The intention is that the sound
|
|||
|
will be played as the alarm effect. If an "ATTACH" property is
|
|||
|
specified that does not refer to a sound resource, or if the
|
|||
|
specified sound resource cannot be rendered (because its format is
|
|||
|
unsupported, or because it cannot be retrieved), then the CUA or
|
|||
|
other entity responsible for playing the sound may choose a fallback
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 71]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
action, such as playing a built-in default sound, or playing no sound
|
|||
|
at all.
|
|||
|
|
|||
|
In a DISPLAY alarm, the intended alarm effect is for the text value
|
|||
|
of the "DESCRIPTION" property to be displayed to the user.
|
|||
|
|
|||
|
In an EMAIL alarm, the intended alarm effect is for an email message
|
|||
|
to be composed and delivered to all the addresses specified by the
|
|||
|
"ATTENDEE" properties in the "VALARM" calendar component. The
|
|||
|
"DESCRIPTION" property of the "VALARM" calendar component MUST be
|
|||
|
used as the body text of the message, and the "SUMMARY" property MUST
|
|||
|
be used as the subject text. Any "ATTACH" properties in the "VALARM"
|
|||
|
calendar component SHOULD be sent as attachments to the message.
|
|||
|
|
|||
|
In a PROCEDURE alarm, the "ATTACH" property in the "VALARM" calendar
|
|||
|
component MUST specify a procedure or program that is intended to be
|
|||
|
invoked as the alarm effect. If the procedure or program is in a
|
|||
|
format that cannot be rendered, then no procedure alarm will be
|
|||
|
invoked. If the "DESCRIPTION" property is present, its value
|
|||
|
specifies the argument string to be passed to the procedure or
|
|||
|
program. "Calendar User Agents" that receive an iCalendar object with
|
|||
|
this category of alarm, can disable or allow the "Calendar User" to
|
|||
|
disable, or otherwise ignore this type of alarm. While a very useful
|
|||
|
alarm capability, the PROCEDURE type of alarm SHOULD be treated by
|
|||
|
the "Calendar User Agent" as a potential security risk.
|
|||
|
|
|||
|
Example: The following example is for a "VALARM" calendar component
|
|||
|
that specifies an audio alarm that will sound at a precise time and
|
|||
|
repeat 4 more times at 15 minute intervals:
|
|||
|
|
|||
|
BEGIN:VALARM
|
|||
|
TRIGGER;VALUE=DATE-TIME:19970317T133000Z
|
|||
|
REPEAT:4
|
|||
|
DURATION:PT15M
|
|||
|
ACTION:AUDIO
|
|||
|
ATTACH;FMTTYPE=audio/basic:ftp://host.com/pub/sounds/bell-01.aud
|
|||
|
END:VALARM
|
|||
|
|
|||
|
The following example is for a "VALARM" calendar component that
|
|||
|
specifies a display alarm that will trigger 30 minutes before the
|
|||
|
scheduled start of the event or the due date/time of the to-do it is
|
|||
|
associated with and will repeat 2 more times at 15 minute intervals:
|
|||
|
|
|||
|
BEGIN:VALARM
|
|||
|
TRIGGER:-PT30M
|
|||
|
REPEAT:2
|
|||
|
DURATION:PT15M
|
|||
|
ACTION:DISPLAY
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 72]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
DESCRIPTION:Breakfast meeting with executive\n
|
|||
|
team at 8:30 AM EST.
|
|||
|
END:VALARM
|
|||
|
|
|||
|
The following example is for a "VALARM" calendar component that
|
|||
|
specifies an email alarm that will trigger 2 days before the
|
|||
|
scheduled due date/time of a to-do it is associated with. It does not
|
|||
|
repeat. The email has a subject, body and attachment link.
|
|||
|
|
|||
|
BEGIN:VALARM
|
|||
|
TRIGGER:-P2D
|
|||
|
ACTION:EMAIL
|
|||
|
ATTENDEE:MAILTO:john_doe@host.com
|
|||
|
SUMMARY:*** REMINDER: SEND AGENDA FOR WEEKLY STAFF MEETING ***
|
|||
|
DESCRIPTION:A draft agenda needs to be sent out to the attendees
|
|||
|
to the weekly managers meeting (MGR-LIST). Attached is a
|
|||
|
pointer the document template for the agenda file.
|
|||
|
ATTACH;FMTTYPE=application/binary:http://host.com/templates/agen
|
|||
|
da.doc
|
|||
|
END:VALARM
|
|||
|
|
|||
|
The following example is for a "VALARM" calendar component that
|
|||
|
specifies a procedural alarm that will trigger at a precise date/time
|
|||
|
and will repeat 23 more times at one hour intervals. The alarm will
|
|||
|
invoke a procedure file.
|
|||
|
|
|||
|
BEGIN:VALARM
|
|||
|
TRIGGER;VALUE=DATE-TIME:19980101T050000Z
|
|||
|
REPEAT:23
|
|||
|
DURATION:PT1H
|
|||
|
ACTION:PROCEDURE
|
|||
|
ATTACH;FMTTYPE=application/binary:ftp://host.com/novo-
|
|||
|
procs/felizano.exe
|
|||
|
END:VALARM
|
|||
|
|
|||
|
4.7 Calendar Properties
|
|||
|
|
|||
|
The Calendar Properties are attributes that apply to the iCalendar
|
|||
|
object, as a whole. These properties do not appear within a calendar
|
|||
|
component. They SHOULD be specified after the "BEGIN:VCALENDAR"
|
|||
|
property and prior to any calendar component.
|
|||
|
|
|||
|
4.7.1 Calendar Scale
|
|||
|
|
|||
|
Property Name: CALSCALE
|
|||
|
|
|||
|
Purpose: This property defines the calendar scale used for the
|
|||
|
calendar information specified in the iCalendar object.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 73]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
Value Type: TEXT
|
|||
|
|
|||
|
Property Parameters: Non-standard property parameters can be
|
|||
|
specified on this property.
|
|||
|
|
|||
|
Conformance: Property can be specified in an iCalendar object. The
|
|||
|
default value is "GREGORIAN".
|
|||
|
|
|||
|
Description: This memo is based on the Gregorian calendar scale. The
|
|||
|
Gregorian calendar scale is assumed if this property is not specified
|
|||
|
in the iCalendar object. It is expected that other calendar scales
|
|||
|
will be defined in other specifications or by future versions of this
|
|||
|
memo.
|
|||
|
|
|||
|
Format Definition: The property is defined by the following notation:
|
|||
|
|
|||
|
calscale = "CALSCALE" calparam ":" calvalue CRLF
|
|||
|
|
|||
|
calparam = *(";" xparam)
|
|||
|
|
|||
|
calvalue = "GREGORIAN" / iana-token
|
|||
|
|
|||
|
Example: The following is an example of this property:
|
|||
|
|
|||
|
CALSCALE:GREGORIAN
|
|||
|
|
|||
|
4.7.2 Method
|
|||
|
|
|||
|
Property Name: METHOD
|
|||
|
|
|||
|
Purpose: This property defines the iCalendar object method associated
|
|||
|
with the calendar object.
|
|||
|
|
|||
|
Value Type: TEXT
|
|||
|
|
|||
|
Property Parameters: Non-standard property parameters can be
|
|||
|
specified on this property.
|
|||
|
|
|||
|
Conformance: The property can be specified in an iCalendar object.
|
|||
|
|
|||
|
Description: When used in a MIME message entity, the value of this
|
|||
|
property MUST be the same as the Content-Type "method" parameter
|
|||
|
value. This property can only appear once within the iCalendar
|
|||
|
object. If either the "METHOD" property or the Content-Type "method"
|
|||
|
parameter is specified, then the other MUST also be specified.
|
|||
|
|
|||
|
No methods are defined by this specification. This is the subject of
|
|||
|
other specifications, such as the iCalendar Transport-independent
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 74]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
Interoperability Protocol (iTIP) defined by [ITIP].
|
|||
|
|
|||
|
If this property is not present in the iCalendar object, then a
|
|||
|
scheduling transaction MUST NOT be assumed. In such cases, the
|
|||
|
iCalendar object is merely being used to transport a snapshot of some
|
|||
|
calendar information; without the intention of conveying a scheduling
|
|||
|
semantic.
|
|||
|
|
|||
|
Format Definition: The property is defined by the following notation:
|
|||
|
|
|||
|
method = "METHOD" metparam ":" metvalue CRLF
|
|||
|
|
|||
|
metparam = *(";" xparam)
|
|||
|
|
|||
|
metvalue = iana-token
|
|||
|
|
|||
|
Example: The following is a hypothetical example of this property to
|
|||
|
convey that the iCalendar object is a request for a meeting:
|
|||
|
|
|||
|
METHOD:REQUEST
|
|||
|
|
|||
|
4.7.3 Product Identifier
|
|||
|
|
|||
|
Property Name: PRODID
|
|||
|
|
|||
|
Purpose: This property specifies the identifier for the product that
|
|||
|
created the iCalendar object.
|
|||
|
|
|||
|
Value Type: TEXT
|
|||
|
|
|||
|
Property Parameters: Non-standard property parameters can be
|
|||
|
specified on this property.
|
|||
|
|
|||
|
Conformance: The property MUST be specified once in an iCalendar
|
|||
|
object.
|
|||
|
|
|||
|
Description: The vendor of the implementation SHOULD assure that this
|
|||
|
is a globally unique identifier; using some technique such as an FPI
|
|||
|
value, as defined in [ISO 9070].
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
Format Definition: The property is defined by the following notation:
|
|||
|
|
|||
|
prodid = "PRODID" pidparam ":" pidvalue CRLF
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 75]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
pidparam = *(";" xparam)
|
|||
|
|
|||
|
pidvalue = text
|
|||
|
;Any text that describes the product and version
|
|||
|
;and that is generally assured of being unique.
|
|||
|
|
|||
|
Example: The following is an example of this property. It does not
|
|||
|
imply that English is the default language.
|
|||
|
|
|||
|
PRODID:-//ABC Corporation//NONSGML My Product//EN
|
|||
|
|
|||
|
4.7.4 Version
|
|||
|
|
|||
|
Property Name: VERSION
|
|||
|
|
|||
|
Purpose: This property specifies the identifier corresponding to the
|
|||
|
highest version number or the minimum and maximum range of the
|
|||
|
iCalendar specification that is required in order to interpret the
|
|||
|
iCalendar object.
|
|||
|
|
|||
|
Value Type: TEXT
|
|||
|
|
|||
|
Property Parameters: Non-standard property parameters can be
|
|||
|
specified on this property.
|
|||
|
|
|||
|
Conformance: This property MUST be specified by an iCalendar object,
|
|||
|
but MUST only be specified once.
|
|||
|
|
|||
|
Description: A value of "2.0" corresponds to this memo.
|
|||
|
|
|||
|
Format Definition: The property is defined by the following notation:
|
|||
|
|
|||
|
version = "VERSION" verparam ":" vervalue CRLF
|
|||
|
|
|||
|
verparam = *(";" xparam)
|
|||
|
|
|||
|
vervalue = "2.0" ;This memo
|
|||
|
/ maxver
|
|||
|
/ (minver ";" maxver)
|
|||
|
|
|||
|
minver = <A IANA registered iCalendar version identifier>
|
|||
|
;Minimum iCalendar version needed to parse the iCalendar object
|
|||
|
|
|||
|
maxver = <A IANA registered iCalendar version identifier>
|
|||
|
;Maximum iCalendar version needed to parse the iCalendar object
|
|||
|
|
|||
|
Example: The following is an example of this property:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 76]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
VERSION:2.0
|
|||
|
|
|||
|
4.8 Component Properties
|
|||
|
|
|||
|
The following properties can appear within calendar components, as
|
|||
|
specified by each component property definition.
|
|||
|
|
|||
|
4.8.1 Descriptive Component Properties
|
|||
|
|
|||
|
The following properties specify descriptive information about
|
|||
|
calendar components.
|
|||
|
|
|||
|
4.8.1.1 Attachment
|
|||
|
|
|||
|
Property Name: ATTACH
|
|||
|
|
|||
|
Purpose: The property provides the capability to associate a document
|
|||
|
object with a calendar component.
|
|||
|
|
|||
|
Value Type: The default value type for this property is URI. The
|
|||
|
value type can also be set to BINARY to indicate inline binary
|
|||
|
encoded content information.
|
|||
|
|
|||
|
Property Parameters: Non-standard, inline encoding, format type and
|
|||
|
value data type property parameters can be specified on this
|
|||
|
property.
|
|||
|
|
|||
|
Conformance: The property can be specified in a "VEVENT", "VTODO",
|
|||
|
"VJOURNAL" or "VALARM" calendar components.
|
|||
|
|
|||
|
Description: The property can be specified within "VEVENT", "VTODO",
|
|||
|
"VJOURNAL", or "VALARM" calendar components. This property can be
|
|||
|
specified multiple times within an iCalendar object.
|
|||
|
|
|||
|
Format Definition: The property is defined by the following notation:
|
|||
|
|
|||
|
attach = "ATTACH" attparam ":" uri CRLF
|
|||
|
|
|||
|
attach =/ "ATTACH" attparam ";" "ENCODING" "=" "BASE64"
|
|||
|
";" "VALUE" "=" "BINARY" ":" binary
|
|||
|
|
|||
|
attparam = *(
|
|||
|
|
|||
|
; the following is optional,
|
|||
|
; but MUST NOT occur more than once
|
|||
|
|
|||
|
(";" fmttypeparam) /
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 77]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
; the following is optional,
|
|||
|
; and MAY occur more than once
|
|||
|
|
|||
|
(";" xparam)
|
|||
|
|
|||
|
)
|
|||
|
|
|||
|
Example: The following are examples of this property:
|
|||
|
|
|||
|
ATTACH:CID:jsmith.part3.960817T083000.xyzMail@host1.com
|
|||
|
|
|||
|
ATTACH;FMTTYPE=application/postscript:ftp://xyzCorp.com/pub/
|
|||
|
reports/r-960812.ps
|
|||
|
|
|||
|
4.8.1.2 Categories
|
|||
|
|
|||
|
Property Name: CATEGORIES
|
|||
|
|
|||
|
Purpose: This property defines the categories for a calendar
|
|||
|
component.
|
|||
|
|
|||
|
Value Type: TEXT
|
|||
|
|
|||
|
Property Parameters: Non-standard and language property parameters
|
|||
|
can be specified on this property.
|
|||
|
|
|||
|
Conformance: The property can be specified within "VEVENT", "VTODO"
|
|||
|
or "VJOURNAL" calendar components.
|
|||
|
|
|||
|
Description: This property is used to specify categories or subtypes
|
|||
|
of the calendar component. The categories are useful in searching for
|
|||
|
a calendar component of a particular type and category. Within the
|
|||
|
"VEVENT", "VTODO" or "VJOURNAL" calendar components, more than one
|
|||
|
category can be specified as a list of categories separated by the
|
|||
|
COMMA character (US-ASCII decimal 44).
|
|||
|
|
|||
|
Format Definition: The property is defined by the following notation:
|
|||
|
|
|||
|
categories = "CATEGORIES" catparam ":" text *("," text)
|
|||
|
CRLF
|
|||
|
|
|||
|
catparam = *(
|
|||
|
|
|||
|
; the following is optional,
|
|||
|
; but MUST NOT occur more than once
|
|||
|
|
|||
|
(";" languageparam ) /
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 78]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
; the following is optional,
|
|||
|
; and MAY occur more than once
|
|||
|
|
|||
|
(";" xparam)
|
|||
|
|
|||
|
)
|
|||
|
|
|||
|
Example: The following are examples of this property:
|
|||
|
|
|||
|
CATEGORIES:APPOINTMENT,EDUCATION
|
|||
|
|
|||
|
CATEGORIES:MEETING
|
|||
|
|
|||
|
4.8.1.3 Classification
|
|||
|
|
|||
|
Property Name: CLASS
|
|||
|
|
|||
|
Purpose: This property defines the access classification for a
|
|||
|
calendar component.
|
|||
|
|
|||
|
Value Type: TEXT
|
|||
|
|
|||
|
Property Parameters: Non-standard property parameters can be
|
|||
|
specified on this property.
|
|||
|
|
|||
|
Conformance: The property can be specified once in a "VEVENT",
|
|||
|
"VTODO" or "VJOURNAL" calendar components.
|
|||
|
|
|||
|
Description: An access classification is only one component of the
|
|||
|
general security system within a calendar application. It provides a
|
|||
|
method of capturing the scope of the access the calendar owner
|
|||
|
intends for information within an individual calendar entry. The
|
|||
|
access classification of an individual iCalendar component is useful
|
|||
|
when measured along with the other security components of a calendar
|
|||
|
system (e.g., calendar user authentication, authorization, access
|
|||
|
rights, access role, etc.). Hence, the semantics of the individual
|
|||
|
access classifications cannot be completely defined by this memo
|
|||
|
alone. Additionally, due to the "blind" nature of most exchange
|
|||
|
processes using this memo, these access classifications cannot serve
|
|||
|
as an enforcement statement for a system receiving an iCalendar
|
|||
|
object. Rather, they provide a method for capturing the intention of
|
|||
|
the calendar owner for the access to the calendar component.
|
|||
|
|
|||
|
Format Definition: The property is defined by the following notation:
|
|||
|
|
|||
|
class = "CLASS" classparam ":" classvalue CRLF
|
|||
|
|
|||
|
classparam = *(";" xparam)
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 79]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
classvalue = "PUBLIC" / "PRIVATE" / "CONFIDENTIAL" / iana-token
|
|||
|
/ x-name
|
|||
|
;Default is PUBLIC
|
|||
|
|
|||
|
Example: The following is an example of this property:
|
|||
|
|
|||
|
CLASS:PUBLIC
|
|||
|
|
|||
|
4.8.1.4 Comment
|
|||
|
|
|||
|
Property Name: COMMENT
|
|||
|
|
|||
|
Purpose: This property specifies non-processing information intended
|
|||
|
to provide a comment to the calendar user.
|
|||
|
|
|||
|
Value Type: TEXT
|
|||
|
|
|||
|
Property Parameters: Non-standard, alternate text representation and
|
|||
|
language property parameters can be specified on this property.
|
|||
|
|
|||
|
Conformance: This property can be specified in "VEVENT", "VTODO",
|
|||
|
"VJOURNAL", "VTIMEZONE" or "VFREEBUSY" calendar components.
|
|||
|
|
|||
|
Description: The property can be specified multiple times.
|
|||
|
|
|||
|
Format Definition: The property is defined by the following notation:
|
|||
|
|
|||
|
comment = "COMMENT" commparam ":" text CRLF
|
|||
|
|
|||
|
commparam = *(
|
|||
|
|
|||
|
; the following are optional,
|
|||
|
; but MUST NOT occur more than once
|
|||
|
|
|||
|
(";" altrepparam) / (";" languageparam) /
|
|||
|
|
|||
|
; the following is optional,
|
|||
|
; and MAY occur more than once
|
|||
|
|
|||
|
(";" xparam)
|
|||
|
|
|||
|
)
|
|||
|
|
|||
|
Example: The following is an example of this property:
|
|||
|
|
|||
|
COMMENT:The meeting really needs to include both ourselves
|
|||
|
and the customer. We can't hold this meeting without them.
|
|||
|
As a matter of fact\, the venue for the meeting ought to be at
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 80]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
their site. - - John
|
|||
|
|
|||
|
The data type for this property is TEXT.
|
|||
|
|
|||
|
4.8.1.5 Description
|
|||
|
|
|||
|
Property Name: DESCRIPTION
|
|||
|
|
|||
|
Purpose: This property provides a more complete description of the
|
|||
|
calendar component, than that provided by the "SUMMARY" property.
|
|||
|
|
|||
|
Value Type: TEXT
|
|||
|
|
|||
|
Property Parameters: Non-standard, alternate text representation and
|
|||
|
language property parameters can be specified on this property.
|
|||
|
|
|||
|
Conformance: The property can be specified in the "VEVENT", "VTODO",
|
|||
|
"VJOURNAL" or "VALARM" calendar components. The property can be
|
|||
|
specified multiple times only within a "VJOURNAL" calendar component.
|
|||
|
|
|||
|
Description: This property is used in the "VEVENT" and "VTODO" to
|
|||
|
capture lengthy textual decriptions associated with the activity.
|
|||
|
|
|||
|
This property is used in the "VJOURNAL" calendar component to capture
|
|||
|
one more textual journal entries.
|
|||
|
|
|||
|
This property is used in the "VALARM" calendar component to capture
|
|||
|
the display text for a DISPLAY category of alarm, to capture the body
|
|||
|
text for an EMAIL category of alarm and to capture the argument
|
|||
|
string for a PROCEDURE category of alarm.
|
|||
|
|
|||
|
Format Definition: The property is defined by the following notation:
|
|||
|
|
|||
|
description = "DESCRIPTION" descparam ":" text CRLF
|
|||
|
|
|||
|
descparam = *(
|
|||
|
|
|||
|
; the following are optional,
|
|||
|
; but MUST NOT occur more than once
|
|||
|
|
|||
|
(";" altrepparam) / (";" languageparam) /
|
|||
|
|
|||
|
; the following is optional,
|
|||
|
; and MAY occur more than once
|
|||
|
|
|||
|
(";" xparam)
|
|||
|
|
|||
|
)
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 81]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
Example: The following is an example of the property with formatted
|
|||
|
line breaks in the property value:
|
|||
|
|
|||
|
DESCRIPTION:Meeting to provide technical review for "Phoenix"
|
|||
|
design.\n Happy Face Conference Room. Phoenix design team
|
|||
|
MUST attend this meeting.\n RSVP to team leader.
|
|||
|
|
|||
|
The following is an example of the property with folding of long
|
|||
|
lines:
|
|||
|
|
|||
|
DESCRIPTION:Last draft of the new novel is to be completed
|
|||
|
for the editor's proof today.
|
|||
|
|
|||
|
4.8.1.6 Geographic Position
|
|||
|
|
|||
|
Property Name: GEO
|
|||
|
|
|||
|
Purpose: This property specifies information related to the global
|
|||
|
position for the activity specified by a calendar component.
|
|||
|
|
|||
|
Value Type: FLOAT. The value MUST be two SEMICOLON separated FLOAT
|
|||
|
values.
|
|||
|
|
|||
|
Property Parameters: Non-standard property parameters can be
|
|||
|
specified on this property.
|
|||
|
|
|||
|
Conformance: This property can be specified in "VEVENT" or "VTODO"
|
|||
|
calendar components.
|
|||
|
|
|||
|
Description: The property value specifies latitude and longitude, in
|
|||
|
that order (i.e., "LAT LON" ordering). The longitude represents the
|
|||
|
location east or west of the prime meridian as a positive or negative
|
|||
|
real number, respectively. The longitude and latitude values MAY be
|
|||
|
specified up to six decimal places, which will allow for accuracy to
|
|||
|
within one meter of geographical position. Receiving applications
|
|||
|
MUST accept values of this precision and MAY truncate values of
|
|||
|
greater precision.
|
|||
|
|
|||
|
Values for latitude and longitude shall be expressed as decimal
|
|||
|
fractions of degrees. Whole degrees of latitude shall be represented
|
|||
|
by a two-digit decimal number ranging from 0 through 90. Whole
|
|||
|
degrees of longitude shall be represented by a decimal number ranging
|
|||
|
from 0 through 180. When a decimal fraction of a degree is specified,
|
|||
|
it shall be separated from the whole number of degrees by a decimal
|
|||
|
point.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 82]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
Latitudes north of the equator shall be specified by a plus sign (+),
|
|||
|
or by the absence of a minus sign (-), preceding the digits
|
|||
|
designating degrees. Latitudes south of the Equator shall be
|
|||
|
designated by a minus sign (-) preceding the digits designating
|
|||
|
degrees. A point on the Equator shall be assigned to the Northern
|
|||
|
Hemisphere.
|
|||
|
|
|||
|
Longitudes east of the prime meridian shall be specified by a plus
|
|||
|
sign (+), or by the absence of a minus sign (-), preceding the digits
|
|||
|
designating degrees. Longitudes west of the meridian shall be
|
|||
|
designated by minus sign (-) preceding the digits designating
|
|||
|
degrees. A point on the prime meridian shall be assigned to the
|
|||
|
Eastern Hemisphere. A point on the 180th meridian shall be assigned
|
|||
|
to the Western Hemisphere. One exception to this last convention is
|
|||
|
permitted. For the special condition of describing a band of latitude
|
|||
|
around the earth, the East Bounding Coordinate data element shall be
|
|||
|
assigned the value +180 (180) degrees.
|
|||
|
|
|||
|
Any spatial address with a latitude of +90 (90) or -90 degrees will
|
|||
|
specify the position at the North or South Pole, respectively. The
|
|||
|
component for longitude may have any legal value.
|
|||
|
|
|||
|
With the exception of the special condition described above, this
|
|||
|
form is specified in Department of Commerce, 1986, Representation of
|
|||
|
geographic point locations for information interchange (Federal
|
|||
|
Information Processing Standard 70-1): Washington, Department of
|
|||
|
Commerce, National Institute of Standards and Technology.
|
|||
|
|
|||
|
The simple formula for converting degrees-minutes-seconds into
|
|||
|
decimal degrees is:
|
|||
|
|
|||
|
decimal = degrees + minutes/60 + seconds/3600.
|
|||
|
|
|||
|
Format Definition: The property is defined by the following notation:
|
|||
|
|
|||
|
geo = "GEO" geoparam ":" geovalue CRLF
|
|||
|
|
|||
|
geoparam = *(";" xparam)
|
|||
|
|
|||
|
geovalue = float ";" float
|
|||
|
;Latitude and Longitude components
|
|||
|
|
|||
|
Example: The following is an example of this property:
|
|||
|
|
|||
|
GEO:37.386013;-122.082932
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 83]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
4.8.1.7 Location
|
|||
|
|
|||
|
Property Name: LOCATION
|
|||
|
|
|||
|
Purpose: The property defines the intended venue for the activity
|
|||
|
defined by a calendar component.
|
|||
|
|
|||
|
Value Type: TEXT
|
|||
|
|
|||
|
Property Parameters: Non-standard, alternate text representation and
|
|||
|
language property parameters can be specified on this property.
|
|||
|
|
|||
|
Conformance: This property can be specified in "VEVENT" or "VTODO"
|
|||
|
calendar component.
|
|||
|
|
|||
|
Description: Specific venues such as conference or meeting rooms may
|
|||
|
be explicitly specified using this property. An alternate
|
|||
|
representation may be specified that is a URI that points to
|
|||
|
directory information with more structured specification of the
|
|||
|
location. For example, the alternate representation may specify
|
|||
|
either an LDAP URI pointing to an LDAP server entry or a CID URI
|
|||
|
pointing to a MIME body part containing a vCard [RFC 2426] for the
|
|||
|
location.
|
|||
|
|
|||
|
Format Definition: The property is defined by the following notation:
|
|||
|
|
|||
|
location = "LOCATION locparam ":" text CRLF
|
|||
|
|
|||
|
locparam = *(
|
|||
|
|
|||
|
; the following are optional,
|
|||
|
; but MUST NOT occur more than once
|
|||
|
|
|||
|
(";" altrepparam) / (";" languageparam) /
|
|||
|
|
|||
|
; the following is optional,
|
|||
|
; and MAY occur more than once
|
|||
|
|
|||
|
(";" xparam)
|
|||
|
|
|||
|
)
|
|||
|
|
|||
|
Example: The following are some examples of this property:
|
|||
|
|
|||
|
LOCATION:Conference Room - F123, Bldg. 002
|
|||
|
|
|||
|
LOCATION;ALTREP="http://xyzcorp.com/conf-rooms/f123.vcf":
|
|||
|
Conference Room - F123, Bldg. 002
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 84]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
4.8.1.8 Percent Complete
|
|||
|
|
|||
|
Property Name: PERCENT-COMPLETE
|
|||
|
|
|||
|
Purpose: This property is used by an assignee or delegatee of a to-do
|
|||
|
to convey the percent completion of a to-do to the Organizer.
|
|||
|
|
|||
|
Value Type: INTEGER
|
|||
|
|
|||
|
Property Parameters: Non-standard property parameters can be
|
|||
|
specified on this property.
|
|||
|
|
|||
|
Conformance: This property can be specified in a "VTODO" calendar
|
|||
|
component.
|
|||
|
|
|||
|
Description: The property value is a positive integer between zero
|
|||
|
and one hundred. A value of "0" indicates the to-do has not yet been
|
|||
|
started. A value of "100" indicates that the to-do has been
|
|||
|
completed. Integer values in between indicate the percent partially
|
|||
|
complete.
|
|||
|
|
|||
|
When a to-do is assigned to multiple individuals, the property value
|
|||
|
indicates the percent complete for that portion of the to-do assigned
|
|||
|
to the assignee or delegatee. For example, if a to-do is assigned to
|
|||
|
both individuals "A" and "B". A reply from "A" with a percent
|
|||
|
complete of "70" indicates that "A" has completed 70% of the to-do
|
|||
|
assigned to them. A reply from "B" with a percent complete of "50"
|
|||
|
indicates "B" has completed 50% of the to-do assigned to them.
|
|||
|
|
|||
|
Format Definition: The property is defined by the following notation:
|
|||
|
|
|||
|
percent = "PERCENT-COMPLETE" pctparam ":" integer CRLF
|
|||
|
|
|||
|
pctparam = *(";" xparam)
|
|||
|
|
|||
|
Example: The following is an example of this property to show 39%
|
|||
|
completion:
|
|||
|
|
|||
|
PERCENT-COMPLETE:39
|
|||
|
|
|||
|
4.8.1.9 Priority
|
|||
|
|
|||
|
Property Name: PRIORITY
|
|||
|
|
|||
|
Purpose: The property defines the relative priority for a calendar
|
|||
|
component.
|
|||
|
|
|||
|
Value Type: INTEGER
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 85]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
Property Parameters: Non-standard property parameters can be
|
|||
|
specified on this property.
|
|||
|
|
|||
|
Conformance: The property can be specified in a "VEVENT" or "VTODO"
|
|||
|
calendar component.
|
|||
|
|
|||
|
Description: The priority is specified as an integer in the range
|
|||
|
zero to nine. A value of zero (US-ASCII decimal 48) specifies an
|
|||
|
undefined priority. A value of one (US-ASCII decimal 49) is the
|
|||
|
highest priority. A value of two (US-ASCII decimal 50) is the second
|
|||
|
highest priority. Subsequent numbers specify a decreasing ordinal
|
|||
|
priority. A value of nine (US-ASCII decimal 58) is the lowest
|
|||
|
priority.
|
|||
|
|
|||
|
A CUA with a three-level priority scheme of "HIGH", "MEDIUM" and
|
|||
|
"LOW" is mapped into this property such that a property value in the
|
|||
|
range of one (US-ASCII decimal 49) to four (US-ASCII decimal 52)
|
|||
|
specifies "HIGH" priority. A value of five (US-ASCII decimal 53) is
|
|||
|
the normal or "MEDIUM" priority. A value in the range of six (US-
|
|||
|
ASCII decimal 54) to nine (US-ASCII decimal 58) is "LOW" priority.
|
|||
|
|
|||
|
A CUA with a priority schema of "A1", "A2", "A3", "B1", "B2", ...,
|
|||
|
"C3" is mapped into this property such that a property value of one
|
|||
|
(US-ASCII decimal 49) specifies "A1", a property value of two (US-
|
|||
|
ASCII decimal 50) specifies "A2", a property value of three (US-ASCII
|
|||
|
decimal 51) specifies "A3", and so forth up to a property value of 9
|
|||
|
(US-ASCII decimal 58) specifies "C3".
|
|||
|
|
|||
|
Other integer values are reserved for future use.
|
|||
|
|
|||
|
Within a "VEVENT" calendar component, this property specifies a
|
|||
|
priority for the event. This property may be useful when more than
|
|||
|
one event is scheduled for a given time period.
|
|||
|
|
|||
|
Within a "VTODO" calendar component, this property specified a
|
|||
|
priority for the to-do. This property is useful in prioritizing
|
|||
|
multiple action items for a given time period.
|
|||
|
|
|||
|
Format Definition: The property is specified by the following
|
|||
|
notation:
|
|||
|
|
|||
|
priority = "PRIORITY" prioparam ":" privalue CRLF
|
|||
|
;Default is zero
|
|||
|
|
|||
|
prioparam = *(";" xparam)
|
|||
|
|
|||
|
privalue = integer ;Must be in the range [0..9]
|
|||
|
; All other values are reserved for future use
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 86]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
The following is an example of a property with the highest priority:
|
|||
|
|
|||
|
PRIORITY:1
|
|||
|
|
|||
|
The following is an example of a property with a next highest
|
|||
|
priority:
|
|||
|
|
|||
|
PRIORITY:2
|
|||
|
|
|||
|
Example: The following is an example of a property with no priority.
|
|||
|
This is equivalent to not specifying the "PRIORITY" property:
|
|||
|
|
|||
|
PRIORITY:0
|
|||
|
|
|||
|
4.8.1.10 Resources
|
|||
|
|
|||
|
Property Name: RESOURCES
|
|||
|
|
|||
|
Purpose: This property defines the equipment or resources anticipated
|
|||
|
for an activity specified by a calendar entity..
|
|||
|
|
|||
|
Value Type: TEXT
|
|||
|
|
|||
|
Property Parameters: Non-standard, alternate text representation and
|
|||
|
language property parameters can be specified on this property.
|
|||
|
|
|||
|
Conformance: This property can be specified in "VEVENT" or "VTODO"
|
|||
|
calendar component.
|
|||
|
|
|||
|
Description: The property value is an arbitrary text. More than one
|
|||
|
resource can be specified as a list of resources separated by the
|
|||
|
COMMA character (US-ASCII decimal 44).
|
|||
|
|
|||
|
Format Definition: The property is defined by the following notation:
|
|||
|
|
|||
|
resources = "RESOURCES" resrcparam ":" text *("," text) CRLF
|
|||
|
|
|||
|
resrcparam = *(
|
|||
|
|
|||
|
; the following are optional,
|
|||
|
; but MUST NOT occur more than once
|
|||
|
|
|||
|
(";" altrepparam) / (";" languageparam) /
|
|||
|
|
|||
|
; the following is optional,
|
|||
|
; and MAY occur more than once
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 87]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
(";" xparam)
|
|||
|
|
|||
|
)
|
|||
|
|
|||
|
Example: The following is an example of this property:
|
|||
|
|
|||
|
RESOURCES:EASEL,PROJECTOR,VCR
|
|||
|
|
|||
|
RESOURCES;LANGUAGE=fr:1 raton-laveur
|
|||
|
|
|||
|
4.8.1.11 Status
|
|||
|
|
|||
|
Property Name: STATUS
|
|||
|
|
|||
|
Purpose: This property defines the overall status or confirmation for
|
|||
|
the calendar component.
|
|||
|
|
|||
|
Value Type: TEXT
|
|||
|
|
|||
|
Property Parameters: Non-standard property parameters can be
|
|||
|
specified on this property.
|
|||
|
|
|||
|
Conformance: This property can be specified in "VEVENT", "VTODO" or
|
|||
|
"VJOURNAL" calendar components.
|
|||
|
|
|||
|
Description: In a group scheduled calendar component, the property is
|
|||
|
used by the "Organizer" to provide a confirmation of the event to the
|
|||
|
"Attendees". For example in a "VEVENT" calendar component, the
|
|||
|
"Organizer" can indicate that a meeting is tentative, confirmed or
|
|||
|
cancelled. In a "VTODO" calendar component, the "Organizer" can
|
|||
|
indicate that an action item needs action, is completed, is in
|
|||
|
process or being worked on, or has been cancelled. In a "VJOURNAL"
|
|||
|
calendar component, the "Organizer" can indicate that a journal entry
|
|||
|
is draft, final or has been cancelled or removed.
|
|||
|
|
|||
|
Format Definition: The property is defined by the following notation:
|
|||
|
|
|||
|
status = "STATUS" statparam] ":" statvalue CRLF
|
|||
|
|
|||
|
statparam = *(";" xparam)
|
|||
|
|
|||
|
statvalue = "TENTATIVE" ;Indicates event is
|
|||
|
;tentative.
|
|||
|
/ "CONFIRMED" ;Indicates event is
|
|||
|
;definite.
|
|||
|
/ "CANCELLED" ;Indicates event was
|
|||
|
;cancelled.
|
|||
|
;Status values for a "VEVENT"
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 88]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
statvalue =/ "NEEDS-ACTION" ;Indicates to-do needs action.
|
|||
|
/ "COMPLETED" ;Indicates to-do completed.
|
|||
|
/ "IN-PROCESS" ;Indicates to-do in process of
|
|||
|
/ "CANCELLED" ;Indicates to-do was cancelled.
|
|||
|
;Status values for "VTODO".
|
|||
|
|
|||
|
statvalue =/ "DRAFT" ;Indicates journal is draft.
|
|||
|
/ "FINAL" ;Indicates journal is final.
|
|||
|
/ "CANCELLED" ;Indicates journal is removed.
|
|||
|
;Status values for "VJOURNAL".
|
|||
|
|
|||
|
Example: The following is an example of this property for a "VEVENT"
|
|||
|
calendar component:
|
|||
|
|
|||
|
STATUS:TENTATIVE
|
|||
|
|
|||
|
The following is an example of this property for a "VTODO" calendar
|
|||
|
component:
|
|||
|
|
|||
|
STATUS:NEEDS-ACTION
|
|||
|
|
|||
|
The following is an example of this property for a "VJOURNAL"
|
|||
|
calendar component:
|
|||
|
|
|||
|
STATUS:DRAFT
|
|||
|
|
|||
|
4.8.1.12 Summary
|
|||
|
|
|||
|
Property Name: SUMMARY
|
|||
|
|
|||
|
Purpose: This property defines a short summary or subject for the
|
|||
|
calendar component.
|
|||
|
|
|||
|
Value Type: TEXT
|
|||
|
|
|||
|
Property Parameters: Non-standard, alternate text representation and
|
|||
|
language property parameters can be specified on this property.
|
|||
|
|
|||
|
Conformance: The property can be specified in "VEVENT", "VTODO",
|
|||
|
"VJOURNAL" or "VALARM" calendar components.
|
|||
|
|
|||
|
Description: This property is used in the "VEVENT", "VTODO" and
|
|||
|
"VJOURNAL" calendar components to capture a short, one line summary
|
|||
|
about the activity or journal entry.
|
|||
|
|
|||
|
This property is used in the "VALARM" calendar component to capture
|
|||
|
the subject of an EMAIL category of alarm.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 89]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
Format Definition: The property is defined by the following notation:
|
|||
|
|
|||
|
summary = "SUMMARY" summparam ":" text CRLF
|
|||
|
|
|||
|
summparam = *(
|
|||
|
|
|||
|
; the following are optional,
|
|||
|
; but MUST NOT occur more than once
|
|||
|
|
|||
|
(";" altrepparam) / (";" languageparam) /
|
|||
|
|
|||
|
; the following is optional,
|
|||
|
; and MAY occur more than once
|
|||
|
|
|||
|
(";" xparam)
|
|||
|
|
|||
|
)
|
|||
|
|
|||
|
Example: The following is an example of this property:
|
|||
|
|
|||
|
SUMMARY:Department Party
|
|||
|
|
|||
|
4.8.2 Date and Time Component Properties
|
|||
|
|
|||
|
The following properties specify date and time related information in
|
|||
|
calendar components.
|
|||
|
|
|||
|
4.8.2.1 Date/Time Completed
|
|||
|
|
|||
|
Property Name: COMPLETED
|
|||
|
|
|||
|
Purpose: This property defines the date and time that a to-do was
|
|||
|
actually completed.
|
|||
|
|
|||
|
Value Type: DATE-TIME
|
|||
|
|
|||
|
Property Parameters: Non-standard property parameters can be
|
|||
|
specified on this property.
|
|||
|
|
|||
|
Conformance: The property can be specified in a "VTODO" calendar
|
|||
|
component.
|
|||
|
|
|||
|
Description: The date and time MUST be in a UTC format.
|
|||
|
|
|||
|
Format Definition: The property is defined by the following notation:
|
|||
|
|
|||
|
completed = "COMPLETED" compparam ":" date-time CRLF
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 90]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
compparam = *(";" xparam)
|
|||
|
|
|||
|
Example: The following is an example of this property:
|
|||
|
|
|||
|
COMPLETED:19960401T235959Z
|
|||
|
|
|||
|
4.8.2.2 Date/Time End
|
|||
|
|
|||
|
Property Name: DTEND
|
|||
|
|
|||
|
Purpose: This property specifies the date and time that a calendar
|
|||
|
component ends.
|
|||
|
|
|||
|
Value Type: The default value type is DATE-TIME. The value type can
|
|||
|
be set to a DATE value type.
|
|||
|
|
|||
|
Property Parameters: Non-standard, value data type, time zone
|
|||
|
identifier property parameters can be specified on this property.
|
|||
|
|
|||
|
Conformance: This property can be specified in "VEVENT" or
|
|||
|
"VFREEBUSY" calendar components.
|
|||
|
|
|||
|
Description: Within the "VEVENT" calendar component, this property
|
|||
|
defines the date and time by which the event ends. The value MUST be
|
|||
|
later in time than the value of the "DTSTART" property.
|
|||
|
|
|||
|
Within the "VFREEBUSY" calendar component, this property defines the
|
|||
|
end date and time for the free or busy time information. The time
|
|||
|
MUST be specified in the UTC time format. The value MUST be later in
|
|||
|
time than the value of the "DTSTART" property.
|
|||
|
|
|||
|
Format Definition: The property is defined by the following notation:
|
|||
|
|
|||
|
dtend = "DTEND" dtendparam":" dtendval CRLF
|
|||
|
|
|||
|
dtendparam = *(
|
|||
|
|
|||
|
; the following are optional,
|
|||
|
; but MUST NOT occur more than once
|
|||
|
|
|||
|
(";" "VALUE" "=" ("DATE-TIME" / "DATE")) /
|
|||
|
(";" tzidparam) /
|
|||
|
|
|||
|
; the following is optional,
|
|||
|
; and MAY occur more than once
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 91]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
(";" xparam)
|
|||
|
|
|||
|
)
|
|||
|
|
|||
|
|
|||
|
|
|||
|
dtendval = date-time / date
|
|||
|
;Value MUST match value type
|
|||
|
|
|||
|
Example: The following is an example of this property:
|
|||
|
|
|||
|
DTEND:19960401T235959Z
|
|||
|
|
|||
|
DTEND;VALUE=DATE:19980704
|
|||
|
|
|||
|
4.8.2.3 Date/Time Due
|
|||
|
|
|||
|
Property Name: DUE
|
|||
|
|
|||
|
Purpose: This property defines the date and time that a to-do is
|
|||
|
expected to be completed.
|
|||
|
|
|||
|
Value Type: The default value type is DATE-TIME. The value type can
|
|||
|
be set to a DATE value type.
|
|||
|
|
|||
|
Property Parameters: Non-standard, value data type, time zone
|
|||
|
identifier property parameters can be specified on this property.
|
|||
|
|
|||
|
Conformance: The property can be specified once in a "VTODO" calendar
|
|||
|
component.
|
|||
|
|
|||
|
Description: The value MUST be a date/time equal to or after the
|
|||
|
DTSTART value, if specified.
|
|||
|
|
|||
|
Format Definition: The property is defined by the following notation:
|
|||
|
|
|||
|
due = "DUE" dueparam":" dueval CRLF
|
|||
|
|
|||
|
dueparam = *(
|
|||
|
; the following are optional,
|
|||
|
; but MUST NOT occur more than once
|
|||
|
|
|||
|
(";" "VALUE" "=" ("DATE-TIME" / "DATE")) /
|
|||
|
(";" tzidparam) /
|
|||
|
|
|||
|
; the following is optional,
|
|||
|
; and MAY occur more than once
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 92]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
*(";" xparam)
|
|||
|
|
|||
|
)
|
|||
|
|
|||
|
|
|||
|
|
|||
|
dueval = date-time / date
|
|||
|
;Value MUST match value type
|
|||
|
|
|||
|
Example: The following is an example of this property:
|
|||
|
|
|||
|
DUE:19980430T235959Z
|
|||
|
|
|||
|
4.8.2.4 Date/Time Start
|
|||
|
|
|||
|
Property Name: DTSTART
|
|||
|
|
|||
|
Purpose: This property specifies when the calendar component begins.
|
|||
|
|
|||
|
Value Type: The default value type is DATE-TIME. The time value MUST
|
|||
|
be one of the forms defined for the DATE-TIME value type. The value
|
|||
|
type can be set to a DATE value type.
|
|||
|
|
|||
|
Property Parameters: Non-standard, value data type, time zone
|
|||
|
identifier property parameters can be specified on this property.
|
|||
|
|
|||
|
Conformance: This property can be specified in the "VEVENT", "VTODO",
|
|||
|
"VFREEBUSY", or "VTIMEZONE" calendar components.
|
|||
|
|
|||
|
Description: Within the "VEVENT" calendar component, this property
|
|||
|
defines the start date and time for the event. The property is
|
|||
|
REQUIRED in "VEVENT" calendar components. Events can have a start
|
|||
|
date/time but no end date/time. In that case, the event does not take
|
|||
|
up any time.
|
|||
|
|
|||
|
Within the "VFREEBUSY" calendar component, this property defines the
|
|||
|
start date and time for the free or busy time information. The time
|
|||
|
MUST be specified in UTC time.
|
|||
|
|
|||
|
Within the "VTIMEZONE" calendar component, this property defines the
|
|||
|
effective start date and time for a time zone specification. This
|
|||
|
property is REQUIRED within each STANDARD and DAYLIGHT part included
|
|||
|
in "VTIMEZONE" calendar components and MUST be specified as a local
|
|||
|
DATE-TIME without the "TZID" property parameter.
|
|||
|
|
|||
|
Format Definition: The property is defined by the following notation:
|
|||
|
|
|||
|
dtstart = "DTSTART" dtstparam ":" dtstval CRLF
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 93]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
dtstparam = *(
|
|||
|
|
|||
|
; the following are optional,
|
|||
|
; but MUST NOT occur more than once
|
|||
|
|
|||
|
(";" "VALUE" "=" ("DATE-TIME" / "DATE")) /
|
|||
|
(";" tzidparam) /
|
|||
|
|
|||
|
; the following is optional,
|
|||
|
; and MAY occur more than once
|
|||
|
|
|||
|
*(";" xparam)
|
|||
|
|
|||
|
)
|
|||
|
|
|||
|
|
|||
|
|
|||
|
dtstval = date-time / date
|
|||
|
;Value MUST match value type
|
|||
|
|
|||
|
Example: The following is an example of this property:
|
|||
|
|
|||
|
DTSTART:19980118T073000Z
|
|||
|
|
|||
|
4.8.2.5 Duration
|
|||
|
|
|||
|
Property Name: DURATION
|
|||
|
|
|||
|
Purpose: The property specifies a positive duration of time.
|
|||
|
|
|||
|
Value Type: DURATION
|
|||
|
|
|||
|
Property Parameters: Non-standard property parameters can be
|
|||
|
specified on this property.
|
|||
|
|
|||
|
Conformance: The property can be specified in "VEVENT", "VTODO",
|
|||
|
"VFREEBUSY" or "VALARM" calendar components.
|
|||
|
|
|||
|
Description: In a "VEVENT" calendar component the property may be
|
|||
|
used to specify a duration of the event, instead of an explicit end
|
|||
|
date/time. In a "VTODO" calendar component the property may be used
|
|||
|
to specify a duration for the to-do, instead of an explicit due
|
|||
|
date/time. In a "VFREEBUSY" calendar component the property may be
|
|||
|
used to specify the interval of free time being requested. In a
|
|||
|
"VALARM" calendar component the property may be used to specify the
|
|||
|
delay period prior to repeating an alarm.
|
|||
|
|
|||
|
Format Definition: The property is defined by the following notation:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 94]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
duration = "DURATION" durparam ":" dur-value CRLF
|
|||
|
;consisting of a positive duration of time.
|
|||
|
|
|||
|
durparam = *(";" xparam)
|
|||
|
|
|||
|
Example: The following is an example of this property that specifies
|
|||
|
an interval of time of 1 hour and zero minutes and zero seconds:
|
|||
|
|
|||
|
DURATION:PT1H0M0S
|
|||
|
|
|||
|
The following is an example of this property that specifies an
|
|||
|
interval of time of 15 minutes.
|
|||
|
|
|||
|
DURATION:PT15M
|
|||
|
|
|||
|
4.8.2.6 Free/Busy Time
|
|||
|
|
|||
|
Property Name: FREEBUSY
|
|||
|
|
|||
|
Purpose: The property defines one or more free or busy time
|
|||
|
intervals.
|
|||
|
|
|||
|
Value Type: PERIOD. The date and time values MUST be in an UTC time
|
|||
|
format.
|
|||
|
|
|||
|
Property Parameters: Non-standard or free/busy time type property
|
|||
|
parameters can be specified on this property.
|
|||
|
|
|||
|
Conformance: The property can be specified in a "VFREEBUSY" calendar
|
|||
|
component.
|
|||
|
|
|||
|
Property Parameter: "FBTYPE" and non-standard parameters can be
|
|||
|
specified on this property.
|
|||
|
|
|||
|
Description: These time periods can be specified as either a start
|
|||
|
and end date-time or a start date-time and duration. The date and
|
|||
|
time MUST be a UTC time format.
|
|||
|
|
|||
|
"FREEBUSY" properties within the "VFREEBUSY" calendar component
|
|||
|
SHOULD be sorted in ascending order, based on start time and then end
|
|||
|
time, with the earliest periods first.
|
|||
|
|
|||
|
The "FREEBUSY" property can specify more than one value, separated by
|
|||
|
the COMMA character (US-ASCII decimal 44). In such cases, the
|
|||
|
"FREEBUSY" property values SHOULD all be of the same "FBTYPE"
|
|||
|
property parameter type (e.g., all values of a particular "FBTYPE"
|
|||
|
listed together in a single property).
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 95]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
Format Definition: The property is defined by the following notation:
|
|||
|
|
|||
|
freebusy = "FREEBUSY" fbparam ":" fbvalue
|
|||
|
CRLF
|
|||
|
|
|||
|
fbparam = *(
|
|||
|
; the following is optional,
|
|||
|
; but MUST NOT occur more than once
|
|||
|
|
|||
|
(";" fbtypeparam) /
|
|||
|
|
|||
|
; the following is optional,
|
|||
|
; and MAY occur more than once
|
|||
|
|
|||
|
(";" xparam)
|
|||
|
|
|||
|
)
|
|||
|
|
|||
|
fbvalue = period *["," period]
|
|||
|
;Time value MUST be in the UTC time format.
|
|||
|
|
|||
|
Example: The following are some examples of this property:
|
|||
|
|
|||
|
FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:19970308T160000Z/PT8H30M
|
|||
|
|
|||
|
FREEBUSY;FBTYPE=FREE:19970308T160000Z/PT3H,19970308T200000Z/PT1H
|
|||
|
|
|||
|
FREEBUSY;FBTYPE=FREE:19970308T160000Z/PT3H,19970308T200000Z/PT1H,
|
|||
|
19970308T230000Z/19970309T000000Z
|
|||
|
|
|||
|
4.8.2.7 Time Transparency
|
|||
|
|
|||
|
Property Name: TRANSP
|
|||
|
|
|||
|
Purpose: This property defines whether an event is transparent or not
|
|||
|
to busy time searches.
|
|||
|
|
|||
|
Value Type: TEXT
|
|||
|
|
|||
|
Property Parameters: Non-standard property parameters can be
|
|||
|
specified on this property.
|
|||
|
|
|||
|
Conformance: This property can be specified once in a "VEVENT"
|
|||
|
calendar component.
|
|||
|
|
|||
|
Description: Time Transparency is the characteristic of an event that
|
|||
|
determines whether it appears to consume time on a calendar. Events
|
|||
|
that consume actual time for the individual or resource associated
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 96]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
with the calendar SHOULD be recorded as OPAQUE, allowing them to be
|
|||
|
detected by free-busy time searches. Other events, which do not take
|
|||
|
up the individual's (or resource's) time SHOULD be recorded as
|
|||
|
TRANSPARENT, making them invisible to free-busy time searches.
|
|||
|
|
|||
|
Format Definition: The property is specified by the following
|
|||
|
notation:
|
|||
|
|
|||
|
transp = "TRANSP" tranparam ":" transvalue CRLF
|
|||
|
|
|||
|
tranparam = *(";" xparam)
|
|||
|
|
|||
|
transvalue = "OPAQUE" ;Blocks or opaque on busy time searches.
|
|||
|
/ "TRANSPARENT" ;Transparent on busy time searches.
|
|||
|
;Default value is OPAQUE
|
|||
|
|
|||
|
Example: The following is an example of this property for an event
|
|||
|
that is transparent or does not block on free/busy time searches:
|
|||
|
|
|||
|
TRANSP:TRANSPARENT
|
|||
|
|
|||
|
The following is an example of this property for an event that is
|
|||
|
opaque or blocks on free/busy time searches:
|
|||
|
|
|||
|
TRANSP:OPAQUE
|
|||
|
|
|||
|
4.8.3 Time Zone Component Properties
|
|||
|
|
|||
|
The following properties specify time zone information in calendar
|
|||
|
components.
|
|||
|
|
|||
|
4.8.3.1 Time Zone Identifier
|
|||
|
|
|||
|
Property Name: TZID
|
|||
|
|
|||
|
Purpose: This property specifies the text value that uniquely
|
|||
|
identifies the "VTIMEZONE" calendar component.
|
|||
|
|
|||
|
Value Type: TEXT
|
|||
|
|
|||
|
Property Parameters: Non-standard property parameters can be
|
|||
|
specified on this property.
|
|||
|
|
|||
|
Conformance: This property MUST be specified in a "VTIMEZONE"
|
|||
|
calendar component.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 97]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
Description: This is the label by which a time zone calendar
|
|||
|
component is referenced by any iCalendar properties whose data type
|
|||
|
is either DATE-TIME or TIME and not intended to specify a UTC or a
|
|||
|
"floating" time. The presence of the SOLIDUS character (US-ASCII
|
|||
|
decimal 47) as a prefix, indicates that this TZID represents an
|
|||
|
unique ID in a globally defined time zone registry (when such
|
|||
|
registry is defined).
|
|||
|
|
|||
|
Note: This document does not define a naming convention for time
|
|||
|
zone identifiers. Implementers may want to use the naming
|
|||
|
conventions defined in existing time zone specifications such as
|
|||
|
the public-domain Olson database [TZ]. The specification of
|
|||
|
globally unique time zone identifiers is not addressed by this
|
|||
|
document and is left for future study.
|
|||
|
|
|||
|
Format Definition: This property is defined by the following
|
|||
|
notation:
|
|||
|
|
|||
|
tzid = "TZID" tzidpropparam ":" [tzidprefix] text CRLF
|
|||
|
|
|||
|
tzidpropparam = *(";" xparam)
|
|||
|
|
|||
|
;tzidprefix = "/"
|
|||
|
; Defined previously. Just listed here for reader convenience.
|
|||
|
|
|||
|
Example: The following are examples of non-globally unique time zone
|
|||
|
identifiers:
|
|||
|
|
|||
|
TZID:US-Eastern
|
|||
|
|
|||
|
TZID:California-Los_Angeles
|
|||
|
|
|||
|
The following is an example of a fictitious globally unique time zone
|
|||
|
identifier:
|
|||
|
|
|||
|
TZID:/US-New_York-New_York
|
|||
|
|
|||
|
4.8.3.2 Time Zone Name
|
|||
|
|
|||
|
Property Name: TZNAME
|
|||
|
|
|||
|
Purpose: This property specifies the customary designation for a time
|
|||
|
zone description.
|
|||
|
|
|||
|
Value Type: TEXT
|
|||
|
|
|||
|
Property Parameters: Non-standard and language property parameters
|
|||
|
can be specified on this property.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 98]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
Conformance: This property can be specified in a "VTIMEZONE" calendar
|
|||
|
component.
|
|||
|
|
|||
|
Description: This property may be specified in multiple languages; in
|
|||
|
order to provide for different language requirements.
|
|||
|
|
|||
|
Format Definition: This property is defined by the following
|
|||
|
notation:
|
|||
|
|
|||
|
tzname = "TZNAME" tznparam ":" text CRLF
|
|||
|
|
|||
|
tznparam = *(
|
|||
|
|
|||
|
; the following is optional,
|
|||
|
; but MUST NOT occur more than once
|
|||
|
|
|||
|
(";" languageparam) /
|
|||
|
|
|||
|
; the following is optional,
|
|||
|
; and MAY occur more than once
|
|||
|
|
|||
|
(";" xparam)
|
|||
|
|
|||
|
)
|
|||
|
|
|||
|
Example: The following are example of this property:
|
|||
|
|
|||
|
TZNAME:EST
|
|||
|
|
|||
|
The following is an example of this property when two different
|
|||
|
languages for the time zone name are specified:
|
|||
|
|
|||
|
TZNAME;LANGUAGE=en:EST
|
|||
|
TZNAME;LANGUAGE=fr-CA:HNE
|
|||
|
|
|||
|
4.8.3.3 Time Zone Offset From
|
|||
|
|
|||
|
Property Name: TZOFFSETFROM
|
|||
|
|
|||
|
Purpose: This property specifies the offset which is in use prior to
|
|||
|
this time zone observance.
|
|||
|
|
|||
|
Value Type: UTC-OFFSET
|
|||
|
|
|||
|
Property Parameters: Non-standard property parameters can be
|
|||
|
specified on this property.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 99]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
Conformance: This property MUST be specified in a "VTIMEZONE"
|
|||
|
calendar component.
|
|||
|
|
|||
|
Description: This property specifies the offset which is in use prior
|
|||
|
to this time observance. It is used to calculate the absolute time at
|
|||
|
which the transition to a given observance takes place. This property
|
|||
|
MUST only be specified in a "VTIMEZONE" calendar component. A
|
|||
|
"VTIMEZONE" calendar component MUST include this property. The
|
|||
|
property value is a signed numeric indicating the number of hours and
|
|||
|
possibly minutes from UTC. Positive numbers represent time zones east
|
|||
|
of the prime meridian, or ahead of UTC. Negative numbers represent
|
|||
|
time zones west of the prime meridian, or behind UTC.
|
|||
|
|
|||
|
Format Definition: The property is defined by the following notation:
|
|||
|
|
|||
|
tzoffsetfrom = "TZOFFSETFROM" frmparam ":" utc-offset
|
|||
|
CRLF
|
|||
|
|
|||
|
frmparam = *(";" xparam)
|
|||
|
|
|||
|
Example: The following are examples of this property:
|
|||
|
|
|||
|
TZOFFSETFROM:-0500
|
|||
|
|
|||
|
TZOFFSETFROM:+1345
|
|||
|
|
|||
|
4.8.3.4 Time Zone Offset To
|
|||
|
|
|||
|
Property Name: TZOFFSETTO
|
|||
|
|
|||
|
Purpose: This property specifies the offset which is in use in this
|
|||
|
time zone observance.
|
|||
|
|
|||
|
Value Type: UTC-OFFSET
|
|||
|
|
|||
|
Property Parameters: Non-standard property parameters can be
|
|||
|
specified on this property.
|
|||
|
|
|||
|
Conformance: This property MUST be specified in a "VTIMEZONE"
|
|||
|
calendar component.
|
|||
|
|
|||
|
Description: This property specifies the offset which is in use in
|
|||
|
this time zone observance. It is used to calculate the absolute time
|
|||
|
for the new observance. The property value is a signed numeric
|
|||
|
indicating the number of hours and possibly minutes from UTC.
|
|||
|
Positive numbers represent time zones east of the prime meridian, or
|
|||
|
ahead of UTC. Negative numbers represent time zones west of the prime
|
|||
|
meridian, or behind UTC.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 100]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
Format Definition: The property is defined by the following notation:
|
|||
|
|
|||
|
tzoffsetto = "TZOFFSETTO" toparam ":" utc-offset CRLF
|
|||
|
|
|||
|
toparam = *(";" xparam)
|
|||
|
|
|||
|
Example: The following are examples of this property:
|
|||
|
|
|||
|
TZOFFSETTO:-0400
|
|||
|
|
|||
|
TZOFFSETTO:+1245
|
|||
|
|
|||
|
4.8.3.5 Time Zone URL
|
|||
|
|
|||
|
Property Name: TZURL
|
|||
|
|
|||
|
Purpose: The TZURL provides a means for a VTIMEZONE component to
|
|||
|
point to a network location that can be used to retrieve an up-to-
|
|||
|
date version of itself.
|
|||
|
|
|||
|
Value Type: URI
|
|||
|
|
|||
|
Property Parameters: Non-standard property parameters can be
|
|||
|
specified on this property.
|
|||
|
|
|||
|
Conformance: This property can be specified in a "VTIMEZONE" calendar
|
|||
|
component.
|
|||
|
|
|||
|
Description: The TZURL provides a means for a VTIMEZONE component to
|
|||
|
point to a network location that can be used to retrieve an up-to-
|
|||
|
date version of itself. This provides a hook to handle changes
|
|||
|
government bodies impose upon time zone definitions. Retrieval of
|
|||
|
this resource results in an iCalendar object containing a single
|
|||
|
VTIMEZONE component and a METHOD property set to PUBLISH.
|
|||
|
|
|||
|
Format Definition: The property is defined by the following notation:
|
|||
|
|
|||
|
tzurl = "TZURL" tzurlparam ":" uri CRLF
|
|||
|
|
|||
|
tzurlparam = *(";" xparam)
|
|||
|
|
|||
|
Example: The following is an example of this property:
|
|||
|
|
|||
|
TZURL:http://timezones.r.us.net/tz/US-California-Los_Angeles
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 101]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
4.8.4 Relationship Component Properties
|
|||
|
|
|||
|
The following properties specify relationship information in calendar
|
|||
|
components.
|
|||
|
|
|||
|
4.8.4.1 Attendee
|
|||
|
|
|||
|
Property Name: ATTENDEE
|
|||
|
|
|||
|
Purpose: The property defines an "Attendee" within a calendar
|
|||
|
component.
|
|||
|
|
|||
|
Value Type: CAL-ADDRESS
|
|||
|
|
|||
|
Property Parameters: Non-standard, language, calendar user type,
|
|||
|
group or list membership, participation role, participation status,
|
|||
|
RSVP expectation, delegatee, delegator, sent by, common name or
|
|||
|
directory entry reference property parameters can be specified on
|
|||
|
this property.
|
|||
|
|
|||
|
Conformance: This property MUST be specified in an iCalendar object
|
|||
|
that specifies a group scheduled calendar entity. This property MUST
|
|||
|
NOT be specified in an iCalendar object when publishing the calendar
|
|||
|
information (e.g., NOT in an iCalendar object that specifies the
|
|||
|
publication of a calendar user's busy time, event, to-do or journal).
|
|||
|
This property is not specified in an iCalendar object that specifies
|
|||
|
only a time zone definition or that defines calendar entities that
|
|||
|
are not group scheduled entities, but are entities only on a single
|
|||
|
user's calendar.
|
|||
|
|
|||
|
Description: The property MUST only be specified within calendar
|
|||
|
components to specify participants, non-participants and the chair of
|
|||
|
a group scheduled calendar entity. The property is specified within
|
|||
|
an "EMAIL" category of the "VALARM" calendar component to specify an
|
|||
|
email address that is to receive the email type of iCalendar alarm.
|
|||
|
|
|||
|
The property parameter CN is for the common or displayable name
|
|||
|
associated with the calendar address; ROLE, for the intended role
|
|||
|
that the attendee will have in the calendar component; PARTSTAT, for
|
|||
|
the status of the attendee's participation; RSVP, for indicating
|
|||
|
whether the favor of a reply is requested; CUTYPE, to indicate the
|
|||
|
type of calendar user; MEMBER, to indicate the groups that the
|
|||
|
attendee belongs to; DELEGATED-TO, to indicate the calendar users
|
|||
|
that the original request was delegated to; and DELEGATED-FROM, to
|
|||
|
indicate whom the request was delegated from; SENT-BY, to indicate
|
|||
|
whom is acting on behalf of the ATTENDEE; and DIR, to indicate the
|
|||
|
URI that points to the directory information corresponding to the
|
|||
|
attendee. These property parameters can be specified on an "ATTENDEE"
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 102]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
property in either a "VEVENT", "VTODO" or "VJOURNAL" calendar
|
|||
|
component. They MUST not be specified in an "ATTENDEE" property in a
|
|||
|
"VFREEBUSY" or "VALARM" calendar component. If the LANGUAGE property
|
|||
|
parameter is specified, the identified language applies to the CN
|
|||
|
parameter.
|
|||
|
|
|||
|
A recipient delegated a request MUST inherit the RSVP and ROLE values
|
|||
|
from the attendee that delegated the request to them.
|
|||
|
|
|||
|
Multiple attendees can be specified by including multiple "ATTENDEE"
|
|||
|
properties within the calendar component.
|
|||
|
|
|||
|
Format Definition: The property is defined by the following notation:
|
|||
|
|
|||
|
attendee = "ATTENDEE" attparam ":" cal-address CRLF
|
|||
|
|
|||
|
attparam = *(
|
|||
|
|
|||
|
; the following are optional,
|
|||
|
; but MUST NOT occur more than once
|
|||
|
|
|||
|
(";" cutypeparam) / (";"memberparam) /
|
|||
|
(";" roleparam) / (";" partstatparam) /
|
|||
|
(";" rsvpparam) / (";" deltoparam) /
|
|||
|
(";" delfromparam) / (";" sentbyparam) /
|
|||
|
(";"cnparam) / (";" dirparam) /
|
|||
|
(";" languageparam) /
|
|||
|
|
|||
|
; the following is optional,
|
|||
|
; and MAY occur more than once
|
|||
|
|
|||
|
(";" xparam)
|
|||
|
|
|||
|
)
|
|||
|
|
|||
|
Example: The following are examples of this property's use for a to-
|
|||
|
do:
|
|||
|
|
|||
|
ORGANIZER:MAILTO:jsmith@host1.com
|
|||
|
ATTENDEE;MEMBER="MAILTO:DEV-GROUP@host2.com":
|
|||
|
MAILTO:joecool@host2.com
|
|||
|
ATTENDEE;DELEGATED-FROM="MAILTO:immud@host3.com":
|
|||
|
MAILTO:ildoit@host1.com
|
|||
|
|
|||
|
The following is an example of this property used for specifying
|
|||
|
multiple attendees to an event:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 103]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
ORGANIZER:MAILTO:jsmith@host1.com
|
|||
|
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;CN=Henry Cabot
|
|||
|
:MAILTO:hcabot@host2.com
|
|||
|
ATTENDEE;ROLE=REQ-PARTICIPANT;DELEGATED-FROM="MAILTO:bob@host.com"
|
|||
|
;PARTSTAT=ACCEPTED;CN=Jane Doe:MAILTO:jdoe@host1.com
|
|||
|
|
|||
|
The following is an example of this property with a URI to the
|
|||
|
directory information associated with the attendee:
|
|||
|
|
|||
|
ATTENDEE;CN=John Smith;DIR="ldap://host.com:6666/o=eDABC%
|
|||
|
20Industries,c=3DUS??(cn=3DBJim%20Dolittle)":MAILTO:jimdo@
|
|||
|
host1.com
|
|||
|
|
|||
|
The following is an example of this property with "delegatee" and
|
|||
|
"delegator" information for an event:
|
|||
|
|
|||
|
ORGANIZER;CN=John Smith:MAILTO:jsmith@host.com
|
|||
|
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;DELEGATED-FROM=
|
|||
|
"MAILTO:iamboss@host2.com";CN=Henry Cabot:MAILTO:hcabot@
|
|||
|
host2.com
|
|||
|
ATTENDEE;ROLE=NON-PARTICIPANT;PARTSTAT=DELEGATED;DELEGATED-TO=
|
|||
|
"MAILTO:hcabot@host2.com";CN=The Big Cheese:MAILTO:iamboss
|
|||
|
@host2.com
|
|||
|
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;CN=Jane Doe
|
|||
|
:MAILTO:jdoe@host1.com
|
|||
|
|
|||
|
Example: The following is an example of this property's use when
|
|||
|
another calendar user is acting on behalf of the "Attendee":
|
|||
|
|
|||
|
ATTENDEE;SENT-BY=MAILTO:jan_doe@host1.com;CN=John Smith:MAILTO:
|
|||
|
jsmith@host1.com
|
|||
|
|
|||
|
4.8.4.2 Contact
|
|||
|
|
|||
|
Property Name: CONTACT
|
|||
|
|
|||
|
Purpose: The property is used to represent contact information or
|
|||
|
alternately a reference to contact information associated with the
|
|||
|
calendar component.
|
|||
|
|
|||
|
Value Type: TEXT
|
|||
|
|
|||
|
Property Parameters: Non-standard, alternate text representation and
|
|||
|
language property parameters can be specified on this property.
|
|||
|
|
|||
|
Conformance: The property can be specified in a "VEVENT", "VTODO",
|
|||
|
"VJOURNAL" or "VFREEBUSY" calendar component.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 104]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
Description: The property value consists of textual contact
|
|||
|
information. An alternative representation for the property value can
|
|||
|
also be specified that refers to a URI pointing to an alternate form,
|
|||
|
such as a vCard [RFC 2426], for the contact information.
|
|||
|
|
|||
|
Format Definition: The property is defined by the following notation:
|
|||
|
|
|||
|
contact = "CONTACT" contparam ":" text CRLF
|
|||
|
|
|||
|
contparam = *(
|
|||
|
; the following are optional,
|
|||
|
; but MUST NOT occur more than once
|
|||
|
|
|||
|
(";" altrepparam) / (";" languageparam) /
|
|||
|
|
|||
|
; the following is optional,
|
|||
|
; and MAY occur more than once
|
|||
|
|
|||
|
(";" xparam)
|
|||
|
|
|||
|
)
|
|||
|
|
|||
|
Example: The following is an example of this property referencing
|
|||
|
textual contact information:
|
|||
|
|
|||
|
CONTACT:Jim Dolittle\, ABC Industries\, +1-919-555-1234
|
|||
|
|
|||
|
The following is an example of this property with an alternate
|
|||
|
representation of a LDAP URI to a directory entry containing the
|
|||
|
contact information:
|
|||
|
|
|||
|
CONTACT;ALTREP="ldap://host.com:6666/o=3DABC%20Industries\,
|
|||
|
c=3DUS??(cn=3DBJim%20Dolittle)":Jim Dolittle\, ABC Industries\,
|
|||
|
+1-919-555-1234
|
|||
|
|
|||
|
The following is an example of this property with an alternate
|
|||
|
representation of a MIME body part containing the contact
|
|||
|
information, such as a vCard [RFC 2426] embedded in a [MIME-DIR]
|
|||
|
content-type:
|
|||
|
|
|||
|
CONTACT;ALTREP="CID=<part3.msg970930T083000SILVER@host.com>":Jim
|
|||
|
Dolittle\, ABC Industries\, +1-919-555-1234
|
|||
|
|
|||
|
The following is an example of this property referencing a network
|
|||
|
resource, such as a vCard [RFC 2426] object containing the contact
|
|||
|
information:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 105]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
CONTACT;ALTREP="http://host.com/pdi/jdoe.vcf":Jim
|
|||
|
Dolittle\, ABC Industries\, +1-919-555-1234
|
|||
|
|
|||
|
4.8.4.3 Organizer
|
|||
|
|
|||
|
Property Name: ORGANIZER
|
|||
|
|
|||
|
Purpose: The property defines the organizer for a calendar component.
|
|||
|
|
|||
|
Value Type: CAL-ADDRESS
|
|||
|
|
|||
|
Property Parameters: Non-standard, language, common name, directory
|
|||
|
entry reference, sent by property parameters can be specified on this
|
|||
|
property.
|
|||
|
|
|||
|
Conformance: This property MUST be specified in an iCalendar object
|
|||
|
that specifies a group scheduled calendar entity. This property MUST
|
|||
|
be specified in an iCalendar object that specifies the publication of
|
|||
|
a calendar user's busy time. This property MUST NOT be specified in
|
|||
|
an iCalendar object that specifies only a time zone definition or
|
|||
|
that defines calendar entities that are not group scheduled entities,
|
|||
|
but are entities only on a single user's calendar.
|
|||
|
|
|||
|
Description: The property is specified within the "VEVENT", "VTODO",
|
|||
|
"VJOURNAL calendar components to specify the organizer of a group
|
|||
|
scheduled calendar entity. The property is specified within the
|
|||
|
"VFREEBUSY" calendar component to specify the calendar user
|
|||
|
requesting the free or busy time. When publishing a "VFREEBUSY"
|
|||
|
calendar component, the property is used to specify the calendar that
|
|||
|
the published busy time came from.
|
|||
|
|
|||
|
The property has the property parameters CN, for specifying the
|
|||
|
common or display name associated with the "Organizer", DIR, for
|
|||
|
specifying a pointer to the directory information associated with the
|
|||
|
"Organizer", SENT-BY, for specifying another calendar user that is
|
|||
|
acting on behalf of the "Organizer". The non-standard parameters may
|
|||
|
also be specified on this property. If the LANGUAGE property
|
|||
|
parameter is specified, the identified language applies to the CN
|
|||
|
parameter value.
|
|||
|
|
|||
|
Format Definition: The property is defined by the following notation:
|
|||
|
|
|||
|
organizer = "ORGANIZER" orgparam ":"
|
|||
|
cal-address CRLF
|
|||
|
|
|||
|
orgparam = *(
|
|||
|
|
|||
|
; the following are optional,
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 106]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
; but MUST NOT occur more than once
|
|||
|
|
|||
|
(";" cnparam) / (";" dirparam) / (";" sentbyparam) /
|
|||
|
(";" languageparam) /
|
|||
|
|
|||
|
; the following is optional,
|
|||
|
; and MAY occur more than once
|
|||
|
|
|||
|
(";" xparam)
|
|||
|
|
|||
|
)
|
|||
|
|
|||
|
Example: The following is an example of this property:
|
|||
|
|
|||
|
ORGANIZER;CN=John Smith:MAILTO:jsmith@host1.com
|
|||
|
|
|||
|
The following is an example of this property with a pointer to the
|
|||
|
directory information associated with the organizer:
|
|||
|
|
|||
|
ORGANIZER;CN=JohnSmith;DIR="ldap://host.com:6666/o=3DDC%20Associ
|
|||
|
ates,c=3DUS??(cn=3DJohn%20Smith)":MAILTO:jsmith@host1.com
|
|||
|
|
|||
|
The following is an example of this property used by another calendar
|
|||
|
user who is acting on behalf of the organizer, with responses
|
|||
|
intended to be sent back to the organizer, not the other calendar
|
|||
|
user:
|
|||
|
|
|||
|
ORGANIZER;SENT-BY="MAILTO:jane_doe@host.com":
|
|||
|
MAILTO:jsmith@host1.com
|
|||
|
|
|||
|
4.8.4.4 Recurrence ID
|
|||
|
|
|||
|
Property Name: RECURRENCE-ID
|
|||
|
|
|||
|
Purpose: This property is used in conjunction with the "UID" and
|
|||
|
"SEQUENCE" property to identify a specific instance of a recurring
|
|||
|
"VEVENT", "VTODO" or "VJOURNAL" calendar component. The property
|
|||
|
value is the effective value of the "DTSTART" property of the
|
|||
|
recurrence instance.
|
|||
|
|
|||
|
Value Type: The default value type for this property is DATE-TIME.
|
|||
|
The time format can be any of the valid forms defined for a DATE-TIME
|
|||
|
value type. See DATE-TIME value type definition for specific
|
|||
|
interpretations of the various forms. The value type can be set to
|
|||
|
DATE.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 107]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
Property Parameters: Non-standard property, value data type, time
|
|||
|
zone identifier and recurrence identifier range parameters can be
|
|||
|
specified on this property.
|
|||
|
|
|||
|
Conformance: This property can be specified in an iCalendar object
|
|||
|
containing a recurring calendar component.
|
|||
|
|
|||
|
Description: The full range of calendar components specified by a
|
|||
|
recurrence set is referenced by referring to just the "UID" property
|
|||
|
value corresponding to the calendar component. The "RECURRENCE-ID"
|
|||
|
property allows the reference to an individual instance within the
|
|||
|
recurrence set.
|
|||
|
|
|||
|
If the value of the "DTSTART" property is a DATE type value, then the
|
|||
|
value MUST be the calendar date for the recurrence instance.
|
|||
|
|
|||
|
The date/time value is set to the time when the original recurrence
|
|||
|
instance would occur; meaning that if the intent is to change a
|
|||
|
Friday meeting to Thursday, the date/time is still set to the
|
|||
|
original Friday meeting.
|
|||
|
|
|||
|
The "RECURRENCE-ID" property is used in conjunction with the "UID"
|
|||
|
and "SEQUENCE" property to identify a particular instance of a
|
|||
|
recurring event, to-do or journal. For a given pair of "UID" and
|
|||
|
"SEQUENCE" property values, the "RECURRENCE-ID" value for a
|
|||
|
recurrence instance is fixed. When the definition of the recurrence
|
|||
|
set for a calendar component changes, and hence the "SEQUENCE"
|
|||
|
property value changes, the "RECURRENCE-ID" for a given recurrence
|
|||
|
instance might also change.The "RANGE" parameter is used to specify
|
|||
|
the effective range of recurrence instances from the instance
|
|||
|
specified by the "RECURRENCE-ID" property value. The default value
|
|||
|
for the range parameter is the single recurrence instance only. The
|
|||
|
value can also be "THISANDPRIOR" to indicate a range defined by the
|
|||
|
given recurrence instance and all prior instances or the value can be
|
|||
|
"THISANDFUTURE" to indicate a range defined by the given recurrence
|
|||
|
instance and all subsequent instances.
|
|||
|
|
|||
|
Format Definition: The property is defined by the following notation:
|
|||
|
|
|||
|
recurid = "RECURRENCE-ID" ridparam ":" ridval CRLF
|
|||
|
|
|||
|
ridparam = *(
|
|||
|
|
|||
|
; the following are optional,
|
|||
|
; but MUST NOT occur more than once
|
|||
|
|
|||
|
(";" "VALUE" "=" ("DATE-TIME" / "DATE)) /
|
|||
|
(";" tzidparam) / (";" rangeparam) /
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 108]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
; the following is optional,
|
|||
|
; and MAY occur more than once
|
|||
|
|
|||
|
(";" xparam)
|
|||
|
|
|||
|
)
|
|||
|
|
|||
|
ridval = date-time / date
|
|||
|
;Value MUST match value type
|
|||
|
|
|||
|
Example: The following are examples of this property:
|
|||
|
|
|||
|
RECURRENCE-ID;VALUE=DATE:19960401
|
|||
|
|
|||
|
RECURRENCE-ID;RANGE=THISANDFUTURE:19960120T120000Z
|
|||
|
|
|||
|
4.8.4.5 Related To
|
|||
|
|
|||
|
Property Name: RELATED-TO
|
|||
|
|
|||
|
Purpose: The property is used to represent a relationship or
|
|||
|
reference between one calendar component and another.
|
|||
|
|
|||
|
Value Type: TEXT
|
|||
|
|
|||
|
Property Parameters: Non-standard and relationship type property
|
|||
|
parameters can be specified on this property.
|
|||
|
|
|||
|
Conformance: The property can be specified one or more times in the
|
|||
|
"VEVENT", "VTODO" or "VJOURNAL" calendar components.
|
|||
|
|
|||
|
Description: The property value consists of the persistent, globally
|
|||
|
unique identifier of another calendar component. This value would be
|
|||
|
represented in a calendar component by the "UID" property.
|
|||
|
|
|||
|
By default, the property value points to another calendar component
|
|||
|
that has a PARENT relationship to the referencing object. The
|
|||
|
"RELTYPE" property parameter is used to either explicitly state the
|
|||
|
default PARENT relationship type to the referenced calendar component
|
|||
|
or to override the default PARENT relationship type and specify
|
|||
|
either a CHILD or SIBLING relationship. The PARENT relationship
|
|||
|
indicates that the calendar component is a subordinate of the
|
|||
|
referenced calendar component. The CHILD relationship indicates that
|
|||
|
the calendar component is a superior of the referenced calendar
|
|||
|
component. The SIBLING relationship indicates that the calendar
|
|||
|
component is a peer of the referenced calendar component.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 109]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
Changes to a calendar component referenced by this property can have
|
|||
|
an implicit impact on the related calendar component. For example, if
|
|||
|
a group event changes its start or end date or time, then the
|
|||
|
related, dependent events will need to have their start and end dates
|
|||
|
changed in a corresponding way. Similarly, if a PARENT calendar
|
|||
|
component is canceled or deleted, then there is an implied impact to
|
|||
|
the related CHILD calendar components. This property is intended only
|
|||
|
to provide information on the relationship of calendar components. It
|
|||
|
is up to the target calendar system to maintain any property
|
|||
|
implications of this relationship.
|
|||
|
|
|||
|
Format Definition: The property is defined by the following notation:
|
|||
|
|
|||
|
related = "RELATED-TO" [relparam] ":" text CRLF
|
|||
|
|
|||
|
relparam = *(
|
|||
|
|
|||
|
; the following is optional,
|
|||
|
; but MUST NOT occur more than once
|
|||
|
|
|||
|
(";" reltypeparam) /
|
|||
|
|
|||
|
; the following is optional,
|
|||
|
; and MAY occur more than once
|
|||
|
|
|||
|
(";" xparm)
|
|||
|
|
|||
|
)
|
|||
|
|
|||
|
The following is an example of this property:
|
|||
|
|
|||
|
RELATED-TO:<jsmith.part7.19960817T083000.xyzMail@host3.com>
|
|||
|
|
|||
|
RELATED-TO:<19960401-080045-4000F192713-0052@host1.com>
|
|||
|
|
|||
|
4.8.4.6 Uniform Resource Locator
|
|||
|
|
|||
|
Property Name: URL
|
|||
|
|
|||
|
Purpose: This property defines a Uniform Resource Locator (URL)
|
|||
|
associated with the iCalendar object.
|
|||
|
|
|||
|
Value Type: URI
|
|||
|
|
|||
|
Property Parameters: Non-standard property parameters can be
|
|||
|
specified on this property.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 110]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
Conformance: This property can be specified once in the "VEVENT",
|
|||
|
"VTODO", "VJOURNAL" or "VFREEBUSY" calendar components.
|
|||
|
|
|||
|
Description: This property may be used in a calendar component to
|
|||
|
convey a location where a more dynamic rendition of the calendar
|
|||
|
information associated with the calendar component can be found. This
|
|||
|
memo does not attempt to standardize the form of the URI, nor the
|
|||
|
format of the resource pointed to by the property value. If the URL
|
|||
|
property and Content-Location MIME header are both specified, they
|
|||
|
MUST point to the same resource.
|
|||
|
|
|||
|
Format Definition: The property is defined by the following notation:
|
|||
|
|
|||
|
url = "URL" urlparam ":" uri CRLF
|
|||
|
|
|||
|
urlparam = *(";" xparam)
|
|||
|
|
|||
|
Example: The following is an example of this property:
|
|||
|
|
|||
|
URL:http://abc.com/pub/calendars/jsmith/mytime.ics
|
|||
|
|
|||
|
4.8.4.7 Unique Identifier
|
|||
|
|
|||
|
Property Name: UID
|
|||
|
|
|||
|
Purpose: This property defines the persistent, globally unique
|
|||
|
identifier for the calendar component.
|
|||
|
|
|||
|
Value Type: TEXT
|
|||
|
|
|||
|
Property Parameters: Non-standard property parameters can be
|
|||
|
specified on this property.
|
|||
|
|
|||
|
Conformance: The property MUST be specified in the "VEVENT", "VTODO",
|
|||
|
"VJOURNAL" or "VFREEBUSY" calendar components.
|
|||
|
|
|||
|
Description: The UID itself MUST be a globally unique identifier. The
|
|||
|
generator of the identifier MUST guarantee that the identifier is
|
|||
|
unique. There are several algorithms that can be used to accomplish
|
|||
|
this. The identifier is RECOMMENDED to be the identical syntax to the
|
|||
|
[RFC 822] addr-spec. A good method to assure uniqueness is to put the
|
|||
|
domain name or a domain literal IP address of the host on which the
|
|||
|
identifier was created on the right hand side of the "@", and on the
|
|||
|
left hand side, put a combination of the current calendar date and
|
|||
|
time of day (i.e., formatted in as a DATE-TIME value) along with some
|
|||
|
other currently unique (perhaps sequential) identifier available on
|
|||
|
the system (for example, a process id number). Using a date/time
|
|||
|
value on the left hand side and a domain name or domain literal on
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 111]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
the right hand side makes it possible to guarantee uniqueness since
|
|||
|
no two hosts should be using the same domain name or IP address at
|
|||
|
the same time. Though other algorithms will work, it is RECOMMENDED
|
|||
|
that the right hand side contain some domain identifier (either of
|
|||
|
the host itself or otherwise) such that the generator of the message
|
|||
|
identifier can guarantee the uniqueness of the left hand side within
|
|||
|
the scope of that domain.
|
|||
|
|
|||
|
This is the method for correlating scheduling messages with the
|
|||
|
referenced "VEVENT", "VTODO", or "VJOURNAL" calendar component.
|
|||
|
|
|||
|
The full range of calendar components specified by a recurrence set
|
|||
|
is referenced by referring to just the "UID" property value
|
|||
|
corresponding to the calendar component. The "RECURRENCE-ID" property
|
|||
|
allows the reference to an individual instance within the recurrence
|
|||
|
set.
|
|||
|
|
|||
|
This property is an important method for group scheduling
|
|||
|
applications to match requests with later replies, modifications or
|
|||
|
deletion requests. Calendaring and scheduling applications MUST
|
|||
|
generate this property in "VEVENT", "VTODO" and "VJOURNAL" calendar
|
|||
|
components to assure interoperability with other group scheduling
|
|||
|
applications. This identifier is created by the calendar system that
|
|||
|
generates an iCalendar object.
|
|||
|
|
|||
|
Implementations MUST be able to receive and persist values of at
|
|||
|
least 255 characters for this property.
|
|||
|
|
|||
|
Format Definition: The property is defined by the following notation:
|
|||
|
|
|||
|
uid = "UID" uidparam ":" text CRLF
|
|||
|
|
|||
|
uidparam = *(";" xparam)
|
|||
|
|
|||
|
Example: The following is an example of this property:
|
|||
|
|
|||
|
UID:19960401T080045Z-4000F192713-0052@host1.com
|
|||
|
|
|||
|
4.8.5 Recurrence Component Properties
|
|||
|
|
|||
|
The following properties specify recurrence information in calendar
|
|||
|
components.
|
|||
|
|
|||
|
4.8.5.1 Exception Date/Times
|
|||
|
|
|||
|
Property Name: EXDATE
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 112]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
Purpose: This property defines the list of date/time exceptions for a
|
|||
|
recurring calendar component.
|
|||
|
|
|||
|
Value Type: The default value type for this property is DATE-TIME.
|
|||
|
The value type can be set to DATE.
|
|||
|
|
|||
|
Property Parameters: Non-standard, value data type and time zone
|
|||
|
identifier property parameters can be specified on this property.
|
|||
|
|
|||
|
Conformance: This property can be specified in an iCalendar object
|
|||
|
that includes a recurring calendar component.
|
|||
|
|
|||
|
Description: The exception dates, if specified, are used in computing
|
|||
|
the recurrence set. The recurrence set is the complete set of
|
|||
|
recurrence instances for a calendar component. The recurrence set is
|
|||
|
generated by considering the initial "DTSTART" property along with
|
|||
|
the "RRULE", "RDATE", "EXDATE" and "EXRULE" properties contained
|
|||
|
within the iCalendar object. The "DTSTART" property defines the first
|
|||
|
instance in the recurrence set. Multiple instances of the "RRULE" and
|
|||
|
"EXRULE" properties can also be specified to define more
|
|||
|
sophisticated recurrence sets. The final recurrence set is generated
|
|||
|
by gathering all of the start date-times generated by any of the
|
|||
|
specified "RRULE" and "RDATE" properties, and then excluding any
|
|||
|
start date and times which fall within the union of start date and
|
|||
|
times generated by any specified "EXRULE" and "EXDATE" properties.
|
|||
|
This implies that start date and times within exclusion related
|
|||
|
properties (i.e., "EXDATE" and "EXRULE") take precedence over those
|
|||
|
specified by inclusion properties (i.e., "RDATE" and "RRULE"). Where
|
|||
|
duplicate instances are generated by the "RRULE" and "RDATE"
|
|||
|
properties, only one recurrence is considered. Duplicate instances
|
|||
|
are ignored.
|
|||
|
|
|||
|
The "EXDATE" property can be used to exclude the value specified in
|
|||
|
"DTSTART". However, in such cases the original "DTSTART" date MUST
|
|||
|
still be maintained by the calendaring and scheduling system because
|
|||
|
the original "DTSTART" value has inherent usage dependencies by other
|
|||
|
properties such as the "RECURRENCE-ID".
|
|||
|
|
|||
|
Format Definition: The property is defined by the following notation:
|
|||
|
|
|||
|
exdate = "EXDATE" exdtparam ":" exdtval *("," exdtval) CRLF
|
|||
|
|
|||
|
exdtparam = *(
|
|||
|
|
|||
|
; the following are optional,
|
|||
|
; but MUST NOT occur more than once
|
|||
|
|
|||
|
(";" "VALUE" "=" ("DATE-TIME" / "DATE")) /
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 113]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
(";" tzidparam) /
|
|||
|
|
|||
|
; the following is optional,
|
|||
|
; and MAY occur more than once
|
|||
|
|
|||
|
(";" xparam)
|
|||
|
|
|||
|
)
|
|||
|
|
|||
|
exdtval = date-time / date
|
|||
|
;Value MUST match value type
|
|||
|
|
|||
|
Example: The following is an example of this property:
|
|||
|
|
|||
|
EXDATE:19960402T010000Z,19960403T010000Z,19960404T010000Z
|
|||
|
|
|||
|
4.8.5.2 Exception Rule
|
|||
|
|
|||
|
Property Name: EXRULE
|
|||
|
|
|||
|
Purpose: This property defines a rule or repeating pattern for an
|
|||
|
exception to a recurrence set.
|
|||
|
|
|||
|
Value Type: RECUR
|
|||
|
|
|||
|
Property Parameters: Non-standard property parameters can be
|
|||
|
specified on this property.
|
|||
|
|
|||
|
Conformance: This property can be specified in "VEVENT", "VTODO" or
|
|||
|
"VJOURNAL" calendar components.
|
|||
|
|
|||
|
Description: The exception rule, if specified, is used in computing
|
|||
|
the recurrence set. The recurrence set is the complete set of
|
|||
|
recurrence instances for a calendar component. The recurrence set is
|
|||
|
generated by considering the initial "DTSTART" property along with
|
|||
|
the "RRULE", "RDATE", "EXDATE" and "EXRULE" properties contained
|
|||
|
within the iCalendar object. The "DTSTART" defines the first instance
|
|||
|
in the recurrence set. Multiple instances of the "RRULE" and "EXRULE"
|
|||
|
properties can also be specified to define more sophisticated
|
|||
|
recurrence sets. The final recurrence set is generated by gathering
|
|||
|
all of the start date-times generated by any of the specified "RRULE"
|
|||
|
and "RDATE" properties, and excluding any start date and times which
|
|||
|
fall within the union of start date and times generated by any
|
|||
|
specified "EXRULE" and "EXDATE" properties. This implies that start
|
|||
|
date and times within exclusion related properties (i.e., "EXDATE"
|
|||
|
and "EXRULE") take precedence over those specified by inclusion
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 114]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
properties (i.e., "RDATE" and "RRULE"). Where duplicate instances are
|
|||
|
generated by the "RRULE" and "RDATE" properties, only one recurrence
|
|||
|
is considered. Duplicate instances are ignored.
|
|||
|
|
|||
|
The "EXRULE" property can be used to exclude the value specified in
|
|||
|
"DTSTART". However, in such cases the original "DTSTART" date MUST
|
|||
|
still be maintained by the calendaring and scheduling system because
|
|||
|
the original "DTSTART" value has inherent usage dependencies by other
|
|||
|
properties such as the "RECURRENCE-ID".
|
|||
|
|
|||
|
Format Definition: The property is defined by the following notation:
|
|||
|
|
|||
|
exrule = "EXRULE" exrparam ":" recur CRLF
|
|||
|
|
|||
|
exrparam = *(";" xparam)
|
|||
|
|
|||
|
Example: The following are examples of this property. Except every
|
|||
|
other week, on Tuesday and Thursday for 4 occurrences:
|
|||
|
|
|||
|
EXRULE:FREQ=WEEKLY;COUNT=4;INTERVAL=2;BYDAY=TU,TH
|
|||
|
|
|||
|
Except daily for 10 occurrences:
|
|||
|
|
|||
|
EXRULE:FREQ=DAILY;COUNT=10
|
|||
|
|
|||
|
Except yearly in June and July for 8 occurrences:
|
|||
|
|
|||
|
EXRULE:FREQ=YEARLY;COUNT=8;BYMONTH=6,7
|
|||
|
|
|||
|
4.8.5.3 Recurrence Date/Times
|
|||
|
|
|||
|
Property Name: RDATE
|
|||
|
|
|||
|
Purpose: This property defines the list of date/times for a
|
|||
|
recurrence set.
|
|||
|
|
|||
|
Value Type: The default value type for this property is DATE-TIME.
|
|||
|
The value type can be set to DATE or PERIOD.
|
|||
|
|
|||
|
Property Parameters: Non-standard, value data type and time zone
|
|||
|
identifier property parameters can be specified on this property.
|
|||
|
|
|||
|
Conformance: The property can be specified in "VEVENT", "VTODO",
|
|||
|
"VJOURNAL" or "VTIMEZONE" calendar components.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 115]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
Description: This property can appear along with the "RRULE" property
|
|||
|
to define an aggregate set of repeating occurrences. When they both
|
|||
|
appear in an iCalendar object, the recurring events are defined by
|
|||
|
the union of occurrences defined by both the "RDATE" and "RRULE".
|
|||
|
|
|||
|
The recurrence dates, if specified, are used in computing the
|
|||
|
recurrence set. The recurrence set is the complete set of recurrence
|
|||
|
instances for a calendar component. The recurrence set is generated
|
|||
|
by considering the initial "DTSTART" property along with the "RRULE",
|
|||
|
"RDATE", "EXDATE" and "EXRULE" properties contained within the
|
|||
|
iCalendar object. The "DTSTART" property defines the first instance
|
|||
|
in the recurrence set. Multiple instances of the "RRULE" and "EXRULE"
|
|||
|
properties can also be specified to define more sophisticated
|
|||
|
recurrence sets. The final recurrence set is generated by gathering
|
|||
|
all of the start date/times generated by any of the specified "RRULE"
|
|||
|
and "RDATE" properties, and excluding any start date/times which fall
|
|||
|
within the union of start date/times generated by any specified
|
|||
|
"EXRULE" and "EXDATE" properties. This implies that start date/times
|
|||
|
within exclusion related properties (i.e., "EXDATE" and "EXRULE")
|
|||
|
take precedence over those specified by inclusion properties (i.e.,
|
|||
|
"RDATE" and "RRULE"). Where duplicate instances are generated by the
|
|||
|
"RRULE" and "RDATE" properties, only one recurrence is considered.
|
|||
|
Duplicate instances are ignored.
|
|||
|
|
|||
|
Format Definition: The property is defined by the following notation:
|
|||
|
|
|||
|
rdate = "RDATE" rdtparam ":" rdtval *("," rdtval) CRLF
|
|||
|
|
|||
|
rdtparam = *(
|
|||
|
|
|||
|
; the following are optional,
|
|||
|
; but MUST NOT occur more than once
|
|||
|
|
|||
|
(";" "VALUE" "=" ("DATE-TIME" / "DATE" / "PERIOD")) /
|
|||
|
(";" tzidparam) /
|
|||
|
|
|||
|
; the following is optional,
|
|||
|
; and MAY occur more than once
|
|||
|
|
|||
|
(";" xparam)
|
|||
|
|
|||
|
)
|
|||
|
|
|||
|
rdtval = date-time / date / period
|
|||
|
;Value MUST match value type
|
|||
|
|
|||
|
Example: The following are examples of this property:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 116]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
RDATE:19970714T123000Z
|
|||
|
|
|||
|
RDATE;TZID=US-EASTERN:19970714T083000
|
|||
|
|
|||
|
RDATE;VALUE=PERIOD:19960403T020000Z/19960403T040000Z,
|
|||
|
19960404T010000Z/PT3H
|
|||
|
|
|||
|
RDATE;VALUE=DATE:19970101,19970120,19970217,19970421
|
|||
|
19970526,19970704,19970901,19971014,19971128,19971129,19971225
|
|||
|
|
|||
|
4.8.5.4 Recurrence Rule
|
|||
|
|
|||
|
Property Name: RRULE
|
|||
|
|
|||
|
Purpose: This property defines a rule or repeating pattern for
|
|||
|
recurring events, to-dos, or time zone definitions.
|
|||
|
|
|||
|
Value Type: RECUR
|
|||
|
|
|||
|
Property Parameters: Non-standard property parameters can be
|
|||
|
specified on this property.
|
|||
|
|
|||
|
Conformance: This property can be specified one or more times in
|
|||
|
recurring "VEVENT", "VTODO" and "VJOURNAL" calendar components. It
|
|||
|
can also be specified once in each STANDARD or DAYLIGHT sub-component
|
|||
|
of the "VTIMEZONE" calendar component.
|
|||
|
|
|||
|
Description: The recurrence rule, if specified, is used in computing
|
|||
|
the recurrence set. The recurrence set is the complete set of
|
|||
|
recurrence instances for a calendar component. The recurrence set is
|
|||
|
generated by considering the initial "DTSTART" property along with
|
|||
|
the "RRULE", "RDATE", "EXDATE" and "EXRULE" properties contained
|
|||
|
within the iCalendar object. The "DTSTART" property defines the first
|
|||
|
instance in the recurrence set. Multiple instances of the "RRULE" and
|
|||
|
"EXRULE" properties can also be specified to define more
|
|||
|
sophisticated recurrence sets. The final recurrence set is generated
|
|||
|
by gathering all of the start date/times generated by any of the
|
|||
|
specified "RRULE" and "RDATE" properties, and excluding any start
|
|||
|
date/times which fall within the union of start date/times generated
|
|||
|
by any specified "EXRULE" and "EXDATE" properties. This implies that
|
|||
|
start date/times within exclusion related properties (i.e., "EXDATE"
|
|||
|
and "EXRULE") take precedence over those specified by inclusion
|
|||
|
properties (i.e., "RDATE" and "RRULE"). Where duplicate instances are
|
|||
|
generated by the "RRULE" and "RDATE" properties, only one recurrence
|
|||
|
is considered. Duplicate instances are ignored.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 117]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
The "DTSTART" and "DTEND" property pair or "DTSTART" and "DURATION"
|
|||
|
property pair, specified within the iCalendar object defines the
|
|||
|
first instance of the recurrence. When used with a recurrence rule,
|
|||
|
the "DTSTART" and "DTEND" properties MUST be specified in local time
|
|||
|
and the appropriate set of "VTIMEZONE" calendar components MUST be
|
|||
|
included. For detail on the usage of the "VTIMEZONE" calendar
|
|||
|
component, see the "VTIMEZONE" calendar component definition.
|
|||
|
|
|||
|
Any duration associated with the iCalendar object applies to all
|
|||
|
members of the generated recurrence set. Any modified duration for
|
|||
|
specific recurrences MUST be explicitly specified using the "RDATE"
|
|||
|
property.
|
|||
|
|
|||
|
Format Definition: This property is defined by the following
|
|||
|
notation:
|
|||
|
|
|||
|
rrule = "RRULE" rrulparam ":" recur CRLF
|
|||
|
|
|||
|
rrulparam = *(";" xparam)
|
|||
|
|
|||
|
Example: All examples assume the Eastern United States time zone.
|
|||
|
|
|||
|
Daily for 10 occurrences:
|
|||
|
|
|||
|
DTSTART;TZID=US-Eastern:19970902T090000
|
|||
|
RRULE:FREQ=DAILY;COUNT=10
|
|||
|
|
|||
|
==> (1997 9:00 AM EDT)September 2-11
|
|||
|
|
|||
|
Daily until December 24, 1997:
|
|||
|
|
|||
|
DTSTART;TZID=US-Eastern:19970902T090000
|
|||
|
RRULE:FREQ=DAILY;UNTIL=19971224T000000Z
|
|||
|
|
|||
|
==> (1997 9:00 AM EDT)September 2-30;October 1-25
|
|||
|
(1997 9:00 AM EST)October 26-31;November 1-30;December 1-23
|
|||
|
|
|||
|
Every other day - forever:
|
|||
|
|
|||
|
DTSTART;TZID=US-Eastern:19970902T090000
|
|||
|
RRULE:FREQ=DAILY;INTERVAL=2
|
|||
|
==> (1997 9:00 AM EDT)September2,4,6,8...24,26,28,30;
|
|||
|
October 2,4,6...20,22,24
|
|||
|
(1997 9:00 AM EST)October 26,28,30;November 1,3,5,7...25,27,29;
|
|||
|
Dec 1,3,...
|
|||
|
|
|||
|
Every 10 days, 5 occurrences:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 118]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
DTSTART;TZID=US-Eastern:19970902T090000
|
|||
|
RRULE:FREQ=DAILY;INTERVAL=10;COUNT=5
|
|||
|
|
|||
|
==> (1997 9:00 AM EDT)September 2,12,22;October 2,12
|
|||
|
|
|||
|
Everyday in January, for 3 years:
|
|||
|
|
|||
|
DTSTART;TZID=US-Eastern:19980101T090000
|
|||
|
RRULE:FREQ=YEARLY;UNTIL=20000131T090000Z;
|
|||
|
BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA
|
|||
|
or
|
|||
|
RRULE:FREQ=DAILY;UNTIL=20000131T090000Z;BYMONTH=1
|
|||
|
|
|||
|
==> (1998 9:00 AM EDT)January 1-31
|
|||
|
(1999 9:00 AM EDT)January 1-31
|
|||
|
(2000 9:00 AM EDT)January 1-31
|
|||
|
|
|||
|
Weekly for 10 occurrences
|
|||
|
|
|||
|
DTSTART;TZID=US-Eastern:19970902T090000
|
|||
|
RRULE:FREQ=WEEKLY;COUNT=10
|
|||
|
|
|||
|
==> (1997 9:00 AM EDT)September 2,9,16,23,30;October 7,14,21
|
|||
|
(1997 9:00 AM EST)October 28;November 4
|
|||
|
|
|||
|
Weekly until December 24, 1997
|
|||
|
|
|||
|
DTSTART;TZID=US-Eastern:19970902T090000
|
|||
|
RRULE:FREQ=WEEKLY;UNTIL=19971224T000000Z
|
|||
|
|
|||
|
==> (1997 9:00 AM EDT)September 2,9,16,23,30;October 7,14,21
|
|||
|
(1997 9:00 AM EST)October 28;November 4,11,18,25;
|
|||
|
December 2,9,16,23
|
|||
|
Every other week - forever:
|
|||
|
|
|||
|
DTSTART;TZID=US-Eastern:19970902T090000
|
|||
|
RRULE:FREQ=WEEKLY;INTERVAL=2;WKST=SU
|
|||
|
|
|||
|
==> (1997 9:00 AM EDT)September 2,16,30;October 14
|
|||
|
(1997 9:00 AM EST)October 28;November 11,25;December 9,23
|
|||
|
(1998 9:00 AM EST)January 6,20;February
|
|||
|
...
|
|||
|
|
|||
|
Weekly on Tuesday and Thursday for 5 weeks:
|
|||
|
|
|||
|
DTSTART;TZID=US-Eastern:19970902T090000
|
|||
|
RRULE:FREQ=WEEKLY;UNTIL=19971007T000000Z;WKST=SU;BYDAY=TU,TH
|
|||
|
or
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 119]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
RRULE:FREQ=WEEKLY;COUNT=10;WKST=SU;BYDAY=TU,TH
|
|||
|
|
|||
|
==> (1997 9:00 AM EDT)September 2,4,9,11,16,18,23,25,30;October 2
|
|||
|
|
|||
|
Every other week on Monday, Wednesday and Friday until December 24,
|
|||
|
1997, but starting on Tuesday, September 2, 1997:
|
|||
|
|
|||
|
DTSTART;TZID=US-Eastern:19970902T090000
|
|||
|
RRULE:FREQ=WEEKLY;INTERVAL=2;UNTIL=19971224T000000Z;WKST=SU;
|
|||
|
BYDAY=MO,WE,FR
|
|||
|
==> (1997 9:00 AM EDT)September 2,3,5,15,17,19,29;October
|
|||
|
1,3,13,15,17
|
|||
|
(1997 9:00 AM EST)October 27,29,31;November 10,12,14,24,26,28;
|
|||
|
December 8,10,12,22
|
|||
|
|
|||
|
Every other week on Tuesday and Thursday, for 8 occurrences:
|
|||
|
|
|||
|
DTSTART;TZID=US-Eastern:19970902T090000
|
|||
|
RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=8;WKST=SU;BYDAY=TU,TH
|
|||
|
|
|||
|
==> (1997 9:00 AM EDT)September 2,4,16,18,30;October 2,14,16
|
|||
|
|
|||
|
Monthly on the 1st Friday for ten occurrences:
|
|||
|
|
|||
|
DTSTART;TZID=US-Eastern:19970905T090000
|
|||
|
RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR
|
|||
|
|
|||
|
==> (1997 9:00 AM EDT)September 5;October 3
|
|||
|
(1997 9:00 AM EST)November 7;Dec 5
|
|||
|
(1998 9:00 AM EST)January 2;February 6;March 6;April 3
|
|||
|
(1998 9:00 AM EDT)May 1;June 5
|
|||
|
|
|||
|
Monthly on the 1st Friday until December 24, 1997:
|
|||
|
|
|||
|
DTSTART;TZID=US-Eastern:19970905T090000
|
|||
|
RRULE:FREQ=MONTHLY;UNTIL=19971224T000000Z;BYDAY=1FR
|
|||
|
|
|||
|
==> (1997 9:00 AM EDT)September 5;October 3
|
|||
|
(1997 9:00 AM EST)November 7;December 5
|
|||
|
|
|||
|
Every other month on the 1st and last Sunday of the month for 10
|
|||
|
occurrences:
|
|||
|
|
|||
|
DTSTART;TZID=US-Eastern:19970907T090000
|
|||
|
RRULE:FREQ=MONTHLY;INTERVAL=2;COUNT=10;BYDAY=1SU,-1SU
|
|||
|
|
|||
|
==> (1997 9:00 AM EDT)September 7,28
|
|||
|
(1997 9:00 AM EST)November 2,30
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 120]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
(1998 9:00 AM EST)January 4,25;March 1,29
|
|||
|
(1998 9:00 AM EDT)May 3,31
|
|||
|
|
|||
|
Monthly on the second to last Monday of the month for 6 months:
|
|||
|
|
|||
|
DTSTART;TZID=US-Eastern:19970922T090000
|
|||
|
RRULE:FREQ=MONTHLY;COUNT=6;BYDAY=-2MO
|
|||
|
|
|||
|
==> (1997 9:00 AM EDT)September 22;October 20
|
|||
|
(1997 9:00 AM EST)November 17;December 22
|
|||
|
(1998 9:00 AM EST)January 19;February 16
|
|||
|
|
|||
|
Monthly on the third to the last day of the month, forever:
|
|||
|
|
|||
|
DTSTART;TZID=US-Eastern:19970928T090000
|
|||
|
RRULE:FREQ=MONTHLY;BYMONTHDAY=-3
|
|||
|
|
|||
|
==> (1997 9:00 AM EDT)September 28
|
|||
|
(1997 9:00 AM EST)October 29;November 28;December 29
|
|||
|
(1998 9:00 AM EST)January 29;February 26
|
|||
|
...
|
|||
|
|
|||
|
Monthly on the 2nd and 15th of the month for 10 occurrences:
|
|||
|
|
|||
|
DTSTART;TZID=US-Eastern:19970902T090000
|
|||
|
RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=2,15
|
|||
|
|
|||
|
==> (1997 9:00 AM EDT)September 2,15;October 2,15
|
|||
|
(1997 9:00 AM EST)November 2,15;December 2,15
|
|||
|
(1998 9:00 AM EST)January 2,15
|
|||
|
|
|||
|
Monthly on the first and last day of the month for 10 occurrences:
|
|||
|
|
|||
|
DTSTART;TZID=US-Eastern:19970930T090000
|
|||
|
RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=1,-1
|
|||
|
|
|||
|
==> (1997 9:00 AM EDT)September 30;October 1
|
|||
|
(1997 9:00 AM EST)October 31;November 1,30;December 1,31
|
|||
|
(1998 9:00 AM EST)January 1,31;February 1
|
|||
|
|
|||
|
Every 18 months on the 10th thru 15th of the month for 10
|
|||
|
occurrences:
|
|||
|
|
|||
|
DTSTART;TZID=US-Eastern:19970910T090000
|
|||
|
RRULE:FREQ=MONTHLY;INTERVAL=18;COUNT=10;BYMONTHDAY=10,11,12,13,14,
|
|||
|
15
|
|||
|
|
|||
|
==> (1997 9:00 AM EDT)September 10,11,12,13,14,15
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 121]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
(1999 9:00 AM EST)March 10,11,12,13
|
|||
|
|
|||
|
Every Tuesday, every other month:
|
|||
|
|
|||
|
DTSTART;TZID=US-Eastern:19970902T090000
|
|||
|
RRULE:FREQ=MONTHLY;INTERVAL=2;BYDAY=TU
|
|||
|
|
|||
|
==> (1997 9:00 AM EDT)September 2,9,16,23,30
|
|||
|
(1997 9:00 AM EST)November 4,11,18,25
|
|||
|
(1998 9:00 AM EST)January 6,13,20,27;March 3,10,17,24,31
|
|||
|
...
|
|||
|
|
|||
|
Yearly in June and July for 10 occurrences:
|
|||
|
|
|||
|
DTSTART;TZID=US-Eastern:19970610T090000
|
|||
|
RRULE:FREQ=YEARLY;COUNT=10;BYMONTH=6,7
|
|||
|
==> (1997 9:00 AM EDT)June 10;July 10
|
|||
|
(1998 9:00 AM EDT)June 10;July 10
|
|||
|
(1999 9:00 AM EDT)June 10;July 10
|
|||
|
(2000 9:00 AM EDT)June 10;July 10
|
|||
|
(2001 9:00 AM EDT)June 10;July 10
|
|||
|
Note: Since none of the BYDAY, BYMONTHDAY or BYYEARDAY components
|
|||
|
are specified, the day is gotten from DTSTART
|
|||
|
|
|||
|
Every other year on January, February, and March for 10 occurrences:
|
|||
|
|
|||
|
DTSTART;TZID=US-Eastern:19970310T090000
|
|||
|
RRULE:FREQ=YEARLY;INTERVAL=2;COUNT=10;BYMONTH=1,2,3
|
|||
|
|
|||
|
==> (1997 9:00 AM EST)March 10
|
|||
|
(1999 9:00 AM EST)January 10;February 10;March 10
|
|||
|
(2001 9:00 AM EST)January 10;February 10;March 10
|
|||
|
(2003 9:00 AM EST)January 10;February 10;March 10
|
|||
|
|
|||
|
Every 3rd year on the 1st, 100th and 200th day for 10 occurrences:
|
|||
|
|
|||
|
DTSTART;TZID=US-Eastern:19970101T090000
|
|||
|
RRULE:FREQ=YEARLY;INTERVAL=3;COUNT=10;BYYEARDAY=1,100,200
|
|||
|
|
|||
|
==> (1997 9:00 AM EST)January 1
|
|||
|
(1997 9:00 AM EDT)April 10;July 19
|
|||
|
(2000 9:00 AM EST)January 1
|
|||
|
(2000 9:00 AM EDT)April 9;July 18
|
|||
|
(2003 9:00 AM EST)January 1
|
|||
|
(2003 9:00 AM EDT)April 10;July 19
|
|||
|
(2006 9:00 AM EST)January 1
|
|||
|
|
|||
|
Every 20th Monday of the year, forever:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 122]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
DTSTART;TZID=US-Eastern:19970519T090000
|
|||
|
RRULE:FREQ=YEARLY;BYDAY=20MO
|
|||
|
|
|||
|
==> (1997 9:00 AM EDT)May 19
|
|||
|
(1998 9:00 AM EDT)May 18
|
|||
|
(1999 9:00 AM EDT)May 17
|
|||
|
...
|
|||
|
|
|||
|
Monday of week number 20 (where the default start of the week is
|
|||
|
Monday), forever:
|
|||
|
|
|||
|
DTSTART;TZID=US-Eastern:19970512T090000
|
|||
|
RRULE:FREQ=YEARLY;BYWEEKNO=20;BYDAY=MO
|
|||
|
|
|||
|
==> (1997 9:00 AM EDT)May 12
|
|||
|
(1998 9:00 AM EDT)May 11
|
|||
|
(1999 9:00 AM EDT)May 17
|
|||
|
...
|
|||
|
|
|||
|
Every Thursday in March, forever:
|
|||
|
|
|||
|
DTSTART;TZID=US-Eastern:19970313T090000
|
|||
|
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=TH
|
|||
|
|
|||
|
==> (1997 9:00 AM EST)March 13,20,27
|
|||
|
(1998 9:00 AM EST)March 5,12,19,26
|
|||
|
(1999 9:00 AM EST)March 4,11,18,25
|
|||
|
...
|
|||
|
|
|||
|
Every Thursday, but only during June, July, and August, forever:
|
|||
|
|
|||
|
DTSTART;TZID=US-Eastern:19970605T090000
|
|||
|
RRULE:FREQ=YEARLY;BYDAY=TH;BYMONTH=6,7,8
|
|||
|
|
|||
|
==> (1997 9:00 AM EDT)June 5,12,19,26;July 3,10,17,24,31;
|
|||
|
August 7,14,21,28
|
|||
|
(1998 9:00 AM EDT)June 4,11,18,25;July 2,9,16,23,30;
|
|||
|
August 6,13,20,27
|
|||
|
(1999 9:00 AM EDT)June 3,10,17,24;July 1,8,15,22,29;
|
|||
|
August 5,12,19,26
|
|||
|
...
|
|||
|
|
|||
|
Every Friday the 13th, forever:
|
|||
|
|
|||
|
DTSTART;TZID=US-Eastern:19970902T090000
|
|||
|
EXDATE;TZID=US-Eastern:19970902T090000
|
|||
|
RRULE:FREQ=MONTHLY;BYDAY=FR;BYMONTHDAY=13
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 123]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
==> (1998 9:00 AM EST)February 13;March 13;November 13
|
|||
|
(1999 9:00 AM EDT)August 13
|
|||
|
(2000 9:00 AM EDT)October 13
|
|||
|
...
|
|||
|
|
|||
|
The first Saturday that follows the first Sunday of the month,
|
|||
|
forever:
|
|||
|
|
|||
|
DTSTART;TZID=US-Eastern:19970913T090000
|
|||
|
RRULE:FREQ=MONTHLY;BYDAY=SA;BYMONTHDAY=7,8,9,10,11,12,13
|
|||
|
|
|||
|
==> (1997 9:00 AM EDT)September 13;October 11
|
|||
|
(1997 9:00 AM EST)November 8;December 13
|
|||
|
(1998 9:00 AM EST)January 10;February 7;March 7
|
|||
|
(1998 9:00 AM EDT)April 11;May 9;June 13...
|
|||
|
...
|
|||
|
|
|||
|
Every four years, the first Tuesday after a Monday in November,
|
|||
|
forever (U.S. Presidential Election day):
|
|||
|
|
|||
|
DTSTART;TZID=US-Eastern:19961105T090000
|
|||
|
RRULE:FREQ=YEARLY;INTERVAL=4;BYMONTH=11;BYDAY=TU;BYMONTHDAY=2,3,4,
|
|||
|
5,6,7,8
|
|||
|
|
|||
|
==> (1996 9:00 AM EST)November 5
|
|||
|
(2000 9:00 AM EST)November 7
|
|||
|
(2004 9:00 AM EST)November 2
|
|||
|
...
|
|||
|
|
|||
|
The 3rd instance into the month of one of Tuesday, Wednesday or
|
|||
|
Thursday, for the next 3 months:
|
|||
|
|
|||
|
DTSTART;TZID=US-Eastern:19970904T090000
|
|||
|
RRULE:FREQ=MONTHLY;COUNT=3;BYDAY=TU,WE,TH;BYSETPOS=3
|
|||
|
|
|||
|
==> (1997 9:00 AM EDT)September 4;October 7
|
|||
|
(1997 9:00 AM EST)November 6
|
|||
|
|
|||
|
The 2nd to last weekday of the month:
|
|||
|
|
|||
|
DTSTART;TZID=US-Eastern:19970929T090000
|
|||
|
RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-2
|
|||
|
|
|||
|
==> (1997 9:00 AM EDT)September 29
|
|||
|
(1997 9:00 AM EST)October 30;November 27;December 30
|
|||
|
(1998 9:00 AM EST)January 29;February 26;March 30
|
|||
|
...
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 124]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
Every 3 hours from 9:00 AM to 5:00 PM on a specific day:
|
|||
|
|
|||
|
DTSTART;TZID=US-Eastern:19970902T090000
|
|||
|
RRULE:FREQ=HOURLY;INTERVAL=3;UNTIL=19970902T170000Z
|
|||
|
|
|||
|
==> (September 2, 1997 EDT)09:00,12:00,15:00
|
|||
|
|
|||
|
Every 15 minutes for 6 occurrences:
|
|||
|
|
|||
|
DTSTART;TZID=US-Eastern:19970902T090000
|
|||
|
RRULE:FREQ=MINUTELY;INTERVAL=15;COUNT=6
|
|||
|
|
|||
|
==> (September 2, 1997 EDT)09:00,09:15,09:30,09:45,10:00,10:15
|
|||
|
|
|||
|
Every hour and a half for 4 occurrences:
|
|||
|
|
|||
|
DTSTART;TZID=US-Eastern:19970902T090000
|
|||
|
RRULE:FREQ=MINUTELY;INTERVAL=90;COUNT=4
|
|||
|
|
|||
|
==> (September 2, 1997 EDT)09:00,10:30;12:00;13:30
|
|||
|
|
|||
|
Every 20 minutes from 9:00 AM to 4:40 PM every day:
|
|||
|
|
|||
|
DTSTART;TZID=US-Eastern:19970902T090000
|
|||
|
RRULE:FREQ=DAILY;BYHOUR=9,10,11,12,13,14,15,16;BYMINUTE=0,20,40
|
|||
|
or
|
|||
|
RRULE:FREQ=MINUTELY;INTERVAL=20;BYHOUR=9,10,11,12,13,14,15,16
|
|||
|
|
|||
|
==> (September 2, 1997 EDT)9:00,9:20,9:40,10:00,10:20,
|
|||
|
... 16:00,16:20,16:40
|
|||
|
(September 3, 1997 EDT)9:00,9:20,9:40,10:00,10:20,
|
|||
|
...16:00,16:20,16:40
|
|||
|
...
|
|||
|
|
|||
|
An example where the days generated makes a difference because of
|
|||
|
WKST:
|
|||
|
|
|||
|
DTSTART;TZID=US-Eastern:19970805T090000
|
|||
|
RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=4;BYDAY=TU,SU;WKST=MO
|
|||
|
|
|||
|
==> (1997 EDT)Aug 5,10,19,24
|
|||
|
|
|||
|
changing only WKST from MO to SU, yields different results...
|
|||
|
|
|||
|
DTSTART;TZID=US-Eastern:19970805T090000
|
|||
|
RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=4;BYDAY=TU,SU;WKST=SU
|
|||
|
==> (1997 EDT)August 5,17,19,31
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 125]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
4.8.6 Alarm Component Properties
|
|||
|
|
|||
|
The following properties specify alarm information in calendar
|
|||
|
components.
|
|||
|
|
|||
|
4.8.6.1 Action
|
|||
|
|
|||
|
Property Name: ACTION
|
|||
|
|
|||
|
Purpose: This property defines the action to be invoked when an alarm
|
|||
|
is triggered.
|
|||
|
|
|||
|
Value Type: TEXT
|
|||
|
|
|||
|
Property Parameters: Non-standard property parameters can be
|
|||
|
specified on this property.
|
|||
|
|
|||
|
Conformance: This property MUST be specified once in a "VALARM"
|
|||
|
calendar component.
|
|||
|
|
|||
|
Description: Each "VALARM" calendar component has a particular type
|
|||
|
of action associated with it. This property specifies the type of
|
|||
|
action
|
|||
|
|
|||
|
Format Definition: The property is defined by the following notation:
|
|||
|
|
|||
|
action = "ACTION" actionparam ":" actionvalue CRLF
|
|||
|
|
|||
|
actionparam = *(";" xparam)
|
|||
|
|
|||
|
actionvalue = "AUDIO" / "DISPLAY" / "EMAIL" / "PROCEDURE"
|
|||
|
/ iana-token / x-name
|
|||
|
|
|||
|
Example: The following are examples of this property in a "VALARM"
|
|||
|
calendar component:
|
|||
|
|
|||
|
ACTION:AUDIO
|
|||
|
|
|||
|
ACTION:DISPLAY
|
|||
|
|
|||
|
ACTION:PROCEDURE
|
|||
|
|
|||
|
4.8.6.2 Repeat Count
|
|||
|
|
|||
|
Property Name: REPEAT
|
|||
|
|
|||
|
Purpose: This property defines the number of time the alarm should be
|
|||
|
repeated, after the initial trigger.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 126]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
Value Type: INTEGER
|
|||
|
|
|||
|
Property Parameters: Non-standard property parameters can be
|
|||
|
specified on this property.
|
|||
|
|
|||
|
Conformance: This property can be specified in a "VALARM" calendar
|
|||
|
component.
|
|||
|
|
|||
|
Description: If the alarm triggers more than once, then this property
|
|||
|
MUST be specified along with the "DURATION" property.
|
|||
|
|
|||
|
Format Definition: The property is defined by the following notation:
|
|||
|
|
|||
|
repeatcnt = "REPEAT" repparam ":" integer CRLF
|
|||
|
;Default is "0", zero.
|
|||
|
|
|||
|
repparam = *(";" xparam)
|
|||
|
|
|||
|
Example: The following is an example of this property for an alarm
|
|||
|
that repeats 4 additional times with a 5 minute delay after the
|
|||
|
initial triggering of the alarm:
|
|||
|
|
|||
|
REPEAT:4
|
|||
|
DURATION:PT5M
|
|||
|
|
|||
|
4.8.6.3 Trigger
|
|||
|
|
|||
|
Property Name: TRIGGER
|
|||
|
|
|||
|
Purpose: This property specifies when an alarm will trigger.
|
|||
|
|
|||
|
Value Type: The default value type is DURATION. The value type can be
|
|||
|
set to a DATE-TIME value type, in which case the value MUST specify a
|
|||
|
UTC formatted DATE-TIME value.
|
|||
|
|
|||
|
Property Parameters: Non-standard, value data type, time zone
|
|||
|
identifier or trigger relationship property parameters can be
|
|||
|
specified on this property. The trigger relationship property
|
|||
|
parameter MUST only be specified when the value type is DURATION.
|
|||
|
|
|||
|
Conformance: This property MUST be specified in the "VALARM" calendar
|
|||
|
component.
|
|||
|
|
|||
|
Description: Within the "VALARM" calendar component, this property
|
|||
|
defines when the alarm will trigger. The default value type is
|
|||
|
DURATION, specifying a relative time for the trigger of the alarm.
|
|||
|
The default duration is relative to the start of an event or to-do
|
|||
|
that the alarm is associated with. The duration can be explicitly set
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 127]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
to trigger from either the end or the start of the associated event
|
|||
|
or to-do with the "RELATED" parameter. A value of START will set the
|
|||
|
alarm to trigger off the start of the associated event or to-do. A
|
|||
|
value of END will set the alarm to trigger off the end of the
|
|||
|
associated event or to-do.
|
|||
|
|
|||
|
Either a positive or negative duration may be specified for the
|
|||
|
"TRIGGER" property. An alarm with a positive duration is triggered
|
|||
|
after the associated start or end of the event or to-do. An alarm
|
|||
|
with a negative duration is triggered before the associated start or
|
|||
|
end of the event or to-do.
|
|||
|
|
|||
|
The "RELATED" property parameter is not valid if the value type of
|
|||
|
the property is set to DATE-TIME (i.e., for an absolute date and time
|
|||
|
alarm trigger). If a value type of DATE-TIME is specified, then the
|
|||
|
property value MUST be specified in the UTC time format. If an
|
|||
|
absolute trigger is specified on an alarm for a recurring event or
|
|||
|
to-do, then the alarm will only trigger for the specified absolute
|
|||
|
date/time, along with any specified repeating instances.
|
|||
|
|
|||
|
If the trigger is set relative to START, then the "DTSTART" property
|
|||
|
MUST be present in the associated "VEVENT" or "VTODO" calendar
|
|||
|
component. If an alarm is specified for an event with the trigger set
|
|||
|
relative to the END, then the "DTEND" property or the "DSTART" and
|
|||
|
"DURATION' properties MUST be present in the associated "VEVENT"
|
|||
|
calendar component. If the alarm is specified for a to-do with a
|
|||
|
trigger set relative to the END, then either the "DUE" property or
|
|||
|
the "DSTART" and "DURATION' properties MUST be present in the
|
|||
|
associated "VTODO" calendar component.
|
|||
|
|
|||
|
Alarms specified in an event or to-do which is defined in terms of a
|
|||
|
DATE value type will be triggered relative to 00:00:00 UTC on the
|
|||
|
specified date. For example, if "DTSTART:19980205, then the duration
|
|||
|
trigger will be relative to19980205T000000Z.
|
|||
|
|
|||
|
Format Definition: The property is defined by the following notation:
|
|||
|
|
|||
|
trigger = "TRIGGER" (trigrel / trigabs)
|
|||
|
|
|||
|
trigrel = *(
|
|||
|
|
|||
|
; the following are optional,
|
|||
|
; but MUST NOT occur more than once
|
|||
|
|
|||
|
(";" "VALUE" "=" "DURATION") /
|
|||
|
(";" trigrelparam) /
|
|||
|
|
|||
|
; the following is optional,
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 128]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
; and MAY occur more than once
|
|||
|
|
|||
|
(";" xparam)
|
|||
|
) ":" dur-value
|
|||
|
|
|||
|
trigabs = 1*(
|
|||
|
|
|||
|
; the following is REQUIRED,
|
|||
|
; but MUST NOT occur more than once
|
|||
|
|
|||
|
(";" "VALUE" "=" "DATE-TIME") /
|
|||
|
|
|||
|
; the following is optional,
|
|||
|
; and MAY occur more than once
|
|||
|
|
|||
|
(";" xparam)
|
|||
|
|
|||
|
) ":" date-time
|
|||
|
|
|||
|
Example: A trigger set 15 minutes prior to the start of the event or
|
|||
|
to-do.
|
|||
|
|
|||
|
TRIGGER:-P15M
|
|||
|
|
|||
|
A trigger set 5 minutes after the end of the event or to-do.
|
|||
|
|
|||
|
TRIGGER;RELATED=END:P5M
|
|||
|
|
|||
|
A trigger set to an absolute date/time.
|
|||
|
|
|||
|
TRIGGER;VALUE=DATE-TIME:19980101T050000Z
|
|||
|
|
|||
|
4.8.7 Change Management Component Properties
|
|||
|
|
|||
|
The following properties specify change management information in
|
|||
|
calendar components.
|
|||
|
|
|||
|
4.8.7.1 Date/Time Created
|
|||
|
|
|||
|
Property Name: CREATED
|
|||
|
|
|||
|
Purpose: This property specifies the date and time that the calendar
|
|||
|
information was created by the calendar user agent in the calendar
|
|||
|
store.
|
|||
|
|
|||
|
Note: This is analogous to the creation date and time for a file
|
|||
|
in the file system.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 129]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
Value Type: DATE-TIME
|
|||
|
|
|||
|
Property Parameters: Non-standard property parameters can be
|
|||
|
specified on this property.
|
|||
|
|
|||
|
Conformance: The property can be specified once in "VEVENT", "VTODO"
|
|||
|
or "VJOURNAL" calendar components.
|
|||
|
|
|||
|
Description: The date and time is a UTC value.
|
|||
|
|
|||
|
Format Definition: The property is defined by the following notation:
|
|||
|
|
|||
|
created = "CREATED" creaparam ":" date-time CRLF
|
|||
|
|
|||
|
creaparam = *(";" xparam)
|
|||
|
|
|||
|
Example: The following is an example of this property:
|
|||
|
|
|||
|
CREATED:19960329T133000Z
|
|||
|
|
|||
|
4.8.7.2 Date/Time Stamp
|
|||
|
|
|||
|
Property Name: DTSTAMP
|
|||
|
|
|||
|
Purpose: The property indicates the date/time that the instance of
|
|||
|
the iCalendar object was created.
|
|||
|
|
|||
|
Value Type: DATE-TIME
|
|||
|
|
|||
|
Property Parameters: Non-standard property parameters can be
|
|||
|
specified on this property.
|
|||
|
|
|||
|
Conformance: This property MUST be included in the "VEVENT", "VTODO",
|
|||
|
"VJOURNAL" or "VFREEBUSY" calendar components.
|
|||
|
|
|||
|
Description: The value MUST be specified in the UTC time format.
|
|||
|
|
|||
|
This property is also useful to protocols such as [IMIP] that have
|
|||
|
inherent latency issues with the delivery of content. This property
|
|||
|
will assist in the proper sequencing of messages containing iCalendar
|
|||
|
objects.
|
|||
|
|
|||
|
This property is different than the "CREATED" and "LAST-MODIFIED"
|
|||
|
properties. These two properties are used to specify when the
|
|||
|
particular calendar data in the calendar store was created and last
|
|||
|
modified. This is different than when the iCalendar object
|
|||
|
representation of the calendar service information was created or
|
|||
|
last modified.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 130]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
Format Definition: The property is defined by the following notation:
|
|||
|
|
|||
|
dtstamp = "DTSTAMP" stmparam ":" date-time CRLF
|
|||
|
|
|||
|
stmparam = *(";" xparam)
|
|||
|
|
|||
|
Example:
|
|||
|
|
|||
|
DTSTAMP:19971210T080000Z
|
|||
|
|
|||
|
4.8.7.3 Last Modified
|
|||
|
|
|||
|
Property Name: LAST-MODIFIED
|
|||
|
|
|||
|
Purpose: The property specifies the date and time that the
|
|||
|
information associated with the calendar component was last revised
|
|||
|
in the calendar store.
|
|||
|
|
|||
|
Note: This is analogous to the modification date and time for a
|
|||
|
file in the file system.
|
|||
|
|
|||
|
Value Type: DATE-TIME
|
|||
|
|
|||
|
Property Parameters: Non-standard property parameters can be
|
|||
|
specified on this property.
|
|||
|
|
|||
|
Conformance: This property can be specified in the "EVENT", "VTODO",
|
|||
|
"VJOURNAL" or "VTIMEZONE" calendar components.
|
|||
|
|
|||
|
Description: The property value MUST be specified in the UTC time
|
|||
|
format.
|
|||
|
|
|||
|
Format Definition: The property is defined by the following notation:
|
|||
|
|
|||
|
last-mod = "LAST-MODIFIED" lstparam ":" date-time CRLF
|
|||
|
|
|||
|
lstparam = *(";" xparam)
|
|||
|
|
|||
|
Example: The following is are examples of this property:
|
|||
|
|
|||
|
LAST-MODIFIED:19960817T133000Z
|
|||
|
|
|||
|
4.8.7.4 Sequence Number
|
|||
|
|
|||
|
Property Name: SEQUENCE
|
|||
|
|
|||
|
Purpose: This property defines the revision sequence number of the
|
|||
|
calendar component within a sequence of revisions.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 131]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
Value Type: integer
|
|||
|
|
|||
|
Property Parameters: Non-standard property parameters can be
|
|||
|
specified on this property.
|
|||
|
|
|||
|
Conformance: The property can be specified in "VEVENT", "VTODO" or
|
|||
|
"VJOURNAL" calendar component.
|
|||
|
|
|||
|
Description: When a calendar component is created, its sequence
|
|||
|
number is zero (US-ASCII decimal 48). It is monotonically incremented
|
|||
|
by the "Organizer's" CUA each time the "Organizer" makes a
|
|||
|
significant revision to the calendar component. When the "Organizer"
|
|||
|
makes changes to one of the following properties, the sequence number
|
|||
|
MUST be incremented:
|
|||
|
|
|||
|
. "DTSTART"
|
|||
|
|
|||
|
. "DTEND"
|
|||
|
|
|||
|
. "DUE"
|
|||
|
|
|||
|
. "RDATE"
|
|||
|
|
|||
|
. "RRULE"
|
|||
|
|
|||
|
. "EXDATE"
|
|||
|
|
|||
|
. "EXRULE"
|
|||
|
|
|||
|
. "STATUS"
|
|||
|
|
|||
|
In addition, changes made by the "Organizer" to other properties can
|
|||
|
also force the sequence number to be incremented. The "Organizer" CUA
|
|||
|
MUST increment the sequence number when ever it makes changes to
|
|||
|
properties in the calendar component that the "Organizer" deems will
|
|||
|
jeopardize the validity of the participation status of the
|
|||
|
"Attendees". For example, changing the location of a meeting from one
|
|||
|
locale to another distant locale could effectively impact the
|
|||
|
participation status of the "Attendees".
|
|||
|
|
|||
|
The "Organizer" includes this property in an iCalendar object that it
|
|||
|
sends to an "Attendee" to specify the current version of the calendar
|
|||
|
component.
|
|||
|
|
|||
|
The "Attendee" includes this property in an iCalendar object that it
|
|||
|
sends to the "Organizer" to specify the version of the calendar
|
|||
|
component that the "Attendee" is referring to.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 132]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
A change to the sequence number is not the mechanism that an
|
|||
|
"Organizer" uses to request a response from the "Attendees". The
|
|||
|
"RSVP" parameter on the "ATTENDEE" property is used by the
|
|||
|
"Organizer" to indicate that a response from the "Attendees" is
|
|||
|
requested.
|
|||
|
|
|||
|
Format Definition: This property is defined by the following
|
|||
|
notation:
|
|||
|
|
|||
|
seq = "SEQUENCE" seqparam ":" integer CRLF
|
|||
|
; Default is "0"
|
|||
|
|
|||
|
seqparam = *(";" xparam)
|
|||
|
|
|||
|
Example: The following is an example of this property for a calendar
|
|||
|
component that was just created by the "Organizer".
|
|||
|
|
|||
|
SEQUENCE:0
|
|||
|
|
|||
|
The following is an example of this property for a calendar component
|
|||
|
that has been revised two different times by the "Organizer".
|
|||
|
|
|||
|
SEQUENCE:2
|
|||
|
|
|||
|
4.8.8 Miscellaneous Component Properties
|
|||
|
|
|||
|
The following properties specify information about a number of
|
|||
|
miscellaneous features of calendar components.
|
|||
|
|
|||
|
4.8.8.1 Non-standard Properties
|
|||
|
|
|||
|
Property Name: Any property name with a "X-" prefix
|
|||
|
|
|||
|
Purpose: This class of property provides a framework for defining
|
|||
|
non-standard properties.
|
|||
|
|
|||
|
Value Type: TEXT
|
|||
|
|
|||
|
Property Parameters: Non-standard and language property parameters
|
|||
|
can be specified on this property.
|
|||
|
|
|||
|
Conformance: This property can be specified in any calendar
|
|||
|
component.
|
|||
|
|
|||
|
Description: The MIME Calendaring and Scheduling Content Type
|
|||
|
provides a "standard mechanism for doing non-standard things". This
|
|||
|
extension support is provided for implementers to "push the envelope"
|
|||
|
on the existing version of the memo. Extension properties are
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 133]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
specified by property and/or property parameter names that have the
|
|||
|
prefix text of "X-" (the two character sequence: LATIN CAPITAL LETTER
|
|||
|
X character followed by the HYPEN-MINUS character). It is recommended
|
|||
|
that vendors concatenate onto this sentinel another short prefix text
|
|||
|
to identify the vendor. This will facilitate readability of the
|
|||
|
extensions and minimize possible collision of names between different
|
|||
|
vendors. User agents that support this content type are expected to
|
|||
|
be able to parse the extension properties and property parameters but
|
|||
|
can ignore them.
|
|||
|
|
|||
|
At present, there is no registration authority for names of extension
|
|||
|
properties and property parameters. The data type for this property
|
|||
|
is TEXT. Optionally, the data type can be any of the other valid data
|
|||
|
types.
|
|||
|
|
|||
|
Format Definition: The property is defined by the following notation:
|
|||
|
|
|||
|
x-prop = x-name *(";" xparam) [";" languageparam] ":" text CRLF
|
|||
|
; Lines longer than 75 octets should be folded
|
|||
|
|
|||
|
Example: The following might be the ABC vendor's extension for an
|
|||
|
audio-clip form of subject property:
|
|||
|
|
|||
|
X-ABC-MMSUBJ;X-ABC-MMSUBJTYPE=wave:http://load.noise.org/mysubj.wav
|
|||
|
|
|||
|
4.8.8.2 Request Status
|
|||
|
|
|||
|
Property Name: REQUEST-STATUS
|
|||
|
|
|||
|
Purpose: This property defines the status code returned for a
|
|||
|
scheduling request.
|
|||
|
|
|||
|
Value Type: TEXT
|
|||
|
|
|||
|
Property Parameters: Non-standard and language property parameters
|
|||
|
can be specified on this property.
|
|||
|
|
|||
|
Conformance: The property can be specified in "VEVENT", "VTODO",
|
|||
|
"VJOURNAL" or "VFREEBUSY" calendar component.
|
|||
|
|
|||
|
Description: This property is used to return status code information
|
|||
|
related to the processing of an associated iCalendar object. The data
|
|||
|
type for this property is TEXT.
|
|||
|
|
|||
|
The value consists of a short return status component, a longer
|
|||
|
return status description component, and optionally a status-specific
|
|||
|
data component. The components of the value are separated by the
|
|||
|
SEMICOLON character (US-ASCII decimal 59).
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 134]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
The short return status is a PERIOD character (US-ASCII decimal 46)
|
|||
|
separated 3-tuple of integers. For example, "3.1.1". The successive
|
|||
|
levels of integers provide for a successive level of status code
|
|||
|
granularity.
|
|||
|
|
|||
|
The following are initial classes for the return status code.
|
|||
|
Individual iCalendar object methods will define specific return
|
|||
|
status codes for these classes. In addition, other classes for the
|
|||
|
return status code may be defined using the registration process
|
|||
|
defined later in this memo.
|
|||
|
|
|||
|
|==============+===============================================|
|
|||
|
| Short Return | Longer Return Status Description |
|
|||
|
| Status Code | |
|
|||
|
|==============+===============================================|
|
|||
|
| 1.xx | Preliminary success. This class of status |
|
|||
|
| | of status code indicates that the request has |
|
|||
|
| | request has been initially processed but that |
|
|||
|
| | completion is pending. |
|
|||
|
|==============+===============================================|
|
|||
|
| 2.xx | Successful. This class of status code |
|
|||
|
| | indicates that the request was completed |
|
|||
|
| | successfuly. However, the exact status code |
|
|||
|
| | can indicate that a fallback has been taken. |
|
|||
|
|==============+===============================================|
|
|||
|
| 3.xx | Client Error. This class of status code |
|
|||
|
| | indicates that the request was not successful.|
|
|||
|
| | The error is the result of either a syntax or |
|
|||
|
| | a semantic error in the client formatted |
|
|||
|
| | request. Request should not be retried until |
|
|||
|
| | the condition in the request is corrected. |
|
|||
|
|==============+===============================================|
|
|||
|
| 4.xx | Scheduling Error. This class of status code |
|
|||
|
| | indicates that the request was not successful.|
|
|||
|
| | Some sort of error occurred within the |
|
|||
|
| | calendaring and scheduling service, not |
|
|||
|
| | directly related to the request itself. |
|
|||
|
|==============+===============================================|
|
|||
|
|
|||
|
Format Definition: The property is defined by the following notation:
|
|||
|
|
|||
|
rstatus = "REQUEST-STATUS" rstatparam ":"
|
|||
|
statcode ";" statdesc [";" extdata]
|
|||
|
|
|||
|
rstatparam = *(
|
|||
|
|
|||
|
; the following is optional,
|
|||
|
; but MUST NOT occur more than once
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 135]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
(";" languageparm) /
|
|||
|
|
|||
|
; the following is optional,
|
|||
|
; and MAY occur more than once
|
|||
|
|
|||
|
(";" xparam)
|
|||
|
|
|||
|
)
|
|||
|
|
|||
|
statcode = 1*DIGIT *("." 1*DIGIT)
|
|||
|
;Hierarchical, numeric return status code
|
|||
|
|
|||
|
statdesc = text
|
|||
|
;Textual status description
|
|||
|
|
|||
|
extdata = text
|
|||
|
;Textual exception data. For example, the offending property
|
|||
|
;name and value or complete property line.
|
|||
|
|
|||
|
Example: The following are some possible examples of this property.
|
|||
|
The COMMA and SEMICOLON separator characters in the property value
|
|||
|
are BACKSLASH character escaped because they appear in a text value.
|
|||
|
|
|||
|
REQUEST-STATUS:2.0;Success
|
|||
|
|
|||
|
REQUEST-STATUS:3.1;Invalid property value;DTSTART:96-Apr-01
|
|||
|
|
|||
|
REQUEST-STATUS:2.8; Success\, repeating event ignored. Scheduled
|
|||
|
as a single event.;RRULE:FREQ=WEEKLY\;INTERVAL=2
|
|||
|
|
|||
|
REQUEST-STATUS:4.1;Event conflict. Date/time is busy.
|
|||
|
|
|||
|
REQUEST-STATUS:3.7;Invalid calendar user;ATTENDEE:
|
|||
|
MAILTO:jsmith@host.com
|
|||
|
|
|||
|
5 iCalendar Object Examples
|
|||
|
|
|||
|
The following examples are provided as an informational source of
|
|||
|
illustrative iCalendar objects consistent with this content type.
|
|||
|
|
|||
|
The following example specifies a three-day conference that begins at
|
|||
|
8:00 AM EDT, September 18, 1996 and end at 6:00 PM EDT, September 20,
|
|||
|
1996.
|
|||
|
|
|||
|
BEGIN:VCALENDAR PRODID:-//xyz Corp//NONSGML PDA Calendar Verson
|
|||
|
1.0//EN VERSION:2.0 BEGIN:VEVENT DTSTAMP:19960704T120000Z
|
|||
|
UID:uid1@host.com ORGANIZER:MAILTO:jsmith@host.com
|
|||
|
DTSTART:19960918T143000Z DTEND:19960920T220000Z STATUS:CONFIRMED
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 136]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
CATEGORIES:CONFERENCE SUMMARY:Networld+Interop Conference
|
|||
|
DESCRIPTION:Networld+Interop Conference
|
|||
|
and Exhibit\nAtlanta World Congress Center\n
|
|||
|
Atlanta, Georgia END:VEVENT END:VCALENDAR
|
|||
|
|
|||
|
The following example specifies a group scheduled meeting that begin
|
|||
|
at 8:30 AM EST on March 12, 1998 and end at 9:30 AM EST on March 12,
|
|||
|
1998. The "Organizer" has scheduled the meeting with one or more
|
|||
|
calendar users in a group. A time zone specification for Eastern
|
|||
|
United States has been specified.
|
|||
|
|
|||
|
BEGIN:VCALENDAR
|
|||
|
PRODID:-//RDU Software//NONSGML HandCal//EN
|
|||
|
VERSION:2.0
|
|||
|
BEGIN:VTIMEZONE
|
|||
|
TZID:US-Eastern
|
|||
|
BEGIN:STANDARD
|
|||
|
DTSTART:19981025T020000
|
|||
|
RDATE:19981025T020000
|
|||
|
TZOFFSETFROM:-0400
|
|||
|
TZOFFSETTO:-0500
|
|||
|
TZNAME:EST
|
|||
|
END:STANDARD
|
|||
|
BEGIN:DAYLIGHT
|
|||
|
DTSTART:19990404T020000
|
|||
|
RDATE:19990404T020000
|
|||
|
TZOFFSETFROM:-0500
|
|||
|
TZOFFSETTO:-0400
|
|||
|
TZNAME:EDT
|
|||
|
END:DAYLIGHT
|
|||
|
END:VTIMEZONE
|
|||
|
BEGIN:VEVENT
|
|||
|
DTSTAMP:19980309T231000Z
|
|||
|
UID:guid-1.host1.com
|
|||
|
ORGANIZER;ROLE=CHAIR:MAILTO:mrbig@host.com
|
|||
|
ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;CUTYPE=GROUP:
|
|||
|
MAILTO:employee-A@host.com
|
|||
|
DESCRIPTION:Project XYZ Review Meeting
|
|||
|
CATEGORIES:MEETING
|
|||
|
CLASS:PUBLIC
|
|||
|
CREATED:19980309T130000Z
|
|||
|
SUMMARY:XYZ Project Review
|
|||
|
DTSTART;TZID=US-Eastern:19980312T083000
|
|||
|
DTEND;TZID=US-Eastern:19980312T093000
|
|||
|
LOCATION:1CP Conference Room 4350
|
|||
|
END:VEVENT
|
|||
|
END:VCALENDAR
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 137]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
The following is an example of an iCalendar object passed in a MIME
|
|||
|
message with a single body part consisting of a "text/calendar"
|
|||
|
Content Type.
|
|||
|
|
|||
|
TO:jsmith@host1.com
|
|||
|
FROM:jdoe@host1.com
|
|||
|
MIME-VERSION:1.0
|
|||
|
MESSAGE-ID:<id3@host1.com>
|
|||
|
CONTENT-TYPE:text/calendar
|
|||
|
|
|||
|
BEGIN:VCALENDAR
|
|||
|
METHOD:xyz
|
|||
|
VERSION:2.0
|
|||
|
PRODID:-//ABC Corporation//NONSGML My Product//EN
|
|||
|
BEGIN:VEVENT
|
|||
|
DTSTAMP:19970324T1200Z
|
|||
|
SEQUENCE:0
|
|||
|
UID:uid3@host1.com
|
|||
|
ORGANIZER:MAILTO:jdoe@host1.com
|
|||
|
ATTENDEE;RSVP=TRUE:MAILTO:jsmith@host1.com
|
|||
|
DTSTART:19970324T123000Z
|
|||
|
DTEND:19970324T210000Z
|
|||
|
CATEGORIES:MEETING,PROJECT
|
|||
|
CLASS:PUBLIC
|
|||
|
SUMMARY:Calendaring Interoperability Planning Meeting
|
|||
|
DESCRIPTION:Discuss how we can test c&s interoperability\n
|
|||
|
using iCalendar and other IETF standards.
|
|||
|
LOCATION:LDB Lobby
|
|||
|
ATTACH;FMTTYPE=application/postscript:ftp://xyzCorp.com/pub/
|
|||
|
conf/bkgrnd.ps
|
|||
|
END:VEVENT
|
|||
|
END:VCALENDAR
|
|||
|
|
|||
|
The following is an example of a to-do due on April 15, 1998. An
|
|||
|
audio alarm has been specified to remind the calendar user at noon,
|
|||
|
the day before the to-do is expected to be completed and repeat
|
|||
|
hourly, four additional times. The to-do definition has been modified
|
|||
|
twice since it was initially created.
|
|||
|
|
|||
|
BEGIN:VCALENDAR
|
|||
|
VERSION:2.0
|
|||
|
PRODID:-//ABC Corporation//NONSGML My Product//EN
|
|||
|
BEGIN:VTODO
|
|||
|
DTSTAMP:19980130T134500Z
|
|||
|
SEQUENCE:2
|
|||
|
UID:uid4@host1.com
|
|||
|
ORGANIZER:MAILTO:unclesam@us.gov
|
|||
|
ATTENDEE;PARTSTAT=ACCEPTED:MAILTO:jqpublic@host.com
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 138]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
DUE:19980415T235959
|
|||
|
STATUS:NEEDS-ACTION
|
|||
|
SUMMARY:Submit Income Taxes
|
|||
|
BEGIN:VALARM
|
|||
|
ACTION:AUDIO
|
|||
|
TRIGGER:19980403T120000
|
|||
|
ATTACH;FMTTYPE=audio/basic:http://host.com/pub/audio-
|
|||
|
files/ssbanner.aud
|
|||
|
REPEAT:4
|
|||
|
DURATION:PT1H
|
|||
|
END:VALARM
|
|||
|
END:VTODO
|
|||
|
END:VCALENDAR
|
|||
|
|
|||
|
The following is an example of a journal entry.
|
|||
|
|
|||
|
BEGIN:VCALENDAR
|
|||
|
VERSION:2.0
|
|||
|
PRODID:-//ABC Corporation//NONSGML My Product//EN
|
|||
|
BEGIN:VJOURNAL
|
|||
|
DTSTAMP:19970324T120000Z
|
|||
|
UID:uid5@host1.com
|
|||
|
ORGANIZER:MAILTO:jsmith@host.com
|
|||
|
STATUS:DRAFT
|
|||
|
CLASS:PUBLIC
|
|||
|
CATEGORY:Project Report, XYZ, Weekly Meeting
|
|||
|
DESCRIPTION:Project xyz Review Meeting Minutes\n
|
|||
|
Agenda\n1. Review of project version 1.0 requirements.\n2.
|
|||
|
Definition
|
|||
|
of project processes.\n3. Review of project schedule.\n
|
|||
|
Participants: John Smith, Jane Doe, Jim Dandy\n-It was
|
|||
|
decided that the requirements need to be signed off by
|
|||
|
product marketing.\n-Project processes were accepted.\n
|
|||
|
-Project schedule needs to account for scheduled holidays
|
|||
|
and employee vacation time. Check with HR for specific
|
|||
|
dates.\n-New schedule will be distributed by Friday.\n-
|
|||
|
Next weeks meeting is cancelled. No meeting until 3/23.
|
|||
|
END:VJOURNAL
|
|||
|
END:VCALENDAR
|
|||
|
|
|||
|
The following is an example of published busy time information. The
|
|||
|
iCalendar object might be placed in the network resource
|
|||
|
www.host.com/calendar/busytime/jsmith.ifb.
|
|||
|
|
|||
|
BEGIN:VCALENDAR
|
|||
|
VERSION:2.0
|
|||
|
PRODID:-//RDU Software//NONSGML HandCal//EN
|
|||
|
BEGIN:VFREEBUSY
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 139]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
ORGANIZER:MAILTO:jsmith@host.com
|
|||
|
DTSTART:19980313T141711Z
|
|||
|
DTEND:19980410T141711Z
|
|||
|
FREEBUSY:19980314T233000Z/19980315T003000Z
|
|||
|
FREEBUSY:19980316T153000Z/19980316T163000Z
|
|||
|
FREEBUSY:19980318T030000Z/19980318T040000Z
|
|||
|
URL:http://www.host.com/calendar/busytime/jsmith.ifb
|
|||
|
END:VFREEBUSY
|
|||
|
END:VCALENDAR
|
|||
|
|
|||
|
6 Recommended Practices
|
|||
|
|
|||
|
These recommended practices should be followed in order to assure
|
|||
|
consistent handling of the following cases for an iCalendar object.
|
|||
|
|
|||
|
1. Content lines longer than 75 octets SHOULD be folded.
|
|||
|
|
|||
|
2. A calendar entry with a "DTSTART" property but no "DTEND"
|
|||
|
property does not take up any time. It is intended to represent
|
|||
|
an event that is associated with a given calendar date and time
|
|||
|
of day, such as an anniversary. Since the event does not take up
|
|||
|
any time, it MUST NOT be used to record busy time no matter what
|
|||
|
the value for the "TRANSP" property.
|
|||
|
|
|||
|
3. When the "DTSTART" and "DTEND", for "VEVENT", "VJOURNAL" and
|
|||
|
"VFREEBUSY" calendar components, and "DTSTART" and "DUE", for
|
|||
|
"VTODO" calendar components, have the same value data type (e.g.,
|
|||
|
DATE-TIME), they SHOULD specify values in the same time format
|
|||
|
(e.g., UTC time format).
|
|||
|
|
|||
|
4. When the combination of the "RRULE" and "RDATE" properties on an
|
|||
|
iCalendar object produces multiple instances having the same
|
|||
|
start date/time, they should be collapsed to, and considered as,
|
|||
|
a single instance.
|
|||
|
|
|||
|
5. When a calendar user receives multiple requests for the same
|
|||
|
calendar component (e.g., REQUEST for a "VEVENT" calendar
|
|||
|
component) as a result of being on multiple mailing lists
|
|||
|
specified by "ATTENDEE" properties in the request, they SHOULD
|
|||
|
respond to only one of the requests. The calendar user SHOULD
|
|||
|
also specify (using the "MEMBER" parameter of the "ATTENDEE"
|
|||
|
property) which mailing list they are a member of.
|
|||
|
|
|||
|
6. An implementation can truncate a "SUMMARY" property value to 255
|
|||
|
characters.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 140]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
7. If seconds of the minute are not supported by an implementation,
|
|||
|
then a value of "00" SHOULD be specified for the seconds
|
|||
|
component in a time value.
|
|||
|
|
|||
|
8. If the value type parameter (VALUE=) contains an unknown value
|
|||
|
type, it SHOULD be treated as TEXT.
|
|||
|
|
|||
|
9. TZURL values SHOULD NOT be specified as a FILE URI type. This URI
|
|||
|
form can be useful within an organization, but is problematic in
|
|||
|
the Internet.
|
|||
|
|
|||
|
10. Some possible English values for CATEGORIES property include
|
|||
|
"ANNIVERSARY", "APPOINTMENT", "BUSINESS", "EDUCATION",
|
|||
|
"HOLIDAY", "MEETING", "MISCELLANEOUS", "NON-WORKING HOURS", "NOT
|
|||
|
IN OFFICE", "PERSONAL", "PHONE CALL", "SICK DAY", "SPECIAL
|
|||
|
OCCASION", "TRAVEL", "VACATION". Categories can be specified in
|
|||
|
any registered language.
|
|||
|
|
|||
|
11. Some possible English values for RESOURCES property include
|
|||
|
"CATERING", "CHAIRS", "COMPUTER PROJECTOR", "EASEL", "OVERHEAD
|
|||
|
PROJECTOR", "SPEAKER PHONE", "TABLE", "TV", "VCR", "VIDEO
|
|||
|
PHONE", "VEHICLE". Resources can be specified in any registered
|
|||
|
language.
|
|||
|
|
|||
|
7 Registration of Content Type Elements
|
|||
|
|
|||
|
This section provides the process for registration of MIME
|
|||
|
Calendaring and Scheduling Content Type iCalendar object methods and
|
|||
|
new or modified properties.
|
|||
|
|
|||
|
7.1 Registration of New and Modified iCalendar Object Methods
|
|||
|
|
|||
|
New MIME Calendaring and Scheduling Content Type iCalendar object
|
|||
|
methods are registered by the publication of an IETF Request for
|
|||
|
Comments (RFC). Changes to an iCalendar object method are registered
|
|||
|
by the publication of a revision of the RFC defining the method.
|
|||
|
|
|||
|
7.2 Registration of New Properties
|
|||
|
|
|||
|
This section defines procedures by which new properties or enumerated
|
|||
|
property values for the MIME Calendaring and Scheduling Content Type
|
|||
|
can be registered with the IANA. Non-IANA properties can be used by
|
|||
|
bilateral agreement, provided the associated properties names follow
|
|||
|
the "X-" convention.
|
|||
|
|
|||
|
The procedures defined here are designed to allow public comment and
|
|||
|
review of new properties, while posing only a small impediment to the
|
|||
|
definition of new properties.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 141]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
Registration of a new property is accomplished by the following
|
|||
|
steps.
|
|||
|
|
|||
|
7.2.1 Define the property
|
|||
|
|
|||
|
A property is defined by completing the following template.
|
|||
|
|
|||
|
To: ietf-calendar@imc.org
|
|||
|
|
|||
|
Subject: Registration of text/calendar MIME property XXX
|
|||
|
|
|||
|
Property name:
|
|||
|
|
|||
|
Property purpose:
|
|||
|
|
|||
|
Property value type(s):
|
|||
|
|
|||
|
Property parameter (s):
|
|||
|
|
|||
|
Conformance:
|
|||
|
|
|||
|
Description:
|
|||
|
|
|||
|
Format definition:
|
|||
|
|
|||
|
Examples:
|
|||
|
|
|||
|
The meaning of each field in the template is as follows.
|
|||
|
|
|||
|
Property name: The name of the property, as it will appear in the
|
|||
|
body of an text/calendar MIME Content-Type "property: value" line to
|
|||
|
the left of the colon ":".
|
|||
|
|
|||
|
Property purpose: The purpose of the property (e.g., to indicate a
|
|||
|
delegate for the event or to-do, etc.). Give a short but clear
|
|||
|
description.
|
|||
|
|
|||
|
Property value type (s): Any of the valid value types for the
|
|||
|
property value needs to be specified. The default value type also
|
|||
|
needs to be specified. If a new value type is specified, it needs to
|
|||
|
be declared in this section.
|
|||
|
|
|||
|
Property parameter (s): Any of the valid property parameters for the
|
|||
|
property needs to be specified.
|
|||
|
|
|||
|
Conformance: The calendar components that the property can appear in
|
|||
|
needs to be specified.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 142]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
Description: Any special notes about the property, how it is to be
|
|||
|
used, etc.
|
|||
|
|
|||
|
Format definition: The ABNF for the property definition needs to be
|
|||
|
specified.
|
|||
|
|
|||
|
Examples: One or more examples of instances of the property needs to
|
|||
|
be specified.
|
|||
|
|
|||
|
7.2.2 Post the Property definition
|
|||
|
|
|||
|
The property description MUST be posted to the new property
|
|||
|
discussion list, ietf-calendar@imc.org.
|
|||
|
|
|||
|
7.2.3 Allow a comment period
|
|||
|
|
|||
|
Discussion on the new property MUST be allowed to take place on the
|
|||
|
list for a minimum of two weeks. Consensus MUST be reached on the
|
|||
|
property before proceeding to the next step.
|
|||
|
|
|||
|
7.2.4 Submit the property for approval
|
|||
|
|
|||
|
Once the two-week comment period has elapsed, and the proposer is
|
|||
|
convinced consensus has been reached on the property, the
|
|||
|
registration application should be submitted to the Method Reviewer
|
|||
|
for approval. The Method Reviewer is appointed to the Application
|
|||
|
Area Directors and can either accept or reject the property
|
|||
|
registration. An accepted registration should be passed on by the
|
|||
|
Method Reviewer to the IANA for inclusion in the official IANA method
|
|||
|
registry. The registration can be rejected for any of the following
|
|||
|
reasons. 1) Insufficient comment period; 2) Consensus not reached; 3)
|
|||
|
Technical deficiencies raised on the list or elsewhere have not been
|
|||
|
addressed. The Method Reviewer's decision to reject a property can be
|
|||
|
appealed by the proposer to the IESG, or the objections raised can be
|
|||
|
addressed by the proposer and the property resubmitted.
|
|||
|
|
|||
|
7.3 Property Change Control
|
|||
|
|
|||
|
Existing properties can be changed using the same process by which
|
|||
|
they were registered.
|
|||
|
|
|||
|
1. Define the change
|
|||
|
|
|||
|
2. Post the change
|
|||
|
|
|||
|
3. Allow a comment period
|
|||
|
|
|||
|
4. Submit the property for approval
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 143]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
Note that the original author or any other interested party can
|
|||
|
propose a change to an existing property, but that such changes
|
|||
|
should only be proposed when there are serious omissions or errors in
|
|||
|
the published memo. The Method Reviewer can object to a change if it
|
|||
|
is not backward compatible, but is not required to do so.
|
|||
|
|
|||
|
Property definitions can never be deleted from the IANA registry, but
|
|||
|
properties which are no longer believed to be useful can be declared
|
|||
|
OBSOLETE by a change to their "intended use" field.
|
|||
|
|
|||
|
8 References
|
|||
|
|
|||
|
[IMIP] Dawson, F., Mansour, S. and S. Silverberg, "iCalendar
|
|||
|
Message-based Interoperability Protocol (IMIP)", RFC 2447,
|
|||
|
November 1998.
|
|||
|
|
|||
|
[ITIP] Silverberg, S., Mansour, S., Dawson, F. and R. Hopson,
|
|||
|
"iCalendar Transport-Independent Interoperability Protocol
|
|||
|
(iTIP) : Scheduling Events, Busy Time, To-dos and Journal
|
|||
|
Entries", RFC 2446, November 1998.
|
|||
|
|
|||
|
[ISO 8601] ISO 8601, "Data elements and interchange formats-
|
|||
|
Information interchange--Representation of dates and
|
|||
|
times", International Organization for Standardization,
|
|||
|
June, 1988.
|
|||
|
|
|||
|
[ISO 9070] ISO/IEC 9070, "Information Technology_SGML Support
|
|||
|
Facilities--Registration Procedures for Public Text Owner
|
|||
|
Identifiers", Second Edition, International Organization
|
|||
|
for Standardization, April 1991.
|
|||
|
|
|||
|
[RFC 822] Crocker, D., "Standard for the Format of ARPA Internet
|
|||
|
Text Messages", STD 11, RFC 822, August 1982.
|
|||
|
|
|||
|
[RFC 1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform
|
|||
|
Resource Locators (URL)", RFC 1738, December 1994.
|
|||
|
|
|||
|
[RFC 1766] Alvestrand, H., "Tags for the Identification of
|
|||
|
Languages", RFC 1766, March 1995.
|
|||
|
|
|||
|
[RFC 2045] Freed, N. and N. Borenstein, " Multipurpose Internet Mail
|
|||
|
Extensions (MIME) - Part One: Format of Internet Message
|
|||
|
Bodies", RFC 2045, November 1996.
|
|||
|
|
|||
|
[RFC 2046] Freed, N. and N. Borenstein, " Multipurpose Internet Mail
|
|||
|
Extensions (MIME) - Part Two: Media Types", RFC 2046,
|
|||
|
November 1996.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 144]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
[RFC 2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose
|
|||
|
Internet Mail Extensions (MIME) - Part Four: Registration
|
|||
|
Procedures", RFC 2048, January 1997.
|
|||
|
|
|||
|
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
|
|||
|
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|||
|
|
|||
|
[RFC 2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
|
|||
|
Specifications: ABNF", RFC 2234, November 1997.
|
|||
|
|
|||
|
[RFC 2279] Yergeau, F., "UTF-8, a transformation format of ISO
|
|||
|
10646", RFC 2279, January 1998.
|
|||
|
|
|||
|
[RFC 2425] Howes, T., Smith, M. and F. Dawson, "A MIME Content-Type
|
|||
|
for Directory Information", RFC 2425, September 1998.
|
|||
|
|
|||
|
[RFC 2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile",
|
|||
|
RFC 2426, September 1998.
|
|||
|
|
|||
|
[TZ] Olson, A.D., et al, Time zone code and data,
|
|||
|
ftp://elsie.nci.nih.gov/pub/, updated periodically.
|
|||
|
|
|||
|
[VCAL] Internet Mail Consortium, "vCalendar - The Electronic
|
|||
|
Calendaring and Scheduling Exchange Format",
|
|||
|
http://www.imc.org/pdi/vcal-10.txt, September 18, 1996.
|
|||
|
|
|||
|
9 Acknowledgments
|
|||
|
|
|||
|
A hearty thanks to the IETF Calendaring and Scheduling Working Group
|
|||
|
and also the following individuals who have participated in the
|
|||
|
drafting, review and discussion of this memo:
|
|||
|
|
|||
|
Roland Alden, Harald T. Alvestrand, Eric Berman, Denis Bigorgne, John
|
|||
|
Binici, Bill Bliss, Philippe Boucher, Steve Carter, Andre
|
|||
|
Courtemanche, Dave Crocker, David Curley, Alec Dun, John Evans, Ross
|
|||
|
Finlayson, Randell Flint, Ned Freed, Patrik Faltstrom, Chuck
|
|||
|
Grandgent, Mark Handley, Steve Hanna, Paul B. Hill, Paul Hoffman,
|
|||
|
Ross Hopson, Mark Horton, Daryl Huff, Bruce Kahn, C. Harald Koch,
|
|||
|
Ryan Jansen, Don Lavange, Antoine Leca, Theodore Lorek, Steve
|
|||
|
Mansour, Skip Montanaro, Keith Moore, Cecil Murray, Chris Newman,
|
|||
|
John Noerenberg, Ralph Patterson, Pete Resnick, Keith Rhodes, Robert
|
|||
|
Ripberger, John Rose, Doug Royer, Andras Salamar, Ted Schuh, Vinod
|
|||
|
Seraphin, Derrick Shadel, Ken Shan, Andrew Shuman, Steve Silverberg,
|
|||
|
William P. Spencer, John Sun, Mark Towfiq, Yvonne Tso, Robert Visnov,
|
|||
|
James L. Weiner, Mike Weston, William Wyatt.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 145]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
10 Authors' and Chairs' Addresses
|
|||
|
|
|||
|
The following address information is provided in a MIME-VCARD,
|
|||
|
Electronic Business Card, format.
|
|||
|
|
|||
|
The authors of this memo are:
|
|||
|
|
|||
|
BEGIN:VCARD
|
|||
|
VERSION:3.0
|
|||
|
N:Dawson;Frank
|
|||
|
FN:Frank Dawson
|
|||
|
ORG:Lotus Development Corporation
|
|||
|
ADR;TYPE=WORK,POSTAL,PARCEL:;;6544 Battleford Drive;
|
|||
|
Raleigh;NC;27613-3502;USA
|
|||
|
TEL;TYPE=WORK,MSG:+1-919-676-9515
|
|||
|
TEL;TYPE=WORK,FAX:+1-919-676-9564
|
|||
|
EMAIL;TYPE=PREF,INTERNET:Frank_Dawson@Lotus.com
|
|||
|
EMAIL;TYPE=INTERNET:fdawson@earthlink.net
|
|||
|
URL:http://home.earthlink.net/~fdawson
|
|||
|
END:VCARD
|
|||
|
|
|||
|
BEGIN:VCARD
|
|||
|
VERSION:3.0
|
|||
|
N:Stenerson;Derik
|
|||
|
FN:Derik Stenerson
|
|||
|
ORG:Microsoft Corporation
|
|||
|
ADR;TYPE=WORK,POSTAL,PARCEL:;;One Microsoft Way;
|
|||
|
Redmond;WA;98052-6399;USA
|
|||
|
TEL;TYPE=WORK,MSG:+1-425-936-5522
|
|||
|
TEL;TYPE=WORK,FAX:+1-425-936-7329
|
|||
|
EMAIL;TYPE=INTERNET:deriks@Microsoft.com
|
|||
|
END:VCARD
|
|||
|
|
|||
|
The iCalendar object is a result of the work of the Internet
|
|||
|
Engineering Task Force Calendaring and Scheduling Working Group. The
|
|||
|
chairmen of that working group are:
|
|||
|
|
|||
|
BEGIN:VCARD
|
|||
|
VERSION:3.0
|
|||
|
N:Ganguly;Anik
|
|||
|
FN:Anik Ganguly
|
|||
|
ORG: Open Text Inc.
|
|||
|
ADR;TYPE=WORK,POSTAL,PARCEL:;Suite 101;38777 West Six Mile Road;
|
|||
|
Livonia;MI;48152;USA
|
|||
|
TEL;TYPE=WORK,MSG:+1-734-542-5955
|
|||
|
EMAIL;TYPE=INTERNET:ganguly@acm.org
|
|||
|
END:VCARD
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 146]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
The co-chairman of that working group is:
|
|||
|
|
|||
|
BEGIN:VCARD
|
|||
|
VERSION:3.0
|
|||
|
N:Moskowitz;Robert
|
|||
|
FN:Robert Moskowitz
|
|||
|
EMAIL;TYPE=INTERNET:rgm-ietf@htt-consult.com
|
|||
|
END:VCARD
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 147]
|
|||
|
|
|||
|
RFC 2445 iCalendar November 1998
|
|||
|
|
|||
|
|
|||
|
11. Full Copyright Statement
|
|||
|
|
|||
|
Copyright (C) The Internet Society (1998). All Rights Reserved.
|
|||
|
|
|||
|
This document and translations of it may be copied and furnished to
|
|||
|
others, and derivative works that comment on or otherwise explain it
|
|||
|
or assist in its implementation may be prepared, copied, published
|
|||
|
and distributed, in whole or in part, without restriction of any
|
|||
|
kind, provided that the above copyright notice and this paragraph are
|
|||
|
included on all such copies and derivative works. However, this
|
|||
|
document itself may not be modified in any way, such as by removing
|
|||
|
the copyright notice or references to the Internet Society or other
|
|||
|
Internet organizations, except as needed for the purpose of
|
|||
|
developing Internet standards in which case the procedures for
|
|||
|
copyrights defined in the Internet Standards process must be
|
|||
|
followed, or as required to translate it into languages other than
|
|||
|
English.
|
|||
|
|
|||
|
The limited permissions granted above are perpetual and will not be
|
|||
|
revoked by the Internet Society or its successors or assigns.
|
|||
|
|
|||
|
This document and the information contained herein is provided on an
|
|||
|
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
|||
|
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
|||
|
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
|||
|
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
|||
|
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dawson & Stenerson Standards Track [Page 148]
|
|||
|
|